From markus.lanthaler@gmx.net Mon Jul 1 10:19:53 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94D8A21F9A7D for ; Mon, 1 Jul 2013 10:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WMWpCsTYJSCy for ; Mon, 1 Jul 2013 10:19:49 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id DD49A11E81C5 for ; Mon, 1 Jul 2013 10:19:46 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.29]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MUiSQ-1UjooH2eOS-00YBCW for ; Mon, 01 Jul 2013 19:19:45 +0200 Received: (qmail invoked by alias); 01 Jul 2013 17:19:45 -0000 Received: from 178.115.248.36.wireless.dyn.drei.com (EHLO Vostro3500) [178.115.248.36] by mail.gmx.net (mp029) with SMTP; 01 Jul 2013 19:19:45 +0200 X-Authenticated: #419883 X-Provags-ID: V01U2FsdGVkX1/1ktd+hMj17giBgCwiXrIiiQX7D2iXLbhHS3Vg+K M+HCehJKSBt+fU From: "Markus Lanthaler" To: References: <20130617205341.15641.96770.idtracker@ietfa.amsl.com> <51BF786B.9060703@stpeter.im> In-Reply-To: <51BF786B.9060703@stpeter.im> Date: Mon, 1 Jul 2013 19:19:43 +0200 Message-ID: <016d01ce767f$2ea45990$8bed0cb0$@lanthaler@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5rnWzRfNP/SGreQsmXVJjAWHLcPQK4Rknw Content-Language: de X-Y-GMX-Trusted: 0 Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-acct-uri-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 17:19:53 -0000 I'm wondering whether it would make sense to add a feature allowing associate a date to an account. This would address problems arising from account recycling (think Yahoo). Maybe something like acct:bob@example.com?date=20130701 I think at the very least this should be covered in the security considerations. -- Markus Lanthaler @markuslanthaler > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > bounces@ietf.org] On Behalf Of Peter Saint-Andre > Sent: Monday, June 17, 2013 10:58 PM > To: apps-discuss@ietf.org > Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-acct-uri- > 05.txt > > Based on IESG feedback, added a paragraph about putting a user@host > address into the localpart of an 'acct' URI (percent-encoding the > at-sign when doing so). > > On 6/17/13 2:53 PM, 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 : The 'acct' URI Scheme > > Author(s) : Peter Saint-Andre > > Filename : draft-ietf-appsawg-acct-uri-05.txt > > Pages : 9 > > Date : 2013-06-17 > > > > Abstract: > > This document defines the 'acct' Uniform Resource Identifier (URI) > > scheme as a way to identify a user's account at a service > provider, > > irrespective of the particular protocols that can be used to > interact > > with the account. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-appsawg-acct-uri > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-appsawg-acct-uri-05 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-acct-uri-05 > > > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > > > > > -- > Peter Saint-Andre > https://stpeter.im/ > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From stpeter@stpeter.im Mon Jul 1 11:02:18 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C472F21F98AC for ; Mon, 1 Jul 2013 11:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.365 X-Spam-Level: X-Spam-Status: No, score=-102.365 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oK90kpAIM3ss for ; Mon, 1 Jul 2013 11:02:13 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B0BC221F96EB for ; Mon, 1 Jul 2013 11:02:13 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D188641346; Mon, 1 Jul 2013 12:02:50 -0600 (MDT) Message-ID: <51D1C423.5000804@stpeter.im> Date: Mon, 01 Jul 2013 12:02:11 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Markus Lanthaler References: <20130617205341.15641.96770.idtracker@ietfa.amsl.com> <51BF786B.9060703@stpeter.im> <016d01ce767f$2ea45990$8bed0cb0$@lanthaler@gmx.net> In-Reply-To: <016d01ce767f$2ea45990$8bed0cb0$@lanthaler@gmx.net> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-acct-uri-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 18:02:18 -0000 On 7/1/13 11:19 AM, Markus Lanthaler wrote: > I'm wondering whether it would make sense to add a feature allowing > associate a date to an account. This would address problems arising from > account recycling (think Yahoo). Maybe something like > > acct:bob@example.com?date=20130701 > > I think at the very least this should be covered in the security > considerations. IMHO we're beyond the point of adding new features to the 'acct' URI scheme (it has completed Working Group Last Call, IETF Last Call, and IESG review -- currently I'm working to address one issue about i18n that arose during IESG review, so that the document can be approved for publication). However, a date could be included in an API or protocol that enables applications to use 'acct' URIs. Is there a reason why this would need to be included in the URI itself? Peter -- Peter Saint-Andre https://stpeter.im/ From markus.lanthaler@gmx.net Mon Jul 1 11:14:01 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 365A311E814E for ; Mon, 1 Jul 2013 11:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJaXuU5aS+sN for ; Mon, 1 Jul 2013 11:13:55 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 1D31421F9A7D for ; Mon, 1 Jul 2013 11:13:33 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.2]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MHJbp-1UyRZr3jdb-00E86u for ; Mon, 01 Jul 2013 20:13:28 +0200 Received: (qmail invoked by alias); 01 Jul 2013 18:13:28 -0000 Received: from 178.115.248.36.wireless.dyn.drei.com (EHLO Vostro3500) [178.115.248.36] by mail.gmx.net (mp002) with SMTP; 01 Jul 2013 20:13:28 +0200 X-Authenticated: #419883 X-Provags-ID: V01U2FsdGVkX1/4KSx5R5P4nRKmnRKCuGxACd38SqM6DZvFGp1RJ4 zqthTH9ZZMcqXB From: "Markus Lanthaler" To: References: <20130617205341.15641.96770.idtracker@ietfa.amsl.com> <51BF786B.9060703@stpeter.im> <016d01ce767f$2ea45990$8bed0cb0$@lanthaler@gmx.net> <51D1C423.5000804@stpeter.im> In-Reply-To: <51D1C423.5000804@stpeter.im> Date: Mon, 1 Jul 2013 20:13:25 +0200 Message-ID: <017801ce7686$afc9db60$0f5d9220$@lanthaler@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac52hR434SValfatRwSiANlfRdjjPgAASh2w Content-Language: de X-Y-GMX-Trusted: 0 Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-acct-uri-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 18:14:01 -0000 On Monday, July 01, 2013 8:02 PM, Peter Saint-Andre wrote: > On 7/1/13 11:19 AM, Markus Lanthaler wrote: > > I'm wondering whether it would make sense to add a feature allowing > > associate a date to an account. This would address problems arising > from > > account recycling (think Yahoo). Maybe something like > > > > acct:bob@example.com?date=20130701 > > > > I think at the very least this should be covered in the security > > considerations. > > IMHO we're beyond the point of adding new features to the 'acct' URI > scheme (it has completed Working Group Last Call, IETF Last Call, and > IESG review -- currently I'm working to address one issue about i18n > that arose during IESG review, so that the document can be approved for > publication). Sorry for bringing it up so late in the process. > However, a date could be included in an API or protocol that enables > applications to use 'acct' URIs. Is there a reason why this would need > to be included in the URI itself? Sure.. but I think the date should actually be a (perhaps optional) part of the identifier, i.e., the acct URI. That would also make it easier to exchange it between various applications and protocols. -- Markus Lanthaler @markuslanthaler From stpeter@stpeter.im Mon Jul 1 12:10:36 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9729511E81B4 for ; Mon, 1 Jul 2013 12:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.404 X-Spam-Level: X-Spam-Status: No, score=-102.404 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HduQjywHHTWv for ; Mon, 1 Jul 2013 12:10:31 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 84C8D11E8232 for ; Mon, 1 Jul 2013 12:10:18 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.235]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 24E8941346; Mon, 1 Jul 2013 13:10:55 -0600 (MDT) Message-ID: <51D1D417.5040705@stpeter.im> Date: Mon, 01 Jul 2013 13:10:15 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Markus Lanthaler References: <20130617205341.15641.96770.idtracker@ietfa.amsl.com> <51BF786B.9060703@stpeter.im> <016d01ce767f$2ea45990$8bed0cb0$@lanthaler@gmx.net> <51D1C423.5000804@stpeter.im> <017801ce7686$afc9db60$0f5d9220$@lanthaler@gmx.net> In-Reply-To: <017801ce7686$afc9db60$0f5d9220$@lanthaler@gmx.net> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-acct-uri-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 19:10:37 -0000 On 7/1/13 12:13 PM, Markus Lanthaler wrote: > On Monday, July 01, 2013 8:02 PM, Peter Saint-Andre wrote: >> On 7/1/13 11:19 AM, Markus Lanthaler wrote: >>> I'm wondering whether it would make sense to add a feature allowing >>> associate a date to an account. This would address problems arising >> from >>> account recycling (think Yahoo). Maybe something like >>> >>> acct:bob@example.com?date=20130701 >>> >>> I think at the very least this should be covered in the security >>> considerations. >> >> IMHO we're beyond the point of adding new features to the 'acct' URI >> scheme (it has completed Working Group Last Call, IETF Last Call, and >> IESG review -- currently I'm working to address one issue about i18n >> that arose during IESG review, so that the document can be approved for >> publication). > > Sorry for bringing it up so late in the process. No worries. It happens. :-) >> However, a date could be included in an API or protocol that enables >> applications to use 'acct' URIs. Is there a reason why this would need >> to be included in the URI itself? > > Sure.. but I think the date should actually be a (perhaps optional) part of > the identifier, i.e., the acct URI. That would also make it easier to > exchange it between various applications and protocols. Are you arguing that it would be easier or *safer*? Also, it seems that your argument would apply to URIs in general (e.g., HTTP URIs for web pages) and not just 'acct' URIs. However, we seem to have ways to deal with stale/old HTTP URIs and the like. Thus I wonder what in your mind is special about 'acct' URIs in this respect. Peter -- Peter Saint-Andre https://stpeter.im/ From datapacrat@gmail.com Mon Jul 1 12:16:19 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CF8B11E8241 for ; Mon, 1 Jul 2013 12:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cEbRrLYpd0i2 for ; Mon, 1 Jul 2013 12:16:18 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id B8CF811E819C for ; Mon, 1 Jul 2013 12:16:14 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id hq4so3424569wib.12 for ; Mon, 01 Jul 2013 12:16: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=WQVsy0ixVw9RjnwohSsckau2URVOFlXnGHXYySHY3GY=; b=Xs6AkHLi4Uz/x+zjHlJrIotpKUYWzJqGJk1rw5LNASxxm44zlg6ndMUZXNl3+3CfRv TmspAJiZvbgsExKxHVAmhrqXTSGS+3wfK9r6fkmqIsIwe9oMEKwHTmDr4IyNClA+su98 SrDYvK6Mk9onHPA08w9F1lw9rewCudCuSew9gsOl48CPgQjibeO2afoiSeyDsUoqDRt2 9+7CVfJy9efVEhQGXH7UcIzNuzNaKbBKXhSTU4N+oTMoH+c67BDwGOVuATCcLxp/GGCW imdjszcdjpVBl7u8OwngVzRbqBFPi5LyJwsbDe3dJMyC6hsXjL97bjRyI1I+uLeKAww7 79uA== MIME-Version: 1.0 X-Received: by 10.194.47.167 with SMTP id e7mr21150118wjn.57.1372706173932; Mon, 01 Jul 2013 12:16:13 -0700 (PDT) Received: by 10.194.243.193 with HTTP; Mon, 1 Jul 2013 12:16:13 -0700 (PDT) In-Reply-To: <51D1D417.5040705@stpeter.im> References: <20130617205341.15641.96770.idtracker@ietfa.amsl.com> <51BF786B.9060703@stpeter.im> <51D1C423.5000804@stpeter.im> <51D1D417.5040705@stpeter.im> Date: Mon, 1 Jul 2013 15:16:13 -0400 Message-ID: From: DataPacRat To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-acct-uri-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 19:16:19 -0000 On Mon, Jul 1, 2013 at 3:10 PM, Peter Saint-Andre wrote: > On 7/1/13 12:13 PM, Markus Lanthaler wrote: >> On Monday, July 01, 2013 8:02 PM, Peter Saint-Andre wrote: >>> However, a date could be included in an API or protocol that enables >>> applications to use 'acct' URIs. Is there a reason why this would need >>> to be included in the URI itself? >> >> Sure.. but I think the date should actually be a (perhaps optional) part of >> the identifier, i.e., the acct URI. That would also make it easier to >> exchange it between various applications and protocols. > > Are you arguing that it would be easier or *safer*? > > Also, it seems that your argument would apply to URIs in general (e.g., > HTTP URIs for web pages) and not just 'acct' URIs. However, we seem to > have ways to deal with stale/old HTTP URIs and the like. Thus I wonder > what in your mind is special about 'acct' URIs in this respect. As I'm discovering in a discussion over at vcarddav, particular accounts seem to have a much higher turnover rate than references to those accounts. As part of a "signed vCard" proposal I'm making, an extension to the format will allow date parameters to be added to any field containing personal information, to cover just such an occasion. (They can be applied to other fields, too, such as gender, should they change over time.) Coming in so late myself, I'm not sure whether this method should be applied to the acct: URI; but since I'm using similar reasoning in my own project, it seemed worth mentioning. Thank you for your time, -- DataPacRat "Then again, I could be wrong." From paulej@packetizer.com Mon Jul 1 18:34:40 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6858021F9CCC for ; Mon, 1 Jul 2013 18:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EqBovEwGJFIm for ; Mon, 1 Jul 2013 18:34:35 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id CEFAA21F901A for ; Mon, 1 Jul 2013 18:34:07 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r621Y2JR003854 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 1 Jul 2013 21:34:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1372728844; bh=Rvh9zaZSQfxSJAMaMGlqZMT16VdQRnV1CP1LstB0tyQ=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=oz04K6T5FN3z2p7cXamegydkMt4aeKZ+iBXXTMuP+9B1i4xkbwlahduppsnWWRKA/ SPcCOBg2NRRMkF5UxZ0mDZMjgy9ZYwFaGT4pcz5yfLwM+LLRz7C/j8R3pLK/89WQ8P 0RzZxZNDywu1Q5CinTS6M4sS2g5D/WuLpw9srN2c= From: "Paul E. Jones" To: "'Markus Lanthaler'" , References: <20130617205341.15641.96770.idtracker@ietfa.amsl.com> <51BF786B.9060703@stpeter.im> <016d01ce767f$2ea45990$8bed0cb0$@lanthaler@gmx.net> <51D1C423.5000804@stpeter.im> <017801ce7686$afc9db60$0f5d9220$@lanthaler@gmx.net> In-Reply-To: <017801ce7686$afc9db60$0f5d9220$@lanthaler@gmx.net> Date: Mon, 1 Jul 2013 21:34:33 -0400 Message-ID: <044d01ce76c4$4f133710$ed39a530$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJV0E+HeqM9oFCI0wWnOEzauIjbLQFZvmQ1AgGRSyQChFqCswFTtRQ8mAhImyA= Content-Language: en-us Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-acct-uri-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 01:34:40 -0000 Markus, > > However, a date could be included in an API or protocol that enables > > applications to use 'acct' URIs. Is there a reason why this would need > > to be included in the URI itself? > > Sure.. but I think the date should actually be a (perhaps optional) part > of > the identifier, i.e., the acct URI. That would also make it easier to > exchange it between various applications and protocols. Wherever the acct URI is used, I would assume a human initially provided the URI (directly or indirectly via a simple "user@domain" entry). How would the human user know any date associated with an account? I think recycling account identifiers is a "bad thing". Set aside the acct URI scheme itself for a minute. Just imagine some prospective employer performing a search one day for some Yahoo! user ID and discovering all kinds of nasty things posted on the web several years ago by the previous owner of that account. The new owner might lose an opportunity for employment. Having a date as a part of any user identifier might help, but it is a little difficult for the average person to use. Could you imagine if all account IDs looked like paulej.20130701@packetizer.com? Not terribly friendly. We might as well just assign serial numbers to all accounts and call it a day. Paul From markus.lanthaler@gmx.net Tue Jul 2 01:31:26 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5E9211E842E for ; Tue, 2 Jul 2013 01:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QFVVpKnL5wKz for ; Tue, 2 Jul 2013 01:31:21 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id CB6E011E841F for ; Tue, 2 Jul 2013 01:31:14 -0700 (PDT) Received: from Vostro3500 ([178.115.248.36]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MbsV8-1Ucwo30gNC-00JKJV for ; Tue, 02 Jul 2013 10:31:13 +0200 From: "Markus Lanthaler" To: References: <20130617205341.15641.96770.idtracker@ietfa.amsl.com> <51BF786B.9060703@stpeter.im> <016d01ce767f$2ea45990$8bed0cb0$@lanthaler@gmx.net> <51D1C423.5000804@stpeter.im> <017801ce7686$afc9db60$0f5d9220$@lanthaler@gmx.net> <51D1D417.5040705@stpeter.im> In-Reply-To: <51D1D417.5040705@stpeter.im> Date: Tue, 2 Jul 2013 10:31:10 +0200 Message-ID: <00ea01ce76fe$82e660f0$88b322d0$@lanthaler@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac52jqB4m7/Hk7mcRk+JVH//q25QVwAbomKA Content-Language: de X-Provags-ID: V03:K0:Wp1dmCfNpozlWGGRiBRK4XP67lLPlxjVxRHUYz7w3jWy96UtAZB 9TAaaTKUN/k7prnvFR+i3io2RxUz6/2eJth6HQZfnBIjrXFw3fkNjgUzcPwCPYovH4KpuOC yYWgFWwzNqCDeI29fvAoRNezYGwYez54j1zp5+j+p9YZ1hu/8bp2Pd7E6k8E08PAe9pvUuI TAfDZrLvz/prZXH9eDfEA== Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-acct-uri-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 08:31:26 -0000 On Monday, July 01, 2013 9:10 PM, Peter Saint-Andre wrote: > >> However, a date could be included in an API or protocol that enables > >> applications to use 'acct' URIs. Is there a reason why this would > >> need to be included in the URI itself? > > > > Sure.. but I think the date should actually be a (perhaps optional) part > > of the identifier, i.e., the acct URI. That would also make it easier to > > exchange it between various applications and protocols. > > Are you arguing that it would be easier or *safer*? Well, both I think. It would make it simpler to exchange such information in an interoperable manner and the resulting systems would be safer. > Also, it seems that your argument would apply to URIs in general (e.g., > HTTP URIs for web pages) and not just 'acct' URIs. However, we seem to That's true and AFAIK there have been efforts to do such things there as well. Now of course we can't change HTTP URIs but since acct is just about to be established we still have a chance to "fix" it there. > have ways to deal with stale/old HTTP URIs and the like. Thus I wonder > what in your mind is special about 'acct' URIs in this respect. It is specifically designed to denote a user account on some system. Consequently it is highly security sensitive. We've seen the problem with recycled email accounts that have been used for user identification. Again, email is really old and we can't change it anymore. We have, however, still the chance to improve the situation for acct and I think it would be worthwhile to do so. -- Markus Lanthaler @markuslanthaler From markus.lanthaler@gmx.net Tue Jul 2 02:01:32 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0B9C11E8433 for ; Tue, 2 Jul 2013 02:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dPJR7IAol7bZ for ; Tue, 2 Jul 2013 02:01:26 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 62DC111E843E for ; Tue, 2 Jul 2013 02:01:26 -0700 (PDT) Received: from Vostro3500 ([178.115.248.36]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MN1Gu-1UrjXn3NaS-006eLr; Tue, 02 Jul 2013 11:01:24 +0200 From: "Markus Lanthaler" To: "'Paul E. Jones'" , References: <20130617205341.15641.96770.idtracker@ietfa.amsl.com> <51BF786B.9060703@stpeter.im> <016d01ce767f$2ea45990$8bed0cb0$@lanthaler@gmx.net> <51D1C423.5000804@stpeter.im> <017801ce7686$afc9db60$0f5d9220$@lanthaler@gmx.net> <044d01ce76c4$4f133710$ed39a530$@packetizer.com> In-Reply-To: <044d01ce76c4$4f133710$ed39a530$@packetizer.com> Date: Tue, 2 Jul 2013 11:01:21 +0200 Message-ID: <010901ce7702$ba7283b0$2f578b10$@lanthaler@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQJV0E+HeqM9oFCI0wWnOEzauIjbLQFZvmQ1AgGRSyQChFqCswFTtRQ8mAhImyCAAH+ZEA== Content-Language: de X-Provags-ID: V03:K0:B1IbRlgiDcpWIZoXk2PgML+BuC88RAQ44+Wq42CTYtwNxiP7Eys mOGWJ0Br7ioj6kUJ2UyoHmzHC35ltkkfnC3FHL3D4zBU33xpYiojfHon1fXlO3o4sdaEvQ3 FHmmZqsNVOC2i4QiVin4adIzDqD1VD98xAtGX6jiU5Jh4zu0y3BUMESoKQsrUabI+9B7Bk9 2xZAwk+pBdmJb5XmA9hLA== Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-acct-uri-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 09:01:32 -0000 On Tuesday, July 02, 2013 3:35 AM, Paul E. Jones wrote: > Wherever the acct URI is used, I would assume a human initially provided the > URI (directly or indirectly via a simple "user@domain" entry). How would > the human user know any date associated with an account? I'm not so sure about that, but in any case, why not simply use the current date when the user enters the acct URI? That way the system would know once for all that the user meant the account that was valid at that point in time. > I think recycling account identifiers is a "bad thing". Set aside the acct > URI scheme itself for a minute. Just imagine some prospective employer > performing a search one day for some Yahoo! user ID and discovering all > kinds of nasty things posted on the web several years ago by the previous > owner of that account. The new owner might lose an opportunity for > employment. True, but if a date would have been used there as well it would be possible to distinguish the two accounts. > Having a date as a part of any user identifier might help, but it is a > little difficult for the average person to use. Could you imagine if all > account IDs looked like paulej.20130701@packetizer.com? What about paulej@packetizer.com?date=20130701 Is that still too difficult? The date wouldn't have to be necessary though. A user can simply type in paulej@packetizer.com and the system adds the current date automatically. -- Markus Lanthaler @markuslanthaler From ht@inf.ed.ac.uk Tue Jul 2 07:45:29 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68BC421F9F77 for ; Tue, 2 Jul 2013 07:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mvHBhifFjCsi for ; Tue, 2 Jul 2013 07:45:24 -0700 (PDT) Received: from nougat.ucs.ed.ac.uk (nougat.ucs.ed.ac.uk [129.215.13.205]) by ietfa.amsl.com (Postfix) with ESMTP id BFAD321F9E91 for ; Tue, 2 Jul 2013 07:45:21 -0700 (PDT) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by nougat.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id r62Ej5Vx021920 for ; Tue, 2 Jul 2013 15:45:10 +0100 (BST) Received: from calexico.inf.ed.ac.uk (calexico.inf.ed.ac.uk [129.215.24.15]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id r62Ej3uE004707 for ; Tue, 2 Jul 2013 15:45:04 +0100 Received: from calexico.inf.ed.ac.uk (localhost [127.0.0.1]) by calexico.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id r62Ej41K010684 for ; Tue, 2 Jul 2013 15:45:04 +0100 Received: (from ht@localhost) by calexico.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id r62Ej4Ym010680; Tue, 2 Jul 2013 15:45:04 +0100 X-Authentication-Warning: calexico.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: apps-discuss@ietf.org References: <20130528150820.16413.98334.idtracker@ietfa.amsl.com> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Tue, 02 Jul 2013 15:45:04 +0100 In-Reply-To: (Henry S. Thompson's message of "Tue\, 28 May 2013 17\:47\:28 +0100") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at nougat.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.13.205 Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-xml-mediatypes-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 14:45:29 -0000 This draft has been out for a month, with only one minor comment appearing. I'd like to do one more draft and try to close this out, so please, it would be great to get any further comments this week, so I can have a final draft in place for discussion in Berlin, if anyone wants to do that (I can't make it :-(. ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From derhoermi@gmx.net Tue Jul 2 08:25:58 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 942AC21F9CD4 for ; Tue, 2 Jul 2013 08:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9w-Nc-Lh2Ig0 for ; Tue, 2 Jul 2013 08:25:54 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 2670521F9007 for ; Tue, 2 Jul 2013 08:25:54 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.17]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0Le7u6-1USMbJ2xn2-00pqHo for ; Tue, 02 Jul 2013 17:25:49 +0200 Received: (qmail invoked by alias); 02 Jul 2013 15:25:49 -0000 Received: from p5B2339F3.dip0.t-ipconnect.de (EHLO netb.Speedport_W_700V) [91.35.57.243] by mail.gmx.net (mp017) with SMTP; 02 Jul 2013 17:25:49 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1+rzblOwFarlbRASVg8OOkLr4hf4Db1O4EG5jsT3C HrLuRo7AiFWPsf From: Bjoern Hoehrmann To: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Tue, 02 Jul 2013 17:25:48 +0200 Message-ID: References: <20130528150820.16413.98334.idtracker@ietfa.amsl.com> In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-xml-mediatypes-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 15:25:58 -0000 * Henry S. Thompson wrote: >This draft has been out for a month, with only one minor comment >appearing. I'd like to do one more draft and try to close this out, >so please, it would be great to get any further comments this week, so >I can have a final draft in place for discussion in Berlin, if anyone >wants to do that (I can't make it :-(. I was waiting for a version that addresses Martin J. Dürst's comments. There still seems to be a lot of cruft that needs to be removed or con- densed, large parts of section 9 for instance. As an example, 9.19 is on "model/x3d+xml" which does not exist even though   http://www.web3d.org/x3d/publiclists/x3dpublic_list_archives/0609/msg00035.html is seven years old now, and there is no point in enumerating types for MathML, XSLT, RDF, SVG, SOAP and others as more than list items. There are a number of problems with the references, for [SVG] for instance we have formatting errors and the URL given leads an arbitrary SVG-related technical report that might be SVG 1.1 Second Edition, but it might also be an abandoned SVG 3 draft. [RFC3987] has "DUeerst". [ASCII] also has formatting errors. The document says it would update RFC 4288, but that has been obsoleted by RFC 6838. The type registration templates do not follow RFC 6838, for instance, Author and Change Controller have been split into separate fields even under RFC 4288 but for application/xml it is one field. That field does not need to list all the e-mail addresses of people listed as editors in the XML 1.0 specification. "MIME media type name" should be "Type name", "MIME subtype name" should be "Subtype name" and so on. The application/xml registration template does not mention XML 1.1 at all, so it is unclear whether the type can be used for 1.1 documents. I suspect many of the references listed as normative are not in fact normative. *HST: What do we do about the registration of +xml in RFC6839? I think we need to reproduce it with appropriate changes, as it currently references 3023, and can be simplified/clarified by including it here. . .* Including that in the document and updating RFC6839 accordingly does seem to be a good way forward. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From ht@inf.ed.ac.uk Tue Jul 2 08:57:24 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A070121F9EDB for ; Tue, 2 Jul 2013 08:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WnHclN7XzH9D for ; Tue, 2 Jul 2013 08:57:10 -0700 (PDT) Received: from nougat.ucs.ed.ac.uk (nougat.ucs.ed.ac.uk [129.215.13.205]) by ietfa.amsl.com (Postfix) with ESMTP id C757521F9D8E for ; Tue, 2 Jul 2013 08:57:08 -0700 (PDT) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by nougat.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id r62Fv1D4008927; Tue, 2 Jul 2013 16:57:01 +0100 (BST) Received: from calexico.inf.ed.ac.uk (calexico.inf.ed.ac.uk [129.215.24.15]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id r62FuxKq008024; Tue, 2 Jul 2013 16:56:59 +0100 Received: from calexico.inf.ed.ac.uk (localhost [127.0.0.1]) by calexico.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id r62Fv0t3014245; Tue, 2 Jul 2013 16:57:00 +0100 Received: (from ht@localhost) by calexico.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id r62Fv0pu014241; Tue, 2 Jul 2013 16:57:00 +0100 X-Authentication-Warning: calexico.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Bjoern Hoehrmann References: <20130528150820.16413.98334.idtracker@ietfa.amsl.com> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Tue, 02 Jul 2013 16:57:00 +0100 In-Reply-To: (Bjoern Hoehrmann's message of "Tue\, 02 Jul 2013 17\:25\:48 +0200") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Edinburgh-Scanned: at nougat.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.13.205 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-xml-mediatypes-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 15:57:24 -0000 Bjoern Hoehrmann writes: > I was waiting for a version that addresses Martin J. D=FCrst's comments. I certainly tried to address his comments -- see the DoC [1]. > There still seems to be a lot of cruft that needs to be removed or con- > densed, large parts of section 9 for instance. As an example, 9.19 is > on "model/x3d+xml" which does not exist even though > > =A0 http://www.web3d.org/x3d/publiclists/x3dpublic_list_archives/0609/msg= 00035.html > > is seven years old now, and there is no point in enumerating types for > MathML, XSLT, RDF, SVG, SOAP and others as more than list items. Martin didn't suggest pruning section 9 specifically, but I agree it could usefully get a lot smaller -- will do. > There are a number of problems with the references, for [SVG] for > instance we have formatting errors and the URL given leads an > arbitrary SVG-related technical report that might be SVG 1.1 Second > Edition, but it might also be an abandoned SVG 3 draft. [RFC3987] > has "DUeerst". [ASCII] also has formatting errors. Thanks for those, will fix. > The document says it would update RFC 4288, but that has been obsoleted > by RFC 6838. Right. > The type registration templates do not follow RFC 6838, for instance, > Author and Change Controller have been split into separate fields even > under RFC 4288 but for application/xml it is one field. That field does > not need to list all the e-mail addresses of people listed as editors > in the XML 1.0 specification. "MIME media type name" should be "Type > name", "MIME subtype name" should be "Subtype name" and so on. Will fix. > The application/xml registration template does not mention XML 1.1 at > all, so it is unclear whether the type can be used for 1.1 documents. Yes, I spotted that too late, thanks. > I suspect many of the references listed as normative are not in fact > normative. I reviewed pretty carefully and moved a significant number out of normative to non-normative -- happy to hear further specific candidates for 'demotion'. > *HST: What do we do about the registration of +xml in RFC6839? I > think we need to reproduce it with appropriate changes, as it > currently references 3023, and can be simplified/clarified by > including it here. . .* > > Including that in the document and updating RFC6839 accordingly does > seem to be a good way forward. OK -- any one else concur? Thanks v. much for feedback, ht --=20 Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged s= pam] From paulej@packetizer.com Tue Jul 2 09:28:46 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32BDE21F9E21 for ; Tue, 2 Jul 2013 09:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ho7UYoxKWIVw for ; Tue, 2 Jul 2013 09:28:41 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 02E8621F9E8A for ; Tue, 2 Jul 2013 09:28:40 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r62GScBe023704 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 2 Jul 2013 12:28:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1372782518; bh=76Wke0yFw0tQKNKDOSm7p8YLoqSALMr4XS7TJvGw+a8=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=rQc4fWXL8tP7SFJtwpznKHEtbsgFnWEeC3BO9/BkC0jLQQjhbwK2RjqzMikl5UF4C WJyPRPXXOabw0Gqvx+ecShfVaQgBwtehT9yyk12kapiL/WxeK+ttdoOz3DCjQfrpsn 9xrl295oVFTRHphZn3RQ07Kuh86OsntlPcpRwPVY= From: "Paul E. Jones" To: "'Markus Lanthaler'" , References: <20130617205341.15641.96770.idtracker@ietfa.amsl.com> <51BF786B.9060703@stpeter.im> <016d01ce767f$2ea45990$8bed0cb0$@lanthaler@gmx.net> <51D1C423.5000804@stpeter.im> <017801ce7686$afc9db60$0f5d9220$@lanthaler@gmx.net> <044d01ce76c4$4f133710$ed39a530$@packetizer.com> <010901ce7702$ba7283b0$2f578b10$@lanthaler@gmx.net> In-Reply-To: <010901ce7702$ba7283b0$2f578b10$@lanthaler@gmx.net> Date: Tue, 2 Jul 2013 12:29:10 -0400 Message-ID: <05aa01ce7741$48378220$d8a68660$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJV0E+HeqM9oFCI0wWnOEzauIjbLQFZvmQ1AgGRSyQChFqCswFTtRQ8AeGiO6sCtZA7WpfkjAwA Content-Language: en-us Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-acct-uri-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 16:28:46 -0000 Markus, > On Tuesday, July 02, 2013 3:35 AM, Paul E. Jones wrote: > > Wherever the acct URI is used, I would assume a human initially provided > the > > URI (directly or indirectly via a simple "user@domain" entry). How > would > > the human user know any date associated with an account? > > I'm not so sure about that, but in any case, why not simply use the > current > date when the user enters the acct URI? That way the system would know > once > for all that the user meant the account that was valid at that point in > time. If you want the end user to enter the current date, there is no need: the system could provide that. However, end users are not usually performing an account verification. They're querying for information or sending an email or something. > > Having a date as a part of any user identifier might help, but it is a > > little difficult for the average person to use. Could you imagine if > all > > account IDs looked like paulej.20130701@packetizer.com? > > What about paulej@packetizer.com?date=20130701 > > Is that still too difficult? The date wouldn't have to be necessary though. > A user can simply type in paulej@packetizer.com and the system adds the > current date automatically. You want to change the format of the email URI, too? Paul From internet-drafts@ietf.org Tue Jul 2 10:45:23 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A266321F9A6F; Tue, 2 Jul 2013 10:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.486 X-Spam-Level: X-Spam-Status: No, score=-102.486 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1+62qqetBHLr; Tue, 2 Jul 2013 10:45:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B52A821F9AC2; Tue, 2 Jul 2013 10:45:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130702174522.28106.26177.idtracker@ietfa.amsl.com> Date: Tue, 02 Jul 2013 10:45:22 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-acct-uri-06.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 17:45:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Working G= roup of the IETF. Title : The 'acct' URI Scheme Author(s) : Peter Saint-Andre Filename : draft-ietf-appsawg-acct-uri-06.txt Pages : 9 Date : 2013-07-02 Abstract: This document defines the 'acct' Uniform Resource Identifier (URI) scheme as a way to identify a user's account at a service provider, irrespective of the particular protocols that can be used to interact with the account. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-acct-uri There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-acct-uri-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-acct-uri-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From stpeter@stpeter.im Tue Jul 2 10:46:15 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98E4B21F9AF0 for ; Tue, 2 Jul 2013 10:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.469 X-Spam-Level: X-Spam-Status: No, score=-102.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PPBIL6fuo5zn for ; Tue, 2 Jul 2013 10:46:11 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id C4CE621F9AFD for ; Tue, 2 Jul 2013 10:46:10 -0700 (PDT) Received: from sjc-vpn5-1046.cisco.com (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id DBBD14134D; Tue, 2 Jul 2013 11:46:50 -0600 (MDT) Message-ID: <51D311E0.9050305@stpeter.im> Date: Tue, 02 Jul 2013 11:46:08 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20130702174522.28106.26177.idtracker@ietfa.amsl.com> In-Reply-To: <20130702174522.28106.26177.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-acct-uri-06.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 17:46:15 -0000 Another update to address final IESG feedback... On 7/2/13 11:45 AM, 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 : The 'acct' URI Scheme > Author(s) : Peter Saint-Andre > Filename : draft-ietf-appsawg-acct-uri-06.txt > Pages : 9 > Date : 2013-07-02 > > Abstract: > This document defines the 'acct' Uniform Resource Identifier (URI) > scheme as a way to identify a user's account at a service provider, > irrespective of the particular protocols that can be used to interact > with the account. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-appsawg-acct-uri > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-appsawg-acct-uri-06 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-acct-uri-06 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From barryleiba.mailing.lists@gmail.com Tue Jul 2 10:46:23 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB4A721F9BC2 for ; Tue, 2 Jul 2013 10:46:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.939 X-Spam-Level: X-Spam-Status: No, score=-101.939 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sGkjKpaGCMMg for ; Tue, 2 Jul 2013 10:46:23 -0700 (PDT) Received: from mail-vb0-x232.google.com (mail-vb0-x232.google.com [IPv6:2607:f8b0:400c:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id C22F621F9BCE for ; Tue, 2 Jul 2013 10:46:20 -0700 (PDT) Received: by mail-vb0-f50.google.com with SMTP id w16so4853073vbb.37 for ; Tue, 02 Jul 2013 10:46:19 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=uxmkGNUstjE3JXwfOOQa8StBjDLn4KMkdMvA/4t6boE=; b=kU0c4xdbseL40m/yhxNLSCeh/puUdXE3j9Z7D7IVEJdp0M9KcOxhL2jX9891JRWE9Z VjV/k1W/t/TPfa4qogi2U1a4wt0C9k2t+VEs3J3EergAiI6Y2LUlZ5BKHmTIjchXcOsv 0+joR/GF7OpKhdKruLEoTyiPjyu0EcfXj1LK0zN5abWVgNXvpBoutkKFnbCChGaG5LQP SOd2WiwYXCr3FId3vDRwqlP6Tly1A6me6PLW3NBJ8r+xdLyI2yxwFQslu0+nwplsaX2f G+GTsgYErNYVU02n/Iqkp9ub7DbVq8sTfwKHTcoGgy/rOSIBm0BE/S5qMQeldLB8H4DY eeXA== MIME-Version: 1.0 X-Received: by 10.220.98.68 with SMTP id p4mr11685179vcn.28.1372787179183; Tue, 02 Jul 2013 10:46:19 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.137.227 with HTTP; Tue, 2 Jul 2013 10:46:19 -0700 (PDT) In-Reply-To: <05aa01ce7741$48378220$d8a68660$@packetizer.com> References: <20130617205341.15641.96770.idtracker@ietfa.amsl.com> <51BF786B.9060703@stpeter.im> <51D1C423.5000804@stpeter.im> <044d01ce76c4$4f133710$ed39a530$@packetizer.com> <05aa01ce7741$48378220$d8a68660$@packetizer.com> Date: Tue, 2 Jul 2013 13:46:19 -0400 X-Google-Sender-Auth: R0erR1_Wx5E19JfHA2lvHrpvxCc Message-ID: From: Barry Leiba To: "Paul E. Jones" Content-Type: text/plain; charset=ISO-8859-1 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-acct-uri-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 17:46:24 -0000 > If you want the end user to enter the current date, there is no need: the > system could provide that. However, end users are not usually performing an > account verification. They're querying for information or sending an email > or something. I've been reading this with interest, because I think there's an interesting use case here. But... Yes, the idea is interesting, being able to say, "When I say acct:ferd@example.com, I'm talking about the entity who had that account back in 2007. If the one who has it now is the same entity, great. If not, tell me, and don't do anything else." It strikes me, though, that that's a function of the protocol you're giving the URI to, not one of the URI itself. As Paul points out, taking this to the mailto: URI (which would be very useful indeed, to be able to say, "If this isn't the same user as the one from 2007, don't deliver my email message!") would mean that something would have to understand what to do with "mailto:ferd@example.com?date=20070410". At the moment, at least, nothing does, and there's certainly no way in SMTP to convey that. A smart email client might be taught to turn that into "acct:ferd@example.com?date=20070410" and send off a webfinger (or web-foot, or whatever) query, and then only do the message submission if it got the go-ahead from that. But in that case, the date-related query belongs as part of the web-foot protocol, not as part of the URI. If you just want to use the URI as a convenient place to store the validity date, I don't buy that. Barry From tony@att.com Tue Jul 2 11:06:32 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5FC921F9C06 for ; Tue, 2 Jul 2013 11:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.48 X-Spam-Level: X-Spam-Status: No, score=-105.48 tagged_above=-999 required=5 tests=[AWL=-0.173, BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b7bVFTbmMKEp for ; Tue, 2 Jul 2013 11:06:26 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id F037521F9BCF for ; Tue, 2 Jul 2013 11:06:25 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 1a613d15.0.7788827.00-489.21723249.nbfkord-smmo05.seg.att.com (envelope-from ); Tue, 02 Jul 2013 18:06:25 +0000 (UTC) X-MXL-Hash: 51d316a15a1783bb-15d5ad66f73ab9af598fd1eedbeec2ae1c398b5e Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r62I6PAq000800 for ; Tue, 2 Jul 2013 14:06:25 -0400 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r62I6JTZ000759 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 2 Jul 2013 14:06:20 -0400 Received: from alpi153.aldc.att.com (alpi153.aldc.att.com [130.8.42.31]) by alpi131.aldc.att.com (RSA Interceptor) for ; Tue, 2 Jul 2013 18:06:02 GMT Received: from aldc.att.com (localhost [127.0.0.1]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id r62I61Rc002752 for ; Tue, 2 Jul 2013 14:06:02 -0400 Received: from mailgw1.maillennium.att.com (maillennium.att.com [135.25.114.99]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id r62I5rgZ002505 for ; Tue, 2 Jul 2013 14:05:55 -0400 Received: from [135.70.247.111] (vpn-135-70-247-111.vpn.east.att.com[135.70.247.111]) by maillennium.att.com (mailgw1) with ESMTP id <20130702180553gw100bhhf3e> (Authid: tony); Tue, 2 Jul 2013 18:05:53 +0000 X-Originating-IP: [135.70.247.111] Message-ID: <51D31689.1050900@att.com> Date: Tue, 02 Jul 2013 14:06:01 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 CC: apps-discuss@ietf.org References: <20130528150820.16413.98334.idtracker@ietfa.amsl.com> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=A9DbydqG c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=ErclZcP0gggA:10 a=3ukmKKXcZEAA:10 a=BxYK8I4q7hEA:10 a=ofM] X-AnalysisOut: [gfj31e3cA:10 a=BLceEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=zQP7CpK] X-AnalysisOut: [OAAAA:8 a=Z21_oMWbUr8A:10 a=JEF8CjgGHCqb_M3XvCgA:9 a=wPNLv] X-AnalysisOut: [fGTeEIA:10 a=_7TtuFm0MZIA:10 a=NJhTYNpwtyMA:10] Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-xml-mediatypes-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 18:06:33 -0000 On 7/2/2013 11:57 AM, Henry S. Thompson wrote: > >> *HST: What do we do about the registration of +xml in RFC6839? I >> think we need to reproduce it with appropriate changes, as it >> currently references 3023, and can be simplified/clarified by >> including it here. . .* >> >> Including that in the document and updating RFC6839 accordingly does >> seem to be a good way forward. > OK -- any one else concur? Yes, I agree. Tony Hansen RFC 6839 co-author From markus.lanthaler@gmx.net Tue Jul 2 11:35:04 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A88B21F9B66 for ; Tue, 2 Jul 2013 11:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFLsPeoydxcV for ; Tue, 2 Jul 2013 11:34:58 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 4353321F9AD1 for ; Tue, 2 Jul 2013 11:34:58 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.10]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0LbO5M-1UVVJ62csE-00ktIn for ; Tue, 02 Jul 2013 20:34:54 +0200 Received: (qmail invoked by alias); 02 Jul 2013 18:34:54 -0000 Received: from 178.115.249.85.wireless.dyn.drei.com (EHLO Vostro3500) [178.115.249.85] by mail.gmx.net (mp010) with SMTP; 02 Jul 2013 20:34:54 +0200 X-Authenticated: #419883 X-Provags-ID: V01U2FsdGVkX1/jwVkiBSjj2SO3rK9PKxuwnQ+Xs6jWsrfGOfeRf9 4pwWVY91u+/Ar8 From: "Markus Lanthaler" To: References: <20130617205341.15641.96770.idtracker@ietfa.amsl.com> <51BF786B.9060703@stpeter.im> <51D1C423.5000804@stpeter.im> <044d01ce76c4$4f133710$ed39a530$@packetizer.com> <05aa01ce7741$48378220$d8a68660$@packetizer.com> In-Reply-To: Date: Tue, 2 Jul 2013 20:34:52 +0200 Message-ID: <008101ce7752$d84865d0$88d93170$@lanthaler@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac53TA9nCRq+Nfa2SKOXljPYA6RB3wABeFxA Content-Language: de X-Y-GMX-Trusted: 0 Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-acct-uri-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 18:35:04 -0000 On Tuesday, July 02, 2013 7:46 PM, Barry Leiba wrote: > Yes, the idea is interesting, being able to say, "When I say > acct:ferd@example.com, I'm talking about the entity who had that > account back in 2007. If the one who has it now is the same entity, > great. If not, tell me, and don't do anything else." It strikes me, > though, that that's a function of the protocol you're giving the URI > to, not one of the URI itself. I think that's really the main question: what does the acct URI identify? In my opinion it identifies a user (account). There may be different users that use the same "userpart" over time but that doesn't mean they are the same users. > As Paul points out, taking this to the > mailto: URI (which would be very useful indeed, to be able to say, "If > this isn't the same user as the one from 2007, don't deliver my email > message!") would mean that something would have to understand what to > do with "mailto:ferd@example.com?date=20070410". At the moment, at > least, nothing does, and there's certainly no way in SMTP to convey > that. > > A smart email client might be taught to turn that into > "acct:ferd@example.com?date=20070410" and send off a webfinger (or > web-foot, or whatever) query, and then only do the message submission > if it got the go-ahead from that. But in that case, the date-related > query belongs as part of the web-foot protocol, not as part of the > URI. Of course you can work around such limitations by making the protocols smarter but as history has shown, this is rarely done and leads (at least sometimes) to massive problems. Why do you think it belongs in the protocol? > If you just want to use the URI as a convenient place to store the > validity date, I don't buy that. No, I think it goes a bit beyond that. From paulej@packetizer.com Tue Jul 2 12:00:59 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BFF311E80DF for ; Tue, 2 Jul 2013 12:00:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zS3e+mqJ6r28 for ; Tue, 2 Jul 2013 12:00:52 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 8C9F121F9A26 for ; Tue, 2 Jul 2013 12:00:29 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r62J0LZ7000542 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 2 Jul 2013 15:00:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1372791621; bh=wpRGE4BmSg/QpuR1hdXafAdbYTDE2RgoQNoFpY4+mFM=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=hax30t43XKzw2tR1FYNa3RKuVICjDRzbxaxCmI3lZEGnih3D350pcwY2RZlI0b/jr TinPcFidMz3bp7GM9CaJSWT7mzXMvrujzr+MX0OxYigvjU8A1faPCrnetAqY+h+vg9 1Zbd/MSUH2gxcW8r8lDpDlNm5bk1o3F80FSBaKBI= From: "Paul E. Jones" To: "'Barry Leiba'" References: <20130617205341.15641.96770.idtracker@ietfa.amsl.com> <51BF786B.9060703@stpeter.im> <51D1C423.5000804@stpeter.im> <044d01ce76c4$4f133710$ed39a530$@packetizer.com> <05aa01ce7741$48378220$d8a68660$@packetizer.com> In-Reply-To: Date: Tue, 2 Jul 2013 15:00:53 -0400 Message-ID: <064801ce7756$7a33f000$6e9bd000$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJV0E+HeqM9oFCI0wWnOEzauIjbLQFZvmQ1AoRagrMB4aI7qwIasMd+AiziNPGX8smaoA== Content-Language: en-us Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-acct-uri-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 19:00:59 -0000 Barry, =20 > A smart email client might be taught to turn that into > "acct:ferd@example.com?date=3D20070410" and send off a webfinger (or > web-foot, or whatever) query, and then only do the message submission > if it got the go-ahead from that. But in that case, the date-related > query belongs as part of the web-foot protocol, not as part of the > URI. That kind of data element could be returned via WebFinger as a = "property". For example: "properties" : { "http://packetizer.com/ns/name" : "Paul E. Jones", "http://packetizer.com/ns/name#zh-CN" : = "=E4=BF=9D=E7=BD=97=E2=80=A7=E7=90=BC=E6=96=AF" "http://packetizer.com/ns/activated" : "2000-02-17T03:00:00Z" } It would be a matter of defining the property identifier (which is a = URI) and the format of the date/time string. =20 > If you just want to use the URI as a convenient place to store the > validity date, I don't buy that. I don't either. Humans have to enter these identifiers. Dates in an = identifier just make it more difficult for the human user. Paul From bobwyman@gmail.com Tue Jul 2 13:21:10 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6195611E80DC for ; Tue, 2 Jul 2013 13:21:10 -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=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xlfLFMZUyJYR for ; Tue, 2 Jul 2013 13:21:09 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 1736A21F9A75 for ; Tue, 2 Jul 2013 13:21:08 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id m6so4559251wiv.14 for ; Tue, 02 Jul 2013 13:21:08 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=U3SY08/epC/IUN8KuZdVtNu+USav37WX03VscpYGQXs=; b=tt0s1rXOb+7CCCpnucbd56UDUPCBfKzjXYCq8jF1sEJSFZQIpy7vxCY3l+HcrkL4uP S4RN9jbubQhepvHMNOoYBuWLAM2jHHPXyrp56eMFkK1VkzmKP3uCB4l3CChpcTXd7tcX z0Qt13gq71U+JmOUDhktRNqyldDT+DN6Rn3wXfN3sVSZfORTzmeGp8bo8UMlS7fl0KOg 7gjYhDL3J3v4ZcsiCvpy6zX+4Duijh/amsdwNSJxSMV3dJnXmubnQtaAxr1HoNAAHoHy jmuoFUJk1MH97kVF7IkzYnHm6ApUkZepUmgz7UnjcNmL4bLkdBQ0qC0avWN5ZjlufG/o zSFQ== MIME-Version: 1.0 X-Received: by 10.180.74.232 with SMTP id x8mr16341684wiv.48.1372796468206; Tue, 02 Jul 2013 13:21:08 -0700 (PDT) Sender: bobwyman@gmail.com Received: by 10.194.125.200 with HTTP; Tue, 2 Jul 2013 13:21:08 -0700 (PDT) In-Reply-To: <51d1ba3b.c190420a.786f.ffffe818SMTPIN_ADDED_BROKEN@mx.google.com> References: <20130617205341.15641.96770.idtracker@ietfa.amsl.com> <51BF786B.9060703@stpeter.im> <51d1ba3b.c190420a.786f.ffffe818SMTPIN_ADDED_BROKEN@mx.google.com> Date: Tue, 2 Jul 2013 16:21:08 -0400 X-Google-Sender-Auth: jlsR9krE9QUUlq0LvWYwykRjfVA Message-ID: From: Bob Wyman To: Markus Lanthaler Content-Type: multipart/alternative; boundary=f46d043c08b0d623a504e08d152d Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-acct-uri-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 20:21:10 -0000 --f46d043c08b0d623a504e08d152d Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jul 1, 2013 at 1:19 PM, Markus Lanthaler wrote: > I'm wondering whether it would make sense to add a feature allowing > associate a date to an account. This would address problems arising from > account recycling (think Yahoo). Maybe something like > > acct:bob@example.com?date=20130701 It seems to me that if one wanted to use dates as part of identifiers, you would probably want to learn from tag URI's as defined in RFC 4151. Tag URI's handle the problem of creating identifiers that are unique across time -- which appears to be the use-case you're looking to address. Thus, rather than the syntax you suggested, you'd be using something like this: (i.e. use a comma, not a question-mark.) acct:bob@example.com,2001-09-15 The relevant ABNF bits from RFC4151 are: > taggingEntity = authorityName "," date > authorityName = DNSname / emailAddress > date = year ["-" month ["-" day]] ... > > I think at the very least this should be covered in the security > considerations. > > > -- > Markus Lanthaler > @markuslanthaler > > > >> -----Original Message----- >> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- >> bounces@ietf.org] On Behalf Of Peter Saint-Andre >> Sent: Monday, June 17, 2013 10:58 PM >> To: apps-discuss@ietf.org >> Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-acct-uri- >> 05.txt >> >> Based on IESG feedback, added a paragraph about putting a user@host >> address into the localpart of an 'acct' URI (percent-encoding the >> at-sign when doing so). >> >> On 6/17/13 2:53 PM, 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 : The 'acct' URI Scheme >> > Author(s) : Peter Saint-Andre >> > Filename : draft-ietf-appsawg-acct-uri-05.txt >> > Pages : 9 >> > Date : 2013-06-17 >> > >> > Abstract: >> > This document defines the 'acct' Uniform Resource Identifier (URI) >> > scheme as a way to identify a user's account at a service >> provider, >> > irrespective of the particular protocols that can be used to >> interact >> > with the account. >> > >> > >> > The IETF datatracker status page for this draft is: >> > https://datatracker.ietf.org/doc/draft-ietf-appsawg-acct-uri >> > >> > There's also a htmlized version available at: >> > http://tools.ietf.org/html/draft-ietf-appsawg-acct-uri-05 >> > >> > A diff from the previous version is available at: >> > http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-acct-uri-05 >> > >> > >> > Internet-Drafts are also available by anonymous FTP at: >> > ftp://ftp.ietf.org/internet-drafts/ >> > >> > _______________________________________________ >> > apps-discuss mailing list >> > apps-discuss@ietf.org >> > https://www.ietf.org/mailman/listinfo/apps-discuss >> > >> >> >> -- >> Peter Saint-Andre >> https://stpeter.im/ >> >> >> _______________________________________________ >> 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 --f46d043c08b0d623a504e08d152d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Mon, Jul 1, 2013 at 1:19 PM, Markus Lanthaler &= lt;markus.lanthaler@gmx.net= > wrote:
> I'm wondering whether it would make sense to add a = feature allowing
> associate a date to an account. This would address problems arising fr= om
> account recycling (think Yahoo). Maybe something like
>> =A0 =A0acct:b= ob@example.com?date=3D20130701
It seems to me that if one wanted to use dates as part of identifiers, you = would probably want to learn from tag URI's as defined in RFC 4151. Tag URI's handle the p= roblem of creating identifiers that are unique across time -- which appears= to be the use-case you're looking to address.

Thus, rather than the syntax you suggested, you'd be using som= ething like this: (i.e. use a comma, not a question-mark.)

acct:bob@example.c= om,2001-09-15

The relevant ABNF bits from RFC4151 are:
taggingEntity =3D authorityName "," date
authorityName =3D DNS= name / emailAddress
date =3D year ["-" month ["-" da= y]]
...=A0

>
> I t= hink at the very least this should be covered in the security
> considerations.
>
>
> --
> Markus Lanthaler> @markuslanthaler
>
>
>
>> -----Original Me= ssage-----
>> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-
>> bounces@ietf.org] On Behal= f Of Peter Saint-Andre
>> Sent: Monday, June 17, 2013 10:58 PM
= >> To: apps-discuss@ietf.org=
>> Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-acct-ur= i-
>> 05.txt
>>
>> Based on IESG feedback, added= a paragraph about putting a user@host
>> address into the localpa= rt of an 'acct' URI (percent-encoding the
>> at-sign when doing so).
>>
>> On 6/17/13 2:53 PM= , internet-drafts@ietf.org = wrote:
>> >
>> > A New Internet-Draft is available = from the on-line Internet-Drafts
>> directories.
>> > =A0This draft is a work item of the = Applications Area Working Group
>> Working Group of the IETF.
&= gt;> >
>> > =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : The '= acct' URI Scheme
>> > =A0 =A0 Author(s) =A0 =A0 =A0 : Peter Saint-Andre
>>= > =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-appsawg-acct-uri-05.txt<= br>>> > =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 9
>> > =A0= =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-06-17
>> >
>> > Abstract:
>> > =A0 =A0This docum= ent defines the 'acct' Uniform Resource Identifier (URI)
>>= ; > =A0 =A0scheme as a way to identify a user's account at a service=
>> provider,
>> > =A0 =A0irrespective of the particular p= rotocols that can be used to
>> interact
>> > =A0 =A0w= ith the account.
>> >
>> >
>> > The IET= F datatracker status page for this draft is:
>> > https://datatracker.ietf.org/doc/draft-ietf-appsawg-acct-uri
>> >
>> > There's also a htmlized version ava= ilable at:
>> > http://tools.ietf.org/html/draft-ietf-appsawg-acct-uri-05
&= gt;> >
>> > A diff from the previous version is available= at:
>> > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-acct= -uri-05
>> >
>> >
>> > Internet-Dra= fts are also available by anonymous FTP at:
>> > ftp://ftp.iet= f.org/internet-drafts/
>> >
>> > ______________= _________________________________
>> > apps-discuss mailing lis= t
>> > apps-discuss@ietf.or= g
>> > https://www.ietf.org/mailman/listinfo/apps-discuss
>&g= t; >
>>
>>
>> --
>> Peter Saint-Andre
>&g= t; https://stpeter.im/
>>
&= gt;>
>> _______________________________________________
>= > 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-discu= ss

--f46d043c08b0d623a504e08d152d-- From superuser@gmail.com Tue Jul 2 13:45:11 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCB4C21F9BB3 for ; Tue, 2 Jul 2013 13:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vPKd5VoNA25E for ; Tue, 2 Jul 2013 13:45:11 -0700 (PDT) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 2346221F9BAF for ; Tue, 2 Jul 2013 13:45:10 -0700 (PDT) Received: by mail-wg0-f53.google.com with SMTP id y10so5246799wgg.32 for ; Tue, 02 Jul 2013 13:45:10 -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=oLUrPazJcs08advfpeh3LTWiAgi7Av7UpyYYAeB2ES0=; b=hE3lBoHHIvFxV+mEfvd/6NwipMBUxf2YDlAmWx8lV1ajC+cZlZEwfLVXULmQif22nX JUH+Kd5Lkvf3SNWzy3y3YruuqPw5U3njhAt7lRqo9vVU6v42UufXzlrRfnytrWBsJ8LX r8eJygVhjbvJQqyMTqIvY8fdV3YadOZPkDtOkCe9nJX+w4p+TkWF2Ha7RM3O6805M971 smN4zUAzjTJKAV2gVy0SBe1ItUrMCHl+Xqwyxv7xK5J5v/G8gcyeTf9LPSMsu411eliI Rt+Ysu8SZ1RK+JyS+TKiadvhGlTG/l/t+RFXPep49PNxcXhwLQsBn2rnraE5Hmv4/8id EIAQ== MIME-Version: 1.0 X-Received: by 10.180.187.209 with SMTP id fu17mr16445509wic.52.1372797910252; Tue, 02 Jul 2013 13:45:10 -0700 (PDT) Received: by 10.180.90.16 with HTTP; Tue, 2 Jul 2013 13:45:10 -0700 (PDT) In-Reply-To: References: <20130625204239.35722.qmail@joyce.lan> Date: Tue, 2 Jul 2013 13:45:10 -0700 Message-ID: From: "Murray S. Kucherawy" To: "John R. Levine" Content-Type: multipart/alternative; boundary=001a11c269acca05ae04e08d6b5c Cc: John Levine , IETF Apps Discuss Subject: Re: [apps-discuss] Remember the MX 0 . draft? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 20:45:11 -0000 --001a11c269acca05ae04e08d6b5c Content-Type: text/plain; charset=ISO-8859-1 On Sat, Jun 29, 2013 at 10:32 AM, John R. Levine wrote: > > Do I formally ask appsarea to take it up, or what? > > Yes, or the co-chairs can. Is there a draft to point at yet, or is there one coming? -MSK --001a11c269acca05ae04e08d6b5c Content-Type: text/html; charset=ISO-8859-1
On Sat, Jun 29, 2013 at 10:32 AM, John R. Levine <johnl@iecc.com> wrote:

Do I formally ask appsarea to take it up, or what?


Yes, or the co-chairs can.

Is there a draft to point at yet, or is there one coming?

-MSK

--001a11c269acca05ae04e08d6b5c-- From datapacrat@gmail.com Tue Jul 2 14:11:24 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C21811E80E0 for ; Tue, 2 Jul 2013 14:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G4GyYr7Okqs5 for ; Tue, 2 Jul 2013 14:11:23 -0700 (PDT) Received: from mail-ve0-x234.google.com (mail-ve0-x234.google.com [IPv6:2607:f8b0:400c:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id ECC0821F9A84 for ; Tue, 2 Jul 2013 14:11:21 -0700 (PDT) Received: by mail-ve0-f180.google.com with SMTP id pa12so5237856veb.25 for ; Tue, 02 Jul 2013 14:11:21 -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=8as8+C9WNb17pVz2N0mm/eCqt8QvjbnTQ/hhphoNCsU=; b=zOURmp2W7/Wr68yo8B317jBcOn1XB9SUvyQQpa+zxjdNNNlmGXjHt+BKGznSpmjecy MpjtJEvbS9SBhYYgVVGIJbCsMnvJazZbehNd1jQBx5aHI1NugzL5VUZ2UNIneCW5RiMi IVqDElDx0twBxqBpT6cB6hCXBMKTuHUryq2BOEr9EgTeVefFkUS1kL5bXDorwutMw6qE lzZDnhX631USUiEdKz1zcmL8dPylMyTZl7/zRRrYzsYoOIMlSjBe64d50UtLzJfB6yV9 r15IhUddkn5nX4PtyUe8Po25mHPSN4iAaySMhFfGcKjQFSN4mQRQdg9bHDk2DKoNNM4F fnfQ== MIME-Version: 1.0 X-Received: by 10.58.96.76 with SMTP id dq12mr11844046veb.91.1372799481396; Tue, 02 Jul 2013 14:11:21 -0700 (PDT) Received: by 10.220.232.6 with HTTP; Tue, 2 Jul 2013 14:11:21 -0700 (PDT) In-Reply-To: References: <20130617205341.15641.96770.idtracker@ietfa.amsl.com> <51BF786B.9060703@stpeter.im> <51d1ba3b.c190420a.786f.ffffe818SMTPIN_ADDED_BROKEN@mx.google.com> Date: Tue, 2 Jul 2013 17:11:21 -0400 Message-ID: From: DataPacRat To: Bob Wyman Content-Type: text/plain; charset=ISO-8859-1 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-acct-uri-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 21:11:24 -0000 On Tue, Jul 2, 2013 at 4:21 PM, Bob Wyman wrote: > On Mon, Jul 1, 2013 at 1:19 PM, Markus Lanthaler > wrote: >> I'm wondering whether it would make sense to add a feature allowing >> associate a date to an account. This would address problems arising from >> account recycling (think Yahoo). Maybe something like >> >> acct:bob@example.com?date=20130701 > It seems to me that if one wanted to use dates as part of identifiers, you > would probably want to learn from tag URI's as defined in RFC 4151. Tag > URI's handle the problem of creating identifiers that are unique across time > -- which appears to be the use-case you're looking to address. > > Thus, rather than the syntax you suggested, you'd be using something like > this: (i.e. use a comma, not a question-mark.) > > acct:bob@example.com,2001-09-15 > > The relevant ABNF bits from RFC4151 are: >> >> taggingEntity = authorityName "," date >> authorityName = DNSname / emailAddress >> date = year ["-" month ["-" day]] While being inspired by tag:, you needn't feel limited by its particular syntax. The date field on tag doesn't allow any more precision than midnight on a particular day; and it only allows for indicating particular moments rather than periods of time. It should be simple enough to draw on ISO 8601's full range of time-indicators, to allow (while not requiring) the indication of any particular second (eg, 2001-09-15T12:34:56Z), or a period of time (eg, 2001-01-01/P1Y to indicate the entirety of that year). Thank you for your time, -- DataPacRat "Then again, I could be wrong." From bobwyman@gmail.com Tue Jul 2 14:45:31 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70B1D21F9A74 for ; Tue, 2 Jul 2013 14:45:31 -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=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oqWzhe7Iayxt for ; Tue, 2 Jul 2013 14:45:30 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 8770121F9A72 for ; Tue, 2 Jul 2013 14:45:30 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 16so13903408iea.17 for ; Tue, 02 Jul 2013 14:45: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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Cvx3Yf36BSox2cNSS2zJtla0u0113VYZM4cIpKP+R00=; b=mxATLPwZMa71qcc4x9DV5TSMGxwF7XJHhwUPArPx7qey34TaDAmPBhdtitnKkNLEIQ a5APKape1z116Dmy72AJF19ocWn3XtmUOOyPlwphnalwvEFxNptr2AEVbyfxQFNZeWCN RYPO/iXxm62JRo8BkV6rV17VHtFEPLvNpW1OEqT6TD8ytVPulYkd/tlDQNbFlMEqeXec FcTivQIU+lDCQLhZhn0yN4eWF3TDgfCJUnY9cbBFCc7jPSFmfb5THUChO2JJVBrblF96 D+YdNKNlvOdsTqGw2OlTBr23V/CnGo8Qbv8t3Q8PTMjmGu+huil701/+By4nhJKXKDu7 oMGQ== MIME-Version: 1.0 X-Received: by 10.50.164.232 with SMTP id yt8mr20962529igb.43.1372801530102; Tue, 02 Jul 2013 14:45:30 -0700 (PDT) Sender: bobwyman@gmail.com Received: by 10.50.195.162 with HTTP; Tue, 2 Jul 2013 14:45:29 -0700 (PDT) In-Reply-To: References: <20130617205341.15641.96770.idtracker@ietfa.amsl.com> <51BF786B.9060703@stpeter.im> <51d1ba3b.c190420a.786f.ffffe818SMTPIN_ADDED_BROKEN@mx.google.com> Date: Tue, 2 Jul 2013 17:45:29 -0400 X-Google-Sender-Auth: Rz8zdbUTbdgJFALE2JGhRQxNPNQ Message-ID: From: Bob Wyman To: DataPacRat Content-Type: multipart/alternative; boundary=089e014952228c8cde04e08e430b Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-acct-uri-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 21:45:31 -0000 --089e014952228c8cde04e08e430b Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 2, 2013 at 5:11 PM, DataPacRat wrote: > On Tue, Jul 2, 2013 at 4:21 PM, Bob Wyman wrote: > > On Mon, Jul 1, 2013 at 1:19 PM, Markus Lanthaler < > markus.lanthaler@gmx.net> > > wrote: > > >> I'm wondering whether it would make sense to add a feature allowing > >> associate a date to an account. This would address problems arising from > >> account recycling (think Yahoo). Maybe something like > >> > >> acct:bob@example.com?date=20130701 > > It seems to me that if one wanted to use dates as part of identifiers, > you > > would probably want to learn from tag URI's as defined in RFC 4151. Tag > > URI's handle the problem of creating identifiers that are unique across > time > > -- which appears to be the use-case you're looking to address. > > > > Thus, rather than the syntax you suggested, you'd be using something like > > this: (i.e. use a comma, not a question-mark.) > > > > acct:bob@example.com,2001-09-15 > > > > The relevant ABNF bits from RFC4151 are: > >> > >> taggingEntity = authorityName "," date > >> authorityName = DNSname / emailAddress > >> date = year ["-" month ["-" day]] > > While being inspired by tag:, you needn't feel limited by its > particular syntax. The date field on tag doesn't allow any more > precision than midnight on a particular day; and it only allows for > indicating particular moments rather than periods of time. I think we'll find that support for "periods of time" is really not necessary for reasonable use-cases. What the date does in this context is allow you to say: "I am referring to the account that was named ' bob@example.com' during 2001-09-15." That should result in a single account being identified (if we assume that account names aren't reused more than once a day...) If ranges were supported, someone might construct something that said: "I am referring to any of the accounts that were identified as 'bob@example.com' between 2001-01-01 and 2013-0101." Depending on how often account names were reused, that could refer to a large number of accounts (i.e. >1). It is tempting, whenever dates are discussed, to want to support the full set of ISO specified date goodies, however, I really don't think it makes sense in this context. Do we want to encourage acct names to be reused more than once a day? Do we want to figure out how to address returning multiple results in protocols that use acct? (What would WebFinger do if it needed to return multiple results?) People will typically have an identifier that was discovered by them on some date in the past. Using something like WebFinger, what they will be interested in asking is: "How do I contact the person or entity who used the account "bob@example.com" on July 2, 2013?" I assume that it would be possible for a WebFinger user or acct: processor to respond with some data pointing to a current email address, etc. for the user or even some indication that they are no longer living... > It should > be simple enough to draw on ISO 8601's full range of time-indicators, > to allow (while not requiring) the indication of any particular second > (eg, 2001-09-15T12:34:56Z), or a period of time (eg, 2001-01-01/P1Y to > indicate the entirety of that year). > > > Thank you for your time, > -- > DataPacRat > "Then again, I could be wrong." > --089e014952228c8cde04e08e430b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Jul 2, 2013 at 5:11 PM, DataPacRat <datapacrat@gmail.co= m> wrote:
On Tue, Jul 2, 2013 at 4:2= 1 PM, Bob Wyman <bob@wyman.us> wr= ote:
> On Mon, Jul 1, 2013 at 1:19 PM, Markus Lanthaler <markus.lanthaler@gmx.net>
> wrote:

>> I'm wondering whether it would make sense to add a feature all= owing
>> associate a date to an account. This would address problems arisin= g from
>> account recycling (think Yahoo). Maybe something like
>>
>> =A0 =A0acct:bob@example.com?date=3D20130701
> It seems to me that if one wanted to use dates as part of identifiers,= you
> would probably want to learn from tag URI's as defined in RFC 4151= . Tag
> URI's handle the problem of creating identifiers that are unique a= cross time
> -- which appears to be the use-case you're looking to address.
>
> Thus, rather than the syntax you suggested, you'd be using somethi= ng like
> this: (i.e. use a comma, not a question-mark.)
>
> acct:bob@example.com,200= 1-09-15
>
> The relevant ABNF bits from RFC4151 are:
>>
>> taggingEntity =3D authorityName "," date
>> authorityName =3D DNSname / emailAddress
>> date =3D year ["-" month ["-" day]]

While being inspired by tag:, you needn't feel limited by its
particular syntax. The date field on tag doesn't allow any more
precision than midnight on a particular day; and it only allows for
indicating particular moments rather than periods of time.
I think we'll find that support for "periods of time" is rea= lly not necessary for reasonable use-cases. What the date does in this cont= ext is allow you to say: "I am referring to the account that was named= 'bob@example.com' during 20= 01-09-15." That should result in a single account being identified (if= we assume that account names aren't reused more than once a day...)
If ranges were supported, someone might construct something that said:= "I am referring to any of the accounts that were identified as '<= a href=3D"mailto:bob@example.com">bob@example.com' between 2001-01-= 01 and 2013-0101." Depending on how often account names were reused, t= hat could refer to a large number of accounts (i.e. >1).=A0

It is tempting, whenever dates are discussed, to want t= o support the full set of ISO specified date goodies, however, I really don= 't think it makes sense in this context. Do we want to encourage acct n= ames to be reused more than once a day? Do we want to figure out how to add= ress returning multiple results in protocols that use acct? (What would Web= Finger do if it needed to return multiple results?)

People will typically have an identifier that was disco= vered by them on some date in the past. Using something like WebFinger, wha= t they will be interested in asking is: "How do I contact the person o= r entity who used the account "bob@= example.com" on July 2, 2013?" I assume that it would be poss= ible for a WebFinger user or acct: processor to respond with some data poin= ting to a current email address, etc. for the user or even some indication = that they are no longer living...

=A0
It should<= br> be simple enough to draw on ISO 8601's full range of time-indicators, to allow (while not requiring) the indication of any particular second
(eg, 2001-09-15T12:34:56Z), or a period of time (eg, 2001-01-01/P1Y to
indicate the entirety of that year).


Thank you for your time,
--
DataPacRat
"Then again, I could be wrong."

--089e014952228c8cde04e08e430b-- From johnl@iecc.com Tue Jul 2 19:46:02 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31C3521F9A90 for ; Tue, 2 Jul 2013 19:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.641 X-Spam-Level: X-Spam-Status: No, score=-110.641 tagged_above=-999 required=5 tests=[AWL=0.558, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sVuSt6v2l8Ww for ; Tue, 2 Jul 2013 19:45:58 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id B87C821F9A8F for ; Tue, 2 Jul 2013 19:45:57 -0700 (PDT) Received: (qmail 21251 invoked from network); 3 Jul 2013 02:45:56 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 3 Jul 2013 02:45:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51d39064.xn--i8sz2z.k1307; i=johnl@user.iecc.com; bh=lQiu46fVXuv6FeKBj2cr4/mtylcwrQ1J31/2gATZ1qc=; b=fkc4lS+w8cdVa85XY4draDWtOOZLxVoWM0pqGynF12rS637hWmwMhesKUy7ctQrYeSB6SFquMyA6IQopZ4z63LJV9FpD7SZ0FTPwYX4HnRWbMGTSwdGjAGXKmEeBCBc7xAjO8746/p8MtltjbixUzv8mus3OJsP+AVPtJzPSkRXs16Wdizvy8no+42Lb1uLzSl/9loSo532weZ70G5WP7E2GODRfKU/OyijlwwTq5XKzW+alPuKeNbtc2MFefdr8 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=51d39064.xn--i8sz2z.k1307; olt=johnl@user.iecc.com; bh=lQiu46fVXuv6FeKBj2cr4/mtylcwrQ1J31/2gATZ1qc=; b=SUVaQ8eFUVxNPOy/guFE+OERe06frmgrpxx6giC+olAxeVORP1mNaLYuO35fy5S+UtHo48fmuBB81iFLya5IdxFWUiPwalIccosGMa62pEwrYZnq4EQcJeoPPIrm9lSZssXsmHjpr9HPmMbD8R2MbebKSgglnpGAfW2YocBFs2W2yrndYsko86+RsZRQ39Blvhy8QsVxKz9fvGqIn8ttagFvyxOBzNLsdz6fhcsrYuTPJU+ouGVxUBtHCCuoUYEs Date: 3 Jul 2013 02:45:34 -0000 Message-ID: <20130703024534.23245.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 Subject: Re: [apps-discuss] Remember the MX 0 . draft? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 02:46:02 -0000 >Yes, or the co-chairs can. > >Is there a draft to point at yet, or is there one coming? There will be one as soon as I can get the I-D submission tool to send me a confirmation message I can click on. From johnl@taugh.com Tue Jul 2 21:35:36 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4B5B11E8167 for ; Tue, 2 Jul 2013 21:35:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wIotU7sJHzBA for ; Tue, 2 Jul 2013 21:35:36 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id D09A211E8166 for ; Tue, 2 Jul 2013 21:35:35 -0700 (PDT) Received: (qmail 34376 invoked from network); 3 Jul 2013 04:35:34 -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:cleverness; s=8647.51d3aa16.k1307; bh=bASwDdGOK7f1+U5uHKrp7VVDm4maejPizD++8DMI5Nc=; b=Ahm9mFGRWRtSt5md8d+q7eg1GsgTewivR9bvf0GVAjsdrtcETbNFpBmwrByy9861ItXCySXVconqU1dKsERxtkxGHqveBKwLryMZmbDh6MfwAog6ADFv89fM7fuPI1vDaNsBPYfZAvre3nNlchps0rr4IP2vcYOySXyAfUyAMJf1Gu7F2X56JAFTMOowca2TqXS+L7W6sV2DWhyzEO8KOCZ6qXsEUQge8DTasWUwuMTcNZUMYmDhjxEPk0MtibLN 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:cleverness; s=8647.51d3aa16.k1307; bh=bASwDdGOK7f1+U5uHKrp7VVDm4maejPizD++8DMI5Nc=; b=uoSXFvHa59mxgtMXeQcYMhbzEYy0IZCydhko8GkNa5u5rRjPNLY2LJuWuyO4sCIDD9R2+IBBcC5mCBgiJ9EB65sFzcfmRgawJAMdl/B76sEUz3CpgCx+3/e6NkKFjveCipTMjEws5VEC5xEd+L2Ol9d4OR/eOjfSYj5r5ByuJmHoX7y7Wj3S/u5moANX5KillWhpq/JVWD2q1Oh9M1Zs/tTUG6mz6yb64qzzf8pi3klR+sLj7FWo0iWfuGDbExe6 Received: (ofmipd 127.0.0.1); 3 Jul 2013 04:35:12 -0000 Date: 3 Jul 2013 00:35:34 -0400 Message-ID: From: "John R Levine" To: apps-discuss@ietf.org In-Reply-To: <20130703024534.23245.qmail@joyce.lan> References: <20130703024534.23245.qmail@joyce.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [apps-discuss] Remember the MX 0 . draft? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 04:35:36 -0000 On Tue, 3 Jul 2013, John Levine wrote: >> Yes, or the co-chairs can. >> >> Is there a draft to point at yet, or is there one coming? See https://datatracker.ietf.org/doc/draft-delany-nullmx Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From GK@ninebynine.org Wed Jul 3 00:52:59 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3B8621F9A4A for ; Wed, 3 Jul 2013 00:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.607 X-Spam-Level: X-Spam-Status: No, score=-5.607 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dV8X2eGxRWQp for ; Wed, 3 Jul 2013 00:52:54 -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 CEC9E21F9A49 for ; Wed, 3 Jul 2013 00:52:53 -0700 (PDT) Received: from smtp0.mail.ox.ac.uk ([129.67.1.205]) by relay16.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1UuHrs-0002zc-rN; Wed, 03 Jul 2013 08:52:48 +0100 Received: from gklyne.plus.com ([80.229.154.156] helo=conina.local) by smtp0.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1UuHrs-0000FG-13; Wed, 03 Jul 2013 08:52:48 +0100 Message-ID: <51D30A19.90202@ninebynine.org> Date: Tue, 02 Jul 2013 18:12:57 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Peter Saint-Andre References: <20130617205341.15641.96770.idtracker@ietfa.amsl.com> <51BF786B.9060703@stpeter.im> <016d01ce767f$2ea45990$8bed0cb0$@lanthaler@gmx.net> <51D1C423.5000804@stpeter.im> <017801ce7686$afc9db60$0f5d9220$@lanthaler@gmx.net> <51D1D417.5040705@stpeter.im> In-Reply-To: <51D1D417.5040705@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-acct-uri-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 07:52:59 -0000 There's also Larry Masinter's old proposal for dated URIs: http://tools.ietf.org/id/draft-masinter-dated-uri-08.html (now expired). #g -- On 01/07/2013 20:10, Peter Saint-Andre wrote: > On 7/1/13 12:13 PM, Markus Lanthaler wrote: >> On Monday, July 01, 2013 8:02 PM, Peter Saint-Andre wrote: >>> On 7/1/13 11:19 AM, Markus Lanthaler wrote: >>>> I'm wondering whether it would make sense to add a feature allowing >>>> associate a date to an account. This would address problems arising >>> from >>>> account recycling (think Yahoo). Maybe something like >>>> >>>> acct:bob@example.com?date=20130701 >>>> >>>> I think at the very least this should be covered in the security >>>> considerations. >>> >>> IMHO we're beyond the point of adding new features to the 'acct' URI >>> scheme (it has completed Working Group Last Call, IETF Last Call, and >>> IESG review -- currently I'm working to address one issue about i18n >>> that arose during IESG review, so that the document can be approved for >>> publication). >> >> Sorry for bringing it up so late in the process. > > No worries. It happens. :-) > >>> However, a date could be included in an API or protocol that enables >>> applications to use 'acct' URIs. Is there a reason why this would need >>> to be included in the URI itself? >> >> Sure.. but I think the date should actually be a (perhaps optional) part of >> the identifier, i.e., the acct URI. That would also make it easier to >> exchange it between various applications and protocols. > > Are you arguing that it would be easier or *safer*? > > Also, it seems that your argument would apply to URIs in general (e.g., > HTTP URIs for web pages) and not just 'acct' URIs. However, we seem to > have ways to deal with stale/old HTTP URIs and the like. Thus I wonder > what in your mind is special about 'acct' URIs in this respect. > > Peter > From duerst@it.aoyama.ac.jp Wed Jul 3 01:18:09 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A2C221F9C09 for ; Wed, 3 Jul 2013 01:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.29 X-Spam-Level: X-Spam-Status: No, score=-103.29 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N3k3SEP84b-2 for ; Wed, 3 Jul 2013 01:18:03 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE8121F9BFC for ; Wed, 3 Jul 2013 01:18:02 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id r638HidA021139; Wed, 3 Jul 2013 17:17:44 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 14ae_316e_098e2e7c_e3b9_11e2_bf9b_001e6722eec2; Wed, 03 Jul 2013 17:17:43 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id E25FFBFF80; Wed, 3 Jul 2013 17:16:08 +0900 (JST) Message-ID: <51D3DE18.8030408@it.aoyama.ac.jp> Date: Wed, 03 Jul 2013 17:17:28 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: "Henry S. Thompson" References: <20130528150820.16413.98334.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Cc: Bjoern Hoehrmann , apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-xml-mediatypes-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 08:18:09 -0000 Hello Henry, Thanks for you work on this document and your patience. On 2013/07/03 0:57, Henry S. Thompson wrote: > Bjoern Hoehrmann writes: > >> I was waiting for a version that addresses Martin J. D=C3=BCrst's comm= ents. > > I certainly tried to address his comments -- see the DoC [1]. Unfortunately, I still have to go through that and the new draft (I=20 printed out the later a few days ago). But unfortunately, that won't=20 happen this week, hopefully over the weekend. >> There still seems to be a lot of cruft that needs to be removed or con= - >> densed, large parts of section 9 for instance. As an example, 9.19 is >> on "model/x3d+xml" which does not exist even though >> >> http://www.web3d.org/x3d/publiclists/x3dpublic_list_archives/0609/m= sg00035.html >> >> is seven years old now, and there is no point in enumerating types for >> MathML, XSLT, RDF, SVG, SOAP and others as more than list items. > > Martin didn't suggest pruning section 9 specifically, but I agree it > could usefully get a lot smaller -- will do. There was so much language that sounded outdated that at some point, I=20 stopped making specific proposals. Basically, if you still find anything=20 that smells like "this made a lot of sense ca. 2000" rather than "I=20 guess this still reads reasonably well in 2020", then please fix it. Regards, Martin. >> There are a number of problems with the references, for [SVG] for >> instance we have formatting errors and the URL given leads an >> arbitrary SVG-related technical report that might be SVG 1.1 Second >> Edition, but it might also be an abandoned SVG 3 draft. [RFC3987] >> has "DUeerst". [ASCII] also has formatting errors. > > Thanks for those, will fix. > >> The document says it would update RFC 4288, but that has been obsolete= d >> by RFC 6838. > > Right. > >> The type registration templates do not follow RFC 6838, for instance, >> Author and Change Controller have been split into separate fields even >> under RFC 4288 but for application/xml it is one field. That field doe= s >> not need to list all the e-mail addresses of people listed as editors >> in the XML 1.0 specification. "MIME media type name" should be "Type >> name", "MIME subtype name" should be "Subtype name" and so on. > > Will fix. > >> The application/xml registration template does not mention XML 1.1 at >> all, so it is unclear whether the type can be used for 1.1 documents. > > Yes, I spotted that too late, thanks. > >> I suspect many of the references listed as normative are not in fact >> normative. > > I reviewed pretty carefully and moved a significant number out of > normative to non-normative -- happy to hear further specific > candidates for 'demotion'. > >> *HST: What do we do about the registration of +xml in RFC6839? I >> think we need to reproduce it with appropriate changes, as it >> currently references 3023, and can be simplified/clarified by >> including it here. . .* >> >> Including that in the document and updating RFC6839 accordingly does >> seem to be a good way forward. > > OK -- any one else concur? > > Thanks v. much for feedback, > > ht From stbryant@cisco.com Wed Jul 3 07:15:14 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31CF221F9C70; Wed, 3 Jul 2013 07:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 35tJNdfOFg6i; Wed, 3 Jul 2013 07:15:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BC54721F9C33; Wed, 3 Jul 2013 07:15:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Stewart Bryant" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130703141513.9256.44126.idtracker@ietfa.amsl.com> Date: Wed, 03 Jul 2013 07:15:13 -0700 Cc: draft-ietf-appsawg-rfc5451bis@tools.ietf.org, appsawg-chairs@tools.ietf.org, sm+ietf@elandsys.com, apps-discuss@ietf.org Subject: [apps-discuss] Stewart Bryant's Discuss on draft-ietf-appsawg-rfc5451bis-09: (with DISCUSS) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2013 14:15:14 -0000 Stewart Bryant has entered the following ballot position for draft-ietf-appsawg-rfc5451bis-09: 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. ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This discuss is initially for my colleagues on the IESG. This update to RFC5451 introduces text containing what are almost certainly the trade marked names of a number of products. This does not seem to be called out in the text, which may be a problem for the trade mark owners. My question (to the IESG) is whether this is something that we need to worry about, or something that we just leave for the RFC Editor to deal with. From presnick@qti.qualcomm.com Wed Jul 3 08:07:44 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36E0111E81AA; Wed, 3 Jul 2013 08:07:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.199 X-Spam-Level: X-Spam-Status: No, score=-106.199 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9NQ8JOeiO2Mx; Wed, 3 Jul 2013 08:07:30 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 0849111E817E; Wed, 3 Jul 2013 08:07: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=1372864049; x=1404400049; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=jcrEh7lHtHE4pCFN0GkusU3JD0jLV2N3a8j/5Rt/2pE=; b=UWM8dw+i/xmNi/0dJYUx7VVYjWZLk69DLcfQWEaX8Dov977NenFLJliJ 3Y/8jA8dlViV+O3cavn0sCrmutVBo+PySisCTlL1qiadsEZAIDayClcrQ cNl6kFbGyFnVJ8ini1dKDia6b5P/VTYl5Uv9TIOjzHpmomGNzdVyn4W3R A=; X-IronPort-AV: E=Sophos;i="4.87,988,1363158000"; d="scan'208";a="60582490" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine02.qualcomm.com with ESMTP; 03 Jul 2013 08:07:29 -0700 X-IronPort-AV: E=Sophos;i="4.87,988,1363158000"; d="scan'208";a="509117857" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 03 Jul 2013 08:07:29 -0700 Received: from presnick-mac.local (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 3 Jul 2013 08:07:28 -0700 Message-ID: <51D43E2F.6040701@qti.qualcomm.com> Date: Wed, 3 Jul 2013 10:07:27 -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: Stewart Bryant References: <20130703141513.9256.44126.idtracker@ietfa.amsl.com> In-Reply-To: <20130703141513.9256.44126.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Cc: draft-ietf-appsawg-rfc5451bis@tools.ietf.org, appsawg-chairs@tools.ietf.org, The IESG , apps-discuss@ietf.org, sm+ietf@elandsys.com Subject: Re: [apps-discuss] Stewart Bryant's Discuss on draft-ietf-appsawg-rfc5451bis-09: (with DISCUSS) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2013 15:07:44 -0000 On 7/3/13 9:15 AM, Stewart Bryant wrote: > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > This discuss is initially for my colleagues on the IESG. > > This update to RFC5451 introduces text containing what are almost > certainly the trade marked names of a number of products. This does not > seem to be called out in the text, which may be a problem for the trade > mark owners. > > My question (to the IESG) is whether this is something that we need to > worry about, or something that we just leave for the RFC Editor to deal > with. > So, two comments on this: 1. Why do you think that the mention of a trademark in a document is something we should at all be concerned about? Referring to a product by using its trademark name is perfectly reasonable. What problem do you have in mind? 2. Are you referring to the products mentioned in section 7? Section 7 has a note at the top that says, "[RFC Editor: Please delete this section prior to publication.]" If those are the trademarks you are concerned about, the point is moot since they won't appear in the document. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From stbryant@cisco.com Wed Jul 3 08:37:22 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A29A411E81B5; Wed, 3 Jul 2013 08:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.499 X-Spam-Level: X-Spam-Status: No, score=-110.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EvDWTXpKJ6xH; Wed, 3 Jul 2013 08:37:17 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 1962611E81EB; Wed, 3 Jul 2013 08:37:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1670; q=dns/txt; s=iport; t=1372865835; x=1374075435; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=6gAqm3p1oryfQzUUIuUG2VK7CvUo0byQ/8mK5xs2qUg=; b=a+vBgyf2MzVBPtHNy1gmwEWdIf2nQ+vPZ8PxZnqxY/hIv6dNkpwRO30M 5oy323q1obBHK84iyEFOEGwDTpzGSDdI+MPcPMkzE1+fYVTjqa34ROsQT fAzBYdmZtBsDCwk5OF4eQsskFAv0LKvkDItCBWhc5hKhsdaiULnGYvGeB U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEFAHtE1FGQ/khR/2dsb2JhbABagwm+PYJwgQMWdIIjAQEBBDhAARALDgoJFg8JAwIBAgFFBg0BBwEBiAu7F49rB4NtA5dJkUWBWIE6 X-IronPort-AV: E=Sophos;i="4.87,988,1363132800"; d="scan'208";a="156127948" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 03 Jul 2013 15:37:13 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r63FbAJI029971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Jul 2013 15:37:11 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r63FbAYD017852; Wed, 3 Jul 2013 16:37:10 +0100 (BST) Message-ID: <51D44526.6070409@cisco.com> Date: Wed, 03 Jul 2013 16:37:10 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Pete Resnick References: <20130703141513.9256.44126.idtracker@ietfa.amsl.com> <51D43E2F.6040701@qti.qualcomm.com> In-Reply-To: <51D43E2F.6040701@qti.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-appsawg-rfc5451bis@tools.ietf.org, appsawg-chairs@tools.ietf.org, The IESG , apps-discuss@ietf.org, sm+ietf@elandsys.com Subject: Re: [apps-discuss] Stewart Bryant's Discuss on draft-ietf-appsawg-rfc5451bis-09: (with DISCUSS) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 15:37:22 -0000 On 03/07/2013 16:07, Pete Resnick wrote: > On 7/3/13 9:15 AM, Stewart Bryant wrote: >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> This discuss is initially for my colleagues on the IESG. >> >> This update to RFC5451 introduces text containing what are almost >> certainly the trade marked names of a number of products. This does not >> seem to be called out in the text, which may be a problem for the trade >> mark owners. >> >> My question (to the IESG) is whether this is something that we need to >> worry about, or something that we just leave for the RFC Editor to deal >> with. > > So, two comments on this: > > 1. Why do you think that the mention of a trademark in a document is > something we should at all be concerned about? Referring to a product > by using its trademark name is perfectly reasonable. What problem do > you have in mind? > > 2. Are you referring to the products mentioned in section 7? Section 7 > has a note at the top that says, "[RFC Editor: Please delete this > section prior to publication.]" If those are the trademarks you are > concerned about, the point is moot since they won't appear in the > document. > > pr > I missed the note to delete - clearing now. The reason that trademarks concern me is that there is a legal requirement that a company protect or loose the right to a trademark - which is why you see Foo(tm) footnote: Foo(tm) is a trademark of Foo Ltd in printed text. Seems if that is not done Foo becomes generic and no longer exclusive. S From stbryant@cisco.com Wed Jul 3 08:38:07 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE49E11E81EA; Wed, 3 Jul 2013 08:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O60K-zsiA-52; Wed, 3 Jul 2013 08:38:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 391FD11E81EC; Wed, 3 Jul 2013 08:38:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Stewart Bryant" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130703153807.26656.6882.idtracker@ietfa.amsl.com> Date: Wed, 03 Jul 2013 08:38:07 -0700 Cc: draft-ietf-appsawg-rfc5451bis@tools.ietf.org, appsawg-chairs@tools.ietf.org, sm+ietf@elandsys.com, apps-discuss@ietf.org Subject: [apps-discuss] Stewart Bryant's No Objection on draft-ietf-appsawg-rfc5451bis-09: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2013 15:38:07 -0000 Stewart Bryant has entered the following ballot position for draft-ietf-appsawg-rfc5451bis-09: 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. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I missed the note that section 7 is to be deleted. From johnl@iecc.com Wed Jul 3 08:56:21 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1061611E81D2 for ; Wed, 3 Jul 2013 08:56:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.697 X-Spam-Level: X-Spam-Status: No, score=-110.697 tagged_above=-999 required=5 tests=[AWL=0.502, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sMEquwBgr6Ch for ; Wed, 3 Jul 2013 08:56:15 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id A57AF11E81CB for ; Wed, 3 Jul 2013 08:56:12 -0700 (PDT) Received: (qmail 89279 invoked from network); 3 Jul 2013 15:56:09 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 3 Jul 2013 15:56:09 -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=51d44999.xn--9vv.k1307; i=johnl@user.iecc.com; bh=Lehd4pl4y+MA/ei5bH+ajPlUv1m4pG5uW6u25f3EyzE=; b=R9HbssqZXDovW4C0GSuO7AfRJtPeVMbu8uaTYnX97ozbskFvQpYCxSAUO9Yq4aLZFj/0MYxkIe4eWiKdcsQycsFTHpyuwoAimYvE9WzBzve+88Yw6tZvp2Ac6Upy4NBeP+yHd3TkzXJedU2YqsZphnOMOHmB9fAQOQXS7AOhrvIgW04y2p/EjrHlFYGQhFv49PiOW7x2LwJneELZX5S6xundh1zX95z1TKZzpoTV2epdAl3Lqo88QxFy2mUOxs91 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=51d44999.xn--9vv.k1307; olt=johnl@user.iecc.com; bh=Lehd4pl4y+MA/ei5bH+ajPlUv1m4pG5uW6u25f3EyzE=; b=mgU8qqP0ORmFJgRa8o4dJYr2RVairRXZwZQfTD87ksodXO5a4T5g7IAIkNCmiWB7dG5VTao7MJpd/IuHSTjDmi946TQQWIepR+hvCOJk5jJksdb0rO3oi8neHmdQalRhzgzRj9tvO0wVFgTIjQx23Q991OmVzZ6JvQFHXN+rL/6dBxmj3v3+blilvbEICWfQ2QcnzBaHFRYSuwmetywycY8sOiZWa7IF0mhPw6eIXLWPPLdxA44V64uoVPJUdYZj Date: 3 Jul 2013 15:55:47 -0000 Message-ID: <20130703155547.33166.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <20130703141513.9256.44126.idtracker@ietfa.amsl.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Cc: stbryant@cisco.com Subject: Re: [apps-discuss] Stewart Bryant's Discuss on draft-ietf-appsawg-rfc5451bis-09: (with DISCUSS) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jul 2013 15:56:21 -0000 >This update to RFC5451 introduces text containing what are almost >certainly the trade marked names of a number of products. This does not >seem to be called out in the text, which may be a problem for the trade >mark owners. > >My question (to the IESG) is whether this is something that we need to >worry about, or something that we just leave for the RFC Editor to deal >with. The IETF is under no duty to acknowledge or otherwise defend trademarks of third parties (despite the legend about the Unix trademark.) This sounds like a question that would better be directed to Jorge. R's, John From Peter.Rushforth@NRCan-RNCan.gc.ca Wed Jul 3 09:51:04 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9C2711E80F2 for ; Wed, 3 Jul 2013 09:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_32=0.6, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P03xkK6hq0mk for ; Wed, 3 Jul 2013 09:50:59 -0700 (PDT) Received: from nrcan.gc.ca (s-bsc-edge1.nrcan.gc.ca [132.156.238.13]) by ietfa.amsl.com (Postfix) with ESMTP id 55D0D21F9D7E for ; Wed, 3 Jul 2013 09:50:57 -0700 (PDT) Received: from S-BSC-CAS2.nrn.nrcan.gc.ca (132.156.238.12) by S-BSC-EDGE1.nrcan.gc.ca (132.156.238.13) with Microsoft SMTP Server (TLS) id 14.2.342.3; Wed, 3 Jul 2013 12:50:56 -0400 Received: from S-BSC-MBX1.nrn.nrcan.gc.ca ([169.254.1.214]) by S-BSC-CAS2.nrn.nrcan.gc.ca ([fe80::48d4:f168:78ba:d4e8%19]) with mapi id 14.02.0342.003; Wed, 3 Jul 2013 12:50:56 -0400 From: "Rushforth, Peter" To: "Henry S. Thompson" Thread-Topic: [apps-discuss] I-D Action: draft-ietf-appsawg-xml-mediatypes-01.txt Thread-Index: AQHOdzLhXfxlcOsZp0uP/PuaiyNSFplTLDOg Date: Wed, 3 Jul 2013 16:50:54 +0000 Message-ID: <1CD55F04538DEA4F85F3ADF7745464AF24A11FB1@S-BSC-MBX1.nrn.nrcan.gc.ca> References: <20130528150820.16413.98334.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [132.156.238.22] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-xml-mediatypes-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 16:51:04 -0000 Should the spec discuss xml:id and xml:space? I apologize if this is too late. Peter > -----Original Message----- > From: apps-discuss-bounces@ietf.org=20 > [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Henry S. Thompson > Sent: July 2, 2013 10:45 > To: apps-discuss@ietf.org > Subject: Re: [apps-discuss] I-D Action:=20 > draft-ietf-appsawg-xml-mediatypes-01.txt >=20 > This draft has been out for a month, with only one minor=20 > comment appearing. I'd like to do one more draft and try to=20 > close this out, so please, it would be great to get any=20 > further comments this week, so I can have a final draft in=20 > place for discussion in Berlin, if anyone wants to do that (I=20 > can't make it :-(. >=20 > ht > --=20 > Henry S. Thompson, School of Informatics, University=20 > of Edinburgh > 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44)=20 > 131 650-4440 > Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk > URL: http://www.ltg.ed.ac.uk/~ht/ =20 > [mail from me _always_ has a .sig like this -- mail without=20 > it is forged spam] _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > = From ht@inf.ed.ac.uk Wed Jul 3 10:02:35 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B041511E820B for ; Wed, 3 Jul 2013 10:02:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g9zAY0Xj0SmT for ; Wed, 3 Jul 2013 10:02:30 -0700 (PDT) Received: from nougat.ucs.ed.ac.uk (nougat.ucs.ed.ac.uk [129.215.13.205]) by ietfa.amsl.com (Postfix) with ESMTP id 8300311E80F2 for ; Wed, 3 Jul 2013 10:02:29 -0700 (PDT) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by nougat.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id r63H2H6W006515; Wed, 3 Jul 2013 18:02:17 +0100 (BST) Received: from calexico.inf.ed.ac.uk (calexico.inf.ed.ac.uk [129.215.24.15]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id r63H2GIa031693; Wed, 3 Jul 2013 18:02:16 +0100 Received: from calexico.inf.ed.ac.uk (localhost [127.0.0.1]) by calexico.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id r63H2I66014447; Wed, 3 Jul 2013 18:02:18 +0100 Received: (from ht@localhost) by calexico.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id r63H2Fij014443; Wed, 3 Jul 2013 18:02:15 +0100 X-Authentication-Warning: calexico.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: "Rushforth\, Peter" References: <20130528150820.16413.98334.idtracker@ietfa.amsl.com> <1CD55F04538DEA4F85F3ADF7745464AF24A11FB1@S-BSC-MBX1.nrn.nrcan.gc.ca> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Wed, 03 Jul 2013 18:02:15 +0100 In-Reply-To: <1CD55F04538DEA4F85F3ADF7745464AF24A11FB1@S-BSC-MBX1.nrn.nrcan.gc.ca> (Peter Rushforth's message of "Wed\, 3 Jul 2013 16\:50\:54 +0000") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at nougat.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.13.205 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-xml-mediatypes-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 17:02:35 -0000 Rushforth, Peter writes: > Should the spec discuss xml:id and xml:space? I apologize if this is > too late. I don't _think_ so. There is nothing about markup in the spec., and that seems right. ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From Peter.Rushforth@NRCan-RNCan.gc.ca Wed Jul 3 10:15:38 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7FB21F9D95 for ; Wed, 3 Jul 2013 10:15:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_32=0.6, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qh2knW4eyQD8 for ; Wed, 3 Jul 2013 10:15:26 -0700 (PDT) Received: from nrcan.gc.ca (s-bsc-edge1.nrcan.gc.ca [132.156.238.13]) by ietfa.amsl.com (Postfix) with ESMTP id 89CA621F9CFE for ; Wed, 3 Jul 2013 10:15:26 -0700 (PDT) Received: from S-BSC-CAS2.nrn.nrcan.gc.ca (132.156.238.12) by S-BSC-EDGE1.nrcan.gc.ca (132.156.238.13) with Microsoft SMTP Server (TLS) id 14.2.342.3; Wed, 3 Jul 2013 13:15:23 -0400 Received: from S-BSC-MBX1.nrn.nrcan.gc.ca ([169.254.1.214]) by S-BSC-CAS2.nrn.nrcan.gc.ca ([fe80::48d4:f168:78ba:d4e8%19]) with mapi id 14.02.0342.003; Wed, 3 Jul 2013 13:15:23 -0400 From: "Rushforth, Peter" To: "Henry S. Thompson" Thread-Topic: [apps-discuss] I-D Action: draft-ietf-appsawg-xml-mediatypes-01.txt Thread-Index: AQHOeA8lC/N5pTpIa0i29c+YbhlkqplTMM1w Date: Wed, 3 Jul 2013 17:15:22 +0000 Message-ID: <1CD55F04538DEA4F85F3ADF7745464AF24A12000@S-BSC-MBX1.nrn.nrcan.gc.ca> References: <20130528150820.16413.98334.idtracker@ietfa.amsl.com> <1CD55F04538DEA4F85F3ADF7745464AF24A11FB1@S-BSC-MBX1.nrn.nrcan.gc.ca> In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [132.156.238.22] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-xml-mediatypes-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 17:15:38 -0000 >=20 > I don't _think_ so. There is nothing about markup in the=20 > spec., and that seems right. >=20 I guess everything about markup is included by reference to the relevant specs; there's no sense duplicating everything there in the media type spec= . =20 There is a section on xml:base, which made me think about the related specs. Most of them are discussed in the XML spec, except xml:= id, which I suppose is not an issue. Thanks Peter= From mnot@mnot.net Wed Jul 3 18:30:30 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEC5A11E80A2 for ; Wed, 3 Jul 2013 18:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.969 X-Spam-Level: X-Spam-Status: No, score=-104.969 tagged_above=-999 required=5 tests=[AWL=-2.370, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bnaq1VbSjOAY for ; Wed, 3 Jul 2013 18:30:25 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8FE21F9C31 for ; Wed, 3 Jul 2013 18:30:25 -0700 (PDT) Received: from [192.168.1.80] (unknown [118.209.244.150]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 6720F22E253; Wed, 3 Jul 2013 21:30:17 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Mark Nottingham In-Reply-To: <51CB8646.60101@berkeley.edu> Date: Thu, 4 Jul 2013 11:30:14 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <873F3899-2365-4F13-A485-8924E67294FA@mnot.net> References: <20130610033804.19451.29465.idtracker@ietfa.amsl.com> <51B7AEAF.20404@berkeley.edu> <4CD4652F-4EAF-4258-A6EB-577019018D2C@mnot.net> <1A136C4D-4F0C-446F-B307-D53FB9A40622@cs.tcd.ie> <8BE038EC-1580-4D27-ABBA-1890EEFD4853@mnot.net> <51C9C91D.90206@berkeley.edu> <4C2FD8A7-4F3E-433B-A7F6-F0BD751D31AD@mnot.net> <51CB240C.3060101@berkeley.edu> <51CB8646.60101@berkeley.edu> To: Erik Wilde X-Mailer: Apple Mail (2.1508) Cc: IETF Apps Discuss , REST-Discuss Discuss Subject: Re: [apps-discuss] New Version Notification for draft-nottingham-link-hint-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 01:30:30 -0000 On 27/06/2013, at 10:24 AM, Erik Wilde wrote: >>>=20 >>> so my suggestion is not so much your (b) but my (c) ;-) fwiw, it = seems that thew current draft uses overly complicated structures, for = example, "formats" maybe just could be an array of formats? >> Could you spell out an example? >=20 > afaict, "formats" = (http://tools.ietf.org/html/draft-nottingham-link-hint-00#section-3.2) = right now says says it's an object with the keys being media types, but = the values are not specified. but maybe i am reading it wrong and where = it says "The object" in the second and third paragraph it actually = refers to the object that's a value of one of the keys? Yes, I need to spell that out more completely. Thanks. > hmmm, i guess that's what it means... i had been reading it wrong so = far. but for a minute, let's just assume it's only media types, which is = how i am using it in an example using link hints here: = https://github.com/dret/I-D/blob/master/link-desc/ld-atompub-00.xml >=20 > so let's assume for a minute that this is just a list. then i would = suggest is the following: the hint is defined as follows (stealing your = structure here): >=20 > o Hint Name: formats > o Description: Hints the representation type(s) that the target = resource can produce and consume, using the GET and PUT (if allowed) = methods respectively. > o Content Model: list > o Specification: [this document] > Content MUST be a list, whose values are media types. >=20 > then, the term "list" in the content model must be defined somewhere. = like i said, maybe we could say there are three "content models" hints = support: single values, lists, key/value pairs. how a particular hint = value would be serialized then would be up to the format where it's = being represented. >=20 > - in JSON, you might represent them as string, array, something else. >=20 > - in XML, you might choose a mix of element/attribute designs. or you = could go text-based such as my example (which is text-based because it = uses JSON syntax right now) >=20 > none of these representations would be binding, they would just be one = way of mapping the abstract link hint model into some concrete model. i = guess the only exception for this would be how to represent links = outside of media types, i.e. in HTTP. = http://tools.ietf.org/html/draft-nottingham-link-hint-00#appendix-A = could be changed then to map the abstract moden into a concrete JSON = syntax (or whatever else looks like a good syntax choice to go into a = Link header). I'm all for that, IF we can be reasonably sure that the current data can = fit comfortably into that simplified model. The current hints that use "complex" objects are (keeping in mind that = we've just started): - formats - links - accept-post (same format as formats) - auth-schemes Formats and accept-post COULD specify a list of strings, and state that = it's either a media type OR a profile URI. This means we'd need a = separate representation format for profiles, which would need to convey = a media type. This is certainly possible, but the downsides I see are: - It's baking in profiles in at a pretty high level. I like some = aspects of profiles, but they certainly haven't taken off in mindshare = yet. - Parsing the string to check which it is is nasty. For auth-schemes, we'd need to specify a tuple, probably. Not great, but = OK. Extensibility would be right out the window, though, which may be = significant for some schemes. Links are fundamentally not possible without some really ugly mapping to = a string, I think. My concern is that this is starting not to meet my use cases for = json-home, which is where link-hints comes from.=20 While I could address this by making those things NOT link hints, but = other "bumps" on json-home, it would make it significantly more complex. = That seems like a poor tradeoff, considering that it's *possible* to map = generic hints into XML, it's just not "pretty." > as i see it, when i design media types that use link hints, it would = be nice if i could expose them in a way that is as useful as possible = for consumers of that media type. my example from above is from an XML = design for link descriptions that i plan to base on link hints. if that = means that the XML-oriented clients using this format need to include a = general-purpose JSON parser, then that's certainly doable, but i don't = think the link hints design has to be like that. To be brutally frank (and I'm sure this isn't going to surprise you too = much, dret ;) I don't see a lot of value in catering to the XML API = market; it's dying, and introducing constraints on the JSON APIs seems = like a bad tradeoff. I absolutely acknowledge that JSON will one day face its own demise, and = will be in a similar situation, but planning for that seems like = premature optimisation to me. > but again, of course my option (c) means that link hints have a = predefined and probably small set of structures that hints can use to = expose whatever they want to expose, and if they want to go beyond that, = that's not covered by the link hint framework anymore. Yes. That's what I'm struggling with. We're already seeing a number of = places that chafe against these constraints, and we're just getting = started. What do other folks think? Cheers, -- Mark Nottingham http://www.mnot.net/ From internet-drafts@ietf.org Wed Jul 3 21:18:38 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3D1E21F9B5D; Wed, 3 Jul 2013 21:18:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.497 X-Spam-Level: X-Spam-Status: No, score=-102.497 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BvmxU2-jXBDH; Wed, 3 Jul 2013 21:18:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E17AC21F885A; Wed, 3 Jul 2013 21:18:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130704041837.2798.55018.idtracker@ietfa.amsl.com> Date: Wed, 03 Jul 2013 21:18:37 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-15.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 04:18:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Working G= roup of the IETF. Title : WebFinger Author(s) : Paul E. Jones Gonzalo Salgueiro Joseph Smarr Filename : draft-ietf-appsawg-webfinger-15.txt Pages : 21 Date : 2013-07-03 Abstract: This specification defines the WebFinger protocol, which can be used to discover information about people or other entities on the Internet using standard HTTP methods. WebFinger discovers information for a URI that might not be usable as a locator otherwise, such as account or email URIs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-15 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-webfinger-15 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mnot@mnot.net Wed Jul 3 22:35:09 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD7421F9E47 for ; Wed, 3 Jul 2013 22:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.764 X-Spam-Level: X-Spam-Status: No, score=-104.764 tagged_above=-999 required=5 tests=[AWL=-2.165, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rCWls2u8PqDF for ; Wed, 3 Jul 2013 22:35:05 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 27AB121F9E45 for ; Wed, 3 Jul 2013 22:35:05 -0700 (PDT) Received: from [192.168.1.80] (unknown [118.209.244.150]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 2B72822E1F3; Thu, 4 Jul 2013 01:34:57 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Mark Nottingham In-Reply-To: Date: Thu, 4 Jul 2013 15:34:54 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <6BC44D72-BAA1-41B6-BFE8-9FD7A9D4CECF@mnot.net> References: To: Michiel de Jong X-Mailer: Apple Mail (2.1508) Cc: Apps Discuss Subject: Re: [apps-discuss] Non-proprietary sync (was Re: Is e-mail going to die? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jul 2013 05:35:09 -0000 Hi Michiel, I'm very interested in this area; I think we need open standards here = desperately. I potentially have a lot of feedback for you (both editorial and more = substantial), but wanted to first know: what is the remoteStorage = community's intent in publishing this draft?=20 I.e., do you think you're nearly done, and just need to publish a = specification? Are you willing to consider substantial changes to the = specification, even if it breaks your current implementations if there's = good reason? Also, what kind of timeline are you on -- i.e., do you have particular = milestones you want to hit? Finally, what's the preferred venue for feedback and discussion? Will = you or anyone else from remoteStorage be coming to the Berlin meeting? Cheers, On 17/06/2013, at 9:02 PM, Michiel de Jong wrote: > On 2013-06-17 10:09, Dave Raggett wrote: > > Non-proprietary sync is the next step >=20 > That is exactly what "remote storage" tries to propose: a = non-proprietary protocol that does something like = Dropbox/GoogleDrive/SkyDrive over cross-origin HTTP. >=20 > We uploaded the -01 version of the I-D last week: >=20 > http://www.ietf.org/id/draft-dejong-remotestorage-01.txt > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham http://www.mnot.net/ From markus.lanthaler@gmx.net Fri Jul 5 07:56:06 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1304E21F9C98; Fri, 5 Jul 2013 07:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OV90dEUnQPhn; Fri, 5 Jul 2013 07:56:01 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB0821F9C56; Fri, 5 Jul 2013 07:56:00 -0700 (PDT) Received: from Vostro3500 ([178.115.248.216]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MD9uq-1V0ces1Maq-00GVVj; Fri, 05 Jul 2013 16:55:48 +0200 From: "Markus Lanthaler" To: "'Cyrus Daboo'" References: In-Reply-To: Date: Fri, 5 Jul 2013 16:55:34 +0200 Message-ID: <012901ce798f$b9c87750$2d5965f0$@lanthaler@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac55imqGwUPLcTdDSJejAS51gZAvWQABI+wg Content-Language: de X-Provags-ID: V03:K0:BEQK/Iz8CC/ypinjUN2+0hdLXoiloLoiszCvTgX8fEBS1U4qWML C1GKLJzRA1Z1s9tcQDpZdWWHLeW93TJRxmvMvrkaT2HyuSyhRz+EWa5mP82f9Jd95+hi4R8 hTljZndJe8L8qfj6RXlvvVYifdEOg3865iujmBu4ZJJkJNZutNPLJGFZXpUnP8hBu0jYR0r mXkJ4ejQ5z8F0ECXJgncw== Cc: webfinger@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] [webfinger] Automated Service Configuration now uses webfinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jul 2013 14:56:06 -0000 CC'ing apps-discuss On Friday, July 05, 2013 4:17 PM, Cyrus Daboo wrote: > Hi folks, > I have recently posted a new version of the Automated Service > Configuration > draft (formerly known as Aggregated Service Discovery): > discovery/>. > > This protocol now makes use of webfinger to "bootstrap" discovery of > the config document. Hopefully it will serve as a useful example of how > webfinger can be used by specific applications. I would appreciate > feedback from the webfinger community on how we have gone about using > webfinger, thanks. Looks good to me. The only thing that bugs me is that the " Automated Service Configuration Document Format" you define doesn't have its own media type. That will make it impossible to reuse in other scenarios and ambiguous how to process the target of a service-configuration link because other people may start using their own JSON flavors. I would suggest to define a media type or at list a profile URI to make this unambiguous. HTH, Markus -- Markus Lanthaler @markuslanthaler From dret@berkeley.edu Fri Jul 5 08:00:38 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1334B21F9E76 for ; Fri, 5 Jul 2013 08:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jbqC58fhKbep for ; Fri, 5 Jul 2013 08:00:28 -0700 (PDT) Received: from cm03fe.IST.Berkeley.EDU (cm03fe.IST.Berkeley.EDU [169.229.218.144]) by ietfa.amsl.com (Postfix) with ESMTP id 41B4821F9DDD for ; Fri, 5 Jul 2013 08:00:28 -0700 (PDT) Received: from 46-126-158-51.dynamic.hispeed.ch ([46.126.158.51] helo=dretpro.local) by cm03fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1Uv7Un-0000VC-CV; Fri, 05 Jul 2013 08:00:27 -0700 Message-ID: <51D6DF85.4060309@berkeley.edu> Date: Fri, 05 Jul 2013 17:00:21 +0200 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Mark Nottingham References: <20130610033804.19451.29465.idtracker@ietfa.amsl.com> <51B7AEAF.20404@berkeley.edu> <4CD4652F-4EAF-4258-A6EB-577019018D2C@mnot.net> <1A136C4D-4F0C-446F-B307-D53FB9A40622@cs.tcd.ie> <8BE038EC-1580-4D27-ABBA-1890EEFD4853@mnot.net> <51C9C91D.90206@berkeley.edu> <4C2FD8A7-4F3E-433B-A7F6-F0BD751D31AD@mnot.net> <51CB240C.3060101@berkeley.edu> <51CB8646.60101@berkeley.edu> <873F3899-2365-4F13-A485-8924E67294FA@mnot.net> In-Reply-To: <873F3899-2365-4F13-A485-8924E67294FA@mnot.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF Apps Discuss , REST-Discuss Discuss Subject: Re: [apps-discuss] New Version Notification for draft-nottingham-link-hint-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 15:00:38 -0000 hello mark. On 2013-07-04 3:30 , Mark Nottingham wrote: >> none of these representations would be binding, they would just be one way of mapping the abstract link hint model into some concrete model. i guess the only exception for this would be how to represent links outside of media types, i.e. in HTTP. http://tools.ietf.org/html/draft-nottingham-link-hint-00#appendix-A could be changed then to map the abstract moden into a concrete JSON syntax (or whatever else looks like a good syntax choice to go into a Link header). > I'm all for that, IF we can be reasonably sure that the current data can fit comfortably into that simplified model. > The current hints that use "complex" objects are (keeping in mind that we've just started): > - formats > - links > - accept-post (same format as formats) > - auth-schemes > Formats and accept-post COULD specify a list of strings, and state that it's either a media type OR a profile URI. This means we'd need a separate representation format for profiles, which would need to convey a media type. > This is certainly possible, but the downsides I see are: > - It's baking in profiles in at a pretty high level. I like some aspects of profiles, but they certainly haven't taken off in mindshare yet. > - Parsing the string to check which it is is nasty. > For auth-schemes, we'd need to specify a tuple, probably. Not great, but OK. Extensibility would be right out the window, though, which may be significant for some schemes. > Links are fundamentally not possible without some really ugly mapping to a string, I think. i guess that's true. but i have to admit that i am struggling a bit with that specific hint anyway. it can hint at links you might find at the target resource. it may contain hints, so it can also contain link hints. so in theory, you could build a multi-level structure of links to be expected several link traversals away, right? more generally speaking, i am having troubles rationalizing hints that give me some "preview" of the target resource. my personal mental model of link hints is that they constrain interactions with the target resource, but really don't tell you what to expect. is http://tools.ietf.org/html/draft-nottingham-json-home-03#section-9 (the separation into "resource" and "representation" hints in the home draft, where the link hint idea started) what might make te difference between hints talking about interactions, and hints talking about the result of an interaction? > My concern is that this is starting not to meet my use cases for json-home, which is where link-hints comes from. that would be bad, but again, i am struggling a bit with the hints that tell you what to expect, and not just what to do. my thoughts were that hints should just be about what to do; do you have a different model in mind? > While I could address this by making those things NOT link hints, but other "bumps" on json-home, it would make it significantly more complex. That seems like a poor tradeoff, considering that it's *possible* to map generic hints into XML, it's just not "pretty." > To be brutally frank (and I'm sure this isn't going to surprise you too much, dret ;) I don't see a lot of value in catering to the XML API market; it's dying, and introducing constraints on the JSON APIs seems like a bad tradeoff. yes, i am not overly surprised ;) but i am not really trying to optimize this for XML, i just try to make it more workable for non-JSON consumers in general. and i am still hoping that somebody will be able to point to prior decisions that were made in similar situations: are there IANA registries that are using JSON as a data model for their entries, and which other approaches were taken in cases where registries attempted to register structured entries? maybe we should just use ASN.1... ;-) > I absolutely acknowledge that JSON will one day face its own demise, and will be in a similar situation, but planning for that seems like premature optimisation to me. sure, and if the consensus is that it's ok to have JSON-based registries, then this is how it is. personally, i think i will then use serialized JSON in XML representations, which are a little less horrible to look at than generic JSON serialized in JSON. >> but again, of course my option (c) means that link hints have a predefined and probably small set of structures that hints can use to expose whatever they want to expose, and if they want to go beyond that, that's not covered by the link hint framework anymore. > Yes. That's what I'm struggling with. We're already seeing a number of places that chafe against these constraints, and we're just getting started. > What do other folks think? good point, so far it's just mark and me. anybody who faced similar design issues who could share their considerations and decisions? thanks and cheers, dret. -- erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | | UC Berkeley - School of Information (ISchool) | | http://dret.net/netdret http://twitter.com/dret | From anything@michielbdejong.com Fri Jul 5 09:50:14 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DAF211E80A2 for ; Fri, 5 Jul 2013 09:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.447 X-Spam-Level: X-Spam-Status: No, score=-3.447 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jEa2jf00MQ7z for ; Fri, 5 Jul 2013 09:50:10 -0700 (PDT) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) by ietfa.amsl.com (Postfix) with ESMTP id 9E6B621F9FD4 for ; Fri, 5 Jul 2013 09:50:09 -0700 (PDT) Received: from mfilter4-d.gandi.net (mfilter4-d.gandi.net [217.70.178.134]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id E2B60172055; Fri, 5 Jul 2013 18:49:57 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter4-d.gandi.net Received: from relay4-d.mail.gandi.net ([217.70.183.196]) by mfilter4-d.gandi.net (mfilter4-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id N6xXPE49wJDb; Fri, 5 Jul 2013 18:49:56 +0200 (CEST) X-Originating-IP: 10.58.1.141 Received: from webmail.gandi.net (unknown [10.58.1.141]) (Authenticated sender: anything@michielbdejong.com) by relay4-d.mail.gandi.net (Postfix) with ESMTPA id 16109172091; Fri, 5 Jul 2013 18:49:55 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 05 Jul 2013 18:49:55 +0200 From: "Michiel B. de Jong" To: In-Reply-To: <6BC44D72-BAA1-41B6-BFE8-9FD7A9D4CECF@mnot.net> References: <6BC44D72-BAA1-41B6-BFE8-9FD7A9D4CECF@mnot.net> Message-ID: <8ee3a48c1d3c44eb5bba7b08b3f77579@michielbdejong.com> X-Sender: anything@michielbdejong.com User-Agent: Roundcube Webmail/0.7.2 Cc: mnot@mnot.net Subject: Re: [apps-discuss] =?utf-8?q?Non-proprietary_sync_=28was_Re=3A_Is_e-m?= =?utf-8?q?ail_going_to_die=3F?= X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jul 2013 16:50:14 -0000 Hi Mark, On 2013-07-04 07:34, Mark Nottingham wrote: > Hi Michiel, > > I'm very interested in this area; I think we need open standards here > desperately. Great! > I potentially have a lot of feedback for you (both editorial and more > substantial), but wanted to first know: what is the remoteStorage > community's intent in publishing this draft? we hadn't really formulated that until now, so we had a little discussion about it; we didn't entirely finish discussing it yet, but overall i think most of us agree that the ietf would probably be the right platform for developing the idea of remoteStorage further. we started working on this spec as an open source project because we identified a need for one - its development so far was partially financed by donations, partially by people donating their time. It's of course scary to give up control over something we care so much about, but we also trust the ietf would do a better job at guarding the public's best interest than our small community of quite inexperienced volunteers. :) > I.e., do you think you're nearly done, and just need to publish a > specification? it's becoming quite crystallized within its very limited defined set of features. you can get an idea of what we consider outstanding issues by browsing https://github.com/remotestorage/spec/issues our current process is to go through that list twice a year, and see which of those issues merit a text change. we are trying to change as little as possible each time, to avoid an entropy walk into feature bloat. :) > Are you willing to consider substantial changes to the > specification, even if it breaks your current implementations if > there's good reason? yes, we do this every 6 months anyway. what type of changes did you have in mind? so far, even though these are themes that continuously come up as requests, we have resisted adding for instance: - byte ranges on GET (and PUT?) requests, - query parameters like sorting/filtering/paging, - access control lists, - long polling and/or other sorts of changes-feeds - retrieving the historic revision history of a certain document (as well as undo/rollback) - atomic transactions - etc. this way, we try to keep the job of the server as simple as possible. > > Also, what kind of timeline are you on -- i.e., do you have > particular milestones you want to hit? we try to go as fast as we can, developing the remotestorage.js client library for it, data formats for the things we want to store on there, try to work out how to structure data into folders so that it's easy to fetch later, write apps that use it, and server implementations that are compliant with it, with (if you add up the volunteers) about 3 full-time people. that's our main constraint. :) we have been trying to make breaking changes only twice a year, although we're probably going to have to disobey that self-imposed rule soon anyway because of a critical bug we found this week. > > Finally, what's the preferred venue for feedback and discussion? currently it's a combination of https://github.com/remotestorage/spec/issues and http://remotestorage.io/community/ but we're open to changing that to the apps-discuss mailinglist for instance? do you think that would be appropriate? > Will > you or anyone else from remoteStorage be coming to the Berlin > meeting? i live in Berlin, and given our project's tight budget, i hadn't bought a ticket yet. but if there is a possibility to chat about remoteStorage with you and/or other people there, then i'll definitely get one for both the meeting and the newcomer event! :) can say roughly in which areas you would propose changing the draft? Cheers, Michiel From franck@peachymango.org Sat Jul 6 15:31:50 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70ED221F9B5C for ; Sat, 6 Jul 2013 15:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mn7FG3cDn+Xz for ; Sat, 6 Jul 2013 15:31:39 -0700 (PDT) Received: from smtp-out-2.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id 4EFCC21F9B38 for ; Sat, 6 Jul 2013 15:31:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 5078E39001A for ; Sat, 6 Jul 2013 17:31:36 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp-out-2.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9aTCvJIkysSh for ; Sat, 6 Jul 2013 17:31:36 -0500 (CDT) Received: from smtp-out-2.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 31D61390052 for ; Sat, 6 Jul 2013 17:31:36 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 1CBDB39002F for ; Sat, 6 Jul 2013 17:31:36 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp-out-2.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id D6H3Q8NJFmCK for ; Sat, 6 Jul 2013 17:31:36 -0500 (CDT) Received: from mail-2.01.com (mail.01.com [172.18.30.178]) by smtp-out-2.01.com (Postfix) with ESMTP id DC1CA39001A for ; Sat, 6 Jul 2013 17:31:35 -0500 (CDT) Date: Sat, 6 Jul 2013 17:31:34 -0500 (CDT) From: Franck Martin To: IETF Apps Discuss Message-ID: <47488958.173803.1373149894362.JavaMail.zimbra@peachymango.org> In-Reply-To: <769743608.173673.1373148450418.JavaMail.zimbra@peachymango.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_173802_993822532.1373149894361" X-Originating-IP: [69.28.149.29] X-Mailer: Zimbra 8.0.4_GA_5737 (ZimbraWebClient - FF21 (Mac)/8.0.4_GA_5737) Thread-Topic: update to rfc5965 Thread-Index: KNZZu0OEF7FH8GJyMoPt+eOyNcSREQ== Subject: [apps-discuss] update to rfc5965 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jul 2013 22:31:50 -0000 ------=_Part_173802_993822532.1373149894361 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit http://tools.ietf.org/html/rfc5965 Specifies the format of Abuse Reporting Format of emails. 2.d indicates the report should contain either the headers of the reported email as a text/rfc822-headers MIME part or the complete message as an message/rfc822. However if the message reported contains spam, virus, bad links, or in general malware, the complete report is likely to be discarded by the receiver anti-spam filters, never reaching abuse desks for processing. It is common amongst security professionals to exchange such dangerous payloads as an encrypted zip file with the common password "infected". This format allows to bypass anti-spam filters as the MTA/MUA is not able to decrypt the attachment to analyze the content. It i difficult to request abuse desk to create a separate email infrastructure for abuse@example.com and especially to disable anti-spam and anti-virus checks. Some of these addresses are part of email hosted in the cloud. I suggest we add the possibility to send the complete email as message/rcf822 email within either an encrypted zip file or within a GPG symmetrically encrypted file, both using the common password "infected". The MIME type should be message/rfc822-zip-crypt for an encrypted zip file message/rfc822-gpg-crypt for the gpg encrypted file gpg and zip are widely used on many systems. I'm gathering comments, and will tentatively write a draft if no major block is received. ------=_Part_173802_993822532.1373149894361 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Specifies= the format of Abuse Reporting Format of emails.

2.d indicates the report should contain either the headers of the report= ed email as a text/rfc822-headers MIME part or the complete message as an m= essage/rfc822. However if the message reported contains spam, virus, bad li= nks, or in general malware, the complete report is likely to be discarded b= y the receiver anti-spam filters, never reaching abuse desks for processing= .

It is common amongst security professionals = to exchange such dangerous payloads as an encrypted zip file with the commo= n password "infected". This format allows to bypass anti-spam filters as th= e MTA/MUA is not able to decrypt the attachment to analyze the content.
=

It i difficult to request abuse desk to create a = separate email infrastructure for abus= e@example.com and especially to disable anti-spam and anti-virus checks= . Some of these addresses are part of email hosted in the cloud.
<= div>
I suggest we add the possibility to send the complete em= ail as message/rcf822 email within either an encrypted zip file or within a= GPG symmetrically encrypted file, both using the common password "infected= ".

The MIME type should be
messa= ge/rfc822-zip-crypt for an encrypted zip file
message/rfc822-= gpg-crypt for the gpg encrypted file

gpg and z= ip are widely used on many systems.

I'm gather= ing comments, and will tentatively write a draft if no major block is recei= ved.




<= /div> ------=_Part_173802_993822532.1373149894361-- From jvasseur@cisco.com Fri Jul 5 00:00:54 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A748421F93E5; Fri, 5 Jul 2013 00:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gk2jg4WHt++8; Fri, 5 Jul 2013 00:00:49 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 070DB11E811D; Fri, 5 Jul 2013 00:00:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3267; q=dns/txt; s=iport; t=1373007649; x=1374217249; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=BjHlmlcoQPa+9bgTDrJ5sHNuOJMif+ibRjQmIx1eES4=; b=NSGwoPNyjcMPEz4Uhs1CwgA9lHYht8pMmRVv7qJAmTwf6o82HWycGx/N iyVYPg8r9Zlit7boPB3uIZ0+/c4tio2KLFUaD8a34BljimWr1572Qg2Pr flYJDzz5YaKz4uC8EpPcgCsEgZBo6nFzINCOdc3ax0QOMm4OT8LmguMCF A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFAMFu1lGtJV2c/2dsb2JhbABagwl7wDB/FnSCIwEBAQMBbAYEAwULAgEIDhQkMiUCBA4NE4duBrhujzgCMQeDBGkDiGugI4MRgig X-IronPort-AV: E=Sophos;i="4.87,1000,1363132800"; d="scan'208";a="231185426" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 05 Jul 2013 07:00:48 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r6570mnO005208 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 5 Jul 2013 07:00:48 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.192]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Fri, 5 Jul 2013 02:00:47 -0500 From: "JP Vasseur (jvasseur)" To: Carsten Bormann Thread-Topic: AppsDir review of draft-ietf-roll-terminology-12.txt Thread-Index: AQHOeU1foqMjtDnPakqZRKa7TCB+UA== Date: Fri, 5 Jul 2013 07:00:47 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A772361B5FE@xmb-rcd-x02.cisco.com> References: <170220D0-A68F-4CAD-9363-549C586772CA@tzi.org> <028a01ce2d2f$79d220d0$6d766270$@olddog.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.114.229] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Sun, 07 Jul 2013 00:26:41 -0700 Cc: "" , "" , IETF Apps Discuss , The IESG Subject: Re: [apps-discuss] AppsDir review of draft-ietf-roll-terminology-12.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 07:00:54 -0000 Hi Carsten, Thanks, I will add a sentence at the beginning ... "The intent of this docu= ment is to provide a high level definition of terms=20 used in various documents produced by Working Groups specifying solutions f= or the Internet of Things." This way the=20 document will stay in the spirit of the objectives of that draft in ROLL. Does that address your concern ? Thanks. JP. On Mar 30, 2013, at 2:33 PM, Carsten Bormann wrote: > Hi Adrian, >=20 > thanks for trying to read my somewhat terse statements, and I apologize f= or making them as easy to misunderstand as I did. >=20 > I didn't pay attention to the discussion that led up to this document. > I was trying to read it from scratch as a document that somebody from a d= ifferent area would use to gain access to the terminology used in the ROLL = work. >=20 > With my critique, I was less interested in the stylistic issues but in th= e definitional intent. >=20 > I think we can all agree that terms like "flash memory" or "field device"= are useful in the vocabulary of someone trying understand ROLL documents. > There is no need to "define" these terms, as they already work in their i= ndustry-standard usage. > So that would be the glossary aspect of the document: gathering informati= on about these terms that is focused on the ROLL context. E.g., highlighti= ng the potential constrainedness of field devices makes this glossary entry= more immediately useful than a Wikipedia entry (which strangely doesn't ex= ist) would be. >=20 > Re the coverage: I used U-LLN as an example of a potentially missing ter= m because draft-tripathi-roll-reactive-applicability-00.txt uses it as if t= he reader were expected to know it. > Fortunately, its first use there is close to a reference to 5548, so the = definition was easy to find. > But. more generally speaking, if the intent is to list terms that are *no= t* defined in the RFCs, that would also be a useful way of scoping. >=20 > I was expecting more definitional intent on the terms that have been inve= nted or appropriated for and by ROLL. =20 > But maybe that is a misunderstanding on my part of what this document is = about (the WG charter did not help me in identifying its objective, and the= introduction reads like there is defining intent). >=20 >=20 > So, in summary, if the WG intends this to be a loose collection of a numb= er of background terms with a glossary-like intent, there is indeed only a = bit more editorial work remaining, starting with clarifying that objective.= Maybe the alphabetic arrangement should have alerted me that this might r= eally be the objective. >=20 > But then, coming from an applications area point of view, I'm still looki= ng forward to a future ROLL terminology document. Is "MP2P" a traffic patt= ern while "P2MP" isn't? What is the relationship between RFC 4461 "P2MP LS= P"s and what is called "P2MP" in RFC 6550? What is the relationship betwee= n RFC 1112's "multicast" and what is called "multicast" in draft-ietf-roll-= trickle-mcast-04.txt, which just completed WGLC? What is the relationship = between RFC 1122's "host"s and RFC 6550's "host"s? What *is* an LLN? >=20 > Gr=FC=DFe, Carsten >=20 From superuser@gmail.com Sun Jul 7 00:42:30 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7844F21F9E5C for ; Sun, 7 Jul 2013 00:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ehIrH5XKC3ku for ; Sun, 7 Jul 2013 00:42:29 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id A01CF21F9E58 for ; Sun, 7 Jul 2013 00:42:29 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id q56so2932048wes.3 for ; Sun, 07 Jul 2013 00:42:27 -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=c420x2KNjf46yLByv6dQ8JNRJIylvITZgEr7Sfr37qE=; b=gTDUa+6WCNA4wEVJxzHO6Usrif0k6VMKrH6EnBdXAf+C2WygVrIS+T+rask8goX1m2 9Mc0sHl6EpDM4wcOYG+AX4NQTaeBm1nttSeWacD9s5iCOhftas6r/RahXEONUOH4zWhN 4R9+aGJoDXkxS+6Ek72wj7jjlM4aOJMh6ZYuYWtClzNncxAboF2d3Nzw6q03ltQE277+ Y2VGgh5skVxyvIHqbgyOFW/voVq3+2aEV467nQmKZfLdOfHfzlfgZ2a5SUrT2rf5YYCB +lcAoZ8Xo5lmRIlWJgN72hw9zx1J0TuwaO3UVG8JFMUzaVTi3ugLpE98QalJT+QFgkWL mlBQ== MIME-Version: 1.0 X-Received: by 10.180.89.231 with SMTP id br7mr27048021wib.19.1373182947365; Sun, 07 Jul 2013 00:42:27 -0700 (PDT) Received: by 10.180.90.16 with HTTP; Sun, 7 Jul 2013 00:42:27 -0700 (PDT) In-Reply-To: <47488958.173803.1373149894362.JavaMail.zimbra@peachymango.org> References: <769743608.173673.1373148450418.JavaMail.zimbra@peachymango.org> <47488958.173803.1373149894362.JavaMail.zimbra@peachymango.org> Date: Sun, 7 Jul 2013 00:42:27 -0700 Message-ID: From: "Murray S. Kucherawy" To: Franck Martin Content-Type: multipart/alternative; boundary=e89a8f3ba255ca1af304e0e711d0 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] update to rfc5965 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jul 2013 07:42:30 -0000 --e89a8f3ba255ca1af304e0e711d0 Content-Type: text/plain; charset=ISO-8859-1 Briefly: On Sat, Jul 6, 2013 at 3:31 PM, Franck Martin wrote: > I suggest we add the possibility to send the complete email as > message/rcf822 email within either an encrypted zip file or within a GPG > symmetrically encrypted file, both using the common password "infected". > > The MIME type should be > message/rfc822-zip-crypt for an encrypted zip file > message/rfc822-gpg-crypt for the gpg encrypted file > > gpg and zip are widely used on many systems. > > I'm gathering comments, and will tentatively write a draft if no major > block is received. > > Has anyone implemented this? It strikes me that putting a specific password in a standards document is unlikely to fly. It might be better to include a new media type parameter to indicate the password used to create the encrypted form. You'd also need to register the media types in your proposal. You might check with the media type reviewer for advice. I think the new hotness would be to use "+" where you have "-". You might also be able to reuse existing stuff like what's in RFC3156. -MSK --e89a8f3ba255ca1af304e0e711d0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Briefly:

On Sat, Jul 6, 2013 at 3:31 PM, Franck Martin <franck@pea= chymango.org> wrote:
I suggest we add the possibility to send the = complete email as message/rcf822 email within either an encrypted zip file = or within a GPG symmetrically encrypted file, both using the common passwor= d "infected".

The MIME type should be
message/rfc822-zi= p-crypt for an encrypted zip file
message/rfc822-gpg-crypt fo= r the gpg encrypted file

gpg and zip are widel= y used on many systems.

I'm gathering comments, and will tentatively = write a draft if no major block is received.

=

Has anyone implemented this?

It strikes me that putting a specific password in a standard= s document is unlikely to fly.=A0 It might be better to include a new media= type parameter to indicate the password used to create the encrypted form.=

You'd also need to register the media types in your prop= osal.=A0 You might check with the media type reviewer for advice.=A0 I thin= k the new hotness would be to use "+" where you have "-"= ;.

You might also be able to reuse existing stuff like what's in RFC31= 56.

-MSK


--e89a8f3ba255ca1af304e0e711d0-- From dave@cridland.net Sun Jul 7 08:31:59 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30B9221F9F63 for ; Sun, 7 Jul 2013 08:31:59 -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=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hpuS1gQT5Vwy for ; Sun, 7 Jul 2013 08:31:57 -0700 (PDT) Received: from mail-qe0-x231.google.com (mail-qe0-x231.google.com [IPv6:2607:f8b0:400d:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 6507321F9F59 for ; Sun, 7 Jul 2013 08:31:56 -0700 (PDT) Received: by mail-qe0-f49.google.com with SMTP id cz11so1869295qeb.8 for ; Sun, 07 Jul 2013 08:31:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=content-type:mime-version:in-reply-to:references:subject:x-mailer :date:message-id:from:to:cc; bh=4uiPjFGpD+ZY2sfYrlyI1AudZQVxLdkgRkNe0uRKiWU=; b=AWTZ7Yggw8Xaw/a5sckzIhqSpu+/5ejD9NtQE3LW+FAR9Lg0OSWHRbUwyXE4BHpSj4 aO+XSgSTkg8k80B4o+ZFlkBE1UiSKInGoFhybjXg6JeshhWX1Wb+RWkRPEGLorCTtmhv lMkbhw2W2eZAM//TjPLy8bnxDK8vzSdlsgNZE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:in-reply-to:references:subject:x-mailer :date:message-id:from:to:cc:x-gm-message-state; bh=4uiPjFGpD+ZY2sfYrlyI1AudZQVxLdkgRkNe0uRKiWU=; b=Vg7xSdgfbZS3swcw89jOhG1DbsTTDSuCyh5AV55R+z+xGUSSKKYRKvQ6cS4x63sbGK it08NzGYJTE5StysuGDksloz1FcQtBUX/byXLMZuOJoIdts8XpeSuZUyDbG+kWFAoffo MwvOmZLZ8UKJgYYZIdSmhGDSlA/78slIOmJrgaMP2BdkEGyTTd6mNWiPM3TnpUY0+/PO az2iRfSnZNXCrAvYqKNBVTsldiB8LaT1xQZXwtPCj90QUWkWTvTAXXp/wX5VzC7IGCE9 QMYwVDe1Lo2r5DKyiGym5K0nUJxn5oIyKOiovuXy+JD0L7XrX+gBSUMCbNFfuBJKCSFd qD/g== X-Received: by 10.224.54.204 with SMTP id r12mr14570176qag.105.1373211116536; Sun, 07 Jul 2013 08:31:56 -0700 (PDT) Received: from [192.168.56.1] (173-10-181-165-BusName-washingtonDC.hfc.comcastbusiness.net. [173.10.181.165]) by mx.google.com with ESMTPSA id r2sm10025566qeh.7.2013.07.07.08.31.55 for (version=TLSv1.1 cipher=RC4-SHA bits=128/128); Sun, 07 Jul 2013 08:31:55 -0700 (PDT) Content-Type: multipart/alternative; boundary="===============0084585691==" MIME-Version: 1.0 In-Reply-To: References: <769743608.173673.1373148450418.JavaMail.zimbra@peachymango.org> <47488958.173803.1373149894362.JavaMail.zimbra@peachymango.org> X-Mailer: Inky (TM) v1.0.51D7.5905 ("Epoch") Date: Sun, 07 Jul 2013 15:31:56 -0000 Message-Id: From: Dave Cridland To: "Murray S. Kucherawy" X-Gm-Message-State: ALoCoQn9tKJE5an2BozOVSZQccnU8cTgt59F5wFaBPy5RK1rGO4xQFCS3bFwsAW8GyUCBC24N5/h Cc: IETF Apps Discuss Subject: Re: [apps-discuss] update to rfc5965 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jul 2013 15:31:59 -0000 --===============0084585691== Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Murray S. Kucherawy wrote: It strikes me that putting a specific password in a standards document is unlikely to fly. It might be better to include a new media type parameter to indicate the password used to create the encrypted form. I would worry that the same problem Franck's trying to workaround here would resurface. That is, scanners would read "inside" the ZIP. Of course, maybe they would anyway with a specific media type and a known password. I don't think that a fixed password in this instance is wrong, given the purpose of the encryption is not actually to encrypt, per-se. I have to wonder if there's an alternative, like a media type that is itself defined as base64 encoded, but I note Franck's statement that a ZIP with a known password is the deployed workaround; standardizing this running code seems like the simplest option. Dave. --===============0084585691== Content-Type: text/html; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable
Murray S. Kucherawy wrote:
It strikes me that putting a specific password in a standards docume= nt is unlikely to fly.=A0 It might be better to include a new media type pa= rameter to indicate the password used to create the encrypted form.
=A0
=A0
I would worry that the same problem Franck's trying to workaround here wou= ld resurface. That is, scanners would read "inside" the ZIP. Of course, may= be they would anyway with a specific media type and a known password.
=A0
I don't think that a fixed password in this instance is wrong, given the p= urpose of the encryption is not actually to encrypt, per-se.
=A0
I have to wonder if there's an alternative, like a media type that is itse= lf defined as base64 encoded, but I note Franck's statement that a ZIP with= a known password is the deployed workaround; standardizing this running co= de seems like the simplest option.
=A0
Dave.
--===============0084585691==-- From johnl@iecc.com Sun Jul 7 11:39:11 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54BBC21F9AEF for ; Sun, 7 Jul 2013 11:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.511 X-Spam-Level: X-Spam-Status: No, score=-110.511 tagged_above=-999 required=5 tests=[AWL=0.688, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wn-moDKwwlpm for ; Sun, 7 Jul 2013 11:39:07 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id E7E6021F9A92 for ; Sun, 7 Jul 2013 11:39:06 -0700 (PDT) Received: (qmail 19174 invoked from network); 7 Jul 2013 18:39:04 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 7 Jul 2013 18:39:04 -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=51d9b5c8.xn--9vv.k1307; i=johnl@user.iecc.com; bh=N38R8MfOd7GHexAhypOlPFqTe9MeHlI7kMFuAAUE7Y4=; b=LsXA24BIW0mozOXMJfFrzDN0l6s/7DEToB2NUY/ef1dYMyhSSAHwhgF8PzDwlQ6ZmtkN0ZbVGyDCAEf8dgVGnPZo8DEJPFEPkANzGvP6cn93EM2wCgg9n7EkGzly+r5/bQyT+yMSXJHUJmEmYnbGlcZnkhCAsLSIS+X6Hs3zo0mmCUh8fkaekqBwe8xc5aJX2uShv7zhRZ+qM7zwwbh9avbLFzXyVEZg3yIjQ+5nmfnSj2kbSUo9eSdDizYop0Pu 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=51d9b5c8.xn--9vv.k1307; olt=johnl@user.iecc.com; bh=N38R8MfOd7GHexAhypOlPFqTe9MeHlI7kMFuAAUE7Y4=; b=S41PMH9W8k9UbZXElQYvl0aPxOU1MkTgmbqMefIIcgsvBfoUxCf1qq6pDPndsI/+uEf5JWye/PU2vvDyzNx5/19c8UFcKofEqSQcswxvNsGf3joBKqmFuWwBrBEp92YY3C3L5bsurcRMiqDO6Sl0UmG/mBVVqXwcEF2pw3TkqybBUp/onmaWBG4ewWLuzrNR2zeQ075gQuuLuqVHtfX4KO+Ym2dmD/xu0FTF4HXd8ISC0kT1zyzdf8CH4ZMduh1F Date: 7 Jul 2013 18:38:42 -0000 Message-ID: <20130707183842.62342.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 Subject: Re: [apps-discuss] update to rfc5965 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jul 2013 18:39:11 -0000 >Has anyone implemented this? Zip with a known password is a convention in the very small malware research community, but I haven't seen it anywhere else. Personally, I don't think that kludges to work around defective implementations belong in standards. The problem is that some organizations run mail to their abuse mailbox through spam filters. To the extent that a standard should address that at all, it should say Don't Do That. R's, John PS: I also think that it's hard to think of a worse idea than a standard way to get malware past spam filters. From ned.freed@mrochek.com Sun Jul 7 17:43:08 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 475F311E8121 for ; Sun, 7 Jul 2013 17:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Ari4JJAUpo5 for ; Sun, 7 Jul 2013 17:43:03 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 14A2121F9E45 for ; Sun, 7 Jul 2013 17:43:03 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OVQOAJIFW000A469@mauve.mrochek.com> for apps-discuss@ietf.org; Sun, 7 Jul 2013 17:38:00 -0700 (PDT) MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=iso-8859-1 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OVLZJ0QSGW000054@mauve.mrochek.com>; Sun, 7 Jul 2013 17:37:57 -0700 (PDT) Message-id: <01OVQOAI222K000054@mauve.mrochek.com> Date: Sun, 07 Jul 2013 17:31:44 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sun, 07 Jul 2013 18:38:42 +0000" <20130707183842.62342.qmail@joyce.lan> References: <20130707183842.62342.qmail@joyce.lan> To: John Levine Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] update to rfc5965 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jul 2013 00:43:08 -0000 > >Has anyone implemented this? > Zip with a known password is a convention in the very small malware > research community, but I haven't seen it anywhere else. And that's where it should stay. Anything that can be used to transfer malware to someone who knows how to deal with it can also be used to transfer malware to someone who doesn't know how to deal with it. I'm sorry, but the notion of standardizing such a thing is nothing short of crazy. > Personally, I don't think that kludges to work around defective > implementations belong in standards. The problem is that some > organizations run mail to their abuse mailbox through spam filters. > To the extent that a standard should address that at all, it should > say Don't Do That. Exactly. We keep trying to use standards in these sorts of convoluted ways to fix problems that can and should be attacked head-on. This is a losing proposition. Ned From superuser@gmail.com Sun Jul 7 22:08:12 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9D5321F9DD6 for ; Sun, 7 Jul 2013 22:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQ4uEG10vS4I for ; Sun, 7 Jul 2013 22:08:12 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 1324521F9DC0 for ; Sun, 7 Jul 2013 22:08:11 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id q56so3301752wes.17 for ; Sun, 07 Jul 2013 22:08:11 -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=E7V/C1xAufTt4Fd8pWQZ79alZWltVL7hlTe7gg5mdO8=; b=fJmRprPEWII+ZEVKjPvb8l5J0iQF1CIhPqCYaaDmPTgZZh1nwMnLvEalPsYLhb5RoQ LrYPfjlKF/DAa8RoAaTx5s4gSlOGATLW5d/hK5OEzX8JN+25C3XVbFDgBHOPTwEN/cfE 4uxw8jV/aybE1pS5CkQYnACdhzQ5OdzRe4RJyCJhpGeGUZ6WH3geuLsZLbKCRF38WQ0B QRsao9DJn0HE8nRkl1F9Fb3xwdpinVElVzBKhTeFxYAQe/fWIOTwhkD5ieHg5JSTowMN rVgfKFkUZSOB4OI8wyvFFdGlhGmIC/0UQGQ/xqly38NxwL+ZcpADM4JIjZqAJ7wHSEP1 ZM3w== MIME-Version: 1.0 X-Received: by 10.180.187.209 with SMTP id fu17mr10560781wic.52.1373260091051; Sun, 07 Jul 2013 22:08:11 -0700 (PDT) Received: by 10.180.90.16 with HTTP; Sun, 7 Jul 2013 22:08:10 -0700 (PDT) In-Reply-To: References: <769743608.173673.1373148450418.JavaMail.zimbra@peachymango.org> <47488958.173803.1373149894362.JavaMail.zimbra@peachymango.org> Date: Sun, 7 Jul 2013 22:08:10 -0700 Message-ID: From: "Murray S. Kucherawy" To: Dave Cridland Content-Type: multipart/alternative; boundary=001a11c269ace956a904e0f907e4 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] update to rfc5965 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jul 2013 05:08:12 -0000 --001a11c269ace956a904e0f907e4 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Jul 7, 2013 at 8:31 AM, Dave Cridland wrote: > I would worry that the same problem Franck's trying to workaround here > would resurface. That is, scanners would read "inside" the ZIP. Of course, > maybe they would anyway with a specific media type and a known password. > > I don't think that a fixed password in this instance is wrong, given the > purpose of the encryption is not actually to encrypt, per-se. > > I have to wonder if there's an alternative, like a media type that is > itself defined as base64 encoded, but I note Franck's statement that a ZIP > with a known password is the deployed workaround; standardizing this > running code seems like the simplest option. > > I'm just thinking that if the common practice shifts to using a different password, now we need a new RFC that updates the other one. That doesn't seem to me to be scalable. Maybe what we need is a media type whose definition spells out the fact that the encoding is meant to obscure the content from everything except analysis software. -MSK --001a11c269ace956a904e0f907e4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sun, Jul 7, 2013 at 8:31 AM, Dave Cridland <dave@cridl= and.net> wrote:
I would worry that the same problem Fra= nck's trying to workaround here would resurface. That is, scanners woul= d read "inside" the ZIP. Of course, maybe they would anyway with = a specific media type and a known password.
=A0
I don't think that a fixed password in this instance is wrong, given t= he purpose of the encryption is not actually to encrypt, per-se.
=A0
I have to wonder if there's an alternative, like a media type that is = itself defined as base64 encoded, but I note Franck's statement that a = ZIP with a known password is the deployed workaround; standardizing this ru= nning code seems like the simplest option.


I'm= just thinking that if the common practice shifts to using a different pass= word, now we need a new RFC that updates the other one.=A0 That doesn't= seem to me to be scalable.

Maybe what we need is a media type whose definition spells out th= e fact that the encoding is meant to obscure the content from everything ex= cept analysis software.

-MSK
--001a11c269ace956a904e0f907e4-- From sm@resistor.net Sun Jul 7 22:16:24 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DD1911E8177 for ; Sun, 7 Jul 2013 22:16:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u2h8-0-H764Z for ; Sun, 7 Jul 2013 22:16:23 -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 BDF3C11E8151 for ; Sun, 7 Jul 2013 22:16:23 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r685GHJU017447; Sun, 7 Jul 2013 22:16:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1373260582; bh=AmHQjHn+HG10izipSp76btkeES15KVK1bEUgvp6o1zg=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=OIcFBNaUsWGEOe1/Du/W0s9jNDTH4NYu4bpI8QwLP2URqEFM8RvOUGpCplKIhYkJc tcGTnlAOfzyreLa7hkAt4rOPDJJl1dvta+KTp/zM/8sXUrx9q0KISREO5KK0DsoON1 zO1AjTHIPM9me7F4Xvd5oyE7SoZDLpG8rHa25bR4= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1373260582; i=@resistor.net; bh=AmHQjHn+HG10izipSp76btkeES15KVK1bEUgvp6o1zg=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=f7O9sspuNNiUw2/btA4I26WX8Q5Go1UQ2ndgVDTTwXFm6x6qqRwEJnIrS46vzhbLN tU4GO2dt+NhKQ0uiIUUPM7H9oApk8SuD3WcoNoRW0H4QKpiGjwP1H4lfMZ6hURtzHE YHZax+TOLbARU/F7fGxEMuUTyA3KgFdQXspbX980= Message-Id: <6.2.5.6.2.20130707210040.0b869ae0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 07 Jul 2013 21:43:29 -0700 To: Franck Martin From: SM In-Reply-To: <47488958.173803.1373149894362.JavaMail.zimbra@peachymango. org> References: <769743608.173673.1373148450418.JavaMail.zimbra@peachymango.org> <47488958.173803.1373149894362.JavaMail.zimbra@peachymango.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] update to rfc5965 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jul 2013 05:16:24 -0000 Hi Franck, At 15:31 06-07-2013, Franck Martin wrote: >http://tools.ietf.org/html/rfc5965 > >Specifies the format of Abuse Reporting Format of emails. > >2.d indicates the report should contain either the headers of the >reported email as a text/rfc822-headers MIME part or the complete >message as an message/rfc822. However if the message reported >contains spam, virus, bad links, or in general malware, the complete >report is likely to be discarded by the receiver anti-spam filters, >never reaching abuse desks for processing. > >It is common amongst security professionals to exchange such >dangerous payloads as an encrypted zip file with the common password >"infected". This format allows to bypass anti-spam filters as the >MTA/MUA is not able to decrypt the attachment to analyze the content. > >It i difficult to request abuse desk to create a separate email >infrastructure for abuse@example.com and especially to disable >anti-spam and anti-virus checks. Some of these addresses are part of >email hosted in the cloud. One of the purposes of the report is to inform the operator about email abuse. In my opinion such a message might have usually undesirable content. The problem is that the operator is using a content filter for their abuse mailbox. It is well-known that it's not a good idea to do that. Whether they do that because they are using the "cloud" is immaterial. When something is difficult for non-technical reasons it is ample reason not to try to fix it by technical means unless profit is all that matters. Security professionals exchanging dangerous payloads by using with encrypted to bypass content filters can be described as being realistic or something else. After all, if security professionals do that, other people can do that too. >I suggest we add the possibility to send the complete email as >message/rcf822 email within either an encrypted zip file or within a >GPG symmetrically encrypted file, both using the common password "infected". The problem is not the suggestion. It's what will happen after that. Regards, -sm From superuser@gmail.com Mon Jul 8 00:20:23 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E1B221F9B10 for ; Mon, 8 Jul 2013 00:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yCDRYMOZSDnn for ; Mon, 8 Jul 2013 00:20:19 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 54A8F11E819E for ; Mon, 8 Jul 2013 00:20:17 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id hq4so8700814wib.0 for ; Mon, 08 Jul 2013 00:20:16 -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=WD6Z6yU+EIeJemiOcNKG2kAFqmJHL4qM8wc+j5o3pFw=; b=Zq+kn5OuKWEN+xahAAZp9+HgMHVkGxvSsFMC6R/+KFSN+M3aAcZ4QSsJW2om6de0DA uBtY9aOKDJdErqwLBk6SP9zzdpVh82Xc9zVAMp/MOJf1x+X7v7t9ObuO6/xQJklH4lOO j74grUVctb/jREhK8TMn5d/fz+SliQkc0929CsCiPPkXQyzjfZdX0UrOlkmYFwI50NWc tKxUCTf9J+Pbu5tcPY02PdXKvwFxBF4MBTPkIcxBO4Cl7p1+tx5VHyhfir3hvtNWTR53 BOK+SzSl7uYHcGjZ7iEaiJ9T5vl8dOeD/O748j2tfQpS19s5zXWkfALmlxOdBU21iTSj 7bVg== MIME-Version: 1.0 X-Received: by 10.194.239.225 with SMTP id vv1mr11471056wjc.63.1373268016510; Mon, 08 Jul 2013 00:20:16 -0700 (PDT) Received: by 10.180.90.16 with HTTP; Mon, 8 Jul 2013 00:20:16 -0700 (PDT) In-Reply-To: <01OVBCWUMFA0007PSE@mauve.mrochek.com> References: <20130513153932.91355.qmail@joyce.lan> <01OVBCWUMFA0007PSE@mauve.mrochek.com> Date: Mon, 8 Jul 2013 00:20:16 -0700 Message-ID: From: "Murray S. Kucherawy" To: Ned Freed Content-Type: multipart/alternative; boundary=089e014933844e3dab04e0fae0ad Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Malformed mail (was Re: Review of: draft-ietf-appsawg-malformed-mail-03) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 07:20:24 -0000 --089e014933844e3dab04e0fae0ad Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 26, 2013 at 6:23 PM, Ned Freed wrote: > In regards to malformed message, I just ran into one containing, among > other > things, the following fields: > > Received: from 1.2.3.4 @ host user@host > Received: from 4.5.6. user@host > Return-Path: user@host "phrase" > Content-Type: text/plain > Content-Transfer-Encoding: 9-bit > Content-Type: text/plain > MIME Ver: 1.40 > > (I have of course anonymized things.) > > Of course I've seen plenty of broken messages, but this is taking things > to a whole new level. > > > Should any or all of these be mentioned in the draft, or is this just fodder for general head-shaking? :-) -MSK --089e014933844e3dab04e0fae0ad Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jun 26, 2013 at 6:23 PM, Ned Freed <ned.freed= @mrochek.com> wrote:
In regards to malformed message, I just ran = into one containing, among other
things, the following fields:

Received: from 1.2.3.4 @ host user@host
Received: from 4.5.6. user@host
Return-Path: user@host "phrase"
Content-Type: text/plain
Content-Transfer-Encoding: 9-bit
Content-Type: text/plain
MIME Ver: 1.40

(I have of course anonymized things.)

Of course I've seen plenty of broken messages, but this is taking thing= s
to a whole new level.



Should any or all of these be ment= ioned in the draft, or is this just fodder for general head-shaking?=A0 :-)=

-MSK

--089e014933844e3dab04e0fae0ad-- From ned.freed@mrochek.com Mon Jul 8 00:31:35 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0161C11E81A9 for ; Mon, 8 Jul 2013 00:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QcklCSh0Ng+z for ; Mon, 8 Jul 2013 00:31:30 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id C638411E81A3 for ; Mon, 8 Jul 2013 00:31:29 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OVR2JXDVHC009NBO@mauve.mrochek.com> for apps-discuss@ietf.org; Mon, 8 Jul 2013 00:26:26 -0700 (PDT) MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=iso-8859-1 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OVLZJ0QSGW000054@mauve.mrochek.com>; Mon, 8 Jul 2013 00:26:23 -0700 (PDT) Message-id: <01OVR2JVAQIA000054@mauve.mrochek.com> Date: Mon, 08 Jul 2013 00:26:00 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Mon, 08 Jul 2013 00:20:16 -0700" References: <20130513153932.91355.qmail@joyce.lan> <01OVBCWUMFA0007PSE@mauve.mrochek.com> To: "Murray S. Kucherawy" Cc: Ned Freed , IETF Apps Discuss Subject: Re: [apps-discuss] Malformed mail (was Re: Review of: draft-ietf-appsawg-malformed-mail-03) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 07:31:35 -0000 > On Wed, Jun 26, 2013 at 6:23 PM, Ned Freed wrote: > > In regards to malformed message, I just ran into one containing, among > > other > > things, the following fields: > > > > Received: from 1.2.3.4 @ host user@host > > Received: from 4.5.6. user@host > > Return-Path: user@host "phrase" > > Content-Type: text/plain > > Content-Transfer-Encoding: 9-bit > > Content-Type: text/plain > > MIME Ver: 1.40 > > > > (I have of course anonymized things.) > > > > Of course I've seen plenty of broken messages, but this is taking things > > to a whole new level. > > > > > > > Should any or all of these be mentioned in the draft, or is this just > fodder for general head-shaking? :-) I sincerely hope it's the latter. Ned From franck@peachymango.org Mon Jul 8 00:38:21 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E845411E81A8 for ; Mon, 8 Jul 2013 00:38:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0WKbam2DMQXV for ; Mon, 8 Jul 2013 00:38:13 -0700 (PDT) Received: from smtp-out-2.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id C738521F9CF0 for ; Mon, 8 Jul 2013 00:38:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 5DE3D39000C; Mon, 8 Jul 2013 02:38:12 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp-out-2.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mZD_vd8AYcF6; Mon, 8 Jul 2013 02:38:12 -0500 (CDT) Received: from smtp-out-2.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 3832C390047; Mon, 8 Jul 2013 02:38:12 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 211F239003A; Mon, 8 Jul 2013 02:38:12 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp-out-2.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id voo17cbz-9sb; Mon, 8 Jul 2013 02:38:11 -0500 (CDT) Received: from [10.0.0.12] (c-50-148-182-52.hsd1.ca.comcast.net [50.148.182.52]) by smtp-out-2.01.com (Postfix) with ESMTPSA id D361A39000C; Mon, 8 Jul 2013 02:38:09 -0500 (CDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_408BF9D4-0598-41C5-B23A-3061607D3936" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Franck Martin In-Reply-To: Date: Mon, 8 Jul 2013 00:38:08 -0700 Message-Id: References: <769743608.173673.1373148450418.JavaMail.zimbra@peachymango.org> <47488958.173803.1373149894362.JavaMail.zimbra@peachymango.org> To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.1508) Cc: IETF Apps Discuss Subject: Re: [apps-discuss] update to rfc5965 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jul 2013 07:38:21 -0000 --Apple-Mail=_408BF9D4-0598-41C5-B23A-3061607D3936 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Jul 7, 2013, at 10:08 PM, "Murray S. Kucherawy" = wrote: > On Sun, Jul 7, 2013 at 8:31 AM, Dave Cridland = wrote: > I would worry that the same problem Franck's trying to workaround here = would resurface. That is, scanners would read "inside" the ZIP. Of = course, maybe they would anyway with a specific media type and a known = password. > =20 > I don't think that a fixed password in this instance is wrong, given = the purpose of the encryption is not actually to encrypt, per-se. > =20 > I have to wonder if there's an alternative, like a media type that is = itself defined as base64 encoded, but I note Franck's statement that a = ZIP with a known password is the deployed workaround; standardizing this = running code seems like the simplest option. >=20 >=20 > I'm just thinking that if the common practice shifts to using a = different password, now we need a new RFC that updates the other one. = That doesn't seem to me to be scalable. >=20 > Maybe what we need is a media type whose definition spells out the = fact that the encoding is meant to obscure the content from everything = except analysis software. >=20 The password could be set as an extra field in message/feedback-report = as well as indicated in the text part. --Apple-Mail=_408BF9D4-0598-41C5-B23A-3061607D3936 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1
On Jul 7, 2013, at 10:08 PM, "Murray S. Kucherawy" <superuser@gmail.com> wrote:

On Sun, Jul 7, 2013 at 8:31 AM, Dave Cridland <dave@cridland.net> wrote:
I would worry that the same problem Franck's trying to workaround here would resurface. That is, scanners would read "inside" the ZIP. Of course, maybe they would anyway with a specific media type and a known password.
 
I don't think that a fixed password in this instance is wrong, given the purpose of the encryption is not actually to encrypt, per-se.
 
I have to wonder if there's an alternative, like a media type that is itself defined as base64 encoded, but I note Franck's statement that a ZIP with a known password is the deployed workaround; standardizing this running code seems like the simplest option.


I'm just thinking that if the common practice shifts to using a different password, now we need a new RFC that updates the other one.  That doesn't seem to me to be scalable.

Maybe what we need is a media type whose definition spells out the fact that the encoding is meant to obscure the content from everything except analysis software.

The password could be set as an extra field in message/feedback-report as well as indicated in the text part.

--Apple-Mail=_408BF9D4-0598-41C5-B23A-3061607D3936-- From franck@peachymango.org Mon Jul 8 01:02:15 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9A0011E81CD for ; Mon, 8 Jul 2013 01:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mq725EFUYJ7V for ; Mon, 8 Jul 2013 01:02:02 -0700 (PDT) Received: from smtp-out-2.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id 1E18021F9A1E for ; Mon, 8 Jul 2013 01:01:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id C181139001F; Mon, 8 Jul 2013 03:00:48 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp-out-2.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n8nTH37uqt8I; Mon, 8 Jul 2013 03:00:48 -0500 (CDT) Received: from smtp-out-2.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 9F386390047; Mon, 8 Jul 2013 03:00:48 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 870AE390042; Mon, 8 Jul 2013 03:00:48 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp-out-2.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id S7SwJg37RlqA; Mon, 8 Jul 2013 03:00:48 -0500 (CDT) Received: from [10.0.0.12] (c-50-148-182-52.hsd1.ca.comcast.net [50.148.182.52]) by smtp-out-2.01.com (Postfix) with ESMTPSA id 1A17D39001F; Mon, 8 Jul 2013 03:00:47 -0500 (CDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Franck Martin In-Reply-To: Date: Mon, 8 Jul 2013 01:00:46 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <769743608.173673.1373148450418.JavaMail.zimbra@peachymango.org> <47488958.173803.1373149894362.JavaMail.zimbra@peachymango.org> <6.2.5.6.2.20130707210040.0b869ae0@resistor.net> To: SM X-Mailer: Apple Mail (2.1508) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] update to rfc5965 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jul 2013 08:02:17 -0000 On Jul 7, 2013, at 9:43 PM, SM wrote: > Hi Franck, > At 15:31 06-07-2013, Franck Martin wrote: >> http://tools.ietf.org/html/rfc5965 >>=20 >> Specifies the format of Abuse Reporting Format of emails. >>=20 >> 2.d indicates the report should contain either the headers of the = reported email as a text/rfc822-headers MIME part or the complete = message as an message/rfc822. However if the message reported contains = spam, virus, bad links, or in general malware, the complete report is = likely to be discarded by the receiver anti-spam filters, never reaching = abuse desks for processing. >>=20 >> It is common amongst security professionals to exchange such = dangerous payloads as an encrypted zip file with the common password = "infected". This format allows to bypass anti-spam filters as the = MTA/MUA is not able to decrypt the attachment to analyze the content. >>=20 >> It i difficult to request abuse desk to create a separate email = infrastructure for abuse@example.com and especially to disable anti-spam = and anti-virus checks. Some of these addresses are part of email hosted = in the cloud. >=20 > One of the purposes of the report is to inform the operator about = email abuse. In my opinion such a message might have usually = undesirable content. The problem is that the operator is using a = content filter for their abuse mailbox. It is well-known that it's not = a good idea to do that. Whether they do that because they are using the = "cloud" is immaterial. When something is difficult for non-technical = reasons it is ample reason not to try to fix it by technical means = unless profit is all that matters. >=20 > Security professionals exchanging dangerous payloads by using with = encrypted to bypass content filters can be described as being realistic = or something else. After all, if security professionals do that, other = people can do that too. >=20 >> I suggest we add the possibility to send the complete email as = message/rcf822 email within either an encrypted zip file or within a GPG = symmetrically encrypted file, both using the common password "infected". >=20 > The problem is not the suggestion. It's what will happen after that. >=20 The problem is that we are moving towards all Internet resources must = publish an abuse email address. Abuse desks seldom controls the way = email comes into their ticketing system (if any). I was indicating the = cloud just as an obvious example. As for what happens after that? Well the text portion should be explicit = enough so that a tier one respondent knows he needs to take precautions. "This email is in the Abuse Reporting Format. Cf RFC... One of the attachment contains the email we received in its entirety, = because we believe it may contains virus, malware, we are sending it = encrypted with the following password: infected. We suggest you take all = the necessary precautions before decrypting and reading this email." As noted in another email, if we pass the password, this allows = automatic processing as well as being able to choose any password. I would also argue the current ARF puts more people at risk, because a = user can simply open the attachment in their mail client, rather than = having them to enter a password in another software than the mail client = before being able to read the email. As for miscreants, they can today send encrypted zip files and have done = so in the past. I don't see this practice much, so it may not be as = effective as they'd like it to be. Anyone has some data here? From vesely@tana.it Mon Jul 8 02:07:29 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 724CB11E81A5 for ; Mon, 8 Jul 2013 02:07:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.122 X-Spam-Level: X-Spam-Status: No, score=-5.122 tagged_above=-999 required=5 tests=[AWL=-0.403, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CAxYy6o6PVpc for ; Mon, 8 Jul 2013 02:07:24 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id D84E421F84A7 for ; Mon, 8 Jul 2013 02:07:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1373274436; bh=5pmfd8u8ZQlyyabgaLCMf1QAbTWp5lX88DIK6nP0gW8=; l=576; h=Date:From:To:References:In-Reply-To; b=OWi3m0hKBMfCSjb7idxh2SyBNlxmrNboV20ENUqQQqGrV2zQt0dNcS4+xN1h6u/2f /PxySZ8mbBRL4Zsl2Qss0Y08gPiS7v0WRlsvGlHiLvE9jCe69qCp2FrqEwxw6rGcNm Cv7MCgH+0uH+OFxZPdyUYIeNRPfOt7h6G9PMuX+g= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.98] (pcale.tana [172.25.197.98]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by wmail.tana.it with ESMTPSA; Mon, 08 Jul 2013 11:07:16 +0200 id 00000000005DC039.0000000051DA8144.00004AAD Message-ID: <51DA8144.6050300@tana.it> Date: Mon, 08 Jul 2013 11:07:16 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <769743608.173673.1373148450418.JavaMail.zimbra@peachymango.org> <47488958.173803.1373149894362.JavaMail.zimbra@peachymango.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] update to rfc5965 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jul 2013 09:07:30 -0000 On Mon 08/Jul/2013 07:08:10 +0200 Murray S. Kucherawy wrote: > > Maybe what we need is a media type whose definition spells out the fact > that the encoding is meant to obscure the content from everything except > analysis software. A string saying *VIRUS*, or anything to that meaning, had better show up right in the subject, rather than hide somewhere in an entity header. Ditto for *SPAM*, after Spamassassin experience. Would that be considered a "typical forwarding prefix"? Bullet f of Section 2 seems to be a good candidate for an update anyway. jm2c From franck@peachymango.org Mon Jul 8 02:22:17 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4713921F8C40 for ; Mon, 8 Jul 2013 02:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DLCWvu8fAwB6 for ; Mon, 8 Jul 2013 02:22:10 -0700 (PDT) Received: from smtp-out-2.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id EF91C21F920B for ; Mon, 8 Jul 2013 02:21:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id E8198390076; Mon, 8 Jul 2013 04:21:25 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp-out-2.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJv2SUbrPBPa; Mon, 8 Jul 2013 04:21:25 -0500 (CDT) Received: from smtp-out-2.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id AC79339007B; Mon, 8 Jul 2013 04:21:25 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 90C1E39007A; Mon, 8 Jul 2013 04:21:25 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp-out-2.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id F3y3nPYsCYoo; Mon, 8 Jul 2013 04:21:25 -0500 (CDT) Received: from [10.0.0.12] (c-50-148-182-52.hsd1.ca.comcast.net [50.148.182.52]) by smtp-out-2.01.com (Postfix) with ESMTPSA id DCB4E39007B; Mon, 8 Jul 2013 04:20:09 -0500 (CDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Franck Martin In-Reply-To: Date: Mon, 8 Jul 2013 02:20:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5F4B4F14-7EE7-478D-BA6E-8B0BF2350707@peachymango.org> References: <769743608.173673.1373148450418.JavaMail.zimbra@peachymango.org> <47488958.173803.1373149894362.JavaMail.zimbra@peachymango.org> <51DA8144.6050300@tana.it> To: Alessandro Vesely X-Mailer: Apple Mail (2.1508) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] update to rfc5965 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jul 2013 09:22:17 -0000 On Jul 8, 2013, at 2:07 AM, Alessandro Vesely wrote: > On Mon 08/Jul/2013 07:08:10 +0200 Murray S. Kucherawy wrote: >>=20 >> Maybe what we need is a media type whose definition spells out the = fact >> that the encoding is meant to obscure the content from everything = except >> analysis software. >=20 > A string saying *VIRUS*, or anything to that meaning, had better show = up > right in the subject, rather than hide somewhere in an entity header. > Ditto for *SPAM*, after Spamassassin experience. >=20 > Would that be considered a "typical forwarding prefix"? Bullet f of > Section 2 seems to be a good candidate for an update anyway. >=20 Yes I differ from it, by prefixing "Abuse report for: " so it is clear = what it is... From stbryant@cisco.com Mon Jul 8 03:06:50 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDA2C21F9ECE for ; Mon, 8 Jul 2013 03:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.499 X-Spam-Level: X-Spam-Status: No, score=-110.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZTV48DZ6j1vy for ; Mon, 8 Jul 2013 03:06:45 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 5E5BC21F9A6A for ; Mon, 8 Jul 2013 03:06:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1177; q=dns/txt; s=iport; t=1373278003; x=1374487603; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=uu7eph3oeDlDzkS0O2aAFL5MyDwRmCkeqSZht2BdEZc=; b=JvSPiLV3PGlF6CFomjOSmocb6OpR61KpwQbKcfLaAdQ09j9hCb0gMsaB T6n3OMsKpZ3uf3h1t+zgoTgfuLKNIudcg6Ba9vR4AVM2oitf5TRsrvxv/ 3gwUHwVMUZzVPV3vNAaYQMW5oHqeB0+xpWjjZ6XzsE9EXuXLGPSkdT7Jy o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFANuM2lGQ/khR/2dsb2JhbABagwmEB7prgm6BEBZ0giMBAQEEIxVAARALGAICBRYLAgIJAwIBAgFFBg0BBwEBiAunQ5BhgSaORQeCVIEcA5dTkUiBWIE6 X-IronPort-AV: E=Sophos;i="4.87,1019,1363132800"; d="scan'208";a="14961388" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-3.cisco.com with ESMTP; 08 Jul 2013 10:06:41 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r68A6dAj017070 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jul 2013 10:06:39 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r68A6cQd005270; Mon, 8 Jul 2013 11:06:38 +0100 (BST) Message-ID: <51DA8F2E.3080202@cisco.com> Date: Mon, 08 Jul 2013 11:06:38 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: John Levine References: <20130703155547.33166.qmail@joyce.lan> In-Reply-To: <20130703155547.33166.qmail@joyce.lan> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Stewart Bryant's Discuss on draft-ietf-appsawg-rfc5451bis-09: (with DISCUSS) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 10:06:50 -0000 On 03/07/2013 16:55, John Levine wrote: >> This update to RFC5451 introduces text containing what are almost >> certainly the trade marked names of a number of products. This does not >> seem to be called out in the text, which may be a problem for the trade >> mark owners. >> >> My question (to the IESG) is whether this is something that we need to >> worry about, or something that we just leave for the RFC Editor to deal >> with. > The IETF is under no duty to acknowledge or otherwise defend > trademarks of third parties (despite the legend about the Unix > trademark.) > > This sounds like a question that would better be directed to Jorge. > > R's, > John > . > John Publishers are required to correctly recognize trademarks, and trademark owners are required to ensure that publishers do this to ensure that their trademark does not degrade to the generic term. For these purposes the IETF is a publisher, and we could receive a complaint from the trademark name owner if we do not properly acknowledge their trademark. However the text will be removed (always had been planned to be removed) so the point is addressed. Stewart From GK@ninebynine.org Mon Jul 8 03:44:55 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B80811E81BD for ; Mon, 8 Jul 2013 03:44:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.103 X-Spam-Level: X-Spam-Status: No, score=-6.103 tagged_above=-999 required=5 tests=[AWL=0.496, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5KXx4uKoGp60 for ; Mon, 8 Jul 2013 03:44:48 -0700 (PDT) Received: from relay11.mail.ox.ac.uk (relay11.mail.ox.ac.uk [129.67.1.162]) by ietfa.amsl.com (Postfix) with ESMTP id 11F2411E819F for ; Mon, 8 Jul 2013 03:44:45 -0700 (PDT) Received: from smtp2.mail.ox.ac.uk ([163.1.2.205]) by relay11.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1Uw8vx-0001si-au; Mon, 08 Jul 2013 11:44:41 +0100 Received: from gklyne.plus.com ([80.229.154.156] helo=conina.local) by smtp2.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Uw8vw-0005Fw-8C; Mon, 08 Jul 2013 11:44:41 +0100 Message-ID: <51DA9355.1040709@ninebynine.org> Date: Mon, 08 Jul 2013 11:24:21 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Erik Wilde References: <20130610033804.19451.29465.idtracker@ietfa.amsl.com> <51B7AEAF.20404@berkeley.edu> <4CD4652F-4EAF-4258-A6EB-577019018D2C@mnot.net> <1A136C4D-4F0C-446F-B307-D53FB9A40622@cs.tcd.ie> <8BE038EC-1580-4D27-ABBA-1890EEFD4853@mnot.net> <51C9C91D.90206@berkeley.edu> <4C2FD8A7-4F3E-433B-A7F6-F0BD751D31AD@mnot.net> <51CB240C.3060101@berkeley.edu> <51CB8646.60101@berkeley.edu> <873F3899-2365-4F13-A485-8924E67294FA@mnot.net> <51D6DF85.4060309@berkeley.edu> In-Reply-To: <51D6DF85.4060309@berkeley.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Cc: Mark Nottingham , REST-Discuss Discuss , IETF Apps Discuss Subject: Re: [apps-discuss] New Version Notification for draft-nottingham-link-hint-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 10:44:55 -0000 Hi Erik, and Mark, On 05/07/2013 16:00, Erik Wilde wrote: >>> but again, of course my option (c) means that link hints have a predefined >>> and probably small set of structures that hints can use to expose whatever >>> they want to expose, and if they want to go beyond that, that's not covered >>> by the link hint framework anymore. >> Yes. That's what I'm struggling with. We're already seeing a number of places >> that chafe against these constraints, and we're just getting started. >> What do other folks think? > > good point, so far it's just mark and me. anybody who faced similar design > issues who could share their considerations and decisions? I'm interested in the json-home work, and I've had discussions with both of you separately about using RDF for something similar. That's the route we followed in PROV-AQ (http://www.w3.org/TR/prov-aq/#provenance-query-service-description). I haven't really been following this link-hint discussion, though I can see it's related to the home document in light of discussions we had about the role of link relations ("why" vs "how", etc). In this general context, having some idea of what types are available to content negotiate seems useful. Beyond that, for applications that choose to use RDF (in one of its available media types), or a similar generic format, to describe services might benefit from some additional indication of whether there is likely to be anything of use to them ... but as you pointed out this tends to increase coupling, trading REST flexibility for possible more efficient discovery. This leaves me wondering if link hints might not be a form of premature optimization that might be better achieved through caching of responses? (Just a thought, not a claim.) [Later] I just (re)read the draft, and it occurs to me that most of these hints are things that can or might be provided by header fields in a server response. That suggests a possibility that a generic data model for representing hints might usefully be based closely based on the HTTP/MIME header field model. In many respects, the proposal's use of key-value pairs does make it closely aligned. It seems to me that the main thing missing may be a model for representing a header (i.e. multiple header fields) within a header field - which I think is where JSON objects are being used. #g -- From anything@michielbdejong.com Mon Jul 8 05:00:59 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D9B821F93B9 for ; Mon, 8 Jul 2013 05:00:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.297 X-Spam-Level: X-Spam-Status: No, score=-3.297 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iKzzu8SVexgX for ; Mon, 8 Jul 2013 05:00:54 -0700 (PDT) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) by ietfa.amsl.com (Postfix) with ESMTP id 4982F21F935A for ; Mon, 8 Jul 2013 05:00:51 -0700 (PDT) Received: from mfilter21-d.gandi.net (mfilter21-d.gandi.net [217.70.178.149]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id D98E941C093; Mon, 8 Jul 2013 14:00:39 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter21-d.gandi.net Received: from relay5-d.mail.gandi.net ([217.70.183.197]) by mfilter21-d.gandi.net (mfilter21-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id i1VWJR-c70NI; Mon, 8 Jul 2013 14:00:38 +0200 (CEST) X-Originating-IP: 10.58.1.141 Received: from webmail.gandi.net (unknown [10.58.1.141]) (Authenticated sender: anything@michielbdejong.com) by relay5-d.mail.gandi.net (Postfix) with ESMTPA id 3977141C087; Mon, 8 Jul 2013 14:00:36 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Date: Mon, 08 Jul 2013 14:00:36 +0200 From: "Michiel B. de Jong" To: In-Reply-To: References: Message-ID: X-Sender: anything@michielbdejong.com User-Agent: Roundcube Webmail/0.7.2 Content-Transfer-Encoding: quoted-printable Cc: mike5guo@gmail.com Subject: Re: [apps-discuss] =?utf-8?q?Who_use_online_office_software_=2Csuch_a?= =?utf-8?q?s_Google_drive_=2CMicrosoft_office_365=2C_Do_you_think_it_need_?= =?utf-8?q?break_the_information_island=EF=BC=9F?= X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jul 2013 12:00:59 -0000 On 2013-06-30 10:36, Zhun Guo wrote: > Dear all,=C2=A0 > Who use online office software ,such as Google drive ,Microsoft=20 > office > 365, Do you think it need break the information island (information > silo)? I have subitted a Internet-drafts about this topic : > > THE INTERCONNECTION AND INTEROPERABILITY OF DIFFERENT CLOUD-OFFICE > APPLICATIONS (IDCOA) WITH THE HTML FILE FORMAT ,=C2=A0.=C2=A0PLEASE GIV= E ME > MORE SUGGESTION! > > Best regards! > > Zhun Guo Hi Zhun, I had a quick read through your draft,=20 http://www.ietf.org/id/draft-guo-idoca-with-the-html-file-format-00.txt=20 here are some questions: - how is the scheme proposed in 4.1 (websocket+oauth) different from=20 the scheme described in figure 5 (self-authenticating URL)? - what makes you propose websockets for server-to-server communication?=20 i think https would do a sufficient job there - you don't describe the actual communication between the two servers.=20 say alice@alice.com initiates the transfer of a document to bob@bob.com.=20 i would expect a process a bit like: - user action: alice tells her server alice.com her intention to send=20 a document to bob. in her user interface, there is an addressbook entry=20 'bob' which includes the information that bob's online identity for this=20 purpose is bob@bob.com. - alice.com uses a webfinger lookup to discover bob@bob.com's=20 "post-me-anything" end-point, a https end-point to which you can POST=20 anything - alice.com does a POST request over https to bob@bob.com's=20 "post-me-anything" end-point, with the file type in the "Content-Type"=20 request header, and the raw document as the (binary) payload. - alice.com adds a dialback header, so bob.com can verify that the=20 document comes from alice@alice.com. - supported content-types are: application/ooxml+presentation,=20 application/odf+spreadsheet, ... (a list). - documents that are received this way and whose content-type is=20 understood by bob.com as an office document, automatically show up in=20 Bob's "documents inbox" as a document coming from Alice (if dialback=20 verification was successful). - you make a distinction between html documents and documents in other=20 formats. although i agree that html is often the best choice, especially=20 in an online environment, where the document is likely to be viewed with=20 a browser, i think you should not make this distinction as two different=20 cases, the "html" case and the "something other than html" case. i don't=20 think figures 7 and 8 are fundamentally different from each other, so i=20 would merge them into one. - do you have a sample implementation of this? you can fake the actual=20 office software of course, but at least have a demo where you send a=20 document from one server to another using your protocol. i think=20 implementing such a demo would be a good next step. in any case, kudos for taking the time to draft this! :) i hope my=20 comments are useful to you, and wish you good luck with your project.=20 let me know if you want help. cheers! Michiel From internet-drafts@ietf.org Mon Jul 8 05:15:59 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59B8121F9BFC; Mon, 8 Jul 2013 05:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.521 X-Spam-Level: X-Spam-Status: No, score=-102.521 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aieDWkb0CLhC; Mon, 8 Jul 2013 05:15:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D0FE221F9AD3; Mon, 8 Jul 2013 05:15:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130708121558.8125.73011.idtracker@ietfa.amsl.com> Date: Mon, 08 Jul 2013 05:15:58 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-xml-mediatypes-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 12:15:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Working G= roup of the IETF. Title : XML Media Types Author(s) : Chris Lilley MURATA Makoto Alexey Melnikov Henry S. Thompson Filename : draft-ietf-appsawg-xml-mediatypes-02.txt Pages : 27 Date : 2013-07-08 Abstract: This specification standardizes three media types -- application/xml, application/xml-external-parsed-entity, and application/xml-dtd -- for use in exchanging network entities that are related to the Extensible Markup Language (XML) while defining text/xml and text/ xml-external-parsed-entity as aliases for the respective application/ types. This specification also standardizes a convention (using the suffix '+xml') for naming media types outside of these five types when those media types represent XML MIME entities. Major differences from [RFC3023] are alignment of charset handling for text/xml and text/xml-external-parsed-entity with application/ xml, the addition of XPointer and XML Base as fragment identifiers and base URIs, respectively, mention of the XPointer Registry, and updating of many references. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-xml-mediatypes There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-xml-mediatypes-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-xml-mediatypes-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ht@inf.ed.ac.uk Mon Jul 8 05:25:59 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4C4611E81D1; Mon, 8 Jul 2013 05:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IijpAo7Efo7u; Mon, 8 Jul 2013 05:25:55 -0700 (PDT) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id C668411E81D5; Mon, 8 Jul 2013 05:25:52 -0700 (PDT) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id r68CPl8r025755; Mon, 8 Jul 2013 13:25:47 +0100 (BST) Received: from calexico.inf.ed.ac.uk (calexico.inf.ed.ac.uk [129.215.24.15]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id r68CPj6u004718; Mon, 8 Jul 2013 13:25:45 +0100 Received: from calexico.inf.ed.ac.uk (localhost [127.0.0.1]) by calexico.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id r68CPk5Z003928; Mon, 8 Jul 2013 13:25:46 +0100 Received: (from ht@localhost) by calexico.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id r68CPjCd003902; Mon, 8 Jul 2013 13:25:45 +0100 X-Authentication-Warning: calexico.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: internet-drafts@ietf.org References: <20130708121558.8125.73011.idtracker@ietfa.amsl.com> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Mon, 08 Jul 2013 13:25:45 +0100 In-Reply-To: <20130708121558.8125.73011.idtracker@ietfa.amsl.com> (internet-drafts@ietf.org's message of "Mon\, 08 Jul 2013 05\:15\:58 -0700") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 Cc: apps-discuss@ietf.org, i-d-announce@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-xml-mediatypes-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 12:26:00 -0000 internet-drafts writes: > 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 : XML Media Types A brief Disposition of Comments is available at http://localhost/ht/WWW/XML/2012/10/3023bis/01-comments.html A clean diff from -01 is available at http://www.w3.org/XML/2012/10/3023bis/draft-ietf-appsawg-xml-mediatypes-02_diff.html The big changes are a substantial shrinking and re-structuring of the Examples section, and the incorporation of a 6838-style registration of the '+xml' suffix, intended to update the one in 6839. I hope we're getting close to a final version here -- I'd welcome discussion at the upcoming F2F (although I can't be there :-(. ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From dret@berkeley.edu Mon Jul 8 05:27:12 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2471E11E81D6; Mon, 8 Jul 2013 05:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zTLFh1pQhu1k; Mon, 8 Jul 2013 05:27:07 -0700 (PDT) Received: from cm03fe.IST.Berkeley.EDU (cm03fe.IST.Berkeley.EDU [169.229.218.144]) by ietfa.amsl.com (Postfix) with ESMTP id A4CC311E81D1; Mon, 8 Jul 2013 05:27:07 -0700 (PDT) Received: from 46-126-158-51.dynamic.hispeed.ch ([46.126.158.51] helo=dretair.local) by cm03fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1UwAX2-00025K-Bt; Mon, 08 Jul 2013 05:27:06 -0700 Message-ID: <51DAB013.2090106@berkeley.edu> Date: Mon, 08 Jul 2013 14:26:59 +0200 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20130708121558.8125.73011.idtracker@ietfa.amsl.com> In-Reply-To: <20130708121558.8125.73011.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: chris@w3.org, internet-drafts@ietf.org, i-d-announce@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-xml-mediatypes-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 12:27:12 -0000 hello. On 2013-07-08 14:15 , internet-drafts@ietf.org wrote: > Abstract: > This specification standardizes three media types -- application/xml, > application/xml-external-parsed-entity, and application/xml-dtd -- > for use in exchanging network entities that are related to the > Extensible Markup Language (XML) while defining text/xml and text/ > xml-external-parsed-entity as aliases for the respective application/ > types. This specification also standardizes a convention (using the > suffix '+xml') for naming media types outside of these five types > when those media types represent XML MIME entities. maybe this is simply out of scope, but since i recently noticed that XSD never got around to defining its own media type: what about including a registration for XSD in this draft? DTDs are covered, RNG has its own types, and it would be useful in general if XSD had a well-defined media type as well. thanks and cheers, dret. -- erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | | UC Berkeley - School of Information (ISchool) | | http://dret.net/netdret http://twitter.com/dret | From derhoermi@gmx.net Mon Jul 8 07:11:22 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5D6A21F9C4A for ; Mon, 8 Jul 2013 07:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oPGYYaGsbcfS for ; Mon, 8 Jul 2013 07:11:18 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 45C6121F9A5B for ; Mon, 8 Jul 2013 07:11:12 -0700 (PDT) Received: from =?utf-8?q?netb.Speedport=5fW=5f700V?= ([91.35.54.144]) by mail.gmx.com (mrgmx102) with ESMTPA (Nemesis) id 0MbaS9-1UfuK80fyP-00J4tJ; Mon, 08 Jul 2013 16:11:09 +0200 From: Bjoern Hoehrmann To: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Mon, 08 Jul 2013 16:11:08 +0200 Message-ID: References: <20130708121558.8125.73011.idtracker@ietfa.amsl.com> In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:oiLP9Wa5B2Qmub8lXijnvJBiu3+hcm7jE6MHEkcAtpKEPth8o2C ghdYxq+VZQIs9E6N5EaMkm2dSuXm4Me7LmSdW/yhTBEEEgitMSnhctwJ2/N/zNEclvwlHb7 z9JDZcpDRqNfC47tQubT1dea80sdGukjFKHA2DbgY4yNCveL2yQZekE1gCNlEGOOW6e4+7l U8xSxxVbmVGeSM2XTlZlg== Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-xml-mediatypes-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 14:11:23 -0000 * Henry S. Thompson wrote: >internet-drafts writes: > >> 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 : XML Media Types > >A brief Disposition of Comments is available at > > http://localhost/ht/WWW/XML/2012/10/3023bis/01-comments.html You mean . I note that the document fails to declare that it's UTF-8 encoded. >A clean diff from -01 is available at > > http://www.w3.org/XML/2012/10/3023bis/draft-ietf-appsawg-xml-mediatypes-02_diff.html I note it says "Updates: 4289" but does not reference RFC 4289 anywhere. It seems odd that UTF-16 is a normative reference but UTF-8 is not. The UTF-16 reference should probably be non-normative. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From derhoermi@gmx.net Mon Jul 8 07:14:33 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1985421F9C61 for ; Mon, 8 Jul 2013 07:14:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jyVLMuKyG7kA for ; Mon, 8 Jul 2013 07:14:28 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id AF84121F9C75 for ; Mon, 8 Jul 2013 07:14:27 -0700 (PDT) Received: from =?utf-8?q?netb.Speedport=5fW=5f700V?= ([91.35.54.144]) by mail.gmx.com (mrgmx101) with ESMTPA (Nemesis) id 0MH4Os-1V06Cz22sc-00DoaX; Mon, 08 Jul 2013 16:14:23 +0200 From: Bjoern Hoehrmann To: Erik Wilde Date: Mon, 08 Jul 2013 16:14:22 +0200 Message-ID: References: <20130708121558.8125.73011.idtracker@ietfa.amsl.com> <51DAB013.2090106@berkeley.edu> In-Reply-To: <51DAB013.2090106@berkeley.edu> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:f1QP5fJkfZbb+8Ug3EvCWVQVeObbsx6+Cbu7F5DKBgClSNUcW0u 6ZyEarRjzBcqqzpE8w4R2qU6/xihxICS9o2ttzXN8a/yhiOaCiznV8HO+MbQsbRYCjqhWMd 7RiexlwEmlu/VXDNo7M8At8kaBCnNRImpyqWcRuibDy9ZvYZOnOxBy2/ezHtiZo8xOhFeln tz30DLl/gJcMPB7+Ie9Zw== Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-xml-mediatypes-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 14:14:33 -0000 * Erik Wilde wrote: >On 2013-07-08 14:15 , internet-drafts@ietf.org wrote: >> Abstract: >> This specification standardizes three media types -- application/xml, >> application/xml-external-parsed-entity, and application/xml-dtd -- >> for use in exchanging network entities that are related to the >> Extensible Markup Language (XML) while defining text/xml and text/ >> xml-external-parsed-entity as aliases for the respective application/ >> types. This specification also standardizes a convention (using the >> suffix '+xml') for naming media types outside of these five types >> when those media types represent XML MIME entities. > >maybe this is simply out of scope, but since i recently noticed that XSD >never got around to defining its own media type: what about including a >registration for XSD in this draft? DTDs are covered, RNG has its own >types, and it would be useful in general if XSD had a well-defined media >type as well. People are welcome to register types as they see fit, but there is no reason to piggyback unrelated types in this specification. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From ht@inf.ed.ac.uk Mon Jul 8 08:07:13 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89B7721F9C81 for ; Mon, 8 Jul 2013 08:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fF-550TabIZq for ; Mon, 8 Jul 2013 08:07:08 -0700 (PDT) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id 1087421F9D09 for ; Mon, 8 Jul 2013 08:06:56 -0700 (PDT) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id r68F6dIn007208; Mon, 8 Jul 2013 16:06:45 +0100 (BST) Received: from calexico.inf.ed.ac.uk (calexico.inf.ed.ac.uk [129.215.24.15]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id r68F6b1K011418; Mon, 8 Jul 2013 16:06:37 +0100 Received: from calexico.inf.ed.ac.uk (localhost [127.0.0.1]) by calexico.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id r68F6cqX008605; Mon, 8 Jul 2013 16:06:38 +0100 Received: (from ht@localhost) by calexico.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id r68F6aLM008601; Mon, 8 Jul 2013 16:06:36 +0100 X-Authentication-Warning: calexico.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Bjoern Hoehrmann References: <20130708121558.8125.73011.idtracker@ietfa.amsl.com> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Mon, 08 Jul 2013 16:06:36 +0100 In-Reply-To: (Bjoern Hoehrmann's message of "Mon\, 08 Jul 2013 16\:11\:08 +0200") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-xml-mediatypes-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 15:07:13 -0000 Bjoern Hoehrmann writes: > * Henry S. Thompson wrote: >>... >>A brief Disposition of Comments is available at >> >> http://localhost/ht/WWW/XML/2012/10/3023bis/01-comments.html > > You mean . Oops -- thanks! > I note that the document fails to declare that it's UTF-8 encoded. Fixed. >>A clean diff from -01 is available at >> >> http://www.w3.org/XML/2012/10/3023bis/draft-ietf-appsawg-xml-mediatypes-02_diff.html > > I note it says "Updates: 4289" but does not reference RFC 4289 anywhere. Ah, another orphan. Thanks, I'll get rid of that, and the entry in the Informative References section. > It seems odd that UTF-16 is a normative reference but UTF-8 is not. The > UTF-16 reference should probably be non-normative. This could go either way. I judged that this sentence: As described in [RFC2781], the UTF-16 family MUST NOT be used with media types under the top-level type "text" except over HTTP or HTTPS (see section 19.4.1 of [RFC2616] for details). amounted to a normative appeal to RFC2781, but that there was nothing like that for ISO-8859 (or ASCII). But I don't feel strongly about this either way --- anyone else? ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From johnl@taugh.com Mon Jul 8 08:12:29 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD4C321F9CD1 for ; Mon, 8 Jul 2013 08:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.567 X-Spam-Level: X-Spam-Status: No, score=-3.567 tagged_above=-999 required=5 tests=[AWL=1.033, BAYES_00=-2.599, GB_I_LETTER=-2, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VTgyMcQUitjW for ; Mon, 8 Jul 2013 08:12:29 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id AFB1921F9CC6 for ; Mon, 8 Jul 2013 08:12:28 -0700 (PDT) Received: (qmail 71618 invoked from network); 8 Jul 2013 15:12:27 -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:cleverness; s=117c1.51dad6db.k1307; bh=hEDtAAdL7Rt2N1SyfLY/2IusFYnPMb4bd+f41bB16XQ=; b=IIvIKS227kZEQ/CKC8e32R7yCnSrW2GOlABEZaAdXJk3tPMuf7aMQ0FGqsZ3/FxYQViGIBgEFaeqjNSS3Cn347T9ITVFsOm0ccEy/qITY5FSHdV4bnXuSCWqIDmw5/7TGtTOYq3kzLAZSiN2hJ3w/rbRMnkqSQojMMVKLyoPh0DU3VeeGszPsimcefGw0FGQBQAYXk+GCga1dxeynvmQlX/s3nZ48n+tcR85QGDBdBqHPAQ7oFQ+79VKsFQ4VdZf 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:cleverness; s=117c1.51dad6db.k1307; bh=hEDtAAdL7Rt2N1SyfLY/2IusFYnPMb4bd+f41bB16XQ=; b=UhyudUTrcdgLV4OkKwqw2qr8sut8yyqckyIEXsd30tKlCiIfIuVhfn2QpQPD7/uXpevEdFm6aXoR7HArYcWRrCVjsZINYzPHH1387+mRLLM/7+FyLj7nwyxlH1/LqpGrd+3OXisXDc3nOpcwy80mvI57w+I7loJzrxXrSLdpQaUqI6/Std24FW1mOYHrfekPF750gG0WDWo8T0llYXWKpDjZvUP3SSP/LyPu1ugaAzY9Q3I9QGRl6ZkKMz7HrhfC Received: (ofmipd 127.0.0.1); 8 Jul 2013 15:12:05 -0000 Date: 8 Jul 2013 11:12:27 -0400 Message-ID: From: "John R Levine" To: "Stewart Bryant" In-Reply-To: <51DA8F2E.3080202@cisco.com> References: <20130703155547.33166.qmail@joyce.lan> <51DA8F2E.3080202@cisco.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Stewart Bryant's Discuss on draft-ietf-appsawg-rfc5451bis-09: (with DISCUSS) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jul 2013 15:12:29 -0000 > Publishers are required to correctly recognize trademarks, and > trademark owners are required to ensure that publishers do this > to ensure that their trademark does not degrade to the generic > term. Having published many books with actual publishers including Wiley, Osborne/McGraw-Hill and the late lamented TAB and Sybex, I can assure you that your claim about publishers is simply not true. While it is true that trademark owners have a duty to defend their trademarks, nobody else is under any duty to help them do so unless they have a contractual relationship with the trademark owners. Trademark owners send out zillions of letters reminding unrelated parties about their trademarks, often phrased in misleading ways that imply that the recipient has to do something about it. Sensible publishers throw them away. Foolish publishers (I've dealt with a few) waste time filling their pages with (tm) and (R) marks. For further information, you can find a copy of the US trademark law here: http://www.law.cornell.edu/uscode/text/15/chapter-22 The one reference to publishers is here: http://www.law.cornell.edu/uscode/text/15/1114 I realize that the language in this document is gone, but it would be nice not to have to do this again the next time this comes up. MPEC IOS NAVI Netcircle Gridblocks Appnav Startnet Tomorrow Starts Here, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From derhoermi@gmx.net Mon Jul 8 08:34:06 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7853C21F9CFF for ; Mon, 8 Jul 2013 08:34:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GsN+NWHuntEJ for ; Mon, 8 Jul 2013 08:34:01 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 917AF21F9D15 for ; Mon, 8 Jul 2013 08:33:52 -0700 (PDT) Received: from =?utf-8?q?netb.Speedport=5fW=5f700V?= ([91.35.54.144]) by mail.gmx.com (mrgmx102) with ESMTPA (Nemesis) id 0MP1PX-1Uscn32ysZ-006NaX; Mon, 08 Jul 2013 17:32:48 +0200 From: Bjoern Hoehrmann To: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Mon, 08 Jul 2013 17:32:45 +0200 Message-ID: References: <20130708121558.8125.73011.idtracker@ietfa.amsl.com> In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:ltA71KO4kQu5oqcEnxZYv9v+vRgp1JXOPqzsFgQynjwAuBIy6CD 3eL/rCp9yqPvZ/fmbZe2W5GA/3RroDZY3u6qWbC0Ydtu3Vo4jNVdLDpDqFGBWsrRmtkf2VX 6Ro/7UGM+H+AZHG7Q+VmZy0C/Ks2qYtCl6YgrJX+wEI7GDCJKmWA+Sx24TOIJcss8SBo1Yz W1PWe1brP3bUP8t/YEwmg== Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-xml-mediatypes-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 15:34:06 -0000 * Henry S. Thompson wrote: >This could go either way. I judged that this sentence: > > As described in [RFC2781], the UTF-16 family MUST NOT be used with > media types under the top-level type "text" except over HTTP or > HTTPS (see section 19.4.1 of [RFC2616] for details). > >amounted to a normative appeal to RFC2781, but that there was nothing >like that for ISO-8859 (or ASCII). But I don't feel strongly about >this either way --- anyone else? The RFC 2119 keywords should only be used when removing them would also remove a requirement. That does not seem to be the case in this text, it just recites a requirement spelled out in RFC 2781. So this should not be a "MUST NOT" (make it lowercase or replace with cannot or "is not usable" or something). -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From johnl@iecc.com Mon Jul 8 09:02:37 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFCCF21F90DC for ; Mon, 8 Jul 2013 09:02:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.554 X-Spam-Level: X-Spam-Status: No, score=-110.554 tagged_above=-999 required=5 tests=[AWL=0.645, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l+NCovAB2Jh2 for ; Mon, 8 Jul 2013 09:02:33 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE4D21F9983 for ; Mon, 8 Jul 2013 09:02:33 -0700 (PDT) Received: (qmail 83841 invoked from network); 8 Jul 2013 16:02:32 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 8 Jul 2013 16:02:32 -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=51dae298.xn--yuvv84g.k1307; i=johnl@user.iecc.com; bh=DAUZZjPLp1cPAqh+M7VcWU8ljK5QFU5GywbAnHVdosM=; b=CTOZqjNgMtrjkYKivXR3YkHQSTx1cUA5+svj3xGEBgCeYhzt3EU4rlrq5pCVO7fNTmjmf2yg4WXUUnG+dF7ZS6j/EbXTM4kEmT8jHF+wJ/ESpbAy5NP/gPldrmuU8APw0jI4JNkDGnh1RSUmyd8NQ4v2lAIeFbwIvov8yuoNpFcB3T5YF2Fh1FS5argPUai8X8JWoJUThyyiZPhNyi64Jxhp7DsAQXql6YeWoh+dCc+jZX1rynrD7hm0tnaWooKX 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=51dae298.xn--yuvv84g.k1307; olt=johnl@user.iecc.com; bh=DAUZZjPLp1cPAqh+M7VcWU8ljK5QFU5GywbAnHVdosM=; b=Et3TnJaxmDqzJM0AnmBOvV6vEaION0K2gbdxql5l3ZvmcHuDOPPKbCaLAkqgHiz+vjccgFW/u/9yh+oUGv/lsn3gQIZG8Ec4MyG5Q0ZjO9WbVasfKaszAszRwzl5qoGCt+020jbU9+V6L/DVrSiiUDz29T9wmbbKx/mE8Ht6kJwBK+ahd6bTfzRbbrgGQVLrC17uiR4abCeUlfG1Pu3Z/Gh8VVQNLAtAHsP6F1zwK8KPSejHF2sdKEt63qTeyzYK Date: 8 Jul 2013 16:02:10 -0000 Message-ID: <20130708160210.69913.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 Subject: Re: [apps-discuss] bad ideas, was update to rfc5965 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jul 2013 16:02:37 -0000 >I'm just thinking that if the common practice shifts to using a different >password, now we need a new RFC that updates the other one. That doesn't >seem to me to be scalable. I gather that the proposal here is to 1) invent something, and then 2) hope that MTA operators around the world implement it. If we're going to ask MTA operators do change what they do, how about a simplified one step process where we don't invent anything, and they adjust their MTAs to stop running abuse mail through spam filters? R's, John From tony@att.com Mon Jul 8 09:06:44 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26E1421F9CFB for ; Mon, 8 Jul 2013 09:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.281 X-Spam-Level: X-Spam-Status: No, score=-106.281 tagged_above=-999 required=5 tests=[AWL=0.319, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9H9B6VNTBBDH for ; Mon, 8 Jul 2013 09:06:37 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 51F0521F8E2A for ; Mon, 8 Jul 2013 09:06:33 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 883ead15.0.348388.00-201.971410.nbfkord-smmo07.seg.att.com (envelope-from ); Mon, 08 Jul 2013 16:06:33 +0000 (UTC) X-MXL-Hash: 51dae38973c2c1d8-edd5322f43463ddd320ef12430b6132ed74f5ebe Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r68G6WiZ018552 for ; Mon, 8 Jul 2013 12:06:32 -0400 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r68G6RYf018452 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 8 Jul 2013 12:06:28 -0400 Received: from alpi153.aldc.att.com (alpi153.aldc.att.com [130.8.42.31]) by alpi133.aldc.att.com (RSA Interceptor) for ; Mon, 8 Jul 2013 16:06:18 GMT Received: from aldc.att.com (localhost [127.0.0.1]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id r68G6I99026132 for ; Mon, 8 Jul 2013 12:06:18 -0400 Received: from mailgw1.maillennium.att.com (maillennium.att.com [135.25.114.99]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id r68G6BkS025895 for ; Mon, 8 Jul 2013 12:06:13 -0400 Received: from [135.70.43.103] (vpn-135-70-43-103.vpn.west.att.com[135.70.43.103]) by maillennium.att.com (mailgw1) with ESMTP id <20130708160610gw100bhhhge> (Authid: tony); Mon, 8 Jul 2013 16:06:11 +0000 X-Originating-IP: [135.70.43.103] Message-ID: <51DAE37C.5000402@att.com> Date: Mon, 08 Jul 2013 12:06:20 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20130708121558.8125.73011.idtracker@ietfa.amsl.com> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=e+Oxv9V/ c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=nXj8lTVzzBkA:10 a=3ukmKKXcZEAA:10 a=ogWTMZA4vQMA:10 a=ofM] X-AnalysisOut: [gfj31e3cA:10 a=BLceEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=zQP7CpK] X-AnalysisOut: [OAAAA:8 a=Z21_oMWbUr8A:10 a=e5YrPUzW661iTPrqPJ0A:9 a=wPNLv] X-AnalysisOut: [fGTeEIA:10 a=0txh4J13cy8A:10 a=rIg1x6M3y2EA:10] Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-xml-mediatypes-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 16:06:44 -0000 On 7/8/2013 11:32 AM, Bjoern Hoehrmann wrote: > The RFC 2119 keywords should only be used when removing them would > also remove a requirement. That does not seem to be the case in this > text, it just recites a requirement spelled out in RFC 2781. So this > should not be a "MUST NOT" (make it lowercase or replace with cannot > or "is not usable" or something). Just a nit: Making it lowercase does not remove its 2119 meaning. Tony Hansen From sm@resistor.net Mon Jul 8 09:51:32 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5082A21F9DC2 for ; Mon, 8 Jul 2013 09:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ijtOnrAbSAi9 for ; Mon, 8 Jul 2013 09:51:31 -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 91A5E21F9DB6 for ; Mon, 8 Jul 2013 09:51:30 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r68GpNDW000076; Mon, 8 Jul 2013 09:51:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1373302289; bh=6jJ2PwDrjjcSwsNJ+8s8f8I3rXnJ8aOCgMwIgxD6Idw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=1uJj+KYFascdvZ1+UCz9C6v5bjpN3Tw812boZ1AgPeAIUqRlyRrG8AUyQsnEv9JVf A3F2P3YwVK8LQjkjxE6y9vMLxn4GjymmUNWp1urS/bwZK75SDxldktuUJLrJNu7Grw 6J/dsXUdgONgk2TWU5AfgshFGdgZZCvtZqW3a7hI= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1373302289; i=@resistor.net; bh=6jJ2PwDrjjcSwsNJ+8s8f8I3rXnJ8aOCgMwIgxD6Idw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=S47v3uZJr7FdDXIsfBhYiVOmCj0SFJSP2Pe1QIyFx/vTxvQWTf6ZakgyJKQ6wGR7X jHQt3crfI7F0uSXWW42Zd36oJD3CgDllVxlnWVPgPmIUwfOt2oubO8IOTpqQlr/TPa hM+z4xT3x29tBMJ8GPEh7ZfMgoORdCpuhdDB3MVw= Message-Id: <6.2.5.6.2.20130708052515.06addcf0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 08 Jul 2013 05:56:35 -0700 To: Franck Martin From: SM In-Reply-To: References: <769743608.173673.1373148450418.JavaMail.zimbra@peachymango.org> <47488958.173803.1373149894362.JavaMail.zimbra@peachymango.org> <6.2.5.6.2.20130707210040.0b869ae0@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] update to rfc5965 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jul 2013 16:51:32 -0000 Hi Franck, At 01:00 08-07-2013, Franck Martin wrote: >As noted in another email, if we pass the password, this allows >automatic processing as well as being able to choose any password. I am not keen about the "automatic processing" part as it is a recipe for disaster. >I would also argue the current ARF puts more people at risk, because >a user can simply open the attachment in their mail client, rather >than having them to enter a password in another software than the >mail client before being able to read the email. I took a quick look at the current specification and I see a warning in the Security Considerations section. I assume that people implementing that specification has read and understood what it means before writing code and before selling that code to abuse desks. >As for miscreants, they can today send encrypted zip files and have >done so in the past. I don't see this practice much, so it may not >be as effective as they'd like it to be. Anyone has some data here? The proposed update might make that practice effective. I was looking for some data. I don't have anything useful. These miscreants seem brighter than their counterparts as they have managed to circumvent whatever methods their counterparts created to thwart their efforts. :-) Regards, -sm From franck@peachymango.org Mon Jul 8 10:33:45 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA9321F9D91 for ; Mon, 8 Jul 2013 10:33:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NjIefHBT6iNY for ; Mon, 8 Jul 2013 10:33:40 -0700 (PDT) Received: from smtp-out-1.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id 825DD21F9D96 for ; Mon, 8 Jul 2013 10:33:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 5BB59294069; Mon, 8 Jul 2013 12:33:32 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp-out-1.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6jyckmHytgjS; Mon, 8 Jul 2013 12:33:32 -0500 (CDT) Received: from smtp-out-1.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 34FC229409F; Mon, 8 Jul 2013 12:33:32 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 1E53B29407A; Mon, 8 Jul 2013 12:33:32 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp-out-1.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id elfv4EZNcSd0; Mon, 8 Jul 2013 12:33:32 -0500 (CDT) Received: from mail-2.01.com (mail.01.com [172.18.30.178]) by smtp-out-1.01.com (Postfix) with ESMTP id D18222940A4; Mon, 8 Jul 2013 12:33:29 -0500 (CDT) Date: Mon, 8 Jul 2013 12:33:27 -0500 (CDT) From: Franck Martin To: SM Message-ID: <702030662.31758.1373304807331.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <769743608.173673.1373148450418.JavaMail.zimbra@peachymango.org> <47488958.173803.1373149894362.JavaMail.zimbra@peachymango.org> <6.2.5.6.2.20130707210040.0b869ae0@resistor.net> <6.2.5.6.2.20130708052515.06addcf0@resistor.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [69.28.149.29] X-Mailer: Zimbra 8.0.4_GA_5737 (ZimbraWebClient - FF21 (Mac)/8.0.4_GA_5737) Thread-Topic: update to rfc5965 Thread-Index: sV8VbyKGeBkng7jpMQweziCSdnruyQ== Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] update to rfc5965 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jul 2013 17:33:45 -0000 ----- Original Message ----- > From: "SM" > To: "Franck Martin" > Cc: apps-discuss@ietf.org > Sent: Monday, July 8, 2013 5:56:35 AM > Subject: Re: [apps-discuss] update to rfc5965 > > Hi Franck, > At 01:00 08-07-2013, Franck Martin wrote: > >As noted in another email, if we pass the password, this allows > >automatic processing as well as being able to choose any password. > > I am not keen about the "automatic processing" part as it is a recipe > for disaster. > How is it different from today, the message is in plain text? In the contrary, I would trust more a machine to process the ARF correctly than some lowly paid "customer success" rep at an abuse desk... > >I would also argue the current ARF puts more people at risk, because > >a user can simply open the attachment in their mail client, rather > >than having them to enter a password in another software than the > >mail client before being able to read the email. > > I took a quick look at the current specification and I see a warning > in the Security Considerations section. I assume that people > implementing that specification has read and understood what it > means before writing code and before selling that code to abuse desks. You assume wrong. There are only two specific software to do abuse desk that I know of: http://wordtothewise.com/products/abacus.html http://abusehq.abusix.com/ And they are not widely used All the rest is for "general support" like RT, which does not treat an ARF email differently from others (AFAIK). > > >As for miscreants, they can today send encrypted zip files and have > >done so in the past. I don't see this practice much, so it may not > >be as effective as they'd like it to be. Anyone has some data here? > > The proposed update might make that practice effective. I was > looking for some data. I don't have anything useful. > > These miscreants seem brighter than their counterparts as they have > managed to circumvent whatever methods their counterparts created to > thwart their efforts. :-) > the Shield and the Sword... but the answer is not let's stop making shields... it is let's make swords. From barryleiba.mailing.lists@gmail.com Mon Jul 8 12:18:11 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83C1D21F9C29 for ; Mon, 8 Jul 2013 12:18:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.969 X-Spam-Level: X-Spam-Status: No, score=-101.969 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pUEQVCZkw7E6 for ; Mon, 8 Jul 2013 12:18:11 -0700 (PDT) Received: from mail-vb0-x229.google.com (mail-vb0-x229.google.com [IPv6:2607:f8b0:400c:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 1884721F9C23 for ; Mon, 8 Jul 2013 12:18:11 -0700 (PDT) Received: by mail-vb0-f41.google.com with SMTP id p13so3799560vbe.0 for ; Mon, 08 Jul 2013 12:18: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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=5CnCkI6XfzPm2/WGfPCQhOQ3EI5mLNb3AyVAD+YVny4=; b=kxFeEIHRqTtCE6L/ZHysl7/cWtHiedqyMq4aaGpenzujQRgzuQQA2+7wtbM/wn54lL EqmaX98NGrKzBTWKca7h1OPMeV236rAosrawXHhoPaIlvCxFX05miGrg4VIJXUAYUVMe lOXawrqO9644A8jIYwVpzBLrUxalzEGx1L/y9k2XGz5bHPQhvNguwaVUnCOoZ0DO25S1 oCt9UOYta4wyK8sWNvYZW0RheQno+cnPL4jM1WeoBiai+1mn06XBFwez4q2Bxwxkl8dw E8ChBuqxqaC+eSt6WW1iUoWsZa8GVrap3/2scSI5LTaUngPSVt0L0JbWukPNhPNqOeVJ DDrA== MIME-Version: 1.0 X-Received: by 10.58.207.195 with SMTP id ly3mr14558232vec.77.1373311089025; Mon, 08 Jul 2013 12:18:09 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.137.227 with HTTP; Mon, 8 Jul 2013 12:18:08 -0700 (PDT) In-Reply-To: <51DAE37C.5000402@att.com> References: <20130708121558.8125.73011.idtracker@ietfa.amsl.com> <51DAE37C.5000402@att.com> Date: Mon, 8 Jul 2013 15:18:08 -0400 X-Google-Sender-Auth: 171vzGKplDQX2bQCK0_roiDJihg Message-ID: From: Barry Leiba To: Tony Hansen Content-Type: text/plain; charset=ISO-8859-1 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-xml-mediatypes-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 19:18:11 -0000 >> The RFC 2119 keywords should only be used when removing them would >> also remove a requirement. That does not seem to be the case in this >> text, it just recites a requirement spelled out in RFC 2781. So this >> should not be a "MUST NOT" (make it lowercase or replace with cannot >> or "is not usable" or something). > > Just a nit: Making it lowercase does not remove its 2119 meaning. Just a nit: That's not what at least a good portion of the sitting ADs think. Barry From presnick@qti.qualcomm.com Mon Jul 8 12:24:35 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E560621F9CE2; Mon, 8 Jul 2013 12:24:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gyGkPfz0p+y3; Mon, 8 Jul 2013 12:24:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C247921F9CC6; Mon, 8 Jul 2013 12:24:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Pete Resnick" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130708192433.5776.73625.idtracker@ietfa.amsl.com> Date: Mon, 08 Jul 2013 12:24:33 -0700 Cc: draft-ietf-appsawg-rfc5451bis@tools.ietf.org, appsawg-chairs@tools.ietf.org, sm+ietf@elandsys.com, apps-discuss@ietf.org Subject: [apps-discuss] Pete Resnick's Discuss on draft-ietf-appsawg-rfc5451bis-09: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jul 2013 19:24:36 -0000 Pete Resnick has entered the following ballot position for draft-ietf-appsawg-rfc5451bis-09: 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. ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I am quite uncomfortable with this document going to Internet Standard and not recycling at Proposed Standard. This document makes several significant non-backwards-compatible changes, which is not appropriate for a document advancing in grade. My ballot would be significantly different if this were going for PS. (Indeed, some of these DISCUSS points might go away, but some of the COMMENTs might become DISCUSS points because they are things that are in 5451.) For purposes of advancing to IS: 1.3: The new information in 1.3 seems incorrect. Certainly an MUA always looks at an already-delivered email message. The old 1.3 made it clear that this wasn't intended for an embedded message/rfc822 construct, but I always took that to be because it was outside of the trust boundary between the MDA and the MUA. But for messages that are delivered to a mail spool that an MUA reads and displays to the user, it is perfectly appropriate to look in the top-level of that message for the Authentication-Results. That does depend on the MDA and MUA being on the same side of the trust boundary, but other than that there is not a problem. Please explain this change. (Note: If this document were recycling at Proposed, this would be a comment, but moving to full Internet Standard, I want to understand the change before moving ahead.) 2.2: - You are expanding authserv-id to allow quoted-string and disallowing "?", "=3D", and "/" outside of quotes. This seems like a big change from 5451. - You are limiting method, result, and property to having nothing but LDH in them. Those are significant changes from 5451. - In the comment to pvalue: I think having 2119 MUST language in a comment to ABNF is crazy (being in 5451 notwithstanding). This requirement should be pulled out into the main text below the ABNF. 2.5.2: You've reversed the sense of the registry by incorporating from the SPF spec. The definition of the registry entries for the codes coming from SPF would now have to point to SPF, not for the meaning, but for the actual names. That would mean that the registry should now be an authentication method registry with the subregistry (or subentries in the table) being the result codes. Very confusing. 4: The set of message properties registered for a given method, upon which the reported result is based, can be numerous. However, the ones included in the header field being generated SHOULD NOT include any that were not included in the computation of the result. Doing so can confound consumers of the field when the method includes multiple evaluation methods. For example, SPF can base its conclusion on the RFC5321.Helo parameter or on the RFC5321.MailFrom domain; including both of those in the Authentication-Results header field makes it impossible for the consumer to determine which property of the message envelope was actually used. I don't get this paragraph. Are you saying that if SPF used HELO, I SHOULD NOT indicate that I used MAIL FROM? That seems like the height of absurdity to say. If this is something that needs to be called out, I don't understand why it isn't a MUST NOT. What does this mean? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 1: - Please repeat the Abstract as the first paragraph of the intro. Some folks don't read abstracts. - Editorial: o reverse IP address name validation ("iprev", defined in [RFC5451]) Defined in section 3 of this document, not 5451. This specification is not intended to be restricted to domain-based authentication, but has proven to be a good starting point for implementations. In order to support the propagation of evaluation results, and as various message authentication methods emerge, this header field encourages convergence for interfacing verifiers to filters and MUAs. I have read those two sentences multiple times and I still have no idea what they're saying. 1.1: In particular, the mere presence of this header field SHOULD NOT be construed as meaning that its data is valid... I'm not sure why that changed to a 2119 "SHOULD NOT", but the passive voice and the word "construed" makes it unclear to me what the requirement being stated here is. 1.5.2: By contrast, DKIM is agnostic as to the routing of a message but uses cryptographic signatures to authenticate agents claim (some) responsibility for the message (which implies authorization)... = That doesn't parse and is a change from 5451. 2.2: - Why did you make two separate "-version" elements? The original seemed fine. - You introduce "mailfrom" and "rcptto". Are those already in use? Is there a reason you simply didn't use the command names from 5321 ("mail" and "rcpt")? - The use of the word "amendment" in this section is undefined, and IMO unhelpful. - Some 2119 nonsense: The "ptype" and "property" values used by each authentication method MUST be defined in the specification for that method (or its amendments). = Not only is this a change from 5451, I'm not clear on whom this requirement rests. There is plenty of text in 2.5.6 and 2.5.7 about this. I say strike it from here. Where an SMTP command name is being reported as a "property", the MAIL FROM command MUST be represented by "mailfrom" and the RCPT TO command MUST be represented by "rcptto". All other SMTP commands MUST be represented unchanged. The MUSTs in here seem silly. So if I get a mixed-case "HeLo", I MUST use it unchanged? Again, who do these requirements apply to? 2.5.1: I'm not sure why the second paragraph was moved up from below. It makes more sense below, to me. 2.5.6: Method identifiers MUST be registered... ...such identifiers SHOULD reflect the name of the method... = Why MUST? Why SHOULD? 4: An MTA compliant with this specification MUST add this header field (after performing one or more message authentication tests) to indicate which MTA or ADMD performed the test, which test got applied and what the result was. If an MTA applies more than one such test, it MUST add this header field either once per test, or once indicating all of the results. An MTA MUST NOT add a result to an existing header field. = This appeared in 5451, so if this document does go for IS, this comment ought to be ignored. But if it recycles at PS: I find this set of requirements weird and unnecessary. The first sentence basically says, "If you implement this document, you MUST implement this document", which is just goofy. The rest says that an MTA MUST NOT add to an existing field, but that seems completely implementation dependent: I might pass partial fields along within an ADMD with trusted MTAs and do exactly that. What I think this is saying is something along the lines of the requirement to remove old ones, but then it's redundant. I don't get this paragraph. An MTA adding this header field MUST take steps to identify it as legitimate to the MUAs or downstream filters that will ultimately consume its content. One REQUIRED process to do so is described in Section 5. Further measures may be necessary in some environments. Some possible solutions are enumerated in Section 8.1. This document does not mandate any specific solution to this issue as each environment has its own facilities and limitations. The added 2119 in this paragraph doesn't help anyone. There is already a requirement in section 5, and some discussion in 8.1, about what to do and what is required. 2119 keywords with forward pointers to the actual requirements are not helpful. From sm@resistor.net Mon Jul 8 14:06:16 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0E621F9D65 for ; Mon, 8 Jul 2013 14:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ixf0t3gBC1bF for ; Mon, 8 Jul 2013 14:06:15 -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 F074421F9D61 for ; Mon, 8 Jul 2013 14:06:14 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r68L692B006176; Mon, 8 Jul 2013 14:06:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1373317574; bh=B99Ph6hADhnrkkXIKlatYikBeaOlD6EM/q0U+N3C6vQ=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=rf9rTrxh5b5VrKlCuLff+y/6TOFYUh61lnuFiRm0CAuWBoecBjeFcj+OVpyxMEsG8 vQJeUWyZazkySoyqCxljAeExx3unACOBDAlhU1JR8t2kFhOzka8B0hbzHvsFJOlFgq W0iHxxPb1+M2MrHkLjfXawT9PVgWu9DVZxYzigvk= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1373317574; i=@resistor.net; bh=B99Ph6hADhnrkkXIKlatYikBeaOlD6EM/q0U+N3C6vQ=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=By+UoyZLuyMM+fZkv0P+2/LG4DW+lj+C6T2oY6052vjSSaG9Nk37+D70Zf6rvP6cs qWXesiKBtHjqz1skxfVEKiLHwQYlEywgxdcKhrsD7kNmKFpQovwekruEDAhbFts5/i 6R9fa82uxqKTkUqFU7Uaj6kvshx1p+wk81LDspig= Message-Id: <6.2.5.6.2.20130708135557.0f4e0e78@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 08 Jul 2013 14:06:00 -0700 To: Franck Martin From: SM In-Reply-To: <702030662.31758.1373304807331.JavaMail.zimbra@peachymango. org> References: <769743608.173673.1373148450418.JavaMail.zimbra@peachymango.org> <47488958.173803.1373149894362.JavaMail.zimbra@peachymango.org> <6.2.5.6.2.20130707210040.0b869ae0@resistor.net> <6.2.5.6.2.20130708052515.06addcf0@resistor.net> <702030662.31758.1373304807331.JavaMail.zimbra@peachymango.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] update to rfc5965 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jul 2013 21:06:16 -0000 Hi Franck, At 10:33 08-07-2013, Franck Martin wrote: >How is it different from today, the message is in plain text? In the >contrary, I would trust more a machine to process the ARF correctly >than some lowly paid "customer success" rep at an abuse desk... The problem was described as being caused by "the cloud". If there isn't any difference there isn't much of a reason for a change. >You assume wrong. > >There are only two specific software to do abuse desk that I know of: >http://wordtothewise.com/products/abacus.html >http://abusehq.abusix.com/ > >And they are not widely used > >All the rest is for "general support" like RT, which does not treat >an ARF email differently from others (AFAIK). Ok. Regards, -sm From superuser@gmail.com Mon Jul 8 23:27:07 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81E5B21F9F8A; Mon, 8 Jul 2013 23:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e5-3J6b6SpsI; Mon, 8 Jul 2013 23:27:06 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id B0EE021F9F23; Mon, 8 Jul 2013 23:27:02 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id k10so9758661wiv.13 for ; Mon, 08 Jul 2013 23:27: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=WFbO2vkEq39zqz3Y7mupDKD0+SXkdtXqfFVezvrfKsY=; b=tUBHC8l+BPB1OreiCpper8TUDx7nbSS//cxpDJ1L7FMAcbFB/WS5nTq5kzkYC2DL4H QSj3RiAYofA56yki/NNN+F+xTxdq8imrodXvzt/gH8wsJ1pkM6GulAfr1/HS1u8Tf6pU /ckWpWU3DoLmfQqFTha0ZU2yDUy7x4qBJXFw+oAeY5fuhcEOHRpkA1NJlUV0KQ6o3dio 2GLxYSiAnGXuHqMh9ZHZQdBbVC3j1QK/XcgnB7qhU6NSrd6SQgA8g1UYRMfGps/AyoU5 GiklUU8dRjKbsfPXDdhpCyVRY0Mfiko8DoWGv1yq9li7kmAj2RzeHECQeX0EvPLcan3M Eaig== MIME-Version: 1.0 X-Received: by 10.180.189.102 with SMTP id gh6mr13569570wic.19.1373351221784; Mon, 08 Jul 2013 23:27:01 -0700 (PDT) Received: by 10.180.90.16 with HTTP; Mon, 8 Jul 2013 23:27:01 -0700 (PDT) In-Reply-To: <20130708192433.5776.73625.idtracker@ietfa.amsl.com> References: <20130708192433.5776.73625.idtracker@ietfa.amsl.com> Date: Mon, 8 Jul 2013 23:27:01 -0700 Message-ID: From: "Murray S. Kucherawy" To: Pete Resnick Content-Type: multipart/alternative; boundary=001a11c3436ab9f66904e10e3f70 Cc: draft-ietf-appsawg-rfc5451bis@tools.ietf.org, "appsawg-chairs@tools.ietf.org" , The IESG , IETF Apps Discuss , SM Subject: Re: [apps-discuss] Pete Resnick's Discuss on draft-ietf-appsawg-rfc5451bis-09: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jul 2013 06:27:07 -0000 --001a11c3436ab9f66904e10e3f70 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jul 8, 2013 at 12:24 PM, Pete Resnick wrote: > Pete Resnick has entered the following ballot position for > draft-ietf-appsawg-rfc5451bis-09: 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. > > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I am quite uncomfortable with this document going to Internet Standard > and not recycling at Proposed Standard. This document makes several > significant non-backwards-compatible changes, which is not appropriate > for a document advancing in grade. My ballot would be significantly > different if this were going for PS. (Indeed, some of these DISCUSS > points might go away, but some of the COMMENTs might become DISCUSS > points because they are things that are in 5451.) For purposes of > advancing to IS: > [...] > The changes you're calling backward compatible are to the best of my knowledge already implemented. A few of the ABNF changes fix errors (with matching errata), while others describe common changes implemented by the community since RFC5451 was published (i.e., they did what the original work had meant to say, not what it said). However, I don't think that argument is going to sway anyone supporting this DISCUSS that would rather we follow a pure path here, so I'm fine with downgrading this to a recycle at Proposed Standard, and simply requesting advancement in-place after six months to a year when we're sure these changes don't disrupt any of the installed base. I've talked to my document shepherd and the sponsoring AD, and they're in agreement. So, Pete, would you like to re-cast your ballot with that in mind? I'll ignore what you have here as DISCUSS until you've done so on the assumption that this choice solves most of those concerns, and focus on your COMMENT points instead. I'll reply separately about that. Also, Barry: I have a -10 in the hopper to respond to the Gen-ART review. I'll hold off posting that until Pete and I work through what's left of his issues, unless you'd like me to do otherwise. -MSK --001a11c3436ab9f66904e10e3f70 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Jul 8, 2013 at 12:24 PM, Pete Resnick <pr= esnick@qti.qualcomm.com> wrote:
Pete Resnick has entered the following ballo= t position for
draft-ietf-appsawg-rfc5451bis-09: 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.




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

I am quite uncomfortable with this document going to Internet Standard
and not recycling at Proposed Standard. This document makes several
significant non-backwards-compatible changes, which is not appropriate
for a document advancing in grade. My ballot would be significantly
different if this were going for PS. (Indeed, some of these DISCUSS
points might go away, but some of the COMMENTs might become DISCUSS
points because they are things that are in 5451.) For purposes of
advancing to IS:
[...]

The changes you're calling ba= ckward compatible are to the best of my knowledge already implemented.=A0 A= few of the ABNF changes fix errors (with matching errata), while others de= scribe common changes implemented by the community since RFC5451 was publis= hed (i.e., they did what the original work had meant to say, not what it sa= id).

However, I don't think that argument is going to sway an= yone supporting this DISCUSS that would rather we follow a pure path here, = so I'm fine with downgrading this to a recycle at Proposed Standard, an= d simply requesting advancement in-place after six months to a year when we= 're sure these changes don't disrupt any of the installed base.=A0 = I've talked to my document shepherd and the sponsoring AD, and they'= ;re in agreement.

So, Pete, would you like to re-cast your ballot with that in mind?=A0 I= 'll ignore what you have here as DISCUSS until you've done so on th= e assumption that this choice solves most of those concerns, and focus on y= our COMMENT points instead.=A0 I'll reply separately about that.

Also, Barry: I have a -10 in the hopper to respond to the G= en-ART review.=A0 I'll hold off posting that until Pete and I work thro= ugh what's left of his issues, unless you'd like me to do otherwise= .

-MSK
--001a11c3436ab9f66904e10e3f70-- From superuser@gmail.com Tue Jul 9 00:12:22 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7CE921F9F47; Tue, 9 Jul 2013 00:12:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P3nTN3zG4LcJ; Tue, 9 Jul 2013 00:12:21 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id B339821F9F34; Tue, 9 Jul 2013 00:12:20 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id b12so4400820wgh.31 for ; Tue, 09 Jul 2013 00:12: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=MBk2xSOV64Bna14JifP23iZrxW0I3FqkzynEXUbBPH0=; b=EOQbYej07PYKIlQpAb22zJ7oBnlCjbqxVPn1gwEfovIn+3o32cP3+yLTZ3TYZXZd4p M3t3XsxWMDg/6xrrU8mSfl25VviGcrKv6gbfadXP//PUexQx049Q9nonmgeGSIuQ2yCp RtjqYF6S2kcPCaxTeDm9uPqxyh43hdeorcQ1C/8WPVsDNclVfqs3reSZKA9n6Y/lITUf YE6ojZhYTlX84r7eYqPTn6rA90kSnUS5o/cg5n+3i/o6RHKZQHFRDpVHHP3r/d7oRcnp 29W6Rvm4WsX3K6tdA+nYSi//km9pENeMCrH3QcNRwWWQXOHHz4Kj/8CJIvXenPeI4RZG 3yeg== MIME-Version: 1.0 X-Received: by 10.180.89.231 with SMTP id br7mr31481124wib.19.1373353939669; Tue, 09 Jul 2013 00:12:19 -0700 (PDT) Received: by 10.180.90.16 with HTTP; Tue, 9 Jul 2013 00:12:19 -0700 (PDT) In-Reply-To: <20130708192433.5776.73625.idtracker@ietfa.amsl.com> References: <20130708192433.5776.73625.idtracker@ietfa.amsl.com> Date: Tue, 9 Jul 2013 00:12:19 -0700 Message-ID: From: "Murray S. Kucherawy" To: Pete Resnick Content-Type: multipart/alternative; boundary=e89a8f3ba255b99be104e10ee12f Cc: draft-ietf-appsawg-rfc5451bis@tools.ietf.org, "appsawg-chairs@tools.ietf.org" , The IESG , IETF Apps Discuss , SM Subject: Re: [apps-discuss] Pete Resnick's Discuss on draft-ietf-appsawg-rfc5451bis-09: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jul 2013 07:12:22 -0000 --e89a8f3ba255b99be104e10ee12f Content-Type: text/plain; charset=ISO-8859-1 Replying now to your COMMENT points: On Mon, Jul 8, 2013 at 12:24 PM, Pete Resnick wrote: > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > 1: > > - Please repeat the Abstract as the first paragraph of the intro. Some > folks don't read abstracts. > > OK. > > - Editorial: > > o reverse IP address name validation ("iprev", defined in [RFC5451]) > Fixed. > > Defined in section 3 of this document, not 5451. > > This specification is not intended to be restricted to domain-based > authentication, but has proven to be a good starting point for > implementations. In order to support the propagation of evaluation > results, and as various message authentication methods emerge, this > header field encourages convergence for interfacing verifiers to > filters and MUAs. > > I have read those two sentences multiple times and I still have no idea > what they're saying. > Looks like some words got cut someplace along the line. I'll fix it up. The point is to note that all of the methods authenticate domain names in one way or another, or even users at domains. There are other identifiers that might be the subject of evaluation now or in the future (the client IP address, perhaps, or something that authenticates something else entirely). Implementers shouldn't assume that this work is only useful for authentication of domain names just because that's all there is right now; it should be considered for methods that evaluate other identifiers of a message, envelope, or transport as well. > 1.1: > > In particular, the mere presence of this header field SHOULD NOT be > construed as meaning that its data is valid... > > I'm not sure why that changed to a 2119 "SHOULD NOT", but the passive > voice and the word "construed" makes it unclear to me what the > requirement being stated here is. > The change here was made because 2119 isn't case-specific, so if "should not" is really "SHOULD NOT", it should be shown that way. I'll reword around it. > 1.5.2: > > By contrast, DKIM is agnostic as to the routing > of a message but uses cryptographic signatures to authenticate agents > claim (some) responsibility for the message (which implies > authorization)... > > That doesn't parse and is a change from 5451. > Grammar fix-up looks easy. The change from 5451 is the addition of "(some)", which is just in line with how DKIM is commonly explained. There's no semantic change. > > 2.2: > > - Why did you make two separate "-version" elements? The original seemed > fine. > This was suggested in the working group. The syntax is indeed identical, but the prose describing the use of each (and the tie to the IANA registry in one case) is different. The suggestion was to split them so that their slightly different uses were more obvious even if the actual syntax is the same. > > - You introduce "mailfrom" and "rcptto". Are those already in use? Is > there a reason you simply didn't use the command names from 5321 ("mail" > and "rcpt")? > Yes, they are already in use. This was polled from among implementers that use A-R to relay SPF results, which is where this counts. > > - The use of the word "amendment" in this section is undefined, and IMO > unhelpful. > Changed to "update". > > - Some 2119 nonsense: > > The "ptype" and "property" values used by each authentication method > MUST be defined in the specification for that method (or its > amendments). > > Not only is this a change from 5451, I'm not clear on whom this > requirement rests. There is plenty of text in 2.5.6 and 2.5.7 about this. > I say strike it from here. > Struck. > > Where an SMTP command name is being reported as a "property", the > MAIL FROM command MUST be represented by "mailfrom" and the RCPT TO > command MUST be represented by "rcptto". All other SMTP commands > MUST be represented unchanged. > > The MUSTs in here seem silly. So if I get a mixed-case "HeLo", I MUST use > it unchanged? Again, who do these requirements apply to? > The MUST applies to the agent generating this header field and adding it to a message. I'll clean up that paragraph. > 2.5.1: > > I'm not sure why the second paragraph was moved up from below. It makes > more sense below, to me. > One of the reviewers had the opposite advice, namely to define the term "acceptable to the verifier" before using it. > > 2.5.6: > > Method identifiers MUST be registered... > ...such identifiers SHOULD reflect the name of the method... > > Why MUST? Why SHOULD? > I think those go back to an old SecDir review. They don't need to be 2119ese, I think. > > 4: > > An MTA compliant with this specification MUST add this header field > (after performing one or more message authentication tests) to > indicate which MTA or ADMD performed the test, which test got applied > and what the result was. If an MTA applies more than one such test, > it MUST add this header field either once per test, or once > indicating all of the results. An MTA MUST NOT add a result to an > existing header field. > > This appeared in 5451, so if this document does go for IS, this comment > ought to be ignored. But if it recycles at PS: I find this set of > requirements weird and unnecessary. The first sentence basically says, > "If you implement this document, you MUST implement this document", which > is just goofy. The rest says that an MTA MUST NOT add to an existing > field, but that seems completely implementation dependent: I might pass > partial fields along within an ADMD with trusted MTAs and do exactly > that. What I think this is saying is something along the lines of the > requirement to remove old ones, but then it's redundant. I don't get this > paragraph. > The first part doesn't need the MUST, I agree. The second part enforces that the field is trace data within the meaning of RFC5321, so one isn't supposed to monkey with its content or its order if it's already there. If you have more authentication information to add, prepend a new field. > > An MTA adding this header field MUST take steps to identify it as > legitimate to the MUAs or downstream filters that will ultimately > consume its content. One REQUIRED process to do so is described in > Section 5. Further measures may be necessary in some environments. > Some possible solutions are enumerated in Section 8.1. This document > does not mandate any specific solution to this issue as each > environment has its own facilities and limitations. > > The added 2119 in this paragraph doesn't help anyone. There is already a > requirement in section 5, and some discussion in 8.1, about what to do > and what is required. 2119 keywords with forward pointers to the actual > requirements are not helpful. > > This is just another lower-to-upper of 2119 key words that were in the previous version. I'll reword around them. -MSK --e89a8f3ba255b99be104e10ee12f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Replying now to your COMMENT points:

On Mon, Jul 8,= 2013 at 12:24 PM, Pete Resnick <presnick@qti.qualcomm.com>= wrote:

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

1:

- Please repeat the Abstract as the first paragraph of the intro. Some
folks don't read abstracts.


OK.
=A0

- Editorial:

=A0 =A0o =A0reverse IP address name validation ("iprev", defined = in [RFC5451])

Fixed.
=A0

Defined in section 3 of this document, not 5451.

=A0 =A0This specification is not intended to be restricted to domain-based<= br> =A0 =A0authentication, but has proven to be a good starting point for
=A0 =A0implementations. =A0In order to support the propagation of evaluatio= n
=A0 =A0results, and as various message authentication methods emerge, this<= br> =A0 =A0header field encourages convergence for interfacing verifiers to
=A0 =A0filters and MUAs.

I have read those two sentences multiple times and I still have no idea
what they're saying.

Looks li= ke some words got cut someplace along the line.=A0 I'll fix it up.=A0 T= he point is to note that all of the methods authenticate domain names in on= e way or another, or even users at domains.=A0 There are other identifiers = that might be the subject of evaluation now or in the future (the client IP= address, perhaps, or something that authenticates something else entirely)= .=A0 Implementers shouldn't assume that this work is only useful for au= thentication of domain names just because that's all there is right now= ; it should be considered for methods that evaluate other identifiers of a = message, envelope, or transport as well.


1.1:

=A0 =A0In particular, the mere presence of this header field SHOULD NOT be<= br> =A0 =A0construed as meaning that its data is valid...

I'm not sure why that changed to a 2119 "SHOULD NOT", but the= passive
voice and the word "construed" makes it unclear to me what the requirement being stated here is.

The change here was made because 2119 isn't case-specific, so if "= ;should not" is really "SHOULD NOT", it should be shown that= way.

I'll reword around it.
=A0
1.5.2:

=A0 =A0By contrast, DKIM is agnostic as to the routing
=A0 =A0of a message but uses cryptographic signatures to authenticate agent= s
=A0 =A0claim (some) responsibility for the message (which implies
=A0 =A0authorization)...

That doesn't parse and is a change from 5451.

Grammar fix-up looks easy.=A0 The change from 5451 is the = addition of "(some)", which is just in line with how DKIM is comm= only explained.=A0 There's no semantic change.
=A0

2.2:

- Why did you make two separate "-version" elements? The original= seemed
fine.

This was suggested in the w= orking group.=A0 The syntax is indeed identical, but the prose describing t= he use of each (and the tie to the IANA registry in one case) is different.= =A0 The suggestion was to split them so that their slightly different uses = were more obvious even if the actual syntax is the same.
=A0

- You introduce "mailfrom" and "rcptto". Are those alre= ady in use? Is
there a reason you simply didn't use the command names from 5321 ("= ;mail"
and "rcpt")?

Yes, they = are already in use.=A0 This was polled from among implementers that use A-R= to relay SPF results, which is where this counts.
=A0

- The use of the word "amendment" in this section is undefined, a= nd IMO
unhelpful.

Changed to "updat= e".
=A0
=

- Some 2119 nonsense:

=A0 =A0The "ptype" and "property" values used by each a= uthentication method
=A0 =A0MUST be defined in the specification for that method (or its
=A0 =A0amendments).

Not only is this a change from 5451, I'm not clear on whom this
requirement rests. There is plenty of text in 2.5.6 and 2.5.7 about this. I say strike it from here.

Struck= .
=A0

=A0 =A0Where an SMTP command name is being reported as a "property&quo= t;, the
=A0 =A0MAIL FROM command MUST be represented by "mailfrom" and th= e RCPT TO
=A0 =A0command MUST be represented by "rcptto". =A0All other SMTP= commands
=A0 =A0MUST be represented unchanged.

The MUSTs in here seem silly. So if I get a mixed-case "HeLo", I = MUST use
it unchanged? Again, who do these requirements apply to?

The MUST applies to the agent generating this heade= r field and adding it to a message.=A0 I'll clean up that paragraph.

2.5.1:

I'm not sure why the second paragraph was moved up from below. It makes=
more sense below, to me.

One of t= he reviewers had the opposite advice, namely to define the term "accep= table to the verifier" before using it.
=A0

2.5.6:

=A0 =A0Method identifiers MUST be registered...
=A0 =A0...such identifiers SHOULD reflect the name of the method...

Why MUST? Why SHOULD?

I think tho= se go back to an old SecDir review.=A0 They don't need to be 2119ese, I= think.
=A0

4:

=A0 =A0An MTA compliant with this specification MUST add this header field<= br> =A0 =A0(after performing one or more message authentication tests) to
=A0 =A0indicate which MTA or ADMD performed the test, which test got applie= d
=A0 =A0and what the result was. =A0If an MTA applies more than one such tes= t,
=A0 =A0it MUST add this header field either once per test, or once
=A0 =A0indicating all of the results. =A0An MTA MUST NOT add a result to an=
=A0 =A0existing header field.

This appeared in 5451, so if this document does go for IS, this comment
ought to be ignored. But if it recycles at PS: I find this set of
requirements weird and unnecessary. The first sentence basically says,
"If you implement this document, you MUST implement this document"= ;, which
is just goofy. The rest says that an MTA MUST NOT add to an existing
field, but that seems completely implementation dependent: I might pass
partial fields along within an ADMD with trusted MTAs and do exactly
that. What I think this is saying is something along the lines of the
requirement to remove old ones, but then it's redundant. I don't ge= t this
paragraph.

The first part doesn&#= 39;t need the MUST, I agree.=A0 The second part enforces that the field is = trace data within the meaning of RFC5321, so one isn't supposed to monk= ey with its content or its order if it's already there.=A0 If you have = more authentication information to add, prepend a new field.
=A0

=A0 =A0An MTA adding this header field MUST take steps to identify it as =A0 =A0legitimate to the MUAs or downstream filters that will ultimately =A0 =A0consume its content. =A0One REQUIRED process to do so is described i= n
=A0 =A0Section 5. =A0Further measures may be necessary in some environments= .
=A0 =A0Some possible solutions are enumerated in Section 8.1. =A0This docum= ent
=A0 =A0does not mandate any specific solution to this issue as each
=A0 =A0environment has its own facilities and limitations.

The added 2119 in this paragraph doesn't help anyone. There is already = a
requirement in section 5, and some discussion in 8.1, about what to do
and what is required. 2119 keywords with forward pointers to the actual
requirements are not helpful.


This is just another lower-to-up= per of 2119 key words that were in the previous version.=A0 I'll reword= around them.

-MSK
--e89a8f3ba255b99be104e10ee12f-- From sm@resistor.net Tue Jul 9 00:32:12 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1749A21F9A1C for ; Tue, 9 Jul 2013 00:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvm6LFyhCwrH for ; Tue, 9 Jul 2013 00:32: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 019F721F9F52 for ; Tue, 9 Jul 2013 00:32:06 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r697VtVX004885; Tue, 9 Jul 2013 00:31:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1373355121; bh=L3HJ0qkrEl7lJFmAwDxUbVh3sjbUFKM6otnxf4Ytpis=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=FYvdU1hyePzXQcz+wMf6YMArRzrLzhSXMZq/Ntp8Uq031vzQnjSpAEaqo0x2gYU4H 1goI7AgzO3YG0v913m/w3YcKDGwU+BDAqHBncmcs1/0fhBncy6HjIqXY3qbLA3sr9H CBJ5zqEAEayLY0S0jvxJu22maONiTj4+4i8PxIRQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1373355121; i=@resistor.net; bh=L3HJ0qkrEl7lJFmAwDxUbVh3sjbUFKM6otnxf4Ytpis=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Cp2kvhJW4+AboWKn+bdaygQNp/aVn+DiA52Rljk8Cz7+A7LZInil23vrCttCXsfjr uHFIenFXgGl5KWB5mTRcnqkVdQSvQ1tn0JarUhdUeR7WGQrrcEXexJziTQVTy8ptC0 +dSir/ruu8H9G0lPCulWkio2R2SqWAgOE3BQZVXI= Message-Id: <6.2.5.6.2.20130709002239.0bd60370@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 09 Jul 2013 00:31:15 -0700 To: Bjoern Hoehrmann From: SM In-Reply-To: References: <20130708121558.8125.73011.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-xml-mediatypes-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 07:32:12 -0000 Hi Bjoern, At 08:32 08-07-2013, Bjoern Hoehrmann wrote: >The RFC 2119 keywords should only be used when removing them would also >remove a requirement. That does not seem to be the case in this text, it >just recites a requirement spelled out in RFC 2781. So this should not >be a "MUST NOT" (make it lowercase or replace with cannot or "is not >usable" or something). The "MUST NOT" could be changed to lower case as it describes a requirement from RFC 2781. The reference would still be normative. Regards, -sm From duerst@it.aoyama.ac.jp Tue Jul 9 02:51:03 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C344221F9BF9; Tue, 9 Jul 2013 02:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.234 X-Spam-Level: X-Spam-Status: No, score=-101.234 tagged_above=-999 required=5 tests=[AWL=-1.444, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HaUlCIozP6gc; Tue, 9 Jul 2013 02:50:51 -0700 (PDT) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF8821F9ED9; Tue, 9 Jul 2013 02:50:37 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id r699o8lP015263; Tue, 9 Jul 2013 18:50:08 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 5019_016e_f0654a7a_e87c_11e2_9d01_001e6722eec2; Tue, 09 Jul 2013 18:50:07 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 597E2BFBBA; Tue, 9 Jul 2013 18:48:26 +0900 (JST) Message-ID: <51DBDCB4.2030509@it.aoyama.ac.jp> Date: Tue, 09 Jul 2013 18:49:40 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Pete Resnick References: <20130708192433.5776.73625.idtracker@ietfa.amsl.com> In-Reply-To: <20130708192433.5776.73625.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-appsawg-rfc5451bis@tools.ietf.org, appsawg-chairs@tools.ietf.org, The IESG , apps-discuss@ietf.org, sm+ietf@elandsys.com Subject: [apps-discuss] Abstract and Introduction (was: Re: Pete Resnick's Discuss on draft-ietf-appsawg-rfc5451bis-09: (with DISCUSS and COMMENT)) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jul 2013 09:51:03 -0000 On 2013/07/09 4:24, Pete Resnick wrote: > Pete Resnick has entered the following ballot position for > draft-ietf-appsawg-rfc5451bis-09: Discuss > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > 1: > > - Please repeat the Abstract as the first paragraph of the intro. Some > folks don't read abstracts. No, please don't! There are plenty of folks who read both abstract and introduction, and it's really annoying to read the same thing twice. So please make sure that there is no information in the abstract that isn't also in the body text (which starts at the introduction), but please don't just copy the abstract into the introduction. Regards, Martin. From cyrus@daboo.name Tue Jul 9 06:51:49 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED10E21F9CE8; Tue, 9 Jul 2013 06:51:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9LcrS9W-HKxH; Tue, 9 Jul 2013 06:51:43 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id E03DE21F99FE; Tue, 9 Jul 2013 06:51:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 15B0F46DC1F8; Tue, 9 Jul 2013 09:51:41 -0400 (EDT) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R2e-m6KD6yx6; Tue, 9 Jul 2013 09:51:40 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 9D53B46DC1ED; Tue, 9 Jul 2013 09:51:39 -0400 (EDT) Date: Tue, 09 Jul 2013 09:51:36 -0400 From: Cyrus Daboo To: Markus Lanthaler Message-ID: <269D10E96ABEE65AF92AB85A@caldav.corp.apple.com> In-Reply-To: <012901ce798f$b9c87750$2d5965f0$@lanthaler@gmx.net> References: <012901ce798f$b9c87750$2d5965f0$@lanthaler@gmx.net> X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=660 Cc: webfinger@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] [webfinger] Automated Service Configuration now uses webfinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jul 2013 13:51:49 -0000 Hi Markus, --On July 5, 2013 at 4:55:34 PM +0200 Markus Lanthaler wrote: > > Looks good to me. The only thing that bugs me is that the " Automated > Service Configuration Document Format" you define doesn't have its own > media type. That will make it impossible to reuse in other scenarios and > ambiguous how to process the target of a service-configuration link > because other people may start using their own JSON flavors. I would > suggest to define a media type or at list a profile URI to make this > unambiguous. > Agreed - I think that makes sense - I will add that to the next revision of the spec. -- Cyrus Daboo From barryleiba@computer.org Tue Jul 9 07:35:04 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C51E21F9FAA; Tue, 9 Jul 2013 07:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.282 X-Spam-Level: X-Spam-Status: No, score=-102.282 tagged_above=-999 required=5 tests=[AWL=0.318, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E5xmifD3iSBd; Tue, 9 Jul 2013 07:35:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 087DA21F9F8F; Tue, 9 Jul 2013 07:35:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Barry Leiba" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130709143503.5948.34585.idtracker@ietfa.amsl.com> Date: Tue, 09 Jul 2013 07:35:03 -0700 Cc: draft-ietf-appsawg-rfc5451bis@tools.ietf.org, appsawg-chairs@tools.ietf.org, sm+ietf@elandsys.com, apps-discuss@ietf.org Subject: [apps-discuss] Barry Leiba's Yes on draft-ietf-appsawg-rfc5451bis-09: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jul 2013 14:35:04 -0000 Barry Leiba has entered the following ballot position for draft-ietf-appsawg-rfc5451bis-09: 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. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Because of the changes being made in the document, I'm changing the target status to Proposed Standard, and it's likely to be presented in six months or so for upgrade to Internet Standard. From turners@ieca.com Tue Jul 9 09:20:23 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0DE421F918F; Tue, 9 Jul 2013 09:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GUQWEvaCIDJz; Tue, 9 Jul 2013 09:20:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 01E7421F909A; Tue, 9 Jul 2013 09:20:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Sean Turner" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130709162022.15695.88269.idtracker@ietfa.amsl.com> Date: Tue, 09 Jul 2013 09:20:22 -0700 Cc: draft-ietf-appsawg-rfc5451bis@tools.ietf.org, appsawg-chairs@tools.ietf.org, sm+ietf@elandsys.com, apps-discuss@ietf.org Subject: [apps-discuss] Sean Turner's No Objection on draft-ietf-appsawg-rfc5451bis-09: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jul 2013 16:20:24 -0000 Sean Turner has entered the following ballot position for draft-ietf-appsawg-rfc5451bis-09: 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. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I hate to slow down progression of this to IS, but I do agree with Pete's assertion that this probably needs to recycle based on the number of changes.* (I'll note Barry's already said he's going to make it cycle so no action but thought I should be on record) How does this draft seemingly get away with not normatively referencing the authentication methods? On the one hand, I can see the argument that this protocol merely copies information from another protocol to a field and then sends it on its way back to the originator. On the other hand, doesn't the creator of the report need to understand the various authentication mechanisms to know what result to send back? And please don't get me wrong, I don't want to hold publishing this up based on this comment - I'm just curious. * the diff tool worked nicely here comparing the original rfc and the bis. From stephen.farrell@cs.tcd.ie Tue Jul 9 09:53:43 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78E9A21F9DEC; Tue, 9 Jul 2013 09:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7v2zsKHNPSY; Tue, 9 Jul 2013 09:53:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6796D21F8EB2; Tue, 9 Jul 2013 09:53:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Stephen Farrell" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130709165340.8692.20830.idtracker@ietfa.amsl.com> Date: Tue, 09 Jul 2013 09:53:40 -0700 Cc: draft-ietf-appsawg-rfc5451bis@tools.ietf.org, appsawg-chairs@tools.ietf.org, sm+ietf@elandsys.com, apps-discuss@ietf.org Subject: [apps-discuss] Stephen Farrell's No Objection on draft-ietf-appsawg-rfc5451bis-09: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jul 2013 16:53:43 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-appsawg-rfc5451bis-09: 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. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - note to RFC editor in the abstract I guess needs changing = now that this is going for PS - intro: Are ADSP and VBR really in common use? - 1.6: you say valid use "requires removing" this when the message first arrives in the ADMD. I think that'd be better as a "MUST remove" but is clear enough. (Section 5 has a MUST btw, though also allows for not removing messages you get *directly* from a "trusted" peer. Is "directly" there really verifiable in general?) - 1.7: I guess this is changed by the new PS target. - 2.3: You say MUAs SHOULD use the authserv-id field to determine whether to use or ignore the header field. That's unchanged since 5451 but I wonder if it'd be better to say that MUAs need to have a whitelist or similar of values that are ok for this? What's actually done here? (This isn't a discuss since its the same in 5451.) - 2.4 and 2.5.7: I think I agree that adding these means that cycling at PS is correct. - section 4, 2nd last para: has a new SHOULD NOT that seems sensible - but I wondered why this was a SHOULD NOT and not a MUST NOT? I can't think of a case where an AR is better containing stuff that the MUA can't see. If there are such cases, maybe mention one. Or maybe I've misinterpreted the text? (It is a bit hard to get.) - section 7: Thanks! From dhc@dcrocker.net Tue Jul 9 10:38:46 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1713021F9CF5; Tue, 9 Jul 2013 10:38:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xwSDYCN-iNGs; Tue, 9 Jul 2013 10:38:41 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3077621F9CE2; Tue, 9 Jul 2013 10:38:40 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r69HcMGk006848 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 9 Jul 2013 10:38:26 -0700 Message-ID: <51DC4A77.4060609@dcrocker.net> Date: Tue, 09 Jul 2013 10:37:59 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= References: <20130708192433.5776.73625.idtracker@ietfa.amsl.com> <51DBDCB4.2030509@it.aoyama.ac.jp> In-Reply-To: <51DBDCB4.2030509@it.aoyama.ac.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Tue, 09 Jul 2013 10:38:28 -0700 (PDT) Cc: apps-discuss@ietf.org, Pete Resnick , sm+ietf@elandsys.com, appsawg-chairs@tools.ietf.org, The IESG , draft-ietf-appsawg-rfc5451bis@tools.ietf.org Subject: Re: [apps-discuss] Abstract and Introduction X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 17:38:46 -0000 On 7/9/2013 2:49 AM, "Martin J. Dürst" wrote: > On 2013/07/09 4:24, Pete Resnick wrote: >> Pete Resnick has entered the following ballot position for >> draft-ietf-appsawg-rfc5451bis-09: Discuss > >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> 1: >> >> - Please repeat the Abstract as the first paragraph of the intro. Some >> folks don't read abstracts. > > No, please don't! There are plenty of folks who read both abstract and > introduction, and it's really annoying to read the same thing twice. +10 It's worse than Martin has said. The job of an Abstract is quite different from the job of the first paragraph of an Introduction. The purpose of an abstract is to market the document to potential readers. It must, therefore, operate as a standalone precis of the document. Hence, an Abstract must summarize the nature of the document. In the case of IETF specifications, this typically means summarizing the problem, possibly summarizing the factors affecting solution efforts, and give some indication of the solution approach. The first paragraph of an Introduction can take a variety of perspectives, since it is only the first of a number of paragraphs in only the first of a number of sections. Typically, the first paragraph sets the stage for the operational environment, or it sets the stage form the problems within that environment. This covers only a small part of the scope of an Abstract. Bad, Pete. Bad. Tsk. Tsk. d/ ps. To make matters a bit confusing, the first paragraph of a /charter/ is supposed to operate as an abstract/marketing-blurb for a working group, since that paragraph is circulated independent of the rest of the charter, as part of the wg announcement. Unfortunately, that requirement is never enforced. -- Dave Crocker Brandenburg InternetWorking bbiw.net From superuser@gmail.com Tue Jul 9 10:53:45 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 440E721F9CFF; Tue, 9 Jul 2013 10:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A49zaroRVz8A; Tue, 9 Jul 2013 10:53:40 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id EE83721F9D18; Tue, 9 Jul 2013 10:53:38 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id j13so5165934wgh.24 for ; Tue, 09 Jul 2013 10:53:38 -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=LoPv9ruO9fkvRHXSf432d3PlwsQXgIS5o5J/r0tXmxo=; b=eSFCZLr8TD+MSlTDPUxwuKp0R5JSfc2eqN5kLdrKe2wTNQ4lpa90t7Si6tH1USbS0U bOvZJ1GOaU5kAf5vXMfu7MuQe9HxwhtEKC6vOcO/jhIUE17Way+i4pILP13zl+Z4QpRB xCmYdlulzqtRKEtdP7vEAaMrnsZ4o5QVvSEy1KWslhQSs9QoLfkWFsmVro01GTGQtCo8 KKAxXwhvCYNpSikhZdnmu1tV0n9rl3hHwHPOYa9ITs9FuZnRACapCzZpgIT+9PAHWoMF FVPaxCzydSbghqNgxu66UNbgymLwlQuLvnIdxWQT3T08MDQgoSNTyP8noPx+kFpzdqzW Rn2A== MIME-Version: 1.0 X-Received: by 10.180.187.209 with SMTP id fu17mr14858661wic.52.1373392416836; Tue, 09 Jul 2013 10:53:36 -0700 (PDT) Received: by 10.180.90.16 with HTTP; Tue, 9 Jul 2013 10:53:36 -0700 (PDT) In-Reply-To: <20130708192433.5776.73625.idtracker@ietfa.amsl.com> References: <20130708192433.5776.73625.idtracker@ietfa.amsl.com> Date: Tue, 9 Jul 2013 10:53:36 -0700 Message-ID: From: "Murray S. Kucherawy" To: Pete Resnick Content-Type: multipart/alternative; boundary=001a11c269ac2493f504e117d7fb Cc: draft-ietf-appsawg-rfc5451bis@tools.ietf.org, "appsawg-chairs@tools.ietf.org" , The IESG , IETF Apps Discuss , SM Subject: Re: [apps-discuss] Pete Resnick's Discuss on draft-ietf-appsawg-rfc5451bis-09: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jul 2013 17:53:45 -0000 --001a11c269ac2493f504e117d7fb Content-Type: text/plain; charset=ISO-8859-1 Pete's asked me to reply to the DISCUSS points as well to help him change his ballot based on my responses: On Mon, Jul 8, 2013 at 12:24 PM, Pete Resnick wrote: > > 1.3: > > The new information in 1.3 seems incorrect. Certainly an MUA always looks > at an already-delivered email message. The old 1.3 made it clear that > this wasn't intended for an embedded message/rfc822 construct, but I > always took that to be because it was outside of the trust boundary > between the MDA and the MUA. But for messages that are delivered to a > mail spool that an MUA reads and displays to the user, it is perfectly > appropriate to look in the top-level of that message for the > Authentication-Results. That does depend on the MDA and MUA being on the > same side of the trust boundary, but other than that there is not a > problem. Please explain this change. (Note: If this document were > recycling at Proposed, this would be a comment, but moving to full > Internet Standard, I want to understand the change before moving ahead.) > The augmented text is meant to address some of the issues that were raised since the publication of RFC5451, including the appeal of that document's approval to the IESG. There exists an argument that this field should carry with it enough information for the MUA to repeat the authentication steps before deciding whether or how to render the message to a user. For example, proponents of that argument claim the IP address should be included in this field so that MUAs can repeat SPF at the time the message is rendered. Certainly MUAs will be consuming the content of this field after delivery to an inbox, but the goal here is not to enable them to do new authentication work, but rather to apply the results of prior authentication work. An A-R field that's part of a message/rfc822 MIME part could bear an authserv-id that the MUA would normally trust, but it's dicey to believe that field was subjected to the required scrubbing rules this document specifies. Any suggestions to make the above clear? > > 2.2: > > - You are expanding authserv-id to allow quoted-string and disallowing > "?", "=", and "/" outside of quotes. This seems like a big change from > 5451. > > - You are limiting method, result, and property to having nothing but LDH > in them. Those are significant changes from 5451. > We're recycling at PS primarily for this reason. > > - In the comment to pvalue: I think having 2119 MUST language in a > comment to ABNF is crazy (being in 5451 notwithstanding). This > requirement should be pulled out into the main text below the ABNF. > OK. > > 2.5.2: > > You've reversed the sense of the registry by incorporating from the SPF > spec. The definition of the registry entries for the codes coming from > SPF would now have to point to SPF, not for the meaning, but for the > actual names. That would mean that the registry should now be an > authentication method registry with the subregistry (or subentries in the > table) being the result codes. Very confusing. > This was done in the spirit of not copying the content of one RFC into another. Unlike DKIM and the others, the list of possible outcomes and their definitions are enumerated in a different RFC for SPF, so it seemed like a cleaner solution. If it turns out the cost of the leaner document is too high in the way you've described, I can revert. > 4: > > The set of message properties registered for a given method, upon > which the reported result is based, can be numerous. However, the > ones included in the header field being generated SHOULD NOT include > any that were not included in the computation of the result. Doing > so can confound consumers of the field when the method includes > multiple evaluation methods. For example, SPF can base its > conclusion on the RFC5321.Helo parameter or on the RFC5321.MailFrom > domain; including both of those in the Authentication-Results header > field makes it impossible for the consumer to determine which > property of the message envelope was actually used. > > I don't get this paragraph. Are you saying that if SPF used HELO, I > SHOULD NOT indicate that I used MAIL FROM? That seems like the height of > absurdity to say. If this is something that needs to be called out, I > don't understand why it isn't a MUST NOT. What does this mean? > SPF can produce a result based on either the HELO or MAIL FROM data provided as part of the SMTP session. If one were to generate an A-R field that says "spf=pass smtp,mailfrom=XXX smtp.helo=YYY", I am unable to tell which of the two parameters was used to produce the "pass" result. For an agent that wants to know that, this limitation is required. So, "yes" to your second sentence. I'm fine with making it a MUST NOT; I think SHOULD NOT was there for a not-very-good reason in retrospect. -MSK --001a11c269ac2493f504e117d7fb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Pete's asked me to reply to the DISCUSS points as well= to help him change his ballot based on my responses:

On Mon, Jul 8, 2013 at 12:24 PM, Pe= te Resnick <presnick@qti.qualcomm.com> wrote:

1.3:

The new information in 1.3 seems incorrect. Certainly an MUA always looks at an already-delivered email message. The old 1.3 made it clear that
this wasn't intended for an embedded message/rfc822 construct, but I always took that to be because it was outside of the trust boundary
between the MDA and the MUA. But for messages that are delivered to a
mail spool that an MUA reads and displays to the user, it is perfectly
appropriate to look in the top-level of that message for the
Authentication-Results. That does depend on the MDA and MUA being on the same side of the trust boundary, but other than that there is not a
problem. Please explain this change. (Note: If this document were
recycling at Proposed, this would be a comment, but moving to full
Internet Standard, I want to understand the change before moving ahead.)

The augmented text is meant to address some of= the issues that were raised since the publication of RFC5451, including th= e appeal of that document's approval to the IESG.=A0 There exists an ar= gument that this field should carry with it enough information for the MUA = to repeat the authentication steps before deciding whether or how to render= the message to a user.=A0 For example, proponents of that argument claim t= he IP address should be included in this field so that MUAs can repeat SPF = at the time the message is rendered.

Certainly MUAs will be consuming the c= ontent of this field after delivery to an inbox, but the goal here is not t= o enable them to do new authentication work, but rather to apply the result= s of prior authentication work.

An A-R field that's part of a mess= age/rfc822 MIME part could bear an authserv-id that the MUA would normally = trust, but it's dicey to believe that field was subjected to the requir= ed scrubbing rules this document specifies.

Any suggestions to make the above clea= r?
=A0

- In the comment to pvalue: I think having 2119 MUST language in a
comment to ABNF is crazy (being in 5451 notwithstanding). This
requirement should be pulled out into the main text below the ABNF.

OK.
=A0

2.5.2:

You've reversed the sense of the registry by incorporating from the SPF=
spec. The definition of the registry entries for the codes coming from
SPF would now have to point to SPF, not for the meaning, but for the
actual names. That would mean that the registry should now be an
authentication method registry with the subregistry (or subentries in the table) being the result codes. Very confusing.

This was done in the spirit of not copying the content of one RFC i= nto another.=A0 Unlike DKIM and the others, the list of possible outcomes a= nd their definitions are enumerated in a different RFC for SPF, so it seeme= d like a cleaner solution.=A0 If it turns out the cost of the leaner docume= nt is too high in the way you've described, I can revert.


4:

=A0 =A0The set of message properties registered for a given method, upon =A0 =A0which the reported result is based, can be numerous. =A0However, the=
=A0 =A0ones included in the header field being generated SHOULD NOT include=
=A0 =A0any that were not included in the computation of the result. =A0Doin= g
=A0 =A0so can confound consumers of the field when the method includes
=A0 =A0multiple evaluation methods. =A0For example, SPF can base its
=A0 =A0conclusion on the RFC5321.Helo parameter or on the RFC5321.MailFrom<= br> =A0 =A0domain; including both of those in the Authentication-Results header=
=A0 =A0field makes it impossible for the consumer to determine which
=A0 =A0property of the message envelope was actually used.

I don't get this paragraph. Are you saying that if SPF used HELO, I
SHOULD NOT indicate that I used MAIL FROM? That seems like the height of absurdity to say. If this is something that needs to be called out, I
don't understand why it isn't a MUST NOT. What does this mean?
<= /blockquote>

SPF can produce a result based on either th= e HELO or MAIL FROM data provided as part of the SMTP session.=A0 If one we= re to generate an A-R field that says "spf=3Dpass smtp,mailfrom=3DXXX = smtp.helo=3DYYY", I am unable to tell which of the two parameters was = used to produce the "pass" result.=A0 For an agent that wants to = know that, this limitation is required.=A0 So, "yes" to your seco= nd sentence.=A0 I'm fine with making it a MUST NOT; I think SHOULD NOT = was there for a not-very-good reason in retrospect.

-MSK
--001a11c269ac2493f504e117d7fb-- From superuser@gmail.com Tue Jul 9 11:04:38 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE46F21F9EC4; Tue, 9 Jul 2013 11:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Loba-ejtBu-W; Tue, 9 Jul 2013 11:04:38 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id B20A421F9EB7; Tue, 9 Jul 2013 11:04:37 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id z11so10158000wgg.3 for ; Tue, 09 Jul 2013 11:04:36 -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=YcSjiJlQLOKfIfOQ915OlK1PfDX4AO6gG/dChsL0p9w=; b=R+5Om3jULh6aJNETJv/j+BV2CXtp93dzP/9sX5kS6iCoxCFVxW8FvjljuInE6DBPQ1 Wu8abT/kZ2fB7xjo/SpE9X/JYql7yw/u2TwQOxoYEUyT3zT5gtRAQsc/rtF9tWqBJAUj 2mP/YEp8FR3yidvzZiv4wUfmFQTqFhrWGQ/JvMPJM8VAdTK8Cix7T5rYZq5HniG5MKaR OsG+8P5Xw+F4Ri9Z92qExph0xI9eMewI1GQuQmFnZyIKMGlamcanOUWBWTqB2u55fO/Q k1pKeRbOD8dSuVAf2dqivGh0Fxp9t5eczqBe9gZKHEGAKIeBkyPxNOWLgxK+qYQsdlmb +W2Q== MIME-Version: 1.0 X-Received: by 10.180.189.102 with SMTP id gh6mr15157838wic.19.1373393076773; Tue, 09 Jul 2013 11:04:36 -0700 (PDT) Received: by 10.180.90.16 with HTTP; Tue, 9 Jul 2013 11:04:36 -0700 (PDT) In-Reply-To: <20130709165340.8692.20830.idtracker@ietfa.amsl.com> References: <20130709165340.8692.20830.idtracker@ietfa.amsl.com> Date: Tue, 9 Jul 2013 11:04:36 -0700 Message-ID: From: "Murray S. Kucherawy" To: Stephen Farrell Content-Type: multipart/alternative; boundary=001a11c3436a7a6ad004e117fe0d Cc: draft-ietf-appsawg-rfc5451bis@tools.ietf.org, "appsawg-chairs@tools.ietf.org" , The IESG , IETF Apps Discuss , SM Subject: Re: [apps-discuss] Stephen Farrell's No Objection on draft-ietf-appsawg-rfc5451bis-09: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jul 2013 18:04:39 -0000 --001a11c3436a7a6ad004e117fe0d Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 9, 2013 at 9:53 AM, Stephen Farrell wrote: > - note to RFC editor in the abstract I guess needs changing > now that this is going for PS > Fixed. > > - intro: Are ADSP and VBR really in common use? > There's support for both in OpenDKIM which is definitely in common use. I don't have any data about how many people have actually turned them on, nor do I have any publication survey data. > - 1.6: you say valid use "requires removing" this when the > message first arrives in the ADMD. I think that'd be better > as a "MUST remove" but is clear enough. (Section 5 has a MUST > btw, though also allows for not removing messages you > get *directly* from a "trusted" peer. Is "directly" there > really verifiable in general?) > Section 1.6 is part of an overall introduction section, so I avoided using RFC2119 language in it. As you point out, the requirement is actually established elsewhere. > > - 1.7: I guess this is changed by the new PS target. > Removed. > > - 2.3: You say MUAs SHOULD use the authserv-id field to > determine whether to use or ignore the header field. That's > unchanged since 5451 but I wonder if it'd be better to say that > MUAs need to have a whitelist or similar of values that are ok > for this? What's actually done here? (This isn't a discuss since > its the same in 5451.) > The whitelist solution is the most common one (and the only one I know of). There might be some way other than a whitelist to determine whether to trust the field, but it didn't seem appropriate to name a specific way to do that in case that's taken as proscribing other methods. > > - 2.4 and 2.5.7: I think I agree that adding these means that > cycling at PS is correct. > Right. > > - section 4, 2nd last para: has a new SHOULD NOT that seems > sensible - but I wondered why this was a SHOULD NOT and not a > MUST NOT? I can't think of a case where an AR is better > containing stuff that the MUA can't see. If there are such > cases, maybe mention one. Or maybe I've misinterpreted the > text? (It is a bit hard to get.) > Pete brought up the same point in a different spot. MUST NOT is fine with me. Any suggestions to de-confuse it? > > - section 7: Thanks! > > A question to the IESG: Should I take that out since this is falling back to PS, or leave it in? It won't be there when the request comes to advance this to IS in 6-12 months. -MSK --001a11c3436a7a6ad004e117fe0d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Jul 9, 2013 at 9:53 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
- note to RFC editor in the abstract I guess= needs changing
now that this is going for PS

Fixed.=A0

- intro: Are ADSP and VBR really in common use?

There's support for both in OpenDKIM which is definitely in co= mmon use.=A0 I don't have any data about how many people have actually = turned them on, nor do I have any publication survey data.


- 1.6: you say valid use "requires removing" this when the
message first arrives in the ADMD. I think that'd be better
as a "MUST remove" but is clear enough. (Section 5 has a MUST
btw, though also allows for not removing messages you
get *directly* from a "trusted" peer. Is "directly" the= re
really verifiable in general?)

Section = 1.6 is part of an overall introduction section, so I avoided using RFC2119 = language in it.=A0 As you point out, the requirement is actually establishe= d elsewhere.
=A0

- 1.7: I guess this is changed by the new PS target.
<= br>
Removed.
=A0

- 2.3: You say MUAs SHOULD use the authserv-id field to
determine whether to use or ignore the header field. That's
unchanged since 5451 but I wonder if it'd be better to say that
MUAs need to have a whitelist or similar of values that are ok
for this? What's actually done here? (This isn't a discuss since its the same in 5451.)

The whitelist so= lution is the most common one (and the only one I know of).=A0 There might = be some way other than a whitelist to determine whether to trust the field,= but it didn't seem appropriate to name a specific way to do that in ca= se that's taken as proscribing other methods.

=A0

- 2.4 and 2.5.7: I think I agree that adding these means that
cycling at PS is correct.

Right.
=A0=

- section 4, 2nd last para: has a new SHOULD NOT that seems
sensible - but I wondered why this was a SHOULD NOT and not a
MUST NOT? I can't think of a case where an AR is better
containing stuff that the MUA can't see. If there are such
cases, maybe mention one. Or maybe I've misinterpreted the
text? (It is a bit hard to get.)

Pete b= rought up the same point in a different spot.=A0 MUST NOT is fine with me.<= br>
Any suggestions to de-confuse it?
=A0

- section 7: Thanks!


A question to the IESG: Should I take = that out since this is falling back to PS, or leave it in?=A0 It won't = be there when the request comes to advance this to IS in 6-12 months.

-MSK
--001a11c3436a7a6ad004e117fe0d-- From superuser@gmail.com Tue Jul 9 11:23:56 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9200D21F9D8D; Tue, 9 Jul 2013 11:23:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rL6tEtyrLmzN; Tue, 9 Jul 2013 11:23:55 -0700 (PDT) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 942B921F9D8A; Tue, 9 Jul 2013 11:23:54 -0700 (PDT) Received: by mail-wg0-f53.google.com with SMTP id y10so5142671wgg.20 for ; Tue, 09 Jul 2013 11:23: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=+wN8qnkqzj8ypSZjIsfbUq3D6uKZWJbHtsWwY40c3Dw=; b=KkRY1nSNAqQz9yraebXaGnmBuHg2Z5brVrWfr1LVnUPCDT04rxObvR4JtfeQ1HOKyz XAZRTv1mBo9ZAgnkwkOoudvQZhsYMUIL2/nifRfCa5Pye5GWqQkvKFuKKuQePub4aVeI ASOQ0kpbEtaQByGW61b5Tf7G4KQ5FCuzEW4UOUD37OfIKKtXI8L6KJIjxxk4WcbcJqYZ ZSOUNasPf9qm3KEBZnCTttCHfNzAGx9KWyPfbCQUcb3B8m7NUGTVi6ztixsO2mkk1YIJ 9cCg0aw8qMd9fAR8s7FISJZNsdpJz2nBT6WTG4+kThlZ6+C68DVypZj1AD2STOZnDXqP bRBw== MIME-Version: 1.0 X-Received: by 10.180.102.37 with SMTP id fl5mr32611450wib.52.1373394233634; Tue, 09 Jul 2013 11:23:53 -0700 (PDT) Received: by 10.180.90.16 with HTTP; Tue, 9 Jul 2013 11:23:53 -0700 (PDT) In-Reply-To: <20130709003704.15548.41553.idtracker@ietfa.amsl.com> References: <20130709003704.15548.41553.idtracker@ietfa.amsl.com> Date: Tue, 9 Jul 2013 11:23:53 -0700 Message-ID: From: "Murray S. Kucherawy" To: Spencer Dawkins Content-Type: multipart/alternative; boundary=f46d044517f76eb9bc04e11843d2 Cc: draft-ietf-appsawg-rfc5451bis@tools.ietf.org, "appsawg-chairs@tools.ietf.org" , The IESG , IETF Apps Discuss , SM Subject: Re: [apps-discuss] Spencer Dawkins' No Objection on draft-ietf-appsawg-rfc5451bis-09: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jul 2013 18:23:56 -0000 --f46d044517f76eb9bc04e11843d2 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jul 8, 2013 at 5:37 PM, Spencer Dawkins < spencerdawkins.ietf@gmail.com> wrote: > > I found this specification clear and especially appreciated the context > in sections like Operational Guidance. > Thanks! > > I had some non-blocking comments that I'd ask you to consider along with > other comments you might receive. > > In 1.1. Purpose > > In particular, the mere presence of this header field SHOULD NOT be > construed as meaning that its data is valid, but, rather, that it is > reporting assertions made by one or more authentication schemes > applied somewhere upstream. > > This doesn't look like a 2119 SHOULD NOT to me ... are you saying > something like "the mere presence of this header field doesn't mean that > its data is valid"? > Yes, I'll calm the language down. I actually violated my own rule about having normative language in an introduction section. > > In 1.5.2. Security > > By contrast, DKIM is agnostic as to the routing > of a message but uses cryptographic signatures to authenticate agents > claim (some) responsibility for the message (which implies > authorization) and ensures that the listed portions of the message > were not modified in transit. > > This sentence isn't parsing for me. Missing word, perhaps? > Yep, already fixed in my copy. > > In 2.5.1. DKIM and DomainKeys > > neutral: The message was signed but the signature or signatures > contained syntax errors or were not otherwise able to be > processed. This result SHOULD also be used for other failures not > covered elsewhere in this list. > > I don't think this is an RFC 2119 SHOULD, but my larger point is, if you > encounter a failure that's not covered in this list, what other choice is > there? (Return no result? return the wrong result?) > It was "should" in the last one, upgraded on the grounds that "should" and "SHOULD" are actually the same thing. It's a little excessive since the listed values constitute the complete list, so we can just say this is the catch-all without the SHOULD (or even a MUST). > In 6.2. Email Authentication Method Name Registry > > Each method must register a name, the specification that defines it, > a version number associated with the method being registered > (preferably starting at "1"), > > this "preferably" is Mostly Harmless, but I'd think if the intent was to > avoiding confusing the reader, you'd be better off mandating that. > "Preferably" seems to say "you could *probably* trust that version 5 > isn't the first version, but you can't know that for certain". > Being a C coder, I was trying to allow for cases where someone wants to start versioning at 0. :-) > > A couple of paragraphs down, > > IANA is also requested to add a "version" field to all existing > registry entries. All current methods are to be recorded as version > "1". > > seems to mandate starting at "1" for existing methods, so I'm confused > why new methods might not begin with version '1'. > The methods currently in the registry all either don't have a version, or are explicitly version 1 anyway, so I believe this was a safe move. -MSK --f46d044517f76eb9bc04e11843d2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Jul 8, 2013 at 5:37 PM, Spencer Dawkins <spencerdawkins.ietf@gmail.com> wrote:

I found this specification clear and especially appreciated the context
in sections like Operational Guidance.

= Thanks!
=A0

I had some non-blocking comments that I'd ask you to consider along wit= h
other comments you might receive.

In 1.1. =A0Purpose

=A0 =A0In particular, the mere presence of this header field SHOULD NOT be<= br> =A0 =A0construed as meaning that its data is valid, but, rather, that it is=
=A0 =A0reporting assertions made by one or more authentication schemes
=A0 =A0applied somewhere upstream.

This doesn't look like a 2119 SHOULD NOT to me ... are you saying
something like "the mere presence of this header field doesn't mea= n that
its data is valid"?

Yes, I'll = calm the language down.=A0 I actually violated my own rule about having nor= mative language in an introduction section.
=A0

In 1.5.2. =A0Security

=A0 =A0By contrast, DKIM is agnostic as to the routing
=A0 =A0of a message but uses cryptographic signatures to authenticate agent= s
=A0 =A0claim (some) responsibility for the message (which implies
=A0 =A0authorization) and ensures that the listed portions of the message =A0 =A0were not modified in transit.

This sentence isn't parsing for me. Missing word, perhaps?

Yep, already fixed in my copy.
=A0

In 2.5.1. =A0DKIM and DomainKeys

=A0 =A0neutral: =A0The message was signed but the signature or signatures =A0 =A0 =A0 contained syntax errors or were not otherwise able to be
=A0 =A0 =A0 processed. =A0This result SHOULD also be used for other failure= s not
=A0 =A0 =A0 covered elsewhere in this list.

I don't think this is an RFC 2119 SHOULD, but my larger point is, if yo= u
encounter a failure that's not covered in this list, what other choice = is
there? (Return no result? return the wrong result?)
It was "should" in the last one, upgraded on the gro= unds that "should" and "SHOULD" are actually the same t= hing.=A0 It's a little excessive since the listed values constitute the= complete list, so we can just say this is the catch-all without the SHOULD= (or even a MUST).


In 6.2. =A0Email Authentication Method Name Registry

=A0 =A0Each method must register a name, the specification that defines it,=
=A0 =A0a version number associated with the method being registered
=A0 =A0(preferably starting at "1"),

this "preferably" is Mostly Harmless, but I'd think if the in= tent was to
avoiding confusing the reader, you'd be better off mandating that.
"Preferably" seems to say "you could *probably* trust that v= ersion 5
isn't the first version, but you can't know that for certain".=

Being a C coder, I was trying to allow= for cases where someone wants to start versioning at 0.=A0 :-)
=A0

A couple of paragraphs down,

=A0 =A0IANA is also requested to add a "version" field to all exi= sting
=A0 =A0registry entries. =A0All current methods are to be recorded as versi= on
=A0 =A0"1".

seems to mandate starting at "1" for existing methods, so I'm= confused
why new methods might not begin with version '1'.
<= div>
The methods currently in the registry all either don'= ;t have a version, or are explicitly version 1 anyway, so I believe this wa= s a safe move.

-MSK
--f46d044517f76eb9bc04e11843d2-- From presnick@qti.qualcomm.com Tue Jul 9 12:19:00 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64D6621F9C58; Tue, 9 Jul 2013 12:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PjLICORJbXhH; Tue, 9 Jul 2013 12:18:56 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id D843921F9C29; Tue, 9 Jul 2013 12:18:55 -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=1373397535; x=1404933535; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=P5sc+d7fAxcvbA7/1LxXgluTEDHQnTwy0UGjQV+elGw=; b=RN1r4g3x7dMi0Uz9zaXu6xdMa7RUI/XkEACtqMK6P63eYrcjiLuFQnLB G6N7Y+JCDiGiWcTRLPH5McvSuCQvE6R2fvCzefu64Eb79rbC5n6ZamRSU YBXk/Zd/kXJ9jbx9fg9EcysIwvqBz+p1lgrGrf2gtK28mGFUobTmpR/pL g=; X-IronPort-AV: E=Sophos;i="4.87,1029,1363158000"; d="scan'208";a="47067988" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by sabertooth01.qualcomm.com with ESMTP; 09 Jul 2013 12:18:55 -0700 Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 09 Jul 2013 12:18:54 -0700 Received: from presnick-mac.local (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.2.318.4; Tue, 9 Jul 2013 12:18:54 -0700 Message-ID: <51DC621B.6040808@qti.qualcomm.com> Date: Tue, 9 Jul 2013 14:18:51 -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: References: <20130708192433.5776.73625.idtracker@ietfa.amsl.com> <51DBDCB4.2030509@it.aoyama.ac.jp> <51DC4A77.4060609@dcrocker.net> In-Reply-To: <51DC4A77.4060609@dcrocker.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [172.30.39.5] Cc: apps-discuss@ietf.org, sm+ietf@elandsys.com, appsawg-chairs@tools.ietf.org, The IESG , draft-ietf-appsawg-rfc5451bis@tools.ietf.org Subject: Re: [apps-discuss] Abstract and Introduction X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jul 2013 19:19:00 -0000 On 7/9/13 12:37 PM, Dave Crocker wrote: > On 7/9/2013 2:49 AM, "Martin J. Dürst" wrote: >> On 2013/07/09 4:24, Pete Resnick wrote: >> >>> - Please repeat the Abstract as the first paragraph of the intro. >> >> No, please don't! > > Bad, Pete. Bad. Tsk. Tsk. Yeah, yeah. That'll teach me for doing the engineer thing I always complain about by suggesting solutions (and, I'll admit, a bad one in this case) when I haven't stated what my problem is. I shall rephrase (and update my comment to match): I found the first sentence of the introduction very abrupt and distracting from the purpose of the document. The mention of "the first version of this document" in the first sentence is anachronistic IMO. Please make the first sentence indicate something about the overall purpose of the document and *then* fall into the details. I'll get to the rest of Murray's replies in just a bit. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From superuser@gmail.com Tue Jul 9 12:43:22 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A49821F9E4B; Tue, 9 Jul 2013 12:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id biTpGAluXpdI; Tue, 9 Jul 2013 12:43:21 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC3321F9E52; Tue, 9 Jul 2013 12:43:21 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id e11so5072557wgh.18 for ; Tue, 09 Jul 2013 12:43: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=DuClTjeBzuH5sxR8tWkOQK+K+mGLOpLcrcePZfxWJLc=; b=u9ADoYFZduRD0YU4rNkRUDdbKD98+ynwoPPNr4bxacrnQ8s1R/Kps8iwZE/ZlKxWGU W0QSolu0xf0eu4q51cSgqXVVWgpCJc5J03k2ydYEva4ajBwTyBLxZxjbvYZwvmJPX4Kc Ejnk8Plha1SJOFQcvqkCbxzNAnlwuJHKKuOu+n2Hvt+QmMUXK1BqQrdzYqG4bAQZ2izC C2YLNjOKPqRN197kB0ySwzgPM0UbU1fzuiE1f6FH0uTe4O9tG5Jt20ga7tDxaqXAiGIp g+QcDXw1XpVSZJqP3rXJnkoL7IzdY9b3g7oogWpy4BCt7Ugsus9PYwrzA9bjs28XLN0h HsuA== MIME-Version: 1.0 X-Received: by 10.194.122.71 with SMTP id lq7mr15730610wjb.77.1373398999828; Tue, 09 Jul 2013 12:43:19 -0700 (PDT) Received: by 10.180.90.16 with HTTP; Tue, 9 Jul 2013 12:43:19 -0700 (PDT) In-Reply-To: <51DC621B.6040808@qti.qualcomm.com> References: <20130708192433.5776.73625.idtracker@ietfa.amsl.com> <51DBDCB4.2030509@it.aoyama.ac.jp> <51DC4A77.4060609@dcrocker.net> <51DC621B.6040808@qti.qualcomm.com> Date: Tue, 9 Jul 2013 12:43:19 -0700 Message-ID: From: "Murray S. Kucherawy" To: Pete Resnick Content-Type: multipart/alternative; boundary=089e012297508510a604e1195f78 Cc: IETF Apps Discuss , SM , "appsawg-chairs@tools.ietf.org" , Dave Crocker , draft-ietf-appsawg-rfc5451bis@tools.ietf.org, The IESG Subject: Re: [apps-discuss] Abstract and Introduction X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jul 2013 19:43:22 -0000 --089e012297508510a604e1195f78 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 9, 2013 at 12:18 PM, Pete Resnick wrote: > I found the first sentence of the introduction very abrupt and distracting > from the purpose of the document. The mention of "the first version of this > document" in the first sentence is anachronistic IMO. Please make the first > sentence indicate something about the overall purpose of the document and > *then* fall into the details. > > > Easy enough; I can just remove the "original document" reference, because I don't think it's actually necessary. The rest falls out nicely after some minor reshuffling. -MSK --089e012297508510a604e1195f78 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Jul 9, 2013 at 12:18 PM, Pete Resnick <pr= esnick@qti.qualcomm.com> wrote:
I found the first sentence of the introducti= on very abrupt and distracting from the purpose of the document. The mentio= n of "the first version of this document" in the first sentence i= s anachronistic IMO. Please make the first sentence indicate something abou= t the overall purpose of the document and *then* fall into the details.



Easy enough; I can just remove the= "original document" reference, because I don't think it'= s actually necessary.=A0 The rest falls out nicely after some minor reshuff= ling.

-MSK

--089e012297508510a604e1195f78-- From dhc@dcrocker.net Tue Jul 9 12:52:18 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C00EE11E8149; Tue, 9 Jul 2013 12:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.59 X-Spam-Level: X-Spam-Status: No, score=-6.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mmSUpVdlh5jr; Tue, 9 Jul 2013 12:52:12 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id A8E6911E8143; Tue, 9 Jul 2013 12:52:11 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r69Jq6U4008909 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 9 Jul 2013 12:52:10 -0700 Message-ID: <51DC69CF.70808@dcrocker.net> Date: Tue, 09 Jul 2013 12:51:43 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Pete Resnick References: <20130708192433.5776.73625.idtracker@ietfa.amsl.com> <51DBDCB4.2030509@it.aoyama.ac.jp> <51DC4A77.4060609@dcrocker.net> <51DC621B.6040808@qti.qualcomm.com> In-Reply-To: <51DC621B.6040808@qti.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Tue, 09 Jul 2013 12:52:10 -0700 (PDT) Cc: draft-ietf-appsawg-rfc5451bis@tools.ietf.org, appsawg-chairs@tools.ietf.org, The IESG , apps-discuss@ietf.org Subject: Re: [apps-discuss] Abstract and Introduction X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 19:52:21 -0000 On 7/9/2013 12:18 PM, Pete Resnick wrote: > I found the first sentence of the introduction very abrupt and > distracting from the purpose of the document. The mention of "the first > version of this document" in the first sentence is anachronistic IMO. > Please make the first sentence indicate something about the overall > purpose of the document and *then* fall into the details. Oh. Well, yeah. That's certainly worth changing. More generally, we need "The Elements of IETF Specification Style". d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From barryleiba@gmail.com Tue Jul 9 13:32:22 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 830D621F9D0F; Tue, 9 Jul 2013 13:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.987 X-Spam-Level: X-Spam-Status: No, score=-101.987 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3wYwCa8f7-OR; Tue, 9 Jul 2013 13:32:22 -0700 (PDT) Received: from mail-qe0-x233.google.com (mail-qe0-x233.google.com [IPv6:2607:f8b0:400d:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 018EE21F99C5; Tue, 9 Jul 2013 13:32:21 -0700 (PDT) Received: by mail-qe0-f51.google.com with SMTP id a11so3297519qen.38 for ; Tue, 09 Jul 2013 13:32:21 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=3lZWcvx7WOwzzsAjVi/29i3Ik9EfcH+qX3YoqyizzO4=; b=HzHD2ngzTYWFNidqEZYfPJf4Fb2/j7TnxY+mxcn7QsiC42EOADlY9etiJaGzu9aoOT UIcqTk0LpK8YpzNaAyxtSv6iWixhKCa87npPYNLOZ9HzCCyt+FyC00k/dGXVd+4U4iDq D17hLkqJDCkxmaNKw0rCYw3+7cdDe8F8qU1zXdJPvTvfCVUZ5E6ZY6lhphgAr7UX/StX BrVRq9l7nlW4eB54WhR1Jnd/rVFRm9KmVvm3O+O6SFjC2rMdsD22zorT6cnji5TQGBvE OuRTHz8eGlhJ/KGwZHoYqlMbUmjcqWdJ1sBCws2+ingVnLKb6pG28a7MWghBD0tOLEDp zaLA== MIME-Version: 1.0 X-Received: by 10.224.4.133 with SMTP id 5mr25244539qar.109.1373401941453; Tue, 09 Jul 2013 13:32:21 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.224.216.201 with HTTP; Tue, 9 Jul 2013 13:32:21 -0700 (PDT) In-Reply-To: References: <20130709165340.8692.20830.idtracker@ietfa.amsl.com> Date: Tue, 9 Jul 2013 16:32:21 -0400 X-Google-Sender-Auth: 75AmHmIrPeAOhxpooL4vyF-qPpc Message-ID: From: Barry Leiba To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=001a11c22108daafba04e11a0e85 Cc: "draft-ietf-appsawg-rfc5451bis@tools.ietf.org" , "appsawg-chairs@tools.ietf.org" , The IESG , IETF Apps Discuss , SM Subject: Re: [apps-discuss] Stephen Farrell's No Objection on draft-ietf-appsawg-rfc5451bis-09: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jul 2013 20:32:22 -0000 --001a11c22108daafba04e11a0e85 Content-Type: text/plain; charset=ISO-8859-1 Re: Section 7: > A question to the IESG: Should I take that out since this is falling back to PS, or leave it > in? It won't be there when the request comes to advance this to IS in 6-12 months. Leave it. It already asks the RFC Editor to remove it, and when it comes back around again later we can refer to the section in the archived draft. Barry --001a11c22108daafba04e11a0e85 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Re: Section 7:
>=A0A question to the IESG: Should I take that out= since this is falling back to PS, or leave it
&= gt;=A0in?=A0 It won't be there when the request comes to advance this t= o IS in 6-12 months.

Leave it. =A0It already asks = the RFC Editor to remove it, and when it comes back around again later we c= an refer to the section in the archived draft.

Barry

--001a11c22108daafba04e11a0e85-- From superuser@gmail.com Tue Jul 9 15:27:53 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2FD811E8190; Tue, 9 Jul 2013 15:27:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7DTfNev8e97X; Tue, 9 Jul 2013 15:27:51 -0700 (PDT) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 63CA411E8191; Tue, 9 Jul 2013 15:27:50 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id p60so5182340wes.41 for ; Tue, 09 Jul 2013 15:27:49 -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=Tu4Mn7wMm2V9sRRdkFolmg9NNinc3QgZpJRKqXWB8Og=; b=bf9k6ax5RSeMKJAHo8EH77E4Tz6a06sn/PAUDf9qPeFRRWVd+rdblVQaSqrDdhyZdb mol6fDnxwj9wrjGR4aVTNTuvl3cf6aNZrFPTsqdNVtWagvPGmXDG/ES1PRNBQrE6Em7i bsIvPyRQv23/I75UM6+YJ3u365TBS4SpADhXSgm5dWMDONHNpkEtYHnikvCS0P3jjJG1 ZMwyoVIKhQR7Pom1n4I4jeqZs7rzVlAzki+jT40DR/RYwWW1uhNT8IrggNg9Ay16fJIn IHjAp+9Hvi50aRO+tqXxC1qurNrLcy62M62kiCkcbxuYem5iSb7AIaM03DTh0C0vlLRy zU3w== MIME-Version: 1.0 X-Received: by 10.180.187.17 with SMTP id fo17mr15539044wic.60.1373408869480; Tue, 09 Jul 2013 15:27:49 -0700 (PDT) Received: by 10.180.90.16 with HTTP; Tue, 9 Jul 2013 15:27:49 -0700 (PDT) In-Reply-To: <51DC8257.6010202@gmail.com> References: <20130709003704.15548.41553.idtracker@ietfa.amsl.com> <51DC8257.6010202@gmail.com> Date: Tue, 9 Jul 2013 15:27:49 -0700 Message-ID: From: "Murray S. Kucherawy" To: Spencer Dawkins Content-Type: multipart/alternative; boundary=001a11c26a5ecc018404e11bab13 Cc: draft-ietf-appsawg-rfc5451bis@tools.ietf.org, "appsawg-chairs@tools.ietf.org" , The IESG , IETF Apps Discuss , SM Subject: Re: [apps-discuss] Spencer Dawkins' No Objection on draft-ietf-appsawg-rfc5451bis-09: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jul 2013 22:27:53 -0000 --001a11c26a5ecc018404e11bab13 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 9, 2013 at 2:36 PM, Spencer Dawkins < spencerdawkins.ietf@gmail.com> wrote: > If we're tracking each other, I agree with what you're doing (setting > everything that's not explicit to the same origin). > > That's why I was more confused when you have what looks like a uniform > situation now, but people can pick some random integer for the first > version number on new methods. > > If you tell me that the mismatch doesn't matter, because no one will > assume anything about version number '1' being the first version without > checking, I'll believe you, but I'll silently and non-blockingly wonder why > you preferred starting with "1". > > Does that make sense? > > Yep. And yes, I don't think it matters. The question in a consumer of this field will be "Do I understand the specific version I see in the header field?" The IANA registry is mainly a mapping of version numbers to specification documents. If new method "foobar" appears and wants to start versioning at 0, there's no reason it can't. I did the "set the current things at 1" only because they all actually are 1 (in DKIM keys, it's "v=DKIM1"; in SPF, it's "v=spf1"; etc.), and I need to populate the new column in the IANA registry with something. -MSK --001a11c26a5ecc018404e11bab13 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Jul 9, 2013 at 2:36 PM, Spencer Dawkins <spencerdawkins.ietf@gmail.com> wrote:
=20 =20 =20
If we're tracking each othe= r, I agree with what you're doing (setting everything that's not explicit to the same origin).

That's why I was more confused when you have what looks like a uniform situation now, but people can pick some random integer for the first version number on new methods.

If you tell me that the mismatch doesn't matter, because no one wil= l assume anything about version number '1' being the first versio= n without checking, I'll believe you, but I'll silently and non-blockingly wonder why you preferred starting with "1".
Does that make sense?

Yep.=A0 And yes, = I don't think it matters.=A0 The question in a consumer of this field w= ill be "Do I understand the specific version I see in the header field= ?"=A0 The IANA registry is mainly a mapping of version numbers to spec= ification documents.=A0 If new method "foobar" appears and wants = to start versioning at 0, there's no reason it can't.=A0 I did the = "set the current things at 1" only because they all actually are = 1 (in DKIM keys, it's "v=3DDKIM1"; in SPF, it's "v= =3Dspf1"; etc.), and I need to populate the new column in the IANA reg= istry with something.

-MSK

--001a11c26a5ecc018404e11bab13-- From johnl@iecc.com Tue Jul 9 16:15:50 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7AFE21F9B53 for ; Tue, 9 Jul 2013 16:15:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.683 X-Spam-Level: X-Spam-Status: No, score=-110.683 tagged_above=-999 required=5 tests=[AWL=0.516, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yc2UWywF3Wym for ; Tue, 9 Jul 2013 16:15:46 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 48CFC21F8201 for ; Tue, 9 Jul 2013 16:15:45 -0700 (PDT) Received: (qmail 25431 invoked from network); 9 Jul 2013 23:15:45 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 9 Jul 2013 23:15:45 -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=51dc99a1.xn--btvx9d.k1307; i=johnl@user.iecc.com; bh=x7EVao4gFGzLlv21X/8cH8vyEjC1P6KIeYhZLOxDpRk=; b=VdsWlAZVoSPRfPwIMy8FrTH1DxaDb8hzvzIQ7WPXk8ixAnvll/LBStXPYs9ylUwgy6pYrSwkz+8c85xp3YhXsAZb48EgrhABB2Y8EsU+GX3UxJ0Qdnauih8zJga84k7z/i8N1jCY7LBEMa5NB3TOs14pKpPMGX0iruxM9gaPJbjQv/0k0pzAZeH7y7dW7scIUWouJFOaTw5TZWNEv6C+FhIAwxbzul8kywDca9yeoef2C7yoSptby8HxfyK6Dopx 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=51dc99a1.xn--btvx9d.k1307; olt=johnl@user.iecc.com; bh=x7EVao4gFGzLlv21X/8cH8vyEjC1P6KIeYhZLOxDpRk=; b=IjJs/KNSmNobQVy6VD1ZLAk5SX6jXonxLeFffOP2M4txbJR7YJ1FuozQlWxL7UQHdAteB2hFQ0xysXehI1jMnWbGQclEK17k2ibM9I5pveOSHA2nOmcyvj0h610BjKZ6OAimI8jgrEdhKQLKhPzjl88TEYHVO9wVEBqKGSt9C6HCvxJxLjMS/YNgun2r+t4P6pB6xwkbB/CJ03YUmaENIQdrfaFE9fyAV0xgWqZE7nm9a/u5PQekZtfWz4quONdp Date: 9 Jul 2013 23:15:23 -0000 Message-ID: <20130709231523.32969.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <51DC69CF.70808@dcrocker.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Cc: dcrocker@bbiw.net Subject: Re: [apps-discuss] Abstract and Introduction X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jul 2013 23:15:50 -0000 >More generally, we need "The Elements of IETF Specification Style". ... 6) Omit needless paragraphs. From dhc@dcrocker.net Tue Jul 9 18:22:08 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7A8921F9C10 for ; Tue, 9 Jul 2013 18:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.591 X-Spam-Level: X-Spam-Status: No, score=-6.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TR-ze+IEDhi8 for ; Tue, 9 Jul 2013 18:22:03 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA4521F9C11 for ; Tue, 9 Jul 2013 18:22:00 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r6A1LtXb014283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 9 Jul 2013 18:21:59 -0700 Message-ID: <51DCB71C.9060302@dcrocker.net> Date: Tue, 09 Jul 2013 18:21:32 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: John Levine References: <20130709231523.32969.qmail@joyce.lan> In-Reply-To: <20130709231523.32969.qmail@joyce.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Tue, 09 Jul 2013 18:21:59 -0700 (PDT) Cc: dcrocker@bbiw.net, apps-discuss@ietf.org Subject: Re: [apps-discuss] Abstract and Introduction X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 01:22:08 -0000 On 7/9/2013 4:15 PM, John Levine wrote: >> More generally, we need "The Elements of IETF Specification Style". > > ... > > 6) Omit needless paragraphs. 5) Write normative text that specifies clear, objective criteria and clear, objective actions. This will preclude directives such as 6. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From ned.freed@mrochek.com Tue Jul 9 18:53:51 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF5E11E80EC; Tue, 9 Jul 2013 18:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xqdANwqA802R; Tue, 9 Jul 2013 18:53:45 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 292EB11E80BA; Tue, 9 Jul 2013 18:53:43 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OVTJBU4ZHC007V71@mauve.mrochek.com>; Tue, 9 Jul 2013 18:48:39 -0700 (PDT) MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=iso-8859-1; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OVSE5EX97K000054@mauve.mrochek.com>; Tue, 9 Jul 2013 18:48:36 -0700 (PDT) Message-id: <01OVTJBSLHUG000054@mauve.mrochek.com> Date: Tue, 09 Jul 2013 18:38:41 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 09 Jul 2013 10:37:59 -0700" <51DC4A77.4060609@dcrocker.net> References: <20130708192433.5776.73625.idtracker@ietfa.amsl.com> <51DBDCB4.2030509@it.aoyama.ac.jp> <51DC4A77.4060609@dcrocker.net> To: Dave Crocker Cc: apps-discuss@ietf.org, Pete Resnick , sm+ietf@elandsys.com, appsawg-chairs@tools.ietf.org, The IESG , draft-ietf-appsawg-rfc5451bis@tools.ietf.org Subject: Re: [apps-discuss] Abstract and Introduction X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jul 2013 01:53:52 -0000 > On 7/9/2013 2:49 AM, "Martin J. Dürst" wrote: > > On 2013/07/09 4:24, Pete Resnick wrote: > >> Pete Resnick has entered the following ballot position for > >> draft-ietf-appsawg-rfc5451bis-09: Discuss > > > >> ---------------------------------------------------------------------- > >> COMMENT: > >> ---------------------------------------------------------------------- > >> > >> 1: > >> > >> - Please repeat the Abstract as the first paragraph of the intro. Some > >> folks don't read abstracts. > > > > No, please don't! There are plenty of folks who read both abstract and > > introduction, and it's really annoying to read the same thing twice. > +10 +10 as well. > It's worse than Martin has said. > The job of an Abstract is quite different from the job of the first > paragraph of an Introduction. It most certainly is. > The purpose of an abstract is to market the document to potential > readers. It must, therefore, operate as a standalone precis of the > document. Hence, an Abstract must summarize the nature of the document. > In the case of IETF specifications, this typically means summarizing > the problem, possibly summarizing the factors affecting solution > efforts, and give some indication of the solution approach. This problem is exacerbated to a great degree by the ready availability of RFCs. Any time the abstract doesn't suffice to describe the document you can readily access the document itself, so why bother? It's not like the rest of the document is behind a paywall, as it so often is for stuff published in academic journals, right? Except this is sloppy thinking leading to sloppy documents. It's a question of scale. Not everyone is focused on RFCs like we are. For many if not most readers RFCs are a small part of the material they consume. And those folks aren't going to pull the whole document and wade through it, even though it's easy enough to do. The abstract really does need to stand alone. This, BTW, is why stuff like "This document obsoletes this other document you could not care less about" has no business being in an abstract. > The first paragraph of an Introduction can take a variety of > perspectives, since it is only the first of a number of paragraphs in > only the first of a number of sections. Typically, the first paragraph > sets the stage for the operational environment, or it sets the stage > form the problems within that environment. This covers only a small > part of the scope of an Abstract. My advice, from having written a lot of these things, is to not even try to write the abstract until the document is fully formed. Up to that point you can simply have something like "this document specifies the foo protocol for frobbing globules" in there. > ps. To make matters a bit confusing, the first paragraph of a /charter/ > is supposed to operate as an abstract/marketing-blurb for a working > group, since that paragraph is circulated independent of the rest of the > charter, as part of the wg announcement. Unfortunately, that > requirement is never enforced. Good point. Ned From mnot@mnot.net Tue Jul 9 22:31:03 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B37521F9BB1 for ; Tue, 9 Jul 2013 22:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.067 X-Spam-Level: X-Spam-Status: No, score=-105.067 tagged_above=-999 required=5 tests=[AWL=-2.468, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mijJMTq-C9Fe for ; Tue, 9 Jul 2013 22:30:59 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id C0F2621F9BEC for ; Tue, 9 Jul 2013 22:30:54 -0700 (PDT) Received: from [192.168.1.80] (unknown [118.209.175.91]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 0DA32509B5; Wed, 10 Jul 2013 01:30:43 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Mark Nottingham In-Reply-To: <8ee3a48c1d3c44eb5bba7b08b3f77579@michielbdejong.com> Date: Wed, 10 Jul 2013 15:30:39 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6BC44D72-BAA1-41B6-BFE8-9FD7A9D4CECF@mnot.net> <8ee3a48c1d3c44eb5bba7b08b3f77579@michielbdejong.com> To: Michiel B. de Jong X-Mailer: Apple Mail (2.1508) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Non-proprietary sync (was Re: Is e-mail going to die? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jul 2013 05:31:03 -0000 On 06/07/2013, at 2:49 AM, Michiel B. de Jong = wrote: > Hi Mark, >=20 > On 2013-07-04 07:34, Mark Nottingham wrote: >> Hi Michiel, >>=20 >> I'm very interested in this area; I think we need open standards here >> desperately. >=20 > Great! >=20 >> I potentially have a lot of feedback for you (both editorial and more >> substantial), but wanted to first know: what is the remoteStorage >> community's intent in publishing this draft? >=20 > we hadn't really formulated that until now, so we had a little = discussion about it; we didn't entirely finish discussing it yet, but = overall i think most of us agree that the ietf would probably be the = right platform for developing the idea of remoteStorage further. >=20 > we started working on this spec as an open source project because we = identified a need for one - its development so far was partially = financed by donations, partially by people donating their time. >=20 > It's of course scary to give up control over something we care so much = about, but we also trust the ietf would do a better job at guarding the = public's best interest than our small community of quite inexperienced = volunteers. :) Great. >> I.e., do you think you're nearly done, and just need to publish a >> specification? >=20 > it's becoming quite crystallized within its very limited defined set = of features. you can get an idea of what we consider outstanding issues = by browsing https://github.com/remotestorage/spec/issues our current = process is to go through that list twice a year, and see which of those = issues merit a text change. we are trying to change as little as = possible each time, to avoid an entropy walk into feature bloat. :) Sounds very reasonable. >> Are you willing to consider substantial changes to the >> specification, even if it breaks your current implementations if >> there's good reason? >=20 > yes, we do this every 6 months anyway. what type of changes did you = have in mind? >=20 > so far, even though these are themes that continuously come up as = requests, we have resisted adding for instance: > - byte ranges on GET (and PUT?) requests, > - query parameters like sorting/filtering/paging, > - access control lists, > - long polling and/or other sorts of changes-feeds > - retrieving the historic revision history of a certain document (as = well as undo/rollback) > - atomic transactions > - etc. >=20 > this way, we try to keep the job of the server as simple as possible. >=20 >>=20 >> Also, what kind of timeline are you on -- i.e., do you have >> particular milestones you want to hit? >=20 > we try to go as fast as we can, developing the remotestorage.js client = library for it, data formats for the things we want to store on there, = try to work out how to structure data into folders so that it's easy to = fetch later, write apps that use it, and server implementations that are = compliant with it, with (if you add up the volunteers) about 3 full-time = people. that's our main constraint. :) >=20 > we have been trying to make breaking changes only twice a year, = although we're probably going to have to disobey that self-imposed rule = soon anyway because of a critical bug we found this week. OK. >> Finally, what's the preferred venue for feedback and discussion? >=20 > currently it's a combination of = https://github.com/remotestorage/spec/issues and = http://remotestorage.io/community/ but we're open to changing that to = the apps-discuss mailinglist for instance? do you think that would be = appropriate? I think on the community site is fine for now; if it becomes a bigger = effort, or traffic is too great, you could either create a separate = mailing list, or move to an IETF list. YMMV, of course. >> Will >> you or anyone else from remoteStorage be coming to the Berlin = meeting? >=20 > i live in Berlin, and given our project's tight budget, i hadn't = bought a ticket yet. but if there is a possibility to chat about = remoteStorage with you and/or other people there, then i'll definitely = get one for both the meeting and the newcomer event! :) That would be great. However, it might be premature for you to register = to attend, since there won't be any time scheduled to discuss the draft = at a meeting (AFAIK - APPSAWG chairs?).=20 So, it might be better to arrange a "Bar BoF" (i.e., informal meeting) = for folks who are interested to discuss this; registration isn't = necessary for that (as it often occurs in a bar or similar space). Even = if that doesn't happen, I'd love to talk over a coffee. This might also be helpful, FWIW: http://www.ietf.org/tao.html > can say roughly in which areas you would propose changing the draft? Let me get my thoughts together and write something down; sorry, it = might take a while (both HTTP and moving house are keeping me busy right = now). Cheers, -- Mark Nottingham http://www.mnot.net/ From anything@michielbdejong.com Wed Jul 10 02:59:51 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2A6211E810F for ; Wed, 10 Jul 2013 02:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.872 X-Spam-Level: X-Spam-Status: No, score=-2.872 tagged_above=-999 required=5 tests=[AWL=-0.425, BAYES_00=-2.599, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ulLy+kfDNZN9 for ; Wed, 10 Jul 2013 02:59:45 -0700 (PDT) Received: from slow1-d.mail.gandi.net (slow1-d.mail.gandi.net [217.70.178.86]) by ietfa.amsl.com (Postfix) with ESMTP id 984D011E8119 for ; Wed, 10 Jul 2013 02:59:45 -0700 (PDT) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) by slow1-d.mail.gandi.net (Postfix) with ESMTP id 68C7A535474 for ; Wed, 10 Jul 2013 11:58:13 +0200 (CEST) Received: from mfilter9-d.gandi.net (mfilter9-d.gandi.net [217.70.178.138]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id 1F18D41C06A; Wed, 10 Jul 2013 11:57:48 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter9-d.gandi.net Received: from relay5-d.mail.gandi.net ([217.70.183.197]) by mfilter9-d.gandi.net (mfilter9-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id YrhHj-CE5uom; Wed, 10 Jul 2013 11:57:46 +0200 (CEST) X-Originating-IP: 10.58.1.142 Received: from webmail.gandi.net (unknown [10.58.1.142]) (Authenticated sender: anything@michielbdejong.com) by relay5-d.mail.gandi.net (Postfix) with ESMTPA id AE36541C06B; Wed, 10 Jul 2013 11:57:46 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 10 Jul 2013 11:57:46 +0200 From: "Michiel B. de Jong" To: Mark Nottingham In-Reply-To: References: <6BC44D72-BAA1-41B6-BFE8-9FD7A9D4CECF@mnot.net> <8ee3a48c1d3c44eb5bba7b08b3f77579@michielbdejong.com> Message-ID: X-Sender: anything@michielbdejong.com User-Agent: Roundcube Webmail/0.7.2 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] =?utf-8?q?Non-proprietary_sync_=28was_Re=3A_Is_e-m?= =?utf-8?q?ail_going_to_die=3F?= X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jul 2013 09:59:52 -0000 On 2013-07-10 07:30, Mark Nottingham wrote: > it might be better to arrange a "Bar BoF" (i.e., informal > meeting) for folks who are interested to discuss this; registration > isn't necessary for that (as it often occurs in a bar or similar > space). Even if that doesn't happen, I'd love to talk over a coffee. ok, great! yes, let's do that then. > Let me get my thoughts together and write something down; sorry, it > might take a while (both HTTP and moving house are keeping me busy > right now). awesome, thanks! :) Cheers, Michiel From paul.hoffman@vpnc.org Wed Jul 10 07:03:20 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71A0C11E8194 for ; Wed, 10 Jul 2013 07:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9YFNIi2B4K8 for ; Wed, 10 Jul 2013 07:03:20 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id BFAE911E818A for ; Wed, 10 Jul 2013 07:03:19 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-228.dsl.dynamic.sonic.net [50.1.98.228]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.5) with ESMTP id r6AE3IvQ037555 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 10 Jul 2013 07:03:19 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: Date: Wed, 10 Jul 2013 07:03:19 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6BC44D72-BAA1-41B6-BFE8-9FD7A9D4CECF@mnot.net> <8ee3a48c1d3c44eb5bba7b08b3f77579@michielbdejong.com> To: "Michiel B. de Jong" X-Mailer: Apple Mail (2.1508) Cc: "apps-discuss@ietf.org Discuss" Subject: [apps-discuss] Possible bar BoF / side meeting on non-proprietary sync X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jul 2013 14:03:20 -0000 On Jul 10, 2013, at 2:57 AM, Michiel B. de Jong = wrote: > On 2013-07-10 07:30, Mark Nottingham wrote: >> it might be better to arrange a "Bar BoF" (i.e., informal >> meeting) for folks who are interested to discuss this; registration >> isn't necessary for that (as it often occurs in a bar or similar >> space). Even if that doesn't happen, I'd love to talk over a coffee. >=20 > ok, great! yes, let's do that then. When you decide a time and place for the informal meeting, by all means = send a message to this list; others here would be interested as well. --Paul Hoffman= From dhc@dcrocker.net Wed Jul 10 07:15:50 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D44C421F8FA1; Wed, 10 Jul 2013 07:15:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.592 X-Spam-Level: X-Spam-Status: No, score=-6.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UtN5oXhmgyNq; Wed, 10 Jul 2013 07:15:45 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 62F6321F92C2; Wed, 10 Jul 2013 07:15:29 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r6AEFC4O027719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 10 Jul 2013 07:15:15 -0700 Message-ID: <51DD6C57.10803@dcrocker.net> Date: Wed, 10 Jul 2013 07:14:47 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Ned Freed References: <20130708192433.5776.73625.idtracker@ietfa.amsl.com> <51DBDCB4.2030509@it.aoyama.ac.jp> <51DC4A77.4060609@dcrocker.net> <01OVTJBSLHUG000054@mauve.mrochek.com> In-Reply-To: <01OVTJBSLHUG000054@mauve.mrochek.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Wed, 10 Jul 2013 07:15:16 -0700 (PDT) Cc: apps-discuss@ietf.org, Pete Resnick , sm+ietf@elandsys.com, appsawg-chairs@tools.ietf.org, The IESG , draft-ietf-appsawg-rfc5451bis@tools.ietf.org Subject: Re: [apps-discuss] Abstract and Introduction X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 14:15:51 -0000 On 7/9/2013 6:38 PM, Ned Freed wrote: >> The purpose of an abstract is to market the document to potential >> readers. ... > This problem is exacerbated to a great degree by the ready availability > of RFCs. ... > Except this is sloppy thinking leading to sloppy documents. It's a > question of > scale. Not everyone is focused on RFCs like we are. I think this issue is worth pressing a bit further. (And this is only meant to augment Ned's note; I agree strongly with all of his points.) I classed the issue as 'marketing' because the important role of an abstract is to help potential readers to decide whether to become actual readers. In the real world of the web, folks who worry about usability of web pages worry quite a bit about key clicks and minimizing them. Extra key clicks lose users. No single key click seems to cost much, but there's a real behavioral barrier. So while yes, the real document is "only" a key-click away, that's actually quite far. On the average, much of the work in the IETF is executed with other IETFers in mind, rather than with non-IETFers in mind. An abstract is meant for someone who is not already likely to read the document. It should be written with a pedagogy targeting that sort of market. And there's an extra benefit in such writing. An ability to write a good capsule summary of the document tends to require a good understanding of what's important about it and that often requires some careful thought. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From spencerdawkins.ietf@gmail.com Mon Jul 8 17:37:05 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE9D11E80F2; Mon, 8 Jul 2013 17:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ToDeTkEWkfbp; Mon, 8 Jul 2013 17:37:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B5C8E11E80E6; Mon, 8 Jul 2013 17:37:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Spencer Dawkins" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130709003704.15548.41553.idtracker@ietfa.amsl.com> Date: Mon, 08 Jul 2013 17:37:04 -0700 X-Mailman-Approved-At: Wed, 10 Jul 2013 09:32:16 -0700 Cc: draft-ietf-appsawg-rfc5451bis@tools.ietf.org, appsawg-chairs@tools.ietf.org, sm+ietf@elandsys.com, apps-discuss@ietf.org Subject: [apps-discuss] Spencer Dawkins' No Objection on draft-ietf-appsawg-rfc5451bis-09: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jul 2013 00:37:05 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-appsawg-rfc5451bis-09: 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. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I am sympathetic to Pete's DISCUSS on advancing to full standard while making incompatible changes, but I'll let you folks hash that out - it wouldn't affect my ballot position either way. I found this specification clear and especially appreciated the context in sections like Operational Guidance. I had some non-blocking comments that I'd ask you to consider along with other comments you might receive. In 1.1. Purpose In particular, the mere presence of this header field SHOULD NOT be construed as meaning that its data is valid, but, rather, that it is reporting assertions made by one or more authentication schemes applied somewhere upstream. = This doesn't look like a 2119 SHOULD NOT to me ... are you saying something like "the mere presence of this header field doesn't mean that its data is valid"? In 1.5.2. Security By contrast, DKIM is agnostic as to the routing of a message but uses cryptographic signatures to authenticate agents claim (some) responsibility for the message (which implies authorization) and ensures that the listed portions of the message were not modified in transit. = This sentence isn't parsing for me. Missing word, perhaps? In 2.5.1. DKIM and DomainKeys neutral: The message was signed but the signature or signatures contained syntax errors or were not otherwise able to be processed. This result SHOULD also be used for other failures not covered elsewhere in this list. I don't think this is an RFC 2119 SHOULD, but my larger point is, if you encounter a failure that's not covered in this list, what other choice is there? (Return no result? return the wrong result?) In 6.2. Email Authentication Method Name Registry Each method must register a name, the specification that defines it, a version number associated with the method being registered (preferably starting at "1"), = this "preferably" is Mostly Harmless, but I'd think if the intent was to avoiding confusing the reader, you'd be better off mandating that. "Preferably" seems to say "you could *probably* trust that version 5 isn't the first version, but you can't know that for certain". A couple of paragraphs down, = IANA is also requested to add a "version" field to all existing registry entries. All current methods are to be recorded as version "1". seems to mandate starting at "1" for existing methods, so I'm confused why new methods might not begin with version '1'. From spencerdawkins.ietf@gmail.com Tue Jul 9 14:37:25 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC29F11E8173; Tue, 9 Jul 2013 14:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8AA1qkJvDPKG; Tue, 9 Jul 2013 14:37:25 -0700 (PDT) Received: from mail-oa0-x22b.google.com (mail-oa0-x22b.google.com [IPv6:2607:f8b0:4003:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 5FBE511E816F; Tue, 9 Jul 2013 14:37:16 -0700 (PDT) Received: by mail-oa0-f43.google.com with SMTP id i7so8694317oag.16 for ; Tue, 09 Jul 2013 14:37:15 -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 :references:in-reply-to:content-type; bh=AgEibtrC2jNwbanExoTwjNDWDOYwe5QbNnQTh67AhY0=; b=BvsY+aN40i6MtT1/k21iQL7GVS0eXWqGHfrmD1TO6qS4mk7vWK/b57o5jyAzy6z/jS lqazNCnd0q54JqZvymEy7vGNmg7t/eCl2KJdncvhpt5wBsKNcV3ezWWP0NN+C4J8QqOz rmoQcO70f0MyKwNloelwUfzXnmqq9jCKUle1GY6nbiW8F2KX6KqeiGKVBeyeCzRl1bZ1 GiDBH9AoyyBQaF8APB2FDN9WWF7u7S0m9L+RWi9Bn6XXQLAWoqInWKGLv5gTgaYzP7V3 1Jhv+EO0paX6yChf/Lf2bM/Kj1lmNTarfY0mPsnM0k7+QowHRj4MhdCFYl419S3FuHWo mS+w== X-Received: by 10.182.225.134 with SMTP id rk6mr25662782obc.40.1373405835853; Tue, 09 Jul 2013 14:37:15 -0700 (PDT) Received: from [192.168.1.77] (99-108-174-213.lightspeed.rcsntx.sbcglobal.net. [99.108.174.213]) by mx.google.com with ESMTPSA id z10sm35988348obl.13.2013.07.09.14.37.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Jul 2013 14:37:15 -0700 (PDT) Message-ID: <51DC8257.6010202@gmail.com> Date: Tue, 09 Jul 2013 16:36:23 -0500 From: Spencer Dawkins User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <20130709003704.15548.41553.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090307020804050802000505" X-Mailman-Approved-At: Wed, 10 Jul 2013 09:32:17 -0700 Cc: IETF Apps Discuss , SM , "appsawg-chairs@tools.ietf.org" , Spencer Dawkins , draft-ietf-appsawg-rfc5451bis@tools.ietf.org, The IESG Subject: Re: [apps-discuss] Spencer Dawkins' No Objection on draft-ietf-appsawg-rfc5451bis-09: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jul 2013 21:37:26 -0000 This is a multi-part message in MIME format. --------------090307020804050802000505 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 7/9/2013 1:23 PM, Murray S. Kucherawy wrote: > On Mon, Jul 8, 2013 at 5:37 PM, Spencer Dawkins > > > wrote: Hi, Murry, Thanks for the quick response! I had one point I should ask more clearly ... > > In 6.2. Email Authentication Method Name Registry > > Each method must register a name, the specification that > defines it, > a version number associated with the method being registered > (preferably starting at "1"), > > this "preferably" is Mostly Harmless, but I'd think if the intent > was to > avoiding confusing the reader, you'd be better off mandating that. > "Preferably" seems to say "you could *probably* trust that version 5 > isn't the first version, but you can't know that for certain". > > > Being a C coder, I was trying to allow for cases where someone wants > to start versioning at 0. :-) Having started as an APL coder, I appreciate that :-) > A couple of paragraphs down, > > IANA is also requested to add a "version" field to all existing > registry entries. All current methods are to be recorded as > version > "1". > > seems to mandate starting at "1" for existing methods, so I'm confused > why new methods might not begin with version '1'. > > > The methods currently in the registry all either don't have a version, > or are explicitly version 1 anyway, so I believe this was a safe move. If we're tracking each other, I agree with what you're doing (setting everything that's not explicit to the same origin). That's why I was more confused when you have what looks like a uniform situation now, but people can pick some random integer for the first version number on new methods. If you tell me that the mismatch doesn't matter, because no one will assume anything about version number '1' being the first version without checking, I'll believe you, but I'll silently and non-blockingly wonder why you preferred starting with "1". Does that make sense? Spencer --------------090307020804050802000505 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 7/9/2013 1:23 PM, Murray S. Kucherawy wrote:
On Mon, Jul 8, 2013 at 5:37 PM, Spencer Dawkins <spencerdawkins.ietf@gmail.com> wrote:

Hi, Murry,

Thanks for the quick response! I had one point I should ask more clearly ...


In 6.2.  Email Authentication Method Name Registry

   Each method must register a name, the specification that defines it,
   a version number associated with the method being registered
   (preferably starting at "1"),

this "preferably" is Mostly Harmless, but I'd think if the intent was to
avoiding confusing the reader, you'd be better off mandating that.
"Preferably" seems to say "you could *probably* trust that version 5
isn't the first version, but you can't know that for certain".

Being a C coder, I was trying to allow for cases where someone wants to start versioning at 0.  :-)

Having started as an APL coder, I appreciate that :-)

A couple of paragraphs down,

   IANA is also requested to add a "version" field to all existing
   registry entries.  All current methods are to be recorded as version
   "1".

seems to mandate starting at "1" for existing methods, so I'm confused
why new methods might not begin with version '1'.

The methods currently in the registry all either don't have a version, or are explicitly version 1 anyway, so I believe this was a safe move.

If we're tracking each other, I agree with what you're doing (setting everything that's not explicit to the same origin).

That's why I was more confused when you have what looks like a uniform situation now, but people can pick some random integer for the first version number on new methods.

If you tell me that the mismatch doesn't matter, because no one will assume anything about version number '1' being the first version without checking, I'll believe you, but I'll silently and non-blockingly wonder why you preferred starting with "1".

Does that make sense?

Spencer
--------------090307020804050802000505-- From spencerdawkins.ietf@gmail.com Tue Jul 9 15:39:03 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0603211E8181; Tue, 9 Jul 2013 15:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HtgGLfrrXDbO; Tue, 9 Jul 2013 15:39:02 -0700 (PDT) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 5395411E817A; Tue, 9 Jul 2013 15:39:02 -0700 (PDT) Received: by mail-ob0-f182.google.com with SMTP id va7so7529460obc.41 for ; Tue, 09 Jul 2013 15:39:00 -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 :references:in-reply-to:content-type; bh=PdzL53/v9roGtC1xPvGsaRwMVTdcUIvZv47NXTTQHlc=; b=0e94BhNWs+SglQmrUueLqXgK1CDB2g0cP1831OTKayfWxcQA4xzx7SNblQDjHItoUy mSIwC4fR9k8HFdyWnSbqdtSADId+BA9aw2zbrZXKHDB54QT3Q772KS0XJY8g0pSU2fUe 7SFZBymJi+CZvXolFZ0ygd+hjSzFvbLWirPpV34Zu5ArLcsQSIXX1l5dA2ZHzS5juUJ4 pCAxs4T1f3tgKEn/7oPhmsSQ/cb/UVktzslLRjefBbSImolsoN9FDwYiQ2+uhls7piZ5 7oZEG/qsqS6wA9JbXxcLWHJGD+Jv2KsAJps7M5aDNC8CDFmUPBSKV4Yy2HAUe/LOfLzG O5/Q== X-Received: by 10.60.83.146 with SMTP id q18mr25903121oey.80.1373409540842; Tue, 09 Jul 2013 15:39:00 -0700 (PDT) Received: from [192.168.1.77] (99-108-174-213.lightspeed.rcsntx.sbcglobal.net. [99.108.174.213]) by mx.google.com with ESMTPSA id fk3sm40536814obb.2.2013.07.09.15.38.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Jul 2013 15:39:00 -0700 (PDT) Message-ID: <51DC90C4.6000301@gmail.com> Date: Tue, 09 Jul 2013 17:37:56 -0500 From: Spencer Dawkins User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <20130709003704.15548.41553.idtracker@ietfa.amsl.com> <51DC8257.6010202@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040807010407040302090506" X-Mailman-Approved-At: Wed, 10 Jul 2013 09:32:20 -0700 Cc: IETF Apps Discuss , SM , "appsawg-chairs@tools.ietf.org" , Spencer Dawkins , draft-ietf-appsawg-rfc5451bis@tools.ietf.org, The IESG Subject: Re: [apps-discuss] Spencer Dawkins' No Objection on draft-ietf-appsawg-rfc5451bis-09: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 Jul 2013 22:39:03 -0000 This is a multi-part message in MIME format. --------------040807010407040302090506 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 7/9/2013 5:27 PM, Murray S. Kucherawy wrote: > On Tue, Jul 9, 2013 at 2:36 PM, Spencer Dawkins > > > wrote: > > > If you tell me that the mismatch doesn't matter, because no one > will assume anything about version number '1' being the first > version without checking, I'll believe you, but I'll silently and > non-blockingly wonder why you preferred starting with "1". > > Does that make sense? > > > Yep. And yes, I don't think it matters. The question in a consumer > of this field will be "Do I understand the specific version I see in > the header field?" The IANA registry is mainly a mapping of version > numbers to specification documents. If new method "foobar" appears > and wants to start versioning at 0, there's no reason it can't. I did > the "set the current things at 1" only because they all actually are 1 > (in DKIM keys, it's "v=DKIM1"; in SPF, it's "v=spf1"; etc.), and I > need to populate the new column in the IANA registry with something. > > -MSK > Thanks for the clue! Spencer --------------040807010407040302090506 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 7/9/2013 5:27 PM, Murray S. Kucherawy wrote:
On Tue, Jul 9, 2013 at 2:36 PM, Spencer Dawkins <spencerdawkins.ietf@gmail.com> wrote:

If you tell me that the mismatch doesn't matter, because no one will assume anything about version number '1' being the first version without checking, I'll believe you, but I'll silently and non-blockingly wonder why you preferred starting with "1".

Does that make sense?


Yep.  And yes, I don't think it matters.  The question in a consumer of this field will be "Do I understand the specific version I see in the header field?"  The IANA registry is mainly a mapping of version numbers to specification documents.  If new method "foobar" appears and wants to start versioning at 0, there's no reason it can't.  I did the "set the current things at 1" only because they all actually are 1 (in DKIM keys, it's "v=DKIM1"; in SPF, it's "v=spf1"; etc.), and I need to populate the new column in the IANA registry with something.

-MSK


Thanks for the clue!

Spencer
--------------040807010407040302090506-- From dcrocker@bbiw.net Wed Jul 10 11:08:10 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5920121F9D22; Wed, 10 Jul 2013 11:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xPdfqlQxJ5iM; Wed, 10 Jul 2013 11:08:05 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id DB7D521F9CE8; Wed, 10 Jul 2013 11:08:05 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r6AI7tUJ000706 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 10 Jul 2013 11:07:59 -0700 Message-ID: <51DDA2E3.8010003@bbiw.net> Date: Wed, 10 Jul 2013 11:07:31 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: draft-ietf-straw-b2bua-taxonomy.all@tools.ietf.org, Apps Discuss , iesg Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.67]); Wed, 10 Jul 2013 11:07:59 -0700 (PDT) Subject: [apps-discuss] Review of: draft-ietf-straw-b2bua-taxonomy-02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 18:08:10 -0000 Howdy. I have been selected as the Applications Area Review Team reviewer for this draft (for background on apps-review, please see http://www.apps.ietf.org/content/applications-area-review-team). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Title: A Taxonomy of Session Initiation Protocol (SIP) Back-to-Back User Agents I-D: draft-ietf-straw-b2bua-taxonomy-02 By: D. Crocker Date: 7 July 2013 NOTE: Because this has just been moved up for tomorrow's IESG telechat, I'm copying the IESG directly. Unfortunately there is no time for issues to first be discussed and resolved with the authors prior to that. /d Summary: SIP exchanges can transit complex arrangements of functional components. Some of these perform classic "gatewaying" functions, by terminating portions of the session and initiating new ones. That is, they are specialized relays operating with detailed application knowledge and potentially imposing extensive modifications to the control or payload data. In the SIP context, these components are called back-to-back user agents (B2BUAS). Given the complexity of the SIP architecture, B2BUAS cover a wide range of possible functions. The current draft provides some structure to that range and offers terminology to label the structure. The document has utility in its current form. However, a diligent editing pass could make portions of it more easily understood and, overall, make the document more accessible to readers less expert in SIP architecture and deployment intricacies. For example, the abstract should be tweaked to make it more readable for non-experts. The current text assumes very large amount of SIP background, such as by using an acronym soup. Better to use fewer acronyms in abstract, unless they have extensive familiarity to /casual/ readers. To the extent that this document can only reasonably be read by first having familiarity with specific RFCs, the requirements need to be stated early in the Introduction. Equally, the terminology section should cite the documents from which it is importing terms. And every acronym should be expanded the first time it is used and/or have a citation to its technical details. Detailed Comments: > Abstract > > In many SIP deployments, SIP entities exist in the SIP signaling path > between the originating UAC and final terminating UAS, which go define acronyms at first occurrence, but better not to use them in an abstract, unless highly familiar to non-experts > beyond the definition of a Proxy, performing functions not defined in > standards-track RFCs. The only term for such devices provided in > [RFC3261] is for a Back-to-Back User Agent (B2BUA), which is defined > as the logical concatenation of a User Agent Server (UAS) and User > Agent Client (UAC). In the spirit of multi-cultural exchange, it might be worth comparing B2BUA to its email equivalent, which is 'mediator'. (RFC 5598). {As a sanity check: I think this draft's purpose compares with section 5 of RFC 5598? /d } > There are numerous types of SIP Back-to-Back User Agents (B2BUAs), > performing different roles in different ways. For Example IP-PBXs, > SBCs and Application Servers. This document identifies several Cite SBC definition. > common B2BUA roles, in order to provide taxonomy other documents can > use and reference. > > 1. Terminology > > B2BUA: a SIP Back-to-Back User Agent, which is the logical > combination of a User Agent Server (UAS) and User Agent Client (UAC). > > UAS: a SIP User Agent Server. > > UAC: a SIP User Agent Client. provide citations to definitions of these. I'm used to having the Introduction be the first section, with something like Terminology following. And, yes, that means the Introduction can't assume familiarity with the terms. > 2. Introduction > > > > Kaplan & Pascual Expires November 11, 2013 [Page 2] > > Internet-Draft Taxonomy of B2BUAs May 2013 > > > In current SIP deployments, there are numerous forms of B2BUAs, > operating at various layers of the protocol stack, and for various Normal models cast UAs at the top of the technical stack. So I've no idea what it means to have B2BUAs "operating at various layers of the protocol stack". The following sentence's don't clarify this issue. > purposes, and with widely varying behavior from a SIP protocol > perspective. Some act as pure SIP Proxies and only change to the > role of B2BUA in order to generate BYEs to terminate dead sessions. This really calls for some text that explicitly clarifies the difference between a SIP proxy and a B2BUA, especially given that a number of B2BUA 'roles' look quite a bit like classic proxy behavior. > Some are full User Agent stacks with only high-level event and > application logic binding the UAS and UAC sides. Some B2BUAs operate > only in the SIP signaling plane, while others participate in the > media plane as well. It would be quite helpful to have a diagram (or pointer to one) that places all of these in relationship to each other. > As more and more SIP domains get deployed and interconnect the delete: "and more" interconnect -> interconnected > probability of a single SIP session crossing multiple B2BUA's at both > the signaling and media planes increases significantly. Note that this means than SIP isn't end-to-end. B2BUAs are 'gateways' in that they terminate one connections/session and start another. > This document provides a taxonomy of several common B2BUA roles, so > that other documents may refer to them using their given names > without re-defining them in each document. > > 3. B2BUA Role Types > > Within the context of this document, the terms refer to a B2BUA role, "the terms"? what terms? The reference lacks context. > not a particular system type. A given system type may change its > role in the middle of a SIP session, for example when a Stateful > Proxy tears-down a session by generating BYEs; or for example when an > SBC performs transcoding or REFER termination. I hadn't heard the term transcoding before; I like it. Since it's in wikipedia, I'll assume it's well-established and doesn't need defining here? Or should RFC 5369 be cited here? > Furthermore, this document defines 'B2BUA' following the definition > provided in [RFC3261], which is the logical concatenation of a UAS > and UAC. A typical centralized conference server, for example, is > not a B2BUA because it is the target UAS of multiple UACs, whereby > the UACs individually and independently initiate separate SIP > sessions to the central conference server. Likewise, a third-party > call control transcoder as described in section 3.1 of [RFC5369] is > not a B2BUA; whereas an inline transcoder based on [RFC5370] is a > B2BUA. What is an "inline" transcoding? The term does not appear in RFC5370. > 3.1. Signaling-plane B2BUA Roles > > A Signaling-plane B2BUA is one that operates only on the SIP message > protocol layer, and only with SIP messages and headers but not the > media itself in any way. This implies it does not modify SDP bodies, implies -> implies that > although it may save them and/or operate on other MIME body types. > This category is further subdivided into specific roles as described > in this section. > > 3.1.1. Proxy-B2BUA > > > > > > Kaplan & Pascual Expires November 11, 2013 [Page 3] > > Internet-Draft Taxonomy of B2BUAs May 2013 > > > A Proxy-B2BUA is one that appears, from a SIP protocol perspective, > to be a SIP Proxy based on [RFC3261] and its extensions, except that > it maintains sufficient dialog state to generate in-dialog SIP > messages on its own and does so in specific cases. The most common > example of this is a SIP Proxy which can generate BYE requests to > tear-down a dead session. > > A Proxy-B2BUA does not modify the received header fields such as the > To, From, or Contact, and only modifies the Via and Record-Route > header fields following the rules in [RFC3261] and its extensions. > If a Proxy-B2BUA can generate in-dialog messages, then it will also > need to modify the CSeq header, after it's generated its own. A it's -> it has > Proxy-B2BUA neither modifies nor inspects MIME bodies (including > SDP), does not have any awareness of media, will forward any Method > type, etc. > > 3.1.2. Signaling-only > > A Signaling-only B2BUA is one that operates at the SIP layer but in > ways beyond those of [RFC3261] Proxies, even for normally forwarded It isn't immediately obvious what 'beyond' means here and I can't tell whether the following sentences are meant to define it, since they merely provide the same kind of might/might-not detail done in the previous sub-section. The detail is necessary, of course, but it doesn't explain the conceptual point being made by saying "beyond". > requests. Such a B2BUA may or may not replace the Contact URI, since rfc 2119 isn't cited, i assume that there is no normative language in this doc? in any event, i think the language is cleaner if 'may or may not' is replace by 'might'. > modify or remove all Via and Record-Route headers, modify the To and > From header fields, modify or inspect specific MIME bodies, etc. No Small stylistic suggestion, especially for anything that is a specification: When a list of (possible) actions is provided, it helps to format it as a list. > SIP header field is guaranteed to be copied from the received request > on the UAS side to the generated request on the UAC side. This last sentence is pretty scary. It seems to affirm a complete lack of assurance of end-to-end functionality. > An example of such a B2BUA would be some forms of Application Servers forms -> form {to match "an example") Servers -> Server > and PBXs, such as a server which locally processes REFER requests and > generates new INVITEs on behalf of the REFER's target. Another > example would be an [RFC3323] Privacy Service Proxy performing the > 'header' privacy function. > > 3.1.3. SDP-Modifying Signaling-only > > An SDP-Modifying Signaling-only B2BUA is one that operates in the > signaling plane only and is not in the media path, but does modify > SDP bodies and is thus aware of and understands SDP syntax and > semantics. Some Application Servers and PBXs act in this role in > some cases, for example to remove certain codec choices or merge two > media endpoints into one SDP offer. it's worth expanding sdp at least once in the doc. Also, these sub-section descriptions provide the mechanical details, but without any attempt to distinguish the meaning of the differences from one type to another. What's the /purpose/ of one role vs. another? As I scan the subsections, it appears that they are meant to describe agents that go progressively deeper into the architectural components. If the different roles are related in such a way, it's worth noting that at the beginning of the section. > 3.2. Media-plane B2BUA Roles > > A Media-plane B2BUA is one that operates at both the SIP and media > planes, not only on SIP messages but also SDP and potentially RTP/ > RTCP or other media. Such a B2BUA may or may not replace the Contact > URI, modify or remove all Via and Record-Route headers, modify the To > and From header fields, etc. No SIP header field is guaranteed to be > rtp/rtcp citation. > Kaplan & Pascual Expires November 11, 2013 [Page 4] > > Internet-Draft Taxonomy of B2BUAs May 2013 > > > copied from the received request on the UAS side to the generated > request on the UAC side, and SDP will also be modified. > > An example of such a B2BUA would be a Session Border Controller Session Border Controller -> Session Border Controller (SBC) > performing the functions defined in [RFC5853], a B2BUA transcoder as > defined in [RFC5370], a rich-ringtone Application Server, or a > recording system. Another example would be an [RFC3323] Privacy > Service Proxy performing the 'session' privacy function. > > Note that a Media-plane B2BUA need not be instantiated in a single > physical system, but may be decomposed into separate signaling and > media functions. This seems to be highlight an essential network architecture point, namely that there is a basic difference between components of the architecture versus their instantiation/implementation is h/w&s/w. Folks often miss this distinction, so it might be worth highlighting much earlier in the doc. > The Media-plane B2BUA category is further subdivided into specific > roles as described in this section. > > 3.2.1. Media-relay > > A B2BUA which performs a media-relay role is one that terminates the > media plane at the IP and UDP/TCP layers on its UAS and UAC sides, udp/tcp but not rtp? don't you mean 'originates' on its UAC side? > but neither modifies nor restricts which forms of UDP or TCP payload > are carried within the UDP or TCP packets. Such a role may only Might be worth inserting a sentence that explicitly says something like "Rather, the payload is transparently copied from the UAS side to the UAC side." > support UDP or only TCP or both, as well as other transport types or > not. Such a role may involve policing the IP packets to fit within a > bandwidth limit, or converting from IPv4 to IPV6 or vice-versa. This > is typically similar to a NAT behavior, except a NAT operating in > both directions on both the source and destination information; it is > often found as the default behavior in SBCs. > > 3.2.2. Media-aware > > A B2BUA which performs a media-aware role is similar to a media- > relay except that it inspects and potentially modifies the payload > carried in UDP or TCP, such as [RFC3550] RTP or RTCP, but not at a text after first comma doesn't parse. perhaps a connector word, before RTP is missing? > codec or higher layer. An example of such a role is an [RFC3711] > SRTP terminator, which does not need to care about the RTP payload > but does care about the RTP header; or a device which monitors RTCP > for QoS information; or a device which muxes/de-muxes RTP and RTCP > packets on the same 5-tuple. > > 3.2.3. Media-termination > > A B2BUA which performs a media-termination role is one that operates > at the media payload layer, such as RTP/RTCP codec or MSRP message > layer and higher. Such a role may only terminate/generate specific > RTP media, such as [RFC4733] DTMF packets, or it may convert between > media codecs, or act as a Back-To-Back [RFC4975] MSRP agent. This is > the role performed by transcoders, conference servers, etc. > > > > Kaplan & Pascual Expires November 11, 2013 [Page 5] > > Internet-Draft Taxonomy of B2BUAs May 2013 > > > 4. Mapping SIP Device Types to B2BUA Roles > > Although the B2BUA role types defined previously do not define a > system type, as discussed in section 3, some discussion of what 'a' system type? or perhaps 'system types'? role types -> roles {I suspect the word 'type' can be dropped for role references in this document, since roles are already an abstraction.} > common system types perform which defined roles may be appropriate. > This section provides such a 'mapping' for general cases, to aid in > understanding of the roles. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From presnick@qti.qualcomm.com Wed Jul 10 13:55:06 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DEAE21F9EBD; Wed, 10 Jul 2013 13:55:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zv61g5At1cNR; Wed, 10 Jul 2013 13:55:01 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9B22B21F9EAA; Wed, 10 Jul 2013 13:55:01 -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=1373489701; x=1405025701; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=pkK55mLyxm4mS424LpL+T8AaXulYrrOTlAbNEW+Jrnw=; b=vB2SudXb8pIkmVJdqXoYpvXs/XAgrwbwF6JNsg9hczXzBiePCDBcP8WS ulCZkGZNvLX2FVSeUZGVnG5g8H3q8Sn+JrX5Vta/D6lXp3dOHAs4uqBhi igxOYTodrBlnSxFcDuNUClrLPkm5cc0ZOriqROkDX/FKUd/Kq5anNNU4o 0=; X-IronPort-AV: E=Sophos;i="4.87,1038,1363158000"; d="scan'208,217";a="47154125" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by sabertooth01.qualcomm.com with ESMTP; 10 Jul 2013 13:55:01 -0700 Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 10 Jul 2013 13:55:00 -0700 Received: from presnick-mac.local (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 10 Jul 2013 13:54:59 -0700 Message-ID: <51DDCA21.9020302@qti.qualcomm.com> Date: Wed, 10 Jul 2013 15:54:57 -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: <20130708192433.5776.73625.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010804000700000500010409" X-Originating-IP: [172.30.48.1] Cc: draft-ietf-appsawg-rfc5451bis@tools.ietf.org, "appsawg-chairs@tools.ietf.org" , The IESG , IETF Apps Discuss , SM Subject: Re: [apps-discuss] Pete Resnick's Discuss on draft-ietf-appsawg-rfc5451bis-09: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jul 2013 20:55:06 -0000 --------------010804000700000500010409 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Skipping by the ones that we all agree on how to fix. On 7/9/13 12:53 PM, Murray S. Kucherawy wrote: > Pete's asked me to reply to the DISCUSS points as well to help him > change his ballot based on my responses: > > On Mon, Jul 8, 2013 at 12:24 PM, Pete Resnick > > wrote: > > > 1.3: > > The new information in 1.3 seems incorrect. Certainly an MUA > always looks > at an already-delivered email message. The old 1.3 made it clear that > this wasn't intended for an embedded message/rfc822 construct, but I > always took that to be because it was outside of the trust boundary > between the MDA and the MUA. But for messages that are delivered to a > mail spool that an MUA reads and displays to the user, it is perfectly > appropriate to look in the top-level of that message for the > Authentication-Results. That does depend on the MDA and MUA being > on the > same side of the trust boundary, but other than that there is not a > problem. Please explain this change. (Note: If this document were > recycling at Proposed, this would be a comment, but moving to full > Internet Standard, I want to understand the change before moving > ahead.) > > > The augmented text is meant to address some of the issues that were > raised since the publication of RFC5451, including the appeal of that > document's approval to the IESG. There exists an argument that this > field should carry with it enough information for the MUA to repeat > the authentication steps before deciding whether or how to render the > message to a user. For example, proponents of that argument claim the > IP address should be included in this field so that MUAs can repeat > SPF at the time the message is rendered. > > Certainly MUAs will be consuming the content of this field after > delivery to an inbox, but the goal here is not to enable them to do > new authentication work, but rather to apply the results of prior > authentication work. Well, why don't you say that? Say that the intention is not to allow the consumer of the field to re-create the authentication work, but rather to simply signal to the consumer that the work was done by someone they trust in the ADMD. > An A-R field that's part of a message/rfc822 MIME part could bear an > authserv-id that the MUA would normally trust, but it's dicey to > believe that field was subjected to the required scrubbing rules this > document specifies. Right. So that's worth preserving from 5451. > 2.5.2: > > You've reversed the sense of the registry by incorporating from > the SPF > spec. The definition of the registry entries for the codes coming from > SPF would now have to point to SPF, not for the meaning, but for the > actual names. That would mean that the registry should now be an > authentication method registry with the subregistry (or subentries > in the > table) being the result codes. Very confusing. > > > This was done in the spirit of not copying the content of one RFC into > another. Unlike DKIM and the others, the list of possible outcomes > and their definitions are enumerated in a different RFC for SPF, so it > seemed like a cleaner solution. If it turns out the cost of the > leaner document is too high in the way you've described, I can revert. I am equally OK with either putting the values for SPF back in (because it is only coincidental to this spec that the names of the codes are the same as the names of the SPF result values, unlike for other protocols) or switching the first two columns in the registry. Whichever makes life easier. > 4: > > The set of message properties registered for a given method, upon > which the reported result is based, can be numerous. However, the > ones included in the header field being generated SHOULD NOT > include > any that were not included in the computation of the result. Doing > so can confound consumers of the field when the method includes > multiple evaluation methods. For example, SPF can base its > conclusion on the RFC5321.Helo parameter or on the RFC5321.MailFrom > domain; including both of those in the Authentication-Results > header > field makes it impossible for the consumer to determine which > property of the message envelope was actually used. > > I don't get this paragraph. Are you saying that if SPF used HELO, I > SHOULD NOT indicate that I used MAIL FROM? That seems like the > height of > absurdity to say. If this is something that needs to be called out, I > don't understand why it isn't a MUST NOT. What does this mean? > > > SPF can produce a result based on either the HELO or MAIL FROM data > provided as part of the SMTP session. If one were to generate an A-R > field that says "spf=pass smtp,mailfrom=XXX smtp.helo=YYY", I am > unable to tell which of the two parameters was used to produce the > "pass" result. Can't I conclude from that A-R that the server ran against both MAIL FROM and HELO and passed both of them? > For an agent that wants to know that, this limitation is required. > So, "yes" to your second sentence. My second sentence was meant to be absurd: If I used HELO, saying MAIL FROM is not something that I would *ever* consider doing, so there's no need to say SHOULD (or MUST) NOT. I can't figure out the case where I would report a result for a computation that I did not in fact do. You don't need to tell me in the protocol that I shouldn't do that. It's like saying, "You MUST NOT put something in the Message-ID field that is not the Message-ID." Well, duh. What possible scenario is there in which I might mistakenly report a result that I did not in fact compute? > I'm fine with making it a MUST NOT; I think SHOULD NOT was there for a > not-very-good reason in retrospect. Surely I'm missing something, but given the explanation so far, I say strike the whole paragraph. On 7/9/13 2:12 AM, Murray S. Kucherawy wrote: > On Mon, Jul 8, 2013 at 12:24 PM, Pete Resnick > > wrote: > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > 1: > > This specification is not intended to be restricted to domain-based > authentication, but has proven to be a good starting point for > implementations. In order to support the propagation of evaluation > results, and as various message authentication methods emerge, this > header field encourages convergence for interfacing verifiers to > filters and MUAs. > > I have read those two sentences multiple times and I still have no > idea > what they're saying. > > > Looks like some words got cut someplace along the line. I'll fix it > up. The point is to note that all of the methods authenticate domain > names in one way or another, or even users at domains. There are > other identifiers that might be the subject of evaluation now or in > the future (the client IP address, perhaps, or something that > authenticates something else entirely). Implementers shouldn't assume > that this work is only useful for authentication of domain names just > because that's all there is right now; it should be considered for > methods that evaluate other identifiers of a message, envelope, or > transport as well. Well, that's fine and you should say that. I still don't understand what the words, "this header field encourages convergence for interfacing verifiers to filters and MUAs" mean. > 2.2: > > - Why did you make two separate "-version" elements? The original > seemed > fine. > > > This was suggested in the working group. The syntax is indeed > identical, but the prose describing the use of each (and the tie to > the IANA registry in one case) is different. The suggestion was to > split them so that their slightly different uses were more obvious > even if the actual syntax is the same. (*Shrug*) OK. > - The use of the word "amendment" in this section is undefined, > and IMO > unhelpful. > > > Changed to "update". No, I was being too obscure. The words "and subsequent amendments" (or "update") and the like are not useful. For example, you don't know if updates to SMTP will result in commands that are similarly two-worded like "MAIL FROM" and therefore will need separate registration. I say simply strike the "amendment/update" language throughout. > Where an SMTP command name is being reported as a "property", the > MAIL FROM command MUST be represented by "mailfrom" and the RCPT TO > command MUST be represented by "rcptto". All other SMTP commands > MUST be represented unchanged. > > The MUSTs in here seem silly. So if I get a mixed-case "HeLo", I > MUST use > it unchanged? Again, who do these requirements apply to? > > > The MUST applies to the agent generating this header field and adding > it to a message. I'll clean up that paragraph. Sounds like a definition where the MUSTs aren't necessary. > 2.5.1: > > I'm not sure why the second paragraph was moved up from below. It > makes > more sense below, to me. > > > One of the reviewers had the opposite advice, namely to define the > term "acceptable to the verifier" before using it. A difference of editorial taste, I suppose. Count me as a reviewer who liked it better the old way. Do with that what you will. > 4: > > If an MTA applies more than one such test, > it MUST add this header field either once per test, or once > indicating all of the results. An MTA MUST NOT add a result to an > existing header field. > > [This] says that an MTA MUST NOT add to an existing > field, but that seems completely implementation dependent: I might > pass > partial fields along within an ADMD with trusted MTAs and do exactly > that. What I think this is saying is something along the lines of the > requirement to remove old ones, but then it's redundant. I don't > get this > paragraph. > > > [This] enforces that the field is trace data within the meaning of > RFC5321, so one isn't supposed to monkey with its content or its order > if it's already there. If you have more authentication information to > add, prepend a new field. OK, so I get the MUST NOT. But I don't get the MUST: What else could I do but add once per test or one field with everything? What are you telling me I MUST NOT do by telling me I MUST do this? > This is just another lower-to-upper of 2119 key words that were in the > previous version. I'll reword around them. One suggestion here: Don't reword MUST to "needs to" or REQUIRED to "necessary". In the cases in this document where the MUSTs are unnecessary, make it simply some conjugation of "to be". pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 --------------010804000700000500010409 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Skipping by the ones that we all agree on how to fix.

On 7/9/13 12:53 PM, Murray S. Kucherawy wrote:
Pete's asked me to reply to the DISCUSS points as well to help him change his ballot based on my responses:

On Mon, Jul 8, 2013 at 12:24 PM, Pete Resnick <presnick@qti.qualcomm.com> wrote:

1.3:

The new information in 1.3 seems incorrect. Certainly an MUA always looks
at an already-delivered email message. The old 1.3 made it clear that
this wasn't intended for an embedded message/rfc822 construct, but I
always took that to be because it was outside of the trust boundary
between the MDA and the MUA. But for messages that are delivered to a
mail spool that an MUA reads and displays to the user, it is perfectly
appropriate to look in the top-level of that message for the
Authentication-Results. That does depend on the MDA and MUA being on the
same side of the trust boundary, but other than that there is not a
problem. Please explain this change. (Note: If this document were
recycling at Proposed, this would be a comment, but moving to full
Internet Standard, I want to understand the change before moving ahead.)

The augmented text is meant to address some of the issues that were raised since the publication of RFC5451, including the appeal of that document's approval to the IESG.  There exists an argument that this field should carry with it enough information for the MUA to repeat the authentication steps before deciding whether or how to render the message to a user.  For example, proponents of that argument claim the IP address should be included in this field so that MUAs can repeat SPF at the time the message is rendered.

Certainly MUAs will be consuming the content of this field after delivery to an inbox, but the goal here is not to enable them to do new authentication work, but rather to apply the results of prior authentication work.

Well, why don't you say that? Say that the intention is not to allow the consumer of the field to re-create the authentication work, but rather to simply signal to the consumer that the work was done by someone they trust in the ADMD.

An A-R field that's part of a message/rfc822 MIME part could bear an authserv-id that the MUA would normally trust, but it's dicey to believe that field was subjected to the required scrubbing rules this document specifies.

Right. So that's worth preserving from 5451.

2.5.2:

You've reversed the sense of the registry by incorporating from the SPF
spec. The definition of the registry entries for the codes coming from
SPF would now have to point to SPF, not for the meaning, but for the
actual names. That would mean that the registry should now be an
authentication method registry with the subregistry (or subentries in the
table) being the result codes. Very confusing.

This was done in the spirit of not copying the content of one RFC into another.  Unlike DKIM and the others, the list of possible outcomes and their definitions are enumerated in a different RFC for SPF, so it seemed like a cleaner solution.  If it turns out the cost of the leaner document is too high in the way you've described, I can revert.

I am equally OK with either putting the values for SPF back in (because it is only coincidental to this spec that the names of the codes are the same as the names of the SPF result values, unlike for other protocols) or switching the first two columns in the registry. Whichever makes life easier.

4:

   The set of message properties registered for a given method, upon
   which the reported result is based, can be numerous.  However, the
   ones included in the header field being generated SHOULD NOT include
   any that were not included in the computation of the result.  Doing
   so can confound consumers of the field when the method includes
   multiple evaluation methods.  For example, SPF can base its
   conclusion on the RFC5321.Helo parameter or on the RFC5321.MailFrom
   domain; including both of those in the Authentication-Results header
   field makes it impossible for the consumer to determine which
   property of the message envelope was actually used.

I don't get this paragraph. Are you saying that if SPF used HELO, I
SHOULD NOT indicate that I used MAIL FROM? That seems like the height of
absurdity to say. If this is something that needs to be called out, I
don't understand why it isn't a MUST NOT. What does this mean?

SPF can produce a result based on either the HELO or MAIL FROM data provided as part of the SMTP session.  If one were to generate an A-R field that says "spf=pass smtp,mailfrom=XXX smtp.helo=YYY", I am unable to tell which of the two parameters was used to produce the "pass" result.

Can't I conclude from that A-R that the server ran against both MAIL FROM and HELO and passed both of them?

For an agent that wants to know that, this limitation is required.  So, "yes" to your second sentence.

My second sentence was meant to be absurd: If I used HELO, saying MAIL FROM is not something that I would *ever* consider doing, so there's no need to say SHOULD (or MUST) NOT. I can't figure out the case where I would report a result for a computation that I did not in fact do. You don't need to tell me in the protocol that I shouldn't do that. It's like saying, "You MUST NOT put something in the Message-ID field that is not the Message-ID." Well, duh. What possible scenario is there in which I might mistakenly report a result that I did not in fact compute?

I'm fine with making it a MUST NOT; I think SHOULD NOT was there for a not-very-good reason in retrospect.

Surely I'm missing something, but given the explanation so far, I say strike the whole paragraph.

On 7/9/13 2:12 AM, Murray S. Kucherawy wrote:
On Mon, Jul 8, 2013 at 12:24 PM, Pete Resnick <presnick@qti.qualcomm.com> wrote:

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

1:

   This specification is not intended to be restricted to domain-based
   authentication, but has proven to be a good starting point for
   implementations.  In order to support the propagation of evaluation
   results, and as various message authentication methods emerge, this
   header field encourages convergence for interfacing verifiers to
   filters and MUAs.

I have read those two sentences multiple times and I still have no idea
what they're saying.

Looks like some words got cut someplace along the line.  I'll fix it up.  The point is to note that all of the methods authenticate domain names in one way or another, or even users at domains.  There are other identifiers that might be the subject of evaluation now or in the future (the client IP address, perhaps, or something that authenticates something else entirely).  Implementers shouldn't assume that this work is only useful for authentication of domain names just because that's all there is right now; it should be considered for methods that evaluate other identifiers of a message, envelope, or transport as well.

Well, that's fine and you should say that. I still don't understand what the words, "this header field encourages convergence for interfacing verifiers to filters and MUAs" mean.

2.2:

- Why did you make two separate "-version" elements? The original seemed
fine.

This was suggested in the working group.  The syntax is indeed identical, but the prose describing the use of each (and the tie to the IANA registry in one case) is different.  The suggestion was to split them so that their slightly different uses were more obvious even if the actual syntax is the same.

(*Shrug*) OK.
 
- The use of the word "amendment" in this section is undefined, and IMO
unhelpful.

Changed to "update".

No, I was being too obscure. The words "and subsequent amendments" (or "update") and the like are not useful. For example, you don't know if updates to SMTP will result in commands that are similarly two-worded like "MAIL FROM" and therefore will need separate registration. I say simply strike the "amendment/update" language throughout.
 
   Where an SMTP command name is being reported as a "property", the
   MAIL FROM command MUST be represented by "mailfrom" and the RCPT TO
   command MUST be represented by "rcptto".  All other SMTP commands
   MUST be represented unchanged.

The MUSTs in here seem silly. So if I get a mixed-case "HeLo", I MUST use
it unchanged? Again, who do these requirements apply to?

The MUST applies to the agent generating this header field and adding it to a message.  I'll clean up that paragraph.

Sounds like a definition where the MUSTs aren't necessary.

2.5.1:

I'm not sure why the second paragraph was moved up from below. It makes
more sense below, to me.

One of the reviewers had the opposite advice, namely to define the term "acceptable to the verifier" before using it.

A difference of editorial taste, I suppose. Count me as a reviewer who liked it better the old way. Do with that what you will.
 
4:

   If an MTA applies more than one such test,
   it MUST add this header field either once per test, or once
   indicating all of the results.  An MTA MUST NOT add a result to an
   existing header field.

[This] says that an MTA MUST NOT add to an existing
field, but that seems completely implementation dependent: I might pass
partial fields along within an ADMD with trusted MTAs and do exactly
that. What I think this is saying is something along the lines of the
requirement to remove old ones, but then it's redundant. I don't get this
paragraph.

[This] enforces that the field is trace data within the meaning of RFC5321, so one isn't supposed to monkey with its content or its order if it's already there.  If you have more authentication information to add, prepend a new field.

OK, so I get the MUST NOT. But I don't get the MUST: What else could I do but add once per test or one field with everything? What are you telling me I MUST NOT do by telling me I MUST do this?
 
This is just another lower-to-upper of 2119 key words that were in the previous version.  I'll reword around them.

One suggestion here: Don't reword MUST to "needs to" or REQUIRED to "necessary". In the cases in this document where the MUSTs are unnecessary, make it simply some conjugation of "to be".

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478
--------------010804000700000500010409-- From presnick@qti.qualcomm.com Wed Jul 10 14:02:17 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEBA621F9C76; Wed, 10 Jul 2013 14:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.467 X-Spam-Level: X-Spam-Status: No, score=-102.467 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QwxdN5UCc1L6; Wed, 10 Jul 2013 14:02:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D06FE21F9C6B; Wed, 10 Jul 2013 14:02:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Pete Resnick" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130710210215.11506.9120.idtracker@ietfa.amsl.com> Date: Wed, 10 Jul 2013 14:02:15 -0700 Cc: draft-ietf-appsawg-rfc5451bis@tools.ietf.org, appsawg-chairs@tools.ietf.org, sm+ietf@elandsys.com, apps-discuss@ietf.org Subject: [apps-discuss] Pete Resnick's Discuss on draft-ietf-appsawg-rfc5451bis-09: (with DISCUSS and COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jul 2013 21:02:18 -0000 Pete Resnick has entered the following ballot position for draft-ietf-appsawg-rfc5451bis-09: 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. ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Updated since the downgrade to PS. I don't think these will take much to sort out. 2.5.2: You've reversed the sense of the registry by incorporating from the SPF spec. The definition of the registry entries for the codes coming from SPF would now have to point to SPF, not for the meaning, but for the actual names. That would mean that the registry should now be an authentication method registry with the subregistry (or subentries in the table) being the result codes. Very confusing. 4: The set of message properties registered for a given method, upon which the reported result is based, can be numerous. However, the ones included in the header field being generated SHOULD NOT include any that were not included in the computation of the result. Doing so can confound consumers of the field when the method includes multiple evaluation methods. For example, SPF can base its conclusion on the RFC5321.Helo parameter or on the RFC5321.MailFrom domain; including both of those in the Authentication-Results header field makes it impossible for the consumer to determine which property of the message envelope was actually used. I don't get this paragraph. Are you saying that if SPF used HELO, I SHOULD NOT indicate that I used MAIL FROM? That seems like the height of absurdity to say. If this is something that needs to be called out, I don't understand why it isn't a MUST NOT. What does this mean? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 1: - I found the first sentence of the introduction very abrupt and distracting from the purpose of the document. The mention of "the first version of this document" in the first sentence is anachronistic IMO. Please make the first sentence indicate something about the overall purpose of the document and *then* fall into the details. - Editorial: o reverse IP address name validation ("iprev", defined in [RFC5451]) Defined in section 3 of this document, not 5451. This specification is not intended to be restricted to domain-based authentication, but has proven to be a good starting point for implementations. In order to support the propagation of evaluation results, and as various message authentication methods emerge, this header field encourages convergence for interfacing verifiers to filters and MUAs. I have read those two sentences multiple times and I still have no idea what they're saying. 1.1: In particular, the mere presence of this header field SHOULD NOT be construed as meaning that its data is valid... I'm not sure why that changed to a 2119 "SHOULD NOT", but the passive voice and the word "construed" makes it unclear to me what the requirement being stated here is. 1.3: The new information in 1.3 seems incorrect. Certainly an MUA always looks at an already-delivered email message. The old 1.3 made it clear that this wasn't intended for an embedded message/rfc822 construct, but I always took that to be because it was outside of the trust boundary between the MDA and the MUA. But for messages that are delivered to a mail spool that an MUA reads and displays to the user, it is perfectly appropriate to look in the top-level of that message for the Authentication-Results. That does depend on the MDA and MUA being on the same side of the trust boundary, but other than that there is not a problem. Please explain this change. 1.5.2: By contrast, DKIM is agnostic as to the routing of a message but uses cryptographic signatures to authenticate agents claim (some) responsibility for the message (which implies authorization)... = That doesn't parse. 2.2: - Why did you make two separate "-version" elements? The original seemed fine. - In the comment to pvalue: I think having 2119 MUST language in a comment to ABNF is crazy (being in 5451 notwithstanding). This requirement should be pulled out into the main text below the ABNF. - The use of the word "amendment" in this section is undefined, and IMO unhelpful. - Some 2119 nonsense: The "ptype" and "property" values used by each authentication method MUST be defined in the specification for that method (or its amendments). = Not only is this a change from 5451, I'm not clear on whom this requirement rests. There is plenty of text in 2.5.6 and 2.5.7 about this. I say strike it from here. Where an SMTP command name is being reported as a "property", the MAIL FROM command MUST be represented by "mailfrom" and the RCPT TO command MUST be represented by "rcptto". All other SMTP commands MUST be represented unchanged. The MUSTs in here seem silly. So if I get a mixed-case "HeLo", I MUST use it unchanged? Again, who do these requirements apply to? 2.5.1: I'm not sure why the second paragraph was moved up from below. It makes more sense below, to me. 2.5.6: Method identifiers MUST be registered... ...such identifiers SHOULD reflect the name of the method... = Why MUST? Why SHOULD? 4: An MTA compliant with this specification MUST add this header field (after performing one or more message authentication tests) to indicate which MTA or ADMD performed the test, which test got applied and what the result was. If an MTA applies more than one such test, it MUST add this header field either once per test, or once indicating all of the results. An MTA MUST NOT add a result to an existing header field. = I find this set of requirements weird and unnecessary. The first sentence basically says, "If you implement this document, you MUST implement this document", which is just goofy. The rest says that an MTA MUST NOT add to an existing field, but that seems completely implementation dependent: I might pass partial fields along within an ADMD with trusted MTAs and do exactly that. What I think this is saying is something along the lines of the requirement to remove old ones, but then it's redundant. I don't get this paragraph. An MTA adding this header field MUST take steps to identify it as legitimate to the MUAs or downstream filters that will ultimately consume its content. One REQUIRED process to do so is described in Section 5. Further measures may be necessary in some environments. Some possible solutions are enumerated in Section 8.1. This document does not mandate any specific solution to this issue as each environment has its own facilities and limitations. The added 2119 in this paragraph doesn't help anyone. There is already a requirement in section 5, and some discussion in 8.1, about what to do and what is required. 2119 keywords with forward pointers to the actual requirements are not helpful. s/MUST take/will. s/REQUIRED//. From ted.lemon@nominum.com Wed Jul 10 20:29:18 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFF9F11E8133; Wed, 10 Jul 2013 20:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8yt0qD2rT-M; Wed, 10 Jul 2013 20:29:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 045E311E80BA; Wed, 10 Jul 2013 20:29:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Ted Lemon" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130711032917.15531.27251.idtracker@ietfa.amsl.com> Date: Wed, 10 Jul 2013 20:29:17 -0700 Cc: draft-ietf-appsawg-rfc5451bis@tools.ietf.org, appsawg-chairs@tools.ietf.org, sm+ietf@elandsys.com, apps-discuss@ietf.org Subject: [apps-discuss] Ted Lemon's No Objection on draft-ietf-appsawg-rfc5451bis-09: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jul 2013 03:29:18 -0000 Ted Lemon has entered the following ballot position for draft-ietf-appsawg-rfc5451bis-09: 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. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Throughout the document, the term "this header field" and "the header field" is used to refer to the Authentication-Results header field. This isn't very user friendly=E2=80=94I keep wondering if the antecedent has cha= nged. Once it's clear to the reader what the document is about, I think this is less of an issue, but it made starting to read it kind of painful. I think it would be more friendly to say "the authref header field" each time, even though it's an extra word. I realize that this is a fairly minor cognitive load for the reader, but when it comes to even minor cognitive loads, less is more. In 2.5.7: Extension results MUST only be used within ADMDs that have explicitly consented to use them. Wouldn't it be better to say: Extension results MUST NOT be used within ADMDs that have not explicitly consented to use them. I suggest this because "MUST only" is not an RFC 2119 key word, but I think you mean the two words together to be normative. It's understandable either way, so this is a minor nit, but take it for what it's worth. >From section 5: For simplicity and maximum security, a border MTA could remove all instances of this header field on mail crossing into its trust boundary. However, this may conflict with the desire to access authentication results performed by trusted external service providers. It may also invalidate signed messages whose signatures cover external instances of this header field. A more robust border MTA could allow a specific list of authenticating MTAs whose information is to be admitted, removing all others. Although this alludes to the problem of breaking DKIM, for example, it doesn't fully address it. A DKIM message may be signed in a way that can be validated, and yet not come from a trusted external service provider. If the DKIM signature includes an Authentication-Results header, removing it will break the signature, preventing the MUA from validating it. This seems like a big loss of functionality, since the end user doesn't have a way of opting out of this breakage. This could be easily mitigated by changing the name of the header field rather than removing it: change it to Elided-Authentication-Results or something. Then the MUA can reverse that and calculate the DKIM signature. I realize that this may be a non-issue in practice. I haven't seen a DKIM signature that signed an Authentication-Results header, and maybe it just never happens. But this seems so easy to fix that it ought to be worth the minor effort involved. From tobias.gondrom@gondrom.org Thu Jul 11 01:44:52 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D09CB21F9E15 for ; Thu, 11 Jul 2013 01:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.361 X-Spam-Level: X-Spam-Status: No, score=-95.361 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ahEZSHD-XTTK for ; Thu, 11 Jul 2013 01:44:48 -0700 (PDT) Received: from lvps176-28-13-69.dedicated.hosteurope.de (lvps176-28-13-69.dedicated.hosteurope.de [176.28.13.69]) by ietfa.amsl.com (Postfix) with ESMTP id AAB7021F9D09 for ; Thu, 11 Jul 2013 01:44:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=j/3Yt06T0OzMEzPGgkGjsN1KaqA5ZEwIM8MdRRd1sYbVZAc+SPm/Z4i6gW4RV++Bed/f57oxin9MYXk+fgg3R/aNTgkps5rR9NEUGmtHxZEAZYFl1gWHbPHTvifHf9vK; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type; Received: (qmail 26581 invoked from network); 11 Jul 2013 10:44:45 +0200 Received: from 88.191.140.61.broad.gz.gd.dynamic.163data.com.cn (HELO ?172.20.22.33?) (61.140.191.88) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 11 Jul 2013 10:44:38 +0200 Message-ID: <51DE7062.3000607@gondrom.org> Date: Thu, 11 Jul 2013 15:44:18 +0700 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: pritikin@cisco.com References: <51C954C5.4060401@gondrom.org> <53EA47528D6ACF4486AA152F92C2B698ED617B@xmb-rcd-x03.cisco.com> In-Reply-To: <53EA47528D6ACF4486AA152F92C2B698ED617B@xmb-rcd-x03.cisco.com> X-Enigmail-Version: 1.5.1 Content-Type: multipart/alternative; boundary="------------000401060304010407030407" Cc: iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] AppsDir review of draft-ietf-pkix-est-07 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jul 2013 08:44:52 -0000 This is a multi-part message in MIME format. --------------000401060304010407030407 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Fine with nearly every answer. One comment inline. Best regards, Tobias On 11/07/13 06:31, Max Pritikin (pritikin) wrote: > This series of emails details the EST updates to est-07 in response to > the comments below, > > On Jun 25, 2013, at 2:28 AM, Tobias Gondrom > > wrote: > >> I have been selected as the Applications Area Directorate reviewer for >> this draft (for background on appsdir, please see ​ >> http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate >> ). >> >> Please resolve these comments along with any other Last Call comments >> you may receive. Please wait for direction from your document shepherd >> or AD before posting a new version of the draft. >> >> Document: draft-ietf-pkix-est-07 >> Title: Enrollment over Secure Transport >> Reviewer: Tobias Gondrom >> Review Date: 25.6.2013 >> >> Summary: The draft looks fine. >> It is heading for STD track and mostly describes Simple PKI over TLS >> (and using the protected channel mechanisms for mutual authentication >> as well (beyond simple confidentiality)). >> >> comments: >> >> >> 1. section 2.2.2 and 2.2.3 >> ( client verification.) >> (Certificate-less TLS (e.g., with a shared credential distributed >> out-of-band); >> and HTTP-based with a username/password distributed out-of-band.) >> >> make sure to avoid information leakage. E.g. in case of >> certificate-less TLS, if cookies are used, make sure that are not >> transmitted over the normal unprotected HTTP band. >> (section 3.2.3 already specifies that "HTTP Basic and Digest >> authentication MUST only be performed over TLS 1.1 [RFC4346] or later >> versions." which is good.) > > This statement in 3.2.3 re-enforces the statement in Section 3.3 that > "HTTPS MUST be used. TLS 1.1 [RFC4346] (or a later version) MUST > be used." > Arguably these statements could be condensed into 2119 assertion > (although we have not done this). > >> 2. section 3.2.4: >> when registering "application/csrattrs" with IANA in section 6 >> I see you have no Magic number or file extension. >> Is there a chance that this request might at some point be made >> without direct HTTP and might want some of the two? > > A file extension (".csrattrs") has been added. > >> 3. section 3.2.2: >> as you want to offer to use HTTP POST and GET. >> I am not so happy about the HTTP GET parts. How do you consider the >> risk of information leakage with HTTP GET when you have e.g. labels? >> e.g. in case of "2. >> https://www.example.com/.well-known/est/arbitraryLabel1/cacerts" > > Infrastructures that wish to keep their public certificate > infrastructure details private can enforce client authentication > during GET operations as specified in s4.1.2 ("EST server SHOULD NOT > require client authentication"). Hm. Not sure. This does potentially not fulfill all security needs: because even if you use authentication, you will still leak the information in the GET URL to everyone in your HTTP/TCP path. Is this a problem? > >> Second you may consider to note URI length limitations in GET requests. > > Reject: There is plenty about URI/HTTP/etc that we are not noting > >> nits: >> page 32 >> s/to use the the secp384r1 elliptic curve/to use the secp384r1 >> elliptic curve > > fixed. > >> >> >> Oh and you should clean up idnits: >> ** Downref: Normative reference to an Informational RFC: RFC 2986 >> ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) > > As previously noted on thread these are acceptable. > > - max > >> >> >> Best regards, Tobias >> >> > --------------000401060304010407030407 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Fine with nearly every answer.
One comment inline.
Best regards, Tobias


On 11/07/13 06:31, Max Pritikin (pritikin) wrote:
This series of emails details the EST updates to est-07 in response to the comments below,
 
On Jun 25, 2013, at 2:28 AM, Tobias Gondrom <tobias.gondrom@gondrom.org> wrote:

I have been selected as the Applications Area Directorate reviewer for
this draft (for background on appsdir, please see ​
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ).

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

Document: draft-ietf-pkix-est-07
Title: Enrollment over Secure Transport
Reviewer: Tobias Gondrom
Review Date: 25.6.2013

Summary: The draft looks fine.
It is heading for STD track and mostly describes Simple PKI over TLS (and using the protected channel mechanisms for mutual authentication as well (beyond simple confidentiality)).

comments:


1. section 2.2.2 and 2.2.3
( client verification.)
(Certificate-less TLS (e.g., with a shared credential distributed out-of-band);
and HTTP-based with a username/password distributed out-of-band.)

make sure to avoid information leakage. E.g. in case of certificate-less TLS, if cookies are used, make sure that are not transmitted over the normal unprotected HTTP band.
(section 3.2.3 already specifies that "HTTP Basic and Digest authentication MUST only be performed over TLS 1.1 [RFC4346] or later versions." which is good.)

This statement in 3.2.3 re-enforces the statement in Section 3.3 that "HTTPS MUST be used.  TLS 1.1 [RFC4346] (or a later version) MUST be used."
Arguably these statements could be condensed into 2119 assertion (although we have not done this). 

2. section 3.2.4:
when registering  "application/csrattrs" with IANA in section 6
I see you have no Magic number or file extension.
Is there a chance that this request might at some point be made without direct HTTP and might want some of the two?

A file extension (".csrattrs") has been added. 

3. section 3.2.2:
as you want to offer to use HTTP POST and GET.
I am not so happy about the HTTP GET parts. How do you consider the risk of information leakage with HTTP GET when you have e.g. labels?
e.g. in case of    "2.  https://www.example.com/.well-known/est/arbitraryLabel1/cacerts"

Infrastructures that wish to keep their public certificate infrastructure details private can enforce client authentication during GET operations as specified in s4.1.2 ("EST server SHOULD NOT require client authentication").

Hm. Not sure. This does potentially not fulfill all security needs: because even if you use authentication, you will still leak the information in the GET URL to everyone in your HTTP/TCP path. Is this a problem?



Second you may consider to note URI length limitations in GET requests. 

Reject: There is plenty about URI/HTTP/etc that we are not noting

nits:
page 32
s/to use the the secp384r1 elliptic curve/to use the secp384r1 elliptic curve

fixed.



Oh and you should clean up idnits:
 ** Downref: Normative reference to an Informational RFC: RFC 2986
  ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246)

As previously noted on thread these are acceptable.

- max



Best regards, Tobias




--------------000401060304010407030407-- From stephen.farrell@cs.tcd.ie Thu Jul 11 03:09:39 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8207521F9FE6; Thu, 11 Jul 2013 03:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.367 X-Spam-Level: X-Spam-Status: No, score=-102.367 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tAKEPkGz7ElS; Thu, 11 Jul 2013 03:09:33 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 9D38921F9C0E; Thu, 11 Jul 2013 03:09:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7952FBE76; Thu, 11 Jul 2013 11:09:09 +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 X9JdDb5TtCBl; Thu, 11 Jul 2013 11:09:08 +0100 (IST) Received: from [10.87.48.9] (unknown [86.42.17.76]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 63B52BE5B; Thu, 11 Jul 2013 11:09:08 +0100 (IST) Message-ID: <51DE8443.6080606@cs.tcd.ie> Date: Thu, 11 Jul 2013 11:09:07 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Ted Lemon References: <20130711032917.15531.27251.idtracker@ietfa.amsl.com> In-Reply-To: <20130711032917.15531.27251.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: draft-ietf-appsawg-rfc5451bis@tools.ietf.org, appsawg-chairs@tools.ietf.org, The IESG , apps-discuss@ietf.org, sm+ietf@elandsys.com Subject: Re: [apps-discuss] Ted Lemon's No Objection on draft-ietf-appsawg-rfc5451bis-09: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jul 2013 10:09:39 -0000 On 07/11/2013 04:29 AM, Ted Lemon wrote: > This could be easily mitigated by changing the name of the header field > rather than removing it: change it to Elided-Authentication-Results or > something. Then the MUA can reverse that and calculate the DKIM > signature. Don't think its that easy. There could be >1 DKIM Signature header field and >1 AR header field. Also sounds quite hacky;-) S. > > I realize that this may be a non-issue in practice. I haven't seen a > DKIM signature that signed an Authentication-Results header, and maybe it > just never happens. But this seems so easy to fix that it ought to be > worth the minor effort involved. > > From Ted.Lemon@nominum.com Thu Jul 11 05:13:08 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2DEA11E810B; Thu, 11 Jul 2013 05:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z91jy+EGtJqI; Thu, 11 Jul 2013 05:13:02 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id 8315F21F9FF3; Thu, 11 Jul 2013 05:12:51 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKUd6hQocUzt0svFCJN4ocF61lH3/FK43v@postini.com; Thu, 11 Jul 2013 05:12:51 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 EA5F01B81C2; Thu, 11 Jul 2013 05:12:49 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 51393190052; Thu, 11 Jul 2013 05:12:49 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Thu, 11 Jul 2013 05:12:49 -0700 From: Ted Lemon To: Stephen Farrell Thread-Topic: Ted Lemon's No Objection on draft-ietf-appsawg-rfc5451bis-09: (with COMMENT) Thread-Index: AQHOfh6x52ax2hqdmkeIC2hveaahBplf2QUA Date: Thu, 11 Jul 2013 12:12:48 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63077520A3BE@mbx-01.win.nominum.com> References: <20130711032917.15531.27251.idtracker@ietfa.amsl.com> <51DE8443.6080606@cs.tcd.ie> In-Reply-To: <51DE8443.6080606@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <1EAAC6B1CF22DD48B6990B53C34E82E6@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "" , The IESG , "" , "" Subject: Re: [apps-discuss] Ted Lemon's No Objection on draft-ietf-appsawg-rfc5451bis-09: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jul 2013 12:13:09 -0000 On Jul 11, 2013, at 6:09 AM, Stephen Farrell wr= ote: > Don't think its that easy. There could be >1 DKIM Signature header > field and >1 AR header field. Also sounds quite hacky;-) Deleting headers is also hacky. Figuring out which headers are covered by= a DKIM signature, assuming MTAs that prepend headers, is pretty straightfo= rward=97you just see how many of a type of header were listed in the DKIM s= ignature, and consume that many from the header history, starting from the = DKIM header. So yeah, it's hacky, and maybe it's not worth doing, but I t= hink it could be done and could work _if_ it were worth doing. From barryleiba@gmail.com Thu Jul 11 05:28:26 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21C5611E8149; Thu, 11 Jul 2013 05:28:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.987 X-Spam-Level: X-Spam-Status: No, score=-101.987 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VouhTDkAJF+c; Thu, 11 Jul 2013 05:28:25 -0700 (PDT) Received: from mail-qe0-x235.google.com (mail-qe0-x235.google.com [IPv6:2607:f8b0:400d:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 2E23C21F9FEA; Thu, 11 Jul 2013 05:28:21 -0700 (PDT) Received: by mail-qe0-f53.google.com with SMTP id 1so4361634qee.12 for ; Thu, 11 Jul 2013 05:28:21 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=5MxmM/jSM6j8DncTiAUyx2+JZhxCc7+8RhX47KxghMA=; b=mgX8g8KButBZyPriffUu0INLUFbpdioMdjZtkKzVoOyJMPl2+auXeHajU2CMRA2p77 eoUvUgpm6xsb3iotl7qBPflM83XbWfKrmIGfNcEKVYV0/aW0pT9ZsSZtwxnDFnnFFrHr jKYiaisYPKBbBA3x+aALpVjBKsQ/OgOpMzNg6/UqCZi9u8n0uhhfoMa3jc76UyQlPmND 5hmuyH0Q62ChQt5SaHUSHUp33RB1wffBflcvgF0cZxBjsJNE5gj7NOQ3kWPIwHfrziPB fvxwIg3MKns5e2BYRxoIfgafWFHLY2XYK1dMcAhso7phHnY6qNSyUmuIKmLB2hntnOf8 VQiQ== MIME-Version: 1.0 X-Received: by 10.224.7.71 with SMTP id c7mr32921217qac.17.1373545700444; Thu, 11 Jul 2013 05:28:20 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.224.216.201 with HTTP; Thu, 11 Jul 2013 05:28:20 -0700 (PDT) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077520A3BE@mbx-01.win.nominum.com> References: <20130711032917.15531.27251.idtracker@ietfa.amsl.com> <51DE8443.6080606@cs.tcd.ie> <8D23D4052ABE7A4490E77B1A012B63077520A3BE@mbx-01.win.nominum.com> Date: Thu, 11 Jul 2013 08:28:20 -0400 X-Google-Sender-Auth: JjfRSyfEy6ArM6PNt73uB8Ex1vU Message-ID: From: Barry Leiba To: Ted Lemon Content-Type: multipart/alternative; boundary=001a11c2a0888f08c904e13b8707 Cc: "" , "" , "" , The IESG , "" Subject: Re: [apps-discuss] Ted Lemon's No Objection on draft-ietf-appsawg-rfc5451bis-09: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jul 2013 12:28:26 -0000 --001a11c2a0888f08c904e13b8707 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable There were, similarly, conversations in the DKIM WG about trying to reconstruct broken signatures through mailing lists by looking for a "[listname]" prefix on the Subject header and stripping it and retrying the sig validation. After discussion, the WG had clear consensus that any such heuristics could be attempted, but NOT within the scope of the standard -- they were too dicey, leaving too many questions open (what if a spammer prepended "[my.bad.url]" to a signed message?). This falls into the same category, and you're asking for a new header field name to be reserved for this, just in case it might work. No, it's not a good approach. Barry On Thursday, July 11, 2013, Ted Lemon wrote: > On Jul 11, 2013, at 6:09 AM, Stephen Farrell > > wrote: > > Don't think its that easy. There could be >1 DKIM Signature header > > field and >1 AR header field. Also sounds quite hacky;-) > > Deleting headers is also hacky. Figuring out which headers are covered > by a DKIM signature, assuming MTAs that prepend headers, is pretty > straightforward=97you just see how many of a type of header were listed i= n > the DKIM signature, and consume that many from the header history, starti= ng > from the DKIM header. So yeah, it's hacky, and maybe it's not worth > doing, but I think it could be done and could work _if_ it were worth doi= ng. > > --001a11c2a0888f08c904e13b8707 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable There were, similarly, conversations in the DKIM WG about trying to reconst= ruct broken signatures through mailing lists by looking for a "[listna= me]" prefix on the Subject header and stripping it and retrying the si= g validation. =A0After discussion, the WG had clear consensus that any such= heuristics could be attempted, but NOT within the scope of the standard --= they were too dicey, leaving too many questions open (what if a spammer pr= epended "[my.bad.url]" to a signed message?).

This falls into the same category, and you're asking for= a new header field name to be reserved for this, just in case it might wor= k. =A0No, it's not a good approach.

Barry

On Thursday, July 11, 2013, Ted Lemon wrote:
On Jul 11, 2013, at 6:09 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
> Don't think its that easy. There could be >1 DKIM Signature hea= der
> field and >1 AR header field. Also sounds quite hacky;-)

Deleting headers is also hacky. =A0 Figuring out which headers are covered = by a DKIM signature, assuming MTAs that prepend headers, is pretty straight= forward=97you just see how many of a type of header were listed in the DKIM= signature, and consume that many from the header history, starting from th= e DKIM header. =A0 So yeah, it's hacky, and maybe it's not worth do= ing, but I think it could be done and could work _if_ it were worth doing.<= br>
--001a11c2a0888f08c904e13b8707-- From internet-drafts@ietf.org Thu Jul 11 06:56:30 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7C2811E8187; Thu, 11 Jul 2013 06:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id spveLiGpFD89; Thu, 11 Jul 2013 06:56:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AF17911E8185; Thu, 11 Jul 2013 06:56:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130711135627.20950.68136.idtracker@ietfa.amsl.com> Date: Thu, 11 Jul 2013 06:56:27 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc5451bis-10.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 13:56:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Working G= roup of the IETF. Title : Message Header Field for Indicating Message Authenticati= on Status Author(s) : Murray S. Kucherawy Filename : draft-ietf-appsawg-rfc5451bis-10.txt Pages : 47 Date : 2013-07-11 Abstract: This document specifies a message 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 use this header field to relay that information in a convenient and meaningful way to users, or make sorting and filtering decisions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc5451bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-rfc5451bis-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-rfc5451bis-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Thu Jul 11 06:56:32 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A296411E818D for ; Thu, 11 Jul 2013 06:56:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.435 X-Spam-Level: X-Spam-Status: No, score=-101.435 tagged_above=-999 required=5 tests=[AWL=-1.054, BAYES_00=-2.599, NO_RELAYS=-0.001, TVD_SPACE_RATIO=2.219, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6phR3vX2bk4T; Thu, 11 Jul 2013 06:56:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D54B11E8185; Thu, 11 Jul 2013 06:56:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-rfc5451bis@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: 4.51.p2 Message-ID: <20130711135631.20950.33464.idtracker@ietfa.amsl.com> Date: Thu, 11 Jul 2013 06:56:31 -0700 Subject: [apps-discuss] New Version Notification - draft-ietf-appsawg-rfc5451bis-10.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 13:56:32 -0000 A new version (-10) has been submitted for draft-ietf-appsawg-rfc5451bis: http://www.ietf.org/internet-drafts/draft-ietf-appsawg-rfc5451bis-10.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc5451bis/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-rfc5451bis-10 IETF Secretariat. From Ted.Lemon@nominum.com Thu Jul 11 07:33:57 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB1611E812C; Thu, 11 Jul 2013 07:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L33XHt23E+Bs; Thu, 11 Jul 2013 07:33:50 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id A05C711E8183; Thu, 11 Jul 2013 07:33:44 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKUd7CR3U4y3betmSyBS6TLf/eN1898t49@postini.com; Thu, 11 Jul 2013 07:33:45 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 E74481B81CF; Thu, 11 Jul 2013 07:33:42 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id DBDFA190052; Thu, 11 Jul 2013 07:33:42 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Thu, 11 Jul 2013 07:33:43 -0700 From: Ted Lemon To: Barry Leiba Thread-Topic: Ted Lemon's No Objection on draft-ietf-appsawg-rfc5451bis-09: (with COMMENT) Thread-Index: AQHOfh6x52ax2hqdmkeIC2hveaahBplf2QUAgAAEVwCAACMGgA== Date: Thu, 11 Jul 2013 14:33:41 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63077520AA1B@mbx-01.win.nominum.com> References: <20130711032917.15531.27251.idtracker@ietfa.amsl.com> <51DE8443.6080606@cs.tcd.ie> <8D23D4052ABE7A4490E77B1A012B63077520A3BE@mbx-01.win.nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "" , "" , The IESG , "" Subject: Re: [apps-discuss] Ted Lemon's No Objection on draft-ietf-appsawg-rfc5451bis-09: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jul 2013 14:33:57 -0000 On Jul 11, 2013, at 8:28 AM, Barry Leiba wrote: > There were, similarly, conversations in the DKIM WG about trying to recon= struct broken signatures through mailing lists by looking for a "[listname]= " prefix on the Subject header and stripping it and retrying the sig valida= tion. After discussion, the WG had clear consensus that any such heuristic= s could be attempted, but NOT within the scope of the standard -- they were= too dicey, leaving too many questions open (what if a spammer prepended "[= my.bad.url]" to a signed message?). >=20 > This falls into the same category, and you're asking for a new header fie= ld name to be reserved for this, just in case it might work. No, it's not = a good approach. In the case you are describing here, you are leaving something that is poss= ible as an exercise to the reader, because you don't want to advise anyone = to do it. This makes sense. In the case that we are talking about with = respect to the draft under review, the draft actually makes it _impossible_= to do the validation if the header is included in the signature. Another way to address this problem would be to just advise that DKIM imple= mentations _not_ sign this header. There's no reason why they should. T= hey probably don't, anyway. You could just add a subsection to the securi= ty considerations: 8.12 Signing Messages That Contain the Authentication-Results Header Field Email message signatures are usually generated somewhere within the ADMD wi= thin which an email message originates. In some cases these signatures ma= y be done after an Authentication-Results header field has been added. Th= is header field may be removed when the message is received by a transit AD= MD or the final destination ADMD. There would be no way, after that remov= al, to validate a signature that covered this header field. For this reas= on, MTAs that compute such signatures SHOULD NOT include this header field = in that computation. From barryleiba@gmail.com Thu Jul 11 07:45:29 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE69211E81B5; Thu, 11 Jul 2013 07:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.987 X-Spam-Level: X-Spam-Status: No, score=-101.987 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eu8q9kxsHZHk; Thu, 11 Jul 2013 07:45:28 -0700 (PDT) Received: from mail-qe0-x233.google.com (mail-qe0-x233.google.com [IPv6:2607:f8b0:400d:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 238C311E81AB; Thu, 11 Jul 2013 07:45:24 -0700 (PDT) Received: by mail-qe0-f51.google.com with SMTP id a11so4401646qen.24 for ; Thu, 11 Jul 2013 07:45:23 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=N2/11nNrlPPqCkML8pjzvtUvx63UgwqWH0XmgnPmDsI=; b=RQEC8i/9su6m1MdBQxmQpxDkUta8++BAKZjtAuiMGWJ2HvdumEhL8Bib3S72XaD2gM 5FEr5Oewd0q845gI/iauw3QDWnM7sSMB49bRGa977kn76Ck8i39AiHGCA7IKYKr76TtF nDUTr3mwsIRV0KLqdhsFPuHGEyRYG5gStJhFxdXKolFFnvmJ9bEpq35PglaZtF4MrjBM mi7IvQ2l3sA97fLgSzvaBLCgXTOfNyxA7nxhbn6oEI/l7UoMqWOnglH5WE2YNro8oKNG FkaRo50sQ76/l5xMeBXofeEIo19HYDUxVliAVVbxGrA2I63Q439nuNx/kNPnmIMXt/U1 G5uA== MIME-Version: 1.0 X-Received: by 10.224.103.138 with SMTP id k10mr16798107qao.42.1373553923517; Thu, 11 Jul 2013 07:45:23 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.224.216.201 with HTTP; Thu, 11 Jul 2013 07:45:23 -0700 (PDT) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077520AA1B@mbx-01.win.nominum.com> References: <20130711032917.15531.27251.idtracker@ietfa.amsl.com> <51DE8443.6080606@cs.tcd.ie> <8D23D4052ABE7A4490E77B1A012B63077520A3BE@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63077520AA1B@mbx-01.win.nominum.com> Date: Thu, 11 Jul 2013 10:45:23 -0400 X-Google-Sender-Auth: mnNmifSUxARt8YiX4JQrdjp6x5M Message-ID: From: Barry Leiba To: Ted Lemon Content-Type: text/plain; charset=ISO-8859-1 Cc: "" , "" , "" , The IESG , "" Subject: Re: [apps-discuss] Ted Lemon's No Objection on draft-ietf-appsawg-rfc5451bis-09: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jul 2013 14:45:30 -0000 > Another way to address this problem would be to just advise that DKIM implementations > _not_ sign this header. There's no reason why they should. They probably don't, > anyway. You could just add a subsection to the security considerations: > > 8.12 Signing Messages That Contain the Authentication-Results Header Field > > Email message signatures are usually generated somewhere within the ADMD within > which an email message originates. In some cases these signatures may be done > after an Authentication-Results header field has been added. This header field may > be removed when the message is received by a transit ADMD or the final destination > ADMD. There would be no way, after that removal, to validate a signature that covered > this header field. For this reason, MTAs that compute such signatures SHOULD NOT > include this header field in that computation. Now, that sounds like a reasonable approach. Murray, what do you think? Even if "SHOULD NOT" is too strong, it would be a good idea to lay out the problem and advise against signing A-R header fields. Barry From stephen.farrell@cs.tcd.ie Thu Jul 11 07:50:42 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5489821F9A6A; Thu, 11 Jul 2013 07:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.483 X-Spam-Level: X-Spam-Status: No, score=-102.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ru0QKsdU5H7A; Thu, 11 Jul 2013 07:50:36 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 54FB011E81CD; Thu, 11 Jul 2013 07:50:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 91F5EBE8A; Thu, 11 Jul 2013 15:50:12 +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 NkN4F2lpLxq8; Thu, 11 Jul 2013 15:50:11 +0100 (IST) Received: from [10.87.48.9] (unknown [86.42.17.76]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 1F378BEC3; Thu, 11 Jul 2013 15:50:11 +0100 (IST) Message-ID: <51DEC622.8060506@cs.tcd.ie> Date: Thu, 11 Jul 2013 15:50:10 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Barry Leiba References: <20130711032917.15531.27251.idtracker@ietfa.amsl.com> <51DE8443.6080606@cs.tcd.ie> <8D23D4052ABE7A4490E77B1A012B63077520A3BE@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63077520AA1B@mbx-01.win.nominum.com> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "" , "" , "" , The IESG , "" , Ted Lemon Subject: Re: [apps-discuss] Ted Lemon's No Objection on draft-ietf-appsawg-rfc5451bis-09: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jul 2013 14:50:42 -0000 On 07/11/2013 03:45 PM, Barry Leiba wrote: >> Another way to address this problem would be to just advise that DKIM implementations >> _not_ sign this header. There's no reason why they should. They probably don't, >> anyway. You could just add a subsection to the security considerations: >> >> 8.12 Signing Messages That Contain the Authentication-Results Header Field >> >> Email message signatures are usually generated somewhere within the ADMD within >> which an email message originates. In some cases these signatures may be done >> after an Authentication-Results header field has been added. This header field may >> be removed when the message is received by a transit ADMD or the final destination >> ADMD. There would be no way, after that removal, to validate a signature that covered >> this header field. For this reason, MTAs that compute such signatures SHOULD NOT >> include this header field in that computation. > > Now, that sounds like a reasonable approach. Murray, what do you > think? Even if "SHOULD NOT" is too strong, it would be a good idea to > lay out the problem and advise against signing A-R header fields. Is that reasonable? Wasn't there a use-case (call it "foo") where the recipient MTA would e.g. verify DKIM from the originator, then add its own AR and then DKIM sign the lot for internal consumption so internal MTAs or UAs could trust the AR header field based on the DKIM signature of their own ADMD. Or did it turn out nobody wanted that? Even if so, I'd say the above reads too much like preventing the foo use-case. But you could reword around that easily enough I guess. S. > > Barry > From scott@kitterman.com Thu Jul 11 07:51:30 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB3AF21F9A96 for ; Thu, 11 Jul 2013 07:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FMhbQGN34CgQ for ; Thu, 11 Jul 2013 07:51:25 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 12BC711E8194 for ; Thu, 11 Jul 2013 07:51:16 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 4E9A920E40D5; Thu, 11 Jul 2013 10:51:14 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1373554274; bh=b58Tcz5FRE63h8qR22OhrPKZmuoMrC3oJt0a3WB0nLU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=ih2J6Wmmif5C4cqs8/NblQ8x+cFX+3JZEqU9n3S2SAoivzk0FqITol+n3wewoanDP n95Ltzn6a/D2Uj9lGPovF2f8KEI/JHgEpFcvuRIUqdagiYVvLQqU9EC8d1BEJ92VdB QA3DrgjdpPN0z6xYILqNYTdMXbjRkLfdwRAZBz78= 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 mailout02.controlledmail.com (Postfix) with ESMTPSA id 33F0D20E4079; Thu, 11 Jul 2013 10:51:13 -0400 (EDT) From: Scott Kitterman To: apps-discuss@ietf.org Date: Thu, 11 Jul 2013 10:51:13 -0400 Message-ID: <3807645.iUPu0daJeD@scott-latitude-e6320> User-Agent: KMail/4.10.4 (Linux/3.8.0-26-generic; KDE/4.10.4; i686; ; ) In-Reply-To: References: <20130711032917.15531.27251.idtracker@ietfa.amsl.com> <8D23D4052ABE7A4490E77B1A012B63077520AA1B@mbx-01.win.nominum.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [apps-discuss] Ted Lemon's No Objection on draft-ietf-appsawg-rfc5451bis-09: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jul 2013 14:51:30 -0000 On Thursday, July 11, 2013 10:45:23 AM Barry Leiba wrote: > > Another way to address this problem would be to just advise that DKIM > > implementations _not_ sign this header. There's no reason why they > > should. They probably don't, anyway. You could just add a subsection > > to the security considerations: > > > > 8.12 Signing Messages That Contain the Authentication-Results Header Field > > > > Email message signatures are usually generated somewhere within the ADMD > > within which an email message originates. In some cases these > > signatures may be done after an Authentication-Results header field has > > been added. This header field may be removed when the message is > > received by a transit ADMD or the final destination ADMD. There would > > be no way, after that removal, to validate a signature that covered this > > header field. For this reason, MTAs that compute such signatures SHOULD > > NOT include this header field in that computation. > > Now, that sounds like a reasonable approach. Murray, what do you > think? Even if "SHOULD NOT" is too strong, it would be a good idea to > lay out the problem and advise against signing A-R header fields. Except, if I get an A-R header field that's signed by an entity I trust, I can trust that field. I think mediators signing them is a good thing so that receiving ADMDs can consider them if they trust the mediator. If there's something not to do here, I'd think it would be don't remove signed header fields and break signatures. Scott K From Ted.Lemon@nominum.com Thu Jul 11 08:21:47 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCE7621F9C32; Thu, 11 Jul 2013 08:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.589 X-Spam-Level: X-Spam-Status: No, score=-106.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1t0Jkd34XYAu; Thu, 11 Jul 2013 08:21:41 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id AF13621F9B79; Thu, 11 Jul 2013 08:21:32 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKUd7NdoRa2PQluCVX1i6oz2MRiQ4FDqfY@postini.com; Thu, 11 Jul 2013 08:21:32 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 A874B1B8240; Thu, 11 Jul 2013 08:21:26 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 5B792190052; Thu, 11 Jul 2013 08:21:25 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Thu, 11 Jul 2013 08:21:19 -0700 From: Ted Lemon To: Stephen Farrell Thread-Topic: Ted Lemon's No Objection on draft-ietf-appsawg-rfc5451bis-09: (with COMMENT) Thread-Index: AQHOfh6x52ax2hqdmkeIC2hveaahBplf2QUAgAAEVwCAACMGgIAAA0WAgAABVgCAAAixgA== Date: Thu, 11 Jul 2013 15:21:18 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63077520ACEB@mbx-01.win.nominum.com> References: <20130711032917.15531.27251.idtracker@ietfa.amsl.com> <51DE8443.6080606@cs.tcd.ie> <8D23D4052ABE7A4490E77B1A012B63077520A3BE@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63077520AA1B@mbx-01.win.nominum.com> <51DEC622.8060506@cs.tcd.ie> In-Reply-To: <51DEC622.8060506@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <28A8F32BB40E114BA5AC6EB2705A8928@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "" , "" , The IESG , "" , Barry Leiba Subject: Re: [apps-discuss] Ted Lemon's No Objection on draft-ietf-appsawg-rfc5451bis-09: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jul 2013 15:21:48 -0000 On Jul 11, 2013, at 10:50 AM, Stephen Farrell w= rote: > Is that reasonable? Wasn't there a use-case (call it "foo") where > the recipient MTA would e.g. verify DKIM from the originator, then > add its own AR and then DKIM sign the lot for internal consumption > so internal MTAs or UAs could trust the AR header field based on > the DKIM signature of their own ADMD. Why would a message with the second DKIM signature make it out of the ADMD? From stephen.farrell@cs.tcd.ie Thu Jul 11 08:29:06 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 434D021F9CF6; Thu, 11 Jul 2013 08:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.512 X-Spam-Level: X-Spam-Status: No, score=-102.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YCn3XMtJHvP9; Thu, 11 Jul 2013 08:28:57 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id A9B1121F9DA5; Thu, 11 Jul 2013 08:28:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7490FBEC6; Thu, 11 Jul 2013 16:28:23 +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 8ca7hiBKCq8D; Thu, 11 Jul 2013 16:28:22 +0100 (IST) Received: from [10.87.48.9] (unknown [86.42.17.76]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E9218BEC0; Thu, 11 Jul 2013 16:28:21 +0100 (IST) Message-ID: <51DECF0B.4090506@cs.tcd.ie> Date: Thu, 11 Jul 2013 16:28:11 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Ted Lemon References: <20130711032917.15531.27251.idtracker@ietfa.amsl.com> <51DE8443.6080606@cs.tcd.ie> <8D23D4052ABE7A4490E77B1A012B63077520A3BE@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63077520AA1B@mbx-01.win.nominum.com> <51DEC622.8060506@cs.tcd.ie> <8D23D4052ABE7A4490E77B1A012B63077520ACEB@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077520ACEB@mbx-01.win.nominum.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "" , "" , "" , The IESG , "" , Barry Leiba Subject: Re: [apps-discuss] Ted Lemon's No Objection on draft-ietf-appsawg-rfc5451bis-09: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jul 2013 15:29:06 -0000 On 07/11/2013 04:21 PM, Ted Lemon wrote: > On Jul 11, 2013, at 10:50 AM, Stephen Farrell wrote: >> Is that reasonable? Wasn't there a use-case (call it "foo") where >> the recipient MTA would e.g. verify DKIM from the originator, then >> add its own AR and then DKIM sign the lot for internal consumption >> so internal MTAs or UAs could trust the AR header field based on >> the DKIM signature of their own ADMD. > > Why would a message with the second DKIM signature make it out of the ADMD? That's not the intent. The 2nd sig would be intended for consumption within the ADMD only. I guess a .vacation or something might mess with that though. S. > From Ted.Lemon@nominum.com Thu Jul 11 08:35:08 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F60421F9E0C; Thu, 11 Jul 2013 08:35:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.589 X-Spam-Level: X-Spam-Status: No, score=-106.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fjOApuVvxroe; Thu, 11 Jul 2013 08:35:01 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id 188F521F9AC2; Thu, 11 Jul 2013 08:35:01 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKUd7QpJU7IvP1l3zHpdkks83+2lEspWpq@postini.com; Thu, 11 Jul 2013 08:35:01 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 9CC981B822C; Thu, 11 Jul 2013 08:35:00 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 91C23190052; Thu, 11 Jul 2013 08:35:00 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Thu, 11 Jul 2013 08:35:00 -0700 From: Ted Lemon To: Stephen Farrell Thread-Topic: Ted Lemon's No Objection on draft-ietf-appsawg-rfc5451bis-09: (with COMMENT) Thread-Index: AQHOfh6x52ax2hqdmkeIC2hveaahBplf2QUAgAAEVwCAACMGgIAAA0WAgAABVgCAAAixgIAAAe6AgAAB5oA= Date: Thu, 11 Jul 2013 15:35:00 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63077520AE00@mbx-01.win.nominum.com> References: <20130711032917.15531.27251.idtracker@ietfa.amsl.com> <51DE8443.6080606@cs.tcd.ie> <8D23D4052ABE7A4490E77B1A012B63077520A3BE@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63077520AA1B@mbx-01.win.nominum.com> <51DEC622.8060506@cs.tcd.ie> <8D23D4052ABE7A4490E77B1A012B63077520ACEB@mbx-01.win.nominum.com> <51DECF0B.4090506@cs.tcd.ie> In-Reply-To: <51DECF0B.4090506@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <8560B83B7795DA45B9FE8B3498C62788@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "" , "" , The IESG , "" , Barry Leiba Subject: Re: [apps-discuss] Ted Lemon's No Objection on draft-ietf-appsawg-rfc5451bis-09: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jul 2013 15:35:08 -0000 On Jul 11, 2013, at 11:28 AM, Stephen Farrell w= rote: > I guess a .vacation or something might mess with that though. Best is the enemy of good enough? :) From barryleiba@gmail.com Thu Jul 11 08:47:02 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3205421F9DDC; Thu, 11 Jul 2013 08:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.987 X-Spam-Level: X-Spam-Status: No, score=-101.987 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2++nG8UXmsqj; Thu, 11 Jul 2013 08:47:01 -0700 (PDT) Received: from mail-qe0-x232.google.com (mail-qe0-x232.google.com [IPv6:2607:f8b0:400d:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE0B21F9E59; Thu, 11 Jul 2013 08:46:58 -0700 (PDT) Received: by mail-qe0-f50.google.com with SMTP id f6so4543871qej.9 for ; Thu, 11 Jul 2013 08:46:57 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=+8gqtPMsQ1TYpOj4c9kDPASXqZg1MR+nPw8PCdQW2X8=; b=lmY2wgCUd6x/mfEF+VUpT2pJ8iNzdeHfRv/t0xEjuqguWAmiZGvLEgkrTaa400U9xp qDbQ9rZnaGX8AsgclhukrFN1rA4hCUWd2i7AE6uoGokBqdgDcms/SVorhrQf3IeydWvJ iG1c1dJeHZhZKPDk6zhYdeYyc4Olk+/pka7HEBz96HsizvReM/Ya+Vuun0SVQtI2OPQV PtN7AMQoSDVZFCJhF0qZcgjNVhydTfgpr0YMfCFaNCVoVJ/jRblTXha+R2Cf+hvCC4s7 ljjeaWyst5O9xWDIf1MLevBiH96GInrvxQwSw2d3NNHr87m2FLRDfp/vkuOeIOS7CCVh nLdA== MIME-Version: 1.0 X-Received: by 10.49.35.34 with SMTP id e2mr30764383qej.67.1373557617662; Thu, 11 Jul 2013 08:46:57 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.224.216.201 with HTTP; Thu, 11 Jul 2013 08:46:57 -0700 (PDT) In-Reply-To: <51DEC622.8060506@cs.tcd.ie> References: <20130711032917.15531.27251.idtracker@ietfa.amsl.com> <51DE8443.6080606@cs.tcd.ie> <8D23D4052ABE7A4490E77B1A012B63077520A3BE@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63077520AA1B@mbx-01.win.nominum.com> <51DEC622.8060506@cs.tcd.ie> Date: Thu, 11 Jul 2013 11:46:57 -0400 X-Google-Sender-Auth: qbNFh_dBLJUblspHXEoB2hOdS_w Message-ID: From: Barry Leiba To: Stephen Farrell Content-Type: text/plain; charset=ISO-8859-1 Cc: "" , "" , "" , The IESG , "" , Ted Lemon Subject: Re: [apps-discuss] Ted Lemon's No Objection on draft-ietf-appsawg-rfc5451bis-09: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jul 2013 15:47:02 -0000 >>> Another way to address this problem would be to just advise that DKIM implementations >>> _not_ sign this header. There's no reason why they should. They probably don't, >>> anyway. You could just add a subsection to the security considerations: >>> >>> 8.12 Signing Messages That Contain the Authentication-Results Header Field >>> >>> Email message signatures are usually generated somewhere within the ADMD within >>> which an email message originates. In some cases these signatures may be done >>> after an Authentication-Results header field has been added. This header field may >>> be removed when the message is received by a transit ADMD or the final destination >>> ADMD. There would be no way, after that removal, to validate a signature that covered >>> this header field. For this reason, MTAs that compute such signatures SHOULD NOT >>> include this header field in that computation. >> >> Now, that sounds like a reasonable approach. Murray, what do you >> think? Even if "SHOULD NOT" is too strong, it would be a good idea to >> lay out the problem and advise against signing A-R header fields. > > Is that reasonable? Wasn't there a use-case (call it "foo") where > the recipient MTA would e.g. verify DKIM from the originator, then > add its own AR and then DKIM sign the lot for internal consumption > so internal MTAs or UAs could trust the AR header field based on > the DKIM signature of their own ADMD. > > Or did it turn out nobody wanted that? Even if so, I'd say the above > reads too much like preventing the foo use-case. But you could reword > around that easily enough I guess. Right, which is why I said that "SHOULD NOT" might (or might not) be too strong. Let's see what Murray's response is before we wrap ourselves up on this. Barry From dhc@dcrocker.net Thu Jul 11 09:15:07 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE45C21F99FE; Thu, 11 Jul 2013 09:15:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.594 X-Spam-Level: X-Spam-Status: No, score=-6.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A9KqzcY6b3Sj; Thu, 11 Jul 2013 09:15:02 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1E7A821F9FE3; Thu, 11 Jul 2013 09:14:03 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r6BGDcen011808 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 11 Jul 2013 09:13:41 -0700 Message-ID: <51DED998.8080300@dcrocker.net> Date: Thu, 11 Jul 2013 09:13:12 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Ted Lemon References: <20130711032917.15531.27251.idtracker@ietfa.amsl.com> <51DE8443.6080606@cs.tcd.ie> <8D23D4052ABE7A4490E77B1A012B63077520A3BE@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63077520AA1B@mbx-01.win.nominum.com> <51DEC622.8060506@cs.tcd.ie> <8D23D4052ABE7A4490E77B1A012B63077520ACEB@mbx-01.win.nominum.com> <51DECF0B.4090506@cs.tcd.ie> <8D23D4052ABE7A4490E77B1A012B63077520AE00@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077520AE00@mbx-01.win.nominum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Thu, 11 Jul 2013 09:13:42 -0700 (PDT) Cc: "" , "" , "" , The IESG , "" , Barry Leiba Subject: Re: [apps-discuss] Ted Lemon's No Objection on draft-ietf-appsawg-rfc5451bis-09: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 16:15:08 -0000 On 7/11/2013 8:35 AM, Ted Lemon wrote: > On Jul 11, 2013, at 11:28 AM, Stephen Farrell wrote: >> I guess a .vacation or something might mess with that though. > > Best is the enemy of good enough? :) Sorry, but that's not the issue at all. Arbitrary restrictions is the enemy of everything. The assertion about who signs and why might have some operational validity, but none of it is a requirement. The fact that things are most typically done a certain way is not justification for prohibiting other ways. Anyone along the path may sign and there are reasonable scenarios that can be described with signing by other than the originating ADMD. Don't impose arbitrary restrictions. Signing makes sense at any 'interesting' point of transition. Email has quite a few interesting transition points, for some real-world scenarios. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From ietf-secretariat-reply@ietf.org Thu Jul 11 10:14:26 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8627721F9F17 for ; Thu, 11 Jul 2013 10:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SNzscxPm+1Ho; Thu, 11 Jul 2013 10:14:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 94B2A21F9F1D; Thu, 11 Jul 2013 10:14:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-rfc5451bis@tools.ietf.org, sm+ietf@elandsys.com, apps-discuss@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130711171424.9327.22796.idtracker@ietfa.amsl.com> Date: Thu, 11 Jul 2013 10:14:24 -0700 From: IETF Secretariat Subject: [apps-discuss] ID Tracker State Update Notice: X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jul 2013 17:14:26 -0000 State changed to Approved-announcement to be sent::Point Raised - writeup n= eeded from IESG Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc5451b= is/ From superuser@gmail.com Thu Jul 11 10:48:14 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9447021F9346; Thu, 11 Jul 2013 10:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27n8A3J+g3ux; Thu, 11 Jul 2013 10:48:13 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 21BC821F9E59; Thu, 11 Jul 2013 10:48:10 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id ey16so13948519wid.5 for ; Thu, 11 Jul 2013 10:48:05 -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=GXfAYIcGfnmdGoxd06G0SomfyZmjXhh3qNknVmLtRiw=; b=pPjbIhkXt6gAi7Ff1rtDoVZz8YLFTgc1jdZBmcaa4Q4ML75L56UjP9kDdtF/9RpAju Zx7m0IAy0js3DEac8tFwAZ4wM4n56TkrlY8NhkEbWRyU3GDLAzL2+q8Ck34/Kok5Idga zaFPbyGpKoEM+I4Y0MbanbrUD7sU0EXqrAs+gytySsEIwbg9DV/4BkXDpZ2ptzh8TuJE Lg1kVjPiXV6hDt0FDNAxxfXI9+DPAHi1sDXi56ryRvaqN5UV5PoiiIwUsa9UagL+J/kH SKrtnI/w6X01JJA7KXR53kvnJ/BTxY3NcJNADBaf+0ZSAGhVSJBhLzeCkDy59D6OAGXS uVyg== MIME-Version: 1.0 X-Received: by 10.194.48.116 with SMTP id k20mr22172943wjn.23.1373564885898; Thu, 11 Jul 2013 10:48:05 -0700 (PDT) Received: by 10.180.90.16 with HTTP; Thu, 11 Jul 2013 10:48:05 -0700 (PDT) In-Reply-To: References: <20130711032917.15531.27251.idtracker@ietfa.amsl.com> <51DE8443.6080606@cs.tcd.ie> <8D23D4052ABE7A4490E77B1A012B63077520A3BE@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63077520AA1B@mbx-01.win.nominum.com> <51DEC622.8060506@cs.tcd.ie> Date: Thu, 11 Jul 2013 10:48:05 -0700 Message-ID: From: "Murray S. Kucherawy" To: Barry Leiba Content-Type: multipart/alternative; boundary=047d7ba975e6199d0204e13fff7f Cc: "" , "" , "" , The IESG , "" , Ted Lemon Subject: Re: [apps-discuss] Ted Lemon's No Objection on draft-ietf-appsawg-rfc5451bis-09: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jul 2013 17:48:14 -0000 --047d7ba975e6199d0204e13fff7f Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jul 11, 2013 at 8:46 AM, Barry Leiba wrote: > >>> 8.12 Signing Messages That Contain the Authentication-Results Header > Field > >>> > >>> Email message signatures are usually generated somewhere within the > ADMD within > >>> which an email message originates. In some cases these signatures > may be done > >>> after an Authentication-Results header field has been added. This > header field may > >>> be removed when the message is received by a transit ADMD or the final > destination > >>> ADMD. There would be no way, after that removal, to validate a > signature that covered > >>> this header field. For this reason, MTAs that compute such > signatures SHOULD NOT > >>> include this header field in that computation. > >> > >> Now, that sounds like a reasonable approach. Murray, what do you > >> think? Even if "SHOULD NOT" is too strong, it would be a good idea to > >> lay out the problem and advise against signing A-R header fields. > > > > Is that reasonable? Wasn't there a use-case (call it "foo") where > > the recipient MTA would e.g. verify DKIM from the originator, then > > add its own AR and then DKIM sign the lot for internal consumption > > so internal MTAs or UAs could trust the AR header field based on > > the DKIM signature of their own ADMD. > > > > Or did it turn out nobody wanted that? Even if so, I'd say the above > > reads too much like preventing the foo use-case. But you could reword > > around that easily enough I guess. > > Right, which is why I said that "SHOULD NOT" might (or might not) be > too strong. Let's see what Murray's response is before we wrap > ourselves up on this. > > Stephen stated the use case, which is also described in Section 8.1, first bullet. An operational environment might not be able to remove fake ones at the border reliably, so one way to deal with that is to add your A-R field and sign it, then send it inbound toward delivery. An MUA or other internal agent could verify that one (by matching the "d=" against a list of trusted signers) and thus confirm that the content of the last one added can be trusted. To ensure its meaning is isolated, the "d=" domain in such a signature could be one that only resolves within that ADMD. I could add this last point to that first bullet in Section 8.1. You're right, though, that such a signature out in the wild could be (or is likely to be) invalidated. According to DKIM, however, that just means it would be ignored by receivers, making it harmless added bulk. -MSK --047d7ba975e6199d0204e13fff7f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Jul 11, 2013 at 8:46 AM, Barry Leiba <barry= leiba@computer.org> wrote:
>= >> 8.12 Signing Messages That Contain the Authentication-Results Head= er Field
>>>
>>> Email message signatures are usually generated somewhere withi= n the ADMD within
>>> which an email message originates. =A0 In some cases these sig= natures may be done
>>> after an Authentication-Results header field has been added. = =A0 This header field may
>>> be removed when the message is received by a transit ADMD or t= he final destination
>>> ADMD. =A0 There would be no way, after that removal, to valida= te a signature that covered
>>> this header field. =A0 For this reason, MTAs that compute such= signatures SHOULD NOT
>>> include this header field in that computation.
>>
>> Now, that sounds like a reasonable approach. =A0Murray, what do yo= u
>> think? =A0Even if "SHOULD NOT" is too strong, it would b= e a good idea to
>> lay out the problem and advise against signing A-R header fields.<= br> >
> Is that reasonable? Wasn't there a use-case (call it "foo&quo= t;) where
> the recipient MTA would e.g. verify DKIM from the originator, then
> add its own AR and then DKIM sign the lot for internal consumption
> so internal MTAs or UAs could trust the AR header field based on
> the DKIM signature of their own ADMD.
>
> Or did it turn out nobody wanted that? Even if so, I'd say the abo= ve
> reads too much like preventing the foo use-case. But you could reword<= br> > around that easily enough I guess.

Right, which is why I said that "SHOULD NOT" might (o= r might not) be
too strong. =A0Let's see what Murray's response is before we wrap ourselves up on this.

=A0
Stephen stated the use case, which is also described = in Section 8.1, first bullet.=A0 An operational environment might not be ab= le to remove fake ones at the border reliably, so one way to deal with that= is to add your A-R field and sign it, then send it inbound toward delivery= .=A0 An MUA or other internal agent could verify that one (by matching the = "d=3D" against a list of trusted signers) and thus confirm that t= he content of the last one added can be trusted.=A0 To ensure its meaning i= s isolated, the "d=3D" domain in such a signature could be one th= at only resolves within that ADMD.=A0 I could add this last point to that f= irst bullet in Section 8.1.

You're right, though, that such a signature out in the w= ild could be (or is likely to be) invalidated.=A0 According to DKIM, howeve= r, that just means it would be ignored by receivers, making it harmless add= ed bulk.

-MSK
--047d7ba975e6199d0204e13fff7f-- From Ted.Lemon@nominum.com Thu Jul 11 10:52:07 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 237A821F9DD0; Thu, 11 Jul 2013 10:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.589 X-Spam-Level: X-Spam-Status: No, score=-106.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N22-S3LQOdWg; Thu, 11 Jul 2013 10:52:00 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id C644D21F9DC7; Thu, 11 Jul 2013 10:51:59 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKUd7wucmk0Vc7yWHn16v7110MGrN2mfAD@postini.com; Thu, 11 Jul 2013 10:51:59 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 E60ED1B822F; Thu, 11 Jul 2013 10:51:52 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id C8A67190052; Thu, 11 Jul 2013 10:51:52 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Thu, 11 Jul 2013 10:51:52 -0700 From: Ted Lemon To: "Murray S. Kucherawy" Thread-Topic: Ted Lemon's No Objection on draft-ietf-appsawg-rfc5451bis-09: (with COMMENT) Thread-Index: AQHOfh6x52ax2hqdmkeIC2hveaahBplf2QUAgAAEVwCAACMGgIAAA0WAgAABVgCAAA/dgIAAIdiAgAABDwA= Date: Thu, 11 Jul 2013 17:51:52 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63077520B456@mbx-01.win.nominum.com> References: <20130711032917.15531.27251.idtracker@ietfa.amsl.com> <51DE8443.6080606@cs.tcd.ie> <8D23D4052ABE7A4490E77B1A012B63077520A3BE@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63077520AA1B@mbx-01.win.nominum.com> <51DEC622.8060506@cs.tcd.ie> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <5555DEE42A43574A8B4D43A05AC71605@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "" , "" , The IESG , "" , Barry Leiba Subject: Re: [apps-discuss] Ted Lemon's No Objection on draft-ietf-appsawg-rfc5451bis-09: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jul 2013 17:52:07 -0000 On Jul 11, 2013, at 1:48 PM, "Murray S. Kucherawy" wr= ote: > You're right, though, that such a signature out in the wild could be (or = is likely to be) invalidated. According to DKIM, however, that just means = it would be ignored by receivers, making it harmless added bulk. True enough. And I suppose and end-to-end signature would never have this= header field in it, so it wouldn't be an issue for that sort of applicatio= n. From barryleiba@gmail.com Thu Jul 11 11:12:03 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3329121F9F7E; Thu, 11 Jul 2013 11:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.987 X-Spam-Level: X-Spam-Status: No, score=-101.987 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sq7f+cLsi-yH; Thu, 11 Jul 2013 11:12:02 -0700 (PDT) Received: from mail-qe0-x22c.google.com (mail-qe0-x22c.google.com [IPv6:2607:f8b0:400d:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 9968821F9F76; Thu, 11 Jul 2013 11:12:02 -0700 (PDT) Received: by mail-qe0-f44.google.com with SMTP id 5so4640920qeb.31 for ; Thu, 11 Jul 2013 11:12:02 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=GKZXX6MZ8YKM7Y/nXDeO+VYtrEerCkWFkVn+ASF3oqk=; b=thRLXlxvdiwd+I3/uAD3Ie6SJ9pCOIFrapKAhygxpWHosFBDpbFlLZ5zieBY097PI3 NmfmqFA94quosh7dC4NGCK9V8fBiTQsYIxbMxBNhkZA8xJKeGhqd/N5/Zz/oOlZlR7g6 bs2Cg0fu1RqQBb2FXfuCMSVHTcTCm9geGF7wqnFUgGxj97oAxYLQY6AWb+/ilPV99RCd WpPIOmutC8uu1GX25rmf06W4TR2jjfO35K6FcGdMHhkIuiSTOa44n0lrNZT2ouko3XSa Rf75BxhNnomWYUq2V9mm0bFxV9iN2sOPN5tz1bhTGEqpR7WPyeTya/7xzAdzZMAyRl5a uMfg== MIME-Version: 1.0 X-Received: by 10.49.132.69 with SMTP id os5mr31912013qeb.48.1373566321996; Thu, 11 Jul 2013 11:12:01 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.224.216.201 with HTTP; Thu, 11 Jul 2013 11:12:01 -0700 (PDT) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077520B456@mbx-01.win.nominum.com> References: <20130711032917.15531.27251.idtracker@ietfa.amsl.com> <51DE8443.6080606@cs.tcd.ie> <8D23D4052ABE7A4490E77B1A012B63077520A3BE@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63077520AA1B@mbx-01.win.nominum.com> <51DEC622.8060506@cs.tcd.ie> <8D23D4052ABE7A4490E77B1A012B63077520B456@mbx-01.win.nominum.com> Date: Thu, 11 Jul 2013 14:12:01 -0400 X-Google-Sender-Auth: RR8QAMsA0BfQ2KoboCgR3h59GQo Message-ID: From: Barry Leiba To: Ted Lemon Content-Type: text/plain; charset=ISO-8859-1 Cc: "" , "" , "" , The IESG , "" Subject: Re: [apps-discuss] Ted Lemon's No Objection on draft-ietf-appsawg-rfc5451bis-09: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jul 2013 18:12:03 -0000 >> You're right, though, that such a signature out in the wild could be (or is likely to be) > invalidated. According to DKIM, however, that just means it would be ignored by > receivers, making it harmless added bulk. > > True enough. And I suppose and end-to-end signature would never have this header > field in it, so it wouldn't be an issue for that sort of application. OK, so... Are we done with this chat, then? Any text change, or are we set? Barry From Ted.Lemon@nominum.com Thu Jul 11 12:22:02 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97B7B21F9B5C; Thu, 11 Jul 2013 12:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.589 X-Spam-Level: X-Spam-Status: No, score=-106.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xBMIQrkcZIy8; Thu, 11 Jul 2013 12:21:54 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id 2701C21F9A25; Thu, 11 Jul 2013 12:21:54 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKUd8Fz8LOHmeGBkpMTwezZty7VaVDeFW2@postini.com; Thu, 11 Jul 2013 12:21:54 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 808941B823F; Thu, 11 Jul 2013 12:21:50 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 31F65190052; Thu, 11 Jul 2013 12:21:49 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Thu, 11 Jul 2013 12:21:49 -0700 From: Ted Lemon To: Barry Leiba Thread-Topic: Ted Lemon's No Objection on draft-ietf-appsawg-rfc5451bis-09: (with COMMENT) Thread-Index: AQHOfh6x52ax2hqdmkeIC2hveaahBplf2QUAgAAEVwCAACMGgIAAA0WAgAABVgCAAA/dgIAAIdiAgAABDwCAAAWhgIAAE38A Date: Thu, 11 Jul 2013 19:21:48 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63077520B835@mbx-01.win.nominum.com> References: <20130711032917.15531.27251.idtracker@ietfa.amsl.com> <51DE8443.6080606@cs.tcd.ie> <8D23D4052ABE7A4490E77B1A012B63077520A3BE@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63077520AA1B@mbx-01.win.nominum.com> <51DEC622.8060506@cs.tcd.ie> <8D23D4052ABE7A4490E77B1A012B63077520B456@mbx-01.win.nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <69DCF704BE588D478827D20D8248BFB1@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "" , "" , The IESG , "" Subject: Re: [apps-discuss] Ted Lemon's No Objection on draft-ietf-appsawg-rfc5451bis-09: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jul 2013 19:22:02 -0000 On Jul 11, 2013, at 1:58 PM, "Murray S. Kucherawy" wr= ote: > Would you like that remark about an internal-only domain name added, or a= re we good to go without? I realize it's a non-blocking issue anyway but I= do like to be accommodating. You guys are the experts. If you think there's any value to be added by i= ncluding the text, please do. If you think it's just silly, don't let me = push you into it. I pointed out the issue because I saw a technical hole,= not because I have the kind of experience that would provide guidance as t= o how much that hole matters. It's certainly not a security issue. [sorry, accidentally sent this just to Murray] From ietf-secretariat-reply@ietf.org Thu Jul 11 12:30:28 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7161A21F9EB3 for ; Thu, 11 Jul 2013 12:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xcVrth7dBmzK; Thu, 11 Jul 2013 12:30:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AFE3F21F9E72; Thu, 11 Jul 2013 12:30:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-rfc5451bis@tools.ietf.org, sm+ietf@elandsys.com, apps-discuss@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130711193027.29512.66542.idtracker@ietfa.amsl.com> Date: Thu, 11 Jul 2013 12:30:27 -0700 From: IETF Secretariat Subject: [apps-discuss] ID Tracker State Update Notice: X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jul 2013 19:30:28 -0000 State changed to Approved-announcement to be sent from Approved-announcemen= t to be sent::Point Raised - writeup needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc5451b= is/ From johnl@iecc.com Thu Jul 11 13:08:13 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF7F21F9EB3 for ; Thu, 11 Jul 2013 13:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.695 X-Spam-Level: X-Spam-Status: No, score=-110.695 tagged_above=-999 required=5 tests=[AWL=0.504, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 39BJAqo556l6 for ; Thu, 11 Jul 2013 13:08:09 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 09FA521F9ECA for ; Thu, 11 Jul 2013 13:08:08 -0700 (PDT) Received: (qmail 25374 invoked from network); 11 Jul 2013 20:07:58 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 11 Jul 2013 20:07:58 -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=51df109e.xn--i8sz2z.k1307; i=johnl@user.iecc.com; bh=gHcCbg9O2gseRfsDxEqKaNuJ9ya2L2JxKmkXk0kLuRk=; b=WlcB1O4vjSM67iFvWLQAGnTCne3EEaCz9jjgEtsaDSBXDoXGlteKDSGcvwQmcPXqFn6IGUPmeYIRT45XPr6YEtNzAw7tHHgrMdnXyjVLG8THdZ9zhff7GGmfMwvzzemj4VWt/XI0Q2iC19uBWhHjMkn8eWNjVkvEtTbsLbNR8EB9eAVGYedRm1mm/oZKu6omgKYNPVpXJg4lf9IdQlJx06RvwkcLkk1XEbhnqKFDVsCFvmd/cDS8CIDJdX1DHZcx 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=51df109e.xn--i8sz2z.k1307; olt=johnl@user.iecc.com; bh=gHcCbg9O2gseRfsDxEqKaNuJ9ya2L2JxKmkXk0kLuRk=; b=eX9kUt3261NAFDYaebm5s3YOmqOWEieqFSodX7O2tJ3GBaushF8prsRqvCPsH2JN080goTKjgE1AKAAxdq7XEc6wAJeu7C1JRKr163kJz9lrxnc8cEFwCqey7f5K4xQoS5It8Es+RlrmNjvcL/QToQmKPVy9nc690mnpIjgf+d0SH6aSkSDOEzcfXb9p+h2FOjcSzrykmPK1R7EF6BVGcVQQZI8tGwRcNS12yuVJmGTUosoBpV8cmPML2BWmnSI5 Date: 11 Jul 2013 20:07:36 -0000 Message-ID: <20130711200736.84292.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <3807645.iUPu0daJeD@scott-latitude-e6320> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Cc: scott@kitterman.com Subject: Re: [apps-discuss] Ted Lemon's No Objection on draft-ietf-appsawg-rfc5451bis-09: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jul 2013 20:08:13 -0000 > If there's something not to do here, I'd think it would be don't > remove signed header fields and break signatures. Bad guy adds a fake A-R field and signs it, so I don't think so. This argument reminds me of a lot of others, in which people want some hack to handle a case which seems superfically useful, but if you write down the actual situation where it would happen, it turns out to be silly. Keeping in mind that each host only removes A-R headers with its own name, for this to matter, the message must have taken a path like A -> B -> C -> B possibly with multiple hops for each arrow, and the second time B sees the mail it wants to reverse engineer what it did the last time, presumably because it trusts C enough to believe that it will only pass real A-R's but not enough to believe that it does competent mail filtering, or something. For me, that's deep into silly. I gather that in response to one of Pete's comments, Murray has agreed to rewrite a section to make it clear that A-R tells downstream users what the MTA concluded from authentication tests, but does not purport to give them enough details so they can redo the tests or otherwise second guess what it did. I think this falls into the same general category. C tells B what C did, but it doesn't promise any details about what happened before that. R's, John From martin.thomson@gmail.com Thu Jul 11 13:54:23 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 356A621F9E24; Thu, 11 Jul 2013 13:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.485 X-Spam-Level: * X-Spam-Status: No, score=1.485 tagged_above=-999 required=5 tests=[AWL=-3.891, BAYES_00=-2.599, FRT_STOCK1=3.988, FRT_STOCK2=3.988, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9xZODkDbMQ-f; Thu, 11 Jul 2013 13:54:22 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 837B721F9D52; Thu, 11 Jul 2013 13:54:21 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id k10so13126015wiv.1 for ; Thu, 11 Jul 2013 13:54:20 -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:content-transfer-encoding; bh=QSGMr0zicqCqvi5yCbjra3aDrpx7K9ZELC2OPf7cDXM=; b=nNTZFtrMpZrrrfgGf3NfR2N4c6pTJhRksffPzd/XcVfy131P0gPyLE/qp1KkvKPvxy 0XKUWgtEvGbtgOeSXKde6YKYFjx1o/zKXeCfEvmSwuXLbT4JdMwqQnjFNsP3hI3Mp/D8 P03AZpjBxv2R72Cm2qqbWybLlaJa+hAyB/V6yYGkzugNmRLVJTizUw9O0tfhAtalurz8 3SpCk+QS7GhNmmA23S/P/vElk12DI2wjQJXle1p+CDgEJ7iWJMBj/NzPYcBBYk1zMD9M euYmdOXTvS5lrqEzat51MVdNdiMGo4NikBsd1Db7fmwzUbEUZyGfTvuaxdmpOgE9xp/D D+AQ== MIME-Version: 1.0 X-Received: by 10.180.187.235 with SMTP id fv11mr20899424wic.65.1373576060605; Thu, 11 Jul 2013 13:54:20 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Thu, 11 Jul 2013 13:54:20 -0700 (PDT) In-Reply-To: <7F110B3ECC623C4EADDEB82154F2693D12871300@EXC-MBX01.tsn.tno.nl> References: <7F110B3ECC623C4EADDEB82154F2693D12871300@EXC-MBX01.tsn.tno.nl> Date: Thu, 11 Jul 2013 13:54:20 -0700 Message-ID: From: Martin Thomson To: "Stokking, H.M. (Hans)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: The IESG , IETF Apps Discuss , "draft-ietf-avtcore-idms.all@tools.ietf.org" Subject: Re: [apps-discuss] AppsDir review of draft-ietf-avtcore-idms-09 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jul 2013 20:54:23 -0000 Thanks. I neglected to send this to a few other folks initially. On 10 July 2013 00:51, Stokking, H.M. (Hans) wrote: > Dear Martin, > > Ray is out-of-office at the moment, I'll discuss your comments with him w= hen he gets back next week. We'll let you know how we expect to deal with y= our comments then. > > Best regards, Hans > > -----Original Message----- > From: Martin Thomson [mailto:martin.thomson@gmail.com] > Sent: maandag 8 juli 2013 19:38 > To: draft-ietf-avtcore-idms.all@tools.ietf.org > Subject: AppsDir review of draft-ietf-avtcore-idms-09 > > I have been selected as the Applications Area Directorate (appsdir) revie= wer for this draft. (For background on appsdir, please see http://trac.too= ls.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). > > Please resolve these comments along with any other Last Call comments you= may receive. Please wait for direction from your document shepherd or AD = before posting a new version of the draft. > > > Document: draft-ietf-avtcore-idms-09 > Reviewer: Martin Thomson > Review Date: 2013-07-08 > IETF Last Call Date: ? > IESG Telechat Date: ? > > Summary: This document is almost ready for publication as proposed standa= rd. There are a few minor issues. > > > Section 6. > Is there a strong reason for the MSAS to be placed at the RTP sender? > Based on the description provided, this function can be independent, with= the exception that it be necessary to receive RTCP reports. The descripti= on in 6.1 omits the information that would be necessary to conclude that it= is in the right place (i.e., it receives RTCP IDMS XR reports, and sends R= TCP IDMS messages.) > > There is also a third potential role in this scenario, which is probably = also assumed by an actual RTP sender. In a network with large disparity of= network delays and playback occurring on devices with limited capacity, is= it not also possible - or even necessary - for an RTP sender to perform so= me buffering to add delay? > > Section 7 re: Synchronization Packet Sender Type . > > I'm not finding any motivation for the inclusion of this field and I can'= t infer from the text what its purpose is. I think that the document needs= something here. I notice that removing it would allow you to remove 32-bi= ts from the payload. > > Section 7 re: Packet Presented NTP timestamp: 32 bits. > > The description of this parameter requires special handling with respect = to epoch and rollover. I might assume that it is within 2^16 seconds of th= e received timestamp, but always greater. > > There are other ways to encode this information, though. Since this is a= lways strictly after a packet is received, then encoding a delta might also= be possible. That would set the epoch for this field to the packet receiv= ed NTP timestamp and avoid any rollover issues (though it would limit the a= mount of buffering delay to 2^16). > > Section 11. > This ABNF implies that the 'a' in 'a=3Drtcp-idms' is case-insensitive. > This is not permitted by RFC 4566. > > Note that you should also specify 'decimal' rather than 'numerical' in th= e description, assuming of course that you want decimal numbers. > This e-mail and its contents are subject to the DISCLAIMER at http://www.= tno.nl/emaildisclaimer From pritikin@cisco.com Wed Jul 10 16:31:58 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B30621F9C0C; Wed, 10 Jul 2013 16:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 702IsSlQEmD1; Wed, 10 Jul 2013 16:31:53 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id CF45021F9C20; Wed, 10 Jul 2013 16:31:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12195; q=dns/txt; s=iport; t=1373499112; x=1374708712; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=YFNAhaYz8bcSrAU8DqZbhZ6qt41V30bllMTct6Z7s5Y=; b=RShBiInazX2C0Ea7phA/2//LsSsSJk8vb+/Repxm0U+y3qs4uMxHdEpN SoxkGa3uBDyHGlidExc2/FNLeDwXIyfSEEXI5Skg8NrZi/7MeRgWhKeEU ELWvITlV6tKJC2USpLi/FajHx/QVeWtSJFx8nwJ1KxIBpV2KB2TPmpaPp A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8FAAru3VGtJXG8/2dsb2JhbABaEwEBgnQyTYMJvh4XdxZ0giQBAQEDI1YQAgEIFA4ODwMCAgIwFBECBA4FCIgHDKY0kS6PMiARBxiCPjNsA5kDkCGDEYIo X-IronPort-AV: E=Sophos;i="4.87,1039,1363132800"; d="scan'208,217";a="233330980" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-5.cisco.com with ESMTP; 10 Jul 2013 23:31:52 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6ANVqSS009772 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 10 Jul 2013 23:31:52 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.100]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Wed, 10 Jul 2013 18:31:52 -0500 From: "Max Pritikin (pritikin)" To: Tobias Gondrom Thread-Topic: AppsDir review of draft-ietf-pkix-est-07 Thread-Index: AQHOcYHaAyHlhd28ukShR/BkvN205ple/ByA Date: Wed, 10 Jul 2013 23:31:51 +0000 Message-ID: <53EA47528D6ACF4486AA152F92C2B698ED617B@xmb-rcd-x03.cisco.com> References: <51C954C5.4060401@gondrom.org> In-Reply-To: <51C954C5.4060401@gondrom.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.1.50] Content-Type: multipart/alternative; boundary="_000_53EA47528D6ACF4486AA152F92C2B698ED617Bxmbrcdx03ciscocom_" MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 12 Jul 2013 09:18:21 -0700 Cc: "iesg@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] AppsDir review of draft-ietf-pkix-est-07 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jul 2013 23:31:58 -0000 --_000_53EA47528D6ACF4486AA152F92C2B698ED617Bxmbrcdx03ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyBzZXJpZXMgb2YgZW1haWxzIGRldGFpbHMgdGhlIEVTVCB1cGRhdGVzIHRvIGVzdC0wNyBp biByZXNwb25zZSB0byB0aGUgY29tbWVudHMgYmVsb3csDQoNCk9uIEp1biAyNSwgMjAxMywgYXQg MjoyOCBBTSwgVG9iaWFzIEdvbmRyb20gPHRvYmlhcy5nb25kcm9tQGdvbmRyb20ub3JnPG1haWx0 bzp0b2JpYXMuZ29uZHJvbUBnb25kcm9tLm9yZz4+IHdyb3RlOg0KDQpJIGhhdmUgYmVlbiBzZWxl Y3RlZCBhcyB0aGUgQXBwbGljYXRpb25zIEFyZWEgRGlyZWN0b3JhdGUgcmV2aWV3ZXIgZm9yDQp0 aGlzIGRyYWZ0IChmb3IgYmFja2dyb3VuZCBvbiBhcHBzZGlyLCBwbGVhc2Ugc2VlIOKAiw0KaHR0 cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYXJlYS9hcHAvdHJhYy93aWtpL0FwcGxpY2F0aW9uc0Fy ZWFEaXJlY3RvcmF0ZSApLg0KDQpQbGVhc2UgcmVzb2x2ZSB0aGVzZSBjb21tZW50cyBhbG9uZyB3 aXRoIGFueSBvdGhlciBMYXN0IENhbGwgY29tbWVudHMNCnlvdSBtYXkgcmVjZWl2ZS4gUGxlYXNl IHdhaXQgZm9yIGRpcmVjdGlvbiBmcm9tIHlvdXIgZG9jdW1lbnQgc2hlcGhlcmQNCm9yIEFEIGJl Zm9yZSBwb3N0aW5nIGEgbmV3IHZlcnNpb24gb2YgdGhlIGRyYWZ0Lg0KDQpEb2N1bWVudDogZHJh ZnQtaWV0Zi1wa2l4LWVzdC0wNw0KVGl0bGU6IEVucm9sbG1lbnQgb3ZlciBTZWN1cmUgVHJhbnNw b3J0DQpSZXZpZXdlcjogVG9iaWFzIEdvbmRyb20NClJldmlldyBEYXRlOiAyNS42LjIwMTMNCg0K U3VtbWFyeTogVGhlIGRyYWZ0IGxvb2tzIGZpbmUuDQpJdCBpcyBoZWFkaW5nIGZvciBTVEQgdHJh Y2sgYW5kIG1vc3RseSBkZXNjcmliZXMgU2ltcGxlIFBLSSBvdmVyIFRMUyAoYW5kIHVzaW5nIHRo ZSBwcm90ZWN0ZWQgY2hhbm5lbCBtZWNoYW5pc21zIGZvciBtdXR1YWwgYXV0aGVudGljYXRpb24g YXMgd2VsbCAoYmV5b25kIHNpbXBsZSBjb25maWRlbnRpYWxpdHkpKS4NCg0KY29tbWVudHM6DQoN Cg0KMS4gc2VjdGlvbiAyLjIuMiBhbmQgMi4yLjMNCiggY2xpZW50IHZlcmlmaWNhdGlvbi4pDQoo Q2VydGlmaWNhdGUtbGVzcyBUTFMgKGUuZy4sIHdpdGggYSBzaGFyZWQgY3JlZGVudGlhbCBkaXN0 cmlidXRlZCBvdXQtb2YtYmFuZCk7DQphbmQgSFRUUC1iYXNlZCB3aXRoIGEgdXNlcm5hbWUvcGFz c3dvcmQgZGlzdHJpYnV0ZWQgb3V0LW9mLWJhbmQuKQ0KDQptYWtlIHN1cmUgdG8gYXZvaWQgaW5m b3JtYXRpb24gbGVha2FnZS4gRS5nLiBpbiBjYXNlIG9mIGNlcnRpZmljYXRlLWxlc3MgVExTLCBp ZiBjb29raWVzIGFyZSB1c2VkLCBtYWtlIHN1cmUgdGhhdCBhcmUgbm90IHRyYW5zbWl0dGVkIG92 ZXIgdGhlIG5vcm1hbCB1bnByb3RlY3RlZCBIVFRQIGJhbmQuDQooc2VjdGlvbiAzLjIuMyBhbHJl YWR5IHNwZWNpZmllcyB0aGF0ICJIVFRQIEJhc2ljIGFuZCBEaWdlc3QgYXV0aGVudGljYXRpb24g TVVTVCBvbmx5IGJlIHBlcmZvcm1lZCBvdmVyIFRMUyAxLjEgW1JGQzQzNDZdIG9yIGxhdGVyIHZl cnNpb25zLiIgd2hpY2ggaXMgZ29vZC4pDQoNClRoaXMgc3RhdGVtZW50IGluIDMuMi4zIHJlLWVu Zm9yY2VzIHRoZSBzdGF0ZW1lbnQgaW4gU2VjdGlvbiAzLjMgdGhhdCAiSFRUUFMgTVVTVCBiZSB1 c2VkLiAgVExTIDEuMSBbUkZDNDM0Nl0gKG9yIGEgbGF0ZXIgdmVyc2lvbikgTVVTVCBiZSB1c2Vk LiINCkFyZ3VhYmx5IHRoZXNlIHN0YXRlbWVudHMgY291bGQgYmUgY29uZGVuc2VkIGludG8gMjEx OSBhc3NlcnRpb24gKGFsdGhvdWdoIHdlIGhhdmUgbm90IGRvbmUgdGhpcykuDQoNCjIuIHNlY3Rp b24gMy4yLjQ6DQp3aGVuIHJlZ2lzdGVyaW5nICAiYXBwbGljYXRpb24vY3NyYXR0cnMiIHdpdGgg SUFOQSBpbiBzZWN0aW9uIDYNCkkgc2VlIHlvdSBoYXZlIG5vIE1hZ2ljIG51bWJlciBvciBmaWxl IGV4dGVuc2lvbi4NCklzIHRoZXJlIGEgY2hhbmNlIHRoYXQgdGhpcyByZXF1ZXN0IG1pZ2h0IGF0 IHNvbWUgcG9pbnQgYmUgbWFkZSB3aXRob3V0IGRpcmVjdCBIVFRQIGFuZCBtaWdodCB3YW50IHNv bWUgb2YgdGhlIHR3bz8NCg0KQSBmaWxlIGV4dGVuc2lvbiAoIi5jc3JhdHRycyIpIGhhcyBiZWVu IGFkZGVkLg0KDQozLiBzZWN0aW9uIDMuMi4yOg0KYXMgeW91IHdhbnQgdG8gb2ZmZXIgdG8gdXNl IEhUVFAgUE9TVCBhbmQgR0VULg0KSSBhbSBub3Qgc28gaGFwcHkgYWJvdXQgdGhlIEhUVFAgR0VU IHBhcnRzLiBIb3cgZG8geW91IGNvbnNpZGVyIHRoZSByaXNrIG9mIGluZm9ybWF0aW9uIGxlYWth Z2Ugd2l0aCBIVFRQIEdFVCB3aGVuIHlvdSBoYXZlIGUuZy4gbGFiZWxzPw0KZS5nLiBpbiBjYXNl IG9mICAgICIyLiAgaHR0cHM6Ly93d3cuZXhhbXBsZS5jb20vLndlbGwta25vd24vZXN0L2FyYml0 cmFyeUxhYmVsMS9jYWNlcnRzIg0KDQpJbmZyYXN0cnVjdHVyZXMgdGhhdCB3aXNoIHRvIGtlZXAg dGhlaXIgcHVibGljIGNlcnRpZmljYXRlIGluZnJhc3RydWN0dXJlIGRldGFpbHMgcHJpdmF0ZSBj YW4gZW5mb3JjZSBjbGllbnQgYXV0aGVudGljYXRpb24gZHVyaW5nIEdFVCBvcGVyYXRpb25zIGFz IHNwZWNpZmllZCBpbiBzNC4xLjIgKCJFU1Qgc2VydmVyIFNIT1VMRCBOT1QgcmVxdWlyZSBjbGll bnQgYXV0aGVudGljYXRpb24iKS4NCg0KU2Vjb25kIHlvdSBtYXkgY29uc2lkZXIgdG8gbm90ZSBV UkkgbGVuZ3RoIGxpbWl0YXRpb25zIGluIEdFVCByZXF1ZXN0cy4NCg0KUmVqZWN0OiBUaGVyZSBp cyBwbGVudHkgYWJvdXQgVVJJL0hUVFAvZXRjIHRoYXQgd2UgYXJlIG5vdCBub3RpbmcNCg0Kbml0 czoNCnBhZ2UgMzINCnMvdG8gdXNlIHRoZSB0aGUgc2VjcDM4NHIxIGVsbGlwdGljIGN1cnZlL3Rv IHVzZSB0aGUgc2VjcDM4NHIxIGVsbGlwdGljIGN1cnZlDQoNCmZpeGVkLg0KDQoNCg0KT2ggYW5k IHlvdSBzaG91bGQgY2xlYW4gdXAgaWRuaXRzOg0KICoqIERvd25yZWY6IE5vcm1hdGl2ZSByZWZl cmVuY2UgdG8gYW4gSW5mb3JtYXRpb25hbCBSRkM6IFJGQyAyOTg2DQogICoqIE9ic29sZXRlIG5v cm1hdGl2ZSByZWZlcmVuY2U6IFJGQyA0MzQ2IChPYnNvbGV0ZWQgYnkgUkZDIDUyNDYpDQoNCkFz IHByZXZpb3VzbHkgbm90ZWQgb24gdGhyZWFkIHRoZXNlIGFyZSBhY2NlcHRhYmxlLg0KDQotIG1h eA0KDQoNCg0KQmVzdCByZWdhcmRzLCBUb2JpYXMNCg0KDQoNCg== --_000_53EA47528D6ACF4486AA152F92C2B698ED617Bxmbrcdx03ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <094966817BC4CA49AD19E95781902BAA@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgIj4NCjxkaXY+VGhpcyBzZXJpZXMgb2YgZW1haWxzIGRl dGFpbHMgdGhlIEVTVCB1cGRhdGVzIHRvIGVzdC0wNyBpbiByZXNwb25zZSB0byB0aGUgY29tbWVu dHMgYmVsb3csPC9kaXY+DQo8ZGl2PiZuYnNwOzxicj4NCjxkaXY+DQo8ZGl2Pk9uIEp1biAyNSwg MjAxMywgYXQgMjoyOCBBTSwgVG9iaWFzIEdvbmRyb20gJmx0OzxhIGhyZWY9Im1haWx0bzp0b2Jp YXMuZ29uZHJvbUBnb25kcm9tLm9yZyI+dG9iaWFzLmdvbmRyb21AZ29uZHJvbS5vcmc8L2E+Jmd0 OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8 YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXYgdGV4dD0iIzAwMDAwMCIgYmdjb2xvcj0iI0ZG RkZGRiI+DQo8ZGl2IGNsYXNzPSJtb3otdGV4dC1odG1sIiBsYW5nPSJ4LXVuaWNvZGUiPjxmb250 IGZhY2U9IkFyaWFsIj5JIGhhdmUgYmVlbiBzZWxlY3RlZCBhcyB0aGUgQXBwbGljYXRpb25zIEFy ZWEgRGlyZWN0b3JhdGUgcmV2aWV3ZXIgZm9yDQo8YnI+DQp0aGlzIGRyYWZ0IChmb3IgYmFja2dy b3VuZCBvbiBhcHBzZGlyLCBwbGVhc2Ugc2VlIOKAiyA8YnI+DQo8YSBjbGFzcz0ibW96LXR4dC1s aW5rLWZyZWV0ZXh0IiBocmVmPSJodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9hcmVhL2FwcC90 cmFjL3dpa2kvQXBwbGljYXRpb25zQXJlYURpcmVjdG9yYXRlIj5odHRwOi8vdHJhYy50b29scy5p ZXRmLm9yZy9hcmVhL2FwcC90cmFjL3dpa2kvQXBwbGljYXRpb25zQXJlYURpcmVjdG9yYXRlPC9h PiApLjxicj4NCjxicj4NClBsZWFzZSByZXNvbHZlIHRoZXNlIGNvbW1lbnRzIGFsb25nIHdpdGgg YW55IG90aGVyIExhc3QgQ2FsbCBjb21tZW50cyA8YnI+DQp5b3UgbWF5IHJlY2VpdmUuIFBsZWFz ZSB3YWl0IGZvciBkaXJlY3Rpb24gZnJvbSB5b3VyIGRvY3VtZW50IHNoZXBoZXJkIDxicj4NCm9y IEFEIGJlZm9yZSBwb3N0aW5nIGEgbmV3IHZlcnNpb24gb2YgdGhlIGRyYWZ0Ljxicj4NCjxicj4N CkRvY3VtZW50OiBkcmFmdC1pZXRmLXBraXgtZXN0LTA3PGJyPg0KVGl0bGU6IEVucm9sbG1lbnQg b3ZlciBTZWN1cmUgVHJhbnNwb3J0PGJyPg0KUmV2aWV3ZXI6IFRvYmlhcyBHb25kcm9tPGJyPg0K UmV2aWV3IERhdGU6IDI1LjYuMjAxMzxicj4NCjxicj4NClN1bW1hcnk6IFRoZSBkcmFmdCBsb29r cyBmaW5lLiA8YnI+DQpJdCBpcyBoZWFkaW5nIGZvciBTVEQgdHJhY2sgYW5kIG1vc3RseSBkZXNj cmliZXMgU2ltcGxlIFBLSSBvdmVyIFRMUyAoYW5kIHVzaW5nIHRoZSBwcm90ZWN0ZWQgY2hhbm5l bCBtZWNoYW5pc21zIGZvciBtdXR1YWwgYXV0aGVudGljYXRpb24gYXMgd2VsbCAoYmV5b25kIHNp bXBsZSBjb25maWRlbnRpYWxpdHkpKS4NCjxicj4NCjxicj4NCmNvbW1lbnRzOiA8YnI+DQo8YnI+ DQo8YnI+DQoxLiBzZWN0aW9uIDIuMi4yIGFuZCAyLjIuMzxicj4NCiggY2xpZW50IHZlcmlmaWNh dGlvbi4pPGJyPg0KKENlcnRpZmljYXRlLWxlc3MgVExTIChlLmcuLCB3aXRoIGEgc2hhcmVkIGNy ZWRlbnRpYWwgZGlzdHJpYnV0ZWQgb3V0LW9mLWJhbmQpOzxicj4NCmFuZCBIVFRQLWJhc2VkIHdp dGggYSB1c2VybmFtZS9wYXNzd29yZCBkaXN0cmlidXRlZCBvdXQtb2YtYmFuZC4pPGJyPg0KPGJy Pg0KbWFrZSBzdXJlIHRvIGF2b2lkIGluZm9ybWF0aW9uIGxlYWthZ2UuIEUuZy4gaW4gY2FzZSBv ZiBjZXJ0aWZpY2F0ZS1sZXNzIFRMUywgaWYgY29va2llcyBhcmUgdXNlZCwgbWFrZSBzdXJlIHRo YXQgYXJlIG5vdCB0cmFuc21pdHRlZCBvdmVyIHRoZSBub3JtYWwgdW5wcm90ZWN0ZWQgSFRUUCBi YW5kLg0KPGJyPg0KKHNlY3Rpb24gMy4yLjMgYWxyZWFkeSBzcGVjaWZpZXMgdGhhdCAmcXVvdDtI VFRQIEJhc2ljIGFuZCBEaWdlc3QgYXV0aGVudGljYXRpb24gTVVTVCBvbmx5IGJlIHBlcmZvcm1l ZCBvdmVyIFRMUyAxLjEgW1JGQzQzNDZdIG9yIGxhdGVyIHZlcnNpb25zLiZxdW90OyB3aGljaCBp cyBnb29kLik8YnI+DQo8L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+ PGJyPg0KPC9kaXY+DQo8ZGl2PlRoaXMgc3RhdGVtZW50IGluIDMuMi4zIHJlLWVuZm9yY2VzIHRo ZSBzdGF0ZW1lbnQgaW4gU2VjdGlvbiAzLjMgdGhhdCAmcXVvdDtIVFRQUyBNVVNUIGJlIHVzZWQu ICZuYnNwO1RMUyAxLjEgW1JGQzQzNDZdIChvciBhIGxhdGVyIHZlcnNpb24pIE1VU1QgYmUmbmJz cDt1c2VkLiZxdW90OzwvZGl2Pg0KPGRpdj5Bcmd1YWJseSB0aGVzZSBzdGF0ZW1lbnRzIGNvdWxk IGJlIGNvbmRlbnNlZCBpbnRvIDIxMTkgYXNzZXJ0aW9uIChhbHRob3VnaCB3ZSBoYXZlIG5vdCBk b25lIHRoaXMpLiZuYnNwOzwvZGl2Pg0KPGJyPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8 ZGl2IHRleHQ9IiMwMDAwMDAiIGJnY29sb3I9IiNGRkZGRkYiPg0KPGRpdiBjbGFzcz0ibW96LXRl eHQtaHRtbCIgbGFuZz0ieC11bmljb2RlIj48Zm9udCBmYWNlPSJBcmlhbCI+Mi4gc2VjdGlvbiAz LjIuNDogPGJyPg0Kd2hlbiByZWdpc3RlcmluZyZuYnNwOyAmcXVvdDthcHBsaWNhdGlvbi9jc3Jh dHRycyZxdW90OyB3aXRoIElBTkEgaW4gc2VjdGlvbiA2PGJyPg0KSSBzZWUgeW91IGhhdmUgbm8g TWFnaWMgbnVtYmVyIG9yIGZpbGUgZXh0ZW5zaW9uLiA8YnI+DQpJcyB0aGVyZSBhIGNoYW5jZSB0 aGF0IHRoaXMgcmVxdWVzdCBtaWdodCBhdCBzb21lIHBvaW50IGJlIG1hZGUgd2l0aG91dCBkaXJl Y3QgSFRUUCBhbmQgbWlnaHQgd2FudCBzb21lIG9mIHRoZSB0d28/DQo8YnI+DQo8L2ZvbnQ+PC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkEgZmls ZSBleHRlbnNpb24gKCZxdW90Oy5jc3JhdHRycyZxdW90OykgaGFzIGJlZW4gYWRkZWQuJm5ic3A7 PC9kaXY+DQo8YnI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXYgdGV4dD0iIzAwMDAw MCIgYmdjb2xvcj0iI0ZGRkZGRiI+DQo8ZGl2IGNsYXNzPSJtb3otdGV4dC1odG1sIiBsYW5nPSJ4 LXVuaWNvZGUiPjxmb250IGZhY2U9IkFyaWFsIj4zLiBzZWN0aW9uIDMuMi4yOiA8YnI+DQphcyB5 b3Ugd2FudCB0byBvZmZlciB0byB1c2UgSFRUUCBQT1NUIGFuZCBHRVQuIDxicj4NCkkgYW0gbm90 IHNvIGhhcHB5IGFib3V0IHRoZSBIVFRQIEdFVCBwYXJ0cy4gSG93IGRvIHlvdSBjb25zaWRlciB0 aGUgcmlzayBvZiBpbmZvcm1hdGlvbiBsZWFrYWdlIHdpdGggSFRUUCBHRVQgd2hlbiB5b3UgaGF2 ZSBlLmcuIGxhYmVscz8NCjxicj4NCmUuZy4gaW4gY2FzZSBvZiZuYnNwOyZuYnNwOyZuYnNwOyAm cXVvdDsyLiZuYnNwOyA8YSBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJodHRw czovL3d3dy5leGFtcGxlLmNvbS8ud2VsbC1rbm93bi9lc3QvYXJiaXRyYXJ5TGFiZWwxL2NhY2Vy dHMiPg0KaHR0cHM6Ly93d3cuZXhhbXBsZS5jb20vLndlbGwta25vd24vZXN0L2FyYml0cmFyeUxh YmVsMS9jYWNlcnRzPC9hPiZxdW90Ozxicj4NCjwvZm9udD48L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SW5mcmFzdHJ1Y3R1cmVzIHRoYXQgd2lz aCB0byBrZWVwIHRoZWlyIHB1YmxpYyBjZXJ0aWZpY2F0ZSBpbmZyYXN0cnVjdHVyZSBkZXRhaWxz IHByaXZhdGUgY2FuIGVuZm9yY2UgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGR1cmluZyBHRVQgb3Bl cmF0aW9ucyBhcyBzcGVjaWZpZWQgaW4gczQuMS4yICgmcXVvdDs8c3BhbiBzdHlsZT0iZm9udC1z aXplOiAxZW07ICI+RVNUIHNlcnZlciBTSE9VTEQgTk9UIHJlcXVpcmUgY2xpZW50IGF1dGhlbnRp Y2F0aW9uJnF1b3Q7KS48L3NwYW4+PC9kaXY+DQo8YnI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRl Ij4NCjxkaXYgdGV4dD0iIzAwMDAwMCIgYmdjb2xvcj0iI0ZGRkZGRiI+DQo8ZGl2IGNsYXNzPSJt b3otdGV4dC1odG1sIiBsYW5nPSJ4LXVuaWNvZGUiPjxmb250IGZhY2U9IkFyaWFsIj5TZWNvbmQg eW91IG1heSBjb25zaWRlciB0byBub3RlIFVSSSBsZW5ndGggbGltaXRhdGlvbnMgaW4gR0VUIHJl cXVlc3RzLiZuYnNwOw0KPGJyPg0KPC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5SZWplY3Q6IFRoZXJlIGlzIHBsZW50eSBhYm91dCBV UkkvSFRUUC9ldGMgdGhhdCB3ZSBhcmUgbm90IG5vdGluZzwvZGl2Pg0KPGJyPg0KPGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSI+DQo8ZGl2IHRleHQ9IiMwMDAwMDAiIGJnY29sb3I9IiNGRkZGRkYiPg0K PGRpdiBjbGFzcz0ibW96LXRleHQtaHRtbCIgbGFuZz0ieC11bmljb2RlIj48Zm9udCBmYWNlPSJB cmlhbCI+bml0czogPGJyPg0KcGFnZSAzMjxicj4NCnMvdG8gdXNlIHRoZSB0aGUgc2VjcDM4NHIx IGVsbGlwdGljIGN1cnZlL3RvIHVzZSB0aGUgc2VjcDM4NHIxIGVsbGlwdGljIGN1cnZlPGJyPg0K PC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0K PGRpdj5maXhlZC48L2Rpdj4NCjxicj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdiB0 ZXh0PSIjMDAwMDAwIiBiZ2NvbG9yPSIjRkZGRkZGIj4NCjxkaXYgY2xhc3M9Im1vei10ZXh0LWh0 bWwiIGxhbmc9IngtdW5pY29kZSI+PGZvbnQgZmFjZT0iQXJpYWwiPjxicj4NCjxicj4NCk9oIGFu ZCB5b3Ugc2hvdWxkIGNsZWFuIHVwIGlkbml0czogPGJyPg0KJm5ic3A7KiogRG93bnJlZjogTm9y bWF0aXZlIHJlZmVyZW5jZSB0byBhbiBJbmZvcm1hdGlvbmFsIFJGQzogUkZDIDI5ODY8YnI+DQom bmJzcDsgKiogT2Jzb2xldGUgbm9ybWF0aXZlIHJlZmVyZW5jZTogUkZDIDQzNDYgKE9ic29sZXRl ZCBieSBSRkMgNTI0Nik8YnI+DQo8L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkFzIHByZXZpb3VzbHkgbm90ZWQgb24gdGhyZWFkIHRo ZXNlIGFyZSBhY2NlcHRhYmxlLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+LSBtYXg8 L2Rpdj4NCjxicj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdiB0ZXh0PSIjMDAwMDAw IiBiZ2NvbG9yPSIjRkZGRkZGIj4NCjxkaXYgY2xhc3M9Im1vei10ZXh0LWh0bWwiIGxhbmc9Ingt dW5pY29kZSI+PGZvbnQgZmFjZT0iQXJpYWwiPjxicj4NCjwvZm9udD48Zm9udCBmYWNlPSJBcmlh bCI+PGJyPg0KQmVzdCByZWdhcmRzLCBUb2JpYXM8YnI+DQo8YnI+DQo8YnI+DQo8L2ZvbnQ+PC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyPg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_53EA47528D6ACF4486AA152F92C2B698ED617Bxmbrcdx03ciscocom_-- From vesely@tana.it Fri Jul 12 09:51:20 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C64AC21F9702 for ; Fri, 12 Jul 2013 09:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.072 X-Spam-Level: X-Spam-Status: No, score=-5.072 tagged_above=-999 required=5 tests=[AWL=-0.353, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F3dibansL3aO for ; Fri, 12 Jul 2013 09:51:16 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 6F13F21F995F for ; Fri, 12 Jul 2013 09:51:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1373647869; bh=JyBL7VXVP0tjCN/cFQ5esS2Wln3alDy8rajgum1YzwM=; l=1426; h=Date:From:To:References:In-Reply-To; b=c1grmXqBFTFWgyDvrtAzVhaF9H+QEFRaijvoX41JZzVGMIx8oDU3Ptf2dI00zC2C1 +Sv22rlBoFUQ7DttuuqJLdLHECHbfVLwd9W+nURSBFDdMFRUsJ6uvdBkEgbTSOBLck qngGM0ybKj0jb8v1GRiKOe7zaLpjlZqwk31Fiv6A= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.158] (alessandro-System-Product-Name.tana [172.25.197.158]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Fri, 12 Jul 2013 18:51:09 +0200 id 00000000005DC033.0000000051E033FD.00005DC1 Message-ID: <51E033FD.3070207@tana.it> Date: Fri, 12 Jul 2013 18:51:09 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130704 Icedove/17.0.7 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20130711032917.15531.27251.idtracker@ietfa.amsl.com> <51DE8443.6080606@cs.tcd.ie> <8D23D4052ABE7A4490E77B1A012B63077520A3BE@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63077520AA1B@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077520AA1B@mbx-01.win.nominum.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] Ted Lemon's No Objection on draft-ietf-appsawg-rfc5451bis-09: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Jul 2013 16:51:21 -0000 On Thu 11/Jul/2013 16:33:41 +0200 Ted Lemon wrote: > On Jul 11, 2013, at 8:28 AM, Barry Leiba wrote: >> There were, similarly, conversations in the DKIM WG about trying >> to reconstruct broken signatures through mailing lists by looking >> for a "[listname]" prefix on the Subject header and stripping it >> and retrying the sig validation. After discussion, the WG had >> clear consensus that any such heuristics could be attempted, but >> NOT within the scope of the standard -- they were too dicey, >> leaving too many questions open (what if a spammer prepended >> "[my.bad.url]" to a signed message?). > > In the case you are describing here, you are leaving something that > is possible as an exercise to the reader, because you don't want to > advise anyone to do it. This makes sense. In the case that we > are talking about with respect to the draft under review, the draft > actually makes it _impossible_ to do the validation if the header > is included in the signature. It does not, as it allows to use Elided-Authentication-Results or similar constructs. It words it as "MUST delete or otherwise obscure", in the first paragraph of Section 5. This hack is needed whenever DKIM verification is done after that A-R processing, by a different filter within the same MTA. Downstream filters have to know the obscuring prefix, which is not (to be) standardized. From internet-drafts@ietf.org Sat Jul 13 00:12:30 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9327711E8184; Sat, 13 Jul 2013 00:12:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.542 X-Spam-Level: X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TfgkeRMx-7AS; Sat, 13 Jul 2013 00:12:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BC8A111E8182; Sat, 13 Jul 2013 00:12:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130713071229.22431.50269.idtracker@ietfa.amsl.com> Date: Sat, 13 Jul 2013 00:12:29 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-malformed-mail-07.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2013 07:12:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Working G= roup of the IETF. Title : Advice for Safe Handling of Malformed Messages Author(s) : Murray S. Kucherawy Gregory N. Shapiro N. Freed Filename : draft-ietf-appsawg-malformed-mail-07.txt Pages : 21 Date : 2013-07-13 Abstract: Although Internet mail formats have been precisely defined since the 1970s, authoring and handling software often show only mild conformance to the specifications. The distributed and non- interactive nature of email has often prompted adjustments to receiving software, to handle these variations, rather than trying to gain better conformance by senders, since the receiving operator is primarily driven by complaining recipient users and has no authority over the sending side of the system. Processing with such flexibility comes at some cost, since mail software is faced with decisions about whether or not to permit non-conforming messages to continue toward their destinations unaltered, adjust them to conform (possibly at the cost of losing some of the original message), or outright rejecting them. A core requirement for interoperability is that both sides of an exchange work from the same details and semantics. By having receivers be flexible, beyond the specifications, there can be -- and often has been -- a good chance that a message will not be fully interoperable. Worse, a well-established pattern of tolerance for variations can sometimes be used as an attack vector. This document includes a collection of the best advice available regarding a variety of common malformed mail situations, to be used as implementation guidance. It must be emphasized, however, that the intent of this document is not to standardize malformations or otherwise encourage their proliferation. The messages are manifestly malformed, and the code and culture that generates them needs to be fixed. Therefore, these messages should be rejected outright if at all possible. Nevertheless, many malformed messages from otherwise legitimate senders are in circulation and will be for some time, and, unfortunately, commercial reality shows that we cannot always simply reject or discard them. Accordingly, this document presents alternatives for dealing with them in ways that seem to do the least additional harm until the infrastructure is tightened up to match the standards. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-malformed-mail There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-malformed-mail-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-malformed-mail-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From superuser@gmail.com Sat Jul 13 00:15:34 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65D2511E8182 for ; Sat, 13 Jul 2013 00:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zSQUaEEDsO6f for ; Sat, 13 Jul 2013 00:15:33 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 3D52D11E8181 for ; Sat, 13 Jul 2013 00:15:33 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id y10so1217644wgg.4 for ; Sat, 13 Jul 2013 00:15:32 -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=i8D/1uD2Zp1vdF879J0ZefLaoBAuktxXMVKybVEFuhI=; b=gLxy3rElkaSETrecj+K2whhXvvpwGFkj2VXZHqY5NgVHVgrn2hCUUIyDiT0f5n1C+V IGbR9jAqU7qslMWIi+OFtiFtGw3CCooNdzHxtaDAoJZd5zTXw3q3vyyKLIuLF/V4jqJo JXhRmh9JEAmkcXurYWswj2DNaZinbqtGUzKtzMRcd9a8nB7BLBpK+qlg89uh1Zg3toMO VlLjIhnmArIRa/9n3mOAc6P43XTisyoTQKi0S2fGY+gfcjk5C3JZWSclapsFhq7ILtiT yMi06Gy02K0lyfgRgU/7HMc6bKV0ZU2X1ZLMgq8PReu4qAKedJXYW7VdFtnulWAFoWqy YP+w== MIME-Version: 1.0 X-Received: by 10.194.48.116 with SMTP id k20mr26585479wjn.23.1373699732273; Sat, 13 Jul 2013 00:15:32 -0700 (PDT) Received: by 10.180.90.16 with HTTP; Sat, 13 Jul 2013 00:15:32 -0700 (PDT) In-Reply-To: <20130713071229.22431.50269.idtracker@ietfa.amsl.com> References: <20130713071229.22431.50269.idtracker@ietfa.amsl.com> Date: Sat, 13 Jul 2013 00:15:32 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=047d7ba975e692007904e15f643e Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-malformed-mail-07.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2013 07:15:34 -0000 --047d7ba975e692007904e15f643e Content-Type: text/plain; charset=ISO-8859-1 On Sat, Jul 13, 2013 at 12:12 AM, 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 : Advice for Safe Handling of Malformed Messages > Author(s) : Murray S. Kucherawy > Gregory N. Shapiro > N. Freed > Filename : draft-ietf-appsawg-malformed-mail-07.txt > Pages : 21 > Date : 2013-07-13 > > Abstract: > Although Internet mail formats have been precisely defined since the > 1970s, authoring and handling software often show only mild > conformance to the specifications. The distributed and non- > interactive nature of email has often prompted adjustments to > receiving software, to handle these variations, rather than trying to > gain better conformance by senders, since the receiving operator is > primarily driven by complaining recipient users and has no authority > over the sending side of the system. Processing with such > flexibility comes at some cost, since mail software is faced with > decisions about whether or not to permit non-conforming messages to > continue toward their destinations unaltered, adjust them to conform > (possibly at the cost of losing some of the original message), or > outright rejecting them. > > A core requirement for interoperability is that both sides of an > exchange work from the same details and semantics. By having > receivers be flexible, beyond the specifications, there can be -- and > often has been -- a good chance that a message will not be fully > interoperable. Worse, a well-established pattern of tolerance for > variations can sometimes be used as an attack vector. > > This document includes a collection of the best advice available > regarding a variety of common malformed mail situations, to be used > as implementation guidance. It must be emphasized, however, that the > intent of this document is not to standardize malformations or > otherwise encourage their proliferation. The messages are manifestly > malformed, and the code and culture that generates them needs to be > fixed. Therefore, these messages should be rejected outright if at > all possible. Nevertheless, many malformed messages from otherwise > legitimate senders are in circulation and will be for some time, and, > unfortunately, commercial reality shows that we cannot always simply > reject or discard them. Accordingly, this document presents > alternatives for dealing with them in ways that seem to do the least > additional harm until the infrastructure is tightened up to match the > standards. > > > This draft incorporates the latest feedback from Ned Freed and Dave Cridland. I've also invited Ned to be a co-author of the document since he has contributed a substantial amount of the working text that now appears in it. Further reviews are invited. As a reminder, Salvatore Loreto is the document shepherd since I am a co-author on it. -MSK --047d7ba975e692007904e15f643e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Jul 13, 2013 at 12:12 AM, <<= a href=3D"mailto:internet-drafts@ietf.org" target=3D"_blank">internet-draft= s@ietf.org> wrote:

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

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Advice for Safe Handling of Mal= formed Messages
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Murray S. Kucherawy
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Gregory N. Shapiro
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 N. Freed
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-appsawg-malformed-mail= -07.txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 21
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-07-13

Abstract:
=A0 =A0Although Internet mail formats have been precisely defined since the=
=A0 =A01970s, authoring and handling software often show only mild
=A0 =A0conformance to the specifications. =A0The distributed and non-
=A0 =A0interactive nature of email has often prompted adjustments to
=A0 =A0receiving software, to handle these variations, rather than trying t= o
=A0 =A0gain better conformance by senders, since the receiving operator is<= br> =A0 =A0primarily driven by complaining recipient users and has no authority=
=A0 =A0over the sending side of the system. =A0Processing with such
=A0 =A0flexibility comes at some cost, since mail software is faced with =A0 =A0decisions about whether or not to permit non-conforming messages to<= br> =A0 =A0continue toward their destinations unaltered, adjust them to conform=
=A0 =A0(possibly at the cost of losing some of the original message), or =A0 =A0outright rejecting them.

=A0 =A0A core requirement for interoperability is that both sides of an
=A0 =A0exchange work from the same details and semantics. =A0By having
=A0 =A0receivers be flexible, beyond the specifications, there can be -- an= d
=A0 =A0often has been -- a good chance that a message will not be fully
=A0 =A0interoperable. =A0Worse, a well-established pattern of tolerance for=
=A0 =A0variations can sometimes be used as an attack vector.

=A0 =A0This document includes a collection of the best advice available
=A0 =A0regarding a variety of common malformed mail situations, to be used<= br> =A0 =A0as implementation guidance. =A0It must be emphasized, however, that = the
=A0 =A0intent of this document is not to standardize malformations or
=A0 =A0otherwise encourage their proliferation. =A0The messages are manifes= tly
=A0 =A0malformed, and the code and culture that generates them needs to be<= br> =A0 =A0fixed. =A0Therefore, these messages should be rejected outright if a= t
=A0 =A0all possible. =A0Nevertheless, many malformed messages from otherwis= e
=A0 =A0legitimate senders are in circulation and will be for some time, and= ,
=A0 =A0unfortunately, commercial reality shows that we cannot always simply=
=A0 =A0reject or discard them. =A0Accordingly, this document presents
=A0 =A0alternatives for dealing with them in ways that seem to do the least=
=A0 =A0additional harm until the infrastructure is tightened up to match th= e
=A0 =A0standards.



This draft incorporates the latest= feedback from Ned Freed and Dave Cridland.=A0 I've also invited Ned to= be a co-author of the document since he has contributed a substantial amou= nt of the working text that now appears in it.

Further reviews are invited.=A0 As a reminder, Salvatore Lor= eto is the document shepherd since I am a co-author on it.

-MSK
--047d7ba975e692007904e15f643e-- From eburger@standardstrack.com Sat Jul 13 03:24:19 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2217D21E80D9 for ; Sat, 13 Jul 2013 03:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.669 X-Spam-Level: X-Spam-Status: No, score=-101.669 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVLIqHDw7LdQ for ; Sat, 13 Jul 2013 03:24:14 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.15]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF9811E8137 for ; Sat, 13 Jul 2013 03:24:02 -0700 (PDT) Received: from ip68-100-196-226.dc.dc.cox.net ([68.100.196.226]:57763 helo=[192.168.15.100]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1Uxwzb-0005dB-Px for apps-discuss@ietf.org; Sat, 13 Jul 2013 03:24:01 -0700 From: Eric Burger Content-Type: multipart/signed; boundary="Apple-Mail=_92CAE401-2C20-45F3-A159-07083602B361"; protocol="application/pgp-signature"; micalg=pgp-sha1 Message-Id: <30784136-6915-4360-87B7-B9B3AD01431A@standardstrack.com> Date: Sat, 13 Jul 2013 06:23:54 -0400 To: "apps-discuss@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) 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: Subject: [apps-discuss] Apps Area Review of draft-ietf-alto-server-discovery-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Jul 2013 10:24:19 -0000 --Apple-Mail=_92CAE401-2C20-45F3-A159-07083602B361 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I have been selected as the Applications Area Review Team reviewer for = this draft. For background on apps-review, please see = http://www.apps.ietf.org/content/applications-area-review-team . =20 Please resolve these comments along with any other Last Call comments = you may receive. Please wait for direction from your document shepherd = or AD before posting a new version of the draft. =20 Document: draft-ietf-alto-server-discovery-08 Title: ALTO Server Discovery Reviewer: Eric Burger Review Date: 13 July 2013 IETF Last Call Date: unknown IESG Telechat Date: unknown =20 Summary: This draft is almost ready for publication as a Proposed = Standard and should be revised before publication. =20 =20 Major Issues: =20 Section 3.1: The second option of Step 1 Option 2, is using RFC 2132 to get the name = of the access domain in the event the DHCP server does not know RFC 5986 = or a middlebox is damaging DHCP requests. That is OK as a fallback = mechanism. However, the document needs to describe why we want RFC 5986 = behavior and not RFC 2132 behavior. The big one is going to be that a = service provider may have the ALTO overlay on a different level than the = access network. For example, the ALTO overlay may span = east.us.example.net, while my access network might be = nova.va.east.us.example.net. My presumption is a U-NAPTR lookup for ALTO = in nova.va.east.us.example.net will fail, while east.us.example.net is = what I want. If I am wrong there, then this major issue becomes a minor = issue - just say something for folks not using the mechanism every day. =20 =20 Minor Issues: =20 Section 4.2: Under what circumstances would an ALTO client *not* " query the ALTO = server(s) that have been discovered for this specific interface and = address family"? =20 Hidden normative language. I would propose "If there is a change in the = IP address of an interface, the client MUST rerun the ALTO server = discovery procedure." Also, why the restriction of forgetting prior = earlier gained information? If the client MUST rerun the procedure, do = not suggest to implementors to remember prior information. This is like = telling a child he cannot have a cookie. He did not know he could have a = cookie until you told him not to have one. In the situation of server = discover, if you say rerun the procedure, there is no question of using = the old data. =20 Nits: Section 6.2, Page 12, first full paragraph: OLD The domain name that is used to authenticated =20 NEW The domain name that is used to authenticate= --Apple-Mail=_92CAE401-2C20-45F3-A159-07083602B361 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) iQIcBAEBAgAGBQJR4Sq6AAoJEORoZaSQsc1IpToQAOdUqtBTxs49bvzjllgMeIwv lF91brlSnJSy6yxCew3z+OP55Y6mfbxGmcMOg/tFxP8QbXrwxCvkKgg+KC2oiAQq dyJ2ALrA/ieSLF3uLTtd5D+r/wvoe189KKbamt1p0o2T2uzFJvYIx+EBcLb1mkXP Ap3XWGMjznARSjRGuvHrKS8CCchVwuUjLnetcV/DNR0QLa11t7hnDGL+uX2l6bFn T2C6AZ9Urd5i+jJNTKZnLi/qlGvWa0H86spW2dzT6JODCsuaeCuMXfHxlTlLLfmi eoHVzBScuQkgpdAUdtkWf2bIuWpBqAYtsYlpX3/DMY7smfEadQj7Nbyr05+b82ff CnzNYBkx3l92loIV97z/wkxsbmydlqIi5nbA9lkyXZQDGJb2WwlqxBWxd5NgkX7j VQV1EQ8rst0gMoMKPFC92fN56vXIzzllIEANcnvMzcUyWQVtpC95JprM9RxMxoPM S2q8x+vyTmvyh4SqatSWCdNKhc8Oe/GBkhuYwBxAMoGdvIkxilg1cmyINx8zmJ3F ZknkPRcoLryEWeggnCq3CqqOFHpWOqETyFSo1GqNdc9TNDGwOuvBsONNTqDtRxTH Fi5ev25bugJvy5YXVeY8fcAlQFIgufeB3QpclebK48ydSL9RA8901u1g+qQXDSka QwYHLcQYPKiJi8lqCjy6 =mXLS -----END PGP SIGNATURE----- --Apple-Mail=_92CAE401-2C20-45F3-A159-07083602B361-- From ian@hixie.ch Fri Jul 12 10:40:19 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA6611E8171 for ; Fri, 12 Jul 2013 10:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P29q8cnv+MqC for ; Fri, 12 Jul 2013 10:40:14 -0700 (PDT) Received: from homiemail-a69.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by ietfa.amsl.com (Postfix) with ESMTP id 47ABB11E810E for ; Fri, 12 Jul 2013 10:40:14 -0700 (PDT) Received: from homiemail-a69.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a69.g.dreamhost.com (Postfix) with ESMTP id 98DCC40119C04 for ; Fri, 12 Jul 2013 10:39:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hixie.ch; h=date:from:to :subject:message-id:mime-version:content-type; s=hixie.ch; bh=3C cT/KbMTRLHKjmRCfC2Cr17S1Y=; b=QXW3fTGq99QZA9QeZ1mf6JN6dO2sQ76YHV pcB05/vcK6gyqZJm4xtRljDZlNb1bXKtoFp0ggZ+KFFyHFvURsq79YUwH7xtoyzF UbIclU//RiCS9INtH33ZnZQhP0HjQ8CCvF52ij/U9sGeYvjm7OGx0LKcXI4u1uSO R7PJQ0uPg= Received: from ps20323.dreamhostps.com (ps20323.dreamhost.com [69.163.222.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: internal@index.hixie.ch) by homiemail-a69.g.dreamhost.com (Postfix) with ESMTPSA id 7D0DA40119C01 for ; Fri, 12 Jul 2013 10:39:43 -0700 (PDT) Date: Fri, 12 Jul 2013 17:39:43 +0000 (UTC) From: Ian Hickson To: apps-discuss@ietf.org Message-ID: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Content-Language: en-GB-hixie Content-Style-Type: text/css MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Mon, 15 Jul 2013 06:12:04 -0700 Subject: [apps-discuss] RFC 2388 (multipart/form-data) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Jul 2013 17:40:19 -0000 Hi, Do you know if there is anyone working on fixing RFC2388? People keep asking me to update the HTML spec to just define it all inline rather than deferring to the RFC since the RFC leaves a lot of stuff underdefined, but I don't have the bandwidth to spec all that myself at this point. e.g.: https://www.w3.org/Bugs/Public/show_bug.cgi?id=16909 https://www.w3.org/Bugs/Public/show_bug.cgi?id=19879 Other feedback: http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Oct/0204.html http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jul/0037.html http://lists.w3.org/Archives/Public/public-whatwg-archive/2012May/0003.html I asked Larry Masinter if he was still maintaining the RFC, but he said he wasn't, and suggested I ask here to find out who was maintaining it now. Thanks in advance, -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From vkg@bell-labs.com Mon Jul 15 06:36:15 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11FC421E8082; Mon, 15 Jul 2013 06:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPMiEZDb7n3f; Mon, 15 Jul 2013 06:36:10 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 673FC11E80D5; Mon, 15 Jul 2013 06:36:10 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r6FDa7Mo019390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 15 Jul 2013 08:36:08 -0500 (CDT) Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id r6FDa7Cd008027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 15 Jul 2013 08:36:07 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.237.229]) by umail.lucent.com (8.13.8/TPES) with ESMTP id r6FDa65s008853; Mon, 15 Jul 2013 08:36:06 -0500 (CDT) Message-ID: <51E3FBC6.4050400@bell-labs.com> Date: Mon, 15 Jul 2013 08:40:22 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: draft-ivov-grouptextchat-purpose.all@tools.ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Cc: IESG IESG , "apps-discuss@ietf.org" Subject: [apps-discuss] APPSDIR review of draft-ivov-grouptextchat-purpose-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 13:36:15 -0000 I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see ​ http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ivov-grouptextchat-purpose-03 Title: A group text chat purpose for conference and service URIs in the Session Initiation Protocol (SIP) event package Reviewer: Vijay K. Gurbani Review Date: Jul-15-2013 IETF Last Call Date: Jul-22-2013 IESG Telechat Date: Not known Summary: This draft is ready for publication as an Informational RFC. Major Issues: 0 Minor Issues: 0 Nits: 1 Nits: ----- - S2: The use of "integrity protect" as a verb is rather unorthodox in the sentence, "Clients can integrity protect and encrypt ...". Better to reword it as "Clients can protect the integrity of and encrypt ..." Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq From ted.ietf@gmail.com Mon Jul 15 09:46:40 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC5C421E80E4; Mon, 15 Jul 2013 09:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.283 X-Spam-Level: X-Spam-Status: No, score=-2.283 tagged_above=-999 required=5 tests=[AWL=0.316, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LlSrkR80pNc3; Mon, 15 Jul 2013 09:46:40 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 08AB221E80E2; Mon, 15 Jul 2013 09:46:39 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id s9so26757188iec.27 for ; Mon, 15 Jul 2013 09:46:38 -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:cc:content-type; bh=xwt7JrPL/8YrlALbYJqnDwIPpk2GYUa/PuZoALhMs9M=; b=xr1ouw9rbDFInLGoRGC+dSHMDJbXvesoZ3JzX7xr86tAY3l1ZaHcFnfmN4rJP75Jl9 Lu7irm8As7uH9V6JnNIgdNBy6anlulW3b8QZEkqY3nq6oIBXuRzg2eBx1OjxixyhydV1 mfnV8NiXqCwxvHUh7MZfYYeonT211efgnpOCdMt7tzqaffIjPr58LIrcKuZ7TaBhV6jK 3g2YvHCsGorZ/JJ6w3X12pcMS62fRklxhKj6O6MrrIkvbqxsS1k22D0b8RWeWCXiGxIw 9Ri0qzvXK+lD2uBmM5TuvrckGbcD9eAjU7P4eYPfqzvL+GRjRNkhPp7YJG5Zn6Ukiq0G Yi7Q== MIME-Version: 1.0 X-Received: by 10.50.134.9 with SMTP id pg9mr7635116igb.29.1373906798599; Mon, 15 Jul 2013 09:46:38 -0700 (PDT) Received: by 10.42.29.202 with HTTP; Mon, 15 Jul 2013 09:46:38 -0700 (PDT) Date: Mon, 15 Jul 2013 09:46:38 -0700 Message-ID: From: Ted Hardie To: draft-ivov-xmpp-cusax.all@tools.ietf.org, apps-discuss@ietf.org Content-Type: multipart/alternative; boundary=047d7b41407eaf6b0104e18f9ada Cc: IESG Subject: [apps-discuss] Apps directorate review of draft-ivov-xmpp-cusax X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 15 Jul 2013 16:46:40 -0000 --047d7b41407eaf6b0104e18f9ada Content-Type: text/plain; charset=ISO-8859-1 I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ivov-xmpp-cusax-06 Title: CUSAX: Combined Use of the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP) Reviewer: Ted Hardie Review Date: July 15th, 2013 Summary: This document is ready for publication as an Informational RFC. Some additional text in the security considerations section (or pointers to external text) may be useful, but is not absolutely required. Minor Issues: The text in the security considerations does not seem to consider some attacks which appear obvious in light of the discussion of federation. The federation example points out that the mismatch between client capabilities may cause calls to be initiated with costs contrary to the expectation of the end user; this could, of course, be done maliciously as well as by accident. A back reference to the federation section with appropriate text (or text focusing on the attack surface) might be appropriate. Nits: I find the text: Today, in the context of the SIMPLE working group, somewhat odd in the context of an archival document. --047d7b41407eaf6b0104e18f9ada Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

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

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

Document:=A0 draft-ivov-xmpp-cusax= -06

Title: CUSAX: Combined Use of the Session Initiation Protocol (SIP) and the Exten= sible Messaging and Presence Protocol (XMPP)

Reviewer: Ted Hardie
Review Date: July 15th, 2013

Summary: This document is ready for publication as an Informational RFC.=A0= Some additional text in the security considerations section (or pointers t= o external text) may be useful, but is not absolutely required.

Minor Issues:=A0 The text in the security considerations does not seem to c= onsider some attacks which appear obvious in light of the discussion of fed= eration.=A0 The federation example points out that the mismatch between cli= ent capabilities may cause calls to be initiated with costs contrary to the= expectation of the end user; this could, of course, be done maliciously as= well as by accident.=A0 A back reference to the federation section with ap= propriate text (or text focusing on the attack surface) might be appropriat= e.

Nits: I find the text:

    Today, in the context of the SIMPLE work=
ing group,

somewhat odd in the context of an archival document.
--047d7b41407eaf6b0104e18f9ada-- From ietf-secretariat-reply@ietf.org Mon Jul 15 12:10:49 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8BC111E8225 for ; Mon, 15 Jul 2013 12:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pm5UAr0mUIl1; Mon, 15 Jul 2013 12:10:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 249C421E8112; Mon, 15 Jul 2013 12:10:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-rfc5451bis@tools.ietf.org, sm+ietf@elandsys.com, apps-discuss@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130715191044.17077.47068.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 12:10:44 -0700 From: IETF Secretariat Subject: [apps-discuss] ID Tracker State Update Notice: X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 15 Jul 2013 19:10:50 -0000 IESG has approved the document and state has been changed to Approved-annou= ncement sent ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc5451b= is/ From internet-drafts@ietf.org Mon Jul 15 12:21:38 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65EC621E8142; Mon, 15 Jul 2013 12:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wfHCvzHOen29; Mon, 15 Jul 2013 12:21:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ECA2821E8112; Mon, 15 Jul 2013 12:21:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130715192136.15300.58650.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 12:21:36 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-16.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 19:21:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Working G= roup of the IETF. Title : WebFinger Author(s) : Paul E. Jones Gonzalo Salgueiro Joseph Smarr Filename : draft-ietf-appsawg-webfinger-16.txt Pages : 21 Date : 2013-07-15 Abstract: This specification defines the WebFinger protocol, which can be used to discover information about people or other entities on the Internet using standard HTTP methods. WebFinger discovers information for a URI that might not be usable as a locator otherwise, such as account or email URIs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-16 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-webfinger-16 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ietf-secretariat-reply@ietf.org Mon Jul 15 12:57:55 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD0B21E813C for ; Mon, 15 Jul 2013 12:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.457 X-Spam-Level: X-Spam-Status: No, score=-101.457 tagged_above=-999 required=5 tests=[AWL=-1.076, BAYES_00=-2.599, NO_RELAYS=-0.001, TVD_SPACE_RATIO=2.219, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wwiud5LCz7hM; Mon, 15 Jul 2013 12:57:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 738EE21E80D1; Mon, 15 Jul 2013 12:57:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-rfc5451bis@tools.ietf.org, sm+ietf@elandsys.com, apps-discuss@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130715195754.19379.35036.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 12:57:54 -0700 From: IETF Secretariat Subject: [apps-discuss] ID Tracker State Update Notice: X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 15 Jul 2013 19:57:55 -0000 IANA action state changed to In Progress ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc5451b= is/ From ted.ietf@gmail.com Mon Jul 15 15:03:47 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0E9D21F9F2D; Mon, 15 Jul 2013 15:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.308 X-Spam-Level: X-Spam-Status: No, score=-2.308 tagged_above=-999 required=5 tests=[AWL=0.291, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VjpIaI96c9S5; Mon, 15 Jul 2013 15:03:46 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 9AF1821F8495; Mon, 15 Jul 2013 15:03:44 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 16so27283055iea.31 for ; Mon, 15 Jul 2013 15:03: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=8og4CfB/ka4K6BV+aHuHJtDZm8Zt+7YPk+J6ME0XB2Y=; b=Ahv/u1/2jB9OlW7J00Jj0GzDkYLKMms310fyRgeXqzKyOdyAAGP7uvpx8nZ9xKodP9 L3F0jWGUsyMW5B6i1BoGnlCCf7eo8AgAgqoDbIjMqArDfF/yep7fR81SgnAb43kQ8Ak1 yUSGODvjN/7vI7MRsmPN9RoZoo7arTukzWrEFz6YDBcS3EnPURIdF2+/hEW1JnuEKx/X +6mEJQlOUiDAa6tj7ZFit/nFaj/Tcmaq7nrMobA8Q0h1XX7XblC63zUzHZTtd8csqqF/ 6aWBgx+71R0iVOqP5sWHl6lHz5GzsIM1wJxS9RG1JOWzO2sP/BGJAgWg9a6mp7sJBo5p xLeQ== MIME-Version: 1.0 X-Received: by 10.50.153.49 with SMTP id vd17mr8439393igb.22.1373925810130; Mon, 15 Jul 2013 15:03:30 -0700 (PDT) Received: by 10.42.29.202 with HTTP; Mon, 15 Jul 2013 15:03:30 -0700 (PDT) In-Reply-To: <51E4706C.7070607@jitsi.org> References: <51E4706C.7070607@jitsi.org> Date: Mon, 15 Jul 2013 15:03:30 -0700 Message-ID: From: Ted Hardie To: Emil Ivov Content-Type: multipart/alternative; boundary=089e014954bedc5b9204e19407b1 Cc: draft-ivov-xmpp-cusax.all@tools.ietf.org, IESG , apps-discuss@ietf.org Subject: Re: [apps-discuss] Apps directorate review of draft-ivov-xmpp-cusax X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 15 Jul 2013 22:03:48 -0000 --089e014954bedc5b9204e19407b1 Content-Type: text/plain; charset=ISO-8859-1 Hi Emil, The updated draft text addresses all of the issues I raised. regards, Ted Hardie On Mon, Jul 15, 2013 at 2:58 PM, Emil Ivov wrote: > Hey Ted, > > > On 15.07.13, 18:46, Ted Hardie wrote: > >> I have been selected as the Applications Area Directorate reviewer for >> this draft (for background on appsdir, please see >> http://trac.tools.ietf.org/**area/app/trac/wiki/** >> ApplicationsAreaDirectorate). >> >> Please resolve these comments along with any other Last Call comments >> you may receive. Please wait for direction from your document shepherd >> or AD before posting a new version of the draft. >> >> Document: draft-ivov-xmpp-cusax-06 >> >> Title: CUSAX: Combined Use of the Session Initiation Protocol (SIP) and >> the Extensible Messaging and Presence Protocol (XMPP) >> >> Reviewer: Ted Hardie >> Review Date: July 15th, 2013 >> >> Summary: This document is ready for publication as an Informational >> RFC. Some additional text in the security considerations section (or >> pointers to external text) may be useful, but is not absolutely required. >> >> Minor Issues: The text in the security considerations does not seem to >> consider some attacks which appear obvious in light of the discussion of >> federation. The federation example points out that the mismatch between >> client capabilities may cause calls to be initiated with costs contrary >> to the expectation of the end user; this could, of course, be done >> maliciously as well as by accident. A back reference to the federation >> section with appropriate text (or text focusing on the attack surface) >> might be appropriate. >> > > Good point! > > > Nits: I find the text: >> >> Today, in the context of the SIMPLE working group, >> >> somewhat odd in the context of an archival document. >> > > Indeed. Removed. > > A new version that incorporates your feedback is available here: > > https://github.com/emcho/**cusax/raw/master/draft-ivov-**xmpp-cusax-07.txt > > (will re-submit as soon as instructed from our shepherd or ID) > > Does this address your comments? > > Thanks, > Emil > > -- > https://jitsi.org > --089e014954bedc5b9204e19407b1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Emil,

The updated draft text addresses all of the issues I raised= .

regards,

Ted Hardie

On Mo= n, Jul 15, 2013 at 2:58 PM, Emil Ivov <emcho@jitsi.org> wrote:=
Hey Ted,


On 15.07.13, 18:46, Ted Hardie wrote:
I have been selected as the Applications Area Directorate reviewer for
this draft (for background on appsdir, please see
http://trac.tools.ietf.org/area/app/tra= c/wiki/ApplicationsAreaDirectorate ).

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

Document: draft-ivov-xmpp-cusax-06

Title: CUSAX: Combined Use of the Session Initiation Protocol (SIP) and
the Extensible Messaging and Presence Protocol (XMPP)

Reviewer: Ted Hardie
Review Date: July 15th, 2013

Summary: This document is ready for publication as an Informational
RFC. =A0Some additional text in the security considerations section (or
pointers to external text) may be useful, but is not absolutely required.
Minor Issues: =A0The text in the security considerations does not seem to consider some attacks which appear obvious in light of the discussion of federation. =A0The federation example points out that the mismatch between<= br> client capabilities may cause calls to be initiated with costs contrary
to the expectation of the end user; this could, of course, be done
maliciously as well as by accident. =A0A back reference to the federation section with appropriate text (or text focusing on the attack surface)
might be appropriate.

Good point!


Nits: I find the text:

=A0 =A0 =A0Today, in the context of the SIMPLE working group,

somewhat odd in the context of an archival document.

Indeed. Removed.

A new version that incorporates your feedback is available here:

https://github.com/emcho/cusax/raw/master/= draft-ivov-xmpp-cusax-07.txt

(will re-submit as soon as instructed from our shepherd or ID)

Does this address your comments?

Thanks,
Emil

--
https://jitsi.org

--089e014954bedc5b9204e19407b1-- From superuser@gmail.com Mon Jul 15 17:21:41 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C469021E8195 for ; Mon, 15 Jul 2013 17:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9SGMYhk4eBW for ; Mon, 15 Jul 2013 17:21:41 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id AAB0221E8186 for ; Mon, 15 Jul 2013 17:21:40 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id m6so52987wiv.9 for ; Mon, 15 Jul 2013 17:21:39 -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=/k+DyMuHTRBibAkHeynfDMjLQRbda5mdI+llYpDt4u8=; b=DEi3PS60Lo9o4vCxz2BOvT33Y5DVgwc2bmiOrcKAPK2WLeFtHd3Wutus9KR5ZttfNx urWZDRzF6dIFcv5FWnlGHQyyqrUYuUJOLa2MefdHyxgf9TEMQ2Jv4zC5diY50B7RKJ8E k6B+y59nljAuIDSalKYJB8d5PGqMF4scGZ+zZz2KacMxL8O2i4rXqNM6evZsyJ//WxUb dFKykLjVFObxTXF+LI0US28yNXk03i0Dlfwu39qnv2odLHk8jUJ7ThXm4b6EqpTGSPfb yXfTt41clKgelj9UvsHn+7P7RfNKWISa90zSzkg7/BQ+f1FoVfWoXFR9/fl60AIfo3eZ LfeQ== MIME-Version: 1.0 X-Received: by 10.180.89.231 with SMTP id br7mr10653003wib.19.1373934099754; Mon, 15 Jul 2013 17:21:39 -0700 (PDT) Received: by 10.180.90.16 with HTTP; Mon, 15 Jul 2013 17:21:39 -0700 (PDT) Date: Mon, 15 Jul 2013 17:21:39 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=e89a8f3ba255f5f60904e195f57a Subject: [apps-discuss] FINAL CALL for IETF 87 (Berlin) agenda items X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 16 Jul 2013 00:21:41 -0000 --e89a8f3ba255f5f60904e195f57a Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 26, 2013 at 5:32 PM, Murray S. Kucherawy wrote: > On Mon, May 20, 2013 at 4:56 PM, Murray S. Kucherawy wrote: > >> Colleagues, >> >> As usual, we will be requesting a Monday morning slot. This is a call >> for agenda items, or suggestions for same. Please submit them before June >> 3rd, which is the cutoff date for submitting or amending meeting requests. >> We will request the usual 2.5 hour session, but we'll shrink it if our >> agenda appears to be thin enough. >> >> You can expect the usual general structure: >> >> - administrivia >> - APPSAWG section >> --- recent activity >> --- current document status and open document issues [*] >> --- incoming/proposed new work [*] >> --- other WG business [*] >> - APPAREA section >> --- new WGs of interest >> --- BoF overview >> --- area-specific topics / AD theatre [*] >> --- presentations [*] >> --- AOB [*] >> >> If you have something you'd like to present in any of the [*] slots >> above, please reply to this post. If you will be chairing a BoF or a new >> WG and would like to present on that, you are also invited to reply for an >> agenda slot. >> >> > We've only received one single request for a time slot. I'm preparing the agenda now since we have to have one posted by Wednesday. If anyone would like time on this agenda, please say so now. Also, this meeting in general will be extremely tight time-wise, so if we don't really need the full 2 1/2 hour time slot, we should determine that and let the Secretariat know so a smaller WG or a BoF could get the extra time it might need. Does anyone wish to present, or request a presentation, other than the usual administrivia and overview/update items from the chairs and the ADs? -MSK, APPSAWG co-chair --e89a8f3ba255f5f60904e195f57a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jun 26, 2013 at 5:32 PM, Murray S. Kucherawy <s= uperuser@gmail.com> wrote:
On Mon, May 20, 2013 at 4:5= 6 PM, Murray S. Kucherawy <superuser@gmail.com> wrote:
Colleagues,

As usual, we = will be requesting a Monday morning slot.=A0 This is a call for agenda item= s, or suggestions for same.=A0 Please submit them before June 3rd, which is= the cutoff date for submitting or amending meeting requests.=A0 We will re= quest the usual 2.5 hour session, but we'll shrink it if our agenda app= ears to be thin enough.

You can expect the usual general structure:

- admini= strivia
- APPSAWG section
--- recent activity
--= - current document status and open document issues [*]
--- incomin= g/proposed new work [*]
--- other WG business [*]
- APPAREA section
--- new= WGs of interest
--- BoF overview
--- area-specific topic= s / AD theatre [*]
--- presentations [*]
--- AOB [*]

If you have something you'd like to present in any of the [*] slo= ts above, please reply to this post.=A0 If you will be chairing a BoF or a = new WG and would like to present on that, you are also invited to reply for= an agenda slot.


=

We've only received one single request for a time slot.=A0 I&#= 39;m preparing the agenda now since we have to have one posted by Wednesday= .=A0 If anyone would like time on this agenda, please say so now.

Also, this meeting in general will be extremely tight time-wise, so if = we don't really need the full 2 1/2 hour time slot, we should determine= that and let the Secretariat know so a smaller WG or a BoF could get the e= xtra time it might need.

Does anyone wish to present, or request a presentation, other than the usua= l administrivia and overview/update items from the chairs and the ADs?
<= br>-MSK, APPSAWG co-chair


--e89a8f3ba255f5f60904e195f57a-- From anything@michielbdejong.com Tue Jul 16 07:55:18 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B48221F9B58 for ; Tue, 16 Jul 2013 07:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.306 X-Spam-Level: X-Spam-Status: No, score=-3.306 tagged_above=-999 required=5 tests=[AWL=0.293, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id edJ3fyyAQYjD for ; Tue, 16 Jul 2013 07:55:11 -0700 (PDT) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) by ietfa.amsl.com (Postfix) with ESMTP id 559B221F9B21 for ; Tue, 16 Jul 2013 07:55:05 -0700 (PDT) Received: from mfilter24-d.gandi.net (mfilter24-d.gandi.net [217.70.178.152]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id BBE5441C07E; Tue, 16 Jul 2013 16:54:53 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter24-d.gandi.net Received: from relay5-d.mail.gandi.net ([217.70.183.197]) by mfilter24-d.gandi.net (mfilter24-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id jMYNvrPzVP61; Tue, 16 Jul 2013 16:54:52 +0200 (CEST) X-Originating-IP: 10.58.1.146 Received: from webmail.gandi.net (unknown [10.58.1.146]) (Authenticated sender: anything@michielbdejong.com) by relay5-d.mail.gandi.net (Postfix) with ESMTPA id 78B6741C09D; Tue, 16 Jul 2013 16:54:48 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Date: Tue, 16 Jul 2013 16:54:48 +0200 From: "Michiel B. de Jong" To: Paul Hoffman In-Reply-To: References: <6BC44D72-BAA1-41B6-BFE8-9FD7A9D4CECF@mnot.net> <8ee3a48c1d3c44eb5bba7b08b3f77579@michielbdejong.com> Message-ID: <49e581fd7805d8615d462e5b05cbe0ce@michielbdejong.com> X-Sender: anything@michielbdejong.com User-Agent: Roundcube Webmail/0.7.2 Content-Transfer-Encoding: quoted-printable Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Possible bar BoF / side meeting on non-proprietary sync X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 16 Jul 2013 14:55:19 -0000 On 2013-07-10 16:03, Paul Hoffman wrote: > On Jul 10, 2013, at 2:57 AM, Michiel B. de Jong > wrote: > >> On 2013-07-10 07:30, Mark Nottingham wrote: >>> it might be better to arrange a "Bar BoF" (i.e., informal >>> meeting) for folks who are interested to discuss this; registration >>> isn't necessary for that (as it often occurs in a bar or similar >>> space). Even if that doesn't happen, I'd love to talk over a=20 >>> coffee. >> >> ok, great! yes, let's do that then. > > When you decide a time and place for the informal meeting, by all > means send a message to this list; others here would be interested as > well. > > --Paul Hoffman yes! I propose the following, let me know if you think this will work: On the Monday evening, directly after the technical plenary finishes=20 (which should be around 19:40=20 https://datatracker.ietf.org/meeting/87/agenda.txt ), I will hold up a=20 sign reading "non-proprietary sync Bar BoF", so we can gather. Then=20 among the people who show up, we decide to either do it there in the=20 foyer, or go for some food, or whatever the group decides. If someone=20 has trouble locating us, they can phone me on +49-1577.6858.499. The proposed topic of this Bar BoF will be "non-prioprietary cloud=20 sync", so something like Dropbox, GoogleDrive, SkyDrive, etcetera, but=20 as an open standard. One work-in-progress for this would be=20 remoteStorage, by Fran=C3=A7ois Kooman and myself, in this internet draft= :=20 http://www.ietf.org/id/draft-dejong-remotestorage-01.txt. cheers, Michiel From hallam@gmail.com Tue Jul 16 08:36:34 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E12E11E80DC for ; Tue, 16 Jul 2013 08:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[AWL=-0.676, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ry4HvlZqTnLt for ; Tue, 16 Jul 2013 08:36:33 -0700 (PDT) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id EB87911E80D5 for ; Tue, 16 Jul 2013 08:36:31 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id t56so756938wes.21 for ; Tue, 16 Jul 2013 08:36:31 -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=NVMfS3ZKt69qGEZeRXRfjDKOKU0TvyjD1oWsJ6nGJXw=; b=1D+dtzGSpK4GqKZv0Alk/UH3m+GsgMAynMH6dfd4nlf4Oc2PS8lw0XuFUOND0ElR1M 1ULNZP2fzkAFoUpfJ2iV8kv5PPfQ3G2k4vbwkhm7SSJn7QgUPlWaeQv5THa3M6tbBFn7 Hz4mEk9D8c/BK9amKwDbORU2MnZJTQIJgpXWN5+k7emF3rSAHdhApaaR88S/hhsQ9KHD JyP3lmQbDAYQW4L0Lt4+Pap/TF2ZZvqV/+YTB56WbY9k0auYCm6R56v4cmve288rZ2zC qSzH9rs299fpRL8knrLmXvcjLUa/9zjAi0RNnKnSWA+NG6DzPfSaB+z136RcRxotVxzJ b2sw== MIME-Version: 1.0 X-Received: by 10.180.107.167 with SMTP id hd7mr1566937wib.33.1373988990919; Tue, 16 Jul 2013 08:36:30 -0700 (PDT) Received: by 10.194.6.65 with HTTP; Tue, 16 Jul 2013 08:36:30 -0700 (PDT) In-Reply-To: <49e581fd7805d8615d462e5b05cbe0ce@michielbdejong.com> References: <6BC44D72-BAA1-41B6-BFE8-9FD7A9D4CECF@mnot.net> <8ee3a48c1d3c44eb5bba7b08b3f77579@michielbdejong.com> <49e581fd7805d8615d462e5b05cbe0ce@michielbdejong.com> Date: Tue, 16 Jul 2013 11:36:30 -0400 Message-ID: From: Phillip Hallam-Baker To: "Michiel B. de Jong" Content-Type: multipart/alternative; boundary=e89a8f2353a7baae9904e1a2bdcf Cc: Paul Hoffman , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Possible bar BoF / side meeting on non-proprietary sync X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 16 Jul 2013 15:36:34 -0000 --e89a8f2353a7baae9904e1a2bdcf Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I can't be there and I can't participate right now due to a court case I am involved in. There is relevant IP that is being asserted but the priority date is 11th April 1995. So I think this is a good time to start looking at an open standard. It seems to me that the question everyone will ask is 'how is this different from a network file store'. The answer in my view is that a network file store supports file locking and incremental updates which are very complicated to implement. This is not what most people want or need in a backup or file replication system. People might be interested in the tool I am currently working on, the Protocol Designer's Workbench which is a set of tools that allow a developer to specify a protocol in an abstract schema language that is not tied to any given encoding which can then be used to generate documentation, examples and production code for a low volume client and server. At present the tool generates code in C# that uses JSON for encoding of protocol messages and HTTP for transport. The next version will support C as an option and at least one binary encoding of JSON. Support for conformance testing and high volume production services will be added over time. The big advantage to using a tool is that the documentation is always locked to the specification and the code. So instead of someone making a change to the document but not the spec and people discovering the issue 6 months down the line, everything is always in sync. On Tue, Jul 16, 2013 at 10:54 AM, Michiel B. de Jong < anything@michielbdejong.com> wrote: > On 2013-07-10 16:03, Paul Hoffman wrote: > >> On Jul 10, 2013, at 2:57 AM, Michiel B. de Jong >> wrote: >> >> On 2013-07-10 07:30, Mark Nottingham wrote: >>> >>>> it might be better to arrange a "Bar BoF" (i.e., informal >>>> meeting) for folks who are interested to discuss this; registration >>>> isn't necessary for that (as it often occurs in a bar or similar >>>> space). Even if that doesn't happen, I'd love to talk over a coffee. >>>> >>> >>> ok, great! yes, let's do that then. >>> >> >> When you decide a time and place for the informal meeting, by all >> means send a message to this list; others here would be interested as >> well. >> >> --Paul Hoffman >> > > yes! I propose the following, let me know if you think this will work: > > On the Monday evening, directly after the technical plenary finishes > (which should be around 19:40 https://datatracker.ietf.org/** > meeting/87/agenda.txt ), I will hold up a sign reading "non-proprietary sync Bar BoF", so we can > gather. Then among the people who show up, we decide to either do it ther= e > in the foyer, or go for some food, or whatever the group decides. If > someone has trouble locating us, they can phone me on +49-1577.6858.499. > > The proposed topic of this Bar BoF will be "non-prioprietary cloud sync", > so something like Dropbox, GoogleDrive, SkyDrive, etcetera, but as an ope= n > standard. One work-in-progress for this would be remoteStorage, by Fran= =E7ois > Kooman and myself, in this internet draft: http://www.ietf.org/id/draft-*= * > dejong-remotestorage-01.txt > . > > > cheers, > Michiel > > ______________________________**_________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/**listinfo/apps-discuss > --=20 Website: http://hallambaker.com/ --e89a8f2353a7baae9904e1a2bdcf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I can't be there and I can't participate right now= due to a court case I am involved in. There is relevant IP that is being a= sserted but the priority date is 11th April 1995. So I think this is a good= time to start looking at an open standard.


It seems to me that the question everyone will ask = is 'how is this different from a network file store'.=A0
=
The answer in my view is that a network file store supports = file locking and incremental updates which are very complicated to implemen= t. This is not what most people want or need in a backup or file replicatio= n system.=A0


People might be interested in the tool I= am currently working on, the Protocol Designer's Workbench which is a = set of tools that allow a developer to specify a protocol in an abstract sc= hema language that is not tied to any given encoding which can then be used= to generate documentation, examples and production code for a low volume c= lient and server.

At present the tool generates code in C# that uses JSON= for encoding of protocol messages and HTTP for transport. The next version= will support C as an option and at least one binary encoding of JSON. Supp= ort for conformance testing and high volume production services will be add= ed over time.

The big advantage to using a tool is that the doc= umentation is always locked to the specification and the code. So instead o= f someone making a change to the document but not the spec and people disco= vering the issue 6 months down the line, everything is always in sync.



On Tue, Jul 16, 2013 at 10:54 AM, Michiel B. de Jong <an= ything@michielbdejong.com> wrote:
On 2013-07-10 16:03, Paul = Hoffman wrote:
On Jul 10, 2013, at 2:57 AM, Michiel B. de Jong
<anythi= ng@michielbdejong.com> wrote:

On 2013-07-10 07:30, Mark Nottingham wrote:
it might be better to arrange a "Bar BoF" (i.e., informal
meeting) for folks who are interested to discuss this; registration
isn't necessary for that (as it often occurs in a bar or similar
space). Even if that doesn't happen, I'd love to talk over a coffee= .

ok, great! yes, let's do that then.

When you decide a time and place for the informal meeting, by all
means send a message to this list; others here would be interested as
well.

--Paul Hoffman

yes! I propose the following, let me know if you think this will work:

On the Monday evening, directly after the technical plenary finishes (which= should be around 19:40 https://datatracker.ietf.org/meeting/8= 7/agenda.txt ), I will hold up a sign reading "non-proprietary syn= c Bar BoF", so we can gather. Then among the people who show up, we de= cide to either do it there in the foyer, or go for some food, or whatever t= he group decides. If someone has trouble locating us, they can phone me on = +49-1577.6858.499.

The proposed topic of this Bar BoF will be "non-prioprietary cloud syn= c", so something like Dropbox, GoogleDrive, SkyDrive, etcetera, but as= an open standard. One work-in-progress for this would be remoteStorage, by= Fran=E7ois Kooman and myself, in this internet draft: http://w= ww.ietf.org/id/draft-dejong-remotestorage-01.txt.


cheers,
Michiel

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



--
= Website: http://hallambaker.com/
--e89a8f2353a7baae9904e1a2bdcf-- From emil@sip-communicator.org Mon Jul 15 14:58:16 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E04821E8158 for ; Mon, 15 Jul 2013 14:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.464 X-Spam-Level: X-Spam-Status: No, score=-3.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bd6rkCpg+Xm7 for ; Mon, 15 Jul 2013 14:58:10 -0700 (PDT) Received: from mail-we0-f179.google.com (mail-we0-f179.google.com [74.125.82.179]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB4221F9FC8 for ; Mon, 15 Jul 2013 14:58:08 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id w59so10359646wes.24 for ; Mon, 15 Jul 2013 14:58:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=nv6ScJvXAxYB0CVKTx0+gDbub4sBlzFsgvTg6nlUi5E=; b=Mz2tJPVUDhHKeaq0KAIA8NXznsXBvv5J53tSIcD/8748MWo8ZYgaDT0kAFUMvrooCl xwHbotyRGB/dlvkBYcpgOzLwc89kmlSFDB0Gac6BvwDrkYEohumvLlHNu+GOAyGSSesg /GF/BH+XeeT295dZz3FsrTQtpv05MdXnZLiK7E8vvYdGb99/4jsLgIEkN5/sgKfGkPtb ulXmXdpJ9gHAge/LEoWvUG5scSjsDN/B3dNCQn83Pr0btSp79BKJtOM7alvboObDKRq2 uUzm+MPGQhPsP6uq2pQUvpyAHprWQ8SftovakdP+iQLd+3t87CFlDssIpzmgVGmw9sd3 rBMQ== X-Received: by 10.194.24.40 with SMTP id r8mr32832719wjf.7.1373925488097; Mon, 15 Jul 2013 14:58:08 -0700 (PDT) Received: from camionet.local ([2a01:e35:8a55:abc0:f8c9:ce4e:4a54:3740]) by mx.google.com with ESMTPSA id u7sm17996649wiw.9.2013.07.15.14.58.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 15 Jul 2013 14:58:07 -0700 (PDT) Message-ID: <51E4706C.7070607@jitsi.org> Date: Mon, 15 Jul 2013 23:58:04 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Ted Hardie References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmkQOuNjhjlhkJXs7pYuQ+kas02JwRsyb8Xd/ssFHa4nzVRnHrgo8ZojrLVDGg/Vf2y7Z4f X-Mailman-Approved-At: Tue, 16 Jul 2013 10:27:43 -0700 Cc: draft-ivov-xmpp-cusax.all@tools.ietf.org, IESG , apps-discuss@ietf.org Subject: Re: [apps-discuss] Apps directorate review of draft-ivov-xmpp-cusax X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 15 Jul 2013 21:58:16 -0000 Hey Ted, On 15.07.13, 18:46, Ted Hardie wrote: > I have been selected as the Applications Area Directorate reviewer for > this draft (for background on appsdir, please see > http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). > > Please resolve these comments along with any other Last Call comments > you may receive. Please wait for direction from your document shepherd > or AD before posting a new version of the draft. > > Document: draft-ivov-xmpp-cusax-06 > > Title: CUSAX: Combined Use of the Session Initiation Protocol (SIP) and > the Extensible Messaging and Presence Protocol (XMPP) > > Reviewer: Ted Hardie > Review Date: July 15th, 2013 > > Summary: This document is ready for publication as an Informational > RFC. Some additional text in the security considerations section (or > pointers to external text) may be useful, but is not absolutely required. > > Minor Issues: The text in the security considerations does not seem to > consider some attacks which appear obvious in light of the discussion of > federation. The federation example points out that the mismatch between > client capabilities may cause calls to be initiated with costs contrary > to the expectation of the end user; this could, of course, be done > maliciously as well as by accident. A back reference to the federation > section with appropriate text (or text focusing on the attack surface) > might be appropriate. Good point! > Nits: I find the text: > > Today, in the context of the SIMPLE working group, > > somewhat odd in the context of an archival document. Indeed. Removed. A new version that incorporates your feedback is available here: https://github.com/emcho/cusax/raw/master/draft-ivov-xmpp-cusax-07.txt (will re-submit as soon as instructed from our shepherd or ID) Does this address your comments? Thanks, Emil -- https://jitsi.org From pritikin@cisco.com Mon Jul 15 10:35:13 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 711A911E8189; Mon, 15 Jul 2013 10:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7NtOQF5x+oFg; Mon, 15 Jul 2013 10:35:08 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id BAC4921E810B; Mon, 15 Jul 2013 10:35:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14853; q=dns/txt; s=iport; t=1373909708; x=1375119308; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Em8XDpqP8OaWT8LkAluQUyo9NE9IrEy6Xmk5gRT81GY=; b=Jb3nLtb/X0FaXDcuyl/sgZd2F3zvHUXuF/9vGc/RBhTaG7JLd3fWlLyE 32v0tEuXj/nK4ZTXlS60M3dqjduoDXiJqGavxrCh0snwE/TglZDFDFq1u tPSXIvRioBwjwTGtm05Z+lYUmgBGBkSvhuElUlKhr0K2BzaLcKTKipgTF k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAG0x5FGtJXG//2dsb2JhbABaEwEBgnE0T4MGvkwXfBZ0giQBAQQjVhACAQgUDg4PAwICAjAUEQIEDgUIiAgMpDKRNo8zFgoRBxiCQDNtA5kFkCSDEoIo X-IronPort-AV: E=Sophos;i="4.89,670,1367971200"; d="scan'208,217";a="232036567" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-9.cisco.com with ESMTP; 15 Jul 2013 17:35:06 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r6FHZ6UE008336 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Jul 2013 17:35:06 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.100]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Mon, 15 Jul 2013 12:35:05 -0500 From: "Max Pritikin (pritikin)" To: Tobias Gondrom Thread-Topic: AppsDir review of draft-ietf-pkix-est-07 Thread-Index: AQHOcYHaAyHlhd28ukShR/BkvN205ple/ByAgACaWgCABt2fAA== Date: Mon, 15 Jul 2013 17:35:05 +0000 Message-ID: <53EA47528D6ACF4486AA152F92C2B698EDB916@xmb-rcd-x03.cisco.com> References: <51C954C5.4060401@gondrom.org> <53EA47528D6ACF4486AA152F92C2B698ED617B@xmb-rcd-x03.cisco.com> <51DE7062.3000607@gondrom.org> In-Reply-To: <51DE7062.3000607@gondrom.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.0.1] Content-Type: multipart/alternative; boundary="_000_53EA47528D6ACF4486AA152F92C2B698EDB916xmbrcdx03ciscocom_" MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 16 Jul 2013 10:38:17 -0700 Cc: "" , "" Subject: Re: [apps-discuss] AppsDir review of draft-ietf-pkix-est-07 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 15 Jul 2013 17:35:13 -0000 --_000_53EA47528D6ACF4486AA152F92C2B698EDB916xmbrcdx03ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmVzcG9uc2UgaW5saW5lLA0KDQpPbiBKdWwgMTEsIDIwMTMsIGF0IDI6NDQgQU0sIFRvYmlhcyBH b25kcm9tIDx0b2JpYXMuZ29uZHJvbUBnb25kcm9tLm9yZzxtYWlsdG86dG9iaWFzLmdvbmRyb21A Z29uZHJvbS5vcmc+PiB3cm90ZToNCg0KRmluZSB3aXRoIG5lYXJseSBldmVyeSBhbnN3ZXIuDQpP bmUgY29tbWVudCBpbmxpbmUuDQpCZXN0IHJlZ2FyZHMsIFRvYmlhcw0KDQoNCk9uIDExLzA3LzEz IDA2OjMxLCBNYXggUHJpdGlraW4gKHByaXRpa2luKSB3cm90ZToNClRoaXMgc2VyaWVzIG9mIGVt YWlscyBkZXRhaWxzIHRoZSBFU1QgdXBkYXRlcyB0byBlc3QtMDcgaW4gcmVzcG9uc2UgdG8gdGhl IGNvbW1lbnRzIGJlbG93LA0KDQpPbiBKdW4gMjUsIDIwMTMsIGF0IDI6MjggQU0sIFRvYmlhcyBH b25kcm9tIDx0b2JpYXMuZ29uZHJvbUBnb25kcm9tLm9yZzxtYWlsdG86dG9iaWFzLmdvbmRyb21A Z29uZHJvbS5vcmc+PiB3cm90ZToNCg0KSSBoYXZlIGJlZW4gc2VsZWN0ZWQgYXMgdGhlIEFwcGxp Y2F0aW9ucyBBcmVhIERpcmVjdG9yYXRlIHJldmlld2VyIGZvcg0KdGhpcyBkcmFmdCAoZm9yIGJh Y2tncm91bmQgb24gYXBwc2RpciwgcGxlYXNlIHNlZSDigIsNCmh0dHA6Ly90cmFjLnRvb2xzLmll dGYub3JnL2FyZWEvYXBwL3RyYWMvd2lraS9BcHBsaWNhdGlvbnNBcmVhRGlyZWN0b3JhdGUgKS4N Cg0KUGxlYXNlIHJlc29sdmUgdGhlc2UgY29tbWVudHMgYWxvbmcgd2l0aCBhbnkgb3RoZXIgTGFz dCBDYWxsIGNvbW1lbnRzDQp5b3UgbWF5IHJlY2VpdmUuIFBsZWFzZSB3YWl0IGZvciBkaXJlY3Rp b24gZnJvbSB5b3VyIGRvY3VtZW50IHNoZXBoZXJkDQpvciBBRCBiZWZvcmUgcG9zdGluZyBhIG5l dyB2ZXJzaW9uIG9mIHRoZSBkcmFmdC4NCg0KRG9jdW1lbnQ6IGRyYWZ0LWlldGYtcGtpeC1lc3Qt MDcNClRpdGxlOiBFbnJvbGxtZW50IG92ZXIgU2VjdXJlIFRyYW5zcG9ydA0KUmV2aWV3ZXI6IFRv YmlhcyBHb25kcm9tDQpSZXZpZXcgRGF0ZTogMjUuNi4yMDEzDQoNClN1bW1hcnk6IFRoZSBkcmFm dCBsb29rcyBmaW5lLg0KSXQgaXMgaGVhZGluZyBmb3IgU1REIHRyYWNrIGFuZCBtb3N0bHkgZGVz Y3JpYmVzIFNpbXBsZSBQS0kgb3ZlciBUTFMgKGFuZCB1c2luZyB0aGUgcHJvdGVjdGVkIGNoYW5u ZWwgbWVjaGFuaXNtcyBmb3IgbXV0dWFsIGF1dGhlbnRpY2F0aW9uIGFzIHdlbGwgKGJleW9uZCBz aW1wbGUgY29uZmlkZW50aWFsaXR5KSkuDQoNCmNvbW1lbnRzOg0KDQoNCjEuIHNlY3Rpb24gMi4y LjIgYW5kIDIuMi4zDQooIGNsaWVudCB2ZXJpZmljYXRpb24uKQ0KKENlcnRpZmljYXRlLWxlc3Mg VExTIChlLmcuLCB3aXRoIGEgc2hhcmVkIGNyZWRlbnRpYWwgZGlzdHJpYnV0ZWQgb3V0LW9mLWJh bmQpOw0KYW5kIEhUVFAtYmFzZWQgd2l0aCBhIHVzZXJuYW1lL3Bhc3N3b3JkIGRpc3RyaWJ1dGVk IG91dC1vZi1iYW5kLikNCg0KbWFrZSBzdXJlIHRvIGF2b2lkIGluZm9ybWF0aW9uIGxlYWthZ2Uu IEUuZy4gaW4gY2FzZSBvZiBjZXJ0aWZpY2F0ZS1sZXNzIFRMUywgaWYgY29va2llcyBhcmUgdXNl ZCwgbWFrZSBzdXJlIHRoYXQgYXJlIG5vdCB0cmFuc21pdHRlZCBvdmVyIHRoZSBub3JtYWwgdW5w cm90ZWN0ZWQgSFRUUCBiYW5kLg0KKHNlY3Rpb24gMy4yLjMgYWxyZWFkeSBzcGVjaWZpZXMgdGhh dCAiSFRUUCBCYXNpYyBhbmQgRGlnZXN0IGF1dGhlbnRpY2F0aW9uIE1VU1Qgb25seSBiZSBwZXJm b3JtZWQgb3ZlciBUTFMgMS4xIFtSRkM0MzQ2XSBvciBsYXRlciB2ZXJzaW9ucy4iIHdoaWNoIGlz IGdvb2QuKQ0KDQpUaGlzIHN0YXRlbWVudCBpbiAzLjIuMyByZS1lbmZvcmNlcyB0aGUgc3RhdGVt ZW50IGluIFNlY3Rpb24gMy4zIHRoYXQgIkhUVFBTIE1VU1QgYmUgdXNlZC4gIFRMUyAxLjEgW1JG QzQzNDZdIChvciBhIGxhdGVyIHZlcnNpb24pIE1VU1QgYmUgdXNlZC4iDQpBcmd1YWJseSB0aGVz ZSBzdGF0ZW1lbnRzIGNvdWxkIGJlIGNvbmRlbnNlZCBpbnRvIDIxMTkgYXNzZXJ0aW9uIChhbHRo b3VnaCB3ZSBoYXZlIG5vdCBkb25lIHRoaXMpLg0KDQoyLiBzZWN0aW9uIDMuMi40Og0Kd2hlbiBy ZWdpc3RlcmluZyAgImFwcGxpY2F0aW9uL2NzcmF0dHJzIiB3aXRoIElBTkEgaW4gc2VjdGlvbiA2 DQpJIHNlZSB5b3UgaGF2ZSBubyBNYWdpYyBudW1iZXIgb3IgZmlsZSBleHRlbnNpb24uDQpJcyB0 aGVyZSBhIGNoYW5jZSB0aGF0IHRoaXMgcmVxdWVzdCBtaWdodCBhdCBzb21lIHBvaW50IGJlIG1h ZGUgd2l0aG91dCBkaXJlY3QgSFRUUCBhbmQgbWlnaHQgd2FudCBzb21lIG9mIHRoZSB0d28/DQoN CkEgZmlsZSBleHRlbnNpb24gKCIuY3NyYXR0cnMiKSBoYXMgYmVlbiBhZGRlZC4NCg0KMy4gc2Vj dGlvbiAzLjIuMjoNCmFzIHlvdSB3YW50IHRvIG9mZmVyIHRvIHVzZSBIVFRQIFBPU1QgYW5kIEdF VC4NCkkgYW0gbm90IHNvIGhhcHB5IGFib3V0IHRoZSBIVFRQIEdFVCBwYXJ0cy4gSG93IGRvIHlv dSBjb25zaWRlciB0aGUgcmlzayBvZiBpbmZvcm1hdGlvbiBsZWFrYWdlIHdpdGggSFRUUCBHRVQg d2hlbiB5b3UgaGF2ZSBlLmcuIGxhYmVscz8NCmUuZy4gaW4gY2FzZSBvZiAgICAiMi4gIGh0dHBz Oi8vd3d3LmV4YW1wbGUuY29tLy53ZWxsLWtub3duL2VzdC9hcmJpdHJhcnlMYWJlbDEvY2FjZXJ0 cyINCg0KSW5mcmFzdHJ1Y3R1cmVzIHRoYXQgd2lzaCB0byBrZWVwIHRoZWlyIHB1YmxpYyBjZXJ0 aWZpY2F0ZSBpbmZyYXN0cnVjdHVyZSBkZXRhaWxzIHByaXZhdGUgY2FuIGVuZm9yY2UgY2xpZW50 IGF1dGhlbnRpY2F0aW9uIGR1cmluZyBHRVQgb3BlcmF0aW9ucyBhcyBzcGVjaWZpZWQgaW4gczQu MS4yICgiRVNUIHNlcnZlciBTSE9VTEQgTk9UIHJlcXVpcmUgY2xpZW50IGF1dGhlbnRpY2F0aW9u IikuDQoNCkhtLiBOb3Qgc3VyZS4gVGhpcyBkb2VzIHBvdGVudGlhbGx5IG5vdCBmdWxmaWxsIGFs bCBzZWN1cml0eSBuZWVkczogYmVjYXVzZSBldmVuIGlmIHlvdSB1c2UgYXV0aGVudGljYXRpb24s IHlvdSB3aWxsIHN0aWxsIGxlYWsgdGhlIGluZm9ybWF0aW9uIGluIHRoZSBHRVQgVVJMIHRvIGV2 ZXJ5b25lIGluIHlvdXIgSFRUUC9UQ1AgcGF0aC4gSXMgdGhpcyBhIHByb2JsZW0/DQoNCkJlY2F1 c2UgVExTIGlzIG1hbmRhdGVkIGFueSBhdHRhY2tlciBvbiBwYXRoIHdpbGwgb25seSBoYXZlIGFj Y2VzcyB0byB0aGUgZW5jcnlwdGVkIGRhdGEuDQoNCi0gbWF4DQoNClNlY29uZCB5b3UgbWF5IGNv bnNpZGVyIHRvIG5vdGUgVVJJIGxlbmd0aCBsaW1pdGF0aW9ucyBpbiBHRVQgcmVxdWVzdHMuDQoN ClJlamVjdDogVGhlcmUgaXMgcGxlbnR5IGFib3V0IFVSSS9IVFRQL2V0YyB0aGF0IHdlIGFyZSBu b3Qgbm90aW5nDQoNCm5pdHM6DQpwYWdlIDMyDQpzL3RvIHVzZSB0aGUgdGhlIHNlY3AzODRyMSBl bGxpcHRpYyBjdXJ2ZS90byB1c2UgdGhlIHNlY3AzODRyMSBlbGxpcHRpYyBjdXJ2ZQ0KDQpmaXhl ZC4NCg0KDQoNCk9oIGFuZCB5b3Ugc2hvdWxkIGNsZWFuIHVwIGlkbml0czoNCiAqKiBEb3ducmVm OiBOb3JtYXRpdmUgcmVmZXJlbmNlIHRvIGFuIEluZm9ybWF0aW9uYWwgUkZDOiBSRkMgMjk4Ng0K ICAqKiBPYnNvbGV0ZSBub3JtYXRpdmUgcmVmZXJlbmNlOiBSRkMgNDM0NiAoT2Jzb2xldGVkIGJ5 IFJGQyA1MjQ2KQ0KDQpBcyBwcmV2aW91c2x5IG5vdGVkIG9uIHRocmVhZCB0aGVzZSBhcmUgYWNj ZXB0YWJsZS4NCg0KLSBtYXgNCg0KDQoNCkJlc3QgcmVnYXJkcywgVG9iaWFzDQoNCg0KDQoNCg0K --_000_53EA47528D6ACF4486AA152F92C2B698EDB916xmbrcdx03ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <76C3A4BA9E24134C8FD6ED69355EF8FB@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgIj4NClJlc3BvbnNlIGlubGluZSwmbmJzcDsNCjxkaXY+ PGJyPg0KPGRpdj4NCjxkaXY+T24gSnVsIDExLCAyMDEzLCBhdCAyOjQ0IEFNLCBUb2JpYXMgR29u ZHJvbSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRvYmlhcy5nb25kcm9tQGdvbmRyb20ub3JnIj50b2Jp YXMuZ29uZHJvbUBnb25kcm9tLm9yZzwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJB cHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRp diB0ZXh0PSIjMDAwMDAwIiBiZ2NvbG9yPSIjRkZGRkZGIj4NCjxkaXYgY2xhc3M9Im1vei1jaXRl LXByZWZpeCI+RmluZSB3aXRoIG5lYXJseSBldmVyeSBhbnN3ZXIuIDxicj4NCk9uZSBjb21tZW50 IGlubGluZS4gPGJyPg0KQmVzdCByZWdhcmRzLCBUb2JpYXM8YnI+DQo8YnI+DQo8YnI+DQpPbiAx MS8wNy8xMyAwNjozMSwgTWF4IFByaXRpa2luIChwcml0aWtpbikgd3JvdGU6PGJyPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBjaXRlPSJtaWQ6NTNFQTQ3NTI4RDZBQ0Y0NDg2QUExNTJGOTJDMkI2OThF RDYxN0JAeG1iLXJjZC14MDMuY2lzY28uY29tIiB0eXBlPSJjaXRlIj4NCjxkaXY+VGhpcyBzZXJp ZXMgb2YgZW1haWxzIGRldGFpbHMgdGhlIEVTVCB1cGRhdGVzIHRvIGVzdC0wNyBpbiByZXNwb25z ZSB0byB0aGUgY29tbWVudHMgYmVsb3csPC9kaXY+DQo8ZGl2PiZuYnNwOzxicj4NCjxkaXY+DQo8 ZGl2Pk9uIEp1biAyNSwgMjAxMywgYXQgMjoyOCBBTSwgVG9iaWFzIEdvbmRyb20gJmx0OzxhIG1v ei1kby1ub3Qtc2VuZD0idHJ1ZSIgaHJlZj0ibWFpbHRvOnRvYmlhcy5nb25kcm9tQGdvbmRyb20u b3JnIj50b2JpYXMuZ29uZHJvbUBnb25kcm9tLm9yZzwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJy IGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNp dGUiPg0KPGRpdiB0ZXh0PSIjMDAwMDAwIiBiZ2NvbG9yPSIjRkZGRkZGIj4NCjxkaXYgY2xhc3M9 Im1vei10ZXh0LWh0bWwiIGxhbmc9IngtdW5pY29kZSI+PGZvbnQgZmFjZT0iQXJpYWwiPkkgaGF2 ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBBcHBsaWNhdGlvbnMgQXJlYSBEaXJlY3RvcmF0ZSByZXZp ZXdlciBmb3INCjxicj4NCnRoaXMgZHJhZnQgKGZvciBiYWNrZ3JvdW5kIG9uIGFwcHNkaXIsIHBs ZWFzZSBzZWUg4oCLIDxicj4NCjxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgY2xhc3M9Im1vei10 eHQtbGluay1mcmVldGV4dCIgaHJlZj0iaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYXJlYS9h cHAvdHJhYy93aWtpL0FwcGxpY2F0aW9uc0FyZWFEaXJlY3RvcmF0ZSI+aHR0cDovL3RyYWMudG9v bHMuaWV0Zi5vcmcvYXJlYS9hcHAvdHJhYy93aWtpL0FwcGxpY2F0aW9uc0FyZWFEaXJlY3RvcmF0 ZTwvYT4gKS48YnI+DQo8YnI+DQpQbGVhc2UgcmVzb2x2ZSB0aGVzZSBjb21tZW50cyBhbG9uZyB3 aXRoIGFueSBvdGhlciBMYXN0IENhbGwgY29tbWVudHMgPGJyPg0KeW91IG1heSByZWNlaXZlLiBQ bGVhc2Ugd2FpdCBmb3IgZGlyZWN0aW9uIGZyb20geW91ciBkb2N1bWVudCBzaGVwaGVyZCA8YnI+ DQpvciBBRCBiZWZvcmUgcG9zdGluZyBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBkcmFmdC48YnI+DQo8 YnI+DQpEb2N1bWVudDogZHJhZnQtaWV0Zi1wa2l4LWVzdC0wNzxicj4NClRpdGxlOiBFbnJvbGxt ZW50IG92ZXIgU2VjdXJlIFRyYW5zcG9ydDxicj4NClJldmlld2VyOiBUb2JpYXMgR29uZHJvbTxi cj4NClJldmlldyBEYXRlOiAyNS42LjIwMTM8YnI+DQo8YnI+DQpTdW1tYXJ5OiBUaGUgZHJhZnQg bG9va3MgZmluZS4gPGJyPg0KSXQgaXMgaGVhZGluZyBmb3IgU1REIHRyYWNrIGFuZCBtb3N0bHkg ZGVzY3JpYmVzIFNpbXBsZSBQS0kgb3ZlciBUTFMgKGFuZCB1c2luZyB0aGUgcHJvdGVjdGVkIGNo YW5uZWwgbWVjaGFuaXNtcyBmb3IgbXV0dWFsIGF1dGhlbnRpY2F0aW9uIGFzIHdlbGwgKGJleW9u ZCBzaW1wbGUgY29uZmlkZW50aWFsaXR5KSkuDQo8YnI+DQo8YnI+DQpjb21tZW50czogPGJyPg0K PGJyPg0KPGJyPg0KMS4gc2VjdGlvbiAyLjIuMiBhbmQgMi4yLjM8YnI+DQooIGNsaWVudCB2ZXJp ZmljYXRpb24uKTxicj4NCihDZXJ0aWZpY2F0ZS1sZXNzIFRMUyAoZS5nLiwgd2l0aCBhIHNoYXJl ZCBjcmVkZW50aWFsIGRpc3RyaWJ1dGVkIG91dC1vZi1iYW5kKTs8YnI+DQphbmQgSFRUUC1iYXNl ZCB3aXRoIGEgdXNlcm5hbWUvcGFzc3dvcmQgZGlzdHJpYnV0ZWQgb3V0LW9mLWJhbmQuKTxicj4N Cjxicj4NCm1ha2Ugc3VyZSB0byBhdm9pZCBpbmZvcm1hdGlvbiBsZWFrYWdlLiBFLmcuIGluIGNh c2Ugb2YgY2VydGlmaWNhdGUtbGVzcyBUTFMsIGlmIGNvb2tpZXMgYXJlIHVzZWQsIG1ha2Ugc3Vy ZSB0aGF0IGFyZSBub3QgdHJhbnNtaXR0ZWQgb3ZlciB0aGUgbm9ybWFsIHVucHJvdGVjdGVkIEhU VFAgYmFuZC4NCjxicj4NCihzZWN0aW9uIDMuMi4zIGFscmVhZHkgc3BlY2lmaWVzIHRoYXQgJnF1 b3Q7SFRUUCBCYXNpYyBhbmQgRGlnZXN0IGF1dGhlbnRpY2F0aW9uIE1VU1Qgb25seSBiZSBwZXJm b3JtZWQgb3ZlciBUTFMgMS4xIFtSRkM0MzQ2XSBvciBsYXRlciB2ZXJzaW9ucy4mcXVvdDsgd2hp Y2ggaXMgZ29vZC4pPGJyPg0KPC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGlzIHN0YXRlbWVudCBpbiAzLjIuMyByZS1lbmZvcmNl cyB0aGUgc3RhdGVtZW50IGluIFNlY3Rpb24gMy4zIHRoYXQgJnF1b3Q7SFRUUFMgTVVTVCBiZSB1 c2VkLiAmbmJzcDtUTFMgMS4xIFtSRkM0MzQ2XSAob3IgYSBsYXRlciB2ZXJzaW9uKSBNVVNUIGJl Jm5ic3A7dXNlZC4mcXVvdDs8L2Rpdj4NCjxkaXY+QXJndWFibHkgdGhlc2Ugc3RhdGVtZW50cyBj b3VsZCBiZSBjb25kZW5zZWQgaW50byAyMTE5IGFzc2VydGlvbiAoYWx0aG91Z2ggd2UgaGF2ZSBu b3QgZG9uZSB0aGlzKS4mbmJzcDs8L2Rpdj4NCjxicj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi Pg0KPGRpdiB0ZXh0PSIjMDAwMDAwIiBiZ2NvbG9yPSIjRkZGRkZGIj4NCjxkaXYgY2xhc3M9Im1v ei10ZXh0LWh0bWwiIGxhbmc9IngtdW5pY29kZSI+PGZvbnQgZmFjZT0iQXJpYWwiPjIuIHNlY3Rp b24gMy4yLjQ6IDxicj4NCndoZW4gcmVnaXN0ZXJpbmcmbmJzcDsgJnF1b3Q7YXBwbGljYXRpb24v Y3NyYXR0cnMmcXVvdDsgd2l0aCBJQU5BIGluIHNlY3Rpb24gNjxicj4NCkkgc2VlIHlvdSBoYXZl IG5vIE1hZ2ljIG51bWJlciBvciBmaWxlIGV4dGVuc2lvbi4gPGJyPg0KSXMgdGhlcmUgYSBjaGFu Y2UgdGhhdCB0aGlzIHJlcXVlc3QgbWlnaHQgYXQgc29tZSBwb2ludCBiZSBtYWRlIHdpdGhvdXQg ZGlyZWN0IEhUVFAgYW5kIG1pZ2h0IHdhbnQgc29tZSBvZiB0aGUgdHdvPw0KPGJyPg0KPC9mb250 PjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5B IGZpbGUgZXh0ZW5zaW9uICgmcXVvdDsuY3NyYXR0cnMmcXVvdDspIGhhcyBiZWVuIGFkZGVkLiZu YnNwOzwvZGl2Pg0KPGJyPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2IHRleHQ9IiMw MDAwMDAiIGJnY29sb3I9IiNGRkZGRkYiPg0KPGRpdiBjbGFzcz0ibW96LXRleHQtaHRtbCIgbGFu Zz0ieC11bmljb2RlIj48Zm9udCBmYWNlPSJBcmlhbCI+My4gc2VjdGlvbiAzLjIuMjogPGJyPg0K YXMgeW91IHdhbnQgdG8gb2ZmZXIgdG8gdXNlIEhUVFAgUE9TVCBhbmQgR0VULiA8YnI+DQpJIGFt IG5vdCBzbyBoYXBweSBhYm91dCB0aGUgSFRUUCBHRVQgcGFydHMuIEhvdyBkbyB5b3UgY29uc2lk ZXIgdGhlIHJpc2sgb2YgaW5mb3JtYXRpb24gbGVha2FnZSB3aXRoIEhUVFAgR0VUIHdoZW4geW91 IGhhdmUgZS5nLiBsYWJlbHM/DQo8YnI+DQplLmcuIGluIGNhc2Ugb2YmbmJzcDsmbmJzcDsmbmJz cDsgJnF1b3Q7Mi4mbmJzcDsgPGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBjbGFzcz0ibW96LXR4 dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJodHRwczovL3d3dy5leGFtcGxlLmNvbS8ud2VsbC1rbm93 bi9lc3QvYXJiaXRyYXJ5TGFiZWwxL2NhY2VydHMiPg0KaHR0cHM6Ly93d3cuZXhhbXBsZS5jb20v LndlbGwta25vd24vZXN0L2FyYml0cmFyeUxhYmVsMS9jYWNlcnRzPC9hPiZxdW90Ozxicj4NCjwv Zm9udD48L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxk aXY+SW5mcmFzdHJ1Y3R1cmVzIHRoYXQgd2lzaCB0byBrZWVwIHRoZWlyIHB1YmxpYyBjZXJ0aWZp Y2F0ZSBpbmZyYXN0cnVjdHVyZSBkZXRhaWxzIHByaXZhdGUgY2FuIGVuZm9yY2UgY2xpZW50IGF1 dGhlbnRpY2F0aW9uIGR1cmluZyBHRVQgb3BlcmF0aW9ucyBhcyBzcGVjaWZpZWQgaW4gczQuMS4y ICgmcXVvdDs8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxZW07ICI+RVNUIHNlcnZlciBTSE9VTEQg Tk9UIHJlcXVpcmUgY2xpZW50IGF1dGhlbnRpY2F0aW9uJnF1b3Q7KS48L3NwYW4+PC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJyPg0KSG0uIE5vdCBzdXJlLiBUaGlzIGRv ZXMgcG90ZW50aWFsbHkgbm90IGZ1bGZpbGwgYWxsIHNlY3VyaXR5IG5lZWRzOiBiZWNhdXNlIGV2 ZW4gaWYgeW91IHVzZSBhdXRoZW50aWNhdGlvbiwgeW91IHdpbGwgc3RpbGwgbGVhayB0aGUgaW5m b3JtYXRpb24gaW4gdGhlIEdFVCBVUkwgdG8gZXZlcnlvbmUgaW4geW91ciBIVFRQL1RDUCBwYXRo LiBJcyB0aGlzIGEgcHJvYmxlbT8NCjxicj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48 YnI+DQo8L2Rpdj4NCjxkaXY+QmVjYXVzZSBUTFMgaXMgbWFuZGF0ZWQgYW55IGF0dGFja2VyIG9u IHBhdGggd2lsbCBvbmx5IGhhdmUgYWNjZXNzIHRvIHRoZSBlbmNyeXB0ZWQgZGF0YS4mbmJzcDs8 L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pi0gbWF4PC9kaXY+DQo8ZGl2Pjxicj4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2IHRleHQ9IiMwMDAwMDAiIGJnY29s b3I9IiNGRkZGRkYiPg0KPGJsb2NrcXVvdGUgY2l0ZT0ibWlkOjUzRUE0NzUyOEQ2QUNGNDQ4NkFB MTUyRjkyQzJCNjk4RUQ2MTdCQHhtYi1yY2QteDAzLmNpc2NvLmNvbSIgdHlwZT0iY2l0ZSI+DQo8 ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdiB0ZXh0PSIjMDAwMDAw IiBiZ2NvbG9yPSIjRkZGRkZGIj4NCjxkaXYgY2xhc3M9Im1vei10ZXh0LWh0bWwiIGxhbmc9Ingt dW5pY29kZSI+PGZvbnQgZmFjZT0iQXJpYWwiPlNlY29uZCB5b3UgbWF5IGNvbnNpZGVyIHRvIG5v dGUgVVJJIGxlbmd0aCBsaW1pdGF0aW9ucyBpbiBHRVQgcmVxdWVzdHMuJm5ic3A7DQo8YnI+DQo8 L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8 ZGl2PlJlamVjdDogVGhlcmUgaXMgcGxlbnR5IGFib3V0IFVSSS9IVFRQL2V0YyB0aGF0IHdlIGFy ZSBub3Qgbm90aW5nPC9kaXY+DQo8YnI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXYg dGV4dD0iIzAwMDAwMCIgYmdjb2xvcj0iI0ZGRkZGRiI+DQo8ZGl2IGNsYXNzPSJtb3otdGV4dC1o dG1sIiBsYW5nPSJ4LXVuaWNvZGUiPjxmb250IGZhY2U9IkFyaWFsIj5uaXRzOiA8YnI+DQpwYWdl IDMyPGJyPg0Kcy90byB1c2UgdGhlIHRoZSBzZWNwMzg0cjEgZWxsaXB0aWMgY3VydmUvdG8gdXNl IHRoZSBzZWNwMzg0cjEgZWxsaXB0aWMgY3VydmU8YnI+DQo8L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PmZpeGVkLjwvZGl2Pg0KPGJy Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2IHRleHQ9IiMwMDAwMDAiIGJnY29sb3I9 IiNGRkZGRkYiPg0KPGRpdiBjbGFzcz0ibW96LXRleHQtaHRtbCIgbGFuZz0ieC11bmljb2RlIj48 Zm9udCBmYWNlPSJBcmlhbCI+PGJyPg0KPGJyPg0KT2ggYW5kIHlvdSBzaG91bGQgY2xlYW4gdXAg aWRuaXRzOiA8YnI+DQombmJzcDsqKiBEb3ducmVmOiBOb3JtYXRpdmUgcmVmZXJlbmNlIHRvIGFu IEluZm9ybWF0aW9uYWwgUkZDOiBSRkMgMjk4Njxicj4NCiZuYnNwOyAqKiBPYnNvbGV0ZSBub3Jt YXRpdmUgcmVmZXJlbmNlOiBSRkMgNDM0NiAoT2Jzb2xldGVkIGJ5IFJGQyA1MjQ2KTxicj4NCjwv Zm9udD48L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxk aXY+QXMgcHJldmlvdXNseSBub3RlZCBvbiB0aHJlYWQgdGhlc2UgYXJlIGFjY2VwdGFibGUuPC9k aXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4tIG1heDwvZGl2Pg0KPGJyPg0KPGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSI+DQo8ZGl2IHRleHQ9IiMwMDAwMDAiIGJnY29sb3I9IiNGRkZGRkYiPg0K PGRpdiBjbGFzcz0ibW96LXRleHQtaHRtbCIgbGFuZz0ieC11bmljb2RlIj48Zm9udCBmYWNlPSJB cmlhbCI+PGJyPg0KPC9mb250Pjxmb250IGZhY2U9IkFyaWFsIj48YnI+DQpCZXN0IHJlZ2FyZHMs IFRvYmlhczxicj4NCjxicj4NCjxicj4NCjwvZm9udD48L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8YnI+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxicj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnI+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_53EA47528D6ACF4486AA152F92C2B698EDB916xmbrcdx03ciscocom_-- From ray.vanbrandenburg@tno.nl Tue Jul 16 02:43:17 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5985111E828E; Tue, 16 Jul 2013 02:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.662 X-Spam-Level: *** X-Spam-Status: No, score=3.662 tagged_above=-999 required=5 tests=[AWL=-3.809, BAYES_00=-2.599, FRT_STOCK1=3.988, FRT_STOCK2=3.988, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2On0aWw6-5h4; Tue, 16 Jul 2013 02:43:12 -0700 (PDT) Received: from fromintoutb.tno.nl (fromintoutb.tno.nl [134.221.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id 4785B11E8275; Tue, 16 Jul 2013 02:43:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,676,1367964000"; d="scan'208";a="1888694" Received: from unknown (HELO mail.tno.nl) ([134.221.225.220]) by mailhost1b.tno.nl with ESMTP; 16 Jul 2013 11:43:02 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.44]) by EXC-CASHUB01.tsn.tno.nl ([134.221.225.220]) with mapi id 14.03.0123.003; Tue, 16 Jul 2013 11:43:02 +0200 From: "Brandenburg, R. (Ray) van" To: Martin Thomson , "Roni Even (ron.even.tlv@gmail.com)" Thread-Topic: AppsDir review of draft-ietf-avtcore-idms-09 Thread-Index: AQHOfAHwdb7/Fb3SG0qoStr4WOE+S5ldaxsAgAJs+wCABzrsEA== Date: Tue, 16 Jul 2013 09:43:02 +0000 Message-ID: References: <7F110B3ECC623C4EADDEB82154F2693D12871300@EXC-MBX01.tsn.tno.nl> In-Reply-To: Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.153] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 X-Mailman-Approved-At: Tue, 16 Jul 2013 10:38:27 -0700 Cc: The IESG , IETF Apps Discuss , "draft-ietf-avtcore-idms.all@tools.ietf.org" Subject: Re: [apps-discuss] AppsDir review of draft-ietf-avtcore-idms-09 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 16 Jul 2013 09:43:17 -0000 SGkgTWFydGluLA0KDQpUaGFua3MgZm9yIHRoZSB0aG9yb3VnaCByZXZpZXcuIFBsZWFzZSBzZWUg bXkgY29tbWVudHMgaW5saW5lLiANCg0KQmVzdCByZWdhcmRzLA0KDQpSYXkNCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE1hcnRpbiBUaG9tc29uIFttYWlsdG86bWFydGluLnRo b21zb25AZ21haWwuY29tXSANClNlbnQ6IGRvbmRlcmRhZyAxMSBqdWxpIDIwMTMgMjI6NTQNClRv OiBTdG9ra2luZywgSC5NLiAoSGFucykNCkNjOiBkcmFmdC1pZXRmLWF2dGNvcmUtaWRtcy5hbGxA dG9vbHMuaWV0Zi5vcmc7IElFVEYgQXBwcyBEaXNjdXNzOyBUaGUgSUVTRw0KU3ViamVjdDogUmU6 IEFwcHNEaXIgcmV2aWV3IG9mIGRyYWZ0LWlldGYtYXZ0Y29yZS1pZG1zLTA5DQoNClRoYW5rcy4N Cg0KSSBuZWdsZWN0ZWQgdG8gc2VuZCB0aGlzIHRvIGEgZmV3IG90aGVyIGZvbGtzIGluaXRpYWxs eS4NCg0KT24gMTAgSnVseSAyMDEzIDAwOjUxLCBTdG9ra2luZywgSC5NLiAoSGFucykgPGhhbnMu c3Rva2tpbmdAdG5vLm5sPiB3cm90ZToNCj4gRGVhciBNYXJ0aW4sDQo+DQo+IFJheSBpcyBvdXQt b2Ytb2ZmaWNlIGF0IHRoZSBtb21lbnQsIEknbGwgZGlzY3VzcyB5b3VyIGNvbW1lbnRzIHdpdGgg aGltIHdoZW4gaGUgZ2V0cyBiYWNrIG5leHQgd2Vlay4gV2UnbGwgbGV0IHlvdSBrbm93IGhvdyB3 ZSBleHBlY3QgdG8gZGVhbCB3aXRoIHlvdXIgY29tbWVudHMgdGhlbi4NCj4NCj4gQmVzdCByZWdh cmRzLCBIYW5zDQo+DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IE1hcnRp biBUaG9tc29uIFttYWlsdG86bWFydGluLnRob21zb25AZ21haWwuY29tXQ0KPiBTZW50OiBtYWFu ZGFnIDgganVsaSAyMDEzIDE5OjM4DQo+IFRvOiBkcmFmdC1pZXRmLWF2dGNvcmUtaWRtcy5hbGxA dG9vbHMuaWV0Zi5vcmcNCj4gU3ViamVjdDogQXBwc0RpciByZXZpZXcgb2YgZHJhZnQtaWV0Zi1h dnRjb3JlLWlkbXMtMDkNCj4NCj4gSSBoYXZlIGJlZW4gc2VsZWN0ZWQgYXMgdGhlIEFwcGxpY2F0 aW9ucyBBcmVhIERpcmVjdG9yYXRlIChhcHBzZGlyKSByZXZpZXdlciBmb3IgdGhpcyBkcmFmdC4g IChGb3IgYmFja2dyb3VuZCBvbiBhcHBzZGlyLCBwbGVhc2Ugc2VlIGh0dHA6Ly90cmFjLnRvb2xz LmlldGYub3JnL2FyZWEvYXBwL3RyYWMvd2lraS9BcHBsaWNhdGlvbnNBcmVhRGlyZWN0b3JhdGUp Lg0KPg0KPiBQbGVhc2UgcmVzb2x2ZSB0aGVzZSBjb21tZW50cyBhbG9uZyB3aXRoIGFueSBvdGhl ciBMYXN0IENhbGwgY29tbWVudHMgeW91IG1heSByZWNlaXZlLiAgUGxlYXNlIHdhaXQgZm9yIGRp cmVjdGlvbiBmcm9tIHlvdXIgZG9jdW1lbnQgc2hlcGhlcmQgb3IgQUQgYmVmb3JlIHBvc3Rpbmcg YSBuZXcgdmVyc2lvbiBvZiB0aGUgZHJhZnQuDQo+DQo+DQo+IERvY3VtZW50OiBkcmFmdC1pZXRm LWF2dGNvcmUtaWRtcy0wOQ0KPiBSZXZpZXdlcjogTWFydGluIFRob21zb24NCj4gUmV2aWV3IERh dGU6IDIwMTMtMDctMDgNCj4gSUVURiBMYXN0IENhbGwgRGF0ZTogPw0KPiBJRVNHIFRlbGVjaGF0 IERhdGU6ID8NCj4NCj4gU3VtbWFyeTogVGhpcyBkb2N1bWVudCBpcyBhbG1vc3QgcmVhZHkgZm9y IHB1YmxpY2F0aW9uIGFzIHByb3Bvc2VkIHN0YW5kYXJkLiAgVGhlcmUgYXJlIGEgZmV3IG1pbm9y IGlzc3Vlcy4NCj4NCj4NCj4gU2VjdGlvbiA2Lg0KPiBJcyB0aGVyZSBhIHN0cm9uZyByZWFzb24g Zm9yIHRoZSBNU0FTIHRvIGJlIHBsYWNlZCBhdCB0aGUgUlRQIHNlbmRlcj8NCj4gQmFzZWQgb24g dGhlIGRlc2NyaXB0aW9uIHByb3ZpZGVkLCB0aGlzIGZ1bmN0aW9uIGNhbiBiZSBpbmRlcGVuZGVu dCwgd2l0aCB0aGUgZXhjZXB0aW9uIHRoYXQgaXQgYmUgbmVjZXNzYXJ5IHRvIHJlY2VpdmUgUlRD UCByZXBvcnRzLiAgVGhlIGRlc2NyaXB0aW9uIGluIDYuMSBvbWl0cyB0aGUgaW5mb3JtYXRpb24g dGhhdCB3b3VsZCBiZSBuZWNlc3NhcnkgdG8gY29uY2x1ZGUgdGhhdCBpdCBpcyBpbiB0aGUgcmln aHQgcGxhY2UgKGkuZS4sIGl0IHJlY2VpdmVzIFJUQ1AgSURNUyBYUiByZXBvcnRzLCBhbmQgc2Vu ZHMgUlRDUCBJRE1TIG1lc3NhZ2VzLikNCg0KWWVzLCB5b3UncmUgcmlnaHQsIGFuIE1TQVMgY291 bGQgYmUgaW5kZXBlbmRlbnQgZnJvbSB0aGUgUlRQIFNlbmRlciBhcyBsb25nIGFzIGl0IHJlY2Vp dmVzIHRoZSBuZWNlc3NhcnkgUlRDUCByZXBvcnRzIGFuZCB0aGUgUlRQIHN0cmVhbSBpdHNlbGYg dG8gY29ycmVsYXRlIHJlcG9ydHMgZnJvbSBkaWZmZXJlbnQgcmVjZWl2ZXJzLiBJdCBjb3VsZCBl dmVuIGJlIGxvY2F0ZWQgaW4gb25lIG9mIHRoZSBSVFAgUmVjZWl2ZXJzIChhcyBub3RlZCBpbiBz ZWN0aW9uIDYpLiBJIHdpbGwgYWRkIGEgZmV3IHNlbnRlbmNlcyB0byA2LjEgdG8gY2xhcmlmeSB0 aGlzLiANCg0KPiBUaGVyZSBpcyBhbHNvIGEgdGhpcmQgcG90ZW50aWFsIHJvbGUgaW4gdGhpcyBz Y2VuYXJpbywgd2hpY2ggaXMgcHJvYmFibHkgYWxzbyBhc3N1bWVkIGJ5IGFuIGFjdHVhbCBSVFAg c2VuZGVyLiAgSW4gYSBuZXR3b3JrIHdpdGggbGFyZ2UgZGlzcGFyaXR5IG9mIG5ldHdvcmsgZGVs YXlzIGFuZCBwbGF5YmFjayBvY2N1cnJpbmcgb24gZGV2aWNlcyB3aXRoIGxpbWl0ZWQgY2FwYWNp dHksIGlzIGl0IG5vdCBhbHNvIHBvc3NpYmxlIC0gb3IgZXZlbiBuZWNlc3NhcnkgLSBmb3IgYW4g UlRQIHNlbmRlciB0byBwZXJmb3JtIHNvbWUgYnVmZmVyaW5nIHRvIGFkZCBkZWxheT8NCg0KWW91 J3JlIHJpZ2h0IHRoYXQgdGhlIGN1cnJlbnQgc3lzdGVtIGFzc3VtZXMgUlRQIHJlY2VpdmVycyBo YXZlIGxhcmdlIGVub3VnaCBidWZmZXJzIHRvIGRlbGF5IHRoZSByZWNlaXZlZCBzdHJlYW1zLiBJ biB0aGVvcnkgaXQgd291bGQgYmUgcG9zc2libGUgdG8gaGF2ZSB0aGUgUlRQIHNlbmRlciBhZGQg ZGVsYXkgYXMgd2VsbCwgYWx0aG91Z2ggdGhpcyB3b3VsZCBhZGQgY29uc2lkZXJhYmxlIGNvbXBs ZXhpdHkgdG8gdGhlIHN5c3RlbSBhbmQgb25seSBiZSB1c2VmdWwgaW4gYSBsaW1pdGVkIHNldCBv ZiBzY2VuYXJpb3MuIEZvciBleGFtcGxlLCBzdWNoIGEgc3lzdGVtIHdpbGwgbm90IHdvcmsgd2Vs bCBpbiBtdWx0aWNhc3QgZW52aXJvbm1lbnRzLiBJbiBhZGRpdGlvbiwgaGF2aW5nIHRvIGNvb3Jk aW5hdGUgYnVmZmVyIGRlbGF5cyBiZXR3ZWVuIG11bHRpcGxlIHBhcnRpZXMgaXMgdmVyeSBjb21w bGV4LiANCg0KPiBTZWN0aW9uIDcgcmU6IFN5bmNocm9uaXphdGlvbiBQYWNrZXQgU2VuZGVyIFR5 cGUgLg0KPg0KPiBJJ20gbm90IGZpbmRpbmcgYW55IG1vdGl2YXRpb24gZm9yIHRoZSBpbmNsdXNp b24gb2YgdGhpcyBmaWVsZCBhbmQgSSBjYW4ndCBpbmZlciBmcm9tIHRoZSB0ZXh0IHdoYXQgaXRz IHB1cnBvc2UgaXMuICBJIHRoaW5rIHRoYXQgdGhlIGRvY3VtZW50IG5lZWRzIHNvbWV0aGluZyBo ZXJlLiAgSSBub3RpY2UgdGhhdCByZW1vdmluZyBpdCB3b3VsZCBhbGxvdyB5b3UgdG8gcmVtb3Zl IDMyLWJpdHMgZnJvbSB0aGUgcGF5bG9hZC4NCg0KVGhlcmUgYXJlIHR3byBtb3RpdmF0aW9ucyBi ZWhpbmQgdGhlIFNQU1QgZmllbGQuIEZpcnN0bHksIGl0IGFsbG93cyBmb3IgZXh0ZW5zaW9ucyB0 byB0aGUgSURNUyBtZWNoYW5pc20gd2l0aG91dCBoYXZpbmcgdG8gc3BlY2lmeSBuZXcgWFIgYmxv Y2tzLiBTZWNvbmRseSwgaXQgYWxsb3dzIGZvciBjb21wYXRpYmlsaXR5IHdpdGggdGhlIEVUU0kg VElTUEFOIHNwZWMgKHNlZSBzZWN0aW9uIDIuMiBvZiB0aGUgLTExIHZlcnNpb24gb2YgdGhlIGRy YWZ0KS4gDQoNCj4gU2VjdGlvbiA3IHJlOiBQYWNrZXQgUHJlc2VudGVkIE5UUCB0aW1lc3RhbXA6 IDMyIGJpdHMuDQo+DQo+IFRoZSBkZXNjcmlwdGlvbiBvZiB0aGlzIHBhcmFtZXRlciByZXF1aXJl cyBzcGVjaWFsIGhhbmRsaW5nIHdpdGggcmVzcGVjdCB0byBlcG9jaCBhbmQgcm9sbG92ZXIuICBJ IG1pZ2h0IGFzc3VtZSB0aGF0IGl0IGlzIHdpdGhpbiAyXjE2IHNlY29uZHMgb2YgdGhlIHJlY2Vp dmVkIHRpbWVzdGFtcCwgYnV0IGFsd2F5cyBncmVhdGVyLg0KPg0KPiBUaGVyZSBhcmUgb3RoZXIg d2F5cyB0byBlbmNvZGUgdGhpcyBpbmZvcm1hdGlvbiwgdGhvdWdoLiAgU2luY2UgdGhpcyBpcyBh bHdheXMgc3RyaWN0bHkgYWZ0ZXIgYSBwYWNrZXQgaXMgcmVjZWl2ZWQsIHRoZW4gZW5jb2Rpbmcg YSBkZWx0YSBtaWdodCBhbHNvIGJlIHBvc3NpYmxlLiAgVGhhdCB3b3VsZCBzZXQgdGhlIGVwb2No IGZvciB0aGlzIGZpZWxkIHRvIHRoZSBwYWNrZXQgcmVjZWl2ZWQgTlRQIHRpbWVzdGFtcCBhbmQg YXZvaWQgYW55IHJvbGxvdmVyIGlzc3VlcyAodGhvdWdoIGl0IHdvdWxkIGxpbWl0IHRoZSBhbW91 bnQgb2YgYnVmZmVyaW5nIGRlbGF5IHRvIDJeMTYpLg0KDQpJbiB0aGUgV0cgd2UgaGF2ZSBoYWQg c29tZSBkaXNjdXNzaW9uIHdoZXRoZXIgd2Ugc2hvdWxkIGhhdmUgYSAzMi1iaXQgb3IgNjQtYml0 IE5UUCB0aW1lc3RhbXAgaGVyZS4gSW4gdGhlIGVuZCwgY29uc2Vuc3VzIHdhcyB0aGF0IGEgMzIt Yml0IHRpbWVzdGFtcCB3b3VsZCBiZSBzdWZmaWNpZW50IGZvciB0aGUgWFIgUmVwb3J0LCB3aGls ZSB3ZSBpbmNsdWRlZCBhIDY0LWJpdCB0aW1lc3RhbXAgaW4gdGhlIFJUQ1AgU2V0dGluZ3MgcGFj a2V0LiBZb3UncmUgcmlnaHQgdGhhdCB3ZSdyZSBhc3N1bWluZyB0aGUgZGVsYXkgdG8gYmUgd2l0 aGluIDJeMTYgc2Vjb25kcy4gSSB3aWxsIGFkZCBhIG5vdGUgdG8gdGhlIHRleHQgdG8gbWFrZSB0 aGlzIGV4cGxpY2l0LiANCg0KPiBTZWN0aW9uIDExLg0KPiBUaGlzIEFCTkYgaW1wbGllcyB0aGF0 IHRoZSAnYScgaW4gJ2E9cnRjcC1pZG1zJyBpcyBjYXNlLWluc2Vuc2l0aXZlLg0KPiBUaGlzIGlz IG5vdCBwZXJtaXR0ZWQgYnkgUkZDIDQ1NjYuDQoNCkknbSBub3QgYW4gQUJORiBleHBlcnQsIGFy ZSB5b3UgcHJvcG9zaW5nIHRvIGNoYW5nZSB0aGUgJ2EnIGludG8gJWQ5Nz8gSSd2ZSBicm93c2Vk IHRocm91Z2ggdmFyaW91cyByZWNlbnQgTU1VU0lDIGFuZCBBVlRDT1JFIGRvY3VtZW50cywgYW5k IHRoZXkgYWxsIHNlZW0gdG8gdXNlIHRoZSAnYScgbm90YXRpb24uIA0KDQo+IE5vdGUgdGhhdCB5 b3Ugc2hvdWxkIGFsc28gc3BlY2lmeSAnZGVjaW1hbCcgcmF0aGVyIHRoYW4gJ251bWVyaWNhbCcg aW4gdGhlIGRlc2NyaXB0aW9uLCBhc3N1bWluZyBvZiBjb3Vyc2UgdGhhdCB5b3Ugd2FudCBkZWNp bWFsIG51bWJlcnMuDQoNCkkgYXNzdW1lIHlvdSBtZWFuIHRoZSBsaW5lICdTeW5jR3JvdXBJZCA9 IDEqMTBESUdJVCA7IE51bWVyaWNhbCB2YWx1ZSBmcm9tIDAgdGhyb3VnaCA0Mjk0OTY3Mjk0Jz8g SSB3aWxsIGNoYW5nZSB0aGlzIGlzIHRoZSBuZXh0IGl0ZXJhdGlvbi4gDQoNClRoYW5rcyBhZ2Fp biwNCg0KUmF5DQoNCg0KVGhpcyBlLW1haWwgYW5kIGl0cyBjb250ZW50cyBhcmUgc3ViamVjdCB0 byB0aGUgRElTQ0xBSU1FUiBhdCBodHRwOi8vd3d3LnRuby5ubC9lbWFpbGRpc2NsYWltZXIK From martin.thomson@gmail.com Tue Jul 16 12:05:01 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EEBD11E80F8; Tue, 16 Jul 2013 12:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.909 X-Spam-Level: ** X-Spam-Status: No, score=2.909 tagged_above=-999 required=5 tests=[AWL=-5.067, BAYES_50=0.001, FRT_STOCK1=3.988, FRT_STOCK2=3.988, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-0ipSVMahez; Tue, 16 Jul 2013 12:05:00 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id BC28621F9A05; Tue, 16 Jul 2013 12:04:59 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id hj3so1075141wib.12 for ; Tue, 16 Jul 2013 12:04:58 -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:content-transfer-encoding; bh=hjbU4qH1n9QtMn4KLued0O705dGbjfzaaUKJZWlurxs=; b=FHe5lG/vGNAXx8eYIm54xyktz1Bi9tw7hAf3Y3YgBO6/W7coY6Aj2Maj2oWiBHsT65 Hf4L+SbchzFOlwgkv+2kZILHMSb5z98iBOEOe4NieedahNSqKq5meG2I9s9z03o9PAFZ IfL2wws8oTFKlwc3Tn6yEQu0XnrYwENV+FCK4ozH+Hc+lk27dvexgQIyKm30H+MoVNpa m0Zduo7ZovgJea0yNeFT7301iHwsQPBN1N4DV142LqNDzpmhnbHWlf4y1tK2EDFR70fA EzO57T8sSfe3USh0lCgP/SPAfr0Y+BDWBstvNrbuIiL6k3nqatwKJ8w+1PUlylCYry63 ZNEQ== MIME-Version: 1.0 X-Received: by 10.194.110.6 with SMTP id hw6mr2389967wjb.3.1374001498796; Tue, 16 Jul 2013 12:04:58 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Tue, 16 Jul 2013 12:04:58 -0700 (PDT) In-Reply-To: References: <7F110B3ECC623C4EADDEB82154F2693D12871300@EXC-MBX01.tsn.tno.nl> Date: Tue, 16 Jul 2013 12:04:58 -0700 Message-ID: From: Martin Thomson To: "Brandenburg, R. (Ray) van" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "Roni Even \(ron.even.tlv@gmail.com\)" , The IESG , IETF Apps Discuss , "draft-ietf-avtcore-idms.all@tools.ietf.org" Subject: Re: [apps-discuss] AppsDir review of draft-ietf-avtcore-idms-09 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 16 Jul 2013 19:05:01 -0000 Thanks Ray, It looks like you got most of what I was concerned about. I will await a -12 revision. On 16 July 2013 02:43, Brandenburg, R. (Ray) van wrote: > Hi Martin, > > Thanks for the thorough review. Please see my comments inline. > > Best regards, > > Ray > > -----Original Message----- > From: Martin Thomson [mailto:martin.thomson@gmail.com] > Sent: donderdag 11 juli 2013 22:54 > To: Stokking, H.M. (Hans) > Cc: draft-ietf-avtcore-idms.all@tools.ietf.org; IETF Apps Discuss; The IE= SG > Subject: Re: AppsDir review of draft-ietf-avtcore-idms-09 > > Thanks. > > I neglected to send this to a few other folks initially. > > On 10 July 2013 00:51, Stokking, H.M. (Hans) wrote= : >> Dear Martin, >> >> Ray is out-of-office at the moment, I'll discuss your comments with him = when he gets back next week. We'll let you know how we expect to deal with = your comments then. >> >> Best regards, Hans >> >> -----Original Message----- >> From: Martin Thomson [mailto:martin.thomson@gmail.com] >> Sent: maandag 8 juli 2013 19:38 >> To: draft-ietf-avtcore-idms.all@tools.ietf.org >> Subject: AppsDir review of draft-ietf-avtcore-idms-09 >> >> I have been selected as the Applications Area Directorate (appsdir) revi= ewer for this draft. (For background on appsdir, please see http://trac.to= ols.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). >> >> Please resolve these comments along with any other Last Call comments yo= u may receive. Please wait for direction from your document shepherd or AD= before posting a new version of the draft. >> >> >> Document: draft-ietf-avtcore-idms-09 >> Reviewer: Martin Thomson >> Review Date: 2013-07-08 >> IETF Last Call Date: ? >> IESG Telechat Date: ? >> >> Summary: This document is almost ready for publication as proposed stand= ard. There are a few minor issues. >> >> >> Section 6. >> Is there a strong reason for the MSAS to be placed at the RTP sender? >> Based on the description provided, this function can be independent, wit= h the exception that it be necessary to receive RTCP reports. The descript= ion in 6.1 omits the information that would be necessary to conclude that i= t is in the right place (i.e., it receives RTCP IDMS XR reports, and sends = RTCP IDMS messages.) > > Yes, you're right, an MSAS could be independent from the RTP Sender as lo= ng as it receives the necessary RTCP reports and the RTP stream itself to c= orrelate reports from different receivers. It could even be located in one = of the RTP Receivers (as noted in section 6). I will add a few sentences to= 6.1 to clarify this. > >> There is also a third potential role in this scenario, which is probably= also assumed by an actual RTP sender. In a network with large disparity o= f network delays and playback occurring on devices with limited capacity, i= s it not also possible - or even necessary - for an RTP sender to perform s= ome buffering to add delay? > > You're right that the current system assumes RTP receivers have large eno= ugh buffers to delay the received streams. In theory it would be possible t= o have the RTP sender add delay as well, although this would add considerab= le complexity to the system and only be useful in a limited set of scenario= s. For example, such a system will not work well in multicast environments.= In addition, having to coordinate buffer delays between multiple parties i= s very complex. > >> Section 7 re: Synchronization Packet Sender Type . >> >> I'm not finding any motivation for the inclusion of this field and I can= 't infer from the text what its purpose is. I think that the document need= s something here. I notice that removing it would allow you to remove 32-b= its from the payload. > > There are two motivations behind the SPST field. Firstly, it allows for e= xtensions to the IDMS mechanism without having to specify new XR blocks. Se= condly, it allows for compatibility with the ETSI TISPAN spec (see section = 2.2 of the -11 version of the draft). > >> Section 7 re: Packet Presented NTP timestamp: 32 bits. >> >> The description of this parameter requires special handling with respect= to epoch and rollover. I might assume that it is within 2^16 seconds of t= he received timestamp, but always greater. >> >> There are other ways to encode this information, though. Since this is = always strictly after a packet is received, then encoding a delta might als= o be possible. That would set the epoch for this field to the packet recei= ved NTP timestamp and avoid any rollover issues (though it would limit the = amount of buffering delay to 2^16). > > In the WG we have had some discussion whether we should have a 32-bit or = 64-bit NTP timestamp here. In the end, consensus was that a 32-bit timestam= p would be sufficient for the XR Report, while we included a 64-bit timesta= mp in the RTCP Settings packet. You're right that we're assuming the delay = to be within 2^16 seconds. I will add a note to the text to make this expli= cit. > >> Section 11. >> This ABNF implies that the 'a' in 'a=3Drtcp-idms' is case-insensitive. >> This is not permitted by RFC 4566. > > I'm not an ABNF expert, are you proposing to change the 'a' into %d97? I'= ve browsed through various recent MMUSIC and AVTCORE documents, and they al= l seem to use the 'a' notation. > >> Note that you should also specify 'decimal' rather than 'numerical' in t= he description, assuming of course that you want decimal numbers. > > I assume you mean the line 'SyncGroupId =3D 1*10DIGIT ; Numerical value f= rom 0 through 4294967294'? I will change this is the next iteration. > > Thanks again, > > Ray > > > This e-mail and its contents are subject to the DISCLAIMER at http://www.= tno.nl/emaildisclaimer From barryleiba@gmail.com Wed Jul 17 10:20:56 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C007921F9C72 for ; Wed, 17 Jul 2013 10:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ksx5aTHwQjfC for ; Wed, 17 Jul 2013 10:20:56 -0700 (PDT) Received: from mail-qa0-x22d.google.com (mail-qa0-x22d.google.com [IPv6:2607:f8b0:400d:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 3127821F9B07 for ; Wed, 17 Jul 2013 10:20:56 -0700 (PDT) Received: by mail-qa0-f45.google.com with SMTP id ci6so3090421qab.18 for ; Wed, 17 Jul 2013 10:20:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=AEUsn6X8InJVzvr+xdlzlEY1yi/REwUR5z1pPXJJVQI=; b=xkzDIx1bxzrOPZtPGoLSeuk0ADV0IqF06Ga8gq2PWWd7OXDrKPeYfTXH+aqonv5YKN mK2hnP3WITBZjilUVPJz2ulbO86PBB+t5veh24hZJ4QFq1nnDOaXmYQxF9E4B28QvxLK z1r9g7Ws2jmItDfDsFKz95TR5f/rOHrIR1M7SRG82cK+Vz6SqK4nxlM2me5IReRhWJNK Qn3Hp9z2WJpYvvk5z1ikYoWqQoUBkUyLSSzgAuIl3FmJC/HflHKlA3vS7GMtui2IKnZl U5XLQM2DdNppGLFf1XTFBK9nXYzlnbAwignNTaMivenISWeTzVYdEAgQPFnIIj8gJKix gFZA== MIME-Version: 1.0 X-Received: by 10.49.35.34 with SMTP id e2mr8816581qej.67.1374081655610; Wed, 17 Jul 2013 10:20:55 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.224.116.202 with HTTP; Wed, 17 Jul 2013 10:20:55 -0700 (PDT) Date: Wed, 17 Jul 2013 13:20:55 -0400 X-Google-Sender-Auth: 5ISt2K3-EuGPlrxclkMrUBnIV50 Message-ID: From: Applications Area Directors To: Apps Discuss Content-Type: text/plain; charset=ISO-8859-1 Subject: [apps-discuss] Comments solicited on the desired expertise for ADs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 17 Jul 2013 17:20:57 -0000 Applications Area denizens, The IESG is in the process of updating the list of desired expertise for ADs, which it sends to the NomCom each year. The App ADs have updated the information for the Applications Area, and we'd like you folks to review and comment. The overall list is anchored here: http://trac.tools.ietf.org/group/iesg/trac/wiki/DesiredExpertise Specifically, we're asking for review of the generic expertise desired for all ADs: http://trac.tools.ietf.org/group/iesg/trac/wiki/GenericExpertise ...and for the desired expertise for Applications ADs: http://trac.tools.ietf.org/group/iesg/trac/wiki/AppsExpertise Please send us comments right away, as the IESG will soon have to send a final set to the NomCom. You may comment on this list, . If you prefer, you may also send comments to Pete and Barry at , or to the IESG as a whole at (use this if you have comments on the generic list). Thanks, Barry and Pete, Applications ADs From masinter@adobe.com Wed Jul 17 11:06:02 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF6DA21E804C for ; Wed, 17 Jul 2013 11:06:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BXIiXc905Mau for ; Wed, 17 Jul 2013 11:05:58 -0700 (PDT) Received: from exprod6og103.obsmtp.com (exprod6og103.obsmtp.com [64.18.1.185]) by ietfa.amsl.com (Postfix) with ESMTP id F16B021F9EF5 for ; Wed, 17 Jul 2013 11:05:55 -0700 (PDT) Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by exprod6ob103.postini.com ([64.18.5.12]) with SMTP ID DSNKUebdAqwwjt9eQq16wPAMiRyJvOTHjw2R@postini.com; Wed, 17 Jul 2013 11:05:56 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r6HI2RD8024479; Wed, 17 Jul 2013 11:02:28 -0700 (PDT) Received: from nacas03.corp.adobe.com (nacas03.corp.adobe.com [10.8.189.121]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r6HI2K6S026644; Wed, 17 Jul 2013 11:05:51 -0700 (PDT) Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nacas03.corp.adobe.com ([10.8.189.121]) with mapi; Wed, 17 Jul 2013 11:02:30 -0700 From: Larry Masinter To: Ian Hickson , "apps-discuss@ietf.org" Date: Wed, 17 Jul 2013 11:02:28 -0700 Thread-Topic: [apps-discuss] RFC 2388 (multipart/form-data) Thread-Index: Ac6BXOpg43jx2QFKQbeGOVxuGZDg9wBuk5cg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [apps-discuss] RFC 2388 (multipart/form-data) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 17 Jul 2013 18:06:03 -0000 If there is anyone interested in working on updating RFC 2388 and related specs, please let me know. I'm not convinced that RFC 2388 leaves more undefined than it should, although there's clearly been some confusion about what it said and certainly implementations now vary enough that RFC 2388 is not a good implementation guide for any of the roles (form creator, filled-form to form-data constructor, form-data parser and interpreter). See comments=20 https://www.w3.org/Bugs/Public/show_bug.cgi?id=3D16909#c8 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] > On Behalf Of Ian Hickson > Sent: Friday, July 12, 2013 10:40 AM > To: apps-discuss@ietf.org > Subject: [apps-discuss] RFC 2388 (multipart/form-data) >=20 >=20 > Hi, >=20 > Do you know if there is anyone working on fixing RFC2388? People keep > asking me to update the HTML spec to just define it all inline rather tha= n > deferring to the RFC since the RFC leaves a lot of stuff underdefined, bu= t > I don't have the bandwidth to spec all that myself at this point. >=20 > e.g.: > https://www.w3.org/Bugs/Public/show_bug.cgi?id=3D16909 > https://www.w3.org/Bugs/Public/show_bug.cgi?id=3D19879 >=20 > Other feedback: > http://lists.w3.org/Archives/Public/public-whatwg- > archive/2012Oct/0204.html > http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jul/0037= .html > http://lists.w3.org/Archives/Public/public-whatwg- > archive/2012May/0003.html >=20 > I asked Larry Masinter if he was still maintaining the RFC, but he said h= e > wasn't, and suggested I ask here to find out who was maintaining it now. >=20 > Thanks in advance, > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From masinter@adobe.com Wed Jul 17 11:06:52 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECA9F21E804B for ; Wed, 17 Jul 2013 11:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hzb4Q5-Whbio for ; Wed, 17 Jul 2013 11:06:47 -0700 (PDT) Received: from exprod6og126.obsmtp.com (exprod6og126.obsmtp.com [64.18.1.77]) by ietfa.amsl.com (Postfix) with ESMTP id 56A1521F9E4D for ; Wed, 17 Jul 2013 11:06:47 -0700 (PDT) Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob126.postini.com ([64.18.5.12]) with SMTP ID DSNKUebdMbzqZOwny2MCp4ZnmojXyhIZRFEd@postini.com; Wed, 17 Jul 2013 11:06:47 PDT Received: from inner-relay-1.corp.adobe.com (inner-relay-1.sea.adobe.com [153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r6HI6dAI007544; Wed, 17 Jul 2013 11:06:39 -0700 (PDT) Received: from nahub02.corp.adobe.com (nahub02.corp.adobe.com [10.8.189.98]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r6HI326h026676; Wed, 17 Jul 2013 11:06:38 -0700 (PDT) Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nahub02.corp.adobe.com ([10.8.189.98]) with mapi; Wed, 17 Jul 2013 11:04:44 -0700 From: Larry Masinter To: Graham Klyne , Peter Saint-Andre Date: Wed, 17 Jul 2013 11:04:43 -0700 Thread-Topic: [apps-discuss] I-D Action: draft-ietf-appsawg-acct-uri-05.txt Thread-Index: Ac53wlnWBWmx841ZT1Wqt9zJQd9sqALVYJoA Message-ID: References: <20130617205341.15641.96770.idtracker@ietfa.amsl.com> <51BF786B.9060703@stpeter.im> <016d01ce767f$2ea45990$8bed0cb0$@lanthaler@gmx.net> <51D1C423.5000804@stpeter.im> <017801ce7686$afc9db60$0f5d9220$@lanthaler@gmx.net> <51D1D417.5040705@stpeter.im> <51D30A19.90202@ninebynine.org> In-Reply-To: <51D30A19.90202@ninebynine.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-acct-uri-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 18:06:53 -0000 I'd like to finally move duri / tdb to RFC. I think the last imponderable question was whether it should be "Informational" or "Experimental". And I'd need an AD sponsor. > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] > On Behalf Of Graham Klyne > Sent: Tuesday, July 02, 2013 10:13 AM > To: Peter Saint-Andre > Cc: apps-discuss@ietf.org > Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-acct-uri-05.tx= t >=20 > There's also Larry Masinter's old proposal for dated URIs: > http://tools.ietf.org/id/draft-masinter-dated-uri-08.html (now expired). >=20 > #g > -- >=20 > On 01/07/2013 20:10, Peter Saint-Andre wrote: > > On 7/1/13 12:13 PM, Markus Lanthaler wrote: > >> On Monday, July 01, 2013 8:02 PM, Peter Saint-Andre wrote: > >>> On 7/1/13 11:19 AM, Markus Lanthaler wrote: > >>>> I'm wondering whether it would make sense to add a feature allowing > >>>> associate a date to an account. This would address problems arising > >>> from > >>>> account recycling (think Yahoo). Maybe something like > >>>> > >>>> acct:bob@example.com?date=3D20130701 > >>>> > >>>> I think at the very least this should be covered in the security > >>>> considerations. > >>> > >>> IMHO we're beyond the point of adding new features to the 'acct' URI > >>> scheme (it has completed Working Group Last Call, IETF Last Call, and > >>> IESG review -- currently I'm working to address one issue about i18n > >>> that arose during IESG review, so that the document can be approved f= or > >>> publication). > >> > >> Sorry for bringing it up so late in the process. > > > > No worries. It happens. :-) > > > >>> However, a date could be included in an API or protocol that enables > >>> applications to use 'acct' URIs. Is there a reason why this would nee= d > >>> to be included in the URI itself? > >> > >> Sure.. but I think the date should actually be a (perhaps optional) pa= rt of > >> the identifier, i.e., the acct URI. That would also make it easier to > >> exchange it between various applications and protocols. > > > > Are you arguing that it would be easier or *safer*? > > > > Also, it seems that your argument would apply to URIs in general (e.g., > > HTTP URIs for web pages) and not just 'acct' URIs. However, we seem to > > have ways to deal with stale/old HTTP URIs and the like. Thus I wonder > > what in your mind is special about 'acct' URIs in this respect. > > > > Peter > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From superuser@gmail.com Wed Jul 17 11:11:15 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F3FC21E8093 for ; Wed, 17 Jul 2013 11:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WIb0-U3AKijK for ; Wed, 17 Jul 2013 11:11:14 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 2D0E521F9371 for ; Wed, 17 Jul 2013 11:11:11 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id k10so5768418wiv.7 for ; Wed, 17 Jul 2013 11:11:10 -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=fovBOVbgWTGs/ZjCTyTV51OVL839xVWC0NEkDCmH+V0=; b=RGVcLPf5CUlIhu3pdTkcUAdoJHxcCy49PXb/D7YC8NTEI+i1upC1QZN7sj5WqAqdIY 4uTj5zBEWydYaQdlkddHD0SImfiRgy/MmWeNFaKilJV8hyxhazWzqEVuud0O5kmlKpbh aC8thNecIjZ3alPR9e2CzHsIsfQtB/AhYm75Jr5WifJ4t0XAs674LTa9gd1po22IRycZ nygDcSjohmNRH8C4KFhSuK3hTDZC3dI7SwnAcgZ51ki8f5Mzr7aMh/sXfap4Avxjj3UF QP94Qh3/fkriFdTGOTUuhH9dAoW+dffA4GWxkMeJmpqlj5SryAbd1jdUT6ASZ4JMFWeh cDRw== MIME-Version: 1.0 X-Received: by 10.180.187.209 with SMTP id fu17mr5483794wic.52.1374084670308; Wed, 17 Jul 2013 11:11:10 -0700 (PDT) Received: by 10.180.90.16 with HTTP; Wed, 17 Jul 2013 11:11:10 -0700 (PDT) Date: Wed, 17 Jul 2013 11:11:10 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=001a11c269acaa49b204e1b904ca Subject: [apps-discuss] Preliminary IETF 87 APPSAWG/APPAREA agenda posted X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 17 Jul 2013 18:11:15 -0000 --001a11c269acaa49b204e1b904ca Content-Type: text/plain; charset=ISO-8859-1 https://datatracker.ietf.org/meeting/87/agenda/appsawg/ Please submit any requests for changes as soon as possible. Revisions are due on 7/22 (Monday). -MSK, APPSAWG co-chair --001a11c269acaa49b204e1b904ca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Please submit any requests for changes as soon as possibl= e.=A0 Revisions are due on 7/22 (Monday).

-MSK, APPSAWG co-chair

--001a11c269acaa49b204e1b904ca-- From superuser@gmail.com Wed Jul 17 11:31:40 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F5A921F9CAD for ; Wed, 17 Jul 2013 11:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.372 X-Spam-Level: X-Spam-Status: No, score=-1.372 tagged_above=-999 required=5 tests=[AWL=-1.228, BAYES_00=-2.599, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Obbg23ecJZWN for ; Wed, 17 Jul 2013 11:31:40 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id C399321F9AB3 for ; Wed, 17 Jul 2013 11:31:39 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id z11so5031108wgg.1 for ; Wed, 17 Jul 2013 11:31:38 -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=M1cUeLasxqP98i5lgFdcvYJe8N84g2dnHA5l0qdeKcg=; b=yXt27MkuLD9T2vldf1Qf042lWnsLE7ZzeLQfMC87QqNXqN8q+QZf5B2vZX0rkSkh5c 94mZHEP4QRonGEXN4PJlU7lrrLKFwOQC6RLIW/GuNuwwlV2qa+Q71chncM5ha1iMYIdy ymZzpZqn3WslXWBqtCfG3dTWhzFB5iQJrHoH6rSxWqn8STDq6oi07A8yWJ1Mz4gpo3Vr k9aywvgZgfUECWRqxoRIG1aHO497IpH/tSwsIt5dj6YsudOoEi6J187tz4lDfUsJ8/JM 3oWrfpTcLfeW+KhW2blpmX2E5+MhMnnkzX0w1THvjtFvYNWHSgV64cJWnc3xruMCsSCf bkdA== MIME-Version: 1.0 X-Received: by 10.194.239.225 with SMTP id vv1mr5875501wjc.63.1374085898887; Wed, 17 Jul 2013 11:31:38 -0700 (PDT) Received: by 10.180.90.16 with HTTP; Wed, 17 Jul 2013 11:31:38 -0700 (PDT) In-Reply-To: References: <20130617205341.15641.96770.idtracker@ietfa.amsl.com> <51BF786B.9060703@stpeter.im> <51D1C423.5000804@stpeter.im> <51D1D417.5040705@stpeter.im> <51D30A19.90202@ninebynine.org> Date: Wed, 17 Jul 2013 11:31:38 -0700 Message-ID: From: "Murray S. Kucherawy" To: Larry Masinter Content-Type: multipart/alternative; boundary=089e01493384e4e7db04e1b94de3 Cc: Graham Klyne , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-acct-uri-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 18:31:40 -0000 --089e01493384e4e7db04e1b94de3 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 17, 2013 at 11:04 AM, Larry Masinter wrote: > I'd like to finally move duri / tdb to RFC. I think the last imponderable > question was whether it should be "Informational" or "Experimental". > And I'd need an AD sponsor. > > ...or adoption by a WG, if there's one that could take it within charter, and has enough participant support to put the work into it. Ahem. -MSK --089e01493384e4e7db04e1b94de3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jul 17, 2013 at 11:04 AM, Larry Masinter <masint= er@adobe.com> wrote:
I'd like to finally move duri / tdb to R= FC. =A0I think the last imponderable
question was whether it should be "Informational" or "Experi= mental".
And I'd need an AD sponsor.


...= or adoption by a WG, if there's one that could take it within charter, = and has enough participant support to put the work into it.

Ahem.
-MSK

--089e01493384e4e7db04e1b94de3-- From jasnell@gmail.com Wed Jul 17 11:38:32 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7014B21F9A1E for ; Wed, 17 Jul 2013 11:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.372 X-Spam-Level: X-Spam-Status: No, score=-1.372 tagged_above=-999 required=5 tests=[AWL=-1.227, BAYES_00=-2.599, FRT_ADOBE2=2.455, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e8D+6khfIzq3 for ; Wed, 17 Jul 2013 11:38:31 -0700 (PDT) Received: from mail-oa0-x233.google.com (mail-oa0-x233.google.com [IPv6:2607:f8b0:4003:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id D71C221F9A16 for ; Wed, 17 Jul 2013 11:38:30 -0700 (PDT) Received: by mail-oa0-f51.google.com with SMTP id i4so3032995oah.10 for ; Wed, 17 Jul 2013 11:38: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=ysWFJuCXvZcN9IPcc46QqJpUq8/qajaog1SCltv+Kmo=; b=rhfS5ljqSpAoOMHFEnWJyEIeKtzbjHugU5CsDfs5BRjaT+wSa8q1ggxXPDO2zQmDgD MGnSrRhSD2ZmEKCVS2xr3TaPhWaK7QhsdtpmIUy548f17X00Tfey+mKYAMwfoQedI61A 7lnp223hVkUabUX4kLfXXlGdCtEBuaMJKbQ9pwD+auWuQfpenyJ+udOtg06gymSScb+T VjHBqJqR4WPJnSCPgFP48AyA2RrIJEHvjAEF30DQTTUgf4m9K2huzBRQVQo4SvRWc/Fb eDpBzulp0GDh9d3wnjwchEwjsMk+mgXhDIeYlh84HoRHYMmxN9dghL3KMy2zkwVHCHun 1QSQ== X-Received: by 10.60.42.101 with SMTP id n5mr9672974oel.4.1374086310441; Wed, 17 Jul 2013 11:38:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.55.8 with HTTP; Wed, 17 Jul 2013 11:38:10 -0700 (PDT) In-Reply-To: References: From: James M Snell Date: Wed, 17 Jul 2013 11:38:10 -0700 Message-ID: To: Larry Masinter Content-Type: text/plain; charset=UTF-8 Cc: Ian Hickson , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] RFC 2388 (multipart/form-data) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 17 Jul 2013 18:38:32 -0000 Updating or refining RFC2388 is currently not on my agenda, however, once HTTP/2 progresses a bit further down the road and matures I do intend to explore using that binary framing model as a possible replacement for multipart mime packaging and multipart form. I suspect that work won't likely begin until next year, however. On Wed, Jul 17, 2013 at 11:02 AM, Larry Masinter wrote: > If there is anyone interested in working on updating RFC 2388 and related > specs, please let me know. > > I'm not convinced that RFC 2388 leaves more undefined than > it should, although there's clearly been some confusion about > what it said and certainly implementations now vary enough > that RFC 2388 is not a good implementation guide for any of > the roles (form creator, filled-form to form-data constructor, > form-data parser and interpreter). > > See comments > https://www.w3.org/Bugs/Public/show_bug.cgi?id=16909#c8 > > >> -----Original Message----- >> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] >> On Behalf Of Ian Hickson >> Sent: Friday, July 12, 2013 10:40 AM >> To: apps-discuss@ietf.org >> Subject: [apps-discuss] RFC 2388 (multipart/form-data) >> >> >> Hi, >> >> Do you know if there is anyone working on fixing RFC2388? People keep >> asking me to update the HTML spec to just define it all inline rather than >> deferring to the RFC since the RFC leaves a lot of stuff underdefined, but >> I don't have the bandwidth to spec all that myself at this point. >> >> e.g.: >> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16909 >> https://www.w3.org/Bugs/Public/show_bug.cgi?id=19879 >> >> Other feedback: >> http://lists.w3.org/Archives/Public/public-whatwg- >> archive/2012Oct/0204.html >> http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jul/0037.html >> http://lists.w3.org/Archives/Public/public-whatwg- >> archive/2012May/0003.html >> >> I asked Larry Masinter if he was still maintaining the RFC, but he said he >> wasn't, and suggested I ask here to find out who was maintaining it now. >> >> Thanks in advance, >> -- >> Ian Hickson U+1047E )\._.,--....,'``. fL >> http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. >> Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' >> _______________________________________________ >> 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 johnl@iecc.com Wed Jul 17 12:17:25 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D089921E804C for ; Wed, 17 Jul 2013 12:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.805 X-Spam-Level: X-Spam-Status: No, score=-110.805 tagged_above=-999 required=5 tests=[AWL=0.393, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WtEoPw2jwtU1 for ; Wed, 17 Jul 2013 12:17:21 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 67E4611E80CC for ; Wed, 17 Jul 2013 12:17:21 -0700 (PDT) Received: (qmail 68084 invoked from network); 17 Jul 2013 19:17:20 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 17 Jul 2013 19:17:20 -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=51e6edc0.xn--i8sz2z.k1307; i=johnl@user.iecc.com; bh=V6DHKdj1Zu6RDvCiGlAk8vuqUCmaaJHeSgidMdNC7qo=; b=qLC8rjKjke38FxUjLP1PVLmCOgMd6wYYLtsfFFD8A2rM0IW++Skz3YjHTneVj9qAbpBFsXHFfo3Yys9tx89oUql7xE2sDqrv0oLNCwsjGAndtBTb97mfOR6aXRkGFQIDDHyBM0sOaTnZsUYgUQbRcV0Whm5aBvkRkaFRguYFel05sHMlBBRJmYFLhA4ihE4vzbXQQJyhAjCYAXqlhkNDcQN8PGAY1det0fJie7z5Xb8sqSXRUIaYhvX/ehl6YBNo 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=51e6edc0.xn--i8sz2z.k1307; olt=johnl@user.iecc.com; bh=V6DHKdj1Zu6RDvCiGlAk8vuqUCmaaJHeSgidMdNC7qo=; b=pLkril5yQhcExFr3JBFArRfFpihqeQw+fBFD7NIDmuuKowaB42VDL50mUtU0MmHy8SqCj/++0Gz7HL/0m5b4n/rDJQeX4kZJjjn7XnGSGvFHbXkmOpVmHOR3/VTXReJQzhxzJ18mhu/kSPBkSa/zU+OMcU5z0HCHPSZr64oMT5rW6DbqPAHAo0+tde2rExda/KhV8i9Q7P8rjfnR1hGozCTya3dLBRmfBDY7dwR/YcuxOJrFNk4gfpuKPIVji4eI Date: 17 Jul 2013 19:16:58 -0000 Message-ID: <20130717191658.66141.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 Subject: Re: [apps-discuss] RFC 2388 (multipart/form-data) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 17 Jul 2013 19:17:25 -0000 >> If there is anyone interested in working on updating RFC 2388 and related >> specs, please let me know. >Updating or refining RFC2388 is currently not on my agenda, however, >once HTTP/2 progresses a bit further down the road and matures I do >intend to explore using that binary framing model as a possible >replacement for multipart mime packaging and multipart form. ... Inevitably, multipart/form-data will be with us for at least a decade after any improved replacement is defined. It's definitely worth updating the RFC to match existing practice, and to document where existing practice is inconsistent. Having written my share of CGI scripts that extracted files from multipart/form-data with more or less success, I'm willing to provide some help. R's, John From kurta@drkurt.com Wed Jul 17 18:18:22 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80E5B21F9AD6 for ; Wed, 17 Jul 2013 18:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-axRLj2wB3Z for ; Wed, 17 Jul 2013 18:18:21 -0700 (PDT) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id B20CD21F9ABB for ; Wed, 17 Jul 2013 18:18:14 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id t59so2336763wes.6 for ; Wed, 17 Jul 2013 18:18:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=aGV4ok7ckBUV1IMXV/twChRFFqyuiVUOt73lMTgzN0E=; b=NvWo95Enz6LdJCE6gRbQqjJyotBd1pEmOEaJ0lV9N6nkXf4d4F9vH2aGSset65ACKk b49b1ULA2v9oxgPywcqKU0k5E2PWsGxzrjnHJXHJ2GiJ2ok608Dy/E/jUlIArBSipl2C J8gvBGM3fq67HcryPt8PqvdgFNDih+V1J+Vms= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type:x-gm-message-state; bh=aGV4ok7ckBUV1IMXV/twChRFFqyuiVUOt73lMTgzN0E=; b=fCZQgUie5EoXejeSXYfFs+WXbtznHswzSXHRs3eCQR+dIgOBftiyvJJ2bM0YYqpcUW /NEHiLynGc6PPCYXX3tU0cC5eVNl0orHLA6u5brywPAEa/PNA9bjJSKZz6O39oImKQLa eaP78PacGbmG0NOZTjCOJ3tzkZIVmA2kisruVp3mIM3L6k2LzZCmpZxy5iZUh1t5aiBK CtMXBpyqwsN0eTBEihCxrW/hTIr/2ABf83++VxCNx3VchiVg2Y5UPjJga1wQO6u4R5vD gmu0cLv9JKrwFRfreld3aHI4QMCfb85KsGY0xptkRmFUeKecLZBeulvMG0V3rLdmM2hq ECkA== MIME-Version: 1.0 X-Received: by 10.194.173.71 with SMTP id bi7mr6810783wjc.2.1374110293391; Wed, 17 Jul 2013 18:18:13 -0700 (PDT) Sender: kurta@drkurt.com Received: by 10.194.90.104 with HTTP; Wed, 17 Jul 2013 18:18:13 -0700 (PDT) Date: Wed, 17 Jul 2013 18:18:13 -0700 X-Google-Sender-Auth: 8j5Vtr9evkO4Oc6KVPpOkysFzdA Message-ID: From: Kurt Andersen To: apps-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlUK+h6ahMvGWlf9gxW9G2rEsWjveAsPb9JO8TENH+12AL9F+ee54CEhPaBI24QIsBdYcGL Subject: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 01:18:22 -0000 After reviewing draft-wmills-rrvs-header-field-00, it looks like a very promising step to support the security of potentially re-assigned email addresses. I would like to see it employed not only for large mailbox providers, but also by enterprises where employee churn can easily lead to address re-use. I have two technical comments/suggestions regarding the proposal: 1) Be explicit regarding the RFC3463 extended response code which should be used when rejecting a message due to an out-of-date attribution. By my reading, the code should be 5.1.6 with whatever additional explanation the receiver chooses to supply; 2) Use epoch seconds in the rrvs header instead of the archaic RFC822 and successors date-time field. The use of epoch seconds for machine-processed email headers has already been established in the case of RFC6376 (DKIM Signatures), section 3.5 for the 't' and 'x' fields. This will be much easier for parsing and smaller. The widespread support for this header would help deal with a number of situations that today can put otherwise innocent senders on blacklists. Nothing is a panacea and senders who attempt to abuse this system would have to be appropriately blocked, just as directory harvest attacks need to be dealt with today. Cheers, Kurt Andersen From superuser@gmail.com Wed Jul 17 23:17:29 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E1FF11E80D5 for ; Wed, 17 Jul 2013 23:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GHB-NFVKrjvu for ; Wed, 17 Jul 2013 23:17:27 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 45D9111E80AE for ; Wed, 17 Jul 2013 23:17:27 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id a12so2588004wgh.16 for ; Wed, 17 Jul 2013 23:17:26 -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=mEBiGh2iHVZyKlt50MceQrl3/IsJuxSel5POT4gvUoc=; b=Fq84oaTwPC28UBrwb96NANfzTD1ofFpKEdSsU93OYwQUYFYNkV3es7wLGquLyyVwgG FhsgM9vrzCGz6cdeug353BJkqXr1tpHBR/FoNFKXDA9SEGYF7idOC35iooYkeGI7o72k 6j1I2JvwVZiDX1x22GR/oqA6RFWkKNHbcFxGbO7cJSHAO8/cKv1iZd8QfxMh/VyiyA1M RSu2mkVYok6cV1NZaeZvTAFI7hjJBaQufpyrQyUjXqb6rR/3iavo0TFv4AnnVuB3nGyw fNjAISM9NuU2N7zOcASp0aQi4Sq6z026Hxk/IXEvmtOXqSdB8PUvM4KB4W94MfLvUKAD y51A== MIME-Version: 1.0 X-Received: by 10.194.239.225 with SMTP id vv1mr7335421wjc.63.1374128246443; Wed, 17 Jul 2013 23:17:26 -0700 (PDT) Received: by 10.180.90.16 with HTTP; Wed, 17 Jul 2013 23:17:26 -0700 (PDT) In-Reply-To: References: Date: Wed, 17 Jul 2013 23:17:26 -0700 Message-ID: From: "Murray S. Kucherawy" To: Kurt Andersen Content-Type: multipart/alternative; boundary=089e0149338401558e04e1c32a15 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 06:17:29 -0000 --089e0149338401558e04e1c32a15 Content-Type: text/plain; charset=ISO-8859-1 Hi Kurt, thanks for your comments. Replies inline: On Wed, Jul 17, 2013 at 6:18 PM, Kurt Andersen wrote: > 1) Be explicit regarding the RFC3463 extended response code which > should be used when rejecting a message due to an out-of-date > attribution. By my reading, the code should be 5.1.6 with whatever > additional explanation the receiver chooses to supply; > This has come up before, most recently in the SPFbis working group. I'll go along with consensus, but for the record, I've never been a fan of doing this. RFC3463 says quite clearly which codes are to be used for what situations; it seems unnecessary to me to call out the specific code when the document defining those codes already spells it out. 2) Use epoch seconds in the rrvs header instead of the archaic RFC822 > and successors date-time field. The use of epoch seconds for > machine-processed email headers has already been established in the > case of RFC6376 (DKIM Signatures), section 3.5 for the 't' and 'x' > fields. This will be much easier for parsing and smaller. > My co-author and I talked about that prior to posting the first draft. We're aware of other standard expressions like UNIX epoch time and RFC3339. We decided on sticking with email format for now because things parsing this content already know how to do that (at least for Date, and possibly for scraping details from Received), and it seemed simpler to have a single timestamp format in a message. There's no guarantee that a DKIM signature will be present on the message, introducing the second format. Having stated all of that, I'm not especially married to that choice, so as above I'll go with consensus. I don't recall my co-author being particularly passionate about it either, but I'll let him speak for himself. -MSK --089e0149338401558e04e1c32a15 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Kurt, thanks for your comments.=A0 Replies inline:
<= div>
On Wed, Jul 17, 2013 at 6:18 PM, Kurt Andersen &l= t;kboth@drkurt.com> wrote:
1) Be explicit regarding the RFC3463 extended response code which=
should be used when rejecting a message due to an out-of-date
attribution. By my reading, the code should be 5.1.6 with whatever
additional explanation the receiver chooses to supply;

This has come up before, most recently in the SPFbis workin= g group.=A0 I'll go along with consensus, but for the record, I've = never been a fan of doing this.=A0 RFC3463 says quite clearly which codes a= re to be used for what situations; it seems unnecessary to me to call out t= he specific code when the document defining those codes already spells it o= ut.

2) Use epoch seconds in the rrvs header instead of the archaic RFC822
and successors date-time field. The use of epoch seconds for
machine-processed email headers has already been established in the
case of RFC6376 (DKIM Signatures), section 3.5 for the 't' and '= ;x'
fields. This will be much easier for parsing and smaller.
<= div>
My co-author and I talked about that prior to posting th= e first draft.=A0 We're aware of other standard expressions like UNIX e= poch time and RFC3339.=A0 We decided on sticking with email format for now = because things parsing this content already know how to do that (at least f= or Date, and possibly for scraping details from Received), and it seemed si= mpler to have a single timestamp format in a message.=A0 There's no gua= rantee that a DKIM signature will be present on the message, introducing th= e second format.=A0 Having stated all of that, I'm not especially marri= ed to that choice, so as above I'll go with consensus.=A0 I don't r= ecall my co-author being particularly passionate about it either, but I'= ;ll let him speak for himself.

-MSK
--089e0149338401558e04e1c32a15-- From wmills@yahoo-inc.com Wed Jul 17 23:47:34 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD1A21E8090 for ; Wed, 17 Jul 2013 23:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.598 X-Spam-Level: X-Spam-Status: No, score=-18.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0I687dFUo0c for ; Wed, 17 Jul 2013 23:47:28 -0700 (PDT) Received: from mrout1.yahoo.com (mrout1.yahoo.com [216.145.54.171]) by ietfa.amsl.com (Postfix) with ESMTP id CBFEE21E8086 for ; Wed, 17 Jul 2013 23:47:28 -0700 (PDT) Received: from GQ1-EX10-CAHT04.y.corp.yahoo.com (gq1-ex10-caht04.corp.gq1.yahoo.com [10.73.118.83]) by mrout1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id r6I6k50n074540 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 17 Jul 2013 23:46:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1374129968; bh=vIlDGgQDQMKzy2H6y4l+kwcv0hAj//SrWuq2Aep1NAc=; h=References:Message-ID:Date:From:Reply-To:Subject:To:CC: In-Reply-To:MIME-Version:Content-Type; b=ujVTRmxFkQQ1SYWySxPJWdjsvC+auUf1IQZac6fn352DKIhngfObG1/gEt9sNzofa mMVO6ne57bWPneYQlewVWHWwZJt+sBtsQpQmsrTKsYMHCJOWBxJWivxhJG9i2bWJj2 4AqJNRULQu1KBaMGsuy/ZTJ57bNK32ZZIrF7NA7o= Received: from omp1006.mail.ne1.yahoo.com (98.138.87.6) by GQ1-EX10-CAHT04.y.corp.yahoo.com (10.72.228.24) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 17 Jul 2013 23:46:04 -0700 Received: (qmail 83029 invoked by uid 1000); 18 Jul 2013 06:46:04 -0000 Received: (qmail 73637 invoked by uid 60001); 18 Jul 2013 06:46:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1374129963; bh=SV8ItXtZqNptCOI9G1KCp3uNI2rD5iU5ZLSrM0uQHjo=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=uJSziIjL0P6Tkr5Z0oy70YnBVtZMlyCqgYM37wUv2x+szW/QnlKwAJoftsj5UiUxEuZBRI8J84SzB8DUdaMPSislCJF5gjApjzFyNJmnviUPP77ko/lM3YAvvksjqnFR33k2zvJKNda+QFLR7lWNUMKPpUMmiGeFcZNjSU7IiIg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=RAzMXW5x5Nj0DK2mRU4ny+rFN4ZTQ9OmYBaBjKEmki3qTtfrDGHRaAgIMNtN/vJqoJ2SFt5OvgvdQ+pinudOaf+FbC4b3XRPbK6VjyI7a3cJcq/AYLyP3OmMxbr2vrsJNkMEKF6bLbavY3C4YqASIjEyvHs8zNDKPZLqz0tZGSM= ; X-YMail-OSG: CHBOV_0VM1nEJyHyqy3kmM8JkOW6VtRwj3TTW7lVzTEPYuO fX_HNIowh5hiuKqzSaN4kD94pssJt8E.3F8a.tn0vFaT5qjRWi.nSaL8XzrR kVy.QMcsa6cKFcpcSDejXN8bCT.B2KlCkdAl414kVNKXrd76WZDOp29OZNl6 msO0vttTSTGmiU9WWOxD9D.lsosDgEUTlIhhCdrtleXt4.wNal.NtOK_2cIk m4Du5y51QJHQiUDFdVN1g1QISrIgNKIfZYpw7aQGSLwx9xdT09Ja8O9s.JgF 48rwYJTrqwhDkqdrO7tEfUbM5pOdFPS_qq1tygCa4 Received: from [99.31.212.42] by web125605.mail.ne1.yahoo.com via HTTP; Wed, 17 Jul 2013 23:46:03 PDT X-Rocket-MIMEInfo: 002.001, T24gdGltZXN0YW1wcy4uLsKgIEknbSBub3QgbWFycmllZCB0byBhbnkgcGFydGljdWxhciBvbmUuwqAgVGhlIGZvbGtzIGluIG91ciB0ZWFtIHdobyBhcmUgaW1wbGVtZW50aW5nIGhhdmUgYSBwYXJzZXIgdGhhdCBhbHJlYWR5IHB1bGxzIGluIHJmYzgyMiBmb3JtYXQgdGltZSzCoCB0aGV5IGFsc28ga25vdyBob3cgYW5kIGhhdmUgY29kZSB0byBwYXJzZSBES0lNIHRpbWVzIGFuZCBJU08gdGltZXMuCgoKSSdtIGhhcHB5IHRvIGxlYXZlIGl0IHRvIGNvbnNlbnN1cyBpZiB3ZSBjYW4gbWFrZSB0aGUgZGVjaXMBMAEBAQE- X-Mailer: YahooMailWebService/0.8.148.557 References: Message-ID: <1374129963.70969.YahooMailNeo@web125605.mail.ne1.yahoo.com> Date: Wed, 17 Jul 2013 23:46:03 -0700 From: Bill Mills To: "Murray S. Kucherawy" , Kurt Andersen In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1124617404-2092784313-1374129963=:70969" X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 129966010 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Bill Mills List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 06:47:34 -0000 ---1124617404-2092784313-1374129963=:70969 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On timestamps...=A0 I'm not married to any particular one.=A0 The folks in = our team who are implementing have a parser that already pulls in rfc822 fo= rmat time,=A0 they also know how and have code to parse DKIM times and ISO = times.=0A=0A=0AI'm happy to leave it to consensus if we can make the decisi= on fast, otherwise inertia will win because what they are planning on doing= now is the -00 spec which is rfc822 times.=A0 =0A=0A=0AI don't want to end= up with several possible formats in the same field though.=0A=0A=A0=0A-bil= l=0A=0A=0A=0A--------------------------------=0AWilliam J. Mills=0A"Paranoi= d" Yahoo!=0A=0A=0A=0A=0A________________________________=0A From: Murray S.= Kucherawy =0ATo: Kurt Andersen =0A= Cc: IETF Apps Discuss ; William Mills =0ASent: Wednesday, July 17, 2013 11:17 PM=0ASubject: Re: [apps-di= scuss] Comments on draft-wmills-rrvs-header-field-00=0A =0A=0A=0AHi Kurt, t= hanks for your comments.=A0 Replies inline:=0A=0A=0AOn Wed, Jul 17, 2013 at= 6:18 PM, Kurt Andersen wrote:=0A=0A1) Be explicit regar= ding the RFC3463 extended response code which=0A>should be used when reject= ing a message due to an out-of-date=0A>attribution. By my reading, the code= should be 5.1.6 with whatever=0A>additional explanation the receiver choos= es to supply;=0A>=0A=0AThis has come up before, most recently in the SPFbis= working group.=A0 I'll go along with consensus, but for the record, I've n= ever been a fan of doing this.=A0 RFC3463 says quite clearly which codes ar= e to be used for what situations; it seems unnecessary to me to call out th= e specific code when the document defining those codes already spells it ou= t.=0A=0A=0A2) Use epoch seconds in the rrvs header instead of the archaic R= FC822=0A>and successors date-time field. The use of epoch seconds for=0A>ma= chine-processed email headers has already been established in the=0A>case o= f RFC6376 (DKIM Signatures), section 3.5 for the 't' and 'x'=0A>fields. Thi= s will be much easier for parsing and smaller.=0A>=0A=0AMy co-author and I = talked about that prior to posting the first draft.=A0 We're aware of other= standard expressions like UNIX epoch time and RFC3339.=A0 We decided on st= icking with email format for now because things parsing this content alread= y know how to do that (at least for Date, and possibly for scraping details= from Received), and it seemed simpler to have a single timestamp format in= a message.=A0 There's no guarantee that a DKIM signature will be present o= n the message, introducing the second format.=A0 Having stated all of that,= I'm not especially married to that choice, so as above I'll go with consen= sus.=A0 I don't recall my co-author being particularly passionate about it = either, but I'll let him speak for himself.=0A=0A=0A-MSK ---1124617404-2092784313-1374129963=:70969 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
On timest= amps...  I'm not married to any particular one.  The folks in our= team who are implementing have a parser that already pulls in rfc822 forma= t time,  they also know how and have code to parse DKIM times and ISO = times.

I'm happy to le= ave it to consensus if we can make the decision fast, otherwise inertia wil= l win because what they are planning on doing now is the -00 spec which is = rfc822 times. 

I don't want to end = up with several possible formats in the same field though.
=
 
-bill


--------------------------------William J. Mills
"Paranoid" Yahoo!


= From= : Murray S. Kucherawy <superuser@gmail.com>
To: Kurt Andersen <kboth@drkurt= .com>
Cc: IETF Apps= Discuss <apps-discuss@ietf.org>; William Mills <wmills@yahoo-inc.= com>
Sent: Wednesd= ay, July 17, 2013 11:17 PM
Subjec= t: Re: [apps-discuss] Comments on draft-wmills-rrvs-header-field= -00

Hi Kurt, thanks for your comments.  Replies inline:

On Wed, Jul 17, 2013 at 6:18 PM, Kurt Andersen <= kboth@drkurt.com> wrote:
= =0A
1) Be explicit regardi= ng the RFC3463 extended response code which
=0A=0Ashould be used when re= jecting a message due to an out-of-date
=0Aattribution. By my reading, t= he code should be 5.1.6 with whatever
=0Aadditional explanation the rece= iver chooses to supply;

This has come u= p before, most recently in the SPFbis working group.  I'll go along wi= th consensus, but for the record, I've never been a fan of doing this. = ; RFC3463 says quite clearly which codes are to be used for what situations= ; it seems unnecessary to me to call out the specific code when the documen= t defining those codes already spells it out.
=0A
=0A2) Use epoch seconds in the rrvs header = instead of the archaic RFC822
=0Aand successors date-time field. The use= of epoch seconds for
=0Amachine-processed email headers has already bee= n established in the
=0Acase of RFC6376 (DKIM Signatures), section 3.5 f= or the 't' and 'x'
=0Afields. This will be much easier for parsing and s= maller.

My co-author and I talked about= that prior to posting the first draft.  We're aware of other standard= expressions like UNIX epoch time and RFC3339.  We decided on sticking= with email format for now because things parsing this content already know= how to do that (at least for Date, and possibly for scraping details from = Received), and it seemed simpler to have a single timestamp format in a mes= sage.  There's no guarantee that a DKIM signature will be present on t= he message, introducing the second format.  Having stated all of that,= I'm not especially married to that choice, so as above I'll go with consen= sus.  I don't recall my co-author being particularly passionate about = it either, but I'll let him speak for himself.
=0A
-MSK
=0A


---1124617404-2092784313-1374129963=:70969-- From Claudio.Allocchio@garr.it Thu Jul 18 01:16:50 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FFF921F9F00; Thu, 18 Jul 2013 01:16:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.541 X-Spam-Level: X-Spam-Status: No, score=-0.541 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZedRu5q9B0E2; Thu, 18 Jul 2013 01:16:46 -0700 (PDT) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [193.206.158.29]) by ietfa.amsl.com (Postfix) with ESMTP id 1973721F9FFB; Thu, 18 Jul 2013 01:16:45 -0700 (PDT) Received: internal info suppressed Date: Thu, 18 Jul 2013 10:16:43 +0200 (CEST) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.elettra.trieste.it To: draft-ietf-jcardcal-jcard.all@tools.ietf.org, apps-discuss@ietf.org Message-ID: User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=garr.it; s=cyrus; t=1374135404; bh=QSfruHM181JNM9TzE3m1ToN1Yo3y/M35m3yLqo4S+z4=; h=Date:From:To:cc:Subject; b=drRH7q4QOB9p3ZGmUgPK+UKs8LsB3zB9M+DlQccYAWFlKAQzjUCvtY3Wd50LqfHL/ QOn54HzG05vK8lYQJW9BR4x4jGVTt3NOGFGERXmz0veix/0GOvkmvP9hhz73+kw9zK IHIzqKL+jdgwDu2+ePSXvvVTNAd5F3Bb9qHBdH1M= Cc: IESG Subject: [apps-discuss] AppsDir review of draft-ietf-jcardcal-jcard-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 18 Jul 2013 08:16:50 -0000 Hello all, I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-jcardcal-jcard-05 Title: jCard: The JSON format for vCard Reviewer: Claudio Allocchio Review Date: July 17th, 2013 Summary: The document is nearly ready for publication. Only minor fixes are needed. Major issues: none Minor Issues: Conventions Used in thei document: There were many discussions in the past about using "large quotings from other documents or just 'pointing to them'. I do nderstand that in this draft the quoting is ""partial" JSON documents used for illustrative purposes." but we should be careful in this! Nits: Intoduction: there is a duplicate paragraph! The purpose of this specification is to define "jCard", a JSON format for vCard data. One main advantage to using a JSON-based format as defined in [RFC4627] over the classic vCard format is easier processing for JavaScript based widgets and libraries, especially in the scope of web-based applications. (same text in the end of first paragraph!): application. The vCard format has gone through multiple revisions, most recently vCard 4. The purpose of this specification is to define "jCard", a JSON format for vCard data. One main advantage to using a JSON-based format as defined in [RFC4627] over the classic vCard format is easier processing for JavaScript based widgets and libraries, especially in the scope of web-based applications. ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca From kurta@drkurt.com Thu Jul 18 06:44:14 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAA7321E80E7 for ; Thu, 18 Jul 2013 06:44:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kK+oJwRyoXEV for ; Thu, 18 Jul 2013 06:44:13 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 9F54011E8133 for ; Thu, 18 Jul 2013 06:44:13 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id m6so6661218wiv.2 for ; Thu, 18 Jul 2013 06:44:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=FbrrMJY8fEd9fRCBxVlG+WRgcWF4mXcL8ntZCiUyBCI=; b=cH85KxugmRdjfSfjSR+b4po+rS5YM9UbYgf/sBgmq2+f/CS9oD/e+qcNP1LHdYIexr BMxTY1A2ZKoNyElntlAikP3TQzk3LkirGCtjrn04V4I1TEmbFZH3VOTn98Azd8IdkD6K Ntz2VLurzYrB3dXO+Bis4Yvq+3qQrwvjEXwKo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=FbrrMJY8fEd9fRCBxVlG+WRgcWF4mXcL8ntZCiUyBCI=; b=MIibE1+5q2OoTkBEBUD5yIFNShA9SZNa+2YnEFeyTeJtkMXCvHrY6Xq6tYIJZ2eB12 VsCT+PKFBV94iKQ0fNlUyWoeLC6AdD23Gr1+i2hIQCMBpbNvCS467YUYSm+bw/k2H7/7 HI/HBEX8aVlU29p68OQrEKNFPZB+X54IupF2mZakZ/RbhqPevKg2CEktNrdAztDDPJz5 s+SfhVWI0T5imcfsuHhXiko/sni/TpWxw+3gFo70saFhRJz3FJTMV9/CJYWV4Wohku6D wB/vysbmIuT919c307iSx2pH4D5WK2XpOPFLhE9px+F1Gd2+tUOJ8MRBmA6HL4D0LmjI 4SGQ== MIME-Version: 1.0 X-Received: by 10.181.13.7 with SMTP id eu7mr19286352wid.54.1374155052635; Thu, 18 Jul 2013 06:44:12 -0700 (PDT) Sender: kurta@drkurt.com Received: by 10.194.90.104 with HTTP; Thu, 18 Jul 2013 06:44:12 -0700 (PDT) In-Reply-To: References: Date: Thu, 18 Jul 2013 06:44:12 -0700 X-Google-Sender-Auth: 7TN63z6hni8rJMJtUpQa7aBooe8 Message-ID: From: Kurt Andersen To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQld+sej4wxYjBKjdsahbSg2GysUIjY2nXa/ec33lkZVxc0BDVp/yqCHRYFOOssb5OmxORUR Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 13:44:14 -0000 On Wed, Jul 17, 2013 at 11:17 PM, Murray S. Kucherawy wrote: > Hi Kurt, thanks for your comments. Replies inline: > > On Wed, Jul 17, 2013 at 6:18 PM, Kurt Andersen wrote: >> >> 1) Be explicit regarding the RFC3463 extended response code which >> should be used when rejecting a message due to an out-of-date >> attribution. By my reading, the code should be 5.1.6 with whatever >> additional explanation the receiver chooses to supply; > > This has come up before, most recently in the SPFbis working group. I'll go > along with consensus, but for the record, I've never been a fan of doing > this. RFC3463 says quite clearly which codes are to be used for what > situations; it seems unnecessary to me to call out the specific code when > the document defining those codes already spells it out. I would suggest that the document should not specify the numeric code, but instead reference the "extended response code used for permanent failures attributed to 'Destination mailbox has moved, No forwarding address'". --Kurt From wmills@yahoo-inc.com Thu Jul 18 09:10:48 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 379E811E80FC for ; Thu, 18 Jul 2013 09:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.598 X-Spam-Level: X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3nEx-8ZV9oEd for ; Thu, 18 Jul 2013 09:10:43 -0700 (PDT) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by ietfa.amsl.com (Postfix) with ESMTP id B701B11E80ED for ; Thu, 18 Jul 2013 09:10:42 -0700 (PDT) Received: from BF1-EX10-CAHT10.y.corp.yahoo.com (bf1-ex10-caht10.corp.bf1.yahoo.com [10.74.209.199]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id r6IG9JrY015600 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 18 Jul 2013 09:09:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1374163760; bh=l83ikDVv7qgKaYjKDHT7fJt1qmaTrUIN7/kj/9T/Tng=; h=References:Message-ID:Date:From:Reply-To:Subject:To:CC: In-Reply-To:MIME-Version:Content-Type; b=C1J6WI/dZ+m9c7rqPdDToOEcNV1i821xQbqGnqLi96KG03+oCn8Y5pGXN0rsklBBv GSixfCcwJuCqlMPdi07ZU2tHl6QWvn65VHTU5gWHZUloi1AE0/K7XpPYdkyb18apHX LTj0aB0oXMb67S60kYsi2Aq6NQqPksL1Fp9rSMJg= Received: from omp1072.mail.ne1.yahoo.com (98.138.101.161) by BF1-EX10-CAHT10.y.corp.yahoo.com (10.74.209.170) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 18 Jul 2013 12:09:18 -0400 Received: (qmail 65557 invoked by uid 1000); 18 Jul 2013 16:09:18 -0000 Received: (qmail 64816 invoked by uid 60001); 18 Jul 2013 16:09:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1374163757; bh=ep9j4bQ67ZnFZ+d3g/O6Od5QznPNLX34QEnfFR/ppTA=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=IOEtbgkQbI+YEnV8rGaoFYy4TEDwVjoYl7dDgHp+m1JKl67D9dN7yWG0okbx9/I+4+Xdd9P10M1VroPmgG4qwqn3T1aE7TPUSJdxKQy+8p7od0jPBAxq1LEaI8n3K+eLhSlWECRT1dbWJkEoKo/HDkTAqg4TevRwTYVtdAGbTKY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=oEmXYgalC/OkYVOV5AgAC5hmWLCyJMSEsPN1/whCiyXkCLmDEB4+HLWqf7+v8WVurUsj8HbpsyZeWf+W8NwBC4vDTJc8QHqivUpxvBKxbgiMKTINnbSQw8UyyFPtTx4K4fAtmwaEpntjVO3nayOCh590WPq41P05y47uAEnj1Nw=; X-YMail-OSG: GjDWaZkVM1kAp9nhrhSj_LD9DksXBm.I7FRfmuojbu3Qh3E 8VASmnmWUqHXHsHaqo3PPfxORzUf0Z3eIpopUl6zaqL8LRKTV6ODDziXhj7X 3uJXB9N0BO7leefebDm047zr5zEmq_iztgksAf.8V8GjmX96Ax_C_BIvp_DP ojeRJjWOjY29b01pK3_zWM6i.Q.Zl4ehVOQUoqh67JcY73KMCP53p80Tgr_q 8yDnk3Cq_89PjGUowAZD_kLzGLpgYYAOY6Im7x7AxyBaNDw.tY44wccA3z1x zYEpSqZJHEWrSzXp3yJ6rTb9lvMNfGPppqw-- Received: from [209.131.62.115] by web125606.mail.ne1.yahoo.com via HTTP; Thu, 18 Jul 2013 09:09:17 PDT X-Rocket-MIMEInfo: 002.001, SSdtIE9LIHdpdGggbWFraW5nIHRoYXQgdGhlIHByaW1hcnkgdGV4dCBhcyBsb25nIGFzIHRoZSA1LjEuNiBpcyBwYXJlbnRoZXRpY2FsIGFmdGVyLCBiZWNhdXNlIGluIHRoZSBlbmQgZm9sa3Mgd2lsbCB3YW50IHRvIGtub3cuCgrCoAotYmlsbAoKCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpXaWxsaWFtIEouIE1pbGxzCiJQYXJhbm9pZCIgWWFob28hCgoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwogRnJvbTogS3VydCBBbmRlcnNlbiA8a2JvdGhAZHJrdXJ0LmNvbT4KVG8BMAEBAQE- X-Mailer: YahooMailWebService/0.8.149.560 References: Message-ID: <1374163757.58014.YahooMailNeo@web125606.mail.ne1.yahoo.com> Date: Thu, 18 Jul 2013 09:09:17 -0700 From: Bill Mills To: Kurt Andersen , "Murray S. Kucherawy" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="607277540-2098771726-1374163757=:58014" X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 163760002 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Bill Mills List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 16:10:48 -0000 --607277540-2098771726-1374163757=:58014 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'm OK with making that the primary text as long as the 5.1.6 is parentheti= cal after, because in the end folks will want to know.=0A=0A=A0=0A-bill=0A= =0A=0A=0A--------------------------------=0AWilliam J. Mills=0A"Paranoid" Y= ahoo!=0A=0A=0A=0A=0A________________________________=0A From: Kurt Andersen= =0ATo: Murray S. Kucherawy =0ACc: = IETF Apps Discuss ; William Mills =0ASent: Thursday, July 18, 2013 6:44 AM=0ASubject: Re: [apps-discuss]= Comments on draft-wmills-rrvs-header-field-00=0A =0A=0AOn Wed, Jul 17, 201= 3 at 11:17 PM, Murray S. Kucherawy=0A wrote:=0A> Hi Ku= rt, thanks for your comments.=A0 Replies inline:=0A>=0A> On Wed, Jul 17, 20= 13 at 6:18 PM, Kurt Andersen wrote:=0A>>=0A>> 1) Be expl= icit regarding the RFC3463 extended response code which=0A>> should be used= when rejecting a message due to an out-of-date=0A>> attribution. By my rea= ding, the code should be 5.1.6 with whatever=0A>> additional explanation th= e receiver chooses to supply;=0A>=0A> This has come up before, most recentl= y in the SPFbis working group.=A0 I'll go=0A> along with consensus, but for= the record, I've never been a fan of doing=0A> this.=A0 RFC3463 says quite= clearly which codes are to be used for what=0A> situations; it seems unnec= essary to me to call out the specific code when=0A> the document defining t= hose codes already spells it out.=0A=0AI would suggest that the document sh= ould not specify the numeric code,=0Abut instead reference the "extended re= sponse code used for permanent=0Afailures attributed to 'Destination mailbo= x has moved, No forwarding=0Aaddress'".=0A=0A--Kurt --607277540-2098771726-1374163757=:58014 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I'm OK with making that the primary text as long as the 5.1.6 is parenthe= tical after, because in the end folks will want to know.
 
-bill


--------------------------------
W= illiam J. Mills
"Paranoid" Yahoo!


<= font face=3D"Arial" size=3D"2"> From:<= /span> Kurt Andersen <kboth@drkurt.com>
To: Murray S. Kucherawy <superuser@gmail.com>
= Cc: IETF Apps Discuss <= apps-discuss@ietf.org>; William Mills <wmills@yahoo-inc.com>
= Sent: Thursday, July 18, 2= 013 6:44 AM
Subject: R= e: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00
=

On Wed, Jul 17, 2013 at 11:17 PM= , Murray S. Kucherawy
<superuser@gmail.com> wrote:
> = Hi Kurt, thanks for your comments.  Replies inline:
>
> On= Wed, Jul 17, 2013 at 6:18 PM, Kurt Andersen <kboth@drkurt.com> wrot= e:
>>
>> 1) Be explicit regarding the RFC3463 extended re= sponse code which
>> should be used when rejecting a message due to an o= ut-of-date
>> attribution. By my reading, the code should be 5.1.6= with whatever
>> additional explanation the receiver chooses to s= upply;
>
> This has come up before, most recently in the SPFbis= working group.  I'll go
> along with consensus, but for the rec= ord, I've never been a fan of doing
> this.  RFC3463 says quite = clearly which codes are to be used for what
> situations; it seems un= necessary to me to call out the specific code when
> the document def= ining those codes already spells it out.

I would suggest that the do= cument should not specify the numeric code,
but instead reference the "e= xtended response code used for permanent
failures attributed to 'Destina= tion mailbox has moved, No forwarding
address'".

--Kurt

--607277540-2098771726-1374163757=:58014-- From franck@peachymango.org Thu Jul 18 09:51:51 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C53AB11E80FD for ; Thu, 18 Jul 2013 09:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aa-ou3cgKO6d for ; Thu, 18 Jul 2013 09:51:38 -0700 (PDT) Received: from smtp-out-2.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id CDEF711E819A for ; Thu, 18 Jul 2013 09:51:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 64BB4390021; Thu, 18 Jul 2013 11:51:30 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp-out-2.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28143S2eaYNS; Thu, 18 Jul 2013 11:51:30 -0500 (CDT) Received: from smtp-out-2.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 3F1DB3900F1; Thu, 18 Jul 2013 11:51:30 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 2EC363900BB; Thu, 18 Jul 2013 11:51:30 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp-out-2.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 4vbJafF3ziAD; Thu, 18 Jul 2013 11:51:30 -0500 (CDT) Received: from mail-2.01.com (mail.01.com [172.18.30.178]) by smtp-out-2.01.com (Postfix) with ESMTP id 90035390021; Thu, 18 Jul 2013 11:51:29 -0500 (CDT) Date: Thu, 18 Jul 2013 11:51:27 -0500 (CDT) From: Franck Martin To: Bill Mills Message-ID: <1545202623.28471.1374166287951.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <1374163757.58014.YahooMailNeo@web125606.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_28470_1425030753.1374166287950" X-Originating-IP: [50.148.182.52] X-Mailer: Zimbra 8.0.4_GA_5737 (ZimbraWebClient - FF22 (Mac)/8.0.4_GA_5737) Thread-Topic: Comments on draft-wmills-rrvs-header-field-00 Thread-Index: t0qZJhPsJ/dfEaYWGVPnLzL11v1gKQ== Cc: Kurt Andersen , IETF Apps Discuss Subject: Re: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 16:51:51 -0000 ------=_Part_28470_1425030753.1374166287950 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit I think what Kurt is saying, is let's avoid RFC chasing. Reference the RFC for Extended code, says it is authoritative, and state that currently the code that matches is 5.1.6 In the text portion I would even be very explicit that this response is due to the presence of the rrvs header field. Let's avoid second guessing. ----- Original Message ----- From: "Bill Mills" To: "Kurt Andersen" , "Murray S. Kucherawy" Cc: "IETF Apps Discuss" Sent: Thursday, July 18, 2013 9:09:17 AM Subject: Re: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00 I'm OK with making that the primary text as long as the 5.1.6 is parenthetical after, because in the end folks will want to know. -bill -------------------------------- William J. Mills "Paranoid" Yahoo! From: Kurt Andersen To: Murray S. Kucherawy Cc: IETF Apps Discuss ; William Mills Sent: Thursday, July 18, 2013 6:44 AM Subject: Re: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00 On Wed, Jul 17, 2013 at 11:17 PM, Murray S. Kucherawy < superuser@gmail.com > wrote: > Hi Kurt, thanks for your comments. Replies inline: > > On Wed, Jul 17, 2013 at 6:18 PM, Kurt Andersen < kboth@drkurt.com > wrote: >> >> 1) Be explicit regarding the RFC3463 extended response code which >> should be used when rejecting a message due to an out-of-date >> attribution. By my reading, the code should be 5.1.6 with whatever >> additional explanation the receiver chooses to supply; > > This has come up before, most recently in the SPFbis working group. I'll go > along with consensus, but for the record, I've never been a fan of doing > this. RFC3463 says quite clearly which codes are to be used for what > situations; it seems unnecessary to me to call out the specific code when > the document defining those codes already spells it out. I would suggest that the document should not specify the numeric code, but instead reference the "extended response code used for permanent failures attributed to 'Destination mailbox has moved, No forwarding address'". ------=_Part_28470_1425030753.1374166287950 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I think what Kurt is saying, is let's avoid R= FC chasing. Reference the RFC for Extended code, says it is authoritative, = and state that currently the code that matches is 5.1.6

<= /div>
In the text portion I would even be very explicit that this respo= nse is due to the presence of the rrvs header field.

Let's avoid second guessing.

Fr= om: "Bill Mills" <wmills@yahoo-inc.com>
To: "Kurt Ander= sen" <kboth@drkurt.com>, "Murray S. Kucherawy" <superuser@gmail.co= m>
Cc: "IETF Apps Discuss" <apps-discuss@ietf.org>
Sent: Thursday, July 18, 2013 9:09:17 AM
Subject: Re: [apps-= discuss] Comments on draft-wmills-rrvs-header-field-00

I'm OK with making that= the primary text as long as the 5.1.6 is parenthetical after, because in t= he end folks will want to know.
 
-bill=


--------------------------------
William J. M= ills
"Paranoid" Yahoo!


From: Kurt Andersen <kboth@drkurt.com>
= To: Murray S. Kuch= erawy <superuser@gmail.com>
Cc: IETF Apps Discuss <= ;apps-discuss@ietf.org>; William Mills <wmills@yahoo-inc.com>
= Subject:= Re: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00

On Wed, Jul 17, 2013 at 11:17 PM= , Murray S. Kucherawy
<superuser@gmail.co= m> wrote:
> Hi Kurt, thanks for your comments.  Replies i= nline:
>
> On Wed, Jul 17, 2013 at 6:18 PM, Kurt Andersen <<= a href=3D"mailto:kboth@drkurt.com" target=3D"_blank" data-mce-href=3D"mailt= o:kboth@drkurt.com">kboth@drkurt.com> wrote:
>>
>>= 1) Be explicit regarding the RFC3463 extended response code which
>&= gt; should be used when rejecting a message due to an out-of-date
>&g= t; attribution. By my reading, the code should be 5.1.6 with whatever
&g= t;> additional explanation the receiver chooses to supply;
>
&g= t; This has come up before, most recently in the SPFbis working group. = ; I'll go
> along with consensus, but for the record, I've never been= a fan of doing
> this.  RFC3463 says quite clearly which codes = are to be used for what
> situations; it seems unnecessary to me to c= all out the specific code when
> the document defining those codes al= ready spells it out.

I would suggest that the document sh= ould not specify the numeric code,
but instead reference the "extended r= esponse code used for permanent
failures attributed to 'Destination mail= box has moved, No forwarding
address'".


------=_Part_28470_1425030753.1374166287950-- From wmills@yahoo-inc.com Thu Jul 18 10:26:53 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E855521E8141 for ; Thu, 18 Jul 2013 10:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.598 X-Spam-Level: X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XgxY7SwUwXf1 for ; Thu, 18 Jul 2013 10:26:29 -0700 (PDT) Received: from mrout2-b.corp.bf1.yahoo.com (mrout2-b.corp.bf1.yahoo.com [98.139.253.105]) by ietfa.amsl.com (Postfix) with ESMTP id B56FD11E81AC for ; Thu, 18 Jul 2013 10:26:26 -0700 (PDT) Received: from BF1-EX10-CAHT11.y.corp.yahoo.com (bf1-ex10-caht11.corp.bf1.yahoo.com [10.74.226.55]) by mrout2-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id r6IHPber062514 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 18 Jul 2013 10:25:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1374168338; bh=SQH9f1vik/QVxvAoUhKCoM2reOlgEVAaW3g21+7L2Cs=; h=References:Message-ID:Date:From:Reply-To:Subject:To:CC: In-Reply-To:MIME-Version:Content-Type; b=wF0aBDipizH+OVGMj6Pp7V3SnW5QFdlYCyoGDj0hlHdPnjiiEDg0yzUzLVzhujIxK HQia7vAVOMNoh+qiU7IITRCHwGkIzHPu1bbxcahQDcExOxiun0LD6suTaGeDLir0Hw q/5208+F+s71So7/TiUMwQFY5uU5WgiLj+q5Jw7s= Received: from omp1041.mail.ne1.yahoo.com (98.138.89.249) by BF1-EX10-CAHT11.y.corp.yahoo.com (10.74.209.170) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 18 Jul 2013 13:25:37 -0400 Received: (qmail 56380 invoked by uid 1000); 18 Jul 2013 17:25:36 -0000 Received: (qmail 29155 invoked by uid 60001); 18 Jul 2013 17:25:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1374168335; bh=K9o+GLpTdFL/FxwqKRGVCUuH3xF9kxCtmhyuTVgD5QM=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Atkjiw0n/Fcj/pEzXBPqoqk1rpdtZQmt8BGfdTLukdyltbS18VE2/rL6k8tIHP1xxhymWcJTfPKOtTQKkhh0Mr5BiEKE1ZILrlZVPfhIV+bZrzyKcQYYFaPYjokYB+L1MIUsKwVbOBvUNLCzCHxYai1e/qpqigq281fey6apm7w= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Klxlg8pttPHhzPoUpMPcpJNgXmRMMduHZOmH2D5rbq5J/wUqGlTOCbi4eC3jkayIReJgT8NJr4P/266vuvFUiwnquZyh5SpK/4WOwSR/BNPoPNt73Ry3PwhAmlTST2GVpkfB0smS6v/IJKaHygPuIJ5pAehL7iBanJdm2cXBnNk=; X-YMail-OSG: JRGmsmEVM1ncsNdd4w097zj6KWl4YSS9_sbTso202SSxsML 7eQNtIlEPgIb6JVf17H0u9mD6vKHSThggizblihVgiahC.f1kvxoEJd1V9lP oprqSvNITjJ.5Nh29zE5Z0wfGqzyOuJDj6rE06znbZJglUjFnQLmEYb3Pzz0 z0R_Wt3SkjpT.MXtVEwMqoGaVX6NvxiLw4SnO2dTs_gErmL4XinL78K0x1Sg WwxgLF6w9cmpObRHQj1Vr0BJd3LgVzTfHxSkhHH9aIQ5y4Ekibrl69te_OP6 gMZuLoZGCqAbIy80LTe2HLIVyvauz Received: from [209.131.62.115] by web125606.mail.ne1.yahoo.com via HTTP; Thu, 18 Jul 2013 10:25:35 PDT X-Rocket-MIMEInfo: 002.001, VGV4dCBjb250ZW50IGluIHRoZXJlIGlzIGZyZWUgZm9ybSBhbmQgdXAgdG8gdGhlIGltcGxlbWVudGVyLsKgIEknbSBpbiBmYXZvciBvZiAidGhpcyBpcyBub3QgdGhlIGRyb2lkIHlvdSdyZSBsb29raW5nIGZvciIuwqAgTm8gb2JqZWN0aW9uIHRvIGFkZGluZyAiKHJydnMpIiB0byB0aGUgZXhhbXBsZSB0ZXh0LCBidXQgaXQncyBub3Qgbm9ybWF0aXZlIGFuZCB3ZSBzaG91bGQgbm90IHRyeSB0byBtYWtlIGl0IHNvLgoKCsKgCi1iaWxsCgoKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCldpbGwBMAEBAQE- X-Mailer: YahooMailWebService/0.8.149.560 References: <1374163757.58014.YahooMailNeo@web125606.mail.ne1.yahoo.com> <1545202623.28471.1374166287951.JavaMail.zimbra@peachymango.org> Message-ID: <1374168335.22112.YahooMailNeo@web125606.mail.ne1.yahoo.com> Date: Thu, 18 Jul 2013 10:25:35 -0700 From: Bill Mills To: Franck Martin In-Reply-To: <1545202623.28471.1374166287951.JavaMail.zimbra@peachymango.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="607277540-334336049-1374168335=:22112" X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 168337002 Cc: Kurt Andersen , IETF Apps Discuss Subject: Re: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Bill Mills List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 17:26:53 -0000 --607277540-334336049-1374168335=:22112 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Text content in there is free form and up to the implementer.=A0 I'm in fav= or of "this is not the droid you're looking for".=A0 No objection to adding= "(rrvs)" to the example text, but it's not normative and we should not try= to make it so.=0A=0A=0A=A0=0A-bill=0A=0A=0A=0A----------------------------= ----=0AWilliam J. Mills=0A"Paranoid" Yahoo!=0A=0A=0A=0A=0A_________________= _______________=0A From: Franck Martin =0ATo: Bill = Mills =0ACc: Kurt Andersen ; Murra= y S. Kucherawy ; IETF Apps Discuss =0ASent: Thursday, July 18, 2013 9:51 AM=0ASubject: Re: [apps-discuss]= Comments on draft-wmills-rrvs-header-field-00=0A =0A=0A=0AI think what Kur= t is saying, is let's avoid RFC chasing. Reference the RFC for Extended cod= e, says it is authoritative, and state that currently the code that matches= is 5.1.6=0A=0A=0AIn the text portion I would even be very explicit that th= is response is due to the presence of the rrvs header field.=0A=0A=0ALet's = avoid second guessing.=0A=0A=0A________________________________=0A=0AFrom: = "Bill Mills" =0ATo: "Kurt Andersen" , "Murray S. Kucherawy" =0ACc: "IETF Apps Discuss" =0ASent: Thursday, July 18, 2013 9:09:17 AM=0ASubject:= Re: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00=0A=0A=0AI= 'm OK with making that the primary text as long as the 5.1.6 is parenthetic= al after, because in the end folks will want to know.=0A=0A=A0=0A-bill=0A= =0A=0A=0A--------------------------------=0AWilliam J. Mills=0A"Paranoid" Y= ahoo!=0A=0A=0A=0A=0A________________________________=0AFrom: Kurt Andersen = =0ATo: Murray S. Kucherawy =0ACc: I= ETF Apps Discuss ; William Mills =0ASent: Thursday, July 18, 2013 6:44 AM=0ASubject: Re: [apps-discuss] = Comments on draft-wmills-rrvs-header-field-00=0A=0A=0AOn Wed, Jul 17, 2013 = at 11:17 PM, Murray S. Kucherawy=0A wrote:=0A> Hi Kurt= , thanks for your comments.=A0 Replies inline:=0A>=0A> On Wed, Jul 17, 2013= at 6:18 PM, Kurt Andersen wrote:=0A>>=0A>> 1) Be explic= it regarding the RFC3463 extended response code which=0A>> should be used w= hen rejecting a message due to an out-of-date=0A>> attribution. By my readi= ng, the code should be 5.1.6 with whatever=0A>> additional explanation the = receiver chooses to supply;=0A>=0A> This has come up before, most recently = in the SPFbis working group.=A0 I'll go=0A> along with consensus, but for t= he record, I've never been a fan of doing=0A> this.=A0 RFC3463 says quite c= learly which codes are to be used for what=0A> situations; it seems unneces= sary to me to call out the specific code when=0A> the document defining tho= se codes already spells it out.=0A=0AI would suggest that the document shou= ld not specify the numeric code,=0Abut instead reference the "extended resp= onse code used for permanent=0Afailures attributed to 'Destination mailbox = has moved, No forwarding=0Aaddress'". --607277540-334336049-1374168335=:22112 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Text cont= ent in there is free form and up to the implementer.  I'm in favor of = "this is not the droid you're looking for".  No objection to adding "(= rrvs)" to the example text, but it's not normative and we should not try to= make it so.

 
-bill
=

--------------------------------
William J. Mills
"Paranoid"= Yahoo!


From: Franck Martin <fr= anck@peachymango.org>
To: Bill Mills <wmills@yahoo-inc.com>
Cc: Kurt Andersen <kboth@drkurt.com>; Murray= S. Kucherawy <superuser@gmail.com>; IETF Apps Discuss <apps-discu= ss@ietf.org>
Sent:= Thursday, July 18, 2013 9:51 AM
= Subject: Re: [apps-discuss] Comments on draft-wmills-rrvs-header= -field-00

=0A=0A =0A
I think what Kurt is saying, = is let's avoid RFC chasing. Reference the RFC for Extended code, says it is= authoritative, and state that currently the code that matches is 5.1.6
=

In the text portion I would even be very explicit= that this response is due to the presence of the rrvs header field.

Let's avoid second guessing.

From: "Bill Mills" <wmills@yahoo-inc.com>= ;
To: "Kurt Andersen" <kboth@drkurt.com>, "Murray S. Kucher= awy" <superuser@gmail.com>
Cc: "IETF Apps Discuss" <apps= -discuss@ietf.org>
Sent: Thursday, July 18, 2013 9:09:17 AMSubject: Re: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00

<= /div>
I'm OK= with making that the primary text as long as the 5.1.6 is parenthetical af= ter, because in the end folks will want to know.
 = ;
-bill


--------------------------------William J. Mills
"Paranoid" Yahoo!


From: Kurt Andersen <kboth@drkur= t.com>
To: Murray= S. Kucherawy <superuser@gmail.com>
Cc: IETF Apps Discuss <apps-discuss@ietf.org>; Wil= liam Mills <wmills@yahoo-inc.com>
Sent: Thursday, July 18, 2013 6:44 AM
Subject: Re: [apps-discuss] Comments on d= raft-wmills-rrvs-header-field-00

On Wed, Jul 17, 2013 at 11:17 PM, Murray S. Kucheraw= y
<superuser@gmail.com>= wrote:
> Hi Kurt, thanks for your comments.  Replies inline:>
> On Wed, Jul 17, 2013 at 6:18 PM, Kurt Andersen <kboth@drkurt.com> wrote:
>>
>> 1) Be explicit regarding the RFC3463 extend= ed response code which
>> should be used when rejecting a message = due to an out-of-date
>> attribution. By my reading, the code shou= ld be 5.1.6 with whatever
>> additional explanation the receiver c= hooses to supply;
>
> This has come up before, most recently in= the SPFbis working group.  I'll go
> along with consensus, but = for the record, I've never been a fan of doing
> this.  RFC3463 = says quite clearly which codes are to be used for what
> situations; = it seems unnecessary to me to call out the specific code when
> the d= ocument defining those codes already spells it out.

I wou= ld suggest that the document should not specify the numeric code,
but in= stead reference the "extended response code used for permanent
failures = attributed to 'Destination mailbox has moved, No forwarding
address'".




=
--607277540-334336049-1374168335=:22112-- From johnl@iecc.com Thu Jul 18 13:30:18 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04AE621E805A for ; Thu, 18 Jul 2013 13:30:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.82 X-Spam-Level: X-Spam-Status: No, score=-110.82 tagged_above=-999 required=5 tests=[AWL=0.379, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RIo-6JsfHhde for ; Thu, 18 Jul 2013 13:30:13 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 5E1DC11E80F2 for ; Thu, 18 Jul 2013 13:30:04 -0700 (PDT) Received: (qmail 31408 invoked from network); 18 Jul 2013 20:30:01 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 18 Jul 2013 20:30:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51e85049.xn--i8sz2z.k1307; i=johnl@user.iecc.com; bh=Ly4kZPvqweE+qqPd1V6tejjCqtYF8Qu0dzD15wWvgqw=; b=jV4jpeags3ND03uPIIZHZB2KA/CfiZP75kJusM+kfpHgb4Rk2kqJhilVuiBMhRKZbgVgUXjazfuO/opPWHtKppsV4X5kOrmaRVsvv7qrmX0foV3a4wpc2/1gXmMqGvXYkeUIrxgF5HO40iElpBewaUOaH+cmvANIt1+O70FW/VDpV9QC0oUbgHzPuftIn8tj5Db43rin3kFBIqsKJAHEPbAS1oDrDT9FSJJg7VehYVpe5JCdI67L6h9ypS6E+zYq 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=51e85049.xn--i8sz2z.k1307; olt=johnl@user.iecc.com; bh=Ly4kZPvqweE+qqPd1V6tejjCqtYF8Qu0dzD15wWvgqw=; b=B3Mtu0+Kx1kXW7hzihYkpPTzwLVFhMB7/PxXTBHCIDSc71xmNTX5P4iyB38TbusGW9W6K5hRIzJ3OqEMydQOPmWBMUJqeXdLl1k8QDeQmuCvzVLUEabpSzga28Ji1iDMxGEDB5TdegxUY1wg4O7ZUc5U7Nis1atWYxJtmtSMggDFVAMwyiNm738BXZkyky64JnUaoVrG1Xrt53P9AUzAF3DLVxKVByL4j+SXfhLqcJaxgbyAco4cBsYdn0Xyjur4 Date: 18 Jul 2013 20:29:39 -0000 Message-ID: <20130718202939.10687.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 Cc: kboth@drkurt.com Subject: Re: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 20:30:18 -0000 >After reviewing draft-wmills-rrvs-header-field-00, it looks like a >very promising step to support the security of potentially re-assigned >email addresses. I'm scratching my head about the security implications. Using the obvious binary search, you can determine the creation date of an address to whatever precision the server will tell you. That feels like one of those things that you can combine with other data to figure out stuff that the server hadn't intended to disclose. I realize you can deter the attack by testing the dates with a coarse granularity, or by limiting the number of queries per address, but that kind of blinding is known not to work well. For example, let's say I don't like people who use throwaway mail addresses, so whenever someone signs up for an account, I put in an rrvs header in the welcome message to check if the address is less than a week old and if it bounces, demand a different address before I let the user activate the account. R's, John From wmills@yahoo-inc.com Thu Jul 18 14:42:41 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68B7C11E8224 for ; Thu, 18 Jul 2013 14:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.598 X-Spam-Level: X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zoAZR8mQmYfd for ; Thu, 18 Jul 2013 14:42:36 -0700 (PDT) Received: from mrout2-b.corp.bf1.yahoo.com (mrout2-b.corp.bf1.yahoo.com [98.139.253.105]) by ietfa.amsl.com (Postfix) with ESMTP id EA6AB11E8227 for ; Thu, 18 Jul 2013 14:42:35 -0700 (PDT) Received: from GQ1-EX10-CAHT03.y.corp.yahoo.com (gq1-ex10-caht03.corp.gq1.yahoo.com [10.73.118.82]) by mrout2-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id r6ILffVq094099 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 18 Jul 2013 14:41:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1374183704; bh=EPtGdXnCVaxmpjCDtAyg+MJGe9xvUU0mGmQSFVJsuOs=; h=References:Message-ID:Date:From:Reply-To:Subject:To:CC: In-Reply-To:MIME-Version:Content-Type; b=PkAQing0O+bTIiVpI9LIvXHc8Jbq7du4k3pqVKSbLcdbYFqqutG5je2somCMQmfBh jKrw66XxZYQlJGIJ9j9qZyRbwmt7zl/o5Kmu2L9cgYY3jOezVxmFYQ8yrgBS9INayl fUf5n83HS4b8AAYybdCUbfMeBxAdy9YggwNLU5NE= Received: from omp1039.mail.ne1.yahoo.com (98.138.88.239) by GQ1-EX10-CAHT03.y.corp.yahoo.com (10.72.228.24) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 18 Jul 2013 14:41:41 -0700 Received: (qmail 72922 invoked by uid 1000); 18 Jul 2013 21:41:40 -0000 Received: (qmail 13390 invoked by uid 60001); 18 Jul 2013 21:41:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1374183700; bh=qnY3cV/YJPv4T7J7CjTREdhLO8lTi1jNRFHorkr/8NU=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=PbITuSLSh8xSgF0JLnCIxnXKFK9EL0qiSEekTec2gmeqXnC1MsxMglD3IRQrzNgpiI2pPvVn4gWeg7APebKTCF+5A3Jn+CCCJ6nLD8HKztlUPvxQG4ObVBqQ2vG0QM3U69PZ/dZuhirvXSpz/p92xTQArBCzERYwFvrBX9+nh+8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=dKbSXWeiW7C2FLpbMxejfAnK7z1sctoGCDuNumIkCCNwlT4InJjtgfY1Nu2PWdGbbsuf1wB9SEZsTqmkHSxxiXI0RUictQz8u6Cpa/E3DFvSn/Bk921JBqv/6M4Pbhrm9pquuBrE11W5v73C2i+iu48eurYiELflMh3pTSEoLKo=; X-YMail-OSG: EF3cviwVM1kySuf.PtjroF.ghGXyTt0qeUfrOCt1AS1n4ux I.rMzh1rV4aHkulxdRVPiWK9.mjKnj.QOG7F_dfocDDAtO14W0YfCrMmk_4O zUSaMZMx5fXZ44ScxWqKJd6ya8IpoijqhCl2FxMDxp5ean9xcOq5RYBmcRRp V1lgn6mueQNyRo2_Qc4I9NErE2HjYNh2iwv4THsUdX7JezWaqSlohR4gbZqk R0djO2Uztp.4HHKGVPpv.orSOmLuAyE9KEED_0TGlqtXetiluqHgAaekDEVp dACzuIBP6_ISVH4Ik7VDSKHC3bQTV Received: from [66.228.162.40] by web125601.mail.ne1.yahoo.com via HTTP; Thu, 18 Jul 2013 14:41:40 PDT X-Rocket-MIMEInfo: 002.001, WWVhaCwgaWYgdGhlcmUgYXJlIGFnZSBiYXNlZCB0aGluZ3MgdGhhdCB5b3UgdXNlIGluIGN1c3RvbWVyIGNhcmUsIGZvciBleGFtcGxlLCBmb3IgYWNjb3VudCByZWNvdmVyeSB0aGVuIGl0J3MgYW4gZXhwb3N1cmUuwqAgU2Vjb25kIG9yZGVyIHRoaW5ncyBsaWtlIEFsaWNlIGtub3dzIHdoZXJlIEJvYiB1c2VkIHRvIGxpdmUgKG9yIGNhbiBkYXRhLW1pbmUgdGhhdCkgbGV0J3MgQWxpY2UgZ3Vlc3MgdGhlIHBvc3RhbCBjb2RlIGF0IHRoZSB0aW1lIG9mIHJlZ2lzdHJhdGlvbi4KCgrCoAotYmlsbAoKCgotLS0BMAEBAQE- X-Mailer: YahooMailWebService/0.8.149.560 References: <20130718202939.10687.qmail@joyce.lan> Message-ID: <1374183700.12320.YahooMailNeo@web125601.mail.ne1.yahoo.com> Date: Thu, 18 Jul 2013 14:41:40 -0700 From: Bill Mills To: John Levine , "apps-discuss@ietf.org" In-Reply-To: <20130718202939.10687.qmail@joyce.lan> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1981468715-147482054-1374183700=:12320" X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 183703000 Cc: "kboth@drkurt.com" Subject: Re: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Bill Mills List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 21:42:41 -0000 ---1981468715-147482054-1374183700=:12320 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yeah, if there are age based things that you use in customer care, for exam= ple, for account recovery then it's an exposure.=A0 Second order things lik= e Alice knows where Bob used to live (or can data-mine that) let's Alice gu= ess the postal code at the time of registration.=0A=0A=0A=A0=0A-bill=0A=0A= =0A=0A--------------------------------=0AWilliam J. Mills=0A"Paranoid" Yaho= o!=0A=0A=0A=0A=0A________________________________=0A From: John Levine =0ATo: apps-discuss@ietf.org =0ACc: kboth@drkurt.com =0ASent: = Thursday, July 18, 2013 1:29 PM=0ASubject: Re: [apps-discuss] Comments on d= raft-wmills-rrvs-header-field-00=0A =0A=0A>After reviewing draft-wmills-rrv= s-header-field-00, it looks like a=0A>very promising step to support the se= curity of potentially re-assigned=0A>email addresses.=0A=0AI'm scratching m= y head about the security implications.=A0 Using the=0Aobvious binary searc= h, you can determine the creation date of an=0Aaddress to whatever precisio= n the server will tell you.=0A=0AThat feels like one of those things that y= ou can combine with other=0Adata to figure out stuff that the server hadn't= intended to disclose.=0AI realize you can deter the attack by testing the = dates with a coarse=0Agranularity, or by limiting the number of queries per= address, but=0Athat kind of blinding is known not to work well.=0A=0AFor e= xample, let's say I don't like people who use throwaway mail=0Aaddresses, s= o whenever someone signs up for an account, I put in an=0Arrvs header in th= e welcome message to check if the address is less=0Athan a week old and if = it bounces, demand a different address before I=0Alet the user activate the= account.=0A=0AR's,=0AJohn=0A______________________________________________= _=0Aapps-discuss mailing list=0Aapps-discuss@ietf.org=0Ahttps://www.ietf.or= g/mailman/listinfo/apps-discuss ---1981468715-147482054-1374183700=:12320 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Yeah, if = there are age based things that you use in customer care, for example, for = account recovery then it's an exposure.  Second order things like Alic= e knows where Bob used to live (or can data-mine that) let's Alice guess th= e postal code at the time of registration.

<= div> 
-bill


--------------------------------
= William J. Mills
"Paranoid" Yahoo!


= From: John Levine <johnl@taugh.com>
To: apps-discuss@ietf.org
Cc: kboth@drkurt.com
Sent: Thursday, July 18, 2013 1:29 PM
Subject: Re: [apps-discuss] Commen= ts on draft-wmills-rrvs-header-field-00

>After reviewing draft-wmills-rrvs-header-field-00, i= t looks like a
>very promising step to support the security of potent= ially re-assigned
>email addresses.

I'm scratching my head abo= ut the security implications.  Using the
obvious binary search, you= can determine the creation date of an
address to whatever precision the= server will tell you.

That feels like one of those things that you = can combine with other
data to figure out stuff that the server hadn't inte= nded to disclose.
I realize you can deter the attack by testing the date= s with a coarse
granularity, or by limiting the number of queries per ad= dress, but
that kind of blinding is known not to work well.

For e= xample, let's say I don't like people who use throwaway mail
addresses, = so whenever someone signs up for an account, I put in an
rrvs header in = the welcome message to check if the address is less
than a week old and = if it bounces, demand a different address before I
let the user activate= the account.

R's,
John
______________________________________= _________
apps-discuss mailing list
apps-discuss@ietf.org<= br>https://www.ietf.org/mailman/listinfo/apps-discuss

---1981468715-147482054-1374183700=:12320-- From superuser@gmail.com Thu Jul 18 16:41:22 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF84C21E8178 for ; Thu, 18 Jul 2013 16:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MNEIsbYxeU9q for ; Thu, 18 Jul 2013 16:41:22 -0700 (PDT) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id D777621E8175 for ; Thu, 18 Jul 2013 16:41:21 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id u53so3365348wes.23 for ; Thu, 18 Jul 2013 16:41:21 -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=aQUeW9OIKIjIUbd04mm/zZrEG/Seqib/oqeXcVSnn/U=; b=UaJP8OB4KIKPcIsknUueqF/IcttYcxSEOpC+fewb4GmTBpaEgRc/lwSlXnjXspo6QT H6hQBTH0CLGfU5EuzhL8hfcF+eckt71CCSP4eOhoyEJOqWWrtWz10az1Mfg37so7KJUQ JgzpOkOt7SdPVO/H9kxWPRUYsNOGBrDUJ+L3j2c2V9LwkQ/ZTksbNetGqcpsGTtw9j+6 fGFb8BRrsIoAhn8kpLtHCvzlVjulkujpzWYjyCpi3/fvui5x7upNL2z1Ww45FN0Oy/Zz eaSNQL5cgDqnSTbVoLRBTsJ4J+AttgCdrU0AMb56rOHbshwfBHlX+3srBmu1VRMWRdIR Matg== MIME-Version: 1.0 X-Received: by 10.180.89.231 with SMTP id br7mr21080397wib.19.1374190880963; Thu, 18 Jul 2013 16:41:20 -0700 (PDT) Received: by 10.180.90.16 with HTTP; Thu, 18 Jul 2013 16:41:20 -0700 (PDT) In-Reply-To: <20130718202939.10687.qmail@joyce.lan> References: <20130718202939.10687.qmail@joyce.lan> Date: Thu, 18 Jul 2013 16:41:20 -0700 Message-ID: From: "Murray S. Kucherawy" To: John Levine Content-Type: multipart/alternative; boundary=e89a8f3ba2555041e404e1d1bfcd Cc: "" , IETF Apps Discuss Subject: Re: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 23:41:22 -0000 --e89a8f3ba2555041e404e1d1bfcd Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jul 18, 2013 at 1:29 PM, John Levine wrote: > I'm scratching my head about the security implications. Using the > obvious binary search, you can determine the creation date of an > address to whatever precision the server will tell you. > Right, and I think Security Considerations already calls this out. > That feels like one of those things that you can combine with other > data to figure out stuff that the server hadn't intended to disclose. > I realize you can deter the attack by testing the dates with a coarse > granularity, or by limiting the number of queries per address, but > that kind of blinding is known not to work well. > > For example, let's say I don't like people who use throwaway mail > addresses, so whenever someone signs up for an account, I put in an > rrvs header in the welcome message to check if the address is less > than a week old and if it bounces, demand a different address before I > let the user activate the account. > > Aren't those sorts of things merely side effects of what Security Considerations already says? -MSK --e89a8f3ba2555041e404e1d1bfcd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Jul 18, 2013 at 1:29 PM, John Levine <johnl@taugh.c= om> wrote:
I'm scratching my head about the security implications. =A0Using the obvious binary search, you can determine the creation date of an
address to whatever precision the server will tell you.

Right, and I think Security Considerations already calls t= his out.
=A0
That feels like one of those things that you can combine with other
data to figure out stuff that the server hadn't intended to disclose. I realize you can deter the attack by testing the dates with a coarse
granularity, or by limiting the number of queries per address, but
that kind of blinding is known not to work well.

For example, let's say I don't like people who use throwaway mail addresses, so whenever someone signs up for an account, I put in an
rrvs header in the welcome message to check if the address is less
than a week old and if it bounces, demand a different address before I
let the user activate the account.


Aren't those sorts of things merel= y side effects of what Security Considerations already says?

<= div>-MSK

--e89a8f3ba2555041e404e1d1bfcd-- From johnl@taugh.com Thu Jul 18 16:53:43 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B07C521E818D for ; Thu, 18 Jul 2013 16:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JmyfhBFCbhPI for ; Thu, 18 Jul 2013 16:53:43 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 8E0CE21E8182 for ; Thu, 18 Jul 2013 16:53:41 -0700 (PDT) Received: (qmail 75671 invoked from network); 18 Jul 2013 23:53:39 -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:cleverness; s=12793.51e88003.k1307; bh=wrmS3aAgMqyVzwSlvyUmZXnZKlTC6wGz39EAdb2tL2k=; b=GQS5EDDn/yobT9gRiCCzBAqsEc6t8dok5JUxn6FtByEKt7SXW7eZ4rkJMgGTXI90eYQ0lETL6CIl8HyDhWIgUfBWTowNlGtLmMg0+j8IuhesTvXrJFIdPcaUWjyZKkXGZVjjqCylkZWFfZ+VaiWxgcEjUFvY1HRx+qpKqxNv5nynC/+rLH/gfII/4SKh75fpQyc3sqPBF3IFAUTgNA2SkOVRTud5kR0MRtrsIuY7MJTUeMrZrVr1YHYlm/OhwXIV 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:cleverness; s=12793.51e88003.k1307; bh=wrmS3aAgMqyVzwSlvyUmZXnZKlTC6wGz39EAdb2tL2k=; b=r6qEOjqx/V+CmnWrg+dWlJMRt8fDq2zfTZ8JmmzoHQNIDVB+CkFcFW0yKZn4+QjAP7pIY450Go03zzcOJ56vdi88Cz9E6+zcEqDo75ABWD8Y+npeR41GNbiw72CjPv4qrty3HhhFjQrnLKgcbd/nsj14gxzoJAwEOR6ncNbEm0HyEaEtbt+npsxPlULTSasD7GRUP2S4gpJl3xpgklPMspPYuqGV/F8bNfsS1T4Jr957jAMgp4Rt0fJ0fV+o0Eoe Received: (ofmipd 127.0.0.1); 18 Jul 2013 23:53:17 -0000 Date: 18 Jul 2013 19:53:39 -0400 Message-ID: From: "John R Levine" To: "Murray S. Kucherawy" In-Reply-To: References: <20130718202939.10687.qmail@joyce.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 23:53:43 -0000 >> For example, let's say I don't like people who use throwaway mail >> addresses, so whenever someone signs up for an account, I put in an >> rrvs header in the welcome message to check if the address is less >> than a week old and if it bounces, demand a different address before I >> let the user activate the account. >> > Aren't those sorts of things merely side effects of what Security > Considerations already says? Probably, but I've found it's usually worth some head scratching to ponder the implications of any new information leak. R's, John From haibin.song@huawei.com Thu Jul 18 18:16:48 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94B1521E813B for ; Thu, 18 Jul 2013 18:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nRgsdeiinfRF for ; Thu, 18 Jul 2013 18:16:44 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4484521E80E3 for ; Thu, 18 Jul 2013 18:16:39 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATO71021; Fri, 19 Jul 2013 01:16:35 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 19 Jul 2013 02:15:50 +0100 Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 19 Jul 2013 02:16:32 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.43]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.01.0323.007; Fri, 19 Jul 2013 09:16:26 +0800 From: "Songhaibin (A)" To: "Murray S. Kucherawy" , IETF Apps Discuss Thread-Topic: [apps-discuss] Preliminary IETF 87 APPSAWG/APPAREA agenda posted Thread-Index: AQHOgxkNQfkU4jWunkqWovfslrYg7JlrNDKQ Date: Fri, 19 Jul 2013 01:16:26 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.51] Content-Type: multipart/alternative; boundary="_000_E33E01DFD5BEA24B9F3F18671078951F24716FE4nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [apps-discuss] Preliminary IETF 87 APPSAWG/APPAREA agenda posted X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jul 2013 01:16:48 -0000 --_000_E33E01DFD5BEA24B9F3F18671078951F24716FE4nkgeml501mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Murray, I hope I can get a short slot (5 to 10 minutes) in Appsawg to introduce the= problems described in the following draft. The draft is very short and I c= an improve it later. http://tools.ietf.org/id/draft-song-appsawg-service-template-00.txt BR, -Haibin From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = On Behalf Of Murray S. Kucherawy Sent: Thursday, July 18, 2013 2:11 AM To: IETF Apps Discuss Subject: [apps-discuss] Preliminary IETF 87 APPSAWG/APPAREA agenda posted https://datatracker.ietf.org/meeting/87/agenda/appsawg/ Please submit any requests for changes as soon as possible. Revisions are = due on 7/22 (Monday). -MSK, APPSAWG co-chair --_000_E33E01DFD5BEA24B9F3F18671078951F24716FE4nkgeml501mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Murray,=

 = ;

I hope I c= an get a short slot (5 to 10 minutes) in Appsawg to introduce the problems = described in the following draft. The draft is very short and I can improve it later.

http:= //tools.ietf.org/id/draft-song-appsawg-service-template-00.txt

 = ;

 

BR,

-Haibin

 = ;

From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bo= unces@ietf.org] On Behalf Of Murray S. Kucherawy
Sent: Thursday, July 18, 2013 2:11 AM
To: IETF Apps Discuss
Subject: [apps-discuss] Preliminary IETF 87 APPSAWG/APPAREA agenda p= osted

 

= Please submit any requests for changes as soon as possible.  Revisions= are due on 7/22 (Monday).

= -MSK, APPSAWG co-chair

--_000_E33E01DFD5BEA24B9F3F18671078951F24716FE4nkgeml501mbschi_-- From wmills@yahoo-inc.com Thu Jul 18 21:55:53 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BFC321E81B3 for ; Thu, 18 Jul 2013 21:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.598 X-Spam-Level: X-Spam-Status: No, score=-18.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82PRADeUv-Ht for ; Thu, 18 Jul 2013 21:55:48 -0700 (PDT) Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8E6DC11E828D for ; Thu, 18 Jul 2013 21:55:48 -0700 (PDT) Received: from BF1-EX10-CAHT15.y.corp.yahoo.com (bf1-ex10-caht15.corp.bf1.yahoo.com [10.74.226.59]) by mrout2.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id r6J4rmug076695 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 18 Jul 2013 21:53:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1374209630; bh=3xpzXoC3KnbBmcYkYMsp0Cw2N4PUSxIX6htwz1vB5DA=; h=References:Message-ID:Date:From:Reply-To:Subject:To:CC: In-Reply-To:MIME-Version:Content-Type; b=MWcnAv3hQqYIm90yg7CREPRVEp6g/D2QvVpWkDPBsy4vkWRvz/SFe/LLZGJcYlr6b sP+V/J4xOAtFQdOnYP660TiHK/mdP8nHKG8gbewme6aJHCN6NU3NTaIaVIh20owrmb JNawCuNsY306iYJz3HvsfSFPg9ksvZIVQn+9ZaTQ= Received: from omp1060.mail.ne1.yahoo.com (98.138.89.246) by BF1-EX10-CAHT15.y.corp.yahoo.com (10.74.209.170) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 19 Jul 2013 00:53:48 -0400 Received: (qmail 12781 invoked by uid 1000); 19 Jul 2013 04:53:47 -0000 Received: (qmail 52364 invoked by uid 60001); 19 Jul 2013 04:53:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1374209627; bh=KOxdSpDHyAEoPBtLEi1wJ0FbsJn93abPonozTZmIv/s=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=qW80onF7PZQr0URLQCzb0dbWGr/j0Of3q5iew0RD/q1GF0BenLhUijv4y7CAsb5iSortJBJlyLIUqCSjZuISCW8tj3bcT7JX0SDBfrJ96brVA+KjzYbUMTSw0bCtQa7VpTnzt6EU6toOxrNfNGCpXlhgWO26Cyzdt/ST5kErF14= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=hnuG7IIz18dgkkCz0GJEHcFPl4PstEfxRaGaPV5rnM5DH1tkQhEo77AiZ7KyxLAS83zYriDID2HgfIyOa7chqrJbhSLvDiHlbtJWI3u13Qabts4TL99w7UBjgJ1GNULZ8t+hE+THM/oOT2m9nxMDCEBZTvbAP5UXtA1pvYmOp8s=; X-YMail-OSG: _Mp5lHgVM1lLSQWOBuxLGmNu6mlcsw52ymwbX5UoSHUm0DB WvIPKPDsIjAQaL_QbN.DHtfF6WwzyzwGfupO3ognP.jsL Received: from [99.31.212.42] by web125604.mail.ne1.yahoo.com via HTTP; Thu, 18 Jul 2013 21:53:46 PDT X-Rocket-MIMEInfo: 002.001, R290dGEgbWFrZSBzdXJlIHdlIGFjdHVhbGx5IGdvdCBpdCByaWdodC7CoCBJJ20gZ29vZCB3aXRoIHRoYXQgOikKCsKgCi1iaWxsCgoKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCldpbGxpYW0gSi4gTWlsbHMKIlBhcmFub2lkIiBZYWhvbyEKCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCiBGcm9tOiBKb2huIFIgTGV2aW5lIDxqb2hubEB0YXVnaC5jb20.ClRvOiBNdXJyYXkgUy4gS3VjaGVyYXd5IDxzdXBlcnVzZXJAZ21haWwuY29tPiAKQ2M6IElFVEYgQXBwcyBEaXNjdXMBMAEBAQE- X-Mailer: YahooMailWebService/0.8.149.560 References: <20130718202939.10687.qmail@joyce.lan> Message-ID: <1374209626.42122.YahooMailNeo@web125604.mail.ne1.yahoo.com> Date: Thu, 18 Jul 2013 21:53:46 -0700 From: Bill Mills To: John R Levine , "Murray S. Kucherawy" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-685807438-858317798-1374209626=:42122" X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 209630001 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Bill Mills List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 04:55:53 -0000 ---685807438-858317798-1374209626=:42122 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Gotta make sure we actually got it right.=A0 I'm good with that :)=0A=0A=A0= =0A-bill=0A=0A=0A=0A--------------------------------=0AWilliam J. Mills=0A"= Paranoid" Yahoo!=0A=0A=0A=0A=0A________________________________=0A From: Jo= hn R Levine =0ATo: Murray S. Kucherawy =0ACc: IETF Apps Discuss =0ASent: Thursday, July= 18, 2013 4:53 PM=0ASubject: Re: [apps-discuss] Comments on draft-wmills-rr= vs-header-field-00=0A =0A=0A>> For example, let's say I don't like people w= ho use throwaway mail=0A>> addresses, so whenever someone signs up for an a= ccount, I put in an=0A>> rrvs header in the welcome message to check if the= address is less=0A>> than a week old and if it bounces, demand a different= address before I=0A>> let the user activate the account.=0A>>=0A> Aren't t= hose sorts of things merely side effects of what Security=0A> Consideration= s already says?=0A=0AProbably, but I've found it's usually worth some head = scratching to ponder =0Athe implications of any new information leak.=0A=0A= R's,=0AJohn=0A_______________________________________________=0Aapps-discus= s mailing list=0Aapps-discuss@ietf.org=0Ahttps://www.ietf.org/mailman/listi= nfo/apps-discuss ---685807438-858317798-1374209626=:42122 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Gotta make sure we actually got it right.  I'm good with that :)
=
 
-bill


----------------------= ----------
William J. Mills
"Paranoid" Yahoo!


From: John R Levine <johnl@taugh.com>
To: Murray S. Kucherawy <superuser@gmail.com>
Cc:<= /span> IETF Apps Discuss <apps-discuss@ietf.org>
Sent: Thursday, July 18, 2013 4:53 PM=
Subject: Re: [apps-di= scuss] Comments on draft-wmills-rrvs-header-field-00

>> For example, let's say I don't lik= e people who use throwaway mail
>> addresses, so whenever someone = signs up for an account, I put in an
>> rrvs header in the welcome= message to check if the address is less
>> than a week old and if= it bounces, demand a different address before I
>> let the user a= ctivate the account.
>>
> Aren't those sorts of things merel= y side effects of what Security
> Considerations already says?
Probably, but I've found it's usually worth some head scratching to ponder
the implications of any new information leak.

R's,
John
_= ______________________________________________
apps-discuss mailing list=
apps-discuss@ietf.org
https://www.ietf.org/mailman/= listinfo/apps-discuss


---685807438-858317798-1374209626=:42122-- From ietfc@btconnect.com Fri Jul 19 00:03:49 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E04BB11E8135 for ; Fri, 19 Jul 2013 00:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.555 X-Spam-Level: X-Spam-Status: No, score=-1.555 tagged_above=-999 required=5 tests=[AWL=1.044, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id irfhdW4Qdc9N for ; Fri, 19 Jul 2013 00:03:44 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0185.outbound.messaging.microsoft.com [213.199.154.185]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD9221F9D01 for ; Fri, 19 Jul 2013 00:03:44 -0700 (PDT) Received: from mail196-db8-R.bigfish.com (10.174.8.233) by DB8EHSOBE021.bigfish.com (10.174.4.84) with Microsoft SMTP Server id 14.1.225.22; Fri, 19 Jul 2013 07:03:43 +0000 Received: from mail196-db8 (localhost [127.0.0.1]) by mail196-db8-R.bigfish.com (Postfix) with ESMTP id 02399AC01CB; Fri, 19 Jul 2013 07:03:43 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.249.213; KIP:(null); UIP:(null); IPV:NLI; H:AM2PRD0710HT002.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -16 X-BigFish: PS-16(zz9371I542I1432I1418I4015Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah1de097h1de096h8275dhz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h304l1d11m1155h) Received: from mail196-db8 (localhost.localdomain [127.0.0.1]) by mail196-db8 (MessageSwitch) id 1374217421101288_5737; Fri, 19 Jul 2013 07:03:41 +0000 (UTC) Received: from DB8EHSMHS004.bigfish.com (unknown [10.174.8.232]) by mail196-db8.bigfish.com (Postfix) with ESMTP id 082A11401D4; Fri, 19 Jul 2013 07:03:41 +0000 (UTC) Received: from AM2PRD0710HT002.eurprd07.prod.outlook.com (157.56.249.213) by DB8EHSMHS004.bigfish.com (10.174.4.14) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 19 Jul 2013 07:03:40 +0000 Received: from AMXPRD0111HT001.eurprd01.prod.exchangelabs.com (157.56.250.117) by pod51017.outlook.com (10.255.165.37) with Microsoft SMTP Server (TLS) id 14.16.329.3; Fri, 19 Jul 2013 07:03:38 +0000 Message-ID: <000901ce844e$1a03df60$4001a8c0@gateway.2wire.net> From: t.petch To: Applications Area Directors , Apps Discuss References: Date: Fri, 19 Jul 2013 08:03:26 +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: [157.56.250.117] X-OriginatorOrg: btconnect.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [apps-discuss] Comments solicited on the desired expertise for ADs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jul 2013 07:03:50 -0000 ----- Original Message ----- From: "Applications Area Directors" To: "Apps Discuss" Sent: Wednesday, July 17, 2013 6:20 PM > Applications Area denizens, > > The IESG is in the process of updating the list of desired expertise > for ADs, which it sends to the NomCom each year. The App ADs have > updated the information for the Applications Area, and we'd like you > folks to review and comment. > > The overall list is anchored here: > http://trac.tools.ietf.org/group/iesg/trac/wiki/DesiredExpertise > > Specifically, we're asking for review of the generic expertise desired > for all ADs: > http://trac.tools.ietf.org/group/iesg/trac/wiki/GenericExpertise Interesting. The words seem right except that they may not capture the flavour of the IETF. Yes, the ADs are managers and the good ones manage, but perhaps not in a way that is taught in a management school. In a business, or in most organisations, there is a greater bond amongst the managed, a greater common goal that a manager can leverage to steer people in the best direction. Thus one task I perform, in a volunteer organisation, gets described as herding cats, and I see parallels in the IETF. Here, as this page says, it is about volunteers and they have all sorts of diverse constraints and motivations which may not even be apparent. I think that to manage in this situation requires a tolerance, a flexibility that the less good ADs lack, not understanding why what is so obviously right is not happening. Yes, it is management, but not as we know it (unless you have wider experience of making things happen in volunteer organisations). Arguably, those who come from a business with a reputation for being 'well managed', in a management school sense, could be those who find it hardest to adapt to the IETF culture (although no examples of that come immediately to mind). Tom Petch > ...and for the desired expertise for Applications ADs: > http://trac.tools.ietf.org/group/iesg/trac/wiki/AppsExpertise > > Please send us comments right away, as the IESG will soon have to send > a final set to the NomCom. You may comment on this list, > . If you prefer, you may also send comments to > Pete and Barry at , or to the IESG as a whole > at (use this if you have comments on the generic > list). > > Thanks, > Barry and Pete, Applications ADs > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From glenn.parsons@ericsson.com Fri Jul 19 03:21:56 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE9421E8098; Fri, 19 Jul 2013 03:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nM0VVbZNnEqS; Fri, 19 Jul 2013 03:21:44 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id B9A3F21E8095; Fri, 19 Jul 2013 03:21:43 -0700 (PDT) X-AuditID: c618062d-b7fc36d0000032ea-e4-51e91336298e Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 47.50.13034.63319E15; Fri, 19 Jul 2013 12:21:43 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0328.009; Fri, 19 Jul 2013 06:21:42 -0400 From: Glenn Parsons To: "draft-yusef-dispatch-ccmp-indication.all@tools.ietf.org" , "apps-discuss@ietf.org" Thread-Topic: AppsDir review of draft-yusef-dispatch-ccmp-indication-04 Thread-Index: AQHOg48w1dzXPIkJCkK2xcjz8TTxoplrxC8w Date: Fri, 19 Jul 2013 10:21:42 +0000 Message-ID: <2BBEF519D867E04EA729626C246A978702E7A200@eusaamb101.ericsson.se> References: In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrPLMWRmVeSWpSXmKPExsUyuXRPgq658MtAgwPtPBarX65gs3h0vYfJ YsaficwOzB5Llvxk8vhy+TNbAFMUl01Kak5mWWqRvl0CV8bKToGCfbwVqxefY21gfMTVxcjJ ISFgIvHs6m9mCFtM4sK99WxdjFwcQgJHGSVmPFkI5HAAOcsZJe6agNSwCRhI3L1yFaxGRGAN o8TDDb/AmpkFJCRaPj9jBbGFBZwkDs1dChYXEXCXaJ7ymAlkjoiAkcSbBbogYRYBVYmt238y gti8Ar4S7393skCsCpSYshGsk1MgSOJi5w92EJtRQFZi99nrTBCbxCVuPZnPBHGygMSSPeeh zheVePn4HyuErSzxfc4jFoh6HYkFuz+xQdjaEssWvmaGWCsocXLmE5YJjGKzkIydhaRlFpKW WUhaFjCyrGLkKC1OLctNNzLYxAiMlGMSbLo7GPe8tDzEKM3BoiTOu0rvTKCQQHpiSWp2ampB alF8UWlOavEhRiYOTqkGxgWKe3t5tkmdCjZcN6vta++qI1fC9p785nfWgztm5uFj0/SrZqqu apm4R6SoZvakazvTtdOWLwtpijwYUTrV8cu56Sz5Z9e9vrt76r3OYL3P0dPv/tR99Npq/sUE 9maGd7d9Ti2w/ryU74idjD/jsb83XV7qlX4JrI6ROmfjr2uyWlZ7S5jDVQslluKMREMt5qLi RAA9HfbjYgIAAA== Cc: IESG Subject: [apps-discuss] AppsDir review of draft-yusef-dispatch-ccmp-indication-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 10:21:56 -0000 Hello all, I have been selected as the Applications Area Directorate reviewer for this= draft (for background on appsdir, please see http://trac.tools.ietf.org/ar= ea/app/trac/wiki/ApplicationsAreaDirectorate). Please resolve these comments along with any other Last Call comments you m= ay receive. Please wait for direction from your document shepherd or AD bef= ore posting a new version of the draft. Document: draft-yusef-dispatch-ccmp-indication-04 Title: Conference Focus Indicating CCMP Support Reviewer: Glenn Parsons Review Date: July 19th, 2013 Summary: The document is needs some improvements in explanation and then wo= uld be ready for publication. Major issues: There are 4 approaches described here. And two are standardized. The abst= ract indicates that pros/cons are explained, but these only appear for the = two not chosen. The reader would benefit from understanding the difference= in choosing between the two approaches standardized. Further, what is the= recommendation for the two not chosen? Could these still be used and they= are shown as a guide? Or must they not be used? Minor Issues: In the abstract: ...the XCON conference event package RFC 4575 [RFC4575] ... This appears to= be incorrect. Do you want to refer the RFC 6502 or 4575 here? I suspect = it is the former, and if so some mention of this in the body of the documen= t (like in 2.1 with XCON-URI) is needed as well as a reference. In the Introduction: RFC 5238 [RFC5239] defines a... -> RFC 5239 [RFC5239] defines a... In 2.1, 4.2: Focus -> conference focus. Perhaps a reference to the definition of this t= erm would be helpful. =20 Nits: None. From peter@denic.de Fri Jul 19 03:51:49 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EC2211E80F6 for ; Fri, 19 Jul 2013 03:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4zwBrnQ6YuBW for ; Fri, 19 Jul 2013 03:51:48 -0700 (PDT) Received: from office.denic.de (office.denic.de [IPv6:2a02:568:122:16:1::3]) by ietfa.amsl.com (Postfix) with ESMTP id 08B3F11E8102 for ; Fri, 19 Jul 2013 03:51:48 -0700 (PDT) Received: from x27.adm.denic.de (x28.fra2.if.denic.de [10.122.64.17]) by office.denic.de with esmtp id 1V08Hq-0007Yj-Rh; Fri, 19 Jul 2013 12:51:46 +0200 Received: from localhost by x27.adm.denic.de with local id 1V08Hq-0007wB-OJ; Fri, 19 Jul 2013 12:51:46 +0200 Date: Fri, 19 Jul 2013 12:51:46 +0200 From: Peter Koch To: IETF Apps Discuss Message-ID: <20130719105146.GA30100@x28.adm.denic.de> Mail-Followup-To: IETF Apps Discuss References: <20130718202939.10687.qmail@joyce.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Subject: Re: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 10:51:49 -0000 On Thu, Jul 18, 2013 at 04:41:20PM -0700, Murray S. Kucherawy wrote: > Aren't those sorts of things merely side effects of what Security > Considerations already says? interestingly, part of the issue would belong into the Privacy Considerations section. For the probing, I think the specification is ambiguous about those time where an account was invalid/not assigned to anybody. Depending on how that's solved, one would either be able to find the initiation of termination date, but not nevessarily both. Either is, of course, a potential privacy breach. Privacy/Security Considerations should mention that using the header might give a flase sense of security and also, to state the obvious, that public key cryptography is a much better solution (ignoring usability issues). -Peter From superuser@gmail.com Fri Jul 19 07:20:05 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1D1A11E8140 for ; Fri, 19 Jul 2013 07:20:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mHoNTgR85EUw for ; Fri, 19 Jul 2013 07:20:05 -0700 (PDT) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id D836711E812C for ; Fri, 19 Jul 2013 07:20:04 -0700 (PDT) Received: by mail-wg0-f54.google.com with SMTP id n11so4128298wgh.9 for ; Fri, 19 Jul 2013 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 :content-type; bh=pcTeDfSxOv8GyXY5TclDfHMV1F2PJ6F6B/H29RMVkfY=; b=s9KPcn2NsuXsrkup3HSC9SYDNiIl8HYMCRGnIS0z0DuXrtgCM8cUyef90HsoiUp0z3 W3MSEfmfU0akM7Nixsim65J30aDUSjMBVvd4vzQAa5KATM+3UIWHA6iKDMY6xb3ElhJB zV7RZTmxPB8Bf7cR+uXpzHh/5sYIXa/z5tQNbhX8RuExXAt/9mCpaHJFJTlYrgERraJE I1Nm6APsdB2SWKk/5ZmfimVYb8VKLzY/ricPnzCh7ftn9Mp5P6Sp/y4vh/vGGfqbY3U6 UEqqiP9RaduAPjePRNxl0ue9jrbW7lX1V/Fc0QdoXuULW1sqmZ2friRXhwIwkFZzi9aR qbFA== MIME-Version: 1.0 X-Received: by 10.194.122.71 with SMTP id lq7mr12107018wjb.77.1374243604045; Fri, 19 Jul 2013 07:20:04 -0700 (PDT) Received: by 10.180.90.16 with HTTP; Fri, 19 Jul 2013 07:20:03 -0700 (PDT) In-Reply-To: <20130719105146.GA30100@x28.adm.denic.de> References: <20130718202939.10687.qmail@joyce.lan> <20130719105146.GA30100@x28.adm.denic.de> Date: Fri, 19 Jul 2013 07:20:03 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=089e01229750daa73c04e1de0562 Subject: Re: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 14:20:05 -0000 --089e01229750daa73c04e1de0562 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jul 19, 2013 at 3:51 AM, Peter Koch wrote: > > Aren't those sorts of things merely side effects of what Security > > Considerations already says? > > interestingly, part of the issue would belong into the Privacy > Considerations > section. For the probing, I think the specification is ambiguous about > those time where an account was invalid/not assigned to anybody. > Depending on how that's solved, one would either be able to find the > initiation of termination date, but not nevessarily both. Either is, of > course, a potential privacy breach. > > Privacy/Security Considerations should mention that using the header > might give a flase sense of security and also, to state the obvious, > that public key cryptography is a much better solution (ignoring > usability issues). > > > I don't believe we need to call that out. If an account was created at time T1, then an inquiry as to whether it's been under continuous ownership since time T0 (for T0 < T1) would be "no". If the account has been deleted, then there's no need to check for an existence or change of ownership, because the mail won't be delivered anyway regardless of when it might have been created, reassigned, or deleted. What would the introduction of encryption solve? -MSK --089e01229750daa73c04e1de0562 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Jul 19, 2013 at 3:51 AM, Peter Koch <pk@denic.de>= ; wrote:
> Aren't those sorts of things merely side effects= of what Security
> Considerations already says?

interestingly, part of the issue would belong into the Privacy Consid= erations
section. For the probing, I think the specification is ambiguous about
those time where an account was invalid/not assigned to anybody.
Depending on how that's solved, one would either be able to find the initiation of termination date, but not nevessarily both. =A0Either is, of<= br> course, a potential privacy breach.

Privacy/Security Considerations should mention that using the header
might give a flase sense of security and also, to state the obvious,
that public key cryptography is a much better solution (ignoring
usability issues).



I don't believe we need to call that out.=A0= If an account was created at time T1, then an inquiry as to whether it'= ;s been under continuous ownership since time T0 (for T0 < T1) would be = "no".=A0 If the account has been deleted, then there's no nee= d to check for an existence or change of ownership, because the mail won= 9;t be delivered anyway regardless of when it might have been created, reas= signed, or deleted.

What would the introduction of encryption solve?

-MSK
--089e01229750daa73c04e1de0562-- From kurta@drkurt.com Fri Jul 19 07:30:41 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC6521E80D0 for ; Fri, 19 Jul 2013 07:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xW3eetJhtQVD for ; Fri, 19 Jul 2013 07:30:40 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 8C82A21E80BF for ; Fri, 19 Jul 2013 07:30:37 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id hq4so7929396wib.6 for ; Fri, 19 Jul 2013 07:30:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=SSM+OwLt1ExtiepXHGox0UmwnHaZht27c5f4Oi94keo=; b=YGMQjsZmUw1uBTwIwoxLciQd2lH0OC98fLL5S7As0pEdt+YDDgws92KcaF2IGVzF/Q xccGcGUJpGpZW153Md/Anc5HvyFvdasmQAV0k5bGPTkcvCg+eBOn1x9XZNfVMBboSWvW aEkWl1BiU+3AOqZ7hW2oI6+JEhc7ngdm3Tk1I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type:x-gm-message-state; bh=SSM+OwLt1ExtiepXHGox0UmwnHaZht27c5f4Oi94keo=; b=Sga9QWnUZl596K+Kz3SbpjnfYiYcZiI4kTlWvGJPr2QNPRXQR6yMO4hLecOf4tf+Hv L9geAunDEldFR/74vOwt2fybcZtz2/JVQptqOU4mO8wjX6ESli2EuDr7LRYG/y+8+XD1 aBonIzsw5USdC7n/3vQKAPotj5IN8tE3W0hUlyumvockD9gPwlr7osLhRPO4GGSwP3SM fDQ0r8c01iGwcWYSAKb+WqEVIa+a2wyFkjeGyfgRFrsByb0dcMhLLyeu7Naudv7gUQoE ZTVTAzbw5uYN0p9by/sZu/1fzJDAbknSgL7SJrsO+CoTtgD3LrnRlYIZe4+8DU6gBJYT Bh9Q== MIME-Version: 1.0 X-Received: by 10.180.109.9 with SMTP id ho9mr1522214wib.43.1374244234075; Fri, 19 Jul 2013 07:30:34 -0700 (PDT) Sender: kurta@drkurt.com Received: by 10.194.90.104 with HTTP; Fri, 19 Jul 2013 07:30:34 -0700 (PDT) Date: Fri, 19 Jul 2013 07:30:34 -0700 X-Google-Sender-Auth: pUeGYVdM91jLPVQS2k288zeIRts Message-ID: From: Kurt Andersen To: IETF Apps Discuss Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnDnZ6VFsAsV/9Tx50qelaqK2bCFymRi4fyZ6VUDjfTuwvoWIiX4xtvOrFTGgL47J8GJbAU Subject: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 14:30:41 -0000 On Fri, 19 Jul 2013 07:20:03 -0700, Murray S. Kucherawy wrote: > If an account was created at time T1, then an inquiry as to whether it's > been under continuous ownership since time T0 (for T0 < T1) would be "no". What would the expected response be for a mailbox provider who, for instance, replaced their underlying infrastructure two years ago if they receive an rrvs header that inquires about the continuity of ownership for a time prior to the systems replacement? Their knowledge horizon is limited to two years (in this example), yet the rrvs header might be predicating five years of continuity. --Kurt Andersen From johnl@iecc.com Fri Jul 19 08:30:57 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAC1811E82B5 for ; Fri, 19 Jul 2013 08:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.833 X-Spam-Level: X-Spam-Status: No, score=-110.833 tagged_above=-999 required=5 tests=[AWL=0.366, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7k-2QMsGfK0U for ; Fri, 19 Jul 2013 08:30:53 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 826D711E82CC for ; Fri, 19 Jul 2013 08:30:51 -0700 (PDT) Received: (qmail 71929 invoked from network); 19 Jul 2013 15:30:35 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 19 Jul 2013 15:30:35 -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=51e95b9b.xn--9vv.k1307; i=johnl@user.iecc.com; bh=96qNDKvobIJXph9H73H0s8Cug/kvIs2+4323m09Oz/A=; b=tvhQ3/s4H3Qqmov7v+ToJUekDz/dTgD4A+PH5fVxV6WJOPCAcrRZkA1s3Suq0ShlaB68anACF0/TqgpcXFX7yI9273A5B3sctcJzS4uGOhchigQzlsL+6NvfTp2AZy0/iEjYA9yVcwe1dBfvy7YPAw0VfuTVxtYHRgu8YOPAD3spOP6grkGOgDdNrnNnm6peZwE25bbsPUUQwtWjroi90m/M4SZwQXDC2WbFzRDI0qfcr8bMgxXV7K7TrB5VqIEC 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=51e95b9b.xn--9vv.k1307; olt=johnl@user.iecc.com; bh=96qNDKvobIJXph9H73H0s8Cug/kvIs2+4323m09Oz/A=; b=KRNL2P4VZA1MmQnmqcMXBYv0zqsjs9N+AJBIx8sdSUrhgp6+cC4GjXug43+BO4ZsaiKN9427iEVCFIGtuyqXdCZGE3CIyWsKmGYFj0eDnz+i9Oe4KGqEjcFXwVXeTjJIeGBlsFPssflzaVXJyIqXAXyNXQ9b8ZBksW4a5WNQ17BqvyhFxy1/FUnzE4SNTps09+6EgQL+BqWa05TCbYpjfHqaBztccM3Fanl52huOIi5YlwkIQMglzhV4vSoZodQp Date: 19 Jul 2013 15:30:13 -0000 Message-ID: <20130719153013.18508.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 Subject: Re: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 15:30:58 -0000 >What would the introduction of encryption solve? I think the plan is that the user registers her PGP or S/MIME key with the sender when she signs up, and subsequent mail is encrypted to that key, so if it ends up at the wrong place it doesn't matter because it'll be unreadable. Other than the obvious problem that it's completely impossible to implement due to the usual key distribution issues, and the privacy issues just from knowing that a specific bank or other institution is sending mail to that address, it's a great idea. R's, John From peter@denic.de Fri Jul 19 08:45:09 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC5C11E82C9 for ; Fri, 19 Jul 2013 08:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aze57WMcoLrD for ; Fri, 19 Jul 2013 08:45:08 -0700 (PDT) Received: from office.denic.de (office.denic.de [IPv6:2a02:568:122:16:1::3]) by ietfa.amsl.com (Postfix) with ESMTP id DABB911E82BD for ; Fri, 19 Jul 2013 08:45:05 -0700 (PDT) Received: from x27.adm.denic.de (x28.fra2.if.denic.de [10.122.64.17]) by office.denic.de with esmtp id 1V0Crf-0001b5-8y; Fri, 19 Jul 2013 17:45:03 +0200 Received: from localhost by x27.adm.denic.de with local id 1V0Crf-000604-2w; Fri, 19 Jul 2013 17:45:03 +0200 Date: Fri, 19 Jul 2013 17:45:03 +0200 From: Peter Koch To: IETF Apps Discuss Message-ID: <20130719154503.GE30100@x28.adm.denic.de> Mail-Followup-To: IETF Apps Discuss References: <20130718202939.10687.qmail@joyce.lan> <20130719105146.GA30100@x28.adm.denic.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Subject: Re: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 15:45:09 -0000 On Fri, Jul 19, 2013 at 07:20:03AM -0700, Murray S. Kucherawy wrote: > I don't believe we need to call that out. If an account was created at > time T1, then an inquiry as to whether it's been under continuous ownership > since time T0 (for T0 < T1) would be "no". If the account has been with A and B denoting different "owners" of an account, and this timeline and teh interpretation you just gave, instead of determining the end of A's control, one could indeed find the inception time for B. This is a privacy risk. -----------+-----------+-----------+----------- T0 T1 T2 AAAAAAAAAAAA BBBBBBBBBBBB > deleted, then there's no need to check for an existence or change of > ownership, because the mail won't be delivered anyway regardless of when it > might have been created, reassigned, or deleted. Sure, it doesn't influence the delivery, but it changes the information leak. If you'd instead account the interval between T1 and T2 for B, you might be able to determine the end of A's "ownership". > What would the introduction of encryption solve? To the extent it has solved anything so far, instead of relying upon a (non-)delivery mechanism, for a message destined to A it would conceal the content (not the fact of delivery) from B, provided B didn't inherit the private key from A. How to you envision the signalling for the header processing? X-My-Provider-Supports-RRVS: Yes? -Peter From ned.freed@mrochek.com Fri Jul 19 09:27:36 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53AAF21F8925 for ; Fri, 19 Jul 2013 09:27:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uaPIAiCTZH1a for ; Fri, 19 Jul 2013 09:27:18 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 598AD11E8145 for ; Fri, 19 Jul 2013 09:27:15 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OW6YGZ18F400AL27@mauve.mrochek.com> for apps-discuss@ietf.org; Fri, 19 Jul 2013 09:22:12 -0700 (PDT) MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=iso-8859-1; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OW6SL60ZBK000054@mauve.mrochek.com>; Fri, 19 Jul 2013 09:22:08 -0700 (PDT) Message-id: <01OW6YGX39GU000054@mauve.mrochek.com> Date: Fri, 19 Jul 2013 07:45:49 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 18 Jul 2013 19:53:39 -0400" References: <20130718202939.10687.qmail@joyce.lan> To: John R Levine Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 16:27:36 -0000 I have a lot of problems with this document as it stands. The biggest by far is the apparent lack of any comparison between what's in the header with the current message envelope. Instead the check appears solely to be of the form "if the address in the RRVS field is local, then check to see if the current usage start of that address postdates the timestamp, and if it does refuse delivery to all recipioents, never mind who the recipient(s) actually is(are)". There are many forms of resending and forwarding that preserve top-level header fields, which could easily cause false positives. Indeed, this risk can never be completely eliminated since it is possible that someone might resend an old message containing this header to the *new* owner of an address. (This case calls for a strong recommendation that clients remove this field when doing this sort of forwarding.) But most of the false positives can be mitigated by checking the address in the field against the envelope to make sure the named party actually is a current recipient. This now becomes a question of how to perform that comparison given the possibility of complex forwarding. Specifically, while a match against the actual recipient has the obvious implication that the mechanism is active for that recipient, what about a check against the ORCPT field value? I don't think such a check makes sense, but I could be convinced otherwise. I'll also note that the example you give in section 4 serves as an excellent example of why such a comparison is essential. In that example the actual outcome depends on whether or not A and B are within the same administrative domain. If they are then the result will be to reject the messagen, if they aren't then the receiving MTA at B will see the address in the field as foreign and ignore the field, resulting in successful delivery. This is a major least astonishment principle violation. Checking against current recipients prevents this problem from occurring, and will result in successful delivery in the described case. And I would argue strongly that that's the correct outcome: Once mail hits an address I own what I do with it, and when, is my own damn busines, not yours. I'm willing, albeit grudgingly, to give up some information about the age of the address you're sending to in exchange for some protection against mail you send to me ending up going to the guy in Oregon who wrote "Understanding Business Statistics" and has much curlier hair than I do. (It's quite a good book, BTW.) But knowledge of how I handle my mail after I receive it goes much much much too far. Another thing that needs to be mentioned is use of this facility when an entire domain changes ownership. This is a little more complex than it appears because of the need for addresses like postmaster@domain.com to be immune to ownership changes. But I can see this as being very useful. This document is going to need an explanation for why a header field is being used to communicate to the MTA/MDA rather than defining an SMTP extension, which would be the "correct" architectural choice, not to mention being able to address all the various forwarding issues. (I'm not saying the current choice is wrong, but it needs to be strongly justified.) I also find this paragraph: This header field SHOULD NOT be added to a message that is addressed to multiple recipients. It is presumed that an author making use of this field is seeking to protect transactional or otherwise sensitive data intended for a single recipient. to be more than a little wierd. I send mail all the time to multiple recipients that I really rather not end up going to an unintended recipient. Indeed, I don't really see who the number of recipients correlates well if at all with data sensitivity. I think this whole thing needs to go, especially since envelope checks mostly solve the problems associated with multiple recipients. More generally, this gets into the entire issue of when a client should use this facility. I suppose one way is to have a button you press to request "additional recipient verification" or something like that, but let's face it, users aren't going to have a clue about what this does and therefore aren't going to know when to use it and when not to. The only way this makes sense is to use it automatically when an address comes out of the user's address book. And not having it work when there are muliple recipients will lead to more least astonishment principle violations. There absolutely has to be some text on mitigating failure cases. A user who is effectively blocked from being able to send or receive legitimate mail because of some screwup (e.g., the account got deleted by mistake and then was reinstated with a new creation date) is not going to be a happy camper. And MSPs are not fond of mechanisms that lead to a rise in support calls. And speaking of failures, a new enhanced status code needs to be defined for use when this mechanism bounces mail, and support for NOTARY and ENHANCEDSTATUSCODES needs to be at least a SHOULD for anyone implementing this. I would also suggest having a separate status code for the case of a domain ownership change. > >> For example, let's say I don't like people who use throwaway mail > >> addresses, so whenever someone signs up for an account, I put in an > >> rrvs header in the welcome message to check if the address is less > >> than a week old and if it bounces, demand a different address before I > >> let the user activate the account. > >> > > Aren't those sorts of things merely side effects of what Security > > Considerations already says? I'm sorry, but the notion that a single sentence security considerations section is going to pass muster for a document like this is nothing short of absurd. The consequences of revealing the age of an account need to be elaborated on at least a little bit. The cases where a false negative occurs absolutely are a security concern, and need to be described as well. There should also be some reference to the part about signing these headers. (I view such recommendations as Mostly Harmless, but security folks like them.) > Probably, but I've found it's usually worth some head scratching to ponder > the implications of any new information leak. And this document needs a lot more of it. I've tried to provide the results of some of that here, but this is nowhere near enough. Ned From wmills@yahoo-inc.com Fri Jul 19 10:21:09 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 612F221E80DE for ; Fri, 19 Jul 2013 10:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.098 X-Spam-Level: X-Spam-Status: No, score=-18.098 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9aa4GAGBIJu8 for ; Fri, 19 Jul 2013 10:21:02 -0700 (PDT) Received: from mrout1.yahoo.com (mrout1.yahoo.com [216.145.54.171]) by ietfa.amsl.com (Postfix) with ESMTP id B47B311E80FD for ; Fri, 19 Jul 2013 10:21:01 -0700 (PDT) Received: from GQ1-EX10-CAHT04.y.corp.yahoo.com (gq1-ex10-caht04.corp.gq1.yahoo.com [10.73.118.83]) by mrout1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id r6JHJ7fC010416 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 19 Jul 2013 10:19:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1374254348; bh=lCrMgDRZZiSU3CWIBfhHXDFthsYiuqyWkdzkJgQvBek=; h=References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To: MIME-Version:Content-Type; b=W6qZtT9n9fCTY0OpUJL2I8zjekNIICvxB0rPBmJmEt1lI2l1fZn2oocRclhwG0cL+ s3G1Wvsh3+rFCdt4gNHa4o9qd+Do6cRUhfEuosa5ED2ea6IjTV8/BI7+dPpKrbcV5O 7hQPyw57BjKk2sSpAa7w1KEcBnIUxypU41P4/kaQ= Received: from omp1084.mail.ne1.yahoo.com (98.138.101.173) by GQ1-EX10-CAHT04.y.corp.yahoo.com (10.72.228.24) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 19 Jul 2013 10:19:06 -0700 Received: (qmail 29007 invoked by uid 1000); 19 Jul 2013 17:19:05 -0000 Received: (qmail 31353 invoked by uid 60001); 19 Jul 2013 17:19:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1374254345; bh=M4Iq3zn84Tds6Sfqzt9QFWyZ63hz8HMAYv+OXFd08Ss=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=tZsbwXWqoStzMTTnZe0jpQQpen/ZlKrbu+0kXxGnr71hbQ2X1vXKt4WHLBvyL64gpZQUYuh6bcSQTgwPDnOb5U4DUns5QTka7E+KHwzn3EbIYydBAAJt386ajMOS+choeCO282Ih2Yyn7MGndxfoJCH+iwC+K0JDoaQSHBF2h3U= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=V4PvanZtzUli4TjMZLI2bO7wgjHpj+VYRBYQqDA7OmbRhIwyazdWlt1p1ViAkNbiZnk84gwiEUDo2MtPrI/uONder8m+ovaptYCRKoyqqZwz8zWh5MMA1ECTfAMQ3IiKxD2i8o36QMGLinBgq8WR6b++FFaQJ2rahxUqUYMUN3s=; X-YMail-OSG: 6e8GilEVM1mip0pbp4u.aI5x7.MpbjEWUbiG_UwB8V60d.i Zd26nrzj7RVvpXnrb_..I0X8tsKo3CxJcIvzvsILNJf8Z Received: from [209.131.62.115] by web125604.mail.ne1.yahoo.com via HTTP; Fri, 19 Jul 2013 10:19:04 PDT X-Rocket-MIMEInfo: 002.001, WWVzLCBpdCBpcyBwb3NzaWJsZSB0byBkZXRlcm1pbmUgdGhlIGluY2VwdGlvbiBvZiBCLsKgIFRoZSBzaXRlIG93bmVyIG5lZWRzIHRvIGRldGVybWluZSBpZiB0aGV5IHdhbnQgdG8gZXhwb3NlIHRoaXMgYW5kIHdoZXRoZXIgdGhhdCByaXNrIGlzIGJhbGFuY2VkIGJ5IHRoZSBiZW5lZml0IHRvIEEuCgrCoAotYmlsbAoKCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpXaWxsaWFtIEouIE1pbGxzCiJQYXJhbm9pZCIgWWFob28hCgoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoBMAEBAQE- X-Mailer: YahooMailWebService/0.8.149.560 References: <20130718202939.10687.qmail@joyce.lan> <20130719105146.GA30100@x28.adm.denic.de> <20130719154503.GE30100@x28.adm.denic.de> Message-ID: <1374254344.30364.YahooMailNeo@web125604.mail.ne1.yahoo.com> Date: Fri, 19 Jul 2013 10:19:04 -0700 From: Bill Mills To: Peter Koch , IETF Apps Discuss In-Reply-To: <20130719154503.GE30100@x28.adm.denic.de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-685807438-1497921492-1374254344=:30364" X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 254348000 Subject: Re: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Bill Mills List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 17:21:09 -0000 ---685807438-1497921492-1374254344=:30364 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes, it is possible to determine the inception of B.=A0 The site owner need= s to determine if they want to expose this and whether that risk is balance= d by the benefit to A.=0A=0A=A0=0A-bill=0A=0A=0A=0A------------------------= --------=0AWilliam J. Mills=0A"Paranoid" Yahoo!=0A=0A=0A=0A=0A_____________= ___________________=0A From: Peter Koch =0ATo: IETF Apps Discu= ss =0ASent: Friday, July 19, 2013 8:45 AM=0ASubject= : Re: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00=0A =0A= =0AOn Fri, Jul 19, 2013 at 07:20:03AM -0700, Murray S. Kucherawy wrote:=0A= =0A> I don't believe we need to call that out.=A0 If an account was created= at=0A> time T1, then an inquiry as to whether it's been under continuous o= wnership=0A> since time T0 (for T0 < T1) would be "no".=A0 If the account h= as been=0A=0Awith A and B denoting different "owners" of an account, and th= is timeline=0Aand teh interpretation you just gave, instead of determining = the end of=0AA's control, one could indeed find the inception time for B.= =A0 This is=0Aa privacy risk.=0A=0A-----------+-----------+-----------+----= -------=0A=A0 =A0 =A0 =A0 =A0 T0=A0 =A0 =A0 =A0 =A0 T1=A0 =A0 =A0 =A0 =A0 = T2=A0 =A0 =A0 =A0 =A0 =0A=A0 =A0 =A0 =A0 =A0 AAAAAAAAAAAA=A0 =A0 =A0 =A0 = =A0 =A0 BBBBBBBBBBBB=0A=0A> deleted, then there's no need to check for an e= xistence or change of=0A> ownership, because the mail won't be delivered an= yway regardless of when it=0A> might have been created, reassigned, or dele= ted.=0A=0ASure, it doesn't influence the delivery, but it changes the=0Ainf= ormation leak.=A0 If you'd instead account the interval=0Abetween T1 and T2= for B, you might be able to determine the=0Aend of A's "ownership".=0A=0A>= What would the introduction of encryption solve?=0A=0ATo the extent it has= solved anything so far, instead of relying=0Aupon a (non-)delivery mechani= sm, for a message destined to A=0Ait would conceal the content (not the fac= t of delivery) from B,=0Aprovided B didn't inherit the private key from A.= =0A=0AHow to you envision the signalling for the header processing?=0AX-My-= Provider-Supports-RRVS: Yes?=0A=0A-Peter=0A________________________________= _______________=0Aapps-discuss mailing list=0Aapps-discuss@ietf.org=0Ahttps= ://www.ietf.org/mailman/listinfo/apps-discuss ---685807438-1497921492-1374254344=:30364 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Yes, it i= s possible to determine the inception of B.  The site owner needs to d= etermine if they want to expose this and whether that risk is balanced by t= he benefit to A.
 
-bill


---------------= -----------------
William J. Mills
"Paranoid" Yahoo!

From: Peter Koch <pk@DENIC.DE>
To: IETF Apps Discuss <apps-dis= cuss@ietf.org>
Sent: Friday, July 19, 2013 8:45 AM
= Subject: Re: [apps-discuss] Comments on draft-wmills-rrvs-header= -field-00

On Fri, Jul= 19, 2013 at 07:20:03AM -0700, Murray S. Kucherawy wrote:

> I don= 't believe we need to call that out.  If an account was created at
= > time T1, then an inquiry as to whether it's been under continuous owne= rship
> since time T0 (for T0 < T1) would be "no".  If the ac= count has been

with A and B denoting different "owners" of an accoun= t, and this timeline
and teh interpretation you just gave, instead of de= termining the end of
A's control, one could indeed find the inception ti= me for B.  This is
a privacy risk.

-----------+-----------+-----------+-----------
  &nb= sp;       T0          T1  &nb= sp;       T2         
  &n= bsp;       AAAAAAAAAAAA          &= nbsp; BBBBBBBBBBBB

> deleted, then there's no need to check for a= n existence or change of
> ownership, because the mail won't be deliv= ered anyway regardless of when it
> might have been created, reassign= ed, or deleted.

Sure, it doesn't influence the delivery, but it chan= ges the
information leak.  If you'd instead account the intervalbetween T1 and T2 for B, you might be able to determine the
end of A's = "ownership".

> What would the introduction of encryption solve?
To the extent it has solved anything so far, instead of relying
up= on a (non-)delivery mechanism, for a message destined to A
it would conceal the content (not the fact of delivery) from B,
provided B= didn't inherit the private key from A.

How to you envision the sign= alling for the header processing?
X-My-Provider-Supports-RRVS: Yes?
<= br>-Peter
_______________________________________________
apps-discus= s mailing list
apps-discuss@ietf.org
https://www.iet= f.org/mailman/listinfo/apps-discuss


---685807438-1497921492-1374254344=:30364-- From wmills@yahoo-inc.com Fri Jul 19 10:57:26 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B925E21E80B6 for ; Fri, 19 Jul 2013 10:57:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.765 X-Spam-Level: X-Spam-Status: No, score=-17.765 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ef01KAqdml9U for ; Fri, 19 Jul 2013 10:57:22 -0700 (PDT) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by ietfa.amsl.com (Postfix) with ESMTP id 95D5E11E80E3 for ; Fri, 19 Jul 2013 10:57:21 -0700 (PDT) Received: from BF1-EX10-CAHT06.y.corp.yahoo.com (bf1-ex10-caht06.corp.bf1.yahoo.com [10.74.209.238]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id r6JHuEkk021987 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 19 Jul 2013 10:56:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1374256574; bh=l1JAzx/zmr7KKSqFZiR80y5Y2qVh0CUuFv6raqwqwYc=; h=References:Message-ID:Date:From:Reply-To:Subject:To:CC: In-Reply-To:MIME-Version:Content-Type; b=ocQ+JXIe168VY43mnMmzWMV9waTMyiAYFnBfvIvUsvoWQVg6ErC0nrAQkJfYmEu0Z Pfmur6pcAtlZADzW6okHfcU7L/KH1WCegZRE5zPFJDidrq3F5e2STJ6eli4GsnUkbR 7XZLejsYxf+iNgiFInDz1iIsRKcldiz5s1mZY7qs= Received: from omp1091.mail.ne1.yahoo.com (98.138.101.180) by BF1-EX10-CAHT06.y.corp.yahoo.com (10.74.209.170) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 19 Jul 2013 13:56:13 -0400 Received: (qmail 55605 invoked by uid 1000); 19 Jul 2013 17:56:13 -0000 Received: (qmail 11906 invoked by uid 60001); 19 Jul 2013 17:56:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1374256573; bh=uyiKvcXPF/A/tv7yP0rnXiV15dhFOkioFOOLoLaVRQU=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=KawJK1+CSPofzJaYikkzyijQMZH3W+r+G1QioPqQL3rFXVKTnFfMkyXzvxnf/YBYFKJrGp1m64S4HCyyw4ayBHi9Yh8pcSSR3A1UtXr6OMqwzmVNpOZaHrTxWqUVjLaQqmp7WTbFueOOer0OXDNTxiS6I49eJtUB1S1Xl3A/r7k= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=dGGChoXB6UgDtgL6G5hFoIAx0yHdUPC5TUGuiI8pe9LBX/y4X1lTa1ylfjKotbQcJ6w6+G5jfauCG2KquuhMM27bMtDyNvdFsllK9pxolARLTyz4+o8M/Lyw4hD165/puXMriUEmWWuYIb9pw5LmaFz0RqRaFWxEJth14tqF2iU=; X-YMail-OSG: j54GX0wVM1kKz_wMrnoh12dNTpg71IVYA32sFBZfkC7mCit 7qPYMfdy9RYgyq5ptN3ub3BvSY47j5DfNkYFvK1p3pHKMiCfI6xtmrrmp1QZ cmfpK73KXTJWhl_ZYFsLMps2y36.9wLdiy7V9hTMu63RAVrImuSNp8hrqG4W OCj7gEWNxdKUCJexCmDg5rvYunCuvzY0B34g5O1yFSAYdPZ04XPPFBX8BUiP x.8sw.pw82ewCxPQePbh25is2sHvqliwh7BoZvnxlvaVGU9ahWUvAWae.l1p FLEBrDiatoKyYDLNiMclNpMB8on5g Received: from [209.131.62.115] by web125601.mail.ne1.yahoo.com via HTTP; Fri, 19 Jul 2013 10:56:12 PDT X-Rocket-MIMEInfo: 002.001, LSBtYXRjaGluZyBuYW1lIGluIHJydnMgdG8gdGhlIGVudmVsb3BlLgoKQSBzZW5kcyB0byBCIHdobyBoYXMgZm9yd2FyZGVkIHRvIEMuwqAgVGhpcyBuZWVkcyB0byBiZSBhcHBsaWVkIGF0IHRoZSBNVEEgaGFuZGxpbmcgQiwgdGhhdCdzIHdoYXQgd2Ugd2VyZSB0cnlpbmcgdG8gc29sdmUgaGVyZS7CoCBDb21wYXJpbmcgdG8gdGhlIG9yaWdpbmFsIGVudmVsb3BlIHNlZW1zIHVzZWZ1bCBmb3IgY29uZmlybWluZyB2YWxpZGl0eSBvZiB0aGUgaGVhZGVyIGl0c2VsZiwgYnV0IEkgZG9uJ3Qgc2VlIG11Y2ggdXQBMAEBAQE- X-Mailer: YahooMailWebService/0.8.149.560 References: <20130718202939.10687.qmail@joyce.lan> <01OW6YGX39GU000054@mauve.mrochek.com> Message-ID: <1374256572.96704.YahooMailNeo@web125601.mail.ne1.yahoo.com> Date: Fri, 19 Jul 2013 10:56:12 -0700 From: Bill Mills To: Ned Freed , John R Levine In-Reply-To: <01OW6YGX39GU000054@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1981468715-1303394165-1374256572=:96704" X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 256574002 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Bill Mills List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 17:57:26 -0000 ---1981468715-1303394165-1374256572=:96704 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable - matching name in rrvs to the envelope.=0A=0AA sends to B who has forwarde= d to C.=A0 This needs to be applied at the MTA handling B, that's what we w= ere trying to solve here.=A0 Comparing to the original envelope seems usefu= l for confirming validity of the header itself, but I don't see much utilit= y beyond that.=A0 Am I missing something?=0A=0A=0A- resending clients shoul= d strip the header=0A=0ASeems fair.=0A=0A- multiple recipients.=0A=0AThis s= tarts to get a LOT hairier if we have to do a multi-valued rrvs header, and= it's not the problem we're trying to solve right now.=A0 So we might allow= multiple rrvs headersto solve this?=A0 Each one needing to apply to a reci= pient in the envelope?=0A=0A=0A- forwarding=0A=0AThe sender has no informat= ion on how delivery will happen, forwarding is a form of delivery in this u= se case, and once you're forwarding RRVS should never apply.=A0 =0A=0A=0A- = enhanced status codes=0A=0Awhy do we need a new one?=A0 X.1.6 seems to fit = well?=0A=0A=0A- domain ownership change=0A=0AA fair point.=A0 A different e= rror return could be useful here.=A0 Another way to do this would be to hav= e an RRVS SMTP extension that advertises domains and the length of ownershi= p.=A0 Needs more thought.=0A=0A=0A- security considerations=0A=0ACan be ful= ler, sure.=A0 Got text?=0A=0A=0A- false negatives=0A=0AMeaning if a provide= r incorrectly rejects mail?=A0 Is this significantly different from the imp= act of current failures to delver when a DB lookup fails and you get a "no = such user" when you know it exists?=0A=0A=0A=0A-bill=0A=0A=0A=0A___________= _____________________=0AFrom: Ned Freed =0ATo: John = R Levine =0ACc: IETF Apps Discuss = =0ASent: Friday, July 19, 2013 7:45 AM=0ASubject: Re: [apps-discuss] Comme= nts on draft-wmills-rrvs-header-field-00=0A=0A=0AI have a lot of problems w= ith this document as it stands.=0A=0AThe biggest by far is the apparent lac= k of any comparison between what's in the=0Aheader with the current message= envelope. Instead the check appears solely to=0Abe of the form "if the add= ress in the RRVS field is local, then check to see if=0Athe current usage s= tart of that address postdates the timestamp, and if it does=0Arefuse deliv= ery to all recipioents, never mind who the recipient(s) actually=0Ais(are)"= .=0A=0AThere are many forms of resending and forwarding that preserve top-l= evel header=0Afields, which could easily cause false positives. Indeed, thi= s risk can never=0Abe completely eliminated since it is possible that someo= ne might resend an old=0Amessage containing this header to the *new* owner = of an address. (This case=0Acalls for a strong recommendation that clients = remove this field when doing=0Athis sort of forwarding.) But most of the fa= lse positives can be mitigated by=0Achecking the address in the field again= st the envelope to make sure the named=0Aparty actually is a current recipi= ent.=0A=0AThis now becomes a question of how to perform that comparison giv= en the=0Apossibility of complex forwarding. Specifically, while a match aga= inst the=0Aactual recipient has the obvious implication that the mechanism = is active for=0Athat recipient, what about a check against the ORCPT field = value? I don't think=0Asuch a check makes sense, but I could be convinced o= therwise.=0A=0AI'll also note that the example you give in section 4 serves= as an excellent=0Aexample of why such a comparison is essential. In that e= xample the actual=0Aoutcome depends on whether or not A and B are within th= e same administrative=0Adomain. If they are then the result will be to reje= ct the messagen, if they=0Aaren't then the receiving MTA at B will see the = address in the field as foreign=0Aand ignore the field, resulting in succes= sful delivery. This is a major least=0Aastonishment principle violation.=0A= =0AChecking against current recipients prevents this problem from occurring= , and=0Awill result in successful delivery in the described case. And I wou= ld argue=0Astrongly that that's the correct outcome: Once mail hits an addr= ess I own what=0AI do with it, and when, is my own damn busines, not yours.= I'm willing, albeit=0Agrudgingly, to give up some information about the ag= e of the address you're=0Asending to in exchange for some protection agains= t mail you send to me ending=0Aup going to the guy in Oregon who wrote "Und= erstanding Business Statistics" and=0Ahas much curlier hair than I do. (It'= s quite a good book, BTW.) But knowledge=0Aof how I handle my mail after I = receive it goes much much much too far.=0A=0AAnother thing that needs to be= mentioned is use of this facility when=0Aan entire domain changes ownershi= p. This is a little more complex than=0Ait appears because of the need for = addresses like postmaster@domain.com=0Ato be immune to ownership changes. B= ut I can see this as being very useful.=0A=0AThis document is going to need= an explanation for why a header field is being=0Aused to communicate to th= e MTA/MDA rather than defining an SMTP extension,=0Awhich would be the "cor= rect" architectural choice, not to mention being able to=0Aaddress all the = various forwarding issues.=A0 (I'm not saying the current choice=0Ais wrong= , but it needs to be strongly justified.)=0A=0AI also find this paragraph:= =0A=0A=A0=A0=A0This header field SHOULD NOT be added to a message that is a= ddressed=0A=A0=A0=A0to multiple recipients.=A0 It is presumed that an autho= r making use of=0A=A0=A0=A0this field is seeking to protect transactional o= r otherwise sensitive=0A=A0=A0=A0data intended for a single recipient.=0A= =0Ato be more than a little wierd. I send mail all the time to multiple rec= ipients=0Athat I really rather not end up going to an unintended recipient.= Indeed, I=0Adon't really see who the number of recipients correlates well = if at all with=0Adata sensitivity. I think this whole thing needs to go, es= pecially since=0Aenvelope checks mostly solve the problems associated with = multiple recipients.=0A=0AMore generally, this gets into the entire issue o= f when a client should use=0Athis facility. I suppose one way is to have a = button you press to request=0A"additional recipient verification" or someth= ing like that, but let's face it,=0Ausers aren't going to have a clue about= what this does and therefore aren't=0Agoing to know when to use it and whe= n not to. The only way this makes sense is=0Ato use it automatically when a= n address comes out of the user's address book.=0AAnd not having it work wh= en there are muliple recipients will lead to more=0Aleast astonishment prin= ciple violations.=0A=0AThere absolutely has to be some text on mitigating f= ailure cases. A user who is=0Aeffectively blocked from being able to send o= r receive legitimate mail because=0Aof some screwup (e.g., the account got = deleted by mistake and then was=0Areinstated with a new creation date) is n= ot going to be a happy camper. And=0AMSPs are not fond of mechanisms that l= ead to a rise in support calls.=0A=0AAnd speaking of failures, a new enhanc= ed status code needs to be defined for=0Ause when this mechanism bounces ma= il, and support for NOTARY and=0AENHANCEDSTATUSCODES needs to be at least a= SHOULD for anyone implementing this.=0AI would also suggest having a separ= ate status code for the case of a domain=0Aownership change.=0A=0A> >> For = example, let's say I don't like people who use throwaway mail=0A> >> addres= ses, so whenever someone signs up for an account, I put in an=0A> >> rrvs h= eader in the welcome message to check if the address is less=0A> >> than a = week old and if it bounces, demand a different address before I=0A> >> let = the user activate the account.=0A> >>=0A> > Aren't those sorts of things me= rely side effects of what Security=0A> > Considerations already says?=0A=0A= I'm sorry, but the notion that a single sentence security considerations=0A= section is going to pass muster for a document like this is nothing short= =0Aof absurd. The consequences of revealing the age of an account need to= =0Abe elaborated on at least a little bit.=0A=0AThe cases where a false neg= ative occurs absolutely are a security concern,=0Aand need to be described = as well.=0A=0AThere should also be some reference to the part about signing= these headers. (I=0Aview such recommendations as Mostly Harmless, but secu= rity folks like them.)=0A=0A> Probably, but I've found it's usually worth s= ome head scratching to ponder=0A> the implications of any new information l= eak.=0A=0AAnd this document needs a lot more of it. I've tried to provide t= he results of=0Asome of that here, but this is nowhere near enough.=0A=0A= =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 Ned=0A_____________________________= __________________=0Aapps-discuss mailing list=0Aapps-discuss@ietf.org=0Aht= tps://www.ietf.org/mailman/listinfo/apps-discuss=A0 ---1981468715-1303394165-1374256572=:96704 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
- ma= tching name in rrvs to the envelope.

A = sends to B who has forwarded to C.  This needs to be applied at the MT= A handling B, that's what we were trying to solve here.  Comparing to = the original envelope seems useful for confirming validity of the header it= self, but I don't see much utility beyond that.  Am I missing somethin= g?

- resending clients should strip= the header

Seems fai= r.

- multiple recipients.

This starts to get a L= OT hairier if we have to do a multi-valued rrvs header, and it's not the pr= oblem we're trying to solve right now.  So we might allow multiple rrv= s headers to solve this?  Each one needing to apply to a recipient in = the envelope?

- forwardi= ng

The sender has no info= rmation on how delivery will happen, forwarding is a form of delivery in th= is use case, and once you're forwarding RRVS should never apply. 
=

- enhanced status codes

why do we need a new one?  X.1.6 seems to fit well?


= A fair point.  A different error return could be useful here.  An= other way to do this would be to have an RRVS SMTP extension that advertise= s domains and the length of ownership.  Needs more thought.

- security considerations=

Can be fuller, sure.  Got text?

- false negatives

Meaning if a provider incor= rectly rejects mail?  Is this significantly different from the impact = of current failures to delver when a DB lookup fails and you get a "no such= user" when you know it exists?


-bill



________________________________
From:= Ned Freed <ned.freed@mrochek.com>
To: John R Levine <johnl@tau= gh.com>
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Sent: Friday, July 19, 2013 7:45 AM
Subject: Re: [apps-discuss] Com= ments on draft-wmills-rrvs-header-field-00


I have a lot of probl= ems with this document as it stands.

The biggest by far is the appar= ent lack of any comparison between what's in the
header with the current= message envelope. Instead the check appears solely to
be of the form "i= f the address in the RRVS field is local, then check to see if
the curre= nt usage start of that address postdates the timestamp, and if it does
r= efuse delivery to all recipioents, never mind who the recipient(s) actually=
is(are)".

There are many forms of resending and forwarding that = preserve top-level header
fields, which could easily cause false positiv= es. Indeed, this risk can never
be completely eliminated since it is pos= sible that someone might resend an old
message containing this header to= the *new* owner of an address. (This case
calls for a strong recommendation that clients remove this field when doing
this sort of f= orwarding.) But most of the false positives can be mitigated by
checking= the address in the field against the envelope to make sure the named
pa= rty actually is a current recipient.

This now becomes a question of = how to perform that comparison given the
possibility of complex forwardi= ng. Specifically, while a match against the
actual recipient has the obv= ious implication that the mechanism is active for
that recipient, what a= bout a check against the ORCPT field value? I don't think
such a check m= akes sense, but I could be convinced otherwise.

I'll also note that = the example you give in section 4 serves as an excellent
example of why = such a comparison is essential. In that example the actual
outcome depen= ds on whether or not A and B are within the same administrative
domain. = If they are then the result will be to reject the messagen, if they
aren't then the receiving MTA at B will see the address in the fie= ld as foreign
and ignore the field, resulting in successful delivery. Th= is is a major least
astonishment principle violation.

Checking ag= ainst current recipients prevents this problem from occurring, and
will = result in successful delivery in the described case. And I would argue
s= trongly that that's the correct outcome: Once mail hits an address I own wh= at
I do with it, and when, is my own damn busines, not yours. I'm willin= g, albeit
grudgingly, to give up some information about the age of the a= ddress you're
sending to in exchange for some protection against mail yo= u send to me ending
up going to the guy in Oregon who wrote "Understandi= ng Business Statistics" and
has much curlier hair than I do. (It's quite= a good book, BTW.) But knowledge
of how I handle my mail after I receiv= e it goes much much much too far.

Another thing that needs to be mentioned is use of this facility when
an entire domain changes owne= rship. This is a little more complex than
it appears because of the need= for addresses like postmaster@domain.com
to be immune to ownership chan= ges. But I can see this as being very useful.

This document is going= to need an explanation for why a header field is being
used to communic= ate to the MTA/MDA rather than defining an SMTP extension,
which would b= e the "correct" architectural choice, not to mention being able to
addre= ss all the various forwarding issues.  (I'm not saying the current cho= ice
is wrong, but it needs to be strongly justified.)

I also find= this paragraph:

   This header field SHOULD NOT be a= dded to a message that is addressed
   to multiple recipi= ents.  It is presumed that an author making use of
  &nbs= p;this field is seeking to protect transactional or otherwise sensitive
   data intended for a single recipient.
to be more than a little wierd. I send mail all the time to multiple reci= pients
that I really rather not end up going to an unintended recipient.= Indeed, I
don't really see who the number of recipients correlates well= if at all with
data sensitivity. I think this whole thing needs to go, = especially since
envelope checks mostly solve the problems associated wi= th multiple recipients.

More generally, this gets into the entire is= sue of when a client should use
this facility. I suppose one way is to h= ave a button you press to request
"additional recipient verification" or= something like that, but let's face it,
users aren't going to have a cl= ue about what this does and therefore aren't
going to know when to use i= t and when not to. The only way this makes sense is
to use it automatica= lly when an address comes out of the user's address book.
And not having it work when there are muliple recipients will lead to more
leas= t astonishment principle violations.

There absolutely has to be some= text on mitigating failure cases. A user who is
effectively blocked fro= m being able to send or receive legitimate mail because
of some screwup = (e.g., the account got deleted by mistake and then was
reinstated with a= new creation date) is not going to be a happy camper. And
MSPs are not = fond of mechanisms that lead to a rise in support calls.

And speakin= g of failures, a new enhanced status code needs to be defined for
use wh= en this mechanism bounces mail, and support for NOTARY and
ENHANCEDSTATU= SCODES needs to be at least a SHOULD for anyone implementing this.
I wou= ld also suggest having a separate status code for the case of a domain
o= wnership change.

> >> For example, let's say I don't like p= eople who use throwaway mail
> >> addresses, so whenever someone signs up for an account, I put in an
> >> rrvs header = in the welcome message to check if the address is less
> >> tha= n a week old and if it bounces, demand a different address before I
>= >> let the user activate the account.
> >>
> > = Aren't those sorts of things merely side effects of what Security
> &= gt; Considerations already says?

I'm sorry, but the notion that a si= ngle sentence security considerations
section is going to pass muster fo= r a document like this is nothing short
of absurd. The consequences of r= evealing the age of an account need to
be elaborated on at least a littl= e bit.

The cases where a false negative occurs absolutely are a secu= rity concern,
and need to be described as well.

There should also= be some reference to the part about signing these headers. (I
view such= recommendations as Mostly Harmless, but security folks like them.)

> Probably, but I've found it's usually worth some head s= cratching to ponder
> the implications of any new information leak.
And this document needs a lot more of it. I've tried to provide the r= esults of
some of that here, but this is nowhere near enough.

&nb= sp;               Ne= d
_______________________________________________
apps-discuss mailin= g list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listi= nfo/apps-discuss
 
---1981468715-1303394165-1374256572=:96704-- From superuser@gmail.com Fri Jul 19 11:48:31 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C500111E816E for ; Fri, 19 Jul 2013 11:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mocsm-5OPSDi for ; Fri, 19 Jul 2013 11:48:31 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id DDFDC11E8145 for ; Fri, 19 Jul 2013 11:48:30 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id m19so4165305wev.8 for ; Fri, 19 Jul 2013 11:48:30 -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=7WWH7BVFhn9tkcjDROahE+ZFduDM+R2lcvjwhMOUR2c=; b=tvvSc4L+JKw7/vIWyx0IOxwbOZ3GsTccggu7GrDKrNHUcS/P3zuBVXIzqMRnSBeyU6 C9Q9NiSPLWgkTfjdqF3O5QeZWyNOdNKS2tU/VWPRyTLN9Gt8zitndJT6FVNlf6Oi1qV5 GNObgvd5yTH3RbLKYQc5w5EsGT0HWWS5rKu5GKPu+MQMPUkQtKVprU30uW2v3ur5P+Ir aCCyIT6mwM8jjd73DgoKg7TZ0xgWtMVAJgfFeIgjZ0LysB73ODdkfUGRF+XgNCOJ/y1X DCiIrci12YerBJbr+Y1+2OsiTD6h2au/xLVnmxXdVOjlPuiTdN5F4gAfmOiX6SSGQXwL XjCQ== MIME-Version: 1.0 X-Received: by 10.194.122.71 with SMTP id lq7mr12850976wjb.77.1374259709949; Fri, 19 Jul 2013 11:48:29 -0700 (PDT) Received: by 10.180.90.16 with HTTP; Fri, 19 Jul 2013 11:48:29 -0700 (PDT) Date: Fri, 19 Jul 2013 11:48:29 -0700 Message-ID: From: "Murray S. Kucherawy" To: draft-sullivan-domain-policy-authority@tools.ietf.org, IETF Apps Discuss Content-Type: multipart/alternative; boundary=089e01229750d73ddb04e1e1c5aa Subject: [apps-discuss] Comments on draft-sullivan-domain-policy-authority X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jul 2013 18:48:31 -0000 --089e01229750d73ddb04e1e1c5aa Content-Type: text/plain; charset=ISO-8859-1 As someone who's involved in email authentication work, identifying the apex of authority given an arbitrary domain name has long been a valuable goal. The current way to do this (the public suffix list) is undesirable, but it's currently the only way to do this. This draft proposes a new solution to this problem and also takes into scope several other related problem statements. It does a very good job describing the problem spaces and also is very up front of its various (and in a couple of cases, daunting) limitations. I'd love to be part of a conversation that talks about how to mitigate some or all of those. One thing it doesn't mention is that it will require a SOPA record to be created at every extant node in the DNS tree for a domain that wishes to make use of it. Unless I've misread something, the document does indicate that a node can indicate it is in the same policy realm as all of its descendants, but it also says this relationship needs to be confirmed to be believed. That means all of the descendant nodes also have to have SOPA records pointing back to that parent node. If I'm understanding that correctly, the document should probably call this out as a constraint as well. There's another related document, draft-levine-orgboundary, about which I'll comment separately. I wonder, though, since we have time on the APPSAWG/APPAREA agenda, if the authors of both drafts would be interested in talking to that audience about their ideas in Berlin. -MSK --089e01229750d73ddb04e1e1c5aa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
As someone who's involved in email= authentication work, identifying the apex of authority given an arbitrary = domain name has long been a valuable goal.=A0 The current way to do this (t= he public suffix list) is undesirable, but it's currently the only way = to do this.

This draft proposes a new solution to this problem and also takes= into scope several other related problem statements.=A0 It does a very goo= d job describing the problem spaces and also is very up front of its variou= s (and in a couple of cases, daunting) limitations.=A0 I'd love to be p= art of a conversation that talks about how to mitigate some or all of those= .

One thing it doesn't mention is that it will require a SOPA r= ecord to be created at every extant node in the DNS tree for a domain that = wishes to make use of it.=A0 Unless I've misread something, the documen= t does indicate that a node can indicate it is in the same policy realm as = all of its descendants, but it also says this relationship needs to be conf= irmed to be believed.=A0 That means all of the descendant nodes also have t= o have SOPA records pointing back to that parent node.=A0 If I'm unders= tanding that correctly, the document should probably call this out as a con= straint as well.

There's another related document, draft-levine-orgboundary, a= bout which I'll comment separately.=A0 I wonder, though, since we have = time on the APPSAWG/APPAREA agenda, if the authors of both drafts would be = interested in talking to that audience about their ideas in Berlin.

-MSK
--089e01229750d73ddb04e1e1c5aa-- From superuser@gmail.com Fri Jul 19 11:49:44 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE3AD11E81A2 for ; Fri, 19 Jul 2013 11:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z+gdH7-INnLo for ; Fri, 19 Jul 2013 11:49:44 -0700 (PDT) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB7C11E81A0 for ; Fri, 19 Jul 2013 11:49:40 -0700 (PDT) Received: by mail-wg0-f53.google.com with SMTP id y10so4331696wgg.20 for ; Fri, 19 Jul 2013 11:49:39 -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=zY1Noo6eTAnvNRihtPVwtBwMwF2HUX8pf7ciknTq8Pw=; b=DhmlCgDuxdcRYIVYzOnFBgAIbcpfQI3Jtk3Bn/SPAfkNM5/vs+ZqhKDcP0mIX8Wnwz VmlrAYDpx3h3wdF69nOFX70NKrXtfZTm09ljmSHH77MYS3j+DxgucOgnPVnEzj04Udwh +RLr+K5uKdRbVeBiVbUawShMZ5cbkKsoirducdGGxYD6QcwBPuWRA0drp/h9yWCtiCCN orKV0TfiYWQssO8o8aRsLYLUByngdzxEB9B4L98F/l3K9IgRvfBdPf3LTh0jFIExdof2 i5rxufOl1XferRhbb8D4BtFPXQPM70bO93LK7gkq6PUyGbGs/DZQubX1l7NZz9nSt84v Me2Q== MIME-Version: 1.0 X-Received: by 10.194.239.225 with SMTP id vv1mr13084954wjc.63.1374259779550; Fri, 19 Jul 2013 11:49:39 -0700 (PDT) Received: by 10.180.90.16 with HTTP; Fri, 19 Jul 2013 11:49:39 -0700 (PDT) In-Reply-To: References: Date: Fri, 19 Jul 2013 11:49:39 -0700 Message-ID: From: "Murray S. Kucherawy" To: Kurt Andersen Content-Type: multipart/alternative; boundary=089e01493384fd47fb04e1e1c906 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 18:49:45 -0000 --089e01493384fd47fb04e1e1c906 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jul 19, 2013 at 7:30 AM, Kurt Andersen wrote: > > If an account was created at time T1, then an inquiry as to whether it's > > been under continuous ownership since time T0 (for T0 < T1) would be > "no". > > What would the expected response be for a mailbox provider who, for > instance, replaced their underlying infrastructure two years ago if > they receive an rrvs header that inquires about the continuity of > ownership for a time prior to the systems replacement? Their knowledge > horizon is limited to two years (in this example), yet the rrvs header > might be predicating five years of continuity. > > > Good question. I would say that a participating receiver should reject such a message; the author is asserting that the content of the message is unsafe to deliver unless continuous ownership can be confirmed, for the sake of protecting one of its users. In the case you described, such confirmation isn't possible. Such an operator might also want to consider not participating at all. What do others think? -MSK --089e01493384fd47fb04e1e1c906 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Jul 19, 2013 at 7:30 AM, Kurt Andersen <kboth@dr= kurt.com> wrote:
> If an account was created at time T1, t= hen an inquiry as to whether it's
> been under continuous ownership since time T0 (for T0 < T1) would b= e "no".

What would the expected response be for a mailbox provider who, for
instance, replaced their underlying infrastructure two years ago if
they receive an rrvs header that inquires about the continuity of
ownership for a time prior to the systems replacement? Their knowledge
horizon is limited to two years (in this example), yet the rrvs header
might be predicating five years of continuity.



Good question.=A0 I would say that a participati= ng receiver should reject such a message; the author is asserting that the = content of the message is unsafe to deliver unless continuous ownership can= be confirmed, for the sake of protecting one of its users.=A0 In the case = you described, such confirmation isn't possible.

Such an operator might also want to consider not participati= ng at all.

What do others think?

-MSK

--089e01493384fd47fb04e1e1c906-- From johnl@iecc.com Fri Jul 19 11:54:35 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF4AB21F9644 for ; Fri, 19 Jul 2013 11:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.839 X-Spam-Level: X-Spam-Status: No, score=-110.839 tagged_above=-999 required=5 tests=[AWL=0.360, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XRUG5pQmnyvF for ; Fri, 19 Jul 2013 11:54:30 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id C7B1A11E8193 for ; Fri, 19 Jul 2013 11:54:27 -0700 (PDT) Received: (qmail 23302 invoked from network); 19 Jul 2013 18:54:26 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 19 Jul 2013 18:54:26 -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=51e98b62.xn--3zv.k1307; i=johnl@user.iecc.com; bh=/L3Z7zV1wW/Z/gECwjVEg1k/as0u7VqRZGw6hT0l9V8=; b=rxZmxLTYz/CDbQJqCKPTU7zi9tZDdUUVKUYgXlHpUx8lRjL4knFiZwpvEAFL9MyrTCkbM9nEgspmBIh/GjisePWRDIyFRkrvVqs5akO/1gwKE/tsAfVuj3EFUBfv+yJGxn3IZbUHgTAlSRypa6lYTW9/kvD1jjdC4U12M1OL+DmuDuZaDrFTCW9N/no1fZAbjZPyQlbClIo8FLmZvQ14sLbJBWLajfw0rNPEFfjug7kcl7YJl0r2Z8W6CfUgCqZY 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=51e98b62.xn--3zv.k1307; olt=johnl@user.iecc.com; bh=/L3Z7zV1wW/Z/gECwjVEg1k/as0u7VqRZGw6hT0l9V8=; b=mfjhWLqZheC23G3cf4SxyqOOpG9nzsCXIAY5ZOJyCooNmCyEkMdcdoUTFubM8/8vg9EHzAb+BwxUXCkoA5oEGPnByJuvpReblTYnlcWVxugHe9bP+is6BiQUEGqzQPezAJ9pgz3c+TuyXBR7W7GpQIqhkWXyO9XM7V/U5fXG9G83kMgjXs17ae+0G2Mj2uWHOHby1BP4ZzrXVobIzDdKnqh70P4Bq/w0hLkf3oAeIKp/jVlJPcfaNWOeoZclHNjY Date: 19 Jul 2013 18:54:03 -0000 Message-ID: <20130719185403.19505.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <1374254344.30364.YahooMailNeo@web125604.mail.ne1.yahoo.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 18:54:35 -0000 >Yes, it is possible to determine the inception of B.  The site owner >needs to determine if they want to expose this and whether that risk is >balanced by the benefit to A. You could return a random answer for queries for times between the end of A and the beginning of B without, as far as I can see, affecting the utility for the indended question of "is this still the same person who signed up." Still scratching my head, though. R's, John From paul.hoffman@vpnc.org Fri Jul 19 12:01:14 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA2F821F9FE4 for ; Fri, 19 Jul 2013 12:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jZZ6nPkPQUS6 for ; Fri, 19 Jul 2013 12:01:13 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id EDA9E11E82B5 for ; Fri, 19 Jul 2013 12:00:55 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-228.dsl.dynamic.sonic.net [50.1.98.228]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.5) with ESMTP id r6JJ0nKe053204 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 19 Jul 2013 12:00:50 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-228.dsl.dynamic.sonic.net [50.1.98.228] claimed to be [10.20.30.90] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: Date: Fri, 19 Jul 2013 12:00:49 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <44FD8AFC-7865-43D4-9CA2-53EFC77AFDAE@vpnc.org> References: To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.1508) Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Comments on draft-sullivan-domain-policy-authority X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jul 2013 19:01:15 -0000 On Jul 19, 2013, at 11:48 AM, Murray S. Kucherawy = wrote: > There's another related document, draft-levine-orgboundary, about = which I'll comment separately. I wonder, though, since we have time on = the APPSAWG/APPAREA agenda, if the authors of both drafts would be = interested in talking to that audience about their ideas in Berlin. +1. Fortunately, both authors will be in Berlin. --Paul Hoffman= From johnl@iecc.com Fri Jul 19 12:08:07 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C57CA11E8197 for ; Fri, 19 Jul 2013 12:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.845 X-Spam-Level: X-Spam-Status: No, score=-110.845 tagged_above=-999 required=5 tests=[AWL=0.354, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5jqtSMm0hqN5 for ; Fri, 19 Jul 2013 12:08:03 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 21F2B11E8193 for ; Fri, 19 Jul 2013 12:08:02 -0700 (PDT) Received: (qmail 26811 invoked from network); 19 Jul 2013 19:08:02 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 19 Jul 2013 19:08:02 -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=51e98e92.xn--30v786c.k1307; i=johnl@user.iecc.com; bh=ceXypNkgHIm/uq0e6B1YRycPzVxLQV1PmawRGkaLe/s=; b=uQPDT0nZ1AwXJuhSXzQ+48OPPw74Ka55Mpl6qwRFkB1rl7nX0UMBHttMPOP7U+nq1gPhBVP3IyjZeUE0bW45YxSPOnsQviDO0oWKjasDN7KcXcv5tSUixA5SL4pcmPwESN1WkLFjSrGHSjpXw5ScilVNcLWNC4qdzTsPD1Do1u9taEMkz6HKufe/We5LIGUDpI0ajRsSHip5JV6aQgvTLxiPGb6eqktKgvtXrVuaOmTMb7jWLm1zTsak+93zEXTu 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=51e98e92.xn--30v786c.k1307; olt=johnl@user.iecc.com; bh=ceXypNkgHIm/uq0e6B1YRycPzVxLQV1PmawRGkaLe/s=; b=LYhnu6UWlV0zfqitoV1vNjxGkxpboCSlOs1lcYY2stufwNKca7StC0iUXjvSX//EL1yTzvr06xU/+mXTwAk4YW7zPprUNz419/zCb96EDjMzXw8jDtZQXDZ7p+Kup/VydtHjloSSD2Uy5ZgMk/54BT0HnCcwuj7S206EfYH0hevzGshZgFeJ0fV1tRNbJ7YHH0PKrdT1hjS8685if1lQxchF9bW/yBoDXivCb077aya6BLBFyhXHMUEFxE5Uc+CR Date: 19 Jul 2013 19:07:40 -0000 Message-ID: <20130719190740.19587.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 Subject: Re: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 19:08:07 -0000 >Such an operator might also want to consider not participating at all. > >What do others think? Seems to me that if I'm buying a used domain without buying its users, there is little reason to accept any mail that it asserts that it is intended for one of those former users. So assuming I already have the infrastructure to do body filtering in the SMTP session, it seems like a cheap way to reject mail that I know is a mistake. R's, John From kurta@drkurt.com Fri Jul 19 12:38:14 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF2A11E81AD for ; Fri, 19 Jul 2013 12:38:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0HHL1AWf6Riv for ; Fri, 19 Jul 2013 12:38:13 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 10D7F11E816E for ; Fri, 19 Jul 2013 12:38:12 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id m15so4329696wgh.35 for ; Fri, 19 Jul 2013 12:38:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=akdABMiIfzcjNmouxP3voIlYwoO73Ta8pqXjeDY5Hwc=; b=DszBm8/gW4Fm39Y7+w5UCxdHWoXvaRF4RzqfWGuj33chFfbZ6L282gwMoTOXnmAOg+ HdntwGYYZP6JgQ0z07nb49cUgoZCTCEBOSqKg5Joh1UUm9+RKvgGje72Qr/OJ/Brmfl1 c0VdMxI/j1Hw3QvT3U779RDXk/1PuOd/CNWBk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=akdABMiIfzcjNmouxP3voIlYwoO73Ta8pqXjeDY5Hwc=; b=kbTcKl6Of8Vp40t+sGeb5fFNarymoFHSWZt0JCT2OX+lGO7KGnZtqt9bKkYB5SXL0X 8fqUbdI0aC2r1Xfi0QcF+SMGsoCwq/CfULenfx7SHZxufjciu4CDk7AFVJYY/8WZS8WU Ms37iq51f1bPTHhY8n5Nh0UmEqQT4eq5Ob1gTZhHPCDKipiXOtXA5lN/C4vqV+rWAOYN Uz7/o/77MFjXFPVVwA9vhQ0S1qFrDMlHCYJLrBOFLtINdg+T54uhAwffR7XOWBH9VI1Z /whJIiz5fwwt/dc6bNHiSiA2Gw3ZAZ8kKnZQLRo4c+ssYg/XHMn6712qeR+Oss+Lb7QI o3QA== MIME-Version: 1.0 X-Received: by 10.194.157.99 with SMTP id wl3mr13081468wjb.76.1374262692075; Fri, 19 Jul 2013 12:38:12 -0700 (PDT) Sender: kurta@drkurt.com Received: by 10.194.90.104 with HTTP; Fri, 19 Jul 2013 12:38:11 -0700 (PDT) In-Reply-To: References: Date: Fri, 19 Jul 2013 12:38:11 -0700 X-Google-Sender-Auth: XjRznq4pQ5ALP5OYUevM9gXP1yg Message-ID: From: Kurt Andersen To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQn3dxys4J65SS3hUpJrR6Hi21W+X09cm+/SOAMxcuxoayV99PHBWKjWbgrZQCxdfj0U7Exx Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 19:38:14 -0000 On Fri, Jul 19, 2013 at 11:49 AM, Murray S. Kucherawy wrote: > On Fri, Jul 19, 2013 at 7:30 AM, Kurt Andersen wrote: >> >> > If an account was created at time T1, then an inquiry as to whether it's >> > been under continuous ownership since time T0 (for T0 < T1) would be >> > "no". >> >> What would the expected response be for a mailbox provider who, for >> instance, replaced their underlying infrastructure two years ago if >> they receive an rrvs header that inquires about the continuity of >> ownership for a time prior to the systems replacement? Their knowledge >> horizon is limited to two years (in this example), yet the rrvs header >> might be predicating five years of continuity. >> > > Good question. I would say that a participating receiver should reject such > a message; the author is asserting that the content of the message is unsafe > to deliver unless continuous ownership can be confirmed, for the sake of > protecting one of its users. In the case you described, such confirmation > isn't possible. > > Such an operator might also want to consider not participating at all. > > What do others think? It seems to me that "asserting that the . . . message is unsafe to deliver . . . unless continuous ownership is confirmed" is a significantly stronger statement than the position that is set forth in the draft. To make such an assertion would limit the scope of applicability for this mechanism to security and identity related messages only: things like password reset but not "updates from your friends". --Kurt Andersen From ajs@anvilwalrusden.com Fri Jul 19 12:45:36 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4104C11E8193 for ; Fri, 19 Jul 2013 12:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.79 X-Spam-Level: X-Spam-Status: No, score=-0.79 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3PbY7rOnNTMH for ; Fri, 19 Jul 2013 12:45:26 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 8345D11E8113 for ; Fri, 19 Jul 2013 12:45:26 -0700 (PDT) Received: from mx1.yitter.info (nat-07-mht.dyndns.com [216.146.45.246]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 073348A031 for ; Fri, 19 Jul 2013 19:45:24 +0000 (UTC) Date: Fri, 19 Jul 2013 15:45:23 -0400 From: Andrew Sullivan To: apps-discuss@ietf.org Message-ID: <20130719194523.GG40049@mx1.yitter.info> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [apps-discuss] Comments on draft-sullivan-domain-policy-authority X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jul 2013 19:45:36 -0000 Hi, On Fri, Jul 19, 2013 at 11:48:29AM -0700, Murray S. Kucherawy wrote: > One thing it doesn't mention is that it will require a SOPA record to be > created at every extant node in the DNS tree for a domain that wishes to > make use of it. Unless I've misread something, the document does indicate > that a node can indicate it is in the same policy realm as all of its > descendants, but it also says this relationship needs to be confirmed to be > believed. That means all of the descendant nodes also have to have SOPA > records pointing back to that parent node. If I'm understanding that > correctly, the document should probably call this out as a constraint as > well. In the inclusion case, yes. This is an unhappy consequence of my worry about certain security implications of the relationship, but thinking about it after John Levine made the same argument to me off-list I'm wondering whether we just need to invent a new relation class that asserts "mail policy apex", which can assert mail control over everything beneath it. The problem with this is the same security problem we have with just doing inclusion without a corresponding inclusion record at the target. However, as several people have argued, a parent has the ultimate authority to redirect the name, so maybe the best way to handle this is just contracts. > APPSAWG/APPAREA agenda, if the authors of both drafts would be interested > in talking to that audience about their ideas in Berlin. I'm prepared to discuss this if others think it would be useful. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From superuser@gmail.com Fri Jul 19 13:36:21 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B55021E809B for ; Fri, 19 Jul 2013 13:36:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8rSXxNVlm+u for ; Fri, 19 Jul 2013 13:36:20 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id A8E2F21E805D for ; Fri, 19 Jul 2013 13:36:13 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id m6so217010wiv.3 for ; Fri, 19 Jul 2013 13:36:12 -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=BGyjVMpVMq4HSJaMUl8ZQxJmdAK9yr/dGrwBBeOD9rk=; b=kWOUh+Q5zCzQ3M654zfHleFMvl/5Uq2HruZECfZre5P509YOl9JKsb8xOwfhKi3qjF pHba0H/dGbrDluWU2VtW2GPBIbQieRRgSmbsl8foAPBCWGuVe+j/MDYb+o3KCD88WDCc uBmmEyO2nlNPUhGNs6rksX8i6KMJXeBxdCbNEKB7KWPEl+tg501qGN14VGwVANhO3O4d PPAyI9l5lraDuEe0PYPB5cmdro+42axOqI+5VMwTKDo14b3bIj118bxzA1HAvF5RycjC sRsNiKgpVyz1aJ840kHjlEmq7yGPuadiufUotWSVpD9Fn+jTRif2u7OTNHRnO/7na1Es 3yIg== MIME-Version: 1.0 X-Received: by 10.194.122.71 with SMTP id lq7mr13084969wjb.77.1374266172783; Fri, 19 Jul 2013 13:36:12 -0700 (PDT) Received: by 10.180.90.16 with HTTP; Fri, 19 Jul 2013 13:36:12 -0700 (PDT) In-Reply-To: <01OW6YGX39GU000054@mauve.mrochek.com> References: <20130718202939.10687.qmail@joyce.lan> <01OW6YGX39GU000054@mauve.mrochek.com> Date: Fri, 19 Jul 2013 13:36:12 -0700 Message-ID: From: "Murray S. Kucherawy" To: Ned Freed Content-Type: multipart/alternative; boundary=089e012297500e445904e1e34756 Cc: John R Levine , IETF Apps Discuss Subject: Re: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 20:36:21 -0000 --089e012297500e445904e1e34756 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jul 19, 2013 at 7:45 AM, Ned Freed wrote: > I have a lot of problems with this document as it stands. > [...] > The suggestion about comparing against the envelope recipient set seems to be pretty solid, so I'll skip that for now. Checking against current recipients prevents this problem from occurring, > and > will result in successful delivery in the described case. And I would argue > strongly that that's the correct outcome: Once mail hits an address I own > what > I do with it, and when, is my own damn busines, not yours. I'm willing, > albeit > grudgingly, to give up some information about the age of the address you're > sending to in exchange for some protection against mail you send to me > ending > up going to the guy in Oregon who wrote "Understanding Business > Statistics" and > has much curlier hair than I do. (It's quite a good book, BTW.) But > knowledge > of how I handle my mail after I receive it goes much much much too far. > > Would a change in language from advocating rejection to merely stressing that the target recipient is not actually the intended recipient be satisfactory? Another thing that needs to be mentioned is use of this facility when > an entire domain changes ownership. This is a little more complex than > it appears because of the need for addresses like postmaster@domain.com > to be immune to ownership changes. But I can see this as being very useful. > Good point here. > > This document is going to need an explanation for why a header field is > being > used to communicate to the MTA/MDA rather than defining an SMTP extension, > which would be the "correct" architectural choice, not to mention being > able to > address all the various forwarding issues. (I'm not saying the current > choice > is wrong, but it needs to be strongly justified.) > Fair enough. > I also find this paragraph: > > This header field SHOULD NOT be added to a message that is addressed > to multiple recipients. It is presumed that an author making use of > this field is seeking to protect transactional or otherwise sensitive > data intended for a single recipient. > > to be more than a little wierd. I send mail all the time to multiple > recipients > that I really rather not end up going to an unintended recipient. Indeed, I > don't really see who the number of recipients correlates well if at all > with > data sensitivity. I think this whole thing needs to go, especially since > envelope checks mostly solve the problems associated with multiple > recipients. > The use case being addressed is only single-recipient messages, like password change requests or user-specific activity. Such things are never sent to multiple users. Certainly there's a class of messages that are sensitive and have multiple recipients, but they're not part of this problem space. In that sense, allowing a list of addresses on the header field rather than just one creates complexity that isn't needed for the problem we're trying to solve. That said, I'm pretty sure it doesn't clobber our use case to allow multiple instances of this field to be added. > > More generally, this gets into the entire issue of when a client should use > this facility. I suppose one way is to have a button you press to request > "additional recipient verification" or something like that, but let's face > it, > users aren't going to have a clue about what this does and therefore aren't > going to know when to use it and when not to. The only way this makes > sense is > to use it automatically when an address comes out of the user's address > book. > And not having it work when there are muliple recipients will lead to more > least astonishment principle violations. > Is it necessary to go into this level of detail? A client uses this facility if the nature of the content means it's important to get to a particular person rather than whatever person currently owns a given mailbox. Describing UI things like buttons seems to go into more specifics than are really required, especially since the systems implementing early versions are entirely backend systems that don't interact directly with users. > > There absolutely has to be some text on mitigating failure cases. A user > who is > effectively blocked from being able to send or receive legitimate mail > because > of some screwup (e.g., the account got deleted by mistake and then was > reinstated with a new creation date) is not going to be a happy camper. And > MSPs are not fond of mechanisms that lead to a rise in support calls. > Fair enough. > > And speaking of failures, a new enhanced status code needs to be defined > for > use when this mechanism bounces mail, and support for NOTARY and > ENHANCEDSTATUSCODES needs to be at least a SHOULD for anyone implementing > this. > I would also suggest having a separate status code for the case of a domain > ownership change. > That all seems fine to me. > I'm sorry, but the notion that a single sentence security considerations > section is going to pass muster for a document like this is nothing short > of absurd. The consequences of revealing the age of an account need to > be elaborated on at least a little bit. > What I claimed was that the specific thing John brought up is covered. I didn't claim the current text of Security Considerations is comprehensive or complete at this early stage. > The cases where a false negative occurs absolutely are a security concern, > and need to be described as well. > > There should also be some reference to the part about signing these > headers. (I > view such recommendations as Mostly Harmless, but security folks like > them.) > Sure, those can be added. But don't we already do that near the end of Section 3? -MSK --089e012297500e445904e1e34756 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Jul 19, 2013 at 7:45 AM, Ned Freed <ned.freed= @mrochek.com> wrote:
I have a lot of problems with this document = as it stands.
[...]

The suggestion about comparing ag= ainst the envelope recipient set seems to be pretty solid, so I'll skip= that for now.

Checking against current recipients prevents this problem from occurring, a= nd
will result in successful delivery in the described case. And I would argue=
strongly that that's the correct outcome: Once mail hits an address I o= wn what
I do with it, and when, is my own damn busines, not yours. I'm willing,= albeit
grudgingly, to give up some information about the age of the address you= 9;re
sending to in exchange for some protection against mail you send to me endi= ng
up going to the guy in Oregon who wrote "Understanding Business Statis= tics" and
has much curlier hair than I do. (It's quite a good book, BTW.) But kno= wledge
of how I handle my mail after I receive it goes much much much too far.
=

Would a change in language from advoc= ating rejection to merely stressing that the target recipient is not actual= ly the intended recipient be satisfactory?

Another thing that needs to be mentioned is use of this facility when
an entire domain changes ownership. This is a little more complex than
it appears because of the need for addresses like postmaster@domain.com
to be immune to ownership changes. But I can see this as being very useful.=

Good point here.
=A0

This document is going to need an explanation for why a header field is bei= ng
used to communicate to the MTA/MDA rather than defining an SMTP extension,<= br> which would be the "correct" architectural choice, not to mention= being able to
address all the various forwarding issues. =A0(I'm not saying the curre= nt choice
is wrong, but it needs to be strongly justified.)

Fair enough.


I also find this paragraph:

=A0 This header field SHOULD NOT be added to a message that is addressed =A0 to multiple recipients. =A0It is presumed that an author making use of<= br> =A0 this field is seeking to protect transactional or otherwise sensitive =A0 data intended for a single recipient.

to be more than a little wierd. I send mail all the time to multiple recipi= ents
that I really rather not end up going to an unintended recipient. Indeed, I=
don't really see who the number of recipients correlates well if at all= with
data sensitivity. I think this whole thing needs to go, especially since envelope checks mostly solve the problems associated with multiple recipien= ts.

The use case being addressed = is only single-recipient messages, like password change requests or user-sp= ecific activity.=A0 Such things are never sent to multiple users.=A0 Certai= nly there's a class of messages that are sensitive and have multiple re= cipients, but they're not part of this problem space.=A0 In that sense,= allowing a list of addresses on the header field rather than just one crea= tes complexity that isn't needed for the problem we're trying to so= lve.

That said, I'm pretty sure it doesn't clobber our us= e case to allow multiple instances of this field to be added.
=A0

More generally, this gets into the entire issue of when a client should use=
this facility. I suppose one way is to have a button you press to request "additional recipient verification" or something like that, but l= et's face it,
users aren't going to have a clue about what this does and therefore ar= en't
going to know when to use it and when not to. The only way this makes sense= is
to use it automatically when an address comes out of the user's address= book.
And not having it work when there are muliple recipients will lead to more<= br> least astonishment principle violations.

Is it necessary to go into this level of detail?=A0 A client uses t= his facility if the nature of the content means it's important to get t= o a particular person rather than whatever person currently owns a given ma= ilbox.=A0 Describing UI things like buttons seems to go into more specifics= than are really required, especially since the systems implementing early = versions are entirely backend systems that don't interact directly with= users.
=A0

There absolutely has to be some text on mitigating failure cases. A user wh= o is
effectively blocked from being able to send or receive legitimate mail beca= use
of some screwup (e.g., the account got deleted by mistake and then was
reinstated with a new creation date) is not going to be a happy camper. And=
MSPs are not fond of mechanisms that lead to a rise in support calls.

Fair enough.
=A0

And speaking of failures, a new enhanced status code needs to be defined fo= r
use when this mechanism bounces mail, and support for NOTARY and
ENHANCEDSTATUSCODES needs to be at least a SHOULD for anyone implementing t= his.
I would also suggest having a separate status code for the case of a domain=
ownership change.

That all seems fine to me.
= =A0
I'm sorry, but the notion that a single sentence security consideration= s
section is going to pass muster for a document like this is nothing short of absurd. The consequences of revealing the age of an account need to
be elaborated on at least a little bit.

What I cl= aimed was that the specific thing John brought up is covered.=A0 I didn'= ;t claim the current text of Security Considerations is comprehensive or co= mplete at this early stage.


The cases where a false negative occurs absolutely are a security concern,<= br> and need to be described as well.

There should also be some reference to the part about signing these headers= . (I
view such recommendations as Mostly Harmless, but security folks like them.= )

Sure, those can be added.=A0 But do= n't we already do that near the end of Section 3?

-MSK
--089e012297500e445904e1e34756-- From kurta@drkurt.com Fri Jul 19 13:51:32 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9639D11E8183 for ; Fri, 19 Jul 2013 13:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qlFhDM8IoEFO for ; Fri, 19 Jul 2013 13:51:29 -0700 (PDT) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 1036C11E819F for ; Fri, 19 Jul 2013 13:51:28 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id p60so4469227wes.13 for ; Fri, 19 Jul 2013 13:51:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; bh=OGD18CADAxgm0Jm23LQZnndAwuxn4y1cCZfsvKv8CAs=; b=FfGFQYVELA+aP1dK3Ss3Y+cB7JkJmys0b/3RX1cQm1UQo1b1UKNaVPp1hgzmtOWPq2 DUdt3vMK0Ymt1KYUMz6HwmkWTROmIXb8vBeQGrGlCbJFdWUKotEGBiyNFDdJ5hMztjdS Y3/urlEjTI6izp5m9hBolVvixT3uUXg1Z2ZKE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding:x-gm-message-state; bh=OGD18CADAxgm0Jm23LQZnndAwuxn4y1cCZfsvKv8CAs=; b=gbtllPLs54F1r2r4tYZ0M4tFampN3iGdeLUGZoMwH1ph2nWygwW2reZ8kyc2fqsAcZ q4gfNQFuBXshJQWHMSyw0ktq2zUURcqYTLpgbeR9mIeRkiyu5uOYkjfxqt1WNhb1XrP4 4YT+x0LAF9MRGsWWxJIlUp+xr9H0pAjMvh95sVF5fc2FMCJKTmy+6IYypO40dkLezvze OjMP2DmYYvkDOq641QzfwmV9cGjkCRR+tdNozULSolRpMpOqumsxO5hGmfasNBnWjCyV JntUUvrp8lxIWkXiUvxQm6xjqWnSQNSL+4CNJq5JpT2wNwKpGCNl4CfQ6dfPctJ7IdB0 BnUw== MIME-Version: 1.0 X-Received: by 10.194.122.103 with SMTP id lr7mr13371316wjb.15.1374267083407; Fri, 19 Jul 2013 13:51:23 -0700 (PDT) Sender: kurta@drkurt.com Received: by 10.194.90.104 with HTTP; Fri, 19 Jul 2013 13:51:23 -0700 (PDT) Date: Fri, 19 Jul 2013 13:51:23 -0700 X-Google-Sender-Auth: gPxJMazhcFx69dsdrwBbdlfZ7-I Message-ID: From: Kurt Andersen To: apps-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlpddrdC5t5b/I54daOrN/oqopVQLIWa0fCNXX/ofTMvj2CSPSYOdEliEL6IPYXNp+g6+Ni Subject: Re: [apps-discuss] Comments on draft-sullivan-domain-policy-authority X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jul 2013 20:51:32 -0000 On Fri, 19 Jul 2013 12:00:49 -0700, Paul Hoffman wr= ote: > > On Jul 19, 2013, at 11:48 AM, Murray S. Kucherawy w= rote: > >> There's another related document, draft-levine-orgboundary, about which = I'll comment separately. I wonder, though, since we have time on the APPSA= WG/APPAREA agenda, if the authors of both drafts would be interested in tal= king to that audience about their ideas in Berlin. > > +1. Fortunately, both authors will be in Berlin. Another +1. I just hope that the appswg meeting will be at a sane time for Pacific Coasters. --Kurt Andersen From stpeter@stpeter.im Fri Jul 19 13:53:59 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1DD821F99F8 for ; Fri, 19 Jul 2013 13:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ian9WH3GUttG for ; Fri, 19 Jul 2013 13:53:51 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 205BB21F99A9 for ; Fri, 19 Jul 2013 13:53:39 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B73D24149B; Fri, 19 Jul 2013 14:55:12 -0600 (MDT) Message-ID: <51E9A74E.8010708@stpeter.im> Date: Fri, 19 Jul 2013 14:53:34 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Kurt Andersen References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Comments on draft-sullivan-domain-policy-authority X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jul 2013 20:53:59 -0000 On 7/19/13 2:51 PM, Kurt Andersen wrote: > On Fri, 19 Jul 2013 12:00:49 -0700, Paul Hoffman wrote: >> >> On Jul 19, 2013, at 11:48 AM, Murray S. Kucherawy wrote: >> >>> There's another related document, draft-levine-orgboundary, about which I'll comment separately. I wonder, though, since we have time on the APPSAWG/APPAREA agenda, if the authors of both drafts would be interested in talking to that audience about their ideas in Berlin. >> >> +1. Fortunately, both authors will be in Berlin. > > Another +1. I just hope that the appswg meeting will be at a sane time > for Pacific Coasters. It won't be: 09:00 Central European Summer Time (UTC+2). I think it'll be starting a bit after midnight Pacific. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Fri Jul 19 13:55:25 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFDB411E8198 for ; Fri, 19 Jul 2013 13:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IQnhJ6I3kG9h for ; Fri, 19 Jul 2013 13:55:07 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1195211E80D3 for ; Fri, 19 Jul 2013 13:54:52 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 736A34149B; Fri, 19 Jul 2013 14:56:21 -0600 (MDT) Message-ID: <51E9A793.70303@stpeter.im> Date: Fri, 19 Jul 2013 14:54:43 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Kurt Andersen References: <51E9A74E.8010708@stpeter.im> In-Reply-To: <51E9A74E.8010708@stpeter.im> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Comments on draft-sullivan-domain-policy-authority X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jul 2013 20:55:25 -0000 On 7/19/13 2:53 PM, Peter Saint-Andre wrote: > On 7/19/13 2:51 PM, Kurt Andersen wrote: >> On Fri, 19 Jul 2013 12:00:49 -0700, Paul Hoffman wrote: >>> >>> On Jul 19, 2013, at 11:48 AM, Murray S. Kucherawy wrote: >>> >>>> There's another related document, draft-levine-orgboundary, about which I'll comment separately. I wonder, though, since we have time on the APPSAWG/APPAREA agenda, if the authors of both drafts would be interested in talking to that audience about their ideas in Berlin. >>> >>> +1. Fortunately, both authors will be in Berlin. >> >> Another +1. I just hope that the appswg meeting will be at a sane time >> for Pacific Coasters. > > It won't be: 09:00 Central European Summer Time (UTC+2). I think it'll > be starting a bit after midnight Pacific. Oh, and on Monday morning in Berlin, so very late Sunday night for folks on the West Coast. Peter -- Peter Saint-Andre https://stpeter.im/ From superuser@gmail.com Fri Jul 19 14:03:11 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBAA411E8158 for ; Fri, 19 Jul 2013 14:03:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n86pGGGlXVua for ; Fri, 19 Jul 2013 14:03:11 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id 263F511E80D3 for ; Fri, 19 Jul 2013 14:03:10 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id k10so233875wiv.5 for ; Fri, 19 Jul 2013 14:03:09 -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=Ftbk46cRcpjPzmhhpyOUx10o3oRktJyLYctBKareSfw=; b=g9gp7q/QawBTgg6nZJIitCPQ6gMmFHymQZM0ZJ9q6ImpRPHNrpntLy/PXp9Tp3g8hp tD0mnB5qF2Aavn6X63RQofU9mLSx6mtk8oejhe3Tp8XMx8siODGhPG0t5DJYmVfWTGEZ QM8tOSICQMrvh07hbeJcueKgDvUAxwUIgymiqmEgmB3zv5LaVXZR8sY16Sp/a6OftX2M n3ASTZ8Y/OIh5IftZdA4Fhw6TTy0VCZn+3qJ2rjUyUnFqWBSUWdcPFzUgolvibYKwT8s 8kNGcxPwijbCXBhmkyI2ocEaBW6DoEyWssBb0Zd0jLnDCQm0eME+mMWh+vbyoRDYbwP6 CZ6Q== MIME-Version: 1.0 X-Received: by 10.194.239.225 with SMTP id vv1mr13374337wjc.63.1374267789091; Fri, 19 Jul 2013 14:03:09 -0700 (PDT) Received: by 10.180.90.16 with HTTP; Fri, 19 Jul 2013 14:03:09 -0700 (PDT) In-Reply-To: References: Date: Fri, 19 Jul 2013 14:03:09 -0700 Message-ID: From: "Murray S. Kucherawy" To: Kurt Andersen Content-Type: multipart/alternative; boundary=089e01493384652a2104e1e3a778 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 21:03:11 -0000 --089e01493384652a2104e1e3a778 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jul 19, 2013 at 12:38 PM, Kurt Andersen wrote: > It seems to me that "asserting that the . . . message is unsafe to > deliver . . . unless continuous ownership is confirmed" is a > significantly stronger statement than the position that is set forth > in the draft. To make such an assertion would limit the scope of > applicability for this mechanism to security and identity related > messages only: things like password reset but not "updates from your > friends". > > > Who's to say updates from your friends aren't equally sensitive, or possibly even more so? -MSK --089e01493384652a2104e1e3a778 Content-Type: text/html; charset=ISO-8859-1
On Fri, Jul 19, 2013 at 12:38 PM, Kurt Andersen <kboth@drkurt.com> wrote:
It seems to me that "asserting that the . . . message is unsafe to
deliver . . . unless continuous ownership is confirmed" is a
significantly stronger statement than the position that is set forth
in the draft. To make such an assertion would limit the scope of
applicability for this mechanism to security and identity related
messages only: things like password reset but not "updates from your
friends".



Who's to say updates from your friends aren't equally sensitive, or possibly even more so?

-MSK

--089e01493384652a2104e1e3a778-- From superuser@gmail.com Fri Jul 19 23:51:41 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E473611E8116 for ; Fri, 19 Jul 2013 23:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FchU0c62FAtc for ; Fri, 19 Jul 2013 23:51:41 -0700 (PDT) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 25D2911E80E4 for ; Fri, 19 Jul 2013 23:51:41 -0700 (PDT) Received: by mail-pa0-f54.google.com with SMTP id kx10so5205135pab.13 for ; Fri, 19 Jul 2013 23:51:39 -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=SikyNBlnzB/vl0UoSdqBn5yi5IA79tale5sUlqkQy4c=; b=OB4P3lfkoix7A1R3r/8Y/jltjSAseTBPjXPxcLj1bwDm38p37W0gMFmGe7vOsDoaU1 k7kOj6AHI1U9OiXjRuIaPHmxb1g+lcqH7WagauXwLYUC8tvL4ea4G0YAlsDlZJX/0FmB UBe2JOuadN3XZb7dM9DKEshNtXE1AWUDA6gNaUClA4NXH3WEzRXQrZ1PuYKH4UOMe7bC AEFoKBd9Wx2dBJDCI3viER5RfgGr2W49DKNKkOe/lF7K7/StEI3HPOczhrP7jma+5NrM 7zI734viY3wH+vTy9Bz05GtY+L/U1X6j2SrXB6aHggQmCYHqLMDgRqoc2TyG+itpb6kZ 1H0g== MIME-Version: 1.0 X-Received: by 10.66.248.164 with SMTP id yn4mr22152831pac.153.1374303099229; Fri, 19 Jul 2013 23:51:39 -0700 (PDT) Received: by 10.67.5.131 with HTTP; Fri, 19 Jul 2013 23:51:38 -0700 (PDT) In-Reply-To: <20130719154503.GE30100@x28.adm.denic.de> References: <20130718202939.10687.qmail@joyce.lan> <20130719105146.GA30100@x28.adm.denic.de> <20130719154503.GE30100@x28.adm.denic.de> Date: Fri, 19 Jul 2013 23:51:38 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=047d7b15b0190b1b4b04e1ebe0c2 Subject: Re: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2013 06:51:42 -0000 --047d7b15b0190b1b4b04e1ebe0c2 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jul 19, 2013 at 8:45 AM, Peter Koch wrote: > > I don't believe we need to call that out. If an account was created at > > time T1, then an inquiry as to whether it's been under continuous > ownership > > since time T0 (for T0 < T1) would be "no". If the account has been > > with A and B denoting different "owners" of an account, and this timeline > and teh interpretation you just gave, instead of determining the end of > A's control, one could indeed find the inception time for B. This is > a privacy risk. > > -----------+-----------+-----------+----------- > T0 T1 T2 > AAAAAAAAAAAA BBBBBBBBBBBB > (This looks different for proportional versus fixed-width fonts. As I understand it, you're saying A owned the mailbox only between T0 and T1, and B owned it starting at T2, and there was no owner in between.) Yes, this can be used to determine the time at which B took ownership of the mailbox being probed. The (brief, currently) Security Considerations says this already. However, ... > > > deleted, then there's no need to check for an existence or change of > > ownership, because the mail won't be delivered anyway regardless of when > it > > might have been created, reassigned, or deleted. > > Sure, it doesn't influence the delivery, but it changes the > information leak. If you'd instead account the interval > between T1 and T2 for B, you might be able to determine the > end of A's "ownership". > The question being asked is "has the target mailbox been under constant ownership since
That's an= interesting use case.  A good thing for mailing lists.
=
 
-bill


------------------= --------------
William J. Mills
"Paranoid" Yahoo!

<= /div>

=
From: Ned Freed <ned.freed@mrochek.com>
<= b>To: IETF Apps Discuss <apps-discuss@ietf.org>
S= ent: Saturday, July 20, 2013 9:23 AM
Subject: Re: [apps-discuss] Comments on draft-wmi= lls-rrvs-header-field-00
=
It occurs to me that the interaction of this proposal with mailing list= s
deserves more consideration. A mailing list processor isn't going to k= now what
this header is and is therefore likely to let it through, at le= ast to all
non-digest recipients. Given the present proposal and the lac= k of an envelope
check, if I know someone is on the list under a certain= address (easy to know
from their postings), I can mess with them as wel= l as anyone else using the
same MSP by including a header listing their = address and some date prior to
when the address came into use.

No= te that an envelope check only partly mitigates this attack. A better
mitigation would be a comparison of the envelope from with the F= rom:/Sender:
field, which I'm starting to think may be needed in additio= n to the envelope
recipient check.

Aside from being another point= in favor of an envelope check, this strongly
argues for mailing list re= moval of this field.

Another thing that deserves consideration is in= addition to checking the
account age, also check to see if there actual= ly was any prior use of the
account. The problem is this has to be coupl= ed with a domain age check in the
event of previous use of the domain, s= o it doesn't fully address the problem
and makes the resulting operation= a lot more complex.

Interestingly, consideration of mailing lists b= rings up another use
of this facility. Mailing list software can (and in= some cases already
does) store the subscription date. That date could t= hen be used to
in an RRVS field to prevent mailing list messages from going to the
wrong recipient and instead unsubscribe the recipient= from the list.

Note that an unsubscription notice probably needs to= be sent unconditionally
in the case of screwups or intentional attackcs= as previously described.

        &nbs= p;       Ned
__________________________________= _____________
apps-discuss mailing list
apps-discuss@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/apps-discuss

=
--933233344-163286532-1374341975=:74035-- From wmills@yahoo-inc.com Sat Jul 20 10:50:07 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B24F811E8117 for ; Sat, 20 Jul 2013 10:50:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.431 X-Spam-Level: X-Spam-Status: No, score=-18.431 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5xFWZp0djtKK for ; Sat, 20 Jul 2013 10:50:02 -0700 (PDT) Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) by ietfa.amsl.com (Postfix) with ESMTP id BEAA211E80E1 for ; Sat, 20 Jul 2013 10:50:02 -0700 (PDT) Received: from GQ1-EX10-CAHT05.y.corp.yahoo.com (gq1-ex10-caht05.corp.gq1.yahoo.com [10.73.118.84]) by mrout3.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id r6KHnjHB075324 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 20 Jul 2013 10:49:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1374342586; bh=Tquj6a8UvZMnPySPckHAEsMtwbtp6qucVv8n1t7GGWI=; h=References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To: MIME-Version:Content-Type; b=uom1dYRfx9+otm23U7LuAHKDMrtX+hwRQiVDBCuaAN9TjEfigFO9UMitI16/UILWJ pfrTL0XSTCCZC9yoAEZe6Ssc7jE05zh8vZ6f7fUYyEFsBkx8yoy0oqgwqOEIVj9aa6 PEowkPdo3ZJ1FCrEL5YXGQlaHe8+NjcIZ0yudle4= Received: from omp1054.mail.ne1.yahoo.com (98.138.89.196) by GQ1-EX10-CAHT05.y.corp.yahoo.com (10.72.228.24) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sat, 20 Jul 2013 10:49:44 -0700 Received: (qmail 22131 invoked by uid 1000); 20 Jul 2013 17:49:44 -0000 Received: (qmail 83468 invoked by uid 60001); 20 Jul 2013 17:49:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1374342583; bh=/1TcaaJjVRf3e5A9NTsVkwSi7d6nXvoD7abPs9bhN/A=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=mIl93Fijj8Rk+qEJTSQ5V+ytGJ4YGAFqxpxTNVYFBF8TJWviCj+Q2RXfxIX6H1gYT0nZFQOS7axU9hCQ1huqUFGqQFRKPSJnupUtuA7JXs6/I6lz50oetAzW0OnPMLAOJK+NdczKYn9BkYefps12TUOBdKtJGNLiyYu1NzZ8Obo= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=fJ4aLekb5Y+eiDHGUTVFDZHmHbB9MhVuaUGmoNpNQ0TIuTnrAuUkusidwCUw7613L+Pj1BKNQ0G4aJJ0NNr2OQQRBJq1CUhmh6VR+Cbke52WouoqrbkzO3tjtF2I610DFecYpXNkaBqfRtyHbqgUg1tON2I4ED/h0FI3xmhjYfE=; X-YMail-OSG: 1lkvuaoVM1lel8Q69eVqMFDHczOezKaeExpa1Tk7HfCtoel lCE0QMdcgBmpWsKw0CgSol0hzR87hzBfpAH2B6f9.X_1b Received: from [99.31.212.42] by web125602.mail.ne1.yahoo.com via HTTP; Sat, 20 Jul 2013 10:49:43 PDT X-Rocket-MIMEInfo: 002.001, T24gaG93IGEgc2VydmVyIGFkdmVydGlzZXMuLi4gTXkgdGhvdWdodCB3YXMgYSBzaW1wbGUgU01QVCBleHRlbnNpb24gdG8gYWR2ZXJ0aXNlIHRoZSBjYXBhYmlsaXR5LCB0aGUgc2VuZGVyIGNoZWNrcyB0aGlzIHRvIGRldGVybWluZSBpZiB0aGV5IHNob3VsZCBleHBlY3QgYSBib3VuY2Ugb3Igbm9yIGZvcm0gUlJWUy4KCgrCoAotYmlsbAoKCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpXaWxsaWFtIEouIE1pbGxzCiJQYXJhbm9pZCIgWWFob28hCgoKCgpfX19fX19fX19fX19fX19fX19fX18BMAEBAQE- X-Mailer: YahooMailWebService/0.8.149.560 References: <20130718202939.10687.qmail@joyce.lan> <20130719105146.GA30100@x28.adm.denic.de> <20130719154503.GE30100@x28.adm.denic.de> Message-ID: <1374342583.81959.YahooMailNeo@web125602.mail.ne1.yahoo.com> Date: Sat, 20 Jul 2013 10:49:43 -0700 From: Bill Mills To: "Murray S. Kucherawy" , IETF Apps Discuss In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1088529044-54509162-1374342583=:81959" X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 342586000 Subject: Re: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Bill Mills List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2013 17:50:07 -0000 ---1088529044-54509162-1374342583=:81959 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On how a server advertises... My thought was a simple SMPT extension to adv= ertise the capability, the sender checks this to determine if they should e= xpect a bounce or nor form RRVS.=0A=0A=0A=A0=0A-bill=0A=0A=0A=0A-----------= ---------------------=0AWilliam J. Mills=0A"Paranoid" Yahoo!=0A=0A=0A=0A=0A= ________________________________=0A From: Murray S. Kucherawy =0ATo: IETF Apps Discuss =0ASent: Friday, J= uly 19, 2013 11:51 PM=0ASubject: Re: [apps-discuss] Comments on draft-wmill= s-rrvs-header-field-00=0A =0A=0A=0AOn Fri, Jul 19, 2013 at 8:45 AM, Peter K= och wrote:=0A=0A> I don't believe we need to call that out. = =A0If an account was created at=0A>> time T1, then an inquiry as to whether= it's been under continuous ownership=0A>> since time T0 (for T0 < T1) woul= d be "no". =A0If the account has been=0A>=0A>with A and B denoting differen= t "owners" of an account, and this timeline=0A>and teh interpretation you j= ust gave, instead of determining the end of=0A>A's control, one could indee= d find the inception time for B. =A0This is=0A>a privacy risk.=0A>=0A>-----= ------+-----------+-----------+-----------=0A>=A0 =A0 =A0 =A0 =A0 =A0T0 =A0= =A0 =A0 =A0 =A0T1 =A0 =A0 =A0 =A0 =A0T2=0A>=A0 =A0 =A0 =A0 =A0 =A0AAAAAAAA= AAAA =A0 =A0 =A0 =A0 =A0 =A0BBBBBBBBBBBB=A0=0A>=0A=0A(This looks different = for proportional versus fixed-width fonts.=A0 As I understand it, you're sa= ying A owned the mailbox only between T0 and T1, and B owned it starting at= T2, and there was no owner in between.)=0A=0A=0AYes, this can be used to d= etermine the time at which B took ownership of the mailbox being probed.=A0= The (brief, currently) Security Considerations says this already.=A0 Howev= er, ...=0A=A0=0A=0A=0A>> deleted, then there's no need to check for an exis= tence or change of=0A>> ownership, because the mail won't be delivered anyw= ay regardless of when it=0A>> might have been created, reassigned, or delet= ed.=0A>=0A>Sure, it doesn't influence the delivery, but it changes the=0A>i= nformation leak. =A0If you'd instead account the interval=0A>between T1 and= T2 for B, you might be able to determine the=0A>end of A's "ownership".=0A= >=0A=0AThe question being asked is "has the target mailbox been under const= ant ownership since
From: Murray = S. Kucherawy <superuser@gmail.com>
To: IETF Apps Discuss <apps-discuss@ietf.org>
<= b>Sent: Friday, July 19, 2013= 11:51 PM
Subject: Re:= [apps-discuss] Comments on draft-wmills-rrvs-header-field-00
 <= /div>

On Fri, Jul 19, 2013 at 8:45 AM, Peter Koch <= pk@denic.de> wrote:
=0A
> = I don't believe we need to call that out.  If an account was created a= t
=0A> time T1, then an inquiry as to whether it's been under continu= ous ownership
=0A> since time T0 (for T0 < T1) would be "no". &nbs= p;If the account has been
=0A
=0A
with A and B denoting differen= t "owners" of an account, and this timeline
=0Aand teh interpretation yo= u just gave, instead of determining the end of
=0AA's control, one could= indeed find the inception time for B.  This is
=0Aa privacy risk.<= br>=0A
=0A-----------+-----------+-----------+-----------
=0A  &= nbsp;        T0          T1 &n= bsp;        T2
=0A         =  AAAAAAAAAAAA            BBBBBBBBBBBB&n= bsp;

(This looks different for proporti= onal versus fixed-width fonts.  As I understand it, you're saying A ow= ned the mailbox only between T0 and T1, and B owned it starting at T2, and = there was no owner in between.)
=0A
Yes, this can be used = to determine the time at which B took ownership of the mailbox being probed= .  The (brief, currently) Security Considerations says this already.&n= bsp; However, ...
 
=0A=0A

=0A> deleted, then there= 's no need to check for an existence or change of
=0A> ownership, bec= ause the mail won't be delivered anyway regardless of when it
=0A> mi= ght have been created, reassigned, or deleted.
=0A
=0A
Sure, it = doesn't influence the delivery, but it changes the
=0Ainformation leak. =  If you'd instead account the interval
=0Abetween T1 and T2 for B, = you might be able to determine the
=0Aend of A's "ownership".

The question being asked is "has the target mailb= ox been under constant ownership since <time>?"  If B is the cur= rent owner, then the answer to that question is "yes" if and only if the ti= mestamp in the header field is T2 or greater.  Thus, if it's less, the= answer is "no", regardless of whether the timestamp is during A's ownershi= p of the same mailbox.  Given that, I don't see how one could distingu= ish T1 as being different from any other timestamp less than T2.
=0A
=
=0A

=0A> What would the introduction of encryption solve?
= =0A
=0A
To the extent it has solved anything so far, instead of rel= ying
=0Aupon a (non-)delivery mechanism, for a message destined to A
= =0Ait would conceal the content (not the fact of delivery) from B,
=0Apr= ovided B didn't inherit the private key from A.

Just so I understand the use case: If some service provider sends = mail to A using this field that's then forwarded to B, you want to make sur= e B doesn't learn the confirmation date of A just in case the new mailbox B= changes owners?
=0A
=0A
=0AHow to you envision the signalling for the header processing?<= br>=0AX-My-Provider-Supports-RRVS: Yes?
=0A


=
We won't be using "X-", that's for sure.

-MSK<= br>

______________________________________= _________
apps-discuss mailing list
apps-discuss@ietf.org<= br>https://www.ietf.org/mailman/listinfo/apps-discuss


=
---1088529044-54509162-1374342583=:81959-- From johnl@iecc.com Sat Jul 20 12:08:31 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3761521E809E for ; Sat, 20 Jul 2013 12:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.851 X-Spam-Level: X-Spam-Status: No, score=-110.851 tagged_above=-999 required=5 tests=[AWL=0.348, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JDfJqvlHLrLs for ; Sat, 20 Jul 2013 12:08:27 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id B675A21F91CA for ; Sat, 20 Jul 2013 12:08:26 -0700 (PDT) Received: (qmail 19595 invoked from network); 20 Jul 2013 19:08:25 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 20 Jul 2013 19:08:25 -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=51eae029.xn--yuvv84g.k1307; i=johnl@user.iecc.com; bh=cQ92BHBwkegiC/ZIrpJMgY0E2EtVQkhYffgUT+HtVeQ=; b=T2ghxbEx4Oy4OfFdB7vDruVg6RpDpOt8MIkuUJZq45piA7tx91cbDKf+rckHIOoiGlFI4178rMEwSTo+BSNTcB9t+txceicxJykRe+FajeMy6CpTmR2ykRVREOvDa/v9o2qWAwe3tq8Vk5qjnmFjspRV0dQPaYVArtQPbfVoSORh9LyoDwNiWSKdeJ0Rm8aBmHsEVeo9U6vOA8Aq4+CEKK+rfZ2zSRLBjPTpNo5zCL4WKe67vXz4nCNWBdSI8RXl 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=51eae029.xn--yuvv84g.k1307; olt=johnl@user.iecc.com; bh=cQ92BHBwkegiC/ZIrpJMgY0E2EtVQkhYffgUT+HtVeQ=; b=NPILHFW+Moiw6qJ+9Irf6oe1gQ/UhHyySgRrkCyFxuqN4QfmrSFWm5D53d3y0xBtGDnOpEomXS9uOTiDTCmBDy8nPHa1GJ6lvsfFLQexMtcMBKEqqLVAYnq1aOQ/6wHYkPZo5hA5di26gIkO7hY7OhmeyPTPJg7lc2b/JyFAfoKAWRFuO0+4OIOHQ734lVDKWxDW0zKtOmwGg1HSSnWG9o1RRkJIXbKz/KTTHw2vTVBD5zn5Jo9Yq55Bguw3NovA Date: 20 Jul 2013 19:08:03 -0000 Message-ID: <20130720190803.6227.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <1374341975.74035.YahooMailNeo@web125603.mail.ne1.yahoo.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2013 19:08:31 -0000 >That's an interesting use case. A good thing for mailing lists. It's 99.9% the same as the original use case, check that the person getting the mail is the same person who signed up. I'm more interested in the complications involved when people send their own rrvs headers through mailing lists, screwing up the victim's subscription. In this regard it is somewhat like what happens when you send mail to a list from an address with a DMARC policy of quarantine or reject. R's, John From johnl@iecc.com Sat Jul 20 12:10:47 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D61C21E80A8 for ; Sat, 20 Jul 2013 12:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.856 X-Spam-Level: X-Spam-Status: No, score=-110.856 tagged_above=-999 required=5 tests=[AWL=0.343, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9dUZKyF2NSeH for ; Sat, 20 Jul 2013 12:10:42 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 7B35F21E809E for ; Sat, 20 Jul 2013 12:10:42 -0700 (PDT) Received: (qmail 20019 invoked from network); 20 Jul 2013 19:10:41 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 20 Jul 2013 19:10:41 -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=51eae0b1.xn--9vv.k1307; i=johnl@user.iecc.com; bh=u5wG3bYPOu4aJj7YnWUlFPcSu17yS2WLOho7SAl4ZPg=; b=DpLnNT50PWV334Uq7HS7Syjgyl3dGVXy9vMM7FV/nuSxAZ5Wnn9ThyCVGHAznMf/WUIjrAgyeZhzii0bN55VEO4Top8BOkJ+noB8PBohPcbdCIJ9YvuIm7diPeEGgM4qdjPUc9EFMZuzdGlpCLasBq1f9g3GMJ35kfzf+V2gCX3KQiKsGTYGL9NAXy2++BkhbDdoQgdVNJzxcNmEvhvdMl2rnBEwVNsB58/MvA61VdDK4iy66Lr8efCo9/Tu3C/8 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=51eae0b1.xn--9vv.k1307; olt=johnl@user.iecc.com; bh=u5wG3bYPOu4aJj7YnWUlFPcSu17yS2WLOho7SAl4ZPg=; b=XYPGIWd8OKH9IIZHDSXZujaFDal6dsEeRRuQFNn6L5Wj5IuaWobK8hUIGd1kYq0DOGVnPU7VocDqMBGOxpL5LVGMiuhufWCFcDA3zomecectGMKO+UU8CnQS3i6RY3siE8fqEHem9BvDWZod8Y1kwwDCZ+VhiE22CbhzJxujWzL3Jh5rAi5V6CXyPLfAWqqB1pFGj4LZ8Q2D4ppssuxk0jk0Ixmrd/jL0nL0YuutGoqqzG31jYVELfxZEvcIqOBN Date: 20 Jul 2013 19:10:19 -0000 Message-ID: <20130720191019.6251.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <1374342583.81959.YahooMailNeo@web125602.mail.ne1.yahoo.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2013 19:10:47 -0000 >On how a server advertises... My thought was a simple SMPT extension to advertise the >capability, the sender checks this to determine if they should expect a bounce or nor form >RRVS. Can you write down the use case that shows how mail handling with the SMTP extension would be different from mail handling without? Either way, you deal with rrvs bounces when they happen. Servers that don't understand rrvs would just ignore the header, so there's no damage from including it anyway. From ned.freed@mrochek.com Sat Jul 20 18:38:29 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FFC811E80BA for ; Sat, 20 Jul 2013 18:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GLiNTB4FQC00 for ; Sat, 20 Jul 2013 18:38:24 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 12C1A21F9F34 for ; Sat, 20 Jul 2013 18:38:23 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OW8VZ10TNK00AFO0@mauve.mrochek.com> for apps-discuss@ietf.org; Sat, 20 Jul 2013 18:32:49 -0700 (PDT) MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=iso-8859-1 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OW6SL60ZBK000054@mauve.mrochek.com>; Sat, 20 Jul 2013 18:32:46 -0700 (PDT) Message-id: <01OW8VYYYOHC000054@mauve.mrochek.com> Date: Sat, 20 Jul 2013 18:31:47 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sat, 20 Jul 2013 19:08:03 +0000" <20130720190803.6227.qmail@joyce.lan> References: <1374341975.74035.YahooMailNeo@web125603.mail.ne1.yahoo.com> <20130720190803.6227.qmail@joyce.lan> To: John Levine Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2013 01:38:29 -0000 > >That's an interesting use case. A good thing for mailing lists. > It's 99.9% the same as the original use case, check that the person > getting the mail is the same person who signed up. It's actually a simpler case, because when you're dealing with a mailing list you just set a policy for using this and then you're done. All the user interaction issues pretty much go away. > I'm more interested in the complications involved when people send > their own rrvs headers through mailing lists, screwing up the victim's > subscription. As am I. Ned From ned.freed@mrochek.com Sat Jul 20 19:11:45 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACE6121F9F2B for ; Sat, 20 Jul 2013 19:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OpeT9g7OdiaT for ; Sat, 20 Jul 2013 19:11:40 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC8F21F9F13 for ; Sat, 20 Jul 2013 19:11:40 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OW8X5WFABK009U00@mauve.mrochek.com> for apps-discuss@ietf.org; Sat, 20 Jul 2013 19:06:36 -0700 (PDT) MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=iso-8859-1 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OW6SL60ZBK000054@mauve.mrochek.com>; Sat, 20 Jul 2013 19:06:33 -0700 (PDT) Message-id: <01OW8X5UAAHW000054@mauve.mrochek.com> Date: Sat, 20 Jul 2013 18:44:48 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 19 Jul 2013 13:36:12 -0700" References: <20130718202939.10687.qmail@joyce.lan> <01OW6YGX39GU000054@mauve.mrochek.com> To: "Murray S. Kucherawy" Cc: John R Levine , Ned Freed , IETF Apps Discuss Subject: Re: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2013 02:11:45 -0000 > On Fri, Jul 19, 2013 at 7:45 AM, Ned Freed wrote: > > I have a lot of problems with this document as it stands. > > [...] > > > The suggestion about comparing against the envelope recipient set seems to > be pretty solid, so I'll skip that for now. OK. > Checking against current recipients prevents this problem from occurring, > > and > > will result in successful delivery in the described case. And I would argue > > strongly that that's the correct outcome: Once mail hits an address I own > > what > > I do with it, and when, is my own damn busines, not yours. I'm willing, > > albeit > > grudgingly, to give up some information about the age of the address you're > > sending to in exchange for some protection against mail you send to me > > ending > > up going to the guy in Oregon who wrote "Understanding Business > > Statistics" and > > has much curlier hair than I do. (It's quite a good book, BTW.) But > > knowledge > > of how I handle my mail after I receive it goes much much much too far. > > > > > Would a change in language from advocating rejection to merely stressing > that the target recipient is not actually the intended recipient be > satisfactory? No, not really. Again, as far as the originator is concerned, the recipient address they know about has been reached and it still belongs to the same person. The mechanism's effect really needs to end there, because if you try and extend it all kinds of wierd stuff can happen. If you want another example, consider what happens when someone uses fetchmail to suck the mail out of a mailbox after delivery and sending it on somewhere else. People route mail in all kinds of ways. And yes, what people do does lead to problems, like when an autoforwarded message bounces back to the message originator who then gets a bounce from an address they have never heard of and wonder what the hell is going on. But new mechanisms need to be designed not to make the problems worse. > Another thing that needs to be mentioned is use of this facility when > > an entire domain changes ownership. This is a little more complex than > > it appears because of the need for addresses like postmaster@domain.com > > to be immune to ownership changes. But I can see this as being very useful. > > > Good point here. Thanks. We deal with domain shifts all the time, and this would be good tool to have in some cases. > > I also find this paragraph: > > > > This header field SHOULD NOT be added to a message that is addressed > > to multiple recipients. It is presumed that an author making use of > > this field is seeking to protect transactional or otherwise sensitive > > data intended for a single recipient. > > > > to be more than a little wierd. I send mail all the time to multiple > > recipients > > that I really rather not end up going to an unintended recipient. Indeed, I > > don't really see who the number of recipients correlates well if at all > > with > > data sensitivity. I think this whole thing needs to go, especially since > > envelope checks mostly solve the problems associated with multiple > > recipients. > > > The use case being addressed is only single-recipient messages, like > password change requests or user-specific activity. Such things are never > sent to multiple users. Certainly there's a class of messages that are > sensitive and have multiple recipients, but they're not part of this > problem space. In that sense, allowing a list of addresses on the header > field rather than just one creates complexity that isn't needed for the > problem we're trying to solve. > That said, I'm pretty sure it doesn't clobber our use case to allow > multiple instances of this field to be added. Password change requests are an easy one, because they're automated. In fact this makes me think about the more general use-case here of preventing a new "owner" of an address from finding out about an account the previous owner had somewhere. If I get mail - never mind what - directed at the previous owner, and it's one of those systems that has a "I forgot my password" button that works by sending the password reset sequence to the registered email address, and the account has a stored credit card #... See the problem? > > > > More generally, this gets into the entire issue of when a client should use > > this facility. I suppose one way is to have a button you press to request > > "additional recipient verification" or something like that, but let's face > > it, > > users aren't going to have a clue about what this does and therefore aren't > > going to know when to use it and when not to. The only way this makes > > sense is > > to use it automatically when an address comes out of the user's address > > book. > > And not having it work when there are muliple recipients will lead to more > > least astonishment principle violations. > > > Is it necessary to go into this level of detail? A client uses this > facility if the nature of the content means it's important to get to a > particular person rather than whatever person currently owns a given > mailbox. OK, so how does a client determine the nature of the content automatically? I don't know about anyone else, but I've written highly confidential reviews of things using exactly the same commands that I used to forward an article to a couple of friends. > Describing UI things like buttons seems to go into more specifics > than are really required, especially since the systems implementing early > versions are entirely backend systems that don't interact directly with > users. My point wasn't that the specification should go into these sorts of specifics, but rather that such interfaces aren't going to work. Unless there's something about this I'm not seeing, The only way this works is if it works automatically. > > I'm sorry, but the notion that a single sentence security considerations > > section is going to pass muster for a document like this is nothing short > > of absurd. The consequences of revealing the age of an account need to > > be elaborated on at least a little bit. > > > What I claimed was that the specific thing John brought up is covered. I > didn't claim the current text of Security Considerations is comprehensive > or complete at this early stage. Fair point. I should also add that things like the password use-case should be mentioned here. Security considerations aren't just about problems but also the solutions the proposal provides. > > The cases where a false negative occurs absolutely are a security concern, > > and need to be described as well. > > > > There should also be some reference to the part about signing these > > headers. (I > > view such recommendations as Mostly Harmless, but security folks like > > them.) > > > Sure, those can be added. But don't we already do that near the end of > Section 3? I was talking about a cite from the security considerations to section 3. Ned From johnl@taugh.com Sat Jul 20 19:24:03 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F0C921F8206 for ; Sat, 20 Jul 2013 19:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HJQTHcoTawvv for ; Sat, 20 Jul 2013 19:24:02 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id CAB0421F8475 for ; Sat, 20 Jul 2013 19:23:49 -0700 (PDT) Received: (qmail 96772 invoked from network); 21 Jul 2013 02:23:48 -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:cleverness; s=17a02.51eb4634.k1307; bh=6j7IRxSmpglUtMhXBtE4s/+47XfyTHXBCHtC8bJCFLM=; b=rJRe2ACsHM8IHdm0O+PuOUshvLMJK6Yj1TCLUM+mlECq+9KTD5VERdRzkh0R1Q1QGMb9FEJHyNjlhtOLeLDAoqcmejEFHcwGaSc3HitpX72PEmFXu2Jr1/Hmn+ApMenfwoBbAI9py/7yNZMv8u3pTaFXCXMKIgzMCXQlKI6TV2WdFobS52ca1jXL+ZSXfVKTI5swgYEBAEcpEGT3UMK2ZGm9fSym0Qv3PiQhvvzr3T/U9Ao5TQgts01p1Tj/ZWlt 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:cleverness; s=17a02.51eb4634.k1307; bh=6j7IRxSmpglUtMhXBtE4s/+47XfyTHXBCHtC8bJCFLM=; b=rvvtx87NczHwS4M7igAoOgzO6K7igNAOkUpTHsmitMV/z0UoEAXKeMxgGiZbyQ37raoPHc7W7iqGWSrZ35McEDd7dIkrPL26ON3gHDkp5xFb6iGibN1qEzVc+zJdTGyBSkERUyY+cqk5lkj09I1bstY5shlnRMr7npMOnrWCa8PMFFofVl12DfooxVLRdPrlr24XD5V5qi7+yuf/JQ0fcSwXF5nSNQIgnSdkMcZUc3J6LEbM00xCfaW5dH6pEglH Received: (ofmipd 127.0.0.1); 21 Jul 2013 02:23:26 -0000 Date: 20 Jul 2013 22:23:48 -0400 Message-ID: From: "John R Levine" To: "Ned Freed" In-Reply-To: <01OW8X5UAAHW000054@mauve.mrochek.com> References: <20130718202939.10687.qmail@joyce.lan> <01OW6YGX39GU000054@mauve.mrochek.com> <01OW8X5UAAHW000054@mauve.mrochek.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2013 02:24:03 -0000 >> Another thing that needs to be mentioned is use of this facility when >> an entire domain changes ownership. This is a little more complex than >> it appears because of the need for addresses like postmaster@domain.com >> to be immune to ownership changes. Huh? If I buy some abandoned domain, postmaster@foo.tld will be a different entity/person/whatever than it was for the previous owner. If you want to contact the current postmaster, send mail without an rrvs header. If you have some mailing list where the previous owner signed up as postmaster (we know it's a bad idea but people do it), then it seems to me that rrvs would be as likely to do the right thing as it would for any other address. It'd somewhat mitigate the damage if the advice to the receiver was to compare the address in the rrvs header to the envelope, if that address is one of the recipients then reject the message if the date is too old, otherwise ignore it, but unconditionally delete the header before subsequent forwarding or relaying. Even if the address in the header turns out to be one to which it is subsequently relayed, if that's not the address to which the author originally sent the message, the chances of rrvs doing the right thing seem quite low. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From wmills@yahoo-inc.com Sat Jul 20 21:20:05 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F58021F9FDE for ; Sat, 20 Jul 2013 21:20:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.473 X-Spam-Level: X-Spam-Status: No, score=-18.473 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4nDuc2OzcT0o for ; Sat, 20 Jul 2013 21:20:00 -0700 (PDT) Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) by ietfa.amsl.com (Postfix) with ESMTP id 1B3AA21F9FCC for ; Sat, 20 Jul 2013 21:19:59 -0700 (PDT) Received: from GQ1-EX10-CAHT14.y.corp.yahoo.com (gq1-ex10-caht14.corp.gq1.yahoo.com [10.73.119.195]) by mrout3.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id r6L4JBJd029575 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 20 Jul 2013 21:19:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1374380354; bh=Obd6DJEQWFKXkipkDwL9rMiZYreSSHiJrnG57qoncKQ=; h=References:Message-ID:Date:From:Reply-To:Subject:To:CC: In-Reply-To:MIME-Version:Content-Type; b=ExfaXR9KzFig+OeS1z8FxTCOpKVyWBLhvyHQXA6WFJIGVXaUyZIadD9f/9FFxImdE TLBOfeYITXrn+EFi1hvuLAc4zgOSeex0519CdbsALiRO9alB1j6DP3tpzyr2DIJPUG Iiq6yG+5BdTa8o9WtnjS1V7fx97FCVnUGGFYHFGs= Received: from omp1003.mail.ne1.yahoo.com (98.138.87.3) by GQ1-EX10-CAHT14.y.corp.yahoo.com (10.72.228.24) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sat, 20 Jul 2013 21:19:10 -0700 Received: (qmail 6545 invoked by uid 1000); 21 Jul 2013 04:19:09 -0000 Received: (qmail 2104 invoked by uid 60001); 21 Jul 2013 04:19:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1374380349; bh=TjfkMn3HpwiVeUhoyuhaTrwRndg0q10Wm92+2t3HvB8=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=nKpG3izbHZ9KELN5/A0Qq1dgwj2G6ggL+R2BVcLLnj33CWDu+Zx63aGCQg3I9O1uswxqKo7lJnVIdTr1RskUfNbkqiOK10tYcaQ0pY4N72USG9osfOixDpgT2SqMFlZI0OP2G0+8dJpVLeHTV0A1a58I4w1Wx1SrO9ALt1lXizU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=P8Cfk6Q+N7TTGa08uHZ47MqO7VwQsg+ohQJmW0TAJTpHXYM9VqXl+FzfvwS93CBhHNC96nvD+tQpPXsbuF0r3+Gp4Yd5eN1uEgQbLXxOZSVCyF6lIHH2gJjUxgS/eY67PYpNDODgv10jgYSRhuA+IdA6c1oj/GEcEldxVf4EKMI=; X-YMail-OSG: Am_WdpUVM1lcV7Z2xfzXRZkQHzbOGVX7kgYnZzpyf2BRcoU Ga99DdIEynARwdPEQnbeOvpX3gcvlTDxo5Gtbsn611urX Received: from [99.31.212.42] by web125604.mail.ne1.yahoo.com via HTTP; Sat, 20 Jul 2013 21:19:08 PDT X-Rocket-MIMEInfo: 002.001, V2VsbCwgbm90IGVudGlyZWx5LsKgIE9uZSBvZiBteSBlLW1haWwgcHJvdmlkZXJzLCBlc2tpbW8uY29tLCB0b29rIG92ZXIgbmV0Y29tLmNvbSBhbmQgY29udGludWVkIHRvIHJ1biBpdCwgYW5kIHdlIGtlcHQgY29udHJvbCBvZiBvdXIgYWNjb3VudHMgdGhlcmUuwqAgVGhhdCB1c2UgY2FzZSB3YXMgbm90IGFuIGFiYW5kb25lZCBkb21haW4sIGl0IHdhcyBhIGxvb3NlbHkgY291cGxlZCB0cmFuc2Zlci7CoCBJbiB0aGUgZW5kIHRoYXQncyBwcmV0dHkgcmFyZSB0aG91Z2gsIGFuZCB0aGV5IGNvdWxkIHNvbHYBMAEBAQE- X-Mailer: YahooMailWebService/0.8.149.560 References: <20130718202939.10687.qmail@joyce.lan> <01OW6YGX39GU000054@mauve.mrochek.com> <01OW8X5UAAHW000054@mauve.mrochek.com> Message-ID: <1374380348.1931.YahooMailNeo@web125604.mail.ne1.yahoo.com> Date: Sat, 20 Jul 2013 21:19:08 -0700 From: Bill Mills To: John R Levine , Ned Freed In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-685807438-82933711-1374380348=:1931" X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 380352000 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Bill Mills List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2013 04:20:05 -0000 ---685807438-82933711-1374380348=:1931 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Well, not entirely.=A0 One of my e-mail providers, eskimo.com, took over ne= tcom.com and continued to run it, and we kept control of our accounts there= .=A0 That use case was not an abandoned domain, it was a loosely coupled tr= ansfer.=A0 In the end that's pretty rare though, and they could solve it fo= r RRVS without changing the spec.=0A=0A=0A=A0=0A-bill=0A=0A=0A=0A----------= ----------------------=0AWilliam J. Mills=0A"Paranoid" Yahoo!=0A=0A=0A=0A= =0A________________________________=0A From: John R Levine =0ATo: Ned Freed =0ACc: IETF Apps Discuss =0ASent: Saturday, July 20, 2013 7:23 PM=0ASubject: Re: [ap= ps-discuss] Comments on draft-wmills-rrvs-header-field-00=0A =0A=0A>> Anoth= er thing that needs to be mentioned is use of this facility when an entire = domain changes ownership. This is a little more complex than it appears bec= ause of the need for addresses like postmaster@domain.com to be immune to o= wnership changes.=0A=0AHuh?=A0 If I buy some abandoned domain, postmaster@f= oo.tld will be a different entity/person/whatever than it was for the previ= ous owner.=A0 If you want to contact the current postmaster, send mail with= out an rrvs header.=A0 If you have some mailing list where the previous own= er signed up as postmaster (we know it's a bad idea but people do it), then= it seems to me that rrvs would be as likely to do the right thing as it wo= uld for any other address.=0A=0AIt'd somewhat mitigate the damage if the ad= vice to the receiver was to compare the address in the rrvs header to the e= nvelope, if that address is one of the recipients then reject the message i= f the date is too old, otherwise ignore it, but unconditionally delete the = header before subsequent forwarding or relaying.=A0 Even if the address in = the header turns out to be one to which it is subsequently relayed, if that= 's not the address to which the author originally sent the message, the cha= nces of rrvs doing the right thing seem quite low.=0A=0ARegards,=0AJohn Lev= ine, johnl@taugh.com, Taughannock Networks, Trumansburg NY=0A"I dropped the= toothpaste", said Tom, crestfallenly.=0A__________________________________= _____________=0Aapps-discuss mailing list=0Aapps-discuss@ietf.org=0Ahttps:/= /www.ietf.org/mailman/listinfo/apps-discuss ---685807438-82933711-1374380348=:1931 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Well, not= entirely.  One of my e-mail providers, eskimo.com, took over netcom.c= om and continued to run it, and we kept control of our accounts there. = ; That use case was not an abandoned domain, it was a loosely coupled trans= fer.  In the end that's pretty rare though, and they could solve it fo= r RRVS without changing the spec.

 = ;
-bill


--------------------------------
William J= . Mills
"Paranoid" Yahoo!


From: John R Levine <johnl@taugh.com>
To: Ned Freed <ned.freed@mrochek.com>
Cc: IETF Apps Discuss <apps-= discuss@ietf.org>
Sent: Saturday, July 20, 2013 7:23 PM
Subject: Re: [apps-discuss] Comments on draft-wmills-rrvs-h= eader-field-00

>&g= t; Another thing that needs to be mentioned is use of this facility when an= entire domain changes ownership. This is a little more complex than it app= ears because of the need for addresses like postmaster@domain.com to be immune to ownership changes.

Huh?  If I buy some abandoned domain, post= master@foo.tld will be a different entity/person/whatever than it was f= or the previous owner.  If you want to contact the current postmaster,= send mail without an rrvs header.  If you have some mailing list wher= e the previous owner signed up as postmaster (we know it's a bad idea but p= eople do it), then it seems to me that rrvs would be as likely to do the ri= ght thing as it would for any other address.

It'd somewhat mitigate = the damage if the advice to the receiver was to compare the address in the = rrvs header to the envelope, if that address is one of the recipients then = reject the message if the date is too old, otherwise ignore it, but uncondi= tionally delete the header before subsequent forwarding or relaying.  = Even if the address in the header turns out to be one to which it is subsequently relayed, if that's not the address to which the author origin= ally sent the message, the chances of rrvs doing the right thing seem quite= low.

Regards,
John Levine, johnl@taugh.com, Taughannock Networks,= Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.
= _______________________________________________
apps-discuss mailing lis= t
apps-discuss@ietf.org
https://www.ietf.org/mailman= /listinfo/apps-discuss


---685807438-82933711-1374380348=:1931-- From superuser@gmail.com Sun Jul 21 01:02:49 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A364221F9D7E for ; Sun, 21 Jul 2013 01:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WO2jp-+RmZ-5 for ; Sun, 21 Jul 2013 01:02:49 -0700 (PDT) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 81D4B21F9D62 for ; Sun, 21 Jul 2013 01:02:48 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id t57so332107wes.38 for ; Sun, 21 Jul 2013 01:02: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=fy8V26GCGZWkyEAdVZ/43Gr6ST4OPGzPuG9w+jEchd4=; b=KL8QUhpn50oxdK+ropfJZLuubrLZDC42tFadKgosBzOjjYXQ8VNykl8uVI9cUZ17p8 AjM43GBE99eFGCaMqV+tkeEvmXK3T5UD7pv5KSER3BHSTKeCkonb6q2GSKP/AbUxTN7k c2lX2LAzAZNx3faS2zfIwbRF8n3aRZaEArNmcDP1gq+MBGPrIv7MHMlkASO3Q2mulMms 52LWOtlfzKGRMEBCeFhLTJSxdz8twgEHsD6qAH9zCzLHWnhMfy7CdEPhMCKtban3N46c xeWlgF89GNdPPfgHZzv35miQLdLadpAMqUOFwJMUu79lRMVh37Vv+RrLXeLWQwU7MEPd JcnA== MIME-Version: 1.0 X-Received: by 10.180.102.37 with SMTP id fl5mr26465612wib.52.1374393767417; Sun, 21 Jul 2013 01:02:47 -0700 (PDT) Received: by 10.180.90.16 with HTTP; Sun, 21 Jul 2013 01:02:47 -0700 (PDT) In-Reply-To: <01OW6YGX39GU000054@mauve.mrochek.com> References: <20130718202939.10687.qmail@joyce.lan> <01OW6YGX39GU000054@mauve.mrochek.com> Date: Sun, 21 Jul 2013 01:02:47 -0700 Message-ID: From: "Murray S. Kucherawy" To: Ned Freed Content-Type: multipart/alternative; boundary=f46d044517f749dde404e200fc63 Cc: John R Levine , IETF Apps Discuss Subject: Re: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2013 08:02:49 -0000 --f46d044517f749dde404e200fc63 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jul 19, 2013 at 7:45 AM, Ned Freed wrote: > I have a lot of problems with this document as it stands. > > The biggest by far is the apparent lack of any comparison between what's > in the > header with the current message envelope. Instead the check appears solely > to > be of the form "if the address in the RRVS field is local, then check to > see if > the current usage start of that address postdates the timestamp, and if it > does > refuse delivery to all recipioents, never mind who the recipient(s) > actually > is(are)". > > There are many forms of resending and forwarding that preserve top-level > header > fields, which could easily cause false positives. Indeed, this risk can > never > be completely eliminated since it is possible that someone might resend an > old > message containing this header to the *new* owner of an address. (This case > calls for a strong recommendation that clients remove this field when doing > this sort of forwarding.) But most of the false positives can be mitigated > by > checking the address in the field against the envelope to make sure the > named > party actually is a current recipient. > Going back to this topic: I'd like to understand your problem statement a little better. Given this (and being lazy about the field name and content): -- MAIL FROM: RCPT TO: From: generator@example1 To: user@example2 RRVS: user@example2; Date: -- Assume this arrives at the "example2" mail server. The test is to determine if the server handles "example2" mail (which, by definition, it does), and then whether the named mailbox has been under continuous ownership since "". If the answer to the first is "no", ignore the field and process normally; if the answer to the second is "no", don't deliver the message. If I understand your concern, you're saying this is a problem where the message gets forwarded, let's say to other@example3. This would yield: -- MAIL FROM: RCPT TO: From: something@example1 To: user@example2 RRVS: user@example2; Date: -- Only the envelope recipient has changed; as you said, the main header fields are unmodified. Presumably though, this would land at a server that handles mail for example3 mailboxes, not example2 mailboxes. So yes, the check against the envelope would fail, but the "is this local?" test would also fail, so in this case the extra check wouldn't improve anything. If the servers handling example2 and example3 are the same server, then that same server is still in a position to evaluate the header field. What's the forwarding scenario you're imagining? Is it different from this? -MSK --f46d044517f749dde404e200fc63 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Jul 19, 2013 at 7:45 AM, Ned Freed <ned.freed= @mrochek.com> wrote:
I have a lot of problems = with this document as it stands.

The biggest by far is the apparent lack of any comparison between what'= s in the
header with the current message envelope. Instead the check appears solely = to
be of the form "if the address in the RRVS field is local, then check = to see if
the current usage start of that address postdates the timestamp, and if it = does
refuse delivery to all recipioents, never mind who the recipient(s) actuall= y
is(are)".

There are many forms of resending and forwarding that preserve top-level he= ader
fields, which could easily cause false positives. Indeed, this risk can nev= er
be completely eliminated since it is possible that someone might resend an = old
message containing this header to the *new* owner of an address. (This case=
calls for a strong recommendation that clients remove this field when doing=
this sort of forwarding.) But most of the false positives can be mitigated = by
checking the address in the field against the envelope to make sure the nam= ed
party actually is a current recipient.

= Going back to this topic:

I'd like to understand your problem st= atement a little better.=A0 Given this (and being lazy about the field name= and content):

--

MAIL FROM:<generator@example1>
RCPT TO:<user@example2>

From: generator@example1
To: user@example2
RRVS: user@example2; <Monda= y>
Date: <Today>

<some sensitive content= >

--

Assume this arrives at the "example2&= quot; mail server.=A0 The test is to determine if the server handles "= example2" mail (which, by definition, it does), and then whether the n= amed mailbox has been under continuous ownership since "<Monday>= ".=A0 If the answer to the first is "no", ignore the field a= nd process normally; if the answer to the second is "no", don'= ;t deliver the message.

If I understand your concern, you're saying t= his is a problem where the message gets forwarded, let's say to other@e= xample3.=A0 This would yield:

--

MAIL FROM:<generator= @example1>
RCPT TO:<other@example3>

From: something= @example1
To: user@example2
RRVS: user@example2= ; <Monday>
Date: <Today>

<some se= nsitive content>

--

Only the envelope recipient has changed; as you sa= id, the main header fields are unmodified.=A0 Presumably though, this would= land at a server that handles mail for example3 mailboxes, not example2 ma= ilboxes.=A0 So yes, the check against the envelope would fail, but the &quo= t;is this local?" test would also fail, so in this case the extra chec= k wouldn't improve anything.

If the servers handling example2 and example3 are the same s= erver, then that same server is still in a position to evaluate the header = field.

What's the forwarding scenario you&= #39;re imagining?=A0 Is it different from this?

-MSK
--f46d044517f749dde404e200fc63-- From superuser@gmail.com Sun Jul 21 01:08:59 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9073921F9D92 for ; Sun, 21 Jul 2013 01:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJ4Tckdpo7hs for ; Sun, 21 Jul 2013 01:08:58 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 2E69821F9D71 for ; Sun, 21 Jul 2013 01:08:57 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id f11so4994013wgh.15 for ; Sun, 21 Jul 2013 01:08:57 -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=xhGPOJhBlkNViRVK1zxhFcq7hms59zQ2Vt9VdNb6Lrw=; b=uS6AHBEkxvaGuhlSb6P5juBGG9VhD1cBGNNf8XJM7AdvfcSQsa9aNDr5X/9dZ/ZT+r yvC6WhR5wwjJDze9rPSla0Tzw1UiEPTpj4vxWopGm/EUPlHMivDt6SPjcQzaRYMksG0M LEhAIi0WAtAnKNmC839znrv97c9vpMNiefhwjk3v27kLfsMy0eC6wl74CAmCxr3PpStX x8hWkAP4BHCS5niXHQ1xWR0o5plseSo0vIa12a4DHvW3JXz4hRttblGYwzKt0nRWN5FT IYtGaaCjBFlx/LXLEKnVLt0Lw9uv8zId3Yr7iC6FXBCrrdzkjyKpa7u+DLrpmwqhp2Dc e8WQ== MIME-Version: 1.0 X-Received: by 10.180.89.231 with SMTP id br7mr26850878wib.19.1374394136165; Sun, 21 Jul 2013 01:08:56 -0700 (PDT) Received: by 10.180.90.16 with HTTP; Sun, 21 Jul 2013 01:08:55 -0700 (PDT) In-Reply-To: <01OW8X5UAAHW000054@mauve.mrochek.com> References: <20130718202939.10687.qmail@joyce.lan> <01OW6YGX39GU000054@mauve.mrochek.com> <01OW8X5UAAHW000054@mauve.mrochek.com> Date: Sun, 21 Jul 2013 01:08:55 -0700 Message-ID: From: "Murray S. Kucherawy" To: Ned Freed Content-Type: multipart/alternative; boundary=e89a8f3ba25544840d04e2011263 Cc: John R Levine , IETF Apps Discuss Subject: Re: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2013 08:08:59 -0000 --e89a8f3ba25544840d04e2011263 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Jul 20, 2013 at 6:44 PM, Ned Freed wrote: > > Would a change in language from advocating rejection to merely stressing > > that the target recipient is not actually the intended recipient be > > satisfactory? > > No, not really. Again, as far as the originator is concerned, the recipient > address they know about has been reached and it still belongs to the same > person. The mechanism's effect really needs to end there, because if you > try > and extend it all kinds of wierd stuff can happen. > > If you want another example, consider what happens when someone uses > fetchmail > to suck the mail out of a mailbox after delivery and sending it on > somewhere > else. People route mail in all kinds of ways. And yes, what people do does > lead > to problems, like when an autoforwarded message bounces back to the message > originator who then gets a bounce from an address they have never heard of > and > wonder what the hell is going on. But new mechanisms need to be designed > not to make the problems worse. > So then a "process this once and then delete it" requirement is what you have in mind? > > > I also find this paragraph: > > > > > > This header field SHOULD NOT be added to a message that is addressed > > > to multiple recipients. It is presumed that an author making use of > > > this field is seeking to protect transactional or otherwise sensitive > > > data intended for a single recipient. > > > > > > to be more than a little wierd. I send mail all the time to multiple > > > recipients > > > that I really rather not end up going to an unintended recipient. > Indeed, I > > > don't really see who the number of recipients correlates well if at all > > > with > > > data sensitivity. I think this whole thing needs to go, especially > since > > > envelope checks mostly solve the problems associated with multiple > > > recipients. > > > > > > The use case being addressed is only single-recipient messages, like > > password change requests or user-specific activity. Such things are > never > > sent to multiple users. Certainly there's a class of messages that are > > sensitive and have multiple recipients, but they're not part of this > > problem space. In that sense, allowing a list of addresses on the header > > field rather than just one creates complexity that isn't needed for the > > problem we're trying to solve. > > > That said, I'm pretty sure it doesn't clobber our use case to allow > > multiple instances of this field to be added. > > Password change requests are an easy one, because they're automated. In > fact > this makes me think about the more general use-case here of preventing a > new > "owner" of an address from finding out about an account the previous owner > had > somewhere. If I get mail - never mind what - directed at the previous > owner, > and it's one of those systems that has a "I forgot my password" button that > works by sending the password reset sequence to the registered email > address, > and the account has a stored credit card #... See the problem? > Yes, of course. That's pretty much the entire use case that started this effort. We don't state anywhere that this is intended for use with auto-generated messages only, but perhaps it would be good to mention that this is the use case we have in mind. It also answers the question about the conditions in which an author would decide to use this. > > > > > > More generally, this gets into the entire issue of when a client > should use > > > this facility. I suppose one way is to have a button you press to > request > > > "additional recipient verification" or something like that, but let's > face > > > it, > > > users aren't going to have a clue about what this does and therefore > aren't > > > going to know when to use it and when not to. The only way this makes > > > sense is > > > to use it automatically when an address comes out of the user's address > > > book. > > > And not having it work when there are muliple recipients will lead to > more > > > least astonishment principle violations. > > > > > > Is it necessary to go into this level of detail? A client uses this > > facility if the nature of the content means it's important to get to a > > particular person rather than whatever person currently owns a given > > mailbox. > > OK, so how does a client determine the nature of the content > automatically? I > don't know about anyone else, but I've written highly confidential reviews > of > things using exactly the same commands that I used to forward an article > to a > couple of friends. > I think this follows nicely from above. This isn't anticipated to be used by humans, but rather by automated things like password change requests and other sensitive but automated things. > > > Describing UI things like buttons seems to go into more specifics > > than are really required, especially since the systems implementing early > > versions are entirely backend systems that don't interact directly with > > users. > > My point wasn't that the specification should go into these sorts of > specifics, > but rather that such interfaces aren't going to work. Unless there's > something > about this I'm not seeing, The only way this works is if it works > automatically. > Right, that's the primary use case. I'm thinking we need to make that more clear. -MSK --e89a8f3ba25544840d04e2011263 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Jul 20, 2013 at 6:44 PM, Ned Freed <ned.freed= @mrochek.com> wrote:
> Would a change in language from advocat= ing rejection to merely stressing
> that the target recipient is not actually the intended recipient be > satisfactory?

No, not really. Again, as far as the originator is concerned, the rec= ipient
address they know about has been reached and it still belongs to the same person. The mechanism's effect really needs to end there, because if yo= u try
and extend it all kinds of wierd stuff can happen.

If you want another example, consider what happens when someone uses fetchm= ail
to suck the mail out of a mailbox after delivery and sending it on somewher= e
else. People route mail in all kinds of ways. And yes, what people do does = lead
to problems, like when an autoforwarded message bounces back to the message=
originator who then gets a bounce from an address they have never heard of = and
wonder what the hell is going on. But new mechanisms need to be designed not to make the problems worse.

So then= a "process this once and then delete it" requirement is what you= have in mind?
=A0
> > I also find this paragraph:
> >
> > =A0 This header field SHOULD NOT be added to a message that is ad= dressed
> > =A0 to multiple recipients. =A0It is presumed that an author maki= ng use of
> > =A0 this field is seeking to protect transactional or otherwise s= ensitive
> > =A0 data intended for a single recipient.
> >
> > to be more than a little wierd. I send mail all the time to multi= ple
> > recipients
> > that I really rather not end up going to an unintended recipient.= Indeed, I
> > don't really see who the number of recipients correlates well= if at all
> > with
> > data sensitivity. I think this whole thing needs to go, especiall= y since
> > envelope checks mostly solve the problems associated with multipl= e
> > recipients.
> >

> The use case being addressed is only single-recipient messages, like > password change requests or user-specific activity. =A0Such things are= never
> sent to multiple users. =A0Certainly there's a class of messages t= hat are
> sensitive and have multiple recipients, but they're not part of th= is
> problem space. =A0In that sense, allowing a list of addresses on the h= eader
> field rather than just one creates complexity that isn't needed fo= r the
> problem we're trying to solve.

> That said, I'm pretty sure it doesn't clobber our use case to = allow
> multiple instances of this field to be added.

Password change requests are an easy one, because they're automat= ed. In fact
this makes me think about the more general use-case here of preventing a ne= w
"owner" of an address from finding out about an account the previ= ous owner had
somewhere. If I get mail - never mind what - directed at the previous owner= ,
and it's one of those systems that has a "I forgot my password&quo= t; button that
works by sending the password reset sequence to the registered email addres= s,
and the account has a stored credit card #... See the problem?

Yes, of course.=A0 That's pretty much the entir= e use case that started this effort.

We don't state a= nywhere that this is intended for use with auto-generated messages only, bu= t perhaps it would be good to mention that this is the use case we have in = mind.=A0 It also answers the question about the conditions in which an auth= or would decide to use this.


> >
> > More generally, this gets into the entire issue of when a client = should use
> > this facility. I suppose one way is to have a button you press to= request
> > "additional recipient verification" or something like t= hat, but let's face
> > it,
> > users aren't going to have a clue about what this does and th= erefore aren't
> > going to know when to use it and when not to. The only way this m= akes
> > sense is
> > to use it automatically when an address comes out of the user'= ;s address
> > book.
> > And not having it work when there are muliple recipients will lea= d to more
> > least astonishment principle violations.
> >

> Is it necessary to go into this level of detail? =A0A client uses this=
> facility if the nature of the content means it's important to get = to a
> particular person rather than whatever person currently owns a given > mailbox.

OK, so how does a client determine the nature of the content automati= cally? I
don't know about anyone else, but I've written highly confidential = reviews of
things using exactly the same commands that I used to forward an article to= a
couple of friends.

I think this follows= nicely from above.=A0 This isn't anticipated to be used by humans, but= rather by automated things like password change requests and other sensiti= ve but automated things.
=A0

> Describing UI things like buttons seems to go into more specifics
> than are really required, especially since the systems implementing ea= rly
> versions are entirely backend systems that don't interact directly= with
> users.

My point wasn't that the specification should go into these sorts= of specifics,
but rather that such interfaces aren't going to work. Unless there'= s something
about this I'm not seeing, The only way this works is if it works
automatically.

Right, that's the pr= imary use case.=A0 I'm thinking we need to make that more clear.
-MSK
--e89a8f3ba25544840d04e2011263-- From superuser@gmail.com Sun Jul 21 01:37:36 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C092821E804E for ; Sun, 21 Jul 2013 01:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nMhCHUEcbqZk for ; Sun, 21 Jul 2013 01:37:35 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 638DB21F9E47 for ; Sun, 21 Jul 2013 01:37:35 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id m19so5044639wev.36 for ; Sun, 21 Jul 2013 01:37:34 -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=bAyOH3s5/9Cpw5RfM/rlR3nZzhUQsQ+M/+ICK6HRCFU=; b=SYx2KfNFyHnldn2v+sqS8UOFJ2x0hC2JNEmn+ARCy6eq8EU14hnw9/OW3zpdMR1CdQ py/Z9QLfUMDkgfuINjtNGXD+d7p8aQfw5AHQj4BdxlRmMgnnz8pIj4cz10HqetCEYl+f Ve0qXRxsN2mCmMYGXaV2fcSXU3cOhHJdjm78ov1jv/6XIG6yOEyUu+wwgUHULcQFAfit qF7d4O2qQN7OzxERN4IGOxe3QuRagY+0tB3LoH6TK6k0Lr/8aeobpPo7hlsZiVwnasSn PR12X1bZ+LNF6apr2MEj5aY88uFNmH+lmpx3kh2UHQYDQ9VRk6axDemJjXMvYY7A5Olz eg/w== MIME-Version: 1.0 X-Received: by 10.180.102.37 with SMTP id fl5mr26520142wib.52.1374395854278; Sun, 21 Jul 2013 01:37:34 -0700 (PDT) Received: by 10.180.90.16 with HTTP; Sun, 21 Jul 2013 01:37:34 -0700 (PDT) Date: Sun, 21 Jul 2013 01:37:34 -0700 Message-ID: From: "Murray S. Kucherawy" To: draft-levine-orgboundary@tools.ietf.org, IETF Apps Discuss Content-Type: multipart/alternative; boundary=f46d044517f7acd70804e20178a1 Subject: [apps-discuss] Comments on draft-levine-orgboundary X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 21 Jul 2013 08:37:36 -0000 --f46d044517f7acd70804e20178a1 Content-Type: text/plain; charset=ISO-8859-1 Hi there, Similar to draft-sullivan-domain-policy-authority, I'm interested in this stuff from the email authentication angle. I've offered off-list to develop this with John in terms of the text. Here I'm just talking about the mechanism itself. The mechanism provided here is fairly straightforward, but there's one limitation in particular. You use this as an example: A query to _ob.ca might yield a response that indicates boundaries at the federal, provincial, and municipal levels, such as "ob=1 ca on.ca toronto.on.ca". The issue I can see is that in fact there are domains in .ca, domains in .on.ca (and the other twelve), and domains in the municipal-level domains which as I recall number in the thousands in Canada. It would be impossible to enumerate them all in a reply to _ob.ca, certainly without switching to TCP or having some kind of indirection. Might it be better to have a reply syntax that can indicate "stuff can be registered here and up to n levels below"? For example, maybe this would work: ob=1 ca on.ca+1 bc.ca+1 ... This allows domains in ca, on.ca, bc.ca, and the rest of the province domains, and one level down from each of those (and would fit in a UDP reply), while maybe this: ob=1 ca on.ca/1 bc.ca/1 ... ...allows domains in ca, and then one below on.ca and bc.ca and the province domains but not directly in them. It also doesn't handle all of the use cases as Andrew's document does. The one in particular that's of interest is the "two related domains" use case that's popped up lately in the DNS groups. It would be great to tackle that as well, but that may be wishful thinking here. -MSK --f46d044517f7acd70804e20178a1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi there,

Similar to= draft-sullivan-domain-policy-authority, I'm interested in this stuff f= rom the email authentication angle.

I've offered off-list = to develop this with John in terms of the text.=A0 Here I'm just talkin= g about the mechanism itself.

The mechanism provided here is fairly straightforward, but there&= #39;s one limitation in particular.=A0 You use this as an example:

<= /div>A query to _ob.ca might yield a response = that indicates boundaries at the federal, provincial, and municipal levels,= such as "ob=3D1 ca on.ca toronto.on.ca".=A0 The issue I can see is that i= n fact there are domains in .ca, domains in .on.ca= (and the other twelve), and domains in the municipal-level domains whi= ch as I recall number in the thousands in Canada.=A0 It would be impossible= to enumerate them all in a reply to _ob.ca, c= ertainly without switching to TCP or having some kind of indirection.=A0 Mi= ght it be better to have a reply syntax that can indicate "stuff can b= e registered here and up to n levels below"?

For example, maybe this would work:

ob=3D1= ca on.ca+1 bc.ca= +1 ...

This allows domains in ca, on.ca, bc.ca, and the rest of the provin= ce domains, and one level down from each of those (and would fit in a UDP r= eply), while maybe this:

ob=3D1 ca on.ca/1 bc.ca/1 ...

...allows domains in ca, = and then one below on.ca and bc.ca and the province domains but not directly in them.

It also doesn't handle all of the use cases a= s Andrew's document does.=A0 The one in particular that's of intere= st is the "two related domains" use case that's popped up lat= ely in the DNS groups.=A0 It would be great to tackle that as well, but tha= t may be wishful thinking here.

-MSK
--f46d044517f7acd70804e20178a1-- From sm@elandsys.com Sun Jul 21 02:18:30 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6883321E804E; Sun, 21 Jul 2013 02:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.616 X-Spam-Level: X-Spam-Status: No, score=-102.616 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cqcICa9OGeqg; Sun, 21 Jul 2013 02:18:29 -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 B23A311E80CC; Sun, 21 Jul 2013 02:18:29 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.151.133]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r6L9IEOi013081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 21 Jul 2013 02:18:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1374398307; bh=TryA9Pix6FYjnKV7DrffRyR2Ev0lDo4Zq2XvxWpxsos=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=V7cDnfYP/bbVgcrnEpY9YIpYMtS8WyPOgqFIWiYUbsew6KqjvRoyq5cU0i94pEILY bD41nmxIk0zcbRJ8IyJMxUcgaQWE6Qb2Hzb1a0Nu9EOuggxgcaQQ4kWZ5poAVl0ASn GDRpTV9LqDiZuM1GeoeEIkk4/9jVpbjbofViG4Ng= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1374398307; i=@elandsys.com; bh=TryA9Pix6FYjnKV7DrffRyR2Ev0lDo4Zq2XvxWpxsos=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=an1jB+zHKjCI9Ad1Zq9cJSrIIjXcG3AfgY+G2dx2TvNgIRzVg8b1Cbv6QL8oHIdy0 eOrg74ci6OxVee9q+fweTsb79tt2TUKTgaNEXS+OcarUUMX6AJdFdAy6glJW0mzp81 1Foikg7t7f/ZTUDFyGU2yqJcHH74kUvUzQJPWL2I= Message-Id: <6.2.5.6.2.20130721013208.0bc61938@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 21 Jul 2013 02:16:54 -0700 To: apps-discuss@ietf.org From: S Moonesamy In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: iesg@ietf.org Subject: Re: [apps-discuss] Comments solicited on the desired expertise for ADs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 21 Jul 2013 09:18:30 -0000 At 10:20 17-07-2013, Applications Area Directors wrote: >...and for the desired expertise for Applications ADs: >http://trac.tools.ietf.org/group/iesg/trac/wiki/AppsExpertise > >Please send us comments right away, as the IESG will soon have to send >a final set to the NomCom. You may comment on this list, >. If you prefer, you may also send comments to This message is not actionable. Feel free to ignore. I have been following the Applications Area for some time now. It has changed over the years. My guess is that there is reduced activity within the area for obvious reasons. I see recurring participants in the different working groups. It is like relying on the same set of people to get work done. The area is not drawing in new people. There are things which do not work in the area. One of the failures has been internationalization. This failure affects work in other areas. Please note that this has nothing to do with Application Area Directors. It would probably have happened no matter who was chosen as Area Director. The Application Area has lost the ability to reach out to new technology communities. A significant number of these communities are informal instead of your regular SDO. I'll quote Harald Alvestrand: "Working groups need a task they can complete. They need chairs that are willing and able to get the hard questions asked, get a decision out, and PUBLISH. Review panels need to have competent people on them, and they need to be able to say NO at need." In the drive for success it is politically incorrect to admit failure. This is an IETF-wide issue. Regards, S. Moonesamy From johnl@taugh.com Sun Jul 21 06:16:15 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74EED11E80E7 for ; Sun, 21 Jul 2013 06:16:15 -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=[AWL=0.032, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JLLLQDx44puF for ; Sun, 21 Jul 2013 06:16:14 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 40C8211E80D9 for ; Sun, 21 Jul 2013 06:16:14 -0700 (PDT) Received: (qmail 126 invoked from network); 21 Jul 2013 13:16:13 -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:cleverness; s=7d.51ebdf1d.k1307; bh=mcPM5QrzoIHmNJa3/3sKTiPeH27Akqi0s3zOP5kZmbY=; b=PsWrSDCZIjCb9ZkdVfsZ5ys2WBR9IwSiKsrD45/TcTR6IkTzorZN1hKg88wExZKZLYwmR7mw4CiHcCCOkSGH97kw8dYXVNrZM1GvPv4dELV7K+a2GgNb6Op9qQTWMoi+2CGgi93ytJDFLl/hYcoMhFOBTBMJoWJsiN2785tGECewX0nYmqp53aa82V2R2nLM1OgRLmPT9pzE7EH7v2L8ippcv7y/wzXstV96lhe4v4xBNnM9y4woS7oMWMwCYWdh 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:cleverness; s=7d.51ebdf1d.k1307; bh=mcPM5QrzoIHmNJa3/3sKTiPeH27Akqi0s3zOP5kZmbY=; b=VDOqojxtI2TcwOKVj5UzroZ0hzJ6+2zN0Y/cB3KSdEGOo3Nb30dMn0SI0SZsPMb6D2HGZ4XDpm5SyCsRXNLmsgvWqTzYIM+/eXDPFvTP3SGdGgBabFaGT46npWaVg+1F8wMKRfDN3woPse1vwxaQSs69bTVqj64jlxDi7be1tTC4ff/rIjY3fGQ9ts/zK3a70wlSxOQe3d3r8+meKtYbErHc6eAS5xEOntLtOwPfB2N6PnZjhG6UHPVuSU52Hout Received: (ofmipd 127.0.0.1); 21 Jul 2013 13:15:51 -0000 Date: 21 Jul 2013 09:16:12 -0400 Message-ID: From: "John R Levine" To: "Murray S. Kucherawy" In-Reply-To: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: MULTIPART/signed; protocol="application/pkcs7-signature"; micalg=sha1; BOUNDARY="3825401791-2127892046-1374412573=:15183" Cc: IETF Apps Discuss Subject: Re: [apps-discuss] [taugh.com-standards] Comments on draft-levine-orgboundary X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 21 Jul 2013 13:16:15 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --3825401791-2127892046-1374412573=:15183 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > A query to _ob.ca might yield a response that indicates boundaries at the > federal, provincial, and municipal levels, such as "ob=1 ca on.ca > toronto.on.ca". The issue I can see is that in fact there are domains in > .ca, domains in .on.ca (and the other twelve), and domains in the > municipal-level domains which as I recall number in the thousands in > Canada. It would be impossible to enumerate them all in a reply to _ob.ca, > certainly without switching to TCP or having some kind of indirection. > Might it be better to have a reply syntax that can indicate "stuff can be > registered here and up to n levels below"? Unfortunately, that doesn't work. aaa.foo.ontario.ca and bbb.foo.ontario.ca are the same entity aaa.toronto.ontario.ca and bbb.toronto.ontario.ca are not This argues for going back to the wildcard hack, with records like *.ontario._ob.ca TXT "ontario.ca" *.toronto.ontario._ob.ca TXT "toronto.ontario.ca" These have lousy DNS cache behavior, but the closest encloser rule means that you can find the cut point for any domain with one UDP lookup. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. --3825401791-2127892046-1374412573=:15183 Content-Type: APPLICATION/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: BASE64 Content-Description: S/MIME Cryptographic Signature Content-Disposition: attachment; filename=smime.p7s MIIJCQYJKoZIhvcNAQcCoIII+jCCCPYCAQExCzAJBgUrDgMCGgUAMAsGCSqG SIb3DQEHAaCCBjowggY2MIIFHqADAgECAgMGLywwDQYJKoZIhvcNAQEFBQAw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTAeFw0xMzAzMTYxOTQ0MDdaFw0xNDAzMTgxMjI4MzVaMFUxGTAX BgNVBA0TEHFaMXRuOTBuMkdVODZzemYxGDAWBgNVBAMMD2pvaG5sQHRhdWdo LmNvbTEeMBwGCSqGSIb3DQEJARYPam9obmxAdGF1Z2guY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAve/4NFMbuvtD6QSuXAoYQ0SkaO9s DiNHA4saJNV0OIXd6dtM87w7OETKWWVq24Ab6vQaYh218oCF1GDdLv6EiRB8 oL1k9sK2v70iAVT83vEnmaj6/hQVcBI6mZJH6LXyCgYSP2e5yBQqJu+hgLte bdg7kOKW2tb937jDn9KYRVFIlEU0/iu/b/Buwq3ahg2BsG3vg92Zk+Dv5VON QDLE8x8wdi1cor7qBY/RERw4O3LXo3644OU0t6KS3aQxLrXEvWZHHvLhsAu1 BjYbC+qdSddDT1t+adEnZq9/wMhNGhPWCd/uFDZanSpyM913b7eI1Q2aNgA0 cccjEgBsp8IipwIDAQABo4IC1TCCAtEwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSL djRDW8NpGZJjlhjZ0SLge0hCvjAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6W NU7y1LhRgjAaBgNVHREEEzARgQ9qb2hubEB0YXVnaC5jb20wggFMBgNVHSAE ggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0 cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYIKwYBBQUHAgIw geowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqB vlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhl IENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0 Q29tIENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVk IHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBv YmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFy dHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5Bggr BgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEv Y2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNv bS9jZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYY aHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQCM pgcOpxRJazPzEBYnhGENuQqzXeLyA3a8XL7YaxaAJwV7ucDVkyQHu35PUEkh vVgIKnxq6N9WxHiO6GK/imdwS3LrUBbs+0v+95m6YhJv6ZfvAHTyTLqrozXU ohR5NRFeL0p1OfK1llnl/I71Fe/JNgxJHDn1puzsFoJD3zYCKgNdST3FPNIb 2v/xIiubuB85tiJSWUlc56OkCdBK3ZgBnwYV8LxFmpOlwedaHC6sxIk1rsuX BHbRIJwLFy2LqVtNm0M5NzBVyPQf72lPn/aaJLbqY5DDm4/lSy94R+CKXabE 6lWan7xmbqdDDlMxGbpMRWV2Cxi5ONp4uNgNcwI6MYIClzCCApMCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQQIDBi8sMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNzIxMTMxNjEzWjAjBgkqhkiG 9w0BCQQxFgQUqSxtJOEMOH7nZDocX1QDCOwRXSMweQYJKoZIhvcNAQkPMWww ajALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4D AgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAh0frRhzBIUby hXskYW0uRaoeLRwfWEHrPbuZYP1ILtv0LP0IV3qJ+800PbnlBGEKb1q84d43 /FmA22CLn7b5GFOn22A9knGGK1/vf2UAPm96unzeTWrTB6b/CtjN6g8Q21Bw mFu547M7CwpbrEB4KUybPQw5kO6xT2Tov/qVoj8BGGYB1RLluF/UWknYnGfU LR+3HW7dLyxZ5HpMfD2x5M4CCVie5VEZyqhGzdtDfqL5MRTrrgBnXo1UmETd eSgE+raMUH9Wr07Ep3KVUVjXXhAgdoP4IHtxsru/SotjiVl9I13KlerD+FWG NjoDk92qFZ2Tn6VsMSFGitLWnjOekw== --3825401791-2127892046-1374412573=:15183-- From ned.freed@mrochek.com Sun Jul 21 07:52:45 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E8E821F9FCC for ; Sun, 21 Jul 2013 07:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LRYBxoPLwe0p for ; Sun, 21 Jul 2013 07:52:40 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 61ABB21F9DBA for ; Sun, 21 Jul 2013 07:52:37 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OW9NQC65UO00A1VO@mauve.mrochek.com> for apps-discuss@ietf.org; Sun, 21 Jul 2013 07:47:33 -0700 (PDT) MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=iso-8859-1 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OW6SL60ZBK000054@mauve.mrochek.com>; Sun, 21 Jul 2013 07:47:29 -0700 (PDT) Message-id: <01OW9NQ9H7E2000054@mauve.mrochek.com> Date: Sun, 21 Jul 2013 07:42:00 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sun, 21 Jul 2013 01:02:47 -0700" References: <20130718202939.10687.qmail@joyce.lan> <01OW6YGX39GU000054@mauve.mrochek.com> To: "Murray S. Kucherawy" Cc: John R Levine , Ned Freed , IETF Apps Discuss Subject: Re: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2013 14:52:45 -0000 > Going back to this topic: > I'd like to understand your problem statement a little better. Given this > (and being lazy about the field name and content): > -- > MAIL FROM: > RCPT TO: > From: generator@example1 > To: user@example2 > RRVS: user@example2; > Date: > > -- No. The concern is when the RRVS header says: RRVS: other@example3; This sort of thing happens when messages are resent without encapsulation. > Assume this arrives at the "example2" mail server. The test is to > determine if the server handles "example2" mail (which, by definition, it > does), and then whether the named mailbox has been under continuous > ownership since "". If the answer to the first is "no", ignore the > field and process normally; if the answer to the second is "no", don't > deliver the message. > If I understand your concern, you're saying this is a problem where the > message gets forwarded, let's say to other@example3. This would yield: > -- > MAIL FROM: > RCPT TO: > From: something@example1 > To: user@example2 > RRVS: user@example2; > Date: > > -- > Only the envelope recipient has changed; as you said, the main header > fields are unmodified. Presumably though, this would land at a server that > handles mail for example3 mailboxes, not example2 mailboxes. So yes, the > check against the envelope would fail, but the "is this local?" test would > also fail, so in this case the extra check wouldn't improve anything. > If the servers handling example2 and example3 are the same server, then > that same server is still in a position to evaluate the header field. > What's the forwarding scenario you're imagining? Is it different from this? Yes. See above. And there's also the case of intentional inclusion of such things to consider, which could allow probing of what happens to mail after it reaches the address the originator specified as the destination. Ned From kewisch@gmail.com Sun Jul 21 10:36:54 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29EEB21F9DBA; Sun, 21 Jul 2013 10:36:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hg-35TDLWKyG; Sun, 21 Jul 2013 10:36:53 -0700 (PDT) Received: from mail-ea0-x22a.google.com (mail-ea0-x22a.google.com [IPv6:2a00:1450:4013:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 6388321E808B; Sun, 21 Jul 2013 10:36:46 -0700 (PDT) Received: by mail-ea0-f170.google.com with SMTP id h10so3461872eaj.1 for ; Sun, 21 Jul 2013 10:36:45 -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 :references:in-reply-to:content-type:content-transfer-encoding; bh=4C9D//UGg8CV9Bs+vR0oeY9SfTVtZDbreLiapiBk2uQ=; b=G4V+rMCQ/izrtK12QT4zlxFwRBlsmFTXJtu4ddvMs3iSDKHGmfKqLBNLU/KnM+JcDq BI1Xosl2EmGe1DWvdBfOuEYX5KfxQvZcalIvjhZ6QDLdNe4IetN7aFgE2S0TAgOsAhpx QtdIf5ly+gn+q4fhdwOGscxQUdgTIv51fOT5+Jj8tbg+OVS7SpBBrFUhpWhq/hIgU5Vf Gnxpa4yk+/ymChT4Lm15HVjbjCSiXLBYSb5GjpATRSpsNrqAbdJq/GE8cwpjme3MEHj3 uSYTpjaa6s+3Bq5DbHQ675B4DRNVa8KAz1QKY7dtwP5tixGQgPX0wbXZvAs1HkBq4bqc PuOQ== X-Received: by 10.15.41.196 with SMTP id s44mr24047578eev.138.1374428205319; Sun, 21 Jul 2013 10:36:45 -0700 (PDT) Received: from oskar.fritz.box (g231164173.adsl.alicedsl.de. [92.231.164.173]) by mx.google.com with ESMTPSA id l42sm44376883eeo.14.2013.07.21.10.36.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 21 Jul 2013 10:36:44 -0700 (PDT) Message-ID: <51EC1C2B.3070605@gmail.com> Date: Sun, 21 Jul 2013 19:36:43 +0200 From: Philipp Kewisch User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:22.0) Gecko/20100101 Thunderbird/22.0 MIME-Version: 1.0 To: Claudio Allocchio , draft-ietf-jcardcal-jcard.all@tools.ietf.org, apps-discuss@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IESG Subject: Re: [apps-discuss] AppsDir review of draft-ietf-jcardcal-jcard-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 21 Jul 2013 17:36:54 -0000 On 7/18/13 10:16 AM, Claudio Allocchio wrote: > > > Minor Issues: > > Conventions Used in thei document: > > There were many discussions in the past about using "large quotings > from other documents or just 'pointing to them'. I do nderstand that > in this draft the quoting is ""partial" JSON documents used for > illustrative purposes." but we should be careful in this! Could you elaborate on this? This is my first RFC so I may not be aware of all past discussion. As this format just makes use of JSON and is a different representation for iCalendar, I personally think its valid to point to these documents. > > Nits: > > Intoduction: there is a duplicate paragraph! Taken care of. Not sure how that got there! From superuser@gmail.com Sun Jul 21 12:42:22 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C22E711E8103 for ; Sun, 21 Jul 2013 12:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yfb2KAOsxUrb for ; Sun, 21 Jul 2013 12:42:22 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id B0C4C11E8100 for ; Sun, 21 Jul 2013 12:42:21 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id f11so5291377wgh.15 for ; Sun, 21 Jul 2013 12:42:20 -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=bAl31OvSVh6fBPWA0dGaA1Nn8iJcYo9M9A3mdbnPAsk=; b=Hc2IBUvHlM5sDmQpbsYId7OJSGiiAXc3NLgPSN4IjM7egyeUVOT88N0iSFlt3/LI2C YE09aZ9wR+iaMjgVXqV9gD0LTpO5KEcG4xj9VqACucNfCg40tKBTrBjfs7zmt45q/Sbp QrOMdLhJyePYL6YEMZ6kUieGQ8zf9IN5dLqCo2F3JxEEHNSnwaS2vqKolaxkWTxt5q7K 5tVfXOelnnT/CSuBlyblVDP5g3/IQ8IoSvvtnZZvRMVPevAtzIcU3qsh0qsTeRNOVUyX bnIyky3wEcpsMiyVCEIEKlBX5SC72OOQyW2jdfCuIXA5NoxXqSOgH5qjTtJJ+fjlmndv wupQ== MIME-Version: 1.0 X-Received: by 10.180.20.228 with SMTP id q4mr3384756wie.60.1374435740048; Sun, 21 Jul 2013 12:42:20 -0700 (PDT) Received: by 10.180.90.16 with HTTP; Sun, 21 Jul 2013 12:42:19 -0700 (PDT) In-Reply-To: References: Date: Sun, 21 Jul 2013 12:42:19 -0700 Message-ID: From: "Murray S. Kucherawy" To: John R Levine Content-Type: multipart/alternative; boundary=f46d042184850d66d304e20ac202 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] [taugh.com-standards] Comments on draft-levine-orgboundary X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 21 Jul 2013 19:42:22 -0000 --f46d042184850d66d304e20ac202 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Jul 21, 2013 at 6:16 AM, John R Levine wrote: > > This argues for going back to the wildcard hack, with records like > > *.ontario._ob.ca TXT "ontario.ca" > *.toronto.ontario._ob.ca TXT "toronto.ontario.ca" > > These have lousy DNS cache behavior, but the closest encloser rule means > that you can find the cut point for any domain with one UDP lookup. > Is there any hope that we could encourage implementers to cache these in the application, since they're likely to change only rarely anyway? -MSK --f46d042184850d66d304e20ac202 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sun, Jul 21, 2013 at 6:16 AM, John R Levine <johnl@tau= gh.com> wrote:

This argues for going back to the wildcard hack, with records like

=A0*.ontario._ob.ca TXT &quo= t;ontario.ca"
=A0*.toronto.ontario._ob.ca = TXT "toronto.o= ntario.ca"

These have lousy DNS cache behavior, but the closest encloser rule means th= at you can find the cut point for any domain with one UDP lookup.

Is there any hope that we could encourage implementer= s to cache these in the application, since they're likely to change onl= y rarely anyway?

-MSK
--f46d042184850d66d304e20ac202-- From johnl@taugh.com Sun Jul 21 15:26:51 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DDF021F8E2A for ; Sun, 21 Jul 2013 15:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fJGxnv7OnHgq for ; Sun, 21 Jul 2013 15:26:50 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE1421F84D9 for ; Sun, 21 Jul 2013 15:26:49 -0700 (PDT) Received: (qmail 99946 invoked from network); 21 Jul 2013 22:26:47 -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:cleverness; s=18668.51ec6027.k1307; bh=U0tLVGmtGtnSALhQ71wHAf4+pHTrcHyC8jX9dN/Cl/w=; b=IOdXcYoFPghxit/1bE7n9qrAwCitDbHFX/Iw/Xz3OuwoP3AQKicZVOmhMDjFvEE9O7s3yaWRgAiyAvhTKx+6ZhzI/NdnLJ1s7xL7HjP9mlBQxNde6pNz5dXw3N9CuTjp0pSfjMSogx1msA2aAtkobVfrB5TayDpbm/PfXS+X5fAqxbpSCPF46Vs8Lx36Qo7iFsl2h17/8WixG2xnM2Rsauf8U91cYnKKVnrBIWOxHNYsJ7n/YCNx1bHJjxHOolpd 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:cleverness; s=18668.51ec6027.k1307; bh=U0tLVGmtGtnSALhQ71wHAf4+pHTrcHyC8jX9dN/Cl/w=; b=o8ic+GwGfJa7+GkxEcfF10iwKcBo5GHDuUJjxIJCOqcT5hi8joqEDa2EbTrCm5hjQLyz83laTkvH9QMoRJ7S5z+hwwJI9WNFAX8Sw/rIyMWyXhXLP3BdvBgyVITSWGAZ/nBUx8udx3yMoUNS9qvtdZYHrGSsIZKwWFuBceeiCxp+993gwtcYBQSC+gg2LMeBTUT2cv1/QueWQSNfdMpvTBY/lpHLXLyFfleXY04wBxjBRMz06BWMVy0Du7f44i+0 Received: (ofmipd 127.0.0.1); 21 Jul 2013 22:26:24 -0000 Date: 21 Jul 2013 18:26:46 -0400 Message-ID: From: "John R Levine" To: "Murray S. Kucherawy" In-Reply-To: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IETF Apps Discuss Subject: Re: [apps-discuss] [taugh.com-standards] Comments on draft-levine-orgboundary X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 21 Jul 2013 22:26:51 -0000 >> This argues for going back to the wildcard hack, with records like >> >> *.ontario._ob.ca TXT "ontario.ca" >> *.toronto.ontario._ob.ca TXT "toronto.ontario.ca" >> >> These have lousy DNS cache behavior, but the closest encloser rule means >> that you can find the cut point for any domain with one UDP lookup. > > Is there any hope that we could encourage implementers to cache these in > the application, since they're likely to change only rarely anyway? The lousy cache behavior is that every different name is a different lookup, even if it comes from the same wildcard, e.g., foo.com, www.foo.com, bar.com, www.bar.com, etc. Repeated queries for the same name cache just fine, give or take the cache being too small. The question is whether the rate at which hosts look for these things will be high enough to matter. It seems unlikely they'd be as frequent as rDNS queries, and those cache just as badly. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From superuser@gmail.com Sun Jul 21 18:10:28 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B72DD21F9C32 for ; Sun, 21 Jul 2013 18:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4aKRn-BT42IN for ; Sun, 21 Jul 2013 18:10:24 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 7182921F9A50 for ; Sun, 21 Jul 2013 18:10:24 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id a12so5341299wgh.28 for ; Sun, 21 Jul 2013 18:10:23 -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=7aSPLUx0v/j23YYsXjmcWc9PctzByRZ7BSoij0riWJg=; b=zDoRWQI2LnpOQiFi3J/fhYzYuogQlSrN06cjQlWbBznuglpWG+voPvltXLgKHeN30q a840WuoxbKq61JfdUeKbLhqdylws6Qs13rQQJSN13fCwVsWGE4tWjRy9/JvNpSC6uGQw IBtQsngOPIGRgLqyZ+Te0rCLnKc2AOzT8DPfBb1T5GpG61A0uGuc+VUH3ZhCo7nEAOf4 S1QghFz7kZ0yc8YdDps4vmtUU5uqAl3SO/Ol0H04qDMPQcwp0w2gux/aUgbbj6fZN4Jn +L4z+Osun3c6TFZMldkLaXydVInATL35m7by6UGZ68inOGbXi6WtMVtnXqIDRa/7wOx5 w0DA== MIME-Version: 1.0 X-Received: by 10.194.48.116 with SMTP id k20mr18262420wjn.23.1374455423560; Sun, 21 Jul 2013 18:10:23 -0700 (PDT) Received: by 10.180.90.16 with HTTP; Sun, 21 Jul 2013 18:10:23 -0700 (PDT) In-Reply-To: References: Date: Sun, 21 Jul 2013 18:10:23 -0700 Message-ID: From: "Murray S. Kucherawy" To: John R Levine Content-Type: multipart/alternative; boundary=047d7ba975e647f42804e20f5709 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] [taugh.com-standards] Comments on draft-levine-orgboundary X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jul 2013 01:10:29 -0000 --047d7ba975e647f42804e20f5709 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Jul 21, 2013 at 3:26 PM, John R Levine wrote: > This argues for going back to the wildcard hack, with records like >>> >>> *.ontario._ob.ca TXT "ontario.ca" >>> *.toronto.ontario._ob.ca TXT "toronto.ontario.ca" >>> >>> These have lousy DNS cache behavior, but the closest encloser rule means >>> that you can find the cut point for any domain with one UDP lookup. >>> >> >> Is there any hope that we could encourage implementers to cache these in >> the application, since they're likely to change only rarely anyway? >> > > The lousy cache behavior is that every different name is a different > lookup, even if it comes from the same wildcard, e.g., foo.com, > www.foo.com, bar.com, www.bar.com, etc. Repeated queries for the same > name cache just fine, give or take the cache being too small. > > The question is whether the rate at which hosts look for these things will > be high enough to matter. It seems unlikely they'd be as frequent as rDNS > queries, and those cache just as badly. > Couldn't application level caching with some knowledge of this system reduce the lousy caching? For example, if through this system you can learn that .com is a point below which all domains are in their own OB, you don't need to look up _ob.com anymore (or at least not for a really long time). -MSK --047d7ba975e647f42804e20f5709 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sun, Jul 21, 2013 at 3:26 PM, John R Levine <johnl@tau= gh.com> wrote:
This argues for going back to the wildcard hack, with records like

=A0*.ontario._ob.ca TXT &quo= t;ontario.ca"
=A0*.toronto.ontario._ob.ca = TXT "toronto.o= ntario.ca"

These have lousy DNS cache behavior, but the closest encloser rule means that you can find the cut point for any domain with one UDP lookup.

Is there any hope that we could encourage implementers to cache these in the application, since they're likely to change only rarely anyway?

The lousy cache behavior is that every different name is a different lookup= , even if it comes from the same wildcard, e.g., foo.com, www.foo.com, bar.com= , www.bar.com, etc= . =A0Repeated queries for the same name cache just fine, give or take the c= ache being too small.

The question is whether the rate at which hosts look for these things will = be high enough to matter. =A0It seems unlikely they'd be as frequent as= rDNS queries, and those cache just as badly.

Couldn't application level= caching with some knowledge of this system reduce the lousy caching?=A0 Fo= r example, if through this system you can learn that .com is a point below = which all domains are in their own OB, you don't need to look up _ob.com anymore (or at least not for a really long = time).

-MSK
--047d7ba975e647f42804e20f5709-- From johnl@iecc.com Sun Jul 21 18:24:46 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04AC521F9C32 for ; Sun, 21 Jul 2013 18:24:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.862 X-Spam-Level: X-Spam-Status: No, score=-110.862 tagged_above=-999 required=5 tests=[AWL=0.337, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ed4l-GMIqaNf for ; Sun, 21 Jul 2013 18:24:42 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id B046821F9ADD for ; Sun, 21 Jul 2013 18:24:41 -0700 (PDT) Received: (qmail 29969 invoked from network); 22 Jul 2013 01:24:40 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 22 Jul 2013 01:24:40 -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=51ec89d8.xn--i8sz2z.k1307; i=johnl@user.iecc.com; bh=0j2P0aqOBf6zOVRvzMtT2UsmhPjAJX2erDs938hvNJk=; b=1vsN6f86yx3T1U2BC/VvuLOjEfy4urXa6G1LnS1Eq6iX+YpGfXSVngRLiPWI09PCexLcRjW8QVT4d359nfDoKivabfeZBlJ8VOtRv+ZURaRxihIOHrrQZr1YxbbaQOsBYKQEOUEdI14N+aqI1uieM845LF6gHtxsl9xc4PwGnUVjL8+a/urCl6F02QL7qfaA2xBK+PpPz2cV3BYlnkGxIHhAqZXKU/ksygTN9uLr1ElazS/Wn+sV3M2pumooZZwT 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=51ec89d8.xn--i8sz2z.k1307; olt=johnl@user.iecc.com; bh=0j2P0aqOBf6zOVRvzMtT2UsmhPjAJX2erDs938hvNJk=; b=erm01ULkJ0cnkKSMpUk5IopTAIHef6peijeGK+8bK50Sf2gAmUrjNCm56EFILId/3NAkPRklOGkm4tnC9hjUdv/ZbwcVg3wCa0DFEIJP9+OBSzJOby7q0h5hd1y3nnaPitnfQTG3H4UlbFKWzKtuFmtCnp9hR+qanQ/GzTQ2sL4/nyPG9+uQTi8DFrB0MeinOihouQikRmBKIwzkfWaZjayajJDut987QixEE1jdSH8S6z5iFeYZxCSFp6PbsYrd Date: 22 Jul 2013 01:24:18 -0000 Message-ID: <20130722012418.54689.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 Subject: Re: [apps-discuss] [taugh.com-standards] Comments on draft-levine-orgboundary X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jul 2013 01:24:46 -0000 >> The question is whether the rate at which hosts look for these things will >> be high enough to matter. It seems unlikely they'd be as frequent as rDNS >> queries, and those cache just as badly. > >Couldn't application level caching with some knowledge of this system >reduce the lousy caching? For example, if through this system you can >learn that .com is a point below which all domains are in their own OB, you >don't need to look up _ob.com anymore (or at least not for a really long >time). That takes us back to my other plan, where _ob.com was a large text record that had all the info in it. I suppose we might have a flag for "nothing interesting below here", so that if you fetch the record for foo.bar._ob.com, it has the flag set so you know you can reuse that for any subsequent lookup in *.com, but the record for foo.on._ob.ca does not have the flag, since there are cut points below that. Or it could have a pointer to where to download the whole table for .ca for sites that are big enough to do local caching. Of course, this assumes that you believe that there actually isn't anything interesting below .com. If you look at the current public suffix list, they don't. It's a mess. My impression is that the DNS is robust enough that it's not worth a lot of effort to try to cut down query rates unless you know that the query rate is totally absurd. That's why I'm not working on the B-tree DNSBL stuff any more, even with address hopping the DNS can likely tolerate a query per e-mail, particularly since the busiest clients generally made side deals to provide local mirrors. R's, John From ned.freed@mrochek.com Sun Jul 21 19:19:39 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8D9B21F9D39 for ; Sun, 21 Jul 2013 19:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.065 X-Spam-Level: X-Spam-Status: No, score=-2.065 tagged_above=-999 required=5 tests=[AWL=-0.534, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O+xzhLPPO8MW for ; Sun, 21 Jul 2013 19:19:28 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id CDCEC21F9A99 for ; Sun, 21 Jul 2013 19:19:27 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OWABPW0W4G00AAJ9@mauve.mrochek.com> for apps-discuss@ietf.org; Sun, 21 Jul 2013 19:14:23 -0700 (PDT) MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=iso-8859-1 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OW6SL60ZBK000054@mauve.mrochek.com>; Sun, 21 Jul 2013 19:14:19 -0700 (PDT) Message-id: <01OWABPTPSU0000054@mauve.mrochek.com> Date: Sun, 21 Jul 2013 08:44:07 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sun, 21 Jul 2013 01:08:55 -0700" References: <20130718202939.10687.qmail@joyce.lan> <01OW6YGX39GU000054@mauve.mrochek.com> <01OW8X5UAAHW000054@mauve.mrochek.com> To: "Murray S. Kucherawy" Cc: John R Levine , Ned Freed , IETF Apps Discuss Subject: Re: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 02:19:39 -0000 > > If you want another example, consider what happens when someone uses > > fetchmail > > to suck the mail out of a mailbox after delivery and sending it on > > somewhere > > else. People route mail in all kinds of ways. And yes, what people do does > > lead > > to problems, like when an autoforwarded message bounces back to the message > > originator who then gets a bounce from an address they have never heard of > > and > > wonder what the hell is going on. But new mechanisms need to be designed > > not to make the problems worse. > > > So then a "process this once and then delete it" requirement is what you > have in mind? No, because you can't be sure that the processing will occur, so it creates even more astonishment. And I don't see how this could be implemented while retaining the semantics given in the specification in any case. My objection was and is to the semantics the current draft calls for. It says: 1. A user subscribes to a service "S" on data "D" and confirms an email address at the user's current location, "A"; 2. At some later date, the user intends to leave the current location, and thus creates a new mailbox elsewhere, at "B"; 3. The user replaces mailbox "A" with forwarding to "B"; 4. "S" constructs a message to "A" claiming that address was valid at date "D" and sends it to "A", which forwards to "B"; 5. The receiving MTA at "B" asserts that "B" has not been under constant ownership since "D" and rejects the message. I think the result in 5 is flat out wrong, and what should be happening is exactly the opposite: The message goes through and is delivered. First of all, as I noted previously, there is no way to actually implement these semantics in a fashion that's consistent with what's in the draft. If mailboxes A and B are under different administrative domains - and they often will be - then implementing these semantics directly contradicts the semantics called for in section 3 because address "A" in the RRVS field is going to be seen as foreign by the receiving MTA at "B" and ignored. So unless we're simply going to ignore the recipient address in the RRVS field entirely - and in that case why is it even there - the behavior you're going to get is going to be wildly inconsistent. (Of course behavior is going to be wildly inconsistent until this proposal either succeeds or fails, but the design really does need to offer some measure of consistency in the event that it does succeed.) And also as I noted earlier, I think this behavior produces the wrong result. I personally have used forwarding extensively in order to be able to move where my mail actually ends up to a new place without having to find and fix all of the various things that send to the old address. When I do this what I want is to have *everything* that was sent to the old address go to the new one, including and in fact most especially sensitive stuff. I strongly doubt I'm alone in this. As long as I continue to own address A in this or many similar scenarios, what happens to mail sent to it after it reaches address A is my business and also my responsibility. And yes, there are attacks associated with bogus forwarding, but you're not going to thwart those with this mechanism so they aren't relevant. (Attackers setting up bogus forwarding are going to direct it to a system that doesn't implement these checks.) And there will also be problems associated with inexperienced users receiving mail at one address but sending it from another - another thing this proposal can't fix. I'll also that that there are mechanisms besides forwarding available that will move mail sent to one place to another after delivery. Indeed, several of the same MSPs this proposal will need support from offer "consolidated mailbox views" and similar things as a value-add. (Think "fetchmail on steroids".) They are certainly not going to implement the spirit of this specification as written as part of those services because that would significantly reduce the value-add. And more generally, it's vitally important to keep in mind the asymmetries in cost and benefit that affect so many email-related proposals, including this one. The benefit of this mechanisms accrues to the actors at either end, and also to the former mailbox owner. But the heavy lifting to be done here is by the MSPs, who have to implement all this check-and-reject logic, or get their software vendors to implement it for them. (And the supposedly simpler case the draft tries to focus on doesn't really make implementation any easier, because anything that's possible has to be handled sensibly, admonitions not to use it notwithstanding.) And the benefit to MSPs is indirect at best, and likely negligible in many cases. This means that anything that significant chance of causing support calls - and the semantics you're calling for here absolutely qualify - is a nonstarter. > > > > I also find this paragraph: > > > > > > > > This header field SHOULD NOT be added to a message that is addressed > > > > to multiple recipients. It is presumed that an author making use of > > > > this field is seeking to protect transactional or otherwise sensitive > > > > data intended for a single recipient. > > > > > > > > to be more than a little wierd. I send mail all the time to multiple > > > > recipients > > > > that I really rather not end up going to an unintended recipient. > > Indeed, I > > > > don't really see who the number of recipients correlates well if at all > > > > with > > > > data sensitivity. I think this whole thing needs to go, especially > > since > > > > envelope checks mostly solve the problems associated with multiple > > > > recipients. > > > > > > > > > The use case being addressed is only single-recipient messages, like > > > password change requests or user-specific activity. Such things are > > never > > > sent to multiple users. Certainly there's a class of messages that are > > > sensitive and have multiple recipients, but they're not part of this > > > problem space. In that sense, allowing a list of addresses on the header > > > field rather than just one creates complexity that isn't needed for the > > > problem we're trying to solve. > > > > > That said, I'm pretty sure it doesn't clobber our use case to allow > > > multiple instances of this field to be added. > > > > Password change requests are an easy one, because they're automated. In > > fact > > this makes me think about the more general use-case here of preventing a > > new > > "owner" of an address from finding out about an account the previous owner > > had > > somewhere. If I get mail - never mind what - directed at the previous > > owner, > > and it's one of those systems that has a "I forgot my password" button that > > works by sending the password reset sequence to the registered email > > address, > > and the account has a stored credit card #... See the problem? > > > Yes, of course. That's pretty much the entire use case that started this > effort. > We don't state anywhere that this is intended for use with auto-generated > messages only, but perhaps it would be good to mention that this is the use > case we have in mind. It also answers the question about the conditions in > which an author would decide to use this. Um, yeah, that's kind of critical. I certainly did not make that assumption and it seems that pretty much nobody else did either. But if we're going to standardize something here, given the difficulty getting things like this deployed as well as the fact that having two slightly different schemes solving the same problem for different constituencies is almost certainly not going to happen, it's actually quite urgent that this be as flexible and failsafe as possible, even if that means a bit more complexity. > > > > > > > > More generally, this gets into the entire issue of when a client > > should use > > > > this facility. I suppose one way is to have a button you press to > > request > > > > "additional recipient verification" or something like that, but let's > > face > > > > it, > > > > users aren't going to have a clue about what this does and therefore > > aren't > > > > going to know when to use it and when not to. The only way this makes > > > > sense is > > > > to use it automatically when an address comes out of the user's address > > > > book. > > > > And not having it work when there are muliple recipients will lead to > > more > > > > least astonishment principle violations. > > > > > > > > > Is it necessary to go into this level of detail? A client uses this > > > facility if the nature of the content means it's important to get to a > > > particular person rather than whatever person currently owns a given > > > mailbox. > > > > OK, so how does a client determine the nature of the content > > automatically? I > > don't know about anyone else, but I've written highly confidential reviews > > of > > things using exactly the same commands that I used to forward an article > > to a > > couple of friends. > > > I think this follows nicely from above. This isn't anticipated to be used > by humans, but rather by automated things like password change requests and > other sensitive but automated things. I will also point out that by focusing on the automated responses from service providers you're going to have a *very* tough time making the case that this should not be done with an SMTP extension. Consider: You're basically talking about Amazon sending notices to Gmail now. In such cases there aren't going to be any SMTP intemediaries, so the value of using a header to avoid issues with intermediary extension support is gone. And the SMTP extension for this is incredibly simple: It's just a date parameter on the RCPT TO. It never ends up in the message itself, so issues with resending all vanish. As to issues with autoforwarding or messages sent to mailing lists - you simply drop the parameter and all those problems go away. And if the receiving software doesn't know how to handle those cases it isn't going to offer the extension. All the issues with multiple recipients also disappear since the date is tightly associated with the recipient. And so on. Really, it's a win all around, except of course for regular clients, who can't use the mechanism without support from their provider and thus end up screwed. But you've just eliminated them from consideration so... Ned From johnl@taugh.com Sun Jul 21 19:35:47 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A669921F9D56 for ; Sun, 21 Jul 2013 19:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id puXsf2zhz8jS for ; Sun, 21 Jul 2013 19:35:46 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 659C321F9D09 for ; Sun, 21 Jul 2013 19:35:46 -0700 (PDT) Received: (qmail 45914 invoked from network); 22 Jul 2013 02:35: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:references:mime-version:content-type:user-agent:cleverness; s=b358.51ec9a7e.k1307; bh=zo/h7bOt8PL95T/sXpRJ8AOP3zXeFRR+Szi+sP5q5Qw=; b=N8JaZez68zHc8Nqsl2iVhPkc6Xr2L1ERbmzngzYjzVeDk10dxv+WOGYGYnb30e14ewDqtUY10b8/Ek/q3Awy29Gqd4kfjEuVMGgxkBUg0p+HLuKcMSTFQphJLwRJYQyAMAdINh/YQ/YvuHL3F9UOh/w2hD7b2T/gsNzsDskGP3KrFut8LdmTSIFpgkpTdsoBFiEpDDKhZPO9fHabPKAGF5ErMZGyLehdWptxXlEJcfdCCbW9zB9b3Ka0YXNVVDM+ 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:cleverness; s=b358.51ec9a7e.k1307; bh=zo/h7bOt8PL95T/sXpRJ8AOP3zXeFRR+Szi+sP5q5Qw=; b=bwrKcRb+ZmR37ftwDMialbQ3oYih70LS+XoPJR792yVUK94SoRXmwtwXmzBciSn84c2ktKB/NxZjCQcqq9lAzidFZIl5KfC1flIDF2cW2EZiFPVgdJg9n74WL3cJxndq2/n447/jIYhlr+M7Q4ELyQTwE5EBTsZuHUkVFMM7nWI9xtZtsQXjTg2Fjv+qlEmhVXJlRPuJJrN+EPFrbJqYRQoOnESlYglsmaY/Qoo7Z6C8kDNoPLCYwrYtILPo5vr8 Received: (ofmipd 127.0.0.1); 22 Jul 2013 02:35:19 -0000 Date: 21 Jul 2013 22:35:41 -0400 Message-ID: From: "John R Levine" To: "Ned Freed" In-Reply-To: <01OWABPTPSU0000054@mauve.mrochek.com> References: <20130718202939.10687.qmail@joyce.lan> <01OW6YGX39GU000054@mauve.mrochek.com> <01OW8X5UAAHW000054@mauve.mrochek.com> <01OWABPTPSU0000054@mauve.mrochek.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 02:35:47 -0000 > My objection was and is to the semantics the current draft calls for. It says: > > 1. A user subscribes to a service "S" on data "D" and confirms an > email address at the user's current location, "A"; > > 2. At some later date, the user intends to leave the current > location, and thus creates a new mailbox elsewhere, at "B"; > > 3. The user replaces mailbox "A" with forwarding to "B"; > > 4. "S" constructs a message to "A" claiming that address was valid > at date "D" and sends it to "A", which forwards to "B"; > > 5. The receiving MTA at "B" asserts that "B" has not been under > constant ownership since "D" and rejects the message. But the rrvs header will have the "A" address in it, and B is supposed to ignore it. I'm more worried about what happens when a hostile sender deliberately puts a "B" address in a message that's likely to be remailed or forwarded. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From ajs@anvilwalrusden.com Sun Jul 21 19:40:25 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09AA021F9D6B for ; Sun, 21 Jul 2013 19:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ugKawomPjwQw for ; Sun, 21 Jul 2013 19:40:20 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 90D0621F9ADD for ; Sun, 21 Jul 2013 19:40:20 -0700 (PDT) Received: from mx1.yitter.info (c-75-69-155-67.hsd1.nh.comcast.net [75.69.155.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 6672E8A031 for ; Mon, 22 Jul 2013 02:40:16 +0000 (UTC) Date: Sun, 21 Jul 2013 22:40:14 -0400 From: Andrew Sullivan To: apps-discuss@ietf.org Message-ID: <20130722024014.GA40429@mx1.yitter.info> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [apps-discuss] [taugh.com-standards] Comments on draft-levine-orgboundary X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jul 2013 02:40:25 -0000 On Sun, Jul 21, 2013 at 09:16:12AM -0400, John R Levine wrote: > Unfortunately, that doesn't work. > > aaa.foo.ontario.ca and bbb.foo.ontario.ca are the same entity > > aaa.toronto.ontario.ca and bbb.toronto.ontario.ca are not To be clear if slightly pedantic about the example, the current registration rules don't permit the first case any more. Also as I understand it, case (2) sort of depends on what you mean by "same entity". Everything of the form [municipality].[province].ca under the current rules must be a department of the municipality. You can't register (for instance) somecompany.toronto.on.ca. This is under the CIRA rules for the delegation of [municipality].[province].ca. Now, none of that obviates your basic point, which is that this pattern is still possible. But that argument, it seems to me, leads almost inexorably to the conclusion that you almost certainly need to descend the tree; and once you've gone that far the overall opt-in model I've argued for starts to look like it makes more sense. (I still appreciate the problem of having to maintain a record for every name beneath one of these policy cuts.) > These have lousy DNS cache behavior, but the closest encloser rule > means that you can find the cut point for any domain with one UDP > lookup. Ok, but I'm not sure the cut point is the thing that makes the difference. For instance, there is no zone cut at dyndns.org, but that name is (and certainly should be) administratively separate from everything beneath it. A -- Andrew Sullivan ajs@anvilwalrusden.com From ajs@anvilwalrusden.com Sun Jul 21 19:43:30 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCB2621F9D56 for ; Sun, 21 Jul 2013 19:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ffhD2j4dVuo7 for ; Sun, 21 Jul 2013 19:43:25 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 0EEFC21F9D09 for ; Sun, 21 Jul 2013 19:43:24 -0700 (PDT) Received: from mx1.yitter.info (c-75-69-155-67.hsd1.nh.comcast.net [75.69.155.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 6DA718A031 for ; Mon, 22 Jul 2013 02:43:24 +0000 (UTC) Date: Sun, 21 Jul 2013 22:43:25 -0400 From: Andrew Sullivan To: apps-discuss@ietf.org Message-ID: <20130722024325.GB40429@mx1.yitter.info> References: <20130722012418.54689.qmail@joyce.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130722012418.54689.qmail@joyce.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [apps-discuss] [taugh.com-standards] Comments on draft-levine-orgboundary X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jul 2013 02:43:30 -0000 On Mon, Jul 22, 2013 at 01:24:18AM -0000, John Levine wrote: > Of course, this assumes that you believe that there actually isn't > anything interesting below .com. If you look at the current public > suffix list, they don't. Yes, this is what has worried me too. Brian Dickson raised this issue at length to me off list; I was hoping he'd chime in some more here. > It's a mess. My impression is that the DNS is robust enough that it's > not worth a lot of effort to try to cut down query rates unless you > know that the query rate is totally absurd. Or at least, if the DNS is the right place to put this data, then it had _better_ be robust enough for that. Certainly, there are lots of people on the Internet today with 30s TTLs on their zones. (Much below 30 and you start to get wildly unpredictable behaviour.) A -- Andrew Sullivan ajs@anvilwalrusden.com From wmills@yahoo-inc.com Sun Jul 21 19:55:23 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7616521F9A99 for ; Sun, 21 Jul 2013 19:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.998 X-Spam-Level: X-Spam-Status: No, score=-17.998 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXBUIOerYLTT for ; Sun, 21 Jul 2013 19:55:18 -0700 (PDT) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by ietfa.amsl.com (Postfix) with ESMTP id 7ECCF21F9E7E for ; Sun, 21 Jul 2013 19:55:18 -0700 (PDT) Received: from BF1-EX10-CAHT05.y.corp.yahoo.com (bf1-ex10-caht05.corp.bf1.yahoo.com [10.74.209.60]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id r6M2sg9a008590 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 21 Jul 2013 19:54:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1374461683; bh=LeD1duxb08VBU4RnoM8mfKwctqZ4e44BUfzrjv7GGrU=; h=References:Message-ID:Date:From:Reply-To:Subject:To:CC: In-Reply-To:MIME-Version:Content-Type; b=jux5wi0FW/vMtvEhWMngdU2Z9u9HTnbK8dYC49VONUVp6R+gyGtu6Kg5rJrGJdX2S yLhXaosP5v9NY/Ugh5b9m0xYXI3yiUTHomUO3QjdAhESpi3pFeT0Pn3heCahNUV3h8 T4PJ4u/WsZrPBsPE33zTWq1AAHDFf21vekQCsmXo= Received: from omp1072.mail.ne1.yahoo.com (98.138.101.161) by BF1-EX10-CAHT05.y.corp.yahoo.com (10.74.209.170) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sun, 21 Jul 2013 19:54:41 -0700 Received: (qmail 12123 invoked by uid 1000); 22 Jul 2013 02:54:41 -0000 Received: (qmail 11842 invoked by uid 60001); 22 Jul 2013 02:54:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1374461681; bh=BcmAxWAiz/0Yz0qEHfqKt/980DrMdU+Df6VQDtRaC8Q=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=CjW+aLd1M8EOYzESbav8PRbNUo/DprRhrQCIql1BmSAeB2jRyMHW/++xUBuorQraEE7CiWF+Ggz4mJdelSOye6VSRyuLK1pDoypWEJ6FQdWJxPARWBmDP2wpvBqIloSoYARbvj0Xbkc7O3hOt9o39oFwMalqwSTVboW4lnd16Ck= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=BHPl/7Ks1NCoLr11LekadPZzst895oHMO1wB3clk3eYS1WSieEeYQ6IwpmBXEeqWM7ZGDDbuf9RDzOo+LEaxQPOXWde015l6dD02DQ/aWrTEnlH6sU4LS/d4f96s2SJoNXe6Hhoz9jPI6BV6mPPjfi8Awsi8FHsKg4YfPRWvr98=; X-YMail-OSG: 4yDoRgQVM1m7IA.z71nCNf9Qfl7KyejmxBb8_krwMFmPcDO _.fst_CsGTHHedB4raUxbFtnDsocEUwtcbR1TpVdjIZDy Received: from [99.31.212.42] by web125604.mail.ne1.yahoo.com via HTTP; Sun, 21 Jul 2013 19:54:40 PDT X-Rocket-MIMEInfo: 002.001, Tm8sIHdoYXQgaXMgc3VwcG9zZWQgdG8gaGFwcGVuIGlzIHRoYXQgdGhlIG1haWwgZ2V0cyB0byB0aGUgTVRBIGZvciBBIHdoZXJlwqAgZm9yd2FyZGluZyBpcyBjb25maWd1cmVkIGFuZCB0aGUgUlJWUyBjaGVjayBuZWVkcyB0byBiZSBkb25lIHRoZXJlLsKgIFRoZXkgbmV2ZXIgZm9yd2FyZCB0byBCLgoKCsKgCi1iaWxsCgoKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCldpbGxpYW0gSi4gTWlsbHMKIlBhcmFub2lkIiBZYWhvbyEKCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18BMAEBAQE- X-Mailer: YahooMailWebService/0.8.149.560 References: <20130718202939.10687.qmail@joyce.lan> <01OW6YGX39GU000054@mauve.mrochek.com> <01OW8X5UAAHW000054@mauve.mrochek.com> <01OWABPTPSU0000054@mauve.mrochek.com> Message-ID: <1374461680.11442.YahooMailNeo@web125604.mail.ne1.yahoo.com> Date: Sun, 21 Jul 2013 19:54:40 -0700 From: Bill Mills To: Ned Freed , "Murray S. Kucherawy" In-Reply-To: <01OWABPTPSU0000054@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-685807438-1692507063-1374461680=:11442" X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 461683000 Cc: John R Levine , IETF Apps Discuss Subject: Re: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Bill Mills List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 02:55:23 -0000 ---685807438-1692507063-1374461680=:11442 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable No, what is supposed to happen is that the mail gets to the MTA for A where= =A0 forwarding is configured and the RRVS check needs to be done there.=A0 = They never forward to B.=0A=0A=0A=A0=0A-bill=0A=0A=0A=0A-------------------= -------------=0AWilliam J. Mills=0A"Paranoid" Yahoo!=0A=0A=0A=0A=0A________= ________________________=0A From: Ned Freed =0ATo: M= urray S. Kucherawy =0ACc: John R Levine ; Ned Freed ; IETF Apps Discuss =0ASent: Sunday, July 21, 2013 8:44 AM=0ASubject: Re: [apps-discuss= ] Comments on draft-wmills-rrvs-header-field-00=0A =0A=0A> > If you want an= other example, consider what happens when someone uses=0A> > fetchmail=0A> = > to suck the mail out of a mailbox after delivery and sending it on=0A> > = somewhere=0A> > else. People route mail in all kinds of ways. And yes, what= people do does=0A> > lead=0A> > to problems, like when an autoforwarded me= ssage bounces back to the message=0A> > originator who then gets a bounce f= rom an address they have never heard of=0A> > and=0A> > wonder what the hel= l is going on. But new mechanisms need to be designed=0A> > not to make the= problems worse.=0A> >=0A=0A> So then a "process this once and then delete = it" requirement is what you=0A> have in mind?=0A=0ANo, because you can't be= sure that the processing will occur, so it creates=0Aeven more astonishmen= t. And I don't see how this could be implemented while=0Aretaining the sema= ntics given in the specification in any case.=0A=0AMy objection was and is = to the semantics the current draft calls for. It says:=0A=0A1.=A0 A user su= bscribes to a service "S" on data "D" and confirms an=0A=A0 =A0 =A0 email = address at the user's current location, "A";=0A=0A=A0 2.=A0 At some later = date, the user intends to leave the current=0A=A0 =A0 =A0 location, and th= us creates a new mailbox elsewhere, at "B";=0A=0A=A0 3.=A0 The user replac= es mailbox "A" with forwarding to "B";=0A=0A=A0 4.=A0 "S" constructs a mes= sage to "A" claiming that address was valid=0A=A0 =A0 =A0 at date "D" and = sends it to "A", which forwards to "B";=0A=0A=A0 5.=A0 The receiving MTA a= t "B" asserts that "B" has not been under=0A=A0 =A0 =A0 constant ownership= since "D" and rejects the message.=0A=0AI think the result in 5 is flat ou= t wrong, and what should be happening is=0Aexactly the opposite: The messag= e goes through and is delivered.=0A=0AFirst of all, as I noted previously, = there is no way to actually implement=0Athese semantics in a fashion that's= consistent with what's in the draft. If=0Amailboxes A and B are under diff= erent administrative domains - and they often=0Awill be - then implementing= these semantics directly contradicts the semantics=0Acalled for in section= 3 because address "A" in the RRVS field is going to be=0Aseen as foreign b= y the receiving MTA at "B" and ignored. So unless we're simply=0Agoing to i= gnore the recipient address in the RRVS field entirely - and in that=0Acase= why is it even there -=A0 the behavior you're going to get is going to be= =0Awildly inconsistent. (Of course behavior is going to be wildly inconsist= ent=0Auntil this proposal either succeeds or fails, but the design really d= oes need=0Ato offer some measure of consistency in the event that it does s= ucceed.)=0A=0AAnd also as I noted earlier, I think this behavior produces t= he wrong result. I=0Apersonally have used forwarding extensively in order t= o be able to move where=0Amy mail actually ends up to a new place without h= aving to find and fix all of=0Athe various things that send to the old addr= ess. When I do this what I want is=0Ato have *everything* that was sent to = the old address go to the new one,=0Aincluding and in fact most especially = sensitive stuff. I strongly doubt I'm=0Aalone in this.=0A=0AAs long as I co= ntinue to own address A in this or many similar scenarios, what=0Ahappens t= o mail sent to it after it reaches address A is my business and also=0Amy r= esponsibility. And yes, there are attacks associated with bogus forwarding,= =0Abut you're not going to thwart those with this mechanism so they aren't= =0Arelevant. (Attackers setting up bogus forwarding are going to direct it = to a=0Asystem that doesn't implement these checks.) And there will also be = problems=0Aassociated with inexperienced users receiving mail at one addres= s but sending=0Ait from another - another thing this proposal can't fix.=0A= =0AI'll also that that there are mechanisms besides forwarding available th= at will=0Amove mail sent to one place to another after delivery. Indeed, se= veral of the=0Asame MSPs this proposal will need support from offer "consol= idated mailbox=0Aviews" and similar things as a value-add. (Think "fetchmai= l on steroids".) They=0Aare certainly not going to implement the spirit of = this specification as=0Awritten as part of those services because that woul= d significantly reduce the=0Avalue-add.=0A=0AAnd more generally, it's vital= ly important to keep in mind the asymmetries in=0Acost and benefit that aff= ect so many email-related proposals, including this=0Aone. The benefit of t= his mechanisms accrues to the actors at either end, and=0Aalso to the forme= r mailbox owner. But the heavy lifting to be done here is by=0Athe MSPs, wh= o have to implement all this check-and-reject logic, or get their=0Asoftwar= e vendors to implement it for them. (And the supposedly simpler case the=0A= draft tries to focus on doesn't really make implementation any easier, beca= use=0Aanything that's possible has to be handled sensibly, admonitions not = to use it=0Anotwithstanding.) And the benefit to MSPs is indirect at best, = and likely=0Anegligible in many cases. This means that anything that signif= icant chance of=0Acausing support calls - and the semantics you're calling = for here absolutely=0Aqualify - is a nonstarter.=0A=0A> > > > I also find t= his paragraph:=0A> > > >=0A> > > >=A0 This header field SHOULD NOT be adde= d to a message that is addressed=0A> > > >=A0 to multiple recipients.=A0 I= t is presumed that an author making use of=0A> > > >=A0 this field is seek= ing to protect transactional or otherwise sensitive=0A> > > >=A0 data inte= nded for a single recipient.=0A> > > >=0A> > > > to be more than a little w= ierd. I send mail all the time to multiple=0A> > > > recipients=0A> > > > t= hat I really rather not end up going to an unintended recipient.=0A> > Inde= ed, I=0A> > > > don't really see who the number of recipients correlates we= ll if at all=0A> > > > with=0A> > > > data sensitivity. I think this whole = thing needs to go, especially=0A> > since=0A> > > > envelope checks mostly = solve the problems associated with multiple=0A> > > > recipients.=0A> > > >= =0A> >=0A> > > The use case being addressed is only single-recipient messag= es, like=0A> > > password change requests or user-specific activity.=A0 Suc= h things are=0A> > never=0A> > > sent to multiple users.=A0 Certainly there= 's a class of messages that are=0A> > > sensitive and have multiple recipie= nts, but they're not part of this=0A> > > problem space.=A0 In that sense, = allowing a list of addresses on the header=0A> > > field rather than just o= ne creates complexity that isn't needed for the=0A> > > problem we're tryin= g to solve.=0A> >=0A> > > That said, I'm pretty sure it doesn't clobber our= use case to allow=0A> > > multiple instances of this field to be added.=0A= > >=0A> > Password change requests are an easy one, because they're automat= ed. In=0A> > fact=0A> > this makes me think about the more general use-case= here of preventing a=0A> > new=0A> > "owner" of an address from finding ou= t about an account the previous owner=0A> > had=0A> > somewhere. If I get m= ail - never mind what - directed at the previous=0A> > owner,=0A> > and it'= s one of those systems that has a "I forgot my password" button that=0A> > = works by sending the password reset sequence to the registered email=0A> > = address,=0A> > and the account has a stored credit card #... See the proble= m?=0A> >=0A=0A> Yes, of course.=A0 That's pretty much the entire use case t= hat started this=0A> effort.=0A=0A> We don't state anywhere that this is in= tended for use with auto-generated=0A> messages only, but perhaps it would = be good to mention that this is the use=0A> case we have in mind.=A0 It als= o answers the question about the conditions in=0A> which an author would de= cide to use this.=0A=0AUm, yeah, that's kind of critical. I certainly did n= ot make that assumption=0Aand it seems that pretty much nobody else did eit= her.=0A=0ABut if we're going to standardize something here, given the diffi= culty getting=0Athings like this deployed as well as the fact that having t= wo slightly=0Adifferent schemes solving the same problem for different cons= tituencies is=0Aalmost certainly not going to happen, it's actually quite u= rgent that this be=0Aas flexible and failsafe as possible, even if that mea= ns a bit more complexity.=0A=0A> > > >=0A> > > > More generally, this gets = into the entire issue of when a client=0A> > should use=0A> > > > this faci= lity. I suppose one way is to have a button you press to=0A> > request=0A> = > > > "additional recipient verification" or something like that, but let's= =0A> > face=0A> > > > it,=0A> > > > users aren't going to have a clue about= what this does and therefore=0A> > aren't=0A> > > > going to know when to = use it and when not to. The only way this makes=0A> > > > sense is=0A> > > = > to use it automatically when an address comes out of the user's address= =0A> > > > book.=0A> > > > And not having it work when there are muliple re= cipients will lead to=0A> > more=0A> > > > least astonishment principle vio= lations.=0A> > > >=0A> >=0A> > > Is it necessary to go into this level of d= etail?=A0 A client uses this=0A> > > facility if the nature of the content = means it's important to get to a=0A> > > particular person rather than what= ever person currently owns a given=0A> > > mailbox.=0A> >=0A> > OK, so how = does a client determine the nature of the content=0A> > automatically? I=0A= > > don't know about anyone else, but I've written highly confidential revi= ews=0A> > of=0A> > things using exactly the same commands that I used to fo= rward an article=0A> > to a=0A> > couple of friends.=0A> >=0A=0A> I think t= his follows nicely from above.=A0 This isn't anticipated to be used=0A> by = humans, but rather by automated things like password change requests and=0A= > other sensitive but automated things.=0A=0AI will also point out that by = focusing on the automated responses from service=0Aproviders you're going t= o have a *very* tough time making the case that this=0Ashould not be done w= ith an SMTP extension. Consider: You're basically talking=0Aabout Amazon se= nding notices to Gmail now. In such cases there aren't going to=0Abe any SM= TP intemediaries, so the value of using a header to avoid issues with=0Aint= ermediary extension support is gone. And the SMTP extension for this is=0Ai= ncredibly simple: It's just a date parameter on the RCPT TO. It never ends = up=0Ain the message itself, so issues with resending all vanish. As to issu= es with=0Aautoforwarding or messages sent to mailing lists - you simply dro= p the=0Aparameter and all those problems go away. And if the receiving soft= ware doesn't=0Aknow how to handle those cases it isn't going to offer the e= xtension. All the=0Aissues with multiple recipients also disappear since th= e date is tightly=0Aassociated with the recipient. And so on.=0A=0AReally, = it's a win all around, except of course for regular clients, who can't=0Aus= e the mechanism without support from their provider and thus end up screwed= .=0ABut you've just eliminated them from consideration so...=0A=0A=A0=A0=A0= =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 Ned=0A______________________________________= _________=0Aapps-discuss mailing list=0Aapps-discuss@ietf.org=0Ahttps://www= .ietf.org/mailman/listinfo/apps-discuss ---685807438-1692507063-1374461680=:11442 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
No, what = is supposed to happen is that the mail gets to the MTA for A where  fo= rwarding is configured and the RRVS check needs to be done there.  The= y never forward to B.

 
= -bill


--------------------------------
William J. Mills
"= Paranoid" Yahoo!


From: Ned Freed <ned.freed@mrochek.com>
To= : Murray S. Kucherawy <superuser@gmail.com>
Cc: John R Levine <johnl@taugh.co= m>; Ned Freed <ned.freed@mrochek.com>; IETF Apps Discuss <apps-= discuss@ietf.org>
Sent: Sunday, July 21, 2013 8:44 AM
Subject: Re: [apps-discuss] Comments on draft-wmills-rrvs-hea= der-field-00

> >= ; If you want another example, consider what happens when someone uses
&= gt; > fetchmail
> > to suck the mail out of a mailbox after del= ivery and sending it on
> > somewhere
> > else. People ro= ute mail in all kinds of ways. And yes, what people do does
> > le= ad
> > to problems, like when an autoforwarded message bounces bac= k to the message
> > originator who then gets a bounce from an addr= ess they have never heard of
> > and
> > wonder what the = hell is going on. But new mechanisms need to be designed
> > not t= o make the problems worse.
> >

> So then a "process this= once and then delete it" requirement is what you
> have in mind?
=
No, because you can't be sure that the processing will occur, so it cre= ates
even more astonishment. And I don't see how this could be implement= ed while
retaining the semantics given in the specification in any case.=

My objection was and is to the semantics the current draft calls fo= r. It says:

1.  A user subscribes to a service "S" on data "D"= and confirms an
      email address at the user's curre= nt location, "A";

  2.  At some later date, the user inte= nds to leave the current
      location, and thus creates a new mailbox elsewhere, at "B";

  3.  The user = replaces mailbox "A" with forwarding to "B";

  4.  "S" co= nstructs a message to "A" claiming that address was valid
    =   at date "D" and sends it to "A", which forwards to "B";

&nbs= p; 5.  The receiving MTA at "B" asserts that "B" has not been under      constant ownership since "D" and rejects the messag= e.

I think the result in 5 is flat out wrong, and what should be hap= pening is
exactly the opposite: The message goes through and is delivere= d.

First of all, as I noted previously, there is no way to actually = implement
these semantics in a fashion that's consistent with what's in = the draft. If
mailboxes A and B are under different administrative domai= ns - and they often
will be - then implementing these semantics directly= contradicts the semantics
called for in section 3 because address "A" in the RRVS field is going to be
seen as foreign by the rec= eiving MTA at "B" and ignored. So unless we're simply
going to ignore th= e recipient address in the RRVS field entirely - and in that
case why is= it even there -  the behavior you're going to get is going to be
w= ildly inconsistent. (Of course behavior is going to be wildly inconsistent<= br>until this proposal either succeeds or fails, but the design really does= need
to offer some measure of consistency in the event that it does suc= ceed.)

And also as I noted earlier, I think this behavior produces t= he wrong result. I
personally have used forwarding extensively in order = to be able to move where
my mail actually ends up to a new place without= having to find and fix all of
the various things that send to the old a= ddress. When I do this what I want is
to have *everything* that was sent= to the old address go to the new one,
including and in fact most especially sensitive stuff. I strongly doubt I'm
alone in this.

= As long as I continue to own address A in this or many similar scenarios, w= hat
happens to mail sent to it after it reaches address A is my business= and also
my responsibility. And yes, there are attacks associated with = bogus forwarding,
but you're not going to thwart those with this mechani= sm so they aren't
relevant. (Attackers setting up bogus forwarding are g= oing to direct it to a
system that doesn't implement these checks.) And = there will also be problems
associated with inexperienced users receivin= g mail at one address but sending
it from another - another thing this p= roposal can't fix.

I'll also that that there are mechanisms besides = forwarding available that will
move mail sent to one place to another af= ter delivery. Indeed, several of the
same MSPs this proposal will need s= upport from offer "consolidated mailbox
views" and similar things as a value-add. (Think "fetchmail on steroids".) They
are certainly not= going to implement the spirit of this specification as
written as part = of those services because that would significantly reduce the
value-add.=

And more generally, it's vitally important to keep in mind the asym= metries in
cost and benefit that affect so many email-related proposals,= including this
one. The benefit of this mechanisms accrues to the actor= s at either end, and
also to the former mailbox owner. But the heavy lif= ting to be done here is by
the MSPs, who have to implement all this chec= k-and-reject logic, or get their
software vendors to implement it for th= em. (And the supposedly simpler case the
draft tries to focus on doesn't= really make implementation any easier, because
anything that's possible= has to be handled sensibly, admonitions not to use it
notwithstanding.)= And the benefit to MSPs is indirect at best, and likely
negligible in many cases. This means that anything that signific= ant chance of
causing support calls - and the semantics you're calling f= or here absolutely
qualify - is a nonstarter.

> > > >= I also find this paragraph:
> > > >
> > > >&= nbsp; This header field SHOULD NOT be added to a message that is addressed=
> > > >  to multiple recipients.  It is presumed= that an author making use of
> > > >  this field is s= eeking to protect transactional or otherwise sensitive
> > > &g= t;  data intended for a single recipient.
> > > >
&= gt; > > > to be more than a little wierd. I send mail all the time= to multiple
> > > > recipients
> > > > that = I really rather not end up going to an unintended recipient.
> > I= ndeed, I
> > > > don't really see who the number of recipients correlates well if at all
> > > > with
> &= gt; > > data sensitivity. I think this whole thing needs to go, espec= ially
> > since
> > > > envelope checks mostly solv= e the problems associated with multiple
> > > > recipients.<= br>> > > >
> >
> > > The use case being ad= dressed is only single-recipient messages, like
> > > password = change requests or user-specific activity.  Such things are
> &g= t; never
> > > sent to multiple users.  Certainly there's = a class of messages that are
> > > sensitive and have multiple = recipients, but they're not part of this
> > > problem space.&n= bsp; In that sense, allowing a list of addresses on the header
> >= > field rather than just one creates complexity that isn't needed for t= he
> > > problem we're trying to solve.
> >
> > > That said, I'm pretty sure it doesn't clobber our u= se case to allow
> > > multiple instances of this field to be a= dded.
> >
> > Password change requests are an easy one, b= ecause they're automated. In
> > fact
> > this makes me t= hink about the more general use-case here of preventing a
> > new<= br>> > "owner" of an address from finding out about an account the pr= evious owner
> > had
> > somewhere. If I get mail - never= mind what - directed at the previous
> > owner,
> > and = it's one of those systems that has a "I forgot my password" button that
= > > works by sending the password reset sequence to the registered em= ail
> > address,
> > and the account has a stored credit = card #... See the problem?
> >

> Yes, of course.  T= hat's pretty much the entire use case that started this
> effort.

> We don't state anywhere that this is intended for use = with auto-generated
> messages only, but perhaps it would be good to = mention that this is the use
> case we have in mind.  It also an= swers the question about the conditions in
> which an author would de= cide to use this.

Um, yeah, that's kind of critical. I certainly did= not make that assumption
and it seems that pretty much nobody else did = either.

But if we're going to standardize something here, given the = difficulty getting
things like this deployed as well as the fact that ha= ving two slightly
different schemes solving the same problem for differe= nt constituencies is
almost certainly not going to happen, it's actually= quite urgent that this be
as flexible and failsafe as possible, even if= that means a bit more complexity.

> > > >
> > = > > More generally, this gets into the entire issue of when a client
> > should use
> > > > this facility. I sup= pose one way is to have a button you press to
> > request
> = > > > "additional recipient verification" or something like that, = but let's
> > face
> > > > it,
> > > &g= t; users aren't going to have a clue about what this does and therefore
= > > aren't
> > > > going to know when to use it and wh= en not to. The only way this makes
> > > > sense is
> = > > > to use it automatically when an address comes out of the use= r's address
> > > > book.
> > > > And not hav= ing it work when there are muliple recipients will lead to
> > mor= e
> > > > least astonishment principle violations.
> &= gt; > >
> >
> > > Is it necessary to go into thi= s level of detail?  A client uses this
> > > facility if the nature of the content means it's important to get to a
= > > > particular person rather than whatever person currently owns= a given
> > > mailbox.
> >
> > OK, so how do= es a client determine the nature of the content
> > automatically?= I
> > don't know about anyone else, but I've written highly confi= dential reviews
> > of
> > things using exactly the same = commands that I used to forward an article
> > to a
> > c= ouple of friends.
> >

> I think this follows nicely from= above.  This isn't anticipated to be used
> by humans, but rath= er by automated things like password change requests and
> other sens= itive but automated things.

I will also point out that by focusing o= n the automated responses from service
providers you're going to have a = *very* tough time making the case that this
should not be done with an SMTP extension. Consider: You're basically talking
about Amazon= sending notices to Gmail now. In such cases there aren't going to
be an= y SMTP intemediaries, so the value of using a header to avoid issues withintermediary extension support is gone. And the SMTP extension for this i= s
incredibly simple: It's just a date parameter on the RCPT TO. It never= ends up
in the message itself, so issues with resending all vanish. As = to issues with
autoforwarding or messages sent to mailing lists - you si= mply drop the
parameter and all those problems go away. And if the recei= ving software doesn't
know how to handle those cases it isn't going to o= ffer the extension. All the
issues with multiple recipients also disappe= ar since the date is tightly
associated with the recipient. And so on.
Really, it's a win all around, except of course for regular clients, = who can't
use the mechanism without support from their provider and thus end up screwed.
But you've just eliminated them from considera= tion so...

            =     Ned
_______________________________________________apps-discuss mailing list
apps-discuss@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/apps-discuss


---685807438-1692507063-1374461680=:11442-- From johnl@iecc.com Sun Jul 21 19:58:14 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C557721F85EB for ; Sun, 21 Jul 2013 19:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.867 X-Spam-Level: X-Spam-Status: No, score=-110.867 tagged_above=-999 required=5 tests=[AWL=0.332, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iodObnnK96zb for ; Sun, 21 Jul 2013 19:58:11 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id B02B921F86BE for ; Sun, 21 Jul 2013 19:58:10 -0700 (PDT) Received: (qmail 49568 invoked from network); 22 Jul 2013 02:58:09 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 22 Jul 2013 02:58:09 -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=51ec9fc1.xn--9vv.k1307; i=johnl@user.iecc.com; bh=fXxzuwJFJQci0NxcEg9owNWD8EB5klI3EKPO4ZKSZ0A=; b=3ceR2i2WMbVkW4yDZJjQPZdwAGIi3KQQT+vReXUvqsItiXhuei6tHpnAJACsLJ1rY4BmuUNqi0sGJwb87Swk+BoW0AobqYGqDiMOvGGYbLl7Per8pvjtSPIlTuiOK4bh3SrO+QgEFm9YGhrR2ndnXyWxeGG1gW6srYH8mSacgbE5GK3tzw/CQMjFuE2ZwH7Apl6e265cZnQhaVS7Vb74RzFMuLx9om6fZVvsbRwWOEHDwIBhQHmPxA7wzejv9Ker 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=51ec9fc1.xn--9vv.k1307; olt=johnl@user.iecc.com; bh=fXxzuwJFJQci0NxcEg9owNWD8EB5klI3EKPO4ZKSZ0A=; b=IwMUeCqIM801d5N6/6mXuKI77MQgoAh8JQTsLl9pbStAnTCZvErQ3D+9vYSPCRgCYb1TLZUbnlLs3bVYTpZFQ7hZ3NPPDQdzE/g0x3f4dvYiqq20/Mf+k4cw1LA635oylSGlQQiWfDc1u/aKQ8QsJ4SUaKnB/6Tf0Xs8W54ImzFE1XSVLDsNCsv8zfJGdIt+XxRErAx6u5bKRbstHvZRZwvZ8U4ra/AI1VB6THAx22w5xTUBx1WsXM/UT3Mn1XAd Date: 22 Jul 2013 02:57:47 -0000 Message-ID: <20130722025747.55027.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <20130722024014.GA40429@mx1.yitter.info> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [apps-discuss] [taugh.com-standards] Comments on draft-levine-orgboundary X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jul 2013 02:58:14 -0000 >> aaa.foo.on.ca and bbb.foo.on.ca are the same entity >> >> aaa.toronto.on.ca and bbb.toronto.on.ca are not > >To be clear if slightly pedantic about the example, the current >registration rules don't permit the first case any more. Also as I >understand it, case (2) sort of depends on what you mean by "same >entity". Everything of the form [municipality].[province].ca under >the current rules must be a department of the municipality. You can't >register (for instance) somecompany.toronto.on.ca. This is under the >CIRA rules for the delegation of [municipality].[province].ca. That may be the current rule, but I know someone whose domain is .montreal.qc.ca. There are of course plenty of other ccTLDs with irregular registration boundaries, e.g., trieste.it is a geographic delegation point while triste.it is a registration. >Now, none of that obviates your basic point, which is that this >pattern is still possible. But that argument, it seems to me, leads >almost inexorably to the conclusion that you almost certainly need to >descend the tree; You can use my grosse hackque with the wildcards, where the closest encloser rule finds the deepest relevant delegation point. R's, John From johnl@taugh.com Sun Jul 21 20:02:08 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F345A21F9A99 for ; Sun, 21 Jul 2013 20:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5oMD9GKT2M25 for ; Sun, 21 Jul 2013 20:02:07 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 13C8421F9A8E for ; Sun, 21 Jul 2013 20:02:06 -0700 (PDT) Received: (qmail 50274 invoked from network); 22 Jul 2013 03:02: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:references:mime-version:content-type:user-agent:cleverness; s=c461.51eca0ae.k1307; bh=/4Sx/5np/jcEcYtuDJ8Vbyk1FrdkImCLjVPRIN4NxKU=; b=h3fCLuQzYgh9gy2PBkIri3Gx7qLicHxAdVwuIlXTtn+P1ioAK5TBScomPouy0y2nagpJUsBA1Frf/wBB3J7iUpaMEuS4RCB5Er4iWXFyzlCWsGlgnAeJeNbcCzOJYHQ0DHcJ6imLQJw7Ab/8Mc+Hva7AlvOjU9+vbDm/CXwHKMH9A9xtk6ZeolT9TXp/0M4yMRuRDNNN+ZSO2GMbyaZ18sXRrjppB19rff3sb/7rhE8ioD3z13LzRVPr8l3IM3Am 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:cleverness; s=c461.51eca0ae.k1307; bh=/4Sx/5np/jcEcYtuDJ8Vbyk1FrdkImCLjVPRIN4NxKU=; b=a/Qi7dZ1+e9Q2sAZbG8VNlTLSdlqLetH5xcUby9dkPjr/znvR15b7VRWmEo3YjoC4Y5mBAxL6WgeC3Ca9YQoFifbCgHtV657FoO5PK1a38bIrD/FwMJjsFkcz4LqDJmV/624jHsmeDqFpVtmuQQnC5O/bu7z0sjyk9PUC+yq6sngyx9lK5tTGVHSiXI/kkmYKlae4Rg9qQntKvsbWvt6SbGe7gS50cfvPCRHvyTF+rbsxV1dVECygWU+UMTcLi33 Received: (ofmipd 127.0.0.1); 22 Jul 2013 03:01:44 -0000 Date: 21 Jul 2013 23:02:06 -0400 Message-ID: From: "John R Levine" To: "Bill Mills" In-Reply-To: <1374461680.11442.YahooMailNeo@web125604.mail.ne1.yahoo.com> References: <20130718202939.10687.qmail@joyce.lan> <01OW6YGX39GU000054@mauve.mrochek.com> <01OW8X5UAAHW000054@mauve.mrochek.com> <01OWABPTPSU0000054@mauve.mrochek.com> <1374461680.11442.YahooMailNeo@web125604.mail.ne1.yahoo.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="3825401791-709129581-1374462126=:55037" Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 03:02:08 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --3825401791-709129581-1374462126=:55037 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT > No, what is supposed to happen is that the mail gets to the MTA for A where  forwarding is configured and the RRVS check needs to be done there.  They never forward to B. In this case the person already has the "A" account and configures it to forward to his new "B" account. The correct thing would be for A to look at rrvs, see an address it knows, accept the message and forward it. B looks at rrvs, sees an unknown address and ignores it. I think that for non-hostile senders this should work OK. My concern is what happens with senders who deliberately or accidentally play games. R's, John --3825401791-709129581-1374462126=:55037-- From wmills@yahoo-inc.com Sun Jul 21 20:14:48 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 904A421F99B0 for ; Sun, 21 Jul 2013 20:14:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.431 X-Spam-Level: X-Spam-Status: No, score=-18.431 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9WrcLMuiMeVE for ; Sun, 21 Jul 2013 20:14:43 -0700 (PDT) Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) by ietfa.amsl.com (Postfix) with ESMTP id 728FD21F85C3 for ; Sun, 21 Jul 2013 20:14:43 -0700 (PDT) Received: from BF1-EX10-CAHT16.y.corp.yahoo.com (bf1-ex10-caht16.corp.bf1.yahoo.com [10.74.226.60]) by mrout3.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id r6M3DrJL078389 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 21 Jul 2013 20:13:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1374462834; bh=qsIMigndzBsmMzYdMjTjeKTn2C7E2T2bnfW2U7RgcDU=; h=References:Message-ID:Date:From:Reply-To:Subject:To:CC: In-Reply-To:MIME-Version:Content-Type; b=qNYeLvUQ09H2YtmAgto6D5SDQVC5n+H/65yIQ5pYwdjKyIrjDHBNoTycTyGy9WceO bw6hogyk+Pzf1QWDuHMbRrESo/rdX1L09TzFTtQorSdM2nqISjw6pgIS/pimP/sX1q NkBwCpdFactSQesl+WSvr3jcNx6Ni2sP5IcGHbKw= Received: from omp1010.mail.ne1.yahoo.com (98.138.87.10) by BF1-EX10-CAHT16.y.corp.yahoo.com (10.74.209.170) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sun, 21 Jul 2013 23:13:52 -0400 Received: (qmail 48104 invoked by uid 1000); 22 Jul 2013 03:13:52 -0000 Received: (qmail 27391 invoked by uid 60001); 22 Jul 2013 03:13:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1374462832; bh=+fkEltUDBVqnWtnQwgEIIpq3s3L01KvSRcGlG70+zpI=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=S3gHCgvFrIZB+8bDJGO37/MGxQzuxL7o3ShqWE0JnaPbRks3eVYXXC7kbfF/M63G3+mjntRlUJ82k5ogQW3tXBrYdtoiQ8tHphfiwFlkCqeSOygfS3ippjsW0fnWaxO9bpzOkinEvIWLdBuAN4+1M2iV9r9UkZXQ6MilcIsGrSg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=hfpvR/pB/kQ4GiaO5YKqL5IsFBdtwMgfqS/CxxYi+rvyI8Ia7hgKiNL/4mMAzMAJAL8uyUm7S6uc/+Gp/gOVwTH8vb+behjTaP7r5RO/a2IpIq+2mTof/LsEgL48Fc9kQThik+DyYVO6yc8D/ATurUW5cHZeHtrBsns643yG5ys=; X-YMail-OSG: _oQ2jowVM1kZq5WOgXjEQz1g4S_1FQBqbmlUFRGpoZ_m8iR KHCBxukKaiyrccxRbvV31u6bTf2JZbh9Bf13kzqtc9jda Received: from [99.31.212.42] by web125604.mail.ne1.yahoo.com via HTTP; Sun, 21 Jul 2013 20:13:51 PDT X-Rocket-MIMEInfo: 002.001, WWVzLCBBIGFwcGxpZXMgdGhlIFJSVlMgcG9saWN5IHRvIGRldGVybWluZSBpZiBpdCB3aWxsIGRlbGl2ZXIgKGRlbGl2ZXJ5IGhhcHBlbnMgdG8gYmUgYSBmb3J3YXJkLsKgIEIgaW4gdGhpcyBjYXNlIGlnbm9yZXMuCgoKwqAKLWJpbGwKCgoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KV2lsbGlhbSBKLiBNaWxscwoiUGFyYW5vaWQiIFlhaG9vIQoKCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KIEZyb206IEpvaG4gUiBMZXZpbmUgPGpvaG5sQHRhdWdoLmNvbT4KVG86IEJpbGwBMAEBAQE- X-Mailer: YahooMailWebService/0.8.149.560 References: <20130718202939.10687.qmail@joyce.lan> <01OW6YGX39GU000054@mauve.mrochek.com> <01OW8X5UAAHW000054@mauve.mrochek.com> <01OWABPTPSU0000054@mauve.mrochek.com> <1374461680.11442.YahooMailNeo@web125604.mail.ne1.yahoo.com> Message-ID: <1374462831.27144.YahooMailNeo@web125604.mail.ne1.yahoo.com> Date: Sun, 21 Jul 2013 20:13:51 -0700 From: Bill Mills To: John R Levine In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-685807438-787064888-1374462831=:27144" X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 462834001 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Bill Mills List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 03:14:48 -0000 ---685807438-787064888-1374462831=:27144 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes, A applies the RRVS policy to determine if it will deliver (delivery ha= ppens to be a forward.=A0 B in this case ignores.=0A=0A=0A=A0=0A-bill=0A=0A= =0A=0A--------------------------------=0AWilliam J. Mills=0A"Paranoid" Yaho= o!=0A=0A=0A=0A=0A________________________________=0A From: John R Levine =0ATo: Bill Mills =0ACc: IETF Apps Di= scuss =0ASent: Sunday, July 21, 2013 8:02 PM=0ASubj= ect: Re: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00=0A = =0A=0A> No, what is supposed to happen is that the mail gets to the MTA for= A where=A0 forwarding is configured and the RRVS check needs to be done th= ere.=A0 They never forward to B.=0A=0AIn this case the person already has t= he "A" account and configures it to =0Aforward to his new "B" account.=A0 T= he correct thing would be for A to look =0Aat rrvs, see an address it knows= , accept the message and forward it.=A0 B =0Alooks at rrvs, sees an unknown= address and ignores it.=0A=0AI think that for non-hostile senders this sho= uld work OK.=A0 My concern is =0Awhat happens with senders who deliberately= or accidentally play games.=0A=0AR's,=0AJohn ---685807438-787064888-1374462831=:27144 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Yes, A ap= plies the RRVS policy to determine if it will deliver (delivery happens to = be a forward.  B in this case ignores.

=
 
-bill


--------------------------------William J. Mills
"Paranoid" Yahoo!


= From= : John R Levine <johnl@taugh.com>
To: Bill Mills <wmills@yahoo-inc.com>
Cc: IETF Apps Discuss <apps-dis= cuss@ietf.org>
Sent: Sunday, July 21, 2013 8:02 PM
= Subject: Re: [apps-discuss] Comments on draft-wmills-rrvs-header= -field-00

> No, wh= at is supposed to happen is that the mail gets to the MTA for A where = forwarding is configured and the RRVS check needs to be done there.  = They never forward to B.

In this case the person already has the "A"= account and configures it to
forward to his new "B" account.  The= correct thing would be for A to look
at rrvs, see an address it knows,= accept the message and forward it.  B
looks at rrvs, sees an unkn= own address and ignores it.

I think that for non-hostile senders thi= s should work OK.  My concern is
what happens with senders who deli= berately or accidentally play games.

R's,
John

---685807438-787064888-1374462831=:27144-- From ned.freed@mrochek.com Sun Jul 21 22:31:52 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D98821E8050 for ; Sun, 21 Jul 2013 22:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQcyTaoyEdYt for ; Sun, 21 Jul 2013 22:31:47 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 70C4A21E808B for ; Sun, 21 Jul 2013 22:31:47 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OWAIGCQW7K006ZYH@mauve.mrochek.com> for apps-discuss@ietf.org; Sun, 21 Jul 2013 22:26:44 -0700 (PDT) MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=iso-8859-1; format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OWAIDGIIPS007PSE@mauve.mrochek.com>; Sun, 21 Jul 2013 22:26:40 -0700 (PDT) Message-id: <01OWAIGAGVAI007PSE@mauve.mrochek.com> Date: Sun, 21 Jul 2013 22:24:44 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sun, 21 Jul 2013 22:35:41 -0400" References: <20130718202939.10687.qmail@joyce.lan> <01OW6YGX39GU000054@mauve.mrochek.com> <01OW8X5UAAHW000054@mauve.mrochek.com> <01OWABPTPSU0000054@mauve.mrochek.com> To: John R Levine Cc: Ned Freed , IETF Apps Discuss Subject: Re: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 05:31:52 -0000 > > My objection was and is to the semantics the current draft calls for. It says: > > > > 1. A user subscribes to a service "S" on data "D" and confirms an > > email address at the user's current location, "A"; > > > > 2. At some later date, the user intends to leave the current > > location, and thus creates a new mailbox elsewhere, at "B"; > > > > 3. The user replaces mailbox "A" with forwarding to "B"; > > > > 4. "S" constructs a message to "A" claiming that address was valid > > at date "D" and sends it to "A", which forwards to "B"; > > > > 5. The receiving MTA at "B" asserts that "B" has not been under > > constant ownership since "D" and rejects the message. > But the rrvs header will have the "A" address in it, and B is supposed to > ignore it. That's exactly my point. It's supposed to ignore it, not notice that "B" has not been under constant ownershp and reject. It can't do what the document says it's supposed to do. THe only way it can do what this section says to do is check address "B" against the date associated with "A", which of course is all sorts of bad. > I'm more worried about what happens when a hostile sender deliberately > puts a "B" address in a message that's likely to be remailed or forwarded. I'm worried about that as well. Ned From ned.freed@mrochek.com Sun Jul 21 22:32:00 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F25621E809F for ; Sun, 21 Jul 2013 22:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V8daTSDv7Yj8 for ; Sun, 21 Jul 2013 22:31:52 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 178C621E8091 for ; Sun, 21 Jul 2013 22:31:48 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OWAIJKHRAO00AOIN@mauve.mrochek.com> for apps-discuss@ietf.org; Sun, 21 Jul 2013 22:29:19 -0700 (PDT) MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=iso-8859-1 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OWAIDGIIPS007PSE@mauve.mrochek.com>; Sun, 21 Jul 2013 22:29:16 -0700 (PDT) Message-id: <01OWAIJIE46G007PSE@mauve.mrochek.com> Date: Sun, 21 Jul 2013 22:28:37 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sun, 21 Jul 2013 19:54:40 -0700" <1374461680.11442.YahooMailNeo@web125604.mail.ne1.yahoo.com> References: <20130718202939.10687.qmail@joyce.lan> <01OW6YGX39GU000054@mauve.mrochek.com> <01OW8X5UAAHW000054@mauve.mrochek.com> <01OWABPTPSU0000054@mauve.mrochek.com> <1374461680.11442.YahooMailNeo@web125604.mail.ne1.yahoo.com> To: Bill Mills Cc: Ned Freed , IETF Apps Discuss , John R Levine Subject: Re: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 05:32:00 -0000 > No, what is supposed to happen is that the mail gets to the MTA for A where  > forwarding is configured and the RRVS check needs to be done there.  They never > forward to B. Why would they do that? The address meets the ownership criteria. And it's the wrong result in any case. Ned From superuser@gmail.com Sun Jul 21 22:47:21 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B627B21F9E68 for ; Sun, 21 Jul 2013 22:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QUV0OvrEqODl for ; Sun, 21 Jul 2013 22:47:20 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id CACE821F9DD0 for ; Sun, 21 Jul 2013 22:47:19 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id ey16so1449631wid.3 for ; Sun, 21 Jul 2013 22:47: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=BTW+Fh0hN0fXW1cGfqbj9eqnzgfB/oB+OV72qMxupv8=; b=BxXqpR1VYWd7VfMyaeY5LwW7Zn91dUplvgAXlE1yUSLnl8DvXrl1ybE5J95GYIhT/S Wj1VqXNDo+fLBY1Lfd5oxQCfQI2ppSWv+ZdtCLUI4KBtv6t4VYD/NF1CkWTHWINmIhq8 fsLzM1Q5Jhh/O5PQDYFIuS4a+FELLVTMQ0OrFx8WIVgRZOX6lOPmYU1K+e9wQEcumO8w UiYLb5RpYArYgTJGeLTVT3xZkYGAdyIGoWIYZ98NJzUYj4FBWz5wlJxmNyYR/Pu3pXuS SFWsvloV3EUc+RhJGAbJW4rlU79EuJSP5Nzz+0RVAZI+6UEG4hGDJLWzkpQtlqFCcKvf FPew== MIME-Version: 1.0 X-Received: by 10.180.89.231 with SMTP id br7mr28883925wib.19.1374472038821; Sun, 21 Jul 2013 22:47:18 -0700 (PDT) Received: by 10.180.90.16 with HTTP; Sun, 21 Jul 2013 22:47:18 -0700 (PDT) In-Reply-To: <20130722025747.55027.qmail@joyce.lan> References: <20130722024014.GA40429@mx1.yitter.info> <20130722025747.55027.qmail@joyce.lan> Date: Sun, 21 Jul 2013 22:47:18 -0700 Message-ID: From: "Murray S. Kucherawy" To: John Levine Content-Type: multipart/alternative; boundary=e89a8f3ba255a0b7c204e2133576 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] [taugh.com-standards] Comments on draft-levine-orgboundary X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jul 2013 05:47:21 -0000 --e89a8f3ba255a0b7c204e2133576 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Jul 21, 2013 at 7:57 PM, John Levine wrote: > >To be clear if slightly pedantic about the example, the current > >registration rules don't permit the first case any more. Also as I > >understand it, case (2) sort of depends on what you mean by "same > >entity". Everything of the form [municipality].[province].ca under > >the current rules must be a department of the municipality. You can't > >register (for instance) somecompany.toronto.on.ca. This is under the > >CIRA rules for the delegation of [municipality].[province].ca. > > That may be the current rule, but I know someone whose domain is > .montreal.qc.ca. There are of course plenty of other > ccTLDs with irregular registration boundaries, e.g., trieste.it is a > geographic delegation point while triste.it is a registration. > Back when there was a committee of ISPs approving .ca domains, what level in the .ca tree you got depended on the breadth of your business. The default was to register your entity in your municipality unless you could show incorporation or operations in a wider scope. There are undoubtedly numerous domains created under that rule that still exist. -MSK --e89a8f3ba255a0b7c204e2133576 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sun, Jul 21, 2013 at 7:57 PM, John Levine <johnl@taugh.c= om> wrote:
>To be clear if slightly pedantic about the example, the current
>registration rules don't permit the first case any more. =A0Also as= I
>understand it, case (2) sort of depends on what you mean by "same<= br> >entity". =A0Everything of the form [municipality].[province].ca un= der
>the current rules must be a department of the municipality. =A0You can&= #39;t
>register (for instance) somecompany.toronto.on.ca. =A0This is under the
>CIRA rules for the delegation of [municipality].[province].ca.

That may be the current rule, but I know someone whose domain is
<something>.montr= eal.qc.ca. =A0There are of course plenty of other
ccTLDs with irregular registration boundaries, e.g., trieste.it is a
geographic delegation point while triste.it is a registration.

= Back when there was a committee of ISPs approving .ca domains, what level i= n the .ca tree you got depended on the breadth of your business.=A0 The def= ault was to register your entity in your municipality unless you could show= incorporation or operations in a wider scope.=A0 There are undoubtedly num= erous domains created under that rule that still exist.

-MSK
--e89a8f3ba255a0b7c204e2133576-- From ned.freed@mrochek.com Sun Jul 21 23:31:48 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E789A21E8050 for ; Sun, 21 Jul 2013 23:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eTFM0V2HT6qL for ; Sun, 21 Jul 2013 23:31:43 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 6C12521F99E3 for ; Sun, 21 Jul 2013 23:31:43 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OWAKJLTT5S00AFD7@mauve.mrochek.com> for apps-discuss@ietf.org; Sun, 21 Jul 2013 23:26:37 -0700 (PDT) MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=iso-8859-1; format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OWAK7I8E5S007PSE@mauve.mrochek.com>; Sun, 21 Jul 2013 23:26:32 -0700 (PDT) Message-id: <01OWAKJHT6EW007PSE@mauve.mrochek.com> Date: Sun, 21 Jul 2013 23:19:37 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sat, 20 Jul 2013 22:23:48 -0400" References: <20130718202939.10687.qmail@joyce.lan> <01OW6YGX39GU000054@mauve.mrochek.com> <01OW8X5UAAHW000054@mauve.mrochek.com> To: John R Levine Cc: Ned Freed , IETF Apps Discuss Subject: Re: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 06:31:49 -0000 > >> Another thing that needs to be mentioned is use of this facility when > >> an entire domain changes ownership. This is a little more complex than > >> it appears because of the need for addresses like postmaster@domain.com > >> to be immune to ownership changes. > Huh? If I buy some abandoned domain, postmaster@foo.tld will be a > different entity/person/whatever than it was for the previous owner. If > you want to contact the current postmaster, send mail without an rrvs > header. How is the user supposed to control that? I grant you that it is unlikely for a postmaster address to appear in a user address book. But if it happens it needs to do the right thing, and bouncing mail sent to postmaster is not it. > If you have some mailing list where the previous owner signed up > as postmaster (we know it's a bad idea but people do it), then it seems to > me that rrvs would be as likely to do the right thing as it would for any > other address. I don't think a bounce should be generated in this case. > It'd somewhat mitigate the damage if the advice to the receiver was to > compare the address in the rrvs header to the envelope, if that address is > one of the recipients then reject the message if the date is too old, > otherwise ignore it, but unconditionally delete the header before > subsequent forwarding or relaying. Agreed 100%. I think this is excellent advice that should be included, but I do note that this may be the first time we've recommended doing header modifications on autoforwarding. Additions, sure, but this goes further. > Even if the address in the header > turns out to be one to which it is subsequently relayed, if that's not the > address to which the author originally sent the message, the chances of > rrvs doing the right thing seem quite low. Agreed again. Ned From wmills@yahoo-inc.com Sun Jul 21 23:33:26 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B918021E8089 for ; Sun, 21 Jul 2013 23:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.598 X-Spam-Level: X-Spam-Status: No, score=-18.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q7jMEZPz6CsR for ; Sun, 21 Jul 2013 23:33:22 -0700 (PDT) Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) by ietfa.amsl.com (Postfix) with ESMTP id 4C94C21E8050 for ; Sun, 21 Jul 2013 23:33:22 -0700 (PDT) Received: from GQ1-EX10-CAHT04.y.corp.yahoo.com (gq1-ex10-caht04.corp.gq1.yahoo.com [10.73.118.83]) by mrout3.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id r6M6WVvc044573 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 21 Jul 2013 23:32:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1374474752; bh=R5XXW8z2Kxxq/h2Yv4YMOoxkaL+3s7OIPWGO6vcP6zs=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To:Reply-To: Content-Type:MIME-Version; b=BQ964NxY29hlQShIN+AzZQC5z6QYKALv5pq3In/So88ByXwbrPrDYNVPjiGAZHcPZ 2CQznIr82V9OThCyd0HipS4vp5bUJmRyfp0ZVZKxYO3SEoEXLurcWS8WMA38CV4QGp h61f5c03Mj0ykSLvQVMs5M+9qscHnjH0joKaPDeE= Received: from GQ1-MB05-02.y.corp.yahoo.com ([fe80::fd24:9461:3a25:f22]) by GQ1-EX10-CAHT04.y.corp.yahoo.com ([fe80::154d:d141:c8f7:3e0c%12]) with mapi id 14.03.0123.003; Sun, 21 Jul 2013 23:32:30 -0700 From: William Mills To: "johnl@taugh.com" , "apps-discuss@ietf.org" Thread-Topic: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00 Thread-Index: AQHOg1TVLiwmQf9vvUWxnrF8DyHOfZlrWbyAgAA1jgCAALtRAIAAOjKAgAAXwICAAP1LAIAAQoaAgACL3YCAAduWmQ== Date: Mon, 22 Jul 2013 06:32:30 +0000 Message-ID: References: <1374342583.81959.YahooMailNeo@web125602.mail.ne1.yahoo.com>, <20130720191019.6251.qmail@joyce.lan> In-Reply-To: <20130720191019.6251.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_xy3ds7go5jfn81w0hs1m7id91374356164281emailandroidcom_" MIME-Version: 1.0 X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 474752000 Subject: Re: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 06:33:26 -0000 --_000_xy3ds7go5jfn81w0hs1m7id91374356164281emailandroidcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I was thinking it would be a useful thing to advertisr in some way... If n= ot then no worries. Sent from my Verizon Wireless 4G LTE Smartphone -------- Original message -------- From: John Levine Date: 07/20/2013 12:11 PM (GMT-08:00) To: apps-discuss@ietf.org Cc: William Mills Subject: Re: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00 >On how a server advertises... My thought was a simple SMPT extension to ad= vertise the >capability, the sender checks this to determine if they should expect a bo= unce or nor form >RRVS. Can you write down the use case that shows how mail handling with the SMTP extension would be different from mail handling without? Either way, you deal with rrvs bounces when they happen. Servers that don't understand rrvs would just ignore the header, so there's no damage from including it anyway. --_000_xy3ds7go5jfn81w0hs1m7id91374356164281emailandroidcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I was thinking it would be a useful thing to advertisr in some way... =  If not then no worries.


Sent from my Verizon Wireless 4= G LTE Smartphone



-------- Original message --------
From: John Levine <johnl@taugh.com>
Date: 07/20/2013 12:11 PM (GMT-08:00)
To: apps-discuss@ietf.org
Cc: William Mills <wmills@yahoo-inc.com>
Subject: Re: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00 <= br>

>On how a server advertises... My thought was a= simple SMPT extension to advertise the
>capability, the sender checks this to determine if they should expect a= bounce or nor form
>RRVS.

Can you write down the use case that shows how mail handling with the
SMTP extension would be different from mail handling without?  Either<= br> way, you deal with rrvs bounces when they happen.  Servers that don't<= br> understand rrvs would just ignore the header, so there's no damage
from including it anyway.

 --_000_xy3ds7go5jfn81w0hs1m7id91374356164281emailandroidcom_-- From wmills@yahoo-inc.com Sun Jul 21 23:50:55 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F348321E8050 for ; Sun, 21 Jul 2013 23:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.455 X-Spam-Level: X-Spam-Status: No, score=-18.455 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kre4xZTBcnjS for ; Sun, 21 Jul 2013 23:50:44 -0700 (PDT) Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) by ietfa.amsl.com (Postfix) with ESMTP id DD92121F9F50 for ; Sun, 21 Jul 2013 23:50:39 -0700 (PDT) Received: from BF1-EX10-CAHT13.y.corp.yahoo.com (bf1-ex10-caht13.corp.bf1.yahoo.com [10.74.226.57]) by mrout3.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id r6M6o0Gi050470 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 21 Jul 2013 23:50:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1374475802; bh=0Igik7Q/XYFEsdOEiB1WAtt6HsvP2PYM/plJNsLYfco=; h=References:Message-ID:Date:From:Reply-To:Subject:To:CC: In-Reply-To:MIME-Version:Content-Type; b=pXk7bq3d3kd7qLQ1cmLZnZf3R3soCfknGtb1GutKKQsim+AS+eM1ZgP6NE5m5L4gO mAaL9KUctMrZuS5zW8J3mgh/UwNFRueJT3l+CQ0CGP9OOTketogCUXXrq9SIzJnNZj ZU6yJTtjFrj7OWJhAPLBur01BGsRj84y5ATbEhQ0= Received: from omp1058.mail.ne1.yahoo.com (98.138.89.244) by BF1-EX10-CAHT13.y.corp.yahoo.com (10.74.209.170) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 22 Jul 2013 02:50:00 -0400 Received: (qmail 15360 invoked by uid 1000); 22 Jul 2013 06:49:59 -0000 Received: (qmail 48035 invoked by uid 60001); 22 Jul 2013 06:49:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1374475799; bh=ZDnjUFKJ80il5gNBKX5mmb624fElzgyv+Pv0E5PyslU=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=hXE69aPD48Fi4YPzMKtnqeJnpOTkF50thFRfJwyGXyTAGmWArH2dHcRzQcISi5aBkHMt3PmA+5DYe7pJRuwFnAfoL/nvmV85AhduEq8cCjJRcIx6I3Cainw4L8v7kCzVbKyB0Tw0vlosrZJxJPVfyOH3AOe2ZI1re641qq98mg8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=gmz+E3GeyozUP36Hq/8n8i3se0ZpCV3kKAtyNMuEwPUKNje018Wj4dMsOw2UktkjN1ktTsZYDXqEaWntMvEhenetbNjygE0z3lgVSwAqtY9xAhCFrd/Fq6uEw8AJy54a3OrG0d0VzY+rmbpGl/Q9c6GCa5ujTx5IhN7cfeZ+OpA=; X-YMail-OSG: PTS10iYVM1m4EbvNzZD7VEJ_hM_lxzIhg_V9kNtzKHj5G9u 4uniB1tKTQTS1MuI22AAa_ajbDX1prh4XtUgBq_.zEtcCvgnUzaAbwQpz7bH _Kkiy.jxeEcBu5etvmVKArROdB2XPDI3S5fSI7.Cs32Qe7JFeK5UN53p9qNm Pq1iPBmMx6VMgvzzV3lFRDSSZyAJSMevuynvbpbNHPx8aR2vfY3qBBi6Og8B BxPuKcIoWvYA8L9fq30I4Qt2sxTOWWv8Jj4intCPQaHKGlsYDxOlJBi..b3h Oo2DkDeK6uAHzN2BTB.ASJsKGlieLPYM36XCMlSV6 Received: from [99.31.212.42] by web125605.mail.ne1.yahoo.com via HTTP; Sun, 21 Jul 2013 23:49:58 PDT X-Rocket-MIMEInfo: 002.001, SSBzYWlkIGl0IGJldHRlciBpbiB0aGUgb3RoZXIgbWVzc2FnZS7CoCBUaGUgaW50ZW50IGlzIHRvIGV2YWx1YXRlIHJydnMgYXQgdGhlIHNlcnZlciB0aGF0IHNob3VsZCBrbm93IGFib3V0IHRoZSBwcmltYXJ5IGFkZHJlc3NlZSwgaW4gdGhpcyBjYXNlIEEuwqAgQSBhcHBsaWVzIHRoZSBwb2xpY3kgYW5kIHRoZW4gZWl0aGVyIGJvdW5jZXMgb3IgZGVsaXZlcnMuwqAgT25jZSBmb3J3YXJkZWQgcnJ2cyB3b3VsZCBuZXZlciBhcHBseS7CoCBDb25jZXB0dWFsbHkgdGhpcyBtYWtlcyBzZW5zZSBhcyB0aGUgc2UBMAEBAQE- X-Mailer: YahooMailWebService/0.8.150.561 References: <20130718202939.10687.qmail@joyce.lan> <01OW6YGX39GU000054@mauve.mrochek.com> <01OW8X5UAAHW000054@mauve.mrochek.com> <01OWABPTPSU0000054@mauve.mrochek.com> <1374461680.11442.YahooMailNeo@web125604.mail.ne1.yahoo.com> <01OWAIJIE46G007PSE@mauve.mrochek.com> Message-ID: <1374475798.32985.YahooMailNeo@web125605.mail.ne1.yahoo.com> Date: Sun, 21 Jul 2013 23:49:58 -0700 From: Bill Mills To: Ned Freed In-Reply-To: <01OWAIJIE46G007PSE@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1124617404-1070189917-1374475798=:32985" X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 475801016 Cc: John R Levine , IETF Apps Discuss Subject: Re: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Bill Mills List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 06:50:55 -0000 ---1124617404-1070189917-1374475798=:32985 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I said it better in the other message.=A0 The intent is to evaluate rrvs at= the server that should know about the primary addressee, in this case A.= =A0 A applies the policy and then either bounces or delivers.=A0 Once forwa= rded rrvs would never apply.=A0 Conceptually this makes sense as the sender= only knows about the primary recipient(s) and is ignorant of forwarding (h= ow the mail will be delivered).=0A=0A=0A=A0=0A-bill=0A=0A=0A=0A------------= --------------------=0AWilliam J. Mills=0A"Paranoid" Yahoo!=0A=0A=0A=0A=0A_= _______________________________=0A From: Ned Freed = =0ATo: Bill Mills =0ACc: Ned Freed ; Murray S. Kucherawy ; John R Levine ; IETF Apps Discuss =0ASent: Sunday, July 21= , 2013 10:28 PM=0ASubject: Re: [apps-discuss] Comments on draft-wmills-rrvs= -header-field-00=0A =0A=0A> No, what is supposed to happen is that the mail= gets to the MTA for A where=A0=0A> forwarding is configured and the RRVS c= heck needs to be done there.=A0 They never=0A> forward to B.=0A=0AWhy would= they do that? The address meets the ownership criteria. And it's=0Athe wro= ng result in any case.=0A=0A=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 Ned ---1124617404-1070189917-1374475798=:32985 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I said it= better in the other message.  The intent is to evaluate rrvs at the s= erver that should know about the primary addressee, in this case A.  A= applies the policy and then either bounces or delivers.  Once forward= ed rrvs would never apply.  Conceptually this makes sense as the sende= r only knows about the primary recipient(s) and is ignorant of forwarding (= how the mail will be delivered).

 =
-bill


--------------------------------
William J.= Mills
"Paranoid" Yahoo!


From:<= /b> Ned Freed <ned.freed@mrochek.com>
To: Bill Mills <wmills@yahoo-inc.com>
Cc: Ned Freed <ned.freed@mro= chek.com>; Murray S. Kucherawy <superuser@gmail.com>; John R Levin= e <johnl@taugh.com>; IETF Apps Discuss <apps-discuss@ietf.org> =
Sent: Sunday, July 21= , 2013 10:28 PM
Subject: Re: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00

> No, what is supposed to= happen is that the mail gets to the MTA for A where 
> forwardi= ng is configured and the RRVS check needs to be done there.  They never
= > forward to B.

Why would they do that? The address meets the own= ership criteria. And it's
the wrong result in any case.

 &nb= sp;              Ned
<= br>
---1124617404-1070189917-1374475798=:32985-- From ajs@anvilwalrusden.com Mon Jul 22 07:08:59 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3481111E80D5 for ; Mon, 22 Jul 2013 07:08:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.793 X-Spam-Level: X-Spam-Status: No, score=-0.793 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iTTS5aLK94K2 for ; Mon, 22 Jul 2013 07:08:47 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 9517E11E80AE for ; Mon, 22 Jul 2013 07:08:47 -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 CD96E8A031 for ; Mon, 22 Jul 2013 14:08:46 +0000 (UTC) Date: Mon, 22 Jul 2013 10:08:51 -0400 From: Andrew Sullivan To: apps-discuss@ietf.org Message-ID: <20130722140850.GA41416@mx1.yitter.info> References: <20130722024014.GA40429@mx1.yitter.info> <20130722025747.55027.qmail@joyce.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130722025747.55027.qmail@joyce.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [apps-discuss] [taugh.com-standards] Comments on draft-levine-orgboundary X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jul 2013 14:08:59 -0000 On Mon, Jul 22, 2013 at 02:57:47AM -0000, John Levine wrote: > You can use my grosse hackque with the wildcards, where the closest > encloser rule finds the deepest relevant delegation point. I really need to spend some more time working out scenarios of that, because I'm not entirely sure it works in every case. I'm not entirely sure it _doesn't_, either, but I'm a little nervous about it. I think the draft could benefit from some more examples in this area. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From masinter@adobe.com Mon Jul 22 07:46:17 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64F4121E808A for ; Mon, 22 Jul 2013 07:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.371 X-Spam-Level: X-Spam-Status: No, score=-5.371 tagged_above=-999 required=5 tests=[AWL=-1.227, BAYES_00=-2.599, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eRJMBzB+BkBv for ; Mon, 22 Jul 2013 07:46:11 -0700 (PDT) Received: from exprod6og123.obsmtp.com (exprod6og123.obsmtp.com [64.18.1.241]) by ietfa.amsl.com (Postfix) with ESMTP id 666F621E8093 for ; Mon, 22 Jul 2013 07:46:01 -0700 (PDT) Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by exprod6ob123.postini.com ([64.18.5.12]) with SMTP ID DSNKUe1FpxHCzp3fkufYt5rDqO4SiBb+CYdh@postini.com; Mon, 22 Jul 2013 07:46:02 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r6MEgVD8017936; Mon, 22 Jul 2013 07:42:31 -0700 (PDT) Received: from nahub02.corp.adobe.com (nahub02.corp.adobe.com [10.8.189.98]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r6MEju6A010549; Mon, 22 Jul 2013 07:45:56 -0700 (PDT) Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nahub02.corp.adobe.com ([10.8.189.98]) with mapi; Mon, 22 Jul 2013 07:45:57 -0700 From: Larry Masinter To: James M Snell Date: Mon, 22 Jul 2013 07:45:53 -0700 Thread-Topic: [apps-discuss] RFC 2388 (multipart/form-data) Thread-Index: Ac6DHNgQs8MYc3ylTv+YDxQdgF3FKADzIjQQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Ian Hickson , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] RFC 2388 (multipart/form-data) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jul 2013 14:46:17 -0000 dGhlIGZpcnN0IHN0ZXAgd291bGQgYmUgdG8gZ2V0IGEgZmV3IHBlb3BsZSBmYW1pbGlhciB3aXRo IG11bHRpcGFydC9mb3JtLWRhdGEgaW1wbGVtZW50YXRpb25zDQpvZiB2YXJpb3VzIHNvcnRzIHRv IHJldmlldyBteSBjb21tZW50cyBodHRwczovL3d3dy53My5vcmcvQnVncy9QdWJsaWMvc2hvd19i dWcuY2dpP2lkPTE2OTA5I2M4IA0KSSB0aGluayB0aGVyZSBhcmUgdGhyZWUgY2xhc3NlcyBvZiBp bXBsZW1lbnRvcnM6DQoqIHRob3NlIGNyZWF0aW5nIEhUTUwgZm9ybXMgd2l0aCBhIHN1Ym1pc3Np b24gdHlwZSBvZiBtdWx0aXBhcnQvZm9ybS1kYXRhIChhbmQgdG9vbHMgZm9yIGZvcm0gY3JlYXRv cnMpDQoqIHRob3NlIGJ1aWxkaW5nIHNlcnZlcnMvc2l0ZXMvcHJvY2Vzc29ycyB0aGF0IHJlY2Vp dmUgYW5kIHByb2Nlc3MgbXVsdGlwYXJ0L2Zvcm0tZGF0YQ0KKiBicm93c2VyIG1ha2VycyB3aG9z ZSBjb2RlIGNyZWF0ZXMgbXVsdGlwYXJ0L2Zvcm0tZGF0YQ0KDQphcmUgdGhlcmUgb3RoZXJzPyBI b3cgY2FuIHdlIGdldCByZXByZXNlbnRhdGl2ZXMgb2YgZWFjaCBraW5kIG9mIGltcGxlbWVudGF0 aW9uDQp0byB3b3JrIHRvZ2V0aGVyIG9uIGFuIGFncmVlbWVudCBhYm91dCB3aGF0IHRoZXkgc2hv dWxkIGRvPw0KDQpMYXJyeQ0KLS0NCmh0dHA6Ly9sYXJyeS5tYXNpbnRlci5uZXQNCg0KDQo+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEphbWVzIE0gU25lbGwgW21haWx0bzpq YXNuZWxsQGdtYWlsLmNvbV0NCj4gU2VudDogV2VkbmVzZGF5LCBKdWx5IDE3LCAyMDEzIDExOjM4 IEFNDQo+IFRvOiBMYXJyeSBNYXNpbnRlcg0KPiBDYzogSWFuIEhpY2tzb247IGFwcHMtZGlzY3Vz c0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW2FwcHMtZGlzY3Vzc10gUkZDIDIzODggKG11bHRp cGFydC9mb3JtLWRhdGEpDQo+IA0KPiBVcGRhdGluZyBvciByZWZpbmluZyBSRkMyMzg4IGlzIGN1 cnJlbnRseSBub3Qgb24gbXkgYWdlbmRhLCBob3dldmVyLA0KPiBvbmNlIEhUVFAvMiBwcm9ncmVz c2VzIGEgYml0IGZ1cnRoZXIgZG93biB0aGUgcm9hZCBhbmQgbWF0dXJlcyBJIGRvDQo+IGludGVu ZCB0byBleHBsb3JlIHVzaW5nIHRoYXQgYmluYXJ5IGZyYW1pbmcgbW9kZWwgYXMgYSBwb3NzaWJs ZQ0KPiByZXBsYWNlbWVudCBmb3IgbXVsdGlwYXJ0IG1pbWUgcGFja2FnaW5nIGFuZCBtdWx0aXBh cnQgZm9ybS4gSSBzdXNwZWN0DQo+IHRoYXQgd29yayB3b24ndCBsaWtlbHkgYmVnaW4gdW50aWwg bmV4dCB5ZWFyLCBob3dldmVyLg0KPiANCj4gT24gV2VkLCBKdWwgMTcsIDIwMTMgYXQgMTE6MDIg QU0sIExhcnJ5IE1hc2ludGVyIDxtYXNpbnRlckBhZG9iZS5jb20+DQo+IHdyb3RlOg0KPiA+IElm IHRoZXJlIGlzIGFueW9uZSBpbnRlcmVzdGVkIGluIHdvcmtpbmcgb24gdXBkYXRpbmcgUkZDIDIz ODggYW5kIHJlbGF0ZWQNCj4gPiBzcGVjcywgcGxlYXNlIGxldCBtZSBrbm93Lg0KPiA+DQo+ID4g SSdtIG5vdCBjb252aW5jZWQgdGhhdCBSRkMgMjM4OCBsZWF2ZXMgbW9yZSB1bmRlZmluZWQgdGhh bg0KPiA+IGl0IHNob3VsZCwgYWx0aG91Z2ggdGhlcmUncyBjbGVhcmx5IGJlZW4gc29tZSBjb25m dXNpb24gYWJvdXQNCj4gPiB3aGF0IGl0IHNhaWQgYW5kIGNlcnRhaW5seSBpbXBsZW1lbnRhdGlv bnMgbm93IHZhcnkgZW5vdWdoDQo+ID4gdGhhdCBSRkMgMjM4OCBpcyBub3QgYSBnb29kIGltcGxl bWVudGF0aW9uIGd1aWRlIGZvciBhbnkgb2YNCj4gPiB0aGUgcm9sZXMgKGZvcm0gY3JlYXRvciwg ZmlsbGVkLWZvcm0gdG8gZm9ybS1kYXRhIGNvbnN0cnVjdG9yLA0KPiA+IGZvcm0tZGF0YSBwYXJz ZXIgYW5kIGludGVycHJldGVyKS4NCj4gPg0KPiA+IFNlZSBjb21tZW50cw0KPiA+IGh0dHBzOi8v d3d3LnczLm9yZy9CdWdzL1B1YmxpYy9zaG93X2J1Zy5jZ2k/aWQ9MTY5MDkjYzgNCj4gPg0KPiA+ DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IGFwcHMtZGlzY3Vz cy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86YXBwcy1kaXNjdXNzLQ0KPiBib3VuY2VzQGlldGYu b3JnXQ0KPiA+PiBPbiBCZWhhbGYgT2YgSWFuIEhpY2tzb24NCj4gPj4gU2VudDogRnJpZGF5LCBK dWx5IDEyLCAyMDEzIDEwOjQwIEFNDQo+ID4+IFRvOiBhcHBzLWRpc2N1c3NAaWV0Zi5vcmcNCj4g Pj4gU3ViamVjdDogW2FwcHMtZGlzY3Vzc10gUkZDIDIzODggKG11bHRpcGFydC9mb3JtLWRhdGEp DQo+ID4+DQo+ID4+DQo+ID4+IEhpLA0KPiA+Pg0KPiA+PiBEbyB5b3Uga25vdyBpZiB0aGVyZSBp cyBhbnlvbmUgd29ya2luZyBvbiBmaXhpbmcgUkZDMjM4OD8gUGVvcGxlIGtlZXANCj4gPj4gYXNr aW5nIG1lIHRvIHVwZGF0ZSB0aGUgSFRNTCBzcGVjIHRvIGp1c3QgZGVmaW5lIGl0IGFsbCBpbmxp bmUgcmF0aGVyIHRoYW4NCj4gPj4gZGVmZXJyaW5nIHRvIHRoZSBSRkMgc2luY2UgdGhlIFJGQyBs ZWF2ZXMgYSBsb3Qgb2Ygc3R1ZmYgdW5kZXJkZWZpbmVkLCBidXQNCj4gPj4gSSBkb24ndCBoYXZl IHRoZSBiYW5kd2lkdGggdG8gc3BlYyBhbGwgdGhhdCBteXNlbGYgYXQgdGhpcyBwb2ludC4NCj4g Pj4NCj4gPj4gZS5nLjoNCj4gPj4gICAgaHR0cHM6Ly93d3cudzMub3JnL0J1Z3MvUHVibGljL3No b3dfYnVnLmNnaT9pZD0xNjkwOQ0KPiA+PiAgICBodHRwczovL3d3dy53My5vcmcvQnVncy9QdWJs aWMvc2hvd19idWcuY2dpP2lkPTE5ODc5DQo+ID4+DQo+ID4+IE90aGVyIGZlZWRiYWNrOg0KPiA+ PiAgICBodHRwOi8vbGlzdHMudzMub3JnL0FyY2hpdmVzL1B1YmxpYy9wdWJsaWMtd2hhdHdnLQ0K PiA+PiBhcmNoaXZlLzIwMTJPY3QvMDIwNC5odG1sDQo+ID4+ICAgIGh0dHA6Ly9saXN0cy53My5v cmcvQXJjaGl2ZXMvUHVibGljL3B1YmxpYy13aGF0d2ctDQo+IGFyY2hpdmUvMjAxMkp1bC8wMDM3 Lmh0bWwNCj4gPj4gICAgaHR0cDovL2xpc3RzLnczLm9yZy9BcmNoaXZlcy9QdWJsaWMvcHVibGlj LXdoYXR3Zy0NCj4gPj4gYXJjaGl2ZS8yMDEyTWF5LzAwMDMuaHRtbA0KPiA+Pg0KPiA+PiBJIGFz a2VkIExhcnJ5IE1hc2ludGVyIGlmIGhlIHdhcyBzdGlsbCBtYWludGFpbmluZyB0aGUgUkZDLCBi dXQgaGUgc2FpZCBoZQ0KPiA+PiB3YXNuJ3QsIGFuZCBzdWdnZXN0ZWQgSSBhc2sgaGVyZSB0byBm aW5kIG91dCB3aG8gd2FzIG1haW50YWluaW5nIGl0IG5vdy4NCj4gPj4NCj4gPj4gVGhhbmtzIGlu IGFkdmFuY2UsDQo+ID4+IC0tDQo+ID4+IElhbiBIaWNrc29uICAgICAgICAgICAgICAgVSsxMDQ3 RSAgICAgICAgICAgICAgICApXC5fLiwtLS4uLi4sJ2BgLiAgICBmTA0KPiA+PiBodHRwOi8vbG4u aGl4aWUuY2gvICAgICAgIFUrMjYzQSAgICAgICAgICAgICAgICAvLCAgIF8uLiBcICAgX1wgIDtg Ll8gLC4NCj4gPj4gVGhpbmdzIHRoYXQgYXJlIGltcG9zc2libGUganVzdCB0YWtlIGxvbmdlci4g ICBgLl8uLSgsXy4uJy0tKCxfLi4nYC0uOy4nDQo+ID4+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+IGFwcHMtZGlzY3VzcyBtYWlsaW5nIGxpc3QN Cj4gPj4gYXBwcy1kaXNjdXNzQGlldGYub3JnDQo+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vYXBwcy1kaXNjdXNzDQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBhcHBzLWRpc2N1c3MgbWFpbGluZyBsaXN0DQo+ ID4gYXBwcy1kaXNjdXNzQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9hcHBzLWRpc2N1c3MNCg== From masinter@adobe.com Mon Jul 22 10:05:30 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7D4211E81A0 for ; Mon, 22 Jul 2013 10:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.998 X-Spam-Level: X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WnFBqKyKsNrm for ; Mon, 22 Jul 2013 10:05:24 -0700 (PDT) Received: from exprod6og112.obsmtp.com (exprod6og112.obsmtp.com [64.18.1.29]) by ietfa.amsl.com (Postfix) with ESMTP id 962D711E8123 for ; Mon, 22 Jul 2013 09:50:13 -0700 (PDT) Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob112.postini.com ([64.18.5.12]) with SMTP ID DSNKUe1iu3U4/ElXPDzfKysRzOSvrOWNQufu@postini.com; Mon, 22 Jul 2013 09:50:20 PDT Received: from inner-relay-2.corp.adobe.com (mail-321.eur.adobe.com [153.32.1.52]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r6MGe8AI005786; Mon, 22 Jul 2013 09:40:08 -0700 (PDT) Received: from nahub02.corp.adobe.com (nahub02.corp.adobe.com [10.8.189.98]) by inner-relay-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r6MGe6w7013521; Mon, 22 Jul 2013 09:40:07 -0700 (PDT) Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nahub02.corp.adobe.com ([10.8.189.98]) with mapi; Mon, 22 Jul 2013 09:40:06 -0700 From: Larry Masinter To: "Murray S. Kucherawy" , IETF Apps Discuss Date: Mon, 22 Jul 2013 09:39:51 -0700 Thread-Topic: [apps-discuss] FINAL CALL for IETF 87 (Berlin) agenda items Thread-Index: Ac6Buoo+yENt+gKPQ0yQpctcg6pD8QFPzQSw Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C68CB012D9182D408CED7B884F441D4D34725CB2C5nambxv01acorp_" MIME-Version: 1.0 Subject: Re: [apps-discuss] FINAL CALL for IETF 87 (Berlin) agenda items X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jul 2013 17:05:31 -0000 --_000_C68CB012D9182D408CED7B884F441D4D34725CB2C5nambxv01acorp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If not too late for agenda items: If there's interest (e.g., someone else on the mailing list saying 'please'= ), we could review multipart/form-data and/or dated URI. --_000_C68CB012D9182D408CED7B884F441D4D34725CB2C5nambxv01acorp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

If not too late for agenda = items:

=  

= If there’s interest (e.g., someone else on the mailing list saying &#= 8216;please’), we could review multipart/form-data and/or dated URI.<= o:p>

&n= bsp;

&n= bsp;

= --_000_C68CB012D9182D408CED7B884F441D4D34725CB2C5nambxv01acorp_-- From johnl@iecc.com Mon Jul 22 10:34:14 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BF6C11E811D for ; Mon, 22 Jul 2013 10:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.6 X-Spam-Level: X-Spam-Status: No, score=-108.6 tagged_above=-999 required=5 tests=[HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BSgayQj4PwFz for ; Mon, 22 Jul 2013 10:34:08 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id B2E9F11E8122 for ; Mon, 22 Jul 2013 10:34:00 -0700 (PDT) Received: (qmail 32547 invoked from network); 22 Jul 2013 17:33:58 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 22 Jul 2013 17:33:58 -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=51ed6d06.xn--i8sz2z.k1307; i=johnl@user.iecc.com; bh=fver103PPMAA2RQsocYsBEqF46wS9QdYufNx/KzIuNM=; b=2wggLis10DaqUFco1KnHRouScz0tqcxH1O9PSHOVe1tTpDihZcHKg+TwSb0OvyHvkgZKzEiQh1N1vs2DpmxHMhLYyNzFZ3P7iDV1HX9MSJabOwW/HX6r0ES82ZWeZkKavjZts3oBOLq6PygmUIoowwUBU5E6LL9xmXlVIlRLVTYsgUsuR/UkiV//5eKT0Vq3SS2sA9bcqFisL7F+LbXHRoHMxZchEvE0QzsTOxFBbPhRNo1wSrs34GYVqrVLPx6x 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=51ed6d06.xn--i8sz2z.k1307; olt=johnl@user.iecc.com; bh=fver103PPMAA2RQsocYsBEqF46wS9QdYufNx/KzIuNM=; b=K5OQtsFwaDkWN3PhytMtugAIe/+GZ+ZWPIYXLhBC0cHnuV8hOeN3z0bY9mHMOQjY/F6snOsoAyqM4Fa/7ANsxov0HJlekvm0b9lQaJCkqrCC0brlICsa81HhXDKRddpHCvEYsdH7dTtA0Dj5LOxyxHBF/ic75I7jsu99CYlKtlUxp82bwVU2ZNZjsF6pyXNljrw/XGQ+8XineZznK28kdQplaO3QGyJhiem3vVY/cizHzfIWy2B2WZeFd6IrevYN Date: 22 Jul 2013 17:33:36 -0000 Message-ID: <20130722173336.61136.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <20130722140850.GA41416@mx1.yitter.info> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [apps-discuss] [taugh.com-standards] Comments on draft-levine-orgboundary X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jul 2013 17:34:14 -0000 >> You can use my grosse hackque with the wildcards, where the closest >> encloser rule finds the deepest relevant delegation point. > >I really need to spend some more time working out scenarios of that, >because I'm not entirely sure it works in every case. I'm not >entirely sure it _doesn't_, either, but I'm a little nervous about it. Please do, but given how simple the closest encloser rule is, I'd be surprised if it didn't work the way I claimed. >I think the draft could benefit from some more examples in this area. Easy enough, give or take the paucity of officially designated example domains. R's, John From johnl@iecc.com Mon Jul 22 10:34:41 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D35C711E80D9 for ; Mon, 22 Jul 2013 10:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.6 X-Spam-Level: X-Spam-Status: No, score=-108.6 tagged_above=-999 required=5 tests=[HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVL-IcqJQD8N for ; Mon, 22 Jul 2013 10:34:38 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id E704D11E811D for ; Mon, 22 Jul 2013 10:34:32 -0700 (PDT) Received: (qmail 32684 invoked from network); 22 Jul 2013 17:34:32 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 22 Jul 2013 17:34:32 -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=51ed6d28.xn--30v786c.k1307; i=johnl@user.iecc.com; bh=fQc9Bx35xMkiyZ5O3D7QGLV1feC4uqpxDNywKx6zbcc=; b=BaBvBdEkBPjgMSOkOfVDNtFLJ6C8riHYWBqsKlciJZDTIQxOcernM4L3KECdimpdqCp1otZgmdPcQcP/YojgLYiM9lzM3kHkzo5Dkt+pm+cQB/CjrgGrKFjsh+V5Vfm1pqRv735V+eHrTUGJ9+H8VmxhO3qIbxoBeIuORrLAaxAR/38b1Mu9HnN0Ep4gb2yzq2+9S1TyjcCoO9SwQtOftw5kuRHgU+7qTqjq8S4AKyARwwew5koquqFtVxfqtzEn 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=51ed6d28.xn--30v786c.k1307; olt=johnl@user.iecc.com; bh=fQc9Bx35xMkiyZ5O3D7QGLV1feC4uqpxDNywKx6zbcc=; b=nBFLsDk2PU3dsHDd/8lIp9qtgrwa/ugilSuxNkt0SPXuRSzLUfWPWTm+WYHfcA97PphB5tA/1grvY1NOOpI0NROrTM7VLXVK28lIgmEtTgaNtW66E54tBnfwbg+ELZVWLcSRlkK5CaW4+NxVWV6k7l+XvJ8lcPk0ho3kg4nsOpk+uVJlaki5c23UOP/ykJfmiC32BYofJXvW+ln7cZTGexpPKQROA8uSe2QvuMlFBEQnYLXM+NqcGYjuhFjg2N3G Date: 22 Jul 2013 17:34:10 -0000 Message-ID: <20130722173410.61160.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 Subject: Re: [apps-discuss] FINAL CALL for IETF 87 (Berlin) agenda items X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jul 2013 17:34:42 -0000 >If not too late for agenda items: > >If there's interest (e.g., someone else on the mailing list saying 'please'), we could review multipart/form-data >and/or dated URI. multipart/form-data. yes please -- Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From ajs@anvilwalrusden.com Mon Jul 22 10:38:06 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E814C11E80DE for ; Mon, 22 Jul 2013 10:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.759 X-Spam-Level: * X-Spam-Status: No, score=1.759 tagged_above=-999 required=5 tests=[HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pTuM83ZctLiB for ; Mon, 22 Jul 2013 10:38:01 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id EE0B111E811F for ; Mon, 22 Jul 2013 10:37:39 -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 6359A8A031 for ; Mon, 22 Jul 2013 17:37:38 +0000 (UTC) Date: Mon, 22 Jul 2013 13:37:37 -0400 From: Andrew Sullivan To: apps-discuss@ietf.org Message-ID: <20130722173736.GN41416@mx1.yitter.info> References: <20130722140850.GA41416@mx1.yitter.info> <20130722173336.61136.qmail@joyce.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130722173336.61136.qmail@joyce.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [apps-discuss] [taugh.com-standards] Comments on draft-levine-orgboundary X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jul 2013 17:38:07 -0000 On Mon, Jul 22, 2013 at 05:33:36PM -0000, John Levine wrote: > > Please do, but given how simple the closest encloser rule is, I'd > be surprised if it didn't work the way I claimed. I'm not worried about the closest encloser rule. I'm worried about wildcard behaviour. A -- Andrew Sullivan ajs@anvilwalrusden.com From johnl@iecc.com Mon Jul 22 16:08:55 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1273F11E8185 for ; Mon, 22 Jul 2013 16:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.9 X-Spam-Level: X-Spam-Status: No, score=-109.9 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1EWbl-4qGb0I for ; Mon, 22 Jul 2013 16:08:44 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id A9A1011E8189 for ; Mon, 22 Jul 2013 16:08:44 -0700 (PDT) Received: (qmail 16628 invoked from network); 22 Jul 2013 23:08:44 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 22 Jul 2013 23:08:44 -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=51edbb7c.xn--30v786c.k1307; i=johnl@user.iecc.com; bh=bXcdsEP9INEU3SRu15gR8OkHzzRx6sYvnpt8prXWmAE=; b=K6sDo7aX1+2KgzW/o+XcaAfXtDoi2HNcKXClRc26wn96zOv9Y9ruY9OJftBeP4yUnIviQg06EmmZeunbgfKCceW/pgYxQvKn80sJv/VUQV2ihkDAW307rLNOaJi7+pnMXP0kewhcWWrnw0vejIpUOCyJRS+/lWb8BrUkEZY8SSFzNxCvvDXzhBjPq4nlaKMGe4ZwfXxN08eF4p7sVarcZ3sJcO/eZ40s5DdxT1VEb5KIjHsWBYYgKsc1TdOEAdRM 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=51edbb7c.xn--30v786c.k1307; olt=johnl@user.iecc.com; bh=bXcdsEP9INEU3SRu15gR8OkHzzRx6sYvnpt8prXWmAE=; b=SUmJwv/yztd7g/KRYwTIUaKPygAG5IxGAxR+p5BReW/TdRiAvGGFVVTrRkjyhlN65mAH7iOj0E+0gH9sCEpRwBDoOdqOYOVVgmLWAAHjKvzH4bmsjcB+Txz0B+q7/akbvtVYF0CsHmntyyutWGRvJQHTGUMEQwON4/S8kpw/NXsRTUCTtcJlXk/S3n7qXtZ/o4WL1RIBLDw/dltUyXK977dkX5yUtxh9b4ICpHzQRpGyHPXsTIL3XLi//dHetHdS Date: 22 Jul 2013 23:08:21 -0000 Message-ID: <20130722230821.62819.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <20130722173736.GN41416@mx1.yitter.info> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [apps-discuss] [taugh.com-standards] Comments on draft-levine-orgboundary X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jul 2013 23:08:55 -0000 [ off list ] >> Please do, but given how simple the closest encloser rule is, I'd >> be surprised if it didn't work the way I claimed. > >I'm not worried about the closest encloser rule. I'm worried about >wildcard behaviour. Um, the closest encloser rule is wildcard behavior. It's defined in RFC 4592. If you're worried that the name servers that will serve *.on._ob.ca and the like won't properly implement closest encloser, I suppose that might be a problem, but I don't ever recall seeing a problem report like that. R's, John From daniel@haxx.se Tue Jul 23 04:18:40 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 392AE11E820E for ; Tue, 23 Jul 2013 04:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LV6GydmmRfJw for ; Tue, 23 Jul 2013 04:18:39 -0700 (PDT) Received: from giant.haxx.se (www.haxx.se [IPv6:2a00:1a28:1200:9::2]) by ietfa.amsl.com (Postfix) with ESMTP id 85A0111E81A5 for ; Tue, 23 Jul 2013 04:18:37 -0700 (PDT) Received: from giant.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id r6NBIH5S027500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 23 Jul 2013 13:18:17 +0200 Received: from localhost (dast@localhost) by giant.haxx.se (8.14.4/8.14.4/Submit) with ESMTP id r6NBIF1J027497; Tue, 23 Jul 2013 13:18:15 +0200 X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs Date: Tue, 23 Jul 2013 13:18:15 +0200 (CEST) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: Larry Masinter In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-fromdanielhimself: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Ian Hickson , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] RFC 2388 (multipart/form-data) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jul 2013 11:18:40 -0000 On Mon, 22 Jul 2013, Larry Masinter wrote: > * browser makers whose code creates multipart/form-data > > are there others? How can we get representatives of each kind of > implementation to work together on an agreement about what they should do? I would categorize myself in a variation of this group. curl and libcurl offer multipart/form-data support but not necessarily/rarely for browsers, but for command line users and various programs who want to submit multipart data over HTTP. -- / daniel.haxx.se From superuser@gmail.com Tue Jul 23 09:46:44 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10F0111E8213 for ; Tue, 23 Jul 2013 09:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.359 X-Spam-Level: X-Spam-Status: No, score=-1.359 tagged_above=-999 required=5 tests=[AWL=-0.979, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, TVD_SPACE_RATIO=2.219] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DDk--x5oLB07 for ; Tue, 23 Jul 2013 09:46:43 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 538C211E82CE for ; Tue, 23 Jul 2013 09:46:40 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id hj3so3263501wib.4 for ; Tue, 23 Jul 2013 09:46:39 -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=u1T/KTIeOT5R1i2Aik94tPackbcaKzRQIhv3Dg/M2C4=; b=E1eItoSTKMxYMUR8l2sCEQ3UcZmL3bef9u/gpej8IluIZx+c50hp+iZdCXlKITJm56 a14EJm/hsRWNDpB1PSsceiWgJUBpvNBxE6WP3KFjSdNGvvHTj65O8tHhmIwkdfUDHhOP RJmq8+mtQ8P9qR5zXWMAOGBbVeXPaa/JdSvmAdF+YFvtegmleh6wYr07H7jfFXAIFoOd R00SFS8qOGUbbTVdUk4mXV2uYOeCHMyt0gLHXO3HxjGwFKhPjQ0WF1GN9vbE6+IcUlzj cmZynKOQWmse46ESqL5PCJ7tqnmCOhghQNSH77mlHwS9xFIqDcuehA908t/zLPe0kL9y bX0Q== MIME-Version: 1.0 X-Received: by 10.180.102.37 with SMTP id fl5mr33616294wib.52.1374597999430; Tue, 23 Jul 2013 09:46:39 -0700 (PDT) Received: by 10.180.125.36 with HTTP; Tue, 23 Jul 2013 09:46:39 -0700 (PDT) Date: Tue, 23 Jul 2013 09:46:39 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=f46d044517f777131904e23089ba Subject: [apps-discuss] Revised APPSAWG/APPAREA agenda posted X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jul 2013 16:46:44 -0000 --f46d044517f777131904e23089ba Content-Type: text/plain; charset=ISO-8859-1 http://www.ietf.org/proceedings/87/agenda/agenda-87-appsawg Comments welcome. -MSK, APPSAWG co-chair --f46d044517f777131904e23089ba Content-Type: text/html; charset=ISO-8859-1
Comments welcome.

-MSK, APPSAWG co-chair

--f46d044517f777131904e23089ba-- From masinter@adobe.com Wed Jul 24 05:25:34 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E931B11E8219 for ; Wed, 24 Jul 2013 05:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1gLSONwDuvTX for ; Wed, 24 Jul 2013 05:25:29 -0700 (PDT) Received: from exprod6og108.obsmtp.com (exprod6og108.obsmtp.com [64.18.1.21]) by ietfa.amsl.com (Postfix) with ESMTP id 57C7711E8215 for ; Wed, 24 Jul 2013 05:25:28 -0700 (PDT) Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob108.postini.com ([64.18.5.12]) with SMTP ID DSNKUe/HtlOaCYrBoyNYO8HgYNVds2n4YrM7@postini.com; Wed, 24 Jul 2013 05:25:29 PDT Received: from inner-relay-2.corp.adobe.com (mail-321.pac.adobe.com [153.32.1.52]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r6OCPNAI009899; Wed, 24 Jul 2013 05:25:24 -0700 (PDT) Received: from nahub01.corp.adobe.com (nahub01.corp.adobe.com [10.8.189.97]) by inner-relay-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r6OCPMw7002177; Wed, 24 Jul 2013 05:25:22 -0700 (PDT) Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nahub01.corp.adobe.com ([10.8.189.97]) with mapi; Wed, 24 Jul 2013 05:25:22 -0700 From: Larry Masinter To: Ian Hickson , "apps-discuss@ietf.org" Date: Wed, 24 Jul 2013 05:25:18 -0700 Thread-Topic: [apps-discuss] RFC 2388 (multipart/form-data) Thread-Index: Ac6BXOpg43jx2QFKQbeGOVxuGZDg9wHCpU5g Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [apps-discuss] RFC 2388 (multipart/form-data) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jul 2013 12:25:35 -0000 > https://www.w3.org/Bugs/Public/show_bug.cgi?id=3D16909 see comments in bug > https://www.w3.org/Bugs/Public/show_bug.cgi?id=3D19879 this was marked a dup of 16909. If there are MAY requirements in RFC 2388 = which would be better as SHOULD or MUST, please identify them. (Beyond how = to encode field names). > Other feedback: > http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Oct/0204.h= tml This doesn't mention multipart/form-data > http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jul/0037= .html=20 This mainly suggests updating 2388, which we will talk about. > http://lists.w3.org/Archives/Public/public-whatwg-archive/2012May/000= 3.html This is about file names, not field names in multipart/form-data. In any ca= se the filename issue seems best addressed by=20 http://www.rfc-editor.org/rfc/rfc5987.txt =20 > I asked Larry Masinter if he was still maintaining the RFC, but he said h= e > wasn't, and suggested I ask here to find out who was maintaining it now. so far there are two volunteers to help, but please review proposed=20 implementation guide in https://www.w3.org/Bugs/Public/show_bug.cgi?id=3D16= 909=20 So far, the only problem which seems concrete is "how to deal with non-asci= i field names in forms". Is there anything else? From cabo@tzi.org Thu Jul 25 02:46:06 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1DBB21F9A94; Thu, 25 Jul 2013 02:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 557gTtDcIqz3; Thu, 25 Jul 2013 02:46:00 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 1DCAA21F9ABA; Thu, 25 Jul 2013 02:45:59 -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.4/8.14.4) with ESMTP id r6P9jun6020348; Thu, 25 Jul 2013 11:45:56 +0200 (CEST) Received: from [192.168.217.105] (p54894526.dip0.t-ipconnect.de [84.137.69.38]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 0049023C; Thu, 25 Jul 2013 11:45:55 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Carsten Bormann Date: Thu, 25 Jul 2013 11:45:55 +0200 Content-Transfer-Encoding: 7bit Message-Id: <226664B3-428E-46F1-A3A4-EC743F28C4F2@tzi.org> To: "apps-discuss@ietf.org Discuss" , draft-housley-ltans-oids.all@tools.ietf.org X-Mailer: Apple Mail (2.1508) Cc: The IESG Subject: [apps-discuss] AppsDir review of draft-housley-ltans-oids-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 09:46:06 -0000 I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-housley-ltans-oids-00 Title: Object Identifier Registry for the Long-Term Archive and Notary Services (LTANS) Working Group Reviewer: Carsten Bormann Review Date: 2013-07-25 IESG Telechat Date: 2013-08-15 IETF Last Call Expires: 2013-07-31 * Summary: The document is almost ready for publication, but may need the addition of some guidance for the IANA expert review. The document nicely and accessibly summarizes the status of ASN.1 OIDs assigned for LTANS and establishes IANA registration policies for some arcs. * Major: As with all registries that specify Expert Review: Is there any guidance for the designated expert? I.e., what is the objective for the review? What will be the grounds for acceptance or rejection of a registration? (Such guidance is likely obvious to those closely involved with the work. It is not obvious to someone newly approaching this document and considering whether the registry is the right one to use.) * Minor One OID is described as obsolete, which is fine. The ones designated for LTAP are not described as obsolete, but it is not clear what the disposition of this protocol is. (It may not be the purview of this document to make statements about this, but if the answer is obvious, it should be given.) (This is confounded by referencing a long dead I-D as "work in progress" -- is it indeed in progress? Again, maybe not for this document to fix this longstanding issue about I-D citations.) * Nits Add period at end of section 1. 6: "it raise no new" From melvincarvalho@gmail.com Thu Jul 25 10:01:19 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B4CF21F9306 for ; Thu, 25 Jul 2013 10:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hAbjk36mzjPw for ; Thu, 25 Jul 2013 10:01:10 -0700 (PDT) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) by ietfa.amsl.com (Postfix) with ESMTP id 4D6A421F89A5 for ; Thu, 25 Jul 2013 10:01:10 -0700 (PDT) Received: by mail-lb0-f176.google.com with SMTP id z5so1696034lbh.7 for ; Thu, 25 Jul 2013 10:01:09 -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=VEb1SDbU/PojVitLkARhzZKujZ/EkSL3oSfK64T/t9Q=; b=vCSTp4jlWHPO+T5qCy2WNva/lrBRW9NtfjugZHKyQC7mHEHYg71eFocANpaJdLb+cU Mx1FuN/7ZgunDLnnlRrLUFBVWg6RY7olStI1JaD7hJiKpcOFP3D8uCkV8N5wDFYCrDZm LGK2seE3G52tyBd8eJL8VJ5+TFzbssUvhTVhgndrbW4b8NmkY0u/l47bRLPtAa78YXJ0 GY9jxkYJ7NjAyPm5S/wxIJD+fYyIPggnh97j/tGTzUO3kOFiE+kRwcwCX00Edm8oy1hw MbS4ZpkgVTQcMbGYd/PiF7MV5X9nyHWvXybAaz7AWRqr1wswYVvmFcjCv74KOpHJjrig H+Jw== MIME-Version: 1.0 X-Received: by 10.152.8.198 with SMTP id t6mr19752208laa.36.1374771669101; Thu, 25 Jul 2013 10:01:09 -0700 (PDT) Received: by 10.112.59.193 with HTTP; Thu, 25 Jul 2013 10:01:09 -0700 (PDT) In-Reply-To: References: <6BC44D72-BAA1-41B6-BFE8-9FD7A9D4CECF@mnot.net> <8ee3a48c1d3c44eb5bba7b08b3f77579@michielbdejong.com> Date: Thu, 25 Jul 2013 19:01:09 +0200 Message-ID: From: Melvin Carvalho To: Mark Nottingham Content-Type: multipart/alternative; boundary=089e0153844afbf57904e258f873 Cc: Apps Discuss Subject: Re: [apps-discuss] Non-proprietary sync (was Re: Is e-mail going to die? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 25 Jul 2013 17:01:20 -0000 --089e0153844afbf57904e258f873 Content-Type: text/plain; charset=ISO-8859-1 On 10 July 2013 07:30, Mark Nottingham wrote: > > On 06/07/2013, at 2:49 AM, Michiel B. de Jong > wrote: > > > Hi Mark, > > > > On 2013-07-04 07:34, Mark Nottingham wrote: > >> Hi Michiel, > >> > >> I'm very interested in this area; I think we need open standards here > >> desperately. > > > > Great! > > > >> I potentially have a lot of feedback for you (both editorial and more > >> substantial), but wanted to first know: what is the remoteStorage > >> community's intent in publishing this draft? > > > > we hadn't really formulated that until now, so we had a little > discussion about it; we didn't entirely finish discussing it yet, but > overall i think most of us agree that the ietf would probably be the right > platform for developing the idea of remoteStorage further. > > > > we started working on this spec as an open source project because we > identified a need for one - its development so far was partially financed > by donations, partially by people donating their time. > > > > It's of course scary to give up control over something we care so much > about, but we also trust the ietf would do a better job at guarding the > public's best interest than our small community of quite inexperienced > volunteers. :) > > Great. > > >> I.e., do you think you're nearly done, and just need to publish a > >> specification? > > > > it's becoming quite crystallized within its very limited defined set of > features. you can get an idea of what we consider outstanding issues by > browsing https://github.com/remotestorage/spec/issues our current process > is to go through that list twice a year, and see which of those issues > merit a text change. we are trying to change as little as possible each > time, to avoid an entropy walk into feature bloat. :) > > Sounds very reasonable. > > > >> Are you willing to consider substantial changes to the > >> specification, even if it breaks your current implementations if > >> there's good reason? > > > > yes, we do this every 6 months anyway. what type of changes did you have > in mind? > > > > so far, even though these are themes that continuously come up as > requests, we have resisted adding for instance: > > - byte ranges on GET (and PUT?) requests, > > - query parameters like sorting/filtering/paging, > > - access control lists, > > - long polling and/or other sorts of changes-feeds > > - retrieving the historic revision history of a certain document (as > well as undo/rollback) > > - atomic transactions > > - etc. > > > > this way, we try to keep the job of the server as simple as possible. > > > >> > >> Also, what kind of timeline are you on -- i.e., do you have > >> particular milestones you want to hit? > > > > we try to go as fast as we can, developing the remotestorage.js client > library for it, data formats for the things we want to store on there, try > to work out how to structure data into folders so that it's easy to fetch > later, write apps that use it, and server implementations that are > compliant with it, with (if you add up the volunteers) about 3 full-time > people. that's our main constraint. :) > > > > we have been trying to make breaking changes only twice a year, although > we're probably going to have to disobey that self-imposed rule soon anyway > because of a critical bug we found this week. > > OK. > > >> Finally, what's the preferred venue for feedback and discussion? > > > > currently it's a combination of > https://github.com/remotestorage/spec/issues and > http://remotestorage.io/community/ but we're open to changing that to the > apps-discuss mailinglist for instance? do you think that would be > appropriate? > > I think on the community site is fine for now; if it becomes a bigger > effort, or traffic is too great, you could either create a separate mailing > list, or move to an IETF list. YMMV, of course. > > > >> Will > >> you or anyone else from remoteStorage be coming to the Berlin meeting? > > > > i live in Berlin, and given our project's tight budget, i hadn't bought > a ticket yet. but if there is a possibility to chat about remoteStorage > with you and/or other people there, then i'll definitely get one for both > the meeting and the newcomer event! :) > > That would be great. However, it might be premature for you to register to > attend, since there won't be any time scheduled to discuss the draft at a > meeting (AFAIK - APPSAWG chairs?). > > So, it might be better to arrange a "Bar BoF" (i.e., informal meeting) for > folks who are interested to discuss this; registration isn't necessary for > that (as it often occurs in a bar or similar space). Even if that doesn't > happen, I'd love to talk over a coffee. > > This might also be helpful, FWIW: > http://www.ietf.org/tao.html > > > > can say roughly in which areas you would propose changing the draft? > > > Let me get my thoughts together and write something down; sorry, it might > take a while (both HTTP and moving house are keeping me busy right now). > FYI: here's a comparison of two of the cloud storage read/write technologies developed at the W3C. Linked Data Platform is a working draft at last call, Graph Store Platform is a W3C REC. https://docs.google.com/document/d/1lofZv855H5D3JDSefpEiE3NBM30YBh2W4pkmAGvlLtM/edit#heading=h.utn64k9xpepq Perhaps an idea to clone this document and add a third column for remote storage so that people can compare. Perhaps the main difference here is the versioning strategy ... > > Cheers, > > -- > Mark Nottingham http://www.mnot.net/ > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --089e0153844afbf57904e258f873 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On 10 July 2013 07:30, Mark Nottingham <mnot@mnot.net> w= rote:

On 06/07/2013, at 2:49 AM, Michiel B. de Jong <anything@michielbdejong.com> wrote:

> Hi Mark,
>
> On 2013-07-04 07:34, Mark Nottingham wrote:
>> Hi Michiel,
>>
>> I'm very interested in this area; I think we need open standar= ds here
>> desperately.
>
> Great!
>
>> I potentially have a lot of feedback for you (both editorial and m= ore
>> substantial), but wanted to first know: what is the remoteStorage<= br> >> community's intent in publishing this draft?
>
> we hadn't really formulated that until now, so we had a little dis= cussion about it; we didn't entirely finish discussing it yet, but over= all i think most of us agree that the ietf would probably be the right plat= form for developing the idea of remoteStorage further.
>
> we started working on this spec as an open source project because we i= dentified a need for one - its development so far was partially financed by= donations, partially by people donating their time.
>
> It's of course scary to give up control over something we care so = much about, but we also trust the ietf would do a better job at guarding th= e public's best interest than our small community of quite inexperience= d volunteers. :)

Great.

>> I.e., do you think you're nearly done, and just need to publis= h a
>> specification?
>
> it's becoming quite crystallized within its very limited defined s= et of features. you can get an idea of what we consider outstanding issues = by browsing https://github.com/remotestorage/spec/issues our current pr= ocess is to go through that list twice a year, and see which of those issue= s merit a text change. we are trying to change as little as possible each t= ime, to avoid an entropy walk into feature bloat. :)

Sounds very reasonable.


>> Are you willing to consider substantial changes to the
>> specification, even if it breaks your current implementations if >> there's good reason?
>
> yes, we do this every 6 months anyway. what type of changes did you ha= ve in mind?
>
> so far, even though these are themes that continuously come up as requ= ests, we have resisted adding for instance:
> - byte ranges on GET (and PUT?) requests,
> - query parameters like sorting/filtering/paging,
> - access control lists,
> - long polling and/or other sorts of changes-feeds
> - retrieving the historic revision history of a certain document (as w= ell as undo/rollback)
> - atomic transactions
> - etc.
>
> this way, we try to keep the job of the server as simple as possible.<= br> >
>>
>> Also, what kind of timeline are you on -- i.e., do you have
>> particular milestones you want to hit?
>
> we try to go as fast as we can, developing the remotestorage.js client= library for it, data formats for the things we want to store on there, try= to work out how to structure data into folders so that it's easy to fe= tch later, write apps that use it, and server implementations that are comp= liant with it, with (if you add up the volunteers) about 3 full-time people= . that's our main constraint. :)
>
> we have been trying to make breaking changes only twice a year, althou= gh we're probably going to have to disobey that self-imposed rule soon = anyway because of a critical bug we found this week.

OK.

>> Finally, what's the preferred venue for feedback and discussio= n?
>
> currently it's a combination of https://github.com/remotestorage/s= pec/issues and http://remotestorage.io/community/ but we're open to chang= ing that to the apps-discuss mailinglist for instance? do you think that wo= uld be appropriate?

I think on the community site is fine for now; if it becomes a bigger= effort, or traffic is too great, you could either create a separate mailin= g list, or move to an IETF list. YMMV, of course.


>> Will
>> you or anyone else from remoteStorage be coming to the Berlin meet= ing?
>
> i live in Berlin, and given our project's tight budget, i hadn'= ;t bought a ticket yet. but if there is a possibility to chat about remoteS= torage with you and/or other people there, then i'll definitely get one= for both the meeting and the newcomer event! :)

That would be great. However, it might be premature for you to regist= er to attend, since there won't be any time scheduled to discuss the dr= aft at a meeting (AFAIK - APPSAWG chairs?).

So, it might be better to arrange a "Bar BoF" (i.e., informal mee= ting) for folks who are interested to discuss this; registration isn't = necessary for that (as it often occurs in a bar or similar space). Even if = that doesn't happen, I'd love to talk over a coffee.

This might also be helpful, FWIW:
=A0 http://www.i= etf.org/tao.html


> can say roughly in which areas you would propose changing the draft?

Let me get my thoughts together and write something down; sorry, it m= ight take a while (both HTTP and moving house are keeping me busy right now= ).

FYI: here's a comparison of two = of the cloud storage read/write technologies developed at the W3C.=A0 Linke= d Data Platform is a working draft at last call, Graph Store Platform is a = W3C REC.

https://docs.google.com/= document/d/1lofZv855H5D3JDSefpEiE3NBM30YBh2W4pkmAGvlLtM/edit#heading=3Dh.ut= n64k9xpepq

Perhaps an idea to clone this document and add a third colum= n for remote storage so that people can compare.=A0 Perhaps the main differ= ence here is the versioning strategy ...
=A0

Cheers,

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



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

--089e0153844afbf57904e258f873-- From housley@vigilsec.com Fri Jul 26 07:28:24 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04E2E21F9971; Fri, 26 Jul 2013 07:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WyMjS6X-7hbm; Fri, 26 Jul 2013 07:28:18 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id BB71F21F8E79; Fri, 26 Jul 2013 07:28:18 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 84330F2412F; Fri, 26 Jul 2013 10:28:34 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id 8pmWOCYQlBXe; Fri, 26 Jul 2013 10:28:06 -0400 (EDT) Received: from eb-be.conference.fu-berlin.de (eb-be.conference.fu-berlin.de [160.45.235.190]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id AA641F24125; Fri, 26 Jul 2013 10:28:31 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <226664B3-428E-46F1-A3A4-EC743F28C4F2@tzi.org> Date: Fri, 26 Jul 2013 10:28:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <62B861CD-7EAE-4B09-A510-93028E919DA3@vigilsec.com> References: <226664B3-428E-46F1-A3A4-EC743F28C4F2@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.1085) Cc: draft-housley-ltans-oids.all@tools.ietf.org, The IESG , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] AppsDir review of draft-housley-ltans-oids-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 14:28:24 -0000 On Jul 25, 2013, at 5:45 AM, Carsten Bormann wrote: > I have been selected as the Applications Area Directorate reviewer for > this draft (for background on appsdir, please see > = http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate)= . >=20 > Please resolve these comments along with any other Last Call comments > you may receive. Please wait for direction from your document shepherd > or AD before posting a new version of the draft. >=20 > Document: draft-housley-ltans-oids-00 >=20 > Title: Object Identifier Registry for the > Long-Term Archive and Notary Services (LTANS) Working = Group >=20 > Reviewer: Carsten Bormann > Review Date: 2013-07-25 > IESG Telechat Date: 2013-08-15 > IETF Last Call Expires: 2013-07-31 >=20 > * Summary: The document is almost ready for publication, but may need > the addition of some guidance for the IANA expert review. >=20 > The document nicely and accessibly summarizes the status of > ASN.1 OIDs assigned for LTANS and establishes IANA registration > policies for some arcs. >=20 > * Major: >=20 > As with all registries that specify Expert Review: > Is there any guidance for the designated expert? > I.e., what is the objective for the review? > What will be the grounds for acceptance or rejection of a = registration? > (Such guidance is likely obvious to those closely involved with the = work. > It is not obvious to someone newly approaching this document and > considering whether the registry is the right one to use.) I suggest adding this text: Updates to the four new tables require Expert Review as defined in = [RFC5226]. The expert is expected to ensure that any new values are = strongly related to the work that was done by the LTANS WG. Object = identifiers for other purposes should not be assigned in this arc. > * Minor >=20 > One OID is described as obsolete, which is fine. The ones designated > for LTAP are not described as obsolete, but it is not clear what the > disposition of this protocol is. (It may not be the purview of this > document to make statements about this, but if the answer is obvious, > it should be given.) > (This is confounded by referencing a long dead I-D as "work in > progress" -- is it indeed in progress? Again, maybe not for this > document to fix this longstanding issue about I-D citations.) It is clear that LTAP is not being worked on at the moment. I am unsure = whether someone will resume this work in the future. > * Nits >=20 > Add period at end of section 1. > 6: "it raise no new" Fixed. Russ From cabo@tzi.org Fri Jul 26 07:34:53 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84AEC21F99A0; Fri, 26 Jul 2013 07:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mY0qdvy2fGH4; Fri, 26 Jul 2013 07:34:47 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 67D8D21F9829; Fri, 26 Jul 2013 07:34:47 -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.4/8.14.4) with ESMTP id r6QEYih0017818; Fri, 26 Jul 2013 16:34:44 +0200 (CEST) Received: from [172.27.14.151] (unknown [195.37.142.72]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id BF8DF792; Fri, 26 Jul 2013 16:34:44 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <62B861CD-7EAE-4B09-A510-93028E919DA3@vigilsec.com> Date: Fri, 26 Jul 2013 16:34:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <226664B3-428E-46F1-A3A4-EC743F28C4F2@tzi.org> <62B861CD-7EAE-4B09-A510-93028E919DA3@vigilsec.com> To: Russ Housley X-Mailer: Apple Mail (2.1508) Cc: draft-housley-ltans-oids.all@tools.ietf.org, The IESG , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] AppsDir review of draft-housley-ltans-oids-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 14:34:53 -0000 On Jul 26, 2013, at 16:28, Russ Housley wrote: > I suggest adding this text: >=20 > Updates to the four new tables require Expert Review as defined in = [RFC5226]. The expert is expected to ensure that any new values are = strongly related to the work that was done by the LTANS WG. Object = identifiers for other purposes should not be assigned in this arc. That is exactly the information I was hoping the document would provide. = Thanks. Gr=FC=DFe, Carsten From anything@michielbdejong.com Fri Jul 26 07:45:21 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2311221F9A04 for ; Fri, 26 Jul 2013 07:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.11 X-Spam-Level: X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WVEq8-OF3AOj for ; Fri, 26 Jul 2013 07:45:16 -0700 (PDT) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) by ietfa.amsl.com (Postfix) with ESMTP id 24C2721F99EE for ; Fri, 26 Jul 2013 07:45:11 -0700 (PDT) Received: from mfilter26-d.gandi.net (mfilter26-d.gandi.net [217.70.178.154]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id C97ADA80DF for ; Fri, 26 Jul 2013 16:44:59 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter26-d.gandi.net Received: from relay3-d.mail.gandi.net ([217.70.183.195]) by mfilter26-d.gandi.net (mfilter26-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id cOrXdpGQC4m9 for ; Fri, 26 Jul 2013 16:44:58 +0200 (CEST) X-Originating-IP: 10.58.1.146 Received: from webmail.gandi.net (unknown [10.58.1.146]) (Authenticated sender: anything@michielbdejong.com) by relay3-d.mail.gandi.net (Postfix) with ESMTPA id 52722A80C6 for ; Fri, 26 Jul 2013 16:44:57 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Date: Fri, 26 Jul 2013 16:44:56 +0200 From: "Michiel B. de Jong" To: In-Reply-To: <49e581fd7805d8615d462e5b05cbe0ce@michielbdejong.com> References: <6BC44D72-BAA1-41B6-BFE8-9FD7A9D4CECF@mnot.net> <8ee3a48c1d3c44eb5bba7b08b3f77579@michielbdejong.com> <49e581fd7805d8615d462e5b05cbe0ce@michielbdejong.com> Message-ID: <4d9c60f1228f2883319d84a05a3f8524@michielbdejong.com> X-Sender: anything@michielbdejong.com User-Agent: Roundcube Webmail/0.7.2 Content-Transfer-Encoding: quoted-printable Subject: Re: [apps-discuss] Possible bar BoF / side meeting on non-proprietary sync X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 26 Jul 2013 14:45:21 -0000 Just to re-confirm and as a reminder, this will happen Monday after the=20 technical plenary in Berlin: On 2013-07-16 16:54, Michiel B. de Jong wrote: > On the Monday evening, directly after the technical plenary finishes > (which should be around 19:40 > https://datatracker.ietf.org/meeting/87/agenda.txt ), I will hold up=20 > a > sign reading "non-proprietary sync Bar BoF", so we can gather. Then > among the people who show up, we decide to either do it there in the > foyer, or go for some food, or whatever the group decides. If someone > has trouble locating us, they can phone me on +49-1577.6858.499. > > The proposed topic of this Bar BoF will be "non-prioprietary cloud > sync", so something like Dropbox, GoogleDrive, SkyDrive, etcetera,=20 > but > as an open standard. One work-in-progress for this would be > remoteStorage, by Fran=C3=A7ois Kooman and myself, in this internet dra= ft: > http://www.ietf.org/id/draft-dejong-remotestorage-01.txt. Hope to see you there! Cheers, Michiel From hallam@gmail.com Fri Jul 26 08:23:44 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE3311E8105 for ; Fri, 26 Jul 2013 08:23:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.766 X-Spam-Level: X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MH3KnObuJ5ir for ; Fri, 26 Jul 2013 08:23:43 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id 7422111E80F4 for ; Fri, 26 Jul 2013 08:23:42 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id en1so913795wid.14 for ; Fri, 26 Jul 2013 08:23:41 -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=3Bw4dhfKceQiPDWbQQYd0L+8ieqjiaDMyG5cRTCitek=; b=PKZDxwPNorMU3pGNBXbSXR9UFlKjpfz2SUA/qmvtoTJBmukrSJxHTV1JUynglotsD2 lnNNvb9BdDCtozCWqSOHDlaq6br+N2Kwc+9knQhDA0uiZUfd5ZoDN+0ULSC4cSr8z8hB DPpV/eHjZUR7+eGDXtBjFtCJo/o/BQC1Bbu5t4M1BadKexx+anoUXBUznPqw4uiLPCWH uE8Y8RChyanTdXzniaR4Gniu4bjmtUxH9WB6a/CEzbTPtyuwLLRt7Tmfy195DGI1xFXw pD8WDe12nlQ4SyIrxa3nZlAx6hdAbntSLNigSSAeKmqsRlPVLgd2VXNuZi50Np6AEqvJ q4dg== MIME-Version: 1.0 X-Received: by 10.180.107.167 with SMTP id hd7mr6014870wib.33.1374852221556; Fri, 26 Jul 2013 08:23:41 -0700 (PDT) Received: by 10.194.6.65 with HTTP; Fri, 26 Jul 2013 08:23:41 -0700 (PDT) In-Reply-To: <4d9c60f1228f2883319d84a05a3f8524@michielbdejong.com> References: <6BC44D72-BAA1-41B6-BFE8-9FD7A9D4CECF@mnot.net> <8ee3a48c1d3c44eb5bba7b08b3f77579@michielbdejong.com> <49e581fd7805d8615d462e5b05cbe0ce@michielbdejong.com> <4d9c60f1228f2883319d84a05a3f8524@michielbdejong.com> Date: Fri, 26 Jul 2013 11:23:41 -0400 Message-ID: From: Phillip Hallam-Baker To: "Michiel B. de Jong" Content-Type: multipart/alternative; boundary=e89a8f2353a748dee404e26bbaec Cc: General discussion of application-layer protocols Subject: Re: [apps-discuss] Possible bar BoF / side meeting on non-proprietary sync X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 26 Jul 2013 15:23:44 -0000 --e89a8f2353a748dee404e26bbaec Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This type of work will require two sets of code. The easy part is the code implementing the actual protocol that the client uses to talk to the server. The harder part will be code to make the remote source visible as a local drive in e.g. Windows and Unix etc. and package it in a way that makes it robust. It occurs to me that some of the necessary functionality might already be present in GIT etc. A source code manager is simply a remote filestore that supports file versioning and keeps all the old version numbers and allows different users to manage different views of the same tree. Another use case that would enable quite a few IETF types to spend time on this would be to support gathering digital evidence. It would be very useful for me to have a drive where I could copy files and cause them to be automatically signed and digitally notarized. I think the first requirement is actually a core requirement. The second is probably not core requirements but could be supported if the core protocol had some sort of capability that allowed file attributes to be added so as to support the 'directory views' that the first implies. On Fri, Jul 26, 2013 at 10:44 AM, Michiel B. de Jong < anything@michielbdejong.com> wrote: > Just to re-confirm and as a reminder, this will happen Monday after the > technical plenary in Berlin: > > > On 2013-07-16 16:54, Michiel B. de Jong wrote: > >> On the Monday evening, directly after the technical plenary finishes >> (which should be around 19:40 >> https://datatracker.ietf.org/**meeting/87/agenda.txt), I will hold up a >> sign reading "non-proprietary sync Bar BoF", so we can gather. Then >> among the people who show up, we decide to either do it there in the >> foyer, or go for some food, or whatever the group decides. If someone >> has trouble locating us, they can phone me on +49-1577.6858.499. >> >> The proposed topic of this Bar BoF will be "non-prioprietary cloud >> sync", so something like Dropbox, GoogleDrive, SkyDrive, etcetera, but >> as an open standard. One work-in-progress for this would be >> remoteStorage, by Fran=E7ois Kooman and myself, in this internet draft: >> http://www.ietf.org/id/draft-**dejong-remotestorage-01.txt >> . >> > > Hope to see you there! > > > > Cheers, > Michiel > ______________________________**_________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/**listinfo/apps-discuss > --=20 Website: http://hallambaker.com/ --e89a8f2353a748dee404e26bbaec Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This type of work will require two sets of code.

<= /div>
The easy part is the code implementing the actual protocol that t= he client uses to talk to the server.

The harder p= art will be code to make the remote source visible as a local drive in e.g.= Windows and Unix etc. and package it in a way that makes it robust.


It occurs to me that some of the necessa= ry functionality might already be present in GIT etc. A source code manager= is simply a remote filestore that supports file versioning and keeps all t= he old version numbers and allows different users to manage different views= of the same tree.

Another use case that would enable quite a few IETF typ= es to spend time on this would be to support gathering digital evidence. It= would be very useful for me to have a drive where I could copy files and c= ause them to be automatically signed and digitally notarized.


I think the first requirement is a= ctually a core requirement.

The second is probably= not core requirements but could be supported if the core protocol had some= sort of capability that allowed file attributes to be added so as to suppo= rt the 'directory views' that the first implies.



On Fri, Jul 26, 2013 at 10:44 AM, Michiel B. de Jong <an= ything@michielbdejong.com> wrote:
Just to re-confirm and as a reminder, this w= ill happen Monday after the technical plenary in Berlin:
<= br>
On 2013-07-16 16:54, Michiel B. de Jong wrote:
On the Monday evening, directly after the technical plenary finishes
(which should be around 19:40
https://datatracker.ietf.org/meeting/87/agenda.txt ), I wi= ll hold up a
sign reading "non-proprietary sync Bar BoF", so we can gather. Th= en
among the people who show up, we decide to either do it there in the
foyer, or go for some food, or whatever the group decides. If someone
has trouble locating us, they can phone me on +49-1577.6858.499.
The proposed topic of this Bar BoF will be "non-prioprietary cloud
sync", so something like Dropbox, GoogleDrive, SkyDrive, etcetera, but=
as an open standard. One work-in-progress for this would be
remoteStorage, by Fran=E7ois Kooman and myself, in this internet draft:
http://www.ietf.org/id/draft-dejong-remotestorage-01.txt= .

Hope to see you there!



Cheers,
Michiel
_______________________________________________
apps-discuss mailing list
apps-discuss@iet= f.org
https://www.ietf.org/mailman/listinfo/apps-discuss



--
= Website: http://hallambaker.com/
--e89a8f2353a748dee404e26bbaec-- From superuser@gmail.com Fri Jul 26 22:40:39 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E920F21F9B80 for ; Fri, 26 Jul 2013 22:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id psD49TmVOW94 for ; Fri, 26 Jul 2013 22:40:39 -0700 (PDT) Received: from mail-pb0-x234.google.com (mail-pb0-x234.google.com [IPv6:2607:f8b0:400e:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 8B25521F9B60 for ; Fri, 26 Jul 2013 22:40:39 -0700 (PDT) Received: by mail-pb0-f52.google.com with SMTP id xa12so2729274pbc.39 for ; Fri, 26 Jul 2013 22:40:38 -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=SNozcm8/fHZ/LOfkDqlKq9nwOLFUpkIihkowFY3QgIY=; b=gEGnj6x2fAIjDyWfSVRFtnYOlVOreoKk8N0i2UFRRubFsbcof5smK2axSLt3fFFAXV n4nQwlEktLLKbUHcgOrkumnZEESB5fqJtjLNh7853dKPp0z0Ne1Q5K3oHpvy8NO2MKsp uTHSluynPhib1Lzh3x6sj3tczqaaNzoCdKVCh28ZO/SVMLjB5KhyRO8dFUPAJqPcnywX Z4SiPINRQxugPaOw7zfEbxaIzlMwOxlwV/Q82/D5A9lXzjp9ByxSXmhmz6OUIXWthayX BHrnVtPrYb6mg2FgLshpFcDzEtrL+YbeOHX2oj4O899ED9Cwh7wMKiFHDrba7SMlA2K9 l8Wg== MIME-Version: 1.0 X-Received: by 10.68.203.105 with SMTP id kp9mr57787279pbc.78.1374903637208; Fri, 26 Jul 2013 22:40:37 -0700 (PDT) Received: by 10.67.5.225 with HTTP; Fri, 26 Jul 2013 22:40:36 -0700 (PDT) Date: Fri, 26 Jul 2013 22:40:36 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=047d7b15aec7e574b004e277b2a1 Subject: [apps-discuss] Slide deck deadline for APPSAWG X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 27 Jul 2013 05:40:40 -0000 --047d7b15aec7e574b004e277b2a1 Content-Type: text/plain; charset=ISO-8859-1 If you are presenting anything at APPSAWG/APPAREA on Monday morning and will be using slides, please submit your slide decks to appsawg-chairs@tools.ietf.org by Sunday evening. We will not be able to accept submissions handed to us on USB sticks, etc. on the day of the meeting. -MSK --047d7b15aec7e574b004e277b2a1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
If you are presenting anything at APPSAWG/APPAREA on = Monday morning and will be using slides, please submit your slide decks to = appsawg-chairs@tools.ietf.= org by Sunday evening.=A0 We will not be able to accept submissions han= ded to us on USB sticks, etc. on the day of the meeting.

-MSK
--047d7b15aec7e574b004e277b2a1-- From tony@att.com Sun Jul 28 04:02:21 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85B3D21F9E12 for ; Sun, 28 Jul 2013 04:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SRH7qnErWXhK for ; Sun, 28 Jul 2013 04:02:15 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id B24E121F9D7C for ; Sun, 28 Jul 2013 04:02:09 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 13af4f15.0.4599388.00-286.12677992.nbfkord-smmo05.seg.att.com (envelope-from ); Sun, 28 Jul 2013 11:02:09 +0000 (UTC) X-MXL-Hash: 51f4fa310086602a-b0ac119d39dc7eeb0a5d97b654e4dae3d3ef0cd3 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6SB29Yo009932 for ; Sun, 28 Jul 2013 07:02:09 -0400 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6SB21IJ009785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 28 Jul 2013 07:02:01 -0400 Received: from alpi153.aldc.att.com (alpi153.aldc.att.com [130.8.42.31]) by alpi131.aldc.att.com (RSA Interceptor) for ; Sun, 28 Jul 2013 11:01:54 GMT Received: from aldc.att.com (localhost [127.0.0.1]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id r6SB1sPb003891 for ; Sun, 28 Jul 2013 07:01:54 -0400 Received: from dns.maillennium.att.com (maillennium.att.com [135.25.114.99]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id r6SB1m0f003697 for ; Sun, 28 Jul 2013 07:01:48 -0400 Received: from [135.70.211.112] (vpn-135-70-211-112.vpn.east.att.com[135.70.211.112]) by maillennium.att.com (mailgw1) with ESMTP id <20130728110147gw100bhhqje> (Authid: tony); Sun, 28 Jul 2013 11:01:47 +0000 X-Originating-IP: [135.70.211.112] Message-ID: <51F4FA18.3070900@att.com> Date: Sun, 28 Jul 2013 07:01:44 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: General discussion of application-layer protocols X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=Sa5AgItu c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=VqjyMmk8zjQA:10 a=3ukmKKXcZEAA:10 a=AU4YzUH8exEA:10 a=ofM] X-AnalysisOut: [gfj31e3cA:10 a=BLceEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=zQP7CpK] X-AnalysisOut: [OAAAA:8 a=019WWEsUgd0A:10 a=48vgC7mUAAAA:8 a=XnzZ4a7KPFAC0] X-AnalysisOut: [EnsmLMA:9 a=wPNLvfGTeEIA:10] Subject: [apps-discuss] AppsDir review of draft-ietf-weirds-rdap-sec-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2013 11:02:21 -0000 I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-weirds-rdap-sec-04 Title: Security Services for the Registration Data Access Protocol (RDAP) Reviewer: Tony Hansen Review Date: 2013-07-28 IESG Telechat Date: unknown IETF Last Call Expires: 2013-07-31 * Summary: The document is almost ready for publication. Minor notes follow. The document describes the topics of authentication, authorization, availability, data confidentiality and data integrety for RDAP. Since RDAP is built on top of HTTP/S, this document is often able to do this task by pointing to and deferring to another documents. A series of suggestions are made below. None are blocking. * Major: none * Minor Section 3.1.1, paragraphs 3 and 4: Should HTTP Over TLS be mandated when using bearer-token-based authentication methods? Section 3.2, paragraph 2: Are there any RDAP servers that *only* allow one level of access to data, such as anonymous access to a limited set of attributes? If so, add the caveat, or the MUST probably should be a SHOULD. On the flip side, I'm wondering if "Server operators will offer" should instead say "Server operators SHOULD offer". Would it be better to swap the order of the first two sentences in this paragraph? (The following also incorporates both of the above comments.) OLD: An RDAP server MUST provide granular access controls (that is, on a OLD: per registration data object basis) in order to implement OLD: authorization policies. Server operators will offer varying degrees OLD: of access depending on policy and need in conjunction with the OLD: authentication methods described in Section 3.1. Some examples: NEW: Server operators SHOULD offer varying degrees of access depending NEW: on policy and need in conjunction with the authentication methods NEW: described in Section 3.1. If such varying degrees of access are NEW: supported, an RDAP server MUST provide granular access controls NEW: (that is, on a per registration data object basis) in order to NEW: implement authorization policies. Some examples: Section 5: Should there be mention that a NULL encryption layer MUST NOT be used when HTTP Over TLS is used? Should mention be made about always checking the server credentials to help alleviate possible man in the middle (MITM) attacks? Should there be a reference to the Security Considerations sections of the other documents referenced within this document, such as HTTP and OAuth? * Nits Section 3.1.1, paragraph 5: OLD: entity called "Certification NEW: entity called a "Certification Section 3.1.1, paragraph 5: OLD: and can be introduced into RDAP. NEW: and can be used with RDAP. Section 5, paragraph 2: OLD: and html script NEW: and HTML script From tobias.gondrom@gondrom.org Sun Jul 28 06:52:56 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBAF021F9D04 for ; Sun, 28 Jul 2013 06:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.362 X-Spam-Level: X-Spam-Status: No, score=-95.362 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JRZ0RS+AUJe6 for ; Sun, 28 Jul 2013 06:52:51 -0700 (PDT) Received: from lvps176-28-13-69.dedicated.hosteurope.de (lvps176-28-13-69.dedicated.hosteurope.de [176.28.13.69]) by ietfa.amsl.com (Postfix) with ESMTP id 4611221F9C82 for ; Sun, 28 Jul 2013 06:52:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=Sb8jsSankTzFiEBj2io31D4moc8tsA5uiWVmtgqymT6G3xq65mm+rwyNGaAsua8sHY2rmaGDKqyI1wWuttZ0B3Emf1bxvcOYMRar73zi9wf4AMQTcF1cJBW0CgaivuwI; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:X-Enigmail-Version:Content-Type; Received: (qmail 24320 invoked from network); 28 Jul 2013 15:52:49 +0200 Received: from dhcp-461e.meeting.ietf.org (HELO ?130.129.70.30?) (130.129.70.30) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 28 Jul 2013 15:52:49 +0200 Message-ID: <51F52230.7@gondrom.org> Date: Sun, 28 Jul 2013 15:52:48 +0200 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: apps-discuss@ietf.org X-Enigmail-Version: 1.5.2 Content-Type: multipart/alternative; boundary="------------000009030101040103010802" Cc: ynir@checkpoint.com Subject: [apps-discuss] fyi: websec inviting more feedback on session continuation (i.e. cookies) during our meeting on Monday at 15:10 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 28 Jul 2013 13:52:56 -0000 This is a multi-part message in MIME format. --------------000009030101040103010802 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi all, sorry for the cross posting, but as this might also be of interest to other Apps WGs: fyi: over the last few months, websec had several discussions and proposals about improving cookies / session continuation and we have a couple of ideas on the agenda for our meeting on Monday at 15:10. The chairs would love to hear and invite more feedback and comments from the community. Cheers, Yoav & Tobias (co-chairs websec) --------------000009030101040103010802 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi all,

sorry for the cross posting, but as this might also be of interest to other Apps WGs:

fyi: over the last few months, websec had several discussions and proposals about improving cookies / session continuation and we have a couple of ideas on the agenda for our meeting on Monday at 15:10. The chairs would love to hear and invite more feedback and comments from the community.

Cheers, Yoav & Tobias
(co-chairs websec)




 --------------000009030101040103010802-- From ned.freed@mrochek.com Sun Jul 28 10:21:58 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAF9A21F9D04 for ; Sun, 28 Jul 2013 10:21:58 -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=-2.599, J_CHICKENPOX_14=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S+DJH0zXjkYH for ; Sun, 28 Jul 2013 10:21:53 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 8368C21F9CF2 for ; Sun, 28 Jul 2013 10:21:53 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OWJKZST0C0000A3K@mauve.mrochek.com> for apps-discuss@ietf.org; Sun, 28 Jul 2013 10:16:48 -0700 (PDT) MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=iso-8859-1 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OWGOYH1YHC00004R@mauve.mrochek.com>; Sun, 28 Jul 2013 10:16:42 -0700 (PDT) Message-id: <01OWJKZOL4R000004R@mauve.mrochek.com> Date: Sun, 28 Jul 2013 09:05:12 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 19 Jul 2013 10:56:12 -0700" <1374256572.96704.YahooMailNeo@web125601.mail.ne1.yahoo.com> References: <20130718202939.10687.qmail@joyce.lan> <01OW6YGX39GU000054@mauve.mrochek.com> <1374256572.96704.YahooMailNeo@web125601.mail.ne1.yahoo.com> To: Bill Mills Cc: John R Levine , Ned Freed , IETF Apps Discuss Subject: Re: [apps-discuss] Comments on draft-wmills-rrvs-header-field-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2013 17:21:58 -0000 Getting back to this; sorry for the delay in responding. > - matching name in rrvs to the envelope. > A sends to B who has forwarded to C.  This needs to be applied at the MTA > handling B, that's what we were trying to solve here. Then you need to correct your example in section 4, because this is exactly the opposite of what it says. I also note that your terminology is inconsistent; here you talk about A sending to B forwarding to C, whereas in the document you talk about S sending to A forwarding to B. So when you say this process needs to be "applied by B" here that corresponds to "applied by A" in the document, but the document in fact says it is to be "applied by B": 5. The receiving MTA at "B" asserts that "B" has not been under constant ownership since "D" and rejects the message. >  Comparing to the > original envelope seems useful for confirming validity of the header itself, > but I don't see much utility beyond that.  Am I missing something? That's precisely what it's is useful for - enormously so. Why should there need to be any utility beyond that? > - resending clients should strip the header > Seems fair. > - multiple recipients. > This starts to get a LOT hairier if we have to do a multi-valued rrvs header, > and it's not the problem we're trying to solve right now.  So we might allow > multiple rrvs headersto solve this?  Each one needing to apply to a recipient > in the envelope? It may not be the problem *you* are trying to solve right now, but if you expect such a proposal to catch on, you need to make it as appealing as possible to as wide an audience as possible. As I've noted previously, your single proposed use-case has a significant cost-benefit asymmetry - the cost, including explaining to people why their mail isn't working properly, is born by receiving agent but the benefit accrues to sender. In the past the fate of proposals with similar characteristics has been mixed at best. And this is hardly rocket science to get right given you already need to perform an envelope check: For a given recipient, all you need to do is check each RRVS header for that recipient address, and if there's a match, do the date comparison. Speaking for myself, this adds a whopping total of three additional lines of code to my imlementation. Indeed, this process is easy part; the date comparison is in practice going to be considerably more difficult. About the simplest form I can see working is something like this: (0) Is this one of several reserved addresses including, but maybe not limited to postmaster@* or abuse@*? If so ignore the check. (1) Has the domain part of this address been associated with the same administrative entity since the date given in the header? If not reject the message. (2) Has the address as a whole been under the same ownership since the data specified in the header? If not reject the message. And this is the simplest it can be; there are going to be cases where the notion of continuous ownership is the wrong one to apply and are going to be a lot more complicated. All that said, the main problem with the multiple recipient case is that it leaks information about when the originator first started corresponding with someone. This is actually a problem I hadn't considered before, and it exists even for the single recipient case. In fact coupled with the narrow use-case you're aiming at it argues strongly for recasting this as an SMTP extension. If you really want to continue with this as a header mechanism you're going to need both broaden your target audience and specify all the cases you've been reluctant to deal with so far. My suggestion here is to either cut bait and switch to an SMTP extension or else define the mechanism so it can handle multiple reicpients but warn about the dangers and recommend sending separate messages to each recipient. > - forwarding > The sender has no information on how delivery will happen, forwarding is a > form of delivery in this use case, and once you're forwarding RRVS should never > apply.  If so that's great, but again, that's not wnat your document says. I can only go by what you write; I had no means of divining that your intent was exactly the opposite. > - enhanced status codes > why do we need a new one?  X.1.6 seems to fit well? On the contrary, it doesn't fit at all. The description of this error code is very clear and it says it's to be issued when the address is no longer valid. That's absolutely not the case here - the address is perfectly valid, but ownership may not be the same so the message is being rejected rather than risk delivery to the wrong person. And even if this was within the scope of this error code, it would still be a bad idea to use it. A separate error code is needed so it's clear when this mechanism was used to reject a message. > - domain ownership change > A fair point.  A different error return could be useful here.  Another way to > do this would be to have an RRVS SMTP extension that advertises domains and > the length of ownership.  Needs more thought. An advertisement doesn't work, doesn't scale, and has all sorts of nasty security implications. The main reason it doesn't work is it requires no SMTP intermediaries be present. But even if you assume a single hop, suppose I advertise domain.com. Does that apply to foo.domain.com? (And I can assure you that while uncommon, cases where foo.domain.com has been under the same management but domain.com and all other subdomains of domain.com have not do exist.) As for scaling, there are MSPs that service thousands or even 10s of thousands of domains, and they absolutely are in your target audience. That's going to a hell of an advertisement. No, if you want to do this as an SMTP extension, it would need to look something like this: S:220 server.domain.com C:EHLO [x] S:250-server.domain.com S:250-ENHANCEDSTATUSCODES S:250 VALIDSINCE C:MAIL FROM: S:250 2.1.5 Ok C:RCPT TO: VALIDSINCE=19961219T163957-08:00 S:550 5.1.x Address ownership has changed since 19961219T163957-08:00 ... > - security considerations > Can be fuller, sure.  Got text? Not at present. > - false negatives > Meaning if a provider incorrectly rejects mail?  Is this significantly > different from the impact of current failures to delver when a DB lookup fails > and you get a "no such user" when you know it exists? Um, yeah, it's significantly different. For one thing, a DB lookup failure is going to be erratic, whereas a failure caused by bogus data attached to an account is going to occur consistently until the problem is corrected. The same thing goes for problems caused by RRVS header fields escaping into messages they weren't intended for. Besides, we have a technical turn of phrase for such DB lookup failures: Egregious bugs that should never occur in practice, and when they do occur they are caused by incompetent software engineering. Whereas all it it takes for RRVS to go wrong is an unfortunate combination of circumstances. Ned From superuser@gmail.com Sun Jul 28 13:19:02 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F30221F9DFD for ; Sun, 28 Jul 2013 13:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n7zDEgvZZABp for ; Sun, 28 Jul 2013 13:19:01 -0700 (PDT) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 6697621F9DFC for ; Sun, 28 Jul 2013 13:19:00 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id n5so2621395wev.14 for ; Sun, 28 Jul 2013 13:19: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=+IAS1B6bmkKSuS51hG017cWZFvaVTLzgrHQzz6Iuomk=; b=doEBm0GW/yyPuDnFwzwT9n2rohP0oAyQoau1qksyb07S9Th2mY8OrOm7I0/RsH0nH5 E+MnAy4gMRxd3C6IgAeVlM4cdG3JEpxOtY+VU2IwZzNuhmCmzheN4KqPEQEJK9RJwc0C 7QdEXsrCPxbvFYD4710TOmMmy9Ut6hKZuip/AqjevQeCmeCA0Nn5Siof3kWYcRLSdOTj dv6leBhkqoaCSXyPA4h+0AS4gNYCWAMrwx5XRpaqMjCFqe59Q/9xO5MeqDxtl7m49BUk tkw+BiuijPP+Dljyw/vw8dl5ojjFBz58Ggogh7Hkb8lh2BQ+XAWqx853Xv1DYuVaTsKf D63A== MIME-Version: 1.0 X-Received: by 10.180.189.102 with SMTP id gh6mr5079948wic.19.1375042740111; Sun, 28 Jul 2013 13:19:00 -0700 (PDT) Received: by 10.180.125.36 with HTTP; Sun, 28 Jul 2013 13:19:00 -0700 (PDT) Date: Sun, 28 Jul 2013 22:19:00 +0200 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=001a11c3436a134f2804e298165f Subject: [apps-discuss] Berlin Meeting materials & volunteers X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 28 Jul 2013 20:19:02 -0000 --001a11c3436a134f2804e298165f Content-Type: text/plain; charset=ISO-8859-1 Greetings, I have uploaded all of the presentations I can find in my inbox for the APPSAWG/APPAREA meeting tomorrow morning. They should be visible here: http://wiki.tools.ietf.org/wg/appsawg/agenda If you sent me something you will be presenting but you don't see it in those lists, please send it again to appsawg-chairs@tools.ietf.org so we can be sure to upload it before the meeting and have it on the laptop that will drive the meeting. To save us a few minutes at the front of the meeting, could we get volunteers to be jabber scribe/mic operators and minute takers? Thanks, see you bright & early... -MSK, APPSAWG co-chair --001a11c3436a134f2804e298165f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Greetings,

I have uploaded all of th= e presentations I can find in my inbox for the APPSAWG/APPAREA meeting tomo= rrow morning.=A0 They should be visible here:

http://wiki.tools.ietf.org/wg/appsawg/ag= enda

If you sent me something you will be presenting but you don= 't see it in those lists, please send it again to appsawg-chairs@tools.ietf.org so we can be = sure to upload it before the meeting and have it on the laptop that will dr= ive the meeting.

To save us a few minutes at the front of the meeting, could = we get volunteers to be jabber scribe/mic operators and minute takers?
<= br>Thanks, see you bright & early...

-MSK, APPS= AWG co-chair

--001a11c3436a134f2804e298165f-- From superuser@gmail.com Sun Jul 28 18:44:48 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D2B821F9D55 for ; Sun, 28 Jul 2013 18:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.484 X-Spam-Level: X-Spam-Status: No, score=-2.484 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hhQH-gfc1uZc for ; Sun, 28 Jul 2013 18:44:47 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 4DEF421F93F3 for ; Sun, 28 Jul 2013 18:44:46 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id f14so290172wiw.2 for ; Sun, 28 Jul 2013 18:44: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 :content-type; bh=C0yESmetLJY9pzRRUBfHnlnnNK6KHi2TOt4j2At4E/w=; b=yPDOk6JRw9d9EzIt2Ej2vZHhk6SBtPCympqslAyNl3aujxPhbINtFdjsBISEHTpp9h W0act8XEFj19xZsaDAEOd/OL9RhXeBvEWsQ4D7e8OVX6pblCD2iZgyhOvlEOkyCxvvm3 KRxy9ftgLXILs1rC8BU1y06fA8iDDQeu8nNQ6N8RadyrhKP1OqVT6YcFkoxqCJbdZreH YHXoGmjrUre9it+9hXG6XaOP5EG6C6ddmTZaftU4yhPdvb9xDoGPfeDhH2OzrN5VukJP 1qaH7AGaMx3cNr7h99WpamEXCy09v0etOpzs/xpaKd+eSwrDuaKnrOugaQuJ/sQNeXil sFWQ== MIME-Version: 1.0 X-Received: by 10.180.89.231 with SMTP id br7mr5577793wib.19.1375062286153; Sun, 28 Jul 2013 18:44:46 -0700 (PDT) Received: by 10.180.125.36 with HTTP; Sun, 28 Jul 2013 18:44:46 -0700 (PDT) In-Reply-To: References: Date: Mon, 29 Jul 2013 03:44:46 +0200 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=e89a8f3ba2551c3f0b04e29ca3a1 Subject: Re: [apps-discuss] Berlin Meeting materials & volunteers X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 29 Jul 2013 01:44:48 -0000 --e89a8f3ba2551c3f0b04e29ca3a1 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Jul 28, 2013 at 10:19 PM, Murray S. Kucherawy wrote: > Greetings, > > I have uploaded all of the presentations I can find in my inbox for the > APPSAWG/APPAREA meeting tomorrow morning. They should be visible here: > > http://wiki.tools.ietf.org/wg/appsawg/agenda > > If you sent me something you will be presenting but you don't see it in > those lists, please send it again to appsawg-chairs@tools.ietf.org so we > can be sure to upload it before the meeting and have it on the laptop that > will drive the meeting. > > To save us a few minutes at the front of the meeting, could we get > volunteers to be jabber scribe/mic operators and minute takers? > > Thanks, see you bright & early... > > -MSK, APPSAWG co-chair > > Also, I suspect we will have two chat rooms since it's a dual meeting (as usual). Please converge in the "appsawg" meeting room so that we're only using one of them. -MSK --e89a8f3ba2551c3f0b04e29ca3a1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sun, Jul 28, 2013 at 10:19 PM, Murray S. Kucherawy <= superuser@gmail.com> wrote:
Greetings,
I have uploaded all of the presentations I can find in my inbox for t= he APPSAWG/APPAREA meeting tomorrow morning.=A0 They should be visible here= :

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

If you sent me something you will be presenting but you don= 't see it in those lists, please send it again to appsawg-chairs@tools.ietf.org= so we can be sure to upload it before the meeting and have it on the l= aptop that will drive the meeting.

To save us a few minutes at the front of the meeting, could = we get volunteers to be jabber scribe/mic operators and minute takers?
<= br>Thanks, see you bright & early...

-MSK, APPS= AWG co-chair


Also, I suspect we = will have two chat rooms since it's a dual meeting (as usual).=A0 Pleas= e converge in the "appsawg" meeting room so that we're only u= sing one of them.

-MSK
--e89a8f3ba2551c3f0b04e29ca3a1-- From stpeter@stpeter.im Mon Jul 29 00:23:50 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40C4C21F8FD5 for ; Mon, 29 Jul 2013 00:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.164 X-Spam-Level: X-Spam-Status: No, score=-102.164 tagged_above=-999 required=5 tests=[AWL=0.435, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iukwhmY87XUc for ; Mon, 29 Jul 2013 00:23:46 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 704A921F9929 for ; Mon, 29 Jul 2013 00:23:21 -0700 (PDT) Received: from ergon.local (unknown [198.135.0.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D54C740038; Mon, 29 Jul 2013 01:25:26 -0600 (MDT) Message-ID: <51F6185C.5050101@stpeter.im> Date: Mon, 29 Jul 2013 09:23:08 +0200 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Songhaibin (A)" References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: [apps-discuss] service configuration (was: Re: Preliminary IETF 87 APPSAWG/APPAREA agenda posted) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 29 Jul 2013 07:23:50 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/19/13 3:16 AM, Songhaibin (A) wrote: > Hi Murray, > > I hope I can get a short slot (5 to 10 minutes) in Appsawg to > introduce the problems described in the following draft. The draft > is very short and I can improve it later. > > http://tools.ietf.org/id/draft-song-appsawg-service-template-00.txt > > BR, > > -Haibin Hello Haibin, As I mentioned at the mic just now, you might want to look at some of the work that's been done about Automated Service Configuration: https://datatracker.ietf.org/doc/draft-daboo-aggregated-service-discovery/ Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJR9hhbAAoJEOoGpJErxa2pBCIP/1JR43Evr6AtHsnej1/OAoSY 4PUNtY6k01EeErH8RYkhGBJvyAYpREmJEHdi30PYBIWiKKA5dWdFOjKj/zPmtPkD 4Z7qJsDvlxPobYa2eKCDjTIdXH+kC0/PidsMSsjsjZRv3YBQCokbPX5F9yOH2kTe MS4zn3axvVnTgPOEelqaZteK5esdtq/XtiQjUb+8BbkqDf45ayrlmPbi9GAOg74g f9IjThdUKsVyxTLyGVXcvUP/tlJ+gb2BuMKilehJ3GruTu6LgegpQpFZA/7DWmJY ssvTma+fP8EE6ZULrrJ0yMiTMqco00TrhMsSMi1mRlttudloYEK+jo3xyJFmFJQS +Wx1HVA0IWiiuDHoxhl88NKA6FP2wgdVRfI8N7HCiISWVOQrnKP1EKa508ctLozk WvW7/3IUjqaohRz99mUlyL6wJR5IU/WQaKIxTVG8LNw1qPUQ/UIXZ/dtQLN11HhL tbxJTQV3x9zxtXCuMuRrtjcN5upkf1knkyBv+uAODW6YFzcbUDvftpgiDvFFYjcJ spcPHh6hWGI4vH5OQbkFuNI0JE2XX3ElKNgeOUkG7Iva1GSR9EbuI3OsL0ICEQKY SfVH/0C7Flg9MUE3aq/erDB921tMeEraNcSfoHEAyeDrctwQaye5Qww+21erie2Q nxhz64xUyQ/LSn/34vsj =uIlX -----END PGP SIGNATURE----- From dret@berkeley.edu Mon Jul 29 00:52:14 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F01321F9D01 for ; Mon, 29 Jul 2013 00:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hcgGH2uAHa1Q for ; Mon, 29 Jul 2013 00:52:09 -0700 (PDT) Received: from cm05fe.IST.Berkeley.EDU (cm05fe.IST.Berkeley.EDU [169.229.218.146]) by ietfa.amsl.com (Postfix) with ESMTP id C4AA821F99B0 for ; Mon, 29 Jul 2013 00:52:09 -0700 (PDT) Received: from 46-126-158-51.dynamic.hispeed.ch ([46.126.158.51] helo=dretpro.local) by cm05fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1V3iFS-0007Dd-HR; Mon, 29 Jul 2013 00:52:08 -0700 Message-ID: <51F61F2A.8030403@berkeley.edu> Date: Mon, 29 Jul 2013 09:52:10 +0200 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "apps-discuss@ietf.org application-layer protocols" , Atom-Syntax , Atom-Protocol References: <20130729071438.10957.87683.idtracker@ietfa.amsl.com> In-Reply-To: <20130729071438.10957.87683.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: REST-Discuss Subject: [apps-discuss] Fw: New Version Notification for draft-wilde-atom-profile-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 07:52:14 -0000 hello. a new version of draft-wilde-atom-profile has been posted. if you are using profiles with atom, and specifically the proposed profile media type parameter, please get in touch. it would be great to add implementations to http://tools.ietf.org/html/draft-wilde-atom-profile-02#section-5 (please see http://tools.ietf.org/html/rfc6982#section-2 for a description of the implementation information needed). thanks and cheers, dret. ---------------------------------------------------------------------- On 2013-07-29 9:14 , internet-drafts@ietf.org wrote: > A new version of I-D, draft-wilde-atom-profile-02.txt > has been successfully submitted by Erik Wilde and posted to the > IETF repository. > > Filename: draft-wilde-atom-profile > Revision: 02 > Title: Profile Support for the Atom Syndication Format > Creation date: 2013-07-29 > Group: Individual Submission > Number of pages: 9 > URL: http://www.ietf.org/internet-drafts/draft-wilde-atom-profile-02.txt > Status: http://datatracker.ietf.org/doc/draft-wilde-atom-profile > Htmlized: http://tools.ietf.org/html/draft-wilde-atom-profile-02 > Diff: http://www.ietf.org/rfcdiff?url2=draft-wilde-atom-profile-02 > > Abstract: > The Atom syndication format is a generic XML format for representing > collections. Profiles are one way how Atom feeds can indicate that > they support specific extensions. To make this support visible on > the media type level, this specification adds an optional "profile" > media type parameter to the Atom media type. This allows profiles to > become visible at the media type level, so that servers as well as > clients can indicate support for specific Atom profiles in > conversations, for example when communicating via HTTP. This > specification updates RFC 4287 by adding the "profile" media type > parameter to the application/atom+xml media type registration. From haibin.song@huawei.com Mon Jul 29 00:56:50 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08F2E21F9C13 for ; Mon, 29 Jul 2013 00:56:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GomXWD68GKmM for ; Mon, 29 Jul 2013 00:56:45 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7F73D21F9B8D for ; Mon, 29 Jul 2013 00:56:44 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATW64193; Mon, 29 Jul 2013 07:56:43 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 29 Jul 2013 08:56:32 +0100 Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 29 Jul 2013 08:56:37 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.43]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.01.0323.007; Mon, 29 Jul 2013 15:56:32 +0800 From: "Songhaibin (A)" To: "apps-discuss@ietf.org" Thread-Topic: application or ops (service template) Thread-Index: Ac6L/end3oh5MSjlQjiEfZqG9hjWVw== Date: Mon, 29 Jul 2013 07:56:31 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.216.45.192] Content-Type: multipart/alternative; boundary="_000_E33E01DFD5BEA24B9F3F18671078951F2471A80Bnkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [apps-discuss] application or ops (service template) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 29 Jul 2013 07:56:50 -0000 --_000_E33E01DFD5BEA24B9F3F18671078951F2471A80Bnkgeml501mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi guys, I'm not sure about the exact scope of applications area or the OPS area. IM= HO, the OPS area is mainly about the network configuration, network diagnos= tics, tests and network deployment considerations. I personally see a pure = software installation on which components to install, where there are not m= uch interactions with the network layer, is a pure application layer thing.= But I would like to learn more on other opinions. BR, -Haibin --_000_E33E01DFD5BEA24B9F3F18671078951F2471A80Bnkgeml501mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi guys,

 

I’m not sure about the ex= act scope of applications area or the OPS area. IMHO, the OPS area is mainl= y about the network configuration, network diagnostics, tests and network d= eployment considerations. I personally see a pure software installation on which components to install, where there a= re not much interactions with the network layer, is a pure application laye= r thing. But I would like to learn more on other opinions.

 

BR,

-Haibin

--_000_E33E01DFD5BEA24B9F3F18671078951F2471A80Bnkgeml501mbschi_-- From dret@berkeley.edu Mon Jul 29 01:02:24 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E696E21F9D45 for ; Mon, 29 Jul 2013 01:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3oYmW86Gy6Nj for ; Mon, 29 Jul 2013 01:02:20 -0700 (PDT) Received: from cm06fe.IST.Berkeley.EDU (cm06fe.IST.Berkeley.EDU [169.229.218.147]) by ietfa.amsl.com (Postfix) with ESMTP id 0500221F9980 for ; Mon, 29 Jul 2013 01:02:18 -0700 (PDT) Received: from 46-126-158-51.dynamic.hispeed.ch ([46.126.158.51] helo=dretpro.local) by cm06fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1V3iPA-0004kh-JV; Mon, 29 Jul 2013 01:02:17 -0700 Message-ID: <51F62184.6080104@berkeley.edu> Date: Mon, 29 Jul 2013 10:02:12 +0200 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "apps-discuss@ietf.org application-layer protocols" References: <20130729071806.3189.90596.idtracker@ietfa.amsl.com> In-Reply-To: <20130729071806.3189.90596.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Steve Speicher , LDP , LDP WG , John Arwe , REST-Discuss Subject: [apps-discuss] Fw: New Version Notification for draft-wilde-accept-post-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 08:02:25 -0000 hello. a new draft "The Accept-Post HTTP Header" has been published. it has been developed within the W3C LDP working group (http://www.w3.org/2012/ldp/wiki/Main_Page), but we thought it would promote reuse of that header field if it were specified and registered separately. any feedback is very welcome. in order to align with the timing of the W3C LDP specifications, our goal is to move this draft forward as fast as we can. thanks and cheers, dret. ---------------------------------------------------------------------- On 2013-07-29 9:18 , internet-drafts@ietf.org wrote: > A new version of I-D, draft-wilde-accept-post-00.txt > has been successfully submitted by John Arwe and posted to the > IETF repository. > > Filename: draft-wilde-accept-post > Revision: 00 > Title: The Accept-Post HTTP Header > Creation date: 2013-07-29 > Group: Individual Submission > Number of pages: 7 > URL: http://www.ietf.org/internet-drafts/draft-wilde-accept-post-00.txt > Status: http://datatracker.ietf.org/doc/draft-wilde-accept-post > Htmlized: http://tools.ietf.org/html/draft-wilde-accept-post-00 > > > Abstract: > This specification defines a new HTTP response header field Accept- > Post, which indicates server support for specific media types for > entity bodies in HTTP POST requests. > > Note to Readers > > This draft should be discussed on the apps-discuss mailing list [9]. > Online access to all versions and files is available on github [10]. From haibin.song@huawei.com Mon Jul 29 01:04:19 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7C0721F9D0D for ; Mon, 29 Jul 2013 01:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xs2MSgIpJbpx for ; Mon, 29 Jul 2013 01:04:16 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1016221F9B1B for ; Mon, 29 Jul 2013 01:04:06 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATW64963; Mon, 29 Jul 2013 08:03:55 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 29 Jul 2013 09:03:40 +0100 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 29 Jul 2013 09:03:44 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.43]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.01.0323.007; Mon, 29 Jul 2013 16:03:38 +0800 From: "Songhaibin (A)" To: Peter Saint-Andre Thread-Topic: service configuration (was: Re: [apps-discuss] Preliminary IETF 87 APPSAWG/APPAREA agenda posted) Thread-Index: AQHOjCyUHoT5o7U8VUKEkM1K8mjx2Zl65oXQ Date: Mon, 29 Jul 2013 08:03:38 +0000 Message-ID: References: <51F6185C.5050101@stpeter.im> In-Reply-To: <51F6185C.5050101@stpeter.im> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.216.45.192] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] service configuration (was: Re: Preliminary IETF 87 APPSAWG/APPAREA agenda posted) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 29 Jul 2013 08:04:20 -0000 Hi Peter, Many thanks for the reference. I will look into the related documents to se= e whether there are overlaps. I do not want to do duplicate work either. BR, -Haibin -----Original Message----- From: Peter Saint-Andre [mailto:stpeter@stpeter.im]=20 Sent: Monday, July 29, 2013 3:23 PM To: Songhaibin (A) Cc: apps-discuss@ietf.org Subject: service configuration (was: Re: [apps-discuss] Preliminary IETF 87= APPSAWG/APPAREA agenda posted) -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/19/13 3:16 AM, Songhaibin (A) wrote: > Hi Murray, >=20 > I hope I can get a short slot (5 to 10 minutes) in Appsawg to=20 > introduce the problems described in the following draft. The draft is=20 > very short and I can improve it later. >=20 > http://tools.ietf.org/id/draft-song-appsawg-service-template-00.txt > > BR, >=20 > -Haibin Hello Haibin, As I mentioned at the mic just now, you might want to look at some of the w= ork that's been done about Automated Service Configuration: https://datatracker.ietf.org/doc/draft-daboo-aggregated-service-discovery/ Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJR9hhbAAoJEOoGpJErxa2pBCIP/1JR43Evr6AtHsnej1/OAoSY 4PUNtY6k01EeErH8RYkhGBJvyAYpREmJEHdi30PYBIWiKKA5dWdFOjKj/zPmtPkD 4Z7qJsDvlxPobYa2eKCDjTIdXH+kC0/PidsMSsjsjZRv3YBQCokbPX5F9yOH2kTe MS4zn3axvVnTgPOEelqaZteK5esdtq/XtiQjUb+8BbkqDf45ayrlmPbi9GAOg74g f9IjThdUKsVyxTLyGVXcvUP/tlJ+gb2BuMKilehJ3GruTu6LgegpQpFZA/7DWmJY ssvTma+fP8EE6ZULrrJ0yMiTMqco00TrhMsSMi1mRlttudloYEK+jo3xyJFmFJQS +Wx1HVA0IWiiuDHoxhl88NKA6FP2wgdVRfI8N7HCiISWVOQrnKP1EKa508ctLozk WvW7/3IUjqaohRz99mUlyL6wJR5IU/WQaKIxTVG8LNw1qPUQ/UIXZ/dtQLN11HhL tbxJTQV3x9zxtXCuMuRrtjcN5upkf1knkyBv+uAODW6YFzcbUDvftpgiDvFFYjcJ spcPHh6hWGI4vH5OQbkFuNI0JE2XX3ElKNgeOUkG7Iva1GSR9EbuI3OsL0ICEQKY SfVH/0C7Flg9MUE3aq/erDB921tMeEraNcSfoHEAyeDrctwQaye5Qww+21erie2Q nxhz64xUyQ/LSn/34vsj =3DuIlX -----END PGP SIGNATURE----- From superuser@gmail.com Mon Jul 29 01:13:18 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51BA821F8B07 for ; Mon, 29 Jul 2013 01:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.794 X-Spam-Level: X-Spam-Status: No, score=-1.794 tagged_above=-999 required=5 tests=[AWL=-0.591, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i4SyXDk0HG1l for ; Mon, 29 Jul 2013 01:13:16 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 7D5F521F9C83 for ; Mon, 29 Jul 2013 01:13:09 -0700 (PDT) Received: by mail-pa0-f41.google.com with SMTP id bj1so3977104pad.28 for ; Mon, 29 Jul 2013 01:13:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:from:content-type:x-mailer:message-id:date:to :content-transfer-encoding:mime-version; bh=8RzjCZmDW/S+Qub0X3zmkoJPXcFd9v3CXPC79rWT2+U=; b=EmTchSPVbMgg3JGNwXRVc8/sp0nkRsj9v3vA5cazyORrvnSx6+4Vcd+gtH2oo17V0/ 0oTFYKbzA96tRoOaywLMw//B9oE5ATTXZws5flsTtU/vzFhVGv35Oul7tQx92elsWdOl 4L7PYur0ZV3JOgzxtNlbRBXhreeUg2/bPEgfCxCrT5m0PEjzwwKoWmki+8C7/I3fUWWp 1XLnvEEb0iAt/kYsVn83fskWlzg1xcrK9VLAMYRB0DMAYxvipL6ieaf3ss6cRO5k0vMC lAq83lfJrWoJgcpdKE/c3I2s+QDeZb3y3mQOITlVEzcznTv+HGvpLdOMVwjtNIqkFAHy rsSw== X-Received: by 10.68.242.105 with SMTP id wp9mr66147911pbc.153.1375085589310; Mon, 29 Jul 2013 01:13:09 -0700 (PDT) Received: from [130.129.22.166] (dhcp-16a6.meeting.ietf.org. [130.129.22.166]) by mx.google.com with ESMTPSA id t9sm17637166pba.46.2013.07.29.01.13.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Jul 2013 01:13:08 -0700 (PDT) From: "Murray S. Kucherawy" Content-Type: text/plain; charset=us-ascii X-Mailer: iPad Mail (10B329) Message-Id: <828708BA-E4BF-48DE-9E44-3C21063AA3D8@gmail.com> Date: Mon, 29 Jul 2013 10:08:03 +0200 To: "apps-discuss@ietf.org" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Subject: [apps-discuss] Working Group Last Call: draft-ietf-appsawg-xml-mediatypes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 29 Jul 2013 08:13:18 -0000 This note begins a Working Group Last Call for draft-ietf-appsawg-xml-mediat= ypes, ending on Friday, August 16. Please provide reviews and comments on t= his list or privately to the authors as soon as possible. -MSK, APPSAWG co-chair and document shepherd= From stpeter@stpeter.im Mon Jul 29 01:30:26 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E71021F9BD5 for ; Mon, 29 Jul 2013 01:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.338 X-Spam-Level: X-Spam-Status: No, score=-102.338 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d62E+scGsbqd for ; Mon, 29 Jul 2013 01:30:20 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 458D121F9EB2 for ; Mon, 29 Jul 2013 01:29:36 -0700 (PDT) Received: from ergon.local (unknown [198.135.0.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E3078E8299; Mon, 29 Jul 2013 02:31:34 -0600 (MDT) Message-ID: <51F627E3.9030004@stpeter.im> Date: Mon, 29 Jul 2013 10:29:23 +0200 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Songhaibin (A)" References: <51F6185C.5050101@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] service configuration X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 29 Jul 2013 08:30:26 -0000 On 7/29/13 10:03 AM, Songhaibin (A) wrote: > Hi Peter, > > Many thanks for the reference. I will look into the related documents > to see whether there are overlaps. I do not want to do duplicate work > either. If you have a chance to review the document from Cyrus this week, you could probably chat with him in person (or with others -- I have been tracking this work and I know several other people who have. Peter From salvatore.loreto@ericsson.com Mon Jul 29 01:31:29 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F7F421F9EE1 for ; Mon, 29 Jul 2013 01:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VUO5HXpFsSZT for ; Mon, 29 Jul 2013 01:31:23 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8445621F91C4 for ; Mon, 29 Jul 2013 01:30:53 -0700 (PDT) X-AuditID: c1b4fb2d-b7f0b6d0000002d5-07-51f6283c66df Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 5A.B2.00725.C3826F15; Mon, 29 Jul 2013 10:30:52 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.183.147) by smtp.internal.ericsson.com (153.88.183.26) with Microsoft SMTP Server id 14.2.328.9; Mon, 29 Jul 2013 10:30:52 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 1656C11043A for ; Mon, 29 Jul 2013 11:30:52 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id B73275561E for ; Mon, 29 Jul 2013 11:30:47 +0300 (EEST) Received: from dhcp-1747.meeting.ietf.org (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 6C9FD552D6 for ; Mon, 29 Jul 2013 11:30:47 +0300 (EEST) Message-ID: <51F6283B.1010000@ericsson.com> Date: Mon, 29 Jul 2013 03:30:51 -0500 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "apps-discuss@ietf.org" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgluLIzCtJLcpLzFFi42KZGfG3VtdG41ugwce7qharX65gc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxpV3q9gK5rFU7L/znqWBcR9zFyMHh4SAicTzVtUuRk4gU0zi wr31bF2MXBxCAocZJbqa5zBDOBsYJa6cmccI4dxklLh6ZQUTSIuQwClGiYVNNhAJIHvq1wls IAleAW2Jhwu+gtksAqoSJ98fZwSx2QTMJJ4/3MIMYosKJEu8v3KHGaJeUOLkzCcsILaIgLHE pM1LwHqFBdwkPj+4CBZnFrCVuDDnOpQtL7H97RxmiLvVJK6e28QMcZCWRO/ZTqYJjEKzkIyd haR9FpL2BYzMqxjZcxMzc9LLDTcxAkPz4JbfujsYT50TOcQozcGiJM67Se9MoJBAemJJanZq akFqUXxRaU5q8SFGJg5OqQZGR3+XbTNS9AOfZJe9TTDuPfr41o7KJ3kT4qvyp70wV82K/nJA WZf7z81Vx46U31ga/XOD+lmbz3PuVE788OeV4J29YrntGmr+JecCzW7VnTFQW3fM+cszfSab vddmO7kdf2WQql3c0NR1Wtx9be/Slel3JSaX3faQ22bevTNs/qyewysdvqydosRSnJFoqMVc VJwIAHx+wpgbAgAA Subject: [apps-discuss] Working Group Last Call: draft-ietf-appsawg-malformed-mail-07 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 29 Jul 2013 08:31:29 -0000 this mail is to initiate the WG Last Call on draft-ietf-appsawg-malformed-mail-07 ( http://tools.ietf.org/html/draft-ietf-appsawg-malformed-mail-07 ) the WGLC will end on Friday, August 16th. Please send your reviews, as well as expression of support regarding document readiness for IESG (or not) to the apps-discuss mailing list. Comments like "I've read the document and it is OK to publish" or "I've read the document and it has the following issues" are useful and would be gratefully accepted by chairs. br /Salvatore From franck@peachymango.org Mon Jul 29 02:04:50 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 157D521F9F7A for ; Mon, 29 Jul 2013 02:04:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iOF7wVf0KnfG for ; Mon, 29 Jul 2013 02:04:43 -0700 (PDT) Received: from smtp-out-1.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id 526F021F9D68 for ; Mon, 29 Jul 2013 02:04:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id BCC7E294059; Mon, 29 Jul 2013 04:04:42 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp-out-1.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YS0ODh_tC_00; Mon, 29 Jul 2013 04:04:42 -0500 (CDT) Received: from smtp-out-1.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 9E0D3294070; Mon, 29 Jul 2013 04:04:42 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 905C729406C; Mon, 29 Jul 2013 04:04:42 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp-out-1.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id b7FuWCozgKhz; Mon, 29 Jul 2013 04:04:42 -0500 (CDT) Received: from mail-2.01.com (mail.01.com [172.18.30.178]) by smtp-out-1.01.com (Postfix) with ESMTP id 2E0BC294059; Mon, 29 Jul 2013 04:04:41 -0500 (CDT) Date: Mon, 29 Jul 2013 04:04:39 -0500 (CDT) From: Franck Martin To: Salvatore Loreto Message-ID: <2021301683.11717.1375088679807.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <51F6283B.1010000@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [69.28.149.29] X-Mailer: Zimbra 8.0.4_GA_5737 (ZimbraWebClient - FF22 (Mac)/8.0.4_GA_5737) Thread-Topic: Working Group Last Call: draft-ietf-appsawg-malformed-mail-07 Thread-Index: zfj+MvfOsZRMfCr2sX06LTiKcAkbQg== Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Working Group Last Call: draft-ietf-appsawg-malformed-mail-07 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 29 Jul 2013 09:04:50 -0000 I have read the document an it is ok to publish, I would only point to some neat-picking 7.1.6 To: "Joe" X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E30921E8085 for ; Mon, 29 Jul 2013 02:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTvhDxtVza9E for ; Mon, 29 Jul 2013 02:33:06 -0700 (PDT) Received: from smtp134.ord.emailsrvr.com (smtp134.ord.emailsrvr.com [173.203.6.134]) by ietfa.amsl.com (Postfix) with ESMTP id 2951421E809C for ; Mon, 29 Jul 2013 02:32:23 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp13.relay.ord1a.emailsrvr.com (SMTP Server) with ESMTP id AF63F198090 for ; Mon, 29 Jul 2013 05:32:09 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp13.relay.ord1a.emailsrvr.com (Authenticated sender: odonoghue-AT-isoc.org) with ESMTPSA id 60C9419808C for ; Mon, 29 Jul 2013 05:32:09 -0400 (EDT) Message-ID: <51F63696.7040600@isoc.org> Date: Mon, 29 Jul 2013 05:32:06 -0400 From: Karen O'Donoghue User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: apps-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [apps-discuss] request to apps area regarding jose wg efforts X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 29 Jul 2013 09:33:11 -0000 Folks, As I mentioned in the appsawg meeting this morning (and to all of you who weren't in attendance), the jose working group is working on secure object formats for JSON. We want to ensure that your use cases are represented and that the formats being developed will meet your needs. The use case document has passed WGLC and is awaiting document shepherd writeup. draft-ietf-jose-use-cases The four core documents are rapidly approaching WGLC... draft-ietf-jose-json-web-algorithms draft-ietf-jose-json-web-encryption draft-ietf-jose-json-web-key draft-ietf-jose-json-web-signature Now would be a really good time to take a look at these documents... Thanks, Karen From martin.thomson@gmail.com Mon Jul 29 02:33:19 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E32E521E8090; Mon, 29 Jul 2013 02:33:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.388 X-Spam-Level: * X-Spam-Status: No, score=1.388 tagged_above=-999 required=5 tests=[AWL=-3.988, BAYES_00=-2.599, FRT_STOCK1=3.988, FRT_STOCK2=3.988, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JeJzimf-qhUq; Mon, 29 Jul 2013 02:33:16 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id E364B21E80A5; Mon, 29 Jul 2013 02:32:46 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id hr7so1122645wib.10 for ; Mon, 29 Jul 2013 02:32:42 -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:content-transfer-encoding; bh=vUSVBuxjAFi5EmKdqaoYadwcRw6b6lwTiQ4L5pRrJQk=; b=UgZfv31ML/VBbuY+OHUsqOZjaM7a+2D96v+7yZtw4isqFcP1nKhBbEj8Q6NVwtSgBU 40Ywb565fBNuX4RwrCBLqwwHKZIN4tTVW8cRwQvbXlqgYBdCloBrOGY6Med4IWxy9GRb 2q8EAfAsIifgpU6mEvZWSzkk0jzVSdXrP8DdIk+zt1HxjKprSrrBQBYS0DJHGYOfgTGa z+3Neb7i9qpwkhy4lt094YtfTK2n8FvI4T14ssSdwlPgrs99+bV6Rpfev3p49DuB1gQq 8WoSvDIC83guBwMhcduuTmYqlCRMT2JsgKjiyXDuf8afMdWIFu9ye3ZFjG+dXTiFkuF6 znbw== MIME-Version: 1.0 X-Received: by 10.180.83.163 with SMTP id r3mr6565261wiy.10.1375090362494; Mon, 29 Jul 2013 02:32:42 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Mon, 29 Jul 2013 02:32:42 -0700 (PDT) In-Reply-To: References: <7F110B3ECC623C4EADDEB82154F2693D12871300@EXC-MBX01.tsn.tno.nl> Date: Mon, 29 Jul 2013 02:32:42 -0700 Message-ID: From: Martin Thomson To: "Brandenburg, R. (Ray) van" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "Roni Even \(ron.even.tlv@gmail.com\)" , The IESG , IETF Apps Discuss , "draft-ietf-avtcore-idms.all@tools.ietf.org" Subject: Re: [apps-discuss] AppsDir review of draft-ietf-avtcore-idms-09 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 29 Jul 2013 09:33:20 -0000 The new version addresses my concerns. Looks good. Thanks Ray. On 16 July 2013 12:04, Martin Thomson wrote: > Thanks Ray, > > It looks like you got most of what I was concerned about. I will > await a -12 revision. > > On 16 July 2013 02:43, Brandenburg, R. (Ray) van > wrote: >> Hi Martin, >> >> Thanks for the thorough review. Please see my comments inline. >> >> Best regards, >> >> Ray >> >> -----Original Message----- >> From: Martin Thomson [mailto:martin.thomson@gmail.com] >> Sent: donderdag 11 juli 2013 22:54 >> To: Stokking, H.M. (Hans) >> Cc: draft-ietf-avtcore-idms.all@tools.ietf.org; IETF Apps Discuss; The I= ESG >> Subject: Re: AppsDir review of draft-ietf-avtcore-idms-09 >> >> Thanks. >> >> I neglected to send this to a few other folks initially. >> >> On 10 July 2013 00:51, Stokking, H.M. (Hans) wrot= e: >>> Dear Martin, >>> >>> Ray is out-of-office at the moment, I'll discuss your comments with him= when he gets back next week. We'll let you know how we expect to deal with= your comments then. >>> >>> Best regards, Hans >>> >>> -----Original Message----- >>> From: Martin Thomson [mailto:martin.thomson@gmail.com] >>> Sent: maandag 8 juli 2013 19:38 >>> To: draft-ietf-avtcore-idms.all@tools.ietf.org >>> Subject: AppsDir review of draft-ietf-avtcore-idms-09 >>> >>> I have been selected as the Applications Area Directorate (appsdir) rev= iewer for this draft. (For background on appsdir, please see http://trac.t= ools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). >>> >>> Please resolve these comments along with any other Last Call comments y= ou may receive. Please wait for direction from your document shepherd or A= D before posting a new version of the draft. >>> >>> >>> Document: draft-ietf-avtcore-idms-09 >>> Reviewer: Martin Thomson >>> Review Date: 2013-07-08 >>> IETF Last Call Date: ? >>> IESG Telechat Date: ? >>> >>> Summary: This document is almost ready for publication as proposed stan= dard. There are a few minor issues. >>> >>> >>> Section 6. >>> Is there a strong reason for the MSAS to be placed at the RTP sender? >>> Based on the description provided, this function can be independent, wi= th the exception that it be necessary to receive RTCP reports. The descrip= tion in 6.1 omits the information that would be necessary to conclude that = it is in the right place (i.e., it receives RTCP IDMS XR reports, and sends= RTCP IDMS messages.) >> >> Yes, you're right, an MSAS could be independent from the RTP Sender as l= ong as it receives the necessary RTCP reports and the RTP stream itself to = correlate reports from different receivers. It could even be located in one= of the RTP Receivers (as noted in section 6). I will add a few sentences t= o 6.1 to clarify this. >> >>> There is also a third potential role in this scenario, which is probabl= y also assumed by an actual RTP sender. In a network with large disparity = of network delays and playback occurring on devices with limited capacity, = is it not also possible - or even necessary - for an RTP sender to perform = some buffering to add delay? >> >> You're right that the current system assumes RTP receivers have large en= ough buffers to delay the received streams. In theory it would be possible = to have the RTP sender add delay as well, although this would add considera= ble complexity to the system and only be useful in a limited set of scenari= os. For example, such a system will not work well in multicast environments= . In addition, having to coordinate buffer delays between multiple parties = is very complex. >> >>> Section 7 re: Synchronization Packet Sender Type . >>> >>> I'm not finding any motivation for the inclusion of this field and I ca= n't infer from the text what its purpose is. I think that the document nee= ds something here. I notice that removing it would allow you to remove 32-= bits from the payload. >> >> There are two motivations behind the SPST field. Firstly, it allows for = extensions to the IDMS mechanism without having to specify new XR blocks. S= econdly, it allows for compatibility with the ETSI TISPAN spec (see section= 2.2 of the -11 version of the draft). >> >>> Section 7 re: Packet Presented NTP timestamp: 32 bits. >>> >>> The description of this parameter requires special handling with respec= t to epoch and rollover. I might assume that it is within 2^16 seconds of = the received timestamp, but always greater. >>> >>> There are other ways to encode this information, though. Since this is= always strictly after a packet is received, then encoding a delta might al= so be possible. That would set the epoch for this field to the packet rece= ived NTP timestamp and avoid any rollover issues (though it would limit the= amount of buffering delay to 2^16). >> >> In the WG we have had some discussion whether we should have a 32-bit or= 64-bit NTP timestamp here. In the end, consensus was that a 32-bit timesta= mp would be sufficient for the XR Report, while we included a 64-bit timest= amp in the RTCP Settings packet. You're right that we're assuming the delay= to be within 2^16 seconds. I will add a note to the text to make this expl= icit. >> >>> Section 11. >>> This ABNF implies that the 'a' in 'a=3Drtcp-idms' is case-insensitive. >>> This is not permitted by RFC 4566. >> >> I'm not an ABNF expert, are you proposing to change the 'a' into %d97? I= 've browsed through various recent MMUSIC and AVTCORE documents, and they a= ll seem to use the 'a' notation. >> >>> Note that you should also specify 'decimal' rather than 'numerical' in = the description, assuming of course that you want decimal numbers. >> >> I assume you mean the line 'SyncGroupId =3D 1*10DIGIT ; Numerical value = from 0 through 4294967294'? I will change this is the next iteration. >> >> Thanks again, >> >> Ray >> >> >> This e-mail and its contents are subject to the DISCLAIMER at http://www= .tno.nl/emaildisclaimer From martin.thomson@gmail.com Mon Jul 29 02:37:38 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44A2821F9CC3; Mon, 29 Jul 2013 02:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.293 X-Spam-Level: X-Spam-Status: No, score=-2.293 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJ2VJ3fPC14K; Mon, 29 Jul 2013 02:37:37 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 7626F21F9AC5; Mon, 29 Jul 2013 02:37:31 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id n11so2576096wgh.0 for ; Mon, 29 Jul 2013 02:37:27 -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:cc:content-type; bh=Tciu7g2CBTkTVlkqGoL/F+yEVDUO+rF5KIC3fiGo5ps=; b=N8JQvthZDSN9godxOcQkw16s6j/1xP47kvixLGdn/YANwIuIsVq398uk2Wa9m7ZrH7 I82aob5qoQfiG1vZmX0OvPoAEdi5SLxZZikZ1CRLGEGdtTPUleO2TAK7idvG10hw2teX XkW8zAz105kang1Wgu59slNzXemFRh2zxi/YbIEsb3r+hS/2klaTpjoMiEF8qGYM/q/e 74EPV/WrDHbIrmQfdPB6PtGz6xkjr9uE2BYCcATc00EZGpwhPHEilMDUK2XGJFIPKTAA 09KBI19nxD7e9j4CYRVQNabywTcUF+3z3S9sPFHHbH8gRfo124ZctUGg1CRcwIDV5vnF eXiA== MIME-Version: 1.0 X-Received: by 10.180.92.1 with SMTP id ci1mr6550274wib.14.1375090647260; Mon, 29 Jul 2013 02:37:27 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Mon, 29 Jul 2013 02:37:27 -0700 (PDT) Date: Mon, 29 Jul 2013 02:37:27 -0700 Message-ID: From: Martin Thomson To: IETF Apps Discuss , draft-ietf-websec-x-frame-options-06.all@tools.ietf.org Content-Type: text/plain; charset=UTF-8 Cc: The IESG Subject: [apps-discuss] Appsdir review of draft-ietf-websec-x-frame-options-06 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 09:37:39 -0000 I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-websec-x-frame-options-06 Title: HTTP Header Field X-Frame-Options Reviewer: Martin Thomson Review Date: 2013-07-29 IETF Last Call Date: ? IESG Telechat Date: ? Summary: This draft is almost ready for publication as an Informational RFC. Major Issues: Please make the list of affected contexts explicit from the outset. The draft initally only talks about and