From nobody Mon Mar 2 06:30:38 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 567921A877B for ; Mon, 2 Mar 2015 06:30:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b3w_06n6zC-L for ; Mon, 2 Mar 2015 06:30:35 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A88C61A8774 for ; Mon, 2 Mar 2015 06:30:35 -0800 (PST) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YSRMc-0001AD-KM; Mon, 02 Mar 2015 09:30:30 -0500 Date: Mon, 02 Mar 2015 09:30:25 -0500 From: John C Klensin To: Pete Resnick , Barry Leiba , John Levine Message-ID: <9BAFB425A5757D4381D157FB@JcK-HP8200.jck.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: apps-discuss@ietf.org Subject: [apps-discuss] The SMTP 521 reply code, RFC 1846, and nullMX X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 14:30:37 -0000 Hi. There was a lot of activity around this in the middle of last year, largely because of the nullMX draft (draft-ietf-appsawg-nullmx). According to the tracker, nullMX has been sitting in the RFC Editor queue since mid-September, in part because it contains a normative reference to draft-klensin-smtp-521code. I think the assumption was that a quick Last Call was going to be done on the latter I-D, possibly through appsawg, but nothing has ever happened. According to the Secretariat's automatic system, draft-klensin-smtp-521code-02.txt expires next week. I'm happy to update and repost it if there is a plan to move it forward. Or I can let it expire, thereby either killing the nullMX draft or requiring that it be reissued with a different strategy and presumably a new Last Call. Please advise. john ---------- Forwarded Message ---------- Date: Monday, March 02, 2015 04:42 -0800 From: IETF Secretariat To: "John C. Klensin" Subject: Expiration impending: The following draft will expire soon: Name: draft-klensin-smtp-521code Title: SMTP 521 and 556 Reply Codes State: I-D Exists Expires: 2015-03-11 (in 1=C2=A0week, 1=C2=A0day) ---------- End Forwarded Message ---------- From nobody Mon Mar 2 08:09:28 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7F8D1A0115 for ; Mon, 2 Mar 2015 08:09:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hbk_dHfASO_t for ; Mon, 2 Mar 2015 08:09:26 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA0A1A00E4 for ; Mon, 2 Mar 2015 08:09:26 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PJ4HYNSVB4009EFN@mauve.mrochek.com> for apps-discuss@ietf.org; Mon, 2 Mar 2015 08:04:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1425312265; bh=h6fJ2oJlexKNlXbC8CxgPzrsrex70OzkCM2zqk9FBJo=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=BEDpP80zoOeTUswyqQpauGao/QQ3VTR64CrjXOqAm1evpWSvFwvbdEQqyD1ICq9z0 my4mUaHzlq/H5WKF1SX2AQftUk5m7JnsnKUCNcZOPrWNG8RCeg3GhdPlnK1JJybf0M qKAqR8kD7e5Wso/Luqwsj8dFKNK/9qPWUNZtEGh0= MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: TEXT/PLAIN; charset=utf-8 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PJ4GV1WOAO0000AQ@mauve.mrochek.com>; Mon, 02 Mar 2015 08:04:21 -0800 (PST) Message-id: <01PJ4HYMFQIQ0000AQ@mauve.mrochek.com> Date: Mon, 02 Mar 2015 08:00:22 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Mon, 02 Mar 2015 09:30:25 -0500" <9BAFB425A5757D4381D157FB@JcK-HP8200.jck.com> References: <9BAFB425A5757D4381D157FB@JcK-HP8200.jck.com> To: John C Klensin Archived-At: Cc: Pete Resnick , Barry Leiba , John Levine , apps-discuss@ietf.org Subject: Re: [apps-discuss] The SMTP 521 reply code, RFC 1846, and nullMX X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 16:09:27 -0000 I took a quick look at draft-klensin-smtp-521code-02 and I don't see anything wrong with it. I suggest moving it forward through whatever means are most expeditious. My only two minor comments on the text as it stands are first, that I believe the RFC editor has a thing about references to other documents in the abstract, so that may be an issue with how it's presently worded. Second, I'm not quite comfortable with the phrase "the preferred message". Perhaps "a possible messsage" or "an acceptable message"? Ned > Hi. > There was a lot of activity around this in the middle of last > year, largely because of the nullMX draft > (draft-ietf-appsawg-nullmx). According to the tracker, nullMX > has been sitting in the RFC Editor queue since mid-September, in > part because it contains a normative reference to > draft-klensin-smtp-521code. I think the assumption was that a > quick Last Call was going to be done on the latter I-D, possibly > through appsawg, but nothing has ever happened. > According to the Secretariat's automatic system, > draft-klensin-smtp-521code-02.txt expires next week. > I'm happy to update and repost it if there is a plan to move it > forward. Or I can let it expire, thereby either killing the > nullMX draft or requiring that it be reissued with a different > strategy and presumably a new Last Call. > Please advise. > john > ---------- Forwarded Message ---------- > Date: Monday, March 02, 2015 04:42 -0800 > From: IETF Secretariat > To: "John C. Klensin" > Subject: Expiration impending: > > The following draft will expire soon: > Name: draft-klensin-smtp-521code > Title: SMTP 521 and 556 Reply Codes > State: I-D Exists > Expires: 2015-03-11 (in 1 week, 1 day) > ---------- End Forwarded Message ---------- > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Mon Mar 2 08:17:50 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEEB71A1ADC for ; Mon, 2 Mar 2015 08:17:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id itadBbGyaITX for ; Mon, 2 Mar 2015 08:17:47 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6F1E1A0377 for ; Mon, 2 Mar 2015 08:17:46 -0800 (PST) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YST2H-0001Wp-Ck; Mon, 02 Mar 2015 11:17:37 -0500 Date: Mon, 02 Mar 2015 11:17:32 -0500 From: John C Klensin To: Ned Freed Message-ID: In-Reply-To: <01PJ4HYMFQIQ0000AQ@mauve.mrochek.com> References: <9BAFB425A5757D4381D157FB@JcK-HP8200.jck.com> <01PJ4HYMFQIQ0000AQ@mauve.mrochek.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: Pete Resnick , Barry Leiba , John Levine , apps-discuss@ietf.org Subject: Re: [apps-discuss] The SMTP 521 reply code, RFC 1846, and nullMX X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 16:17:49 -0000 --On Monday, March 02, 2015 08:00 -0800 Ned Freed wrote: > I took a quick look at draft-klensin-smtp-521code-02 and I > don't see anything wrong with it. I suggest moving it forward > through whatever means are most expeditious. > > My only two minor comments on the text as it stands are first, > that I believe the RFC editor has a thing about references to > other documents in the abstract, so that may be an issue with > how it's presently worded. The rule, as far as I recall, is about actual citations in the abstract, but will sort that out as/when needed. > Second, I'm not quite comfortable with the phrase "the > preferred message". Perhaps "a possible messsage" or "an > acceptable message"? I agree with your point and (slightly) prefer the latter, so, unless someone has a strong preference to the contrary, -03 will say "an acceptable message". Alexey, I agree with Ned about "most expeditious" -- I think this has been discussed and isn't work a lot more time. If you or others see taking this up officially in APPSAWG as adding value, I'm ok with that, but it might be equally or more efficient to post a heads-up to ietf-smtp and then do a four week IETF LC. Completely up to you folks; I did the draft because it seemed like a quick fix and now just want it out of my queue. john From nobody Mon Mar 2 08:54:00 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEE041A1B7A for ; Mon, 2 Mar 2015 08:53:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2o82YBETCVY0 for ; Mon, 2 Mar 2015 08:53:58 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94B0D1A1B69 for ; Mon, 2 Mar 2015 08:53:57 -0800 (PST) Received: (qmail 54294 invoked from network); 2 Mar 2015 16:53:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=d415.54f495a4.k1503; bh=d32AUccAkllk64vqM1JJ3aC4NU9db3GbTnfj8SA+MDQ=; b=WK4GDVvIf0u9kyztkhfHzWI3ew56j66MH4lw7VAUXMhj3gNa1f9WXRgN+PnywvnrY2HBtfkokXn8OCFwzGCMjbDo05hTM19+Eee2LRgUxRFHfRNhoNoVELVAZaLJ4BGZ+v4jmhfv2rCZSrq6nK9KK/RKMAipPgqPgai0ev9u3tK9qK1rck88pYKK5WbvmQsVMVAl9HmN0C9UmtZIK5Yece9R5yf+P1kgwYBhViH5uPhtgr73E8yNc8XasZK9zIMI DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=d415.54f495a4.k1503; bh=d32AUccAkllk64vqM1JJ3aC4NU9db3GbTnfj8SA+MDQ=; b=mSgkIm39M43sDyAgOhJkB3Z4mLFbAKJHPk4BZLXvIrU60SrdaMmO34wby3idvCMW8rrm0SsirsWgkVZq1JW813ppmAFpeXlKqex+cg+4xvuj0AQUIkWuDKjfuKsZPjBOPVk7L0NOFhmCEs/C10eVLeA50Tk1pMul20aYCNg3pF6t9lIIs0de8oevGw8jstf8J6yVTWDLLVQgnussH3GXIOOb5ivNZjs6o0pkLmICCAVn1scI5M2TfonTWMecmial Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 02 Mar 2015 16:53:56 -0000 Date: 2 Mar 2015 11:53:55 -0500 Message-ID: From: "John R Levine" To: "John C Klensin" In-Reply-To: References: <9BAFB425A5757D4381D157FB@JcK-HP8200.jck.com> <01PJ4HYMFQIQ0000AQ@mauve.mrochek.com> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: Pete Resnick , Barry Leiba , Ned Freed , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] The SMTP 521 reply code, RFC 1846, and nullMX X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 16:53:59 -0000 > Alexey, I agree with Ned about "most expeditious" -- ... I'm happy with whatever gets it through quickly. It seems unlikely that anyone would be opposed to it. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Mon Mar 2 08:56:21 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12D941A1B73 for ; Mon, 2 Mar 2015 08:56:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHfhcDm5aIhh for ; Mon, 2 Mar 2015 08:56:19 -0800 (PST) Received: from statler.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id B0BC91A1B69 for ; Mon, 2 Mar 2015 08:56:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1425315376; d=isode.com; s=selector; i=@isode.com; bh=RvM1W17TneE8YJqZ94RnYvBWEc47/MxcMaxkRQCWu2k=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=pbzHyYPKTdVZXme1Anc6tv6Er2FwaQmVD4+NdOtIagJz67nctnhukSeLZq3lmFtKkms2H+ fP+vezD+WI3TshXnYXaoIwzMKm5u7MVwdbWNVtiTpKruOmO/VAmO+YteXoJBYApn0RJW0L RGI4XijlmfFWF7K3Oh1+76yed1yiXz8=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 2 Mar 2015 16:56:16 +0000 Message-ID: <54F4962C.5060803@isode.com> Date: Mon, 02 Mar 2015 16:56:12 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 To: John C Klensin , Ned Freed References: <9BAFB425A5757D4381D157FB@JcK-HP8200.jck.com> <01PJ4HYMFQIQ0000AQ@mauve.mrochek.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Pete Resnick , Barry Leiba , John Levine , apps-discuss@ietf.org Subject: Re: [apps-discuss] The SMTP 521 reply code, RFC 1846, and nullMX X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 16:56:20 -0000 Hi John, On 02/03/2015 16:17, John C Klensin wrote: > Alexey, I agree with Ned about "most expeditious" -- I think > this has been discussed and isn't work a lot more time. If you > or others see taking this up officially in APPSAWG as adding > value, I'm ok with that, but it might be equally or more > efficient to post a heads-up to ietf-smtp and then do a four > week IETF LC. Completely up to you folks; I did the draft > because it seemed like a quick fix and now just want it out of > my queue. I am fine either way, I think our esteemed ADs need to comment on what they prefer. From nobody Mon Mar 2 08:57:38 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29A1F1A1B81 for ; Mon, 2 Mar 2015 08:57:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CzRJ2CpiYG6w for ; Mon, 2 Mar 2015 08:57:35 -0800 (PST) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A36F1A1B69 for ; Mon, 2 Mar 2015 08:57:35 -0800 (PST) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id c7694f45.0.2223304.00-2399.5861944.nbfkord-smmo06.seg.att.com (envelope-from ); Mon, 02 Mar 2015 16:57:35 +0000 (UTC) X-MXL-Hash: 54f4967f27bf7768-47af6d60055c6618a651f8c41244d9e3ff26f792 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t22GvWVS012465 for ; Mon, 2 Mar 2015 11:57:32 -0500 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t22GvQqM012440 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 2 Mar 2015 11:57:26 -0500 Received: from alpi153.aldc.att.com (alpi153.aldc.att.com [130.8.42.31]) by alpi132.aldc.att.com (RSA Interceptor) for ; Mon, 2 Mar 2015 16:57: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 t22GvI9W005581 for ; Mon, 2 Mar 2015 11:57:18 -0500 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 t22GvEHJ005395 for ; Mon, 2 Mar 2015 11:57:14 -0500 Received: from txcdtl03dh9314.itservices.sbc.com (txcdtl03dh9314.itservices.sbc.com?[135.110.240.192](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20150302165713gw1000cegle>; Mon, 2 Mar 2015 16:57:13 +0000 X-Originating-IP: [135.110.240.192] Message-ID: <54F49668.7030106@att.com> Date: Mon, 02 Mar 2015 11:57:12 -0500 From: Tony Hansen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 CC: apps-discuss@ietf.org References: <9BAFB425A5757D4381D157FB@JcK-HP8200.jck.com> <01PJ4HYMFQIQ0000AQ@mauve.mrochek.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090003010707000505000003" X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=WN3IqAQR c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=9cW_t1CCXrUA:10 a=CA33sFktnKwA:10 a=xS6R0AjqyPEA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=emO1SXQWCLwA:10 a=9aueKP-j] X-AnalysisOut: [AAAA:8 a=-5TaTEf5KivjCZkGxooA:9 a=pILNOxqGKmIA:10 a=A59MmV] X-AnalysisOut: [ax0RBZBhHO:21 a=lKS82kgQA9WuQl3A:21 a=9NGZVl_YAAAA:8 a=hr-] X-AnalysisOut: [FvNgxcIWJZh4y9nYA:9 a=_W_S_7VecoQA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: Subject: Re: [apps-discuss] The SMTP 521 reply code, RFC 1846, and nullMX X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 16:57:37 -0000 This is a multi-part message in MIME format. --------------090003010707000505000003 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 3/2/15 11:17 AM, John C Klensin wrote: > > --On Monday, March 02, 2015 08:00 -0800 Ned Freed > wrote: > >> I took a quick look at draft-klensin-smtp-521code-02 and I >> don't see anything wrong with it. I suggest moving it forward >> through whatever means are most expeditious. >> >> My only two minor comments on the text as it stands are first, >> that I believe the RFC editor has a thing about references to >> other documents in the abstract, so that may be an issue with >> how it's presently worded. > The rule, as far as I recall, is about actual citations in the > abstract, but will sort that out as/when needed. > >> Second, I'm not quite comfortable with the phrase "the >> preferred message". Perhaps "a possible messsage" or "an >> acceptable message"? > I agree with your point and (slightly) prefer the latter, so, > unless someone has a strong preference to the contrary, -03 will > say "an acceptable message". > > Alexey, I agree with Ned about "most expeditious" -- I think > this has been discussed and isn't work a lot more time. If you > or others see taking this up officially in APPSAWG as adding > value, I'm ok with that, but it might be equally or more > efficient to post a heads-up to ietf-smtp and then do a four > week IETF LC. Completely up to you folks; I did the draft > because it seemed like a quick fix and now just want it out of > my queue. +1 to AD-sponsored 4-week IETF LC. I re-read it and think it's ready for publication. Minor nit: In section 4, I got lost and had to re-read the 1-sentence paragraph several times. I suggest rewriting it slightly: When an SMTP server returns a 556 response code after receiving a command, such as RCPT, containing a forward-pointing address because it has information, as discussed above, that mail is not accepted, the SMTP client is, consistent with the SMTP specification, expected to handle the response like any other permanent negative completion reply to the command. to something along these lines: When an SMTP server returns a 556 response code after receiving a command (such as RCPT, which contains a forward-pointing address) because it has information (such as discussed above) that the mail will not be accepted, the SMTP client is expected to handle the response like any other permanent negative completion reply to the command. This is consistent with the SMTP specification. Tony --------------090003010707000505000003 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit On 3/2/15 11:17 AM, John C Klensin wrote:

--On Monday, March 02, 2015 08:00 -0800 Ned Freed
<ned.freed@mrochek.com> wrote:


I took a quick look at draft-klensin-smtp-521code-02 and I
don't see anything wrong with it. I suggest moving it forward
through whatever means are most expeditious.

My only two minor comments on the text as it stands are first,
that I believe the RFC editor has a thing about references to
other documents in the abstract, so that may be an issue with
how it's presently worded.

The rule, as far as I recall, is about actual citations in the
abstract, but will sort that out as/when needed.


Second, I'm not quite comfortable with the phrase "the
preferred message". Perhaps "a possible messsage" or "an
acceptable message"?

I agree with your point and (slightly) prefer the latter, so,
unless someone has a strong preference to the contrary, -03 will
say "an acceptable message".

Alexey, I agree with Ned about "most expeditious" -- I think
this has been discussed and isn't work a lot more time.  If you
or others see taking this up officially in APPSAWG as adding
value, I'm ok with that, but it might be equally or more
efficient to post a heads-up to ietf-smtp and then do a four
week IETF LC.    Completely up to you folks; I did the draft
because it seemed like a quick fix and now just want it out of
my queue.

+1 to AD-sponsored 4-week IETF LC.

I re-read it and think it's ready for publication.

Minor nit: In section 4, I got lost and had to re-read the 1-sentence paragraph several times. I suggest rewriting it slightly:

   When an SMTP server returns a 556 response code after receiving a
   command, such as RCPT, containing a forward-pointing address because
   it has information, as discussed above, that mail is not accepted,
   the SMTP client is, consistent with the SMTP specification, expected
   to handle the response like any other permanent negative completion
   reply to the command.

to something along these lines:

   When an SMTP server returns a 556 response code after receiving a
   command (such as RCPT, which contains a forward-pointing address) because
   it has information (such as discussed above) that the mail will 
   not be accepted, the SMTP client is expected
   to handle the response like any other permanent negative completion
   reply to the command. This is consistent with the SMTP specification.

Tony
--------------090003010707000505000003-- From nobody Mon Mar 2 09:06:15 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBFAD1A1B89 for ; Mon, 2 Mar 2015 09:06:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.431 X-Spam-Level: X-Spam-Status: No, score=-2.431 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQHifTTS-jmt for ; Mon, 2 Mar 2015 09:06:11 -0800 (PST) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [193.206.158.29]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B1591A0377 for ; Mon, 2 Mar 2015 09:06:11 -0800 (PST) Received: internal info suppressed Date: Mon, 2 Mar 2015 18:06:07 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@synx02.dir.garr.it To: Alexey Melnikov In-Reply-To: <54F4962C.5060803@isode.com> Message-ID: References: <9BAFB425A5757D4381D157FB@JcK-HP8200.jck.com> <01PJ4HYMFQIQ0000AQ@mauve.mrochek.com> <54F4962C.5060803@isode.com> User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=garr.it; s=cyrus; t=1425315968; bh=3d9DA6xBpveD/R95fltqb/ebBZhZTnWQMoVQO9WuhmE=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=GUDec3qfbt7Jy+c0Jv0k8OQwrKPkQrUpN5SmMmM11NCh7nGvAlP/TUrRkXb2/+h1z GFvs4mxCMLwADKW8DpHoIac6pGC/mY7Dclno3bWXX7soYo/AYUQGOaJ4kbNmKUEkDN 4X2DT+NjVa5JtuOszFctZJEIHh72SzGylwuuTIgk= Archived-At: Cc: Ned Freed , apps-discuss@ietf.org, Pete Resnick , John Levine , Barry Leiba Subject: Re: [apps-discuss] The SMTP 521 reply code, RFC 1846, and nullMX X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 17:06:14 -0000 On Mon, 2 Mar 2015, Alexey Melnikov wrote: > Hi John, > > On 02/03/2015 16:17, John C Klensin wrote: >> Alexey, I agree with Ned about "most expeditious" -- I think >> this has been discussed and isn't work a lot more time. If you >> or others see taking this up officially in APPSAWG as adding >> value, I'm ok with that, but it might be equally or more >> efficient to post a heads-up to ietf-smtp and then do a four >> week IETF LC. Completely up to you folks; I did the draft >> because it seemed like a quick fix and now just want it out of >> my queue. > I am fine either way, I think our esteemed ADs need to comment on what they > prefer. I also agree with Alexey! ------------------------------------------------------------------------------ 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 nobody Mon Mar 2 10:30:51 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D7691A88A3 for ; Mon, 2 Mar 2015 10:30:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-Z_C629_esM for ; Mon, 2 Mar 2015 10:30:47 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0729.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::729]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 569A31A8891 for ; Mon, 2 Mar 2015 10:30:47 -0800 (PST) Received: from pc6 (81.151.167.59) by AMXPR07MB054.eurprd07.prod.outlook.com (10.242.67.143) with Microsoft SMTP Server (TLS) id 15.1.99.14; Mon, 2 Mar 2015 18:30:28 +0000 Message-ID: <0af201d05516$aa8615e0$4001a8c0@gateway.2wire.net> From: t.petch To: John C Klensin , Ned Freed References: <9BAFB425A5757D4381D157FB@JcK-HP8200.jck.com> <01PJ4HYMFQIQ0000AQ@mauve.mrochek.com> Date: Mon, 2 Mar 2015 18:28:17 +0000 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: [81.151.167.59] X-ClientProxiedBy: DB4PR05CA0017.eurprd05.prod.outlook.com (25.160.40.27) To AMXPR07MB054.eurprd07.prod.outlook.com (10.242.67.143) Authentication-Results: jck.com; dkim=none (message not signed) header.d=none; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB054; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006); SRVR:AMXPR07MB054; BCL:0; PCL:0; RULEID:; SRVR:AMXPR07MB054; X-Forefront-PRVS: 0503FF9A3E X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(24454002)(377454003)(51704005)(66066001)(47776003)(62966003)(77156002)(122386002)(40100003)(33646002)(23756003)(42186005)(46102003)(86362001)(92566002)(50226001)(62236002)(44716002)(77096005)(50466002)(61296003)(87976001)(19580395003)(81816999)(50986999)(14496001)(76176999)(81686999)(84392001)(19580405001)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMXPR07MB054; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Mar 2015 18:30:28.1482 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMXPR07MB054 Archived-At: Cc: John Levine , apps-discuss Subject: Re: [apps-discuss] The SMTP 521 reply code, RFC 1846, and nullMX X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 18:30:50 -0000 ----- Original Message ----- From: "John C Klensin" To: "Ned Freed" Sent: Monday, March 02, 2015 4:17 PM > > --On Monday, March 02, 2015 08:00 -0800 Ned Freed > wrote: > > > I took a quick look at draft-klensin-smtp-521code-02 and I > > don't see anything wrong with it. I suggest moving it forward > > through whatever means are most expeditious. > > > > My only two minor comments on the text as it stands are first, > > that I believe the RFC editor has a thing about references to > > other documents in the abstract, so that may be an issue with > > how it's presently worded. > > The rule, as far as I recall, is about actual citations in the > abstract, but will sort that out as/when needed. John The latest style guide [RFC7322] says s4.3 " the Abstract must not contain citations" and "The 556 code was created for [[RFC nullMX]]. " does look very like a citation. Perhaps you need an RFC Editor note to the effect that this should be replaced by the RFC nnnn allocated to the nullMX I-D. Other RFC have, at least before the latest style guide, contained RFC numbers. Or, crib from the Introduction "The 556 code was created for for use when an SMTP client encounters a domain that it can determine does not support receipt of email." and leave the Introduction to say more. Tom Petch > > > Second, I'm not quite comfortable with the phrase "the > > preferred message". Perhaps "a possible messsage" or "an > > acceptable message"? > > I agree with your point and (slightly) prefer the latter, so, > unless someone has a strong preference to the contrary, -03 will > say "an acceptable message". > > Alexey, I agree with Ned about "most expeditious" -- I think > this has been discussed and isn't work a lot more time. If you > or others see taking this up officially in APPSAWG as adding > value, I'm ok with that, but it might be equally or more > efficient to post a heads-up to ietf-smtp and then do a four > week IETF LC. Completely up to you folks; I did the draft > because it seemed like a quick fix and now just want it out of > my queue. > > john From nobody Mon Mar 2 10:59:20 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07F9C1A88F7 for ; Mon, 2 Mar 2015 10:59:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KLex5sJ310bp for ; Mon, 2 Mar 2015 10:59:17 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34A181A890B for ; Mon, 2 Mar 2015 10:59:08 -0800 (PST) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YSVYR-0002BP-J1; Mon, 02 Mar 2015 13:58:59 -0500 Date: Mon, 02 Mar 2015 13:58:54 -0500 From: John C Klensin To: "t.petch" , Ned Freed Message-ID: In-Reply-To: <0af201d05516$aa8615e0$4001a8c0@gateway.2wire.net> References: <9BAFB425A5757D4381D157FB@JcK-HP8200.jck.com> <01PJ4HYMFQIQ0000AQ@mauve.mrochek.com> <0af201d05516$aa8615e0$4001a8c0@gateway.2wire.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: John Levine , apps-discuss Subject: Re: [apps-discuss] The SMTP 521 reply code, RFC 1846, and nullMX X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 18:59:19 -0000 --On Monday, March 02, 2015 18:28 +0000 "t.petch" wrote: >... >> > My only two minor comments on the text as it stands are >> > first, that I believe the RFC editor has a thing about >> > references to other documents in the abstract, so that may >> > be an issue with how it's presently worded. >> >> The rule, as far as I recall, is about actual citations in the >> abstract, but will sort that out as/when needed. >... > The latest style guide [RFC7322] says s4.3 > " the Abstract must not contain citations" Yes. That is consistent with what I said above. > and > "The 556 code was created for [[RFC nullMX]]. " > does look very like a citation. The doubled brackets should have been a hint that it is actually something else. The observation that references in this spec are numbered, rather than symbolic, might be another hint. The XML contained an Entity definition and reference (not a citation) that produces that string and a note to the RFC Editor telling them to change it to reflect the RFC number for that spec. Before someone else points it out, I've had problems with the RFCNNNN convention that have barely been caught during AUTH48 and prefer to not take that risk. Since this confused both you and Ned, the Entity definition has been changed to "RFC-nullMX" without the brackets. > Perhaps you need an RFC Editor note to the effect that this > should be replaced by the RFC nnnn allocated to the nullMX > I-D. Other RFC have, at least before the latest style guide, > contained RFC numbers. Putting RFC numbers in the abstract is just about the only way to conform to the IESG's guidance that strings like "updates RFC NNNN" appear there. In the hope of not having to spend more time on this, I've added an RFC Editor note where people can see it (i.e., not just in the XML). > Or, crib from the Introduction > > "The 556 code was created for > for use when an SMTP client encounters a > domain that it can > determine does not support receipt of email." Unfortunately, that isn't how 556 is defined; it is fairly specific to situations in which that determination is made without opening a connection. If a connection is actually opened to the destination and then the client determines that mail is not accepted, different options apply. Last-minute editorial tuning of this type is dangerous because the changes can accidentally have substantive side effects. thanks for the careful reading, john From nobody Mon Mar 2 12:56:51 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DCBA1A897D for ; Mon, 2 Mar 2015 12:56:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IT5dMez2oF-i for ; Mon, 2 Mar 2015 12:56:44 -0800 (PST) Received: from mx20.mailtransaction.com (mx20.mailtransaction.com [78.46.16.213]) by ietfa.amsl.com (Postfix) with ESMTP id 107F71A1BCF for ; Mon, 2 Mar 2015 12:56:44 -0800 (PST) Received: from mx24.mailtransaction.com (mx21.mailtransaction.com [78.46.16.236]) by mx20.mailtransaction.com (Postfix) with ESMTP id 3kwv0V75jBz1L8n8; Mon, 2 Mar 2015 21:56:42 +0100 (CET) Received: from jaguar.sonnection.nl (D57E1702.static.ziggozakelijk.nl [213.126.23.2]) by mx24.mailtransaction.com (Postfix) with ESMTP id 3kwv0V5Ky6z1L8n7; Mon, 2 Mar 2015 21:56:42 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by jaguar.sonnection.nl (Postfix) with ESMTP id 8567A1232B9; Mon, 2 Mar 2015 21:56:42 +0100 (CET) X-Virus-Scanned: amavisd-new at sonnection.nl Received: from jaguar.sonnection.nl ([127.0.0.1]) by localhost (jaguar.sonnection.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id gpuegA9i6eHG; Mon, 2 Mar 2015 21:56:41 +0100 (CET) Received: from [192.168.1.49] (unknown [192.168.1.49]) by jaguar.sonnection.nl (Postfix) with ESMTPSA id D17E3123051; Mon, 2 Mar 2015 21:56:40 +0100 (CET) Message-ID: <54F4CE88.7050201@sonnection.nl> Date: Mon, 02 Mar 2015 21:56:40 +0100 From: "Rolf E. Sonneveld" Organization: Sonnection B.V. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: John C Klensin , Pete Resnick , Barry Leiba , John Levine References: <9BAFB425A5757D4381D157FB@JcK-HP8200.jck.com> In-Reply-To: <9BAFB425A5757D4381D157FB@JcK-HP8200.jck.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1425329803; bh=sYLxLYBoewe0D4jEv3j4HAlHTkVcQ7WdumZ2xFfGhYc=; h=Message-ID:Date:From:To:Subject:From; b=jCk8lmYaw58foxhJvTkzUplAXEzMcysb9eXRzoaZA0Nxu+YAakKdiHua9IRoyU9AB 35VS+IHEKEP8pzhDJ9IOa5R8o9IK8X9Cve6WaUGI8vgfVXxGmxi9OEpnexW9rn4fdy vwOjoIADm5Qo31cX1FEoADst37AOlVZG2kEDT6+4= DKIM-Filter: OpenDKIM Filter v2.8.2 mx20.mailtransaction.com 3kwv0V75jBz1L8n8 Archived-At: Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] The SMTP 521 reply code, RFC 1846, and nullMX X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: R.E.Sonneveld@sonnection.nl List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 20:56:50 -0000 John, On 03/02/2015 03:30 PM, John C Klensin wrote: > Hi. > > There was a lot of activity around this in the middle of last > year, largely because of the nullMX draft > (draft-ietf-appsawg-nullmx). According to the tracker, nullMX > has been sitting in the RFC Editor queue since mid-September, in > part because it contains a normative reference to > draft-klensin-smtp-521code. I think the assumption was that a > quick Last Call was going to be done on the latter I-D, possibly > through appsawg, but nothing has ever happened. > > According to the Secretariat's automatic system, > draft-klensin-smtp-521code-02.txt expires next week. > > I'm happy to update and repost it if there is a plan to move it > forward. Or I can let it expire, thereby either killing the > nullMX draft or requiring that it be reissued with a different > strategy and presumably a new Last Call. Two minor nits: first sentence of Abstract: code should be plural: s/code/codes and, section 3: s/Server/server In section 3: > One additional case is > covered in the next section. it is not clear for me: a) to which this case is referring (code 554 or 521) b) to which section this is referring. General question: Excuse me if this has been discussed before, it is not my intention to propose significant changes right before publication. What I would like to ask is: is there a specific reason that some paragraphs talk about 'client' and 'server' where other paragraphs talk about 'system' and 'host'? I know these terms have different meanings, but wouldn't it be more consistent to use one 'set' throughout the document as much as possible? If (I repeat: if) there is no specific reason, I'd suggest to use the words 'client' and 'server'. Section 3, for example: > This specification adds the 521 reply code to the repertoire > specified in SMTP, reserving it for use at connection-opening time to > indicate that the host does not accept email under any circumstances. > It SHOULD be used for dummy SMTP servers whose sole purpose is to > notify systems that attempt to open mail connections that the host > never accepts mail. It MAY be used in other situations where the > intent is for the host to indicate that it never accepts email. would then become: This specification adds the 521 reply code to the repertoire specified in SMTP, reserving it for use at connection-opening time to indicate that the server does not accept email under any circumstances. It SHOULD be used for dummy SMTP servers whose sole purpose is to notify clients that attempt to open mail connections that the server never accepts mail. It MAY be used in other situations where the intent is for the server to indicate that it never accepts email. and the proposed 'acceptable' message for code 521 would become: "Server does not accept mail" /rolf From nobody Tue Mar 3 10:57:12 2015 Return-Path: X-Original-To: expand-draft-ietf-appsawg-uri-scheme-reg.all@virtual.ietf.org Delivered-To: apps-discuss@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 9D83F1A7028; Tue, 3 Mar 2015 04:15:23 -0800 (PST) X-Original-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F3C11A6EFE for ; Tue, 3 Mar 2015 04:15:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLXQ3jEhxxFq for ; Tue, 3 Mar 2015 04:15:21 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [IPv6:2607:f170:8000:1500::de]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CA451A3B9F for ; Tue, 3 Mar 2015 04:09:18 -0800 (PST) Received: from szxga01-in.huawei.com ([119.145.14.64]:5202) by gamay.tools.ietf.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:128) (Exim 4.80) (envelope-from ) id 1YSldR-0002Vm-9Q for draft-ietf-appsawg-uri-scheme-reg.all@tools.ietf.org; Tue, 03 Mar 2015 07:09:16 -0500 Received: from 172.24.2.119 (EHLO nkgeml404-hub.china.huawei.com) ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CKG34924; Tue, 03 Mar 2015 20:06:40 +0800 (CST) Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.146]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Tue, 3 Mar 2015 20:06:38 +0800 From: Qin Wu To: "ops-dir@ietf.org" , "draft-ietf-appsawg-uri-scheme-reg.all@tools.ietf.org" Thread-Topic: OPS-DIR review of draft-ietf-appsawg-uri-scheme-reg-04 Thread-Index: AdBVqoBBzKB16QZoQqSP3Y7FahtJFg== Date: Tue, 3 Mar 2015 12:06:38 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.180] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA846DC8C6nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-SA-Exim-Connect-IP: 119.145.14.64 X-SA-Exim-Rcpt-To: draft-ietf-appsawg-uri-scheme-reg.all@tools.ietf.org X-SA-Exim-Mail-From: bill.wu@huawei.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:57:07 +0000) X-SA-Exim-Scanned: Yes (on gamay.tools.ietf.org) Resent-To: draft-ietf-appsawg-uri-scheme-reg.all@ietf.org Resent-Message-Id: <20150303120918.9CA451A3B9F@ietfa.amsl.com> Resent-Date: Tue, 3 Mar 2015 04:09:18 -0800 (PST) Resent-From: bill.wu@huawei.com Archived-At: Archived-At: X-Mailman-Approved-At: Tue, 03 Mar 2015 10:57:10 -0800 Subject: [apps-discuss] OPS-DIR review of draft-ietf-appsawg-uri-scheme-reg-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 12:15:23 -0000 --_000_B8F9A780D330094D99AF023C5877DABA846DC8C6nkgeml501mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks: I have reviewed this document as part of the Operational directorate's ongo= ing effort to review all IETF documents being processed by the IESG. These= comments were written with the intent of improving the operational aspects= of the IETF drafts. Comments that are not addressed in last call may be in= cluded in AD reviews during the IESG review. Document editors and WG chair= s should treat these comments just like any other last call comments. This draft discusses Guidelines and Registration Procedures for URI Schemes= . It looks Operations and Management Review Checklist defined in RFC5706 do= esn't apply since there is no new protocol or protocol extension defined in= this draft. I think this draft is ready for publication. Here are a few editorial comme= nts: 1. Section 1, last two paragraphs s/Interationalized/Internationalized s/accomodate/accommodate 2. Section 1, last two paragraphs It looks these two paragraphs more fit into Scheme definition requirements = section, why split it out from section 3? would it be good to incorporate t= hese two paragraphs into section 3, No,? 3. Section 3, the 6th paragraph said: " The URI scheme name registration procedure can be used in such an event. " Pointing to section 7 would be good. 4. Section 4 and 5 Are there guidelines for permanent URI Scheme Registration if there is perm= anent URI Scheme Registration? Or Permanent URI Scheme Registration can onl= y be possible by upgrading provision URI Scheme Registration? -Qin --_000_B8F9A780D330094D99AF023C5877DABA846DC8C6nkgeml501mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks:

I have reviewed this documen= t as part of the Operational directorate's ongoing effort to review all IET= F documents being processed by the IESG.  These comments were written = with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call m= ay be included in AD reviews during the IESG review.  Document editors= and WG chairs should treat these comments just like any other last call co= mments.

 

This draft discusses Guideli= nes and Registration Procedures for URI Schemes. It looks Operations and Ma= nagement Review Checklist defined in RFC5706 doesn't apply since there is n= o new protocol or protocol extension defined in this draft.

I think this draft is ready = for publication. Here are a few editorial comments:

 

1= .   &= nbsp;   Section 1, last two par= agraphs

s/Interationalized/Internationa= lized

s/accomodate/accommodate

2= .   &= nbsp;   Section 1, last two par= agraphs

It looks these two paragraphs m= ore fit into Scheme definition requirements section, why split it out from = section 3? would it be good to incorporate these two paragraphs into sectio= n 3, No,?

 

3= .   &= nbsp;   Section 3, the 6th= paragraph said:

“

The URI scheme name registration p= rocedure can be used in such an event.

”

Pointing to section 7 woul= d be good.

 

4= .   &= nbsp;   Section 4 and 5

Are there guidelines for p= ermanent URI Scheme Registration if there is permanent URI Scheme Registrat= ion? Or Permanent URI Scheme Registration can only be possible by upgrading= provision URI Scheme Registration?

 

-Qin

 

--_000_B8F9A780D330094D99AF023C5877DABA846DC8C6nkgeml501mbschi_-- From nobody Tue Mar 3 15:25:59 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71EAA1A1BFC for ; Tue, 3 Mar 2015 15:25:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.185 X-Spam-Level: X-Spam-Status: No, score=0.185 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3581JmnN0W_q for ; Tue, 3 Mar 2015 15:25:57 -0800 (PST) Received: from drpepper.rename-it.nl (drpepper.rename-it.nl [217.119.238.16]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D0691A0277 for ; Tue, 3 Mar 2015 15:25:48 -0800 (PST) Received: from klara.student.utwente.nl ([130.89.162.218]:50373 helo=[10.168.3.2]) by drpepper.rename-it.nl with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1YSwC8-0004yg-0W for apps-discuss@ietf.org; Wed, 04 Mar 2015 00:25:45 +0100 Message-ID: <54F642C2.9020808@rename-it.nl> Date: Wed, 04 Mar 2015 00:24:50 +0100 From: Stephan Bosch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: apps-discuss@ietf.org Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-RenameIT-MailScanner-SpamScore: -2.3 (--) X-RenameIT-MailScanner-SpamCheck: No, score=-2.3 required=5.0 tests=ALL_TRUSTED, BAYES_00 autolearn=ham version=3.3.1 Archived-At: Subject: [apps-discuss] About the "tel:" URI X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 23:25:58 -0000 Hi, I'm assuming this is the correct place to discuss this, since the iptel WG is long concluded and I've seen some URI-related activity here recentl= y. I was testing my generic URI parser a bit and I encountered the "tel:" URI in RFC 3966. I noticed the following ABNF rule in that RFC: param-unreserved =3D "[" / "]" / "/" / ":" / "&" / "+" / "$" This describes part of the characters allowed unescaped in parameter values of the "tel:" URI. The generic URI specification in RFC 3986 states the following in Section 3.2.2: "A host identified by an Internet Protocol literal address, version 6 [RFC3513] or later, is distinguished by enclosing the IP literal within square brackets ("[" and "]"). This is the only place where square bracket characters are allowed in the URI syntax." The generic URI ABNF in RFC 3986 matches that statement. Given the param-unreserved ABNF rule stated above, the "tel:" URI would violate tha= t. Of course, RFC 3966 predates RFC 3986 and therefore the "tel:" URI would conform to its predecessor. Section 12 of RFC 3966 states the following: "The URI syntax now conforms to RFC 2396 [RFC2396]." But does it? It don't think so. Section 2.4.3 of RFC 2396 states the following: " Other characters are excluded because gateways and other transport agents are known to sometimes modify such characters, or they are used as delimiters. unwise =3D "{" | "}" | "|" | "\" | "^" | "[" | "]" | "`" " That is why the opaque_part ABNF rule in RFC 2396 does not allow a literal "[" and "]" either, which is what the "tel:" URI body would need to conform to. I've seen no erratum or RFC that would address this issue. So, am I missing something, or is this just an error that went unnoticed so far? Regards, Stephan. From nobody Fri Mar 6 06:12:33 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF8081ACE12 for ; Fri, 6 Mar 2015 06:12:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ah4lZhlTl-hH for ; Fri, 6 Mar 2015 06:12:25 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEA2A1A0419 for ; Fri, 6 Mar 2015 06:12:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3658; q=dns/txt; s=iport; t=1425651146; x=1426860746; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=L+NgwdMsGR1BdA1IsN7LsbY3CLyyBUdUpqqAhi61QUg=; b=YGSL8fEhuMSByTnZNDRGe1XPiR9LBIiR5z4fduLtghx7+4jegN2g5/qy mb+UbdnqpsZQMmTt/CQrKE/XpvlBRMausJVZ/O3Avh1ESRVdUtHJ9joAZ XQSdrYT0evWAnfjKiYiPGRV8gl9Lh1JY7tUA3dD6bCQTYdRj6OHdbNBuo o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CmBgCAtflU/5BdJa1cgwZSVQUEgwa+aIVuAhyBHU0BAQEBAQF8hBABAQQjETMQEgIBCBoCJgICAjAVBgEGAwIEEwmIJggFtAWaVgEBAQEBAQQBAQEBAQEBG4EhiXaEJVCCaIFDBZAHg2OFaoEaOYJtjy8jgjKBPG+BA0F/AQEB X-IronPort-AV: E=Sophos;i="5.11,353,1422921600"; d="scan'208";a="129555474" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-7.cisco.com with ESMTP; 06 Mar 2015 14:12:25 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t26ECOKT012326 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 6 Mar 2015 14:12:24 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.138]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Fri, 6 Mar 2015 08:12:24 -0600 From: "Eric Vyncke (evyncke)" To: "apps-discuss@ietf.org" Thread-Topic: New Version Notification for draft-vyncke-v6ops-happy-eyeballs-cookie-01.txt Thread-Index: AQHQV+OAmfOoS9exuUuMXePFUNM3gp0P9LIA Date: Fri, 6 Mar 2015 14:12:22 +0000 Message-ID: References: <20150306075938.24593.60303.idtracker@ietfa.amsl.com> In-Reply-To: <20150306075938.24593.60303.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.6.141106 x-originating-ip: [10.55.185.71] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [apps-discuss] FW: New Version Notification for draft-vyncke-v6ops-happy-eyeballs-cookie-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 14:12:32 -0000 WW91IG1heSBmaW5kIHRoaXMgc2hvcnQgSS1EIGludGVyZXN0aW5nOiBpdCBpcyByZWxhdGVkIHRv IGFsbCBhcHBsaWNhdGlvbg0KdXNpbmcgY29va2llIChvciBhbnkgc3RhdGUpIGxpbmtlZCBvbiBh biBJUCBhZGRyZXNzIGluIGEgd29ybGQgd2hlcmUgdXNlcg0KYWdlbnRzIGFyZSBkdWFsLXN0YWNr LCBhcmUgTkFUIGJ5IGNhcnJpZXItZ3JhZGUgTkFULCBhcmUgbXVsdGktaG9tZWQsIC4uLg0KPT4g dGhlIG1hcHBpbmcgSVBfYWRkcmVzcyA8PT4gdXNlciB3aGljaCB3YXMgbmV2ZXIgY29ycmVjdCBp cyBiZWNvbWluZw0KbW9yZSBhbmQgbW9yZSB3cm9uZyA6LSkNCg0KQ29tbWVudHMgYXJlIG9idmlv dXNseSB3ZWxjb21lDQoNCi3DqXJpYw0KDQpPbiA2LzAzLzE1IDA4OjU5LCAiaW50ZXJuZXQtZHJh ZnRzQGlldGYub3JnIiA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPg0Kd3JvdGU6DQoNCj4NCj5B IG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtdnluY2tlLXY2b3BzLWhhcHB5LWV5ZWJhbGxzLWNv b2tpZS0wMS50eHQNCj5oYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEVyaWMgVnlu Y2tlIGFuZCBwb3N0ZWQgdG8gdGhlDQo+SUVURiByZXBvc2l0b3J5Lg0KPg0KPk5hbWU6CQlkcmFm dC12eW5ja2UtdjZvcHMtaGFwcHktZXllYmFsbHMtY29va2llDQo+UmV2aXNpb246CTAxDQo+VGl0 bGU6CQlIVFRQIFN0YXRlIE1hbmFnZW1lbnQgTWVjaGFuaXNtcyB3aXRoIE11bHRpcGxlIEFkZHJl c3NlcyBVc2VyDQo+QWdlbnRzDQo+RG9jdW1lbnQgZGF0ZToJMjAxNS0wMy0wNg0KPkdyb3VwOgkJ SW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+UGFnZXM6CQk3DQo+VVJMOiAgICAgICAgICAgIA0KPmh0 dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXZ5bmNrZS12Nm9wcy1oYXBw eS1leWViYWxscy1jb29rDQo+aWUtMDEudHh0DQo+U3RhdHVzOiAgICAgICAgIA0KPmh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXZ5bmNrZS12Nm9wcy1oYXBweS1leWViYWxs cy1jb29raWUvDQo+SHRtbGl6ZWQ6ICAgICAgIA0KPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LXZ5bmNrZS12Nm9wcy1oYXBweS1leWViYWxscy1jb29raWUtMDENCj5EaWZmOiAgICAg ICAgICAgDQo+aHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtdnluY2tlLXY2 b3BzLWhhcHB5LWV5ZWJhbGxzLWNvb2tpZS0NCj4wMQ0KPg0KPkFic3RyYWN0Og0KPiAgIEhUVFAg c2VydmVycyB1c3VhbGx5IHNhdmUgc2Vzc2lvbiBzdGF0ZXMgaW4gdGhlaXIgcGVyc2lzdGVudCBz dG9yYWdlDQo+ICAgaW5kZXhlZCBieSBzZXNzaW9uIGNvb2tpZXMgZ2VuZXJhdGVkIGJ5IHRoZSBI VFRQIHNlcnZlcnMuICBJdCBpcyB1cA0KPiAgIHRvIHRoZSBIVFRQIHVzZXItYWdlbnQgdG8gc2Vu ZCB0aGlzIHNlc3Npb24gY29va2llIG9uIGVhY2ggSFRUUA0KPiAgIHJlcXVlc3QuICBTb21lIEhU VFAgc2VydmVycyBjaGVjayB3aGV0aGVyIHRoZSBjb29raWUgaXMgYXNzb2NpYXRlZA0KPiAgIHdp dGggdGhlIEhUVFAgdXNlci1hZ2VudCBieSB0aGUgbWVhbnMgb2YgdGhlIHVzZXItYWdlbnQgSVAg YWRkcmVzcy4NCj4gICBFdmVyeXRoaW5nIGxpbmtpbmcgYSBzdGF0ZSB0byBhbiBJUCBhZGRyZXNz IChzdWNoIGFzIE9BdXRoIGFjY2Vzcw0KPiAgIGNvZGUpIHRvIGFuIElQIGFkZHJlc3MgaGFzIHRo ZSBzYW1lIGlzc3VlLg0KPg0KPiAgIElmIHRoZSBIYXBweSBFeWViYWxsIG1lY2hhbmlzbSBpcyB1 c2VkIHRvIHNlbGVjdCBiZXR3ZWVuIElQdjYgYW5kDQo+ICAgSVB2NCwgaXQgbWF5IGhhcHBlbiB0 aGF0IHdoaWxlIHVzaW5nIHRoZSBzYW1lIEhUVFAgc2VydmVyLCBzb21lIEhUVFANCj4gICByZXF1 ZXN0cyBhcmUgZG9uZSBvdmVyIElQdjYgYW5kIHRoZSBvdGhlcnMgb3ZlciBJUHY0LCB3aGljaCBs ZWFkcyB0bw0KPiAgIHR3byBkaWZmZXJlbnQgc2V0cyBvZiBzZXNzaW9uIHN0YXRlcyBpbiB0aGUg SFRUUCBzZXJ2ZXIuICBUaGlzIGhhcw0KPiAgIHRoZSBjb25zZXF1ZW5jZSBvZiBpbmNvbnNpc3Rl bmNpZXMgYXQgdGhlIEhUVFAgc2VydmVyLg0KPg0KPiAgIFRoZSBvbmx5IHB1cnBvc2Ugb2YgdGhp cyBkb2N1bWVudCBpcyB0byBkb2N1bWVudCB0aGlzIGlzc3VlIGluIG1vcmUNCj4gICBkZXRhaWxz IHRoYW4gaW4gc2VjdGlvbiA4LjIgb2YgUkZDIDY4ODMgaW5jbHVkaW5nIHNlY3VyaXR5DQo+ICAg Y29uc2lkZXJhdGlvbnMgYW5kIG1pdGlnYXRpb25zLg0KPg0KPiAgIEEgc2ltaWxhciBwcm9ibGVt IGFyaXNlcyB3aXRoIHRoZSB1c2Ugb2Ygbm9uIFJGQyA2ODg4IGNvbXBsaWFudA0KPiAgIENhcnJp ZXItR3JhZGUgTkFUIChDR04pIGRldmljZXMgdXNlZCB0byBhY2Nlc3MgYW4gSVB2NC1vbmx5IEhU VFANCj4gICBzZXJ2ZXIgb3IgSFRUUCB1c2VyLWFnZW50IHVzaW5nIG11bHRpLWhvbWluZy4NCj4N Cj4gICAgICAgICAgICAgICAgICANCj4gICAgICAgIA0KPg0KPg0KPlBsZWFzZSBub3RlIHRoYXQg aXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQo+c3VibWlz c2lvbg0KPnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUg YXQgdG9vbHMuaWV0Zi5vcmcuDQo+DQo+VGhlIElFVEYgU2VjcmV0YXJpYXQNCj4NCg0K From nobody Sun Mar 8 00:37:02 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93F801A1DE1 for ; Sun, 8 Mar 2015 00:37:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fo-NjTcCeKUK for ; Sun, 8 Mar 2015 00:36:56 -0800 (PST) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0D5D1A1DBC for ; Sun, 8 Mar 2015 00:36:55 -0800 (PST) Received: by widex7 with SMTP id ex7so12250046wid.3 for ; Sun, 08 Mar 2015 00:36:54 -0800 (PST) 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=Lg4YqmJgtfeSCyUnRDEyR5l8OTePRbObuOQc3quGl7A=; b=JprQFWKMOcPsxM5rgmjaUytHfnydqeccXlj/cCdWh8iQnai4SFU3uGRCrG4vJrPE+V Z8HmAaRPlyvf6mI/p9ArK+aR3xpzefck33QL8/SzhFLIg9hZXopIZ/h7R3wyvJFzDpxy 9PH8UMRYV83LTPR1SfhVYygubTuDVJgUbz5YrlATARQEaPdMt63PZhsPb0oI/fjmeSiv HerGqf/lKwEi4mP2ETqwt89PGrPWL0d2r/G6ekpWMEAhvioE6SzUAY9eY1dqPlbysEJ7 3Qe3ZUyU4pHg/4Fo49NZYj0vdB5y2l5F8fakyZrXpTLD7riWrkj+NHUm7Kv8Y8iphvio TwGw== MIME-Version: 1.0 X-Received: by 10.180.208.43 with SMTP id mb11mr35383525wic.52.1425803814620; Sun, 08 Mar 2015 00:36:54 -0800 (PST) Received: by 10.27.179.212 with HTTP; Sun, 8 Mar 2015 00:36:54 -0800 (PST) Date: Sun, 8 Mar 2015 00:36:54 -0800 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=001a11c3863ce3d78a0510c2d1ef Archived-At: Subject: [apps-discuss] Preliminary IETF 92 APPSAWG/APPAREA agenda X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2015 08:37:00 -0000 --001a11c3863ce3d78a0510c2d1ef Content-Type: text/plain; charset=UTF-8 The preliminary agenda for IETF 92's APPSAWG/APPAREA meeting is now available at: http://www.ietf.org/proceedings/92/agenda/agenda-92-appsawg Please let us know if any requests for agenda time were missed or the time allotted needs adjustment. -MSK, APPSAWG co-chair --001a11c3863ce3d78a0510c2d1ef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The preliminary agenda for IETF 92's APPSAWG= /APPAREA meeting is now available at:

http://www.ietf.org/proceedings/9= 2/agenda/agenda-92-appsawg

Please let us know if any reque= sts for agenda time were missed or the time allotted needs adjustment.
<= br>
-MSK, APPSAWG co-chair

--001a11c3863ce3d78a0510c2d1ef-- From nobody Sun Mar 8 10:04:59 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C80DA1A004A for ; Sun, 8 Mar 2015 10:04:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XHnqNSIcBtGD for ; Sun, 8 Mar 2015 10:04:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 481DE1A004B for ; Sun, 8 Mar 2015 10:04:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150308170457.31237.65454.idtracker@ietfa.amsl.com> Date: Sun, 08 Mar 2015 10:04:57 -0700 From: IETF Secretariat Archived-At: Subject: [apps-discuss] Milestones changed for appsawg WG X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2015 17:04:58 -0000 Changed milestone "Publication requested for draft-ietf-appsawg-http-problem", set due date to April 2015 from March 2015. Changed milestone "Publication requested for draft-ietf-appsawg-rfc7001bis", set due date to April 2015 from March 2015. URL: http://datatracker.ietf.org/wg/appsawg/charter/ From nobody Sun Mar 8 22:32:25 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 962F21A6EF1 for ; Sun, 8 Mar 2015 22:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4YXLOQOas76D for ; Sun, 8 Mar 2015 22:32:23 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0087.outbound.protection.outlook.com [207.46.100.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 331221A6F29 for ; Sun, 8 Mar 2015 22:32:23 -0700 (PDT) Received: from DM2PR0201MB0960.namprd02.prod.outlook.com (25.160.216.28) by DM2PR0201MB0959.namprd02.prod.outlook.com (25.160.216.27) with Microsoft SMTP Server (TLS) id 15.1.99.14; Mon, 9 Mar 2015 05:32:22 +0000 Received: from DM2PR0201MB0960.namprd02.prod.outlook.com ([25.160.216.28]) by DM2PR0201MB0960.namprd02.prod.outlook.com ([25.160.216.28]) with mapi id 15.01.0099.004; Mon, 9 Mar 2015 05:32:22 +0000 From: Larry Masinter To: Stephan Bosch , "apps-discuss@ietf.org" Thread-Topic: [apps-discuss] About the "tel:" URI Thread-Index: AQHQVglsf+q5Nj1WEUysfEL3La/EOp0TM2cA Date: Mon, 9 Mar 2015 05:32:22 +0000 Message-ID: <885C9E34-4333-4678-A59A-6AA5973DBB2F@adobe.com> References: <54F642C2.9020808@rename-it.nl> In-Reply-To: <54F642C2.9020808@rename-it.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/15.8.0.150303 x-originating-ip: [50.184.24.49] authentication-results: rename-it.nl; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0201MB0959; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:0; SFV:NSPM; SFS:(10009020)(6009001)(24454002)(479174004)(377454003)(33656002)(76176999)(106116001)(558084003)(107886001)(50986999)(99286002)(54356999)(2900100001)(2950100001)(2501003)(122556002)(86362001)(19580395003)(19580405001)(92566002)(83716003)(87936001)(46102003)(2656002)(82746002)(83506001)(40100003)(77156002)(36756003)(102836002)(66066001)(62966003)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR0201MB0959; H:DM2PR0201MB0960.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:de; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5001009); SRVR:DM2PR0201MB0959; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0201MB0959; x-forefront-prvs: 05102978A2 Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: adobe.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2015 05:32:22.2270 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0201MB0959 Archived-At: Subject: Re: [apps-discuss] About the "tel:" URI X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 05:32:24 -0000 DQoNCg0KDQoNCk9uIDMvMy8xNSwgMzoyNCBQTSwgIlN0ZXBoYW4gQm9zY2giIDxzdGVwaGFuQHJl bmFtZS1pdC5ubD4gd3JvdGU6DQoNCj4zOTY2DQo= From nobody Sun Mar 8 22:32:49 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED9BC1A7008 for ; Sun, 8 Mar 2015 22:32:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m5CIdmr7iw9S for ; Sun, 8 Mar 2015 22:32:47 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0699.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:699]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E751E1A6FEF for ; Sun, 8 Mar 2015 22:32:41 -0700 (PDT) Received: from DM2PR0201MB0960.namprd02.prod.outlook.com (25.160.216.28) by DM2PR0201MB0958.namprd02.prod.outlook.com (25.160.216.26) with Microsoft SMTP Server (TLS) id 15.1.99.14; Mon, 9 Mar 2015 05:32:20 +0000 Received: from DM2PR0201MB0960.namprd02.prod.outlook.com ([25.160.216.28]) by DM2PR0201MB0960.namprd02.prod.outlook.com ([25.160.216.28]) with mapi id 15.01.0099.004; Mon, 9 Mar 2015 05:32:20 +0000 From: Larry Masinter To: Stephan Bosch , "apps-discuss@ietf.org" Thread-Topic: [apps-discuss] About the "tel:" URI Thread-Index: AQHQVglsf+q5Nj1WEUysfEL3La/EOp0TM2UA Date: Mon, 9 Mar 2015 05:32:20 +0000 Message-ID: <3A1BADCD-F4EA-4CEC-993E-F1F9D796FEA5@adobe.com> References: <54F642C2.9020808@rename-it.nl> In-Reply-To: <54F642C2.9020808@rename-it.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/15.8.0.150303 x-originating-ip: [50.184.24.49] authentication-results: rename-it.nl; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0201MB0958; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:0; SFV:NSPM; SFS:(10009020)(6009001)(24454002)(51704005)(479174004)(377454003)(54356999)(2950100001)(33656002)(106116001)(76176999)(107886001)(50986999)(99286002)(2501003)(2900100001)(122556002)(86362001)(19580395003)(19580405001)(92566002)(83716003)(87936001)(46102003)(2656002)(82746002)(40100003)(83506001)(77156002)(36756003)(102836002)(15975445007)(66066001)(62966003)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR0201MB0958; H:DM2PR0201MB0960.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5001009); SRVR:DM2PR0201MB0958; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0201MB0958; x-forefront-prvs: 05102978A2 Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: adobe.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2015 05:32:20.0864 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0201MB0958 Archived-At: Subject: Re: [apps-discuss] About the "tel:" URI X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 05:32:49 -0000 VGhpcyBpcyBhIHByb2JsZW0gbm8gb25lIG5vdGljZWQgYmVmb3JlLiBSRkMgMzk2NiAo4oCYdGVs 4oCZKSBhbGxvd3MgWyBdIGluIHBsYWNlcyB3aGVyZSBSRkMgMzk4NiAoZ2VuZXJpYyBVUkkgc3lu dGF4KSBkb2VzbuKAmXQuDQoNCklmIHRoZXJlIHdlcmUgYXBwbGljYXRpb25zIHRoYXQgdXNlZCBb IF0gaW4gcGFyYW1ldGVycywgdGhlbiB3ZSBjb3VsZCB0YWxrIGFib3V0IGNoYW5naW5nIDM5ODYg YW5kIHRoZSDigJxVUkwgbWVzc+KAnSwgYnV0IEkgY2Fu4oCZdCBzZWVtIHRvIGZpbmQgYW55IGV4 cGxhbmF0aW9uIG9mIGhvdyBvbmUgbWlnaHQgdXNlIFtdIGluIHBhcmFtZXRlcnMgYXBwbGllZCB0 byBhIHRlbGVwaG9uZSBudW1iZXIsIHNvIHBlcmhhcHMgdGhlIGNvbmZsaWN0IGlzIG1vb3QuIA0K DQpMYXJyeQ0KDQpJcyB0aGVyZSBhbnkgcGxhbm5lZCBkaXNjdXNzaW9uIG9mIHRoZSBVUkwvVVJJ L0lSSSBzaXR1YXRpb24/IE5vIEJPRiwgbm8gZGlzY3Vzc2lvbiBpbiB0aGUgYXBwcyBhcmVhIHdv cmtpbmcgZ3JvdXAgYWdlbmRhPw0KDQoNCg0KDQoNCg0KDQpPbiAzLzMvMTUsIDM6MjQgUE0sICJT dGVwaGFuIEJvc2NoIiA8c3RlcGhhbkByZW5hbWUtaXQubmw+IHdyb3RlOg0KDQo+SGksDQo+DQo+ SSdtIGFzc3VtaW5nIHRoaXMgaXMgdGhlIGNvcnJlY3QgcGxhY2UgdG8gZGlzY3VzcyB0aGlzLCBz aW5jZSB0aGUgaXB0ZWwNCj5XRyBpcyBsb25nIGNvbmNsdWRlZCBhbmQgSSd2ZSBzZWVuIHNvbWUg VVJJLXJlbGF0ZWQgYWN0aXZpdHkgaGVyZSByZWNlbnRseS4NCj4NCj5JIHdhcyB0ZXN0aW5nIG15 IGdlbmVyaWMgVVJJIHBhcnNlciBhIGJpdCBhbmQgSSBlbmNvdW50ZXJlZCB0aGUgInRlbDoiDQo+ VVJJIGluIFJGQyAzOTY2LiBJIG5vdGljZWQgdGhlIGZvbGxvd2luZyBBQk5GIHJ1bGUgaW4gdGhh dCBSRkM6DQo+DQo+cGFyYW0tdW5yZXNlcnZlZCAgICAgPSAiWyIgLyAiXSIgLyAiLyIgLyAiOiIg LyAiJiIgLyAiKyIgLyAiJCINCj4NCj5UaGlzIGRlc2NyaWJlcyBwYXJ0IG9mIHRoZSBjaGFyYWN0 ZXJzIGFsbG93ZWQgdW5lc2NhcGVkIGluIHBhcmFtZXRlcg0KPnZhbHVlcyBvZiB0aGUgInRlbDoi IFVSSS4NCj4NCj5UaGUgZ2VuZXJpYyBVUkkgc3BlY2lmaWNhdGlvbiBpbiBSRkMgMzk4NiBzdGF0 ZXMgdGhlIGZvbGxvd2luZyBpbg0KPlNlY3Rpb24gMy4yLjI6ICJBIGhvc3QgaWRlbnRpZmllZCBi eSBhbiBJbnRlcm5ldCBQcm90b2NvbCBsaXRlcmFsDQo+YWRkcmVzcywgdmVyc2lvbiA2IFtSRkMz NTEzXSBvciBsYXRlciwgaXMgZGlzdGluZ3Vpc2hlZCBieSBlbmNsb3NpbmcgdGhlDQo+SVAgbGl0 ZXJ1bCB3aXRoaW4gc3F1YXJlIGJyYWNrZXRzICgiWyIgYW5kICJdIikuICBUaGlzIGlzIHRoZSBv bmx5IHBsYWNlDQo+d2hlcmUgc3F1YXJlIGJyYWNrZXQgY2hhcmFjdGVycyBhcmUgYWxsb3dlZCBp biB0aGUgVVJJIHN5bnRheC4iDQo+DQo+VGhlIGdlbmVyaWMgVVJJIEFCTkYgaW4gUkZDIDM5ODYg IG1hdGNoZXMgdGhhdCBzdGF0ZW1lbnQuIEdpdmVuIHRoZQ0KPnBhcmFtLXVucmVzZXJ2ZWQgQUJO RiBydWxlIHN0YXRlZCBhYm92ZSwgdGhlICJ0ZWw6IiBVUkkgd291bGQgdmlvbGF0ZSB0aGF0Lg0K Pg0KPk9mIGNvdXJzZSwgUkZDIDM5NjYgcHJlZGF0ZXMgUkZDIDM5ODYgYW5kIHRoZXJlZm9yZSB0 aGUgInRlbDoiIFVSSSB3b3VsZA0KPmNvbmZvcm0gdG8gaXRzIHByZWRlY2Vzc29yLiBTZWN0aW9u IDEyIG9mIFJGQyAzOTY2IHN0YXRlcyB0aGUgZm9sbG93aW5nOg0KPiJUaGUgVVJJIHN5bnRheCBu b3cgY29uZm9ybXMgdG8gUkZDIDIzOTYgW1JGQzIzOTZdLiINCj4NCj5CdXQgZG9lcyBpdD8gSXQg ZG9uJ3QgdGhpbmsgc28uIFNlY3Rpb24gMi40LjMgb2YgUkZDIDIzOTYgc3RhdGVzIHRoZQ0KPmZv bGxvd2luZzoNCj4NCj4iDQo+T3RoZXIgY2hhcmFjdGVycyBhcmUgZXhjbHVkZWQgYmVjYXVzZSBn YXRld2F5cyBhbmQgb3RoZXIgdHJhbnNwb3J0DQo+YWdlbnRzIGFyZSBrbm93biB0byBzb21ldGlt ZXMgbW9kaWZ5IHN1Y2ggY2hhcmFjdGVycywgb3IgdGhleSBhcmUgdXNlZA0KPmFzIGRlbGltaXRl cnMuDQo+DQo+dW53aXNlID0gInsiIHwgIn0iIHwgInwiIHwgIlwiIHwgIl4iIHwgIlsiIHwgIl0i IHwgImAiDQo+Ig0KPg0KPlRoYXQgaXMgd2h5IHRoZSBvcGFxdWVfcGFydCBBQk5GIHJ1bGUgaW4g UkZDIDIzOTYgZG9lcyBub3QgYWxsb3cgYQ0KPmxpdGVyYWwgIlsiIGFuZCAiXSIgZWl0aGVyLCB3 aGljaCBpcyB3aGF0IHRoZSAidGVsOiIgVVJJIGJvZHkgd291bGQgbmVlZA0KPnRvIGNvbmZvcm0g dG8uDQo+DQo+SSd2ZSBzZWVuIG5vIGVycmF0dW0gb3IgUkZDIHRoYXQgd291bGQgYWRkcmVzcyB0 aGlzIGlzc3VlLiBTbywgYW0gSQ0KPm1pc3Npbmcgc29tZXRoaW5nLCBvciBpcyB0aGlzIGp1c3Qg YW4gZXJyb3IgdGhhdCB3ZW50IHVubm90aWNlZCBzbyBmYXI/DQo+DQo+UmVnYXJkcywNCj4NCj5T dGVwaGFuLg0KPg0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+YXBwcy1kaXNjdXNzIG1haWxpbmcgbGlzdA0KPmFwcHMtZGlzY3Vzc0BpZXRmLm9y Zw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXBwcy1kaXNjdXNzDQo= From nobody Mon Mar 9 01:25:03 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 748291A86EA; Mon, 9 Mar 2015 01:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zelWivZZJOwn; Mon, 9 Mar 2015 01:24:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C521A1A86FE; Mon, 9 Mar 2015 01:24:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150309082455.21530.15286.idtracker@ietfa.amsl.com> Date: Mon, 09 Mar 2015 01:24:55 -0700 Archived-At: Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-text-markdown-06.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 08:25:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : The text/markdown Media Type Author : Sean Leonard Filename : draft-ietf-appsawg-text-markdown-06.txt Pages : 13 Date : 2015-02-23 Abstract: This document registers the text/markdown media type for use with Markdown, a family of plain text formatting syntaxes that optionally can be converted to formal markup languages such as HTML. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-text-markdown/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-text-markdown-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-text-markdown-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 9 09:03:12 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C0A11A8A7C for ; Mon, 9 Mar 2015 09:03:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.185 X-Spam-Level: X-Spam-Status: No, score=0.185 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dAF4vDSHCKT9 for ; Mon, 9 Mar 2015 09:03:00 -0700 (PDT) Received: from drpepper.rename-it.nl (drpepper.rename-it.nl [217.119.238.16]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B3CE1A8EA9 for ; Mon, 9 Mar 2015 09:02:38 -0700 (PDT) Received: from zilver015069.mobiel.utwente.nl ([130.89.15.69]:57883) by drpepper.rename-it.nl with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1YV08Y-00025I-1q; Mon, 09 Mar 2015 17:02:35 +0100 Message-ID: <54FDC3DD.90408@rename-it.nl> Date: Mon, 09 Mar 2015 17:01:33 +0100 From: Stephan Bosch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Larry Masinter , "apps-discuss@ietf.org" References: <54F642C2.9020808@rename-it.nl> <3A1BADCD-F4EA-4CEC-993E-F1F9D796FEA5@adobe.com> In-Reply-To: <3A1BADCD-F4EA-4CEC-993E-F1F9D796FEA5@adobe.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-RenameIT-MailScanner-SpamScore: -2.3 (--) X-RenameIT-MailScanner-SpamCheck: No, score=-2.3 required=5.0 tests=ALL_TRUSTED, BAYES_00 autolearn=ham version=3.3.1 Archived-At: Subject: Re: [apps-discuss] About the "tel:" URI X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 16:03:06 -0000 Hi Larry, Larry Masinter schreef op 9-3-2015 om 6:32: > This is a problem no one noticed before. RFC 3966 (‘tel’) allows [ ] in places where RFC 3986 (generic URI syntax) doesn’t. Ok. > If there were applications that used [ ] in parameters, then we could talk about changing 3986 and the “URL mess”, but I can’t seem to find any explanation of how one might use [] in parameters applied to a telephone number, so perhaps the conflict is moot. If no applications depend on it, I'd propose prohibiting "[" and "]" in an erratum to RFC 3966 (or even a new RFC if that is what it takes); new tel URI parameters may be defined in the future and it should be made clear that those characters cannot used in parameters without escaping. > Is there any planned discussion of the URL/URI/IRI situation? No BOF, no discussion in the apps area working group agenda? Not that I've seen. I did notice some past discussions about SIP URIs vs RFC 3986 in some IETF mailing list (can't remember which one). Those also violate RFC 3986, because these allow IP6 literals with "[" and "]" inside an URI component that is not //authority. IAX URIs have similar issues. Regards, Stephan. From nobody Mon Mar 9 10:11:46 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4F9C1A8906; Mon, 9 Mar 2015 10:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2BZ1v6c1JVm; Mon, 9 Mar 2015 10:11:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 18BCE1A90A2; Mon, 9 Mar 2015 10:11:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150309171133.27954.42393.idtracker@ietfa.amsl.com> Date: Mon, 09 Mar 2015 10:11:33 -0700 Archived-At: Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-mdn-3798bis-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 17:11:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : Message Disposition Notification Authors : Tony Hansen Alexey Melnikov Filename : draft-ietf-appsawg-mdn-3798bis-02.txt Pages : 32 Date : 2015-03-09 Abstract: This memo defines a MIME content-type that may be used by a mail user agent (MUA) or electronic mail gateway to report the disposition of a message after it has been successfully delivered to a recipient. This content-type is intended to be machine-processable. Additional message header fields are also defined to permit Message Disposition Notifications (MDNs) to be requested by the sender of a message. The purpose is to extend Internet Mail to support functionality often found in other messaging systems, such as X.400 and the proprietary "LAN-based" systems, and often referred to as "read receipts," "acknowledgements", or "receipt notifications." The intention is to do this while respecting privacy concerns, which have often been expressed when such functions have been discussed in the past. Because many messages are sent between the Internet and other messaging systems (such as X.400 or the proprietary "LAN-based" systems), the MDN protocol is designed to be useful in a multi- protocol messaging environment. To this end, the protocol described in this memo provides for the carriage of "foreign" addresses, in addition to those normally used in Internet Mail. Additional attributes may also be defined to support "tunneling" of foreign notifications through Internet Mail. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-mdn-3798bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-mdn-3798bis-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-mdn-3798bis-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 9 14:27:38 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F418D1AC40D; Mon, 9 Mar 2015 14:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F0XQ4UGG_VlM; Mon, 9 Mar 2015 14:27:26 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEF9F1ACD42; Mon, 9 Mar 2015 14:27:23 -0700 (PDT) Received: by widem10 with SMTP id em10so10425977wid.2; Mon, 09 Mar 2015 14:27:22 -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=MyNg4zjxnX0MX4NPxcTJyDggXW0RwbyTjphNdxqARSQ=; b=HJakZFeNINmu/hCsdbbtgP5nEBuRKrtXHYVSEXQer33K2t046vSpZasJCASdfrw+QZ FYW2X5Ua+kCpQri4VZDKIKz89mQBzQxF4uks9Or1hfTNKPe1ScmOADJEt9qxzFOzkhE9 aMXle/RhelGKFDNQ/GRCghvwNYPRQMvBl+Y/ajy6pxmWRcZfDW7hAIYJh2emAINm2SxI YYyJ3cBtA8iBBAXcFxVEhoOVaYFmhl1cVawwbvuI04bjiMoXOKvPQQry5cKoAWr6f3EX SrSbXcOFCFtm2UGbgOjPus9Ts3bVoKTeQrVD105oDn7lc4Wib7HKF3OHR32bT44eoWfq Kqlg== MIME-Version: 1.0 X-Received: by 10.194.192.167 with SMTP id hh7mr62171415wjc.151.1425936442636; Mon, 09 Mar 2015 14:27:22 -0700 (PDT) Received: by 10.194.68.39 with HTTP; Mon, 9 Mar 2015 14:27:20 -0700 (PDT) Date: Mon, 9 Mar 2015 17:27:20 -0400 Message-ID: From: Daniel Migault To: Time Zone Data Distribution Service , saag@ietf.org, apps-discuss@ietf.org, int-area@ietf.org, ops-area@ietf.org, ietf-privacy@ietf.org Content-Type: multipart/alternative; boundary=047d7b8743f822bd630510e1b31f Archived-At: Subject: [apps-discuss] [Tzdist] WGLC2 for draft-ietf-tzdist-service-06.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 21:27:30 -0000 --047d7b8743f822bd630510e1b31f Content-Type: text/plain; charset=UTF-8 Dear Friends and Colleagues, This is the second Working Group Last Call (WGLC) for draft-ietf-tzdist-service-06 [1]. Feel free to make any comment before March 23. During the first WGLC of draft-ietf-tzdist-service-05.txt we received consequent feed backs and remarks from cross areas. We believe these remarks have been addressed in this new version. [1] http://tools.ietf.org/html/draft-ietf-tzdist-service-06 Best Regards Daniel and Eliot ---------- Forwarded message ---------- From: Date: Mon, Mar 9, 2015 at 5:10 PM Subject: [Tzdist] I-D Action: draft-ietf-tzdist-service-06.txt To: i-d-announce@ietf.org Cc: tzdist@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Time Zone Data Distribution Service Working Group of the IETF. Title : Time Zone Data Distribution Service Authors : Michael Douglass Cyrus Daboo Filename : draft-ietf-tzdist-service-06.txt Pages : 54 Date : 2015-03-09 Abstract: This document defines a time zone data distribution service that allows reliable, secure and fast delivery of time zone data and leap second rules to client systems such as calendaring and scheduling applications or operating systems. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tzdist-service/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tzdist-service-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tzdist-service-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Tzdist mailing list Tzdist@ietf.org https://www.ietf.org/mailman/listinfo/tzdist -- Daniel Migault Ericsson --047d7b8743f822bd630510e1b31f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Friends and Colleagues,

<= /div>This is the second Working Group Last Call (WGLC) for=20 draft-i= etf-tzdist-service-06 [1]. Feel free to make any comment before March 23.

During the first WGLC of draft-ietf-tzdist-service-05.txt we re= ceived consequent feed backs and remarks from cross areas. We believe these= remarks have been addressed in this new version.

[1] http://tools.ietf.org/html/draft-ietf-tzdist-service-06

Best Regards

Daniel and Eliot


---------- Forwarded message --= --------
From: <= internet-drafts@ietf.org>= ;
Date: Mon, Mar 9, 2015 at 5:10 PM
Subject: [Tzdist] I-D Acti= on: draft-ietf-tzdist-service-06.txt
To: i-d-announce@ietf.org
Cc: tzdist@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Time Zone Data Distribution Service = Working Group of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Time Zone Data Distribution Service
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Mich= ael Douglass
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Cyrus Daboo
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-tzdist-service-06.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 54
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2015-03-09

Abstract:
=C2=A0 =C2=A0This document defines a time zone data distribution service th= at
=C2=A0 =C2=A0allows reliable, secure and fast delivery of time zone data an= d leap
=C2=A0 =C2=A0second rules to client systems such as calendaring and schedul= ing
=C2=A0 =C2=A0applications or operating systems.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tzdist-service/<= /a>

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-tzdist-service-06

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tzdist-ser= vice-06


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

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

_______________________________________________
Tzdist mailing list
Tzdist@ietf.org
= https://www.ietf.org/mailman/listinfo/tzdist



--
Daniel Migault
Ericsson
--047d7b8743f822bd630510e1b31f-- From nobody Mon Mar 9 14:32:47 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E37B31A0126; Mon, 9 Mar 2015 14:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4RTb3kfODGXx; Mon, 9 Mar 2015 14:32:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DAAFC1A8BB6; Mon, 9 Mar 2015 14:32:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150309213241.21308.78039.idtracker@ietfa.amsl.com> Date: Mon, 09 Mar 2015 14:32:41 -0700 Archived-At: Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc7001bis-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 21:32:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : Message Header Field for Indicating Message Authentication Status Author : Murray S. Kucherawy Filename : draft-ietf-appsawg-rfc7001bis-03.txt Pages : 46 Date : 2015-03-09 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 to make sorting and filtering decisions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc7001bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-rfc7001bis-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-rfc7001bis-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 9 14:34:43 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3007F1A0126 for ; Mon, 9 Mar 2015 14:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1igFAPpjtx9P for ; Mon, 9 Mar 2015 14:34:41 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2471D1AC3A2 for ; Mon, 9 Mar 2015 14:34:40 -0700 (PDT) Received: by wivr20 with SMTP id r20so25458757wiv.3 for ; Mon, 09 Mar 2015 14:34: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=Ka3qtJ0X+Xzdzswde8Ud/xf2EfoF2w8ssXexj43Ta/Q=; b=mOs8j+Z2ef0+LNXyhZVmIthpzwgGY5YtnpC+VOGUJzMf1qHNyVQNiRlLmmg2RvnVLk ehEzKqZyrg/7xQ4854xrdgR4i6/26IxswvSB5ME0k3GhG1zM2UyyIqYoy3gCuCmpRfNQ ipuNUx+crIWu/DIJcvEYA8p6HGeYHRs1b4uMhJn2/GyDYA0awFxUqSHJ9BszhRakAD8Z DUpb4lZCymcpi2prleQ3HYJjmOdLlImX2hP+/1up4Iwcp/iMaTIbnKnsp8N49M1zDa+E LU62+q5iL2k8JceEbOsFNCctke4xonU1sdAzBFck200VlxP0LK7y4gn7e3S8oFWCRZOT G3hQ== MIME-Version: 1.0 X-Received: by 10.180.106.103 with SMTP id gt7mr107452725wib.59.1425936878961; Mon, 09 Mar 2015 14:34:38 -0700 (PDT) Received: by 10.27.179.212 with HTTP; Mon, 9 Mar 2015 14:34:38 -0700 (PDT) In-Reply-To: <20150309213241.21308.78039.idtracker@ietfa.amsl.com> References: <20150309213241.21308.78039.idtracker@ietfa.amsl.com> Date: Mon, 9 Mar 2015 14:34:38 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=f46d04428f44248a2a0510e1cde1 Archived-At: Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc7001bis-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 21:34:43 -0000 --f46d04428f44248a2a0510e1cde1 Content-Type: text/plain; charset=UTF-8 On Mon, Mar 9, 2015 at 2:32 PM, 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 : Message Header Field for Indicating Message > Authentication Status > Author : Murray S. Kucherawy > Filename : draft-ietf-appsawg-rfc7001bis-03.txt > Pages : 46 > Date : 2015-03-09 > > 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 to make sorting and filtering decisions. > This is an attempt to address the concerns expressed, especially by John Levine and Tom Petch. John has seen it and says it resolves his concerns. Everyone, and Tom in particular, do you agree that this is how it should look? -MSK --f46d04428f44248a2a0510e1cde1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Mar 9, 2015 at 2:32 PM, <internet-drafts@= ietf.org> wrote:

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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Message Header Field for Indicating Message Authentication Status
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Murr= ay S. Kucherawy
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-appsawg-rfc7001bis-03.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 46
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2015-03-09

Abstract:
=C2=A0 =C2=A0This document specifies a message header field called Authenti= cation-
=C2=A0 =C2=A0Results for use with electronic mail messages to indicate the = results
=C2=A0 =C2=A0of message authentication efforts.=C2=A0 Any receiver-side sof= tware, such
=C2=A0 =C2=A0as mail filters or Mail User Agents (MUAs), can use this heade= r field
=C2=A0 =C2=A0to relay that information in a convenient and meaningful way t= o users
=C2=A0 =C2=A0or to make sorting and filtering decisions.

This is an attempt to address the concerns expressed, esp= ecially by John Levine and Tom Petch.=C2=A0 John has seen it and says it re= solves his concerns.=C2=A0 Everyone, and Tom in particular, do you agree th= at this is how it should look?

-MSK
--f46d04428f44248a2a0510e1cde1-- From nobody Mon Mar 9 14:44:25 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 868771ABD3D; Mon, 9 Mar 2015 14:44:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AIJgqHd1LW6O; Mon, 9 Mar 2015 14:44:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CCC281ACD97; Mon, 9 Mar 2015 14:44:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150309214413.26044.91565.idtracker@ietfa.amsl.com> Date: Mon, 09 Mar 2015 14:44:13 -0700 Archived-At: Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-multipart-form-data-08.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 21:44:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : Returning Values from Forms: multipart/form-data Author : Larry Masinter Filename : draft-ietf-appsawg-multipart-form-data-08.txt Pages : 13 Date : 2015-03-09 Abstract: This specification (re)defines the multipart/form-data Internet Media Type, which can be used by a wide variety of applications and transported by a wide variety of protocols as a way of returning a set of values as the result of a user filling out a form. It replaces RFC 2388. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-multipart-form-data/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-multipart-form-data-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-multipart-form-data-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 9 14:44:28 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 372D81ACD32; Mon, 9 Mar 2015 14:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2_pY1c6gEOcI; Mon, 9 Mar 2015 14:44:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DB0DA1ACD9B; Mon, 9 Mar 2015 14:44:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150309214413.26044.6872.idtracker@ietfa.amsl.com> Date: Mon, 09 Mar 2015 14:44:13 -0700 Archived-At: Subject: [apps-discuss] New Version Notification - draft-ietf-appsawg-multipart-form-data-08.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 21:44:22 -0000 A new version (-08) has been submitted for draft-ietf-appsawg-multipart-form-data: http://www.ietf.org/internet-drafts/draft-ietf-appsawg-multipart-form-data-08.txt Sub state has been changed to AD Followup from Revised ID Needed The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-multipart-form-data/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-multipart-form-data-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Mon Mar 9 14:44:30 2015 Return-Path: X-Original-To: expand-draft-ietf-appsawg-multipart-form-data.all@virtual.ietf.org Delivered-To: apps-discuss@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 634431A90BE; Mon, 9 Mar 2015 14:44:22 -0700 (PDT) X-Original-To: xfilter-draft-ietf-appsawg-multipart-form-data.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-appsawg-multipart-form-data.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 372D81ACD32; Mon, 9 Mar 2015 14:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2_pY1c6gEOcI; Mon, 9 Mar 2015 14:44:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DB0DA1ACD9B; Mon, 9 Mar 2015 14:44:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150309214413.26044.6872.idtracker@ietfa.amsl.com> Date: Mon, 09 Mar 2015 14:44:13 -0700 Archived-At: Subject: [apps-discuss] New Version Notification - draft-ietf-appsawg-multipart-form-data-08.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 21:44:22 -0000 A new version (-08) has been submitted for draft-ietf-appsawg-multipart-form-data: http://www.ietf.org/internet-drafts/draft-ietf-appsawg-multipart-form-data-08.txt Sub state has been changed to AD Followup from Revised ID Needed The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-multipart-form-data/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-multipart-form-data-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Mon Mar 9 15:00:12 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E93C1ACD97 for ; Mon, 9 Mar 2015 15:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KwZDNK1A-tDr for ; Mon, 9 Mar 2015 15:00:05 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0076.outbound.protection.outlook.com [207.46.100.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3D931ACDA4 for ; Mon, 9 Mar 2015 15:00:01 -0700 (PDT) Received: from DM2PR0201MB0960.namprd02.prod.outlook.com (25.160.216.28) by DM2PR0201MB0958.namprd02.prod.outlook.com (25.160.216.26) with Microsoft SMTP Server (TLS) id 15.1.99.14; Mon, 9 Mar 2015 22:00:00 +0000 Received: from DM2PR0201MB0960.namprd02.prod.outlook.com ([25.160.216.28]) by DM2PR0201MB0960.namprd02.prod.outlook.com ([25.160.216.28]) with mapi id 15.01.0099.004; Mon, 9 Mar 2015 22:00:00 +0000 From: Larry Masinter To: Barry Leiba Thread-Topic: AD review of draft-ietf-appsawg-multipart-form-data-07 Thread-Index: AQHQQhoDDA1Ieg2rFka3OQu0xFtTtZ0UbzcA Date: Mon, 9 Mar 2015 21:59:59 +0000 Message-ID: <7514DD37-8BAE-4EDA-BDCE-649D518C435E@adobe.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/15.8.0.150303 x-originating-ip: [50.184.24.49] authentication-results: computer.org; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0201MB0958; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:0; SFV:NSPM; SFS:(10009020)(6009001)(51704005)(77156002)(82746002)(83506001)(40100003)(19580395003)(87936001)(83716003)(2656002)(86362001)(92566002)(46102003)(62966003)(15975445007)(66066001)(102836002)(110136001)(36756003)(106116001)(33656002)(76176999)(54356999)(2950100001)(2900100001)(230783001)(122556002)(50986999)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR0201MB0958; H:DM2PR0201MB0960.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5001009); SRVR:DM2PR0201MB0958; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0201MB0958; x-forefront-prvs: 05102978A2 Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: adobe.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2015 21:59:59.7033 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0201MB0958 Archived-At: Cc: Apps Discuss Subject: Re: [apps-discuss] AD review of draft-ietf-appsawg-multipart-form-data-07 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 22:00:08 -0000 SSB3ZW50IGFoZWFkIGFuZCBkaWQgYSBuZXcgdmVyc2lvbiBiZWZvcmUgdGhlIGN1dG9mZg0KDQoN Cg0KDQo+TGFycnksDQo+SSdtIHNvcnJ5IGZvciB0aGUgaHVnZSBkZWxheSBpbiBoYW5kbGluZyB0 aGlzLiAgSSd2ZSBnaXZlbiB0aGUNCj5kb2N1bWVudCBhIHJldmlldywgYW5kIGhlcmUgYXJlIG15 IGNvbW1lbnRzIC0tIG1vc3QgYXJlIGVkaXRvcmlhbCwgYnV0DQo+dGhlcmUgYXJlIGEgZmV3IHRo YXQgSSB0aGluayB3ZSBzaG91bGQgc29ydCBvdXQgYmVmb3JlIEkgcmVxdWVzdCBsYXN0DQo+Y2Fs bA0KDQpJ4oCZbGwgYmUgYXQgSUVURiBEYWxsYXMgdG8gcmV2aWV3IGNoYW5nZXMuDQoNCj4tLQ0K PlNlY3Rpb24gMSBzaG91bGQgaGF2ZSBhIG5vdGUgZm9yIHRoZSBSRkMgRWRpdG9yIHRvIHJlbW92 ZSBpdCBhdA0KPnB1YmxpY2F0aW9uLiAgQmV0dGVyLCBqdXN0IHJlbW92ZSBpdCBub3csIHllcz8N Cg0KSSB0b29rIHRoaXMgb3V0LCBidXQgYXNJIHRoaW5rIEkgd2FudCB0byBwdXQgaXQgYmFjayBp biBiZWZvcmUNCkxhc3QgQ2FsbCwgYmVjYXVzZSBJIHdhbnQgcGVvcGxlIHRvIGxvb2sgYXQgdGhl IHZlcnkgaW5jb21wbGV0ZQ0KdGVzdCBjYXNlcyBkdXJpbmcgbGFzdCBjYWxsLg0KDQpzdGlsbCB3 YW50IHRvIHBvaW50IHBlb3BsZSB0byBodHRwczovL2dpdGh1Yi5jb20vbWFzaW50ZXIvbXVsdGlw YXJ0LWZvcm0tZGF0YSANCg0KPg0KPi0tIFNlY3Rpb24gMyAtLQ0KPg0KPllvdSBzaG91bGQgaW5j bHVkZSBhIHJlZmVyZW5jZSB0byB0aGUgZGVmaW5pdGlvbiBvZiBVUkwgZW5jb2RpbmcgLS0NCj5p dCdzIGNhbGxlZCAicGVyY2VudC1lbmNvZGluZyIgaW4gUkZDIDM5ODYuDQoNCkkgcmVuYW1lZCBp dCBhbmQgYWRkZWQgYSByZWZlcmVuY2UNCg0KPg0KPkFsc28sIHRoYXQgZW5jb2RpbmcgaXNuJ3Qg dXNlZCBqdXN0IGZvciBub24tQVNDSUkgY2hhcmFjdGVycywgYnV0IGZvcg0KPmFueSBjaGFyYWN0 ZXJzIG91dHNpZGUgdGhlIHNldCB0aGF0IGNhbiBiZSBsZWdhbGx5IGluY2x1ZGVkIHdpdGggQVND SUkNCj5lbmNvZGluZy4gIFlvdSBzaG91bGQgcmVwaHJhc2UgdGhpcy4NCg0KSSB0cmllZC4NCg0K Pg0KPkFsc28gYWxzbywgcGVyY2VudC1lbmNvZGluZyBpcyBub3QgY2FzZS1zZW5zaXRpdmUgKHRo ZSBjaGFyYWN0ZXJzDQo+ZG9uJ3QgaGF2ZSB0byBiZSBsb3dlciBjYXNlKS4gIElmIHRoaXMgZGlm ZmVycyBmcm9tIHdoYXQncyBkZWZpbmVkDQo+ZWxzZXdoZXJlLCBpdCBzaG91bGQgZXhwbGljaXRs eSBzYXkgc28sIGFuZCB3aHkuDQoNCkkgZ290IHJpZCBvZiB0aGUg4oCYbG93ZXIgY2FzZeKAmSBh bmQgcmV3b3JkZWQuDQoNCj4NCj4tLSBTZWN0aW9uIDUuMSAtLQ0KPg0KPiAgIEVhY2ggZmllbGQn cyBmb3JtIGRhdGEgb2YgdGhlIGZvcm0gaXMgc2VudCwgaW4NCj4gICB0aGUgb3JkZXIgZGVmaW5l ZCBieSB0aGUgc2VuZGluZyBhcHBsaWNhdGlvbiBhbmQgZm9ybSwgYXMgYSBwYXJ0IG9mDQo+ICAg dGhlIG11bHRpcGFydCBzdHJlYW0uDQo+DQo+Q2FuIHlvdSByZS13b3JkIHRoaXMgYW5kIGV4cGxh aW4gaXQgYmV0dGVyPyAgSSBmaW5kIGl0IHVuY2xlYXIgaW4gYQ0KPmZldyB3YXlzLCB0aGUgbW9z dCBpbXBvcnRhbnQgb2Ygd2hpY2ggaXMgdGhhdCBJIGRvbid0IGtub3cgd2hhdCAicGFydA0KPm9m IHRoZSBtdWx0aXBhcnQgc3RyZWFtIiBtZWFucy4NCg0KSSByZW1vdmVkIHRoZSBzZW50ZW5jZSBh cyBpdCBpcyBleHBsYWluZWQgZWxzZXdoZXJlIGFuZCBub3QNCnJlbGV2YW50IHRvIHRoZSBzZWN0 aW9uLg0KDQo+ICAgVGhlIGJvdW5kYXJ5IGlzIHN1cHBsaWVkIGFzIGEgImJvdW5kYXJ5Ig0KPiAg IHBhcmFtZXRlciB0byB0aGUgIm11bHRpcGFydC9mb3JtLWRhdGEgdHlwZSIuDQo+DQo+VGhlIGNs b3NpbmcgcXVvdGUgaXMgbWlzcGxhY2VkLg0KDQpmaXhlZA0KDQo+DQo+LS0gU2VjdGlvbiA1LjIg LS0NCj4NCj4gICB3aXRoIHRoZSBib2R5IG9mIHRoZSBwYXJ0IGNvcnJlc3BvbmRpbmcgdG8gdGhl IGZvcm0gZGF0YSBvZiB0aGUNCj4gICAidXNlciIgZmllbGQuDQo+DQo+IkNvcnJlc3BvbmRpbmcg dG8iPyAgSSB0aGluayAiY29udGFpbmluZyIgaXMgdGhlIHJpZ2h0IHdvcmQgaGVyZS4NCg0KZml4 ZWQNCg0KPg0KPi0tIFNlY3Rpb24gNS4zIC0tDQo+DQo+ICAgRm9yIGZvcm0gZGF0YSB0aGF0IHJl cHJlc2VudHMgdGhlIGNvbnRlbnQgb2YgYSBmaWxlLCBhIG5hbWUgZm9yIHRoZQ0KPiAgIGZpbGUg U0hPVUxEIGJlIHN1cHBsaWVkIGFzIHdlbGwNCj4NCj5XaHkgIlNIT1VMRCI/ICBXaHkgZG9lcyB0 aGlzIGFmZmVjdCBpbnRlcm9wZXJhYmlsaXR5LCBpZiB0aGUgb3RoZXIgZW5kDQo+Y2FuJ3QgZmln dXJlIG91dCB3aGV0aGVyIHlvdSBqdXN0IGRpZG4ndCBmZWVsIGxpa2UgaW5jbHVkaW5nIHRoZSBm aWxlDQo+bmFtZSwgb3IgdGhhdCB0aGUgZmlsZSBuYW1lIGlzIG1lYW5pbmdsZXNzIG9yIHByaXZh dGU/DQoNCkkgdHJpZWQgcmV3cml0aW5nLCBhbmQgYWRkZWQgc29tZSBhZGRpdGlvbmFsIG1hdGVy aWFsIHJlZmVyZW5jaW5nDQpDb250ZW50LURpc3Bvc2l0aW9uIGZpbGVuYW1lIGRpc2N1c3Npb24g Zm9yIE1VQXMuDQoNCj4NCj4gICBOT1RFOiB0aGUgbWV0aG9kIGluIFtSRkM1OTg3XSBmb3IgdXNp bmcgYSAiZmlsZW5hbWUqIiBwYXJhbXRlciBvZiB0aGUNCj4gICAiQ29udGVudC1EaXNwb3NpdGlv biIgaGVhZGVyIFNIT1VMRCBOT1QgYmUgdXNlZC4NCj4NCj5XaGF0IG1ldGhvZD8gIFJGQyA1OTg3 IGRvZXMgbm90IGNvbnRhaW4gYW55IG9mIHRoZSBzdHJpbmdzICJmaWxlbmFtZSIsDQo+ImNvbnRl bnQtIiwgbm9yICJkaXNwb3NpdGlvbiIuDQo+DQo+QWguICBQZXJoYXBzIHlvdSBtZWFuIHRoaXM/ Og0KPg0KPk5FVw0KPiAgIFRoZSBlbmNvZGluZyBtZXRob2QgZGVzY3JpYmVkIGluIFtSRkM1OTg3 XSwgd2hpY2ggd291bGQgYWRkIGENCj4gICAiZmlsZW5hbWUqIiBwYXJhbXRlciB0byB0aGUgIkNv bnRlbnQtRGlzcG9zaXRpb24iIGhlYWRlciwgU0hPVUxEDQo+ICAgTk9UIGJlIHVzZWQuDQo+RU5E DQoNClllcw0KDQo+QWdhaW4sIHdoeSBpcyB0aGlzIGEgMjExOSAiU0hPVUxEIE5PVCI/ICBXaGF0 IGhhcHBlbnMgaWYgSSBkbyB1c2UgaXQ/DQo+V2h5IG1pZ2h0IEkgZGVjaWRlIHVzZSBpdCwgZGVz cGl0ZSB0aGUgIlNIT1VMRCBOT1QiIGhlcmU/DQoNClRoZSBzZWN0aW9uIG5vdyB0cmllcyB0byBl eHBsYWluDQoNCj4NCj4tLSBTZWN0aW9uIDUuNCAtLQ0KPg0KPiAgIFtSRkMyMzg4XSBzdWdnZXN0 ZWQgdGhhdCBtdWx0aXBsZSBmaWxlcyBmb3IgYSBzaW5nbGUgZm9ybSBmaWVsZCBiZQ0KPiAgIHRy YW5zbWl0dGVkIHVzaW5nIGEgbmVzdGVkIG11bHRpcGFydC9taXhlZCBwYXJ0Lg0KPg0KPiAgIFRv IG1hdGNoIHdpZGVseSBkZXBsb3llZCBpbXBsZW1lbnRhdGlvbnMsIG11bHRpcGxlIGZpbGVzIFNI T1VMRCBiZQ0KPiAgIHNlbnQgYnkgc3VwcGx5aW5nIGVhY2ggZmlsZSBpbiBhIHNlcGFyYXRlIHBh cnQsIGJ1dCBhbGwgd2l0aCB0aGUgc2FtZQ0KPiAgICJuYW1lIiBwYXJhbWV0ZXIuDQo+DQo+SXMg aXQgaW50ZW5kZWQgdGhhdCB0aGUgbWVjaGFuaXNtIGluIHRoZSBmaXJzdCBwYXJhZ3JhcGggYmUN Cj5kZXByZWNhdGVkPyAgVGhhdCdzIHdoYXQgaXQgbG9va3MgbGlrZSBmcm9tIHdoYXQgeW91IHNh eSBpbiB0aGlzDQo+c2VjdGlvbi4gIFNvIHdoeSBub3Qgc2F5IHRoYXQsIGFuZCB3aHkgaXMgdGhl IFNIT1VMRCBub3QgYSBNVVNUICh5b3UNCj5hbHJlYWR5IGFkdmlzZSByZWNlaXZlcnMgdG8gdG9s ZXJhdGUgdGhlIGRlcHJlY2F0ZWQgbWVjaGFuaXNtLCBzbyB0aGF0DQo+c2hvdWxkIGJlIGZpbmUp PyAgVGhhdCB3YXksIHlvdSdkIGJlIHNheWluZyAiTVVTVCBnZW5lcmF0ZSB0aGUgbmV3DQo+d2F5 OyBTSE9VTEQgYWNjZXB0IHRoZSBvbGQgd2F5IG9uIHJlY2VpcHQuIg0KDQpJIGNoYW5nZWQgdGhl IFNIT1VMRCB0byBhIE1VU1QNCg0KPg0KPi0tIFNlY3Rpb24gNi4xIC0tDQo+DQo+ICAgV2hpbGUg W1JGQzIzODhdDQo+ICAgc3VnZ2VzdGVkIHRoYXQgbm9uLUFTQ0lJIGZpZWxkIG5hbWVzIHNob3Vs ZCBiZSBlbmNvZGVkIGFjY29yZGluZyB0bw0KPiAgIHRoZSBtZXRob2QgaW4gW1JGQzIwNDddIGlm IHRoZXkgY29udGFpbiBjaGFyYWN0ZXJzIG91dHNpZGUgb2YgVVMtDQo+ICAgQVNDSUksIHRoaXMg cHJhY3RpY2UgZG9lc24ndCBzZWVtIHRvIGhhdmUgYmVlbiBmb2xsb3dlZCB3aWRlbHkuDQo+DQo+ VGhlcmUncyByZWR1bmRhbmN5IGluIHRoZXJlOyBJIHN1Z2dlc3QgcmVtb3ZpbmcgIiBpZiB0aGV5 IGNvbnRhaW4NCj5jaGFyYWN0ZXJzIG91dHNpZGUgb2YgVVMtDQo+ICAgQVNDSUkiLCBhcyB5b3Ug YWxyZWFkeSBzYXkgIm5vbi1BU0NJSSIuDQoNCmZpeGVkDQoNCj4NCj4tLSBTZWN0aW9uIDYuMS4x IC0tDQo+DQo+ICAgRm9yIGJyb2FkZXN0IGludGVyb3BlcmFiaWxpdHkgd2l0aCBleGlzdGluZyBk ZXBsb3llZCBzb2Z0d2FyZSwgdGhvc2UNCj4gICBjcmVhdGluZyBmb3JtcyBTSE9VTEQgYXZvaWQg bm9uLUFTQ0lJIGZpZWxkIG5hbWVzLiAgVGhpcyBzaG91bGQgbm90DQo+ICAgYmUgYSBidXJkZW4s IGJlY2F1c2UgaW4gZ2VuZXJhbCB0aGUgZmllbGQgbmFtZXMgYXJlIG5vdCB2aXNpYmxlIHRvDQo+ ICAgdXNlcnMuDQo+DQo+SSB0aGluayBpdCdzIHdvcnRoIGFkZGluZyBhIHJlbWluZGVyIHRoYXQg dGhlIGZpZWxkIG5hbWVzIGluIHRoZQ0KPnVuZGVybHlpbmcgZm9ybSBkb24ndCBoYXZlIHRvIG1h dGNoIHRoZSBuYW1lcyB0aGUgdXNlciBtaWdodCBzZWUgb24NCj50aGUgc2NyZWVuLiAgVGhhdCB3 b3VsZCBjbGFyaWZ5IHRoZSAibm90IHZpc2libGUgdG8gdXNlcnMiIHBhcnQuDQoNCmRvbmUsIHBs ZWFzZSByZXZpZXcNCg0KPi0tIFNlY3Rpb24gNi4yIC0tDQo+DQo+ICAgRm9ybSBwcm9jZXNzb3Jz IGdpdmVuIGZvcm1zIHdpdGggYSB3ZWxsLWRlZmluZWQgb3JkZXJpbmcgU0hPVUxEIHNlbmQNCj4g ICBiYWNrIHJlc3VsdHMgaW4gdGhlIG9yZGVyIHJlY2VpdmVkIGFuZCBwcmVzZXJ2ZSBkdXBsaWNh dGUgZmllbGQNCj4gICBuYW1lcywgaW4gb3JkZXIuICBJbnRlcm1lZGlhcmllcyBNVVNUIE5PVCBy ZW9yZGVyIHRoZSByZXN1bHRzLiAgKE5vdGUNCj4gICB0aGF0IHRoZXJlIGFyZSBzb21lIGZvcm1z IHdoaWNoIGRvIG5vdCBkZWZpbmUgYSBuYXR1cmFsIG9yZGVyIG9mDQo+ICAgYXBwZWFyYW5jZS4p DQo+DQo+V2h5IGlzIHRoaXMgU0hPVUxELCBhbmQgbm90IE1VU1Q/ICBXaGF0IGRvIEkgbmVlZCB0 byB0YWtlIGludG8gYWNjb3VudA0KPndoZW4gSSdtIGRlY2lkaW5nIHdoZXRoZXIgdG8gY29tcGx5 IHdpdGggdGhpcyBTSE9VTEQgb3Igbm90PyAgV2h5DQo+bWlnaHQgSSB3YW50IG9yIG5lZWQgbm90 IHRvIGRvIGl0Pw0KDQpJIHJld3JvdGUsIGhvcGVmdWxseSB0byBtYWtlIGl0IGNsZWFyZXIsIHdo eSDigJh3ZWxsLWRlZmluZWQgb3JkZXJpbmfigJkNCmlzbuKAmXQgd2VsbC1kZWZpbmVkLg0KDQo+ DQo+LS0gU2VjdGlvbiA4IC0tDQo+Tm93IHRoYXQgbWFueSAoYWxsIG1ham9yKSBicm93c2VycyBo YXZlIGF1dG9maWxsIG9wdGlvbnMsIGl0IHN0cmlrZXMNCj5tZSB0aGF0IGl0IG1pZ2h0IGJlIHBv c3NpYmxlIGZvciBhIHNlcnZlciB0byBpbmNsdWRlIGluIGFuIG90aGVyd2lzZQ0KPnVucmVtYXJr YWJsZSBmb3JtIHNvbWUgZmllbGRzIHRoYXQgYXJlIHByZXNlbnRlZCBpbiBhIHdheSB0aGF0IGEg dXNlcg0KPndvbid0IG5vdGljZSAod2hpdGUgb24gd2hpdGUsIHZlcnkgdGlueSwgb3IgdGhlIGxp a2UpIGFuZCB0aGF0IGhhdmUNCj5uYW1lcyB0aGF0IHRoZSBicm93c2VyIHdpbGwgZmlsbCBpbmZv cm1hdGlvbiBpbiB3aGVuIHRoZSB1c2VyDQo+YXV0b2ZpbGxzIHRoZSBvdGhlciBmaWVsZHMgYW5k IGRvZXNuJ3Qgbm90aWNlIHRoYXQgdGhlc2UgYXJlIGJlaW5nDQo+YXV0b2ZpbGxlZCBhcyB3ZWxs LiAgVGhhdCBjb3VsZCBleHBvc2UgaW5mb3JtYXRpb24gdGhhdCB0aGUgdXNlciBpc24ndA0KPmlu dGVuZGluZyB0byBzZW5kIHRvIHRoaXMgc2l0ZS4NCj4NCj5UaGlzIGlzIGEgVUkgaXNzdWUsIG5v dCBkaXJlY3RseSBhbiBpc3N1ZSB3aXRoIHRoZSBwcm90b2NvbCBoZXJlLi4uDQo+YnV0IHRoaXMg aXMgdGhlIG9ubHkgcGxhY2UgdG8gbm90ZSB0aGUgZXhwb3N1cmUgYW5kIHdhcm4gaW1wbGVtZW50 b3JzDQo+dG8gYmUgYXdhcmUgb2YgaXQuICBNaWdodCBpdCBiZSB3b3J0aCBwdXR0aW5nIHNvbWV0 aGluZyBpbiBoZXJlPw0KDQpJIG5vdGVkIHRoaXMgaW4gdGhlIOKAnEFsbCBmb3JtIHByb2Nlc3Np bmcgc29mdHdhcmXigJ0gc2luY2UgdGhlIGlzc3VlDQppcyBhYm91dCBmb3JtcyBhbmQgbm90IHRo aXMgcGFydGljdWxhciBlbmNvZGluZy4NCg0KPg0KPi0tIFNlY3Rpb24gOSAtLQ0KPldoYXQgaXMg dGhpcyBtZWFudCB0byBiZT8gIEl0J3Mgbm90IGluIHRoZSBJQU5BIENvbnNpZGVyYXRpb25zDQo+ c2VjdGlvbi4gIEl0J3Mgbm90IGEgY29tcGxldGUgdGVtcGxhdGUuICBJcyBpdCBtZWFudCB0byBi ZSBhbiB1cGRhdGUNCj50byB0aGUgb3JpZ2luYWwgdGVtcGxhdGU/ICBPciB3aGF0Pw0KPg0KDQpJ IG1hZGUgaXQgY2xlYXIgaXQgd2FzIGEgTUlNRSB0ZW1wbGF0ZSBhbmQgYWRkZWQgdGhlIG1pc3Np bmcgcGFydHMuDQoNCg== From nobody Mon Mar 9 15:31:48 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE671A0196 for ; Mon, 9 Mar 2015 15:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UJ4TOII1lNOe for ; Mon, 9 Mar 2015 15:31:45 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E2A61A017D for ; Mon, 9 Mar 2015 15:31:45 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id DC86CC4016D for ; Mon, 9 Mar 2015 17:31:43 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1425940303; bh=oqdc60TIXyTOcD+wuPOPPv7I6VdYuyXZ212nsV+7m6I=; h=From:To:Subject:Date:In-Reply-To:References:From; b=t+LMjoMteekf2u7ei9nw+JNotYGjwKLioTo05uHh2vSliznzQb5i/40Ieo2EAOewX ZYPygB0RAnaItetkgJLQKlIjH7k+z55bMNcxMEXB+VvLqMsvlOwMOiD3PXpOrpQp+3 TargTv0NLztKVBRFgFp69bBZHIZ6savE6bV9zPjU= From: Scott Kitterman To: apps-discuss@ietf.org Date: Mon, 09 Mar 2015 18:31:39 -0400 Message-ID: <1924417.J0j5dftIzS@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-46-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <20150309213241.21308.78039.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc7001bis-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 22:31:47 -0000 On Monday, March 09, 2015 02:34:38 PM Murray S. Kucherawy wrote: > On Mon, Mar 9, 2015 at 2:32 PM, 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 : Message Header Field for Indicating Message > > > > Authentication Status > > > > Author : Murray S. Kucherawy > > Filename : draft-ietf-appsawg-rfc7001bis-03.txt > > Pages : 46 > > Date : 2015-03-09 > > > > 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 to make sorting and filtering decisions. > > This is an attempt to address the concerns expressed, especially by John > Levine and Tom Petch. John has seen it and says it resolves his concerns. > Everyone, and Tom in particular, do you agree that this is how it should > look? Should RFC 6008 - https://tools.ietf.org/html/rfc6008 - also be listed in 2.7.5? Scott K From nobody Mon Mar 9 15:35:56 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD081ACDF6; Mon, 9 Mar 2015 15:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NmaIPBwvN8Np; Mon, 9 Mar 2015 15:35:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AFA551ACDE4; Mon, 9 Mar 2015 15:35:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150309223536.8246.40072.idtracker@ietfa.amsl.com> Date: Mon, 09 Mar 2015 15:35:36 -0700 Archived-At: Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-text-markdown-use-cases-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 22:35:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : text/markdown Use Cases Author : Sean Leonard Filename : draft-ietf-appsawg-text-markdown-use-cases-01.txt Pages : 25 Date : 2015-03-09 Abstract: This document elaborates upon the text/markdown media type for use with Markdown, a family of plain text formatting syntaxes that optionally can be converted to formal markup languages such as HTML. Background information, local storage strategies, and additional syntax registrations are supplied. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-text-markdown-use-cases/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-text-markdown-use-cases-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-text-markdown-use-cases-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 9 15:51:02 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 212F01ACDCB for ; Mon, 9 Mar 2015 15:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 085FXgWJpjZX for ; Mon, 9 Mar 2015 15:50:58 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFBD41A8947 for ; Mon, 9 Mar 2015 15:50:58 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id EC711C4035D for ; Mon, 9 Mar 2015 17:50:57 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1425941458; bh=HhQ73MbJMHJ20hKdubmBiqkog24STddQGr4fzM1c/pI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=dtp7syq5cXseE3OESgRp1x6MsrWnTVR50o8BOByxU21GSOmgiS7SDq06RJcZ4Hw0x JKHy539M8xppDhPM3IEiBOU0cAKo67vOH+eDWJH1YD7wjvPQ+i7ldjLKZpYrtczg87 GYnMudP4lWIlIgarPjW7AsyJU1qv76G/r69gx+5A= From: Scott Kitterman To: apps-discuss@ietf.org Date: Mon, 09 Mar 2015 18:50:57 -0400 Message-ID: <2371338.ajW3kri7gd@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-46-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <20150309213241.21308.78039.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc7001bis-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 22:51:00 -0000 On Monday, March 09, 2015 02:34:38 PM Murray S. Kucherawy wrote: > On Mon, Mar 9, 2015 at 2:32 PM, 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 : Message Header Field for Indicating Message > > > > Authentication Status > > > > Author : Murray S. Kucherawy > > Filename : draft-ietf-appsawg-rfc7001bis-03.txt > > Pages : 46 > > Date : 2015-03-09 > > > > 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 to make sorting and filtering decisions. > > This is an attempt to address the concerns expressed, especially by John > Levine and Tom Petch. John has seen it and says it resolves his concerns. > Everyone, and Tom in particular, do you agree that this is how it should > look? > > -MSK I've either missed or forgotten the discussion that led to the proposal to change property for the "auth" Email Authentication Method to mailfrom. SMTP auth doesn't authenticate the mail from, so I'm confused about the purpose of this change. Scott K From nobody Mon Mar 9 16:02:17 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 927D11A8892 for ; Mon, 9 Mar 2015 16:02:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KHQU7MkXrlvk for ; Mon, 9 Mar 2015 16:02:12 -0700 (PDT) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA1141A88F9 for ; Mon, 9 Mar 2015 16:02:00 -0700 (PDT) Received: by wggx12 with SMTP id x12so18100098wgg.10 for ; Mon, 09 Mar 2015 16:01:59 -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=nhUtHWJdoZ9kKEmpPKt8BEqkBnhdRJaQlcj0VSHjAFs=; b=b25EnGfmSN4MVSrvJUjv5bC1loCyyJO8+sUattgHEMjjUzSmp9uVavNiqpnUgTMQ4I 7f++eVD6YEVLG+glustizK2/VYkvDIRIjRfZADuHgMM3Vp1uHQW20INNCwzxT9poTapJ myXROt+4AtHU4I2dZ8zKQVKonqcHqgjSHznWrCdiO5ZUiDPsSfMYlSc8hn0GKqcEPcC6 bqFDn/mfzh7lKv6i6AylW2+uk3Foi26yfiYelw9emmCW3Ocf0nW7zPAii2WYK8rmADgb Eo1HS/MIGgjM3frxu7ynsiPeDpVhJ/CTpI/UkZUhTTj0jkbE3B4liTCTUuv+mRkeypb0 xBlA== MIME-Version: 1.0 X-Received: by 10.194.185.68 with SMTP id fa4mr61064717wjc.111.1425942119475; Mon, 09 Mar 2015 16:01:59 -0700 (PDT) Received: by 10.27.179.212 with HTTP; Mon, 9 Mar 2015 16:01:59 -0700 (PDT) In-Reply-To: <2371338.ajW3kri7gd@kitterma-e6430> References: <20150309213241.21308.78039.idtracker@ietfa.amsl.com> <2371338.ajW3kri7gd@kitterma-e6430> Date: Mon, 9 Mar 2015 16:01:59 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=047d7bacb11e806f250510e30558 Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc7001bis-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 23:02:14 -0000 --047d7bacb11e806f250510e30558 Content-Type: text/plain; charset=UTF-8 On Mon, Mar 9, 2015 at 3:50 PM, Scott Kitterman wrote: > I've either missed or forgotten the discussion that led to the proposal to > change property for the "auth" Email Authentication Method to mailfrom. > SMTP > auth doesn't authenticate the mail from, so I'm confused about the purpose > of > this change. > It's a bit of a mistake, showing an incomplete review of SMTP AUTH on my part. I've never implemented SMTP AUTH, so I'm happy to yield to someone who has, but here's what I ran into: As I read RFC4954, SMTP AUTH can produce an authenticated author identifier via either the MAIL FROM parameter or through the AUTH command itself. Shouldn't A-R be able to report either or both? -MSK --047d7bacb11e806f250510e30558 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Mar 9, 2015 at 3:50 PM, Scott Kitterman <scott= @kitterman.com> wrote:
I've either missed or= forgotten the discussion that led to the proposal to
change property for the "auth" Email Authentication Method to mai= lfrom.=C2=A0 SMTP
auth doesn't authenticate the mail from, so I'm confused about the = purpose of
this change.

It's a bit of a mistak= e, showing an incomplete review of SMTP AUTH on my part.=C2=A0 I've nev= er implemented SMTP AUTH, so I'm happy to yield to someone who has, but= here's what I ran into:

As I read RFC4954, SMTP AUTH can produc= e an authenticated author identifier via either the MAIL FROM parameter or = through the AUTH command itself.=C2=A0 Shouldn't A-R be able to report = either or both?

-MSK
--047d7bacb11e806f250510e30558-- From nobody Mon Mar 9 16:03:34 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF4941AC3F4 for ; Mon, 9 Mar 2015 16:03:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mwFss4c8LyIS for ; Mon, 9 Mar 2015 16:03:29 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9975F1A88A6 for ; Mon, 9 Mar 2015 16:03:27 -0700 (PDT) Received: by widex7 with SMTP id ex7so24888395wid.3 for ; Mon, 09 Mar 2015 16:03: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=AhOqdIHUFyHCqUN9tyUF9XY6blgnyqDlIZ8erHoudyk=; b=g38+YjjNdcTiT3lNFhUDXeUcRTRRv4AiRJ3QFSA7w2E0Y04CrLkk2oTEbScQFt955G rGt2SJgGlrjxF3FlghG5rHp5snrRjAFvJQzdY5UEqOKSAKFxrp3rGmfzfsQlTKIfRJXk xDx7+/mI2BQ8vr8JNSQzp6i/4F1JgMlQ/43ycAK9VmUu/s9gvDbyWc68DxYGzUH/b8WB PHPV6OIqfEs57p9b5s1DT2Bkb18Wh3+A5LQnn0PVYTd47AMLAo64lzw1/Yd0JX2toZv4 ywlNqhWIWjw+0dvr0TmkogqeAgI5eZFy5j+vSXAkJF5Ap4fEHTKmRSkEdfI97t2M1Ayj PFMg== MIME-Version: 1.0 X-Received: by 10.180.106.103 with SMTP id gt7mr107924342wib.59.1425942206498; Mon, 09 Mar 2015 16:03:26 -0700 (PDT) Received: by 10.27.179.212 with HTTP; Mon, 9 Mar 2015 16:03:26 -0700 (PDT) In-Reply-To: <1924417.J0j5dftIzS@kitterma-e6430> References: <20150309213241.21308.78039.idtracker@ietfa.amsl.com> <1924417.J0j5dftIzS@kitterma-e6430> Date: Mon, 9 Mar 2015 16:03:26 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=f46d04428f44b04db70510e30a21 Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc7001bis-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 23:03:30 -0000 --f46d04428f44b04db70510e30a21 Content-Type: text/plain; charset=UTF-8 On Mon, Mar 9, 2015 at 3:31 PM, Scott Kitterman wrote: > > Should RFC 6008 - https://tools.ietf.org/html/rfc6008 - also be listed in > 2.7.5? > > Yes, it should be referenced. I'll tidy that up for -04. Thanks. -MSK --f46d04428f44b04db70510e30a21 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Mar 9, 2015 at 3:31 PM, Scott Kitterman <scott= @kitterman.com> wrote:

Should RFC 6008 - https://tools.ietf.org/html/rfc6008 - also be list= ed in
2.7.5?


Yes, it should be referenced.=C2=A0 I&= #39;ll tidy that up for -04.=C2=A0 Thanks.

-MSK
--f46d04428f44b04db70510e30a21-- From nobody Mon Mar 9 16:22:09 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D74F1A887D for ; Mon, 9 Mar 2015 16:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5ndDUjtj2uI for ; Mon, 9 Mar 2015 16:22:04 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5E311A884F for ; Mon, 9 Mar 2015 16:22:03 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 215DEC4035D for ; Mon, 9 Mar 2015 18:22:03 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1425943323; bh=wOeNw8VbDLZ+ABlF5O7Ra29oWYyD5YAfA5EdTqQOgrY=; h=From:To:Subject:Date:In-Reply-To:References:From; b=xuQFtrzWr7iDpzWKPncZ7b2tmwoa+79U3IQOV4KUjT9UA2x+pcVUJF9cwsKLISDuF ePZTW9oi/HZzO6cILyiCZq72gqu/YJ6dgay1i9AWtde9fq7ws/DTkxSt3jqj/XhKC7 XFCLLEy1Z0XzuJVTck1XjISGcmvUoUHHM2F0JkNw= From: Scott Kitterman To: apps-discuss@ietf.org Date: Mon, 09 Mar 2015 19:22:02 -0400 Message-ID: <1745871.VmxIvUMNcD@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-46-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <20150309213241.21308.78039.idtracker@ietfa.amsl.com> <2371338.ajW3kri7gd@kitterma-e6430> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc7001bis-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 23:22:08 -0000 On Monday, March 09, 2015 04:01:59 PM Murray S. Kucherawy wrote: > On Mon, Mar 9, 2015 at 3:50 PM, Scott Kitterman wrote: > > I've either missed or forgotten the discussion that led to the proposal to > > change property for the "auth" Email Authentication Method to mailfrom. > > SMTP > > auth doesn't authenticate the mail from, so I'm confused about the purpose > > of > > this change. > > It's a bit of a mistake, showing an incomplete review of SMTP AUTH on my > part. I've never implemented SMTP AUTH, so I'm happy to yield to someone > who has, but here's what I ran into: > > As I read RFC4954, SMTP AUTH can produce an authenticated author identifier > via either the MAIL FROM parameter or through the AUTH command itself. > Shouldn't A-R be able to report either or both? I've never implemented SMTP AUTH either. My reading of the RFC is that even when the AUTH value is tied to Mail From there's still an AUTH parameter the the authenticated identifier is tied to. Here's the two examples in 4954: 5.1. Examples An example where the original identity of the sender is trusted and known: C: MAIL FROM: AUTH=e+3Dmc2@example.com S: 250 OK One example where the identity of the sender is not trusted or is otherwise being suppressed by the client: C: MAIL FROM: AUTH=<> S: 250 OK I think the registry is correct as is, but I'd be interested to hear from people with actual implementation experience. Scott K From nobody Mon Mar 9 16:41:35 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD4171A01D5 for ; Mon, 9 Mar 2015 16:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pyq7vljE0J5J for ; Mon, 9 Mar 2015 16:41:31 -0700 (PDT) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 721531A88A6 for ; Mon, 9 Mar 2015 16:41:31 -0700 (PDT) Received: by wevk48 with SMTP id k48so32494842wev.5 for ; Mon, 09 Mar 2015 16:41: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=MQAEodri1L7Mv5puXrF71FPJpODCiNAvxhj+qZEW8KM=; b=eqY7O1oGtF7pXSYyArXucrjfG6QOUbJkr311fLfBKS6OE7zOIQ8LQtU/emrWJchShj onjl1EeUWqkYDQhjGyDm29GRL6CxVDH+Keqchgl4uhse4Y6f9gTPNAbUpE4CQynn4UpK BmdKGNWx0zfJmyy+NCFdrCPQrZd1TrOxWppPVbVwqmIHIpR8ivJQ8JTXyaSCnh9wDyxU PG9lr1y/n5BMJnkfwmmMhAE7IA4uLpA5OQiHxLO19FEO/uFdY+91mw2DEJAM3B79Pc5E ENPcANPvTqh8+dPCMG4EeEwPkmdbcee54PSHVcMTyi4KgEJ+QxAScrbLQqodYwrknYfG 7HCw== MIME-Version: 1.0 X-Received: by 10.180.106.103 with SMTP id gt7mr108108635wib.59.1425944490156; Mon, 09 Mar 2015 16:41:30 -0700 (PDT) Received: by 10.27.179.212 with HTTP; Mon, 9 Mar 2015 16:41:29 -0700 (PDT) In-Reply-To: <1745871.VmxIvUMNcD@kitterma-e6430> References: <20150309213241.21308.78039.idtracker@ietfa.amsl.com> <2371338.ajW3kri7gd@kitterma-e6430> <1745871.VmxIvUMNcD@kitterma-e6430> Date: Mon, 9 Mar 2015 16:41:29 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=f46d04428f44ce29e00510e39285 Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc7001bis-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 23:41:34 -0000 --f46d04428f44ce29e00510e39285 Content-Type: text/plain; charset=UTF-8 On Mon, Mar 9, 2015 at 4:22 PM, Scott Kitterman wrote: > > > > As I read RFC4954, SMTP AUTH can produce an authenticated author > identifier > > via either the MAIL FROM parameter or through the AUTH command itself. > > Shouldn't A-R be able to report either or both? > > I've never implemented SMTP AUTH either. My reading of the RFC is that > even > when the AUTH value is tied to Mail From there's still an AUTH parameter > the > the authenticated identifier is tied to. Here's the two examples in 4954: > > 5.1. Examples > > > An example where the original identity of the sender is trusted and > known: > > C: MAIL FROM: AUTH=e+3Dmc2@example.com > S: 250 OK > > One example where the identity of the sender is not trusted or is > otherwise being suppressed by the client: > > C: MAIL FROM: AUTH=<> > S: 250 OK > > I think the registry is correct as is, but I'd be interested to hear from > people with actual implementation experience. > RFC4954 says this about the MAIL FROM parameter you're referencing: If the AUTH parameter to the MAIL FROM command is not supplied, the client has authenticated, and the server believes the message is an original submission, the server MAY generate a from the user's authenticated identity for use in an AUTH parameter when relaying the message to any server which supports the AUTH extension. The generated is implementation specific, but it MUST conform to the syntax of [SMTP ]. To me that says if MAIL FROM doesn't include AUTH, then the server falls back to using the client's authorization name (established by the earlier AUTH command). So it seems to me A-R might want to relay one or both of those identities, since in theory at east the first is defined, and possibly both, and they may not be the same. -MSK --f46d04428f44ce29e00510e39285 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Mar 9, 2015 at 4:22 PM, Scott Kitterman <scott= @kitterman.com> wrote:
>
> As I read RFC4954, SMTP AUTH can produce an authenticated author ident= ifier
> via either the MAIL FROM parameter or through the AUTH command itself.=
> Shouldn't A-R be able to report either or both?

I've never implemented SMTP AUTH either.=C2=A0 My reading o= f the RFC is that even
when the AUTH value is tied to Mail From there's still an AUTH paramete= r the
the authenticated identifier is tied to.=C2=A0 Here's the two examples = in 4954:

5.1. Examples


=C2=A0 =C2=A0An example where the original identity of the sender is truste= d and
=C2=A0 =C2=A0known:

=C2=A0 =C2=A0C: MAIL FROM:<e=3Dmc2@ex= ample.com> AUTH=3De+3Dmc2@e= xample.com
=C2=A0 =C2=A0S: 250 OK

=C2=A0 =C2=A0One example where the identity of the sender is not trusted or= is
=C2=A0 =C2=A0otherwise being suppressed by the client:

=C2=A0 =C2=A0C: MAIL FROM:<john+@= example.org> AUTH=3D<>
=C2=A0 =C2=A0S: 250 OK

I think the registry is correct as is, but I'd be interested to hear fr= om
people with actual implementation experience.

RFC4954 says this about the MAIL FROM parameter you're referenci= ng:
        If the AUTH parameter to the MAIL FROM comma=
nd is not supplied,
        the client has authenticated, and the server believes the
        message is an original submission, the server MAY generate a
        <mailbox> from the user's authenticated identity for use =
in an
        AUTH parameter when relaying the message to any server which
        supports the AUTH extension.  The generated <mailbox> is
        implementation specific, but it MUST conform to the syntax of
        [SMTP].
To me = that says if MAIL FROM doesn't include AUTH, then the server falls back= to using the client's authorization name (established by the earlier A= UTH command).=C2=A0 So it seems to me A-R might want to relay one or both o= f those identities, since in theory at east the first is defined, and possi= bly both, and they may not be the same.

-MSK
--f46d04428f44ce29e00510e39285-- From nobody Mon Mar 9 17:20:16 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80B131A908C for ; Mon, 9 Mar 2015 17:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fugluZxiH_6I for ; Mon, 9 Mar 2015 17:20:14 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6AB51A87B2 for ; Mon, 9 Mar 2015 17:20:13 -0700 (PDT) Received: from [192.168.123.7] (unknown [23.241.1.22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 00B5A22E262 for ; Mon, 9 Mar 2015 20:20:06 -0400 (EDT) Message-ID: <54FE3864.6080201@seantek.com> Date: Mon, 09 Mar 2015 17:18:44 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "apps-discuss@ietf.org" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000603000102080506050701" Archived-At: Subject: [apps-discuss] Markdown drafts close to done (text-markdown-06, text-markdown-use-cases-01) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 00:20:15 -0000 This is a cryptographically signed message in MIME format. --------------ms000603000102080506050701 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Colleagues, Amidst the fury of last-minute draft submissions, we are now at: draft-ietf-appsawg-text-markdown-06 draft-ietf-appsawg-text-markdown-use-cases-01 (Apologies about the delay in posting text-markdown-06--that was=20 actually submitted Feburary 23 but didn't get confirmed until this mornin= g.) The main change in use-cases-01 is that I tried to cobble together=20 examples of the syntaxes in Section 4. I went through the list archives and believe that all comments thus far=20 have been addressed. If anything looks amiss or should be brought up,=20 however, please bring it up. These drafts are getting pretty close to don= e. Best regards, Sean --------------ms000603000102080506050701 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ9jCC BK8wggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNV BAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJu YWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcN MTQxMjIyMDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAibEN2npTGU5wUh28VqYGJre4SeCW51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2 IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JDFnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9 KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUIkzqcKlOjENs9IGE8VQOO2U52JQIhKfqj fHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7AzaS1D6/rWpfGXd2dRjNnuJ+u8pQc4 doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZAP8vk4p+iIQIDAQABo4IBFzCC ARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYDVR0OBBYEFJJha4LhoqCq T+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1Ud JQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0w OzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJv b3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRy dXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOc Uvi7BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc0 6HvgARClnMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLK hjQHuSzK5hxK2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6 H3kU9koQGib6fIr7mzCCBT8wggQnoAMCAQICEBpCSs8n+cQbczyWKtueyecwDQYJKoZIhvcN AQELBQAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO BgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhD T01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QTAeFw0xNTAyMDIwMDAwMDBaFw0xNjAyMDIyMzU5NTlaMCUxIzAhBgkqhkiG9w0BCQEWFGRl ditpZXRmQHNlYW50ZWsuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz4n2 0qAOzUtC1oNz5zgTny0JRBE1mJZszV2s6EurahKPvku7E+utnLhcaNahAWr2oZgeCK9uhEqi jaC4qLZHnGt/+lnbsQtjmMJrcFCzhDZjDOJdYzmuS2cUvZqY7YwzCG6jSfs4gwNh+29MS6fa Y6ucncbnfO9rBB0xu5GIdI3BzsPNYnACNlBYU7w4X4GA0/MwNAabNhDgxU2Tw1fl5w1Vt+6x RTXBk6V93LyVZN9wBIOpr2MuhoCJLHZrLirv/mbQE5ao4pkJLR/syYhS1Ko4MSiJmR3ugKPk xEo6DZkuJrfck36hLmtMo3yuzi7hkXmDzPKkdLlNj+Xek1GWtwIDAQABo4IB8jCCAe4wHwYD VR0jBBgwFoAUkmFrguGioKpP7GfxwqP3tIAAwewwHQYDVR0OBBYEFBpm5d7y8PBT6NqnIVbf NK8hbpPGMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUF BwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEE AbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMw XQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2 Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBkAYIKwYBBQUHAQEE gYMwgYAwWAYIKwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1 NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGG GGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAfBgNVHREEGDAWgRRkZXYraWV0ZkBzZWFudGVr LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAeIf/Nevvv10ssk0unrJb9FC8lJi41sSpq5AFYtmC 8IXwUmNxL7L5uE3tGlNJVoTKZvGeklYWDRCzq6zqte221TowXYmFO7G27rJZbQRjLzQoY63r MlFPFrjqQCEA6rDgo9DlFO9/81P7ZC7xvZ52WH7e3p/yJNA4Av8E0eeavhC+l+cwtrw0wCp3 gUs5xJT0koGVvli2wR18zecG3ib3ml+GnDDv2AH7OhcyhVoj6V9AeGQa2HqaVpOQVRUNPamq r3xeARKk5sUSeBvxlF+0FWhl+AnhqNdxmeEpqpgSvbcS1jbTsqApvgsBcDzjC09wV8mtBoMC tqlHvF3YY2z55jGCBDEwggQtAgEBMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0Eg TGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9u IGFuZCBTZWN1cmUgRW1haWwgQ0ECEBpCSs8n+cQbczyWKtueyecwCQYFKw4DAhoFAKCCAlUw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTUwMzEwMDAxODQ0 WjAjBgkqhkiG9w0BCQQxFgQUVlOhZx9ogtPy8fFbHlnRxmvTEJ4wbAYJKoZIhvcNAQkPMV8w XTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBwQYJKwYBBAGCNxAE MYGzMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAw DgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4 Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEBpCSs8n+cQbczyWKtueyecwgcMGCyqGSIb3DQEJEAILMYGzoIGwMIGbMQswCQYDVQQG EwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRow GAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBpCSs8n+cQbczyWKtue yecwDQYJKoZIhvcNAQEBBQAEggEAYgpKROvUBR0VaS1fSIQIrwcNFwMrx3cTOWzM7iNA76f/ 230oFgSEe48RZqcJGYvELTAWz/lZ+l3oJGwyGSzachnPNAxnJVAxvTRD0psoj/cEKP8vK4DZ 1f4RxLYCA9ggIt7ms0eif1EUXCgjBCfbc1qrhE6T6Sk5EA4zv0BkGQh3Pq/T3FTeiLao0qQZ RabBd55Yw+wvNscKHYAe6DZQjLDPnFHHlMwa4MCXtGYCqRMUIOqOMLE55AnnRHbYwL07psNy c/yxq/ysGbwnSfZDoxibx3MSXT3Vj185H/YbhLqlUdSG7Gx6/P6NcW6xg2DJl4stvT5KotAa xaMXjelpfAAAAAAAAA== --------------ms000603000102080506050701-- From nobody Mon Mar 9 18:49:50 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8953D1AD0AE for ; Mon, 9 Mar 2015 18:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JLvT69_yjEV1 for ; Mon, 9 Mar 2015 18:49:47 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B0541ACD95 for ; Mon, 9 Mar 2015 18:49:47 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 56E28C4016D for ; Mon, 9 Mar 2015 20:49:46 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1425952186; bh=XGGLA9qnjuEZiG3e/UABr+UB3FLn8joAPjLy0dM9VuA=; h=From:To:Subject:Date:In-Reply-To:References:From; b=eZ+nNQhyNVw/pBu7bT6aYtsHv2Ipduf7CA1I7pKuyml3HJ2Nvzn+Hg35I5Ep4bmNF YkeQ72rzb0W5L2qezU2ethDQoUgXjVSFksUpasELxrtOMkqwWCZJAB6lmmrYaKRtED z603ukJfeoR0Z7yihRjCIz1pUP4KIbBFgV6q/SUs= From: Scott Kitterman To: apps-discuss@ietf.org Date: Mon, 09 Mar 2015 21:49:40 -0400 Message-ID: <1731091.ESpB87eB1S@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-46-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <20150309213241.21308.78039.idtracker@ietfa.amsl.com> <1745871.VmxIvUMNcD@kitterma-e6430> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc7001bis-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 01:49:49 -0000 On Monday, March 09, 2015 04:41:29 PM Murray S. Kucherawy wrote: > On Mon, Mar 9, 2015 at 4:22 PM, Scott Kitterman wrote: > > > As I read RFC4954, SMTP AUTH can produce an authenticated author > > > > identifier > > > > > via either the MAIL FROM parameter or through the AUTH command itself. > > > Shouldn't A-R be able to report either or both? > > > > I've never implemented SMTP AUTH either. My reading of the RFC is that > > even > > when the AUTH value is tied to Mail From there's still an AUTH parameter > > the > > the authenticated identifier is tied to. Here's the two examples in 4954: > > > > 5.1. Examples > > > > An example where the original identity of the sender is trusted and > > known: > > > > C: MAIL FROM: AUTH=e+3Dmc2@example.com > > S: 250 OK > > > > One example where the identity of the sender is not trusted or is > > otherwise being suppressed by the client: > > > > C: MAIL FROM: AUTH=<> > > S: 250 OK > > > > I think the registry is correct as is, but I'd be interested to hear from > > people with actual implementation experience. > > RFC4954 says this about the MAIL FROM parameter you're referencing: > > If the AUTH parameter to the MAIL FROM command is not supplied, > the client has authenticated, and the server believes the > message is an original submission, the server MAY generate a > from the user's authenticated identity for use in an > AUTH parameter when relaying the message to any server which > supports the AUTH extension. The generated is > implementation specific, but it MUST conform to the syntax of > [SMTP ]. > > To me that says if MAIL FROM doesn't include AUTH, then the server falls > back to using the client's authorization name (established by the earlier > AUTH command). So it seems to me A-R might want to relay one or both of > those identities, since in theory at east the first is defined, and > possibly both, and they may not be the same. > > -MSK Except they are both auth and neither are the mail from identity. I still don't see the need for a registry change. Also, since that paragraph starts out "If the AUTH parameter to the MAIL FROM command is not supplied ..." I don't think you can have both. It's either one you were provided or one you generated. Scott K Scott K From nobody Mon Mar 9 19:09:58 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C92BC1ACE2C for ; Mon, 9 Mar 2015 19:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.563 X-Spam-Level: * X-Spam-Status: No, score=1.563 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_44=0.6, J_CHICKENPOX_84=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1au0Ru47bxN8 for ; Mon, 9 Mar 2015 19:09:55 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5345F1ACE26 for ; Mon, 9 Mar 2015 19:09:55 -0700 (PDT) Received: (qmail 81719 invoked from network); 10 Mar 2015 02:09:50 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 10 Mar 2015 02:09:50 -0000 Date: 10 Mar 2015 02:09:28 -0000 Message-ID: <20150310020928.33511.qmail@ary.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <1745871.VmxIvUMNcD@kitterma-e6430> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: scott@kitterman.com Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc7001bis-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 02:09:57 -0000 >> > I've either missed or forgotten the discussion that led to the proposal to >> > change property for the "auth" Email Authentication Method to mailfrom.SMTP >> > auth doesn't authenticate the mail from, so I'm confused about the purpose of >> > this change. >> >> It's a bit of a mistake, showing an incomplete review of SMTP AUTH on my >> part. I've never implemented SMTP AUTH, so I'm happy to yield to someone >> who has, but here's what I ran into: >> >> As I read RFC4954, SMTP AUTH can produce an authenticated author identifier >> via either the MAIL FROM parameter or through the AUTH command itself. >> Shouldn't A-R be able to report either or both? > >I've never implemented SMTP AUTH either. I have, and I should have caught this. Everyone who implements SMTP AUTH implements the AUTH command with username and password credentials, but I don't know anyone who implements the mailfrom auth= parameter beyond perhaps ignoring it. The interesting bit to record is smtp.auth with the username as the value. I think the official name for the username is the authentication identity. SASL allows much fancier credentials with certificates and such, but I don't know anyone who implements that, either. I believe that the few people who do SUBMIT authentication with certs do it with a client cert in the STARTTLS handshake. R's, John From nobody Tue Mar 10 10:20:40 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E95501A6FF9 for ; Tue, 10 Mar 2015 10:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.087 X-Spam-Level: * X-Spam-Status: No, score=1.087 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_44=0.6, J_CHICKENPOX_84=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OTLN8aoZOUIl for ; Tue, 10 Mar 2015 10:20:37 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 752D01A6FEE for ; Tue, 10 Mar 2015 10:20:37 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PJFSW1CBRK00CT7E@mauve.mrochek.com> for apps-discuss@ietf.org; Tue, 10 Mar 2015 10:15:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1426007734; bh=GEgm3pGcvy6aVW1ugg8yLOlVl/DGfaQrbOamW4rjRdI=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=B8ywAXePb4nzHe3LZ2Ae/Gid2FDTfnmJSqlZxP4xEMC96cy7NBejbG+7q95LyBVGz 4zv6zxSw8d2xxm/sAe8+iHUJ3O4wgNHr5TGKmlU4fhOKZqBZOzzvo34wEkceyX2QfB H8uzaW80LP3wMXkP1yayfoTyeTxUe6QEzAXFh9aU= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PJ6KCZSXQ80000AQ@mauve.mrochek.com>; Tue, 10 Mar 2015 10:15:29 -0700 (PDT) Message-id: <01PJFSVXS0XW0000AQ@mauve.mrochek.com> Date: Tue, 10 Mar 2015 09:58:24 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 10 Mar 2015 02:09:28 +0000" <20150310020928.33511.qmail@ary.lan> References: <1745871.VmxIvUMNcD@kitterma-e6430> <20150310020928.33511.qmail@ary.lan> To: John Levine Archived-At: Cc: scott@kitterman.com, apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc7001bis-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 17:20:39 -0000 > >> > I've either missed or forgotten the discussion that led to the proposal to > >> > change property for the "auth" Email Authentication Method to mailfrom.SMTP > >> > auth doesn't authenticate the mail from, so I'm confused about the purpose of > >> > this change. > >> > >> It's a bit of a mistake, showing an incomplete review of SMTP AUTH on my > >> part. I've never implemented SMTP AUTH, so I'm happy to yield to someone > >> who has, but here's what I ran into: > >> > >> As I read RFC4954, SMTP AUTH can produce an authenticated author identifier > >> via either the MAIL FROM parameter or through the AUTH command itself. > >> Shouldn't A-R be able to report either or both? > > > >I've never implemented SMTP AUTH either. > I have, and I should have caught this. Everyone who implements SMTP > AUTH implements the AUTH command with username and password > credentials, but I don't know anyone who implements the mailfrom auth= > parameter beyond perhaps ignoring it. We do. We provide a number of options for generating, consuming, and using this information. And we have customers using it. Not a huge number, and not on the open Internet where it's meaningless, but within an ADMD, absolutely. OTOH, I can't recall a single instance of anyone wanting to generate an Authentication-Results field from this information. Or any other information internal to our MTA, for that matter. The only time we run into Authentication-Results is when some other piece of software generates it and Sieve scripts or whatever need to process it. I'll also note that in this regard, the field has some fairly significant semantic issues, such as there being no way to reliably tie it to a specific DKIM result. > The interesting bit to record is smtp.auth with the username as the > value. I think the official name for the username is the > authentication identity. But if you want to pass that information along from an ingress system to another system along a trusted path, the MAIL FROM AUTH parameter is the obvous way to do it. > SASL allows much fancier credentials with certificates and such, but I > don't know anyone who implements that, either. We do. And we have lots of customers using it. AUTH EXTERNAL in particular is a requirement in quite a few places. > I believe that the few > people who do SUBMIT authentication with certs do it with a client cert > in the STARTTLS handshake. Which is then supposed to be bound to the session using AUTH EXTERNAL. Although there's sufficient wiggle room in the specifications for this not to be a requirement, which means you also need to support implicit binding. Ned From nobody Tue Mar 10 10:34:25 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A0B21A1EF5 for ; Tue, 10 Mar 2015 10:34:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.063 X-Spam-Level: X-Spam-Status: No, score=0.063 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_44=0.6, J_CHICKENPOX_48=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K5r52ZEwMTsT for ; Tue, 10 Mar 2015 10:34:23 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9497E1A2130 for ; Tue, 10 Mar 2015 10:34:23 -0700 (PDT) Received: (qmail 67560 invoked from network); 10 Mar 2015 17:34:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=107e7.54ff2b18.k1503; bh=7Hqg3T4O+JSPDzafjv+dYB+mhb5atgXVFfYhzBrD7C8=; b=Zr06YUh0LFVmYQpO2+ROa+xtNbo+E1+bPNYorRddPMQY1gtf32Q0Ql/UjT0HZsGKkVnyAqstACFTP2j5kwmx1ZqJIdIa2DeVshJ9t6KopXA/klrCIiLoiN+NL5c9q2vuEMJ8/r+Rpz3HZUpexTeST+m8Veh7zWzBMug+f9MBZ2GoBCP8tdisgrwNux+n1BT8n+IpICEuyvL2CmTp0SB+rI+4CTDtgivNFB8xgaWpSoye8c5XYxAmkXZgYCeic8sH DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=107e7.54ff2b18.k1503; bh=7Hqg3T4O+JSPDzafjv+dYB+mhb5atgXVFfYhzBrD7C8=; b=XYR3hrzXvPUPAxVJ9SoA3dcA43TQemIVA5Cd1MVKHybwSV3Mf2DGq3kmbHAXGv3UTEiDLBjPLGsvzEMA6Mi2m84XMVlN8hKQb5nNlHwobveK92vOXrvMzamr+3fUts098fYjBOq9YMTEr/xvNlZ5NGS7uKZpV6kjIVx+xM6la36rFBnVS2O9yGVZ1akirrxCnEogUM4wUOh0SIyyzbbJYn54rjUA7xsgi13dNJzDZyK1q5+j9fNaECF9b0yBcreO Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 10 Mar 2015 17:34:16 -0000 Date: 10 Mar 2015 13:34:15 -0400 Message-ID: From: "John R Levine" To: "Ned Freed" In-Reply-To: <01PJFSVXS0XW0000AQ@mauve.mrochek.com> References: <1745871.VmxIvUMNcD@kitterma-e6430> <20150310020928.33511.qmail@ary.lan> <01PJFSVXS0XW0000AQ@mauve.mrochek.com> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc7001bis-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 17:34:25 -0000 >> The interesting bit to record is smtp.auth with the username as the >> value. I think the official name for the username is the >> authentication identity. > > But if you want to pass that information along from an ingress system > to another system along a trusted path, the MAIL FROM AUTH parameter is > the obvous way to do it. I'd have no objection to allowing both smtp.auth and smtp.mailfrom ptypes. It'd be at worst harmless. > We do. And we have lots of customers using it. AUTH EXTERNAL in particular is a > requirement in quite a few places. When someone uses AUTH EXTERNAL, is the authorized identity anything that couldn't be recorded in the smtp.auth clause? Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Tue Mar 10 10:51:37 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 361C61A2130 for ; Tue, 10 Mar 2015 10:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LebUfhgrsMmM for ; Tue, 10 Mar 2015 10:51:34 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 759E01A6F15 for ; Tue, 10 Mar 2015 10:51:34 -0700 (PDT) Received: by wggy19 with SMTP id y19so3559672wgg.9 for ; Tue, 10 Mar 2015 10:51:33 -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=i+k4q5VEZSOyRYPgzTaAqSTyaqlAjN37SxLDjwYgUqI=; b=v6fR0DB0/dx5viDKQITL710xtql/7UtTzO4aQNqf8F79L72OSwm4qQJj5ge8HDQIKg dOnbvqhhw77YnkzwFl5prX2njL37/OzWqHrmaMei12obKXIJdEkwv3TX28b17gG0G09S dSGtsxi5rxVt0XbPlQf+bfE7L0N3p9pJ1JWy1fISAdm3FUHgXKQxppfkLVHsuoDrsx8G DeerenfihKasqSGvud3YP7AV0/v6uBEuagG6hBJeHRFMDgCKZ/DZLgJclbzSlBNB6W9P o9F56do7fNcA2jOQ6nOnniEXWDHYvGndsWQE+hazDSgF2wGfBFrxtx8QPZGVj514HerB S2Ew== MIME-Version: 1.0 X-Received: by 10.180.106.103 with SMTP id gt7mr115624426wib.59.1426009893174; Tue, 10 Mar 2015 10:51:33 -0700 (PDT) Received: by 10.27.179.212 with HTTP; Tue, 10 Mar 2015 10:51:33 -0700 (PDT) In-Reply-To: <01PJFSVXS0XW0000AQ@mauve.mrochek.com> References: <1745871.VmxIvUMNcD@kitterma-e6430> <20150310020928.33511.qmail@ary.lan> <01PJFSVXS0XW0000AQ@mauve.mrochek.com> Date: Tue, 10 Mar 2015 10:51:33 -0700 Message-ID: From: "Murray S. Kucherawy" To: Ned Freed Content-Type: multipart/alternative; boundary=f46d04428f442101ac0510f2cdef Archived-At: Cc: Scott Kitterman , John Levine , IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc7001bis-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 17:51:36 -0000 --f46d04428f442101ac0510f2cdef Content-Type: text/plain; charset=UTF-8 On Tue, Mar 10, 2015 at 9:58 AM, Ned Freed wrote: > I'll also note that in this regard, the field has some fairly significant > semantic issues, such as there being no way to reliably tie it to a > specific > DKIM result. > That was fixed in RFC6008, I believe. -MSK --f46d04428f442101ac0510f2cdef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Mar 10, 2015 at 9:58 AM, Ned Freed <ned.freed= @mrochek.com> wrote:
I'll also note that in = this regard, the field has some fairly significant
semantic issues, such as there being no way to reliably tie it to a specifi= c
DKIM result.

That was fixed in RFC6008,= I believe.
=C2=A0
-MSK
--f46d04428f442101ac0510f2cdef-- From nobody Tue Mar 10 11:19:24 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8DB1A872C for ; Tue, 10 Mar 2015 11:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wwC5yOcr6T2n for ; Tue, 10 Mar 2015 11:19:22 -0700 (PDT) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC0111A8726 for ; Tue, 10 Mar 2015 11:19:21 -0700 (PDT) Received: by lbiz11 with SMTP id z11so3611662lbi.13 for ; Tue, 10 Mar 2015 11:19:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=9nz8Z0TPYxZNlnuj2IIWzlHh0T1+suft/USGisYQ1hU=; b=M+dWNnTAKUJ5JUtdea34RiKDKQKbz/9SrxNIaY1NU6PM003FAKSmsKBIJ1aoGZb8/3 ix6YNUVhOUkIUXQ89TGaeoBKT2HNnCcBJa7UqLO63cL8bCy+YluOANWjhTWCSwB/EL8Y O6B2IEnTmwFMiRkmABw/r1w+qRlP2TDzZhjJNhuIfyfRjN4b6BPAKfIaG+UgdcVjIBb0 PElN42rnPjjVA0w/+1ZlqidTmEUaNiPA5Z1I/ZSeiXXwG0hpenhlxL4+8rXNXPqHdx3g C+6HuXuiKeWmYiDWOIZSo79oiljnHE8tWEkBZldbAm7uayRnHfupA+3lI0vr+500Cmkx zO8g== MIME-Version: 1.0 X-Received: by 10.112.139.136 with SMTP id qy8mr31574999lbb.38.1426011560247; Tue, 10 Mar 2015 11:19:20 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.183.34 with HTTP; Tue, 10 Mar 2015 11:19:20 -0700 (PDT) In-Reply-To: <7514DD37-8BAE-4EDA-BDCE-649D518C435E@adobe.com> References: <7514DD37-8BAE-4EDA-BDCE-649D518C435E@adobe.com> Date: Tue, 10 Mar 2015 14:19:20 -0400 X-Google-Sender-Auth: ZV0WfTbx3NvxofCkJrU3hfVQbR0 Message-ID: From: Barry Leiba To: Larry Masinter Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: Apps Discuss Subject: Re: [apps-discuss] AD review of draft-ietf-appsawg-multipart-form-data-07 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 18:19:23 -0000 > I went ahead and did a new version before the cutoff Thanks, Larry. And I've trimmed everything below that needs no further comment. For all the trimmed stuff: Thanks for addressing it. >>Section 1 should have a note for the RFC Editor to remove it at >>publication. Better, just remove it now, yes? > > I took this out, but asI think I want to put it back in before > Last Call, because I want people to look at the very incomplete > test cases during last call. > > still want to point people to https://github.com/masinter/multipart-form-data Ack. You can put it back for now, or... I can make sure it's in the last call note. Let me know whether you think having it in the last call note is good enough. >>Also, that encoding isn't used just for non-ASCII characters, but for >>any characters outside the set that can be legally included with ASCII >>encoding. You should rephrase this. > > I tried. You succeeded. >>-- Section 6.1.1 -- >> >> For broadest interoperability with existing deployed software, those >> creating forms SHOULD avoid non-ASCII field names. This should not >> be a burden, because in general the field names are not visible to >> users. >> >>I think it's worth adding a reminder that the field names in the >>underlying form don't have to match the names the user might see on >>the screen. That would clarify the "not visible to users" part. > > done, please review Reviewed (now Section 5.1.1). You left out a word: OLD The field names in the underlying need not match what the user sees on the screen. NEW The field names in the underlying form need not match what the user sees on the screen. -- I'm ready to request last call on this as soon as you give me the go-ahead. If you want to make one more revision before I do that, let me know off list and I'll approve posting it during the pre-meeting blackout. Barry From nobody Tue Mar 10 14:37:20 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 858E01A87AC for ; Tue, 10 Mar 2015 14:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.802 X-Spam-Level: X-Spam-Status: No, score=-0.802 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_44=0.6, J_CHICKENPOX_48=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ccbR93NZ8gQF for ; Tue, 10 Mar 2015 14:37:17 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1C4A1A8A66 for ; Tue, 10 Mar 2015 14:37:16 -0700 (PDT) Received: from [100.70.94.89] (29.sub-70-208-144.myvzw.com [70.208.144.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 61E97C4016D; Tue, 10 Mar 2015 16:37:15 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1426023436; bh=k2dwbeGqpBHkfQ6NMHzFTw8LrF3VzsT6zhbwGMeCNnE=; h=In-Reply-To:References:Subject:From:Date:To:From; b=wJ6Jg3DNSlUkT8pFVJD/wbjh3GE8mI3iLokx67ZcAxR0k5Ji0a6zq6Jcm7RDCAl4u RdhOH/Z5vVxz0Gb2ZyHvcCULMa3vdzac3FuDBH3+dXDqnaGFM56GBS74+49eDe9F2O OYUO5NDx3O249E02ZBcH9xV5I3StKNS2mkRoT150= User-Agent: K-9 Mail for Android In-Reply-To: References: <1745871.VmxIvUMNcD@kitterma-e6430> <20150310020928.33511.qmail@ary.lan> <01PJFSVXS0XW0000AQ@mauve.mrochek.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Scott Kitterman Date: Tue, 10 Mar 2015 17:37:10 -0400 To: "apps-discuss@ietf.org" Message-ID: <1A1157E7-0253-423F-A86B-0D1A3E1DF38B@kitterman.com> Archived-At: Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc7001bis-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 21:37:18 -0000 On March 10, 2015 1:34:15 PM EDT, John R Levine wrote: >>> The interesting bit to record is smtp.auth with the username as the >>> value. I think the official name for the username is the >>> authentication identity. >> >> But if you want to pass that information along from an ingress system >> to another system along a trusted path, the MAIL FROM AUTH parameter >is >> the obvous way to do it. > >I'd have no objection to allowing both smtp.auth and smtp.mailfrom >ptypes. >It'd be at worst harmless. Except the auth value in mail from auth isn't necessarily the same as the actual mail from. Reporting something as smtp.mailfrom that's not the actual mail from seems wrong to me. Scott K From nobody Tue Mar 10 15:19:33 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B01DD1A8F46 for ; Tue, 10 Mar 2015 15:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, J_CHICKENPOX_48=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhNngyVxNbET for ; Tue, 10 Mar 2015 15:19:30 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 673051A8F37 for ; Tue, 10 Mar 2015 15:19:28 -0700 (PDT) Received: by wivr20 with SMTP id r20so6852938wiv.3 for ; Tue, 10 Mar 2015 15:19: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=ZV+x5DkjCXhfBP7H6qr9jg84au3MyKU/TviCr2HQElE=; b=UGGawjosX1sSQ2j97aDWIyuIgE58+dRDU8jllR06ORGudNxLUcoVV0uxyIj9ADH+5S XBRY9vAjSKiJqDZOF16yockvPMWzFTc0mupzz+/iNVGkunetdKmgNJ/nuYeWxIf7r67Q l6947aq2JYzGgmSsWXrT/Nl5K/izRYNaO3MzhtaRkc0uJvIMCzQyp9ygu0VJg6rhMGG4 JvJygYmi1tJFJBKobt4YUnqe0zswgQOwpWW87E79wfTw28tAO5wSoW4et7Mj0sta85Zx hHlKrgTb4UyW43ZAOFeNpUA3SLBv/I/S0Wh+IDC5r9NXyhdcubD16IUPHkU9DC/b45cn nxTA== MIME-Version: 1.0 X-Received: by 10.180.106.103 with SMTP id gt7mr117311672wib.59.1426025967113; Tue, 10 Mar 2015 15:19:27 -0700 (PDT) Received: by 10.27.179.212 with HTTP; Tue, 10 Mar 2015 15:19:27 -0700 (PDT) In-Reply-To: <1A1157E7-0253-423F-A86B-0D1A3E1DF38B@kitterman.com> References: <1745871.VmxIvUMNcD@kitterma-e6430> <20150310020928.33511.qmail@ary.lan> <01PJFSVXS0XW0000AQ@mauve.mrochek.com> <1A1157E7-0253-423F-A86B-0D1A3E1DF38B@kitterman.com> Date: Tue, 10 Mar 2015 15:19:27 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=f46d04428f4435dd170510f68b84 Archived-At: Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc7001bis-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 22:19:31 -0000 --f46d04428f4435dd170510f68b84 Content-Type: text/plain; charset=UTF-8 On Tue, Mar 10, 2015 at 2:37 PM, Scott Kitterman wrote: > >I'd have no objection to allowing both smtp.auth and smtp.mailfrom > >ptypes. > >It'd be at worst harmless. > > Except the auth value in mail from auth isn't necessarily the same as the > actual mail from. Reporting something as smtp.mailfrom that's not the > actual mail from seems wrong to me. > I think a result of "auth=pass smtp.mailfrom=foo@bar" resulting from MAIL FROM: AUTH=" is unambiguous. -MSK --f46d04428f4435dd170510f68b84 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Mar 10, 2015 at 2:37 PM, Scott Kitterman <scott= @kitterman.com> wrote:
>I= 9;d have no objection to allowing both smtp.auth and smtp.mailfrom
>ptypes.
>It'd be at worst harmless.

Except the auth value in mail from auth isn't necessarily the sa= me as the actual mail from. Reporting something as smtp.mailfrom that's= not the actual mail from seems wrong to me.

I think a result of "auth=3Dpass smtp.mailfrom=3Dfoo@bar" r= esulting from MAIL FROM:<x@y> AUTH=3D<foo@bar>" is unambig= uous.

-MSK
--f46d04428f4435dd170510f68b84-- From nobody Tue Mar 10 18:53:27 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D9651A92AF for ; Tue, 10 Mar 2015 18:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.802 X-Spam-Level: X-Spam-Status: No, score=-0.802 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_44=0.6, J_CHICKENPOX_48=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H_NZZGG_l0cy for ; Tue, 10 Mar 2015 18:53:18 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11D641A9241 for ; Tue, 10 Mar 2015 18:53:18 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id ED02BC4035D for ; Tue, 10 Mar 2015 20:53:16 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1426038797; bh=ZH08R9wPkzP2ctSB0e9G7/xo+UNatF6uQGhKmRqYK0U=; h=From:To:Subject:Date:In-Reply-To:References:From; b=RdQv2x5KxsYeCWjhRs+hTAgIL7IIvl4WhukdFSSwdGgFxi/UNkaq2plVUXRTJXNh7 L5TFyCeNsop2LKPMgcqwS9E+1IfUm/AdcxQoCRvoNrpJ4OJPvpG8wNcCLwHTlbeZ8+ B8xv4q/m17ZzigRXRumvSKAcStQq/RtcsY4cI+nw= From: Scott Kitterman To: apps-discuss@ietf.org Date: Tue, 10 Mar 2015 21:53:11 -0400 Message-ID: <8490991.UtrA20XB6B@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-46-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <1745871.VmxIvUMNcD@kitterma-e6430> <1A1157E7-0253-423F-A86B-0D1A3E1DF38B@kitterman.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc7001bis-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 01:53:25 -0000 On Tuesday, March 10, 2015 03:19:27 PM Murray S. Kucherawy wrote: > On Tue, Mar 10, 2015 at 2:37 PM, Scott Kitterman > > wrote: > > >I'd have no objection to allowing both smtp.auth and smtp.mailfrom > > >ptypes. > > >It'd be at worst harmless. > > > > Except the auth value in mail from auth isn't necessarily the same as the > > actual mail from. Reporting something as smtp.mailfrom that's not the > > actual mail from seems wrong to me. > > I think a result of "auth=pass smtp.mailfrom=foo@bar" resulting from MAIL > FROM: AUTH=" is unambiguous. > > -MSK I agree it's unambiguous. I think it's ugly, but I can't find anything in the ABNF that strictly precludes it. Please add an example to show this because I don't think it's at all obvious. Scott K From nobody Wed Mar 11 09:26:06 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10EBE1ACD77; Wed, 11 Mar 2015 09:26:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2w8zeKwpuPuT; Wed, 11 Mar 2015 09:26:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C90E41ACDDF; Wed, 11 Mar 2015 09:25:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150311162559.21236.15078.idtracker@ietfa.amsl.com> Date: Wed, 11 Mar 2015 09:25:59 -0700 From: IETF Secretariat Archived-At: Subject: [apps-discuss] Telechat update notice: X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 16:26:05 -0000 Placed on agenda for telechat - 2015-04-09 ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-uri-scheme-reg/ From nobody Wed Mar 11 09:26:08 2015 Return-Path: X-Original-To: expand-draft-ietf-appsawg-uri-scheme-reg.all@virtual.ietf.org Delivered-To: apps-discuss@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 423DB1ACDE6; Wed, 11 Mar 2015 09:26:05 -0700 (PDT) X-Original-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10EBE1ACD77; Wed, 11 Mar 2015 09:26:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2w8zeKwpuPuT; Wed, 11 Mar 2015 09:26:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C90E41ACDDF; Wed, 11 Mar 2015 09:25:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150311162559.21236.15078.idtracker@ietfa.amsl.com> Date: Wed, 11 Mar 2015 09:25:59 -0700 From: IETF Secretariat Archived-At: Subject: [apps-discuss] Telechat update notice: X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 16:26:05 -0000 Placed on agenda for telechat - 2015-04-09 ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-uri-scheme-reg/ From nobody Wed Mar 11 11:06:15 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 964021A1B8F; Wed, 11 Mar 2015 11:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aSnkobhmDUhp; Wed, 11 Mar 2015 11:06:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DC3FE1A1BAC; Wed, 11 Mar 2015 11:06:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150311180602.31232.76227.idtracker@ietfa.amsl.com> Date: Wed, 11 Mar 2015 11:06:02 -0700 From: IETF Secretariat Archived-At: Subject: [apps-discuss] ID Tracker State Update Notice: X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 18:06:14 -0000 IANA review state changed to IANA - Not OK ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-uri-scheme-reg/ From nobody Wed Mar 11 11:06:17 2015 Return-Path: X-Original-To: expand-draft-ietf-appsawg-uri-scheme-reg.all@virtual.ietf.org Delivered-To: apps-discuss@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id B51F31A1BA4; Wed, 11 Mar 2015 11:06:14 -0700 (PDT) X-Original-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 964021A1B8F; Wed, 11 Mar 2015 11:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aSnkobhmDUhp; Wed, 11 Mar 2015 11:06:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DC3FE1A1BAC; Wed, 11 Mar 2015 11:06:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150311180602.31232.76227.idtracker@ietfa.amsl.com> Date: Wed, 11 Mar 2015 11:06:02 -0700 From: IETF Secretariat Archived-At: Subject: [apps-discuss] ID Tracker State Update Notice: X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 18:06:14 -0000 IANA review state changed to IANA - Not OK ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-uri-scheme-reg/ From nobody Wed Mar 11 11:16:19 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D8691A1BE5; Wed, 11 Mar 2015 11:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ySe0-UTf4ZWo; Wed, 11 Mar 2015 11:16:16 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0771.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::771]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF64A1A1BC2; Wed, 11 Mar 2015 11:16:12 -0700 (PDT) Received: from BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) by BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) with Microsoft SMTP Server (TLS) id 15.1.106.11; Wed, 11 Mar 2015 18:15:54 +0000 Received: from BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) by BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) with mapi id 15.01.0106.007; Wed, 11 Mar 2015 18:15:54 +0000 From: Dave Thaler To: "drafts-lastcall@iana.org" Thread-Topic: [IANA #810446] Last Call: (Guidelines and Registration Procedures for URI Schemes) to Best Current Practice Thread-Index: AQHQXB/FAGCDJE6Ak0Kh1XBZOc3TEJ0XlKpA Date: Wed, 11 Mar 2015 18:15:54 +0000 Message-ID: References: <20150226200519.21140.53651.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e0:ee43::3] authentication-results: iana.org; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB412; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(51704005)(40100003)(122556002)(2950100001)(77156002)(110136001)(92566002)(62966003)(87936001)(2351001)(76576001)(106116001)(46102003)(2656002)(2501003)(54356999)(230783001)(74316001)(77096005)(102836002)(2900100001)(86362001)(33656002)(86612001)(76176999)(50986999)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB412; H:BY2PR03MB412.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002009)(5005006); SRVR:BY2PR03MB412; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB412; x-forefront-prvs: 0512CC5201 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Mar 2015 18:15:54.3699 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB412 Archived-At: Cc: "appsawg-chairs@ietf.org" , "draft-ietf-appsawg-uri-scheme-reg.all@ietf.org" , "iesg@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [IANA #810446] Last Call: (Guidelines and Registration Procedures for URI Schemes) to Best Current Practice X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 18:16:18 -0000 UGVhcmwgTGlhbmcgIHdyaXRlczoNCj4gSUFOQSBoYXMgcmV2aWV3ZWQgZHJhZnQtaWV0Zi1hcHBz YXdnLXVyaS1zY2hlbWUtcmVnLTA0LiAgQXV0aG9ycyBzaG91bGQNCj4gcmV2aWV3IHRoZSBjb21t ZW50cyBhbmQvb3IgcXVlc3Rpb25zIGJlbG93LiAgUGxlYXNlIHJlcG9ydCBhbnkgaW5hY2N1cmFj aWVzDQo+IGFuZCByZXNwb25kIHRvIGFueSBxdWVzdGlvbnMgYXMgc29vbiBhcyBwb3NzaWJsZS4N Cj4gDQo+IFdlIHJlY2VpdmVkIHRoZSBmb2xsb3dpbmcgY29tbWVudHMvcXVlc3Rpb25zIGZyb20g dGhlIElBTkEncyByZXZpZXdlcjoNCj4gDQo+IFdlIGhhdmUgcXVlc3Rpb25zIGFib3V0IHNvbWUg b2YgdGhlIElBTkEgYWN0aW9ucyByZXF1ZXN0ZWQgYnkgdGhpcyBkcmFmdC4NCj4gDQo+IElBTkEg dW5kZXJzdGFuZHMgdGhhdCwgdXBvbiBhcHByb3ZhbCBvZiB0aGlzIGRvY3VtZW50LCB0aGVyZSBh cmUgZm91ciBhY3Rpb25zDQo+IHdoaWNoIElBTkEgbXVzdCBjb21wbGV0ZS4NCg0KWW91ciBzdW1t YXJ5IGxvb2tzIGNvcnJlY3QuICBSZXNwb25zZXMgdG8gcXVlc3Rpb25zIGJlbG93Lg0KDQpbLi4u XQ0KPiBTZWNvbmQsIHRoaXMgZHJhZnQgdXBkYXRlcyB0aGUgcmVnaXN0cmF0aW9uIHByb2NlZHVy ZXMgZm9yIHRoZSBVbmlmb3JtIFJlc291cmNlDQo+IElkZW50aWZpZXIgKFVSSSkgU2NoZW1lcyBy ZWdpc3RyeSB0byB0aGUgZm9sbG93aW5nOg0KPiANCj4gIlBlcm1hbmVudCBVUkkgU2NoZW1lcyI6 IChObyBjaGFuZ2UpDQo+IEV4cGVydCBSZXZpZXcNCj4gDQo+ICJQcm92aXNpb25hbCBVUkkgU2No ZW1lcyI6DQo+IE9MRDoNCj4gRXhwZXJ0IFJldmlldw0KPiANCj4gTkVXOg0KPiAgRmlyc3QgQ29t ZSBGaXJzdCBTZXJ2ZWQNCj4gDQo+ICJIaXN0b3JpY2FsIFVSSSBTY2hlbWVzIjoNCj4gRXhwZXJ0 IFJldmlldyA/Pz8NCj4gDQo+IFF1ZXN0aW9uOiBXaGF0IGlzIHRoZSBwb2xpY3kgdG8gZGVzaWdu YXRlZCBhIHNjaGVtYSBhcyBoaXN0b3JpY2FsPyAgRXhwZXJ0DQo+IFJldmlldz8NCg0KVGhpcyBp cyBhbnN3ZXJlZCBpbiBTZWN0aW9uIDcuMSBvZiB0aGUgZHJhZnQsIHdoZXJlIHRoZSBmaXJzdCBw YXJhZ3JhcGggc3RhdGVzOg0KDQogICBUaGUgSUFOQSBwb2xpY3kgKHVzaW5nIHRlcm1zIGRlZmlu ZWQgaW4gW1JGQzUyMjZdKSBmb3IgUHJvdmlzaW9uYWwNCiAgIHJlZ2lzdHJhdGlvbiB3YXMgZm9y bWVybHkgRXhwZXJ0IFJldmlldyBhbmQgaXMgbm93IGNoYW5nZWQgdG8gc2ltcGx5DQogICB1c2Ug YSBGaXJzdCBDb21lIEZpcnN0IFNlcnZlZCBwb2xpY3kuICBUaGUgcG9saWN5IGZvciBQZXJtYW5l bnQgYW5kDQogICBIaXN0b3JpYyByZWdpc3RyYXRpb24gY29udGludWVzIHRvIGJlIEV4cGVydCBS ZXZpZXcuDQoNClRoZSBsYXN0IHNlbnRlbmNlIHF1b3RlZCBhYm92ZSBpcyB0aGUgYW5zd2VyIHRv IHlvdXIgcXVlc3Rpb24uDQoNCj4gV2hhdCBpZiBzb21lb25lIHJlcXVlc3RzIHRvIG1hcmsgYSBG Q0ZTIFByb3Zpc2lvbmFsIHNjaGVtYSwgaG93IHNob3VsZCBJQU5BDQo+IHByb2Nlc3MgdGhlIHJl cXVlc3Q/DQoNCkJ5ICJtYXJrIiwgZG8geW91IG1lYW4gYWRkaW5nIGEgbm90ZSBpbiB0aGUgTm90 ZXMgY29sdW1uPyAgSWYgc28sIFNlY3Rpb24gOSBzYXlzOg0KDQogICBvICBDb21iaW5lIHRoZSAi UGVybWFuZW50IFVSSSBTY2hlbWVzIiwgIlByb3Zpc2lvbmFsIFVSSSBTY2hlbWVzIiwNCiAgICAg IGFuZCAiSGlzdG9yaWNhbCBVUkkgU2NoZW1lcyIgc3ViLXJlZ2lzdHJpZXMgaW50byBhIHNpbmds ZSBjb21tb24NCiAgICAgIHJlZ2lzdHJ5IHdpdGggYW4gYWRkaXRpb25hbCAiU3RhdHVzIiBjb2x1 bW4gY29udGFpbmluZyB0aGUgc3RhdHVzDQogICAgICAoUGVybWFuZW50LCBQcm92aXNpb25hbCwg SGlzdG9yaWNhbCwgb3IgUGVuZGluZyBSZXZpZXcpLCBhbmQgYW4NCiAgICAgIGFkZGl0aW9uYWwg Ik5vdGVzIiBjb2x1bW4gd2hpY2ggaXMgbm9ybWFsbHkgZW1wdHksIGJ1dCBtYXkgY29udGFpbg0K ICAgICAgbm90ZXMgYXBwcm92ZWQgYnkgdGhlIERlc2lnbmF0ZWQgRXhwZXJ0Lg0KDQpTbyB0aGUg YW5zd2VyIGZyb20gdGhlIGxhc3QgcXVvdGVkIHNlbnRlbmNlIGlzIHRoYXQgYW55IG5vdGUgaGFz IHRvIGJlIGFwcHJvdmVkDQpieSB0aGUgRGVzaWduYXRlZCBFeHBlcnQgKHJlZ2FyZGxlc3Mgb2Yg dGhlIHN0YXR1cyBvZiB0aGUgZW50cnkpLg0KDQpEYXZlDQo= From nobody Wed Mar 11 11:16:22 2015 Return-Path: X-Original-To: expand-draft-ietf-appsawg-uri-scheme-reg.all@virtual.ietf.org Delivered-To: apps-discuss@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 3D38F1A1DBE; Wed, 11 Mar 2015 11:16:18 -0700 (PDT) X-Original-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D8691A1BE5; Wed, 11 Mar 2015 11:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ySe0-UTf4ZWo; Wed, 11 Mar 2015 11:16:16 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0771.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::771]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF64A1A1BC2; Wed, 11 Mar 2015 11:16:12 -0700 (PDT) Received: from BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) by BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) with Microsoft SMTP Server (TLS) id 15.1.106.11; Wed, 11 Mar 2015 18:15:54 +0000 Received: from BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) by BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) with mapi id 15.01.0106.007; Wed, 11 Mar 2015 18:15:54 +0000 From: Dave Thaler To: "drafts-lastcall@iana.org" Thread-Topic: [IANA #810446] Last Call: (Guidelines and Registration Procedures for URI Schemes) to Best Current Practice Thread-Index: AQHQXB/FAGCDJE6Ak0Kh1XBZOc3TEJ0XlKpA Date: Wed, 11 Mar 2015 18:15:54 +0000 Message-ID: References: <20150226200519.21140.53651.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e0:ee43::3] authentication-results: iana.org; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB412; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(51704005)(40100003)(122556002)(2950100001)(77156002)(110136001)(92566002)(62966003)(87936001)(2351001)(76576001)(106116001)(46102003)(2656002)(2501003)(54356999)(230783001)(74316001)(77096005)(102836002)(2900100001)(86362001)(33656002)(86612001)(76176999)(50986999)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB412; H:BY2PR03MB412.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002009)(5005006); SRVR:BY2PR03MB412; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB412; x-forefront-prvs: 0512CC5201 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Mar 2015 18:15:54.3699 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB412 Archived-At: Cc: "appsawg-chairs@ietf.org" , "draft-ietf-appsawg-uri-scheme-reg.all@ietf.org" , "iesg@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [IANA #810446] Last Call: (Guidelines and Registration Procedures for URI Schemes) to Best Current Practice X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 18:16:18 -0000 UGVhcmwgTGlhbmcgIHdyaXRlczoNCj4gSUFOQSBoYXMgcmV2aWV3ZWQgZHJhZnQtaWV0Zi1hcHBz YXdnLXVyaS1zY2hlbWUtcmVnLTA0LiAgQXV0aG9ycyBzaG91bGQNCj4gcmV2aWV3IHRoZSBjb21t ZW50cyBhbmQvb3IgcXVlc3Rpb25zIGJlbG93LiAgUGxlYXNlIHJlcG9ydCBhbnkgaW5hY2N1cmFj aWVzDQo+IGFuZCByZXNwb25kIHRvIGFueSBxdWVzdGlvbnMgYXMgc29vbiBhcyBwb3NzaWJsZS4N Cj4gDQo+IFdlIHJlY2VpdmVkIHRoZSBmb2xsb3dpbmcgY29tbWVudHMvcXVlc3Rpb25zIGZyb20g dGhlIElBTkEncyByZXZpZXdlcjoNCj4gDQo+IFdlIGhhdmUgcXVlc3Rpb25zIGFib3V0IHNvbWUg b2YgdGhlIElBTkEgYWN0aW9ucyByZXF1ZXN0ZWQgYnkgdGhpcyBkcmFmdC4NCj4gDQo+IElBTkEg dW5kZXJzdGFuZHMgdGhhdCwgdXBvbiBhcHByb3ZhbCBvZiB0aGlzIGRvY3VtZW50LCB0aGVyZSBh cmUgZm91ciBhY3Rpb25zDQo+IHdoaWNoIElBTkEgbXVzdCBjb21wbGV0ZS4NCg0KWW91ciBzdW1t YXJ5IGxvb2tzIGNvcnJlY3QuICBSZXNwb25zZXMgdG8gcXVlc3Rpb25zIGJlbG93Lg0KDQpbLi4u XQ0KPiBTZWNvbmQsIHRoaXMgZHJhZnQgdXBkYXRlcyB0aGUgcmVnaXN0cmF0aW9uIHByb2NlZHVy ZXMgZm9yIHRoZSBVbmlmb3JtIFJlc291cmNlDQo+IElkZW50aWZpZXIgKFVSSSkgU2NoZW1lcyBy ZWdpc3RyeSB0byB0aGUgZm9sbG93aW5nOg0KPiANCj4gIlBlcm1hbmVudCBVUkkgU2NoZW1lcyI6 IChObyBjaGFuZ2UpDQo+IEV4cGVydCBSZXZpZXcNCj4gDQo+ICJQcm92aXNpb25hbCBVUkkgU2No ZW1lcyI6DQo+IE9MRDoNCj4gRXhwZXJ0IFJldmlldw0KPiANCj4gTkVXOg0KPiAgRmlyc3QgQ29t ZSBGaXJzdCBTZXJ2ZWQNCj4gDQo+ICJIaXN0b3JpY2FsIFVSSSBTY2hlbWVzIjoNCj4gRXhwZXJ0 IFJldmlldyA/Pz8NCj4gDQo+IFF1ZXN0aW9uOiBXaGF0IGlzIHRoZSBwb2xpY3kgdG8gZGVzaWdu YXRlZCBhIHNjaGVtYSBhcyBoaXN0b3JpY2FsPyAgRXhwZXJ0DQo+IFJldmlldz8NCg0KVGhpcyBp cyBhbnN3ZXJlZCBpbiBTZWN0aW9uIDcuMSBvZiB0aGUgZHJhZnQsIHdoZXJlIHRoZSBmaXJzdCBw YXJhZ3JhcGggc3RhdGVzOg0KDQogICBUaGUgSUFOQSBwb2xpY3kgKHVzaW5nIHRlcm1zIGRlZmlu ZWQgaW4gW1JGQzUyMjZdKSBmb3IgUHJvdmlzaW9uYWwNCiAgIHJlZ2lzdHJhdGlvbiB3YXMgZm9y bWVybHkgRXhwZXJ0IFJldmlldyBhbmQgaXMgbm93IGNoYW5nZWQgdG8gc2ltcGx5DQogICB1c2Ug YSBGaXJzdCBDb21lIEZpcnN0IFNlcnZlZCBwb2xpY3kuICBUaGUgcG9saWN5IGZvciBQZXJtYW5l bnQgYW5kDQogICBIaXN0b3JpYyByZWdpc3RyYXRpb24gY29udGludWVzIHRvIGJlIEV4cGVydCBS ZXZpZXcuDQoNClRoZSBsYXN0IHNlbnRlbmNlIHF1b3RlZCBhYm92ZSBpcyB0aGUgYW5zd2VyIHRv IHlvdXIgcXVlc3Rpb24uDQoNCj4gV2hhdCBpZiBzb21lb25lIHJlcXVlc3RzIHRvIG1hcmsgYSBG Q0ZTIFByb3Zpc2lvbmFsIHNjaGVtYSwgaG93IHNob3VsZCBJQU5BDQo+IHByb2Nlc3MgdGhlIHJl cXVlc3Q/DQoNCkJ5ICJtYXJrIiwgZG8geW91IG1lYW4gYWRkaW5nIGEgbm90ZSBpbiB0aGUgTm90 ZXMgY29sdW1uPyAgSWYgc28sIFNlY3Rpb24gOSBzYXlzOg0KDQogICBvICBDb21iaW5lIHRoZSAi UGVybWFuZW50IFVSSSBTY2hlbWVzIiwgIlByb3Zpc2lvbmFsIFVSSSBTY2hlbWVzIiwNCiAgICAg IGFuZCAiSGlzdG9yaWNhbCBVUkkgU2NoZW1lcyIgc3ViLXJlZ2lzdHJpZXMgaW50byBhIHNpbmds ZSBjb21tb24NCiAgICAgIHJlZ2lzdHJ5IHdpdGggYW4gYWRkaXRpb25hbCAiU3RhdHVzIiBjb2x1 bW4gY29udGFpbmluZyB0aGUgc3RhdHVzDQogICAgICAoUGVybWFuZW50LCBQcm92aXNpb25hbCwg SGlzdG9yaWNhbCwgb3IgUGVuZGluZyBSZXZpZXcpLCBhbmQgYW4NCiAgICAgIGFkZGl0aW9uYWwg Ik5vdGVzIiBjb2x1bW4gd2hpY2ggaXMgbm9ybWFsbHkgZW1wdHksIGJ1dCBtYXkgY29udGFpbg0K ICAgICAgbm90ZXMgYXBwcm92ZWQgYnkgdGhlIERlc2lnbmF0ZWQgRXhwZXJ0Lg0KDQpTbyB0aGUg YW5zd2VyIGZyb20gdGhlIGxhc3QgcXVvdGVkIHNlbnRlbmNlIGlzIHRoYXQgYW55IG5vdGUgaGFz IHRvIGJlIGFwcHJvdmVkDQpieSB0aGUgRGVzaWduYXRlZCBFeHBlcnQgKHJlZ2FyZGxlc3Mgb2Yg dGhlIHN0YXR1cyBvZiB0aGUgZW50cnkpLg0KDQpEYXZlDQo= From nobody Wed Mar 11 11:44:21 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 096EB1A6ED9; Wed, 11 Mar 2015 11:44:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NzTia-AiBV66; Wed, 11 Mar 2015 11:44:19 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4F881A0430; Wed, 11 Mar 2015 11:44:18 -0700 (PDT) Received: by lamq1 with SMTP id q1so10796793lam.12; Wed, 11 Mar 2015 11:44:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=c8+GhpyxV8cxpSASjVJWFChPVR9siyJV3f+BRqbNUKE=; b=qrs6EeGOw8aKuSaaZcmjnpB7OhiXhrixXXAaQah0P8TeAACx+mJK5sJaaCsGlevBgo XaeSAes6nB/Z7x6eZU4lZ/0ezg+4jcFMJHViQ1mnYZ+dmsx6BK7Mr/KvinWpQdLu1cbQ Sa09UEiE6aLGo2vFmAnp5d4iVGcWo5o8yoAogG5a9onYcElVxMrG81PprUS/W5qSxhaJ mkv9tmQS9eIeMmEVkk3baeYLPEmSVi8JCuW39QwKjPusvz0Bvl2/4CkBnUqimyixV2wR TKFuB8ObgahHBw4j5GkH0twT5uGsQwUCozf1lVZJaarUtRhA6LL9NlBOCyWPNeVrnxBU P7ow== MIME-Version: 1.0 X-Received: by 10.112.148.38 with SMTP id tp6mr35639879lbb.82.1426099457219; Wed, 11 Mar 2015 11:44:17 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.183.34 with HTTP; Wed, 11 Mar 2015 11:44:17 -0700 (PDT) In-Reply-To: References: <20150226200519.21140.53651.idtracker@ietfa.amsl.com> Date: Wed, 11 Mar 2015 14:44:17 -0400 X-Google-Sender-Auth: GE4eNI67wo90nUxlA3awAWwYZCA Message-ID: From: Barry Leiba To: Dave Thaler Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: "appsawg-chairs@ietf.org" , "drafts-lastcall@iana.org" , "draft-ietf-appsawg-uri-scheme-reg.all@ietf.org" , "iesg@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [IANA #810446] Last Call: (Guidelines and Registration Procedures for URI Schemes) to Best Current Practice X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 18:44:20 -0000 >> What if someone requests to mark a FCFS Provisional schema, how should IANA >> process the request? > > By "mark", do you mean adding a note in the Notes column? If so, Section 9 says: > > o Combine the "Permanent URI Schemes", "Provisional URI Schemes", > and "Historical URI Schemes" sub-registries into a single common > registry with an additional "Status" column containing the status > (Permanent, Provisional, Historical, or Pending Review), and an > additional "Notes" column which is normally empty, but may contain > notes approved by the Designated Expert. > > So the answer from the last quoted sentence is that any note has to be approved > by the Designated Expert (regardless of the status of the entry). No, by "mark" I think Pearl means changing the value of the Status column from Provisional to Historical: does that change require expert review? Clearly, changing from Provisional to Permanent would, and, on the surface, a change from Provisional to Historical is the same (moving from an FCFS status to an Expert Review status). Is that what you want? Barry From nobody Wed Mar 11 11:44:23 2015 Return-Path: X-Original-To: expand-draft-ietf-appsawg-uri-scheme-reg.all@virtual.ietf.org Delivered-To: apps-discuss@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 2AF2F1A6F15; Wed, 11 Mar 2015 11:44:20 -0700 (PDT) X-Original-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 096EB1A6ED9; Wed, 11 Mar 2015 11:44:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NzTia-AiBV66; Wed, 11 Mar 2015 11:44:19 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4F881A0430; Wed, 11 Mar 2015 11:44:18 -0700 (PDT) Received: by lamq1 with SMTP id q1so10796793lam.12; Wed, 11 Mar 2015 11:44:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=c8+GhpyxV8cxpSASjVJWFChPVR9siyJV3f+BRqbNUKE=; b=qrs6EeGOw8aKuSaaZcmjnpB7OhiXhrixXXAaQah0P8TeAACx+mJK5sJaaCsGlevBgo XaeSAes6nB/Z7x6eZU4lZ/0ezg+4jcFMJHViQ1mnYZ+dmsx6BK7Mr/KvinWpQdLu1cbQ Sa09UEiE6aLGo2vFmAnp5d4iVGcWo5o8yoAogG5a9onYcElVxMrG81PprUS/W5qSxhaJ mkv9tmQS9eIeMmEVkk3baeYLPEmSVi8JCuW39QwKjPusvz0Bvl2/4CkBnUqimyixV2wR TKFuB8ObgahHBw4j5GkH0twT5uGsQwUCozf1lVZJaarUtRhA6LL9NlBOCyWPNeVrnxBU P7ow== MIME-Version: 1.0 X-Received: by 10.112.148.38 with SMTP id tp6mr35639879lbb.82.1426099457219; Wed, 11 Mar 2015 11:44:17 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.183.34 with HTTP; Wed, 11 Mar 2015 11:44:17 -0700 (PDT) In-Reply-To: References: <20150226200519.21140.53651.idtracker@ietfa.amsl.com> Date: Wed, 11 Mar 2015 14:44:17 -0400 X-Google-Sender-Auth: GE4eNI67wo90nUxlA3awAWwYZCA Message-ID: From: Barry Leiba To: Dave Thaler Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: "appsawg-chairs@ietf.org" , "drafts-lastcall@iana.org" , "draft-ietf-appsawg-uri-scheme-reg.all@ietf.org" , "iesg@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [IANA #810446] Last Call: (Guidelines and Registration Procedures for URI Schemes) to Best Current Practice X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 18:44:20 -0000 >> What if someone requests to mark a FCFS Provisional schema, how should IANA >> process the request? > > By "mark", do you mean adding a note in the Notes column? If so, Section 9 says: > > o Combine the "Permanent URI Schemes", "Provisional URI Schemes", > and "Historical URI Schemes" sub-registries into a single common > registry with an additional "Status" column containing the status > (Permanent, Provisional, Historical, or Pending Review), and an > additional "Notes" column which is normally empty, but may contain > notes approved by the Designated Expert. > > So the answer from the last quoted sentence is that any note has to be approved > by the Designated Expert (regardless of the status of the entry). No, by "mark" I think Pearl means changing the value of the Status column from Provisional to Historical: does that change require expert review? Clearly, changing from Provisional to Permanent would, and, on the surface, a change from Provisional to Historical is the same (moving from an FCFS status to an Expert Review status). Is that what you want? Barry From nobody Wed Mar 11 12:05:52 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48F071A0149; Wed, 11 Mar 2015 12:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16PJC2VoBKqz; Wed, 11 Mar 2015 12:05:49 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0125.outbound.protection.outlook.com [207.46.100.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBD581A0430; Wed, 11 Mar 2015 12:05:46 -0700 (PDT) Received: from BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) by BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) with Microsoft SMTP Server (TLS) id 15.1.106.11; Wed, 11 Mar 2015 19:05:45 +0000 Received: from BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) by BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) with mapi id 15.01.0106.007; Wed, 11 Mar 2015 19:05:45 +0000 From: Dave Thaler To: Barry Leiba Thread-Topic: [IANA #810446] Last Call: (Guidelines and Registration Procedures for URI Schemes) to Best Current Practice Thread-Index: AQHQXB/FAGCDJE6Ak0Kh1XBZOc3TEJ0XlKpAgAAJ14CAAAU+YA== Date: Wed, 11 Mar 2015 19:05:44 +0000 Message-ID: References: <20150226200519.21140.53651.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e0:ee43::3] authentication-results: computer.org; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB412; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(51704005)(77096005)(230783001)(74316001)(54356999)(46102003)(106116001)(2656002)(93886004)(86612001)(33656002)(50986999)(76176999)(99286002)(86362001)(2900100001)(102836002)(2950100001)(40100003)(122556002)(77156002)(87936001)(76576001)(110136001)(92566002)(62966003)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB412; H:BY2PR03MB412.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002009)(5005006); SRVR:BY2PR03MB412; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB412; x-forefront-prvs: 0512CC5201 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Mar 2015 19:05:44.8790 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB412 Archived-At: Cc: "appsawg-chairs@ietf.org" , "drafts-lastcall@iana.org" , "draft-ietf-appsawg-uri-scheme-reg.all@ietf.org" , "iesg@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [IANA #810446] Last Call: (Guidelines and Registration Procedures for URI Schemes) to Best Current Practice X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 19:05:50 -0000 Barry Leiba writes:=20 > >> What if someone requests to mark a FCFS Provisional schema, how > >> should IANA process the request? > > > > By "mark", do you mean adding a note in the Notes column? If so, Secti= on 9 > says: > > > > o Combine the "Permanent URI Schemes", "Provisional URI Schemes", > > and "Historical URI Schemes" sub-registries into a single common > > registry with an additional "Status" column containing the status > > (Permanent, Provisional, Historical, or Pending Review), and an > > additional "Notes" column which is normally empty, but may contai= n > > notes approved by the Designated Expert. > > > > So the answer from the last quoted sentence is that any note has to be > > approved by the Designated Expert (regardless of the status of the entr= y). >=20 > No, by "mark" I think Pearl means changing the value of the Status column= from > Provisional to Historical: does that change require expert review? Clear= ly, > changing from Provisional to Permanent would, and, on the surface, a chan= ge > from Provisional to Historical is the same (moving from an FCFS status to= an > Expert Review status). Is that what you want? That is the current answer that by default (since it's not a change from be= fore) has WG (and presumably IETF) consensus because it did before. However I don't think the WG explicitly discussed whether the answer to that question should change from current practice. Dave From nobody Wed Mar 11 12:05:54 2015 Return-Path: X-Original-To: expand-draft-ietf-appsawg-uri-scheme-reg.all@virtual.ietf.org Delivered-To: apps-discuss@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 6ECDB1A0430; Wed, 11 Mar 2015 12:05:50 -0700 (PDT) X-Original-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48F071A0149; Wed, 11 Mar 2015 12:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16PJC2VoBKqz; Wed, 11 Mar 2015 12:05:49 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0125.outbound.protection.outlook.com [207.46.100.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBD581A0430; Wed, 11 Mar 2015 12:05:46 -0700 (PDT) Received: from BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) by BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) with Microsoft SMTP Server (TLS) id 15.1.106.11; Wed, 11 Mar 2015 19:05:45 +0000 Received: from BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) by BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) with mapi id 15.01.0106.007; Wed, 11 Mar 2015 19:05:45 +0000 From: Dave Thaler To: Barry Leiba Thread-Topic: [IANA #810446] Last Call: (Guidelines and Registration Procedures for URI Schemes) to Best Current Practice Thread-Index: AQHQXB/FAGCDJE6Ak0Kh1XBZOc3TEJ0XlKpAgAAJ14CAAAU+YA== Date: Wed, 11 Mar 2015 19:05:44 +0000 Message-ID: References: <20150226200519.21140.53651.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e0:ee43::3] authentication-results: computer.org; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB412; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(51704005)(77096005)(230783001)(74316001)(54356999)(46102003)(106116001)(2656002)(93886004)(86612001)(33656002)(50986999)(76176999)(99286002)(86362001)(2900100001)(102836002)(2950100001)(40100003)(122556002)(77156002)(87936001)(76576001)(110136001)(92566002)(62966003)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB412; H:BY2PR03MB412.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002009)(5005006); SRVR:BY2PR03MB412; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB412; x-forefront-prvs: 0512CC5201 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Mar 2015 19:05:44.8790 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB412 Archived-At: Cc: "appsawg-chairs@ietf.org" , "drafts-lastcall@iana.org" , "draft-ietf-appsawg-uri-scheme-reg.all@ietf.org" , "iesg@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [IANA #810446] Last Call: (Guidelines and Registration Procedures for URI Schemes) to Best Current Practice X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 19:05:50 -0000 Barry Leiba writes:=20 > >> What if someone requests to mark a FCFS Provisional schema, how > >> should IANA process the request? > > > > By "mark", do you mean adding a note in the Notes column? If so, Secti= on 9 > says: > > > > o Combine the "Permanent URI Schemes", "Provisional URI Schemes", > > and "Historical URI Schemes" sub-registries into a single common > > registry with an additional "Status" column containing the status > > (Permanent, Provisional, Historical, or Pending Review), and an > > additional "Notes" column which is normally empty, but may contai= n > > notes approved by the Designated Expert. > > > > So the answer from the last quoted sentence is that any note has to be > > approved by the Designated Expert (regardless of the status of the entr= y). >=20 > No, by "mark" I think Pearl means changing the value of the Status column= from > Provisional to Historical: does that change require expert review? Clear= ly, > changing from Provisional to Permanent would, and, on the surface, a chan= ge > from Provisional to Historical is the same (moving from an FCFS status to= an > Expert Review status). Is that what you want? That is the current answer that by default (since it's not a change from be= fore) has WG (and presumably IETF) consensus because it did before. However I don't think the WG explicitly discussed whether the answer to that question should change from current practice. Dave From nobody Wed Mar 11 12:45:16 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E05831A86F2; Wed, 11 Mar 2015 12:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MHy98vSz-jv1; Wed, 11 Mar 2015 12:45:13 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2C331A86E4; Wed, 11 Mar 2015 12:45:08 -0700 (PDT) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id 04b90055.0.2111446.00-2283.5892340.nbfkord-smmo05.seg.att.com (envelope-from ); Wed, 11 Mar 2015 19:45:08 +0000 (UTC) X-MXL-Hash: 55009b444d280274-4b53787c9b09a97e0918e9a5a2e6e52ffd6ae4cd Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t2BJj4dn024282; Wed, 11 Mar 2015 15:45:04 -0400 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t2BJixEK024191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 11 Mar 2015 15:45:00 -0400 Received: from alpi153.aldc.att.com (alpi153.aldc.att.com [130.8.42.31]) by alpi132.aldc.att.com (RSA Interceptor); Wed, 11 Mar 2015 19:44:41 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 t2BJifis026850; Wed, 11 Mar 2015 15:44:41 -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 t2BJiZWF026553; Wed, 11 Mar 2015 15:44:35 -0400 Received: from tonys-macbook-pro.local (unknown[135.110.241.237](untrusted sender)) by maillennium.att.com (mailgw1) with ESMTP id <20150311194433gw1000cek3e>; Wed, 11 Mar 2015 19:44:35 +0000 X-Originating-IP: [135.110.241.237] Message-ID: <55009B20.1080407@att.com> Date: Wed, 11 Mar 2015 15:44:32 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Dave Thaler , Barry Leiba References: <20150226200519.21140.53651.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=Y51PRGiN c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=CA33sFktnKwA:10 a=nB5KrqegNggA:10 a=BLceEmwcHowA:10 a=N65] X-AnalysisOut: [9UExz7-8A:10 a=zQP7CpKOAAAA:8 a=emO1SXQWCLwA:10 a=72oeruQT] X-AnalysisOut: [8wBFL5uO_v0A:9 a=pILNOxqGKmIA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: Cc: "appsawg-chairs@ietf.org" , "drafts-lastcall@iana.org" , "draft-ietf-appsawg-uri-scheme-reg.all@ietf.org" , "iesg@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [IANA #810446] Last Call: (Guidelines and Registration Procedures for URI Schemes) to Best Current Practice X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 19:45:15 -0000 I think Pearl should be asked to clarify her question. I read her question differently from either of you. Tony On 3/11/15 3:05 PM, Dave Thaler wrote: > Barry Leiba writes: >>>> What if someone requests to mark a FCFS Provisional schema, how >>>> should IANA process the request? >>> By "mark", do you mean adding a note in the Notes column? If so, Section 9 >> says: >>> o Combine the "Permanent URI Schemes", "Provisional URI Schemes", >>> and "Historical URI Schemes" sub-registries into a single common >>> registry with an additional "Status" column containing the status >>> (Permanent, Provisional, Historical, or Pending Review), and an >>> additional "Notes" column which is normally empty, but may contain >>> notes approved by the Designated Expert. >>> >>> So the answer from the last quoted sentence is that any note has to be >>> approved by the Designated Expert (regardless of the status of the entry). >> No, by "mark" I think Pearl means changing the value of the Status column from >> Provisional to Historical: does that change require expert review? Clearly, >> changing from Provisional to Permanent would, and, on the surface, a change >> from Provisional to Historical is the same (moving from an FCFS status to an >> Expert Review status). Is that what you want? > That is the current answer that by default (since it's not a change from before) > has WG (and presumably IETF) consensus because it did before. However I > don't think the WG explicitly discussed whether the answer to that question > should change from current practice. > > Dave > > From nobody Wed Mar 11 12:45:19 2015 Return-Path: X-Original-To: expand-draft-ietf-appsawg-uri-scheme-reg.all@virtual.ietf.org Delivered-To: apps-discuss@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 0D4AD1A86FF; Wed, 11 Mar 2015 12:45:15 -0700 (PDT) X-Original-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E05831A86F2; Wed, 11 Mar 2015 12:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MHy98vSz-jv1; Wed, 11 Mar 2015 12:45:13 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2C331A86E4; Wed, 11 Mar 2015 12:45:08 -0700 (PDT) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id 04b90055.0.2111446.00-2283.5892340.nbfkord-smmo05.seg.att.com (envelope-from ); Wed, 11 Mar 2015 19:45:08 +0000 (UTC) X-MXL-Hash: 55009b444d280274-4b53787c9b09a97e0918e9a5a2e6e52ffd6ae4cd Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t2BJj4dn024282; Wed, 11 Mar 2015 15:45:04 -0400 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t2BJixEK024191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 11 Mar 2015 15:45:00 -0400 Received: from alpi153.aldc.att.com (alpi153.aldc.att.com [130.8.42.31]) by alpi132.aldc.att.com (RSA Interceptor); Wed, 11 Mar 2015 19:44:41 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 t2BJifis026850; Wed, 11 Mar 2015 15:44:41 -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 t2BJiZWF026553; Wed, 11 Mar 2015 15:44:35 -0400 Received: from tonys-macbook-pro.local (unknown[135.110.241.237](untrusted sender)) by maillennium.att.com (mailgw1) with ESMTP id <20150311194433gw1000cek3e>; Wed, 11 Mar 2015 19:44:35 +0000 X-Originating-IP: [135.110.241.237] Message-ID: <55009B20.1080407@att.com> Date: Wed, 11 Mar 2015 15:44:32 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Dave Thaler , Barry Leiba References: <20150226200519.21140.53651.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=Y51PRGiN c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=CA33sFktnKwA:10 a=nB5KrqegNggA:10 a=BLceEmwcHowA:10 a=N65] X-AnalysisOut: [9UExz7-8A:10 a=zQP7CpKOAAAA:8 a=emO1SXQWCLwA:10 a=72oeruQT] X-AnalysisOut: [8wBFL5uO_v0A:9 a=pILNOxqGKmIA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: Cc: "appsawg-chairs@ietf.org" , "drafts-lastcall@iana.org" , "draft-ietf-appsawg-uri-scheme-reg.all@ietf.org" , "iesg@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [IANA #810446] Last Call: (Guidelines and Registration Procedures for URI Schemes) to Best Current Practice X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 19:45:15 -0000 I think Pearl should be asked to clarify her question. I read her question differently from either of you. Tony On 3/11/15 3:05 PM, Dave Thaler wrote: > Barry Leiba writes: >>>> What if someone requests to mark a FCFS Provisional schema, how >>>> should IANA process the request? >>> By "mark", do you mean adding a note in the Notes column? If so, Section 9 >> says: >>> o Combine the "Permanent URI Schemes", "Provisional URI Schemes", >>> and "Historical URI Schemes" sub-registries into a single common >>> registry with an additional "Status" column containing the status >>> (Permanent, Provisional, Historical, or Pending Review), and an >>> additional "Notes" column which is normally empty, but may contain >>> notes approved by the Designated Expert. >>> >>> So the answer from the last quoted sentence is that any note has to be >>> approved by the Designated Expert (regardless of the status of the entry). >> No, by "mark" I think Pearl means changing the value of the Status column from >> Provisional to Historical: does that change require expert review? Clearly, >> changing from Provisional to Permanent would, and, on the surface, a change >> from Provisional to Historical is the same (moving from an FCFS status to an >> Expert Review status). Is that what you want? > That is the current answer that by default (since it's not a change from before) > has WG (and presumably IETF) consensus because it did before. However I > don't think the WG explicitly discussed whether the answer to that question > should change from current practice. > > Dave > > From nobody Wed Mar 11 18:29:57 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A63B31A89AB for ; Wed, 11 Mar 2015 18:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.812 X-Spam-Level: X-Spam-Status: No, score=-0.812 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_44=0.6, J_CHICKENPOX_48=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xIE2C9eeXesl for ; Wed, 11 Mar 2015 18:29:56 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 02DEA1A8993 for ; Wed, 11 Mar 2015 18:29:56 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PJHO9ZX9CW00CRWC@mauve.mrochek.com> for apps-discuss@ietf.org; Wed, 11 Mar 2015 18:24:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1426123492; bh=/rhoz6G9VO+SIK79NxEAp9VZhUfpPtO3YRRMRsKmn10=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=p7I7AFm4rUTU06PzW5LXRAcimfWKjjGLM/jiL1zoK+JXXrXuW3PyRtfxM92dGqQqz 0thl/l1fJQmJq6m/EJTgKc+HKnJ+RR1APUqouSlTCqrobMjyhS8C07Sd25c5Y/aMCI FdR7xs8C3MbYKF0mbdGNRsXcO14Um8y3n3ZUbll8= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PJ6KCZSXQ80000AQ@mauve.mrochek.com>; Wed, 11 Mar 2015 18:24:46 -0700 (PDT) Message-id: <01PJHO9WJ8CY0000AQ@mauve.mrochek.com> Date: Wed, 11 Mar 2015 18:21:05 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 10 Mar 2015 13:34:15 -0400" References: <1745871.VmxIvUMNcD@kitterma-e6430> <20150310020928.33511.qmail@ary.lan> <01PJFSVXS0XW0000AQ@mauve.mrochek.com> To: John R Levine Archived-At: Cc: Ned Freed , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc7001bis-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 01:29:56 -0000 > >> The interesting bit to record is smtp.auth with the username as the > >> value. I think the official name for the username is the > >> authentication identity. > > > > But if you want to pass that information along from an ingress system > > to another system along a trusted path, the MAIL FROM AUTH parameter is > > the obvous way to do it. > I'd have no objection to allowing both smtp.auth and smtp.mailfrom ptypes. > It'd be at worst harmless. Seems reasonable. > > We do. And we have lots of customers using it. AUTH EXTERNAL in particular is a > > requirement in quite a few places. > When someone uses AUTH EXTERNAL, is the authorized identity anything that > couldn't be recorded in the smtp.auth clause? It's certainly possible in theory, but as a practical matter, there's usually an identifier of some sort attached to the identity. A better question, in the case of AUTH EXTERNAL, is whether there's a need to log additional information. A fingerprint for the certificate that was used comes to mind as a possibility. Ned From nobody Wed Mar 11 18:48:11 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2AD71A898E for ; Wed, 11 Mar 2015 18:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.537 X-Spam-Level: X-Spam-Status: No, score=-0.537 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_44=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ObHkNhRyD6qm for ; Wed, 11 Mar 2015 18:48:08 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 936E61A898F for ; Wed, 11 Mar 2015 18:48:08 -0700 (PDT) Received: (qmail 30868 invoked from network); 12 Mar 2015 01:48:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=7893.5500f057.k1503; bh=DBzB315P3M6xW8Otm8FwNZISs4Ru6xueZoGFMS5n43I=; b=gsxFgr0PvaBqx8Fg+AjRddAESbcs13DWKaqRjsvAc+JRNHta3nc+kNw2hpZkQm8oN92+zBwZ+mIxjjk+/Qm/c9KU24ls08Uljj23I9lRF7WOtexI40RJzqKzzUWYAVk+1ouHvpyGHQsp6uuaTDGSeErmsRMOUjh2g/3n7P4LKO3R/i07+X/dPbHnKYhrtpY5a8oe0oa75V0sHwJ1d6C13IxrpslaiXIG3iryMz3l3ZxrcFDNsfW0WQYouuxerpJm DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=7893.5500f057.k1503; bh=DBzB315P3M6xW8Otm8FwNZISs4Ru6xueZoGFMS5n43I=; b=aOHseW3uYmYIAxUKPYkOiTRrn+48U+rVy4bQH2TNjDdPjNlwNzDznzV2PQOIC/Q6zIIFIcP3Xwo9otAN/zl7Q3RKgA3TlXBwMA/J2J8DGqNyPeoUCcyUHpth6z7kjVq+jbyFekPv1CrniJ45mPF9HsZqUz338smNZC6kKDgo8cuANqDUahCEgn6ucHnopOqu/uZgo2bM6HAOQojbhLsTM9RPUHaqwLuUxq1TUT7SQv0IKwN5QhiL6SL1afBW9x9q Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 12 Mar 2015 01:48:07 -0000 Date: 11 Mar 2015 21:48:06 -0400 Message-ID: From: "John R Levine" To: "Ned Freed" In-Reply-To: <01PJHO9WJ8CY0000AQ@mauve.mrochek.com> References: <1745871.VmxIvUMNcD@kitterma-e6430> <20150310020928.33511.qmail@ary.lan> <01PJFSVXS0XW0000AQ@mauve.mrochek.com> <01PJHO9WJ8CY0000AQ@mauve.mrochek.com> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc7001bis-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 01:48:10 -0000 >> When someone uses AUTH EXTERNAL, is the authorized identity anything that >> couldn't be recorded in the smtp.auth clause? > > It's certainly possible in theory, but as a practical matter, there's usually > an identifier of some sort attached to the identity. > > A better question, in the case of AUTH EXTERNAL, is whether there's a need > to log additional information. A fingerprint for the certificate that > was used comes to mind as a possibility. Since this is an expert review registry, how about just leaving it as is, and if someone actually starts logging fingerprints or whatever, encourage them to write in and we'll add it to the registry. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Thu Mar 12 00:08:53 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E10F1A1A02; Thu, 12 Mar 2015 00:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rMFD3Cghq5-K; Thu, 12 Mar 2015 00:08:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B9F11A049C; Thu, 12 Mar 2015 00:08:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: DraftTracker Mail System To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150312070848.663.88211.idtracker@ietfa.amsl.com> Date: Thu, 12 Mar 2015 00:08:48 -0700 Archived-At: Cc: iesg-secretary@ietf.org Subject: [apps-discuss] Last Call Expired: X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 07:08:52 -0000 Please DO NOT reply to this email. I-D: ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-uri-scheme-reg/ IETF Last Call has ended, and the state has been changed to Waiting for AD Go-Ahead. From nobody Thu Mar 12 00:08:56 2015 Return-Path: X-Original-To: expand-draft-ietf-appsawg-uri-scheme-reg.all@virtual.ietf.org Delivered-To: apps-discuss@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 7D04D1A049C; Thu, 12 Mar 2015 00:08:52 -0700 (PDT) X-Original-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E10F1A1A02; Thu, 12 Mar 2015 00:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rMFD3Cghq5-K; Thu, 12 Mar 2015 00:08:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B9F11A049C; Thu, 12 Mar 2015 00:08:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: DraftTracker Mail System To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150312070848.663.88211.idtracker@ietfa.amsl.com> Date: Thu, 12 Mar 2015 00:08:48 -0700 Archived-At: Cc: iesg-secretary@ietf.org Subject: [apps-discuss] Last Call Expired: X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 07:08:52 -0000 Please DO NOT reply to this email. I-D: ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-uri-scheme-reg/ IETF Last Call has ended, and the state has been changed to Waiting for AD Go-Ahead. From nobody Thu Mar 12 03:06:06 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 331671A90D8; Thu, 12 Mar 2015 03:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.401 X-Spam-Level: X-Spam-Status: No, score=-3.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gKXs21qy51ph; Thu, 12 Mar 2015 03:06:01 -0700 (PDT) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id 3EFDF1A90D7; Thu, 12 Mar 2015 03:06:00 -0700 (PDT) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmeg01-14.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id 6C67832E585; Thu, 12 Mar 2015 19:05:15 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 3f60_9e61_cf2e0947_a1c1_4214_93ed_c2695eccb17e; Thu, 12 Mar 2015 19:05:15 +0900 Received: from [133.2.210.64] (unknown [133.2.210.64]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 832A5BF521; Thu, 12 Mar 2015 19:05:14 +0900 (JST) Message-ID: <550164DD.6020509@it.aoyama.ac.jp> Date: Thu, 12 Mar 2015 19:05:17 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "apps-discuss@ietf.org" , Larry Masinter , Ted Hardie , Tony Hansen , Dave Thaler , IETF discussion list Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [apps-discuss] Last Call: (Guidelines and Registration Procedures for URI Schemes) to Best Current Practice X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 10:06:05 -0000 Here are some last call comments on=20 draft-ietf-appsawg-uri-scheme-reg-04. The review was started a while=20 ago, and completed, but the writeup took a lot of time and is still not=20 completed, sorry. I may be able to complete it tomorrow, but please=20 don't hold your breath. [Just in case this is necessary, as a process point, I have seen various=20 tracker messages (such as the draft being placed on telechat, or that=20 the last call has ended), but I'd like to note that the Last Call=20 mentions an end date of 2015-03-12, and it's still 2015-03-12 here in=20 Japan, which means that this date has barely started in some other=20 locations around the world.] My overall impression is that the overall direction of the draft is just=20 fine, but that presentation and wording are quite rough in many places=20 and would tremendously benefit from more careful wording. Introduction: Overall, this felt too long, and it would benefit from=20 better structuring, and/or moving some of the points out to their own=20 sections/subsections. For example, adding subsection titles such as=20 "URIs and IRIs" and "Generic Syntax and Scheme Specific Syntax" or some=20 such would help quite a lot. " o provide a central point of discovery for established URI scheme names, and easy location of defining documents for standard schemes;" The use of the word "standard" in "standard scheme" is unclear. This use=20 doesn't appear anywhere in the document. Do you mean permanently=20 registered schemes? If there's some specific point to be made, please=20 make it more clearly. Otherwise, I suggest to just drop the word "standar= d". "o discourage multiple separate uses of the same scheme name;" I'd personally be happier if this said "strongly discourage", because I=20 hope we all agree that it's really not a good idea. If the consensus is=20 that it's obvious anyway that it's really not a good idea, and we don't=20 need to be overly clear about that, then I'll keep quiet. "o encourage registration by setting a low barrier for registration." What about making this "encourage early registration"? "A URI scheme name is the same as the corresponding IRI scheme name." At the minimum, I'd turn this around and say "An IRI scheme name is the=20 same as the corresponding URI scheme name." But because the there isn't=20 really anything like an "IRI scheme name", I'd actually prefer if this=20 said "IRIs use the same scheme names as URIs." or something similar. "For example, this means that fragment identifiers (#) cannot be re-used=20 outside the generic syntax restrictions." My 'best-guess' interpretation of this sentence is that this intended to=20 say that a scheme definition cannot define fragments that contain=20 characters (e.g. #) that RFC 3986 doesn't allow. But this is bad advice, because scheme definitions cannot say anything=20 about fragments at all. This isn't syntax, but semantics; the semantics=20 of a fragment are defined by the media type, not the scheme. I haven't=20 found any place anywhere in this doc that says this, it clearly should=20 be added. If you want to make an example re. syntax, I'd suggest to say something=20 like "For example, the query part cannot contain literal '#' characters=20 because they and anything after them would be interpreted as part of the=20 fragment and not the query." or some such. Also, the "(#)" in the text is completely superfluous; the '#' itself=20 isn't the fragment, and a reader should be able to correlate the word in=20 the text and the same word in the ABNF. "A scheme definition must specify the scheme name and the syntax of the=20 scheme-specific part, which is clarified as follows:" Saying "clarified as follows" and then just giving some ABNF may be=20 difficult to grok for some people. I propose to change the sentence to "A scheme definition must specify the scheme name and the syntax of the=20 scheme-specific part, which corresponds to the 'hier-part' and the=20 optional query in the above definition. This can be clarified by=20 rewriting the definition as follows:" 2. Terminology: Within this document, the key words MUST, MAY, SHOULD, REQUIRED, RECOMMENDED, and so forth are used within the general meanings established in [RFC2119], within the context that they are requirements on future registrations. The double 'within' is confusing. I propose to replace "within the=20 context that they are requirements on future registrations" with "as=20 requirements on future registrations" 3. Requirements for Permanent Scheme Definitions For IETF Standards-Track documents, Permanent registration status is REQUIRED. Please change this to: "For URI Scheme definitions in IETF=20 Standards-Track documents, Permanent registration status is REQUIRED." 3.2. Syntactic Compatibility Care must be taken to ensure that all strings matching their scheme-specific syntax will also match the grammar described in [RFC3986]. Pronouns like "their" don't usually work well in standard language. I=20 suggest changing "their scheme-specific syntax" to "the syntactic=20 restrictions of the scheme definition" or some such. If there is a strong reason for a scheme not to use the hierarchical syntax, then the new scheme definition SHOULD follow the syntax of previously registered schemes. Please change "the syntax of previously registered schemes" to "the=20 syntax of previously registered schemes with similar components or=20 similar syntactic needs." or some such, to make it clear that it's not=20 sufficient to just copy some syntax if it's totally unrelated. Schemes that are not intended for use with relative URIs SHOULD avoid use of the forward slash "/" character, which is used for hierarchical delimiters, and the complete path segments "." and ".." (dot-segments). It would be good if the text gave the reasons for the SHOULD (which I=20 fully agree with; maybe even a MUST). Please add a(n informational) reference to Gettys, J., "URI Model=20 Consequences", in=20 this section. It is a great text helping designers of URI scheme syntax=20 to understand the ideas regarding the different syntax components. New schemes SHOULD clearly define the role of [RFC3986] reserved characters in URIs of the scheme being defined. The location of [RFC3986] is a bit strange. It might work if "[RFC3986]=20 reserved characters" is taken as a phrase, but it's difficult for the=20 reader to see that. Also, the specific topic is discussed in Section 2.2=20 of [RFC3986], so change the above to: New schemes SHOULD clearly define the role of reserved characters (see [RFC3986], Section 2.2) in URIs of the scheme being defined. 3.3. Well-Defined and how legal values in the base namespace, or legal protocol interactions, might be represented in a valid URI. "might be represented" -> "are represented" See Section 3.6 for guidelines for encoding binary or character strings within valid character sequences in a URI . "binary or character strings" -> "sequences of bytes or characters" (in=20 most contexts (programming languages,...), "character string" is=20 equivalent to "string", while "binary string" is undefined.) Superfluous space before period. If not all legal values or protocol interactions of the base standard can be represented using the scheme, the definition SHOULD be clear about which subset are allowed, and why. "Which subset are" -> "which subset is" (or "which subsets are") 3.5. Context of Use Most commonly, URIs are used as references to resources within directories or hypertext documents, as hyperlinks to other resources. This sentence is totally unclear. Why do directories turn up here? Is=20 "resources within directories" and "other resources" parallels? Are=20 "references" and "hyperlinks" intended to be parallels? Is "references=20 to resources within ..." intended to mean "references to resources from=20 within ..." or "references to (resources within ...)"?. Please clarify. 3.6. Internationalization and Character Encoding When describing schemes in which (some of) the elements of the URI are actually representations of human-readable text, care should be taken not to introduce unnecessary variety in the ways in which characters are encoded into octets and then into URI characters; see [RFC3987] and Section 2.5 of [RFC3986] for guidelines. If URIs of a scheme contain any text fields, the scheme definition MUST describe the ways in which characters are encoded and any compatibility issues with IRIs of the scheme. I think it would be extremely helpful to the average URI scheme=20 designer/describer if this section mentioned the use of UTF-8. The=20 reference to Section 2.5 of RFC 3986 is good, but the problem with that=20 section is that it starts out with very general and abstract language,=20 and one has to read through the whole section to find the relevant (and=20 extremely clear and appropriate) advice in the last paragraph. At a minimum, please point the reader to the last paragraph of Section=20 2.5. Much better would be to include that paragraph verbatim (and saying=20 so explicitly): >>>> When a new URI scheme defines a component that represents textual data consisting of characters from the Universal Character Set [UCS], the data should first be encoded as octets according to the UTF-8 character encoding [STD63]; then only those octets that do not correspond to characters in the unreserved set should be percent- encoded. For example, the character A would be represented as "A", the character LATIN CAPITAL LETTER A WITH GRAVE would be represented as "%C3%80", and the character KATAKANA LETTER A would be represented as "%E3%82%A2". >>>> The scheme specification SHOULD be as restrictive as possible regarding what characters are allowed in the URI, because some characters can create several different security considerations (see, for example [RFC4690]). I'm afraid that many people will read "as restrictive as possible" as=20 "well, let's just do ASCII only" or some such. I believe and hope that=20 this wasn't the intent, but I don't think this comes across. One kind of=20 improvement would be to change "as restrictive as possible" to just=20 "restrictive". Another is to change "as restrictive as possible" to "as=20 restrictive as possible without excluding characters outside US-ASCII". "can create security considerations" sounds weird. The characters may=20 create security issues or security problems or some such, which may need=20 to be described in a security consideration section. All percent-encoded variants are automatically included by definition for any character given in an IRI production. This means that if you want to restrict the URI percent-encoded forms in some way, you must restrict the Unicode forms that would lead to them. I know what you want to say here (I think it's the point originally=20 brought up by Bj=C3=B6rn H=C3=B6hrmann in the IRI WG). But I think it's t= oo=20 restrictive and can be worded better: URI schemes that include textual data from Unicode have to be aware that they have to define both the actual characters allowed (for IRIs) and the corresponding percent-encoded forms (for URIs and IRIs). This can be done in various ways, but in most cases, it is advisable to define the actual characters allowed in an IRI production, to allow the 'pct-encoded' definition from Section 2.1 of [RFC 3986] at the same places, and to add prose that limits percent-escapes to those that can be created by converting valid character sequences to percent-encoding via UTF-8. Regards, Martin. From nobody Thu Mar 12 04:54:22 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 017811A92A9 for ; Thu, 12 Mar 2015 04:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.415 X-Spam-Level: X-Spam-Status: No, score=-0.415 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1T1bopsrEb-1 for ; Thu, 12 Mar 2015 04:54:18 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0722.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::722]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 450E91A924C for ; Thu, 12 Mar 2015 04:54:18 -0700 (PDT) Received: from pc6 (86.185.85.149) by AMXPR07MB054.eurprd07.prod.outlook.com (10.242.67.143) with Microsoft SMTP Server (TLS) id 15.1.106.15; Thu, 12 Mar 2015 11:53:58 +0000 Message-ID: <018e01d05cba$e6ba8400$4001a8c0@gateway.2wire.net> From: t.petch To: "Murray S. Kucherawy" , IETF Apps Discuss Date: Thu, 12 Mar 2015 11:47:07 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.185.85.149] X-ClientProxiedBy: DB4PR01CA0041.eurprd01.prod.exchangelabs.com (10.242.152.31) To AMXPR07MB054.eurprd07.prod.outlook.com (10.242.67.143) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB054; X-Forefront-Antispam-Report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(13464003)(24454002)(51444003)(51704005)(377424004)(377454003)(50986999)(44736004)(44716002)(62236002)(1456003)(107886001)(92566002)(77096005)(15975445007)(40100003)(42186005)(81686999)(81816999)(50466002)(66066001)(47776003)(86362001)(61296003)(50226001)(14496001)(87976001)(62966003)(77156002)(230783001)(122386002)(1556002)(46102003)(19580395003)(84392001)(116806002)(19580405001)(23676002)(33646002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMXPR07MB054; H:pc6; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5002009)(5005006); SRVR:AMXPR07MB054; BCL:0; PCL:0; RULEID:; SRVR:AMXPR07MB054; X-Forefront-PRVS: 05134F8B4F Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Mar 2015 11:53:58.0718 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMXPR07MB054 Archived-At: Subject: Re: [apps-discuss] draft-ietf-appsawg-rfc7001bis s2.7.1 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 11:54:21 -0000 s2.7.1 is fine for DKIM which is well covered in RFC6376 but I do not think that the same can be said for DomainKeys and RFC4870. I think the gulf too wide and would add a small bridge, such as OLD DomainKeys is defined in [DOMAINKEYS] and is represented by the "domainkeys" method. NEW DomainKeys is defined in [DOMAINKEYS] and is represented by the "domainkeys" method. The relevant section for this specification is section 3.3 on the "DomainKey-Signature" header. [assuming I have understood aright] Tom Petch ----- Original Message ----- From: "t.petch" To: "Murray S. Kucherawy" ; "IETF Apps Discuss" Sent: Thursday, March 12, 2015 11:42 AM Subject: draft-ietf-appsawg-rfc7001bis s6.2 > Um > > s 6.2 contains a lot of good information but I struggle to see an IANA > Consideration in there. Is the intention that the reference for "Email > Authentication Methods" be updated to this I-D? If so, I think that > that needs saying. > Also, if that is the only action, then again worth saying to stop IANA > ploughing through this lengthy section to try and find another action. > Also, registries can be very hard to find if you do not know the group > so again worth saying. > > So I would start with > > NEW > The "Email Authentication Methods" Registry is part of the "Email > Authentication Parameters" group. IANA is requested to update the > reference for that registry to point to this I-D. That is the only > change requested by this section. > > Tom Petch > > > ----- Original Message ----- > From: "Murray S. Kucherawy" > To: "IETF Apps Discuss" > Sent: Monday, March 09, 2015 9:34 PM > Subject: Re: [apps-discuss] I-D Action: > draft-ietf-appsawg-rfc7001bis-03.txt > > > > On Mon, Mar 9, 2015 at 2:32 PM, 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 : Message Header Field for Indicating > Message > > > Authentication Status > > > Author : Murray S. Kucherawy > > > Filename : draft-ietf-appsawg-rfc7001bis-03.txt > > > Pages : 46 > > > Date : 2015-03-09 > > > > > > 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 to make sorting and filtering decisions. > > > > > > > This is an attempt to address the concerns expressed, especially by > John > > Levine and Tom Petch. John has seen it and says it resolves his > concerns. > > Everyone, and Tom in particular, do you agree that this is how it > should > > look? > > > > -MSK > > > > > ---------------------------------------------------------------------- -- > -------- > > > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > > > From nobody Thu Mar 12 04:57:38 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB59E1A9240 for ; Thu, 12 Mar 2015 04:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s_CRnUz1t3wT for ; Thu, 12 Mar 2015 04:57:35 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0745.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::745]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1E841A92A9 for ; Thu, 12 Mar 2015 04:57:34 -0700 (PDT) Received: from pc6 (86.185.85.149) by DB3PR07MB057.eurprd07.prod.outlook.com (10.242.137.144) with Microsoft SMTP Server (TLS) id 15.1.112.16; Thu, 12 Mar 2015 11:45:28 +0000 Message-ID: <018601d05cb9$b6fbba00$4001a8c0@gateway.2wire.net> From: t.petch To: "Murray S. Kucherawy" , IETF Apps Discuss References: <20150309213241.21308.78039.idtracker@ietfa.amsl.com> Date: Thu, 12 Mar 2015 11:42:35 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.185.85.149] X-ClientProxiedBy: DB4PR01CA0043.eurprd01.prod.exchangelabs.com (10.242.152.33) To DB3PR07MB057.eurprd07.prod.outlook.com (10.242.137.144) Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB3PR07MB057; X-Forefront-Antispam-Report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(13464003)(51704005)(24454002)(377454003)(51444003)(377424004)(23676002)(122386002)(76176999)(50986999)(19580395003)(81816999)(44736004)(44716002)(46102003)(50226001)(81686999)(1456003)(62236002)(87976001)(1556002)(77096005)(84392001)(14496001)(40100003)(15975445007)(86362001)(50466002)(19580405001)(42186005)(62966003)(61296003)(77156002)(33646002)(116806002)(47776003)(66066001)(107886001)(229853001)(230783001)(92566002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR07MB057; H:pc6; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5002009)(5005006); SRVR:DB3PR07MB057; BCL:0; PCL:0; RULEID:; SRVR:DB3PR07MB057; X-Forefront-PRVS: 05134F8B4F X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Mar 2015 11:45:28.2225 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR07MB057 Archived-At: Subject: [apps-discuss] draft-ietf-appsawg-rfc7001bis s6.2 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 11:57:37 -0000 Um s 6.2 contains a lot of good information but I struggle to see an IANA Consideration in there. Is the intention that the reference for "Email Authentication Methods" be updated to this I-D? If so, I think that that needs saying. Also, if that is the only action, then again worth saying to stop IANA ploughing through this lengthy section to try and find another action. Also, registries can be very hard to find if you do not know the group so again worth saying. So I would start with NEW The "Email Authentication Methods" Registry is part of the "Email Authentication Parameters" group. IANA is requested to update the reference for that registry to point to this I-D. That is the only change requested by this section. Tom Petch ----- Original Message ----- From: "Murray S. Kucherawy" To: "IETF Apps Discuss" Sent: Monday, March 09, 2015 9:34 PM Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc7001bis-03.txt > On Mon, Mar 9, 2015 at 2:32 PM, 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 : Message Header Field for Indicating Message > > Authentication Status > > Author : Murray S. Kucherawy > > Filename : draft-ietf-appsawg-rfc7001bis-03.txt > > Pages : 46 > > Date : 2015-03-09 > > > > 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 to make sorting and filtering decisions. > > > > This is an attempt to address the concerns expressed, especially by John > Levine and Tom Petch. John has seen it and says it resolves his concerns. > Everyone, and Tom in particular, do you agree that this is how it should > look? > > -MSK > ------------------------------------------------------------------------ -------- > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From nobody Thu Mar 12 08:45:21 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE0121A0065; Wed, 11 Mar 2015 10:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.19 X-Spam-Level: X-Spam-Status: No, score=-3.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SNXNgmffT8dZ; Wed, 11 Mar 2015 10:21:06 -0700 (PDT) Received: from smtp1.lax.icann.org (smtp01.icann.org [192.0.33.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 168971A0077; Wed, 11 Mar 2015 10:21:06 -0700 (PDT) Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id t2BHL5pg030259; Wed, 11 Mar 2015 17:21:05 GMT Received: by request3.lax.icann.org (Postfix, from userid 48) id CEC75C20367; Wed, 11 Mar 2015 17:21:05 +0000 (UTC) RT-Owner: pearl.liang From: "Pearl Liang via RT" In-Reply-To: <20150226200519.21140.53651.idtracker@ietfa.amsl.com> References: <20150226200519.21140.53651.idtracker@ietfa.amsl.com> Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #810446 X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/) X-RT-Originator: pearl.liang@icann.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Wed, 11 Mar 2015 17:21:05 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Thu, 12 Mar 2015 08:45:19 -0700 Cc: appsawg-chairs@ietf.org, draft-ietf-appsawg-uri-scheme-reg.all@ietf.org, iesg@ietf.org, apps-discuss@ietf.org Subject: [apps-discuss] [IANA #810446] Last Call: (Guidelines and Registration Procedures for URI Schemes) to Best Current Practice X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Reply-To: drafts-lastcall@iana.org List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 17:21:07 -0000 (BEGIN IANA LAST CALL COMMENTS) IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-appsawg-uri-scheme-reg-04. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon as possible. We received the following comments/questions from the IANA's reviewer: We have questions about some of the IANA actions requested by this draft. IANA understands that, upon approval of this document, there are four actions which IANA must complete. First, in the Uniform Resource Identifier (URI) Schemes registry located at: http://www.iana.org/assignments/uri-schemes/ the reference for the entire registry is to be changed from RFC4395 to [ RFC-to-be ]. Second, this draft updates the registration procedures for the Uniform Resource Identifier (URI) Schemes registry to the following: "Permanent URI Schemes": (No change) Expert Review "Provisional URI Schemes": OLD: Expert Review NEW: First Come First Served "Historical URI Schemes": Expert Review ??? Question: What is the policy to designated a schema as historical? Expert Review? What if someone requests to mark a FCFS Provisional schema, how should IANA process the request? Third, also in the Uniform Resource Identifier (URI) Schemes registry located at: http://www.iana.org/assignments/uri-schemes/ the "Permanent URI Schemes", "Provisional URI Schemes", and "Historical URI Schemes" sub-registries into a single common registry. Fourth, also in the Uniform Resource Identifier (URI) Schemes registry located at: http://www.iana.org/assignments/uri-schemes/ the new, merged registry created in step three above is to have the following change: two new columns are to be added to the registry. First, an additional "Status" column containing the status (Permanent, Provisional, Historical, or Pending Review), and second an additional "Notes" column which is normally empty, but may contain notes approved by the Designated Expert. Fifth, also in the Uniform Resource Identifier (URI) Schemes registry located at: http://www.iana.org/assignments/uri-schemes/ in the new, merged registry created in step two above a new URI scheme is to be registered as follows: URI Scheme: example Template: [ as in section 8.1 of the current document ] Description: Example Status: permanent Notes: Reference: [ RFC-to-be ] Comment/Question: As this document requests a registration in an Expert Review (see RFC 5226) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC. IANA understands that these five actions are the only ones required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. Thanks, Pearl Liang ICANN (END IANA LAST CALL COMMENTS) On Thu Feb 26 20:05:50 2015, iesg-secretary@ietf.org wrote: > > The IESG has received a request from the Applications Area Working Group > WG (appsawg) to consider the following document: > - 'Guidelines and Registration Procedures for URI Schemes' > as Best Current Practice > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2015-03-12. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > This document updates the guidelines and recommendations, as well as > the IANA registration processes, for the definition of Uniform > Resource Identifier (URI) schemes. It obsoletes RFC 4395. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-appsawg-uri-scheme-reg/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-appsawg-uri-scheme-reg/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > From nobody Thu Mar 12 08:45:22 2015 Return-Path: X-Original-To: expand-draft-ietf-appsawg-uri-scheme-reg.all@virtual.ietf.org Delivered-To: apps-discuss@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id EE4DB1A0077; Wed, 11 Mar 2015 10:21:07 -0700 (PDT) X-Original-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE0121A0065; Wed, 11 Mar 2015 10:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.19 X-Spam-Level: X-Spam-Status: No, score=-3.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SNXNgmffT8dZ; Wed, 11 Mar 2015 10:21:06 -0700 (PDT) Received: from smtp1.lax.icann.org (smtp01.icann.org [192.0.33.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 168971A0077; Wed, 11 Mar 2015 10:21:06 -0700 (PDT) Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id t2BHL5pg030259; Wed, 11 Mar 2015 17:21:05 GMT Received: by request3.lax.icann.org (Postfix, from userid 48) id CEC75C20367; Wed, 11 Mar 2015 17:21:05 +0000 (UTC) RT-Owner: pearl.liang From: "Pearl Liang via RT" In-Reply-To: <20150226200519.21140.53651.idtracker@ietfa.amsl.com> References: <20150226200519.21140.53651.idtracker@ietfa.amsl.com> Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #810446 X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/) X-RT-Originator: pearl.liang@icann.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Wed, 11 Mar 2015 17:21:05 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Thu, 12 Mar 2015 08:45:19 -0700 Cc: appsawg-chairs@ietf.org, draft-ietf-appsawg-uri-scheme-reg.all@ietf.org, iesg@ietf.org, apps-discuss@ietf.org Subject: [apps-discuss] [IANA #810446] Last Call: (Guidelines and Registration Procedures for URI Schemes) to Best Current Practice X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Reply-To: drafts-lastcall@iana.org List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 17:21:08 -0000 (BEGIN IANA LAST CALL COMMENTS) IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-appsawg-uri-scheme-reg-04. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon as possible. We received the following comments/questions from the IANA's reviewer: We have questions about some of the IANA actions requested by this draft. IANA understands that, upon approval of this document, there are four actions which IANA must complete. First, in the Uniform Resource Identifier (URI) Schemes registry located at: http://www.iana.org/assignments/uri-schemes/ the reference for the entire registry is to be changed from RFC4395 to [ RFC-to-be ]. Second, this draft updates the registration procedures for the Uniform Resource Identifier (URI) Schemes registry to the following: "Permanent URI Schemes": (No change) Expert Review "Provisional URI Schemes": OLD: Expert Review NEW: First Come First Served "Historical URI Schemes": Expert Review ??? Question: What is the policy to designated a schema as historical? Expert Review? What if someone requests to mark a FCFS Provisional schema, how should IANA process the request? Third, also in the Uniform Resource Identifier (URI) Schemes registry located at: http://www.iana.org/assignments/uri-schemes/ the "Permanent URI Schemes", "Provisional URI Schemes", and "Historical URI Schemes" sub-registries into a single common registry. Fourth, also in the Uniform Resource Identifier (URI) Schemes registry located at: http://www.iana.org/assignments/uri-schemes/ the new, merged registry created in step three above is to have the following change: two new columns are to be added to the registry. First, an additional "Status" column containing the status (Permanent, Provisional, Historical, or Pending Review), and second an additional "Notes" column which is normally empty, but may contain notes approved by the Designated Expert. Fifth, also in the Uniform Resource Identifier (URI) Schemes registry located at: http://www.iana.org/assignments/uri-schemes/ in the new, merged registry created in step two above a new URI scheme is to be registered as follows: URI Scheme: example Template: [ as in section 8.1 of the current document ] Description: Example Status: permanent Notes: Reference: [ RFC-to-be ] Comment/Question: As this document requests a registration in an Expert Review (see RFC 5226) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC. IANA understands that these five actions are the only ones required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. Thanks, Pearl Liang ICANN (END IANA LAST CALL COMMENTS) On Thu Feb 26 20:05:50 2015, iesg-secretary@ietf.org wrote: > > The IESG has received a request from the Applications Area Working Group > WG (appsawg) to consider the following document: > - 'Guidelines and Registration Procedures for URI Schemes' > as Best Current Practice > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2015-03-12. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > This document updates the guidelines and recommendations, as well as > the IANA registration processes, for the definition of Uniform > Resource Identifier (URI) schemes. It obsoletes RFC 4395. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-appsawg-uri-scheme-reg/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-appsawg-uri-scheme-reg/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > From nobody Thu Mar 12 08:45:23 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D0EA1A0021; Wed, 11 Mar 2015 13:26:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.19 X-Spam-Level: X-Spam-Status: No, score=-3.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pASoe1hD_X6h; Wed, 11 Mar 2015 13:26:00 -0700 (PDT) Received: from smtp1.lax.icann.org (smtp01.icann.org [192.0.33.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31E9B1A8702; Wed, 11 Mar 2015 13:26:00 -0700 (PDT) Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id t2BKPvcS006615; Wed, 11 Mar 2015 20:25:57 GMT Received: by request3.lax.icann.org (Postfix, from userid 48) id 93838C203E9; Wed, 11 Mar 2015 20:25:57 +0000 (UTC) RT-Owner: pearl.liang From: "Pearl Liang via RT" In-Reply-To: <55009B20.1080407@att.com> References: <20150226200519.21140.53651.idtracker@ietfa.amsl.com> <55009B20.1080407@att.com> Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #812464 X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/) X-RT-Originator: pearl.liang@icann.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Wed, 11 Mar 2015 20:25:57 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Thu, 12 Mar 2015 08:45:19 -0700 Cc: appsawg-chairs@ietf.org, apps-discuss@ietf.org, draft-ietf-appsawg-uri-scheme-reg.all@ietf.org, iesg@ietf.org, barryleiba@computer.org Subject: [apps-discuss] [IANA #812464] RE: Last Call: (Guidelines and Registration Procedures for URI Schemes) to Best Current Practice X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Reply-To: iana-issues@iana.org List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 20:26:01 -0000 Hi all, Sorry for the confusion. Dave has pointed out the answer is described in section 7.1 of this draft: The IANA policy (using terms defined in [RFC5226]) for Provisional registration was formerly Expert Review and is now changed to simply use a First Come First Served policy. The policy for Permanent and Historic registration continues to be Expert Review. So, if someone requests to mark a FCFS Provisional schema to "Historical", Expert Review should be used. Thanks for clarifying this. Regarding the new requested URI scheme, I've submitted an expert review request to Graham. We will inform you when we hear from him. Thanks, ~pl On Wed Mar 11 19:45:23 2015, tony@att.com wrote: > I think Pearl should be asked to clarify her question. I read her > question differently from either of you. > > Tony > > On 3/11/15 3:05 PM, Dave Thaler wrote: > > Barry Leiba writes: > >>>> What if someone requests to mark a FCFS Provisional schema, how > >>>> should IANA process the request? > >>> By "mark", do you mean adding a note in the Notes column? If so, > >>> Section 9 > >> says: > >>> o Combine the "Permanent URI Schemes", "Provisional URI Schemes", > >>> and "Historical URI Schemes" sub-registries into a single common > >>> registry with an additional "Status" column containing the > >>> status > >>> (Permanent, Provisional, Historical, or Pending Review), and an > >>> additional "Notes" column which is normally empty, but may > >>> contain > >>> notes approved by the Designated Expert. > >>> > >>> So the answer from the last quoted sentence is that any note has to > >>> be > >>> approved by the Designated Expert (regardless of the status of the > >>> entry). > >> No, by "mark" I think Pearl means changing the value of the Status > >> column from > >> Provisional to Historical: does that change require expert review? > >> Clearly, > >> changing from Provisional to Permanent would, and, on the surface, a > >> change > >> from Provisional to Historical is the same (moving from an FCFS > >> status to an > >> Expert Review status). Is that what you want? > > That is the current answer that by default (since it's not a change > > from before) > > has WG (and presumably IETF) consensus because it did before. > > However I > > don't think the WG explicitly discussed whether the answer to that > > question > > should change from current practice. > > > > Dave > > > > From nobody Thu Mar 12 08:45:25 2015 Return-Path: X-Original-To: expand-draft-ietf-appsawg-uri-scheme-reg.all@virtual.ietf.org Delivered-To: apps-discuss@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 6E9A51A8707; Wed, 11 Mar 2015 13:26:01 -0700 (PDT) X-Original-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D0EA1A0021; Wed, 11 Mar 2015 13:26:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.19 X-Spam-Level: X-Spam-Status: No, score=-3.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pASoe1hD_X6h; Wed, 11 Mar 2015 13:26:00 -0700 (PDT) Received: from smtp1.lax.icann.org (smtp01.icann.org [192.0.33.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31E9B1A8702; Wed, 11 Mar 2015 13:26:00 -0700 (PDT) Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id t2BKPvcS006615; Wed, 11 Mar 2015 20:25:57 GMT Received: by request3.lax.icann.org (Postfix, from userid 48) id 93838C203E9; Wed, 11 Mar 2015 20:25:57 +0000 (UTC) RT-Owner: pearl.liang From: "Pearl Liang via RT" In-Reply-To: <55009B20.1080407@att.com> References: <20150226200519.21140.53651.idtracker@ietfa.amsl.com> <55009B20.1080407@att.com> Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #812464 X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/) X-RT-Originator: pearl.liang@icann.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Wed, 11 Mar 2015 20:25:57 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Thu, 12 Mar 2015 08:45:19 -0700 Cc: appsawg-chairs@ietf.org, apps-discuss@ietf.org, draft-ietf-appsawg-uri-scheme-reg.all@ietf.org, iesg@ietf.org, barryleiba@computer.org Subject: [apps-discuss] [IANA #812464] RE: Last Call: (Guidelines and Registration Procedures for URI Schemes) to Best Current Practice X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Reply-To: iana-issues@iana.org List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 20:26:01 -0000 Hi all, Sorry for the confusion. Dave has pointed out the answer is described in section 7.1 of this draft: The IANA policy (using terms defined in [RFC5226]) for Provisional registration was formerly Expert Review and is now changed to simply use a First Come First Served policy. The policy for Permanent and Historic registration continues to be Expert Review. So, if someone requests to mark a FCFS Provisional schema to "Historical", Expert Review should be used. Thanks for clarifying this. Regarding the new requested URI scheme, I've submitted an expert review request to Graham. We will inform you when we hear from him. Thanks, ~pl On Wed Mar 11 19:45:23 2015, tony@att.com wrote: > I think Pearl should be asked to clarify her question. I read her > question differently from either of you. > > Tony > > On 3/11/15 3:05 PM, Dave Thaler wrote: > > Barry Leiba writes: > >>>> What if someone requests to mark a FCFS Provisional schema, how > >>>> should IANA process the request? > >>> By "mark", do you mean adding a note in the Notes column? If so, > >>> Section 9 > >> says: > >>> o Combine the "Permanent URI Schemes", "Provisional URI Schemes", > >>> and "Historical URI Schemes" sub-registries into a single common > >>> registry with an additional "Status" column containing the > >>> status > >>> (Permanent, Provisional, Historical, or Pending Review), and an > >>> additional "Notes" column which is normally empty, but may > >>> contain > >>> notes approved by the Designated Expert. > >>> > >>> So the answer from the last quoted sentence is that any note has to > >>> be > >>> approved by the Designated Expert (regardless of the status of the > >>> entry). > >> No, by "mark" I think Pearl means changing the value of the Status > >> column from > >> Provisional to Historical: does that change require expert review? > >> Clearly, > >> changing from Provisional to Permanent would, and, on the surface, a > >> change > >> from Provisional to Historical is the same (moving from an FCFS > >> status to an > >> Expert Review status). Is that what you want? > > That is the current answer that by default (since it's not a change > > from before) > > has WG (and presumably IETF) consensus because it did before. > > However I > > don't think the WG explicitly discussed whether the answer to that > > question > > should change from current practice. > > > > Dave > > > > From nobody Thu Mar 12 09:51:23 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 287681A88E1; Thu, 12 Mar 2015 09:51:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.31 X-Spam-Level: X-Spam-Status: No, score=-2.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Vws2R-Tm5BE; Thu, 12 Mar 2015 09:51:20 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEE311A8888; Thu, 12 Mar 2015 09:51:19 -0700 (PDT) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YW6KL-0004dj-Ex; Thu, 12 Mar 2015 12:51:17 -0400 Date: Thu, 12 Mar 2015 12:51:12 -0400 From: John C Klensin To: =?UTF-8?Q?=22Martin_J=2E_D=C3=BCrst=22?= Message-ID: In-Reply-To: <550164DD.6020509@it.aoyama.ac.jp> References: <550164DD.6020509@it.aoyama.ac.jp> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: IETF discussion list , apps-discuss@ietf.org Subject: Re: [apps-discuss] Last Call: (Guidelines and Registration Procedures for URI Schemes) to Best Current Practice X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 16:51:22 -0000 --On Thursday, March 12, 2015 19:05 +0900 "\"Martin J. = D=C3=BCrst\"" wrote: > Here are some last call comments on > draft-ietf-appsawg-uri-scheme-reg-04. The review was started a > while ago, and completed, but the writeup took a lot of time > and is still not completed, sorry. I may be able to complete > it tomorrow, but please don't hold your breath. >=20 > [Just in case this is necessary, as a process point, I have > seen various tracker messages (such as the draft being placed > on telechat, or that the last call has ended), but I'd like to > note that the Last Call mentions an end date of 2015-03-12, > and it's still 2015-03-12 here in Japan, which means that this > date has barely started in some other locations around the > world.] >... =20 Hi. I had decided to just let this Last Call expire without comment -- my IETF time in the last several weeks has been completely taken up by other issues, notably URNBIS and i18n (IDNA, LUCID, etc.) work on which I'm on the critical path. However, with the last of those drafts posted, Martin's notes and a few recent comments prompt a comment from a slightly different perspective. (1) First, several people have commented, directly or indirectly, about the precision and clarity of the document. I agree: it is less clear and precise than it should be. Clarity and precision are especially important for a document that specifies expert review because there is limited exposure and broad community discussion of these documents. Registration proposal review lists are not a substitute for the type of review that occurs (or should occur) in IETF LC because people with subject matter expertise associated with a particular registration proposal are unlikely to on on those lists. (2) The clarity and precision problem is particularly important in this case because there are issues with the clarity and precision of the underlying documents. Both the apps-discuss and URN mailing lists (and associated WGs) have been treated to long, and mostly, IMO, still unresolved, threads about what RFC 3986 actually means, specifies, recommends, or requires. Regardless of the position one takes on those arguments, having a document that is necessarily dependent on 3986 is problematic unless they are adequately resolved for its purposes and should be considered unacceptable if it substantially or completely ignores those issues. I note that there have been discussions in other forums, including WHATWG, W3C, and private discussions among the latter and relevant ADs, about drafts and proposals that are being developed outside the IETF with the intention of superceding all or part of 3986 in the relatively near future. Regardless of the other effects of those efforts and how the IETF should respond to them, work that is heavily dependent on practical definitions (including definitions-by-practice (aka "running code") as well as 3986) of URIs needs to be completely clear about what it is specifying and expecting. One example arises in passing in Martin's comment (an issue that has also come up in URNBIS and elsewhere). 3986 parsing and semantics are either normative or they are not (the current working assumptions in URNBIS is that semantics need to be excluded for URNs by amending 3986 for that purpose) and, again, this document needs to be clear rather than glossing over the issue and hoping things will work out "by default". (3) Similarly, as soon as a URI-related specification starts to discuss non-ASCII characters, it either needs to link itself _very_ closely to 3986 or it inherently gets tangled up with IRIs. In that area, there is a Proposed Standard (RFC 3987). There was an effort to update 3987 in the IETF that identified a number of (IMO important) issues but that was unsuccessful in resolving then, leading to the effort collapsing. As with 3986, there are now efforts going on outside the IETF to revise or reinterpret the IRI spec and/or to simply fold IRIs and URIs together. Under other circumstances, that situation might result in a "health warning" applicability statement about 3987, but there apparently hasn't been energy to create and debate such a thing. It seems to me that we could have an interesting debate about whether 3986 applies (i.e., no non-ASCII characters except via %-encoded UTF-8), some broader statement about IRIs should be made, or some other direction taken, but that is is not acceptable to not be clear about the options for whatever is being registered. (4) Finally, this Last Call identifies a procedural issue with APPSAEG in particular and perhaps some other Area WGs. The applications area, and hence AppsAWG, span a very broad collection of topic areas (a situation that will certainly become worse with the upcoming reorganization and consolidation). Most participants are active in other WGs (to which they may have primary commitments) and few have the time and expertise to dig deeply into every topic the WG chooses to take up. I favor such WGs as a way to discussion Area-wide topics and to help strike a balance between the overhead of traditional WGs that have highly constrained and topic-specific charters and the use of AD-sponsored individual submissions for immature or controversial drafts. But because of their breadth and the difficulty of assuming that there is a significant number of WG participants who are expert about and examining each specification in careful and appropriately skeptical way, automatic use of two-week IETF Last Calls from the output of such groups may not be consistent with fairness. john From nobody Thu Mar 12 14:53:16 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAC041AC3A6 for ; Thu, 12 Mar 2015 14:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EskYFgV32pPt for ; Thu, 12 Mar 2015 14:53:13 -0700 (PDT) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 654761A8777 for ; Thu, 12 Mar 2015 14:53:13 -0700 (PDT) Received: by wesp10 with SMTP id p10so19322420wes.11 for ; Thu, 12 Mar 2015 14:53: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=MesCYc9HgL/jvEqYM4j6xrW79sKkcTOv//3NHdR5m04=; b=jNZZYtV4YwkRez0RypQyfhzXtbCSZH52K/8T8rbpJGZRlmtFWF23lGJ05zNco3GtAn w1b6NOUht0SMHMPfKue69vWOkivyI+/Ejmfg02X2r2NzRP5+c9ebkDh5EBOVmRp19iC4 wyQ7y6MH505egGQhy6EmZo0WWigRFvnQFRgVT0SOzAgf/cuzVNE771mPyg+WlpkgjZ5I O7HB+CPgeORJsNRS3VM8ckum/3xXSOSij+jQcESBtajjt4+Z99nYiqSF3Utr/K/4ZLIC Wu7GX33fJS7uMJpm6jocCcDpmM1WMNCUSO+tMKKKtTrzCKPYad8yDISZWMi+EkJAF6wu /hVQ== MIME-Version: 1.0 X-Received: by 10.194.179.194 with SMTP id di2mr90076507wjc.4.1426197192143; Thu, 12 Mar 2015 14:53:12 -0700 (PDT) Received: by 10.27.179.212 with HTTP; Thu, 12 Mar 2015 14:53:12 -0700 (PDT) In-Reply-To: <018601d05cb9$b6fbba00$4001a8c0@gateway.2wire.net> References: <20150309213241.21308.78039.idtracker@ietfa.amsl.com> <018601d05cb9$b6fbba00$4001a8c0@gateway.2wire.net> Date: Thu, 12 Mar 2015 14:53:12 -0700 Message-ID: From: "Murray S. Kucherawy" To: "t.petch" Content-Type: multipart/alternative; boundary=089e01419d1c047a1805111e697b Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-ietf-appsawg-rfc7001bis s6.2 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 21:53:14 -0000 --089e01419d1c047a1805111e697b Content-Type: text/plain; charset=UTF-8 On Thu, Mar 12, 2015 at 4:42 AM, t.petch wrote: > s 6.2 contains a lot of good information but I struggle to see an IANA > Consideration in there. Is the intention that the reference for "Email > Authentication Methods" be updated to this I-D? If so, I think that > that needs saying. > Also, if that is the only action, then again worth saying to stop IANA > ploughing through this lengthy section to try and find another action. > Also, registries can be very hard to find if you do not know the group > so again worth saying. > > So I would start with > > NEW > The "Email Authentication Methods" Registry is part of the "Email > Authentication Parameters" group. IANA is requested to update the > reference for that registry to point to this I-D. That is the only > change requested by this section. > That isn't quite the only change, but it's worth being explicit that this is the new reference document. I'll do that in -04. Among other minor changes, this document now says explicitly that each entry has to cover a unique method/ptype/property tuple (i.e., duplicates aren't allowed). -MSK --089e01419d1c047a1805111e697b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Mar 12, 2015 at 4:42 AM, t.petch <ietfc@btconne= ct.com> wrote:
s 6.2 contains a lot of good info= rmation but I struggle to see an IANA
Consideration in there.=C2=A0 Is the intention that the reference for "= ;Email
Authentication Methods" be updated to this I-D?=C2=A0 =C2=A0If so, I t= hink that
that needs saying.
Also, if that is the only action, then again worth saying to stop IANA
ploughing through this lengthy section to try and find another action.
Also, registries can be very hard to find if you do not know the group
so again worth saying.

So I would start with

NEW
The "Email Authentication Methods" Registry=C2=A0 is part of the = "Email
Authentication Parameters" group.=C2=A0 IANA is requested to update th= e
reference for that registry to point to this I-D.=C2=A0 That is the only change requested by this section.

That = isn't quite the only change, but it's worth being explicit that thi= s is the new reference document.=C2=A0 I'll do that in -04.

Among other minor changes, this document now says explicitly that ea= ch entry has to cover a unique method/ptype/property tuple (i.e., duplicate= s aren't allowed).

-MSK
--089e01419d1c047a1805111e697b-- From nobody Thu Mar 12 15:03:31 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 274151A6FFA for ; Thu, 12 Mar 2015 15:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gaoBxtKV2-mI for ; Thu, 12 Mar 2015 15:03:28 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD71D1A1BDC for ; Thu, 12 Mar 2015 15:03:27 -0700 (PDT) Received: by wevk48 with SMTP id k48so19355858wev.7 for ; Thu, 12 Mar 2015 15:03: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=yKVbLeaAeoUkX6zWUm7Uth/hlAqyDEyuhBnhdn0NXkk=; b=AMvhljhubx+QgDfqFtkYSk8XL2ejxv8GPFarRDDTRuVPX3Ccr0bO1xfC0Lmoogjmp2 H0274eeOrfHrvtUZpEQ869/vXYuCptAbtfYLqK4liltWMQEXVz07iJACje/5vINgHvT1 /SegrUCy/yG/6gXIp3/VJHxoceUNrOppW/cAFUH8sqSAM7/67qO3DJuj/O76yrabH5QK NyYwAFITr+RvBxYzkFyhDrM5076NVxhH647ccuTapX7EUF9V/zx3BoVXAOnAFgTlcc+m OvEOyZQfzCjH9LUPoIvFnuj8hOsRBks8WiFxsEyGayvYp15CajE7I5HJCte5ILUB4KjP mNvQ== MIME-Version: 1.0 X-Received: by 10.194.185.9 with SMTP id ey9mr92464830wjc.135.1426197806550; Thu, 12 Mar 2015 15:03:26 -0700 (PDT) Received: by 10.27.179.212 with HTTP; Thu, 12 Mar 2015 15:03:26 -0700 (PDT) In-Reply-To: <018e01d05cba$e6ba8400$4001a8c0@gateway.2wire.net> References: <018e01d05cba$e6ba8400$4001a8c0@gateway.2wire.net> Date: Thu, 12 Mar 2015 15:03:26 -0700 Message-ID: From: "Murray S. Kucherawy" To: "t.petch" Content-Type: multipart/alternative; boundary=047d7bd6adcea394f505111e8dfd Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-ietf-appsawg-rfc7001bis s2.7.1 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 22:03:29 -0000 --047d7bd6adcea394f505111e8dfd Content-Type: text/plain; charset=UTF-8 On Thu, Mar 12, 2015 at 4:47 AM, t.petch wrote: > s2.7.1 is fine for DKIM which is well covered in RFC6376 but I do not > think that the same can be said for DomainKeys and RFC4870. > > I think the gulf too wide and would add a small bridge, such as > OLD > DomainKeys is defined in [DOMAINKEYS] and is represented by the > "domainkeys" method. > NEW > DomainKeys is defined in [DOMAINKEYS] and is represented by the > "domainkeys" method. The relevant section for this specification is > section 3.3 on the "DomainKey-Signature" header. > I think you need to know more than what Section 3.3 of RFC4870 says. That section just gives the syntax of a DomainKey-Signature header field, but doesn't go into how you go about figuring out "pass" vs. "fail", for example. I think the more general reference is better. Also, Section 2.7.1 seems to me to be equally balanced between DKIM and DomainKeys. -MSK --047d7bd6adcea394f505111e8dfd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Mar 12, 2015 at 4:47 AM, t.petch <ietfc@btconne= ct.com> wrote:
s2.7.1=C2=A0 is fine for DKIM whi= ch is well covered in RFC6376 but I do not
think that the same can be said for DomainKeys and RFC4870.

=C2=A0I think the gulf too wide and would add a small bridge, such as
OLD
=C2=A0 =C2=A0DomainKeys is defined in [DOMAINKEYS]=C2=A0 and is represented= by the
=C2=A0 =C2=A0"domainkeys" method.
NEW
=C2=A0 =C2=A0DomainKeys is defined in [DOMAINKEYS]=C2=A0 and is represented= by the
=C2=A0 =C2=A0"domainkeys" method.=C2=A0 The relevant section for = this specification is
section 3.3 on the "DomainKey-Signature" header.
=

I think you need to know more than what Section 3.3 of = RFC4870 says.=C2=A0 That section just gives the syntax of a DomainKey-Signa= ture header field, but doesn't go into how you go about figuring out &q= uot;pass" vs. "fail", for example.=C2=A0 I think the more ge= neral reference is better.

Also, Section 2.7.1 seems to m= e to be equally balanced between DKIM and DomainKeys.

-MS= K
--047d7bd6adcea394f505111e8dfd-- From nobody Thu Mar 12 17:08:50 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8B871A8866 for ; Thu, 12 Mar 2015 17:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.412 X-Spam-Level: X-Spam-Status: No, score=-1.412 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_44=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iNgNTDEA-YwZ for ; Thu, 12 Mar 2015 17:08:49 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4ACC01A8864 for ; Thu, 12 Mar 2015 17:08:49 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PJIZSV4Y7400CNO4@mauve.mrochek.com> for apps-discuss@ietf.org; Thu, 12 Mar 2015 17:06:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1426205172; bh=MiBbiV6Z/HnN1PDXAB5ERqLMlGPFhhyAg2r/TllNesY=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=F6paULqqvQIOkoKL3COJjTS+XC+ZrBwuJ4U5PMF3NgvphtNPAxGAaz1rWQ9IR460b n4NkFa8XyWiRiDP286HJDDpINPZ+/xW5D2BRzuu6/KYiW1VCQ9dR5zyID+7ZK4iQ4s 0UPyYnUiXs50NiCT/2rKCbJuYTVjPZ8oubMrUtxM= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PJ6KCZSXQ80000AQ@mauve.mrochek.com>; Thu, 12 Mar 2015 17:06:09 -0700 (PDT) Message-id: <01PJIZST6QA80000AQ@mauve.mrochek.com> Date: Thu, 12 Mar 2015 17:05:57 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Wed, 11 Mar 2015 21:48:06 -0400" References: <1745871.VmxIvUMNcD@kitterma-e6430> <20150310020928.33511.qmail@ary.lan> <01PJFSVXS0XW0000AQ@mauve.mrochek.com> <01PJHO9WJ8CY0000AQ@mauve.mrochek.com> To: John R Levine Archived-At: Cc: Ned Freed , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc7001bis-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 00:08:50 -0000 > >> When someone uses AUTH EXTERNAL, is the authorized identity anything that > >> couldn't be recorded in the smtp.auth clause? > > > > It's certainly possible in theory, but as a practical matter, there's usually > > an identifier of some sort attached to the identity. > > > > A better question, in the case of AUTH EXTERNAL, is whether there's a need > > to log additional information. A fingerprint for the certificate that > > was used comes to mind as a possibility. > Since this is an expert review registry, how about just leaving it as is, > and if someone actually starts logging fingerprints or whatever, encourage > them to write in and we'll add it to the registry. That seems reasonable. Ned From nobody Fri Mar 13 02:29:27 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FC131A1B91; Fri, 13 Mar 2015 02:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5caHe7DzUpW2; Fri, 13 Mar 2015 02:29:21 -0700 (PDT) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta01-14.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id 149CD1A1B7C; Fri, 13 Mar 2015 02:29:20 -0700 (PDT) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmse.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id 6BB6132E52E; Fri, 13 Mar 2015 18:28:35 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 09cd_418b_91d2cc87_7c66_4903_9c67_2d450f8587ba; Fri, 13 Mar 2015 18:28:35 +0900 Received: from [133.2.210.64] (unknown [133.2.210.64]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 884BFBF8E4; Fri, 13 Mar 2015 18:28:34 +0900 (JST) Message-ID: <5502ADC6.3030108@it.aoyama.ac.jp> Date: Fri, 13 Mar 2015 18:28:38 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "apps-discuss@ietf.org" , Larry Masinter , Ted Hardie , Tony Hansen , Dave Thaler , IETF discussion list References: <550164DD.6020509@it.aoyama.ac.jp> In-Reply-To: <550164DD.6020509@it.aoyama.ac.jp> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [apps-discuss] Last Call: (Guidelines and Registration Procedures for URI Schemes) to Best Current Practice X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 09:29:24 -0000 On 2015/03/12 19:05, "Martin J. D=C3=BCrst" wrote: > Here are some last call comments on > draft-ietf-appsawg-uri-scheme-reg-04. The review was started a while > ago, and completed, but the writeup took a lot of time and is still not > completed, sorry. I may be able to complete it tomorrow, but please > don't hold your breath. I managed to find my review notes again and to complete the writeup, so=20 below is the rest of my comments. [Looking at the copy with my notes, it's actually the -03 draft, so=20 please ignore all issues in yesterday's mail that already have been=20 fixed in -04.] 3.8. Scheme Name Considerations New registered schemes registrations MUST follow this syntax, which only allows a limited repertoire of characters (taken from US-ASCII). "schemes registrations" -> "scheme registrations" A scheme name is not a "protocol" although, like a service name as defined in section 5 of [RFC6335], it often identifies a particular protocol or application. '"protocol" although' doesn't work. I suggest to reword as: A scheme name is not a "protocol". However, like a service name as defined in section 5 of [RFC6335], it often identifies a particular protocol or application. I wonder whether it makes sense to say something about abbreviations,=20 such as "If there is a well-known abbreviation for the protocol or=20 service, then it's preferable to use it as a scheme name (e.g. http:=20 rather than hypertext-transfer-protocol:)." Some organizations desire their own namespace for URI scheme names for private use (see Section 6). In doing so, it is important to prevent collisions, and to make it possible to identify the owner of a private use scheme. To accomplish these two goals, such organizations SHOULD use a prefix based on their domain name, expressed in reverse order. For example, a URI scheme name of com.example.info might be used by the organization that owns the example.com domain name. Care must be taken, however, if the organization later loses the domain name embedded in their scheme names, since domain name registrations are not permanent. The URI scheme name registration procedure can be used in such an event. The the last sentence is unclear. I suggest to rewrite the last sentence=20 to something like "In order to permanently associate the private use=20 scheme name with the original domain name owner, the private use scheme=20 can be registered using the registration procedure in Section XYZ.". Either at the end of section 1 or in a subsection of section 3, it=20 should be made *extremely* clear that scheme registrations neither can=20 nor should define anything related to fragments, i.e. that fragments are=20 mostly if not completely orthogonal to schemes, and their interpretation=20 is defined by the MIME media type of the returned representation when=20 dereferencing. 4. Guidelines for Provisional URI Scheme Registration There is a point about provisional registrations meeting the syntax=20 restrictions for scheme names, but nothing about syntax restrictions for=20 the rest of the URIs. I think it should be made very clear that while we=20 have made provisional registration very easy on purpose, if a scheme=20 doesn't meet the general syntax restrictions, it may not work in some or=20 all URI software, and it doesn't have a chance to move to permanent=20 registration. o The scheme definition SHOULD include a clear Security Considerations (Section 3.7) "a clear Security Considerations" -> "a clear Security Considerations=20 section" or "clear security considerations" Also: "(Section 3.7)" -> "(see Section 3.7)" 5. Guidelines for Historical URI Scheme Registration In some circumstances, it is appropriate to note a scheme that was once in use or registered but for whatever reason is no longer in common use or the use is not recommended. Change the last bit ("or the use is not recommended") to "or is no=20 longer recommended for use" to avoid a change of subject in mid-sentence. Any scheme that is no longer in common use MAY be designated as historical; the registration SHOULD contain some indication to where the scheme was previously defined or documented. "indication to" -> "indication about" 6. Guidelines for Private URI Scheme Use As such, a unique namespace (see Section 3.8) MUST be used, and it is strongly encouraged to do a Provisional registration unless the scheme name is constructed from a domain name. Please add a pointer to the example at the end of section 3.8. 7. URI Scheme Registration Procedure 7.1. General The IANA policy (using terms defined in [RFC5226]) for Provisional registration was formerly Expert Review and is now changed to simply use a First Come First Served policy. "is now changed" will read badly a few years down the line. Please=20 reword. Also, it may be worth pointing out that somebody who wants to=20 register something as provisional still can ask for review. While there=20 are people who know that they are exactly right (even if they may be=20 wrong), there are also other people who might want to get a (few)=20 pair(s) of eyes more on what they are doing. 7.2. Registration Procedures Someone wishing to register a new scheme MUST: 1. Check the IANA URI Schemes registry to see whether there is already an entry for the desired name. If there is already an entry under the name, choose a different scheme name, or update the existing scheme specification. The last clause may be interpreted to allow hijacking. It should be made=20 clear that this isn't the intent. 2. Prepare a scheme registration request using the template specified in Section 7.4. In this paragraph, it should be made clear that the template should be=20 complete on its own. As an example, Scheme syntax: See the syntax definition in section FOO. is bad, but Scheme syntax: See the syntax definition in section FOO of the BAR specification. may be okay, even if it reads somewhat redundantly when inside the BAR=20 specification itself. 2. Send a copy of the completed template or a pointer to the containing document (with specific reference to the section with the completed template) to the mailing list uri- review@ietf.org , requesting review. It should be made clear that sending a full copy of the template is=20 strongly preferred, because it significantly increases the chance and=20 timeliness of comments. For example, general discussion of URI syntactical issues could be discussed on uri@w3.org; schemes for a network protocol could be discussed on a mailing list for that protocol. Change "could" to "ought" or "can" (two times). 4. Submit the (possibly updated) registration template (or pointer to document containing it) to IANA at iana@iana.org. It may be obvious to insiders, but worth pointing out because we want to=20 reach outsiders, too: It is important to note that submission to IANA=20 for registration doesn't happen automatically but has to be done by the=20 registrant. 1. IANA checks the submission for completeness; if sections of the template are missing or any citations are not correct, IANA will reject the registration request. Again, it may be obvious to insiders, but worth adding: This doesn't=20 preclude new, fixed submissions. 3. Otherwise, IANA enters the registration request in the IANA registry, with status marked as "Pending Review" and the remainder of this section applies. Please add a comma after "Pending Review" (end of 'with' clause). 6. In the case of a Permanent registration request, the Designated Expert may: * Request additional review or discussion, as necessary. Again this may be obvious to insiders, but it may be worth saying that=20 this should as much as possible be conducted on public mailing lists. Either based on an explicit request or independently initiated, the Designated Expert or IESG can request the upgrade of a 'provisional' registration to a 'permanent' one. "IESG" -> "the IESG" It would probably be better if the paragraph starting with the above=20 lines would move from the end of section 7.2 to the end of section 7.3. Typically this would only occur if the use is considered a standard (not necessarily an IETF standard). A standard may be used, but 'use' isn't a standard. Either say "use is=20 considered to be very widespread" (I'd avoid the word "standard" in that=20 sense) and remove the "IETF standard" parenthetical, or change to "if=20 the scheme is defined in a standard" (in that case "IETF standard"=20 should be changed to (IETF) Internet Standard). 7.4. URI Scheme Registration Template Contact: Person (including contact information) to contact for further information. Author/Change controller: Person (including contact information) authorized to change this. This is a problem with many other registration templates, too, which we=20 should fix whenever we can: I have seen many people struggling with this=20 distinction. It's rarely very useful. What is useful in some cases is to make a distinction between the=20 submitter/author and the organization in charge, but "Author/Change=20 controller" mixes the two. The minimum improvement that I'd propose is=20 the following: Author/Contact: Person (including contact information) to contact for further information. Change controller: Organization or person (including contact information) authorized to change this. This would at least make it moderately easy for registrations from the IE= TF. The following fields are no longer required in a scheme registration request. The answers instead belong in the scheme specification. "no longer required" and "belong" conflict, in that "no longer required"=20 doesn't exclude them, but "belong" does. I'd prefer to say that if they=20 are short or very important, they should be given in the template, if=20 they are lengthy, they should be given separately, and if they are=20 irrelevant, they can be ignored. Interoperability considerations: inability to support multibyte character sets; The modern Internet, in particular in URIs and IRIs, does have=20 absolutely no need to support multibyte character sets, and even less of=20 a need to use such a term (see=20 http://www.w3.org/MarkUp/html-spec/charset-harmful.html). Please change=20 this to something like "inability to support non-ASCII characters". Scheme syntax: The entire range of allowable syntax specified in [RFC3986] is allowed for "example" URIs. Please add: The entire range of allowable syntax specified in [RFC3987]=20 is allowed for "example" IRIs. 8.1. "Example" Scheme Registration Request Please change this title to "Example" Scheme Registration Template. 10. Security Considerations All registered values are expected to contain accurate security consideration sections; 'permanent' registered scheme names are expected to contain complete definitions. Words such as "accurate" and "complete" are wishful thinking. When it=20 comes to security, there is always the chance of a discovery of new=20 security issues. This section should make it clear that best effort is=20 expected of the registrants, and that third parties may request the=20 addition of new issues, but that the security information in a scheme=20 registration should never be seen as complete and final. Regards, Martin. From nobody Fri Mar 13 09:05:11 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25AA81A8AF0 for ; Fri, 13 Mar 2015 09:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HDOP8LjnyBNo for ; Fri, 13 Mar 2015 09:05:08 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0715.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::715]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D0CC1A8ADD for ; Fri, 13 Mar 2015 09:05:07 -0700 (PDT) Received: from pc6 (86.185.85.149) by DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) with Microsoft SMTP Server (TLS) id 15.1.112.19; Fri, 13 Mar 2015 16:04:48 +0000 Message-ID: <00ce01d05da7$1ace6580$4001a8c0@gateway.2wire.net> From: t.petch To: "Murray S. Kucherawy" , IETF Apps Discuss References: <018e01d05cba$e6ba8400$4001a8c0@gateway.2wire.net> Date: Fri, 13 Mar 2015 15:40:34 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.185.85.149] X-ClientProxiedBy: AM3PR03CA052.eurprd03.prod.outlook.com (10.141.191.180) To DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB3PR07MB060; X-Forefront-Antispam-Report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(51444003)(62966003)(77156002)(92566002)(86362001)(50226001)(106356001)(1456003)(46102003)(42186005)(122386002)(40100003)(61296003)(77096005)(66066001)(44736004)(62236002)(47776003)(64706001)(44716002)(14496001)(50466002)(23756003)(1556002)(87976001)(84392001)(230783001)(116806002)(107886001)(229853001)(33646002)(81816999)(50986999)(81686999)(76176999)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR07MB060; H:pc6; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5002009)(5005006); SRVR:DB3PR07MB060; BCL:0; PCL:0; RULEID:; SRVR:DB3PR07MB060; X-Forefront-PRVS: 05143A8241 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Mar 2015 16:04:48.2707 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR07MB060 Archived-At: Subject: [apps-discuss] draft-ietf-appsawg-rfc7001bis s2.7.2 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 16:05:10 -0000 s2.7.2 I find problematic Ironically, SPF is described comprehensively, which in a way it does not need since RFC7208 does a good job, mostly. sender-id, on the other hand, is poorly served in this context by RFC4406 and is likewise hard to understand from what is here. Interleaving the comprehensive description of SPF with the sparse references to sender-id compounds the problem. Yes they are closely related and belong in the same section but interleaving the descrptions confuses me - I would have all the SPF material first and then the sender-id, each part complete in itself. When it says " Similarly, the results for Sender ID are listed and described in Section 4.2 of [SENDERID], which in turn uses the SPF definitions that now appear in [SPF]." Well no. [SENDERID] is RFC4406 and no way does it use [SPF] which is RFC7208. The latter could have updated the former, but it didn't! For PRA, I would like to see the relevant header fields named, just to make it easier to find your way around RFC4407, which I think is Resent-Sender Resent-From Received Return-Path Sender From And tied to this, I think that s6.4 is asking a lot of IANA. It is titled "Email Authentication Result Names" Registry but the last paragraph says " The definitions for the SPF and Sender ID authentication >methods< are to be updated using the references found in Section 2.7.2." and as ever, this is trivial for SPF, a big ask for sender-id. I think that sender-id needs the same results table and references in 2.7.2 as SPF has got So I would have something like ================================================ The "sender-id" method is described in [SENDERID] For Sender ID, the ptype used is "header", and the property will be the name of the header field from which the Purported Responsible Address (see [PRA]) was extracted, namely "Resent-Sender" "Resent-From" "Received" "Return-Path" "Sender" "From" The results for Sender ID are listed and described in Section 4.2 of [SENDERID], but for the purposes of this specification, the SPF definitions that now appear in [SPF] should be used instead Those definitions are included here by reference: +-----------+--------------------------------+ | Code | Meaning | +-----------+--------------------------------+ | none | [RFC7208], Section 2.6.1 | +-----------+--------------------------------+ | pass | [RFC7208], Section 2.6.3 | +-----------+--------------------------------+ | fail | [RFC7208], Section 2.6.4 | +-----------+--------------------------------+ | softfail | [RFC7208], Section 2.6.5 | +-----------+--------------------------------+ | policy | [this RFC], Section 2.4 | +-----------+--------------------------------+ | neutral | [RFC7208], Section 2.6.2 | +-----------+--------------------------------+ | temperror | [RFC7208], Section 2.6.6 | +-----------+--------------------------------+ | permerror | [RFC7208], Section 2.6.7 | +-----------+--------------------------------+ =============================================== with the last two paragraphs as at present. If I have got this wrong, well, what more need I say? Tom Petch From nobody Sat Mar 14 14:10:08 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADFE81A01F0 for ; Sat, 14 Mar 2015 14:10:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.598 X-Spam-Level: X-Spam-Status: No, score=0.598 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, J_CHICKENPOX_15=0.6, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Y6NG4_-gfOM for ; Sat, 14 Mar 2015 14:10:04 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0756.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::756]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68E5F1A0107 for ; Sat, 14 Mar 2015 14:10:04 -0700 (PDT) Received: from pc6 (86.185.85.149) by DB3PR07MB057.eurprd07.prod.outlook.com (10.242.137.144) with Microsoft SMTP Server (TLS) id 15.1.112.16; Sat, 14 Mar 2015 21:09:43 +0000 Message-ID: <00fb01d05e9a$dde6a840$4001a8c0@gateway.2wire.net> From: t.petch To: "Murray S. Kucherawy" References: <018e01d05cba$e6ba8400$4001a8c0@gateway.2wire.net> Date: Sat, 14 Mar 2015 21:07:13 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.185.85.149] X-ClientProxiedBy: DB4PR03CA0005.eurprd03.prod.outlook.com (25.160.39.143) To DB3PR07MB057.eurprd07.prod.outlook.com (10.242.137.144) Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB3PR07MB057; X-Forefront-Antispam-Report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(24454002)(377454003)(51704005)(122386002)(230783001)(81816999)(76176999)(46102003)(50986999)(47776003)(1411001)(61296003)(23676002)(66066001)(110136001)(44716002)(92566002)(40100003)(81686999)(62236002)(116806002)(50226001)(77096005)(87976001)(42186005)(44736004)(50466002)(84392001)(86362001)(62966003)(77156002)(33646002)(1556002)(19580405001)(19580395003)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR07MB057; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:DB3PR07MB057; BCL:0; PCL:0; RULEID:; SRVR:DB3PR07MB057; X-Forefront-PRVS: 0515208626 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Mar 2015 21:09:43.9108 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR07MB057 Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-ietf-appsawg-rfc7001bis s2.7.1 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 21:10:06 -0000 ----- Original Message ----- From: "Murray S. Kucherawy" To: "t.petch" Cc: "IETF Apps Discuss" Sent: Thursday, March 12, 2015 10:03 PM > On Thu, Mar 12, 2015 at 4:47 AM, t.petch wrote: > > > s2.7.1 is fine for DKIM which is well covered in RFC6376 but I do not > > think that the same can be said for DomainKeys and RFC4870. > > > > I think the gulf too wide and would add a small bridge, such as > > OLD > > DomainKeys is defined in [DOMAINKEYS] and is represented by the > > "domainkeys" method. > > NEW > > DomainKeys is defined in [DOMAINKEYS] and is represented by the > > "domainkeys" method. The relevant section for this specification is > > section 3.3 on the "DomainKey-Signature" header. > > > > I think you need to know more than what Section 3.3 of RFC4870 says. That > section just gives the syntax of a DomainKey-Signature header field, but > doesn't go into how you go about figuring out "pass" vs. "fail", for > example. I think the more general reference is better. > > Also, Section 2.7.1 seems to me to be equally balanced between DKIM and > DomainKeys. True! It is RFC6376 and RFC4870 that I find unbalanced, that is, s.2.7.1 plus RFC6376 tells me all I need to know, which s.2.7.1 plus RFC4870 does not, which is not surprising because RFC4870 was written without any consideration for an "Authentication-Results:" (naturally enough). Which is why I have been looking for more in s.2.7.1. to help the reader bridge the gap in order to find what they want in RFC4870. Tom Petch > > -MSK > From nobody Sat Mar 14 15:53:44 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 430801A0387 for ; Sat, 14 Mar 2015 15:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.002 X-Spam-Level: X-Spam-Status: No, score=-102.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H26NXcT4h6Kr for ; Sat, 14 Mar 2015 15:53:40 -0700 (PDT) Received: from listserv.winserver.com (news.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 588D81A037A for ; Sat, 14 Mar 2015 15:53:39 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2335; t=1426373615; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=QI7JmCvqKoP+/cEXp0jAbWd1P0I=; b=ZZMig8q7VnDYGBC4yhvv w8izESBoIBEIbhtzs1FPzAOOMyQ/zQKKAAYHeNAAniDjjBoP9mkHdURG0aQZDCFj DP9Ej8VG/ct41pDeV6FsfZfN0/WAPefg9mqrGbiBf+f57gFIkQ5EVF0BRwAml4jU /WGO5gOfVVjmU2TOYGmLRgg= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Sat, 14 Mar 2015 17:53:35 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=fail author.d=isdg.net signer.d=beta.winserver.com (unauthorized signer); Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 83660537.2730.324; Sat, 14 Mar 2015 17:53:34 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2335; t=1426373433; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=2o1I9UJ hqSa40kA7A+8HnAQxHNMhMkP9MxIXlDCtO0I=; b=bYOSQeW91+VSVZsRk/zFavg WYT8Evdtbx8e5UBZpoo2wTjIYhQVg0qfIoJy3FFRS1meS/W6UIW1ceaxK8BB7yzL tdo1qrD1JMm/9d5TwuDA375mieMWctglJrHZMoKQ53dJ42zNoQVV+0HlZ/pvay1J XEOfFqivITB0GhkTW49k= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Sat, 14 Mar 2015 18:50:33 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2970936675.9.9408; Sat, 14 Mar 2015 18:50:32 -0400 Message-ID: <5504BBF0.9000100@isdg.net> Date: Sat, 14 Mar 2015 18:53:36 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 CC: apps-discuss References: <20150309213241.21308.78039.idtracker@ietfa.amsl.com> In-Reply-To: <20150309213241.21308.78039.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Comment: Missing recipient address appended by wcSMTP router. To: apps-discuss@ietf.org Archived-At: Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc7001bis-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 22:53:43 -0000 Some comments On 3/9/2015 5:32 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 : Message Header Field for Indicating Message Authentication Status > Author : Murray S. Kucherawy > Filename : draft-ietf-appsawg-rfc7001bis-03.txt > Pages : 46 > Date : 2015-03-09 > > 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 to make sorting and filtering decisions. For sentence #1, .... indicate the results of different message authentication efforts. or .... indicate the results of any internal message authorization and authentication efforts. I was under the impression that this header can only be "trusted" internally, essentially by the creator to be used by the backend "receiver-side" software or even at the UI hosted presentation? The DKIM/ADSP/DMARC/SPF/OTHER machine domain host name creating this header needs to be trusted. The main reason I say this is because the first time I began to use this for DKIM, I also used it for ADSP, Not SPF, nor ATPS. SPF already had an internally produced and most importantly trusted result header (Received-SPF) and AUTH-RES wasn't quite ready to pass all the essential, different A/A protocol process parameters information being done, including SPF and ATPS. So I created the fields I needed. Since it would intended for internal consumption, other consumers like RFC-based Offline Mail Readers/Writers, these offline MUAs should not rely on it. Is this still true? If so, what are the rules for this? How about different AUTH-RES from different processing host? As a related tech note, does the latest work reflect all the essential information needed for? DKIM DMARC SPF Is it ready for indicating 3rd party results? Does it still support ADSP or its obsolete in the new AUTH-RES as well? -- HLS From nobody Sat Mar 14 22:25:18 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 443121A1AAA for ; Sat, 14 Mar 2015 22:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FzvvQOqDiy1o for ; Sat, 14 Mar 2015 22:25:14 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB5B31A1AB2 for ; Sat, 14 Mar 2015 22:25:13 -0700 (PDT) Received: by wifj2 with SMTP id j2so17099874wif.1 for ; Sat, 14 Mar 2015 22:25: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=pZAOYa2ycgJ9wtHVX9TY1fr4LJakxlO4qX/kPGr+aJ0=; b=WiNzUcgS5Up+nRL8wNCmoOhlOLP1+uS7sg1/x64yi8h+aeKeTZTCYwNzBbWArdyhAj 3Lh7IMgMqGrQooj+M+ViC6LyyFHe1mVSHwGIEQQEMmazgi8W1HvDNEoRvu062WwVDNkV xPDZ2G3IwXKt+NyUGo1z77euR5JI08RIqVzv0vcODC2BYd8EWfwTcotsMf8NWjNGYV1w ruwq9EUT+WKlS8IiItYH0v+/kQlc7AuXXMo7mJAdasdtLY6BJVZOGrJvEC1cIHX8z5ru KZJq5LXziMZiunoPgBtb9cwUSMHxK/vRbhbhji6zcjgrifeoWfVIhWZyiTbCoksFZkKz 7gsQ== MIME-Version: 1.0 X-Received: by 10.194.239.65 with SMTP id vq1mr107580399wjc.98.1426397112562; Sat, 14 Mar 2015 22:25:12 -0700 (PDT) Received: by 10.27.179.212 with HTTP; Sat, 14 Mar 2015 22:25:12 -0700 (PDT) In-Reply-To: <5504BBF0.9000100@isdg.net> References: <20150309213241.21308.78039.idtracker@ietfa.amsl.com> <5504BBF0.9000100@isdg.net> Date: Sat, 14 Mar 2015 22:25:12 -0700 Message-ID: From: "Murray S. Kucherawy" To: Hector Santos Content-Type: multipart/alternative; boundary=001a11c1b8f033fab705114cf5d5 Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc7001bis-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2015 05:25:17 -0000 --001a11c1b8f033fab705114cf5d5 Content-Type: text/plain; charset=UTF-8 On Sat, Mar 14, 2015 at 3:53 PM, Hector Santos wrote: > For sentence #1, > > .... indicate the results > of different message authentication efforts. > > or > > .... indicate the results of any internal message > authorization and authentication efforts. > They're not necessarily internal checks (where "internal", I assume, means "done by my ADMD"). You could decide to trust an upstream check from your ISP, for example. > I was under the impression that this header can only be "trusted" > internally, essentially by the creator to be used by the backend > "receiver-side" software or even at the UI hosted presentation? > No, that's never been the case. Going back as far as RFC5451 Section 5, we've always allowed for the possibility of trusting information from outside. You just have to decide you believe whatever the outside source is telling you. > The DKIM/ADSP/DMARC/SPF/OTHER machine domain host name creating this > header needs to be trusted. > Yes, that's the point, not that it has to be internal. > The main reason I say this is because the first time I began to use this > for DKIM, I also used it for ADSP, Not SPF, nor ATPS. SPF already had an > internally produced and most importantly trusted result header > (Received-SPF) and AUTH-RES wasn't quite ready to pass all the essential, > different A/A protocol process parameters information being done, including > SPF and ATPS. > A-R predated ATPS, so they've always been compatible. As for Received-SPF, the whole reason this was introduced is because SPF created a header field for recording its results, and DomainKeys proposed one as well. Rather than having a different one for every method, it made sense to create one extensible one for this purpose. > So I created the fields I needed. Since it would intended for internal > consumption, other consumers like RFC-based Offline Mail Readers/Writers, > these offline MUAs should not rely on it. > > Is this still true? > If by "this" you mean internal consumption, then yes, mostly; it's intended for consumption by downstream agents (filters and MUAs, mainly) that are able to figure out which ones they believe. > If so, what are the rules for this? > Several sections of RFC5451, such as 2.3, 4.1, and 7, talk about when and how to consume the header field. All of this is carried forward into RFC7001 and now this document. > How about different AUTH-RES from different processing host? > Same answer. > As a related tech note, does the latest work reflect all the essential > information needed for? > > DKIM > DMARC > SPF > Yes. Is it ready for indicating 3rd party results? > The only supported third-party reporting scheme is ATPS, but it hasn't seen much in the way of real world deployment. None of the others have documents attaching them to Authentication-Results. Does it still support ADSP or its obsolete in the new AUTH-RES as well? > This draft doesn't cover them because ADSP was declared Historic. However, previous versions did, so "dkim-adsp" is still a registered method (though it's marked "obsolete"). I think this draft should actually change their entries to "deprecated". -MSK --001a11c1b8f033fab705114cf5d5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, Mar 14, 2015 at 3:53 PM, Hector Santos <hsantos@= isdg.net> wrote:
For sentence #1,

=C2=A0 =C2=A0 =C2=A0.... indicate the results
=C2=A0 =C2=A0 =C2=A0of different message authentication efforts.

or

=C2=A0 =C2=A0 =C2=A0.... indicate the results of any internal message
=C2=A0 =C2=A0 =C2=A0authorization and authentication efforts.

They're not necessarily internal checks (where &= quot;internal", I assume, means "done by my ADMD").=C2=A0 Yo= u could decide to trust an upstream check from your ISP, for example.
= =C2=A0
I was under the impression that this header can only be "trusted"= internally, essentially by the creator to be used by the backend "rec= eiver-side" software or even at the UI hosted presentation?
<= /blockquote>

No, that's never been the case.=C2=A0 G= oing back as far as RFC5451 Section 5, we've always allowed for the pos= sibility of trusting information from outside.=C2=A0 You just have to decid= e you believe whatever the outside source is telling you.
=C2= =A0
The DKIM/ADSP/DMARC/SPF/OTHER machine domain host name creating this header= needs to be trusted.

Yes, that&#= 39;s the point, not that it has to be internal.
=C2=A0
The main reason I say this is because the first time I began to use this fo= r DKIM, I also used it for ADSP, Not SPF, nor ATPS.=C2=A0 SPF already had a= n internally produced and most importantly trusted result header (Received-= SPF) and AUTH-RES wasn't quite ready to pass all the essential, differe= nt A/A protocol process parameters information being done, including SPF an= d ATPS.

A-R predated ATPS, so the= y've always been compatible.=C2=A0 As for Received-SPF, the whole reaso= n this was introduced is because SPF created a header field for recording i= ts results, and DomainKeys proposed one as well.=C2=A0 Rather than having a= different one for every method, it made sense to create one extensible one= for this purpose.
=C2=A0
So I created the fields I needed.=C2=A0 =C2=A0Since it would intended for i= nternal consumption, other consumers like RFC-based Offline Mail Readers/Wr= iters, these offline MUAs should not rely on it.

Is this still true?

If by "t= his" you mean internal consumption, then yes, mostly; it's intende= d for consumption by downstream agents (filters and MUAs, mainly) that are = able to figure out which ones they believe.
=C2=A0
If so, what are the rules for th= is?

Several sections of RFC5451, such= as 2.3, 4.1, and 7, talk about when and how to consume the header field.= =C2=A0 All of this is carried forward into RFC7001 and now this document.=C2=A0
Ho= w about different AUTH-RES from different processing host?

Same answer.
=C2=A0
As a related tech note,=C2=A0 does the latest work reflect all the essentia= l information needed for?

=C2=A0 DKIM
=C2=A0 DMARC
=C2=A0 SPF

Yes.

Is it ready for indicating 3rd party results?
The only supported third-party reporting scheme is ATPS, but i= t hasn't seen much in the way of real world deployment.=C2=A0 None of t= he others have documents attaching them to Authentication-Results.

<= /div>
Does it still support ADSP or its obsolete in the new AUTH-RES as well?

This draft doesn't cover them because ADSP was= declared Historic.=C2=A0 However, previous versions did, so "dkim-ads= p" is still a registered method (though it's marked "obsolete= ").=C2=A0 I think this draft should actually change their entries to &= quot;deprecated".

-MSK
--001a11c1b8f033fab705114cf5d5-- From nobody Sun Mar 15 00:47:08 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3B611A1AFB for ; Sun, 15 Mar 2015 00:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vTqdI1UxMaaY for ; Sun, 15 Mar 2015 00:47:05 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 535CA1A1AB8 for ; Sun, 15 Mar 2015 00:47:05 -0700 (PDT) Received: by wggv3 with SMTP id v3so17248784wgg.1 for ; Sun, 15 Mar 2015 00:47:03 -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=Z7+01xXolVS95DIneRNYoEEEhC+50HOYPmkfxsZwnyc=; b=ZRNrxlRP1Z7s/3qGCNOaxFOnCiidkqR5iAa1Xj3DxRI5AakWCaWNGEM+eFp8fw3aXe xL1lJGirI16jGoifrZfzRXJqvBGmjtF1mwWY4BNLvdBCDoiBnu8qLjpFfXZFq3cE+Fev IR2vY2+FkZR3mFzzMYoRQHdnSBQNpBgwq3jifZf2t52pOdQufvt0gpyOu8Oy60ySd5nI K/TmWPqlJSs7rLftzIVdr/C1O+3BsM8Gb/ewFbU5QjQM+a2MW79bXo+GDcHnk/DVELFL uFMKK0X4IGdkU1ojD9qUCgTqoSkBQOHNwgqCQonZEFqTWoRKtbhJjXZmn6U8OupEoxbb fk1w== MIME-Version: 1.0 X-Received: by 10.194.185.68 with SMTP id fa4mr109239913wjc.111.1426405623837; Sun, 15 Mar 2015 00:47:03 -0700 (PDT) Received: by 10.27.179.212 with HTTP; Sun, 15 Mar 2015 00:47:03 -0700 (PDT) In-Reply-To: <00fb01d05e9a$dde6a840$4001a8c0@gateway.2wire.net> References: <018e01d05cba$e6ba8400$4001a8c0@gateway.2wire.net> <00fb01d05e9a$dde6a840$4001a8c0@gateway.2wire.net> Date: Sun, 15 Mar 2015 00:47:03 -0700 Message-ID: From: "Murray S. Kucherawy" To: "t.petch" Content-Type: multipart/alternative; boundary=047d7bacb11e83ba3305114ef0b5 Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-ietf-appsawg-rfc7001bis s2.7.1 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2015 07:47:06 -0000 --047d7bacb11e83ba3305114ef0b5 Content-Type: text/plain; charset=UTF-8 On Sat, Mar 14, 2015 at 2:07 PM, t.petch wrote: > True! It is RFC6376 and RFC4870 that I find unbalanced, that is, > s.2.7.1 plus RFC6376 tells me all I need to know, which s.2.7.1 plus > RFC4870 does not, which is not surprising because RFC4870 was written > without any consideration for an "Authentication-Results:" (naturally > enough). Which is why I have been looking for more in s.2.7.1. to help > the reader bridge the gap in order to find what they want in RFC4870. > OK, but it seems to me the key bits in both are: - how to verify a signature, and thus what constitutes a "pass" - the domain that signed it, pulled from the "d" tag (DK doesn't have an "i" tag) Those are the key things that go in an Authentication-Results field. Both documents do specify that. So which key details does RFC6376 have that RFC4870 doesn't? I realize I'm quite possibly looking at this from too close, so I appreciate the help in seeing what's deficient here. -MSK --047d7bacb11e83ba3305114ef0b5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, Mar 14, 2015 at 2:07 PM, t.petch <ietfc@btconne= ct.com> wrote:
True!=C2=A0 It= is RFC6376 and RFC4870 that I find unbalanced, that is,
s.2.7.1 plus RFC6376 tells me all I need to know, which s.2.7.1 plus
RFC4870 does not, which is not surprising because RFC4870 was written
without any consideration for an "Authentication-Results:" (natur= ally
enough).=C2=A0 Which is why I have been looking for more in s.2.7.1. to hel= p
the reader bridge the gap in order to find what they want in RFC4870.

OK, but it seems to me the key bits in both = are:

- how to verify a signature, and thus what constitut= es a "pass"
- the domain that signed it, pulled fro= m the "d" tag (DK doesn't have an "i" tag)

<= /div>
Those are the key things that go in an Authentication-Results fie= ld.=C2=A0 Both documents do specify that.=C2=A0 So which key details does R= FC6376 have that RFC4870 doesn't?

I realize I'm q= uite possibly looking at this from too close, so I appreciate the help in s= eeing what's deficient here.

-MSK
--047d7bacb11e83ba3305114ef0b5-- From nobody Sun Mar 15 03:18:51 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A62501A008A for ; Sun, 15 Mar 2015 03:18:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.699 X-Spam-Level: X-Spam-Status: No, score=0.699 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, J_CHICKENPOX_15=0.6, J_CHICKENPOX_62=0.6, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aj3ulQ2tW0Zx for ; Sun, 15 Mar 2015 03:18:46 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0726.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::726]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D16B1A007C for ; Sun, 15 Mar 2015 03:18:46 -0700 (PDT) Received: from pc6 (86.185.85.149) by DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) with Microsoft SMTP Server (TLS) id 15.1.112.19; Sun, 15 Mar 2015 09:55:34 +0000 Message-ID: <00a601d05f05$d94b2480$4001a8c0@gateway.2wire.net> From: t.petch To: "Murray S. Kucherawy" References: <018e01d05cba$e6ba8400$4001a8c0@gateway.2wire.net><00fb01d05e9a$dde6a840$4001a8c0@gateway.2wire.net> Date: Sun, 15 Mar 2015 09:51:23 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.185.85.149] X-ClientProxiedBy: DB4PR01CA0049.eurprd01.prod.exchangelabs.com (10.242.152.39) To DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB3PR07MB060; X-Forefront-Antispam-Report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(51444003)(377454003)(24454002)(47776003)(19580405001)(19580395003)(116806002)(230783001)(44716002)(66066001)(76176999)(81816999)(50986999)(84392001)(23676002)(33646002)(87976001)(93886004)(50466002)(110136001)(81686999)(50226001)(44736004)(1411001)(92566002)(77156002)(62966003)(40100003)(86362001)(77096005)(61296003)(42186005)(122386002)(46102003); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR07MB060; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:DB3PR07MB060; BCL:0; PCL:0; RULEID:; SRVR:DB3PR07MB060; X-Forefront-PRVS: 05168A3970 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Mar 2015 09:55:34.1782 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR07MB060 Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-ietf-appsawg-rfc7001bis s2.7.1 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2015 10:18:49 -0000 Murray To flesh out what I mean - s.2.7.1 says "Both DKIM and DomainKeys use the same result set" and goes on to list none: pass: fail: policy: neutral: temperror: permerror: while RFC4870 offers results of "good" "bad" "no key" "revoked" "no signature" "bad format" "non-participant" I struggle to see this as the same result set. - the value field in the IANA registry for dkim-adsp mentions 'From:' and I note the trailing colon and appreciate its significance. The value field for domainkeys has 'From' and 'Sender' without that colon. Significant? I don't know whether the colon-less version is meant to be the e-mail header field or something else related to it. Which leads me on to RFC4870 s3.1 which has a discussion on what to do when 'From' and/or 'Sender' appear as e-mail header fields. If s3.1 deems 'From:' (and it always uses colons) unacceptable, can it still appear as part of an 'E-mail Authentication Method'or is it barred from that? - and then the IANA registry only lists a property of 'd' with a ptype of 'header' whereas rfc7001 bis has 'DKIM-style values (e.g., "d" represents ...)'. e.g. means an example to me, one of many, RFC4870 lists other values, the IANA registry only lists one. Is 'd' the only valid value? If so, I think that that 'e.g.' is wrong. - ditto for a property of 'From' or 'Sender' with a ptype of 'header'. Again, rfc7001bis has 'e.g.' implying other values are possible, and RFC4870 has other values, but the IANA registry just has those two. I would like that clarified. - and then there is 'DomainKeys results are reported using the "header" ptype, but a mixture of DKIM-style values (...) and typical uses (........). ' which does not parse in my grammar (your grammar may be different:-) As I say, I see a gulf between the IANA registry and RFC4870 which needs more of a bridge than rfc7001bis currently provides. Tom Petch ----- Original Message ----- From: "Murray S. Kucherawy" To: "t.petch" Cc: "IETF Apps Discuss" Sent: Sunday, March 15, 2015 7:47 AM > On Sat, Mar 14, 2015 at 2:07 PM, t.petch wrote: > > > True! It is RFC6376 and RFC4870 that I find unbalanced, that is, > > s.2.7.1 plus RFC6376 tells me all I need to know, which s.2.7.1 plus > > RFC4870 does not, which is not surprising because RFC4870 was written > > without any consideration for an "Authentication-Results:" (naturally > > enough). Which is why I have been looking for more in s.2.7.1. to help > > the reader bridge the gap in order to find what they want in RFC4870. > > > > OK, but it seems to me the key bits in both are: > > - how to verify a signature, and thus what constitutes a "pass" > - the domain that signed it, pulled from the "d" tag (DK doesn't have an > "i" tag) > > Those are the key things that go in an Authentication-Results field. Both > documents do specify that. So which key details does RFC6376 have that > RFC4870 doesn't? > > I realize I'm quite possibly looking at this from too close, so I > appreciate the help in seeing what's deficient here. > > -MSK > From nobody Mon Mar 16 07:26:53 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E43141A87A8; Mon, 16 Mar 2015 07:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e5JWA5S-CGR9; Mon, 16 Mar 2015 07:26:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C5F921A87B0; Mon, 16 Mar 2015 07:26:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150316142646.17273.58290.idtracker@ietfa.amsl.com> Date: Mon, 16 Mar 2015 07:26:46 -0700 From: IETF Secretariat Archived-At: Subject: [apps-discuss] ID Tracker State Update Notice: X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 14:26:52 -0000 IESG state changed to Last Call Requested from AD Evaluation::AD Followup ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-multipart-form-data/ From nobody Mon Mar 16 07:26:55 2015 Return-Path: X-Original-To: expand-draft-ietf-appsawg-multipart-form-data.all@virtual.ietf.org Delivered-To: apps-discuss@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 0F9331A87AB; Mon, 16 Mar 2015 07:26:52 -0700 (PDT) X-Original-To: xfilter-draft-ietf-appsawg-multipart-form-data.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-appsawg-multipart-form-data.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E43141A87A8; Mon, 16 Mar 2015 07:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e5JWA5S-CGR9; Mon, 16 Mar 2015 07:26:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C5F921A87B0; Mon, 16 Mar 2015 07:26:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150316142646.17273.58290.idtracker@ietfa.amsl.com> Date: Mon, 16 Mar 2015 07:26:46 -0700 From: IETF Secretariat Archived-At: Subject: [apps-discuss] ID Tracker State Update Notice: X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 14:26:52 -0000 IESG state changed to Last Call Requested from AD Evaluation::AD Followup ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-multipart-form-data/ From nobody Mon Mar 16 07:27:48 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 228D91A87A3; Mon, 16 Mar 2015 07:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K_g01Pmbn0vC; Mon, 16 Mar 2015 07:27:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 97E3F1A87AA; Mon, 16 Mar 2015 07:27:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150316142741.15375.53532.idtracker@ietfa.amsl.com> Date: Mon, 16 Mar 2015 07:27:41 -0700 From: IETF Secretariat Archived-At: Subject: [apps-discuss] Telechat update notice: X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 14:27:44 -0000 Placed on agenda for telechat - 2015-04-09 ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-multipart-form-data/ From nobody Mon Mar 16 07:27:49 2015 Return-Path: X-Original-To: expand-draft-ietf-appsawg-multipart-form-data.all@virtual.ietf.org Delivered-To: apps-discuss@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 4489E1A87AA; Mon, 16 Mar 2015 07:27:44 -0700 (PDT) X-Original-To: xfilter-draft-ietf-appsawg-multipart-form-data.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-appsawg-multipart-form-data.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 228D91A87A3; Mon, 16 Mar 2015 07:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K_g01Pmbn0vC; Mon, 16 Mar 2015 07:27:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 97E3F1A87AA; Mon, 16 Mar 2015 07:27:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150316142741.15375.53532.idtracker@ietfa.amsl.com> Date: Mon, 16 Mar 2015 07:27:41 -0700 From: IETF Secretariat Archived-At: Subject: [apps-discuss] Telechat update notice: X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 14:27:44 -0000 Placed on agenda for telechat - 2015-04-09 ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-multipart-form-data/ From nobody Mon Mar 16 08:03:47 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD011A883E; Mon, 16 Mar 2015 08:03:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJvqvGTwbh5L; Mon, 16 Mar 2015 08:03:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 35F421A87CB; Mon, 16 Mar 2015 08:03:43 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 5.12.2 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150316150343.6724.94588.idtracker@ietfa.amsl.com> Date: Mon, 16 Mar 2015 08:03:43 -0700 Archived-At: Cc: apps-discuss@ietf.org Subject: [apps-discuss] Last Call: (Returning Values from Forms: multipart/form-data) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 15:03:46 -0000 The IESG has received a request from the Applications Area Working Group WG (appsawg) to consider the following document: - 'Returning Values from Forms: multipart/form-data' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-04-06. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This specification (re)defines the multipart/form-data Internet Media Type, which can be used by a wide variety of applications and transported by a wide variety of protocols as a way of returning a set of values as the result of a user filling out a form. It replaces RFC 2388. NOTE: There is a GitHub repository for this draft at The repository includes an issue tracker and a start on a test framework. It might be helpful to consult the repository when reviewing the draft. The draft file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-appsawg-multipart-form-data/ Once IESG discussion begins, it can be tracked via http://datatracker.ietf.org/doc/draft-ietf-appsawg-multipart-form-data/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Mar 16 08:04:07 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E5851A882D; Mon, 16 Mar 2015 08:04:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDRW2AXXibCj; Mon, 16 Mar 2015 08:04:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CA631A882E; Mon, 16 Mar 2015 08:03:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150316150345.6724.82613.idtracker@ietfa.amsl.com> Date: Mon, 16 Mar 2015 08:03:45 -0700 From: IETF Secretariat Archived-At: Subject: [apps-discuss] ID Tracker State Update Notice: X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 15:04:06 -0000 Last call has been made for draft-ietf-appsawg-multipart-form-data and state has been changed to In Last Call ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-multipart-form-data/ From nobody Mon Mar 16 14:19:23 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C89761A9102 for ; Mon, 16 Mar 2015 14:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, J_CHICKENPOX_62=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oYS88xrIHOlH for ; Mon, 16 Mar 2015 14:19:21 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD28E1A9149 for ; Mon, 16 Mar 2015 14:19:20 -0700 (PDT) Received: by wibg7 with SMTP id g7so48166885wib.1 for ; Mon, 16 Mar 2015 14:19: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=3/nPMc8dft7RjCJ6tMGR937PMDRx5r48Tq3NyD7UvrM=; b=hDLkJb6ioe/mHtOkNkYXJxiyfHruNDwJ/Kf7Jkgrc7ahOui7+HQ1z7M8m51scmouAt KGCgWaLu4zTQzkifcDIX8dIkGM8f2KeFiverugIdzBgq73ZzyZYKZn9yFs6Nj2ozhf+u KT+VlxTnTNOPCO7Tokum2uC/p37WwhzNmkMf4QA6qo4WJV74ajYRs8fYrEeGl8yOBWsZ +nT4vna4xjE5mVncQBEJG/EDUMsBENZG0BdkuYVYW+HCzV3Dov6WQVdHZYnUohjFVS8E s3wASNYM/5fPHIigW/Coprg4nsFv0L3avtLxT/fuMx9nAL/fUp7QUSNVOJTETEI1K9+t Gr9A== MIME-Version: 1.0 X-Received: by 10.180.187.171 with SMTP id ft11mr82345113wic.0.1426540759415; Mon, 16 Mar 2015 14:19:19 -0700 (PDT) Received: by 10.27.179.212 with HTTP; Mon, 16 Mar 2015 14:19:19 -0700 (PDT) In-Reply-To: <00a601d05f05$d94b2480$4001a8c0@gateway.2wire.net> References: <018e01d05cba$e6ba8400$4001a8c0@gateway.2wire.net> <00fb01d05e9a$dde6a840$4001a8c0@gateway.2wire.net> <00a601d05f05$d94b2480$4001a8c0@gateway.2wire.net> Date: Mon, 16 Mar 2015 14:19:19 -0700 Message-ID: From: "Murray S. Kucherawy" To: "t.petch" Content-Type: multipart/alternative; boundary=001a11c38e9c392dfe05116e6790 Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-ietf-appsawg-rfc7001bis s2.7.1 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 21:19:23 -0000 --001a11c38e9c392dfe05116e6790 Content-Type: text/plain; charset=UTF-8 On Sun, Mar 15, 2015 at 2:51 AM, t.petch wrote: > - s.2.7.1 says "Both DKIM and DomainKeys use the same result set" and > goes on to list > none: pass: fail: policy: neutral: temperror: > permerror: > while RFC4870 offers results of > "good" "bad" "no key" "revoked" "no signature" "bad format" > "non-participant" > I struggle to see this as the same result set. > -04 now makes it clear that the result set in RFC4870 is plainly not used in the context of this header field. > - the value field in the IANA registry for dkim-adsp mentions 'From:' > and I note the trailing colon and appreciate its significance. The > value field for domainkeys has 'From' and 'Sender' without that colon. > Significant? I don't know whether the colon-less version is meant to be > the e-mail header field or something else related to it. Which leads > me on to RFC4870 s3.1 which has a discussion on what to do when 'From' > and/or 'Sender' appear as e-mail header fields. If s3.1 deems 'From:' > (and it always uses colons) unacceptable, can it still appear as part of > an 'E-mail Authentication Method'or is it barred from that? > This seems like a stylistic distinction rather than a semantic one. What, for example, is the difference between "From header field" and "From: header field"? Are you just looking to have the registry entries for domainkeys changed such that they look like the DKIM ones? They read pretty much the same to me, but I can certainly do that if it would help. > - and then the IANA registry only lists a property of 'd' with a ptype > of 'header' whereas rfc7001 bis has 'DKIM-style values (e.g., "d" > represents ...)'. e.g. means an example to me, one of many, RFC4870 > lists other values, the IANA registry only lists one. Is 'd' the only > valid value? If so, I think that that 'e.g.' is wrong. > Removed "e.g.". > - ditto for a property of 'From' or 'Sender' with a ptype of 'header'. > Again, rfc7001bis has 'e.g.' implying other values are possible, and > RFC4870 has other values, but the IANA registry just has those two. > I would like that clarified. > Removed "e.g.". > - and then there is > 'DomainKeys results are reported using the "header" ptype, but a > mixture of DKIM-style values (...) and typical uses > (........). ' > which does not parse in my grammar (your grammar may be different:-) > Reworded to: DomainKeys results are reported using the "header" ptype, but the property can be either the name of a DKIM tag ("d" represents the value of the "d" tag from the DomainKey-Signature header field) or the name of a relevant header field ("from" or "sender, containing those header fields' values, per Section 3.1 of [DOMAINKEYS]). In the latter case, [MAIL]-style comments are removed, leaving only the address; moreover, the local-part of the address is removed if it has not been authenticated in some way. As I say, I see a gulf between the IANA registry and RFC4870 which needs > more of a bridge than rfc7001bis currently provides. > Does this clarify sufficiently? -MSK --001a11c38e9c392dfe05116e6790 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sun, Mar 15, 2015 at 2:51 AM, t.petch <ietfc@btconne= ct.com> wrote:
- s.2.7.1 says=C2=A0 "Both D= KIM and DomainKeys use the same result set" and
goes on to list
=C2=A0 none:=C2=A0 =C2=A0 =C2=A0pass:=C2=A0 =C2=A0 =C2=A0fail:=C2=A0 =C2=A0= =C2=A0policy:=C2=A0 =C2=A0 neutral:=C2=A0 =C2=A0 =C2=A0temperror:
permerror:
while RFC4870 offers results of
=C2=A0"good"=C2=A0 =C2=A0 "bad"=C2=A0 =C2=A0"no ke= y"=C2=A0 =C2=A0"revoked" "no signature"=C2=A0 &quo= t;bad format"
"non-participant"
I struggle to see this as the same result set.

-04 now makes it clear that the result set in RFC4870 is plainly no= t used in the context of this header field.
=C2=A0
- the value field in the IANA registry for dkim-adsp mentions 'From:= 9;
and I note the trailing colon and appreciate its significance.=C2=A0 The value field for domainkeys has 'From' and 'Sender' without = that colon.
Significant?=C2=A0 I don't know whether the colon-less version is meant= to be
the e-mail header field or something else related to it.=C2=A0 Which leads<= br> me on to RFC4870 s3.1 which has a discussion on what to do when 'From&#= 39;
and/or 'Sender' appear as e-mail header fields.=C2=A0 If s3.1 deems= 'From:'
(and it always uses colons) unacceptable, can it still appear as part of an 'E-mail Authentication Method'or is it barred from that?

This seems like a stylistic distinction rather= than a semantic one.=C2=A0 What, for example, is the difference between &q= uot;From header field" and "From: header field"?

Are you just looking to have the registry entries for domainkeys cha= nged such that they look like the DKIM ones?=C2=A0 They read pretty much th= e same to me, but I can certainly do that if it would help.
= =C2=A0
- and then the IANA registry only lists a property of 'd' with a pt= ype
of=C2=A0 'header' whereas rfc7001 bis has 'DKIM-style values (e= .g., "d"
represents=C2=A0 ...)'.=C2=A0 e.g. means an example to me, one of many,= RFC4870
lists other values, the IANA registry only lists one.=C2=A0 Is 'd' = the only
valid value?=C2=A0 If so, I think that that 'e.g.' is wrong.

Removed "e.g.".
=C2=A0
=
- ditto for a property of=C2=A0 'From' or 'Sender' with a p= type of 'header'.
Again, rfc7001bis has 'e.g.' implying other values are possible, an= d
RFC4870 has other values, but the IANA registry just has those two.
I would like that clarified.

Removed &q= uot;e.g.".
=C2=A0
- and then there is
'DomainKeys results are reported using the "header" ptype, bu= t a
=C2=A0 =C2=A0mixture of DKIM-style values (...) and typical uses
=C2=A0 =C2=A0(........). '
which does not parse in my grammar (your grammar may be different:-)

Reworded to:

DomainKeys res= ults are reported using the "header" ptype, but the property can = be either the name of a DKIM tag ("d" represents the value of the= "d" tag from the DomainKey-Signature header field) or the name o= f a relevant header field ("from" or "sender, containing tho= se header fields' values, per Section 3.1 of [DOMAINKEYS]).=C2=A0 In th= e latter case, [MAIL]-style comments are removed, leaving only the address;= moreover, the local-part of the address is removed if it has not been auth= enticated in some way.

As I say, I see a gulf between the IANA registry and RFC4870 which needs more of a bridge than rfc7001bis currently provides.
<= br>
Does this clarify sufficiently?

-MSK
--001a11c38e9c392dfe05116e6790-- From nobody Mon Mar 16 14:23:07 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC3B1A9151 for ; Mon, 16 Mar 2015 14:23:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.802 X-Spam-Level: X-Spam-Status: No, score=-0.802 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_15=0.6, J_CHICKENPOX_62=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9JnxG6nQ8iYG for ; Mon, 16 Mar 2015 14:23:04 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FCF01A9166 for ; Mon, 16 Mar 2015 14:23:04 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 81F84C40132 for ; Mon, 16 Mar 2015 16:23:03 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1426540983; bh=7up8l8dg9Q1XLzTwvwGa8FtuAnyfhTuVthDsfL+5ZGE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=VnkYTxLyldfaSXPGY5Fb49Iyd+QyrMLOGBnQkyik8iau084TxgVzbjZ3RwCU3nYBl J3946WaBAlHwPKX5d9aHZKCrOwJSXld5yHglBa71niUcoS7wx6B+uPi90/dDjNNUKI PodNZI7MxYqXdxId1PUVZqlpfmEqZUz8jZXudkP8= From: Scott Kitterman To: apps-discuss@ietf.org Date: Mon, 16 Mar 2015 17:23:03 -0400 Message-ID: <4649378.GyMiKQ6r2m@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-46-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <018e01d05cba$e6ba8400$4001a8c0@gateway.2wire.net> <00a601d05f05$d94b2480$4001a8c0@gateway.2wire.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [apps-discuss] draft-ietf-appsawg-rfc7001bis s2.7.1 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 21:23:06 -0000 On Monday, March 16, 2015 02:19:19 PM Murray S. Kucherawy wrote: > On Sun, Mar 15, 2015 at 2:51 AM, t.petch wrote: > > - s.2.7.1 says "Both DKIM and DomainKeys use the same result set" and > > goes on to list > > > > none: pass: fail: policy: neutral: temperror: > > permerror: > > while RFC4870 offers results of > > > > "good" "bad" "no key" "revoked" "no signature" "bad format" > > > > "non-participant" > > I struggle to see this as the same result set. > > -04 now makes it clear that the result set in RFC4870 is plainly not used > in the context of this header field. > > > - the value field in the IANA registry for dkim-adsp mentions 'From:' > > and I note the trailing colon and appreciate its significance. The > > value field for domainkeys has 'From' and 'Sender' without that colon. > > Significant? I don't know whether the colon-less version is meant to be > > the e-mail header field or something else related to it. Which leads > > me on to RFC4870 s3.1 which has a discussion on what to do when 'From' > > and/or 'Sender' appear as e-mail header fields. If s3.1 deems 'From:' > > (and it always uses colons) unacceptable, can it still appear as part of > > an 'E-mail Authentication Method'or is it barred from that? > > This seems like a stylistic distinction rather than a semantic one. What, > for example, is the difference between "From header field" and "From: > header field"? > > Are you just looking to have the registry entries for domainkeys changed > such that they look like the DKIM ones? They read pretty much the same to > me, but I can certainly do that if it would help. > > > - and then the IANA registry only lists a property of 'd' with a ptype > > of 'header' whereas rfc7001 bis has 'DKIM-style values (e.g., "d" > > represents ...)'. e.g. means an example to me, one of many, RFC4870 > > lists other values, the IANA registry only lists one. Is 'd' the only > > valid value? If so, I think that that 'e.g.' is wrong. > > Removed "e.g.". > > > - ditto for a property of 'From' or 'Sender' with a ptype of 'header'. > > Again, rfc7001bis has 'e.g.' implying other values are possible, and > > RFC4870 has other values, but the IANA registry just has those two. > > I would like that clarified. > > Removed "e.g.". > > > - and then there is > > 'DomainKeys results are reported using the "header" ptype, but a > > > > mixture of DKIM-style values (...) and typical uses > > (........). ' > > > > which does not parse in my grammar (your grammar may be different:-) > > Reworded to: > > DomainKeys results are reported using the "header" ptype, but the property > can be either the name of a DKIM tag ("d" represents the value of the "d" > tag from the DomainKey-Signature header field) or the name of a relevant > header field ("from" or "sender, containing those header fields' values, > per Section 3.1 of [DOMAINKEYS]). In the latter case, [MAIL]-style > comments are removed, leaving only the address; moreover, the local-part of > the address is removed if it has not been authenticated in some way. Shouldn't that be a DK tag vice DKIM since we're on DK, not DKIM here? Scott K > > As I say, I see a gulf between the IANA registry and RFC4870 which needs > > more of a bridge than rfc7001bis currently provides. > > Does this clarify sufficiently? > > -MSK From nobody Mon Mar 16 14:59:26 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24A1C1A92E8 for ; Mon, 16 Mar 2015 14:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SUAMmItAfXaO for ; Mon, 16 Mar 2015 14:59:24 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B98BE1A1B8F for ; Mon, 16 Mar 2015 14:59:23 -0700 (PDT) Received: by wibdy8 with SMTP id dy8so48810981wib.0 for ; Mon, 16 Mar 2015 14:59:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0YPloY+tswKYH8blp01MqSPrv02lJcmiCv31B+Iz4Y4=; b=UCJC1tR6J7zDG1IXTO7zoDWxATeumOCH3cNqnd8fBE+lvln+cjmwz796e9DJuKJPGA uBY5MfwSUfOsj8tDBDiNHYCJ9JUGDw860p206tDRD2WZEAnuDy3KZRm7Kapmgxi1lC3k +IESOJYdCKg9NAtXDx9qUvVGUa5o6GEFgHg1FBcFDE445Lc7rNFv/c92+754m26oxEJu 60VJbkXF8LYwxqoHA1ql2UvwmWYfTuziL89ZHYEN9+lRqMh+J4RlFFfEKpYjbsvRIde2 XcDRB5RfImecfxVyEYl/mh49yUbFmdib8lGG1tSD1Zr6Q3TvwttWH2M+35pdNcDkANRK OGgw== MIME-Version: 1.0 X-Received: by 10.194.79.226 with SMTP id m2mr125411340wjx.60.1426543162531; Mon, 16 Mar 2015 14:59:22 -0700 (PDT) Received: by 10.27.179.212 with HTTP; Mon, 16 Mar 2015 14:59:22 -0700 (PDT) In-Reply-To: <4649378.GyMiKQ6r2m@kitterma-e6430> References: <018e01d05cba$e6ba8400$4001a8c0@gateway.2wire.net> <00a601d05f05$d94b2480$4001a8c0@gateway.2wire.net> <4649378.GyMiKQ6r2m@kitterma-e6430> Date: Mon, 16 Mar 2015 14:59:22 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=047d7bf0c53875a42305116ef6c1 Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-ietf-appsawg-rfc7001bis s2.7.1 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 21:59:25 -0000 --047d7bf0c53875a42305116ef6c1 Content-Type: text/plain; charset=UTF-8 On Mon, Mar 16, 2015 at 2:23 PM, Scott Kitterman wrote: > > DomainKeys results are reported using the "header" ptype, but the > property > > can be either the name of a DKIM tag ("d" represents the value of the "d" > > tag from the DomainKey-Signature header field) or the name of a relevant > > header field ("from" or "sender, containing those header fields' values, > > per Section 3.1 of [DOMAINKEYS]). In the latter case, [MAIL]-style > > comments are removed, leaving only the address; moreover, the local-part > of > > the address is removed if it has not been authenticated in some way. > > Shouldn't that be a DK tag vice DKIM since we're on DK, not DKIM here? > Quite right, fixed. -MSK --047d7bf0c53875a42305116ef6c1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Mar 16, 2015 at 2:23 PM, Scott Kitterman <scott= @kitterman.com> wrote:
> DomainKeys results are reported using the "header&= quot; ptype, but the property
> can be either the name of a DKIM tag ("d" represents the val= ue of the "d"
> tag from the DomainKey-Signature header field) or the name of a releva= nt
> header field ("from" or "sender, containing those heade= r fields' values,
> per Section 3.1 of [DOMAINKEYS]).=C2=A0 In the latter case, [MAIL]-sty= le
> comments are removed, leaving only the address; moreover, the local-pa= rt of
> the address is removed if it has not been authenticated in some way.
Shouldn't that be a DK tag vice DKIM since we're on DK,= not DKIM here?

Quite right, fixed.
=
-MSK
--047d7bf0c53875a42305116ef6c1-- From nobody Tue Mar 17 03:30:37 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 623AA1A0222 for ; Tue, 17 Mar 2015 03:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, J_CHICKENPOX_62=0.6, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LBAwglP6pW1o for ; Tue, 17 Mar 2015 03:30:20 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0703.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::703]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC4781A01F9 for ; Tue, 17 Mar 2015 03:30:19 -0700 (PDT) Received: from pc6 (86.185.85.149) by AMSPR07MB049.eurprd07.prod.outlook.com (10.242.81.11) with Microsoft SMTP Server (TLS) id 15.1.112.19; Tue, 17 Mar 2015 10:26:52 +0000 Message-ID: <014e01d0609c$8c181ea0$4001a8c0@gateway.2wire.net> From: t.petch To: "Murray S. Kucherawy" References: <018e01d05cba$e6ba8400$4001a8c0@gateway.2wire.net><00fb01d05e9a$dde6a840$4001a8c0@gateway.2wire.net><00a601d05f05$d94b2480$4001a8c0@gateway.2wire.net> Date: Tue, 17 Mar 2015 10:19:30 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.185.85.149] X-ClientProxiedBy: DB3PR05CA0048.eurprd05.prod.outlook.com (25.160.41.176) To AMSPR07MB049.eurprd07.prod.outlook.com (10.242.81.11) Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB049; X-Forefront-Antispam-Report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(24454002)(51704005)(13464003)(377454003)(47776003)(62236002)(66066001)(50466002)(44716002)(230783001)(116806002)(23676002)(1556002)(42186005)(87976001)(46102003)(61296003)(19580405001)(19580395003)(1411001)(44736004)(77096005)(50226001)(1456003)(77156002)(62966003)(76176999)(81686999)(33646002)(86362001)(122386002)(81816999)(40100003)(92566002)(110136001)(50986999)(93886004)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMSPR07MB049; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:AMSPR07MB049; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB049; X-Forefront-PRVS: 0518EEFB48 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Mar 2015 10:26:52.3747 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB049 Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-ietf-appsawg-rfc7001bis s2.7.1 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 10:30:22 -0000 ----- Original Message ----- From: "Murray S. Kucherawy" To: "t.petch" Cc: "IETF Apps Discuss" Sent: Monday, March 16, 2015 9:19 PM > On Sun, Mar 15, 2015 at 2:51 AM, t.petch wrote: > > > - s.2.7.1 says "Both DKIM and DomainKeys use the same result set" and > > goes on to list > > none: pass: fail: policy: neutral: temperror: > > permerror: > > while RFC4870 offers results of > > "good" "bad" "no key" "revoked" "no signature" "bad format" > > "non-participant" > > I struggle to see this as the same result set. > > > -04 now makes it clear that the result set in RFC4870 is plainly not used > in the context of this header field. > > > - the value field in the IANA registry for dkim-adsp mentions 'From:' > > and I note the trailing colon and appreciate its significance. The > > value field for domainkeys has 'From' and 'Sender' without that colon. > > Significant? I don't know whether the colon-less version is meant to be > > the e-mail header field or something else related to it. Which leads > > me on to RFC4870 s3.1 which has a discussion on what to do when 'From' > > and/or 'Sender' appear as e-mail header fields. If s3.1 deems 'From:' > > (and it always uses colons) unacceptable, can it still appear as part of > > an 'E-mail Authentication Method'or is it barred from that? > > > This seems like a stylistic distinction rather than a semantic one. What, > for example, is the difference between "From header field" and "From: > header field"? > > Are you just looking to have the registry entries for domainkeys changed > such that they look like the DKIM ones? They read pretty much the same to > me, but I can certainly do that if it would help. > > > - and then the IANA registry only lists a property of 'd' with a ptype > > of 'header' whereas rfc7001 bis has 'DKIM-style values (e.g., "d" > > represents ...)'. e.g. means an example to me, one of many, RFC4870 > > lists other values, the IANA registry only lists one. Is 'd' the only > > valid value? If so, I think that that 'e.g.' is wrong. > > > Removed "e.g.". > > > - ditto for a property of 'From' or 'Sender' with a ptype of 'header'. > > Again, rfc7001bis has 'e.g.' implying other values are possible, and > > RFC4870 has other values, but the IANA registry just has those two. > > I would like that clarified. > > > Removed "e.g.". > > > - and then there is > > 'DomainKeys results are reported using the "header" ptype, but a > > mixture of DKIM-style values (...) and typical uses > > (........). ' > > which does not parse in my grammar (your grammar may be different:-) > > > Reworded to: > > DomainKeys results are reported using the "header" ptype, but the property > can be either the name of a DKIM tag ("d" represents the value of the "d" > tag from the DomainKey-Signature header field) or the name of a relevant > header field ("from" or "sender, containing those header fields' values, > per Section 3.1 of [DOMAINKEYS]). In the latter case, [MAIL]-style > comments are removed, leaving only the address; moreover, the local-part of > the address is removed if it has not been authenticated in some way. > > As I say, I see a gulf between the IANA registry and RFC4870 which needs > > more of a bridge than rfc7001bis currently provides. > > > Does this clarify sufficiently? Much clearer, with those colons added please to the entries in the IANA Registry.. The one lingering doubt is RFC4870 s3.1 which has a discussion on what to do when 'From' and/or 'Sender' appear as e-mail header fields. If s3.1 deems 'From:' unacceptable, can it still appear as part of an 'E-mail Authentication Method'? Or is the idea that 'From:' can only appear if it passes the tests in RFC4870 s3.1? I don't know what the answer it to that one. Tom Petch > -MSK > From nobody Tue Mar 17 11:31:28 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B68191A897D; Mon, 16 Mar 2015 10:58:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.49 X-Spam-Level: X-Spam-Status: No, score=-0.49 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X6iq9pBrqtPg; Mon, 16 Mar 2015 10:58:49 -0700 (PDT) Received: from smtp1.lax.icann.org (smtp01.icann.org [192.0.33.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF7DF1A8981; Mon, 16 Mar 2015 10:58:48 -0700 (PDT) Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id t2GHwmqH025797; Mon, 16 Mar 2015 17:58:48 GMT Received: by request3.lax.icann.org (Postfix, from userid 48) id 89927C207E3; Mon, 16 Mar 2015 17:58:48 +0000 (UTC) RT-Owner: pearl.liang From: "Pearl Liang via RT" In-Reply-To: References: Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #812412 X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/) X-RT-Originator: pearl.liang@icann.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Mon, 16 Mar 2015 17:58:48 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Tue, 17 Mar 2015 11:31:26 -0700 Cc: appsawg-chairs@ietf.org, draft-ietf-appsawg-uri-scheme-reg.all@ietf.org, iesg@ietf.org, apps-discuss@ietf.org Subject: [apps-discuss] [IANA #812412] Expert Review - draft-ietf-appsawg-uri-scheme-reg-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Reply-To: drafts-expert-review@iana.org List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 17:58:54 -0000 Dear Authors, Upon review, Graham Klyne has approved the requested new URI scheme and raised some comments and question: ... I'm also taking this opportunity to review the current version and make some final comments. These are pretty much all editorial, and I'm assuming they could be addressed (or not) in any AUTH48 period without requiring further public review. Section 3. "For IETF Standards-Track documents, Permanent registration status is REQUIRED." Reading this now, I find the drafting here is potentially confusing. Suggest: "For URI schemes defined or normatively referenced by IETF Standards-Track documents, Permanent registration status is REQUIRED." Section 3.3 "Schemes that are not intended to be used as locators SHOULD describe how the resource identified can be determined or accessed by software that obtains a URI of that scheme." This doesn't seem quite right to me. Schemes that are not intended to be used as locators aren't generally expected to be accessed by software (though they may be in particular circumstances). I think then point that needs to be made here is that there should be some defined structure of naming authority for the scheme, which is not necessarily interpretable by software. E.g., something like: "Schemes that are not intended to be used as locators SHOULD describe how the resource identified can be determined or accessed by an agent that obtains a URI of that scheme." Section 7.2: " 8. Once Expert Review approves registration for a given status, IANA adds the registration to the registry." I note that the scheme has already been added to the registry at prior step 3. Suggest: " 8. Once Expert Review approves registration for a given status, IANA updates the registration (per step 3) to indicate the approved status. " Section 8: I was somewhat thrown by the heading of section 8.1. "8.1. "Example" Scheme Registration Request" I think the intent would be clearer if the section title were given as: "8.1. "Example" Scheme Registration Template" ... - Regarding the Pending Review Status: Section 7.2, a step 3 said: 3. Otherwise, IANA enters the registration request in the IANA registry, with status marked as "Pending Review" and the remainder of this section applies. Question: Shall IANA remove the "Pending Review" URI scheme from the registry if a new 'requested' permanent URI scheme is not being accepted after DE reviewed (step 4/5)? Or it is okay to keep the Pending Review entry in the such status as long as it is under "additional review or discussion"? The scheme may not be approved for its requested status. If not accepted, I imagine would would revert to "provisional" status (which does not require approval if it meets the minimal criteria set out). But I agree that this should probably be clarified. ...... We (IANA) need to know how we should manage the "Pending Review" URI scheme listed in the registry if any. Note: The action(s) requested in this document will not be completed until the document has been approved for publication as an RFC. Thanks, ~pl Pearl Liang ICANN From nobody Tue Mar 17 11:31:30 2015 Return-Path: X-Original-To: expand-draft-ietf-appsawg-uri-scheme-reg.all@virtual.ietf.org Delivered-To: apps-discuss@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id E33F81A8981; Mon, 16 Mar 2015 10:58:54 -0700 (PDT) X-Original-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B68191A897D; Mon, 16 Mar 2015 10:58:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.49 X-Spam-Level: X-Spam-Status: No, score=-0.49 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X6iq9pBrqtPg; Mon, 16 Mar 2015 10:58:49 -0700 (PDT) Received: from smtp1.lax.icann.org (smtp01.icann.org [192.0.33.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF7DF1A8981; Mon, 16 Mar 2015 10:58:48 -0700 (PDT) Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id t2GHwmqH025797; Mon, 16 Mar 2015 17:58:48 GMT Received: by request3.lax.icann.org (Postfix, from userid 48) id 89927C207E3; Mon, 16 Mar 2015 17:58:48 +0000 (UTC) RT-Owner: pearl.liang From: "Pearl Liang via RT" In-Reply-To: References: Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #812412 X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/) X-RT-Originator: pearl.liang@icann.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Mon, 16 Mar 2015 17:58:48 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Tue, 17 Mar 2015 11:31:27 -0700 Cc: appsawg-chairs@ietf.org, draft-ietf-appsawg-uri-scheme-reg.all@ietf.org, iesg@ietf.org, apps-discuss@ietf.org Subject: [apps-discuss] [IANA #812412] Expert Review - draft-ietf-appsawg-uri-scheme-reg-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Reply-To: drafts-expert-review@iana.org List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 17:58:55 -0000 Dear Authors, Upon review, Graham Klyne has approved the requested new URI scheme and raised some comments and question: ... I'm also taking this opportunity to review the current version and make some final comments. These are pretty much all editorial, and I'm assuming they could be addressed (or not) in any AUTH48 period without requiring further public review. Section 3. "For IETF Standards-Track documents, Permanent registration status is REQUIRED." Reading this now, I find the drafting here is potentially confusing. Suggest: "For URI schemes defined or normatively referenced by IETF Standards-Track documents, Permanent registration status is REQUIRED." Section 3.3 "Schemes that are not intended to be used as locators SHOULD describe how the resource identified can be determined or accessed by software that obtains a URI of that scheme." This doesn't seem quite right to me. Schemes that are not intended to be used as locators aren't generally expected to be accessed by software (though they may be in particular circumstances). I think then point that needs to be made here is that there should be some defined structure of naming authority for the scheme, which is not necessarily interpretable by software. E.g., something like: "Schemes that are not intended to be used as locators SHOULD describe how the resource identified can be determined or accessed by an agent that obtains a URI of that scheme." Section 7.2: " 8. Once Expert Review approves registration for a given status, IANA adds the registration to the registry." I note that the scheme has already been added to the registry at prior step 3. Suggest: " 8. Once Expert Review approves registration for a given status, IANA updates the registration (per step 3) to indicate the approved status. " Section 8: I was somewhat thrown by the heading of section 8.1. "8.1. "Example" Scheme Registration Request" I think the intent would be clearer if the section title were given as: "8.1. "Example" Scheme Registration Template" ... - Regarding the Pending Review Status: Section 7.2, a step 3 said: 3. Otherwise, IANA enters the registration request in the IANA registry, with status marked as "Pending Review" and the remainder of this section applies. Question: Shall IANA remove the "Pending Review" URI scheme from the registry if a new 'requested' permanent URI scheme is not being accepted after DE reviewed (step 4/5)? Or it is okay to keep the Pending Review entry in the such status as long as it is under "additional review or discussion"? The scheme may not be approved for its requested status. If not accepted, I imagine would would revert to "provisional" status (which does not require approval if it meets the minimal criteria set out). But I agree that this should probably be clarified. ...... We (IANA) need to know how we should manage the "Pending Review" URI scheme listed in the registry if any. Note: The action(s) requested in this document will not be completed until the document has been approved for publication as an RFC. Thanks, ~pl Pearl Liang ICANN From nobody Tue Mar 17 23:12:37 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 376F01A8A84 for ; Tue, 17 Mar 2015 23:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OHuv78FtMLvG for ; Tue, 17 Mar 2015 23:12:35 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E91BE1A0069 for ; Tue, 17 Mar 2015 23:12:34 -0700 (PDT) Received: by wibdy8 with SMTP id dy8so81094465wib.0 for ; Tue, 17 Mar 2015 23:12:33 -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=mCYu2HoWSBlbswMDVp6rogYz6VTEla0+ehf4yF5/XAU=; b=BPtiaagMekAqtWumJ2/FzCald7RRVR7oIueqM/q0Etv5bwsy0RUIPAJ2nUOOjcbt4k KUM4Vt/nY28g9usUX3snDkabZhwPIhnwdIuBdSaVIRFnJmTQ4gIK6pGwKELpduoswJ1H NLzPd291Zm5t1Aeycs/VksvjK8fT45Wit0/vuGWSihPiwnZTn77N3RArsxfTtPj4gy6V kjhbAFqP37myEDpJ3FfoLxRUbDc0tpWD3OL/xyBawHq577tgTnQPyNwTJUSbWHxinqkd sSPIfKLsR734kfVs3+lcswYF2GMLzUSXbjbS8WWJnfT6pZHOAAX8vPPBKIrSCYJkbyRt ORrg== MIME-Version: 1.0 X-Received: by 10.180.77.166 with SMTP id t6mr3980574wiw.52.1426659153721; Tue, 17 Mar 2015 23:12:33 -0700 (PDT) Received: by 10.27.179.212 with HTTP; Tue, 17 Mar 2015 23:12:33 -0700 (PDT) In-Reply-To: <014e01d0609c$8c181ea0$4001a8c0@gateway.2wire.net> References: <018e01d05cba$e6ba8400$4001a8c0@gateway.2wire.net> <00fb01d05e9a$dde6a840$4001a8c0@gateway.2wire.net> <00a601d05f05$d94b2480$4001a8c0@gateway.2wire.net> <014e01d0609c$8c181ea0$4001a8c0@gateway.2wire.net> Date: Tue, 17 Mar 2015 23:12:33 -0700 Message-ID: From: "Murray S. Kucherawy" To: "t.petch" Content-Type: multipart/alternative; boundary=f46d043d645f12bd34051189f8ea Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-ietf-appsawg-rfc7001bis s2.7.1 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 06:12:36 -0000 --f46d043d645f12bd34051189f8ea Content-Type: text/plain; charset=UTF-8 On Tue, Mar 17, 2015 at 3:19 AM, t.petch wrote: > The one lingering doubt is RFC4870 s3.1 which has a discussion on what > to do when 'From' and/or 'Sender' appear as e-mail header fields. If > s3.1 deems 'From:' unacceptable, can it still appear as part of an > 'E-mail Authentication Method'? Or is the idea that 'From:' can only > appear if it passes the tests in RFC4870 s3.1? > > I don't know what the answer it to that one. > 3.1 explains how to select the message sender (as the term is used in RFC4870) from one of two header fields. The intent with A-R is to report the sender address and which header field it came from. I've update the text to say so. While I'm at it, I also cleaned up the Result Names registry which seems to have gotten into a confused state, and marked the ADSP and DomainKeys entries in both registries as "deprecated" since their defining RFCs are also in that state. I'll post -04 once the embargo lifts on Monday. -MSK --f46d043d645f12bd34051189f8ea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Mar 17, 2015 at 3:19 AM, t.petch <ietfc@btconne= ct.com> wrote:
The one linger= ing doubt is RFC4870 s3.1 which has a discussion on what
to do when 'From' and/or 'Sender' appear a= s e-mail header fields.=C2=A0 If
s3.1 deems 'From:' unacceptable, can it still appear as part= of an
'E-mail Authentication Method'?=C2=A0 Or is the idea that 'From= :' can only
appear if it passes the tests in RFC4870 s3.1?

I don't know what the answer it to that one.

<= /div>
3.1 explains how to select the message sender (as the term is use= d in RFC4870) from one of two header fields.=C2=A0 The intent with A-R is t= o report the sender address and which header field it came from.=C2=A0 I= 9;ve update the text to say so.

While I'm at it, I al= so cleaned up the Result Names registry which seems to have gotten into a c= onfused state, and marked the ADSP and DomainKeys entries in both registrie= s as "deprecated" since their defining RFCs are also in that stat= e.

I'll post -04 once the embargo lifts on Monday.
-MSK
--f46d043d645f12bd34051189f8ea-- From nobody Wed Mar 18 07:59:39 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABDB41A19FE; Wed, 18 Mar 2015 07:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4FwmPcYXaDZs; Wed, 18 Mar 2015 07:59:30 -0700 (PDT) Received: from statler.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id 3ED0F1A19F0; Wed, 18 Mar 2015 07:59:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1426690769; d=isode.com; s=selector; i=@isode.com; bh=S1Yc2q3mU4OGStCLwZXSQxfh9CJpj/gBIVfyHmjzh08=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=ZSldawc4WVc0iNozQIFdo7eDB8RC9EhBdORMSod973Og/itf1Ga7atnW0YuBRHe3qwQj6v ssfcZfAHdDcIGWN5L4+5dSP8KZzPT1cEYoIv/fO8qII7DXCUMojOQGJ1rcDogmc7ku20W4 baYlFWW3wWky8Nh+8qYt+iVMe1g8j40=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 18 Mar 2015 14:59:28 +0000 Message-ID: <550992C1.8060809@isode.com> Date: Wed, 18 Mar 2015 14:59:13 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 To: drafts-expert-review@iana.org References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: appsawg-chairs@ietf.org, draft-ietf-appsawg-uri-scheme-reg.all@ietf.org, iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] [IANA #812412] Expert Review - draft-ietf-appsawg-uri-scheme-reg-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 14:59:34 -0000 On 16/03/2015 17:58, Pearl Liang via RT wrote: > Dear Authors, > > Upon review, Graham Klyne has approved the requested new URI scheme and raised > some comments and question: > > ... > > I'm also taking this opportunity to review the current version and make some > final comments. These are pretty much all editorial, and I'm assuming they > could be addressed (or not) in any AUTH48 period without requiring further > public review. > > > Section 3. > > "For IETF Standards-Track documents, Permanent registration status is REQUIRED." > Reading this now, I find the drafting here is potentially confusing. Suggest: > > "For URI schemes defined or normatively referenced by IETF Standards-Track > documents, Permanent registration status is REQUIRED." I don't think the addition of "or normatively referenced" is correct. This seems to be a rather high bar. This would mean that certain URI types can't be normatively referenced until their status is upgraded to permanent. I don't have objections to the rest of the suggestions. From nobody Wed Mar 18 07:59:41 2015 Return-Path: X-Original-To: expand-draft-ietf-appsawg-uri-scheme-reg.all@virtual.ietf.org Delivered-To: apps-discuss@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id D73B41A19F0; Wed, 18 Mar 2015 07:59:34 -0700 (PDT) X-Original-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABDB41A19FE; Wed, 18 Mar 2015 07:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4FwmPcYXaDZs; Wed, 18 Mar 2015 07:59:30 -0700 (PDT) Received: from statler.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id 3ED0F1A19F0; Wed, 18 Mar 2015 07:59:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1426690769; d=isode.com; s=selector; i=@isode.com; bh=S1Yc2q3mU4OGStCLwZXSQxfh9CJpj/gBIVfyHmjzh08=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=ZSldawc4WVc0iNozQIFdo7eDB8RC9EhBdORMSod973Og/itf1Ga7atnW0YuBRHe3qwQj6v ssfcZfAHdDcIGWN5L4+5dSP8KZzPT1cEYoIv/fO8qII7DXCUMojOQGJ1rcDogmc7ku20W4 baYlFWW3wWky8Nh+8qYt+iVMe1g8j40=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 18 Mar 2015 14:59:28 +0000 Message-ID: <550992C1.8060809@isode.com> Date: Wed, 18 Mar 2015 14:59:13 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 To: drafts-expert-review@iana.org References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: appsawg-chairs@ietf.org, draft-ietf-appsawg-uri-scheme-reg.all@ietf.org, iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] [IANA #812412] Expert Review - draft-ietf-appsawg-uri-scheme-reg-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 14:59:35 -0000 On 16/03/2015 17:58, Pearl Liang via RT wrote: > Dear Authors, > > Upon review, Graham Klyne has approved the requested new URI scheme and raised > some comments and question: > > ... > > I'm also taking this opportunity to review the current version and make some > final comments. These are pretty much all editorial, and I'm assuming they > could be addressed (or not) in any AUTH48 period without requiring further > public review. > > > Section 3. > > "For IETF Standards-Track documents, Permanent registration status is REQUIRED." > Reading this now, I find the drafting here is potentially confusing. Suggest: > > "For URI schemes defined or normatively referenced by IETF Standards-Track > documents, Permanent registration status is REQUIRED." I don't think the addition of "or normatively referenced" is correct. This seems to be a rather high bar. This would mean that certain URI types can't be normatively referenced until their status is upgraded to permanent. I don't have objections to the rest of the suggestions. From nobody Wed Mar 18 08:25:52 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4643E1A1AB4; Wed, 18 Mar 2015 08:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j2kAyhgeYUcs; Wed, 18 Mar 2015 08:25:44 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF0801A1A96; Wed, 18 Mar 2015 08:25:41 -0700 (PDT) Received: by labjg1 with SMTP id jg1so38979376lab.2; Wed, 18 Mar 2015 08:25:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=PkXkgOIDYiG5/jX9qSX+yGKc9cE2wlet+SEixHdCm+o=; b=YMQZvTP36ZVkk5qV8TZY+ukK/af1NgxwnemGgmEqZRrY7lFWJuBeo6aaRj47HdtCbR 3B6CKKWeOoa5It5QfDSbLa1KQ7oSdJG1zhdruTIdIMJjoGj2ni4gFcBwTW/uSRrz/keD Id76/wHBrdF6GmECevWZb9SwSk+f8y0SKe41p7wxPFcDpmussTmnURl2wkNjC9PHYPpC /nrECNQmtWNUuj+kk6pBK5X6Do4pIsrIEj/Z0wWecIam+w2CsSZzY2juCP1TbKd3/7k/ IomW788i+p8F1T1vwYCjQCxtrmjy7rEQ9Vj1ggr86jNM0NvRRMRdqvt4/Kxfk8749cAV DMCg== MIME-Version: 1.0 X-Received: by 10.152.244.161 with SMTP id xh1mr36477942lac.119.1426692340467; Wed, 18 Mar 2015 08:25:40 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.137.10 with HTTP; Wed, 18 Mar 2015 08:25:40 -0700 (PDT) In-Reply-To: <550992C1.8060809@isode.com> References: <550992C1.8060809@isode.com> Date: Wed, 18 Mar 2015 11:25:40 -0400 X-Google-Sender-Auth: CT3J_YFSYE4jdS18wMudkTH64KM Message-ID: From: Barry Leiba To: Alexey Melnikov Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: "appsawg-chairs@ietf.org" , Apps Discuss , "draft-ietf-appsawg-uri-scheme-reg.all@ietf.org" , IESG , drafts-expert-review@iana.org Subject: Re: [apps-discuss] [IANA #812412] Expert Review - draft-ietf-appsawg-uri-scheme-reg-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 15:25:46 -0000 >> "For IETF Standards-Track documents, Permanent registration status is >> REQUIRED." >> >> Reading this now, I find the drafting here is potentially confusing. >> Suggest: >> >> "For URI schemes defined or normatively referenced by IETF Standards-Track >> documents, Permanent registration status is REQUIRED." > > I don't think the addition of "or normatively referenced" is correct. This > seems to be a rather high bar. This would mean that certain URI types can't > be normatively referenced until their status is upgraded to permanent. On the other hand, without some change like that, one can simply pull a URI scheme definition out of a Standards Track document, post it on a web site, get a provisional registration for it, and use it in the Standards Track document... making this requirement fairly pointless. What's the real intent of this requirement? If it's that standards-track protocols have to use "permanent" URI schemes, not "provisional" ones, then Graham's proposal is right, or almost right. It's possible that what we really need is to say what we intend, very clearly and in plain English (without trying to put MUSTs and SHOULDs in exactly the right places), and then depend upon the designated experts and the IESG to do the right thing, given those plain-English instructions. Barry From nobody Wed Mar 18 08:26:04 2015 Return-Path: X-Original-To: expand-draft-ietf-appsawg-uri-scheme-reg.all@virtual.ietf.org Delivered-To: apps-discuss@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 8AD481A1AC1; Wed, 18 Mar 2015 08:25:46 -0700 (PDT) X-Original-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4643E1A1AB4; Wed, 18 Mar 2015 08:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j2kAyhgeYUcs; Wed, 18 Mar 2015 08:25:44 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF0801A1A96; Wed, 18 Mar 2015 08:25:41 -0700 (PDT) Received: by labjg1 with SMTP id jg1so38979376lab.2; Wed, 18 Mar 2015 08:25:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=PkXkgOIDYiG5/jX9qSX+yGKc9cE2wlet+SEixHdCm+o=; b=YMQZvTP36ZVkk5qV8TZY+ukK/af1NgxwnemGgmEqZRrY7lFWJuBeo6aaRj47HdtCbR 3B6CKKWeOoa5It5QfDSbLa1KQ7oSdJG1zhdruTIdIMJjoGj2ni4gFcBwTW/uSRrz/keD Id76/wHBrdF6GmECevWZb9SwSk+f8y0SKe41p7wxPFcDpmussTmnURl2wkNjC9PHYPpC /nrECNQmtWNUuj+kk6pBK5X6Do4pIsrIEj/Z0wWecIam+w2CsSZzY2juCP1TbKd3/7k/ IomW788i+p8F1T1vwYCjQCxtrmjy7rEQ9Vj1ggr86jNM0NvRRMRdqvt4/Kxfk8749cAV DMCg== MIME-Version: 1.0 X-Received: by 10.152.244.161 with SMTP id xh1mr36477942lac.119.1426692340467; Wed, 18 Mar 2015 08:25:40 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.137.10 with HTTP; Wed, 18 Mar 2015 08:25:40 -0700 (PDT) In-Reply-To: <550992C1.8060809@isode.com> References: <550992C1.8060809@isode.com> Date: Wed, 18 Mar 2015 11:25:40 -0400 X-Google-Sender-Auth: CT3J_YFSYE4jdS18wMudkTH64KM Message-ID: From: Barry Leiba To: Alexey Melnikov Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: "appsawg-chairs@ietf.org" , Apps Discuss , "draft-ietf-appsawg-uri-scheme-reg.all@ietf.org" , IESG , drafts-expert-review@iana.org Subject: Re: [apps-discuss] [IANA #812412] Expert Review - draft-ietf-appsawg-uri-scheme-reg-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 15:25:46 -0000 >> "For IETF Standards-Track documents, Permanent registration status is >> REQUIRED." >> >> Reading this now, I find the drafting here is potentially confusing. >> Suggest: >> >> "For URI schemes defined or normatively referenced by IETF Standards-Track >> documents, Permanent registration status is REQUIRED." > > I don't think the addition of "or normatively referenced" is correct. This > seems to be a rather high bar. This would mean that certain URI types can't > be normatively referenced until their status is upgraded to permanent. On the other hand, without some change like that, one can simply pull a URI scheme definition out of a Standards Track document, post it on a web site, get a provisional registration for it, and use it in the Standards Track document... making this requirement fairly pointless. What's the real intent of this requirement? If it's that standards-track protocols have to use "permanent" URI schemes, not "provisional" ones, then Graham's proposal is right, or almost right. It's possible that what we really need is to say what we intend, very clearly and in plain English (without trying to put MUSTs and SHOULDs in exactly the right places), and then depend upon the designated experts and the IESG to do the right thing, given those plain-English instructions. Barry From nobody Wed Mar 18 09:28:49 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB2021A7013; Wed, 18 Mar 2015 09:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qYd5Pe95qVXO; Wed, 18 Mar 2015 09:28:46 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13B7D1A6F7A; Wed, 18 Mar 2015 09:28:46 -0700 (PDT) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YYGpm-000KND-Gu; Wed, 18 Mar 2015 12:28:42 -0400 Date: Wed, 18 Mar 2015 12:28:37 -0400 From: John C Klensin To: Barry Leiba , Alexey Melnikov Message-ID: <3D6AF6B00B1967F8E3988CB6@JcK-HP8200.jck.com> In-Reply-To: References: <550992C1.8060809@isode.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: appsawg-chairs@ietf.org, draft-ietf-appsawg-uri-scheme-reg.all@ietf.org, IESG , Apps Discuss , drafts-expert-review@iana.org Subject: Re: [apps-discuss] [IANA #812412] Expert Review - draft-ietf-appsawg-uri-scheme-reg-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 16:28:48 -0000 --On Wednesday, March 18, 2015 11:25 -0400 Barry Leiba wrote: >... > On the other hand, without some change like that, one can > simply pull a URI scheme definition out of a Standards Track > document, post it on a web site, get a provisional > registration for it, and use it in the Standards Track > document... making this requirement fairly pointless. And, coming back to my basic concern about the interaction between registrations with Expert Review and IETF Standards: If the Standards Track is going to be meaningful, there must be meaningful IETF consensus and change control over the specification. If, whether through malice or accident (I'm pleased that the latter appears to be far more prevalent), we create a race condition in which a small-group review by particularly interested parties eliminates a meaningful opportunity for IETF community review (and potential changes) of something that is a substantial and normative element of a standards track spec, the standards process and its credibility are undermined. Now, in theory, the right thing could be accomplished by having a "Provisional" registration that has the explicit property that the IETF can change up through and including Last Call and then move it to "Permanent". I don't think that would work in practice but I continue to be skeptical about Provisional registrations generally once the scheme is put into anything resembling general use. >... > It's possible that what we really need is to say what we > intend, very clearly and in plain English (without trying to > put MUSTs and SHOULDs in exactly the right places), and then > depend upon the designated experts and the IESG to do the > right thing, given those plain-English instructions. I'm not sure that is sufficient. Examples with, e.g., DNS RRTYPEs in which registrations have occurred after Expert Review and then people have come forward to standardize the RRTYPE and said, approximately, "the IETF cannot alter the definition of that RRTYPE because it is already legitimately registered and in use" suggest that it is not. john From nobody Wed Mar 18 09:29:05 2015 Return-Path: X-Original-To: expand-draft-ietf-appsawg-uri-scheme-reg.all@virtual.ietf.org Delivered-To: apps-discuss@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 17FA81A6F7A; Wed, 18 Mar 2015 09:28:48 -0700 (PDT) X-Original-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB2021A7013; Wed, 18 Mar 2015 09:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qYd5Pe95qVXO; Wed, 18 Mar 2015 09:28:46 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13B7D1A6F7A; Wed, 18 Mar 2015 09:28:46 -0700 (PDT) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YYGpm-000KND-Gu; Wed, 18 Mar 2015 12:28:42 -0400 Date: Wed, 18 Mar 2015 12:28:37 -0400 From: John C Klensin To: Barry Leiba , Alexey Melnikov Message-ID: <3D6AF6B00B1967F8E3988CB6@JcK-HP8200.jck.com> In-Reply-To: References: <550992C1.8060809@isode.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: appsawg-chairs@ietf.org, draft-ietf-appsawg-uri-scheme-reg.all@ietf.org, IESG , Apps Discuss , drafts-expert-review@iana.org Subject: Re: [apps-discuss] [IANA #812412] Expert Review - draft-ietf-appsawg-uri-scheme-reg-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 16:28:48 -0000 --On Wednesday, March 18, 2015 11:25 -0400 Barry Leiba wrote: >... > On the other hand, without some change like that, one can > simply pull a URI scheme definition out of a Standards Track > document, post it on a web site, get a provisional > registration for it, and use it in the Standards Track > document... making this requirement fairly pointless. And, coming back to my basic concern about the interaction between registrations with Expert Review and IETF Standards: If the Standards Track is going to be meaningful, there must be meaningful IETF consensus and change control over the specification. If, whether through malice or accident (I'm pleased that the latter appears to be far more prevalent), we create a race condition in which a small-group review by particularly interested parties eliminates a meaningful opportunity for IETF community review (and potential changes) of something that is a substantial and normative element of a standards track spec, the standards process and its credibility are undermined. Now, in theory, the right thing could be accomplished by having a "Provisional" registration that has the explicit property that the IETF can change up through and including Last Call and then move it to "Permanent". I don't think that would work in practice but I continue to be skeptical about Provisional registrations generally once the scheme is put into anything resembling general use. >... > It's possible that what we really need is to say what we > intend, very clearly and in plain English (without trying to > put MUSTs and SHOULDs in exactly the right places), and then > depend upon the designated experts and the IESG to do the > right thing, given those plain-English instructions. I'm not sure that is sufficient. Examples with, e.g., DNS RRTYPEs in which registrations have occurred after Expert Review and then people have come forward to standardize the RRTYPE and said, approximately, "the IETF cannot alter the definition of that RRTYPE because it is already legitimately registered and in use" suggest that it is not. john From nobody Thu Mar 19 10:05:31 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BCF81A1EFF; Thu, 19 Mar 2015 10:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJR025CFqf3M; Thu, 19 Mar 2015 10:05:25 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0627.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:627]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 943501A1AFC; Thu, 19 Mar 2015 10:05:25 -0700 (PDT) Received: from DM2PR02MB1322.namprd02.prod.outlook.com (25.161.142.21) by DM2PR02MB1323.namprd02.prod.outlook.com (25.161.142.22) with Microsoft SMTP Server (TLS) id 15.1.118.21; Thu, 19 Mar 2015 17:05:04 +0000 Received: from DM2PR02MB1322.namprd02.prod.outlook.com ([25.161.142.21]) by DM2PR02MB1322.namprd02.prod.outlook.com ([25.161.142.21]) with mapi id 15.01.0112.000; Thu, 19 Mar 2015 17:05:04 +0000 From: Larry Masinter To: John C Klensin , Barry Leiba , Alexey Melnikov Thread-Topic: [apps-discuss] [IANA #812412] Expert Review - draft-ietf-appsawg-uri-scheme-reg-04 Thread-Index: AQHQYBLfKW1Gz67/2k23IEjtS8bytp0iWAuAgAAHZACAABGWgIABJykA Date: Thu, 19 Mar 2015 17:05:04 +0000 Message-ID: <07581D83-86E4-4573-A247-0647D82A15C4@adobe.com> References: <550992C1.8060809@isode.com> <3D6AF6B00B1967F8E3988CB6@JcK-HP8200.jck.com> In-Reply-To: <3D6AF6B00B1967F8E3988CB6@JcK-HP8200.jck.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/15.8.0.150303 x-originating-ip: [50.184.24.49] authentication-results: jck.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR02MB1323; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10009020)(6009001)(83506001)(82746002)(87936001)(102836002)(2656002)(83716003)(19580395003)(99286002)(92566002)(106116001)(15975445007)(77156002)(62966003)(86362001)(122556002)(46102003)(40100003)(93886004)(33656002)(76176999)(54356999)(50986999)(230783001)(2950100001)(2900100001)(66066001)(36756003)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR02MB1323; H:DM2PR02MB1322.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:DM2PR02MB1323; BCL:0; PCL:0; RULEID:; SRVR:DM2PR02MB1323; x-forefront-prvs: 052017CAF1 Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: adobe.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Mar 2015 17:05:04.3883 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR02MB1323 Archived-At: Cc: "appsawg-chairs@ietf.org" , "draft-ietf-appsawg-uri-scheme-reg.all@ietf.org" , IESG , Apps Discuss , "drafts-expert-review@iana.org" Subject: Re: [apps-discuss] [IANA #812412] Expert Review - draft-ietf-appsawg-uri-scheme-reg-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 17:05:27 -0000 PiAiRm9yIElFVEYgU3RhbmRhcmRzLVRyYWNrIGRvY3VtZW50cywgUGVybWFuZW50IHJlZ2lzdHJh dGlvbiBzdGF0dXMgaXMgUkVRVUlSRUQuIg0KPiBSZWFkaW5nIHRoaXMgbm93LCBJIGZpbmQgdGhl IGRyYWZ0aW5nIGhlcmUgaXMgcG90ZW50aWFsbHkgY29uZnVzaW5nLiBTdWdnZXN0Og0KDQo+ICJG b3IgVVJJIHNjaGVtZXMgZGVmaW5lZCBvciBub3JtYXRpdmVseSByZWZlcmVuY2VkIGJ5IElFVEYg U3RhbmRhcmRzLVRyYWNrDQo+IGRvY3VtZW50cywgUGVybWFuZW50IHJlZ2lzdHJhdGlvbiBzdGF0 dXMgaXMgUkVRVUlSRUQuIg0KDQoNCg0KDQpJIGRvbuKAmXQgdGhpbmsgd2Ugd2FudCB0byBlc3Rh Ymxpc2ggYW55IG5ldyBydWxlcyBmb3Igbm9ybWF0aXZlIHJlZmVyZW5jZXMuDQpRaGVuIGV2YWx1 YXRpbmcgdGhlIHN0YWJpbGl0eSBvZiBub3JtYXRpdmUgcmVmZXJlbmNlcyB0byBVUkkgc2NoZW1l cywgdGhlIA0KDQoNCnN0YWJpbGl0eSBvZiB0aGUgZG9jdW1lbnQgZXN0YWJsaXNoaW5nIHRoZSBz Y2hlbWUsIGFuZCB0aGUgc2NoZW1l4oCZcyBjaGFuZ2UNCmNvbnRyb2xsZXIsIHNob3VsZCBiZSB0 YWtlbiBpbnRvIGNvbnNpZGVyYXRpb24uDQoNCg0KTGFycnkNCuKAlA0KaHR0cDovL2xhcnJ5Lm1h c2ludGVyLm5ldA0KDQo= From nobody Thu Mar 19 10:05:33 2015 Return-Path: X-Original-To: expand-draft-ietf-appsawg-uri-scheme-reg.all@virtual.ietf.org Delivered-To: apps-discuss@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id A541D1A3B9C; Thu, 19 Mar 2015 10:05:27 -0700 (PDT) X-Original-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BCF81A1EFF; Thu, 19 Mar 2015 10:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJR025CFqf3M; Thu, 19 Mar 2015 10:05:25 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0627.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:627]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 943501A1AFC; Thu, 19 Mar 2015 10:05:25 -0700 (PDT) Received: from DM2PR02MB1322.namprd02.prod.outlook.com (25.161.142.21) by DM2PR02MB1323.namprd02.prod.outlook.com (25.161.142.22) with Microsoft SMTP Server (TLS) id 15.1.118.21; Thu, 19 Mar 2015 17:05:04 +0000 Received: from DM2PR02MB1322.namprd02.prod.outlook.com ([25.161.142.21]) by DM2PR02MB1322.namprd02.prod.outlook.com ([25.161.142.21]) with mapi id 15.01.0112.000; Thu, 19 Mar 2015 17:05:04 +0000 From: Larry Masinter To: John C Klensin , Barry Leiba , Alexey Melnikov Thread-Topic: [apps-discuss] [IANA #812412] Expert Review - draft-ietf-appsawg-uri-scheme-reg-04 Thread-Index: AQHQYBLfKW1Gz67/2k23IEjtS8bytp0iWAuAgAAHZACAABGWgIABJykA Date: Thu, 19 Mar 2015 17:05:04 +0000 Message-ID: <07581D83-86E4-4573-A247-0647D82A15C4@adobe.com> References: <550992C1.8060809@isode.com> <3D6AF6B00B1967F8E3988CB6@JcK-HP8200.jck.com> In-Reply-To: <3D6AF6B00B1967F8E3988CB6@JcK-HP8200.jck.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/15.8.0.150303 x-originating-ip: [50.184.24.49] authentication-results: jck.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR02MB1323; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10009020)(6009001)(83506001)(82746002)(87936001)(102836002)(2656002)(83716003)(19580395003)(99286002)(92566002)(106116001)(15975445007)(77156002)(62966003)(86362001)(122556002)(46102003)(40100003)(93886004)(33656002)(76176999)(54356999)(50986999)(230783001)(2950100001)(2900100001)(66066001)(36756003)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR02MB1323; H:DM2PR02MB1322.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:DM2PR02MB1323; BCL:0; PCL:0; RULEID:; SRVR:DM2PR02MB1323; x-forefront-prvs: 052017CAF1 Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: adobe.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Mar 2015 17:05:04.3883 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR02MB1323 Archived-At: Cc: "appsawg-chairs@ietf.org" , "draft-ietf-appsawg-uri-scheme-reg.all@ietf.org" , IESG , Apps Discuss , "drafts-expert-review@iana.org" Subject: Re: [apps-discuss] [IANA #812412] Expert Review - draft-ietf-appsawg-uri-scheme-reg-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 17:05:27 -0000 PiAiRm9yIElFVEYgU3RhbmRhcmRzLVRyYWNrIGRvY3VtZW50cywgUGVybWFuZW50IHJlZ2lzdHJh dGlvbiBzdGF0dXMgaXMgUkVRVUlSRUQuIg0KPiBSZWFkaW5nIHRoaXMgbm93LCBJIGZpbmQgdGhl IGRyYWZ0aW5nIGhlcmUgaXMgcG90ZW50aWFsbHkgY29uZnVzaW5nLiBTdWdnZXN0Og0KDQo+ICJG b3IgVVJJIHNjaGVtZXMgZGVmaW5lZCBvciBub3JtYXRpdmVseSByZWZlcmVuY2VkIGJ5IElFVEYg U3RhbmRhcmRzLVRyYWNrDQo+IGRvY3VtZW50cywgUGVybWFuZW50IHJlZ2lzdHJhdGlvbiBzdGF0 dXMgaXMgUkVRVUlSRUQuIg0KDQoNCg0KDQpJIGRvbuKAmXQgdGhpbmsgd2Ugd2FudCB0byBlc3Rh Ymxpc2ggYW55IG5ldyBydWxlcyBmb3Igbm9ybWF0aXZlIHJlZmVyZW5jZXMuDQpRaGVuIGV2YWx1 YXRpbmcgdGhlIHN0YWJpbGl0eSBvZiBub3JtYXRpdmUgcmVmZXJlbmNlcyB0byBVUkkgc2NoZW1l cywgdGhlIA0KDQoNCnN0YWJpbGl0eSBvZiB0aGUgZG9jdW1lbnQgZXN0YWJsaXNoaW5nIHRoZSBz Y2hlbWUsIGFuZCB0aGUgc2NoZW1l4oCZcyBjaGFuZ2UNCmNvbnRyb2xsZXIsIHNob3VsZCBiZSB0 YWtlbiBpbnRvIGNvbnNpZGVyYXRpb24uDQoNCg0KTGFycnkNCuKAlA0KaHR0cDovL2xhcnJ5Lm1h c2ludGVyLm5ldA0KDQo= From nobody Thu Mar 19 10:14:31 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A04C1A6EE6; Thu, 19 Mar 2015 10:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.155 X-Spam-Level: X-Spam-Status: No, score=-0.155 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tKCUb_Op71j4; Thu, 19 Mar 2015 10:14:28 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5822F1A6EE0; Thu, 19 Mar 2015 10:14:28 -0700 (PDT) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YYe1W-000PFH-AO; Thu, 19 Mar 2015 13:14:22 -0400 Date: Thu, 19 Mar 2015 13:14:17 -0400 From: John C Klensin To: Larry Masinter , Barry Leiba , Alexey Melnikov Message-ID: <7BB9B867544D5984A5CDA0A0@JcK-HP8200.jck.com> In-Reply-To: <07581D83-86E4-4573-A247-0647D82A15C4@adobe.com> References: <550992C1.8060809@isode.com> <3D6AF6B00B1967F8E3988CB6@JcK-HP8200.jck.com> <07581D83-86E4-4573-A247-0647D82A15C4@adobe.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: appsawg-chairs@ietf.org, draft-ietf-appsawg-uri-scheme-reg.all@ietf.org, IESG , Apps Discuss , drafts-expert-review@iana.org Subject: Re: [apps-discuss] [IANA #812412] Expert Review - draft-ietf-appsawg-uri-scheme-reg-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 17:14:29 -0000 --On Thursday, March 19, 2015 17:05 +0000 Larry Masinter wrote: >... > I don't think we want to establish any new rules for > normative references. Qhen evaluating the stability of > normative references to URI schemes, the > stability of the document establishing the scheme, and the > scheme's change controller, should be taken into > consideration. Larry, the RFC Editor already has rules requiring stability for normative references. If, as I believe to be the case, non-Permanent URI registrations are inherently not stable (although some may be less stable than others), then the suggested text is just a case-specific restatement of existing rules. In addition, stating it this way removes the issue from a requirement that the RFC Editor evaluate the stability of the registrations and therefore the reference. That seems desirable to me. If you disagree and think that decision should really be in the hands of the RFC Editor (and, hence, bluntly, assorted secret dealings between RFC Editor staff and authors, ADs, etc.) rather than this spec, an Expert Reviewer, or some open process, please explain why. best, john From nobody Thu Mar 19 10:14:35 2015 Return-Path: X-Original-To: expand-draft-ietf-appsawg-uri-scheme-reg.all@virtual.ietf.org Delivered-To: apps-discuss@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 427101A6EFB; Thu, 19 Mar 2015 10:14:29 -0700 (PDT) X-Original-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A04C1A6EE6; Thu, 19 Mar 2015 10:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.155 X-Spam-Level: X-Spam-Status: No, score=-0.155 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tKCUb_Op71j4; Thu, 19 Mar 2015 10:14:28 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5822F1A6EE0; Thu, 19 Mar 2015 10:14:28 -0700 (PDT) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YYe1W-000PFH-AO; Thu, 19 Mar 2015 13:14:22 -0400 Date: Thu, 19 Mar 2015 13:14:17 -0400 From: John C Klensin To: Larry Masinter , Barry Leiba , Alexey Melnikov Message-ID: <7BB9B867544D5984A5CDA0A0@JcK-HP8200.jck.com> In-Reply-To: <07581D83-86E4-4573-A247-0647D82A15C4@adobe.com> References: <550992C1.8060809@isode.com> <3D6AF6B00B1967F8E3988CB6@JcK-HP8200.jck.com> <07581D83-86E4-4573-A247-0647D82A15C4@adobe.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: appsawg-chairs@ietf.org, draft-ietf-appsawg-uri-scheme-reg.all@ietf.org, IESG , Apps Discuss , drafts-expert-review@iana.org Subject: Re: [apps-discuss] [IANA #812412] Expert Review - draft-ietf-appsawg-uri-scheme-reg-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 17:14:29 -0000 --On Thursday, March 19, 2015 17:05 +0000 Larry Masinter wrote: >... > I don't think we want to establish any new rules for > normative references. Qhen evaluating the stability of > normative references to URI schemes, the > stability of the document establishing the scheme, and the > scheme's change controller, should be taken into > consideration. Larry, the RFC Editor already has rules requiring stability for normative references. If, as I believe to be the case, non-Permanent URI registrations are inherently not stable (although some may be less stable than others), then the suggested text is just a case-specific restatement of existing rules. In addition, stating it this way removes the issue from a requirement that the RFC Editor evaluate the stability of the registrations and therefore the reference. That seems desirable to me. If you disagree and think that decision should really be in the hands of the RFC Editor (and, hence, bluntly, assorted secret dealings between RFC Editor staff and authors, ADs, etc.) rather than this spec, an Expert Reviewer, or some open process, please explain why. best, john From nobody Thu Mar 19 11:28:19 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29CF91A8772; Thu, 19 Mar 2015 11:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vTe8XiFXQyZH; Thu, 19 Mar 2015 11:28:13 -0700 (PDT) Received: from relay14.mail.ox.ac.uk (relay14.mail.ox.ac.uk [163.1.2.162]) by ietfa.amsl.com (Postfix) with ESMTP id 3ABB21A8798; Thu, 19 Mar 2015 11:28:13 -0700 (PDT) Received: from smtp6.mail.ox.ac.uk ([163.1.2.206]) by relay14.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1YYfAw-0003eA-l0; Thu, 19 Mar 2015 18:28:10 +0000 Received: from oerc-dynamic-220.oerc.ox.ac.uk ([129.67.194.220]) by smtp6.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YYfAw-00060w-L2; Thu, 19 Mar 2015 18:28:10 +0000 Message-ID: <550B153A.8010100@ninebynine.org> Date: Thu, 19 Mar 2015 18:28:10 +0000 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Barry Leiba , Alexey Melnikov References: <550992C1.8060809@isode.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: Cc: "appsawg-chairs@ietf.org" , "draft-ietf-appsawg-uri-scheme-reg.all@ietf.org" , IESG , Apps Discuss , drafts-expert-review@iana.org Subject: Re: [apps-discuss] [IANA #812412] Expert Review - draft-ietf-appsawg-uri-scheme-reg-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 18:28:15 -0000 On 18/03/2015 15:25, Barry Leiba wrote: >>> "For IETF Standards-Track documents, Permanent registration status is >>> REQUIRED." >>> >>> Reading this now, I find the drafting here is potentially confusing. >>> Suggest: >>> >>> "For URI schemes defined or normatively referenced by IETF Standards-Track >>> documents, Permanent registration status is REQUIRED." >> >> I don't think the addition of "or normatively referenced" is correct. This >> seems to be a rather high bar. This would mean that certain URI types can't >> be normatively referenced until their status is upgraded to permanent. > > On the other hand, without some change like that, one can simply pull > a URI scheme definition out of a Standards Track document, post it on > a web site, get a provisional registration for it, and use it in the > Standards Track document... making this requirement fairly pointless. > > What's the real intent of this requirement? If it's that > standards-track protocols have to use "permanent" URI schemes, not > "provisional" ones, then Graham's proposal is right, or almost right. My intent in making that suggestion was that schemes referenced by standards should have been subjected (as John also says) to a corresponding level of review. It's arguable that my suggestion is unnecessary, as a document that has been reviewed for standards-track publication SHOULD (?) have had its normative references checked. But consider this scenario: A W3C REC (their name for full standard) spec defines and provisionally registers a URI scheme (shouldn't happen, but we can't prohibit that). An IETF standards-track spec normatively references that spec - I think that's perfectly allowable. Now we have a standard track RFC referencing a URI that has never been checked by DE review (under the proposed new regime). My proposal was intended to ensure, in somewhat "belt and braces" style, that the referenced URI scheme would at least get subjected to DE review. In short, I think the bar SHOULD be (relatively) high for something referenced by a standards track document. #g -- > > It's possible that what we really need is to say what we intend, very > clearly and in plain English (without trying to put MUSTs and SHOULDs > in exactly the right places), and then depend upon the designated > experts and the IESG to do the right thing, given those plain-English > instructions. > > Barry > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From nobody Thu Mar 19 11:28:20 2015 Return-Path: X-Original-To: expand-draft-ietf-appsawg-uri-scheme-reg.all@virtual.ietf.org Delivered-To: apps-discuss@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 540BB1A8798; Thu, 19 Mar 2015 11:28:15 -0700 (PDT) X-Original-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29CF91A8772; Thu, 19 Mar 2015 11:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vTe8XiFXQyZH; Thu, 19 Mar 2015 11:28:13 -0700 (PDT) Received: from relay14.mail.ox.ac.uk (relay14.mail.ox.ac.uk [163.1.2.162]) by ietfa.amsl.com (Postfix) with ESMTP id 3ABB21A8798; Thu, 19 Mar 2015 11:28:13 -0700 (PDT) Received: from smtp6.mail.ox.ac.uk ([163.1.2.206]) by relay14.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1YYfAw-0003eA-l0; Thu, 19 Mar 2015 18:28:10 +0000 Received: from oerc-dynamic-220.oerc.ox.ac.uk ([129.67.194.220]) by smtp6.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YYfAw-00060w-L2; Thu, 19 Mar 2015 18:28:10 +0000 Message-ID: <550B153A.8010100@ninebynine.org> Date: Thu, 19 Mar 2015 18:28:10 +0000 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Barry Leiba , Alexey Melnikov References: <550992C1.8060809@isode.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: Cc: "appsawg-chairs@ietf.org" , "draft-ietf-appsawg-uri-scheme-reg.all@ietf.org" , IESG , Apps Discuss , drafts-expert-review@iana.org Subject: Re: [apps-discuss] [IANA #812412] Expert Review - draft-ietf-appsawg-uri-scheme-reg-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 18:28:15 -0000 On 18/03/2015 15:25, Barry Leiba wrote: >>> "For IETF Standards-Track documents, Permanent registration status is >>> REQUIRED." >>> >>> Reading this now, I find the drafting here is potentially confusing. >>> Suggest: >>> >>> "For URI schemes defined or normatively referenced by IETF Standards-Track >>> documents, Permanent registration status is REQUIRED." >> >> I don't think the addition of "or normatively referenced" is correct. This >> seems to be a rather high bar. This would mean that certain URI types can't >> be normatively referenced until their status is upgraded to permanent. > > On the other hand, without some change like that, one can simply pull > a URI scheme definition out of a Standards Track document, post it on > a web site, get a provisional registration for it, and use it in the > Standards Track document... making this requirement fairly pointless. > > What's the real intent of this requirement? If it's that > standards-track protocols have to use "permanent" URI schemes, not > "provisional" ones, then Graham's proposal is right, or almost right. My intent in making that suggestion was that schemes referenced by standards should have been subjected (as John also says) to a corresponding level of review. It's arguable that my suggestion is unnecessary, as a document that has been reviewed for standards-track publication SHOULD (?) have had its normative references checked. But consider this scenario: A W3C REC (their name for full standard) spec defines and provisionally registers a URI scheme (shouldn't happen, but we can't prohibit that). An IETF standards-track spec normatively references that spec - I think that's perfectly allowable. Now we have a standard track RFC referencing a URI that has never been checked by DE review (under the proposed new regime). My proposal was intended to ensure, in somewhat "belt and braces" style, that the referenced URI scheme would at least get subjected to DE review. In short, I think the bar SHOULD be (relatively) high for something referenced by a standards track document. #g -- > > It's possible that what we really need is to say what we intend, very > clearly and in plain English (without trying to put MUSTs and SHOULDs > in exactly the right places), and then depend upon the designated > experts and the IESG to do the right thing, given those plain-English > instructions. > > Barry > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From nobody Thu Mar 19 11:31:09 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4BA71A8831; Thu, 19 Mar 2015 11:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3QLEPzlIgD0q; Thu, 19 Mar 2015 11:30:57 -0700 (PDT) Received: from relay13.mail.ox.ac.uk (relay13.mail.ox.ac.uk [129.67.1.166]) by ietfa.amsl.com (Postfix) with ESMTP id BFC3B1A883B; Thu, 19 Mar 2015 11:30:53 -0700 (PDT) Received: from smtp6.mail.ox.ac.uk ([163.1.2.206]) by relay13.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1YYfDW-0001bQ-j4; Thu, 19 Mar 2015 18:30:51 +0000 Received: from oerc-dynamic-220.oerc.ox.ac.uk ([129.67.194.220]) by smtp6.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YYfDW-0006Gb-M5; Thu, 19 Mar 2015 18:30:50 +0000 Message-ID: <550B15DA.7040307@ninebynine.org> Date: Thu, 19 Mar 2015 18:30:50 +0000 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: John C Klensin , Barry Leiba , Alexey Melnikov References: <550992C1.8060809@isode.com> <3D6AF6B00B1967F8E3988CB6@JcK-HP8200.jck.com> In-Reply-To: <3D6AF6B00B1967F8E3988CB6@JcK-HP8200.jck.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: Cc: appsawg-chairs@ietf.org, draft-ietf-appsawg-uri-scheme-reg.all@ietf.org, IESG , Apps Discuss , drafts-expert-review@iana.org Subject: Re: [apps-discuss] [IANA #812412] Expert Review - draft-ietf-appsawg-uri-scheme-reg-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 18:31:01 -0000 On 18/03/2015 16:28, John C Klensin wrote: > > > --On Wednesday, March 18, 2015 11:25 -0400 Barry Leiba > wrote: > >> ... >> On the other hand, without some change like that, one can >> simply pull a URI scheme definition out of a Standards Track >> document, post it on a web site, get a provisional >> registration for it, and use it in the Standards Track >> document... making this requirement fairly pointless. > > And, coming back to my basic concern about the interaction > between registrations with Expert Review and IETF Standards: If > the Standards Track is going to be meaningful, there must be > meaningful IETF consensus and change control over the > specification. If, whether through malice or accident (I'm > pleased that the latter appears to be far more prevalent), we > create a race condition in which a small-group review by > particularly interested parties eliminates a meaningful > opportunity for IETF community review (and potential changes) of > something that is a substantial and normative element of a > standards track spec, the standards process and its credibility > are undermined. One thing I try to do when a URI scheme is submitted for permanent registration is check that it has been subjected to appropriate community review, comparable with standards track review. If the registration is requested in a document approved for standards track, I pretty much assume that the review has been adequate. (If I spot any problems as part of my review, I tend to offer them as last-call type comments, not as part of my decision.) I think this at least partially addresses the concern of using registration as an end runaround of the standards process. (E.g., I have in the past recommended refusal of a permanent registration request contained in an ISE RFC publication for this reason, because I couldn't confirm the level of review.) > > Now, in theory, the right thing could be accomplished by having > a "Provisional" registration that has the explicit property that > the IETF can change up through and including Last Call and then > move it to "Permanent". I'm not sure what this adds that isn't already covered. > ... I don't think that would work in > practice but I continue to be skeptical about Provisional > registrations generally once the scheme is put into anything > resembling general use. Well, the web is a messy place. We can try to mandate perfection, but in the end people do stuff that bends the rules, whatever we say. The point of provisional registration is that it at least allows such cases to be documented and discoverable, and making provisional simpler (as the current draft aims to do) is intended to improve the prevalence of such documentation. If a provisional scheme does come into widespread use, the community can then decide to make the registration permanent (even if it comes with a health warning), in recognition of a (possibly sub-optimal) reality. > >> ... >> It's possible that what we really need is to say what we >> intend, very clearly and in plain English (without trying to >> put MUSTs and SHOULDs in exactly the right places), and then >> depend upon the designated experts and the IESG to do the >> right thing, given those plain-English instructions. > > I'm not sure that is sufficient. [...] I think I agree. As DE, I try to refer any negative decisions to clearly stated requirements in the registration procedure, as this helps to ensure consistency and avoid a sense of capriciousness in the decisions. Cases which are not referable to clear requirements in this way are much trickier to negotiate with authors. #g -- From nobody Thu Mar 19 11:31:10 2015 Return-Path: X-Original-To: expand-draft-ietf-appsawg-uri-scheme-reg.all@virtual.ietf.org Delivered-To: apps-discuss@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id D5F8A1A8837; Thu, 19 Mar 2015 11:31:01 -0700 (PDT) X-Original-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4BA71A8831; Thu, 19 Mar 2015 11:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3QLEPzlIgD0q; Thu, 19 Mar 2015 11:30:57 -0700 (PDT) Received: from relay13.mail.ox.ac.uk (relay13.mail.ox.ac.uk [129.67.1.166]) by ietfa.amsl.com (Postfix) with ESMTP id BFC3B1A883B; Thu, 19 Mar 2015 11:30:53 -0700 (PDT) Received: from smtp6.mail.ox.ac.uk ([163.1.2.206]) by relay13.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1YYfDW-0001bQ-j4; Thu, 19 Mar 2015 18:30:51 +0000 Received: from oerc-dynamic-220.oerc.ox.ac.uk ([129.67.194.220]) by smtp6.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YYfDW-0006Gb-M5; Thu, 19 Mar 2015 18:30:50 +0000 Message-ID: <550B15DA.7040307@ninebynine.org> Date: Thu, 19 Mar 2015 18:30:50 +0000 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: John C Klensin , Barry Leiba , Alexey Melnikov References: <550992C1.8060809@isode.com> <3D6AF6B00B1967F8E3988CB6@JcK-HP8200.jck.com> In-Reply-To: <3D6AF6B00B1967F8E3988CB6@JcK-HP8200.jck.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: Cc: appsawg-chairs@ietf.org, draft-ietf-appsawg-uri-scheme-reg.all@ietf.org, IESG , Apps Discuss , drafts-expert-review@iana.org Subject: Re: [apps-discuss] [IANA #812412] Expert Review - draft-ietf-appsawg-uri-scheme-reg-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 18:31:02 -0000 On 18/03/2015 16:28, John C Klensin wrote: > > > --On Wednesday, March 18, 2015 11:25 -0400 Barry Leiba > wrote: > >> ... >> On the other hand, without some change like that, one can >> simply pull a URI scheme definition out of a Standards Track >> document, post it on a web site, get a provisional >> registration for it, and use it in the Standards Track >> document... making this requirement fairly pointless. > > And, coming back to my basic concern about the interaction > between registrations with Expert Review and IETF Standards: If > the Standards Track is going to be meaningful, there must be > meaningful IETF consensus and change control over the > specification. If, whether through malice or accident (I'm > pleased that the latter appears to be far more prevalent), we > create a race condition in which a small-group review by > particularly interested parties eliminates a meaningful > opportunity for IETF community review (and potential changes) of > something that is a substantial and normative element of a > standards track spec, the standards process and its credibility > are undermined. One thing I try to do when a URI scheme is submitted for permanent registration is check that it has been subjected to appropriate community review, comparable with standards track review. If the registration is requested in a document approved for standards track, I pretty much assume that the review has been adequate. (If I spot any problems as part of my review, I tend to offer them as last-call type comments, not as part of my decision.) I think this at least partially addresses the concern of using registration as an end runaround of the standards process. (E.g., I have in the past recommended refusal of a permanent registration request contained in an ISE RFC publication for this reason, because I couldn't confirm the level of review.) > > Now, in theory, the right thing could be accomplished by having > a "Provisional" registration that has the explicit property that > the IETF can change up through and including Last Call and then > move it to "Permanent". I'm not sure what this adds that isn't already covered. > ... I don't think that would work in > practice but I continue to be skeptical about Provisional > registrations generally once the scheme is put into anything > resembling general use. Well, the web is a messy place. We can try to mandate perfection, but in the end people do stuff that bends the rules, whatever we say. The point of provisional registration is that it at least allows such cases to be documented and discoverable, and making provisional simpler (as the current draft aims to do) is intended to improve the prevalence of such documentation. If a provisional scheme does come into widespread use, the community can then decide to make the registration permanent (even if it comes with a health warning), in recognition of a (possibly sub-optimal) reality. > >> ... >> It's possible that what we really need is to say what we >> intend, very clearly and in plain English (without trying to >> put MUSTs and SHOULDs in exactly the right places), and then >> depend upon the designated experts and the IESG to do the >> right thing, given those plain-English instructions. > > I'm not sure that is sufficient. [...] I think I agree. As DE, I try to refer any negative decisions to clearly stated requirements in the registration procedure, as this helps to ensure consistency and avoid a sense of capriciousness in the decisions. Cases which are not referable to clear requirements in this way are much trickier to negotiate with authors. #g -- From nobody Sun Mar 22 07:28:49 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7E911A914E for ; Sun, 22 Mar 2015 07:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.611 X-Spam-Level: X-Spam-Status: No, score=-0.611 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F5vCbiGR9ML8 for ; Sun, 22 Mar 2015 07:28:46 -0700 (PDT) Received: from waldorf.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id 9A0E21A9142 for ; Sun, 22 Mar 2015 07:28:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1427034525; d=isode.com; s=selector; i=@isode.com; bh=JIONMALzDm2tSWA/gWkmXRuw34Id8yjqXy36Qo+RPFE=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=NVk4r6Q902f9EDdtS9JX/FYQiz9CuZVIW9jxDGjs8dzuU3eIoJv/0Qzd3tzAICVlqrN7zM 5298cAJ2i8dWXoeivMf7VXJ1rX7L86BpCruHvVjzrccKGx7unogH7Lgs5Hy/AZSLk/jcX7 LkswnIgydcplSlx0SDxLOQr4vzf4taQ=; Received: from [10.248.37.28] (rrcs-64-183-197-98.sw.biz.rr.com [64.183.197.98]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Sun, 22 Mar 2015 14:28:44 +0000 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <550ED198.9000303@isode.com> Date: Sun, 22 Mar 2015 14:28:40 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 To: "apps-discuss@ietf.org" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [apps-discuss] Slides for APPSAWG/APPSAREA presentations in Dallas X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 14:28:47 -0000 Hi, If you are presenting, please send your slides to me by the end of today. If I don't see your slides today, I reserve the right to move you to the end of the agenda and even cancel your presentation. Thank you, Alexey (as a co-chair) From nobody Mon Mar 23 06:13:10 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 444171A8A12 for ; Mon, 23 Mar 2015 06:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9sbkb8XQjPG for ; Mon, 23 Mar 2015 06:13:08 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C225C1A89F6 for ; Mon, 23 Mar 2015 06:13:07 -0700 (PDT) Received: from [192.168.1.197] ([217.91.35.233]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MId0S-1YcF5H3QNc-002DDC; Mon, 23 Mar 2015 14:13:00 +0100 Message-ID: <55101158.8030105@gmx.de> Date: Mon, 23 Mar 2015 14:12:56 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Apps Discuss Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:ZGZ410VA9F0hhZk0S5W9iRo9iJQyARh9zZJztw+NTZtU7iinx1e GXxw4FAU7HT2uKSxtbPjcrkiUtI6eWTk/M3dKQhld6t8hHBdgV/05KyTePOgClwjmPG4l8u vBsvWAsktlU+0ALvbVqMcjb3QH4l/Fq2dCeIvo99DuTSmL41/xu29gfYC7SFY2q6+LUJXdQ Ujzmsfn5D2HkJEQ124Dbg== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: draft-ietf-appsawg-text-markdown@tools.ietf.org Subject: [apps-discuss] draft-ietf-appsawg-text-markdown vs Content-Disposition X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 13:13:09 -0000 Hi there, it would be good if the draft stated whether the C-D parameter "preview-type" is supposed to apply to Content-Disposition in HTTP, and to clarify, exactly how. (Note that Content-Disposition in HTTP is defined by RFC 6266, which the draft currently doesn't even reference) Best regards, Julian From nobody Mon Mar 23 08:01:23 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C222A1A89FB; Sun, 22 Mar 2015 08:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vCT2Yvr1UNTV; Sun, 22 Mar 2015 08:28:20 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C87DE1A89F0; Sun, 22 Mar 2015 08:28:16 -0700 (PDT) Received: by pagj4 with SMTP id j4so72960999pag.2; Sun, 22 Mar 2015 08:28: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=hZ0Mxv0ow0ZzR0NQu/iusFD4+c06hkUlwNNz7e+UmP0=; b=wcvYj3o80BIn/30ESOG+z1OXDmD7iqcPdaZfaGCkCye4dA+fHdRQxs/cIvVvKtfPnH /b9cOsVOX8pjdHwUArQv9LvISH7hsvRu8bXZRPhb5aWWS/w5Cydgw6m9cX2jz2y/UwQ0 BQucAX7mgJxKaZql6/zsZVxp3HkdJjY6ZKfNgNnKjxNQJz5Ll+3OIRNjKlB5l7b8B9NX jT4QafC7st2A/ahfrpxfsC5NVO+HtQrwRGGox0M04wADHdjlkfLOg3XXH5f2K+IcsLQC N+dbzrUgyrimpYIySRjzjrI/2P8xBe3YitGWP8NceuvEh9iu4/bJZp14VnGYCFLaHXa3 zO3Q== MIME-Version: 1.0 X-Received: by 10.68.194.137 with SMTP id hw9mr13370557pbc.162.1427038096467; Sun, 22 Mar 2015 08:28:16 -0700 (PDT) Received: by 10.67.3.38 with HTTP; Sun, 22 Mar 2015 08:28:16 -0700 (PDT) In-Reply-To: <550B15DA.7040307@ninebynine.org> References: <550992C1.8060809@isode.com> <3D6AF6B00B1967F8E3988CB6@JcK-HP8200.jck.com> <550B15DA.7040307@ninebynine.org> Date: Sun, 22 Mar 2015 08:28:16 -0700 Message-ID: From: Jonathan Ballard To: Graham Klyne Content-Type: multipart/alternative; boundary=047d7b417763d22d2d0511e23258 Archived-At: X-Mailman-Approved-At: Mon, 23 Mar 2015 08:01:22 -0700 Cc: appsawg-chairs@ietf.org, drafts-expert-review@iana.org, Apps Discuss , draft-ietf-appsawg-uri-scheme-reg.all@ietf.org, IESG , Barry Leiba Subject: Re: [apps-discuss] [IANA #812412] Expert Review - draft-ietf-appsawg-uri-scheme-reg-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 15:28:21 -0000 --047d7b417763d22d2d0511e23258 Content-Type: text/plain; charset=UTF-8 On Thu, Mar 19, 2015 at 11:30 AM, Graham Klyne wrote: > On 18/03/2015 16:28, John C Klensin wrote: > >> >> >> --On Wednesday, March 18, 2015 11:25 -0400 Barry Leiba >> wrote: >> > >> ... >>> It's possible that what we really need is to say what we >>> intend, very clearly and in plain English (without trying to >>> put MUSTs and SHOULDs in exactly the right places), and then >>> depend upon the designated experts and the IESG to do the >>> right thing, given those plain-English instructions. >>> >> >> I'm not sure that is sufficient. [...] >> > > I think I agree. [...] That intention matches those that write plain English sentences that are easily readable, secular, and put into perfect past tense. That technical guild is not taught. It is acquired by trade and experience. It clearly divided standardization processes between unified facts and predicate proposals. Writing against time, in that mode, requires more work than any apparent appreciation level of such guild. Thanks. --047d7b417763d22d2d0511e23258 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Mar 19, 2015 at 11:30 AM, Graham Klyne <gk@ninebynine.org&= gt; wrote:
On 18/= 03/2015 16:28, John C Klensin wrote:


--On Wednesday, March 18, 2015 11:25 -0400 Barry Leiba
<barryleiba= @computer.org> wrote:

...
It's possible that what we really need is to say what we
intend, very clearly and in plain English (without trying to
put MUSTs and SHOULDs in exactly the right places), and then
depend upon the designated experts and the IESG to do the
right thing, given those plain-English instructions.

 I'm not sure that is sufficient.=C2=A0 [...]

I think I agree. =C2=A0[...]

That intention= matches those that write plain English sentences that are easily readable,= secular, and put into perfect past tense. That technical guild is not taug= ht. It is acquired by trade and experience. It clearly divided standardizat= ion processes between unified facts and predicate proposals.

=
Writing against time, in that mode, requires more work than any = apparent appreciation level of such guild.

Thanks.=
--047d7b417763d22d2d0511e23258-- From nobody Mon Mar 23 08:01:25 2015 Return-Path: X-Original-To: expand-draft-ietf-appsawg-uri-scheme-reg.all@virtual.ietf.org Delivered-To: apps-discuss@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id E64CF1A89F0; Sun, 22 Mar 2015 08:28:21 -0700 (PDT) X-Original-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C222A1A89FB; Sun, 22 Mar 2015 08:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vCT2Yvr1UNTV; Sun, 22 Mar 2015 08:28:20 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C87DE1A89F0; Sun, 22 Mar 2015 08:28:16 -0700 (PDT) Received: by pagj4 with SMTP id j4so72960999pag.2; Sun, 22 Mar 2015 08:28: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=hZ0Mxv0ow0ZzR0NQu/iusFD4+c06hkUlwNNz7e+UmP0=; b=wcvYj3o80BIn/30ESOG+z1OXDmD7iqcPdaZfaGCkCye4dA+fHdRQxs/cIvVvKtfPnH /b9cOsVOX8pjdHwUArQv9LvISH7hsvRu8bXZRPhb5aWWS/w5Cydgw6m9cX2jz2y/UwQ0 BQucAX7mgJxKaZql6/zsZVxp3HkdJjY6ZKfNgNnKjxNQJz5Ll+3OIRNjKlB5l7b8B9NX jT4QafC7st2A/ahfrpxfsC5NVO+HtQrwRGGox0M04wADHdjlkfLOg3XXH5f2K+IcsLQC N+dbzrUgyrimpYIySRjzjrI/2P8xBe3YitGWP8NceuvEh9iu4/bJZp14VnGYCFLaHXa3 zO3Q== MIME-Version: 1.0 X-Received: by 10.68.194.137 with SMTP id hw9mr13370557pbc.162.1427038096467; Sun, 22 Mar 2015 08:28:16 -0700 (PDT) Received: by 10.67.3.38 with HTTP; Sun, 22 Mar 2015 08:28:16 -0700 (PDT) In-Reply-To: <550B15DA.7040307@ninebynine.org> References: <550992C1.8060809@isode.com> <3D6AF6B00B1967F8E3988CB6@JcK-HP8200.jck.com> <550B15DA.7040307@ninebynine.org> Date: Sun, 22 Mar 2015 08:28:16 -0700 Message-ID: From: Jonathan Ballard To: Graham Klyne Content-Type: multipart/alternative; boundary=047d7b417763d22d2d0511e23258 Archived-At: X-Mailman-Approved-At: Mon, 23 Mar 2015 08:01:22 -0700 Cc: appsawg-chairs@ietf.org, drafts-expert-review@iana.org, Apps Discuss , draft-ietf-appsawg-uri-scheme-reg.all@ietf.org, IESG , Barry Leiba Subject: Re: [apps-discuss] [IANA #812412] Expert Review - draft-ietf-appsawg-uri-scheme-reg-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 15:28:22 -0000 --047d7b417763d22d2d0511e23258 Content-Type: text/plain; charset=UTF-8 On Thu, Mar 19, 2015 at 11:30 AM, Graham Klyne wrote: > On 18/03/2015 16:28, John C Klensin wrote: > >> >> >> --On Wednesday, March 18, 2015 11:25 -0400 Barry Leiba >> wrote: >> > >> ... >>> It's possible that what we really need is to say what we >>> intend, very clearly and in plain English (without trying to >>> put MUSTs and SHOULDs in exactly the right places), and then >>> depend upon the designated experts and the IESG to do the >>> right thing, given those plain-English instructions. >>> >> >> I'm not sure that is sufficient. [...] >> > > I think I agree. [...] That intention matches those that write plain English sentences that are easily readable, secular, and put into perfect past tense. That technical guild is not taught. It is acquired by trade and experience. It clearly divided standardization processes between unified facts and predicate proposals. Writing against time, in that mode, requires more work than any apparent appreciation level of such guild. Thanks. --047d7b417763d22d2d0511e23258 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Mar 19, 2015 at 11:30 AM, Graham Klyne <gk@ninebynine.org&= gt; wrote:
On 18/= 03/2015 16:28, John C Klensin wrote:


--On Wednesday, March 18, 2015 11:25 -0400 Barry Leiba
<barryleiba= @computer.org> wrote:

...
It's possible that what we really need is to say what we
intend, very clearly and in plain English (without trying to
put MUSTs and SHOULDs in exactly the right places), and then
depend upon the designated experts and the IESG to do the
right thing, given those plain-English instructions.

 I'm not sure that is sufficient.=C2=A0 [...]

I think I agree. =C2=A0[...]

That intention= matches those that write plain English sentences that are easily readable,= secular, and put into perfect past tense. That technical guild is not taug= ht. It is acquired by trade and experience. It clearly divided standardizat= ion processes between unified facts and predicate proposals.

=
Writing against time, in that mode, requires more work than any = apparent appreciation level of such guild.

Thanks.=
--047d7b417763d22d2d0511e23258-- From nobody Mon Mar 23 08:01:35 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CB3C1A8F51; Mon, 23 Mar 2015 08:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhXFiNfCWMIF; Mon, 23 Mar 2015 08:01:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CB90D1A8F50; Mon, 23 Mar 2015 08:00:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150323150056.3303.33358.idtracker@ietfa.amsl.com> Date: Mon, 23 Mar 2015 08:00:56 -0700 Archived-At: Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc7001bis-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 15:01:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : Message Header Field for Indicating Message Authentication Status Author : Murray S. Kucherawy Filename : draft-ietf-appsawg-rfc7001bis-04.txt Pages : 50 Date : 2015-03-23 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 to make sorting and filtering decisions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc7001bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-rfc7001bis-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-rfc7001bis-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 23 08:05:44 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB7571A8F3A for ; Mon, 23 Mar 2015 08:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xnT5ErmHA1wo for ; Mon, 23 Mar 2015 08:05:38 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8DAD1A8F4C for ; Mon, 23 Mar 2015 08:05:37 -0700 (PDT) Received: by wgs2 with SMTP id 2so41402496wgs.1 for ; Mon, 23 Mar 2015 08:05: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 :content-type; bh=EFobSd5PdIETgbRc0aqTwaLKgMMQn15kk4A+o0HPQDs=; b=PpDRcdpPGtCuJZuEmzxR3xQ1gUox+2PF9kPRVLFOT47/nVSDY5DGf0Seky7iYCMfXp LLgLjzcqqDA+WVhyHMd6ehBOCYBQi0DG67t+YEVg4taaHcBQO6fkuZbqmT+xE5DT280b EO6H6Ltk2qCR3E4NhHs8g9xQ3l4Gu5PSS/FWBm90VTTY0SonBqgoK0ijCi4/t9wcwKoU ik1Jx0yVAVHMw2DuszNTCjsrl9NQnWqRuMFh+AZGNxIduc9tDBKOaHLOTQbKoruAd2VE aWWHj07eNH2eb3hk36gGcY4tuypxBRDpY3TJKhouVU5R0pByR4jQXr/M+Stq/byvc2At xBZg== MIME-Version: 1.0 X-Received: by 10.180.80.199 with SMTP id t7mr20574915wix.52.1427123136469; Mon, 23 Mar 2015 08:05:36 -0700 (PDT) Received: by 10.27.179.212 with HTTP; Mon, 23 Mar 2015 08:05:36 -0700 (PDT) In-Reply-To: <20150323150056.3303.33358.idtracker@ietfa.amsl.com> References: <20150323150056.3303.33358.idtracker@ietfa.amsl.com> Date: Mon, 23 Mar 2015 08:05:36 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=f46d044289e8999fad0511f5ffb6 Archived-At: Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc7001bis-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 15:05:42 -0000 --f46d044289e8999fad0511f5ffb6 Content-Type: text/plain; charset=UTF-8 On Mon, Mar 23, 2015 at 8:00 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 : Message Header Field for Indicating Message > Authentication Status > Author : Murray S. Kucherawy > Filename : draft-ietf-appsawg-rfc7001bis-04.txt > Pages : 50 > Date : 2015-03-23 > > 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 to make sorting and filtering decisions. > This tackles all of Tom Petch's outstanding issues, and all others that I know of. Please review. If there's nothing outstanding, I believe it's ready for WGLC. -MSK --f46d044289e8999fad0511f5ffb6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Mar 23, 2015 at 8:00 AM, <internet-drafts= @ietf.org> wrote:

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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Message Header Field for Indicating Message Authentication Status
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Murr= ay S. Kucherawy
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-appsawg-rfc7001bis-04.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 50
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2015-03-23

Abstract:
=C2=A0 =C2=A0This document specifies a message header field called Authenti= cation-
=C2=A0 =C2=A0Results for use with electronic mail messages to indicate the = results
=C2=A0 =C2=A0of message authentication efforts.=C2=A0 Any receiver-side sof= tware, such
=C2=A0 =C2=A0as mail filters or Mail User Agents (MUAs), can use this heade= r field
=C2=A0 =C2=A0to relay that information in a convenient and meaningful way t= o users
=C2=A0 =C2=A0or to make sorting and filtering decisions.

This tackles all of Tom Petch's outstanding issues, a= nd all others that I know of.=C2=A0 Please review.=C2=A0 If there's not= hing outstanding, I believe it's ready for WGLC.

-MSK=
--f46d044289e8999fad0511f5ffb6-- From nobody Mon Mar 23 10:51:21 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB7871ACF58 for ; Mon, 23 Mar 2015 10:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tg4faz7JCJrP for ; Mon, 23 Mar 2015 10:51:10 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CA801ACF57 for ; Mon, 23 Mar 2015 10:51:10 -0700 (PDT) Received: by wgra20 with SMTP id a20so152166304wgr.3 for ; Mon, 23 Mar 2015 10:51:09 -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=PmITs572nsFmqbER5juhIMBY2+rwWvh8W1dE4bxtjHo=; b=PcbQQH/SqTuhEP5tnuOGjPKFtq4K7kP5+Z7ZvJZent9jB1/HTOguQCsrgTFnUb11M+ Pxjjr2HZQ/VFk981/4qtRuLvkhMGGGJkBQvb4WXz0ZU+hEKE0+NeRUiOdJrQFBtk8CWf qz8qPt3eF+VyoGWMtodaqy/TGFac24+p0aFBcz+WW5nHtYNDx8xolP57sY7VGwNOr3GG byWduEfll7d2fRHPpRiM1ipnX1Ik4tWh8GQscJ7w9q7yOp+RIs65SIrOryq2x8OG28UU e3lC+c9tPPwm0/vxvDIrvt7wTj0JFTcaagapeu6VBXQndR3Fu2jjz+ArTtjTGkqi/6VN iskQ== MIME-Version: 1.0 X-Received: by 10.180.99.98 with SMTP id ep2mr18239239wib.61.1427133068950; Mon, 23 Mar 2015 10:51:08 -0700 (PDT) Received: by 10.27.179.212 with HTTP; Mon, 23 Mar 2015 10:51:08 -0700 (PDT) Date: Mon, 23 Mar 2015 10:51:08 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=f46d04428f4e9f455c0511f84f7f Archived-At: Subject: [apps-discuss] markdown drafts X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 17:51:20 -0000 --f46d04428f4e9f455c0511f84f7f Content-Type: text/plain; charset=UTF-8 Colleagues, Given Sean's comments at today's meeting, and not including Julian's post from a few hours ago, it looks like we might be close to being able to wrap these up. To those of you who have commented on these drafts before, it would be helpful if you could take a few minutes to review the latest versions to determine whether your comments have been addressed or if any are outstanding. If we're all clear, we can formally start Working Group Last Call soon and get them on their way. Thanks, -MSK, APPSAWG co-chair --f46d04428f4e9f455c0511f84f7f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Colleagues,

Given Sean's comments at = today's meeting, and not including Julian's post from a few hours a= go, it looks like we might be close to being able to wrap these up.=C2=A0 T= o those of you who have commented on these drafts before, it would be helpf= ul if you could take a few minutes to review the latest versions to determi= ne whether your comments have been addressed or if any are outstanding.=C2= =A0 If we're all clear, we can formally start Working Group Last Call s= oon and get them on their way.

Thanks,
-MSK, APPSAWG = co-chair

--f46d04428f4e9f455c0511f84f7f-- From nobody Mon Mar 23 11:21:05 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6B481AD1BF for ; Mon, 23 Mar 2015 11:21:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4y_l32AOF4Vq for ; Mon, 23 Mar 2015 11:21:02 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE1CC1AD1C3 for ; Mon, 23 Mar 2015 11:21:01 -0700 (PDT) Received: from dhcp-8913.meeting.ietf.org (unknown [31.133.139.19]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id BD9D2509C1; Mon, 23 Mar 2015 14:20:57 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_F3A89AF5-D8A4-419B-B564-81C048F57184"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Leonard In-Reply-To: <55101158.8030105@gmx.de> Date: Mon, 23 Mar 2015 13:19:02 -0500 Message-Id: <0FDC9BB7-6416-4CB8-BBBF-53517CBAEA6B@seantek.com> References: <55101158.8030105@gmx.de> To: Julian Reschke , Apps Discuss X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: draft-ietf-appsawg-text-markdown@tools.ietf.org Subject: Re: [apps-discuss] draft-ietf-appsawg-text-markdown vs Content-Disposition X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 18:21:03 -0000 --Apple-Mail=_F3A89AF5-D8A4-419B-B564-81C048F57184 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Thanks for the comments. On Mar 23, 2015, at 8:12 AM, Julian Reschke = wrote: > Hi there, >=20 > it would be good if the draft stated whether the C-D parameter = "preview-type" is supposed to apply to Content-Disposition in HTTP, and = to clarify, exactly how. >=20 > (Note that Content-Disposition in HTTP is defined by RFC 6266, which = the draft currently doesn't even reference) I checked out RFC 6266. To my knowledge, there are =93no special = considerations=94 with regard to serving the preview-type parameter over = HTTP. I can add some text or leave it blank. What I mean by =93no = special considerations=94, is that whatever a MIME (e-mail) processor = would do with it, an HTTP processor shouldn=92t do anything particularly = different. If the content is provided over any Internet header-oriented protocol, = the Content-Disposition data should be provided to the Markdown = processor/displayer software for it to act on it. I do not anticipate text/markdown content to be served over HTTP; my = expectation is that text/markdown (along with various parameters) is = processed on the server and delivered to a client over HTTP as text/html = or similar. So do folks want a statement about that and a reference to RFC 6266? I = do not mind including it. Best regards, Sean= --Apple-Mail=_F3A89AF5-D8A4-419B-B564-81C048F57184 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ9jCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBT8wggQnoAMCAQICEBpCSs8n+cQbczyWKtueyecwDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTAyMDIwMDAwMDBaFw0xNjAy MDIyMzU5NTlaMCUxIzAhBgkqhkiG9w0BCQEWFGRlditpZXRmQHNlYW50ZWsuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz4n20qAOzUtC1oNz5zgTny0JRBE1mJZszV2s6EurahKP vku7E+utnLhcaNahAWr2oZgeCK9uhEqijaC4qLZHnGt/+lnbsQtjmMJrcFCzhDZjDOJdYzmuS2cU vZqY7YwzCG6jSfs4gwNh+29MS6faY6ucncbnfO9rBB0xu5GIdI3BzsPNYnACNlBYU7w4X4GA0/Mw NAabNhDgxU2Tw1fl5w1Vt+6xRTXBk6V93LyVZN9wBIOpr2MuhoCJLHZrLirv/mbQE5ao4pkJLR/s yYhS1Ko4MSiJmR3ugKPkxEo6DZkuJrfck36hLmtMo3yuzi7hkXmDzPKkdLlNj+Xek1GWtwIDAQAB o4IB8jCCAe4wHwYDVR0jBBgwFoAUkmFrguGioKpP7GfxwqP3tIAAwewwHQYDVR0OBBYEFBpm5d7y 8PBT6NqnIVbfNK8hbpPGMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcG CCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7Bgwr BgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMw XQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBkAYIKwYBBQUHAQEEgYMwgYAw WAYIKwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmNvbW9kb2NhLmNvbTAfBgNVHREEGDAWgRRkZXYraWV0ZkBzZWFudGVrLmNvbTANBgkqhkiG9w0B AQsFAAOCAQEAeIf/Nevvv10ssk0unrJb9FC8lJi41sSpq5AFYtmC8IXwUmNxL7L5uE3tGlNJVoTK ZvGeklYWDRCzq6zqte221TowXYmFO7G27rJZbQRjLzQoY63rMlFPFrjqQCEA6rDgo9DlFO9/81P7 ZC7xvZ52WH7e3p/yJNA4Av8E0eeavhC+l+cwtrw0wCp3gUs5xJT0koGVvli2wR18zecG3ib3ml+G nDDv2AH7OhcyhVoj6V9AeGQa2HqaVpOQVRUNPamqr3xeARKk5sUSeBvxlF+0FWhl+AnhqNdxmeEp qpgSvbcS1jbTsqApvgsBcDzjC09wV8mtBoMCtqlHvF3YY2z55jGCA8MwggO/AgEBMIGwMIGbMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBpCSs8n+cQbczyWKtueyecw CQYFKw4DAhoFAKCCAecwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTUwMzIzMTgyMDU2WjAjBgkqhkiG9w0BCQQxFgQUNUefO2SqIuA9YvXxuTL5SVBpPawwgcEGCSsG AQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMT OENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhAaQkrPJ/nEG3M8lirbnsnnMIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqGSIb3DQEB AQUABIIBAJ2xtOyIXzrjfYRUSNUyghNOOl2VUVlwXmkRhcy/MjHfyBrijwA4fhIlG5fDIVHweTzu hLRwl0sW8F7q6uFn6QNE8EsdJLgFKh1Pxf4IuvU8a8XhTVEoB0oD51tfUvTX1heA02N9ymPd0ku4 EwDjsasxJgv+0DQguQGoBI9uExyRxx8apSFviGV4ncUQU1nW8LwgtHsKNaRqaty9Zt8bbq9HlT47 ddvlYPVlfQaH++un+VprpRMmSDA9W7TItXK6FylYMxr5cXC6fwVRwmr3ZQ/l0jc8W6tncQgrcEzg A28vq5OIl4bvglow/oVtVkL4vKEPA//it/+n+VsPaUmNLJcAAAAAAAA= --Apple-Mail=_F3A89AF5-D8A4-419B-B564-81C048F57184-- From nobody Mon Mar 23 11:29:21 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E4BE1AD0C3 for ; Mon, 23 Mar 2015 11:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PRE2vwuv2b3c for ; Mon, 23 Mar 2015 11:29:11 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED8E61AD1BF for ; Mon, 23 Mar 2015 11:29:03 -0700 (PDT) Received: from dhcp-b0ef.meeting.ietf.org (unknown [31.133.176.239]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id ECD3C22E263 for ; Mon, 23 Mar 2015 14:29:02 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <1B3C015F-AD7A-45B2-83C8-DB8C6FE7B2EC@mnot.net> Date: Mon, 23 Mar 2015 13:29:01 -0500 To: IETF Apps Discuss Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: [apps-discuss] TAG review of http problem draft X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 18:29:13 -0000 See: Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Mon Mar 23 11:30:54 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2EB41AD1DB for ; Mon, 23 Mar 2015 11:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9piPj57rZc-S for ; Mon, 23 Mar 2015 11:30:52 -0700 (PDT) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E17611AD0C5 for ; Mon, 23 Mar 2015 11:30:51 -0700 (PDT) Received: by igcau2 with SMTP id au2so37866698igc.1 for ; Mon, 23 Mar 2015 11:30:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=+hWzUf7mSVMCdy3ssAXBrRMjDkKzxceiNqch22UVcaY=; b=P2XrHAedY1LcgOin7Xed0m7dJtBZrykW1r/sqN0rloKY9WEqZYdgdKn5SDenH5X2CC v2REWEeI2a30xLcL9x/hYIRq7Xkt6274r+dwaWiaWUcOSD8PxT7eg/+9dVDdSOLQwHMY vDKQNXiN5OvExCD2QQCwRV8RlToPQa4z738zcGwbhZuoWlYc1UzUeSV9pbrtV8uvDrk5 gNJHtgBH+/lnTxIZe9vPAiNkt63IemPtmrm5IPPlhgNsYBuO4ZGrMLLlJRCgyWr0nYQN XBzWARhaWFO2BN/TvFTPE2TPG1CyVMvwdk6KrisvByc0+QRLTZZ8IRk/AJZsAw7XcZR8 d7Yw== MIME-Version: 1.0 X-Received: by 10.42.207.206 with SMTP id fz14mr21352905icb.34.1427135451372; Mon, 23 Mar 2015 11:30:51 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.107.17.26 with HTTP; Mon, 23 Mar 2015 11:30:51 -0700 (PDT) Date: Mon, 23 Mar 2015 13:30:51 -0500 X-Google-Sender-Auth: rskA5YsvBCrlg2Aa4noNI39yZd0 Message-ID: From: Barry Leiba To: Apps Discuss Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Subject: [apps-discuss] Applications Directorate news and changes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 18:30:53 -0000 As I announced at the Applications Area meeting this morning in Dallas, we're making some changes to the Applications Directorate. - Many thanks to Claudio Allocchio for having managed the directorate for the last couple of years. Claudio is stepping down from that, with our great appreciation for his work. - Eliot Lear has agreed to take on the job now, and thanks for that! Eliot can be reached at . - Along with that switch, we're making changes in how the directorate works. Eliot will watch for new working group drafts (-00) versions, and will ask for an App-Area "once over" -- a light review -- to determine whether there's a potential in the draft for App issues that should be identified early. We'll try to keep an eye on those drafts, and give earlier input to the working group rather than waiting until the normal directorate last call reviews. This will mean some extra work, but we're hoping that it'll save time in the long run by identifying problems early and getting them dealt with. We'll give it a try for a while and see how it works. This is also a good time to ask anyone who has expertise in some part of the applications area -- email, web, xml, internationalization, ldap, and so on -- and who is willing to help... to contact Eliot, give him a list of your expertise, and offer to be part of the Applications Directorate. You'll be asked to review documents occasionally, and you'll be helping a great deal. Barry, Applications AD From nobody Mon Mar 23 14:00:41 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3AFC1B2A4D; Mon, 23 Mar 2015 14:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lxrdBErO-Txu; Mon, 23 Mar 2015 14:00:37 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A31051A1A98; Mon, 23 Mar 2015 14:00:37 -0700 (PDT) Received: from [31.133.180.160] (dhcp-b4a0.meeting.ietf.org [31.133.180.160]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t2NL0XVo003942 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 23 Mar 2015 14:00:37 -0700 Message-ID: <55107EEB.8070300@dcrocker.net> Date: Mon, 23 Mar 2015 16:00:27 -0500 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Apps Discuss , "saag@ietf.org" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Mon, 23 Mar 2015 14:00:37 -0700 (PDT) Archived-At: Subject: [apps-discuss] BarBOF for PRIME/DMAIL, after Apps and SAAG presentations X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 21:00:39 -0000 There was a presentation at this morning's Apps Area session on PRIME, an privacy-intensive email architecture by Ladar Levison. http://darkmail.info/ The presentation covered basic architecture. At the Thursday afternoon SAAG session, Ladar will discuss more detailed security considerations for the work. We've secured a room for follow-on Bar-BOF-y discussions after the SAAG session: Thursday evening, 7:30pm Room: Royal d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Mar 23 14:24:48 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72C541A1B40; Mon, 23 Mar 2015 14:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3mgt_c5zWIUA; Mon, 23 Mar 2015 14:24:45 -0700 (PDT) Received: from mx10.mailtransaction.com (mx10.mailtransaction.com [88.198.59.241]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE8D1A1AFF; Mon, 23 Mar 2015 14:24:45 -0700 (PDT) Received: from mx14.mailtransaction.com (mx11.mailtransaction.com [88.198.59.230]) by mx10.mailtransaction.com (Postfix) with ESMTP id 3l9pd767H9z5Mgfn; Mon, 23 Mar 2015 22:24:43 +0100 (CET) Received: from jaguar.sonnection.nl (D57E1702.static.ziggozakelijk.nl [213.126.23.2]) by mx14.mailtransaction.com (Postfix) with ESMTP id 3l9pd74jqrz5Mgff; Mon, 23 Mar 2015 22:24:43 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by jaguar.sonnection.nl (Postfix) with ESMTP id 3C36F12341C; Mon, 23 Mar 2015 22:24:43 +0100 (CET) X-Virus-Scanned: amavisd-new at sonnection.nl Received: from jaguar.sonnection.nl ([127.0.0.1]) by localhost (jaguar.sonnection.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id De8V4fGQ8MFE; Mon, 23 Mar 2015 22:24:41 +0100 (CET) Received: from [192.168.1.49] (unknown [192.168.1.49]) by jaguar.sonnection.nl (Postfix) with ESMTPSA id 196601232B9; Mon, 23 Mar 2015 22:24:41 +0100 (CET) Message-ID: <55108498.1050006@sonnection.nl> Date: Mon, 23 Mar 2015 22:24:40 +0100 From: "Rolf E. Sonneveld" Organization: Sonnection B.V. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: dcrocker@bbiw.net, Apps Discuss , "saag@ietf.org" References: <55107EEB.8070300@dcrocker.net> In-Reply-To: <55107EEB.8070300@dcrocker.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1427145883; bh=vpDVEcZ0NG42Sh3YWHbFCCti756yCWu49cerNJdR5pA=; h=Message-ID:Date:From:To:Subject:From; b=L6CYTuihbi8OZoH0m/1Z3lLOFwQbSZGA4tmRBBD5yx2Ym+oWpshIwyVoS9hyAJPM5 qhrhbYQno4X9hLByQQS4RdSzwZO1K211PfsQs60rLxhgvISmCqoW4ORCvhTLLDtlOV Y13i6cZUwd/sa/Y/Zc4DGHF5BKaf9ETYDcMTMP/8= DKIM-Filter: OpenDKIM Filter v2.8.2 mx10.mailtransaction.com 3l9pd767H9z5Mgfn Archived-At: Subject: Re: [apps-discuss] BarBOF for PRIME/DMAIL, after Apps and SAAG presentations X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: R.E.Sonneveld@sonnection.nl List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 21:24:47 -0000 Hi, Dave, On 03/23/2015 10:00 PM, Dave Crocker wrote: > There was a presentation at this morning's Apps Area session on PRIME, > an privacy-intensive email architecture by Ladar Levison. > > http://darkmail.info/ > > The presentation covered basic architecture. > > At the Thursday afternoon SAAG session, Ladar will discuss more detailed > security considerations for the work. > > We've secured a room for follow-on Bar-BOF-y discussions after the SAAG > session: > > Thursday evening, 7:30pm > > Room: Royal thanks for the info. Does Ladar intend to submit DMAIL/DIME via the ISE or is there any chance a DIME WG will be chartered? /rolf P.S. Has anyone a link to the recording of this PRIME session, this morning? I tried to find it at http://ietf92.conf.meetecho.com/index.php/Recorded_Sessions but it is not (yet?) available. From nobody Mon Mar 23 15:28:23 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CD621A1BCA; Mon, 23 Mar 2015 15:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJY6Q9V40PUJ; Mon, 23 Mar 2015 15:28:15 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 698421A1BEF; Mon, 23 Mar 2015 15:28:15 -0700 (PDT) Received: from [31.133.180.160] (dhcp-b4a0.meeting.ietf.org [31.133.180.160]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t2NMSApd005424 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 23 Mar 2015 15:28:14 -0700 Message-ID: <55109374.2010408@dcrocker.net> Date: Mon, 23 Mar 2015 17:28:04 -0500 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: R.E.Sonneveld@sonnection.nl, dcrocker@bbiw.net, Apps Discuss , "saag@ietf.org" References: <55107EEB.8070300@dcrocker.net> <55108498.1050006@sonnection.nl> In-Reply-To: <55108498.1050006@sonnection.nl> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Mon, 23 Mar 2015 15:28:14 -0700 (PDT) Archived-At: Subject: Re: [apps-discuss] BarBOF for PRIME/DMAIL, after Apps and SAAG presentations X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 22:28:17 -0000 On 3/23/2015 4:24 PM, Rolf E. Sonneveld wrote: >Does Ladar intend to submit DMAIL/DIME via the ISE > or is there any chance a DIME WG will be chartered? We discussed this, some time back, but not recently. Given his near-term workload, I would not want to predict how or whether RFC publication of the docs will proceed. IMO, the Independent stream would be a reasonable choice. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Mar 24 03:50:39 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14F021B2E77 for ; Tue, 24 Mar 2015 03:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FLdd07xBukU6 for ; Tue, 24 Mar 2015 03:50:36 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6282B1A2130 for ; Tue, 24 Mar 2015 03:50:36 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 24B9FC4016C for ; Tue, 24 Mar 2015 05:50:35 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1427194235; bh=vdVDUTX6dicziJYNWjtYdwReHmYvnW46Ou2o/tiDR3I=; h=From:To:Subject:Date:In-Reply-To:References:From; b=XWI8fdPHY4c4C7b2y1bdCz99RlgSSUxxkEmBMga/ABEZ9fh/xa8fwn+tyhwwo69oV wZkqyJXo0GpsI1zKabVBQ4Bv3vKtcUHdxZP+yNXtsacTdYwA+ypFeX6QzaQAGpg5nM DLbUjQbURqr0KyABsyFWoFi3e7ovno5CKjgGo2+c= From: Scott Kitterman To: apps-discuss@ietf.org Date: Tue, 24 Mar 2015 06:50:34 -0400 Message-ID: <2397772.kkcDL6IhXZ@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-48-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <20150323150056.3303.33358.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc7001bis-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 10:50:38 -0000 On Monday, March 23, 2015 08:05:36 AM Murray S. Kucherawy wrote: > On Mon, Mar 23, 2015 at 8:00 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 : Message Header Field for Indicating Message > > > > Authentication Status > > > > Author : Murray S. Kucherawy > > Filename : draft-ietf-appsawg-rfc7001bis-04.txt > > Pages : 50 > > Date : 2015-03-23 > > > > 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 to make sorting and filtering decisions. > > This tackles all of Tom Petch's outstanding issues, and all others that I > know of. Please review. If there's nothing outstanding, I believe it's > ready for WGLC. There was one error introduced in this revision. Where it says: For SPF, the ptype used is "smtp", and the property is any of "mailfrom", "helo", and "ehlo", since those values are the ones SPF can evaluate. "ehlo" isn't a valid property. The property is "helo" and it contains the value of "helo" or "ehlo" as needed. Needs to say 'either of "mailfrom" or "helo"' instead. Also, right after that, where it says: Note that both of those documents specify result codes that use mixed case, but they are typically used all lowercase in this context. That's no longer true for SPF since the SPF reference is updated from RFC 4408 to RFC 7208. It's only relevant for Sender ID now. Neither of these should prevent the start of WGLC in my opinion. Scott K From nobody Tue Mar 24 07:35:01 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CAF41A854B for ; Tue, 24 Mar 2015 07:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id apGUjuDP7S5o for ; Tue, 24 Mar 2015 07:34:58 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0754.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::754]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C6651A8767 for ; Tue, 24 Mar 2015 07:34:57 -0700 (PDT) Received: from pc6 (86.185.85.149) by AMXPR07MB053.eurprd07.prod.outlook.com (10.242.67.142) with Microsoft SMTP Server (TLS) id 15.1.118.21; Tue, 24 Mar 2015 14:34:40 +0000 Message-ID: <012801d0663f$8f700380$4001a8c0@gateway.2wire.net> From: t.petch To: "Murray S. Kucherawy" , IETF Apps Discuss References: <20150323150056.3303.33358.idtracker@ietfa.amsl.com> Date: Tue, 24 Mar 2015 14:33:29 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.185.85.149] X-ClientProxiedBy: DB4PR01CA0036.eurprd01.prod.exchangelabs.com (10.242.152.26) To AMXPR07MB053.eurprd07.prod.outlook.com (10.242.67.142) Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB053; X-Forefront-Antispam-Report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(51704005)(377454003)(377424004)(24454002)(13464003)(84392001)(107886001)(19580405001)(77156002)(122386002)(14496001)(230783001)(62966003)(44716002)(19580395003)(33646002)(40100003)(5820100001)(50466002)(15975445007)(46102003)(1456003)(77096005)(92566002)(23676002)(44736004)(50226001)(1556002)(87976001)(61296003)(76176999)(81686999)(81816999)(116806002)(50986999)(86362001)(66066001)(62236002)(47776003)(42186005)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMXPR07MB053; H:pc6; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:AMXPR07MB053; BCL:0; PCL:0; RULEID:; SRVR:AMXPR07MB053; X-Forefront-PRVS: 0525BB0ADF X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Mar 2015 14:34:40.2482 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMXPR07MB053 Archived-At: Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc7001bis-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 14:35:00 -0000 ----- Original Message ----- From: "Murray S. Kucherawy" To: "IETF Apps Discuss" Sent: Monday, March 23, 2015 3:05 PM > On Mon, Mar 23, 2015 at 8:00 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 : Message Header Field for Indicating Message > > Authentication Status > > Author : Murray S. Kucherawy > > Filename : draft-ietf-appsawg-rfc7001bis-04.txt > > Pages : 50 > > Date : 2015-03-23 > > > > 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 to make sorting and filtering decisions. > > > This tackles all of Tom Petch's outstanding issues, and all others that I > know of. Please review. If there's nothing outstanding, I believe it's > ready for WGLC. Indeed. It clears all my outstanding issues. Meanwhile:-(, s 2.3 /inidcate/indicate / 'it ignores the result reported with that "ptype". ' Is that a SHOULD or MUST, even? Tom Petch > -MSK > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From nobody Tue Mar 24 07:39:25 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2900D1A87B2; Tue, 24 Mar 2015 07:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MI6XmaQFegxU; Tue, 24 Mar 2015 07:39:20 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99E341A87A6; Tue, 24 Mar 2015 07:38:31 -0700 (PDT) Received: by iedm5 with SMTP id m5so61861882ied.3; Tue, 24 Mar 2015 07:38:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=d/Kl/0JzbRgmyFyQPuoUsV7j+/HTEsS342ol+ox5HWI=; b=SXMRXyd/QESlEe3aErOUNYF5FGo+3rHosZrlgnxQo+tw8lPfk+xqZqonYW3ihXeeys OTKE+1GyrxJqWw/RtaNJFSJqo95YoIi2F5NOcHGnwdvzyb6Mwt2WWnu1iBVgmqsRDnaP MI6mYcUzm3HLYFGlUv0amyY0JBAlVKzw6h12MYlB+6Cwagohr74MpRimvR1MGKy9WrLF UG7YO80MkJMNjTmr2giEqBq8aS2qgEXBN4JqIYAiF9vZIH4d+DWZsD7I32GvfYrS24Cq m5zuDU2QuU0l+ZB6v8cVpLoW2nvlcv9ld5/Qeredf3ngB5VxRFuwwPeSwBsndr2+4fsp Lz/w== MIME-Version: 1.0 X-Received: by 10.50.176.196 with SMTP id ck4mr22947659igc.40.1427207911065; Tue, 24 Mar 2015 07:38:31 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.107.17.26 with HTTP; Tue, 24 Mar 2015 07:38:31 -0700 (PDT) Date: Tue, 24 Mar 2015 09:38:31 -0500 X-Google-Sender-Auth: F_RRqaChwwZxbqZ5L-eQKb9lZpo Message-ID: From: Barry Leiba To: Apps Discuss , "urn@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Subject: [apps-discuss] URNbis working group session is postponed to a conference call within a few weeks X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 14:39:22 -0000 At the request of the URNbis chair and document editors, I am cancelling the URNbis session at IETF 92, postponing the meeting to a conference call within a few weeks. We'll get that set up and announced with at least two weeks' notice, and everyone will be welcome to join it. The document authors think this is wise because most of the key people will have trouble attending, even remotely, on Thursday, and because they think they can be better ready for a meeting if they have a chance to work out another revision of the documents first. The chairs (and I) agree. Please watch for details and discussion. The conference call details will also be posted to ietf-announce. Barry, Applications AD From nobody Tue Mar 24 10:16:06 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8FC41A9026 for ; Tue, 24 Mar 2015 10:16:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C5bYU0-7tpF1 for ; Tue, 24 Mar 2015 10:16:03 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 605481A92B8 for ; Tue, 24 Mar 2015 10:16:00 -0700 (PDT) Received: by wibg7 with SMTP id g7so56622823wib.1 for ; Tue, 24 Mar 2015 10:15:59 -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=nSVrGd+TDseorE+sGvfQuM1+sWJUXpzy13Yejimae3g=; b=MCbqq/doGxkXRDBwlTUgNmSFO7QDlRI2yVwAEdXkOCG1866G7OZhlmpfAnB13uTBeZ om8k0XAUTN5/J84ucLUM5ugSZO6EskPjJryjX6v/WLcFHKn1PrVFLmdbPvAWIIdpnGvT KqUftG6wy7WGbMOoZQfEdVOyB0G6Gnpja8hJQH0CVJngINo+VT2gcBILpy6oNEarfb7/ EYkIOAGeZd6vDYHMqST9a8kDTIRBtlE7qdqqfONMilW538QFfUrPjTBkqUUtUmBE7xV1 aGiMrnSDjfXgMWygCmhD6pUGdEQUGvcO/I/++IkvmpWjqwD0tH6WqFGIjVYUERiKEjtq 55mQ== MIME-Version: 1.0 X-Received: by 10.180.80.199 with SMTP id t7mr30999175wix.52.1427217359149; Tue, 24 Mar 2015 10:15:59 -0700 (PDT) Received: by 10.27.179.212 with HTTP; Tue, 24 Mar 2015 10:15:59 -0700 (PDT) In-Reply-To: <012801d0663f$8f700380$4001a8c0@gateway.2wire.net> References: <20150323150056.3303.33358.idtracker@ietfa.amsl.com> <012801d0663f$8f700380$4001a8c0@gateway.2wire.net> Date: Tue, 24 Mar 2015 10:15:59 -0700 Message-ID: From: "Murray S. Kucherawy" To: "t.petch" Content-Type: multipart/alternative; boundary=f46d044289e8b59ff105120befe6 Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc7001bis-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 17:16:04 -0000 --f46d044289e8b59ff105120befe6 Content-Type: text/plain; charset=UTF-8 On Tue, Mar 24, 2015 at 7:33 AM, t.petch wrote: > Indeed. It clears all my outstanding issues. > Huzzah! > Meanwhile:-(, > > s 2.3 /inidcate/indicate / > Fixed for -05 (not a WGLC-stopper at any rate). > 'it ignores the result reported with that "ptype". ' > > Is that a SHOULD or MUST, even? > This draft doesn't use RFC2119 words at all, but still manages to be normative. That is, what you've cited is equivalent to a MUST. Pete, back me up here. ;-) -MSK --f46d044289e8b59ff105120befe6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Mar 24, 2015 at 7:33 AM, t.petch <ietfc@btconne= ct.com> wrote:
Indeed. It clears all my outstand= ing issues.

Huzzah!
=C2=A0
=
Meanwhile:-(,

s 2.3 /inidcate/indicate /

Fixed for -0= 5 (not a WGLC-stopper at any rate).
=C2=A0
'it ignores the result reported with that=C2=A0 "ptype". '= ;

Is that a SHOULD or MUST, even?

This dr= aft doesn't use RFC2119 words at all, but still manages to be normative= .=C2=A0 That is, what you've cited is equivalent to a MUST.=C2=A0 Pete,= back me up here.=C2=A0 ;-)

-MSK
--f46d044289e8b59ff105120befe6-- From nobody Tue Mar 24 10:24:02 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60F231AC3EA for ; Tue, 24 Mar 2015 10:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7iWnQc9_JEOg for ; Tue, 24 Mar 2015 10:23:51 -0700 (PDT) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69E491ABD39 for ; Tue, 24 Mar 2015 10:23:36 -0700 (PDT) Received: by weop45 with SMTP id p45so168987441weo.0 for ; Tue, 24 Mar 2015 10:23:35 -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=cgf+N91I4n7AqfnFgx1jWoOnOnnjeNLPEEiLU2vHVIM=; b=JvgfoxKiamQDPFPkOijFM7dhk5rg4h+6IDjDG22Opu9LyTJ253568KH+LfqtgmrCeS m9HwEzcp5KRCOi6Cyp3R8hoEL9eSSpBQaEJ9/2/zXfpKX+lAlH191sifG+7GQSBARRcC 4VTwEKbAOpria3RUEi55wEfK1uZIbEZhOstP2FsHhpUfxbiQ3WIVT5ujxZBbHrEINie0 VuTTYD7rH0S8Uegf1wQGSmltuq6U03MqAw7SWpn1qq4UFKG3QD7Hd9YEZ99fBMeaRkV4 JSjU2X49/iR9HvfE7qS+toJEY7ybsVzZFZ38MkoYhQag07XreGCkbAbB5KEcw7IIXsey saUQ== MIME-Version: 1.0 X-Received: by 10.180.206.98 with SMTP id ln2mr30094982wic.94.1427217815203; Tue, 24 Mar 2015 10:23:35 -0700 (PDT) Received: by 10.27.179.212 with HTTP; Tue, 24 Mar 2015 10:23:35 -0700 (PDT) In-Reply-To: <2397772.kkcDL6IhXZ@kitterma-e6430> References: <20150323150056.3303.33358.idtracker@ietfa.amsl.com> <2397772.kkcDL6IhXZ@kitterma-e6430> Date: Tue, 24 Mar 2015 10:23:35 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=001a11c381cee4762205120c0a45 Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc7001bis-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 17:23:55 -0000 --001a11c381cee4762205120c0a45 Content-Type: text/plain; charset=UTF-8 On Tue, Mar 24, 2015 at 3:50 AM, Scott Kitterman wrote: > > There was one error introduced in this revision. Where it says: > > For SPF, the ptype used is "smtp", and the property is any of > "mailfrom", "helo", and "ehlo", since those values are the ones SPF > can evaluate. > > "ehlo" isn't a valid property. The property is "helo" and it contains the > value of "helo" or "ehlo" as needed. Needs to say 'either of "mailfrom" or > "helo"' instead. > In Section 2.2 we say that the "smtp" ptype can have a property of any valid SMTP command. EHLO is one. Moreover, SPF can evaluate EHLO, naturally. So if we make the change you're talking about, we also need to say that EHLO is mapped to HELO in this context. Would that satisfy this issue? Also, right after that, where it says: > > Note that both of those documents specify result codes that use > mixed > case, but they are typically used all lowercase in this context. > > That's no longer true for SPF since the SPF reference is updated from RFC > 4408 > to RFC 7208. It's only relevant for Sender ID now. > Done for -05. -MSK --001a11c381cee4762205120c0a45 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Mar 24, 2015 at 3:50 AM, Scott Kitterman <scott= @kitterman.com> wrote:

There was one error introduced in this revision.=C2=A0 Where it= says:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 For SPF, the ptype used is "smtp", an= d the property is any of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "mailfrom", "helo", and &qu= ot;ehlo", since those values are the ones SPF
=C2=A0 =C2=A0 =C2=A0 =C2=A0 can evaluate.

"ehlo" isn't a valid property.=C2=A0 The property is "he= lo" and it contains the
value of "helo" or "ehlo" as needed.=C2=A0 Needs to say= 'either of "mailfrom" or
"helo"' instead.

In Secti= on 2.2 we say that the "smtp" ptype can have a property of any va= lid SMTP command.=C2=A0 EHLO is one.=C2=A0 Moreover, SPF can evaluate EHLO,= naturally.=C2=A0 So if we make the change you're talking about, we als= o need to say that EHLO is mapped to HELO in this context.=C2=A0 Would that= satisfy this issue?

Also, right after that, where it says:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Note that both of those documents specify resul= t codes that use mixed
=C2=A0 =C2=A0 =C2=A0 =C2=A0 case, but they are typically used all lowercase= in this context.

That's no longer true for SPF since the SPF reference is updated from R= FC 4408
to RFC 7208.=C2=A0 It's only relevant for Sender ID now.

Done for -05.

-MSK
<= /div>
--001a11c381cee4762205120c0a45-- From nobody Tue Mar 24 10:24:23 2015 Return-Path: X-Original-To: expand-draft-ietf-appsawg-multipart-form-data.all@virtual.ietf.org Delivered-To: apps-discuss@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 2A42C1B2E7C; Tue, 24 Mar 2015 04:44:48 -0700 (PDT) X-Original-To: xfilter-draft-ietf-appsawg-multipart-form-data.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-appsawg-multipart-form-data.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 128771B2CCA for ; Tue, 24 Mar 2015 04:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ZPdXIFK3S07 for ; Tue, 24 Mar 2015 04:44:47 -0700 (PDT) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [IPv6:2a01:3f0:0:31::14]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E61D1A8880 for ; Tue, 24 Mar 2015 04:44:44 -0700 (PDT) Received: from lb1-smtp-cloud6.xs4all.net ([194.109.24.24]:49067) by merlot.tools.ietf.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.84) (envelope-from ) id 1YaNGD-0003Wo-UC for draft-ietf-appsawg-multipart-form-data.all@tools.ietf.org; Tue, 24 Mar 2015 12:44:42 +0100 Received: from Macintosh-6.fritz.box ([83.163.239.181]) by smtp-cloud6.xs4all.net with ESMTP id 7PkC1q00A3vXPcr01PkDeE; Tue, 24 Mar 2015 12:44:14 +0100 Message-ID: <55114E0C.9050007@bwijnen.net> Date: Tue, 24 Mar 2015 12:44:12 +0100 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: draft-ietf-appsawg-multipart-form-data.all@tools.ietf.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 194.109.24.24 X-SA-Exim-Rcpt-To: draft-ietf-appsawg-multipart-form-data.all@tools.ietf.org X-SA-Exim-Mail-From: bwietf@bwijnen.net X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:57:07 +0000) X-SA-Exim-Scanned: Yes (on merlot.tools.ietf.org) Resent-To: draft-ietf-appsawg-multipart-form-data.all@ietf.org Resent-Message-Id: <20150324114447.4E61D1A8880@ietfa.amsl.com> Resent-Date: Tue, 24 Mar 2015 04:44:44 -0700 (PDT) Resent-From: bwietf@bwijnen.net Archived-At: Archived-At: X-Mailman-Approved-At: Tue, 24 Mar 2015 10:24:14 -0700 Cc: "ops-dir@ietf.org" Subject: [apps-discuss] OPSDIR review for draft-ietf-appsawg-multipart-form-data-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 11:44:48 -0000 I did OPSDIR review for I see not operational aspects or network management aspects in this document. I see the use of RFC2119 words like MUST, MAY etc. yet I see no reference to RFC2119 But other than that, I think the document is ready for publication. nits and/or typos: - bottom of page 3, last para: Within a given form, insuring field names are unique is also helpful. Is it ensuring or insuring? I would think ensuring, but English is not my native language - last line on page 4: do not use directory path information that may seesms to be present. s/seesms/seems/ - section 4.7 --AaB03x content-disposition: form-data; name="_charset_" iso8859-1 --AaB03x-- content-disposition: form-data; name="field1" ...text encoded in iso-8859-1 ... AaB03x-- I am not an expert in character sets and such. But.... would it not be more consistent to use the same "iso8859-1" verywhere instead of using "iso-8859-1" in addition to "iso8859-1" ??? Bert From nobody Tue Mar 24 10:24:25 2015 Return-Path: X-Original-To: expand-draft-ietf-appsawg-multipart-form-data.all@virtual.ietf.org Delivered-To: apps-discuss@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 618A91A8799; Tue, 24 Mar 2015 07:28:34 -0700 (PDT) X-Original-To: xfilter-draft-ietf-appsawg-multipart-form-data.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-appsawg-multipart-form-data.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F5971A8793 for ; Tue, 24 Mar 2015 07:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 49lbntmM30Eq for ; Tue, 24 Mar 2015 07:28:32 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 894B61A878A for ; Tue, 24 Mar 2015 07:28:29 -0700 (PDT) Received: from nagasaki.bogus.com ([2001:418:1::81]:24492) by zinfandel.tools.ietf.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YaPoj-0005Ir-0C for draft-ietf-appsawg-multipart-form-data.all@tools.ietf.org; Tue, 24 Mar 2015 07:28:29 -0700 Received: from dhcp-b52a.meeting.ietf.org ([IPv6:2001:67c:370:176:32:b909:b78b:6c9b]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t2OESL26071161 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 24 Mar 2015 14:28:22 GMT (envelope-from joelja@bogus.com) To: "Bert Wijnen (IETF)" , draft-ietf-appsawg-multipart-form-data.all@tools.ietf.org references: <55114E0C.9050007@bwijnen.net> From: joel jaeggli message-id: <55117483.1040007@bogus.com> Date: Tue, 24 Mar 2015 09:28:19 -0500 user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:37.0) Gecko/20100101 Thunderbird/37.0 mime-version: 1.0 in-reply-to: <55114E0C.9050007@bwijnen.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="J1mGI5q2FDE9mOfMP6LLC75D6a84kvEuE" X-SA-Exim-Connect-IP: 2001:418:1::81 X-SA-Exim-Rcpt-To: draft-ietf-appsawg-multipart-form-data.all@tools.ietf.org X-SA-Exim-Mail-From: joelja@bogus.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-appsawg-multipart-form-data.all@ietf.org Resent-Message-Id: <20150324142829.894B61A878A@ietfa.amsl.com> Resent-Date: Tue, 24 Mar 2015 07:28:29 -0700 (PDT) Resent-From: joelja@bogus.com Archived-At: Archived-At: X-Mailman-Approved-At: Tue, 24 Mar 2015 10:24:13 -0700 Cc: "ops-dir@ietf.org" Subject: Re: [apps-discuss] [OPS-DIR] OPSDIR review for draft-ietf-appsawg-multipart-form-data-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 14:28:34 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --J1mGI5q2FDE9mOfMP6LLC75D6a84kvEuE Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks Bert, joel On 3/24/15 6:44 AM, Bert Wijnen (IETF) wrote: > I did OPSDIR review for >=20 > I see not operational aspects or network management aspects > in this document. >=20 >=20 > I see the use of RFC2119 words like MUST, MAY etc. yet I see no > reference to RFC2119 >=20 > But other than that, I think the document is ready for publication. >=20 > nits and/or typos: >=20 > - bottom of page 3, last para: >=20 > Within a given form, insuring field names are unique is also help= ful. >=20 > Is it ensuring or insuring? I would think ensuring, but English is not > my native language >=20 > - last line on page 4: >=20 > do not use directory path information that may seesms to be presen= t. >=20 > s/seesms/seems/ >=20 > - section 4.7 >=20 > --AaB03x > content-disposition: form-data; name=3D"_charset_" >=20 > iso8859-1 > --AaB03x-- > content-disposition: form-data; name=3D"field1" >=20 > ...text encoded in iso-8859-1 ... > AaB03x-- >=20 > I am not an expert in character sets and such. > But.... would it not be more consistent to use the same "iso8859-1" > verywhere instead > of using "iso-8859-1" in addition to "iso8859-1" ??? >=20 > Bert >=20 > _______________________________________________ > OPS-DIR mailing list > OPS-DIR@ietf.org > https://www.ietf.org/mailman/listinfo/ops-dir >=20 --J1mGI5q2FDE9mOfMP6LLC75D6a84kvEuE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlURdIMACgkQ8AA1q7Z/VrKm+gCePZx+m1G9JiS8NSiQD+WVLWs/ w6IAn16PZbOqtp32FkKJvUbpgT3z99Mk =Et5d -----END PGP SIGNATURE----- --J1mGI5q2FDE9mOfMP6LLC75D6a84kvEuE-- From nobody Tue Mar 24 11:16:55 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7A9A1A1B24 for ; Tue, 24 Mar 2015 11:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kgsgk5H2gVl1 for ; Tue, 24 Mar 2015 11:16:51 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DD1E1A028A for ; Tue, 24 Mar 2015 11:16:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3359; q=dns/txt; s=iport; t=1427221011; x=1428430611; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=hZoqF2N8hctPNF8KNGvmDdX0Q8KB/V2JA7NVu9b4wjg=; b=bSqhUZ//w+M/1zdr6UJGc5hb/nRfcOSfzOUiULAUsHqmu2OVnRSKxPrS NmLsrWtZ8odo/AAEOzLWA05Hsb8hNEgNGFv5hpV4pGUMe5RfdKqWXVQHT CGhuPgfQvE4PjqEjqx3I12YWbPN7ckNAvSVzhcMeOYC/z1SnJcCLnIO8v g=; X-Files: signature.asc : 486 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ASBQC3qRFV/4gNJK1cgwZSWoMSwy4MhXMCgT1MAQEBAQEBfYQVAQEEAQEBIEgDGwsYCSECAg8CFjAGAQwGAgEBFogVDa8DmhQBAQEBAQEBAQEBAQEBAQEBAQEBGYshhBQRAVeCaIFFBYsThyaBMlSGAIEbOoUuiWKDRyKEDCAxAYEKgTgBAQE X-IronPort-AV: E=Sophos;i="5.11,459,1422921600"; d="asc'?scan'208";a="406318026" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-6.cisco.com with ESMTP; 24 Mar 2015 18:16:50 +0000 Received: from [10.89.10.10] ([10.89.10.10]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t2OIGn8n006312; Tue, 24 Mar 2015 18:16:50 GMT Message-ID: <5511AA14.30903@cisco.com> Date: Tue, 24 Mar 2015 13:16:52 -0500 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Barry Leiba , Apps Discuss References: In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="arNa18AEWtRQNUexf5ShCT1W6W0UM7jCC" Archived-At: Subject: Re: [apps-discuss] Applications Directorate news and changes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 18:16:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --arNa18AEWtRQNUexf5ShCT1W6W0UM7jCC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thank you Barry. I also want to add my thanks to Claudio for his service= =2E We are seeking additional reviewers. You should be a reviewer to advise the authors, working groups, and the area directors on issues that might impact applications. Information on the Apps Directorate can be found at http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate= You can find existing reviews as examples on the tracker: http://trac.tools.ietf.org/area/app/trac/wiki/tracker As Barry mentioned, we're changing our process a bit. Expect more communication about that in due course. Regards, Eliot On 3/23/15 1:30 PM, Barry Leiba wrote: > As I announced at the Applications Area meeting this morning in > Dallas, we're making some changes to the Applications Directorate. > > - Many thanks to Claudio Allocchio for having managed the directorate > for the last couple of years. Claudio is stepping down from that, > with our great appreciation for his work. > > - Eliot Lear has agreed to take on the job now, and thanks for that! > Eliot can be reached at . > > - Along with that switch, we're making changes in how the directorate > works. Eliot will watch for new working group drafts (-00) versions, > and will ask for an App-Area "once over" -- a light review -- to > determine whether there's a potential in the draft for App issues that > should be identified early. We'll try to keep an eye on those drafts, > and give earlier input to the working group rather than waiting until > the normal directorate last call reviews. > > This will mean some extra work, but we're hoping that it'll save time > in the long run by identifying problems early and getting them dealt > with. We'll give it a try for a while and see how it works. > > This is also a good time to ask anyone who has expertise in some part > of the applications area -- email, web, xml, internationalization, > ldap, and so on -- and who is willing to help... to contact Eliot, > give him a list of your expertise, and offer to be part of the > Applications Directorate. You'll be asked to review documents > occasionally, and you'll be helping a great deal. > > Barry, Applications AD > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --arNa18AEWtRQNUexf5ShCT1W6W0UM7jCC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQEcBAEBAgAGBQJVEaoUAAoJEIe2a0bZ0nozFi0IAKJhCOvJojTVeYDg7q3EQZ08 MQBMsZ6POB7/2A6gwTbHpAtwrU92yXQBEjSSCVQPbvgWBBgDYRTswC5C+tqUgzgZ NEG7Oqd9o5MDkXXAoSlAlBumPsLlJS5BmUquYSrysr1PCxXKb1Np5PP3FZIwZVv1 kVc8bvz4cRMCvY2Q1k/m/VO9DzHYaLcPowCkixzeFf/EO3cxymPXcHXsbYQTnvn0 wljqaVZXsPpQbZ7lxGmo9tHD9e2jkqUvZ9fgaupaMAGOk/rnuc6ysENqH8GtHvY9 V4WuEeFvrad94BMPWMpVAWwfu+Dus0ajC2jHjhK0KgHw1NU7QHxuonVaDoQ9Wg4= =V9kM -----END PGP SIGNATURE----- --arNa18AEWtRQNUexf5ShCT1W6W0UM7jCC-- From nobody Tue Mar 24 13:57:35 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D19311A0364 for ; Tue, 24 Mar 2015 13:57:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3gpt3TQUfaVR for ; Tue, 24 Mar 2015 13:57:32 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B47161A01A5 for ; Tue, 24 Mar 2015 13:57:32 -0700 (PDT) Received: by oiag65 with SMTP id g65so4820937oia.2 for ; Tue, 24 Mar 2015 13:57:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:mime-version:date :subject:message-id:to; bh=tSEyIg2BEPw+fSITOozSTpR44RBaZBVHOsyzvo8J0SU=; b=fnmnJEooQj6dpDVrPzjsh1c41rov+WPmGN66lKSTbcfMmgw7Ke6GUxLxvF3J6zycdG wY2wooPQ/AKXFpOeLdsE/GFho0GwkyghIrvPfmfjnwc1DsXsJ+AK3hnpH0bSK5Om8TSO vLhPle0LlztFkD8Sg2PEw0kpvcDmSeIWpEJQsPO1iyoFSrm8zYn222RD1G44Ko0PqiVP +qIoEK+hH8O9QajsQjvLALJiCQ+KqK/IxhbI7XzrWtnR3GJTqhWLX7aoIUPH+0ah+a5s KtYWWMKnY6SnebKkG3cm4z8J3vr6heeZyW9GiJWe2RpwMnlDZmeNW2c1V1O+VX58Qn4v jWoQ== X-Received: by 10.202.181.193 with SMTP id e184mr4039370oif.53.1427230652250; Tue, 24 Mar 2015 13:57:32 -0700 (PDT) Received: from [10.9.221.135] (mobile-166-173-187-216.mycingular.net. [166.173.187.216]) by mx.google.com with ESMTPSA id rt10sm307029obb.7.2015.03.24.13.57.31 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 24 Mar 2015 13:57:31 -0700 (PDT) From: Doug Otis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Date: Tue, 24 Mar 2015 15:57:28 -0500 Message-Id: To: "apps-discuss@ietf.org" X-Mailer: iPhone Mail (12D508) Archived-At: Subject: [apps-discuss] I X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 20:57:34 -0000 Regards, Douglas Otis From David_Warden@dell.com Tue Mar 24 14:10:49 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97E471A8BC3 for ; Tue, 24 Mar 2015 14:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-2gxx8-G1xz for ; Tue, 24 Mar 2015 14:10:47 -0700 (PDT) Received: from ausxippc110.us.dell.com (AUSXIPPC110.us.dell.com [143.166.85.200]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 622971A8AF4 for ; Tue, 24 Mar 2015 14:10:46 -0700 (PDT) DomainKey-Signature: s=smtpout; d=dell.com; c=nofws; q=dns; h=X-LoopCount0:X-IronPort-AV:From:To:Date:Subject: Thread-Topic:Thread-Index:Message-ID:Accept-Language: Content-Language:X-MS-Has-Attach:acceptlanguage: Content-Type:MIME-Version; b=H3ee3+JaGKWCovnZof49W2lD6shhQeTKfbypbMzaw4X3G9e7ThcidZh7 f/w5sQ9eLwUsE3gLYhkjYOHdXLBqafbaQ+l7CosYm9y/lZd/Pglshci6j S8+FV2PEHhwYZlEqPaih8BhwSEKN5YMo43uLA3z9LvVDEvYIG3CDMC95R A=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1427231446; x=1458767446; h=from:to:date:subject:message-id:mime-version: content-transfer-encoding; bh=Q29hra0do5dwfYcAb1+j1S7H09gqNNwIE+IvKbppC8U=; b=scufiDlrsbn6cKz/HyYckCtR7NdflphlEScD8dClgCu6PJoh/4nY0s7m +e5cyPLzC520RGjvA1WAvfY8/4D5/5ArLBthsryTvcB6LWyMHAkQoKoSC 7FwFKPmekctPYNhkkNA96XB7NxmYhfn8flLafbj9SkZ17RhocW68PkuYS Y=; X-LoopCount0: from 10.175.216.250 X-IronPort-AV: E=Sophos;i="5.11,460,1422943200"; d="scan'208,217";a="146152545" From: To: Date: Tue, 24 Mar 2015 16:08:18 -0500 Thread-Topic: New Proposed VNC URI Scheme Thread-Index: AdBmc3epAv18Q27XS4e4XqWT/BQbvg== Message-ID: <2D58682309E75147BB3B286C815CAC7E2ABCBBE11B@AUSX7MCPS308.AMER.DELL.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2D58682309E75147BB3B286C815CAC7E2ABCBBE11BAUSX7MCPS308A_" MIME-Version: 1.0 Archived-At: Subject: [apps-discuss] New Proposed VNC URI Scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 21:11:53 -0000 --_000_2D58682309E75147BB3B286C815CAC7E2ABCBBE11BAUSX7MCPS308A_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, My co-author and I have prepared a proposed VNC URI scheme for review by th= e community available at: http://www.ietf.org/internet-drafts/draft-warden-appsawg-vnc-scheme-00.txt To provide a bit of background, VNC applications are fairly common means of= providing remote desktop functionality. While the capabilities of VNC clie= nts are fairly uniform and several of them support VNC URIs, the URI format= consumed by each application differs. While we can't standardize every par= ameter in use by the varying clients, this document allow us to move toward= interoperability while providing for backward compatibility and custom par= ameters. We've implemented the scheme described in the document within the open sour= ce bVNC client on Android, which is launched from the Dell OpenManage Mobil= e app using a URI. We greatly appreciate comments on the proposal, as well as a sense of suppo= rt for processing the draft within the Applications Area Working Group. We = plan to reach out to the authors of several VNC applications, but encourage= anyone with contact information to forward this to others working in the a= rea who may be interested. Regards, David Warden Software Development Principal Engineer Dell | Enterprise Solutions Group --_000_2D58682309E75147BB3B286C815CAC7E2ABCBBE11BAUSX7MCPS308A_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi al= l,

 

My co-author and I have prepared a proposed VNC URI scheme for r= eview by the community available at:

 

http://www.ietf.o= rg/internet-drafts/draft-warden-appsawg-vnc-scheme-00.txt

 

To pr= ovide a bit of background, VNC applications are fairly common means of prov= iding remote desktop functionality. While the capabilities of VNC clients a= re fairly uniform and several of them support VNC URIs, the URI format cons= umed by each application differs. While we can't standardize every paramete= r in use by the varying clients, this document allow us to move toward inte= roperability while providing for backward compatibility and custom paramete= rs.

 

We've implemented the scheme described in the document within = the open source bVNC client on Android, which is launched from the Dell Ope= nManage Mobile app using a URI.

 

We greatly appreciate comments on = the proposal, as well as a sense of support for processing the draft within= the Applications Area Working Group. We plan to reach out to the authors o= f several VNC applications, but encourage anyone with contact information t= o forward this to others working in the area who may be interested.

 

Rega= rds,

 

David Warden

Dell | Enterpri= se Solutions Group

&= nbsp;

= --_000_2D58682309E75147BB3B286C815CAC7E2ABCBBE11BAUSX7MCPS308A_-- From nobody Tue Mar 24 14:18:39 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 327A31A0140 for ; Tue, 24 Mar 2015 14:18:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rWsjAED2xAnl for ; Tue, 24 Mar 2015 14:18:36 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBC2E1A19E3 for ; Tue, 24 Mar 2015 14:18:36 -0700 (PDT) Received: from [100.108.121.233] (18.sub-70-208-150.myvzw.com [70.208.150.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 726D2C4014D; Tue, 24 Mar 2015 16:18:35 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1427231915; bh=YdnR5CQudn4/sswfk2uDJc1y+UWCSiupopI7UwkjHIg=; h=In-Reply-To:References:Subject:From:Date:To:From; b=iR9WmlFm2yW57PcWqWrabyVMuJlcV6T0ioKv/K2Y+Tw/qurqGQrgi+wLBVMi9LgrC FzBEAvKNJeuKy+hgWWzVHG4Dq+IsTKuHpwn2vJZ6Q9QSgPYMd1JSWGh9DnIXSNps0g hxGLMuBCqv8yBL/s/LETxqNpIc04kL/Q0Vv29TXA= User-Agent: K-9 Mail for Android In-Reply-To: References: <20150323150056.3303.33358.idtracker@ietfa.amsl.com> <2397772.kkcDL6IhXZ@kitterma-e6430> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Scott Kitterman Date: Tue, 24 Mar 2015 17:18:33 -0400 To: IETF Apps Discuss Message-ID: <00E8B377-AD75-4934-ABDF-BC4B2169F557@kitterman.com> Archived-At: Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc7001bis-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 21:18:38 -0000 On March 24, 2015 1:23:35 PM EDT, "Murray S. Kucherawy" wrote: >On Tue, Mar 24, 2015 at 3:50 AM, Scott Kitterman >wrote: > >> >> There was one error introduced in this revision. Where it says: >> >> For SPF, the ptype used is "smtp", and the property is any of >> "mailfrom", "helo", and "ehlo", since those values are the >ones SPF >> can evaluate. >> >> "ehlo" isn't a valid property. The property is "helo" and it >contains the >> value of "helo" or "ehlo" as needed. Needs to say 'either of >"mailfrom" or >> "helo"' instead. >> > >In Section 2.2 we say that the "smtp" ptype can have a property of any >valid SMTP command. EHLO is one. Moreover, SPF can evaluate EHLO, >naturally. So if we make the change you're talking about, we also need >to >say that EHLO is mapped to HELO in this context. Would that satisfy >this >issue? Yes. As I read the registry that's what it says to do. Scott K From nobody Tue Mar 24 14:19:03 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B97281A19EC for ; Tue, 24 Mar 2015 14:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bcpW-zNjrlX7 for ; Tue, 24 Mar 2015 14:19:01 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD6EA1A0140 for ; Tue, 24 Mar 2015 14:19:00 -0700 (PDT) Received: by wgs2 with SMTP id 2so4707772wgs.1 for ; Tue, 24 Mar 2015 14:18:59 -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=CPWem8kbpXGtY2wA5GAYzkZQY7JasPigYVC01HgXhG4=; b=lCYkF/3OkTyeJZZkzOtLny6MaVycH8MrvuOm7DE062lpHYCfqmoZYB193Cx8sDekUH 5w/iaE8+V3AAdg+fxcKEhef0yC9OVdS4xE6tCLWvaeiMk9sATLxfDtvz+gToLy5LAvBY 3GTP2nEiWO0RQ8V+qbNoOZQwsrsHxSzMERxLSYtHpnU4xqUjpe5m9DkH/On7eVYOrjyq tBlXSVma+/pDRzj7F+J1lEMU77CTgBikYB+e2vdZYbBQCivKoljeQG9LEcEeDiEkuCKz ULgY3iDqdkdWq4JFwK+WEFR55FvMv3LF6vo1OHibTbPg6go9p4G0icC1H8L4L+1c3kbA wIFA== MIME-Version: 1.0 X-Received: by 10.180.79.65 with SMTP id h1mr32127187wix.59.1427231939558; Tue, 24 Mar 2015 14:18:59 -0700 (PDT) Received: by 10.27.179.212 with HTTP; Tue, 24 Mar 2015 14:18:59 -0700 (PDT) In-Reply-To: <2D58682309E75147BB3B286C815CAC7E2ABCBBE11B@AUSX7MCPS308.AMER.DELL.COM> References: <2D58682309E75147BB3B286C815CAC7E2ABCBBE11B@AUSX7MCPS308.AMER.DELL.COM> Date: Tue, 24 Mar 2015 14:18:59 -0700 Message-ID: From: "Murray S. Kucherawy" To: David_Warden@dell.com Content-Type: multipart/alternative; boundary=14dae9cc9534c502d405120f549a Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] New Proposed VNC URI Scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 21:19:02 -0000 --14dae9cc9534c502d405120f549a Content-Type: text/plain; charset=UTF-8 On Tue, Mar 24, 2015 at 2:08 PM, wrote: > My co-author and I have prepared a proposed VNC URI scheme for review by > the community available at: > > http://www.ietf.org/internet-drafts/draft-warden-appsawg-vnc-scheme-00.txt > > [...] > Thanks, David. All: While considering this, please keep in mind that the URI Scheme Registrations BCP will soon be updated, replaced by this one, which is about to undergo its IESG Evaluation: http://tools.ietf.org/html/draft-ietf-appsawg-uri-scheme-reg-04 We'll need to make sure this draft conforms to that one before the registration can happen. -MSK --14dae9cc9534c502d405120f549a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Mar 24, 2015 at 2:08 PM, <David_Warden@dell.= com> wrote:
My co-author and I have prepared= a proposed VNC URI scheme for review by the community available at:

http://www.ietf.org/internet-drafts/draft-warden= -appsawg-vnc-scheme-00.txt

[...]

Thanks, David.

All: While consideri= ng this, please keep in mind that the URI Scheme Registrations BCP will soo= n be updated, replaced by this one, which is about to undergo its IESG Eval= uation:

http://tools.ietf.org/html/draft-ietf-appsawg-uri-scheme-re= g-04

We'll need to make sure this draft conforms = to that one before the registration can happen.

-MSK
<= /div>
--14dae9cc9534c502d405120f549a-- From nobody Tue Mar 24 14:20:12 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FCCE1A19E3 for ; Tue, 24 Mar 2015 14:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Odhxsv7LpFD for ; Tue, 24 Mar 2015 14:20:09 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7A591A1ADD for ; Tue, 24 Mar 2015 14:20:08 -0700 (PDT) Received: by wixw10 with SMTP id w10so10362624wix.0 for ; Tue, 24 Mar 2015 14:20:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FoAogtHgj2UbZTwAlSnKUBzE5mTHcOuKg8Gx2bdO5Y4=; b=gbsjgG89kqTTpRHz/AcH+U8EYwO0qhXfVCBtFQeBWNe7KMxyM4TN4CpJLhnhiiXNrY hQxzBGB5LhN/UY6DqqeHpGnyxVQigZ830fXqKLnyryOC9CL0sgnDgoyOxT49yOdPlKd8 0qpAbEyUG0X1iVj6Nf4hPE7i14QDeZ7bvlQsq8b3/eAXsUq2O7xFPGp+LCl4wfNgDNx0 ow13qArCDmIJm9PqGUg2jPs8LmC3ppD+WYj2xfUbGBEAwnOYSv0vHb1w322Jpbgk/MyM hn5MWPF3bRrtn/jrDAclVWxX5QuZzDSTp8/9fYp+tR+zqlv59Y8gInHc86DNMXOPIo4I z9ww== MIME-Version: 1.0 X-Received: by 10.194.179.194 with SMTP id di2mr11856487wjc.4.1427232007527; Tue, 24 Mar 2015 14:20:07 -0700 (PDT) Received: by 10.27.179.212 with HTTP; Tue, 24 Mar 2015 14:20:07 -0700 (PDT) In-Reply-To: <00E8B377-AD75-4934-ABDF-BC4B2169F557@kitterman.com> References: <20150323150056.3303.33358.idtracker@ietfa.amsl.com> <2397772.kkcDL6IhXZ@kitterma-e6430> <00E8B377-AD75-4934-ABDF-BC4B2169F557@kitterman.com> Date: Tue, 24 Mar 2015 14:20:07 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=089e01419d1cd2220c05120f58e1 Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc7001bis-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 21:20:10 -0000 --089e01419d1cd2220c05120f58e1 Content-Type: text/plain; charset=UTF-8 On Tue, Mar 24, 2015 at 2:18 PM, Scott Kitterman wrote: > >In Section 2.2 we say that the "smtp" ptype can have a property of any > >valid SMTP command. EHLO is one. Moreover, SPF can evaluate EHLO, > >naturally. So if we make the change you're talking about, we also need > >to > >say that EHLO is mapped to HELO in this context. Would that satisfy > >this > >issue? > > Yes. As I read the registry that's what it says to do. > Cool, done for -05. Stephane, what say you? -MSK --089e01419d1cd2220c05120f58e1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Mar 24, 2015 at 2:18 PM, Scott Kitterman <scott= @kitterman.com> wrote:
>In S= ection 2.2 we say that the "smtp" ptype can have a property of an= y
>valid SMTP command.=C2=A0 EHLO is one.=C2=A0 Moreover, SPF can evaluate= EHLO,
>naturally.=C2=A0 So if we make the change you're talking about, we = also need
>to
>say that EHLO is mapped to HELO in this context.=C2=A0 Would that satis= fy
>this
>issue?

Yes. As I read the registry that's what it says to do.

Cool, done for -05.

Stephane, = what say you?

-MSK
--089e01419d1cd2220c05120f58e1-- From nobody Tue Mar 24 14:47:11 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7260C1A8ADF for ; Tue, 24 Mar 2015 14:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, TVD_SPACE_RATIO=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WME7ijpVTZd6 for ; Tue, 24 Mar 2015 14:47:08 -0700 (PDT) Received: from mail-yh0-x234.google.com (mail-yh0-x234.google.com [IPv6:2607:f8b0:4002:c01::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3C1F1A9007 for ; Tue, 24 Mar 2015 14:46:55 -0700 (PDT) Received: by yhch68 with SMTP id h68so3296071yhc.1 for ; Tue, 24 Mar 2015 14:46:55 -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=f2/pG0NO+gEhY8v3VN7uRfypqatFgqP0GviWnj6esBw=; b=XeP7MmhabnWj9e/eiYIzmgoV0MAfeM7HAMx/WfcUMOmCt1u+T946+WtSZ1p21tJqKZ nQ6cgxR/FS90G4qGccYRmTVYe64uPnCZS40XSko1jpDqlhqweUwZLMtFJWMxwA9y0JGo 4Zhnoi0CLbEQRs1dyr76O/0FftZDoFq3p0ssi5RZTTP4x62wNpByvnmBt9j5ErYfUcR8 hCETppnEBSb2ugBfvGjyw+xQbV1DWo3iEEpOYXsXIDr6O5DVP6e+CPP+1k87CU13CEQb J2pLOUF5ko6b0bJ8n+knaxcNmYRctieS+CqmOyVgjrT8JFkyLlmr6Puv59gGZV2YKlm2 7j/w== MIME-Version: 1.0 X-Received: by 10.170.112.130 with SMTP id e124mr8075805ykb.40.1427233615134; Tue, 24 Mar 2015 14:46:55 -0700 (PDT) Received: by 10.170.47.70 with HTTP; Tue, 24 Mar 2015 14:46:55 -0700 (PDT) Date: Tue, 24 Mar 2015 14:46:55 -0700 Message-ID: From: chris jamison To: "apps-discuss@ietf.org" Content-Type: multipart/alternative; boundary=001a1137ab84a4472305120fb81b Archived-At: Subject: [apps-discuss] (no subject) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 21:47:09 -0000 --001a1137ab84a4472305120fb81b Content-Type: text/plain; charset=UTF-8 --001a1137ab84a4472305120fb81b Content-Type: text/html; charset=UTF-8 <d2v6ciEAbqvy/AQAAAAB/u7ec1/JPEClU/1v31xx/ReHT6//jln6neq/Et>
--001a1137ab84a4472305120fb81b-- From nobody Wed Mar 25 02:37:07 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 002521A07BC for ; Wed, 25 Mar 2015 02:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGP6bkS0uZlB for ; Wed, 25 Mar 2015 02:37:04 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0762.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::762]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE91C1A896A for ; Wed, 25 Mar 2015 02:37:03 -0700 (PDT) Received: from pc6 (81.151.162.168) by AMXPR07MB054.eurprd07.prod.outlook.com (10.242.67.143) with Microsoft SMTP Server (TLS) id 15.1.118.21; Wed, 25 Mar 2015 09:36:44 +0000 Message-ID: <01f201d066df$19eac1e0$4001a8c0@gateway.2wire.net> From: t.petch To: "Murray S. Kucherawy" References: <20150323150056.3303.33358.idtracker@ietfa.amsl.com><012801d0663f$8f700380$4001a8c0@gateway.2wire.net> Date: Wed, 25 Mar 2015 09:27:13 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.151.162.168] X-ClientProxiedBy: HE1PR08CA0015.eurprd08.prod.outlook.com (25.161.112.25) To AMXPR07MB054.eurprd07.prod.outlook.com (10.242.67.143) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB054; X-Forefront-Antispam-Report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(51704005)(377454003)(24454002)(13464003)(50466002)(1411001)(62236002)(116806002)(42186005)(44716002)(230783001)(1556002)(61296003)(87976001)(66066001)(68736005)(77096005)(47776003)(86362001)(84392001)(23676002)(50226001)(44736004)(19580395003)(19580405001)(14496001)(77156002)(62966003)(50986999)(76176999)(81816999)(81686999)(33646002)(92566002)(122386002)(40100003)(46102003)(1456003)(97736003)(110136001)(93886004)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMXPR07MB054; H:pc6; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:AMXPR07MB054; BCL:0; PCL:0; RULEID:; SRVR:AMXPR07MB054; X-Forefront-PRVS: 052670E5A4 Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Mar 2015 09:36:44.1126 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMXPR07MB054 Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc7001bis-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 09:37:06 -0000 ----- Original Message ----- From: "Murray S. Kucherawy" To: "t.petch" Cc: "IETF Apps Discuss" Sent: Tuesday, March 24, 2015 5:15 PM > On Tue, Mar 24, 2015 at 7:33 AM, t.petch wrote: > > Indeed. It clears all my outstanding issues. > > Huzzah! > > > Meanwhile:-(, > > > > s 2.3 /inidcate/indicate / > > Fixed for -05 (not a WGLC-stopper at any rate). > > > 'it ignores the result reported with that "ptype". ' > > > > Is that a SHOULD or MUST, even? > > This draft doesn't use RFC2119 words at all, but still manages to be > normative. That is, what you've cited is equivalent to a MUST. Pete, back > me up here. ;-) Murray I am confused. s.1.5.1 Key Words has the usual extract about RFC2119 while I think I see in the text "then it MUST use the right hand" "uniqueness of the identifier MUST " "MUST pertain to that ADMD. " etc a total of 19 times. What am I missing? Tom Petch > > -MSK > From nobody Wed Mar 25 15:59:44 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 560611AC41A for ; Wed, 25 Mar 2015 15:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bgXoLNU6Lk9W for ; Wed, 25 Mar 2015 15:59:42 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23C151ABD3A for ; Wed, 25 Mar 2015 15:59:42 -0700 (PDT) Received: by wibg7 with SMTP id g7so4072227wib.1 for ; Wed, 25 Mar 2015 15:59: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=zEUpevq50mUB+/wIsXWi5QC0nFkYzIDW3gs4QQBVkJM=; b=oFyr/IH4OQoaatBJyLjAleNjNuQN7ErJYOB/+L3RNoP+kkqpD28CN0XlgmIVYxzIS4 X18pGNUob3KeY5kAv6OMMEAAJthQZa7u9GBF50ASTfNAXBwFcMGidUb8rLeXY3v9Z7Oi J3kuTzXFiiF5JKKIwQvjeEIx0kJ7fF+Qy/pTqxXrWNV2wQLUuBU6BmOa+8lrGaF0Vx3d ojKsPXR4Dy8tQ0UU+yi7JUXkxj4RBIkGpNyugw7yfp+MddD2+eURD3O0ILLlMLJBMheK 6FlOjZ+hTNzuVDNaFf8LAFo/uGm7WoXUuI9JlSUfrrF3S+5U9ym5ZkjWeOyEU30Y29zK VdBA== MIME-Version: 1.0 X-Received: by 10.180.75.243 with SMTP id f19mr41872543wiw.94.1427324380951; Wed, 25 Mar 2015 15:59:40 -0700 (PDT) Received: by 10.27.179.212 with HTTP; Wed, 25 Mar 2015 15:59:40 -0700 (PDT) In-Reply-To: <01f201d066df$19eac1e0$4001a8c0@gateway.2wire.net> References: <20150323150056.3303.33358.idtracker@ietfa.amsl.com> <012801d0663f$8f700380$4001a8c0@gateway.2wire.net> <01f201d066df$19eac1e0$4001a8c0@gateway.2wire.net> Date: Wed, 25 Mar 2015 15:59:40 -0700 Message-ID: From: "Murray S. Kucherawy" To: "t.petch" Content-Type: multipart/alternative; boundary=f46d0438951bb4b866051224dacc Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc7001bis-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 22:59:43 -0000 --f46d0438951bb4b866051224dacc Content-Type: text/plain; charset=UTF-8 On Wed, Mar 25, 2015 at 2:27 AM, t.petch wrote: > I am confused. > > s.1.5.1 Key Words has the usual extract about RFC2119 while I think I > see in the text > "then it MUST use the right hand" > "uniqueness of the identifier MUST " > "MUST pertain to that ADMD. " > etc a total of 19 times. What am I missing? > You fell victim to my temporary insanity. Translation: I was apparently thinking about a different document somehow. You're right, I'm wrong. The text has been fixed up; thanks to Pete for his help. I'll post -05 when I hear back from Stephane. -MSK --f46d0438951bb4b866051224dacc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Mar 25, 2015 at 2:27 AM, t.petch <ietfc@btconne= ct.com> wrote:
I am confused.

s.1.5.1 Key Words has the usual extract about RFC2119 while I think I
see in the text
"then it MUST use the right hand"
"uniqueness of the identifier MUST "
"MUST pertain to that ADMD.=C2=A0 "
etc a total of 19 times.=C2=A0 What am I missing?

=
You fell victim to my temporary insanity.

Tran= slation: I was apparently thinking about a different document somehow.=C2= =A0 You're right, I'm wrong.=C2=A0 The text has been fixed up; than= ks to Pete for his help.

I'll post -05 when I hear ba= ck from Stephane.

-MSK
--f46d0438951bb4b866051224dacc-- From nobody Thu Mar 26 08:17:24 2015 Return-Path: X-Original-To: expand-draft-ietf-appsawg-multipart-form-data.all@virtual.ietf.org Delivered-To: apps-discuss@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 628881A8AE3; Wed, 25 Mar 2015 09:42:18 -0700 (PDT) X-Original-To: xfilter-draft-ietf-appsawg-multipart-form-data.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-appsawg-multipart-form-data.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 442FF1A8A08 for ; Wed, 25 Mar 2015 09:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.935 X-Spam-Level: X-Spam-Status: No, score=-0.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yggux5B0kNVa for ; Wed, 25 Mar 2015 09:42:17 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C7251A8974 for ; Wed, 25 Mar 2015 09:42:17 -0700 (PDT) Received: from mail-sg1bn0109.outbound.protection.outlook.com ([134.170.132.109]:39577 helo=APAC01-SG1-obe.outbound.protection.outlook.com) by zinfandel.tools.ietf.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YaoNj-0000F7-HS for draft-ietf-appsawg-multipart-form-data.all@tools.ietf.org; Wed, 25 Mar 2015 09:42:16 -0700 Received: from [133.2.210.64] (133.2.210.64) by OS2PR01MB0076.jpnprd01.prod.outlook.com (25.161.76.19) with Microsoft SMTP Server (TLS) id 15.1.118.21; Wed, 25 Mar 2015 02:14:28 +0000 Message-ID: <551219FE.1070306@it.aoyama.ac.jp> Date: Wed, 25 Mar 2015 11:14:22 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Bert Wijnen (IETF)" , References: <55114E0C.9050007@bwijnen.net> In-Reply-To: <55114E0C.9050007@bwijnen.net> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: OS1PR01CA0007.jpnprd01.prod.outlook.com (25.161.225.145) To OS2PR01MB0076.jpnprd01.prod.outlook.com (25.161.76.19) Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:OS2PR01MB0076; X-Forefront-Antispam-Report: BMV:1; SFV:NSPM; SFS:(10019020)(6049001)(6009001)(24454002)(51704005)(479174004)(52604005)(65956001)(83506001)(23676002)(86362001)(64126003)(65806001)(66066001)(87976001)(46102003)(230783001)(74482002)(33656002)(85182001)(50466002)(92566002)(42186005)(99136001)(40100003)(77156002)(50986999)(2950100001)(122386002)(65816999)(80316001)(62966003)(54356999)(87266999)(76176999)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:OS2PR01MB0076; H:[133.2.210.64]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(5002010)(5005006); SRVR:OS2PR01MB0076; BCL:0; PCL:0; RULEID:; SRVR:OS2PR01MB0076; X-Forefront-PRVS: 052670E5A4 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Mar 2015 02:14:28.1449 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: OS2PR01MB0076 X-OriginatorOrg: it.aoyama.ac.jp X-Helo-Check-Failed: Verification failed for HELO APAC01-SG1-obe.outbound.protection.outlook.com X-SA-Exim-Connect-IP: 134.170.132.109 X-SA-Exim-Rcpt-To: draft-ietf-appsawg-multipart-form-data.all@tools.ietf.org X-SA-Exim-Mail-From: duerst@it.aoyama.ac.jp X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-appsawg-multipart-form-data.all@ietf.org Resent-Message-Id: <20150325164217.0C7251A8974@ietfa.amsl.com> Resent-Date: Wed, 25 Mar 2015 09:42:17 -0700 (PDT) Resent-From: duerst@it.aoyama.ac.jp Archived-At: Archived-At: X-Mailman-Approved-At: Thu, 26 Mar 2015 08:17:21 -0700 Cc: "ops-dir@ietf.org" Subject: Re: [apps-discuss] OPSDIR review for draft-ietf-appsawg-multipart-form-data-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 16:42:18 -0000 On 2015/03/24 20:44, Bert Wijnen (IETF) wrote: > - section 4.7 > > --AaB03x > content-disposition: form-data; name="_charset_" > > iso8859-1 > --AaB03x-- > content-disposition: form-data; name="field1" > > ...text encoded in iso-8859-1 ... > AaB03x-- > > I am not an expert in character sets and such. > But.... would it not be more consistent to use the same "iso8859-1" > verywhere instead > of using "iso-8859-1" in addition to "iso8859-1" ??? This is a mistake. "iso8859-1" needs to be fixed to "iso-8859-1". Thanks for catching it! Regards, Martin. From nobody Thu Mar 26 15:15:17 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82DC11A00E8; Thu, 26 Mar 2015 15:15:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9eugUqqo_X6C; Thu, 26 Mar 2015 15:15:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 565CB1A011D; Thu, 26 Mar 2015 15:15:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150326221513.1954.77762.idtracker@ietfa.amsl.com> Date: Thu, 26 Mar 2015 15:15:13 -0700 Archived-At: Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc7001bis-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 22:15:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : Message Header Field for Indicating Message Authentication Status Author : Murray S. Kucherawy Filename : draft-ietf-appsawg-rfc7001bis-05.txt Pages : 50 Date : 2015-03-26 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 to make sorting and filtering decisions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc7001bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-rfc7001bis-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-rfc7001bis-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Mar 27 09:33:43 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03FEE1ACEFB; Fri, 27 Mar 2015 09:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gu03hVLrsevK; Fri, 27 Mar 2015 09:33:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E509E1AD0B2; Fri, 27 Mar 2015 09:33:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150327163331.20999.18776.idtracker@ietfa.amsl.com> Date: Fri, 27 Mar 2015 09:33:31 -0700 Archived-At: Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-uri-scheme-reg-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 16:33:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : Guidelines and Registration Procedures for URI Schemes Authors : Dave Thaler Tony Hansen Ted Hardie Larry Masinter Filename : draft-ietf-appsawg-uri-scheme-reg-05.txt Pages : 19 Date : 2015-03-27 Abstract: This document updates the guidelines and recommendations, as well as the IANA registration processes, for the definition of Uniform Resource Identifier (URI) schemes. It obsoletes RFC 4395. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-uri-scheme-reg/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-uri-scheme-reg-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-uri-scheme-reg-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Mar 27 09:33:45 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9F061AD067; Fri, 27 Mar 2015 09:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0sJPRGRBQg47; Fri, 27 Mar 2015 09:33:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F24891AD066; Fri, 27 Mar 2015 09:33:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150327163331.20999.30881.idtracker@ietfa.amsl.com> Date: Fri, 27 Mar 2015 09:33:31 -0700 Archived-At: Subject: [apps-discuss] New Version Notification - draft-ietf-appsawg-uri-scheme-reg-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 16:33:42 -0000 A new version (-05) has been submitted for draft-ietf-appsawg-uri-scheme-reg: http://www.ietf.org/internet-drafts/draft-ietf-appsawg-uri-scheme-reg-05.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-uri-scheme-reg/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-uri-scheme-reg-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Sat Mar 28 10:20:40 2015 Return-Path: X-Original-To: expand-draft-ietf-appsawg-uri-scheme-reg.all@virtual.ietf.org Delivered-To: apps-discuss@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id A85051A92F4; Fri, 27 Mar 2015 12:27:21 -0700 (PDT) X-Original-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC601A92F0 for ; Fri, 27 Mar 2015 12:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uonCtJZux3AL for ; Fri, 27 Mar 2015 12:27:17 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0766.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:766]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6026A1A92E8 for ; Fri, 27 Mar 2015 12:27:17 -0700 (PDT) Received: from DM2PR03MB414.namprd03.prod.outlook.com (10.141.84.145) by DM2PR03MB413.namprd03.prod.outlook.com (10.141.84.142) with Microsoft SMTP Server (TLS) id 15.1.125.14; Fri, 27 Mar 2015 19:26:58 +0000 Received: from DM2PR03MB414.namprd03.prod.outlook.com ([10.141.84.145]) by DM2PR03MB414.namprd03.prod.outlook.com ([10.141.84.145]) with mapi id 15.01.0125.002; Fri, 27 Mar 2015 19:26:58 +0000 From: Dave Thaler To: "Barry Leiba (barryleiba@computer.org)" Thread-Topic: [apps-discuss] New Version Notification - draft-ietf-appsawg-uri-scheme-reg-05.txt Thread-Index: AQHQaKvktgSev9YEQ0eqv7bsgQVQj50wtQcA Date: Fri, 27 Mar 2015 19:26:58 +0000 Message-ID: References: <20150327163331.20999.30881.idtracker@ietfa.amsl.com> In-Reply-To: <20150327163331.20999.30881.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:67c:370:160:89d0:b50d:1db:2623] authentication-results: computer.org; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR03MB413; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(377454003)(13464003)(110136001)(77096005)(46102003)(33656002)(2420400003)(102836002)(62966003)(74316001)(106116001)(19580395003)(19580405001)(15975445007)(76576001)(77156002)(86362001)(92566002)(230783001)(87936001)(2656002)(76176999)(50986999)(122556002)(54356999)(86612001)(2950100001)(2900100001)(40100003)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR03MB413; H:DM2PR03MB414.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:DM2PR03MB413; BCL:0; PCL:0; RULEID:; SRVR:DM2PR03MB413; x-forefront-prvs: 0528942FD8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Mar 2015 19:26:58.1214 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR03MB413 Archived-At: X-Mailman-Approved-At: Sat, 28 Mar 2015 10:20:39 -0700 Cc: "draft-ietf-appsawg-uri-scheme-reg.all@ietf.org" Subject: [apps-discuss] FW: New Version Notification - draft-ietf-appsawg-uri-scheme-reg-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 19:27:21 -0000 Hi Barry,=20 Larry, Tony, Alexey, and I met yesterday to go over proposed resolutions to= the feedback received. I've attempted to make changes per what we've discussed, though my co-autho= rs and doc shepherd need to check, and if I messed up anything, I can spin another rev early ne= xt week if needed. I will send email responses to the feedback received with what we did. I m= ay not get those out today though. But I think the doc should be ready for the IESG telechat. Dave -----Original Message----- From: apps-discuss [mailto:apps-discuss-bounces@ietf.org] On Behalf Of inte= rnet-drafts@ietf.org Sent: Friday, March 27, 2015 11:34 AM To: alexey.melnikov@isode.com; appsawg-chairs@ietf.org; apps-discuss@ietf.o= rg; barryleiba@computer.org Subject: [apps-discuss] New Version Notification - draft-ietf-appsawg-uri-s= cheme-reg-05.txt A new version (-05) has been submitted for draft-ietf-appsawg-uri-scheme-re= g: http://www.ietf.org/internet-drafts/draft-ietf-appsawg-uri-scheme-reg-05.tx= t The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-uri-scheme-reg/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-uri-scheme-reg-05 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Sat Mar 28 10:20:42 2015 Return-Path: X-Original-To: expand-draft-ietf-appsawg-uri-scheme-reg.all@virtual.ietf.org Delivered-To: apps-discuss@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id C7C241A1BD9; Fri, 27 Mar 2015 22:32:03 -0700 (PDT) X-Original-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD9DB1A1BD1 for ; Fri, 27 Mar 2015 22:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ENgILKGClKJ for ; Fri, 27 Mar 2015 22:32:02 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0095.outbound.protection.outlook.com [207.46.100.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E39411A1BCC for ; Fri, 27 Mar 2015 22:32:01 -0700 (PDT) Received: from DM2PR02MB1322.namprd02.prod.outlook.com (25.161.142.21) by DM2PR02MB1322.namprd02.prod.outlook.com (25.161.142.21) with Microsoft SMTP Server (TLS) id 15.1.118.21; Sat, 28 Mar 2015 05:31:59 +0000 Received: from DM2PR02MB1322.namprd02.prod.outlook.com ([25.161.142.21]) by DM2PR02MB1322.namprd02.prod.outlook.com ([25.161.142.21]) with mapi id 15.01.0118.022; Sat, 28 Mar 2015 05:31:59 +0000 From: Larry Masinter To: Barry Leiba , Dave Thaler Thread-Topic: [apps-discuss] New Version Notification - draft-ietf-appsawg-uri-scheme-reg-05.txt Thread-Index: AQHQaRiCo9zqWW6I1EWWXgjBoh/W0A== Date: Sat, 28 Mar 2015 05:31:58 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/15.8.0.150303 x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [142.131.228.251] authentication-results: computer.org; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR02MB1322; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10009020)(6009001)(377454003)(51704005)(479174004)(24454002)(2421001)(99286002)(2656002)(102836002)(50986999)(54356999)(33656002)(87936001)(106116001)(1511001)(92566002)(83506001)(230783001)(36756003)(46102003)(19580395003)(19580405001)(2900100001)(122556002)(83716003)(82746002)(40100003)(86362001)(66066001)(77156002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR02MB1322; H:DM2PR02MB1322.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:DM2PR02MB1322; BCL:0; PCL:0; RULEID:; SRVR:DM2PR02MB1322; x-forefront-prvs: 05299D545B Content-Type: text/plain; charset="utf-8" Content-ID: <38D457669BF1064185B5C9B263C9891F@namprd02.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: adobe.com X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Mar 2015 05:31:58.6641 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR02MB1322 Archived-At: X-Mailman-Approved-At: Sat, 28 Mar 2015 10:20:39 -0700 Cc: "draft-ietf-appsawg-uri-scheme-reg.all@ietf.org" Subject: Re: [apps-discuss] New Version Notification - draft-ietf-appsawg-uri-scheme-reg-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2015 05:32:03 -0000 U28gSeKAmW0gT0sgd2l0aCB0aGUgZG9jdW1lbnQgYXMgaXMuIEkgaGF2ZSBjb25jZXJucyAodGhl IOKAmHVybC1tZXNz4oCZLA0KYW5kIHdoZXRoZXIgVVJOQklTIGFjY2VwdHMgbXkgaW50ZXJwcmV0 YXRpb25zKSBidXQgdGhvc2UgYXJlDQpmdXR1cmUgaXNzdWVzIHRoYXQgbWF5IG9yIG1heSBub3Qg YWZmZWN0IHRoaXMgZG9jdW1lbnQsIHNvIGxldOKAmXMNCmdvIHdpdGggaXQuDQoNCkxhcnJ5DQoN Cg0KDQoNCk9uIDMvMjcvMTUsIDI6MjkgUE0sICJCYXJyeSBMZWliYSIgPGJhcnJ5bGVpYmFAY29t cHV0ZXIub3JnPiB3cm90ZToNCg0KPj4gSSB3aWxsIHNlbmQgZW1haWwgcmVzcG9uc2VzIHRvIHRo ZSBmZWVkYmFjayByZWNlaXZlZCB3aXRoIHdoYXQgd2UgZGlkLg0KPj4gSSBtYXkgbm90IGdldCB0 aG9zZSBvdXQgdG9kYXkgdGhvdWdoLiBCdXQgSSB0aGluayB0aGUgZG9jIHNob3VsZCBiZQ0KPj4g cmVhZHkgZm9yIHRoZSBJRVNHIHRlbGVjaGF0Lg0KPg0KPlRoYW5rcy4gIEkndmUgaXNzdWVkIHRo ZSBiYWxsb3Q7IEknbGwgd2FpdCB0byBjaGFuZ2UgdGhlIHN0YXRlIHVudGlsIEkNCj5oZWFyIHRo YXQgeW91ciBjby1hdXRob3JzICYgc2hlcGhlcmQgYXJlIE9LIHdpdGggaXQuDQo+DQo+Yg0K From nobody Sun Mar 29 06:44:01 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 558FC1A1EEA for ; Sun, 29 Mar 2015 06:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.689 X-Spam-Level: X-Spam-Status: No, score=0.689 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BDBT_DNMKqzC for ; Sun, 29 Mar 2015 06:43:59 -0700 (PDT) Received: from waldorf.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id 44F841A1C06 for ; Sun, 29 Mar 2015 06:43:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1427636638; d=isode.com; s=selector; i=@isode.com; bh=lziiOOs8D3WZzQU/N+eGU5e21+g9rhWFmiVrNzkAdUg=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=VGTWKfW+K6vVQffI6rqPhI1f0BccZtf5PvZ5zhts4QUJ9VbaSVkNqqrTCFCwP2YK46NoDG CJoWHefpvSwlIpLnXTN5CoUgwte47j8s0lH0tdutoDfLLr1JxGAzXGSzaJjvIa435u+kIF C2WVaBNQu7k+zQGagp3fzu2lX9tGEpI=; Received: from [192.168.6.196] (ip-64-134-51-59.public.wayport.net [64.134.51.59]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Sun, 29 Mar 2015 14:43:57 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <5518019A.7080508@isode.com> Date: Sun, 29 Mar 2015 14:43:54 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 To: "apps-discuss@ietf.org" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [apps-discuss] WGLC on draft-ietf-appsawg-rfc7001bis-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2015 13:44:00 -0000 This message is starting 3 weeks (*) Working Group Last Calls on draft-ietf-appsawg-rfc7001bis-05 (Message Header Field for Indicating Message Authentication Status). The WGLC ends on April 19th. Please send your comments on the document in a reply to this message or directly to me. If you read the document and you think the document is ready for publication, saying so would also be helpful. Alexey, As a co-chair. (*) - this is to allow people to recover from the Dallas IETF. From nobody Sun Mar 29 08:30:15 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B1381ACCE8 for ; Sun, 29 Mar 2015 08:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VxyBXZgUgfcF for ; Sun, 29 Mar 2015 08:30:12 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0761.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::761]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B81701ACCDC for ; Sun, 29 Mar 2015 08:30:11 -0700 (PDT) Received: from pc6 (81.151.162.168) by DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) with Microsoft SMTP Server (TLS) id 15.1.118.21; Sun, 29 Mar 2015 15:24:03 +0000 Message-ID: <012f01d06a34$447b0160$4001a8c0@gateway.2wire.net> From: t.petch To: Alexey Melnikov , References: <5518019A.7080508@isode.com> Date: Sun, 29 Mar 2015 16:14:33 +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: [81.151.162.168] X-ClientProxiedBy: AM2PR09CA0009.eurprd09.prod.outlook.com (25.161.22.147) To DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB3PR07MB060; X-Microsoft-Antispam-PRVS: X-Forefront-Antispam-Report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(13464003)(51704005)(51444003)(377454003)(76176999)(42186005)(19580405001)(14496001)(19580395003)(84392001)(15975445007)(66066001)(81686999)(47776003)(50986999)(64706001)(50466002)(62236002)(44716002)(81816999)(77096005)(86362001)(46102003)(77156002)(62966003)(40100003)(50226001)(44736004)(122386002)(87976001)(1556002)(107886001)(92566002)(61296003)(33646002)(23756003)(1456003)(116806002)(230783001)(74416001)(7726001)(2101003); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR07MB060; H:pc6; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:DB3PR07MB060; BCL:0; PCL:0; RULEID:; SRVR:DB3PR07MB060; X-Forefront-PRVS: 0530FCB552 Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Mar 2015 15:24:03.8854 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR07MB060 Archived-At: Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-rfc7001bis-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2015 15:30:14 -0000 I think that this I-D is ready to advance. It has as complex an IANA Considerations as I can recall, comprising, depending on how you count, several hundred changes to the underlying HTML. I could not readily tell what the new registries would look like, so I applied the changes, by hand, to the current registries and have the result in .mhtml. The file is 175kbyte (mostly SCRIPT, probably not needed) and I will post that separately in case others want to peruse it. Picking my words with care, with so much to do, it is possible that IANA will find an alternative interpretation to the one on which the WG has consensus. I have seen that happen before and seen it fixed, without having to change the RFC, but cannot recall just how. It may have been a consensus call on the WG List, or even just an e-mail from AD or WG Chairs; it might be prudent to have the mechanics of this to hand. And/or might it be prudent to insert a further check, perhaps after 'IANA OK', to see what IANA are going to come up with prior to AUTH48? As you may guess, I am a pessimist (but have learnt that the problems that I anticipate are less likely to be problems:-) Tom Petch ----- Original Message ----- From: "Alexey Melnikov" To: Sent: Sunday, March 29, 2015 2:43 PM > This message is starting 3 weeks (*) Working Group Last Calls on > draft-ietf-appsawg-rfc7001bis-05 (Message Header Field for Indicating > Message Authentication Status). The WGLC ends on > April 19th. > > Please send your comments on the document in a reply to this message or > directly to me. If you read the document and you think the document is > ready for publication, saying so would also be helpful. > > Alexey, > As a co-chair. > > (*) - this is to allow people to recover from the Dallas IETF. > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Sun Mar 29 10:37:49 2015 Return-Path: X-Original-To: expand-draft-ietf-appsawg-uri-scheme-reg.all@virtual.ietf.org Delivered-To: apps-discuss@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 261651AC3F5; Sun, 29 Mar 2015 07:05:41 -0700 (PDT) X-Original-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01A611AC3F4 for ; Sun, 29 Mar 2015 07:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.689 X-Spam-Level: X-Spam-Status: No, score=0.689 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tor92WYYBf32 for ; Sun, 29 Mar 2015 07:05:39 -0700 (PDT) Received: from waldorf.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id 645DF1AC3F3 for ; Sun, 29 Mar 2015 07:05:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1427637938; d=isode.com; s=selector; i=@isode.com; bh=5m/gHDdck7zuhG62zlFA9Yeg2DJFjYd17fBF7j/TSU8=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=EasFMAxDZWunTbs4t9u4/BxD/XkT4Fhalb7rrxJngVCS3xqSJ5v8KgXKT3MSuhDxLdO2/y SuENTHDixT0HXi7JePz5MRHj9yVDjqw+LgGgW+l1TVdnNenbuMLhbDJJ+n5irmV3+cUENd NEDwW/yEVdbeScvHj7+AOEmdrclz/2k=; Received: from [192.168.6.196] (ip-64-134-51-59.public.wayport.net [64.134.51.59]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Sun, 29 Mar 2015 15:05:38 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <551806AD.2010409@isode.com> Date: Sun, 29 Mar 2015 15:05:33 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 To: Barry Leiba References: <20150327163331.20999.30881.idtracker@ietfa.amsl.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Sun, 29 Mar 2015 10:37:47 -0700 Cc: "draft-ietf-appsawg-uri-scheme-reg.all@ietf.org" Subject: Re: [apps-discuss] FW: New Version Notification - draft-ietf-appsawg-uri-scheme-reg-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2015 14:05:41 -0000 On 27/03/2015 19:29, Barry Leiba wrote: >> I will send email responses to the feedback received with what we did. >> I may not get those out today though. But I think the doc should be >> ready for the IESG telechat. > Thanks. I've issued the ballot; I'll wait to change the state until I > hear that your co-authors & shepherd are OK with it. This is almost perfect :-). A couple of comments: 1) The last paragraph in Section 3.6 (Internationalization and Character Encoding) now reads (the last sentence is new): All percent-encoded variants are automatically included by definition for any character given in an IRI production. This means that if you want to restrict the URI percent-encoded forms in some way, you must restrict the Unicode forms that would lead to them. In most cases, it is advisable to define the actual characters allowed in an IRI production, to allow the 'pct-encoded' definition from Section 2.1 of [RFC3986] at the same places, and to add prose that limits percent- escapes to those that can be created by converting valid character sequences to percent-encoding via UTF-8. The last part of the sentence doesn't read well (and I can't understand exactly what is it trying to do): and to add prose that limits percent- escapes to those that can be created by converting valid UTF-8 character sequences to their percent-encoding. Dave, is this what you intended? 2) Regarding my earlier disagreement about text suggested by Graham: 3. Requirements for Permanent Scheme Definitions This section gives considerations for new schemes. Meeting these guidelines is REQUIRED for permanent scheme registration. Permanent status is appropriate for, but not limited to, use in standards. For URI schemes defined or normatively referenced by IETF Standards-Track documents, Permanent registration status is REQUIRED. He added "or normatively referenced" which now appears in the draft. Here is a real world example of a problem with this text. SIDR WG decided to use rsync protocol, they needed to use rsync URIs. rsync URIs are currently provisional, defined in an Informational RFC. So this text is basically saying that under the new rule the registration have to be upgraded to Permanent, allowing the expert reviewer (no disrespect to Graham or his future replacement) to be a person that blocks consensus of a WG to use a particular technology. I find this to be problematic. Do people agree that this is problematic? From nobody Sun Mar 29 13:05:54 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 656661A8885; Sun, 29 Mar 2015 13:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FCH5itjDjhpF; Sun, 29 Mar 2015 13:05:48 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A67C71A8884; Sun, 29 Mar 2015 13:05:48 -0700 (PDT) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YcJSs-000Ft7-SM; Sun, 29 Mar 2015 16:05:46 -0400 Date: Sun, 29 Mar 2015 16:05:41 -0400 From: John C Klensin To: Alexey Melnikov , Barry Leiba Message-ID: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: draft-ietf-appsawg-uri-scheme-reg.all@ietf.org, iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] FW: New Version Notification - draft-ietf-appsawg-uri-scheme-reg-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2015 20:05:50 -0000 (reposting -- the IETF mail system apparently didn't like the "implicit" copy to apps-discuss) --On Sunday, March 29, 2015 15:05 +0100 Alexey Melnikov wrote: > On 27/03/2015 19:29, Barry Leiba wrote: >>> I will send email responses to the feedback received with >>> what we did. I may not get those out today though. But I >>> think the doc should be ready for the IESG telechat. >> Thanks. I've issued the ballot; I'll wait to change the >> state until I hear that your co-authors & shepherd are OK >> with it. > This is almost perfect :-). > > A couple of comments: >... > Here is a real world example of a problem with this text. SIDR > WG decided to use rsync protocol, they needed to use rsync > URIs. rsync URIs are currently provisional, defined in an > Informational RFC. So this text is basically saying that > under the new rule the registration have to be upgraded to > Permanent, allowing the expert reviewer (no disrespect to > Graham or his future replacement) to be a person that blocks > consensus of a WG to use a particular technology. I find this > to be problematic. > > Do people agree that this is problematic? Yes. At the risk of tossing a spanner toward the works, one more issue that seems to me very significant: Larry Masinter has raised several issues in the URNBIS WG in which he claims that draft-ietf-appsawg-uri-scheme-reg constrains what that WG is proposing to do with URNs [1]. I also believe that some of his comments mix up registration of schemes (e.g., "urn:") with registrations of URN namespaces and NIDs I think those issues need to be considered in that WG. However, procedurally, it seems to me that either: (1) Existing registrations are existing registrations and any updates to them are grandfathered, i.e., whatever draft-ietf-appsawg-uri-scheme-reg says is not applicable to the original or updated registration of any URI scheme registered or deployed before it is approved and published. That obviously includes the revised URN registration contemplated by draft-ietf-urnbis-rfc2141bis-urn. (2) We have a mess on our hands in which not only do the mandates of different WGs overlap but in which an area WG that is not noted for very intense reviews can constrain and override the work of more topic-focused (and, therefore, presumably more expert on their own topics) WGs and other efforts. This is particularly problematic in the case of URIs, where parallel (and not entirely consistent) work is going on to further develop specific URI schemes (URNs being only one such example) and groups outside the IETF (including WHATWG and W3C groups) with coordination processes that are still being negotiated and in groups that are heavily dependent on URIs and URI handling (certainly including HTTPbis). If it is applicable to existing registrations and ongoing work in other WGs, this spec is even more problematic because it is heavily dependent on details of RFC 3986, a specification whose exact meaning, implications, and consequences continue to be debated and which is a candidate for preemption or replacement by those other bodies. I suggest that any IESG action on draft-ietf-appsawg-uri-scheme-reg be deferred until which of the above principles applies can be clarified (and clarified in the document) and, if the second option is chosen, that formal reviews and impact assessments be sought from all active WGs that are involved with or use URIs as well as from W3C. Sorry to be raising this so late in the process, but it never occurred to me that anyone would claim that draft-ietf-appsawg-uri-scheme-reg constrained other IETF WGs, standards-track updates to existing registrations that were made as the result of standards actions, etc. Since that claim has now been made, and made by one of the authors of the new draft who presumably understands the intent, a "wait a minute" response seems necessary. john [1] http://www.ietf.org/mail-archive/web/urn/current/msg02873.html From nobody Sun Mar 29 13:05:56 2015 Return-Path: X-Original-To: expand-draft-ietf-appsawg-uri-scheme-reg.all@virtual.ietf.org Delivered-To: apps-discuss@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 8C80A1A8889; Sun, 29 Mar 2015 13:05:50 -0700 (PDT) X-Original-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 656661A8885; Sun, 29 Mar 2015 13:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FCH5itjDjhpF; Sun, 29 Mar 2015 13:05:48 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A67C71A8884; Sun, 29 Mar 2015 13:05:48 -0700 (PDT) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YcJSs-000Ft7-SM; Sun, 29 Mar 2015 16:05:46 -0400 Date: Sun, 29 Mar 2015 16:05:41 -0400 From: John C Klensin To: Alexey Melnikov , Barry Leiba Message-ID: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: draft-ietf-appsawg-uri-scheme-reg.all@ietf.org, iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] FW: New Version Notification - draft-ietf-appsawg-uri-scheme-reg-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2015 20:05:50 -0000 (reposting -- the IETF mail system apparently didn't like the "implicit" copy to apps-discuss) --On Sunday, March 29, 2015 15:05 +0100 Alexey Melnikov wrote: > On 27/03/2015 19:29, Barry Leiba wrote: >>> I will send email responses to the feedback received with >>> what we did. I may not get those out today though. But I >>> think the doc should be ready for the IESG telechat. >> Thanks. I've issued the ballot; I'll wait to change the >> state until I hear that your co-authors & shepherd are OK >> with it. > This is almost perfect :-). > > A couple of comments: >... > Here is a real world example of a problem with this text. SIDR > WG decided to use rsync protocol, they needed to use rsync > URIs. rsync URIs are currently provisional, defined in an > Informational RFC. So this text is basically saying that > under the new rule the registration have to be upgraded to > Permanent, allowing the expert reviewer (no disrespect to > Graham or his future replacement) to be a person that blocks > consensus of a WG to use a particular technology. I find this > to be problematic. > > Do people agree that this is problematic? Yes. At the risk of tossing a spanner toward the works, one more issue that seems to me very significant: Larry Masinter has raised several issues in the URNBIS WG in which he claims that draft-ietf-appsawg-uri-scheme-reg constrains what that WG is proposing to do with URNs [1]. I also believe that some of his comments mix up registration of schemes (e.g., "urn:") with registrations of URN namespaces and NIDs I think those issues need to be considered in that WG. However, procedurally, it seems to me that either: (1) Existing registrations are existing registrations and any updates to them are grandfathered, i.e., whatever draft-ietf-appsawg-uri-scheme-reg says is not applicable to the original or updated registration of any URI scheme registered or deployed before it is approved and published. That obviously includes the revised URN registration contemplated by draft-ietf-urnbis-rfc2141bis-urn. (2) We have a mess on our hands in which not only do the mandates of different WGs overlap but in which an area WG that is not noted for very intense reviews can constrain and override the work of more topic-focused (and, therefore, presumably more expert on their own topics) WGs and other efforts. This is particularly problematic in the case of URIs, where parallel (and not entirely consistent) work is going on to further develop specific URI schemes (URNs being only one such example) and groups outside the IETF (including WHATWG and W3C groups) with coordination processes that are still being negotiated and in groups that are heavily dependent on URIs and URI handling (certainly including HTTPbis). If it is applicable to existing registrations and ongoing work in other WGs, this spec is even more problematic because it is heavily dependent on details of RFC 3986, a specification whose exact meaning, implications, and consequences continue to be debated and which is a candidate for preemption or replacement by those other bodies. I suggest that any IESG action on draft-ietf-appsawg-uri-scheme-reg be deferred until which of the above principles applies can be clarified (and clarified in the document) and, if the second option is chosen, that formal reviews and impact assessments be sought from all active WGs that are involved with or use URIs as well as from W3C. Sorry to be raising this so late in the process, but it never occurred to me that anyone would claim that draft-ietf-appsawg-uri-scheme-reg constrained other IETF WGs, standards-track updates to existing registrations that were made as the result of standards actions, etc. Since that claim has now been made, and made by one of the authors of the new draft who presumably understands the intent, a "wait a minute" response seems necessary. john [1] http://www.ietf.org/mail-archive/web/urn/current/msg02873.html From nobody Mon Mar 30 06:19:30 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 844421ACE0D for ; Mon, 30 Mar 2015 06:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.411 X-Spam-Level: X-Spam-Status: No, score=-1.411 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hF4yUJAC5I55 for ; Mon, 30 Mar 2015 06:19:28 -0700 (PDT) Received: from waldorf.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id 4D1461A8927 for ; Mon, 30 Mar 2015 06:19:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1427721567; d=isode.com; s=selector; i=@isode.com; bh=6bK4Oz+BJGa8U9kW5X8C7qc034hezrokz8nJJc0KyCw=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=g6EUzckHeqEr7OmTfCHyjAIBBzjxoBiH3MZdbFg97lRM5rvpmnqXgARvjU2qFCMq07PHYO YaSi6quPOYJYMoBOJz8GhRkzmPPs8wN9xvJffIRm+0i720J50cR+3OP1eeLwQ6+FwyCCxu fI62+Buk+9YX8OK1z1QVMMTeLAo1Iyk=; Received: from [10.1.10.192] ((unknown) [50.249.67.138]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 30 Mar 2015 14:19:27 +0100 X-SMTP-Protocol-Errors: NORDNS PIPELINING From: Alexey Melnikov X-Mailer: iPad Mail (12B435) In-Reply-To: <012f01d06a34$447b0160$4001a8c0@gateway.2wire.net> Date: Mon, 30 Mar 2015 14:27:16 +0100 Message-Id: <0785DFB9-8E63-4EFC-B47C-F6788AE125DD@isode.com> References: <5518019A.7080508@isode.com> <012f01d06a34$447b0160$4001a8c0@gateway.2wire.net> To: "t.petch" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: "" Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-rfc7001bis-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2015 13:19:29 -0000 Hi Tom, > On 29 Mar 2015, at 16:14, t.petch wrote: > > I think that this I-D is ready to advance. > > It has as complex an IANA Considerations as I can recall, > comprising, depending on how you count, several hundred changes to the > underlying HTML. I could not readily tell what the new registries would > look like, so I applied the changes, by hand, to the current registries > and have the result in > .mhtml. The file is 175kbyte (mostly SCRIPT, probably not needed) and I > will post that separately in case others want to peruse it. Yes, changes are quite complicated in this case. > > Picking my words with care, with so much to do, it is possible that IANA > will find an alternative interpretation to the one on which the WG has > consensus. I have seen that happen before and seen it fixed, without > having to change the RFC, but cannot recall just how. It may have been > a > consensus call on the WG List, or even just an e-mail from AD or WG > Chairs; it might be prudent to have the mechanics of this to hand. > > And/or might it be prudent to insert a further check, perhaps after > 'IANA > OK', to see what IANA are going to come up with prior to AUTH48? This would happen anyway, as IANA always ask editors to check changes. > > As you may guess, I am a pessimist (but have learnt that the problems > that I anticipate are less likely to be problems:-) > > Tom Petch > > ----- Original Message ----- > From: "Alexey Melnikov" > To: > Sent: Sunday, March 29, 2015 2:43 PM >> This message is starting 3 weeks (*) Working Group Last Calls on >> draft-ietf-appsawg-rfc7001bis-05 (Message Header Field for Indicating >> Message Authentication Status). The WGLC ends on >> April 19th. >> >> Please send your comments on the document in a reply to this message > or >> directly to me. If you read the document and you think the document is >> ready for publication, saying so would also be helpful. >> >> Alexey, >> As a co-chair. >> >> (*) - this is to allow people to recover from the Dallas IETF. >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss > From nobody Mon Mar 30 10:37:37 2015 Return-Path: X-Original-To: expand-draft-ietf-appsawg-uri-scheme-reg.all@virtual.ietf.org Delivered-To: apps-discuss@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id BD6711ACDE2; Mon, 30 Mar 2015 04:13:21 -0700 (PDT) X-Original-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A1321ACDE0 for ; Mon, 30 Mar 2015 04:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4A4wjxx1q2ZT for ; Mon, 30 Mar 2015 04:13:16 -0700 (PDT) Received: from APAC01-HK1-obe.outbound.protection.outlook.com (mail-hk1on0134.outbound.protection.outlook.com [134.170.140.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C22341A9102 for ; Mon, 30 Mar 2015 04:13:15 -0700 (PDT) Received: from [133.2.210.64] (133.2.210.64) by OS1PR01MB0072.jpnprd01.prod.outlook.com (25.161.230.13) with Microsoft SMTP Server (TLS) id 15.1.125.19; Mon, 30 Mar 2015 11:13:07 +0000 Message-ID: <55192FBC.5070300@it.aoyama.ac.jp> Date: Mon, 30 Mar 2015 20:13:00 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Alexey Melnikov , Barry Leiba References: <20150327163331.20999.30881.idtracker@ietfa.amsl.com> <551806AD.2010409@isode.com> In-Reply-To: <551806AD.2010409@isode.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: OS1PR01CA0018.jpnprd01.prod.outlook.com (25.161.225.156) To OS1PR01MB0072.jpnprd01.prod.outlook.com (25.161.230.13) Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:OS1PR01MB0072; X-Microsoft-Antispam-PRVS: X-Forefront-Antispam-Report: BMV:1; SFV:NSPM; SFS:(10019020)(6049001)(6009001)(24454002)(479174004)(51704005)(42186005)(40100003)(85182001)(54356999)(50986999)(99136001)(87266999)(64126003)(74482002)(76176999)(87976001)(59896002)(80316001)(65816999)(50466002)(2950100001)(23676002)(85202003)(77156002)(230783001)(33656002)(122386002)(86362001)(65956001)(62966003)(92566002)(46102003)(66066001)(65806001)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:OS1PR01MB0072; H:[133.2.210.64]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(5005006)(5002010); SRVR:OS1PR01MB0072; BCL:0; PCL:0; RULEID:; SRVR:OS1PR01MB0072; X-Forefront-PRVS: 05315CBE52 X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Mar 2015 11:13:07.0874 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: OS1PR01MB0072 Archived-At: X-Mailman-Approved-At: Mon, 30 Mar 2015 10:37:36 -0700 Cc: "draft-ietf-appsawg-uri-scheme-reg.all@ietf.org" Subject: Re: [apps-discuss] FW: New Version Notification - draft-ietf-appsawg-uri-scheme-reg-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2015 11:13:21 -0000 On 2015/03/29 23:05, Alexey Melnikov wrote: > 2) Regarding my earlier disagreement about text suggested by Graham: > > 3. Requirements for Permanent Scheme Definitions > > This section gives considerations for new schemes. Meeting these > guidelines is REQUIRED for permanent scheme registration. > Permanent status is appropriate for, but not limited to, > use in standards. For URI schemes defined or normatively > referenced by IETF Standards-Track documents, Permanent registration > status is REQUIRED. > > He added "or normatively referenced" which now appears in the draft. > > Here is a real world example of a problem with this text. SIDR WG > decided to use rsync protocol, they needed to use rsync URIs. rsync URIs > are currently provisional, defined in an Informational RFC. So this > text is basically saying that under the new rule the registration have > to be upgraded to Permanent, allowing the expert reviewer (no disrespect > to Graham or his future replacement) to be a person that blocks > consensus of a WG to use a particular technology. I find this to be > problematic. > > Do people agree that this is problematic? I agree that it would be problematic if the expert reviewer could block. However, my understanding is that IETF consensus (not WG consensus) would be stronger than expert review, and would win in the end if there was really a conflict that couldn't be resolved otherwise. Isn't that the case? My understanding is based on just the general observation that both the Expert Reviewer and IANA (for the registry in question) serve at the pleasure of the IETF and the IESG (in particular, at the pleasure of the AD). Note that 7.2., Registration Procedures, also contains the following: >>>> 6. In the case of a Permanent registration request, the Designated Expert may: * Accept the specification of the scheme for permanent registration. * Suggest provisional registration instead. * Request IETF review and IESG approval; in the meanwhile, suggest provisional registration. * Request additional review or discussion, as necessary. >>>> This essentially says that the expert reviewer only can delay things (by suggesting provisional registration or additional review or discussion), not completely refuse permanent registration. Regards, Martin. From nobody Mon Mar 30 12:33:58 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9ACE1AD0C2 for ; Mon, 30 Mar 2015 12:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1g0zaNdxmrd for ; Mon, 30 Mar 2015 12:33:55 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B9B61A9172 for ; Mon, 30 Mar 2015 12:33:55 -0700 (PDT) Received: from [10.177.240.84] (unknown [63.92.241.249]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id D56E0509BD for ; Mon, 30 Mar 2015 15:33:53 -0400 (EDT) From: Sean Leonard Content-Type: multipart/signed; boundary="Apple-Mail=_5FAA02C1-51CE-481F-8375-DF4D6A8CACD2"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: <99577869-CD48-4EA8-A271-713F7509F540@seantek.com> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Date: Mon, 30 Mar 2015 12:33:13 -0700 References: <55101158.8030105@gmx.de> <0FDC9BB7-6416-4CB8-BBBF-53517CBAEA6B@seantek.com> To: Apps Discuss In-Reply-To: <0FDC9BB7-6416-4CB8-BBBF-53517CBAEA6B@seantek.com> X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [apps-discuss] draft-ietf-appsawg-text-markdown vs Content-Disposition X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2015 19:33:56 -0000 --Apple-Mail=_5FAA02C1-51CE-481F-8375-DF4D6A8CACD2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Mar 23, 2015, at 11:19 AM, Sean Leonard wrote: > Thanks for the comments. >=20 > On Mar 23, 2015, at 8:12 AM, Julian Reschke = wrote: >=20 >> Hi there, >>=20 >> it would be good if the draft stated whether the C-D parameter = "preview-type" is supposed to apply to Content-Disposition in HTTP, and = to clarify, exactly how. >>=20 >> (Note that Content-Disposition in HTTP is defined by RFC 6266, which = the draft currently doesn't even reference) >=20 > [...] >=20 > So do folks want a statement about that and a reference to RFC 6266? I = do not mind including it. To follow up on this: I think that text-markdown and = text-markdown-use-cases are pretty much ready for Last Call, unless = folks want the RFC 6266 or more elaboration. Hopefully we can start that = ball rolling in the next week in order to push them off of the queue. Thanks, Sean= --Apple-Mail=_5FAA02C1-51CE-481F-8375-DF4D6A8CACD2 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ9jCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBT8wggQnoAMCAQICEBpCSs8n+cQbczyWKtueyecwDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTAyMDIwMDAwMDBaFw0xNjAy MDIyMzU5NTlaMCUxIzAhBgkqhkiG9w0BCQEWFGRlditpZXRmQHNlYW50ZWsuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz4n20qAOzUtC1oNz5zgTny0JRBE1mJZszV2s6EurahKP vku7E+utnLhcaNahAWr2oZgeCK9uhEqijaC4qLZHnGt/+lnbsQtjmMJrcFCzhDZjDOJdYzmuS2cU vZqY7YwzCG6jSfs4gwNh+29MS6faY6ucncbnfO9rBB0xu5GIdI3BzsPNYnACNlBYU7w4X4GA0/Mw NAabNhDgxU2Tw1fl5w1Vt+6xRTXBk6V93LyVZN9wBIOpr2MuhoCJLHZrLirv/mbQE5ao4pkJLR/s yYhS1Ko4MSiJmR3ugKPkxEo6DZkuJrfck36hLmtMo3yuzi7hkXmDzPKkdLlNj+Xek1GWtwIDAQAB o4IB8jCCAe4wHwYDVR0jBBgwFoAUkmFrguGioKpP7GfxwqP3tIAAwewwHQYDVR0OBBYEFBpm5d7y 8PBT6NqnIVbfNK8hbpPGMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcG CCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7Bgwr BgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMw XQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBkAYIKwYBBQUHAQEEgYMwgYAw WAYIKwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVudEF1 dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmNvbW9kb2NhLmNvbTAfBgNVHREEGDAWgRRkZXYraWV0ZkBzZWFudGVrLmNvbTANBgkqhkiG9w0B AQsFAAOCAQEAeIf/Nevvv10ssk0unrJb9FC8lJi41sSpq5AFYtmC8IXwUmNxL7L5uE3tGlNJVoTK ZvGeklYWDRCzq6zqte221TowXYmFO7G27rJZbQRjLzQoY63rMlFPFrjqQCEA6rDgo9DlFO9/81P7 ZC7xvZ52WH7e3p/yJNA4Av8E0eeavhC+l+cwtrw0wCp3gUs5xJT0koGVvli2wR18zecG3ib3ml+G nDDv2AH7OhcyhVoj6V9AeGQa2HqaVpOQVRUNPamqr3xeARKk5sUSeBvxlF+0FWhl+AnhqNdxmeEp qpgSvbcS1jbTsqApvgsBcDzjC09wV8mtBoMCtqlHvF3YY2z55jGCA8MwggO/AgEBMIGwMIGbMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBpCSs8n+cQbczyWKtueyecw CQYFKw4DAhoFAKCCAecwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTUwMzMwMTkzMzU2WjAjBgkqhkiG9w0BCQQxFgQUuvXyWhHkvlS5MSuZ2zdycpgZ05YwgcEGCSsG AQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMT OENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhAaQkrPJ/nEG3M8lirbnsnnMIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqGSIb3DQEB AQUABIIBAINzieWLcLVe/qU2F8SZ+2bJ6Y2jx+Gj/pyyzDzEHtT9bQSLCM89D/7MGNpRsj76xx+x vttT3qggKPgYqyCXPSyOj5qt5lNGcghTTdCDpHdLoxiZROEeXMVw+Pon54rVbjV34bi2T+z1J7TU RkWOHqDlq9BlhmTVaUU1/V2Xnk5P4RXZUKLRcOqyldX/hxQAG+HeWb8u69GD3iKGqvrrtiKoiaVu rnt81i/TltsY9TtlZR4XSFXZG1LVRknPJ2AqmgT4828Bz115VLQnQSF8Z61qgq6LeJUv4JkFkpFz vY1PxQL/95B+wACjAlgOi6Au8b/udmaXIhL60r7R6gpxBLIAAAAAAAA= --Apple-Mail=_5FAA02C1-51CE-481F-8375-DF4D6A8CACD2-- From nobody Tue Mar 31 11:10:54 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C94321A897C; Tue, 31 Mar 2015 11:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hcscFeAT50jr; Tue, 31 Mar 2015 11:10:48 -0700 (PDT) Received: from relay12.mail.ox.ac.uk (relay12.mail.ox.ac.uk [129.67.1.163]) by ietfa.amsl.com (Postfix) with ESMTP id CF42F1A8863; Tue, 31 Mar 2015 11:10:44 -0700 (PDT) Received: from smtp6.mail.ox.ac.uk ([163.1.2.206]) by relay12.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1Yd0ca-0004GY-fN; Tue, 31 Mar 2015 19:10:40 +0100 Received: from gklyne.plus.com ([80.229.154.156] helo=cheery.atuin.ninebynine.org) by smtp6.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Yd0ca-0006Vh-L9; Tue, 31 Mar 2015 19:10:40 +0100 Message-ID: <551AE31E.1070009@ninebynine.org> Date: Tue, 31 Mar 2015 19:10:38 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: John C Klensin , Alexey Melnikov , Barry Leiba References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: Cc: draft-ietf-appsawg-uri-scheme-reg.all@ietf.org, iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] FW: New Version Notification - draft-ietf-appsawg-uri-scheme-reg-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 18:10:51 -0000 On 29/03/2015 21:05, John C Klensin wrote: > (reposting -- the IETF mail system apparently didn't like the > "implicit" copy to apps-discuss) > > --On Sunday, March 29, 2015 15:05 +0100 Alexey Melnikov > wrote: > >> On 27/03/2015 19:29, Barry Leiba wrote: >>>> I will send email responses to the feedback received with >>>> what we did. I may not get those out today though. But I >>>> think the doc should be ready for the IESG telechat. >>> Thanks. I've issued the ballot; I'll wait to change the >>> state until I hear that your co-authors & shepherd are OK >>> with it. >> This is almost perfect :-). >> >> A couple of comments: >> ... >> Here is a real world example of a problem with this text. SIDR >> WG decided to use rsync protocol, they needed to use rsync >> URIs. rsync URIs are currently provisional, defined in an >> Informational RFC. So this text is basically saying that >> under the new rule the registration have to be upgraded to >> Permanent, allowing the expert reviewer (no disrespect to >> Graham or his future replacement) to be a person that blocks >> consensus of a WG to use a particular technology. I find this >> to be problematic. >> >> Do people agree that this is problematic? > > Yes. To a point, but I think it should be resolvable (I'm responding without cross-checking the original or revised registration procedure). Under the circumstances that a WG has achieved consensus to use a particular scheme, I think there's sufficient grounds to upgrade its registration to permanent. I think a request to do so should come from the WG concerned (I think that's doable within the current and new spec), and preferably as part of the IANA considerations for the spec that uses it. That would bring the issue to DE's attention with appropriate context. I don't think think this gives the DE any greater power of veto than they already have with respect to a WG consensus request to register a new permanent scheme. #g -- > > At the risk of tossing a spanner toward the works, one more > issue that seems to me very significant: > > Larry Masinter has raised several issues in the URNBIS WG in > which he claims that draft-ietf-appsawg-uri-scheme-reg > constrains what that WG is proposing to do with URNs [1]. I > also believe that some of his comments mix up registration of > schemes (e.g., "urn:") with registrations of URN namespaces and > NIDs I think those issues need to be considered in that WG. > However, procedurally, it seems to me that either: > > (1) Existing registrations are existing registrations and any > updates to them are grandfathered, i.e., whatever > draft-ietf-appsawg-uri-scheme-reg says is not applicable to the > original or updated registration of any URI scheme registered or > deployed before it is approved and published. That obviously > includes the revised URN registration contemplated by > draft-ietf-urnbis-rfc2141bis-urn. > > (2) We have a mess on our hands in which not only do the > mandates of different WGs overlap but in which an area WG that > is not noted for very intense reviews can constrain and override > the work of more topic-focused (and, therefore, presumably more > expert on their own topics) WGs and other efforts. This is > particularly problematic in the case of URIs, where parallel > (and not entirely consistent) work is going on to further > develop specific URI schemes (URNs being only one such example) > and groups outside the IETF (including WHATWG and W3C groups) > with coordination processes that are still being negotiated and > in groups that are heavily dependent on URIs and URI handling > (certainly including HTTPbis). > > If it is applicable to existing registrations and ongoing work > in other WGs, this spec is even more problematic because it is > heavily dependent on details of RFC 3986, a specification whose > exact meaning, implications, and consequences continue to be > debated and which is a candidate for preemption or replacement > by those other bodies. > > I suggest that any IESG action on > draft-ietf-appsawg-uri-scheme-reg be deferred until which of the > above principles applies can be clarified (and clarified in the > document) and, if the second option is chosen, that formal > reviews and impact assessments be sought from all active WGs > that are involved with or use URIs as well as from W3C. > > Sorry to be raising this so late in the process, but it never > occurred to me that anyone would claim that > draft-ietf-appsawg-uri-scheme-reg constrained other IETF WGs, > standards-track updates to existing registrations that were made > as the result of standards actions, etc. Since that claim has > now been made, and made by one of the authors of the new draft > who presumably understands the intent, a "wait a minute" > response seems necessary. > > john > > > [1] > http://www.ietf.org/mail-archive/web/urn/current/msg02873.html > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From nobody Tue Mar 31 11:10:55 2015 Return-Path: X-Original-To: expand-draft-ietf-appsawg-uri-scheme-reg.all@virtual.ietf.org Delivered-To: apps-discuss@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id ECAD91A8989; Tue, 31 Mar 2015 11:10:50 -0700 (PDT) X-Original-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C94321A897C; Tue, 31 Mar 2015 11:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hcscFeAT50jr; Tue, 31 Mar 2015 11:10:48 -0700 (PDT) Received: from relay12.mail.ox.ac.uk (relay12.mail.ox.ac.uk [129.67.1.163]) by ietfa.amsl.com (Postfix) with ESMTP id CF42F1A8863; Tue, 31 Mar 2015 11:10:44 -0700 (PDT) Received: from smtp6.mail.ox.ac.uk ([163.1.2.206]) by relay12.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1Yd0ca-0004GY-fN; Tue, 31 Mar 2015 19:10:40 +0100 Received: from gklyne.plus.com ([80.229.154.156] helo=cheery.atuin.ninebynine.org) by smtp6.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Yd0ca-0006Vh-L9; Tue, 31 Mar 2015 19:10:40 +0100 Message-ID: <551AE31E.1070009@ninebynine.org> Date: Tue, 31 Mar 2015 19:10:38 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: John C Klensin , Alexey Melnikov , Barry Leiba References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: Cc: draft-ietf-appsawg-uri-scheme-reg.all@ietf.org, iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] FW: New Version Notification - draft-ietf-appsawg-uri-scheme-reg-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 18:10:51 -0000 On 29/03/2015 21:05, John C Klensin wrote: > (reposting -- the IETF mail system apparently didn't like the > "implicit" copy to apps-discuss) > > --On Sunday, March 29, 2015 15:05 +0100 Alexey Melnikov > wrote: > >> On 27/03/2015 19:29, Barry Leiba wrote: >>>> I will send email responses to the feedback received with >>>> what we did. I may not get those out today though. But I >>>> think the doc should be ready for the IESG telechat. >>> Thanks. I've issued the ballot; I'll wait to change the >>> state until I hear that your co-authors & shepherd are OK >>> with it. >> This is almost perfect :-). >> >> A couple of comments: >> ... >> Here is a real world example of a problem with this text. SIDR >> WG decided to use rsync protocol, they needed to use rsync >> URIs. rsync URIs are currently provisional, defined in an >> Informational RFC. So this text is basically saying that >> under the new rule the registration have to be upgraded to >> Permanent, allowing the expert reviewer (no disrespect to >> Graham or his future replacement) to be a person that blocks >> consensus of a WG to use a particular technology. I find this >> to be problematic. >> >> Do people agree that this is problematic? > > Yes. To a point, but I think it should be resolvable (I'm responding without cross-checking the original or revised registration procedure). Under the circumstances that a WG has achieved consensus to use a particular scheme, I think there's sufficient grounds to upgrade its registration to permanent. I think a request to do so should come from the WG concerned (I think that's doable within the current and new spec), and preferably as part of the IANA considerations for the spec that uses it. That would bring the issue to DE's attention with appropriate context. I don't think think this gives the DE any greater power of veto than they already have with respect to a WG consensus request to register a new permanent scheme. #g -- > > At the risk of tossing a spanner toward the works, one more > issue that seems to me very significant: > > Larry Masinter has raised several issues in the URNBIS WG in > which he claims that draft-ietf-appsawg-uri-scheme-reg > constrains what that WG is proposing to do with URNs [1]. I > also believe that some of his comments mix up registration of > schemes (e.g., "urn:") with registrations of URN namespaces and > NIDs I think those issues need to be considered in that WG. > However, procedurally, it seems to me that either: > > (1) Existing registrations are existing registrations and any > updates to them are grandfathered, i.e., whatever > draft-ietf-appsawg-uri-scheme-reg says is not applicable to the > original or updated registration of any URI scheme registered or > deployed before it is approved and published. That obviously > includes the revised URN registration contemplated by > draft-ietf-urnbis-rfc2141bis-urn. > > (2) We have a mess on our hands in which not only do the > mandates of different WGs overlap but in which an area WG that > is not noted for very intense reviews can constrain and override > the work of more topic-focused (and, therefore, presumably more > expert on their own topics) WGs and other efforts. This is > particularly problematic in the case of URIs, where parallel > (and not entirely consistent) work is going on to further > develop specific URI schemes (URNs being only one such example) > and groups outside the IETF (including WHATWG and W3C groups) > with coordination processes that are still being negotiated and > in groups that are heavily dependent on URIs and URI handling > (certainly including HTTPbis). > > If it is applicable to existing registrations and ongoing work > in other WGs, this spec is even more problematic because it is > heavily dependent on details of RFC 3986, a specification whose > exact meaning, implications, and consequences continue to be > debated and which is a candidate for preemption or replacement > by those other bodies. > > I suggest that any IESG action on > draft-ietf-appsawg-uri-scheme-reg be deferred until which of the > above principles applies can be clarified (and clarified in the > document) and, if the second option is chosen, that formal > reviews and impact assessments be sought from all active WGs > that are involved with or use URIs as well as from W3C. > > Sorry to be raising this so late in the process, but it never > occurred to me that anyone would claim that > draft-ietf-appsawg-uri-scheme-reg constrained other IETF WGs, > standards-track updates to existing registrations that were made > as the result of standards actions, etc. Since that claim has > now been made, and made by one of the authors of the new draft > who presumably understands the intent, a "wait a minute" > response seems necessary. > > john > > > [1] > http://www.ietf.org/mail-archive/web/urn/current/msg02873.html > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From nobody Tue Mar 31 18:32:49 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A7E51A1AFF; Tue, 31 Mar 2015 18:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HcEPR3JzupDx; Tue, 31 Mar 2015 18:32:46 -0700 (PDT) Received: from waldorf.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id CE6751A1AF0; Tue, 31 Mar 2015 18:32:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1427851962; d=isode.com; s=selector; i=@isode.com; bh=z6nPIxDmqzRgGnoZe8I8Tgdyr0QOSdQSxiSvuofVQm8=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=nAIotdsLtRGhxp0iEpAr4xqK9bK/TUw5bFI6Jr0QA/t665L+fynGFDGIuHcQC5dhn9BRTK oOR0pINwUeCJQMjmDOolsIrxJNMPQ+0Lb5/LK0MOg3FjFUq+7cQubp1tiJNUUTocUwA5ER SMpThHyFdNon+yPeMlSdd/wD60/to10=; Received: from [192.168.86.29] ((unknown) [198.170.185.222]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 1 Apr 2015 02:32:42 +0100 X-SMTP-Protocol-Errors: NORDNS PIPELINING From: Alexey Melnikov X-Mailer: iPad Mail (12B435) In-Reply-To: <551AE31E.1070009@ninebynine.org> Date: Wed, 1 Apr 2015 02:40:25 +0100 Message-Id: <306B3AB5-02E3-4958-9D05-4E4FF82AD114@isode.com> References: <551AE31E.1070009@ninebynine.org> To: Graham Klyne , "draft-ietf-appsawg-uri-scheme-reg.all@ietf.org" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Barry Leiba , "iesg@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] FW: New Version Notification - draft-ietf-appsawg-uri-scheme-reg-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 01:32:47 -0000 Hi, > On 31 Mar 2015, at 19:10, Graham Klyne wrote: >=20 >> On 29/03/2015 21:05, John C Klensin wrote: >> (reposting -- the IETF mail system apparently didn't like the >> "implicit" copy to apps-discuss) >>=20 >> --On Sunday, March 29, 2015 15:05 +0100 Alexey Melnikov >> wrote: >>=20 >>> On 27/03/2015 19:29, Barry Leiba wrote: >>>>> I will send email responses to the feedback received with >>>>> what we did. I may not get those out today though. But I >>>>> think the doc should be ready for the IESG telechat. >>>> Thanks. I've issued the ballot; I'll wait to change the >>>> state until I hear that your co-authors & shepherd are OK >>>> with it. >>> This is almost perfect :-). >>>=20 >>> A couple of comments: >>> ... >>> Here is a real world example of a problem with this text. SIDR >>> WG decided to use rsync protocol, they needed to use rsync >>> URIs. rsync URIs are currently provisional, defined in an >>> Informational RFC. So this text is basically saying that >>> under the new rule the registration have to be upgraded to >>> Permanent, allowing the expert reviewer (no disrespect to >>> Graham or his future replacement) to be a person that blocks >>> consensus of a WG to use a particular technology. I find this >>> to be problematic. >>>=20 >>> Do people agree that this is problematic? >>=20 >> Yes. >=20 > To a point, but I think it should be resolvable (I'm responding without cr= oss-checking the original or revised registration procedure). >=20 > Under the circumstances that a WG has achieved consensus to use a particul= ar scheme, I think there's sufficient grounds to upgrade its registration to= permanent. I think a request to do so should come from the WG concerned (I= think that's doable within the current and new spec), and preferably as par= t of the IANA considerations for the spec that uses it. That would bring th= e issue to DE's attention with appropriate context. >=20 > I don't think think this gives the DE any greater power of veto than they a= lready have with respect to a WG consensus request to register a new permane= nt scheme. I would think slightly more comfortable if the document has a paragraph disc= ussing the above (pretty much using what you said). But if others don't think this is an issue, I will let it go. From nobody Tue Mar 31 18:32:55 2015 Return-Path: X-Original-To: expand-draft-ietf-appsawg-uri-scheme-reg.all@virtual.ietf.org Delivered-To: apps-discuss@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id BEB991A1B28; Tue, 31 Mar 2015 18:32:47 -0700 (PDT) X-Original-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A7E51A1AFF; Tue, 31 Mar 2015 18:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HcEPR3JzupDx; Tue, 31 Mar 2015 18:32:46 -0700 (PDT) Received: from waldorf.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id CE6751A1AF0; Tue, 31 Mar 2015 18:32:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1427851962; d=isode.com; s=selector; i=@isode.com; bh=z6nPIxDmqzRgGnoZe8I8Tgdyr0QOSdQSxiSvuofVQm8=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=nAIotdsLtRGhxp0iEpAr4xqK9bK/TUw5bFI6Jr0QA/t665L+fynGFDGIuHcQC5dhn9BRTK oOR0pINwUeCJQMjmDOolsIrxJNMPQ+0Lb5/LK0MOg3FjFUq+7cQubp1tiJNUUTocUwA5ER SMpThHyFdNon+yPeMlSdd/wD60/to10=; Received: from [192.168.86.29] ((unknown) [198.170.185.222]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 1 Apr 2015 02:32:42 +0100 X-SMTP-Protocol-Errors: NORDNS PIPELINING From: Alexey Melnikov X-Mailer: iPad Mail (12B435) In-Reply-To: <551AE31E.1070009@ninebynine.org> Date: Wed, 1 Apr 2015 02:40:25 +0100 Message-Id: <306B3AB5-02E3-4958-9D05-4E4FF82AD114@isode.com> References: <551AE31E.1070009@ninebynine.org> To: Graham Klyne , "draft-ietf-appsawg-uri-scheme-reg.all@ietf.org" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Barry Leiba , "iesg@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] FW: New Version Notification - draft-ietf-appsawg-uri-scheme-reg-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 01:32:47 -0000 Hi, > On 31 Mar 2015, at 19:10, Graham Klyne wrote: >=20 >> On 29/03/2015 21:05, John C Klensin wrote: >> (reposting -- the IETF mail system apparently didn't like the >> "implicit" copy to apps-discuss) >>=20 >> --On Sunday, March 29, 2015 15:05 +0100 Alexey Melnikov >> wrote: >>=20 >>> On 27/03/2015 19:29, Barry Leiba wrote: >>>>> I will send email responses to the feedback received with >>>>> what we did. I may not get those out today though. But I >>>>> think the doc should be ready for the IESG telechat. >>>> Thanks. I've issued the ballot; I'll wait to change the >>>> state until I hear that your co-authors & shepherd are OK >>>> with it. >>> This is almost perfect :-). >>>=20 >>> A couple of comments: >>> ... >>> Here is a real world example of a problem with this text. SIDR >>> WG decided to use rsync protocol, they needed to use rsync >>> URIs. rsync URIs are currently provisional, defined in an >>> Informational RFC. So this text is basically saying that >>> under the new rule the registration have to be upgraded to >>> Permanent, allowing the expert reviewer (no disrespect to >>> Graham or his future replacement) to be a person that blocks >>> consensus of a WG to use a particular technology. I find this >>> to be problematic. >>>=20 >>> Do people agree that this is problematic? >>=20 >> Yes. >=20 > To a point, but I think it should be resolvable (I'm responding without cr= oss-checking the original or revised registration procedure). >=20 > Under the circumstances that a WG has achieved consensus to use a particul= ar scheme, I think there's sufficient grounds to upgrade its registration to= permanent. I think a request to do so should come from the WG concerned (I= think that's doable within the current and new spec), and preferably as par= t of the IANA considerations for the spec that uses it. That would bring th= e issue to DE's attention with appropriate context. >=20 > I don't think think this gives the DE any greater power of veto than they a= lready have with respect to a WG consensus request to register a new permane= nt scheme. I would think slightly more comfortable if the document has a paragraph disc= ussing the above (pretty much using what you said). But if others don't think this is an issue, I will let it go.