From ietfc@btconnect.com Wed Feb 1 02:02:06 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF88121F8633 for ; Wed, 1 Feb 2012 02:02:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.629 X-Spam-Level: X-Spam-Status: No, score=-0.629 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_20=-0.74] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7HR1pSt9Yq-D for ; Wed, 1 Feb 2012 02:02:06 -0800 (PST) Received: from mail.btconnect.com (c2bthomr10.btconnect.com [213.123.20.128]) by ietfa.amsl.com (Postfix) with ESMTP id DCA5A21F862A for ; Wed, 1 Feb 2012 02:02:05 -0800 (PST) Received: from host86-163-138-100.range86-163.btcentralplus.com (HELO pc6) ([86.163.138.100]) by c2bthomr10.btconnect.com with SMTP id GDH71317; Wed, 01 Feb 2012 10:01:35 +0000 (GMT) Message-ID: <009101cce0c0$23d36160$4001a8c0@gateway.2wire.net> From: "t.petch" To: , "Peter Saint-Andre" References: <4EE2430E.4080501@isode.com> <4F1F1A72.1090302@isode.com><6068EE9E-D120-4CE9-8096-C296C169C7DE@vpnc.org><4F22EE3A.9010801@stpeter.im> <4F22EF8B.9000509@dcrocker.net><4F22EFCF.3050607@stpeter.im> <4F22F08D.4060902@stpeter.im> <4F22FF9F.5040304@dcrocker.net> Date: Wed, 1 Feb 2012 10:01:44 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0302.4F290D7D.00AF, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2012.1.30.73017:17:7.944, ip=86.163.138.100, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __TO_NO_NAME, __MULTIPLE_RCPTS_CC_X2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __URI_NO_WWW, __URI_NO_PATH, __CP_NOT_1, BODYTEXTP_SIZE_3000_LESS, BODY_SIZE_1600_1699, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, MULTIPLE_RCPTS, RDNS_SUSP, BODY_SIZE_2000_LESS, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2bthomr10.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0204.4F290D80.00A8,ss=1,re=0.000,fgs=0, ip=0.0.0.0, so=2011-07-25 19:15:43, dmn=2011-05-27 18:58:46, mode=multiengine X-Junkmail-IWF: false Cc: Paul Hoffman , apps-discuss Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-xdash-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 10:02:06 -0000 ----- Original Message ----- From: "Dave CROCKER" To: "Peter Saint-Andre" Cc: "Paul Hoffman" ; Sent: Friday, January 27, 2012 8:48 PM > On 1/27/2012 10:44 AM, Peter Saint-Andre wrote: > >> The specification only cover parameter names, not numbers. > >> Brevity is good. > Usually. As long as it is right. My number parameters have text names; my textual parameters have text names. I think that 'the specification only cover textual parameter, not numeric one'. Aliter, 'Note that this document only discusses parameters expressed in text; it does not discuss parameters that are expressed with numbers.' modifying Paul's original proposal slightly. Arguably, the first sentence of the Introduction has the same problem with its reference to 'named parameters' as opposed to 'parameters expressed in text'. But like Paul, I think that that is worth explicitly stating in this I-D, because when I get to Appendix B, it says ' [BCP82] is entitled "Assigning Experimental and Testing Numbers Considered Useful" and therefore implies that the "X-" prefix is also useful for experimental parameters. ' Well, if this is about textual parameters, then BCP82 is irrelevant, its title clearly states its scope and reading and re-reading it, I see nothing in it about text or characters, every reference is to number(s) and so I see nothing that has implications for X-. Reading Appendix B might well muddy the waters as to the scope of this I-D which is why I would like that sentence above added. Tom Petch > d/ From ietfc@btconnect.com Wed Feb 1 03:03:00 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09F0C21F86AD for ; Wed, 1 Feb 2012 03:03:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.064 X-Spam-Level: X-Spam-Status: No, score=-1.064 tagged_above=-999 required=5 tests=[AWL=0.501, BAYES_00=-2.599, HTTP_ESCAPED_HOST=0.134, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jV-538jDammP for ; Wed, 1 Feb 2012 03:02:59 -0800 (PST) Received: from mail.btconnect.com (c2bthomr13.btconnect.com [213.123.20.131]) by ietfa.amsl.com (Postfix) with ESMTP id 1D9BF21F85CD for ; Wed, 1 Feb 2012 03:02:41 -0800 (PST) Received: from host86-163-138-100.range86-163.btcentralplus.com (HELO pc6) ([86.163.138.100]) by c2bthomr13.btconnect.com with SMTP id GCC23450; Wed, 01 Feb 2012 11:02:29 +0000 (GMT) Message-ID: <00ad01cce0c8$a5b22ba0$4001a8c0@gateway.2wire.net> From: "t.petch" To: "=?utf-8?Q?Martin_J._D=C3=BCrst?=" References: <4EB86078.8070904@stpeter.im><4EB8D0F4.9020907@it.aoyama.ac.jp><555BA718-A5FA-4111-9A8B-1DE99921CCE2@standardstrack.com><60D34A5D-985C-4C97-A4FA-3CBF5CD31FCF@mnot.net><4EB9D49C.5010100@it.aoyama.ac.jp> <4EBB2FEA.5060602@dcrocker.net><4EBB50F4.7020501@it.aoyama.ac.jp> <4EBB54E0.9090005@dcrocker.net><00bb01cc9f87$ff24b9a0$4001a8c0@gateway.2wire.net><02de01cc9fca$f7c08020$4001a8c0@gateway.2wire.net><4EBCD919.9050600@it.aoyama.ac.jp> <00ac01cca378$0680a940$4001a8c0@gateway.2wire.net> Date: Wed, 1 Feb 2012 11:02:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4F291BC2.0074, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2012.1.30.73017:17:7.944, ip=86.163.138.100, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __MULTIPLE_RCPTS_CC_X2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __FRAUD_BODY_WEBMAIL, ECARD_KNOWN_DOMAINS, __CP_URI_IN_BODY, __STOCK_PHRASE_7, __INT_PROD_LOC, BODY_SIZE_3000_3999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, MULTIPLE_RCPTS, RDNS_SUSP, __FRAUD_WEBMAIL, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2bthomr13.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020A.4F291BC5.0227,ss=1,re=0.000,fgs=0, ip=0.0.0.0, so=2011-07-25 19:15:43, dmn=2011-05-27 18:58:46, mode=multiengine X-Junkmail-IWF: false Cc: dcrocker@bbiw.net, apps-discuss@ietf.org Subject: Re: [apps-discuss] font/* X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Feb 2012 11:03:00 -0000 Martin I do not know if missing fonts are still of interest to you but if so, see inline Tom Petch ----- Original Message ----- From: "t.petch" To: "Martin J. Dürst" Cc: ; Sent: Tuesday, November 15, 2011 10:18 AM Subject: Re: [apps-discuss] font/* > ----- Original Message ----- > From: "Martin J. Dürst" > To: "t.petch" > Cc: "Frank Ellermann" ; > ; > Sent: Friday, November 11, 2011 9:13 AM > > On 2011/11/11 2:05, t.petch wrote: > > > > > What I see at present is that when I access certain web sites, I get a > message > > > saying the my machine has not got the fonts installed to view the web site > > > properly and would I like the web site to instal some more for me. NO WAY. > I > > > decide what and when I instal on my machine from where. But I am curious, > and > > > might try it when I have machine ready to be trashed, as to just how it > would do > > > it. I am assuming it would try to instal a .ttf file in a suitable > directory > > > (which I would expect to fail unless it is a temporary file). > > > > > > I did ask the maintainers of the web site what was going on, and they had > not a > > > clue. My guess would be something Chinese or Korean (although the web site > is > > > not). > > > > To look at this case, it would help if you would tell us what your > > browser was, and what websites they were. I now see this message, that fonts need to be installed, on http://www.google.com/policies/ and http://www.google.com/policies/terms/ and http://www.google.com/policies/privacy/preview/ I do not see it on http://www.google.co.uk/ (which is where I am redirected to when I type in http://www.google.com/ nor have I seen it on any other website since my last post on this subject. Tom Petch > Indeed, I intend to do so, but the most recent example, when accessing > https://catalogue.library.manchester.ac.uk/login?message=borrowerservices_notlog > gedin&referer=https%3A%2F%2Fcatalogue.library.manchester.ac.uk%2Faccount > only occurs once I have entered my userid and password, and you > may not be surprised to learn that I do not intend to disclose that > information by e-mail. > > My memory is that I have seen it on other pages on that host and will > continue to look for one and post it as and when I find it. > > My browser is Internet Explorer 6.0 but I suspect that it is the Fonts > directory in Windows that is lacking either a 'font' or more likely, some > code points in a font (I do get displays of Russian and CJK characters > which I did not on older software). One thing I link to this is the > display I get on the Subject: line of some e-mails, on lists such as > MPLS-TP, from users with a Chinese affiliation, where the line > displays with many underscores, whereas at an Internet cafe, > looking at the archives, as one does, I get CJK characters instead, > probably a language variant of 'Re: '. > My MUA does not generate messages about wanting to download > 'fonts'. > > Tom Petch > > > Regards, Martin. > > > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From internet-drafts@ietf.org Wed Feb 1 06:42:48 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4338A11E83AE; Wed, 1 Feb 2012 06:42:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.591 X-Spam-Level: X-Spam-Status: No, score=-102.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z213Y9v71Nid; Wed, 1 Feb 2012 06:42:47 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6514C11E832D; Wed, 1 Feb 2012 06:42:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120201144227.15671.45463.idtracker@ietfa.amsl.com> Date: Wed, 01 Feb 2012 06:42:27 -0800 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-mime-default-charset-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 14:42:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Worki= ng Group of the IETF. Title : Update to MIME regarding Charset Parameter Handling in T= extual Media Types Author(s) : Alexey Melnikov Julian F. Reschke Filename : draft-ietf-appsawg-mime-default-charset-00.txt Pages : 6 Date : 2012-02-01 This document changes RFC 2046 rules regarding default charset parameter values for text/* media types to better align with common usage by existing clients and servers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-appsawg-mime-default-charset= -00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-appsawg-mime-default-charset-= 00.txt From julian.reschke@gmx.de Wed Feb 1 06:56:59 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86D2411E8076 for ; Wed, 1 Feb 2012 06:56:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.336 X-Spam-Level: X-Spam-Status: No, score=-104.336 tagged_above=-999 required=5 tests=[AWL=-1.737, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SKmt+zoLSoMy for ; Wed, 1 Feb 2012 06:56:59 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id D9EDB11E8071 for ; Wed, 1 Feb 2012 06:56:58 -0800 (PST) Received: (qmail invoked by alias); 01 Feb 2012 14:50:18 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp032) with SMTP; 01 Feb 2012 15:50:18 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19X1Ow8kWJXmOs7jyqqteYzC8MSGUnGCyPx4DCExq ccpvB+jjUOxVjW Message-ID: <4F295127.90909@gmx.de> Date: Wed, 01 Feb 2012 15:50:15 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: internet-drafts@ietf.org References: <20120201144227.15671.45463.idtracker@ietfa.amsl.com> In-Reply-To: <20120201144227.15671.45463.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: apps-discuss@ietf.org, i-d-announce@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-mime-default-charset-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 14:56:59 -0000 On 2012-02-01 15:42, 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 : Update to MIME regarding Charset Parameter Handling in Textual Media Types > Author(s) : Alexey Melnikov > Julian F. Reschke > Filename : draft-ietf-appsawg-mime-default-charset-00.txt > Pages : 6 > Date : 2012-02-01 > > This document changes RFC 2046 rules regarding default charset > parameter values for text/* media types to better align with common > usage by existing clients and servers. > ... (HTML version at: ) Best regards, Julian From yoshiro.yoneya@jprs.co.jp Thu Feb 2 01:23:25 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F9FC21F8A27; Thu, 2 Feb 2012 01:23:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LMemeuOLD+aS; Thu, 2 Feb 2012 01:23:24 -0800 (PST) Received: from off-send01.tyo.jprs.co.jp (off-send01.tyo.jprs.co.jp [IPv6:2001:df0:8:17::10]) by ietfa.amsl.com (Postfix) with ESMTP id 5E26F21F899D; Thu, 2 Feb 2012 01:23:24 -0800 (PST) Received: from off-sendsmg01.tyo.jprs.co.jp (off-sendsmg01.tyo.jprs.co.jp [172.18.8.32]) by off-send01.tyo.jprs.co.jp (8.13.8/8.13.8) with ESMTP id q129NLjT017534; Thu, 2 Feb 2012 18:23:22 +0900 X-AuditID: ac120820-b7f2a6d0000076cf-9e-4f2a5609f60e Received: from NOTE550 (off-cpu04.tyo.jprs.co.jp [172.18.4.14]) by off-sendsmg01.tyo.jprs.co.jp (Symantec Messaging Gateway) with SMTP id 05.B1.30415.9065A2F4; Thu, 2 Feb 2012 18:23:21 +0900 (JST) Date: Thu, 2 Feb 2012 18:23:20 +0900 From: Yoshiro YONEYA To: apps-discuss@ietf.org, draft-harkins-ipsecme-spsk-auth.all@tools.ietf.org Message-Id: <20120202182320.165d81f8.yoshiro.yoneya@jprs.co.jp> X-Mailer: Sylpheed 3.1.2 (GTK+ 2.10.14; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFIsWRmVeSWpSXmKPExsWyRoiFT5czTMvfoH+uiMXqlyvYLHbNXMZu MePPRGaLrrbNLA4sHkuW/GTy+Hv/HavHl8uf2QKYo7hsUlJzMstSi/TtErgy/ky/ylowibNi 0rZ1TA2MS9i7GDk5JARMJJ51TGOBsMUkLtxbz9bFyMUhJHCcUWLe7Q5WkASLgIrEnv4VjCA2 m4CBxK9lv5lAbBEBf4k/FyexgdjMAoISTe9fgQ0SFrCVeLnpEFgNr4C9xO4P/4HmcAAtsJDY us4SxOQFKv+7QxiiU0vi4a9bLBC2vMT2t3OYJzDyzkKomoWkahaSqgWMzKsYZfLT0nSLU/NS inPTDQz1Sirz9bIKior1kkH0JkZw0HEo7GCcccrgEKMAB6MSD+/vw5r+QqyJZcWVuYcYJTmY lER514Ro+QvxJeWnVGYkFmfEF5XmpBYfYpTgYFYS4U10AsrxpiRWVqUW5cOkpDlYlMR5j5/d 4SckkJ5YkpqdmlqQWgSTleHgUJLgrQ0FahQsSk1PrUjLzClBSDNxcIIM5wEang9Sw1tckJhb nJkOkT/FKCklzpsAkhAASWSU5sH1vmIUB3pBmDcIJMsDTCBwXa+ABjIBDWSw0AQZWJKIkJJq YBTpLfqm9P1a5n5pyZYV0n8E9epnfZG06q6aaitgO+Xd8wKGw+rLttdq5nK6ijZlNK07tj7k 7B2ezrrmxe9zjgQ11hhoPhXweT5p/oKfB3uNXZYwmktlx99gjWT0+NgbtHF/l7ju3afxn/Z/ 9lJY5XZ06ufwS//fed/bnZLmv5+H8zrrVWXVeiWW4oxEQy3mouJEAJxFFF/dAgAA Cc: iesg@ietf.org Subject: [apps-discuss] APPSDIR review of draft-harkins-ipsecme-spsk-auth-06 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 09:23:25 -0000 I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-harkins-ipsecme-spsk-auth-06 Title: Secure PSK Authentication for IKE Reviewer: Yoshiro Yoneya Review Date: 2012-02-02 IETF Last Call Date: 2012-02-14 IESG Telechat Date: 2012-03-15 Summary: This draft is almost ready for publication as an Experimental RFC but has a few nits that should be fixed before publication. Major Issues: Minor Issues: Nits: - Section 4.2 Two elementx, X and Y, --> Two element, X and Y, - Section 7 [RFC5996]) --> [RFC5996] - Section 8.2.2 ske-value = prf+(swd-seed, "IKE SKE Hunting And Pecking") --> ske-value = prf+(ske-seed, "IKE SKE Hunting And Pecking") - Section 8.5.1 [RFC6467]) --> [RFC6467] Regards, -- Yoshiro YONEYA From julian.reschke@gmx.de Thu Feb 2 05:26:41 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E835A21F8868 for ; Thu, 2 Feb 2012 05:26:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.03 X-Spam-Level: X-Spam-Status: No, score=-104.03 tagged_above=-999 required=5 tests=[AWL=-1.431, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGoWE0BMlhu9 for ; Thu, 2 Feb 2012 05:26:41 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id E8A9621F886F for ; Thu, 2 Feb 2012 05:26:40 -0800 (PST) Received: (qmail invoked by alias); 02 Feb 2012 13:26:39 -0000 Received: from p3EE278DD.dip.t-dialin.net (EHLO [192.168.178.36]) [62.226.120.221] by mail.gmx.net (mp032) with SMTP; 02 Feb 2012 14:26:39 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX199d/8UelF9O9xfY+7DhbQv1mwXA+zsfqczBQPs7B 5THcCjdhp2u1eI Message-ID: <4F2A8F09.9000401@gmx.de> Date: Thu, 02 Feb 2012 14:26:33 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: SM References: <4F2567DA.3060608@gmx.de> <4F25693C.1050701@gmx.de> <6.2.5.6.2.20120129082227.0630b9c0@resistor.net> In-Reply-To: <6.2.5.6.2.20120129082227.0630b9c0@resistor.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Fwd: Informal Last Call for draft-reschke-basicauth-enc-04, was: Fwd: I-D Action: draft-reschke-basicauth-enc-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 13:26:42 -0000 On 2012-01-29 17:42, SM wrote: > Hi Julian, > At 07:43 29-01-2012, Julian Reschke wrote: >> At this point, I'd like to solicit additional feedback before I proceed; >> in particular: should this potentially be an Applications Area WG >> deliverable? > > I'll volunteer to review the draft. > >> With respect to intended status: in theory, this is a candidate for >> Experimental. However, Basic Authentication (as defined in RFC 2617) >> doesn't have a registry for extension parameters, so the cleanest >> approach appears to say "Updates 2617", which IMHO requires a standards >> track document. > > I'd say go to Proposed Standard. BTW, the "Updates 2617" does not > require a standard track document. Interesting. The rule I found is: Updates Specifies an earlier document whose contents are modified or augmented by the new document. The new document cannot be used alone, it can only be used in conjunction with the earlier document. (, Section 2.11 (*)) ...which supports what you said. It would be interesting to find out whether this proves to be correct in practice, which would be a reason to switch to "Experimental" :-). Best regards, Julian From sm@elandsys.com Thu Feb 2 11:00:13 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8D8D21F8585 for ; Thu, 2 Feb 2012 11:00:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ydvTveMQkWwA for ; Thu, 2 Feb 2012 11:00:13 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id F367F21F84EF for ; Thu, 2 Feb 2012 11:00:12 -0800 (PST) Received: from sm-THINK.elandsys.com (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q12J09Qv012077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 2 Feb 2012 11:00:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1328209211; i=@elandsys.com; bh=b92VUQwoDCyhZeV561xi3T0lMeUAtjudVIJf7sgIv80=; h=Message-Id:Date:To:From:Subject:Mime-Version:Content-Type:Cc; b=WDyJZDjBAt/aiapiZT9SyHfND7mZVLheLx8E4MLuDzitrT+298eoCzQcEO45wjsPc cfMoD1cR1cAer4QX38oefB11uVM7npu9Wp3T4tA1hUSDfpi5k6fNu6yBuaVgnbhwdr kNHJ+qtoXWm5kjxrf5kMmG9PaUM+eK3ZBYqXQ8KY= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1328209211; i=@elandsys.com; bh=b92VUQwoDCyhZeV561xi3T0lMeUAtjudVIJf7sgIv80=; h=Message-Id:Date:To:From:Subject:Mime-Version:Content-Type:Cc; b=INzwEALi/GSK/DbKZvK6axV9WRLdK1XBJZLnRsTVeEIJ95Gm7O9yuaUxmGSwBZ6iC BAgUaooo5HVqQni2t8dGcWs2hwi00zZavVwF2BjVxWd8wXXshmfwo7B/xQDtOQG4M+ b9CsiC+QRCYZSHqbD8IOAFhjGTEmekkfoAixa5lE= Message-Id: <6.2.5.6.2.20120202104110.04a21a80@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 02 Feb 2012 10:57:52 -0800 To: apps-discuss@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [apps-discuss] Apps Area Directorate Report for January 2012 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 19:00:13 -0000 Hello, The Applications Area Directorate provides semi-formal reviews of Internet-Drafts as a way to improve the quality of IETF specifications. The directorate consists of the Working Group Chairs of the Applications Area and recognized experts in the Applications Area. The following reviews were performed in January 2012: Reviewer I-D Glenn Parsons draft-melnikov-smtp-priority-04 S. Moonesamy draft-ietf-v6ops-ipv6-discard-prefix-02 Murray S. Kucherawy draft-ietf-dnsext-xnamercode-00 Alexey Melnikov draft-kucherawy-authres-spf-erratum-01 Claudio Allocchio draft-ietf-sipclf-format-05 Salvatore Loreto draft-ietf-avtcore-srtp-vbr-audio-04 Barry Leiba draft-ietf-dane-protocol-14 Carsten Bormann draft-ietf-decade-arch-04 Tim Bray draft-ietf-oauth-v2-threatmodel-01 Jiankang Yao draft-ietf-dhc-dhcpv6-redundancy-consider-02 Lisa Dusseault draft-ietf-sidr-rpki-rtr-25 Pending reviews are listed at http://trac.tools.ietf.org/area/app/trac/report/1 Regards, S. Moonesamy On behalf of the Applications Area Directorate http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate From internet-drafts@ietf.org Fri Feb 3 16:14:21 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 803F821F862A; Fri, 3 Feb 2012 16:14:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.591 X-Spam-Level: X-Spam-Status: No, score=-102.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NP8+yRtjG8ZX; Fri, 3 Feb 2012 16:14:21 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B24E21F8534; Fri, 3 Feb 2012 16:14:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120204001408.16716.94710.idtracker@ietfa.amsl.com> Date: Fri, 03 Feb 2012 16:14:08 -0800 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-media-type-regs-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2012 00:14:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Worki= ng Group of the IETF. Title : Media Type Specifications and Registration Procedures Author(s) : Ned Freed John C. Klensin Tony Hansen Filename : draft-ietf-appsawg-media-type-regs-00.txt Pages : 29 Date : 2012-02-03 This document defines procedures for the specification and registration of media types for use in HTTP, MIME and other Internet protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-appsawg-media-type-regs-00.t= xt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-appsawg-media-type-regs-00.txt From evnikita2@gmail.com Fri Feb 3 21:38:48 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3DE411E8080 for ; Fri, 3 Feb 2012 21:38:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.346 X-Spam-Level: X-Spam-Status: No, score=-3.346 tagged_above=-999 required=5 tests=[AWL=-0.348, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZ09tuCH-IjA for ; Fri, 3 Feb 2012 21:38:47 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id BEED911E8075 for ; Fri, 3 Feb 2012 21:38:23 -0800 (PST) Received: by obbwd15 with SMTP id wd15so6153470obb.31 for ; Fri, 03 Feb 2012 21:38:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=B8OQ/TFfcl049Ouwx6YjQm6oqVjrGQ97+tL4bGncdpI=; b=dm2/Mz80arW8KyfbFDK4mLIg5tGnMfsh657Enc+fjIM0qn/rSYCgP0PatlKtb0oTj7 tpZmC+0VmZwVEikM77FhWxpX9rkj7aps/N2R+NA5U7EYJG6fYW8LDy94mKwv8AyOa0H1 5gD7M0SGajAIWfdst1bSqxKE3Rbb6+Q4mR79U= MIME-Version: 1.0 Received: by 10.182.11.6 with SMTP id m6mr9146490obb.74.1328333903411; Fri, 03 Feb 2012 21:38:23 -0800 (PST) Received: by 10.182.213.71 with HTTP; Fri, 3 Feb 2012 21:38:23 -0800 (PST) In-Reply-To: <20120204001408.16716.94710.idtracker@ietfa.amsl.com> References: <20120204001408.16716.94710.idtracker@ietfa.amsl.com> Date: Sat, 4 Feb 2012 07:38:23 +0200 Message-ID: From: Mykyta Yevstifeyev To: apps-discuss@ietf.org Content-Type: multipart/alternative; boundary=f46d0447f32a74b90d04b81cd637 Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-media-type-regs-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2012 05:38:49 -0000 --f46d0447f32a74b90d04b81cd637 Content-Type: text/plain; charset=ISO-8859-1 Hi all, Looking through this document again... I don't really know whether comments from http://www.ietf.org/mail-archive/web/happiana/current/msg00184.html have been considered (at least, no response from authors have been received so far), but here is what I see in the current version with respect to the issues these comments concerned: --citing begins (my comments in-line starting with "MY>")-- Ned, all, Some additional (to Julian's) comments. In Abstract, it must be mentioned that the document obsoletes RFC 4288. MY> Still relevant. I find the current text in Introduction very confusing (or irrelevant), as it is very generic and not related to media types. It should be rewritten to make clear the goal of the doc. I also concur with Julian that Historical Note should be moved in the Introduction section. MY> Now Introduction seems fine. In Section 3.1: when specifying the procedures for registration media types in Standards Tree, you mentioned (in terms of RFC 5226): IESG approval, Specification Required, IETF Consensus, RFC Required with IESG Approval, i.e. 4 different registration policies. Whereas they serve a variety of possible cases, I think we would benefit from a single policy which would cover all of them. I suppose it is "Specification Required with IESG Approval" that would cover the following cases: (1) IESG-approved document, (2) specification of other standards body; registration undergoing IESG approval, (3) non-IESG-approved RFCs, registration of which also undergo IESG approval. The possible cases may also be discussed, though. MY> Also relevant in this version. Section 3.3: the "vanity" naming. I may be wrong cause it may be some sort of stylistic choice, but I actually think that "personal" is enough to characterize this tree. Whereas English native speakers would understand such naming, this would be frankly difficult for those who speak English as a foreign lang. I can't manage to find Russian or Ukrainian translation of RFC 4288 to prove, but I'm sure that the said formulation is applicable in English language only, and isn't appropriate for the international-scoped document. MY> Relevant as well. Section 3.4: this is what Julian has already mentioned for Section 4.2. APPSAWG is obliged to bring the draft deprecating x- to BCP, so if we revising the procedures docs, we need to take it into account. I propose you remove Section 3.4 and naming convention from Section 4.2 but put a note in Appendix B referring to the RFC-to-be. I think that if we produce new version of the doc we should take into account the current practice documented as BCP (and I hope it will get BCP). At least you should note that their registration is not absolutely prohibited; I also agree that in exceptional cases they can be registered, but only if wide use is demonstrated. MY> Current WG draft on deprecating x- says nothing on this, so I think we still should mention something in this document. Let'as consider my above proposal. Section 4.2: Shouldn't it explain the differences between RFC 2045 and the given ABNF? Section 4.10: "Proposals for media types registered in the standards tree by the IETF itself MUST be published as RFCs.". Do you really mean "proposal"? Also, do we need to encourage publishing RFCs for vnd and prs registrations? MY> This is ok in the current version. Section 5.1: "Registrations in other trees MAY be sent to the list for review as well." Maybe SHOULD? MY> Fixed; thanks. Section 5.9: Do we need to leave mail-style lines in the template (I mean To: and Subject:)? MY> (Now s5.7), and fixed in the doc. Ibid: Please move the para about MacOS file types into Section 4.11. MY> Now moved, I see. Section 6: s/RFC 3978/RFC 5378/ (and in References) MY> This is fixed. Sections 6 and 8: As your document sets up the registry for +suffixes, it should contain the description as required by RFC 5226, which it currently doesn't have. MY> This comment still applies. --citing ends-- These are my November comments, and so I suppose there could be more while discussing the document. Mykyta Yevstifeyev 2012/2/4 > > 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 : Media Type Specifications and Registration > Procedures > Author(s) : Ned Freed > John C. Klensin > Tony Hansen > Filename : draft-ietf-appsawg-media-type-regs-00.txt > Pages : 29 > Date : 2012-02-03 > > This document defines procedures for the specification and > registration of media types for use in HTTP, MIME and other Internet > protocols. > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-appsawg-media-type-regs-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > > ftp://ftp.ietf.org/internet-drafts/draft-ietf-appsawg-media-type-regs-00.txt > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --f46d0447f32a74b90d04b81cd637 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

Looking through this document again...

I don't re= ally know whether comments from http://www.ietf.org/mail-archive/web/h= appiana/current/msg00184.html have been considered (at least, no respon= se from authors have been received so far), but here is what I see in the c= urrent version with respect to the issues these comments concerned:

--citing begins (my comments in-line starting with "MY>")-= -

Ned, all,

Some additional (to Julian's) comments.
In Abstract, it must be mentioned that the document obsoletes RFC 4288.
MY> Still relevant.

I find the current text in Introduction v= ery confusing (or irrelevant), as it is very generic and not related to med= ia types. It should be rewritten to make clear the goal of the doc. I also = concur with Julian that Historical Note should be moved in the Introduction= section.

MY> Now Introduction seems fine.

In Section 3.1: when specify= ing the procedures for registration media types in Standards Tree, you ment= ioned (in terms of RFC 5226): IESG approval, Specification Required, IETF C= onsensus, RFC Required with IESG Approval, i.e. 4 different registration po= licies. Whereas they serve a variety of possible cases, I think we would be= nefit from a single policy which would cover all of them. I suppose it is &= quot;Specification Required with IESG Approval" that would cover the f= ollowing cases: (1) IESG-approved document, (2) specification of other stan= dards body; registration undergoing IESG approval, (3) non-IESG-approved RF= Cs, registration of which also undergo IESG approval. The possible cases ma= y also be discussed, though.

MY> Also relevant in this version.

Section 3.3: the "van= ity" naming. I may be wrong cause it may be some sort of stylistic cho= ice, but I actually think that "personal" is enough to characteri= ze this tree. Whereas English native speakers would understand such naming,= this would be frankly difficult for those who speak English as a foreign l= ang. I can't manage to find Russian or Ukrainian translation of RFC 428= 8 to prove, but I'm sure that the said formulation is applicable in Eng= lish language only, and isn't appropriate for the international-scoped = document.

MY> Relevant as well.

Section 3.4: this is what Julian has al= ready mentioned for Section 4.2. APPSAWG is obliged to bring the draft depr= ecating x- to BCP, so if we revising the procedures docs, we need to take i= t into account. I propose you remove Section 3.4 and naming convention from= Section 4.2 but put a note in Appendix B referring to the RFC-to-be. <l= ater when=3D"after reading reply to Julian's message">I th= ink that if we produce new version of the doc we should take into account t= he current practice documented as BCP (and I hope it will get BCP). At leas= t you should note that their registration is not absolutely prohibited; I a= lso agree that in exceptional cases they can be registered, but only if wid= e use is demonstrated.</later>

MY> Current WG draft on deprecating x- says nothing on this, so I th= ink we still should mention something in this document.=A0 Let'as consi= der my above proposal.

Section 4.2: Shouldn't it explain the dif= ferences between RFC 2045 and the given ABNF?

Section 4.10: "Proposals for media types registered in the standar= ds tree by the IETF itself MUST be published as RFCs.". Do you really = mean "proposal"? Also, do we need to encourage publishing RFCs fo= r vnd and prs registrations?

MY> This is ok in the current version.

Section 5.1: "Reg= istrations in other trees MAY be sent to the list for review as well."= Maybe SHOULD?

MY> Fixed; thanks.

Section 5.9: Do we need = to leave mail-style lines in the template (I mean To: and Subject:)?

MY> (Now s5.7), and fixed in the doc.

Ibid:=A0 Please move th= e para about MacOS file types into Section 4.11.

MY> Now moved, I= see.

Section 6: s/RFC 3978/RFC 5378/ (and in References)

MY&= gt; This is fixed.

Sections 6 and 8: As your document sets up the registry for +suffixes, = it should contain the description as required by RFC 5226, which it current= ly doesn't have.

MY> This comment still applies.

--citing ends--

These are my November comments, and so I suppose the= re could be more while discussing the document.

Mykyta Yevstifeyev
2012/2/4 <internet-drafts@ietf.org>

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

=A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Media Type Specifications and R= egistration Procedures
=A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Ned Freed
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0John C. Klensin
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Tony Hansen
=A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-appsawg-media-type-reg= s-00.txt
=A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 29
=A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-02-03

=A0 This document defines procedures for the specification and
=A0 registration of media types for use in HTTP, MIME and other Internet =A0 protocols.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-= ietf-appsawg-media-type-regs-00.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ie= tf-appsawg-media-type-regs-00.txt

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

--f46d0447f32a74b90d04b81cd637-- From ned.freed@mrochek.com Fri Feb 3 23:23:54 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B68EA21F8534 for ; Fri, 3 Feb 2012 23:23:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oRZhyYpl7KxB for ; Fri, 3 Feb 2012 23:23:54 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id AE2DF21F853F for ; Fri, 3 Feb 2012 23:23:53 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OBKKTRJ5PS00TK8L@mauve.mrochek.com> for apps-discuss@ietf.org; Fri, 3 Feb 2012 23:23:52 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OBHM72OXPS00ZUIL@mauve.mrochek.com>; Fri, 3 Feb 2012 23:23:49 -0800 (PST) Message-id: <01OBKKTPYLIE00ZUIL@mauve.mrochek.com> Date: Fri, 03 Feb 2012 22:52:03 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Sat, 04 Feb 2012 07:38:23 +0200" MIME-version: 1.0 Content-type: TEXT/PLAIN References: <20120204001408.16716.94710.idtracker@ietfa.amsl.com> To: Mykyta Yevstifeyev Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-media-type-regs-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2012 07:23:54 -0000 > Hi all, > Looking through this document again... > I don't really know whether comments from > http://www.ietf.org/mail-archive/web/happiana/current/msg00184.html have > been considered (at least, no response from authors have been received so > far), but here is what I see in the current version with respect to the > issues these comments concerned: Yes, I did take them into consideration. > --citing begins (my comments in-line starting with "MY>")-- > Ned, all, > Some additional (to Julian's) comments. > In Abstract, it must be mentioned that the document obsoletes RFC 4288. A stupid rule in my opinion, but a rule nevertheless. I forgot to add it but will do so in the next revision. > MY> Still relevant. > I find the current text in Introduction very confusing (or irrelevant), as > it is very generic and not related to media types. It should be rewritten > to make clear the goal of the doc. I also concur with Julian that > Historical Note should be moved in the Introduction section. > MY> Now Introduction seems fine. I actually didn't change anything in response to your comment because I couldn't figure out how to do so, so I'm a little confused as to why you think it's OK now but not before, but as you think it's OK now I guess it's all good. > In Section 3.1: when specifying the procedures for registration media types > in Standards Tree, you mentioned (in terms of RFC 5226): IESG approval, > Specification Required, IETF Consensus, RFC Required with IESG Approval, > i.e. 4 different registration policies. Whereas they serve a variety of > possible cases, I think we would benefit from a single policy which would > cover all of them. I suppose it is "Specification Required with IESG > Approval" that would cover the following cases: (1) IESG-approved document, > (2) specification of other standards body; registration undergoing IESG > approval, (3) non-IESG-approved RFCs, registration of which also undergo > IESG approval. The possible cases may also be discussed, though. > MY> Also relevant in this version. If I understand what you're trying to do, not going to happen. The main point of this revision is to remove the need for the IESG to be involved in the approval of standards tree types from other SDOs, while retaining their role in IETF registration approval. As such, your suggestion for a single policy for all registrations is totally inconsistent with the fundamental goal of this revision. > Section 3.3: the "vanity" naming. I may be wrong cause it may be some sort > of stylistic choice, but I actually think that "personal" is enough to > characterize this tree. Whereas English native speakers would understand > such naming, this would be frankly difficult for those who speak English as > a foreign lang. I can't manage to find Russian or Ukrainian translation of > RFC 4288 to prove, but I'm sure that the said formulation is applicable in > English language only, and isn't appropriate for the international-scoped > document. > MY> Relevant as well. I'm sorry, but I really don't see the point of removing it. It's not like it has ever proved to be a source of confusion in the past. > Section 3.4: this is what Julian has already mentioned for Section 4.2. > APPSAWG is obliged to bring the draft deprecating x- to BCP, so if we > revising the procedures docs, we need to take it into account. I propose > you remove Section 3.4 and naming convention from Section 4.2 but put a > note in Appendix B referring to the RFC-to-be. I think that if we produce new version of the > doc we should take into account the current practice documented as BCP (and > I hope it will get BCP). At least you should note that their registration > is not absolutely prohibited; I also agree that in exceptional cases they > can be registered, but only if wide use is demonstrated. First of all, the WG is in no way "obliged" to do anything. It may in fact fail to reach consensus and not do anything about x-. The draft in question is still being actively debated, and there appears to be some controversy. I'm waiting to see the outcome of that before taking any action on this point, as it's possible the whole x- thing may prove to be a lot more problematic than some suppose. > MY> Current WG draft on deprecating x- says nothing on this, so I think we > still should mention something in this document. Let'as consider my above > proposal. I was thinking of going further and saying something like "the restriction on registration of x- types that appeared in previous document has been dropped" or something along those lines, but I really want to wait. > Section 4.2: Shouldn't it explain the differences between RFC 2045 and the > given ABNF? Nope. I very intentionally chose not to get into the historical details of why the restrictions exist. This is a document focused on getting registrations done. The origin of the restrictions or comparisons to what they were historically do not assist in that goal in any way that I can see. > Section 4.10: "Proposals for media types registered in the standards tree > by the IETF itself MUST be published as RFCs.". Do you really mean > "proposal"? Also, do we need to encourage publishing RFCs for vnd and prs > registrations? > MY> This is ok in the current version. I agree and not only that, I removed the word "proposal" in several other places as well in response to your comment. (There's still one left that I believe is necessary - I took it out but was convinced it needed to go back in.) > Section 5.1: "Registrations in other trees MAY be sent to the list for > review as well." Maybe SHOULD? > MY> Fixed; thanks. > Section 5.9: Do we need to leave mail-style lines in the template (I mean > To: and Subject:)? > MY> (Now s5.7), and fixed in the doc. Yeah, it was unnecessary. > Ibid: Please move the para about MacOS file types into Section 4.11. > MY> Now moved, I see. Actually, no, I didn't move the pointer to the reference out of the template, and I should have. This is now sufficiently obscure that having it in the template is a distraction. (Again, focus focus focus on getting registrations done with as few distractions as possible.) I'll move it. > Section 6: s/RFC 3978/RFC 5378/ (and in References) > MY> This is fixed. > Sections 6 and 8: As your document sets up the registry for +suffixes, it > should contain the description as required by RFC 5226, which it currently > doesn't have. > MY> This comment still applies. Description where? I do not understand this one. I also do not see the requirement you're talking about anywhere in RFC 5226. (The word description appears exactly twice, and neither time in a requirement.) > --citing ends-- You might want to look at the open issues list and consider if they are good ideas or not. Ned From john-ietf@jck.com Sat Feb 4 06:05:13 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A69221F852C for ; Sat, 4 Feb 2012 06:05:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XzF7xFw6V5V5 for ; Sat, 4 Feb 2012 06:05:12 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 6836721F8532 for ; Sat, 4 Feb 2012 06:05:12 -0800 (PST) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1RtgBE-000F2f-Fu; Sat, 04 Feb 2012 09:01:28 -0500 Date: Sat, 04 Feb 2012 09:05:05 -0500 From: John C Klensin To: Ned Freed , Mykyta Yevstifeyev Message-ID: In-Reply-To: <01OBKKTPYLIE00ZUIL@mauve.mrochek.com> References: <20120204001408.16716.94710.idtracker@ietfa.amsl.com> <01OBKKTPYLIE00ZUIL@mauve.mrochek.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: apps-discuss@ietf.org Subject: [apps-discuss] Requirement for "obsoletes" in Abstracts (was: Re: I-D Action: draft-ietf-appsawg-media-type-regs-00.txt) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2012 14:05:13 -0000 (changing subject line because this is really a separate topic) --On Friday, February 03, 2012 22:52 -0800 Ned Freed wrote: >... >> In Abstract, it must be mentioned that the document obsoletes >> RFC 4288. > > A stupid rule in my opinion, but a rule nevertheless. I forgot > to add it but will do so in the next revision. Actually, as co-author, I want to strongly resist this change and therefore that putative rule (I claim that, independent of its substantive properties, it is invalid; see below). I have three separate reasons, any one of which would, IMO, justify saying "no". Rant follows. (1) Abstracts are supposed to be about the content and function of the document and are supposed to be as minimal as possible while still covering the actual substance. Except in unusual cases, which this is not, mentioning the history and relationships of a document in the Abstract is not substantively important to someone who is simply looking at it to find the present state of things, as would be the case with this once it is published. Worse, except for RFCs that are much better known by their numbers than by their titles (there aren't many; RFC 822 comes to mind as an example), good practice requires citations on first use to explain what the number refers to. But the RFC Editor's practice (and almost every style manual for professional publications in the world) prohibits citations from Abstracts -- they are supposed to stand on their own. Things might be different if the sole purpose of a document were to obsolete or reclassify another one, but that does not apply in this case. That may be a very long way of saying "stupid rule". (2) Determination of what should be required or permitted in Abstracts in published RFCs has always been an RFC Editor matter, not something the IESG can change, any more than they can unilaterally change page header or footer formats. Note that we already have a header on the first page (almost always the same pages as the abstract since we fixed the "boilerplate first" problem), so, stylistically, there is a "how much overkill is needed" question. FWIW, I don't have any problem with the IESG imposing an "explain what this updates and why" requirement on the body of a document, although I believe even then that they ought to have a discussion with the RFC Editor about placement (e.g., Introduction versus separate section or subsection). I believe that the "Status of Document" section of IETF Stream RFCs basically belongs to the IETF and IESG, so, if the IESG wants some particular "obsoletes XXX" text there, I might still think it was stupid, but I wouldn't consider it nearly as inappropriate as imposing requirements on the abstract. In addition, I think the IESG, subject to community review, can impose whatever requirements they think necessary on I-Ds to get effective review of documents. I think the rule requiring that all IETF Stream I-Ds contain an "IANA Considerations" section that can be removed on publication is ill-advised and have seen a number of problems that can be attributed to the rule itself. But, if the IESG, after careful deliberation, is convinced that it is helpful to the review and consensus process, I'm ok with it and will conform without saying much of anything. The same principle might apply here: if the IESG wants to say, e.g., that obsoleting or reclassification relationships should be reflected in an extra paragraph of the Abstract that is removed on publication and hence not subject to the RFC Editor's rules about length and content, I'll mutter into my beard, but will comply. (3) Although they can make suggestions and determine their own practices, the IESG doesn't get to invent and make binding rules for the community. The Tools Team may incorporate what they consider reasonable practices into checking tools (I'm strongly in favor of that, actually), but that doesn't make those practices binding on the community either. In both cases, the difference between "strong suggestion" and "requirement" has always been community consensus. That hasn't occurred here -- there has been no document for which community discussion has occurred and consensus sought. What we have is (i) a statement in Section 3(1)(D) of the I-D checklist http://www.ietf.org/id-info/checklist.html (a fine document if taken as strong suggestions) (ii) a check in the the I-D nits tool. (iii) a few statements, e.g., in the checklist itself and the Shepherd template that effectively make the above normative. There has not been an explicit consensus call on this requirement in on any of the above contexts. In the interest of efficiency, I'm even ok if the IESG sets requirements and puts them into effect immediately, issuing formal consensus calls only later or if there are objections from the community. Well, I'm objecting, I have objected in the past, and, while the the IESG hasn't issued a consensus call, they have published Standards Track documents in the IETF Stream that do not contain "obsoleting" information in the abstract. And, again, even if the IESG asked for community consensus and got it, it isn't clear that they can impose requirements on the content of abstracts without the concurrence of the RFC Editor. john-the-grump From john-ietf@jck.com Sat Feb 4 06:24:13 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17E5121F855D for ; Sat, 4 Feb 2012 06:24:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3sXV3xLbCYG5 for ; Sat, 4 Feb 2012 06:24:12 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE7721F84A6 for ; Sat, 4 Feb 2012 06:24:12 -0800 (PST) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1RtgTd-000F3z-Ai; Sat, 04 Feb 2012 09:20:29 -0500 Date: Sat, 04 Feb 2012 09:24:06 -0500 From: John C Klensin To: Ned Freed , Mykyta Yevstifeyev Message-ID: <3E47C25AC70628DF68F28EDC@PST.JCK.COM> In-Reply-To: <01OBKKTPYLIE00ZUIL@mauve.mrochek.com> References: <20120204001408.16716.94710.idtracker@ietfa.amsl.com> <01OBKKTPYLIE00ZUIL@mauve.mrochek.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-media-type-regs-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2012 14:24:13 -0000 --On Friday, February 03, 2012 22:52 -0800 Ned Freed wrote: >... >> Section 3.3: the "vanity" naming. I may be wrong cause it may >> be some sort of stylistic choice, but I actually think that >> "personal" is enough to characterize this tree. Whereas >> English native speakers would understand such naming, this >> would be frankly difficult for those who speak English as a >> foreign lang. I can't manage to find Russian or Ukrainian >> translation of RFC 4288 to prove, but I'm sure that the said >> formulation is applicable in English language only, and isn't >> appropriate for the international-scoped document. > >> MY> Relevant as well. > > I'm sorry, but I really don't see the point of removing it. > It's not like it has ever proved to be a source of confusion > in the past. Mykyta, slightly different (and longer) answer: I think "vanity" is obnoxious and always have. For reasons that have nothing to do with this particular usage, I'd prefer that it not be there. But such changes in wording in revisions almost always have consequences, some of which we don't anticipate, so I'm reluctant to make them unless there is evidence that they cause a problem. As Ned says, there is no evidence that this has. If the text said "Vanity Tree, sometimes known as 'personal tree'" or "Vanity (Personal) Tree", or if the facet designator was "vnt" or equivalent, I'd feel differently about this. But "Personal or Vanity" does not require that anyone pay any attention to the implicit "vanity" sub-branch, so the risks of making a change that might confuse people or require an explanation seem to me to far outweigh the problems with the existing text, problems that seem to be limited to offending the tastes of several of us. >> Section 3.4: this is what Julian has already mentioned for >> Section 4.2. APPSAWG is obliged to bring the draft >> deprecating x- to BCP, so if we revising the procedures docs, >> we need to take it into account. I propose you remove Section >> 3.4 and naming convention from Section 4.2 but put a note in >> Appendix B referring to the RFC-to-be. I think that if we produce >> new version of the doc we should take into account the >> current practice documented as BCP (and I hope it will get >> BCP). At least you should note that their registration is not >> absolutely prohibited; I also agree that in exceptional cases >> they can be registered, but only if wide use is >> demonstrated. > > First of all, the WG is in no way "obliged" to do anything. It > may in fact fail to reach consensus and not do anything about > x-. The draft in question is still being actively debated, > and there appears to be some controversy. I'm waiting to see > the outcome of that before taking any action on this point, as > it's possible the whole x- thing may prove to be a lot more > problematic than some suppose. While I agree with Ned, I note that, in any event, the document already discourages "x-" and "x." registrations. The newly-proposed "deprecated alias" mechanism actually provides a path to get rid of the things, which may be far better (and, for better or worse, more consistent with the spirit of the xdash draft) than trying to set up criteria for "wide use" and then enshrining them forever. >... john From evnikita2@gmail.com Sat Feb 4 06:46:51 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D74521F8566 for ; Sat, 4 Feb 2012 06:46:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.334 X-Spam-Level: X-Spam-Status: No, score=-3.334 tagged_above=-999 required=5 tests=[AWL=-0.336, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x4T3Eke0yWhc for ; Sat, 4 Feb 2012 06:46:49 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 74D6F21F8562 for ; Sat, 4 Feb 2012 06:46:49 -0800 (PST) Received: by obbwd15 with SMTP id wd15so6463071obb.31 for ; Sat, 04 Feb 2012 06:46:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Y9ToznhX8LB2ntNuXUVdzPEjlhvzpuzmGZpNTu7tctU=; b=Ll9MEkk+59LZvoBEOdWW1n1/1v18sERonNAvwvUqW/j18pCg66V7TBUhwdB4czrrua SrHZ/2TdvY5ycXGQgXKdSO6C6VdB9alu/QpA1yd2pZZuHN4JulNSkX/WIinHnzNRIoFg 98wTZ3p3spYy0jup48fkW5nC1H9UF3sF/S7yo= MIME-Version: 1.0 Received: by 10.182.144.68 with SMTP id sk4mr10539581obb.4.1328366809125; Sat, 04 Feb 2012 06:46:49 -0800 (PST) Received: by 10.182.213.71 with HTTP; Sat, 4 Feb 2012 06:46:49 -0800 (PST) In-Reply-To: <01OBKKTPYLIE00ZUIL@mauve.mrochek.com> References: <20120204001408.16716.94710.idtracker@ietfa.amsl.com> <01OBKKTPYLIE00ZUIL@mauve.mrochek.com> Date: Sat, 4 Feb 2012 16:46:49 +0200 Message-ID: From: Mykyta Yevstifeyev To: Ned Freed Content-Type: multipart/alternative; boundary=14dae9399ce7ca143804b8247fa6 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-media-type-regs-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2012 14:46:51 -0000 --14dae9399ce7ca143804b8247fa6 Content-Type: text/plain; charset=ISO-8859-1 2012/2/4 Ned Freed > > Hi all, > > > Looking through this document again... > > > I don't really know whether comments from > > http://www.ietf.org/mail-archive/web/happiana/current/msg00184.html have > > been considered (at least, no response from authors have been received so > > far), but here is what I see in the current version with respect to the > > issues these comments concerned: > > Yes, I did take them into consideration. > > > --citing begins (my comments in-line starting with "MY>")-- > > > Ned, all, > > > Some additional (to Julian's) comments. > > > In Abstract, it must be mentioned that the document obsoletes RFC 4288. > > A stupid rule in my opinion, but a rule nevertheless. I forgot to add it > but will do so in the next revision. > > > MY> Still relevant. > > > I find the current text in Introduction very confusing (or irrelevant), > as > > it is very generic and not related to media types. It should be rewritten > > to make clear the goal of the doc. I also concur with Julian that > > Historical Note should be moved in the Introduction section. > > > MY> Now Introduction seems fine. > > I actually didn't change anything in response to your comment because I > couldn't figure out how to do so, so I'm a little confused as to why you > think > it's OK now but not before, but as you think it's OK now I guess it's all > good. > I don't remember what was "confusing" there as I'm looking at -01 individual version, so I think "I guess it's all good" is good. > > > In Section 3.1: when specifying the procedures for registration media > types > > in Standards Tree, you mentioned (in terms of RFC 5226): IESG approval, > > Specification Required, IETF Consensus, RFC Required with IESG Approval, > > i.e. 4 different registration policies. Whereas they serve a variety of > > possible cases, I think we would benefit from a single policy which would > > cover all of them. I suppose it is "Specification Required with IESG > > Approval" that would cover the following cases: (1) IESG-approved > document, > > (2) specification of other standards body; registration undergoing IESG > > approval, (3) non-IESG-approved RFCs, registration of which also undergo > > IESG approval. The possible cases may also be discussed, though. > > > MY> Also relevant in this version. > > If I understand what you're trying to do, not going to happen. The main > point > of this revision is to remove the need for the IESG to be involved in the > approval of standards tree types from other SDOs, while retaining their > role in > IETF registration approval. As such, your suggestion for a single policy > for > all registrations is totally inconsistent with the fundamental goal of this > revision. > I meant procedure for Standards Tree only, and in no way for all registrations. The four policies I listed are mentioned in Section 3.1 only, which defines Standards Tree procedures. > > > Section 3.3: the "vanity" naming. I may be wrong cause it may be some > sort > > of stylistic choice, but I actually think that "personal" is enough to > > characterize this tree. Whereas English native speakers would understand > > such naming, this would be frankly difficult for those who speak English > as > > a foreign lang. I can't manage to find Russian or Ukrainian translation > of > > RFC 4288 to prove, but I'm sure that the said formulation is applicable > in > > English language only, and isn't appropriate for the international-scoped > > document. > > > MY> Relevant as well. > > I'm sorry, but I really don't see the point of removing it. It's not > like it has ever proved to be a source of confusion in the past. > I'll reply to John's response. > > > Section 3.4: this is what Julian has already mentioned for Section 4.2. > > APPSAWG is obliged to bring the draft deprecating x- to BCP, so if we > > revising the procedures docs, we need to take it into account. I propose > > you remove Section 3.4 and naming convention from Section 4.2 but put a > > note in Appendix B referring to the RFC-to-be. I think that if we produce new version of the > > doc we should take into account the current practice documented as BCP > (and > > I hope it will get BCP). At least you should note that their registration > > is not absolutely prohibited; I also agree that in exceptional cases they > > can be registered, but only if wide use is demonstrated. > > First of all, the WG is in no way "obliged" to do anything. It may in fact > fail > to reach consensus and not do anything about x-. The draft in question is > still being actively debated, and there appears to be some controversy. I'm > waiting to see the outcome of that before taking any action on this point, > as > it's possible the whole x- thing may prove to be a lot more problematic > than > some suppose. > That was what I saw the consensus was at the time of writing. > > > MY> Current WG draft on deprecating x- says nothing on this, so I think > we > > still should mention something in this document. Let'as consider my > above > > proposal. > > I was thinking of going further and saying something like "the restriction > on registration of x- types that appeared in previous document has been > dropped" or something along those lines, but I really want to wait. > Agreed, let's wait. > > > Section 4.2: Shouldn't it explain the differences between RFC 2045 and > the > > given ABNF? > > Nope. I very intentionally chose not to get into the historical details of > why > the restrictions exist. This is a document focused on getting registrations > done. The origin of the restrictions or comparisons to what they were > historically do not assist in that goal in any way that I can see. > Having no objections to not mentioning this in the document. > > > Section 4.10: "Proposals for media types registered in the standards tree > > by the IETF itself MUST be published as RFCs.". Do you really mean > > "proposal"? Also, do we need to encourage publishing RFCs for vnd and prs > > registrations? > > > MY> This is ok in the current version. > > I agree and not only that, I removed the word "proposal" in several other > places as well in response to your comment. (There's still one left that I > believe is necessary - I took it out but was convinced it needed to go back > in.) > > > Section 5.1: "Registrations in other trees MAY be sent to the list for > > review as well." Maybe SHOULD? > > > MY> Fixed; thanks. > > > Section 5.9: Do we need to leave mail-style lines in the template (I mean > > To: and Subject:)? > > > MY> (Now s5.7), and fixed in the doc. > > Yeah, it was unnecessary. > > > Ibid: Please move the para about MacOS file types into Section 4.11. > > > MY> Now moved, I see. > > Actually, no, I didn't move the pointer to the reference out of the > template, > and I should have. This is now sufficiently obscure that having it in the > template is a distraction. (Again, focus focus focus on getting > registrations > done with as few distractions as possible.) I'll move it. > And again I don't remember what I meant in November... but the current situation is fine. > > > Section 6: s/RFC 3978/RFC 5378/ (and in References) > > > MY> This is fixed. > > > Sections 6 and 8: As your document sets up the registry for +suffixes, it > > should contain the description as required by RFC 5226, which it > currently > > doesn't have. > > > MY> This comment still applies. > > Description where? I do not understand this one. I also do not see the > requirement you're talking about anywhere in RFC 5226. (The word > description > appears exactly twice, and neither time in a requirement.) > I mean your description in Section 6 should follow Section 4.2 of RFC 5226. > > > --citing ends-- > > You might want to look at the open issues list and consider if they are > good > ideas or not. > Commenting on the 'open issues': o The list of fields in the registration is getting long. Should the fields be numbered and referred to by number in order to facilitate translation into other languages and similar activities? Whereas I'm not a native English speaker, I can say that this won't help in translation in any way (I can't imagine such way, at least). Also, what are 'similar activities' here? o Currently anyone can register a vendor media type on behalf of a vendor but subsequent to that only the vendor can make changes. Do we want to retain this restriction? I think we should allow registering vnd types by anyone with vendor's approval (or by tacit agreement if vendor is ignoring the proposal), and to change the registration in a similar way. Mykyta Yevstifeyev > > Ned > --14dae9399ce7ca143804b8247fa6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
2012/2/4 Ned Freed <ned.freed@mrochek.com>
> Hi all,

> Looking through this document again...

> I don't really know whether comments from
> http://www.ietf.org/mail-archive/web/happiana/c= urrent/msg00184.html have
> been considered (at least, no response from authors have been received= so
> far), but here is what I see in the current version with respect to th= e
> issues these comments concerned:

Yes, I did take them into consideration.

> --citing begins (my comments in-line starting with "MY>")= --

> Ned, all,

> Some additional (to Julian's) comments.

> In Abstract, it must be mentioned that the document obsoletes RFC 4288= .

A stupid rule in my opinion, but a rule nevertheless. I forgot to add it but will do so in the next revision.

> MY> Still relevant.

> I find the current text in Introduction very confusing (or irrelevant)= , as
> it is very generic and not related to media types. It should be rewrit= ten
> to make clear the goal of the doc. I also concur with Julian that
> Historical Note should be moved in the Introduction section.

> MY> Now Introduction seems fine.

I actually didn't change anything in response to your comment because I=
couldn't figure out how to do so, so I'm a little confused as to wh= y you think
it's OK now but not before, but as you think it's OK now I guess it= 's all good.

I don't remember what was &qu= ot;confusing" there as I'm looking at -01 individual version, so I= think "I guess it's all good" is good.
=A0

> In Section 3.1: when specifying the procedures for registration media = types
> in Standards Tree, you mentioned (in terms of RFC 5226): IESG approval= ,
> Specification Required, IETF Consensus, RFC Required with IESG Approva= l,
> i.e. 4 different registration policies. Whereas they serve a variety o= f
> possible cases, I think we would benefit from a single policy which wo= uld
> cover all of them. I suppose it is "Specification Required with I= ESG
> Approval" that would cover the following cases: (1) IESG-approved= document,
> (2) specification of other standards body; registration undergoing IES= G
> approval, (3) non-IESG-approved RFCs, registration of which also under= go
> IESG approval. The possible cases may also be discussed, though.

> MY> Also relevant in this version.

If I understand what you're trying to do, not going to happen. The main= point
of this revision is to remove the need for the IESG to be involved in the approval of standards tree types from other SDOs, while retaining their rol= e in
IETF registration approval. As such, your suggestion for a single policy fo= r
all registrations is totally inconsistent with the fundamental goal of this=
revision.

I meant procedure for Standards Tree onl= y, and in no way for all registrations.=A0 The four policies I listed are m= entioned in Section 3.1 only, which defines Standards Tree procedures.
=A0

> Section 3.3: the "vanity" naming. I may be wrong cause it ma= y be some sort
> of stylistic choice, but I actually think that "personal" is= enough to
> characterize this tree. Whereas English native speakers would understa= nd
> such naming, this would be frankly difficult for those who speak Engli= sh as
> a foreign lang. I can't manage to find Russian or Ukrainian transl= ation of
> RFC 4288 to prove, but I'm sure that the said formulation is appli= cable in
> English language only, and isn't appropriate for the international= -scoped
> document.

> MY> Relevant as well.

I'm sorry, but I really don't see the point of removing it. It'= s not
like it has ever proved to be a source of confusion in the past.

I'll reply to John's response.
=A0

> Section 3.4: this is what Julian has already mentioned for Section 4.2= .
> APPSAWG is obliged to bring the draft deprecating x- to BCP, so if we<= br> > revising the procedures docs, we need to take it into account. I propo= se
> you remove Section 3.4 and naming convention from Section 4.2 but put = a
> note in Appendix B referring to the RFC-to-be. <later when=3D"= after reading
> reply to Julian's message">I think that if we produce new = version of the
> doc we should take into account the current practice documented as BCP= (and
> I hope it will get BCP). At least you should note that their registrat= ion
> is not absolutely prohibited; I also agree that in exceptional cases t= hey
> can be registered, but only if wide use is demonstrated.</later>=

First of all, the WG is in no way "obliged" to do anything. It ma= y in fact fail
to reach consensus and not do anything about x-. =A0The draft in question i= s
still being actively debated, and there appears to be some controversy. I&#= 39;m
waiting to see the outcome of that before taking any action on this point, = as
it's possible the whole x- thing may prove to be a lot more problematic= than
some suppose.

That was what I saw the consensus wa= s at the time of writing.
=A0

> MY> Current WG draft on deprecating x- says nothing on this, so I t= hink we
> still should mention something in this document. =A0Let'as conside= r my above
> proposal.

I was thinking of going further and saying something like "the restric= tion
on registration of x- types that appeared in previous document has been
dropped" or something along those lines, but I really want to wait.

Agreed, let's wait.
=A0

> Section 4.2: Shouldn't it explain the differences between RFC 2045= and the
> given ABNF?

Nope. I very intentionally chose not to get into the historical details of = why
the restrictions exist. This is a document focused on getting registrations=
done. The origin of the restrictions or comparisons to what they were
historically do not assist in that goal in any way that I can see.

Having no objections to not mentioning this in the documen= t.
=A0

> Section 4.10: "Proposals for media types registered in the standa= rds tree
> by the IETF itself MUST be published as RFCs.". Do you really mea= n
> "proposal"? Also, do we need to encourage publishing RFCs fo= r vnd and prs
> registrations?

> MY> This is ok in the current version.

I agree and not only that, I removed the word "proposal" in sever= al other
places as well in response to your comment. (There's still one left tha= t I
believe is necessary - I took it out but was convinced it needed to go back=
in.)

> Section 5.1: "Registrations in other trees MAY be sent to the lis= t for
> review as well." Maybe SHOULD?

> MY> Fixed; thanks.

> Section 5.9: Do we need to leave mail-style lines in the template (I m= ean
> To: and Subject:)?

> MY> (Now s5.7), and fixed in the doc.

Yeah, it was unnecessary.

> Ibid: =A0Please move the para about MacOS file types into Section 4.11= .

> MY> Now moved, I see.

Actually, no, I didn't move the pointer to the reference out of the tem= plate,
and I should have. This is now sufficiently obscure that having it in the template is a distraction. (Again, focus focus focus on getting registratio= ns
done with as few distractions as possible.) I'll move it.

And again I don't remember what I meant in November... but = the current situation is fine.
=A0

> Section 6: s/RFC 3978/RFC 5378/ (and in References)

> MY> This is fixed.

> Sections 6 and 8: As your document sets up the registry for +suffixes,= it
> should contain the description as required by RFC 5226, which it curre= ntly
> doesn't have.

> MY> This comment still applies.

Description where? I do not understand this one. I also do not see the
requirement you're talking about anywhere in RFC 5226. (The word descri= ption
appears exactly twice, and neither time in a requirement.)
=

I mean your description in Section 6 should follow Section 4.2 of = RFC 5226.
=A0

> --citing ends--

You might want to look at the open issues list and consider if they are goo= d
ideas or not.

Commenting on the 'open issues&#= 39;:

=A0=A0 o=A0 The list of fields in the registration is getting l= ong.=A0 Should
=A0=A0=A0=A0=A0 the fields be numbered and referred to by= number in order to
=A0=A0=A0=A0=A0 facilitate translation into other languages and similar
= =A0=A0=A0=A0=A0 activities?

Whereas I'm not a native English spe= aker, I can say that this won't help in translation in any way (I can&#= 39;t imagine such way, at least).=A0 Also, what are 'similar activities= ' here?

=A0=A0 o=A0 Currently anyone can register a vendor media type on behalf= of a
=A0=A0=A0=A0=A0 vendor but subsequent to that only the vendor can = make changes.
=A0=A0=A0=A0=A0 Do we want to retain this restriction?
=
I think we should allow registering vnd types by anyone with vendor'= ;s approval (or by tacit agreement if vendor is ignoring the proposal), and= to change the registration in a similar way.

Mykyta Yevstifeyev
=A0

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Ned

--14dae9399ce7ca143804b8247fa6-- From evnikita2@gmail.com Sat Feb 4 06:54:22 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A915F21F854E for ; Sat, 4 Feb 2012 06:54:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.622 X-Spam-Level: X-Spam-Status: No, score=-3.622 tagged_above=-999 required=5 tests=[AWL=-0.024, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8mRQ9jSgZqM for ; Sat, 4 Feb 2012 06:54:21 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id B253E21F8545 for ; Sat, 4 Feb 2012 06:54:21 -0800 (PST) Received: by obbwd15 with SMTP id wd15so6467730obb.31 for ; Sat, 04 Feb 2012 06:54:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PYAQ3jwhYS/SzL17VegxxR2DPbqQJ9MCzGWMTJXs6tA=; b=xTSbqUKbBMwNQnZJM6Hg/M48PUhj+VcZxVER9rSORdyxzQueeh4GjQHGEfYLNhdTVm OXzwn1TqkuzRDXR3kvjGx4EK26GVsq6zCfYFc6Og8iIF/olPMcekfmGZcoWhsV85GIJP PcueU1XKLQ/uYForQQgV80AMN6zFJFiegiNuc= MIME-Version: 1.0 Received: by 10.182.11.6 with SMTP id m6mr10396883obb.74.1328367261379; Sat, 04 Feb 2012 06:54:21 -0800 (PST) Received: by 10.182.213.71 with HTTP; Sat, 4 Feb 2012 06:54:21 -0800 (PST) In-Reply-To: <3E47C25AC70628DF68F28EDC@PST.JCK.COM> References: <20120204001408.16716.94710.idtracker@ietfa.amsl.com> <01OBKKTPYLIE00ZUIL@mauve.mrochek.com> <3E47C25AC70628DF68F28EDC@PST.JCK.COM> Date: Sat, 4 Feb 2012 16:54:21 +0200 Message-ID: From: Mykyta Yevstifeyev To: John C Klensin Content-Type: multipart/alternative; boundary=f46d0447f32abeeda204b8249ad2 Cc: Ned Freed , apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-media-type-regs-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2012 14:54:22 -0000 --f46d0447f32abeeda204b8249ad2 Content-Type: text/plain; charset=ISO-8859-1 2012/2/4 John C Klensin > > > --On Friday, February 03, 2012 22:52 -0800 Ned Freed > wrote: > > >... > >> Section 3.3: the "vanity" naming. I may be wrong cause it may > >> be some sort of stylistic choice, but I actually think that > >> "personal" is enough to characterize this tree. Whereas > >> English native speakers would understand such naming, this > >> would be frankly difficult for those who speak English as a > >> foreign lang. I can't manage to find Russian or Ukrainian > >> translation of RFC 4288 to prove, but I'm sure that the said > >> formulation is applicable in English language only, and isn't > >> appropriate for the international-scoped document. > > > >> MY> Relevant as well. > > > > I'm sorry, but I really don't see the point of removing it. > > It's not like it has ever proved to be a source of confusion > > in the past. > > Mykyta, slightly different (and longer) answer: I think "vanity" > is obnoxious and always have. For reasons that have nothing to > do with this particular usage, I'd prefer that it not be there. > But such changes in wording in revisions almost always have > consequences, some of which we don't anticipate, so I'm > reluctant to make them unless there is evidence that they cause > a problem. As Ned says, there is no evidence that this has. > If the text said "Vanity Tree, sometimes known as 'personal > tree'" or "Vanity (Personal) Tree", or if the facet designator > was "vnt" or equivalent, I'd feel differently about this. But > "Personal or Vanity" does not require that anyone pay any > attention to the implicit "vanity" sub-branch, so the risks of > making a change that might confuse people or require an > explanation seem to me to far outweigh the problems with the > existing text, problems that seem to be limited to offending the > tastes of several of us. > While this is really not a matter of life and death, I think retaining the old name should be fine, and so withdrawing my concern. > > >> Section 3.4: this is what Julian has already mentioned for > >> Section 4.2. APPSAWG is obliged to bring the draft > >> deprecating x- to BCP, so if we revising the procedures docs, > >> we need to take it into account. I propose you remove Section > >> 3.4 and naming convention from Section 4.2 but put a note in > >> Appendix B referring to the RFC-to-be. I think that if we produce > >> new version of the doc we should take into account the > >> current practice documented as BCP (and I hope it will get > >> BCP). At least you should note that their registration is not > >> absolutely prohibited; I also agree that in exceptional cases > >> they can be registered, but only if wide use is > >> demonstrated. > > > > First of all, the WG is in no way "obliged" to do anything. It > > may in fact fail to reach consensus and not do anything about > > x-. The draft in question is still being actively debated, > > and there appears to be some controversy. I'm waiting to see > > the outcome of that before taking any action on this point, as > > it's possible the whole x- thing may prove to be a lot more > > problematic than some suppose. > > While I agree with Ned, I note that, in any event, the document > already discourages "x-" and "x." registrations. The > newly-proposed "deprecated alias" mechanism actually provides a > path to get rid of the things, which may be far better (and, for > better or worse, more consistent with the spirit of the xdash > draft) than trying to set up criteria for "wide use" and then > enshrining them forever. > Yes, and so let's better wait for what appsawg 'x'-deprecating draft finishes in, and than see what we can do with this one. Mykyta Yevstifeyev > > >... > > john > > --f46d0447f32abeeda204b8249ad2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
2012/2/4 John C Klensin <john-ietf@jck.com>


--On Friday, February 03, 2012 22:52 -0800 Ned Freed
<ned.freed@mrochek.com> = wrote:

>...
>> Section 3.3: the "vanity" naming. I may be wrong cause i= t may
>> be some sort of stylistic choice, but I actually think that
>> "personal" is enough to characterize this tree. Whereas<= br> >> English native speakers would understand such naming, this
>> would be frankly difficult for those who speak English as a
>> foreign lang. I can't manage to find Russian or Ukrainian
>> translation of RFC 4288 to prove, but I'm sure that the said >> formulation is applicable in English language only, and isn't<= br> >> appropriate for the international-scoped document.
>
>> MY> Relevant as well.
>
> I'm sorry, but I really don't see the point of removing it. > It's not like it has ever proved to be a source of confusion
> in the past.

Mykyta, slightly different (and longer) answer: I think "vanity"<= br> is obnoxious and always have. =A0For reasons that have nothing to
do with this particular usage, I'd prefer that it not be there.
But such changes in wording in revisions almost always have
consequences, some of which we don't anticipate, so I'm
reluctant to make them unless there is evidence that they cause
a problem. =A0 As Ned says, there is no evidence that this has.
If the text said "Vanity Tree, sometimes known as 'personal
tree'" or "Vanity (Personal) Tree", or if the facet desi= gnator
was "vnt" or equivalent, I'd feel differently about this. =A0= But
"Personal or Vanity" does not require that anyone pay any
attention to the implicit "vanity" sub-branch, so the risks of making a change that might confuse people or require an
explanation seem to me to far outweigh the problems with the
existing text, problems that seem to be limited to offending the
tastes of several of us.

While this is really not = a matter of life and death, I think retaining the old name should be fine, = and so withdrawing my concern.
=A0

>> Section 3.4: this is what Julian has already mentioned for
>> Section 4.2. APPSAWG is obliged to bring the draft
>> deprecating x- to BCP, so if we revising the procedures docs,
>> we need to take it into account. I propose you remove Section
>> 3.4 and naming convention from Section 4.2 but put a note in
>> Appendix B referring to the RFC-to-be. <later when=3D"afte= r
>> reading reply to Julian's message">I think that if we = produce
>> new version of the doc we should take into account the
>> current practice documented as BCP (and I hope it will get
>> BCP). At least you should note that their registration is not
>> absolutely prohibited; I also agree that in exceptional cases
>> they can be registered, but only if wide use is
>> demonstrated.</later>
>
> First of all, the WG is in no way "obliged" to do anything. = It
> may in fact fail to reach consensus and not do anything about
> x-. =A0The draft in question is still being actively debated,
> and there appears to be some controversy. I'm waiting to see
> the outcome of that before taking any action on this point, as
> it's possible the whole x- thing may prove to be a lot more
> problematic than some suppose.

While I agree with Ned, I note that, in any event, the document
already discourages "x-" and "x." registrations. =A0The=
newly-proposed "deprecated alias" mechanism actually provides a path to get rid of the things, which may be far better (and, for
better or worse, more consistent with the spirit of the xdash
draft) than trying to set up criteria for "wide use" and then
enshrining them forever.

Yes, and so let's bet= ter wait for what appsawg 'x'-deprecating draft finishes in, and th= an see what we can do with this one.

Mykyta Yevstifeyev
=A0

>...

=A0 =A0john


--f46d0447f32abeeda204b8249ad2-- From ned.freed@mrochek.com Sat Feb 4 07:34:52 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 004D321F8569 for ; Sat, 4 Feb 2012 07:34:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGux2-SIJXrb for ; Sat, 4 Feb 2012 07:34:51 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 7580821F8568 for ; Sat, 4 Feb 2012 07:34:49 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OBL1YBZJTC00TKQD@mauve.mrochek.com> for apps-discuss@ietf.org; Sat, 4 Feb 2012 07:34:42 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OBHM72OXPS00ZUIL@mauve.mrochek.com>; Sat, 4 Feb 2012 07:34:38 -0800 (PST) Message-id: <01OBL1Y9HCI800ZUIL@mauve.mrochek.com> Date: Sat, 04 Feb 2012 07:13:06 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Sat, 04 Feb 2012 16:46:49 +0200" MIME-version: 1.0 Content-type: TEXT/PLAIN References: <20120204001408.16716.94710.idtracker@ietfa.amsl.com> <01OBKKTPYLIE00ZUIL@mauve.mrochek.com> To: Mykyta Yevstifeyev Cc: Ned Freed , apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-media-type-regs-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2012 15:34:52 -0000 > > > In Section 3.1: when specifying the procedures for registration media > > types > > > in Standards Tree, you mentioned (in terms of RFC 5226): IESG approval, > > > Specification Required, IETF Consensus, RFC Required with IESG Approval, > > > i.e. 4 different registration policies. Whereas they serve a variety of > > > possible cases, I think we would benefit from a single policy which would > > > cover all of them. I suppose it is "Specification Required with IESG > > > Approval" that would cover the following cases: (1) IESG-approved > > document, > > > (2) specification of other standards body; registration undergoing IESG > > > approval, (3) non-IESG-approved RFCs, registration of which also undergo > > > IESG approval. The possible cases may also be discussed, though. > > > > > MY> Also relevant in this version. > > > > If I understand what you're trying to do, not going to happen. The main > > point > > of this revision is to remove the need for the IESG to be involved in the > > approval of standards tree types from other SDOs, while retaining their > > role in > > IETF registration approval. As such, your suggestion for a single policy > > for > > all registrations is totally inconsistent with the fundamental goal of this > > revision. > > > I meant procedure for Standards Tree only, and in no way for all > registrations. The four policies I listed are mentioned in Section 3.1 > only, which defines Standards Tree procedures. But that's exactly the point. We're not talking about anything but standards tree registrations here. Yet there are two completely different processes for registering types in the standards tree. You appear to be asking for there to be only one, and having two is the entire point of this revision. Now, if you want to talk about there being a simpler or different set of criteria for or the other of those processes, then you're going to have to make a strong case for doing so. As it is I'm just not seeing any rationale for changing anything in section 3.1. > > > > > Section 6: s/RFC 3978/RFC 5378/ (and in References) > > > > > MY> This is fixed. > > > > > Sections 6 and 8: As your document sets up the registry for +suffixes, it > > > should contain the description as required by RFC 5226, which it > > currently > > > doesn't have. > > > > > MY> This comment still applies. > > > > Description where? I do not understand this one. I also do not see the > > requirement you're talking about anywhere in RFC 5226. (The word > > description > > appears exactly twice, and neither time in a requirement.) > > > I mean your description in Section 6 should follow Section 4.2 of RFC 5226. I don't actually see anything in RFC 5226 that says you have to define a registry using a particular layout in your document - all it says is that certain information has to be provided. And with one important exception, all of that information is currently present, just not in that format. That said, a thought occurs. This is a new registry that's not currently set up, and that means we need to call out the action to create it in the IANA considerations section of this document. So what I'm going to do is add that action to the IANA considerations, which will appear as a list more or less conforming to the list in section 4.2 of RFC 5226. (Most of the list items will simply be references to other sections of the current document.) The sticking point is the initial registry content. I really don't want to clutter up an important process specification that's intended to be used for a long period of time with this crap that's only useful once. (I've always objected to this requirement in RFC 5226 - I think it's excessive rigidity causes more problems than it solves.) So I'm going to try to finesse it by saying that an initial list of the content of the registry effectively already exists and is in IANA 's hands - it's the list of conforming suffixes in current use in the existing media types registry - and direct the media types reviewers to, at the time of registry creation, extract that list and use it as the initial registry content. This also addresses the possibility that an additional legitimate suffix should show up and get registered under the current rules, making having a static list in a document somewhat problematic. > > > > > --citing ends-- > > > > You might want to look at the open issues list and consider if they are > > good > > ideas or not. > > > Commenting on the 'open issues': > o The list of fields in the registration is getting long. Should > the fields be numbered and referred to by number in order to > facilitate translation into other languages and similar > activities? > Whereas I'm not a native English speaker, I can say that this won't help in > translation in any way (I can't imagine such way, at least). Also, what > are 'similar activities' here? Since this one is not my idea I'll let other folks respond. (It's entirely possible I failed to describe or justify it properly.) > o Currently anyone can register a vendor media type on behalf of a > vendor but subsequent to that only the vendor can make changes. > Do we want to retain this restriction? > I think we should allow registering vnd types by anyone with vendor's > approval (or by tacit agreement if vendor is ignoring the proposal), and to > change the registration in a similar way. That approach actually sounds pretty good to me. Let's see what others think. Ned From ned.freed@mrochek.com Sat Feb 4 08:02:41 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2438F21F8497 for ; Sat, 4 Feb 2012 08:02:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U7E75mIRh+mN for ; Sat, 4 Feb 2012 08:02:40 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 1921F21F8480 for ; Sat, 4 Feb 2012 08:02:40 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OBL2XV4SYO002PCO@mauve.mrochek.com> for apps-discuss@ietf.org; Sat, 4 Feb 2012 08:02:34 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OBHM72OXPS00ZUIL@mauve.mrochek.com>; Sat, 4 Feb 2012 08:02:30 -0800 (PST) Message-id: <01OBL2XS986200ZUIL@mauve.mrochek.com> Date: Sat, 04 Feb 2012 07:59:47 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Sat, 04 Feb 2012 09:05:05 -0500" MIME-version: 1.0 Content-type: TEXT/PLAIN References: <20120204001408.16716.94710.idtracker@ietfa.amsl.com> <01OBKKTPYLIE00ZUIL@mauve.mrochek.com> To: John C Klensin Cc: Ned Freed , apps-discuss@ietf.org Subject: Re: [apps-discuss] Requirement for "obsoletes" in Abstracts (was: Re: I-D Action: draft-ietf-appsawg-media-type-regs-00.txt) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2012 16:02:41 -0000 Initial response: *gulp* I obviously don't feel nearly as strongly about this as John does, although I completely agree with everything he says. So I'm going to defer to him entirely on this point. I won't add anything to the document at the present time and we'll see how it goes. And with that, I actually think it's time to post -01. It should be out in a few minutes. Ned > --On Friday, February 03, 2012 22:52 -0800 Ned Freed > wrote: > >... > >> In Abstract, it must be mentioned that the document obsoletes > >> RFC 4288. > > > > A stupid rule in my opinion, but a rule nevertheless. I forgot > > to add it but will do so in the next revision. > Actually, as co-author, I want to strongly resist this change > and therefore that putative rule (I claim that, independent of > its substantive properties, it is invalid; see below). I have > three separate reasons, any one of which would, IMO, justify > saying "no". > Rant follows. > (1) Abstracts are supposed to be about the content and function > of the document and are supposed to be as minimal as possible > while still covering the actual substance. Except in unusual > cases, which this is not, mentioning the history and > relationships of a document in the Abstract is not substantively > important to someone who is simply looking at it to find the > present state of things, as would be the case with this once it > is published. Worse, except for RFCs that are much better > known by their numbers than by their titles (there aren't many; > RFC 822 comes to mind as an example), good practice requires > citations on first use to explain what the number refers to. > But the RFC Editor's practice (and almost every style manual for > professional publications in the world) prohibits citations from > Abstracts -- they are supposed to stand on their own. Things > might be different if the sole purpose of a document were to > obsolete or reclassify another one, but that does not apply in > this case. > That may be a very long way of saying "stupid rule". > (2) Determination of what should be required or permitted in > Abstracts in published RFCs has always been an RFC Editor > matter, not something the IESG can change, any more than they > can unilaterally change page header or footer formats. Note > that we already have a header on the first page (almost always > the same pages as the abstract since we fixed the "boilerplate > first" problem), so, stylistically, there is a "how much > overkill is needed" question. FWIW, I don't have any problem > with the IESG imposing an "explain what this updates and why" > requirement on the body of a document, although I believe even > then that they ought to have a discussion with the RFC Editor > about placement (e.g., Introduction versus separate section or > subsection). > I believe that the "Status of Document" section of IETF Stream > RFCs basically belongs to the IETF and IESG, so, if the IESG > wants some particular "obsoletes XXX" text there, I might still > think it was stupid, but I wouldn't consider it nearly as > inappropriate as imposing requirements on the abstract. In > addition, I think the IESG, subject to community review, can > impose whatever requirements they think necessary on I-Ds to get > effective review of documents. I think the rule requiring that > all IETF Stream I-Ds contain an "IANA Considerations" section > that can be removed on publication is ill-advised and have seen > a number of problems that can be attributed to the rule itself. > But, if the IESG, after careful deliberation, is convinced that > it is helpful to the review and consensus process, I'm ok with > it and will conform without saying much of anything. The same > principle might apply here: if the IESG wants to say, e.g., that > obsoleting or reclassification relationships should be reflected > in an extra paragraph of the Abstract that is removed on > publication and hence not subject to the RFC Editor's rules > about length and content, I'll mutter into my beard, but will > comply. > (3) Although they can make suggestions and determine their own > practices, the IESG doesn't get to invent and make binding rules > for the community. The Tools Team may incorporate what they > consider reasonable practices into checking tools (I'm strongly > in favor of that, actually), but that doesn't make those > practices binding on the community either. In both cases, the > difference between "strong suggestion" and "requirement" has > always been community consensus. That hasn't occurred here -- > there has been no document for which community discussion has > occurred and consensus sought. What we have is > (i) a statement in Section 3(1)(D) of the I-D checklist > http://www.ietf.org/id-info/checklist.html (a fine > document if taken as strong suggestions) > (ii) a check in the the I-D nits tool. > (iii) a few statements, e.g., in the checklist itself > and the Shepherd template that effectively make the > above normative. > There has not been an explicit consensus call on this > requirement in on any of the above contexts. > In the interest of efficiency, I'm even ok if the IESG sets > requirements and puts them into effect immediately, issuing > formal consensus calls only later or if there are objections > from the community. Well, I'm objecting, I have objected in the > past, and, while the the IESG hasn't issued a consensus call, > they have published Standards Track documents in the IETF Stream > that do not contain "obsoleting" information in the abstract. > And, again, even if the IESG asked for community consensus and > got it, it isn't clear that they can impose requirements on the > content of abstracts without the concurrence of the RFC Editor. > john-the-grump > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From internet-drafts@ietf.org Sat Feb 4 08:10:53 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3020A21F8548; Sat, 4 Feb 2012 08:10:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wvxjO5VId1Eh; Sat, 4 Feb 2012 08:10:52 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FDBB21F850C; Sat, 4 Feb 2012 08:10:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120204161045.23306.29095.idtracker@ietfa.amsl.com> Date: Sat, 04 Feb 2012 08:10:45 -0800 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-media-type-regs-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2012 16:10:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Worki= ng Group of the IETF. Title : Media Type Specifications and Registration Procedures Author(s) : Ned Freed John C. Klensin Tony Hansen Filename : draft-ietf-appsawg-media-type-regs-01.txt Pages : 29 Date : 2012-02-04 This document defines procedures for the specification and registration of media types for use in HTTP, MIME and other Internet protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-appsawg-media-type-regs-01.t= xt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-appsawg-media-type-regs-01.txt From barryleiba.mailing.lists@gmail.com Sat Feb 4 10:12:47 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA7721F84F6 for ; Sat, 4 Feb 2012 10:12:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.951 X-Spam-Level: X-Spam-Status: No, score=-102.951 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5AHA-nr+yPG for ; Sat, 4 Feb 2012 10:12:46 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id A252C21F84F5 for ; Sat, 4 Feb 2012 10:12:46 -0800 (PST) Received: by ggnq2 with SMTP id q2so2715264ggn.31 for ; Sat, 04 Feb 2012 10:12:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=fHyBPctDRvwRP1Arc3PAbVRHu8qUmMRHY/eXASpd1Dk=; b=o8loXFvJuWNCWKpqTAXTMv8RBgwguJsTq5Hu6dw3pRAVley9+ulA4KwFMCkeolol43 uRiDJFq+uUm/WUAVFqfIPI0LwISNVEvvlsD9OXGLoPVCDW/mkwH8wjDicfpVRAfDO+uW Ri1mtPerOMN05U8pFNeubIk8SLyV9JpN+3aJY= MIME-Version: 1.0 Received: by 10.101.141.9 with SMTP id t9mr5210149ann.42.1328379166194; Sat, 04 Feb 2012 10:12:46 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.146.136.20 with HTTP; Sat, 4 Feb 2012 10:12:46 -0800 (PST) In-Reply-To: References: <20120204001408.16716.94710.idtracker@ietfa.amsl.com> <01OBKKTPYLIE00ZUIL@mauve.mrochek.com> Date: Sat, 4 Feb 2012 13:12:46 -0500 X-Google-Sender-Auth: HS4vxEI9qLDDEVt1i-PqkG7gJB8 Message-ID: From: Barry Leiba To: John C Klensin Content-Type: multipart/alternative; boundary=0016e6d3cf1a53fd6204b8276059 Cc: Ned Freed , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Requirement for "obsoletes" in Abstracts (was: Re: I-D Action: draft-ietf-appsawg-media-type-regs-00.txt) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2012 18:12:47 -0000 --0016e6d3cf1a53fd6204b8276059 Content-Type: text/plain; charset=ISO-8859-1 >> A stupid rule in my opinion, but a rule nevertheless. I forgot >> to add it but will do so in the next revision. > > Actually, as co-author, I want to strongly resist this change > and therefore that putative rule (I claim that, independent of > its substantive properties, it is invalid; see below). I have > three separate reasons, any one of which would, IMO, justify > saying "no". Contrary to John's rant (which, dont you know, I was shocked to see, shocked, I tell you), the IESG does not treat this as a hard-and-fast rule, but, in fact, more as a "strong recommendation". ADs normally don't use DISCUSS to comment on this, but non-blocking COMMENT. And the PROTO writeup can call it out and say that it's intended this way. Either Alexey or I will shepherd this. I, for one, am happy to call this out in he writeup. Barry, as chair --0016e6d3cf1a53fd6204b8276059 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >> A stupid rule in my opinion, but a rule nevertheless. I forgot
= >> to add it but will do so in the next revision.
>
> Act= ually, as co-author, I want to strongly resist this change
> and ther= efore that putative rule (I claim that, independent of
> its substantive properties, it is invalid; see below). =A0 I have
&= gt; three separate reasons, any one of which would, IMO, justify
> sa= ying "no".

Contrary to John's rant (which, dont you kn= ow, I was shocked to see, shocked, I tell you), the IESG does not treat thi= s as a hard-and-fast rule, but, in fact, more as a "strong recommendat= ion". =A0ADs normally don't use DISCUSS to comment on this, but no= n-blocking COMMENT. =A0And the PROTO writeup can call it out and say that i= t's intended this way.

Either Alexey or I will shepherd this. =A0I, for one, am happy to call = this out in he writeup.

Barry, as chair
--0016e6d3cf1a53fd6204b8276059-- From fielding@gbiv.com Sat Feb 4 16:42:12 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81FC121F8504 for ; Sat, 4 Feb 2012 16:42:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.799 X-Spam-Level: X-Spam-Status: No, score=-106.799 tagged_above=-999 required=5 tests=[AWL=-4.200, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZRq2sL2qDQgg for ; Sat, 4 Feb 2012 16:42:12 -0800 (PST) Received: from homiemail-a30.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id F33C121F84FF for ; Sat, 4 Feb 2012 16:42:11 -0800 (PST) Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id A74A521DE58; Sat, 4 Feb 2012 16:42:11 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gbiv.com; h=subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to; q=dns; s=gbiv.com; b=bTw3NANh1osU6non aDe5eNY3XzJNXhYBDc8vWX+JXlqcE5dapardPYgKMjJUl9Z5JQeX2sdHfHjSBKK+ gudvh1lSpwqz4NSuOpgXmRxDxagd/lLhdcFMJhtf5L6RoYLCTFqc699X87pq8GAL CbLXWUwO78vsWgvMpXrP5RDLoQU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=1IsLtAqZfU0kSMUNGcPE6BzcLos=; b=E02lol/ID7IYNXtwS12jchy75NL+ amfzLLK8svQzFmPnjLujMvkPY9mDM7q466BVoMAP9RGbU/91ds3JHeVeYNxJESns PiGcQugoyAeLs+pnIgFOPYAKop1/nkYD6JD24O93Rnke1l3framlm82ezyPrba1Y REVWzC3P1k1J6zA= Received: from [192.168.1.84] (99-21-208-82.lightspeed.irvnca.sbcglobal.net [99.21.208.82]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTPSA id 8916221DE56; Sat, 4 Feb 2012 16:42:11 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: "Roy T. Fielding" In-Reply-To: Date: Sat, 4 Feb 2012 16:42:17 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <37E2E68B-23F6-4722-B7DC-444FA50D1E62@gbiv.com> References: <20120204001408.16716.94710.idtracker@ietfa.amsl.com> <01OBKKTPYLIE00ZUIL@mauve.mrochek.com> To: IETF Apps Discuss X-Mailer: Apple Mail (2.1257) Subject: Re: [apps-discuss] Requirement for "obsoletes" in Abstracts (was: Re: I-D Action: draft-ietf-appsawg-media-type-regs-00.txt) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2012 00:42:12 -0000 +1 to John's rant. I really hate all of the useless status bits that we = have in the abstracts for HTTPbis. People who read the document five years = from now don't care how many older RFCs it updates or obsoletes. They belong in the Introduction, where we describe the history of the = protocol. ....Roy= From ned.freed@mrochek.com Sat Feb 4 16:51:08 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAB4A21F850D for ; Sat, 4 Feb 2012 16:51:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MrjPfxTK23AO for ; Sat, 4 Feb 2012 16:51:08 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id DB32021F844B for ; Sat, 4 Feb 2012 16:51:07 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OBLLE439TC0164H6@mauve.mrochek.com> for apps-discuss@ietf.org; Sat, 4 Feb 2012 16:51:04 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OBHM72OXPS00ZUIL@mauve.mrochek.com>; Sat, 4 Feb 2012 16:50:59 -0800 (PST) Message-id: <01OBLLE13ULY00ZUIL@mauve.mrochek.com> Date: Sat, 04 Feb 2012 16:42:07 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Fri, 16 Dec 2011 12:47:09 -0700" <4EEBA03D.7000906@stpeter.im> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <4EEBA03D.7000906@stpeter.im> To: Peter Saint-Andre Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [happiana] comments on draft-freed-media-type-regs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2012 00:51:09 -0000 I've been reviewing past comments on the draft and realized I had missed this one that was originally posted to the HAPPIANA list. > > Overall this looks quite good and is an improvement over RFC 4288. > Thanks to the authors for working on this. > I have a few small comments. > 1. Non-Commercial Producers > Section 3.2 says: > "Vendor" or "producer" are construed as > equivalent and very broadly in this context. > Section 3.3 says: > Registrations for media types created experimentally or as part of > products that are not distributed commercially may be registered in > the personal or vanity tree. > What about products that are distributed non-commercially, such as > open-source software. Should the registrant use "vnd." or "prs."? vnd. definitely. We already added text about industry consortia using the vnd. tree but it is worth adding non-commercial to that. It will be in the next revision. > IMHO it would be better to define vendor/producer broadly enough to > include non-commercial organizations. Agreed. > 2. Owners > Sections 3.1 and 3.3 define the "owner" for a registration: > The "owner" of a media type registration in the standards tree is > assumed to be the standards body itself. > The owner of "personal" registrations and associated specifications > is the person or entity making the registration, or one to whom > responsibility has been transferred as described below. > As far as I can see, such a definition is not provided for the vendor > tree (despite the claim in Section 5.8). Thus arises the question: are > third-party registrations allowed? I think they should be. This is currently on the open issues list. > 3. The "x." Tree > Section 3.4 is somewhat at odds with draft-ietf-appsawg-xdash, which > deprecates use of "x-" and similar constructions in application > protocols. I doubt that we still need a special tree here. See also the > naming restrictions in Section 4.2. I would be happy to discuss this > further or propose text if desired. Per my previous response, I'm taking a wait-and-see position on this one for now. My preference would be to leave x. alone (it's never seen any real use AFAIK) but remove the special status for x- entirely. But let's see how the consensus develops. > 4. "charset" > Section 4.1 mentions things that are not media formats but charsets. > Just to be sure, do we actually mean charset instead of one of the other > terms (e.g., "character encoding") from BCP 166? Absolutely not. Charset is the correct term to use here. For one thing, neither character encoding nor coded character by themselves suffice to define a complete way to encode characters as text - you have to combine them. And even if you do, there are charsets that are defined in other ways. Charset really is the most general term as it is defined as a mapping of octets to characters. > 5. Encodings > When mentioning "7bit US-ASCII text", perhaps reference RFC 5198. Er, no. RFC 5198 doesn't even mention US-ASCII. And the Unicode format it defines is 8bit, not 7bit! > 6. Submission to the IESG > One topic we've discussed on and off is removing the IESG bottleneck for > standards-tree registrations, enabling other SDOs to directly submit > their registration requests to the IANA for review by the IESG (rather > than having the SDO's initial contact be to the IESG). I don't think > we've quite reached consensus on that approach, but I think we should do > so before draft-freed-media-type-regs is approved. Of course this is the entire focus of the most recent revision; any feedback on how it has been implemented would be appreciated. Ned From john-ietf@jck.com Sat Feb 4 17:08:30 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8948D21F84B6 for ; Sat, 4 Feb 2012 17:08:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fXM5LlbJFGRq for ; Sat, 4 Feb 2012 17:08:29 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 7952321F8487 for ; Sat, 4 Feb 2012 17:08:29 -0800 (PST) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1RtqX8-000G8s-CA; Sat, 04 Feb 2012 20:04:46 -0500 Date: Sat, 04 Feb 2012 20:08:23 -0500 From: John C Klensin To: "Roy T. Fielding" , IETF Apps Discuss Message-ID: In-Reply-To: <37E2E68B-23F6-4722-B7DC-444FA50D1E62@gbiv.com> References: <20120204001408.16716.94710.idtracker@ietfa.amsl.com> <01OBKKTPYLIE00ZUIL@mauve.mrochek.com> <37E2E68B-23F6-4722-B7DC-444FA50D1E62@gbiv.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [apps-discuss] Requirement for "obsoletes" in Abstracts (was: Re: I-D Action: draft-ietf-appsawg-media-type-regs-00.txt) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2012 01:08:30 -0000 --On Saturday, February 04, 2012 16:42 -0800 "Roy T. Fielding" wrote: > +1 to John's rant. I really hate all of the useless status > bits that we have in the abstracts for HTTPbis. People who > read the document five years from now don't care how many > older RFCs it updates or obsoletes. Yes. Remember that someone who already knows that RFC 9999 is a protocol spec, and the one they are looking for, probably won't even look at the abstract. The abstract is much more likely to be useful to people who are trying to figure out if they have the right spec or should keep looking, and a sentence that says "This obsoletes RFC NNNN." is of even less use to them. > They belong in the Introduction, where we describe the history > of the protocol. Lest we substitute one bad rule for another, I wish the above paragraph had said "They belong wherever we describe the history of the protocol". Sometimes -- I'd even guess "usually" -- that should be the Introduction (sometimes a separate subsection of the Introduction), but sometimes it should be a separate section of the document, an appendix, or even another document with a clear citation and reference from the protocol spec. Even though I recognize the advantages to the community of always having particular kinds of text in particular places or order, that really ought to be a matter of editorial judgment (with or without advice about defaults and preferences) rather than one of rigid-appearing rules. john From evnikita2@gmail.com Sat Feb 4 22:04:32 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88D1C21F8526 for ; Sat, 4 Feb 2012 22:04:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.622 X-Spam-Level: X-Spam-Status: No, score=-3.622 tagged_above=-999 required=5 tests=[AWL=-0.024, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zgTsZen9dEL for ; Sat, 4 Feb 2012 22:04:31 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id D4E0521F8514 for ; Sat, 4 Feb 2012 22:04:30 -0800 (PST) Received: by obbwd15 with SMTP id wd15so6921351obb.31 for ; Sat, 04 Feb 2012 22:04:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=0nRHTqj3evLZzkuVVjttnDoVRLV9m3sr7nUskbx8Rr4=; b=QGCD69HACE9myX2wHanwmaNRTMw1RQJCqYF7tZ3FXgjf+MlmBO92bp8riT9mRIsOwk 7ZI05FGg5vjiqrvzntVIzdTr/APISVmac+d3d0nS88300Q03gaakq/U8qZN0Ik2BMsh4 iiUKPA/mRETFyxB2GVnxSBUMSLBne5AOPaqc0= MIME-Version: 1.0 Received: by 10.182.144.68 with SMTP id sk4mr12449987obb.4.1328421870420; Sat, 04 Feb 2012 22:04:30 -0800 (PST) Received: by 10.182.213.71 with HTTP; Sat, 4 Feb 2012 22:04:30 -0800 (PST) Date: Sun, 5 Feb 2012 08:04:30 +0200 Message-ID: From: Mykyta Yevstifeyev To: Ned Freed Content-Type: multipart/alternative; boundary=14dae9399ce7b2c21e04b8315186 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-media-type-regs-00.txt; now -01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2012 06:04:32 -0000 --14dae9399ce7b2c21e04b8315186 Content-Type: text/plain; charset=ISO-8859-1 2012/2/4 Ned Freed > > > > In Section 3.1: when specifying the procedures for registration media > > > types > > > > in Standards Tree, you mentioned (in terms of RFC 5226): IESG > approval, > > > > Specification Required, IETF Consensus, RFC Required with IESG > Approval, > > > > i.e. 4 different registration policies. Whereas they serve a variety > of > > > > possible cases, I think we would benefit from a single policy which > would > > > > cover all of them. I suppose it is "Specification Required with IESG > > > > Approval" that would cover the following cases: (1) IESG-approved > > > document, > > > > (2) specification of other standards body; registration undergoing > IESG > > > > approval, (3) non-IESG-approved RFCs, registration of which also > undergo > > > > IESG approval. The possible cases may also be discussed, though. > > > > > > > MY> Also relevant in this version. > > > > > > If I understand what you're trying to do, not going to happen. The main > > > point > > > of this revision is to remove the need for the IESG to be involved in > the > > > approval of standards tree types from other SDOs, while retaining their > > > role in > > > IETF registration approval. As such, your suggestion for a single > policy > > > for > > > all registrations is totally inconsistent with the fundamental goal of > this > > > revision. > > > > > > I meant procedure for Standards Tree only, and in no way for all > > registrations. The four policies I listed are mentioned in Section 3.1 > > only, which defines Standards Tree procedures. > > But that's exactly the point. We're not talking about anything but > standards > tree registrations here. Yet there are two completely different processes > for > registering types in the standards tree. You appear to be asking for there > to > be only one, and having two is the entire point of this revision. > > Now, if you want to talk about there being a simpler or different set of > criteria for or the other of those processes, then you're going to have to > make > a strong case for doing so. As it is I'm just not seeing any rationale for > changing anything in section 3.1. > Mow, reading Section 3.1 of -01, I notice several inconsistencies with the above position and between some of the document's parts. I mean: 1) The standards tree is intended for types of general interest to the Internet community. Registrations in the standards tree MUST be either: ... 2. registered by a recognized standards body using the "Specification Required" IANA registration policy [RFC5226] (which implies Expert Review). And later, you say: In the second case the IESG makes the decision on whether the registration submitter represents a recognized standards body; So, anyway, IESG isn't fully eliminated from this process, as they are to decide on whether some SDO is 'recognized' standards body or not. The Expert Reviewer is IESG's representative, and so I don't know the reasons to make IESG decide on 'recognized' bodies. Additionally, in Section 8 you ask IANA to maintain a list of IESG-recognized standards bodies who are allowed to register types in the standards tree. and give no other provisions on this. Is this going to be a registry or something else, and how is it going to be filled in? Does this mean that once IESG allowed some SDO to register their media type in Standards Tree, IANA will automatically add this SDO to the list? Or something else? 2) Registrations published in non-IETF RFC streams are allowed and require IESG approval. I don't have an idea of what "are allowed" means? Are they to undergo this review depending on whether their authors see it necessary? Doesn't this fall into the second case for registrations in Standards Tree? 3) Standards-tree registrations from recognized standards bodies may be submitted directly to the IANA, where they will undergo Expert Review [RFC5226] prior to approval. In this case, the Expert Reviewer(s) will, among other things, ensure that the required specification provides adequate documentation. Doesn't this conflict with the paragraph mentioned above in 1) about IESG's decision on 'recognizedness' of SDO? Summary. The page-long description of the procedures for Standards Tree registration will help nobody in registering media types in this tree. I like RFC 4288 description, and RFC 2048 description, which only contained three paragraphs which stated these registrations must be approved by IESG. Now, if you want to allow other SDO to register their types without IESG's approval, that's easy to do by only adding a few words, so stating that IETF-sourced and grandfathered registrations in Standards Tree are subject to IESG's approval of the document registering them (and this means RFC 5226 IETF consensus) and registrations ibid which originate from other SDOs are subject to Expert Review who will also review and ensure appropriate level of documentation (and this means RFC 5226 Specification Required). Also it may be stated that non-IETF-stream RFCs may register Standards Tree types with IESG's approval (that's actually what you now have, but "are allowed" has already been commented on above). > > > > > > > > Section 6: s/RFC 3978/RFC 5378/ (and in References) > > > > > > > MY> This is fixed. > > > > > > > Sections 6 and 8: As your document sets up the registry for > +suffixes, it > > > > should contain the description as required by RFC 5226, which it > > > currently > > > > doesn't have. > > > > > > > MY> This comment still applies. > > > > > > Description where? I do not understand this one. I also do not see the > > > requirement you're talking about anywhere in RFC 5226. (The word > > > description > > > appears exactly twice, and neither time in a requirement.) > > > > > > I mean your description in Section 6 should follow Section 4.2 of RFC > 5226. > > I don't actually see anything in RFC 5226 that says you have to define > a registry using a particular layout in your document - all it says is that > certain information has to be provided. And with one important exception, > all of that information is currently present, just not in that format. > > That said, a thought occurs. This is a new registry that's not currently > set up, and that means we need to call out the action to create it in the > IANA considerations section of this document. So what I'm going to do is > add that action to the IANA considerations, which will appear as a list > more or less conforming to the list in section 4.2 of RFC 5226. (Most of > the list items will simply be references to other sections of the > current document.) > I wasn't talking about the layout. You could freely describe the registry in Section 6 and then reference it later in Section 8. But I meant you didn't mention RFC 5226 specification policy for this registry, as well as its name (now mentioned). You may add some paragraph to Section 6.1 stating that this document creates the registry called "Structured Syntax Suffix" and the registration policy is "Expert Review" with the registration process spelled out below. Additionally, the structure (fields to be present in the registry itself) are to be defined. > > The sticking point is the initial registry content. I really don't want to > clutter up an important process specification that's intended to be used > for a > long period of time with this crap that's only useful once. (I've always > objected to this requirement in RFC 5226 - I think it's excessive rigidity > causes more problems than it solves.) So I'm going to try to finesse it by > saying that an initial list of the content of the registry effectively > already > exists and is in IANA 's hands - it's the list of conforming suffixes in > current use in the existing media types registry - and direct the media > types > reviewers to, at the time of registry creation, extract that list and use > it as > the initial registry content. This also addresses the possibility that an > additional legitimate suffix should show up and get registered under the > current rules, making having a static list in a document somewhat > problematic. > I think upon approval of the document Expert Reviewer will examine the currently used ones, and we'll be able to publish a separate document registering them. > > > > > > > > --citing ends-- > > > > > > You might want to look at the open issues list and consider if they are > > > good > > > ideas or not. > > > > > > Commenting on the 'open issues': > > > o The list of fields in the registration is getting long. Should > > the fields be numbered and referred to by number in order to > > facilitate translation into other languages and similar > > activities? > > > Whereas I'm not a native English speaker, I can say that this won't help > in > > translation in any way (I can't imagine such way, at least). Also, what > > are 'similar activities' here? > > Since this one is not my idea I'll let other folks respond. (It's entirely > possible I failed to describe or justify it properly.) > > > o Currently anyone can register a vendor media type on behalf of a > > vendor but subsequent to that only the vendor can make changes. > > Do we want to retain this restriction? > > > I think we should allow registering vnd types by anyone with vendor's > > approval (or by tacit agreement if vendor is ignoring the proposal), and > to > > change the registration in a similar way. > > That approach actually sounds pretty good to me. Let's see what others > think. > > Ned > --14dae9399ce7b2c21e04b8315186 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
2012/2/4 Ned Freed <ned.freed@mrochek.com>
> > > In Section 3.1: when specifying the procedures for registrat= ion media
> > types
> > > in Standards Tree, you mentioned (in terms of RFC 5226): IES= G approval,
> > > Specification Required, IETF Consensus, RFC Required with IE= SG Approval,
> > > i.e. 4 different registration policies. Whereas they serve a= variety of
> > > possible cases, I think we would benefit from a single polic= y which would
> > > cover all of them. I suppose it is "Specification Requi= red with IESG
> > > Approval" that would cover the following cases: (1) IES= G-approved
> > document,
> > > (2) specification of other standards body; registration unde= rgoing IESG
> > > approval, (3) non-IESG-approved RFCs, registration of which = also undergo
> > > IESG approval. The possible cases may also be discussed, tho= ugh.
> >
> > > MY> Also relevant in this version.
> >
> > If I understand what you're trying to do, not going to happen= . The main
> > point
> > of this revision is to remove the need for the IESG to be involve= d in the
> > approval of standards tree types from other SDOs, while retaining= their
> > role in
> > IETF registration approval. As such, your suggestion for a single= policy
> > for
> > all registrations is totally inconsistent with the fundamental go= al of this
> > revision.
> >

> I meant procedure for Standards Tree only, and in no way for all
> registrations. =A0The four policies I listed are mentioned in Section = 3.1
> only, which defines Standards Tree procedures.

But that's exactly the point. We're not talking about anything but = standards
tree registrations here. Yet there are two completely different processes f= or
registering types in the standards tree. You appear to be asking for there = to
be only one, and having two is the entire point of this revision.

Now, if you want to talk about there being a simpler or different set of criteria for or the other of those processes, then you're going to have= to make
a strong case for doing so. As it is I'm just not seeing any rationale = for
changing anything in section 3.1.

Mow, reading Sec= tion 3.1 of -01, I notice several inconsistencies w= ith the above position and between some of the document's parts.=A0 I m= ean:

1)

=A0=A0 The standards tree is intended for types of general in= terest to the
=A0=A0 Internet community.=A0 Registrations in the standar= ds tree MUST be
=A0=A0 either:
=A0=A0 ...
=A0=A0 2.=A0 registered = by a recognized standards body using the
=A0=A0=A0=A0=A0=A0 "Specification Required" IANA registration pol= icy [RFC5226]
=A0=A0=A0=A0=A0=A0 (which implies Expert Review).

A= nd later, you say:

=A0=A0 In the second case the IESG makes the deci= sion on whether the
=A0=A0 registration submitter represents a recognized standards body;

So, anyway, IESG isn't fully eliminated from this process, as they = are to decide on whether some SDO is 'recognized' standards body or= not.=A0 The Expert Reviewer is IESG's representative, and so I don'= ;t know the reasons to make IESG decide on 'recognized' bodies.=A0 = Additionally, in Section 8 you ask IANA to

=A0=A0 maintain a list of IESG-recognized standards bodies who are
= =A0=A0 allowed to register types in the standards tree.

and give no = other provisions on this.=A0 Is this going to be a registry or something el= se, and how is it going to be filled in?=A0 Does this mean that once IESG a= llowed some SDO to register their media type in Standards Tree, IANA will a= utomatically add this SDO to the list?=A0 Or something else?

2)

=A0=A0 Registrations published in non-IETF RFC streams are al= lowed and
=A0=A0 require IESG approval.

I don't have an idea = of what "are allowed" means?=A0 Are they to undergo this review d= epending on whether their authors see it necessary?=A0 Doesn't this fal= l into the second case for registrations in Standards Tree?

3)

=A0=A0 Standards-tree registrations from recognized standards= bodies may be
=A0=A0 submitted directly to the IANA, where they will un= dergo Expert Review
=A0=A0 [RFC5226] prior to approval.=A0 In this case,= the Expert Reviewer(s)
=A0=A0 will, among other things, ensure that the required specification
= =A0=A0 provides adequate documentation.

Doesn't this conflict wi= th the paragraph mentioned above in 1) about IESG's decision on 're= cognizedness' of SDO?

Summary.=A0 The page-long description of the procedures for Standards T= ree registration will help nobody in registering media types in this tree.= =A0 I like RFC 4288 description, and RFC 2048 description, which only conta= ined three paragraphs which stated these registrations must be approved by = IESG.=A0 Now, if you want to allow other SDO to register their types withou= t IESG's approval, that's easy to do by only adding a few words, so= stating that IETF-sourced and grandfathered registrations in Standards Tre= e are subject to IESG's approval of the document registering them (and = this means RFC 5226 IETF consensus) and registrations ibid which originate = from other SDOs are subject to Expert Review who will also review and ensur= e appropriate level of documentation (and this means RFC 5226 Specification= Required).=A0 Also it may be stated that non-IETF-stream RFCs may register= Standards Tree types with IESG's approval (that's actually what yo= u now have, but "are allowed" has already been commented on above= ).
=A0

> >
> > > Section 6: s/RFC 3978/RFC 5378/ (and in References)
> >
> > > MY> This is fixed.
> >
> > > Sections 6 and 8: As your document sets up the registry for = +suffixes, it
> > > should contain the description as required by RFC 5226, whic= h it
> > currently
> > > doesn't have.
> >
> > > MY> This comment still applies.
> >
> > Description where? I do not understand this one. I also do not se= e the
> > requirement you're talking about anywhere in RFC 5226. (The w= ord
> > description
> > appears exactly twice, and neither time in a requirement.)
> >

> I mean your description in Section 6 should follow Section 4.2 of RFC = 5226.

I don't actually see anything in RFC 5226 that says you have to define<= br> a registry using a particular layout in your document - all it says is that=
certain information has to be provided. And with one important exception, all of that information is currently present, just not in that format.

That said, a thought occurs. This is a new registry that's not currentl= y
set up, and that means we need to call out the action to create it in the IANA considerations section of this document. So what I'm going to do i= s
add that action to the IANA considerations, which will appear as a list
more or less conforming to the list in section 4.2 of RFC 5226. (Most of the list items will simply be references to other sections of the
current document.)

I wasn't talking about the = layout.=A0 You could freely describe the registry in Section 6 and then ref= erence it later in Section 8.=A0 But I meant you didn't mention RFC 522= 6 specification policy for this registry, as well as its name (now mentione= d).=A0 You may add some paragraph to Section 6.1 stating that this document= creates the registry called "Structured Syntax Suffix" and the r= egistration policy is "Expert Review" with the registration proce= ss spelled out below.=A0 Additionally, the structure (fields to be present = in the registry itself) are to be defined.
=A0

The sticking point is the initial registry content. I really don't want= =A0to
clutter up an important process specification that's intended to be use= d for a
long period of time with this crap that's only useful once. (I've a= lways
objected to this requirement in RFC 5226 - I think it's excessive rigid= ity
causes more problems than it solves.) So I'm going to try to finesse it= by
saying that an initial list of the content of the registry effectively alre= ady
exists and is in IANA 's hands - it's the list of conforming suffix= es in
current use in the existing media =A0types registry - and direct the media = types
reviewers to, at the time of registry creation, extract that list and use i= t as
the initial registry content. This also addresses the possibility that an additional legitimate suffix should show up and get registered under the current rules, making having a static list in a document somewhat problemat= ic.

I think upon approval of the document Expert R= eviewer will examine the currently used ones, and we'll be able to publ= ish a separate document registering them.
=A0

> >
> > > --citing ends--
> >
> > You might want to look at the open issues list and consider if th= ey are
> > good
> > ideas or not.
> >

> Commenting on the 'open issues':

> =A0 =A0o =A0The list of fields in the registration is getting long. = =A0Should
> =A0 =A0 =A0 the fields be numbered and referred to by number in order = to
> =A0 =A0 =A0 facilitate translation into other languages and similar > =A0 =A0 =A0 activities?

> Whereas I'm not a native English speaker, I can say that this won&= #39;t help in
> translation in any way (I can't imagine such way, at least). =A0Al= so, what
> are 'similar activities' here?

Since this one is not my idea I'll let other folks respond. (It's e= ntirely
possible I failed to describe or justify it properly.)

> =A0 =A0o =A0Currently anyone can register a vendor media type on behal= f of a
> =A0 =A0 =A0 vendor but subsequent to that only the vendor can make cha= nges.
> =A0 =A0 =A0 Do we want to retain this restriction?

> I think we should allow registering vnd types by anyone with vendor= 9;s
> approval (or by tacit agreement if vendor is ignoring the proposal), a= nd to
> change the registration in a similar way.

That approach actually sounds pretty good to me. Let's see what others = think.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Ned

--14dae9399ce7b2c21e04b8315186-- From ned.freed@mrochek.com Sat Feb 4 22:39:49 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABAEE21F853E for ; Sat, 4 Feb 2012 22:39:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wzEsvl5i5gCc for ; Sat, 4 Feb 2012 22:39:48 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 95B1821F853A for ; Sat, 4 Feb 2012 22:39:47 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OBLXKCFCWW000AOM@mauve.mrochek.com> for apps-discuss@ietf.org; Sat, 4 Feb 2012 22:39:41 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OBHM72OXPS00ZUIL@mauve.mrochek.com>; Sat, 4 Feb 2012 22:39:36 -0800 (PST) Message-id: <01OBLXK8STQ600ZUIL@mauve.mrochek.com> Date: Sat, 04 Feb 2012 22:14:59 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Sun, 05 Feb 2012 08:04:30 +0200" MIME-version: 1.0 Content-type: TEXT/PLAIN References: To: Mykyta Yevstifeyev Cc: Ned Freed , apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-media-type-regs-00.txt; now -01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2012 06:39:49 -0000 > 2012/2/4 Ned Freed > > > > > In Section 3.1: when specifying the procedures for registration media > > > > types > > > > > in Standards Tree, you mentioned (in terms of RFC 5226): IESG > > approval, > > > > > Specification Required, IETF Consensus, RFC Required with IESG > > Approval, > > > > > i.e. 4 different registration policies. Whereas they serve a variety > > of > > > > > possible cases, I think we would benefit from a single policy which > > would > > > > > cover all of them. I suppose it is "Specification Required with IESG > > > > > Approval" that would cover the following cases: (1) IESG-approved > > > > document, > > > > > (2) specification of other standards body; registration undergoing > > IESG > > > > > approval, (3) non-IESG-approved RFCs, registration of which also > > undergo > > > > > IESG approval. The possible cases may also be discussed, though. > > > > > > > > > MY> Also relevant in this version. > > > > > > > > If I understand what you're trying to do, not going to happen. The main > > > > point > > > > of this revision is to remove the need for the IESG to be involved in > > the > > > > approval of standards tree types from other SDOs, while retaining their > > > > role in > > > > IETF registration approval. As such, your suggestion for a single > > policy > > > > for > > > > all registrations is totally inconsistent with the fundamental goal of > > this > > > > revision. > > > > > > > > > I meant procedure for Standards Tree only, and in no way for all > > > registrations. The four policies I listed are mentioned in Section 3.1 > > > only, which defines Standards Tree procedures. > > > > But that's exactly the point. We're not talking about anything but > > standards > > tree registrations here. Yet there are two completely different processes > > for > > registering types in the standards tree. You appear to be asking for there > > to > > be only one, and having two is the entire point of this revision. > > > > Now, if you want to talk about there being a simpler or different set of > > criteria for or the other of those processes, then you're going to have to > > make > > a strong case for doing so. As it is I'm just not seeing any rationale for > > changing anything in section 3.1. > > > Mow, reading Section 3.1 of -01, I notice several inconsistencies with the > above position and between some of the document's parts. I mean: > 1) > The standards tree is intended for types of general interest to the > Internet community. Registrations in the standards tree MUST be > either: > ... > 2. registered by a recognized standards body using the > "Specification Required" IANA registration policy [RFC5226] > (which implies Expert Review). > And later, you say: > In the second case the IESG makes the decision on whether the > registration submitter represents a recognized standards body; > So, anyway, IESG isn't fully eliminated from this process, as they are to > decide on whether some SDO is 'recognized' standards body or not. The > Expert Reviewer is IESG's representative, and so I don't know the reasons > to make IESG decide on 'recognized' bodies. I completely fail to see any inconsistency or the relevance of any of this. Yes, the IESG makes a one-time determination that a given group is in fact an SDO, and in almot every case this is certain to be little more than a pro-forma action. So what? Once that is done they have no involvement in the media type approval process, which is the part that happens over and over and over again and has to be optimized. > Additionally, in Section 8 you > ask IANA to > maintain a list of IESG-recognized standards bodies who are > allowed to register types in the standards tree. > and give no other provisions on this. Is this going to be a registry or > something else, and how is it going to be filled in? It's a list that IANA consults. It is not a registry. Exactly what the text says currently. > Does this mean that > once IESG allowed some SDO to register their media type in Standards Tree, > IANA will automatically add this SDO to the list? Or something else? The process that happens between IANA and the IESG is intentionally unspecified here. Since representatives of IANA attend IESG meetings as a matter of routine and routinely place items on the IESG agenga for action, what's the point of specifying some completely unnecessary process? Remember: The focus here is on getting things done. Not on creating unnecessary bureaucracy. > 2) > Registrations published in non-IETF RFC streams are allowed and > require IESG approval. > I don't have an idea of what "are allowed" means? Are they to undergo this > review depending on whether their authors see it necessary? Doesn't this > fall into the second case for registrations in Standards Tree? Not when the end result is an RFC of any sort, no. Think about it for a minute: Will people understand the difference between a registration in an independent submission and one in a IETF document? Do you seriously think it is a good idea for there to be a way to get a registration into an RFC without some sort of OK from the IETF? And since the IESG reviews both non-IETF RFCs and IETF-generated standards tree registrations anyway, doesn't it make sense for them to be the ones to do it? > 3) > Standards-tree registrations from recognized standards bodies may be > submitted directly to the IANA, where they will undergo Expert Review > [RFC5226] prior to approval. In this case, the Expert Reviewer(s) > will, among other things, ensure that the required specification > provides adequate documentation. > Doesn't this conflict with the paragraph mentioned above in 1) about IESG's > decision on 'recognizedness' of SDO? In no way, shape, or form does it conflict. In one case the IESG is checking to see if a given organization is in fact an SDO - which will be a trivial check in almost every case. In the other case the expert reviewer is checking to see if the underlying format is properly specified. These are entirely different activities. > Summary. The page-long description of the procedures for Standards Tree > registration will help nobody in registering media types in this tree. That may be your opinion. I doubt very much if anyone else agrees with you. I absolutely do not. > I > like RFC 4288 description, and RFC 2048 description, which only contained > three paragraphs which stated these registrations must be approved by > IESG. Now, if you want to allow other SDO to register their types without > IESG's approval, that's easy to do by only adding a few words, so stating > that IETF-sourced and grandfathered registrations in Standards Tree are > subject to IESG's approval of the document registering them (and this means > RFC 5226 IETF consensus) and registrations ibid which originate from other > SDOs are subject to Expert Review who will also review and ensure > appropriate level of documentation (and this means RFC 5226 Specification > Required). Also it may be stated that non-IETF-stream RFCs may register > Standards Tree types with IESG's approval (that's actually what you now > have, but "are allowed" has already been commented on above). I have no real idea what you're getting at here, but it sounds far more complex that what we have. Look. There aren't that many SDOs out there that need to register media types, and the ones that do create type afer type after type. The approved list will almost immediately contain them all. Once that happens the process for an SDO registering a type is they fill in a form, the reviewer reviews, done. Couldn't possibly be any simpler. And at this point I'm done discussing this. > > > > > > > > > > > Section 6: s/RFC 3978/RFC 5378/ (and in References) > > > > > > > > > MY> This is fixed. > > > > > > > > > Sections 6 and 8: As your document sets up the registry for > > +suffixes, it > > > > > should contain the description as required by RFC 5226, which it > > > > currently > > > > > doesn't have. > > > > > > > > > MY> This comment still applies. > > > > > > > > Description where? I do not understand this one. I also do not see the > > > > requirement you're talking about anywhere in RFC 5226. (The word > > > > description > > > > appears exactly twice, and neither time in a requirement.) > > > > > > > > > I mean your description in Section 6 should follow Section 4.2 of RFC > > 5226. > > > > I don't actually see anything in RFC 5226 that says you have to define > > a registry using a particular layout in your document - all it says is that > > certain information has to be provided. And with one important exception, > > all of that information is currently present, just not in that format. > > > > That said, a thought occurs. This is a new registry that's not currently > > set up, and that means we need to call out the action to create it in the > > IANA considerations section of this document. So what I'm going to do is > > add that action to the IANA considerations, which will appear as a list > > more or less conforming to the list in section 4.2 of RFC 5226. (Most of > > the list items will simply be references to other sections of the > > current document.) > > > I wasn't talking about the layout. You could freely describe the registry > in Section 6 and then reference it later in Section 8. But I meant you > didn't mention RFC 5226 specification policy for this registry, as well as > its name (now mentioned). You may add some paragraph to Section 6.1 > stating that this document creates the registry called "Structured Syntax > Suffix" and the registration policy is "Expert Review" with the > registration process spelled out below. Additionally, the structure > (fields to be present in the registry itself) are to be defined. That's implicit in the template. I see no reason to repeat it and no requirement to. > > > > The sticking point is the initial registry content. I really don't want to > > clutter up an important process specification that's intended to be used > > for a > > long period of time with this crap that's only useful once. (I've always > > objected to this requirement in RFC 5226 - I think it's excessive rigidity > > causes more problems than it solves.) So I'm going to try to finesse it by > > saying that an initial list of the content of the registry effectively > > already > > exists and is in IANA 's hands - it's the list of conforming suffixes in > > current use in the existing media types registry - and direct the media > > types > > reviewers to, at the time of registry creation, extract that list and use > > it as > > the initial registry content. This also addresses the possibility that an > > additional legitimate suffix should show up and get registered under the > > current rules, making having a static list in a document somewhat > > problematic. > > > I think upon approval of the document Expert Reviewer will examine the > currently used ones, and we'll be able to publish a separate document > registering them. I see no point in generating such a document. Ned From fielding@gbiv.com Sun Feb 5 00:21:33 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A7AE11E8072 for ; Sun, 5 Feb 2012 00:21:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.099 X-Spam-Level: X-Spam-Status: No, score=-106.099 tagged_above=-999 required=5 tests=[AWL=-3.500, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fxVBA6+CGgry for ; Sun, 5 Feb 2012 00:21:32 -0800 (PST) Received: from homiemail-a64.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id E482111E8071 for ; Sun, 5 Feb 2012 00:21:32 -0800 (PST) Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id A0981438072; Sun, 5 Feb 2012 00:21:32 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gbiv.com; h=subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to; q=dns; s=gbiv.com; b=D1LzGlqbZ3x7MovV oV5PYUQObQL4ctXoF3SwzT0lSR7MBJ9uj0AnGswbV53ZJVZ25BlIkTgxZY9g30YE 3VaxFr1GUR3rmT0239XYhiy4N83bTrMb7PNN354RhnE4m6pVi7v5J5Y0fMtZVHf8 WFrUW1y6BHOpmTYeM6RALd+wk+8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=AGJ/SZPy2ZtCFeSAFOqZH7JUikI=; b=igoXJ9gJEQDpE6EFsYmC1V1NiWxL UWT0DPb/cDVnLOEcLaJ2QiBnJG6LzuKnWecSvg/fqx6bdUHcFCveZvTZTTyDdfDe SC/6+k3dF5mYCFyTXqi0HwVqp+BEIdA+M70hl+vwJ/bP51mD2v82CiOXmA2dSrnj yFitBesUqMvkTAw= Received: from [192.168.1.84] (99-21-208-82.lightspeed.irvnca.sbcglobal.net [99.21.208.82]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTPSA id 7C98643806C; Sun, 5 Feb 2012 00:21:32 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: "Roy T. Fielding" In-Reply-To: Date: Sun, 5 Feb 2012 00:21:40 -0800 Content-Transfer-Encoding: 7bit Message-Id: <486AD4F4-2C56-4BC3-BA58-807706952F09@gbiv.com> References: <20120204001408.16716.94710.idtracker@ietfa.amsl.com> <01OBKKTPYLIE00ZUIL@mauve.mrochek.com> <37E2E68B-23F6-4722-B7DC-444FA50D1E62@gbiv.com> To: John C Klensin X-Mailer: Apple Mail (2.1257) Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Requirement for "obsoletes" in Abstracts (was: Re: I-D Action: draft-ietf-appsawg-media-type-regs-00.txt) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2012 08:21:33 -0000 On Feb 4, 2012, at 5:08 PM, John C Klensin wrote: > --On Saturday, February 04, 2012 16:42 -0800 "Roy T. Fielding" > wrote: > >> +1 to John's rant. I really hate all of the useless status >> bits that we have in the abstracts for HTTPbis. People who >> read the document five years from now don't care how many >> older RFCs it updates or obsoletes. > > Yes. Remember that someone who already knows that RFC 9999 is a > protocol spec, and the one they are looking for, probably won't > even look at the abstract. The abstract is much more likely to > be useful to people who are trying to figure out if they have > the right spec or should keep looking, and a sentence that says > "This obsoletes RFC NNNN." is of even less use to them. > >> They belong in the Introduction, where we describe the history >> of the protocol. > > Lest we substitute one bad rule for another, I wish the above > paragraph had said "They belong wherever we describe the history > of the protocol". Sometimes -- I'd even guess "usually" -- > that should be the Introduction (sometimes a separate subsection > of the Introduction), but sometimes it should be a separate > section of the document, an appendix, or even another document > with a clear citation and reference from the protocol spec. Actually, I was referring specifically to HTTPbis. I have no need for a rule -- it just happens to be where we describe the history. ....Roy From julian.reschke@gmx.de Sun Feb 5 02:58:35 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E368721F84E0 for ; Sun, 5 Feb 2012 02:58:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.722 X-Spam-Level: X-Spam-Status: No, score=-103.722 tagged_above=-999 required=5 tests=[AWL=-1.123, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id osiH24yLLfao for ; Sun, 5 Feb 2012 02:58:35 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id EC46E21F84DF for ; Sun, 5 Feb 2012 02:58:34 -0800 (PST) Received: (qmail invoked by alias); 05 Feb 2012 10:58:32 -0000 Received: from p5DCC2C83.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.44.131] by mail.gmx.net (mp037) with SMTP; 05 Feb 2012 11:58:32 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19lTxN1l0Bl+4AnpsmITib0uwsrn75/3Y8+MXdtnw UBKdTUJK1xdsU7 Message-ID: <4F2E60D5.7070409@gmx.de> Date: Sun, 05 Feb 2012 11:58:29 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: "Roy T. Fielding" References: <20120204001408.16716.94710.idtracker@ietfa.amsl.com> <01OBKKTPYLIE00ZUIL@mauve.mrochek.com> <37E2E68B-23F6-4722-B7DC-444FA50D1E62@gbiv.com> In-Reply-To: <37E2E68B-23F6-4722-B7DC-444FA50D1E62@gbiv.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Requirement for "obsoletes" in Abstracts X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2012 10:58:36 -0000 On 2012-02-05 01:42, Roy T. Fielding wrote: > +1 to John's rant. I really hate all of the useless status bits that we have > in the abstracts for HTTPbis. People who read the document five years from > now don't care how many older RFCs it updates or obsoletes. > > They belong in the Introduction, where we describe the history of the protocol. +1 From julian.reschke@gmx.de Sun Feb 5 03:16:49 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB76C21F84DF for ; Sun, 5 Feb 2012 03:16:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.698 X-Spam-Level: X-Spam-Status: No, score=-103.698 tagged_above=-999 required=5 tests=[AWL=-1.099, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTKmS6rxVkXU for ; Sun, 5 Feb 2012 03:16:49 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 8727121F84A1 for ; Sun, 5 Feb 2012 03:16:48 -0800 (PST) Received: (qmail invoked by alias); 05 Feb 2012 11:16:47 -0000 Received: from p5DCC2C83.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.44.131] by mail.gmx.net (mp019) with SMTP; 05 Feb 2012 12:16:47 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX183Waloymo3lcA0JWBKp4Z/aj4VSRmWogbpQrwEmY C/TGqROoPh+J2s Message-ID: <4F2E651A.2000804@gmx.de> Date: Sun, 05 Feb 2012 12:16:42 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: "Roy T. Fielding" References: <20120204001408.16716.94710.idtracker@ietfa.amsl.com> <01OBKKTPYLIE00ZUIL@mauve.mrochek.com> <37E2E68B-23F6-4722-B7DC-444FA50D1E62@gbiv.com> In-Reply-To: <37E2E68B-23F6-4722-B7DC-444FA50D1E62@gbiv.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Requirement for "obsoletes" in Abstracts X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2012 11:16:50 -0000 On 2012-02-05 01:42, Roy T. Fielding wrote: > +1 to John's rant. I really hate all of the useless status bits that we have > in the abstracts for HTTPbis. People who read the document five years from > now don't care how many older RFCs it updates or obsoletes. > > They belong in the Introduction, where we describe the history of the protocol. > > ....Roy Some HTTPbis context: which cites which in fact doesn't even mention the Abstract, but it does mention the Introduction. Is there another written rule around? Best regards, Julian From john-ietf@jck.com Sun Feb 5 07:48:39 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D110721F8589 for ; Sun, 5 Feb 2012 07:48:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5bo29ONrJyHr for ; Sun, 5 Feb 2012 07:48:39 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 3C59021F8576 for ; Sun, 5 Feb 2012 07:48:39 -0800 (PST) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Ru4Gq-000HSu-1x; Sun, 05 Feb 2012 10:44:52 -0500 Date: Sun, 05 Feb 2012 10:48:30 -0500 From: John C Klensin To: Julian Reschke , "Roy T. Fielding" Message-ID: <709BD26081B1AAD7C18A4411@PST.JCK.COM> In-Reply-To: <4F2E651A.2000804@gmx.de> References: <20120204001408.16716.94710.idtracker@ietfa.amsl.com> <01OBKKTPYLIE00ZUIL@mauve.mrochek.com> <37E2E68B-23F6-4722-B7DC-444FA50D1E62@gbiv.com> <4F2E651A.2000804@gmx.de> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Requirement for "obsoletes" in Abstracts X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2012 15:48:39 -0000 --On Sunday, February 05, 2012 12:16 +0100 Julian Reschke wrote: >... > Some HTTPbis context: > > > > which cites > > > ic.html> > > which in fact doesn't even mention the Abstract, but it does > mention the Introduction. > > Is there another written rule around? The cause of this particular problem is http://www.ietf.org/id-info/checklist.html , section 3(1)(d). john From john-ietf@jck.com Sun Feb 5 12:28:54 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C36C021F852E for ; Sun, 5 Feb 2012 12:28:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0+Y2hJCJj2sW for ; Sun, 5 Feb 2012 12:28:53 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id D4C9921F8527 for ; Sun, 5 Feb 2012 12:28:53 -0800 (PST) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Ru8dx-000Hyx-02; Sun, 05 Feb 2012 15:25:01 -0500 Date: Sun, 05 Feb 2012 15:28:37 -0500 From: John C Klensin To: Ned Freed , Peter Saint-Andre Message-ID: In-Reply-To: <01OBLLE13ULY00ZUIL@mauve.mrochek.com> References: <4EEBA03D.7000906@stpeter.im> <01OBLLE13ULY00ZUIL@mauve.mrochek.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] [happiana] comments on draft-freed-media-type-regs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2012 20:28:54 -0000 --On Saturday, February 04, 2012 16:42 -0800 Ned Freed wrote: >... >> 5. Encodings > >> When mentioning "7bit US-ASCII text", perhaps reference RFC >> 5198. > > Er, no. RFC 5198 doesn't even mention US-ASCII. And the > Unicode format it defines is 8bit, not 7bit! It mentions ASCII and, IIR, NVT ASCII. As far as charsets are concerned, the latter, along with RFC 20 ASCII, are a 7bit code embedded in an 8bit field. But they are mentioned largely in the context of moving beyond them. (Abbreviated version of a long tirade: there is no such thing as "US-ASCII" and the term/ attempted distinction doesn't even have informal value unless you think there are, e.g., Canadian-ASCII, Mexican-ASCII, Brazilian-ASCII, etc.). Anyone who is inclined to split hairs along the above lines should note that, in the early days of the ARPANET, we had machines floating around that embedded the 7bit ASCII code in 7bits, 9bits, and at least two different flavors of 8bits. john From dhc@dcrocker.net Sun Feb 5 12:46:33 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3A521F8548 for ; Sun, 5 Feb 2012 12:46:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.6 X-Spam-Level: X-Spam-Status: No, score=-6.6 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJLKps28crX8 for ; Sun, 5 Feb 2012 12:46:32 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id ADCC021F8541 for ; Sun, 5 Feb 2012 12:46:32 -0800 (PST) Received: from [192.168.1.11] (adsl-67-124-148-117.dsl.pltn13.pacbell.net [67.124.148.117]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q15KkPdW027710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 5 Feb 2012 12:46:30 -0800 Message-ID: <4F2EEAA1.7060706@dcrocker.net> Date: Sun, 05 Feb 2012 12:46:25 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Barry Leiba References: <20120204001408.16716.94710.idtracker@ietfa.amsl.com> <01OBKKTPYLIE00ZUIL@mauve.mrochek.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sun, 05 Feb 2012 12:46:30 -0800 (PST) Cc: Ned Freed , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Requirement for "obsoletes" in Abstracts X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2012 20:46:33 -0000 On 2/4/2012 10:12 AM, Barry Leiba wrote: >the IESG does not treat this as a hard-and-fast rule, but, in fact, > more as a "strong recommendation". ADs normally don't use DISCUSS to comment on > this, but non-blocking COMMENT. And the PROTO writeup can call it out and say > that it's intended this way. I just posted a note to the RFC Editor suggesting that all this points to some benefit in reviewing and revising the RFC Style guide. In the current case: 1. I happen to believe that RFCs usually should not contain information that ceases to be interesting; that is, that has a short lifetime of usefulness. For some odd reason, I think of an RFC as having a twenty-year or more span of utility. From that perspective, what it obsoletes isn't useful in the Abstract, especially since Abstracts are supposed to be information-dense. 2. Authors should not have to guess about what is an absolute rule and what isn't. 3. The rationale for the rules should be provided. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From ned.freed@mrochek.com Sun Feb 5 12:58:57 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF4E721F856F for ; Sun, 5 Feb 2012 12:58:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HJdsWqJcrYZf for ; Sun, 5 Feb 2012 12:58:57 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 6921121F854D for ; Sun, 5 Feb 2012 12:58:57 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OBMRKKWHV400KI3Q@mauve.mrochek.com> for apps-discuss@ietf.org; Sun, 5 Feb 2012 12:58:52 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OBHM72OXPS00ZUIL@mauve.mrochek.com>; Sun, 5 Feb 2012 12:58:47 -0800 (PST) Message-id: <01OBMRKHFVU800ZUIL@mauve.mrochek.com> Date: Sun, 05 Feb 2012 12:52:26 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Sun, 05 Feb 2012 15:28:37 -0500" MIME-version: 1.0 Content-type: TEXT/PLAIN References: <4EEBA03D.7000906@stpeter.im> <01OBLLE13ULY00ZUIL@mauve.mrochek.com> To: John C Klensin Cc: Ned Freed , apps-discuss@ietf.org Subject: Re: [apps-discuss] [happiana] comments on draft-freed-media-type-regs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2012 20:58:58 -0000 > --On Saturday, February 04, 2012 16:42 -0800 Ned Freed > wrote: > >... > >> 5. Encodings > > > >> When mentioning "7bit US-ASCII text", perhaps reference RFC > >> 5198. > > > > Er, no. RFC 5198 doesn't even mention US-ASCII. And the > > Unicode format it defines is 8bit, not 7bit! > It mentions ASCII and, IIR, NVT ASCII. As far as charsets are > concerned, the latter, along with RFC 20 ASCII, are a 7bit code > embedded in an 8bit field. But they are mentioned largely in > the context of moving beyond them. (Abbreviated version of a > long tirade: there is no such thing as "US-ASCII" and the term/ > attempted distinction doesn't even have informal value unless > you think there are, e.g., Canadian-ASCII, Mexican-ASCII, > Brazilian-ASCII, etc.). But not US-ASCII, and as you say, it discusses ASCII in any form only in passing. If we really need a reference for that we can copy the one that's in MIME that actually points to a defining document. But seriously, does anyone really think we need such a reference? We're concerned with encodings, not charsets, here, and US-ASCII is simply being mentioned in some text providing context as to why encodings are even part of a registration. Ned From barryleiba@gmail.com Sun Feb 5 13:29:19 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68A1321F855F for ; Sun, 5 Feb 2012 13:29:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.94 X-Spam-Level: X-Spam-Status: No, score=-102.94 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FdxZta8JwNzB for ; Sun, 5 Feb 2012 13:29:18 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id B2E2621F852B for ; Sun, 5 Feb 2012 13:29:18 -0800 (PST) Received: by obbwd15 with SMTP id wd15so7369766obb.31 for ; Sun, 05 Feb 2012 13:29:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=hLkOTgMU6DznKb5019k6bN7yZy3Z0DOonvYkX/ccZjs=; b=M8/YXRloyS29Jr7mTAy8xwGmlcnFFGL5StJycbUw5x3RGEKPQwh4N7ZvIOjDWskht6 AUDWCFt3kb7fzUxWRhII5Wdv4gOz/jDDkKCFX5OsvbHSIO1/TpsMzHlGlbypSo/qQjr/ au9c4UfRvAZwu7cOvFs6oOt6SZ0bTsxg1IEO0= MIME-Version: 1.0 Received: by 10.182.162.40 with SMTP id xx8mr14470253obb.17.1328477358349; Sun, 05 Feb 2012 13:29:18 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.60.9.65 with HTTP; Sun, 5 Feb 2012 13:29:18 -0800 (PST) In-Reply-To: <4F2EEAA1.7060706@dcrocker.net> References: <20120204001408.16716.94710.idtracker@ietfa.amsl.com> <01OBKKTPYLIE00ZUIL@mauve.mrochek.com> <4F2EEAA1.7060706@dcrocker.net> Date: Sun, 5 Feb 2012 16:29:18 -0500 X-Google-Sender-Auth: rk6jgE6KkNxyOw1ATrNEVyt0w1w Message-ID: From: Barry Leiba To: dcrocker@bbiw.net Content-Type: text/plain; charset=ISO-8859-1 Cc: Ned Freed , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Requirement for "obsoletes" in Abstracts X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2012 21:29:19 -0000 > I just posted a note to the RFC Editor suggesting that all this points to > some benefit in reviewing and revising the RFC Style guide. Agreed; and then we need to reflect those changes into the I-D checklist. > From that perspective, what it obsoletes isn't useful in the > Abstract, especially since Abstracts are supposed to be information-dense. It's particularly not useful because the abstract is, at least with the current template, on the same page as the header information, which already contains the obsoletes/updates information. To my mind, that makes it 100% useless to include that in the abstract. I would support a recommendation that specs SHOULD explain in the introduction *why* this document obsoletes another if the reason is not blazingly obvious (obvious as when, for example, RFC 5321 obsoleted RFC 2821). > 2. Authors should not have to guess about what is an absolute rule and what > isn't. Clearly right. > 3. The rationale for the rules should be provided. I think explaining rationale is usually valuable, and am curious when I see various reviewers push back on such things, saying that they don't see the need for it. Barry From paul.hoffman@vpnc.org Sun Feb 5 13:31:25 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE1521F855F for ; Sun, 5 Feb 2012 13:31:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kKFYD3YdJaor for ; Sun, 5 Feb 2012 13:31:24 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 95A0321F852B for ; Sun, 5 Feb 2012 13:31:24 -0800 (PST) Received: from [192.168.11.124] ([12.239.109.3]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q15LVJeS090972 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 5 Feb 2012 14:31:20 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: Paul Hoffman In-Reply-To: <4F2EEAA1.7060706@dcrocker.net> Date: Sun, 5 Feb 2012 16:31:19 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <799720BC-AAEB-4270-BDF4-A24E83E5C553@vpnc.org> References: <20120204001408.16716.94710.idtracker@ietfa.amsl.com> <01OBKKTPYLIE00ZUIL@mauve.mrochek.com> <4F2EEAA1.7060706@dcrocker.net> To: "apps-discuss@ietf.org Discuss" X-Mailer: Apple Mail (2.1251.1) Subject: Re: [apps-discuss] Requirement for "obsoletes" in Abstracts X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2012 21:31:25 -0000 On Feb 5, 2012, at 3:46 PM, Dave CROCKER wrote: > I just posted a note to the RFC Editor suggesting that all this points = to some benefit in reviewing and revising the RFC Style guide. Although as John noted, this rule is actually from the IESG. Barry = suggests that it might not always be enforced; I would hope that the = document that John linked to (as compared to the RFC Style Guide) could = be updated as well. --Paul Hoffman From julian.reschke@gmx.de Sun Feb 5 13:48:36 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77C6C21F8550 for ; Sun, 5 Feb 2012 13:48:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.951 X-Spam-Level: X-Spam-Status: No, score=-103.951 tagged_above=-999 required=5 tests=[AWL=-1.352, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6HtiMhqVXKZH for ; Sun, 5 Feb 2012 13:48:36 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 97CF121F854D for ; Sun, 5 Feb 2012 13:48:35 -0800 (PST) Received: (qmail invoked by alias); 05 Feb 2012 21:48:34 -0000 Received: from p5DCC2AE9.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.42.233] by mail.gmx.net (mp039) with SMTP; 05 Feb 2012 22:48:34 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+ls5ZZORClz4yJf6DGNEy1x2D2w/scY4e2qBjcAu 7fiuSYqZ3Ljg9u Message-ID: <4F2EF915.4070001@gmx.de> Date: Sun, 05 Feb 2012 22:48:05 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: dcrocker@bbiw.net References: <20120204001408.16716.94710.idtracker@ietfa.amsl.com> <01OBKKTPYLIE00ZUIL@mauve.mrochek.com> <4F2EEAA1.7060706@dcrocker.net> In-Reply-To: <4F2EEAA1.7060706@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Ned Freed , "apps-discuss@ietf.org" , Barry Leiba Subject: Re: [apps-discuss] Requirement for "obsoletes" in Abstracts X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2012 21:48:36 -0000 On 2012-02-05 21:46, Dave CROCKER wrote: > > On 2/4/2012 10:12 AM, Barry Leiba wrote: >> the IESG does not treat this as a hard-and-fast rule, but, in fact, >> more as a "strong recommendation". ADs normally don't use DISCUSS to >> comment on >> this, but non-blocking COMMENT. And the PROTO writeup can call it out >> and say >> that it's intended this way. > > > I just posted a note to the RFC Editor suggesting that all this points > to some benefit in reviewing and revising the RFC Style guide. > > In the current case: > > 1. I happen to believe that RFCs usually should not contain information > that ceases to be interesting; that is, that has a short lifetime of > usefulness. For some odd reason, I think of an RFC as having a > twenty-year or more span of utility. From that perspective, what it > obsoletes isn't useful in the Abstract, especially since Abstracts are > supposed to be information-dense. > > 2. Authors should not have to guess about what is an absolute rule and > what isn't. > > 3. The rationale for the rules should be provided. +1 I can see that it's useful for the RFC Editor to be able to easily find out what changes to the RFC Editor database are required. Maybe just introduce something similar to the "IANA Considerations"? From john-ietf@jck.com Sun Feb 5 14:29:05 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0BFE21F849C for ; Sun, 5 Feb 2012 14:29:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQd1FwKt7+mH for ; Sun, 5 Feb 2012 14:29:05 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 2433221F8495 for ; Sun, 5 Feb 2012 14:29:05 -0800 (PST) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1RuAWF-000I7U-NH; Sun, 05 Feb 2012 17:25:11 -0500 Date: Sun, 05 Feb 2012 17:28:50 -0500 From: John C Klensin To: Julian Reschke , dcrocker@bbiw.net Message-ID: In-Reply-To: <4F2EF915.4070001@gmx.de> References: <20120204001408.16716.94710.idtracker@ietfa.amsl.com> <01OBKKTPYLIE00ZUIL@mauve.mrochek.com> <4F2EEAA1.7060706@dcrocker.net> <4F2EF915.4070001@gmx.de> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Barry Leiba , Ned Freed , apps-discuss@ietf.org Subject: Re: [apps-discuss] Requirement for "obsoletes" in Abstracts X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2012 22:29:05 -0000 --On Sunday, February 05, 2012 22:48 +0100 Julian Reschke wrote: >> 3. The rationale for the rules should be provided. > > +1 > > I can see that it's useful for the RFC Editor to be able to > easily find out what changes to the RFC Editor database are > required. Maybe just introduce something similar to the "IANA > Considerations"? Julian, I think it would help this discussion if we avoided conflating too many issues. But, fwiw, there isn't a lot of information in the database or information needed to construct/ update it. Unless that changes, 100% of the information that is needed for "obsoletes" is contained in the "updates" header at the top of the page. As Barry pointed out, if the "updates" header is there an almost-content-free sentence in the abstract that says "this updates that" is pretty close to 100% useless. FWIW, and generalizing a bit from an earlier comment, I think it would be worthwhile for the community and the IESG to explore types of information that are really useful in the review and publication process, including updating databases of various sorts but that fall somewhere on the spectrum between "useless" and "actively confusing" in the long term. If the IESG wants some additional information in a specific form in I-Ds to help with reviews, I think that is fine. Similarly, I think putting the entire desired contents of a new (and potentially large) registry as part of instructions to IANA is useful. But either should be carried into an RFC is an open question and, while I think there are lots of edge cases and places where careful consideration is going to be necessary, a translation of Dave's comment into a "will this be useful in 20 years or just a distraction" criterion seems quite useful to me. So, just as I'd like to see any suggestions about "updates" sentences in an I-D Abstract either dropped entirely or having that text dropped before RFC publication, I'd much rather see the published version of "IANA Considerations" (where it is included at all) reduced to a summary description of what IANA was asked to do and did, with a pointer to the registry if appropriate, rather than the listing of code points and descriptions that might be entirely reasonable in an I-D/proposal. My guess is that a thoughtful examination of what we are doing to and with the RFC Series (IETF Stream and more generally) might yield more examples of the underlying principle that implies. john From sm@resistor.net Sun Feb 5 14:58:28 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E99F21F855A for ; Sun, 5 Feb 2012 14:58:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.61 X-Spam-Level: X-Spam-Status: No, score=-102.61 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x0s-rRHK3Bfq for ; Sun, 5 Feb 2012 14:58:26 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 09B3821F8557 for ; Sun, 5 Feb 2012 14:58:25 -0800 (PST) Received: from sm-THINK.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q15MwAbV024676; Sun, 5 Feb 2012 14:58:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1328482698; i=@resistor.net; bh=V8i4sg5weWHXrz7YucnMmdbLiBgA49kRH6Xs089Uv2c=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=p3zev4P/Tw1hrC9gbuYUF9NjPuv4dUr4UUoMKjnFIzPLpdlWevjVJV/sleGxB4tTK t5Z/i0AxQW9TeZu815yBmpuwvTsX/MKgsQT7j4TQJxbcmR8gEmsSN2KOMCrmG87Kmg VVVdDz0m3b5BO6AW58F9nz/cepv80lIkG4GSYKfk= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1328482698; i=@resistor.net; bh=V8i4sg5weWHXrz7YucnMmdbLiBgA49kRH6Xs089Uv2c=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=27XdGhGL2j+ihvf+lt4wqnVmHENY6reP0CMrmhrLcXB3qSKgpYG3FnRHaPi6xX70I 7jTL7fh/T20FmwteHASGvrwfxetHUigLx3TM08nYZaFPZ2I9jSQOkTDdBuxFpmV3VJ /BLAIdES+3ScGkiJaR6qBu6sVp23rOzoNzPvLR7k= Message-Id: <6.2.5.6.2.20120205134413.094dff80@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 05 Feb 2012 13:48:03 -0800 To: Julian Reschke From: SM In-Reply-To: <4F2E651A.2000804@gmx.de> References: <20120204001408.16716.94710.idtracker@ietfa.amsl.com> <01OBKKTPYLIE00ZUIL@mauve.mrochek.com> <37E2E68B-23F6-4722-B7DC-444FA50D1E62@gbiv.com> <4F2E651A.2000804@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Requirement for "obsoletes" in Abstracts X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2012 22:58:28 -0000 Hi Julian, At 03:16 AM 2/5/2012, Julian Reschke wrote: >Is there another written rule around? See Section 4.1.1 of http://www.rfc-editor.org/rfc-style-guide/rfc-style I read it as a guideline. Regards, -sm From dhc@dcrocker.net Sun Feb 5 15:03:23 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31BF921F8572 for ; Sun, 5 Feb 2012 15:03:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.6 X-Spam-Level: X-Spam-Status: No, score=-6.6 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YRTTPWqq+dLf for ; Sun, 5 Feb 2012 15:03:22 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9B3D921F855A for ; Sun, 5 Feb 2012 15:03:22 -0800 (PST) Received: from [192.168.1.11] (adsl-67-124-148-117.dsl.pltn13.pacbell.net [67.124.148.117]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q15N3Gt7030152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 5 Feb 2012 15:03:22 -0800 Message-ID: <4F2F0AB4.6010007@dcrocker.net> Date: Sun, 05 Feb 2012 15:03:16 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: "apps-discuss@ietf.org Discuss" References: <20120204001408.16716.94710.idtracker@ietfa.amsl.com> <01OBKKTPYLIE00ZUIL@mauve.mrochek.com> <4F2EEAA1.7060706@dcrocker.net> <799720BC-AAEB-4270-BDF4-A24E83E5C553@vpnc.org> In-Reply-To: <799720BC-AAEB-4270-BDF4-A24E83E5C553@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sun, 05 Feb 2012 15:03:22 -0800 (PST) Subject: Re: [apps-discuss] Requirement for "obsoletes" in Abstracts X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2012 23:03:23 -0000 > Although as John noted, this rule is actually from the IESG. Existing documentation still has remnants of confusion about what is IETF stream policy versus, for example, overall RFC Editor policy. These are items to reconcile as they are discovered. I suppose the larger question for the IETF stream is whether its RFC-related policies should be set by the IESG or by the IETF... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From ned.freed@mrochek.com Sun Feb 5 16:33:01 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3299F21F8585 for ; Sun, 5 Feb 2012 16:33:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bsgBxuTxJm9d for ; Sun, 5 Feb 2012 16:33:00 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 384DD21F8572 for ; Sun, 5 Feb 2012 16:32:59 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OBMZ1XO4GG00YZA2@mauve.mrochek.com> for apps-discuss@ietf.org; Sun, 5 Feb 2012 16:32:54 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OBMQVK09MO012404@mauve.mrochek.com>; Sun, 5 Feb 2012 16:32:49 -0800 (PST) Message-id: <01OBMZ1U2LH4012404@mauve.mrochek.com> Date: Sun, 05 Feb 2012 16:17:14 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Sun, 05 Feb 2012 16:29:18 -0500" MIME-version: 1.0 Content-type: TEXT/PLAIN References: <20120204001408.16716.94710.idtracker@ietfa.amsl.com> <01OBKKTPYLIE00ZUIL@mauve.mrochek.com> <4F2EEAA1.7060706@dcrocker.net> To: Barry Leiba Cc: Ned Freed , dcrocker@bbiw.net, "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Requirement for "obsoletes" in Abstracts X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 00:33:01 -0000 > > I just posted a note to the RFC Editor suggesting that all this points to > > some benefit in reviewing and revising the RFC Style guide. > Agreed; and then we need to reflect those changes into the I-D checklist. > > From that perspective, what it obsoletes isn't useful in the > > Abstract, especially since Abstracts are supposed to be information-dense. > It's particularly not useful because the abstract is, at least with > the current template, on the same page as the header information, > which already contains the obsoletes/updates information. Well, the theory, as I understand it, is that the Abstract is actually a separable entity designed to be extracted and use elsewhered. Therefore it needs to be self-contained, to the point where it duplicates stuff that's on the same page. There are two problems with this theory, however. The first is that separable Abstracts make all sorts of sense when the full document is not readily accessible (only in print journal, behind a paywall, blah blah blah.). But that's not the case for RFCs. It might have made sense even for RFCs when data transfer was expensive, but these days pulling out the Abstract is more trouble than it's worth - why not just send the whole thing? The only remaining use-case I can think would be some sort of index, and any such index done competently will include much more extensive forward and backwards pointers of its own. (And it is axiomatic that the far more important forward pointers, that is, "this document is obsoleted/updated by RFC N", cannot possibly appear in the Abstract.) The second problem is really an extension of my point about forward pointers. Simple backwards pointers just don't give enough context to justify cluttering what should be a straightforward statement of what *this* document does.. > To my mind, > that makes it 100% useless to include that in the abstract. I would > support a recommendation that specs SHOULD explain in the introduction > *why* this document obsoletes another if the reason is not blazingly > obvious (obvious as when, for example, RFC 5321 obsoleted RFC 2821). Agreed. And in the process it adds the context these simple statements in the Abstract lack. Ned From enrico.marocco@telecomitalia.it Mon Feb 6 01:49:17 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30A4721F85C9; Mon, 6 Feb 2012 01:49:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.544 X-Spam-Level: X-Spam-Status: No, score=-100.544 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lLnoO3CvscqI; Mon, 6 Feb 2012 01:49:16 -0800 (PST) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id 248D521F85C3; Mon, 6 Feb 2012 01:49:16 -0800 (PST) Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 6 Feb 2012 10:49:06 +0100 Received: from MacLab.local (163.162.180.246) by smtp.telecomitalia.it (10.188.101.114) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 6 Feb 2012 10:49:04 +0100 Message-ID: <4F2FA266.8040406@telecomitalia.it> Date: Mon, 6 Feb 2012 10:50:30 +0100 From: Enrico Marocco User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "apps-discuss@ietf.org" , Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080108030207010104060809" Cc: IESG Subject: [apps-discuss] APPSDIR review of draft-ietf-simple-chat-13 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 09:49:17 -0000 --------------ms080108030207010104060809 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Document: draft-ietf-simple-chat-13 Title: Multi-party Chat Using the Message Session Relay Protocol (MSRP) Reviewers: Alexey Melnicov and Enrico Marocco Review Date: 2012-02-06 IETF Last Call Date: 2012-02-06 Summary: This draft is almost ready for publication as a Proposed Standard, but has a major issue to be taken into consideration and a few minor issues to be fixed. Major Issue The document doesn't describe allowed characters in Nicks and any normalization that needs to be applied. Minor Issues The document strictly forbids multiple To: headers in the CPIM message, that could be used for example to send public personal messages (i.e. messages addressed to some particular individual, but shared with the entire conference, a-la Twitter). If there's a reason for that, some explanation would be useful. Figure 1 seems to imply that MSRP relays are mandatory. Since they are not -- and the draft is pretty clear about it -- I'd suggest to have some of MSRP flows in the diagram flow straight from the client to the switch. A reference to the SDP mechanism defined in S. 8. would be useful in in S. 5.2., last paragraph, S. 6.2, last paragraph, and in any other part that deals with discovering of client capability. In Section 5.2: The conference focus of a chat room MUST learn the chat room How can this be achieved? A forward pointer might be missing here. capabilities of each participant that joins the chat room. The conference focus MUST inform the MSRP switch of such support in order to prevent the MSRP switch from distributing private messages to participants who do not support private messaging. The recipient would not be able to render the message as private, and any potential reply would be sent to the whole chat room. In Section 7.1: The reservation of a nickname can fail, e.g. if the NICKNAME request contains a malformed or non-existent Use-Nickname header field, or if the same nickname has already been reserved by another participant (i.e., by another URI) in the chat room. The validation can also fail where the sender of the message is not entitled to reserve the nickname. In any of these cases the MSRP switch MUST answer the NICKNAME request with a 423 response. The semantics of the 423 response are: "Nickname usage failed; the nickname is not allocated to this user". It would be better to use different response codes for different error conditions. Nits [Only the few that came out in non-nitpicking read] S. 3, REQ-3: s/depend no/depend on/ S. 4, second paragraph after Figure 2: s/a text/text/ A few 2119 refuses can be also found in the text, e.g.: S. 5.2, sixth paragraph: s/URI must not/URI MUST NOT/ --------------ms080108030207010104060809 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINfjCC BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6 qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95 m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy 6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9 sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t 5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIHQjCCBiqgAwIBAgIDAt9AMA0GCSqGSIb3DQEB BQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTEwODIyMDYyNDA2 WhcNMTIwODIyMDM0MDM3WjB8MSAwHgYDVQQNExc0OTAyNDItOU1QZVJYRnFlVVU0QUMybTEo MCYGA1UEAwwfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEuMCwGCSqGSIb3DQEJ ARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBALl4L3Uj7TJrMbll5JAyphws2AMR67q3D2FH0JmRqQ5r+ujqaxyeHcrx Kclu2tz/D3SPtZAlcDOclxpEDbpxXlMpo+3DsbNweNgSF6mnyRDYU2ay3qO54ENz21GZ64bl ZRsMI6KsGnxm7sORWLUdx229ijARs3aQD1js9bidUJsnxg26UvnwpJ8eGoFiCLzzsQXUD+OL 3TXEGrTzt+B2RDb13TIOe085T8jzBh08wNKPTDmKjxy5m35Xn8QfRy8b93d0wUs98Fst5iND EgHEHc9CwurwLYrOd/1ZkbfAoRi7kRQ0Ih4wKkP+Lkww/0qHEIrrgW+aVmGjkQ0nidAaE+sC AwEAAaOCA7owggO2MAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUF BwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUYgEiK9qxBHth8ziqydxV7QYZn1QwHwYDVR0jBBgw FoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwKgYDVR0RBCMwIYEfZW5yaWNvLm1hcm9jY29AdGVs ZWNvbWl0YWxpYS5pdDCCAiEGA1UdIASCAhgwggIUMIICEAYLKwYBBAGBtTcBAgIwggH/MC4G CCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUF BwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIH3BggrBgEF BQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhp cyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5j ZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSBy ZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjCBnAYIKwYBBQUHAgIwgY8wJxYgU3RhcnRDb20g Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBAhpkTGlhYmlsaXR5IGFuZCB3YXJyYW50aWVz IGFyZSBsaW1pdGVkISBTZWUgc2VjdGlvbiAiTGVnYWwgYW5kIExpbWl0YXRpb25zIiBvZiB0 aGUgU3RhcnRDb20gQ0EgcG9saWN5LjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0 YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzAB hi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYB BQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcN AQEFBQADggEBAF4gnxCzZVmINcZh7ZMB6G1+8/kV6pLqDxyUidalFSJ8KLwJxrxhESOb+E7d JHxZBuJFH1NBXuVn+MI7rqa/HI7PkLJjkHhMH8ay7jhR2VVMIFYAqRn9O22oDDw2iEigYkgo HcHP1vD5rtydbGr6mCcHOtWCk5B7FqEoMYTQRO1F6szoqORVaajVtZeSwtVAMufV20tohyUL hpOH5lZDblsej2XueyJVqD8RYSUJp7w4eMpr5CTP9QdNBS0cca83JA070JMudV+ozG6ADIBx mGPrWyPv7PmjBBGIXxPJJRxDsDyJBYhs+qh6fZWNl6WZkQNepkn7IAUB0+0ggds992kxggPQ MIIDzAIBATCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0 YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMC30AwCQYF Kw4DAhoFAKCCAhAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTIwMjA2MDk1MDMwWjAjBgkqhkiG9w0BCQQxFgQUBStMbjD200P4WqBXD2zsRMgQYOwwXwYJ KoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQx gZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENv bSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDAt9AMIGnBgsqhkiG 9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMC30Aw DQYJKoZIhvcNAQEBBQAEggEAMgddQH/3y5tGbiQPSQeCA1W+74VD5zJ6uS0L4co7knqYeGP2 wpgmV2yssNReK/PseuzfeV4gBE9keZ+FPhVo6jc2dmlWGHlxfRi8BQGJFfAQ2vLQU8YN8EDF ffTmFBkiVyOVc96GIG7WqW5bA1tVa/uVElf72CmIdXMIsjARSdCT5Tn+jkh0WUMbpPhmZdBI 5M6CYOeGEi7A9AEMfqSh7NCgaWA8IexKRwfGU7a6H7XzkutxiGeuQnqiQCSkp8LBFNG7xAG8 2APJvhQhEPFuErFLe2ImM7YDLdOKu24Lf9QqD7NzAF92MQ6Uq7uyIxeAD8n8yRHHVPqi4+wt fYWlWwAAAAAAAA== --------------ms080108030207010104060809-- From tobias.gondrom@gondrom.org Mon Feb 6 06:29:21 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7609C21F8636 for ; Mon, 6 Feb 2012 06:29:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.777 X-Spam-Level: X-Spam-Status: No, score=-96.777 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PUUhOjL0ZvT6 for ; Mon, 6 Feb 2012 06:29:17 -0800 (PST) Received: from lvps83-169-7-107.dedicated.hosteurope.de (www.gondrom.org [83.169.7.107]) by ietfa.amsl.com (Postfix) with ESMTP id 0707721F8630 for ; Mon, 6 Feb 2012 06:29:16 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=QD2AMH2A/I3HP7LSiTqOrJPqt9FyYn37l0g4SFbr6qhDrRCzPiKNwgx5avRflUcbsJzOJJ9d1HeQEEZdbPUzRcbrzmR4/kZO717FUdm8XNEkkk4e1f+VlweKmJFh1/Fr; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:Content-Type; Received: (qmail 18014 invoked from network); 6 Feb 2012 15:29:12 +0100 Received: from 94-194-102-93.zone8.bethere.co.uk (HELO ?192.168.1.68?) (94.194.102.93) by www.gondrom.org with (DHE-RSA-AES256-SHA encrypted) SMTP; 6 Feb 2012 15:29:12 +0100 Message-ID: <4F2FE3B8.4080808@gondrom.org> Date: Mon, 06 Feb 2012 14:29:12 +0000 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: apps-discuss@ietf.org, draft-ietf-tsvwg-source-quench.all@tools.ietf.org Content-Type: multipart/alternative; boundary="------------060801090407020307050202" Cc: iesg@ietf.org Subject: [apps-discuss] APPSDIR review of draft-ietf-tsvwg-source-quench-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 14:29:21 -0000 This is a multi-part message in MIME format. --------------060801090407020307050202 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello, I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). Please consider these comments along with any other Last Call comments you may receive. Document: draft-ietf-tsvwg-source-quench-04 Title: Deprecation of ICMP Source Quench messages Reviewer: Tobias Gondrom Review Date: 2012-02-06 Abstract: This document formally deprecates the use of ICMP Source Quench messages by transport protocols, formally updating RFC 792, RFC 1122, and RFC 1812. Additionally, it requests that the status of RFC 1016 be changed to "Historic". Summary: This draft is ready for publication as an RFC. And I agree with the conclusions of the Transport Area Working Group (tsvwg) to deprecate ICMP source quench, especially from a potential security perspective. Comment/remark: one of the reasons for deprecating ICMP source quench was given in the draft in section 1 as: "- Virtually all popular host implementations have removed support for ICMP Source Quench messages since (at least) 2005 [RFC5927]" Please note, that the reviewer did not test/verify this statement, but assumes that the transport working group has researched and confirmed this data in WGLC. If this is not the case, the transport are WG should reconfirm this assumption before the draft progresses to IESG. Best regards, Tobias Tobias Gondrom email: tobias.gondrom@gondrom.org mobile: +447521003005 --------------060801090407020307050202 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello,

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

Please consider these comments along with any other Last Call comments you may receive.

Document:  draft-ietf-tsvwg-source-quench-04
Title:  Deprecation of ICMP Source Quench messages
Reviewer: Tobias Gondrom
Review Date: 2012-02-06
Abstract: This document formally deprecates the use of ICMP Source Quench
   messages by transport protocols, formally updating RFC 792, RFC 1122,
   and RFC 1812.  Additionally, it requests that the status of RFC 1016
   be changed to "Historic".


Summary:

This draft is ready for publication as an RFC.
And I agree with the conclusions of the Transport Area Working Group (tsvwg) to deprecate ICMP source quench, especially from a potential security perspective.

Comment/remark:
one of the reasons for deprecating ICMP source quench was given in the draft in section 1 as:
"- Virtually all popular host implementations have removed support
      for ICMP Source Quench messages since (at least) 2005 [RFC5927]"
Please note, that the reviewer did not test/verify this statement, but assumes that the transport working group has researched and confirmed this data in WGLC. If this is not the case, the transport are WG should reconfirm this assumption before the draft progresses to IESG.

Best regards, Tobias



Tobias Gondrom
email: tobias.gondrom@gondrom.org
mobile: +447521003005
--------------060801090407020307050202-- From ben@nostrum.com Mon Feb 6 06:35:18 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD1B421F8643; Mon, 6 Feb 2012 06:35:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJRjPQ2F3iXq; Mon, 6 Feb 2012 06:35:18 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id D8FC321F8508; Mon, 6 Feb 2012 06:35:17 -0800 (PST) Received: from [10.0.1.2] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q16EZFuG038805 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 6 Feb 2012 08:35:16 -0600 (CST) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Ben Campbell In-Reply-To: <4F2FA266.8040406@telecomitalia.it> Date: Mon, 6 Feb 2012 08:35:28 -0600 Content-Transfer-Encoding: 7bit Message-Id: <2B8404CA-7602-4143-9D2D-959EAA08F2C3@nostrum.com> References: <4F2FA266.8040406@telecomitalia.it> To: Enrico Marocco X-Mailer: Apple Mail (2.1257) Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) X-Mailman-Approved-At: Mon, 06 Feb 2012 08:02:46 -0800 Cc: draft-ietf-simple-chat.all@tools.ietf.org, IESG , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-simple-chat-13 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 14:35:19 -0000 Thanks for the thorough review Enrico and Alexey! Miguel and Geir Arne: What are your thoughts? Thanks! Ben. On Feb 6, 2012, at 3:50 AM, Enrico Marocco wrote: > Document: draft-ietf-simple-chat-13 > Title: Multi-party Chat Using the Message Session Relay Protocol (MSRP) > Reviewers: Alexey Melnicov and Enrico Marocco > Review Date: 2012-02-06 > IETF Last Call Date: 2012-02-06 > > > Summary: This draft is almost ready for publication as a Proposed > Standard, but has a major issue to be taken into consideration and a few > minor issues to be fixed. > > > Major Issue > > The document doesn't describe allowed characters in Nicks and any > normalization that needs to be applied. > > > Minor Issues > > The document strictly forbids multiple To: headers in the CPIM message, > that could be used for example to send public personal messages (i.e. > messages addressed to some particular individual, but shared with the > entire conference, a-la Twitter). If there's a reason for that, some > explanation would be useful. > > Figure 1 seems to imply that MSRP relays are mandatory. Since they are > not -- and the draft is pretty clear about it -- I'd suggest to have > some of MSRP flows in the diagram flow straight from the client to the > switch. > > A reference to the SDP mechanism defined in S. 8. would be useful in in > S. 5.2., last paragraph, S. 6.2, last paragraph, and in any other part > that deals with discovering of client capability. > > In Section 5.2: > > The conference focus of a chat room MUST learn the chat room > > How can this be achieved? A forward pointer might be missing here. > > capabilities of each participant that joins the chat room. The > conference focus MUST inform the MSRP switch of such support in > order to prevent the MSRP switch from distributing private messages > to participants who do not support private messaging. The recipient > would not be able to render the message as private, and any > potential reply would be sent to the whole chat room. > > In Section 7.1: > > The reservation of a nickname can fail, e.g. if the NICKNAME request > contains a malformed or non-existent Use-Nickname header field, or > if the same nickname has already been reserved by another > participant (i.e., by another URI) in the chat room. The > validation can also fail where the sender of the message is not > entitled to reserve the nickname. In any of these cases the MSRP > switch MUST answer the NICKNAME request with a 423 response. The > semantics of the 423 response are: "Nickname usage failed; the > nickname is not allocated to this user". > > It would be better to use different response codes for different error > conditions. > > > Nits [Only the few that came out in non-nitpicking read] > > S. 3, REQ-3: s/depend no/depend on/ > > S. 4, second paragraph after Figure 2: s/a text/text/ > > A few 2119 refuses can be also found in the text, e.g.: > > S. 5.2, sixth paragraph: s/URI must not/URI MUST NOT/ > > From dhc@dcrocker.net Mon Feb 6 09:49:53 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7E3321F8622 for ; Mon, 6 Feb 2012 09:49:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.6 X-Spam-Level: X-Spam-Status: No, score=-6.6 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6q7OhZljpG4V for ; Mon, 6 Feb 2012 09:49:53 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id F169921F8600 for ; Mon, 6 Feb 2012 09:49:48 -0800 (PST) Received: from [192.168.1.11] (adsl-67-124-148-117.dsl.pltn13.pacbell.net [67.124.148.117]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q16HnhFf017215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Feb 2012 09:49:48 -0800 Message-ID: <4F3012B5.9080107@dcrocker.net> Date: Mon, 06 Feb 2012 09:49:41 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Ned Freed References: <20120204001408.16716.94710.idtracker@ietfa.amsl.com> <01OBKKTPYLIE00ZUIL@mauve.mrochek.com> <4F2EEAA1.7060706@dcrocker.net> <01OBMZ1U2LH4012404@mauve.mrochek.com> In-Reply-To: <01OBMZ1U2LH4012404@mauve.mrochek.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 06 Feb 2012 09:49:48 -0800 (PST) Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Requirement for "obsoletes" in Abstracts X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 17:49:53 -0000 On 2/5/2012 4:17 PM, Ned Freed wrote: > There are two problems with this theory, however. The first is that separable > Abstracts make all sorts of sense when the full document is not readily > accessible (only in print journal, behind a paywall, blah blah blah.). But > that's not the case for RFCs. It might have made sense even for RFCs when data > transfer was expensive, but these days pulling out the Abstract is more trouble > than it's worth - why not just send the whole thing? The only remaining > use-case I can think would be some sort of index, and any such index done > competently will include much more extensive forward and backwards pointers of > its own. (And it is axiomatic that the far more important forward pointers, > that is, "this document is obsoleted/updated by RFC N", cannot possibly appear > in the Abstract.) There's a big difference between sending out a notice that includes one-paragraph summary (the Abstract) versus automatically including the entire document of 20-100 pages. The exercise of producing a one-paragraph summary requires some discipline and understanding of the work that was done. I see this as a meaningful value-add, over the full detail of that work which is the entire document. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From ned.freed@mrochek.com Mon Feb 6 10:16:46 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11D0C21F86F0 for ; Mon, 6 Feb 2012 10:16:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hi5Z54dDkcAa for ; Mon, 6 Feb 2012 10:16:45 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 7D67421F86C9 for ; Mon, 6 Feb 2012 10:16:45 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OBO07UZAU8002JAW@mauve.mrochek.com> for apps-discuss@ietf.org; Mon, 6 Feb 2012 10:16:43 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OBHM72OXPS00ZUIL@mauve.mrochek.com>; Mon, 6 Feb 2012 10:16:40 -0800 (PST) Message-id: <01OBO07TM62000ZUIL@mauve.mrochek.com> Date: Mon, 06 Feb 2012 10:05:26 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Mon, 06 Feb 2012 09:49:41 -0800" <4F3012B5.9080107@dcrocker.net> MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed References: <20120204001408.16716.94710.idtracker@ietfa.amsl.com> <01OBKKTPYLIE00ZUIL@mauve.mrochek.com> <4F2EEAA1.7060706@dcrocker.net> <01OBMZ1U2LH4012404@mauve.mrochek.com> <4F3012B5.9080107@dcrocker.net> To: Dave CROCKER Cc: Ned Freed , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Requirement for "obsoletes" in Abstracts X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 18:16:46 -0000 > On 2/5/2012 4:17 PM, Ned Freed wrote: > > There are two problems with this theory, however. The first is that separable > > Abstracts make all sorts of sense when the full document is not readily > > accessible (only in print journal, behind a paywall, blah blah blah.). But > > that's not the case for RFCs. It might have made sense even for RFCs when data > > transfer was expensive, but these days pulling out the Abstract is more trouble > > than it's worth - why not just send the whole thing? The only remaining > > use-case I can think would be some sort of index, and any such index done > > competently will include much more extensive forward and backwards pointers of > > its own. (And it is axiomatic that the far more important forward pointers, > > that is, "this document is obsoleted/updated by RFC N", cannot possibly appear > > in the Abstract.) > There's a big difference between sending out a notice that includes > one-paragraph summary (the Abstract) versus automatically including the entire > document of 20-100 pages. Actually, Dave, my point is that I actually disagree with this assessment. It used to be true. Not anymore. Bandwidth being what it is, nowadays people are lazy and just sent the whole thing. In fact people forward groups of articles to me - sometimes very large groups - fairly regularly and of late the only time I can recall them bothering to just send the abstract is when that's all they have. This is even, and perhaps especially, true when the article is a PDF. (Adobe seems to be making it harder and harder to extract portions of the text.) People just don't care about size any more. > The exercise of producing a one-paragraph summary requires some discipline and > understanding of the work that was done. I see this as a meaningful value-add, > over the full detail of that work which is the entire document. I think that the abstract's value has dropped exponentially for RFCs - and I also think it's reflected in the quality of the abstracts we see these days. (When I-D announcements come out I increasingly find myself having to click on the link to find out what the draft is actually about.) I also think it is a problem not worth spending time solving, for reasons that should be obvious. Ned From ylafon@w3.org Mon Feb 6 12:51:32 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7A2221F87C5 for ; Mon, 6 Feb 2012 12:51:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.818 X-Spam-Level: X-Spam-Status: No, score=-8.818 tagged_above=-999 required=5 tests=[AWL=-1.181, BAYES_00=-2.599, J_CHICKENPOX_111=0.6, J_CHICKENPOX_45=0.6, MISSING_SUBJECT=1.762, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2cUmwHzeE6K9 for ; Mon, 6 Feb 2012 12:51:32 -0800 (PST) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 5B2A821F87C4 for ; Mon, 6 Feb 2012 12:51:32 -0800 (PST) Received: from ylafon by jay.w3.org with local (Exim 4.69) (envelope-from ) id 1RuVX7-0005L9-Of; Mon, 06 Feb 2012 15:51:29 -0500 Date: Mon, 6 Feb 2012 15:51:29 -0500 (EST) From: Yves Lafon To: apps-discuss@ietf.org, draft-snell-atompub-tombstones.all@tools.ietf.org Message-ID: User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=ISO-8859-15 Content-Transfer-Encoding: QUOTED-PRINTABLE Subject: [apps-discuss] (no subject) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 20:51:33 -0000 Dear all, I have been selected as the Applications Area Directorate reviewer for=20 this draft (for background on appsdir, please see=20 http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). Document: draft-snell-atompub-tombstones-14 Title: The Atom "deleted-entry" Element Reviewer: Yves Lafon Review Date: 6 Feb 2012 Summary: This draft is almost ready for publication as Informational RFC,= =20 there is a minor issue with the ref. section, and a clarification request= =20 on a MUST-level requirement that is non-blocking. First, the clarification request: I noted that in 3/ "The at:deleted-entry= =20 element" It says: << An Atom feed MAY contain any number of at:deleted-entry elements, but MUST NOT contain more than one with the same combination of ref and when attribute values. >> then later << Implementors should note that the at:deleted-entry element is informative in nature only and may be ignored by Atom processors. The presence of an at:deleted-entry element does not guarantee that the atom:entry to which it is referring will no longer be available. >> If it is informative only, why in the first paragraph there is a MUST NOT= =20 on duplicate at:deleted-entry with same 'ref' and 'when', especially as=20 two delete may happen in the same second while being different. What is the rationale for having a MUST NOT instead of a SHOULD NOT? --=20 In the reference section, the link to XML is to the third edition while=20 the fifth edition was published in 2008 [1], for namespaces in XML, it is= =20 to the first edition while the third edition [2] was published in 2009,=20 and for XML base, the first edition instead of the second edition [3]. Was that done on purpose (and then why?) or should the ref section be=20 updated? Cheers, [1] [2] [3] --=20 Baroula que barouleras, au ti=E9u toujou t'entourneras. ~~Yves From wmills@yahoo-inc.com Mon Feb 6 21:46:49 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A86421F853C for ; Mon, 6 Feb 2012 21:46:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.063 X-Spam-Level: X-Spam-Status: No, score=-16.063 tagged_above=-999 required=5 tests=[AWL=-0.879, BAYES_40=-0.185, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b8QjYBzOyiqb for ; Mon, 6 Feb 2012 21:46:48 -0800 (PST) Received: from nm3.bullet.mail.bf1.yahoo.com (nm3.bullet.mail.bf1.yahoo.com [98.139.212.162]) by ietfa.amsl.com (Postfix) with SMTP id C5FAE21F8552 for ; Mon, 6 Feb 2012 21:46:47 -0800 (PST) Received: from [98.139.212.151] by nm3.bullet.mail.bf1.yahoo.com with NNFMP; 07 Feb 2012 05:46:44 -0000 Received: from [98.139.212.245] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 07 Feb 2012 05:46:43 -0000 Received: from [127.0.0.1] by omp1054.mail.bf1.yahoo.com with NNFMP; 07 Feb 2012 05:46:43 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 921272.63177.bm@omp1054.mail.bf1.yahoo.com Received: (qmail 80260 invoked by uid 60001); 7 Feb 2012 05:46:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1328593603; bh=Qir2qXmaqrbSQiaqbXJhxqsCGeadrvRAE61boAGB0RA=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type; b=ESVy1hqlpY1pdjdwhnahGlCPt8I7eXqo0ho4Bjznd7r868vVoZYkNlsA6Apo9S/FXlBzrPzKENKq/fqHoMdrGFyqbrIkBVhyWylr7EMSYlNKyVQdysnqOOnORXmQfHvYeUQKSH6ldSEpImOV27JSiHqAxhG/xOM2VL+e9KTpByM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type; b=sUONuZw8dRtwPv3zd+HYR9tnrB/Fbf+I7St9klUJL1JmLiLQpoMdX/9zd6ZdA8a3PGmjsh39nRcAQhMXNPeUL8StizRtuItHs7XuOw/YqS9zfDZzALpnQ6kSTYJWjyk9tyax4Wev5CjFo9YSyWW6hgblWAwOmCXtDag2X0FlQgY=; X-YMail-OSG: 9d.4qMgVM1l7UP0wpz.mu7F8eIrOr_NMCpLitUpJVAzNhsG 3bE18ttLcEoU0MVUV3PKr3Nxxdka9LW3J8V.VF2TAHX8fG.a38rAFVoFxTKa 7AudmqNCQEj.iPLrZEGtaxbfnrnC_oA6Gi2B15LcxOhrRbGBeX85CXfiI.tJ LNsFaBoPGiiNOpk05695G3pjL8MByUdYUHg7m0sjEiGNWmpE9y_gWeRb0aSj dj8hDct7wXT.DcfzJzI2EPifkfL7U3puJ7PXmfSMjF.6YwzdFHzIwyRTBc.O kEW5Ij2dApJF_qW24XArx1nA5CtTG_g93SsWwJk4HQWsM4gVbRL2Mn3US0jh FlxIhUWx9spF3r.uR0DYnzxDtRkoTTbW52XfrLzR6oyHYwkzSxex9bHcewMP iVAdmjp3Mi4mooukPyhO.L6duCtKoV3MMfw-- Received: from [209.131.62.115] by web31813.mail.mud.yahoo.com via HTTP; Mon, 06 Feb 2012 21:46:43 PST X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.117.340031 Message-ID: <1328593603.37879.YahooMailNeo@web31813.mail.mud.yahoo.com> Date: Mon, 6 Feb 2012 21:46:43 -0800 (PST) From: William Mills To: "apps-discuss@ietf.org" , draft-ietf-dnsext-ecdsa.all@tools.ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="767760015-1450876057-1328593603=:37879" Cc: "iesg@ietf.org" Subject: [apps-discuss] APPSDIR Review of draft-ietf-dnsext-ecdsa-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 05:46:49 -0000 --767760015-1450876057-1328593603=:37879 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Document: draft-ietf-dnsext-ecdsa-04=0A=0ATitle: Elliptic Curve DSA for DNS= SEC=0A=0AReviewer: William J. Mills=0A=0A=0AReview Date: February 6th, 2012= =0A=0AIETF Last Call Date: NA=0A=0AIESG Telechat Date: NA=0A=0ASummary: Thi= s draft informational RFC is ready for publication subject to correcting on= e major issue.=0ACaveats: I'm not a DNS expert, so while this looks right t= o me there may be something obvious that I missed.=0A=0AMajor Issues: =0A= =0ASection 4 paragraph 2: While this is an informational RFC, "The two inte= gers, each of which is formatted as a simple octet string, are combined int= o a single longer=0A octet string ..." is not well enough defined.=A0 The= examples are base64 encoded and it looks like what we have there is for in= stance 2 48byte integers concatenated.=A0 =0A=0AThis document should do one= of:=0A-=A0=A0=A0 quote the normative language from the appropriate specifi= cation for how these integers are to be formatted=0A-=A0=A0=A0 cite the nor= mative specification explicitly in this paragraph=0A-=A0=A0=A0 if there is = no normative language already then this spec is going to have to become nor= mative (not likely)=0A=0A=0A=0AMinor Issues: [list any minor issues such as= text that is unclear or confusing, preferably by section number] =0A=0A=0A= Section 1 paragraph 5:=0A=0AIs the computational difference here simply inf= ormational?=A0 If so it might want to move out of the introduction. =0A=0A= =0AIf the computation cost is =0Ameaningful then that impact should probabl= y be discussed a little more (probably in a new section?) =0Aso the impleme= nter can make an informed choice about what will be right =0Afor their use = case.=A0 Presumably the signatures could actually be computed once per zone= file load, that probably depends on the implementation.=A0 Similar savings= can probably be had on the client doing a lookup, caching the previous val= ues and checking against the returned signature so the validation only need= be done once per item.=A0 =0A=0A=0A=0ANits:=0A=0ANone.=0A --767760015-1450876057-1328593603=:37879 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
=0AD= ocument: draft-ietf-dnsext-ecdsa-04

=0ATitle: Elli= ptic Curve DSA for DNSSEC

=0AReviewer: William J. = Mills
=0A

Review Date: February 6th, 2012
=

=0AIETF Last Call Date: NA

=0AIESG Telech= at Date: NA

=0A
=0A
=0ASummary: This draft informati= onal RFC is ready for publication subject to correcting one major issue.
Caveats: I'm not a DNS expert, so while this looks right to me there= may be something obvious that I missed.

Major Issues:

Secti= on 4 paragraph 2: While this is an informational RFC, "The two integers, ea= ch of which is formatted as a simple octet string, are combined into a sing= le longer=0A octet string ..." is not well enough defined.  The exam= ples are base64 encoded and it looks like what we have there is for instanc= e 2 48byte integers concatenated. 

This document should do one= of:
-    quote the normative = language from the appropriate specification for how these integers are to b= e formatted
-    cite the normative s= pecification explicitly in this paragraph
-&n= bsp;   if there is no normative language already then this spec i= s going to have to become normative (not likely)

<= div>
=0A
Minor Issues: [list any minor issues such as text tha= t is unclear or confusing, preferably by section number]
Section 1 paragraph 5:

Is the computat= ional difference here simply informational?  If so it might want to mo= ve out of the introduction.

If the computatio= n cost is =0Ameaningful then that impact should probably be discussed a lit= tle more (probably in a new section?) =0Aso the implementer can make an inf= ormed choice about what will be right =0Afor their use case.  Presumab= ly the signatures could actually be computed once per zone file load, that = probably depends on the implementation.  Similar savings can probably = be had on the client doing a lookup, caching the previous values and checki= ng against the returned signature so the validation only need be done once = per item. 


Nits:

None.
=0A=0A
--767760015-1450876057-1328593603=:37879-- From ylafon@w3.org Tue Feb 7 00:46:49 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CF2121F871A for ; Tue, 7 Feb 2012 00:46:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.305 X-Spam-Level: X-Spam-Status: No, score=-9.305 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, J_CHICKENPOX_111=0.6, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i51SbWSUetAg for ; Tue, 7 Feb 2012 00:46:48 -0800 (PST) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id B229121F8711 for ; Tue, 7 Feb 2012 00:46:48 -0800 (PST) Received: from ylafon by jay.w3.org with local (Exim 4.69) (envelope-from ) id 1RughK-000485-O7; Tue, 07 Feb 2012 03:46:46 -0500 Date: Tue, 7 Feb 2012 03:46:46 -0500 (EST) From: Yves Lafon To: apps-discuss@ietf.org, draft-snell-atompub-tombstones.all@tools.ietf.org In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Subject: [apps-discuss] Review of draft-snell-atompub-tombstones-14 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 08:46:49 -0000 On Mon, 6 Feb 2012, Yves Lafon wrote: It's always better with a proper subject line :) > Dear all, > > I have been selected as the Applications Area Directorate reviewer for th= is=20 > draft (for background on appsdir, please see=20 > http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate= ). > > Document: draft-snell-atompub-tombstones-14 > Title: The Atom "deleted-entry" Element > Reviewer: Yves Lafon > Review Date: 6 Feb 2012 > > Summary: This draft is almost ready for publication as Informational RFC,= =20 > there is a minor issue with the ref. section, and a clarification request= on=20 > a MUST-level requirement that is non-blocking. > > First, the clarification request: I noted that in 3/ "The at:deleted-entr= y=20 > element" > > It says: > << > An Atom feed MAY contain any number of at:deleted-entry elements, but > MUST NOT contain more than one with the same combination of ref and > when attribute values. >>>=20 > then later > << > Implementors should note that the at:deleted-entry element is > informative in nature only and may be ignored by Atom processors. > The presence of an at:deleted-entry element does not guarantee that > the atom:entry to which it is referring will no longer be available. >>>=20 > > If it is informative only, why in the first paragraph there is a MUST NOT= on=20 > duplicate at:deleted-entry with same 'ref' and 'when', especially as two= =20 > delete may happen in the same second while being different. > What is the rationale for having a MUST NOT instead of a SHOULD NOT? > > --=20 Baroula que barouleras, au ti=E9u toujou t'entourneras. ~~Yves From ietfc@btconnect.com Tue Feb 7 03:28:53 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C29FF21F8607 for ; Tue, 7 Feb 2012 03:28:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[AWL=0.683, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HCOvrIg+fSCx for ; Tue, 7 Feb 2012 03:28:50 -0800 (PST) Received: from mail.btconnect.com (c2bthomr07.btconnect.com [213.123.20.125]) by ietfa.amsl.com (Postfix) with ESMTP id 55E9A21F8606 for ; Tue, 7 Feb 2012 03:28:48 -0800 (PST) Received: from host86-163-138-100.range86-163.btcentralplus.com (HELO pc6) ([86.163.138.100]) by c2bthomr07.btconnect.com with SMTP id GHP57876; Tue, 07 Feb 2012 11:28:34 +0000 (GMT) Message-ID: <02c801cce583$4394bf40$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Ned Freed" References: <01OBLXK8STQ600ZUIL@mauve.mrochek.com> Date: Tue, 7 Feb 2012 11:28:39 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0302.4F310AE2.000E, actions=TAG X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2012.1.30.73017:17:7.944, ip=86.163.138.100, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __MULTIPLE_RCPTS_CC_X2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __FRAUD_BODY_WEBMAIL, __URI_NO_WWW, __URI_NO_PATH, BODY_SIZE_10000_PLUS, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, MULTIPLE_RCPTS, RDNS_SUSP, __FRAUD_WEBMAIL X-Junkmail-Status: score=10/50, host=c2bthomr07.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0207.4F310AE3.00C4,ss=1,re=0.000,fgs=0, ip=0.0.0.0, so=2011-07-25 19:15:43, dmn=2011-05-27 18:58:46, mode=multiengine X-Junkmail-IWF: false Cc: Ned Freed , apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-media-type-regs-00.txt; now -01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 11:28:53 -0000 Tom Petch ----- Original Message ----- From: "Ned Freed" To: "Mykyta Yevstifeyev" Cc: "Ned Freed" ; Sent: Sunday, February 05, 2012 7:14 AM Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-media-type-regs-00.txt; now -01 > > 2012/2/4 Ned Freed > > > > > > > In Section 3.1: when specifying the procedures for registration media > > > > > types > > > > > > in Standards Tree, you mentioned (in terms of RFC 5226): IESG > > > approval, > > > > > > Specification Required, IETF Consensus, RFC Required with IESG > > > Approval, > > > > > > i.e. 4 different registration policies. Whereas they serve a variety > > > of > > > > > > possible cases, I think we would benefit from a single policy which > > > would > > > > > > cover all of them. I suppose it is "Specification Required with IESG > > > > > > Approval" that would cover the following cases: (1) IESG-approved > > > > > document, > > > > > > (2) specification of other standards body; registration undergoing > > > IESG > > > > > > approval, (3) non-IESG-approved RFCs, registration of which also > > > undergo > > > > > > IESG approval. The possible cases may also be discussed, though. > > > > > > > > > > > MY> Also relevant in this version. > > > > > > > > > > If I understand what you're trying to do, not going to happen. The main > > > > > point > > > > > of this revision is to remove the need for the IESG to be involved in > > > the > > > > > approval of standards tree types from other SDOs, while retaining their > > > > > role in > > > > > IETF registration approval. As such, your suggestion for a single > > > policy > > > > > for > > > > > all registrations is totally inconsistent with the fundamental goal of > > > this > > > > > revision. > > > > > > > > > > > > I meant procedure for Standards Tree only, and in no way for all > > > > registrations. The four policies I listed are mentioned in Section 3.1 > > > > only, which defines Standards Tree procedures. > > > > > > But that's exactly the point. We're not talking about anything but > > > standards > > > tree registrations here. Yet there are two completely different processes > > > for > > > registering types in the standards tree. You appear to be asking for there > > > to > > > be only one, and having two is the entire point of this revision. > > > > > > Now, if you want to talk about there being a simpler or different set of > > > criteria for or the other of those processes, then you're going to have to > > > make > > > a strong case for doing so. As it is I'm just not seeing any rationale for > > > changing anything in section 3.1. > > > > > > Mow, reading Section 3.1 of -01, I notice several inconsistencies with the > > above position and between some of the document's parts. I mean: > > > 1) > > > The standards tree is intended for types of general interest to the > > Internet community. Registrations in the standards tree MUST be > > either: > > ... > > 2. registered by a recognized standards body using the > > "Specification Required" IANA registration policy [RFC5226] > > (which implies Expert Review). > > > And later, you say: > > > In the second case the IESG makes the decision on whether the > > registration submitter represents a recognized standards body; > > > So, anyway, IESG isn't fully eliminated from this process, as they are to > > decide on whether some SDO is 'recognized' standards body or not. The > > Expert Reviewer is IESG's representative, and so I don't know the reasons > > to make IESG decide on 'recognized' bodies. > > I completely fail to see any inconsistency or the relevance of any of this. > Yes, the IESG makes a one-time determination that a given group is in fact an > SDO, and in almot every case this is certain to be little more than a pro-forma > action. So what? Once that is done they have no involvement in the media type > approval process, which is the part that happens over and over and over again > and has to be optimized. Ned I understand what you are trying to do but it is more from this e-mail than from the I-D:-( I do think that the I-D stresses the role of the IESG overmuch and leaves me with the impression that each and every request will take up the IESG's time, and only then will be approved for passing on to Expert Review whereas your e-mail suggests that the IESG are only involved once for each SDO and that IANA can recognise the SDO thereafter. I think that this needs calling out more clearly, in the Abstract, since, as you say, it is the point of the I-D. I think too that it needs calling out because others may wonder how it will work in practice. Other SDOs are not like us; the interface to them is different, some have much more formal procedures for interacting with other SDOs so the issue of how a communication is recognised as from an approved SDO, and so not need further IESG involvement, may be hard to achieve. I see IETF Last Call as the acid test of this idea so I think it needs to be in the Abstract. So I like the idea, but wonder if it may come to grief on the politics of other SDOs. Tom Petch > > > Additionally, in Section 8 you > > ask IANA to > > > maintain a list of IESG-recognized standards bodies who are > > allowed to register types in the standards tree. > > > and give no other provisions on this. Is this going to be a registry or > > something else, and how is it going to be filled in? > > It's a list that IANA consults. It is not a registry. Exactly what the text > says currently. > > > Does this mean that > > once IESG allowed some SDO to register their media type in Standards Tree, > > IANA will automatically add this SDO to the list? Or something else? > > The process that happens between IANA and the IESG is intentionally unspecified > here. Since representatives of IANA attend IESG meetings as a matter of routine > and routinely place items on the IESG agenga for action, what's the point of > specifying some completely unnecessary process? > > Remember: The focus here is on getting things done. Not on creating unnecessary > bureaucracy. > > > 2) > > > Registrations published in non-IETF RFC streams are allowed and > > require IESG approval. > > > I don't have an idea of what "are allowed" means? Are they to undergo this > > review depending on whether their authors see it necessary? Doesn't this > > fall into the second case for registrations in Standards Tree? > > Not when the end result is an RFC of any sort, no. Think about it for a minute: > Will people understand the difference between a registration in an independent > submission and one in a IETF document? Do you seriously think it is a good idea > for there to be a way to get a registration into an RFC without some sort of OK > from the IETF? And since the IESG reviews both non-IETF RFCs and IETF-generated > standards tree registrations anyway, doesn't it make sense for them to be the > ones to do it? > > > 3) > > > Standards-tree registrations from recognized standards bodies may be > > submitted directly to the IANA, where they will undergo Expert Review > > [RFC5226] prior to approval. In this case, the Expert Reviewer(s) > > will, among other things, ensure that the required specification > > provides adequate documentation. > > > Doesn't this conflict with the paragraph mentioned above in 1) about IESG's > > decision on 'recognizedness' of SDO? > > In no way, shape, or form does it conflict. In one case the IESG is checking to > see if a given organization is in fact an SDO - which will be a trivial check > in almost every case. In the other case the expert reviewer is checking to see > if the underlying format is properly specified. These are entirely different > activities. > > > Summary. The page-long description of the procedures for Standards Tree > > registration will help nobody in registering media types in this tree. > > That may be your opinion. I doubt very much if anyone else agrees with you. > I absolutely do not. > > > I > > like RFC 4288 description, and RFC 2048 description, which only contained > > three paragraphs which stated these registrations must be approved by > > IESG. Now, if you want to allow other SDO to register their types without > > IESG's approval, that's easy to do by only adding a few words, so stating > > that IETF-sourced and grandfathered registrations in Standards Tree are > > subject to IESG's approval of the document registering them (and this means > > RFC 5226 IETF consensus) and registrations ibid which originate from other > > SDOs are subject to Expert Review who will also review and ensure > > appropriate level of documentation (and this means RFC 5226 Specification > > Required). Also it may be stated that non-IETF-stream RFCs may register > > Standards Tree types with IESG's approval (that's actually what you now > > have, but "are allowed" has already been commented on above). > > I have no real idea what you're getting at here, but it sounds far more complex > that what we have. > > Look. There aren't that many SDOs out there that need to register media types, > and the ones that do create type afer type after type. The approved list will > almost immediately contain them all. Once that happens the process for an SDO > registering a type is they fill in a form, the reviewer reviews, done. Couldn't > possibly be any simpler. > > And at this point I'm done discussing this. > > > > > > > > > > > > > > > Section 6: s/RFC 3978/RFC 5378/ (and in References) > > > > > > > > > > > MY> This is fixed. > > > > > > > > > > > Sections 6 and 8: As your document sets up the registry for > > > +suffixes, it > > > > > > should contain the description as required by RFC 5226, which it > > > > > currently > > > > > > doesn't have. > > > > > > > > > > > MY> This comment still applies. > > > > > > > > > > Description where? I do not understand this one. I also do not see the > > > > > requirement you're talking about anywhere in RFC 5226. (The word > > > > > description > > > > > appears exactly twice, and neither time in a requirement.) > > > > > > > > > > > > I mean your description in Section 6 should follow Section 4.2 of RFC > > > 5226. > > > > > > I don't actually see anything in RFC 5226 that says you have to define > > > a registry using a particular layout in your document - all it says is that > > > certain information has to be provided. And with one important exception, > > > all of that information is currently present, just not in that format. > > > > > > That said, a thought occurs. This is a new registry that's not currently > > > set up, and that means we need to call out the action to create it in the > > > IANA considerations section of this document. So what I'm going to do is > > > add that action to the IANA considerations, which will appear as a list > > > more or less conforming to the list in section 4.2 of RFC 5226. (Most of > > > the list items will simply be references to other sections of the > > > current document.) > > > > > > I wasn't talking about the layout. You could freely describe the registry > > in Section 6 and then reference it later in Section 8. But I meant you > > didn't mention RFC 5226 specification policy for this registry, as well as > > its name (now mentioned). You may add some paragraph to Section 6.1 > > stating that this document creates the registry called "Structured Syntax > > Suffix" and the registration policy is "Expert Review" with the > > registration process spelled out below. Additionally, the structure > > (fields to be present in the registry itself) are to be defined. > > That's implicit in the template. I see no reason to repeat it and no > requirement to. > > > > > > > The sticking point is the initial registry content. I really don't want to > > > clutter up an important process specification that's intended to be used > > > for a > > > long period of time with this crap that's only useful once. (I've always > > > objected to this requirement in RFC 5226 - I think it's excessive rigidity > > > causes more problems than it solves.) So I'm going to try to finesse it by > > > saying that an initial list of the content of the registry effectively > > > already > > > exists and is in IANA 's hands - it's the list of conforming suffixes in > > > current use in the existing media types registry - and direct the media > > > types > > > reviewers to, at the time of registry creation, extract that list and use > > > it as > > > the initial registry content. This also addresses the possibility that an > > > additional legitimate suffix should show up and get registered under the > > > current rules, making having a static list in a document somewhat > > > problematic. > > > > > > I think upon approval of the document Expert Reviewer will examine the > > currently used ones, and we'll be able to publish a separate document > > registering them. > > I see no point in generating such a document. > > Ned > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > From ned.freed@mrochek.com Tue Feb 7 08:00:44 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AED5021F8845 for ; Tue, 7 Feb 2012 08:00:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-HdegJzbf9C for ; Tue, 7 Feb 2012 08:00:44 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id D9EFE21F8843 for ; Tue, 7 Feb 2012 08:00:43 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OBP9QJP8TS00S9TA@mauve.mrochek.com> for apps-discuss@ietf.org; Tue, 7 Feb 2012 08:00:39 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OBHM72OXPS00ZUIL@mauve.mrochek.com>; Tue, 7 Feb 2012 08:00:36 -0800 (PST) Message-id: <01OBP9QHCGEM00ZUIL@mauve.mrochek.com> Date: Tue, 07 Feb 2012 07:38:45 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Tue, 07 Feb 2012 11:28:39 +0100" <02c801cce583$4394bf40$4001a8c0@gateway.2wire.net> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <01OBLXK8STQ600ZUIL@mauve.mrochek.com> <02c801cce583$4394bf40$4001a8c0@gateway.2wire.net> To: "t.petch" Cc: Ned Freed , apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-media-type-regs-00.txt; now -01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 16:00:44 -0000 > I understand what you are trying to do but it is more from this e-mail than from > the I-D:-( That's because the goals of the changes are irrelevant to actually performing the process. I intentionally do not get into those, because such text almost immediately becomes a pointless distraction to people actually trying to get stuff registered. > I do think that the I-D stresses the role of the IESG overmuch and > leaves me with the impression that each and every request will take up the > IESG's time, I disagree, but I'll add some clauses and a sentence clarifying that IESG involvement is a one time thing. > and only then will be approved for passing on to Expert Review > whereas your e-mail suggests that the IESG are only involved once for each SDO > and that IANA can recognise the SDO thereafter. > I think that this needs calling out more clearly, in the Abstract, since, as you > say, it is the point of the I-D. It absolutely does NOT belong in the Abstract. Again, the the purposes and goals of this revision are only relevant during the development process; once this document is published as a BCP this turns into irrelevant material readers have to wade through to undersand the point of the document as well as to get at the actual requirements and process steps. In fact this is very similar to the issue of putting silly "this obsoletes that" crap in the Abstract which is being discussed in another thread. The consensus there so far is that cluttering up the Abstract with this and similar nonsense is a really stupid thing to be doing. > I think too that it needs calling out because others may wonder how it will work > in practice. Other SDOs are not like us; the interface to them is different, > some have much more formal procedures for interacting with other SDOs so the > issue of how a communication is recognised as from an approved SDO, and so not > need further IESG involvement, may be hard to achieve. I see IETF Last Call as > the acid test of this idea so I think it needs to be in the Abstract. Again the answer from me is a very, very, very emphatic NO. And as for interactions with other SDOs that go beyond the basic process; that's not simply a rathole, rather it's a huge chasm I have been explicitly directed by the PTB to avoid in this specification. > So I like the idea, but wonder if it may come to grief on the politics of other > SDOs. Politics in other SDOs have been big problems in the past and I have no doubt will continue to be a problem in the future. But a registration process document is not the place to get into any of this, if for no other reasons than the issues shift over time and anything we write will quickly be dated and may in fact become a serious liability. That said, if you seriously want to fall into this particular chasm and go splat at the bottem, you can always try and get some text about this into the advisory document the HAPPIANA folks are talking about writing. My guess is the IESG will not allow a document containing such text to go forward (I certainly wouldn't if I were on the IESG), but of course I don't speak for them. Ned From miguel.a.garcia@ericsson.com Tue Feb 7 06:12:45 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E47921F856A; Tue, 7 Feb 2012 06:12:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.046 X-Spam-Level: X-Spam-Status: No, score=-10.046 tagged_above=-999 required=5 tests=[AWL=0.553, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tdwggNdibrSp; Tue, 7 Feb 2012 06:12:39 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 5552321F850D; Tue, 7 Feb 2012 06:12:38 -0800 (PST) X-AuditID: c1b4fb3d-b7b26ae000000a35-94-4f313154895c Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 22.4D.02613.451313F4; Tue, 7 Feb 2012 15:12:37 +0100 (CET) Received: from [159.107.25.10] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Tue, 7 Feb 2012 15:12:36 +0100 Message-ID: <4F313153.8050806@ericsson.com> Date: Tue, 7 Feb 2012 15:12:35 +0100 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Enrico Marocco References: <4F2FA266.8040406@telecomitalia.it> In-Reply-To: <4F2FA266.8040406@telecomitalia.it> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Tue, 07 Feb 2012 08:06:45 -0800 Cc: "draft-ietf-simple-chat.all@tools.ietf.org" , IESG , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-simple-chat-13 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 14:12:46 -0000 Hi Enrico: Thanks for your review. See inline comments. On 06/02/2012 10:50, Enrico Marocco wrote: > Document: draft-ietf-simple-chat-13 > Title: Multi-party Chat Using the Message Session Relay Protocol (MSRP) > Reviewers: Alexey Melnicov and Enrico Marocco > Review Date: 2012-02-06 > IETF Last Call Date: 2012-02-06 > > > Summary: This draft is almost ready for publication as a Proposed > Standard, but has a major issue to be taken into consideration and a few > minor issues to be fixed. > > > Major Issue > > The document doesn't describe allowed characters in Nicks and any > normalization that needs to be applied. I think the document clearly describes the allowed characters in nicknames by making a reference to RFC 4975. In Section 7.1, the syntax of the Use-Nickname header is written as: Use-Nickname = "Use-Nickname:" SP nickname nickname = quoted-string ; quoted-string defined in RFC 4975 According to RFC 4975: quoted-string = DQUOTE *(qdtext / qd-esc) DQUOTE qdtext = SP / HTAB / %x21 / %x23-5B / %x5D-7E / UTF8-NONASCII qd-esc = (BACKSLASH BACKSLASH) / (BACKSLASH DQUOTE) BACKSLASH = "\" UPALPHA = %x41-5A ALPHANUM = ALPHA / DIGIT So, I think it is described. With respect to normalization, I am not sure if a nickname needs to be normalized and now this normalization should take place. Let me know the text that you are missing and I will add it to the draft. > > > Minor Issues > > The document strictly forbids multiple To: headers in the CPIM message, > that could be used for example to send public personal messages (i.e. > messages addressed to some particular individual, but shared with the > entire conference, a-la Twitter). If there's a reason for that, some > explanation would be useful. This was a decision taken by the working group due to the complexity. For example, what happens if one of the recipients is correct, but another one is incorrect or has left the chat room. Should the server process the message to one recipient and not to the other? what would be the error? It was also conflicting with requirements for side conferences, something that was part of the deliverables in XCON. At the end of the day, the endpoint can always send multiple messages, each one with a single To header. I agree that this explanation can be added to the draft. > > Figure 1 seems to imply that MSRP relays are mandatory. Since they are > not -- and the draft is pretty clear about it -- I'd suggest to have > some of MSRP flows in the diagram flow straight from the client to the > switch. > Right, we can remove one of the MSRP Relays and leave the other one, indicating that both configurations are possible. > A reference to the SDP mechanism defined in S. 8. would be useful in in > S. 5.2., last paragraph, S. 6.2, last paragraph, and in any other part > that deals with discovering of client capability. > > In Section 5.2: > > The conference focus of a chat room MUST learn the chat room > > How can this be achieved? A forward pointer might be missing here. Yes, correct. We need to explain how, which is by means of the chatroom attribute in SDP (Section 8). We will add the forward pointer. > > capabilities of each participant that joins the chat room. The > conference focus MUST inform the MSRP switch of such support in > order to prevent the MSRP switch from distributing private messages > to participants who do not support private messaging. The recipient > would not be able to render the message as private, and any > potential reply would be sent to the whole chat room. > > In Section 7.1: > > The reservation of a nickname can fail, e.g. if the NICKNAME request > contains a malformed or non-existent Use-Nickname header field, or > if the same nickname has already been reserved by another > participant (i.e., by another URI) in the chat room. The > validation can also fail where the sender of the message is not > entitled to reserve the nickname. In any of these cases the MSRP > switch MUST answer the NICKNAME request with a 423 response. The > semantics of the 423 response are: "Nickname usage failed; the > nickname is not allocated to this user". > > It would be better to use different response codes for different error > conditions. I also sympathize your proposal. We had this for avoiding creating very detailed error conditions. But I wouldn't mind to differentiate both error cases. Perhaps we should take this to the WG for comments. > > > Nits [Only the few that came out in non-nitpicking read] > > S. 3, REQ-3: s/depend no/depend on/ > > S. 4, second paragraph after Figure 2: s/a text/text/ > > A few 2119 refuses can be also found in the text, e.g.: > > S. 5.2, sixth paragraph: s/URI must not/URI MUST NOT/ > > Good catches. We will fix them. Thanks, Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From ht@inf.ed.ac.uk Tue Feb 7 09:31:09 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9442421F888C; Tue, 7 Feb 2012 09:31:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NywJqaOM2DgN; Tue, 7 Feb 2012 09:31:08 -0800 (PST) Received: from nougat.ucs.ed.ac.uk (nougat.ucs.ed.ac.uk [129.215.13.205]) by ietfa.amsl.com (Postfix) with ESMTP id 5029721F8882; Tue, 7 Feb 2012 09:31:07 -0800 (PST) Received: from nutty.inf.ed.ac.uk (nutty.inf.ed.ac.uk [129.215.33.33]) by nougat.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id q17HUds4013044; Tue, 7 Feb 2012 17:30:44 GMT Received: from calexico.inf.ed.ac.uk (calexico.inf.ed.ac.uk [129.215.24.15]) by nutty.inf.ed.ac.uk (8.13.8/8.13.8) with ESMTP id q17HUc4j007695; Tue, 7 Feb 2012 17:30:38 GMT Received: from calexico.inf.ed.ac.uk (localhost [127.0.0.1]) by calexico.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id q17HUc1B020959; Tue, 7 Feb 2012 17:30:38 GMT Received: (from ht@localhost) by calexico.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id q17HUbak020955; Tue, 7 Feb 2012 17:30:37 GMT X-Authentication-Warning: calexico.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: apps-discuss@ietf.org, barryleiba@gmail.com, dick.hardt@gmail.com, dr@fb.com, eran@hueniverse.com, hannes.tschofenig@gmx.net, stephen.farrell@cs.tcd.ie From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Tue, 07 Feb 2012 17:30:37 +0000 Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.4.21 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at nougat.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.13.205 X-Mailman-Approved-At: Tue, 07 Feb 2012 09:34:04 -0800 Cc: iesg@ietf.org Subject: [apps-discuss] Appsdir review of draft-ietf-oauth-v2-23 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 17:31:09 -0000 I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-oauth-v2-23 Title: The OAuth 2.0 Authorization Protocol Reviewer: Henry S. Thompson Review Date: 2012-02-07 IETF Last Call Date: 2012-01-24 Summary: This draft is almost ready for publication as an Proposed Standard but has a few issues that should be fixed before publication [Note - My expertise is in the areas of markup and architecture, with only the average geek's understanding of security and cryptographic technologies. Any comments below on security issues are therefore of the nature of general audience concerns, rather than technical worries.] Major Issues: 3.1.2.1 The failure to require TLS here is worrying. At the very least I would expect a requirement that clients which do _not_ require TLS MUST provide significant user feedback calling attention to this -- by analogy, absence of a padlock does _not_ suffice. . . 2.1.2.5 In a somewhat parallel case, I would expect this section to at least explain why the SHOULD NOT is not a MUST NOT. Since in practice the distinction between trusted and untrusted 3rd-party scripting is difficult if not impossible to draw, as written the 2nd para is effectively overriden by the third. 11 It seems at best old-fashioned that the designer of a new access token type, parameter, endpoint response type or extension error has no better tool available than Google to help him/her discover whether the name they have in mind is in use already. The same is true under the proposed approach for any developer trying to determine what they can use or must support. Is there some reason that mandated URI templates, after the fashion of http://www.iana.org/assignments/media-types/text/... are not mandated for the registries, e.g. http://www.iana.org/assignments/access-token-types/bearer ? If there is a good reason, please use it to at least explicitly acknowledge and justify the basis for failing to provide a way for users and developers to use the "follow your nose" strategy [1]. If there is no good reason, please include the appropriate language to require something along the lines suggested above. If you need a model, see [2]. Minor Issues: A short summary of the changes from OAuth 1.0/RFC5849 would have been helpful, and it might still be a good idea to add one. . . 4.1 Would it be helpful to indicate that steps D&E may occur at any time after C, and may be repeated subsequently? 11.1 It might be useful to have an 11.1.2, which repeats references to the bearer and mac access token type registration drafts? Nits: Apostrophes are missing in a few places in the text ("end-user s", "OAuth s"), presumably because a non-standard character encoding was used by one of the editors. 9 The bulleted list after "When choosing between an external or embedded user-agent, developers should consider:" contains several grammatical errors, e.g. "External user-agents. . . It" and "Embedded user-agents educate end-user" . . . ht [1] http://www.w3.org/2001/tag/doc/selfDescribingDocuments.html [2] http://www.w3.org/2005/04/xpointer-schemes/ -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From ben@nostrum.com Tue Feb 7 12:11:15 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC05121F855F; Tue, 7 Feb 2012 12:11:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8iy1UsJ8xf7f; Tue, 7 Feb 2012 12:11:12 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 272F221F84F2; Tue, 7 Feb 2012 12:11:11 -0800 (PST) Received: from [10.0.1.2] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q17KB7Ze001803 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 7 Feb 2012 14:11:07 -0600 (CST) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Ben Campbell In-Reply-To: <4F313153.8050806@ericsson.com> Date: Tue, 7 Feb 2012 14:11:09 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F2FA266.8040406@telecomitalia.it> <4F313153.8050806@ericsson.com> To: "Miguel A. Garcia" X-Mailer: Apple Mail (2.1257) Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: "draft-ietf-simple-chat.all@tools.ietf.org" , IESG , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-simple-chat-13 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 20:11:19 -0000 On Feb 7, 2012, at 8:12 AM, Miguel A. Garcia wrote: >> In Section 7.1: >>=20 >> The reservation of a nickname can fail, e.g. if the NICKNAME = request >> contains a malformed or non-existent Use-Nickname header field, = or >> if the same nickname has already been reserved by another >> participant (i.e., by another URI) in the chat room. The >> validation can also fail where the sender of the message is not >> entitled to reserve the nickname. In any of these cases the MSRP >> switch MUST answer the NICKNAME request with a 423 response. The >> semantics of the 423 response are: "Nickname usage failed; the >> nickname is not allocated to this user". >>=20 >> It would be better to use different response codes for different = error >> conditions. >=20 > I also sympathize your proposal. We had this for avoiding creating = very detailed error conditions. But I wouldn't mind to differentiate = both error cases. Perhaps we should take this to the WG for comments. I agree that if we think we need to allocate additional error codes, we = should run that by the work group. Miguel, can you send a note to the = SIMPLE list on that? Thanks! Ben.= From jasnell@us.ibm.com Tue Feb 7 15:46:24 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90BAC11E8074 for ; Tue, 7 Feb 2012 15:46:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.399 X-Spam-Level: X-Spam-Status: No, score=-9.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_111=0.6, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JgF24mekM7gM for ; Tue, 7 Feb 2012 15:46:24 -0800 (PST) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.152]) by ietfa.amsl.com (Postfix) with ESMTP id E5DA411E8072 for ; Tue, 7 Feb 2012 15:46:23 -0800 (PST) Received: from /spool/local by e34.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 7 Feb 2012 16:46:22 -0700 Received: from d03dlp03.boulder.ibm.com (9.17.202.179) by e34.co.us.ibm.com (192.168.1.134) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 7 Feb 2012 16:46:19 -0700 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by d03dlp03.boulder.ibm.com (Postfix) with ESMTP id CDAB519D8026 for ; Tue, 7 Feb 2012 16:46:15 -0700 (MST) Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q17NkHkd026590 for ; Tue, 7 Feb 2012 16:46:18 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q17NkELP005788 for ; Tue, 7 Feb 2012 16:46:14 -0700 Received: from d03nm122.boulder.ibm.com (d03nm122.boulder.ibm.com [9.63.40.217]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q17NkEVV005752; Tue, 7 Feb 2012 16:46:14 -0700 In-Reply-To: References: X-KeepSent: E36E149B:80A35836-8825799D:008184C1; type=4; name=$KeepSent To: Yves Lafon X-Mailer: Lotus Notes Release 8.5.2 August 10, 2010 Message-ID: From: James M Snell Date: Tue, 7 Feb 2012 15:46:11 -0800 X-MIMETrack: Serialize by Router on D03NM122/03/M/IBM(Release 8.5.3 ZX853HP5|January 12, 2012) at 02/07/2012 16:46:13 MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12020723-1780-0000-0000-000002F4BC95 X-IBM-ISS-SpamDetectors: X-IBM-ISS-DetailInfo: BY=3.00000246; HX=3.00000182; KW=3.00000007; PH=3.00000001; SC=3.00000001; SDB=6.00111827; UDB=6.00027677; UTC=2012-02-07 23:46:20 X-Mailman-Approved-At: Wed, 08 Feb 2012 08:04:47 -0800 Cc: apps-discuss@ietf.org, draft-snell-atompub-tombstones.all@tools.ietf.org Subject: Re: [apps-discuss] Review of draft-snell-atompub-tombstones-14 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 23:46:24 -0000 Yves Lafon wrote on 02/07/2012 12:46:46 AM: [snip] > > Review of draft-snell-atompub-tombstones-14 > > On Mon, 6 Feb 2012, Yves Lafon wrote: > > It's always better with a proper subject line :) Yes, quite... my spam filter flagged the first one because of the lack = of a subject line ;-) > > > Dear all, > > > > I have been selected as the Applications Area Directorate reviewerf= or this > > draft (for background on appsdir, please see > > http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectora= te). > > > > Document: draft-snell-atompub-tombstones-14 > > Title: The Atom "deleted-entry" Element > > Reviewer: Yves Lafon > > Review Date: 6 Feb 2012 > > > > Summary: This draft is almost ready for publication as Informationa= l RFC, > > there is a minor issue with the ref. section, and a clarification > request on > > a MUST-level requirement that is non-blocking. > > > > First, the clarification request: I noted that in 3/ "The at:deleted-entry > > element" > > > > It says: > > << > > An Atom feed MAY contain any number of at:deleted-entry elements,= but > > MUST NOT contain more than one with the same combination of ref a= nd > > when attribute values. > >>> > > then later > > << > > Implementors should note that the at:deleted-entry element is > > informative in nature only and may be ignored by Atom processors.= > > The presence of an at:deleted-entry element does not guarantee th= at > > the atom:entry to which it is referring will no longer be availab= le. > >>> > > > > If it is informative only, why in the first paragraph there is a > MUST NOT on > > duplicate at:deleted-entry with same 'ref' and 'when', especially a= s two > > delete may happen in the same second while being different. > > What is the rationale for having a MUST NOT instead of a SHOULD NOT= ? > > > > > While SHOULD NOT would likely work here, the motivation for the MUST NO= T is that I was unable to find any valid cases where multiple deleted-entry elements for the same entry at the same time would appear in a single f= eed. If such duplication did occur, it is either certainly an error or a possible attack vector. The Informative nature is purely a recognition that, as an extension to= Atom, there mere presence of the deleted-entry element in a field does = not guarantee that Atom implementations will be able to actually do anythin= g with it. > -- > Baroula que barouleras, au ti=E9u toujou t'entourneras. > > ~~Yves >= From miguel.a.garcia@ericsson.com Tue Feb 7 23:51:12 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A82321F872A; Tue, 7 Feb 2012 23:51:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.08 X-Spam-Level: X-Spam-Status: No, score=-10.08 tagged_above=-999 required=5 tests=[AWL=0.519, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9OMoTVGeNXLQ; Tue, 7 Feb 2012 23:51:11 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 7B0B921F84E6; Tue, 7 Feb 2012 23:51:10 -0800 (PST) X-AuditID: c1b4fb3d-b7b26ae000000a35-77-4f32296c5faa Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 6B.5E.02613.D69223F4; Wed, 8 Feb 2012 08:51:09 +0100 (CET) Received: from [159.107.24.212] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Wed, 8 Feb 2012 08:51:08 +0100 Message-ID: <4F32296B.3010609@ericsson.com> Date: Wed, 8 Feb 2012 08:51:07 +0100 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Ben Campbell References: <4F2FA266.8040406@telecomitalia.it> <4F313153.8050806@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Wed, 08 Feb 2012 08:05:01 -0800 Cc: "draft-ietf-simple-chat.all@tools.ietf.org" , IESG , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-simple-chat-13 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 07:51:12 -0000 Yes, I will ping the SIMPLE WG. /Miguel On 07/02/2012 21:11, Ben Campbell wrote: > > On Feb 7, 2012, at 8:12 AM, Miguel A. Garcia wrote: > >>> In Section 7.1: >>> >>> The reservation of a nickname can fail, e.g. if the NICKNAME request >>> contains a malformed or non-existent Use-Nickname header field, or >>> if the same nickname has already been reserved by another >>> participant (i.e., by another URI) in the chat room. The >>> validation can also fail where the sender of the message is not >>> entitled to reserve the nickname. In any of these cases the MSRP >>> switch MUST answer the NICKNAME request with a 423 response. The >>> semantics of the 423 response are: "Nickname usage failed; the >>> nickname is not allocated to this user". >>> >>> It would be better to use different response codes for different error >>> conditions. >> >> I also sympathize your proposal. We had this for avoiding creating very detailed error conditions. But I wouldn't mind to differentiate both error cases. Perhaps we should take this to the WG for comments. > > I agree that if we think we need to allocate additional error codes, we should run that by the work group. Miguel, can you send a note to the SIMPLE list on that? > > Thanks! > > Ben. -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From alexey.melnikov@isode.com Wed Feb 8 10:17:15 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E46621E8010; Wed, 8 Feb 2012 10:17:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.177 X-Spam-Level: X-Spam-Status: No, score=-102.177 tagged_above=-999 required=5 tests=[AWL=0.422, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fyRuPTmhsxqG; Wed, 8 Feb 2012 10:17:14 -0800 (PST) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id EFB0321E8019; Wed, 8 Feb 2012 10:17:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1328725031; d=isode.com; s=selector; i=@isode.com; bh=22OsjMD9vGKcp0leXaleJwVilw9Q0VYbCTNhd0ZVVco=; 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=C44bIXAMWnSK5opMpeaSu8kfjR6z9dDpSSa7qEilw+y1bV96h3f27NnlFTTuqjV8+ooQ0a 5LTFJwvA8mcHfaiTocZlua5zMd4Ek2Zn9sfH2xf7I1ikI1MhtXyStKFkxmCqtcqcRIDJgw snIC5RipyLudGmDOA3ogQpSrqxkQbDo=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 8 Feb 2012 18:17:10 +0000 Message-ID: <4F32BC2A.9040503@isode.com> Date: Wed, 08 Feb 2012 18:17:14 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 To: "Miguel A. Garcia" References: <4F2FA266.8040406@telecomitalia.it> <4F313153.8050806@ericsson.com> In-Reply-To: <4F313153.8050806@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "draft-ietf-simple-chat.all@tools.ietf.org" , IESG , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-simple-chat-13 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 18:17:15 -0000 Hi Miguel, On 07/02/2012 14:12, Miguel A. Garcia wrote: > Hi Enrico: > > Thanks for your review. > > See inline comments. > > On 06/02/2012 10:50, Enrico Marocco wrote: >> Document: draft-ietf-simple-chat-13 >> Title: Multi-party Chat Using the Message Session Relay Protocol (MSRP) >> Reviewers: Alexey Melnicov and Enrico Marocco >> Review Date: 2012-02-06 >> IETF Last Call Date: 2012-02-06 >> >> >> Summary: This draft is almost ready for publication as a Proposed >> Standard, but has a major issue to be taken into consideration and a few >> minor issues to be fixed. >> >> >> Major Issue >> >> The document doesn't describe allowed characters in Nicks and any >> normalization that needs to be applied. > > I think the document clearly describes the allowed characters in > nicknames by making a reference to RFC 4975. In Section 7.1, the > syntax of the Use-Nickname header is written as: > > Use-Nickname = "Use-Nickname:" SP nickname > nickname = quoted-string > ; quoted-string defined in RFC 4975 > > According to RFC 4975: > > quoted-string = DQUOTE *(qdtext / qd-esc) DQUOTE > qdtext = SP / HTAB / %x21 / %x23-5B / %x5D-7E > / UTF8-NONASCII > qd-esc = (BACKSLASH BACKSLASH) / (BACKSLASH DQUOTE) > BACKSLASH = "\" > UPALPHA = %x41-5A > ALPHANUM = ALPHA / DIGIT > > > So, I think it is described. If ABNF is saying that only UTF-8 is allowed, then the current text is Ok. > > With respect to normalization, I am not sure if a nickname needs to be > normalized and now this normalization should take place. Let me know > the text that you are missing and I will add it to the draft. Have a look at ResourcePrep: http://datatracker.ietf.org/doc/draft-ietf-xmpp-6122bis/ If you can't wait for Precis to finish, you can also use an older version (based on StringPrep): http://www.rfc-editor.org/rfc/rfc6122.txt From gsalguei@cisco.com Wed Feb 8 16:52:29 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD54121F84D7 for ; Wed, 8 Feb 2012 16:52:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.448 X-Spam-Level: X-Spam-Status: No, score=-9.448 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_DEALS=2.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4vd32GEzwl0M for ; Wed, 8 Feb 2012 16:52:28 -0800 (PST) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by ietfa.amsl.com (Postfix) with ESMTP id 8E6D421F84A0 for ; Wed, 8 Feb 2012 16:52:23 -0800 (PST) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q190qMFC013731 for ; Wed, 8 Feb 2012 19:52:23 -0500 (EST) Received: from dhcp-64-102-210-22.cisco.com (dhcp-64-102-210-22.cisco.com [64.102.210.22]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q190qGdY012269; Wed, 8 Feb 2012 19:52:16 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-17-401701545 From: Gonzalo Salgueiro In-Reply-To: Date: Wed, 8 Feb 2012 19:52:16 -0500 Message-Id: References: To: Claudio Allocchio X-Mailer: Apple Mail (2.1084) Cc: "sip-clf@ietf.org Mailing" , apps-discuss@ietf.org, Gonzalo Camarillo , draft-ietf-sipclf-format.all@tools.ietf.org Subject: Re: [apps-discuss] AppsDir review of draft-ietf-sipclf-format-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 00:52:29 -0000 --Apple-Mail-17-401701545 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Claudio -=20 Thanks for the thorough review. See inline comments. On Jan 19, 2012, at 5:21 AM, Claudio Allocchio wrote: >=20 > I have been selected as the Applications Area Directorate reviewer for = this draft (for background on appsdir, please see = http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate)= . >=20 > Please resolve these comments along with any other Last Call comments = you may receive. Please wait for direction from your document shepherd = or AD before posting a new version of the draft. >=20 > Document: draft-ietf-sipclf-format-05 > Title: Format for the Session Initiation Protocol (SIP) Common Log = Format > (CLF) > Reviewer: Claudio Allocchio > Review Date: 2012-01-18 > IETF Last Call Date: unknown > IESG Telechat Date: unknown >=20 > NOTE: is there is an IESG telechat which I'm missing, just copy this = messae to iesg ML! >=20 > Summary: >=20 > This draft is ready for publication as a Proposed Standard RFC; it = just needs one consideration about a minor issue about an external = reference, and fixing some Nits. This is great news. Thanks. >=20 > Major Issues: >=20 > NONE >=20 > Minor Issues: >=20 > just one ! >=20 > * Section "3. Document Conventions" >=20 > The authors have decided "For the sake of clarity and completeness" to = quote a full section of RFC4475 into this document. However there were = quite long discussions in the Apps Dir in other reviews if this quoting = practice is appropriate or not, because it can lead to discrepacies, = when the quoted document is updated or obsoleted, resuing in confusion = for the readers who just trust the quoted text without checking the = state of the referenced document. I would suggest, as in the other = cases, NOT to quote the external text, but to use an explicit external = reference only, urging the reader to check that "for the sake of = clarity". I agree with the position but in this particular case I'm of the mind = that removing that text and referencing the RFC diminishes the = effectiveness of that section. It is my preference to leave the quoted = text (which is very short) embedded in this document as it is critical = to understanding the notation used throughout the document. >=20 > Nits: >=20 > * Section "Copyright Notice" >=20 > change the year to 2012. Will do this. >=20 > * Section "3. Document Conventions" >=20 > remember to change "formatting rules for Internet-Drafts" into = "formatting rules for RFCs" when published. Great point. I'll proactively beat the RFC Editor to this. >=20 > * Section "4. Format" >=20 > I do understand that it probably does not fit into the I-D formatting = line lenghts, but... maybe an attempt to add aside the SIP CLF record = depicted in Figure 1 the grouping described as >=20 > > > >=20 > in the figure 1 itself (on the left?) may help in reading the = distinction, and maybe may even not require to repeat portions of the = figure itself later in the I-D, like in figure 3, figure 4 and figure 5. = It is really a nit and just a suggestion. Not really important. >=20 > What I am suggesting: >=20 > +----------------------------------+ > /| | > / | | > P | | > o | | > I i | | > n n | | > d t | | > e e | | > x r | | > s | | > \ | | > \| | > +----------------------------------+ > /| | > / | | > M | | > a F | | > n i | | > d e | | > a l | | > t d | | > o s | | > r | | > y \ | | > \| | > +----------------------------------+ > /| | > / | | > O | | > p F | | > t i | | > i e | | > o l | | > n d | | > a s | | > l | | > \ | | > \| | > +----------------------------------+ >=20 This is something that we have discussed and have not found an elegant = solution for.=20 While there are maintenance risks it was thought to be very valuable to = display the=20 pertinent portion of the complete CLF within the section where that was = discussed.=20 I'll do my best to ensure that they are all copied over properly from = Figure 1. > * Section "5. Example SIP CLF Record" >=20 > Remember to change "Due to internet-draft conventions" into "Due to = RFC conventions" when published (and also "to format it for an RFC" = later on...). Indeed. >=20 > * =46rom the DataTracker ID Nits check tool (References Nits): >=20 > =3D=3D Unused Reference: 'RFC5612' is defined on line 984, but no = explicit > reference was found in the text >=20 > ** Downref: Normative reference to an Informational draft: > draft-ietf-sipclf-problem-statement (ref. > 'I-D.ietf-sipclf-problem-statement') >=20 > Comment: the document shepard is aware and has a solution for these = nits. Just apply it. Absolutely. Thanks, Gonzalo >=20 > = --------------------------------------------------------------------------= ---- > Claudio Allocchio G A R R = Claudio.Allocchio@garr.it > Senior Technical Officer > tel: +39 040 3758523 Italian Academic and G=3DClaudio; = S=3DAllocchio; > fax: +39 040 3758565 Research Network P=3Dgarr; A=3Dgarr;= C=3Dit; >=20 > PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss >=20 --Apple-Mail-17-401701545 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Claudio - 

Thanks for the thorough = review.

See inline = comments.

On Jan 19, 2012, at 5:21 AM, Claudio = Allocchio wrote:


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

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

Document: draft-ietf-sipclf-format-05
Title: Format for = the Session Initiation Protocol (SIP) Common Log Format
=       (CLF)
Reviewer: Claudio = Allocchio
Review Date: 2012-01-18
IETF Last Call Date: = unknown
IESG Telechat Date: unknown

NOTE: is there is an IESG = telechat which I'm missing, just copy this messae to iesg = ML!

Summary:

This draft is ready for publication as a = Proposed Standard RFC; it just needs one consideration about a minor = issue about an external reference, and fixing some = Nits.

This is great news. = Thanks.

Major = Issues:

NONE

Minor Issues:

just one !

* = Section "3. Document Conventions"

The authors have decided "For = the sake of clarity and completeness" to quote a full section of RFC4475 = into this document. However there were quite long discussions in the = Apps Dir in other reviews if this quoting practice is appropriate or = not, because it can lead to discrepacies, when the quoted document is = updated or obsoleted, resuing in confusion for the readers who just = trust the quoted text without checking the state of the referenced = document. I would suggest, as in the other cases, NOT to quote the = external text, but to use an explicit external reference only, urging = the reader to check that "for the sake of = clarity".

I agree with the position = but in this particular case I'm of the mind that removing that text and = referencing the RFC diminishes the effectiveness of that section. It is = my preference to leave the quoted text (which is very short) embedded in = this document as it is critical to understanding the notation used = throughout the document.

Nits:

* Section "Copyright = Notice"

change the year to = 2012.

Will do this.

* Section "3. Document = Conventions"

remember to change "formatting rules for = Internet-Drafts" into "formatting rules for RFCs" when = published.

Great point. I'll = proactively beat the RFC Editor to this.

* Section "4. Format"

I do understand that = it probably does not fit into the I-D formatting line lenghts, but... = maybe an attempt to add aside the SIP CLF record depicted in Figure 1 = the grouping described as

=             &n= bsp;           &nbs= p;       <IndexPointers>
=             &n= bsp;           &nbs= p;       <MandatoryFields>
=             &n= bsp;           &nbs= p;       <OptionalFields>

= in the figure 1 itself (on the left?) may help in reading the = distinction, and maybe may even not require to repeat portions of the = figure itself later in the I-D, like in figure 3, figure 4 and figure 5. = It is really a nit and just a suggestion. Not really = important.

What I am suggesting:

=       +----------------------------------+      /| =             &n= bsp;           &nbs= p;        |
=     / | =             &n= bsp;           &nbs= p;        |
  P =   | =             &n= bsp;           &nbs= p;        |
  o =   | =             &n= bsp;           &nbs= p;        |
I i =   | =             &n= bsp;           &nbs= p;        |
n n =   | =             &n= bsp;           &nbs= p;        |
d t =   | =             &n= bsp;           &nbs= p;        |
e e =   | =             &n= bsp;           &nbs= p;        |
x r =   | =             &n= bsp;           &nbs= p;        |
  s =   | =             &n= bsp;           &nbs= p;        |
=    \  | =             &n= bsp;           &nbs= p;        |
=      \| =             &n= bsp;           &nbs= p;        |
=       +----------------------------------+      /| =             &n= bsp;           &nbs= p;        |
=     / | =             &n= bsp;           &nbs= p;        |
M =     | =             &n= bsp;           &nbs= p;        |
a F =   | =             &n= bsp;           &nbs= p;        |
n i =   | =             &n= bsp;           &nbs= p;        |
d e =   | =             &n= bsp;           &nbs= p;        |
a l =   | =             &n= bsp;           &nbs= p;        |
t d =   | =             &n= bsp;           &nbs= p;        |
o s =   | =             &n= bsp;           &nbs= p;        |
r =     | =             &n= bsp;           &nbs= p;        |
y  \ =  | =             &n= bsp;           &nbs= p;        |
=      \| =             &n= bsp;           &nbs= p;        |
=       +----------------------------------+      /| =             &n= bsp;           &nbs= p;        |
=     / | =             &n= bsp;           &nbs= p;        |
O =     | =             &n= bsp;           &nbs= p;        |
p F =   | =             &n= bsp;           &nbs= p;        |
t i =   | =             &n= bsp;           &nbs= p;        |
i e =   | =             &n= bsp;           &nbs= p;        |
o l =   | =             &n= bsp;           &nbs= p;        |
n d =   | =             &n= bsp;           &nbs= p;        |
a s =   | =             &n= bsp;           &nbs= p;        |
l =     | =             &n= bsp;           &nbs= p;        |
=    \  | =             &n= bsp;           &nbs= p;        |
=      \| =             &n= bsp;           &nbs= p;        |
=       +----------------------------------+

This is something that we have = discussed and have not found an elegant solution = for. 
While there are maintenance risks it was thought to = be very valuable to display the 
pertinent portion of the = complete CLF within the section where that was = discussed. 
I'll do my best to ensure that they are = all copied over properly from Figure = 1.


* = Section "5. Example SIP CLF Record"

Remember to change "Due to = internet-draft conventions" into "Due to RFC conventions" when published = (and also "to format it for an RFC" later = on...).

Indeed.

* =46rom the DataTracker ID Nits check tool = (References Nits):

 =3D=3D Unused Reference: 'RFC5612' is = defined on line 984, but no explicit
=     reference was found in the text

 ** = Downref: Normative reference to an Informational draft:
=     draft-ietf-sipclf-problem-statement (ref.
=     'I-D.ietf-sipclf-problem-statement')

Commen= t: the document shepard is aware and has a solution for these nits. Just = apply = it.

Absolutely.

<= div>Thanks,

Gonzalo


=

---------------------------------------------------= ---------------------------
Claudio Allocchio =             G =   A   R   R =          Claudio.Allocchio@garr.it =             &n= bsp;          Senior = Technical Officer
tel: +39 040 3758523 =      Italian Academic and =       G=3DClaudio; S=3DAllocchio;
fax: = +39 040 3758565        Research = Network         P=3Dgarr; = A=3Dgarr; C=3Dit;

=           PGP Key: http://www.cert.garr.it/= PGP/keys.php3#ca
_______________________________________________apps-discuss mailing list
apps-discuss@ietf.org
https:/= /www.ietf.org/mailman/listinfo/apps-discuss


= --Apple-Mail-17-401701545-- From Claudio.Allocchio@garr.it Wed Feb 8 23:47:12 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ACEF21F85E6 for ; Wed, 8 Feb 2012 23:47:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id afLddqy-J1Ad for ; Wed, 8 Feb 2012 23:47:11 -0800 (PST) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [IPv6:2001:760:0:158::29]) by ietfa.amsl.com (Postfix) with ESMTP id 44AEF21F85E4 for ; Wed, 8 Feb 2012 23:47:11 -0800 (PST) Received: from mac-allocchio3.elettra.trieste.it (mac-allocchio3.elettra.trieste.it [140.105.2.18]) (authenticated bits=0) by cyrus.dir.garr.it (8.14.5/8.14.5) with ESMTP id q197l5QP095456 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Feb 2012 08:47:05 +0100 (CET) X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 cyrus.dir.garr.it q197l5QP095456 DomainKey-Signature: a=rsa-sha1; s=mail; d=garr.it; c=simple; q=dns; b=Im0x/1Ex6jRfQWoa6a9STAvQoGvGtlbfn2PstJ/hMeGWoOZvlYkxLHRGACUaM4B08 oY1YBUolyawVUgaVD8ktwSDViyyCnZNHnRhyAv7QI7sgSlN3dYuYkGjIVLN2XuYGEDu hZ9rtt/4yikIZXNI3fo1AOnqhPDs2wpHEUuXkfM= Date: Thu, 9 Feb 2012 08:47:05 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.elettra.trieste.it To: Gonzalo Salgueiro In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "sip-clf@ietf.org Mailing" , apps-discuss@ietf.org, Gonzalo Camarillo , draft-ietf-sipclf-format.all@tools.ietf.org Subject: Re: [apps-discuss] AppsDir review of draft-ietf-sipclf-format-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 07:47:12 -0000 Hello all! >> * Section "3. Document Conventions" >> >> The authors have decided "For the sake of clarity and completeness" to >> quote a full section of RFC4475 into this document. However there were >> quite long discussions in the Apps Dir in other reviews if this quoting >> practice is appropriate or not, because it can lead to discrepacies, >> when the quoted document is updated or obsoleted, resuing in confusion >> for the readers who just trust the quoted text without checking the >> state of the referenced document. I would suggest, as in the other >> cases, NOT to quote the external text, but to use an explicit external >> reference only, urging the reader to check that "for the sake of >> clarity". > > I agree with the position but in this particular case I'm of the mind > that removing that text and referencing the RFC diminishes the > effectiveness of that section. It is my preference to leave the quoted > text (which is very short) embedded in this document as it is critical > to understanding the notation used throughout the document. maybe a possible compromise is to quote the text, as is now, but to add a small note which reminds the reader to check the update/obsoletes status of RFC4475? ;-) >> * Section "4. Format" >> > This is something that we have discussed and have not found an elegant > solution for. While there are maintenance risks it was thought to be > very valuable to display the pertinent portion of the complete CLF > within the section where that was discussed. I'll do my best to ensure > that they are all copied over properly from Figure 1. as I said, it is a Nit... thanks for taking some time in thinking about it. have a nice day! ------------------------------------------------------------------------------ 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 gsalguei@cisco.com Thu Feb 9 06:44:16 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92EB821F84E6 for ; Thu, 9 Feb 2012 06:44:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.31 X-Spam-Level: X-Spam-Status: No, score=-10.31 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lmZdkFNCJkR1 for ; Thu, 9 Feb 2012 06:44:15 -0800 (PST) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by ietfa.amsl.com (Postfix) with ESMTP id 87F5121F861D for ; Thu, 9 Feb 2012 06:44:15 -0800 (PST) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q19EiDf2029016 for ; Thu, 9 Feb 2012 09:44:14 -0500 (EST) Received: from rtp-gsalguei-8714.cisco.com (rtp-gsalguei-8714.cisco.com [10.116.61.53]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q19EiCec025302; Thu, 9 Feb 2012 09:44:12 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-20-451617382 From: Gonzalo Salgueiro In-Reply-To: Date: Thu, 9 Feb 2012 09:44:11 -0500 Message-Id: <4FB65F28-DC68-4240-99F9-E99C457968A8@cisco.com> References: To: Claudio Allocchio X-Mailer: Apple Mail (2.1084) Cc: "sip-clf@ietf.org Mailing" , apps-discuss@ietf.org, Gonzalo Camarillo , draft-ietf-sipclf-format.all@tools.ietf.org Subject: Re: [apps-discuss] AppsDir review of draft-ietf-sipclf-format-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 14:44:16 -0000 --Apple-Mail-20-451617382 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Claudio -=20 On Feb 9, 2012, at 2:47 AM, Claudio Allocchio wrote: > Hello all! >=20 >>> * Section "3. Document Conventions" >>>=20 >>> The authors have decided "For the sake of clarity and completeness" = to quote a full section of RFC4475 into this document. However there = were quite long discussions in the Apps Dir in other reviews if this = quoting practice is appropriate or not, because it can lead to = discrepacies, when the quoted document is updated or obsoleted, resuing = in confusion for the readers who just trust the quoted text without = checking the state of the referenced document. I would suggest, as in = the other cases, NOT to quote the external text, but to use an explicit = external reference only, urging the reader to check that "for the sake = of clarity". >>=20 >> I agree with the position but in this particular case I'm of the mind = that removing that text and referencing the RFC diminishes the = effectiveness of that section. It is my preference to leave the quoted = text (which is very short) embedded in this document as it is critical = to understanding the notation used throughout the document. >=20 > maybe a possible compromise is to quote the text, as is now, but to = add a small note which reminds the reader to check the update/obsoletes = status of RFC4475? ;-) I could add that but bear in mind that I only care about the quoted text = dealing with formatting rules from RFC4475 and nothing else. So whether = it gets updated or obsoleted is irrelevant in this case. In fact, if it = gets updated and it affects the formatting guidelines I quoted then I = don't want to reference it at all since it is no longer useful or = significant to this draft. >=20 >>> * Section "4. Format" >>>=20 >> This is something that we have discussed and have not found an = elegant solution for. While there are maintenance risks it was thought = to be very valuable to display the pertinent portion of the complete CLF = within the section where that was discussed. I'll do my best to ensure = that they are all copied over properly from Figure 1. >=20 > as I said, it is a Nit... thanks for taking some time in thinking = about it. Thanks to you for your careful review. Warm Regards, Gonzalo >=20 > have a nice day! >=20 >=20 > = --------------------------------------------------------------------------= ---- > Claudio Allocchio G A R R = Claudio.Allocchio@garr.it > Senior Technical Officer > tel: +39 040 3758523 Italian Academic and G=3DClaudio; = S=3DAllocchio; > fax: +39 040 3758565 Research Network P=3Dgarr; A=3Dgarr;= C=3Dit; >=20 > PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca >=20 --Apple-Mail-20-451617382 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Claudio - 

On Feb 9, 2012, at 2:47 AM, Claudio = Allocchio wrote:

Hello = all!

* = Section "3. Document = Conventions"

The authors have decided "For = the sake of clarity and completeness" to quote a full section of RFC4475 = into this document. However there were quite long discussions in the = Apps Dir in other reviews if this quoting practice is appropriate or = not, because it can lead to discrepacies, when the quoted document is = updated or obsoleted, resuing in confusion for the readers who just = trust the quoted text without checking the state of the referenced = document. I would suggest, as in the other cases, NOT to quote the = external text, but to use an explicit external reference only, urging = the reader to check that "for the sake of = clarity".

I agree with = the position but in this particular case I'm of the mind that removing = that text and referencing the RFC diminishes the effectiveness of that = section. It is my preference to leave the quoted text (which is very = short) embedded in this document as it is critical to understanding the = notation used throughout the document.

maybe a = possible compromise is to quote the text, as is now, but to add a small = note which reminds the reader to check the update/obsoletes status of = RFC4475? ;-)

I could add that but = bear in mind that I only care about the quoted text dealing with = formatting rules from RFC4475 and nothing else. So whether it gets = updated or obsoleted is irrelevant in this case. In fact, if it gets = updated and it affects the formatting guidelines I quoted then I don't = want to reference it at all since it is no longer useful or significant = to this draft.

* Section "4. = Format"

This is something that we have discussed and have not = found an elegant solution for. While there are maintenance risks it was = thought to be very valuable to display the pertinent portion of the = complete CLF within the section where that was discussed. I'll do my = best to ensure that they are all copied over properly from Figure = 1.

as I said, it is a Nit... thanks for taking some = time in thinking about it.

Thanks = to you for your careful review.

Warm = Regards,

Gonzalo


have a nice = day!


----------------------------------------------------------= --------------------
Claudio Allocchio =             G =   A   R   R =          Claudio.Allocchio@garr.it =             &n= bsp;          Senior = Technical Officer
tel: +39 040 3758523 =      Italian Academic and =       G=3DClaudio; S=3DAllocchio;
fax: = +39 040 3758565        Research = Network         P=3Dgarr; = A=3Dgarr; C=3Dit;

=           PGP Key: http://www.cert.garr.it/= PGP/keys.php3#ca


= --Apple-Mail-20-451617382-- From aaron@serendipity.cx Thu Feb 9 08:41:11 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9EDD21F85B5; Thu, 9 Feb 2012 08:41:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.417 X-Spam-Level: X-Spam-Status: No, score=-101.417 tagged_above=-999 required=5 tests=[AWL=0.226, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QsPMepQYw0cq; Thu, 9 Feb 2012 08:41:10 -0800 (PST) Received: from slice.serendipity.cx (slice.serendipity.cx [67.23.2.90]) by ietfa.amsl.com (Postfix) with ESMTP id 312DF21F85A0; Thu, 9 Feb 2012 08:41:10 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by slice.serendipity.cx (Postfix) with ESMTPSA id F3DCC11006C; Thu, 9 Feb 2012 08:38:35 -0800 (PST) Received: by vbbfr13 with SMTP id fr13so1408613vbb.31 for ; Thu, 09 Feb 2012 08:38:45 -0800 (PST) Received: by 10.52.66.166 with SMTP id g6mr1140141vdt.34.1328805525682; Thu, 09 Feb 2012 08:38:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.111.164 with HTTP; Thu, 9 Feb 2012 08:38:25 -0800 (PST) From: Aaron Stone Date: Thu, 9 Feb 2012 11:38:25 -0500 Message-ID: To: apps-discuss@ietf.org, draft-ietf-payload-rtp-klv.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: The IESG Subject: [apps-discuss] APPSDIR review of draft-ietf-payload-rtp-klv-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 16:41:12 -0000 I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-payload-rtp-klv-03 Title: RTP Payload Format for SMPTE 336M Encoded Data Reviewer: Aaron Stone Review Date: Feb 6, 2012 IETF Last Call Date: unknown IESG Telechat Date: 2012-02-16 Summary: This draft is ready for publication on the Standards Track. Major Issues: None. Minor Issues: Introduction: How does the recipient know what the length of a Key is? Reading this document as if I were going to implement the protocol, I could not figure out how my code would figure out the length of the K in KLV. There is a good description of discovering the length of the Length field! Please include a definition of "KLV universal key", as it is used in the introduction and abstract without definition. Is there a key registry maintained somewhere? Presumably the SMPTE maintains this registry, rather than IANA. If so, please reference this registry. Section 6.2: Please expand SDP upon first use. Nits: I wonder if RFC3551 could be an informative, rather than normative, referen= ce. The sections below have several spelling and grammar errors. I have excerpted the sections, and provided [[ notes ]] in double square brackets. 4.2.2. KLVunit Mapping to RTP Packet Payload An RTP packet payload SHALL contain one, and only one, KLVunit or a fragment thereof. KLVunits small enough to fit into a single RTP packet (RTP packet size is up to implementation but should consider underlying transport/network factors such as MTU limitations) are placed directly into the payload of the RTP packet, with the first byte of the KLVunit (which is the first byte of a KLV universal key) being the first byte of the RTP packet payload. KLVunits too large to fit into a single RTP packet payload MAY span multiple RTP packet payloads. When this is done, the KLVunit data MUST be sent in sequential byte order, such that when all RTP packets comprising the KLVunit are arranged in sequence number order, concatenating the payload data together exactly reproduces the original KLVunit. Additionally, when a KLVunit is fragmented across multiple RTP packets, all RTP packets transporting the fragments a KLVunit MUST have the same timestamp. [[ the fragment _of_ a KLVunit ]] KLVunits are bounded with changes in RTP packet timestamps. The marker (M) bit in the RTP packet headers marks the last RTP packet comprising a KLVunit (see Section 4.1). A receiver MUST consider a KLVunit to be completed when it receives either a packet with M=3D1 or a packet with a new timestamp. In the former case, the packet payload is included in the completed KLVunit; in the latter case, it is not. [[ or the size of the KLVunit is satisfied by the contents of the RTP packe= t ]] 6.2. Mapping to SDP The mapping of the above defined payload format media type and its parameters SHALL be done according to Section 3 of [RFC4855]. [[ Please expand the acronym SDP upon first use ]] 8. Security Considerations RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [RFC3550], and in any applicable RTP profile. The main security considerations for the RTP packet carrying the RTP payload format defined within this memo are confidentiality, integrity and source authenticity. Confidentiality is achieved by encryption of the RTP payload. Integrity of the RTP packets through suitable cryptographic integrity protection mechanism. Cryptographic system [[ grammatical error. systems? ]] may also allow the authentication of the source of the payload. A suitable security mechanism for this RTP payload format should provide confidentiality, integrity protection and at least source authentication capable of determining if an RTP packet is from a member of the RTP session or not. Note that the appropriate mechanism to provide security to RTP and payloads following this memo may vary. It is dependent on the application, the transport, and the signalling protocol employed. [[ spelling: signaling ]] Therefore a single mechanism is not sufficient, although if suitable [[ Why is a single mechanism not sufficient? Why is SRTP recommended? Suggest breaking up this sentence better explain. ]] the usage of SRTP [RFC3711] is recommended. Other mechanism that may [[ mechanisms ]] be used are IPsec [RFC4301] and TLS [RFC5246] (RTP over TCP), but [[ buzzword spelling: IPSec ]] also other alternatives may exist. This RTP payload format presents the possibility for significant non- uniformity in the receiver-side computational complexity during processing of SMPTE 336M payload data. Because the length of SMPTE 336M encoded data items is essentially unbounded, receivers must take care when allocating resources used in processing. It is trivial to construct pathological data that would cause a naive decoder to allocate large amounts of resources, resulting in denial-of-service threats. Receivers SHOULD place limits on resource allocation that are within the bounds set forth by any application profile in use. This RTP payload format does not contain any inheritly active [[ spelling: inherently ]] content. However, individual SMPTE 336M KLV items could be defined to convey active content in a particular application. Therefore, receivers capable of decoding and interpreting such data items should use appropriate caution and security practices. In particular, accepting active content from streams that lack authenticity or Downs & Arbeiter Expires August 4, 2012 [Page 10] =0C Internet-Draft RTP Format for SMPTE 336M Data February 2012 integrity proteciton mechanisms places a receiver at risk to attacks [[ spelling: protection. grammar: places a receiver at right of attack by spoofed packets. ]] using spoofed packets. Receivers not capable of decoding such data items are not at risk; unknown data items are skipped over and discarded according to SMPTE 336M processing rules. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003. [[ could be informational; the reference in Section 5 may be non-normative.= ]] [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005. [RFC4855] Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, February 2007. [SMPTE336M] Society of Motion Picture and Television Engineers, "SMPTE336M-2007: Data Encoding Protocol Using Key-Length- Value", 2007, . [[ the full spec document appears to include the year? should it be "SMPTE-336M-2007" ? ]] END OF REVIEW From paduffy@cisco.com Thu Feb 9 11:54:29 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7153221F8752 for ; Thu, 9 Feb 2012 11:54:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30Y4gCmSpjEc for ; Thu, 9 Feb 2012 11:54:11 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id A10FC21E804C for ; Thu, 9 Feb 2012 11:54:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paduffy@cisco.com; l=1111; q=dns/txt; s=iport; t=1328817250; x=1330026850; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=ybdJGSAoyqyRHX0DV18QRKF4fNRo/R8JR/lgnF2qnBI=; b=ULxbeGKtLvDq+gdpBKbpFkaLl1xUwSTZfnkH698jTDnpOut4sHBGCp4t +FxNF4+ltpFBLJqWoWVmIBHvLEL9oSI3Ag0zhVIG02pJIMkvoKUWgHBDp TAcscHMGmO+9Gwzv5+qqFdOwyKoGshw9jwlx40VE1MCv/G3NRSNJLDUe3 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmAHAEUjNE+rRDoJ/2dsb2JhbABEgw2CAqpNgQeBcgEBAQQSAQIBDRU6BgEQCxgCAgUWCwICCQMCAQIBRQYNAQUCAQEeohABgzEPAYkkki6BL4onAwgFFgUDDgkBBwEFBAMECwIHBQYBAwIUAQQOBoNgEQEBAQEBgnCBFgSISIxohVqNKQ X-IronPort-AV: E=Sophos;i="4.73,391,1325462400"; d="scan'208";a="29567568" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 09 Feb 2012 19:54:10 +0000 Received: from [10.21.122.242] (sjc-vpn6-754.cisco.com [10.21.122.242]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q19JsA5V015825; Thu, 9 Feb 2012 19:54:10 GMT Message-ID: <4F342460.7020402@cisco.com> Date: Thu, 09 Feb 2012 11:54:08 -0800 From: Paul Duffy Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Peter Saint-Andre References: <4EC31F1E.6070304@stpeter.im> <8p86c7d6chvadsku6k5dhct20qkl7uk73l@hive.bjoern.hoehrmann.de> <4EC326FE.1010809@stpeter.im> <4EE78F2F.2070601@stpeter.im> <20111213215816.GI5525@jay.w3.org> <5EFF390A-3D29-4F15-95BE-C81EFCF6D3D5@mnot.net> <20111214092327.GK5525@jay.w3.org> <7472087B-86F9-4683-BA74-F70EC98D483C@sensinode.com> <20111217104103.GP5525@jay.w3.org> <3AC08E67-21D3-471D-8CE8-45B9FAB8A74F@sensinode.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 09 Feb 2012 18:53:24 -0800 Cc: "apps-discuss@ietf.org" , Mark Nottingham , Thomas Herbst Subject: Re: [apps-discuss] +exi X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: paduffy@cisco.com List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 19:54:29 -0000 We are closing this SEP2 issue in the next few days. Consensus seems to be (?): Content_Type: application/sep+xml ... or ... Content_Type: application/sep+exi The first indicating POX-to-native objects processing only, the second indicating EXI-to-native processing (no intermediate XML ... its not a compression). May be further extended to support variants of EXI processing. Going once, going twice, .... We need to get this registered with IANA, etc. Thanks On 12/17/2011 7:11 PM, Martin Thomson wrote: > On 18 December 2011 06:34, Zach Shelby wrote: >> I don't find the SchemaId all that useful. First of all, you need to invoke your EXI parser to even get at that. It is more useful to immediately look at the content-type to decide which parser to throw a representation at. A strictly defined foo+exi registration would tell you that nicely. > ISTM that a link relation type for schema would make some sort of > difference. The JSON schema draft had a "describedby" relation type > that might fit the bill (though "schema" is shorter). > From psaintan@cisco.com Thu Feb 9 18:52:23 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3C1A21F8474 for ; Thu, 9 Feb 2012 18:52:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-7xjaIe7LWw for ; Thu, 9 Feb 2012 18:52:22 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 968B021F8598 for ; Thu, 9 Feb 2012 18:52:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=psaintan@cisco.com; l=1473; q=dns/txt; s=iport; t=1328842329; x=1330051929; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=jbogm/asBQODu62IJ6lAmMLN2o7F8Q32BVJOTloRajk=; b=GS5aNaoO8Ofizfy6dwAbgq0zZTO/CD87qIv+9GgXwh+yr8wjw9IgdI6p RNVkHOiQsh6QLMmNRIC57H+qkYM7y0naIRhGatMCVwWJOAQ5ZlTfwEpVD 3AvPaHCPopYOC/9EXY7QUrn4DiGqoQeor3YvDSB5Ha+287pVULpYyzA1/ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAD2FNE+tJV2Y/2dsb2JhbABDr1+BB4FyAQEBAwESAScCATUHBQ0BCAkPgQUBAQQOBQkZh1oJmgMBnw+LMQgFFgUFBwUJAQcBNQsEEA6EMwEFJoMdBIhIhRuHTJMC X-IronPort-AV: E=Sophos;i="4.73,394,1325462400"; d="scan'208";a="57785297" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP; 10 Feb 2012 02:52:08 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q1A2q8Rx013145; Fri, 10 Feb 2012 02:52:08 GMT Received: from xmb-rcd-310.cisco.com ([72.163.63.25]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 9 Feb 2012 20:52:08 -0600 Received: from 10.89.14.167 ([10.89.14.167]) by XMB-RCD-310.cisco.com ([72.163.63.25]) via Exchange Front-End Server email.cisco.com ([128.107.191.32]) with Microsoft Exchange Server HTTP-DAV ; Fri, 10 Feb 2012 02:52:08 +0000 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Thu, 09 Feb 2012 19:52:05 -0700 From: psaintan To: Message-ID: Thread-Topic: [apps-discuss] +exi Thread-Index: AcznnvivizwwE7CwFU2psIu1GoJBiA== In-Reply-To: <4F342460.7020402@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 10 Feb 2012 02:52:08.0559 (UTC) FILETIME=[FACE87F0:01CCE79E] X-Mailman-Approved-At: Thu, 09 Feb 2012 18:53:24 -0800 Cc: "apps-discuss@ietf.org" , Mark Nottingham , Thomas Herbst Subject: Re: [apps-discuss] +exi X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 02:52:23 -0000 As I recall, Zach Shelby was going to write a short draft about the registration requirements for +exi... http://www.ietf.org/mail-archive/web/apps-discuss/current/msg03981.html I haven't seen that pop out yet. Peter On 2/9/12 12:54 PM, "Paul Duffy" wrote: > We are closing this SEP2 issue in the next few days. > > Consensus seems to be (?): > > Content_Type: application/sep+xml > > ... or ... > > Content_Type: application/sep+exi > > The first indicating POX-to-native objects processing only, the second > indicating EXI-to-native processing (no intermediate XML ... its not a > compression). May be further extended to support variants of EXI > processing. > > Going once, going twice, .... > > We need to get this registered with IANA, etc. > > Thanks > > > On 12/17/2011 7:11 PM, Martin Thomson wrote: >> On 18 December 2011 06:34, Zach Shelby wrote: >>> I don't find the SchemaId all that useful. First of all, you need to invoke >>> your EXI parser to even get at that. It is more useful to immediately look >>> at the content-type to decide which parser to throw a representation at. A >>> strictly defined foo+exi registration would tell you that nicely. >> ISTM that a link relation type for schema would make some sort of >> difference. The JSON schema draft had a "describedby" relation type >> that might fit the bill (though "schema" is shorter). >> > From zach@sensinode.com Fri Feb 10 04:28:44 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 228A121F84FE for ; Fri, 10 Feb 2012 04:28:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.418 X-Spam-Level: X-Spam-Status: No, score=-3.418 tagged_above=-999 required=5 tests=[AWL=-0.419, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nGBi30R87I+Z for ; Fri, 10 Feb 2012 04:28:42 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 0624721F84FD for ; Fri, 10 Feb 2012 04:28:41 -0800 (PST) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q1ACSXW1030479 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 10 Feb 2012 14:28:34 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: Date: Fri, 10 Feb 2012 14:28:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <86F0E68C-8D18-4F9A-86C5-0CC93D406238@sensinode.com> References: To: psaintan X-Mailer: Apple Mail (2.1084) Cc: "apps-discuss@ietf.org" , paduffy@cisco.com, Mark Nottingham , Thomas Herbst Subject: Re: [apps-discuss] +exi X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 12:28:44 -0000 Hi, That's right, slipped my todo list. Pointers to fairly similar documents = appreciated as a template, first time writing this kind of draft. Paul, let's keep in touch directly regarding this.=20 Zach=20 On Feb 10, 2012, at 4:52 AM, psaintan wrote: > As I recall, Zach Shelby was going to write a short draft about the > registration requirements for +exi... >=20 > = http://www.ietf.org/mail-archive/web/apps-discuss/current/msg03981.html >=20 > I haven't seen that pop out yet. >=20 > Peter >=20 > On 2/9/12 12:54 PM, "Paul Duffy" wrote: >=20 >> We are closing this SEP2 issue in the next few days. >>=20 >> Consensus seems to be (?): >>=20 >> Content_Type: application/sep+xml >>=20 >> ... or ... >>=20 >> Content_Type: application/sep+exi >>=20 >> The first indicating POX-to-native objects processing only, the = second >> indicating EXI-to-native processing (no intermediate XML ... its not = a >> compression). May be further extended to support variants of EXI >> processing. >>=20 >> Going once, going twice, .... >>=20 >> We need to get this registered with IANA, etc. >>=20 >> Thanks >>=20 >>=20 >> On 12/17/2011 7:11 PM, Martin Thomson wrote: >>> On 18 December 2011 06:34, Zach Shelby wrote: >>>> I don't find the SchemaId all that useful. First of all, you need = to invoke >>>> your EXI parser to even get at that. It is more useful to = immediately look >>>> at the content-type to decide which parser to throw a = representation at. A >>>> strictly defined foo+exi registration would tell you that nicely. >>> ISTM that a link relation type for schema would make some sort of >>> difference. The JSON schema draft had a "describedby" relation type >>> that might fit the bill (though "schema" is shorter). >>>=20 >>=20 >=20 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From paduffy@cisco.com Fri Feb 10 10:54:18 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35A2021F8813 for ; Fri, 10 Feb 2012 10:54:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fFPZ5FRWsJFQ for ; Fri, 10 Feb 2012 10:54:14 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 8921221F8812 for ; Fri, 10 Feb 2012 10:54:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paduffy@cisco.com; l=2108; q=dns/txt; s=iport; t=1328900052; x=1330109652; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Rtu3Jc628SbyBpPVJZrRFlrdkMmpmcJZ9a0BZh7gn6U=; b=PW5xLNVrov90uOPzS/LipG27GJWUBxP9YkzKBRA02OgeHiKFQBZ4vQPf nn+gVERDR5nCh8b6CASuaKXgdqocyyl9YwYEB8hJu8CMXMaHpj0ht7XNS ROoYDLTXP/EUtivQVXZKNSpjth40B8ssr4Vc5tCcjfPKWp0NVDtymcMQ/ w=; X-IronPort-AV: E=Sophos;i="4.73,397,1325462400"; d="scan'208";a="65885425" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 10 Feb 2012 18:54:11 +0000 Received: from [10.61.82.74] (ams3-vpn-dhcp4683.cisco.com [10.61.82.74]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q1AIqxAL000782; Fri, 10 Feb 2012 18:53:00 GMT Message-ID: <4F356773.1060306@cisco.com> Date: Fri, 10 Feb 2012 10:52:35 -0800 From: Paul Duffy Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Zach Shelby References: <86F0E68C-8D18-4F9A-86C5-0CC93D406238@sensinode.com> In-Reply-To: <86F0E68C-8D18-4F9A-86C5-0CC93D406238@sensinode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 10 Feb 2012 11:16:34 -0800 Cc: "apps-discuss@ietf.org" , psaintan , Mark Nottingham , Thomas Herbst Subject: Re: [apps-discuss] +exi X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: paduffy@cisco.com List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 18:54:18 -0000 I can review. I took the AI from Zigbee Alliance I'm going to propose SEP2 adopt what I outlined below until/if directed otherwise. We have an ongoing interop schedule for which we must meet spec content deadlines. Cheers On 2/10/2012 4:28 AM, Zach Shelby wrote: > Hi, > > That's right, slipped my todo list. Pointers to fairly similar documents appreciated as a template, first time writing this kind of draft. > > Paul, let's keep in touch directly regarding this. > > Zach > > On Feb 10, 2012, at 4:52 AM, psaintan wrote: > >> As I recall, Zach Shelby was going to write a short draft about the >> registration requirements for +exi... >> >> http://www.ietf.org/mail-archive/web/apps-discuss/current/msg03981.html >> >> I haven't seen that pop out yet. >> >> Peter >> >> On 2/9/12 12:54 PM, "Paul Duffy" wrote: >> >>> We are closing this SEP2 issue in the next few days. >>> >>> Consensus seems to be (?): >>> >>> Content_Type: application/sep+xml >>> >>> ... or ... >>> >>> Content_Type: application/sep+exi >>> >>> The first indicating POX-to-native objects processing only, the second >>> indicating EXI-to-native processing (no intermediate XML ... its not a >>> compression). May be further extended to support variants of EXI >>> processing. >>> >>> Going once, going twice, .... >>> >>> We need to get this registered with IANA, etc. >>> >>> Thanks >>> >>> >>> On 12/17/2011 7:11 PM, Martin Thomson wrote: >>>> On 18 December 2011 06:34, Zach Shelby wrote: >>>>> I don't find the SchemaId all that useful. First of all, you need to invoke >>>>> your EXI parser to even get at that. It is more useful to immediately look >>>>> at the content-type to decide which parser to throw a representation at. A >>>>> strictly defined foo+exi registration would tell you that nicely. >>>> ISTM that a link relation type for schema would make some sort of >>>> difference. The JSON schema draft had a "describedby" relation type >>>> that might fit the bill (though "schema" is shorter). >>>> From stpeter@stpeter.im Fri Feb 10 12:08:08 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58E1821F888A for ; Fri, 10 Feb 2012 12:08:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1brDtiC3l7T for ; Fri, 10 Feb 2012 12:08:07 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 82FCD21F8887 for ; Fri, 10 Feb 2012 12:08:07 -0800 (PST) Received: from squire.local (unknown [64.101.72.114]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 84FF840058; Fri, 10 Feb 2012 13:18:43 -0700 (MST) Message-ID: <4F357924.2070705@stpeter.im> Date: Fri, 10 Feb 2012 13:08:04 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Zach Shelby References: <86F0E68C-8D18-4F9A-86C5-0CC93D406238@sensinode.com> In-Reply-To: <86F0E68C-8D18-4F9A-86C5-0CC93D406238@sensinode.com> X-Enigmail-Version: 1.3.5 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: paduffy@cisco.com, Mark Nottingham , Thomas Herbst , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] +exi X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 20:08:08 -0000 On 2/10/12 5:28 AM, Zach Shelby wrote: > Hi, > > That's right, slipped my todo list. Pointers to fairly similar documents appreciated as a template, first time writing this kind of draft. Section 7 of RFC 3023 (XML media type) might be helpful: http://tools.ietf.org/html/rfc3023#section-7 I was hoping that RFC 4627 has something similar for JSON, but I don't see it there. Peter -- Peter Saint-Andre https://stpeter.im/ From derhoermi@gmx.net Fri Feb 10 12:20:39 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C781B21E801A for ; Fri, 10 Feb 2012 12:20:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.861 X-Spam-Level: X-Spam-Status: No, score=-4.861 tagged_above=-999 required=5 tests=[AWL=-2.262, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XipVwcEzl6tt for ; Fri, 10 Feb 2012 12:20:38 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 5206721F88B8 for ; Fri, 10 Feb 2012 12:20:38 -0800 (PST) Received: (qmail invoked by alias); 10 Feb 2012 20:20:36 -0000 Received: from dslb-094-222-139-046.pools.arcor-ip.net (EHLO HIVE) [94.222.139.46] by mail.gmx.net (mp024) with SMTP; 10 Feb 2012 21:20:36 +0100 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1+3YMgQA5K3hA3owlNdzNDJ8laRvOLOh1zUNa6BTX k2q2mCMtPp06jz From: Bjoern Hoehrmann To: Peter Saint-Andre Date: Fri, 10 Feb 2012 21:20:37 +0100 Message-ID: References: <86F0E68C-8D18-4F9A-86C5-0CC93D406238@sensinode.com> <4F357924.2070705@stpeter.im> In-Reply-To: <4F357924.2070705@stpeter.im> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: paduffy@cisco.com, Mark Nottingham , "apps-discuss@ietf.org" , Thomas Herbst Subject: Re: [apps-discuss] +exi X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 20:20:39 -0000 * Peter Saint-Andre wrote: >Section 7 of RFC 3023 (XML media type) might be helpful: > >http://tools.ietf.org/html/rfc3023#section-7 > >I was hoping that RFC 4627 has something similar for JSON, but I don't >see it there. Last I heard the idea was that draft-ietf-appsawg-media-type-regs would formalize the `+example` convention, but someone would have to write the registration for `+json` separately. That has not happened yet as far as I am aware. I argued that draft-ietf-appsawg-media-type-regs should re- gister already established conventions like `+json`, but apparently I was unsuccessful. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From ht@inf.ed.ac.uk Fri Feb 10 12:22:51 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5491E21F8828 for ; Fri, 10 Feb 2012 12:22:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wcisvWUuVaf8 for ; Fri, 10 Feb 2012 12:22:48 -0800 (PST) Received: from nougat.ucs.ed.ac.uk (nougat.ucs.ed.ac.uk [129.215.13.205]) by ietfa.amsl.com (Postfix) with ESMTP id 5174021F8827 for ; Fri, 10 Feb 2012 12:22:48 -0800 (PST) Received: from nutty.inf.ed.ac.uk (nutty.inf.ed.ac.uk [129.215.33.33]) by nougat.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id q1AKMiOf022342; Fri, 10 Feb 2012 20:22:44 GMT Received: from calexico.inf.ed.ac.uk (calexico.inf.ed.ac.uk [129.215.24.15]) by nutty.inf.ed.ac.uk (8.13.8/8.13.8) with ESMTP id q1AKMife031018; Fri, 10 Feb 2012 20:22:44 GMT Received: from calexico.inf.ed.ac.uk (localhost [127.0.0.1]) by calexico.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id q1AKMi4u024671; Fri, 10 Feb 2012 20:22:44 GMT Received: (from ht@localhost) by calexico.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id q1AKMgDC024666; Fri, 10 Feb 2012 20:22:42 GMT X-Authentication-Warning: calexico.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Peter Saint-Andre References: <86F0E68C-8D18-4F9A-86C5-0CC93D406238@sensinode.com> <4F357924.2070705@stpeter.im> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Fri, 10 Feb 2012 20:22:42 +0000 In-Reply-To: <4F357924.2070705@stpeter.im> (Peter Saint-Andre's message of "Fri, 10 Feb 2012 13:08:04 -0700") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.4.21 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at nougat.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.13.205 Cc: paduffy@cisco.com, Mark Nottingham , "apps-discuss@ietf.org" , Thomas Herbst Subject: Re: [apps-discuss] +exi X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 20:22:51 -0000 Peter Saint-Andre writes: > On 2/10/12 5:28 AM, Zach Shelby wrote: >> Hi, >> >> That's right, slipped my todo list. Pointers to fairly similar documents appreciated as a template, first time writing this kind of draft. > > Section 7 of RFC 3023 (XML media type) might be helpful: > > http://tools.ietf.org/html/rfc3023#section-7 Or perhaps http://www.w3.org/2006/02/son-of-3023/draft-murata-kohn-lilley-xml-04.html#naming which is slightly more up-to-date wrt +xml ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From vkg@bell-labs.com Fri Feb 10 13:53:44 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6214821F854B for ; Fri, 10 Feb 2012 13:53:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.871 X-Spam-Level: X-Spam-Status: No, score=-108.871 tagged_above=-999 required=5 tests=[AWL=1.728, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cn-YbsxAGCX6 for ; Fri, 10 Feb 2012 13:53:43 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 4868321F8542 for ; Fri, 10 Feb 2012 13:53:43 -0800 (PST) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q1ALrfke027373 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 10 Feb 2012 15:53:41 -0600 (CST) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q1ALrfgD015111 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 10 Feb 2012 15:53:41 -0600 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.235]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q1ALreJD004412; Fri, 10 Feb 2012 15:53:40 -0600 (CST) Message-ID: <4F3592E5.3080707@bell-labs.com> Date: Fri, 10 Feb 2012 15:57:57 -0600 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: "apps-discuss@ietf.org" , draft-ietf-pcp-base@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: [apps-discuss] APPSDIR rdraft-ietf-pcp-base-22 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 21:53:44 -0000 Document: draft-ietf-pcp-base-22 Title: Port Control Protocol (PCP) Reviewer: Vijay K. Gurbani Review Date: Feb-10-2012 IETF Last Call Date: Not known IESG Telechat Date: Not known Summary: This draft is almost ready for publication as a Proposed Standard but has a few issues that should be fixed before publication. Major issues: 0 Minor issues: 11 Major issues: 0 Issues listed below are in document order. - S5, the all zeroes IPv4 address as defined by the draft is a contribution of the draft itself, right? That is, at least I am not aware whether ::ffff:0:0 is generally used as the all-zero IPv4-mapped IPv6 address. It may well be, in which case this comment can be ignored. But if it is not a general use address and is intended to be defined by this draft, I wonder if rfc2119 MUST is appropriate here (as in "The all-zeroes IPv4 address MUST be expressed as: 80 bits of zeros, 16 bits of ones, and 32 bits of zeros (::ffff:0:0)."). - S6.1, the "Opcode-specific information" block of Figure 2 is not discussed at all in the text following Figure 2. - S6.1, the "PCP Options" block of Figure 2 is not discussed at all in the text following Figure 2. You do provide a Section 6.3 that discusses options; perhaps it is sufficient to say the following at the end of the text following Figure 2: "PCP Options: Please see Section 6.3". - Ditto for S6.2 and Figure 3's use of "Opcode-specific response data" and "Options" block. - S7.1, second-to-last paragraph: I suspect that if more than one server was specified in the server list, the client will cycle through and try the next server. I also note that this document only considers one server, so exact guidance is not provided on what to do when a PCP client has more than one server. But I think it possible that the default router list (mentioned earlier in the section) creates a list of two servers: an IPv4- and IPv6-server. Would it be prudent to try the IPv6 server if the IPv4 server --- and vice-versa --- did not result in any response within the maximum retransmission interval of 15m? - S7.3, the third paragraph from the end of the section ("For both ... is RECOMMENDED."): Here you say that "A limit of 24 hours for success responses and 30 minutes for error responses is RECOMMENDED." However, in S6.4 you said that, "It is RECOMMENDED that short lifetime errors use a 30 second lifetime and long lifetime errors use a 30 minute lifetime." So --- is S7.3 treating *all* error responses as long lifetime errors? - S9.1: The algorithm provided is excellent, but can only be used when writing new servers (since it requires sending and receiving PCP messages). This should be made clear before the algorithm. (I believe that this stands to reason, but being explicit does not hurt.) Existing servers that need to be reachable from the outside, but ones whose source code cannot be modified, will need to arrange for an explicit static mapping to happen before they are started. - I believe that the above issue is true for S9.{2,3} as well. - S16.1.1: I am not sure how to interpret the listed attacks in this section. Is it the case that these attacks can happen even if PCP servers comply with the Simple Threat Model? Or is it the case that the Simple Threat Model mitigates these attacks? - S16.2: To protect against Advanced Threat Model attacks, the draft assumes a PCP security mechanism that provides channel authentication and encryption. However, no further information is provided for such a mechanism. Will it help to provide any candidates for such a mechanism (TLS? S/MIME?) or is there something entirely different in mind? - S16.3.1: As far as I can see, there is no mitigation for Denial of Service attack mounted by an attacker on the path between the PCP client and PCP server, yes? If so, it will be nice to explicitly state this. Nit: - S3, while discussing Internal Host: The term "PCP MAP" request is used here without further context, like a short definition. Clearly, the PCP MAP request arranges for a mapping to occur in the NAT ... the reader can tell that much. But all the same, for the sake of completeness, it will be good to provide a quick definition when the term is first used. - S3, while discussing Explicit static mappings: any reason why a GUI (distinct from a web-based UI) is omitted? I suspect the answer is just plain oversight, but just the same, I think it will not hurt to include it in, or simply take out the text in the brackets. - S16.2: s/mechanism which provides/mechanism that provides That's it. Thanks! - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From ned.freed@mrochek.com Fri Feb 10 14:02:38 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7647421F84F4 for ; Fri, 10 Feb 2012 14:02:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IlfSE3nTZ2F0 for ; Fri, 10 Feb 2012 14:02:35 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD1E21F84EE for ; Fri, 10 Feb 2012 14:02:29 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OBTT905EAO003XVD@mauve.mrochek.com> for apps-discuss@ietf.org; Fri, 10 Feb 2012 14:02:21 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OBR11Q7E9S00ZUIL@mauve.mrochek.com>; Fri, 10 Feb 2012 14:02:16 -0800 (PST) Message-id: <01OBTT8X03QS00ZUIL@mauve.mrochek.com> Date: Fri, 10 Feb 2012 14:01:19 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Fri, 10 Feb 2012 21:20:37 +0100" MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=iso-8859-1 References: <86F0E68C-8D18-4F9A-86C5-0CC93D406238@sensinode.com> <4F357924.2070705@stpeter.im> To: Bjoern Hoehrmann Cc: paduffy@cisco.com, Mark Nottingham , Thomas Herbst , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] +exi X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 22:02:38 -0000 > * Peter Saint-Andre wrote: > >Section 7 of RFC 3023 (XML media type) might be helpful: > > > >http://tools.ietf.org/html/rfc3023#section-7 > > > >I was hoping that RFC 4627 has something similar for JSON, but I don't > >see it there. > Last I heard the idea was that draft-ietf-appsawg-media-type-regs would > formalize the `+example` convention, but someone would have to write the > registration for `+json` separately. That has not happened yet as far as > I am aware. I argued that draft-ietf-appsawg-media-type-regs should re- > gister already established conventions like `+json`, but apparently I > was unsuccessful. Read the draft again, in particular the IANA considerations. That's exactly what it does do. Ned From derhoermi@gmx.net Sun Feb 12 11:59:48 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF65621F8636 for ; Sun, 12 Feb 2012 11:59:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.017 X-Spam-Level: X-Spam-Status: No, score=-3.017 tagged_above=-999 required=5 tests=[AWL=-2.277, BAYES_20=-0.74] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nGhBCbLyVNPg for ; Sun, 12 Feb 2012 11:59:46 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 6666521F8617 for ; Sun, 12 Feb 2012 11:59:46 -0800 (PST) Received: (qmail invoked by alias); 12 Feb 2012 19:59:42 -0000 Received: from dslb-094-223-155-246.pools.arcor-ip.net (EHLO HIVE) [94.223.155.246] by mail.gmx.net (mp034) with SMTP; 12 Feb 2012 20:59:42 +0100 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX19e6RoHZXJepfHHgPkxc7vmLzVEjDIFjHlUmkXopf /t+7i/DSayJ0bk From: Bjoern Hoehrmann To: Ned Freed Date: Sun, 12 Feb 2012 20:59:45 +0100 Message-ID: References: <86F0E68C-8D18-4F9A-86C5-0CC93D406238@sensinode.com> <4F357924.2070705@stpeter.im> <01OBTT8X03QS00ZUIL@mauve.mrochek.com> In-Reply-To: <01OBTT8X03QS00ZUIL@mauve.mrochek.com> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: paduffy@cisco.com, Mark Nottingham , Thomas Herbst , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] +exi X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2012 19:59:48 -0000 * Ned Freed wrote: >> Last I heard the idea was that draft-ietf-appsawg-media-type-regs would >> formalize the `+example` convention, but someone would have to write the >> registration for `+json` separately. That has not happened yet as far as >> I am aware. I argued that draft-ietf-appsawg-media-type-regs should re- >> gister already established conventions like `+json`, but apparently I >> was unsuccessful. > >Read the draft again, in particular the IANA considerations. That's exactly >what it does do. I take it you mean o The initial content of the registry shall be constructed at the time of the registry's creation by the designated media types reviewer(s) by examining the current media types registry and extracting all conforming uses of "+suffix" names. I would have expected the draft to have the actual registration forms for the suffixes in question, but okay. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From ned.freed@mrochek.com Sun Feb 12 12:28:23 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 590A121F8683 for ; Sun, 12 Feb 2012 12:28:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vAwrMsdvhhhX for ; Sun, 12 Feb 2012 12:28:22 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id D3C0C21F8610 for ; Sun, 12 Feb 2012 12:28:22 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OBWIJZXN3K00KYHY@mauve.mrochek.com> for apps-discuss@ietf.org; Sun, 12 Feb 2012 12:28:15 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OBR11Q7E9S00ZUIL@mauve.mrochek.com>; Sun, 12 Feb 2012 12:28:09 -0800 (PST) Message-id: <01OBWIJWLZRM00ZUIL@mauve.mrochek.com> Date: Sun, 12 Feb 2012 12:21:39 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Sun, 12 Feb 2012 20:59:45 +0100" MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=ISO-8859-1 References: <86F0E68C-8D18-4F9A-86C5-0CC93D406238@sensinode.com> <4F357924.2070705@stpeter.im> <01OBTT8X03QS00ZUIL@mauve.mrochek.com> To: Bjoern Hoehrmann Cc: paduffy@cisco.com, Mark Nottingham , Thomas Herbst , Ned Freed , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] +exi X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2012 20:28:23 -0000 > * Ned Freed wrote: > >> Last I heard the idea was that draft-ietf-appsawg-media-type-regs would > >> formalize the `+example` convention, but someone would have to write the > >> registration for `+json` separately. That has not happened yet as far as > >> I am aware. I argued that draft-ietf-appsawg-media-type-regs should re- > >> gister already established conventions like `+json`, but apparently I > >> was unsuccessful. > > > >Read the draft again, in particular the IANA considerations. That's exactly > >what it does do. > I take it you mean > o The initial content of the registry shall be constructed at the > time of the registry's creation by the designated media types > reviewer(s) by examining the current media types registry and > extracting all conforming uses of "+suffix" names. > I would have expected the draft to have the actual registration forms > for the suffixes in question, but okay. Material for one time use like this turns into useless clutter the minute the registrations are done. In fact it's worse than useless clutter - a careless reader might infer that the registrations in a registration document like this are the list of available suffixes. Additionally, I don't see any point in duplicating existing registry content anywhere else and then having to continually check to see if any new prefixes have shown up in the registry. So I'm also opposed to having a separate document to do this. That's why I came up with the idea of having the reviewers create the initial suffix registry content from the existing media types registry. Again, the lighter the processes we define, the better. Ned From stpeter@stpeter.im Mon Feb 13 14:45:38 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EC6221F864B for ; Mon, 13 Feb 2012 14:45:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.235 X-Spam-Level: X-Spam-Status: No, score=-102.235 tagged_above=-999 required=5 tests=[AWL=-0.236, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EfZ++5JCD8I7 for ; Mon, 13 Feb 2012 14:45:37 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 2AEA621F8646 for ; Mon, 13 Feb 2012 14:45:37 -0800 (PST) Received: from squire.local (unknown [64.101.72.114]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5BB2C4005B; Mon, 13 Feb 2012 15:56:23 -0700 (MST) Message-ID: <4F39928F.5000300@stpeter.im> Date: Mon, 13 Feb 2012 15:45:35 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: "t.petch" References: <4EE2430E.4080501@isode.com> <4F1F1A72.1090302@isode.com><6068EE9E-D120-4CE9-8096-C296C169C7DE@vpnc.org><4F22EE3A.9010801@stpeter.im> <4F22EF8B.9000509@dcrocker.net><4F22EFCF.3050607@stpeter.im> <4F22F08D.4060902@stpeter.im> <4F22FF9F.5040304@dcrocker.net> <009101cce0c0$23d36160$4001a8c0@gateway.2wire.net> In-Reply-To: <009101cce0c0$23d36160$4001a8c0@gateway.2wire.net> X-Enigmail-Version: 1.3.5 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: dcrocker@bbiw.net, apps-discuss , Paul Hoffman Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-xdash-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 22:45:38 -0000 On 2/1/12 2:01 AM, t.petch wrote: > ----- Original Message ----- > From: "Dave CROCKER" > To: "Peter Saint-Andre" > Cc: "Paul Hoffman" ; > Sent: Friday, January 27, 2012 8:48 PM >> On 1/27/2012 10:44 AM, Peter Saint-Andre wrote: >>>> The specification only cover parameter names, not numbers. >>>> Brevity is good. >> Usually. > > As long as it is right. My number parameters have text names; my textual > parameters have text names. I think that 'the specification only cover textual > parameter, not numeric one'. > > Aliter, > 'Note that this document only discusses parameters expressed in text; it does > not discuss parameters that are expressed with numbers.' > modifying Paul's original proposal slightly. > > Arguably, the first sentence of the Introduction has the same problem with its > reference to 'named parameters' as opposed to 'parameters expressed in text'. > > But like Paul, I think that that is worth explicitly stating in this I-D, > because when I get to Appendix B, it says > ' [BCP82] is entitled "Assigning Experimental and Testing Numbers > Considered Useful" and therefore implies that the "X-" prefix is > also useful for experimental parameters. ' > Well, if this is about textual parameters, then BCP82 is irrelevant, its > title clearly states its scope and reading and re-reading it, I see nothing in > it > about text or characters, every reference is to number(s) and so I see > nothing that has implications for X-. Reading Appendix B might well muddy the > waters as to the scope of this I-D which is why I would like that sentence > above added. In our working copy I have: "Note that this document covers only parameters with textual names, not parameters that are expressed as numbers." I've also clarified the matter a bit in the abstract and the introduction: "[T]his document deprecates the "X-" convention for textual parameters in application protocols." "Many application protocols use parameters with textual names to identify data..." Etc. Shall I submit -03 so that the text is easier to track? Peter -- Peter Saint-Andre https://stpeter.im/ From dhc@dcrocker.net Mon Feb 13 15:19:59 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3505121F856D for ; Mon, 13 Feb 2012 15:19:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.635 X-Spam-Level: X-Spam-Status: No, score=-6.635 tagged_above=-999 required=5 tests=[AWL=-0.036, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 979-0TWFLe4p for ; Mon, 13 Feb 2012 15:19:58 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7E6AE21F8573 for ; Mon, 13 Feb 2012 15:19:58 -0800 (PST) Received: from [192.168.1.9] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q1DNJnQD023417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Feb 2012 15:19:55 -0800 Message-ID: <4F399A8C.6080405@dcrocker.net> Date: Mon, 13 Feb 2012 15:19:40 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1 MIME-Version: 1.0 To: Peter Saint-Andre References: <4EE2430E.4080501@isode.com> <4F1F1A72.1090302@isode.com><6068EE9E-D120-4CE9-8096-C296C169C7DE@vpnc.org><4F22EE3A.9010801@stpeter.im> <4F22EF8B.9000509@dcrocker.net><4F22EFCF.3050607@stpeter.im> <4F22F08D.4060902@stpeter.im> <4F22FF9F.5040304@dcrocker.net> <009101cce0c0$23d36160$4001a8c0@gateway.2wire.net> <4F39928F.5000300@stpeter.im> In-Reply-To: <4F39928F.5000300@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 13 Feb 2012 15:19:56 -0800 (PST) Cc: Paul Hoffman , apps-discuss , dcrocker@bbiw.net Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-xdash-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 23:19:59 -0000 On 2/13/2012 2:45 PM, Peter Saint-Andre wrote: > Shall I submit -03 so that the text is easier to track? +1 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From internet-drafts@ietf.org Mon Feb 13 15:31:22 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD4E21E805B; Mon, 13 Feb 2012 15:31:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ApDXy5zoifI3; Mon, 13 Feb 2012 15:31:21 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5775B21E804C; Mon, 13 Feb 2012 15:31:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p2 Message-ID: <20120213233121.22460.63714.idtracker@ietfa.amsl.com> Date: Mon, 13 Feb 2012 15:31:21 -0800 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-xdash-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 23:31:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Worki= ng Group of the IETF. Title : Deprecating Use of the "X-" Prefix in Application Protoc= ols Author(s) : Peter Saint-Andre D. Crocker Mark Nottingham Filename : draft-ietf-appsawg-xdash-03.txt Pages : 12 Date : 2012-02-13 Historically, designers and implementers of application protocols have often distinguished between "standard" and "non-standard" parameters by prefixing the latter with the string "X-" or similar constructions. In practice, this convention causes more problems than it solves. Therefore, this document deprecates the "X-" convention for textual parameters in application protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-appsawg-xdash-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-appsawg-xdash-03.txt From stpeter@stpeter.im Mon Feb 13 15:39:50 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F89321F875A for ; Mon, 13 Feb 2012 15:39:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.519 X-Spam-Level: X-Spam-Status: No, score=-102.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XwD7hGEEuQL8 for ; Mon, 13 Feb 2012 15:39:49 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 76BB221F8759 for ; Mon, 13 Feb 2012 15:39:49 -0800 (PST) Received: from squire.local (unknown [64.101.72.114]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8227C40058; Mon, 13 Feb 2012 16:50:27 -0700 (MST) Message-ID: <4F399F3B.2090802@stpeter.im> Date: Mon, 13 Feb 2012 16:39:39 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: dcrocker@bbiw.net References: <4EE2430E.4080501@isode.com> <4F1F1A72.1090302@isode.com><6068EE9E-D120-4CE9-8096-C296C169C7DE@vpnc.org><4F22EE3A.9010801@stpeter.im> <4F22EF8B.9000509@dcrocker.net><4F22EFCF.3050607@stpeter.im> <4F22F08D.4060902@stpeter.im> <4F22FF9F.5040304@dcrocker.net> <009101cce0c0$23d36160$4001a8c0@gateway.2wire.net> <4F39928F.5000300@stpeter.im> <4F399A8C.6080405@dcrocker.net> In-Reply-To: <4F399A8C.6080405@dcrocker.net> X-Enigmail-Version: 1.3.5 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: apps-discuss , Paul Hoffman Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-xdash-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 23:39:50 -0000 On 2/13/12 4:19 PM, Dave CROCKER wrote: > > On 2/13/2012 2:45 PM, Peter Saint-Andre wrote: >> Shall I submit -03 so that the text is easier to track? > > +1 Ask and ye shall receive: http://tools.ietf.org/rfcdiff?url2=draft-ietf-appsawg-xdash-03 Peter -- Peter Saint-Andre https://stpeter.im/ From dwing@cisco.com Mon Feb 13 17:07:05 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9725321E8023 for ; Mon, 13 Feb 2012 17:07:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.59 X-Spam-Level: X-Spam-Status: No, score=-108.59 tagged_above=-999 required=5 tests=[AWL=2.009, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oikq7VLLNM5l for ; Mon, 13 Feb 2012 17:07:04 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 75CC221E8010 for ; Mon, 13 Feb 2012 17:07:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=9036; q=dns/txt; s=iport; t=1329181624; x=1330391224; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=O1glOEpODVicmDM8mywpScQRm2eLC5qDvBkBRyFY3og=; b=g0yg1KjyfmbzaOXbELyxDFQBKSgfTCjp6sernvTRiFWNQ5ONzwIPCllq fz4isgsDzuRRfVV5dhDS7FeGOnNA3jq+kUePXmTB9SeIF1kY8vWofpCs5 ATDpEJsgN78fF4rdjFH1TLbHfMnnNgI1i+e77FKEjV48Rrev9mGG6I+ps c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8FAGGzOU+rRDoI/2dsb2JhbABDoQaPIIEHgXIBAQEDAQEBAQUKARcQNBAHAQMCCQ8CAwEBASgHGQ4VCgkIAQEEARILF4daCZpjAZ8Diz0CBAEKCAcEEAMCAgECAQIFAwQBNQkEBQQbAYNXXRODMASISoUGmmc X-IronPort-AV: E=Sophos;i="4.73,414,1325462400"; d="scan'208";a="30043902" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 14 Feb 2012 01:07:04 +0000 Received: from dwingWS ([10.32.240.195]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q1E173DL022597; Tue, 14 Feb 2012 01:07:03 GMT From: "Dan Wing" To: "'Vijay K. Gurbani'" , , References: <4F3592E5.3080707@bell-labs.com> In-Reply-To: <4F3592E5.3080707@bell-labs.com> Date: Mon, 13 Feb 2012 17:07:04 -0800 Message-ID: <0a5701cceab4$f723c070$e56b4150$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AczoPnenEPU4FAVGS+2awcHKeBOU6gCbIqSw Content-Language: en-us Subject: Re: [apps-discuss] APPSDIR rdraft-ietf-pcp-base-22 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 01:07:05 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > bounces@ietf.org] On Behalf Of Vijay K. Gurbani > Sent: Friday, February 10, 2012 1:58 PM > To: apps-discuss@ietf.org; draft-ietf-pcp-base@tools.ietf.org > Subject: [apps-discuss] APPSDIR rdraft-ietf-pcp-base-22 > > Document: draft-ietf-pcp-base-22 > Title: Port Control Protocol (PCP) > Reviewer: Vijay K. Gurbani > Review Date: Feb-10-2012 > IETF Last Call Date: Not known > IESG Telechat Date: Not known > > Summary: This draft is almost ready for publication as a Proposed > Standard but has a few issues that should be fixed before publication. > > Major issues: 0 > Minor issues: 11 > Major issues: 0 > > Issues listed below are in document order. > > - S5, the all zeroes IPv4 address as defined by the draft is a > contribution of the draft itself, right? That is, at least I am not > aware whether ::ffff:0:0 is generally used as the all-zero IPv4- > mapped > IPv6 address. It may well be, in which case this comment can be > ignored. I attempted to search for the phrase, and for ::ffff:0:0 and :ffff:0.0.0.0, and found no existing RFC using either notation to indicate "all-zeros address". So, this is the first. > But if it is not a general use address and is intended to > be > defined by this draft, I wonder if rfc2119 MUST is appropriate here > (as > in "The all-zeroes IPv4 address MUST be expressed as: 80 bits of > zeros, 16 bits of ones, and 32 bits of zeros (::ffff:0:0)."). Done. Will appear in -24. > - S6.1, the "Opcode-specific information" block of Figure 2 is not > discussed at all in the text following Figure 2. > > - S6.1, the "PCP Options" block of Figure 2 is not discussed at all in > the text following Figure 2. You do provide a Section 6.3 that > discusses options; perhaps it is sufficient to say the following at > the end of the text following Figure 2: "PCP Options: Please see > Section 6.3". > > - Ditto for S6.2 and Figure 3's use of "Opcode-specific response data" > and "Options" block. Added all of three points those described above. Will appear in -24. > - S7.1, second-to-last paragraph: I suspect that if more than one > server > was specified in the server list, the client will cycle through and > try the next server. I also note that this document only considers > one server, so exact guidance is not provided on what to do when a > PCP > client has more than one server. We are purposefully silent on multiple servers, because we expect that to be described in a later document. There are a lot of nuances and details related to multiple servers, including a multi-homed network (where you purposefully want to talk to one server, or both servers, for different reasons). Such a network is purposefully out of scope. However, we wanted the text to allow a list of servers to be returned, so that we could do something with that list in the future. > But I think it possible that the default router list (mentioned > earlier > in the section) creates a list of two servers: an IPv4- and > IPv6-server. Would it be prudent to try the IPv6 server if the IPv4 > server --- and vice-versa --- did not result in any response within > the maximum retransmission interval of 15m? The IPv6 server might do different things than the IPv4 server. For example, the IPv6 server might solely provide IPv6 firewall functionality while the IPv4 server provides IPv4-only NAT functionality. So, the IPv6 server can only deal with IPv6 addresses, and the IPv4 server can only deal with IPv4 addresses. Also, the PCP server's security model expects the requests for a mapping to an address to come from that same address. (There is an exception for THIRD_PARTY, but that is unnecessary in normal PCP deployments and not expected to be implemented.) The reason for that security model is that there is no easy way to know that a certain IPv4 address and a certain IPv6 address are really the same host -- and because of that, the PCP server can't decide to allow a PCP request sent over IPv6 transport to open a mapping to an internal IPv4 address. > - S7.3, the third paragraph from the end of the section ("For both ... > is RECOMMENDED."): Here you say that "A limit of 24 hours for success > responses and 30 minutes for error responses is RECOMMENDED." > > However, in S6.4 you said that, "It is RECOMMENDED that short > lifetime errors use a 30 second lifetime and long lifetime errors > use a 30 minute lifetime." So --- is S7.3 treating *all* error > responses as long lifetime errors? No, it's trying to set an upper limit, so if the server returns a lifetime of 5 years for an error, the client treats it as if it was a 30 minute error. I adjusted the sentence so it now reads: The PCP client SHOULD impose an upper limit on this returned value (to protect against absurdly large values, e.g., 5 years), and the suggested values are 24 hours for success responses and 30 minutes for error responses. which should be clearer? > - S9.1: The algorithm provided is excellent, but can only be used > when writing new servers (since it requires sending and receiving > PCP messages). This should be made clear before the algorithm. (I > believe that this stands to reason, but being explicit does not > hurt.) Existing servers that need to be reachable from the outside, > but > ones whose source code cannot be modified, will need to arrange for > an explicit static mapping to happen before they are started. There was an idea to have a host's IP stack automatically notify firewalls (when authorized by the user) of an application listening on a port. This idea was originally brought up in http://tools.ietf.org/html/draft-woodyatt-ald for the ALD protocol, and could also be done using PCP. I don't see a need to prevent / discourage it in the document. > - I believe that the above issue is true for S9.{2,3} as well. Yes, to get the features of the new protocol, client applications will have to change. I don't think that is unique to PCP, though. > - S16.1.1: I am not sure how to interpret the listed attacks > in this section. Is it the case that these attacks can happen > even if PCP servers comply with the Simple Threat Model? Or is > it the case that the Simple Threat Model mitigates these attacks? Section 16.1.1 enumerates the threats that are considered in the rest of 16.1. > - S16.2: To protect against Advanced Threat Model attacks, the > draft assumes a PCP security mechanism that provides channel > authentication and encryption. However, no further information > is provided for such a mechanism. Will it help to provide > any candidates for such a mechanism (TLS? S/MIME?) or is there > something entirely different in mind? The candidate at this time is draft-wasserman-pcp-authentication, which uses EAP. However, it is not yet a working group document and it seemed premature to cite it. > - S16.3.1: As far as I can see, there is no mitigation for Denial > of Service attack mounted by an attacker on the path between the > PCP client and PCP server, yes? If so, it will be nice to > explicitly state this. Done, will appear in -24. > Nit: > > - S3, while discussing Internal Host: The term "PCP MAP" request is > used > here without further context, like a short definition. Clearly, the > PCP MAP request arranges for a mapping to occur in the NAT ... the > reader can tell that much. But all the same, for the sake of > completeness, it will be good to provide a quick definition when the > term is first used. Good catch; both PEER and MAP can create a new mapping, so I changed it from ... incoming traffic resulting from a PCP MAP request ... to ... incoming traffic resulting from a PCP mapping request ... > - S3, while discussing Explicit static mappings: any reason why a GUI > (distinct from a web-based UI) is omitted? I suspect the answer is > just plain oversight, but just the same, I think it will not hurt to > include it in, or simply take out the text in the brackets. Dropped "web-based", so it now reads (e.g., via command-line interface or other user interface) > - S16.2: s/mechanism which provides/mechanism that provides Thanks for your review! -d > That's it. Thanks! > > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) > Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com > Web: http://ect.bell-labs.com/who/vkg/ > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From sm@elandsys.com Mon Feb 13 19:19:34 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0771E21F876E for ; Mon, 13 Feb 2012 19:19:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.596 X-Spam-Level: X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vc3OJSlxZ0aR for ; Mon, 13 Feb 2012 19:19:33 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 43F0921F8675 for ; Mon, 13 Feb 2012 19:19:33 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.238.167]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q1E3JHWX016163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Feb 2012 19:19:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1329189570; i=@elandsys.com; bh=IYVCTuclsklxBd8C0JCRn6VLSoZaKeC4u9nkDiWTCEs=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=M6o0eNWSUIyF3SFcpu+9+8Yh/IWrWfo8njMT8VSUD05WBsHirYNfBI8lh2G0ViWEJ 2f8KOBLyLSjVeUfwMbQfICW2KrNm/bRtAgBn1SeAif1tpIDrrQy/JCgbRgLKjJ485X 22THw6HPJsR+xeZDg7gIYL7UZALD8daIAiG7uOLw= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1329189570; i=@elandsys.com; bh=IYVCTuclsklxBd8C0JCRn6VLSoZaKeC4u9nkDiWTCEs=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=46w2u5f3kUB+j9ssl3+oPL70CvvT4VYmEH/DLousnzShf6n/G8tAMZfSSPy4ohECn XVtsImUlpaCZ+3lQTtuAhWEmp0vGPyGueRjkpZF9a5zYBLD5XRj+O9iv1oiKU+ijTk tt1mi476UFKh2/zjCc5ujOzQNVjgia1DWb4PSEug= Message-Id: <6.2.5.6.2.20120213191423.0ae30480@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 13 Feb 2012 19:18:43 -0800 To: Dan Wing , draft-ietf-pcp-base@tools.ietf.org From: S Moonesamy In-Reply-To: <0a5701cceab4$f723c070$e56b4150$@com> References: <4F3592E5.3080707@bell-labs.com> <0a5701cceab4$f723c070$e56b4150$@com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] APPSDIR rdraft-ietf-pcp-base-22 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 03:19:34 -0000 Hi Dan, At 17:07 13-02-2012, Dan Wing wrote: >I attempted to search for the phrase, and for ::ffff:0:0 and :ffff:0.0.0.0, >and found no existing RFC using either notation to indicate "all-zeros >address". So, this is the first. Would RFC 5952 be of help? Regards, S. Moonesamy From ht@inf.ed.ac.uk Tue Feb 14 09:10:12 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28D4D21F87AB; Tue, 14 Feb 2012 09:10:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6WOfkjBifCCY; Tue, 14 Feb 2012 09:10:08 -0800 (PST) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id 9DECA21F87A1; Tue, 14 Feb 2012 09:10:05 -0800 (PST) Received: from nutty.inf.ed.ac.uk (nutty.inf.ed.ac.uk [129.215.33.33]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id q1EH7EAI021667; Tue, 14 Feb 2012 17:07:18 GMT Received: from calexico.inf.ed.ac.uk (calexico.inf.ed.ac.uk [129.215.24.15]) by nutty.inf.ed.ac.uk (8.13.8/8.13.8) with ESMTP id q1EH7DkH004957; Tue, 14 Feb 2012 17:07:13 GMT Received: from calexico.inf.ed.ac.uk (localhost [127.0.0.1]) by calexico.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id q1EH7DQG025047; Tue, 14 Feb 2012 17:07:13 GMT Received: (from ht@localhost) by calexico.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id q1EH7DAr025043; Tue, 14 Feb 2012 17:07:13 GMT X-Authentication-Warning: calexico.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Justin Richer In-reply-to: 4F319539.5070606@mitre.org References: 90C41DD21FB7C64BB94121FBBC2E723453AADDD2D4@P3PW5EX1MB01.EX1.SECURESERVER.NET, f5bfwemh7pe.fsf@calexico.inf.ed.ac.uk From: ht@inf.ed.ac.uk (Henry S. Thompson) User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.4.21 (linux) Date: Tue, 14 Feb 2012 17:07:12 +0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 Cc: barryleiba@gmail.com, apps-discuss@ietf.org, dr@fb.com, oauth@ietf.org, dick.hardt@gmail.com Subject: Re: [apps-discuss] [OAUTH-WG] FW: Appsdir review of draft-ietf-oauth-v2-23 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 17:10:12 -0000 [Sigh, resending with corrected CC list] Justin writes: > [Henry wrote]: >> Subject: Appsdir review of draft-ietf-oauth-v2-23 >> >> I have been selected as the Applications Area Directorate reviewer for >> this draft (for background on appsdir, please see > href="http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate">http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). >> >> Please resolve these comments along with any other Last Call comments >> you may receive. Please wait for direction from your document shepherd >> or AD before posting a new version of the draft. >> >> Document: draft-ietf-oauth-v2-23 >> >> Title: The OAuth 2.0 Authorization Protocol >> >> Reviewer: Henry S. Thompson >> >> Review Date: 2012-02-07 >> >> IETF Last Call Date: 2012-01-24 >> >> Summary: This draft is almost ready for publication as an Proposed >> Standard but has a few issues that should be fixed >> before publication >> >> [Note - My expertise is in the areas of markup and architecture, with >> only the average geek's understanding of security and cryptographic >> technologies. Any comments below on security issues are therefore of >> the nature of general audience concerns, rather than technical >> worries.] >> >> Major Issues: >> >> 3.1.2.1 The failure to require TLS here is worrying. At the very >> least I would expect a requirement that clients which do _not_ require >> TLS MUST provide significant user feedback calling attention to this >> -- by analogy, absence of a padlock does _not_ suffice. . . > There are two bits going on here, and I think there's confusion > again about this being a *client* controlled endpoint. First, not > all callback redirects are remote HTTP URLs. A href="http://localhost/">http://localhost/ callback or an app:// > callback are going to be very common with installed clients, and in > both of these cases TLS makes no sense to require. Second, and this > is the reason spelled out in the text, you can't really expect all > *clients* to use proper TLS on their redirects. If it's a remote > HTTP call, then it's likely a very Bad Idea to go over a plaintext > socket, yes. But there are enough other cases where mandating it > doesn't make sense. > Suggestion: call out second non-HTTP use case here as well, perhaps > stop calling it an "endpoint" to differentiate it from the > server-side pieces. OK, sounds like I didn't fully understand the context here. Providing the examples you give as motivation would help keep others from making the same mistake. . . >> [3].1.2.5 In a somewhat parallel case, I would expect this section to >> at least explain why the SHOULD NOT is not a MUST NOT. Since in >> practice the distinction between trusted and untrusted 3rd-party >> scripting is difficult if not impossible to draw, as written the 2nd >> para is effectively overriden by the third. > Assuming this means 3.1.2.5 Yes, sorry. > A MUST NOT is impossible to enforce here. You're telling people to > not include jQuery in their JavaScript app. Truth is, any third > party library that you include in your app could get access to the > security bits whether it's on the callback page or not. I think it's > appropriate to provide guidance for best practices here, and the > MUST be first and SHOULD be only makes sense. People will get it > wrong in spite of what the spec says here one way or another. Hmmm. Either I'm misreading the text, or I don't understand your argument. . . The existing "MUST NOT" para applies to untrusted js. The second para. is nearly identical in terms of what it wants done, but covers _all_ js. Writing MUST/SHOULD NOT and knowing people will get it wrong just undermines the value of the spec. > Suggestion: drop the requirements (and move them to the security > doc), or otherwise no change. If by that you mean, moving it to the security section, and observing there that _failure_ to sanitise early is a risk, by effectively changing MUST NOT to WILL RISK COMPROMISE and SHOULD NOT to MAY RISK COMPROMISE, that would work for me. >> 11 It seems at best old-fashioned that the designer of a new access >> token type, parameter, endpoint response type or extension error has >> no better tool available than Google to help him/her discover whether >> the name they have in mind is in use already. The same is true under >> the proposed approach for any developer trying to determine what they >> can use or must support. Is there some reason that mandated URI >> templates, after the fashion of >> http://www.iana.org/assignments/media-types/text/ >> are not mandated for the registries, e.g. >> http://www.iana.org/assignments/access-token-types/bearer >> ? If there is a good reason, please use it to at least explicitly >> acknowledge and justify the basis for failing to provide a way for >> users and developers to use the "follow your nose" strategy >> [1]. If there is no good reason, please include the appropriate >> language to require something along the lines suggested above. If you >> need a model, see [2]. > I'm confused - is this a request to use a full URI for all extension > values? I thought the purpose of a registry was to deconflict the > short names, and that URIs could be used for anything else. No, I appreciate that you want to use registered short names in the protocol, that's just fine. My problem is that you have left users, developers etc. with no way to discover what shortnames have been registered short of a non-trivial and error-prone informal search effort. What I'm asking for is support for probe URI prefixes for each family of shortnames. So, just as today I use "text/n3" as the media type for my Notation3 documents, I can check that this is a registered media type by attempting to retrieve http://www.iana.org/assignments/media-types/text/n3 and I can see all the registered text types by retrieving from http://www.iana.org/assignments/media-types/text likewise I ought to be able to check e.g. the "bearer" token type by attempting retrieval from (something along the lines of) http://www.iana.org/assignments/access-token-types/bearer and I should be able to see all the registered token types by retrieving from http://www.iana.org/assignments/access-token-types Hope this clarifies what I meant. >> Minor Issues: >> A short summary of the changes from OAuth 1.0/RFC5849 would have >> been helpful, and it might still be a good idea to add one. . . > I don't think this is possible. OAuth2 is built nfundamentally > differently from OAuth1, so this paragraph might as well read "just > about everything but the concept". Suggestion: don't add this, > unless someone can come up with a succinct way to summarize the > decision to build on a new foundation. OK, thanks. Even something like the above short statement would be useful . . . >> 4.1 Would it be helpful to indicate that steps D&E may occur at >> any time after C, and may be repeated subsequently? > D&E may be delayed, but shouldn't be repeated. The Access Code is > one-time-use, and in the best deployments will expire after a short > period of time. Suggestion: leave as is. OK, I just think as it is it invites misinterpretation. >> 11.1 It might be useful to have an 11.1.2, which repeats references >> to the bearer and mac access token type registration drafts? > Is this a request to pre-register the two 'core' token types? Yes, in that what I had in mind was making 11.1 parallel to ll.2, 3 and 4 in this regard. ht [I'm sorry about the mailing list confusion. But please don't punish me again by sending HTML change bar markup which I have to hand edit :-] -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From internet-drafts@ietf.org Wed Feb 15 13:53:23 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 045A021E809B; Wed, 15 Feb 2012 13:53:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yb-Gj+uT7kcu; Wed, 15 Feb 2012 13:53:18 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C25121E80B8; Wed, 15 Feb 2012 13:53:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p2 Message-ID: <20120215215318.8897.58368.idtracker@ietfa.amsl.com> Date: Wed, 15 Feb 2012 13:53:18 -0800 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-greylisting-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 21:53:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Worki= ng Group of the IETF. Title : Email Greylisting: An Applicability Statement for SMTP Author(s) : Murray S. Kucherawy Filename : draft-ietf-appsawg-greylisting-03.txt Pages : 13 Date : 2012-02-15 This memo describes the art of email greylisting, the practice of providing temporarily degraded service to unknown email clients as an anti-abuse mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-appsawg-greylisting-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-appsawg-greylisting-03.txt From msk@cloudmark.com Wed Feb 15 14:02:22 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7728721F8625 for ; Wed, 15 Feb 2012 14:02:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C+2RJTumk+ik for ; Wed, 15 Feb 2012 14:02:22 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id EB4BF21F85E4 for ; Wed, 15 Feb 2012 14:02:21 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 15 Feb 2012 14:02:21 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Wed, 15 Feb 2012 14:02:19 -0800 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Date: Wed, 15 Feb 2012 13:57:25 -0800 Thread-Topic: [apps-discuss] I-D Action: draft-ietf-appsawg-greylisting-03.txt Thread-Index: AczsLEaGMAx1aU1cTmCWPLRDWNDxDQAABC+w Message-ID: References: <20120215215318.8897.58368.idtracker@ietfa.amsl.com> In-Reply-To: <20120215215318.8897.58368.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-greylisting-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 22:02:22 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] On Behalf Of internet-drafts@ietf.org > Sent: Wednesday, February 15, 2012 1:53 PM > To: i-d-announce@ietf.org > Cc: apps-discuss@ietf.org > Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-greylisting-03.txt >=20 > 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. >=20 > Title : Email Greylisting: An Applicability Statement for SMTP > Author(s) : Murray S. Kucherawy > Filename : draft-ietf-appsawg-greylisting-03.txt > Pages : 13 > Date : 2012-02-15 >=20 > This memo describes the art of email greylisting, the practice of > providing temporarily degraded service to unknown email clients as an > anti-abuse mechanism. This version takes into account various recent feedback, some of which came= from members of the Messaging Anti-Abuse Working Group, a group external t= o IETF but with which we have a liaison relationship. MAAWG is meeting nex= t week in San Francisco, and there may be another round of feedback from th= at which I'll bring to APPSAWG as well. It also changes its intended status from BCP to PS, because it's really an = applicability statement. Comments requested. If it appears to be stable between now and Paris, I'd = like to request that we start WGLC during the Paris meeting. Cheers, -MSK From sm@resistor.net Wed Feb 15 21:46:59 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6130921F8507 for ; Wed, 15 Feb 2012 21:46:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.633 X-Spam-Level: X-Spam-Status: No, score=-102.633 tagged_above=-999 required=5 tests=[AWL=-0.034, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rhN8+Rule9vb for ; Wed, 15 Feb 2012 21:46:39 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5580E21F84F3 for ; Wed, 15 Feb 2012 21:46:29 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q1G5kBWB008573 for ; Wed, 15 Feb 2012 21:46:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1329371176; i=@resistor.net; bh=hKiC3Br+PCtrKYgKjciw+fMx2HSnnIhN6dq9IhHn+BI=; h=Message-Id:Date:To:From:Subject:Mime-Version:Content-Type:Cc; b=RuhL5cedr7cnRyjy4knt3iTgHW15Bj7QI32uvRsH86IuwBKRbgdhbFak8NB55rnUW TuY7quQwnaT2cptZtnrrCHH91bvFVd+CZUYVc+xqsBkmQZC1AWqQ6otwbPTLLuLGw9 FTZWhvF+9p9xiC0TGjJ44NEFP+sgTEVd1Pg8yA6o= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1329371176; i=@resistor.net; bh=hKiC3Br+PCtrKYgKjciw+fMx2HSnnIhN6dq9IhHn+BI=; h=Message-Id:Date:To:From:Subject:Mime-Version:Content-Type:Cc; b=wj4WfzyTC2a1wMkp4mNJYBcgBG3O4vgYcr4AsRmMZ2vP3VVKl+Vd15WzPkaMDtCHi ikBgahk6+WcqkU+6Zn69/4uV7nkOa0Rp+TdXgeNYQ/+Z/9gNVe7dgiK7NP9x1BR6QP B2Mhfr+KnIVFTaGSFFy+Wxrl8WrqnwrG9+IIbuFI= Message-Id: <6.2.5.6.2.20120215194417.098a0438@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 15 Feb 2012 21:30:14 -0800 To: apps-discuss@ietf.org From: SM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [apps-discuss] Comments on draft-ietf-appsawg-greylisting-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 05:46:59 -0000 Hi Murray, Here are some comments on draft-ietf-appsawg-greylisting-03. The title of the document is "An Applicability Statement for SMTP". If we ignore that greylisting is a antispam technique that reuses one of the properties of SMTP, that might be appropriate. In Section 1: 'Preferred techniques for handling email abuse explicitly identify good actors and bad actors, giving each significantly differential service. In some cases an actor does not have a known reputation; this can justify providing degraded service, until there is a basis for provider better service. This latter approach known as "greylisting".' The last sentence seems incomplete. The above is one way to look at greylisting. Another way would be to describe the SMTP angle which is to relying on SMTP retries to "reject" mail delivery on the first try if the SMTP client is not known to the SMTP server. That is mentioned in Section 1.1. I suggest having the Background Section first. 'Greylisting exploits this by rejecting mail from unfamiliar sources with a "soft fail" (4xx) [SMTP] error code' "soft fail" is an euphemism of Section 4.2.1 of RFC 5321. :-) maemuki ni kento sasete itadakimasu. 'Another, less well-developed, application of greylisting is to delay mail from newly seen IP addresses on the theory that, if it's a spam source, then by the time it retries, it will appear in a list of sources to be filtered, and the mail will not be accepted.' This is actually one of the first and well-developed application of greylisting (see http://projects.puremagic.com/greylisting/whitepaper.html ). I recommend adding a reference to the paper as the author proposed the technique. Section 2.l is titled "Connection-level greylisting". This technique is used by a well-known provider. It makes debugging difficult as 421 is a forced shutdown when the SMTP service is unavailable. Section 2.4 mentions "the return email address" for the tuple. RFC 5321 uses the term "reverse-path". BTW, instead of "other recipients", you could use "recipients". I don't know about the effects of "greylisting" in response to DATA. In Section 2.5, the dot could be referred to as the end of mail data indicator. In Section 3: "The most obvious benefit with any of the above techniques is that spamware does not retry, and is therefore less likely to succeed, absent a record of a previous delivery attempts." Some "spamware" do retry nowadays. In Section 4.2, I suggest using "SMTP client" instead of "client". In Section 5: "To accommodate those senders that have clusters of outgoing mail servers, greylisting servers MAY track CIDR blocks of a size of its own choosing, such as /24, rather than the full IP address." As a note, there are some odd cases where mail from the cluster may come from outside a /24 (IPv4). I suggest mentioning that it's the full IPv4 address. " There is no specific recommendation as to the specific choice of 4yz code to be returned as a result of a greylisting delay." I prefer a recommendation about the choice of code as this is a policy reason (see Section 4.2.2 and 4.3.2 of RFC 5321). RFC 5598 should be a normative reference as it is mentioned in Section 1.2.2. The draft is well-written. It is ready for a Last Call. Regards, -sm From fanf2@hermes.cam.ac.uk Thu Feb 16 04:29:26 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC1D21F861A for ; Thu, 16 Feb 2012 04:29:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.32 X-Spam-Level: X-Spam-Status: No, score=-6.32 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xTihavescEGu for ; Thu, 16 Feb 2012 04:29:21 -0800 (PST) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by ietfa.amsl.com (Postfix) with ESMTP id 5D79F21F84EA for ; Thu, 16 Feb 2012 04:29:21 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:60291) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1Ry0Se-000542-qS (Exim 4.72) (return-path ); Thu, 16 Feb 2012 12:29:20 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Ry0Se-0001KX-79 (Exim 4.67) (return-path ); Thu, 16 Feb 2012 12:29:20 +0000 Date: Thu, 16 Feb 2012 12:29:20 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: SM In-Reply-To: <6.2.5.6.2.20120215194417.098a0438@elandnews.com> Message-ID: References: <6.2.5.6.2.20120215194417.098a0438@elandnews.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-greylisting-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 12:29:26 -0000 SM wrote: > > 'Another, less well-developed, application of greylisting is > to delay mail from newly seen IP addresses on the theory that, if > it's a spam source, then by the time it retries, it will appear in a > list of sources to be filtered, and the mail will not be accepted.' > > This is actually one of the first and well-developed application of > greylisting (see http://projects.puremagic.com/greylisting/whitepaper.html ). > I recommend adding a reference to the paper as the author proposed the > technique. Perhaps the author of that paper proposed the name: the technique is at least five years older. See for instance http://www.gnu.org/software/sauce/ "Mail from previously-unknown sources is delayed to give them a chance to try a bait address or get their account cancelled." Tony. -- f.anthony.n.finch http://dotat.at/ Faeroes, South-east Iceland: Westerly or northwesterly, backing southwesterly, 5 to 7, increasing gale 8 at times. Rough or very rough, occasionally high. Squally wintry showers. Good, occasionally poor, becoming very poor at times. From dhc@dcrocker.net Thu Feb 16 06:13:07 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 361CB21F86C1 for ; Thu, 16 Feb 2012 06:13:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.597 X-Spam-Level: X-Spam-Status: No, score=-6.597 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G3q+BUiTvSrd for ; Thu, 16 Feb 2012 06:13:02 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 992EA21F85DD for ; Thu, 16 Feb 2012 06:13:02 -0800 (PST) Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q1GECtDE003679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Feb 2012 06:13:01 -0800 Message-ID: <4F3D0EE5.9060008@dcrocker.net> Date: Thu, 16 Feb 2012 06:12:53 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1 MIME-Version: 1.0 To: SM References: <6.2.5.6.2.20120215194417.098a0438@elandnews.com> In-Reply-To: <6.2.5.6.2.20120215194417.098a0438@elandnews.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Thu, 16 Feb 2012 06:13:01 -0800 (PST) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-greylisting-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 14:13:07 -0000 On 2/15/2012 9:30 PM, SM wrote: > In Section 1: > > 'Preferred techniques for handling email abuse explicitly identify > good actors and bad actors, giving each significantly differential > service. In some cases an actor does not have a known reputation; > this can justify providing degraded service, until there is a basis > for provider better service. This latter approach known as > "greylisting".' > > The last sentence seems incomplete. should be 'is known as'. The above is one way to look at greylisting. > Another way would be to describe the SMTP angle which is to relying on SMTP > retries to "reject" mail delivery on the first try if the SMTP client is not > known to the SMTP server. That is mentioned in Section 1.1. I suggest having the > Background Section first. rejection is the goal that is most discussed, but note that this is also a way to slow down incoming mail selectively. > 'Greylisting exploits this by rejecting mail from unfamiliar > sources with a "soft fail" (4xx) [SMTP] error code' > > "soft fail" is an euphemism of Section 4.2.1 of RFC 5321. :-) maemuki ni kento > sasete itadakimasu. Since the class of error codes is officially "Transient Negative Completion" I'm inclined to suggest having the text say "transient (soft) fail". > This is actually one of the first and well-developed application of greylisting > (see http://projects.puremagic.com/greylisting/whitepaper.html ). I recommend > adding a reference to the paper as the author proposed the technique. Since this is non-normative material, it's generally good to be especially inclusive. Including both your and Tony's citation nicely establishes relatively long history for the mechanism. > Section 2.l is titled "Connection-level greylisting". This technique is used by > a well-known provider. It makes debugging difficult as 421 is a forced shutdown > when the SMTP service is unavailable. > > Section 2.4 mentions "the return email address" for the tuple. RFC 5321 uses the > term "reverse-path". BTW, instead of "other recipients", you could use > "recipients". hmm. the email architecture document uses the term return address and that term matches the actual semantics of the address better than the RFC821 label that RFC5321 uses. To add explicit linkage, I'll suggest "the return email address (rfc5321.MailFrom)" > In Section 5: > > "To accommodate those senders that have clusters of outgoing mail > servers, greylisting servers MAY track CIDR blocks of a size of > its own choosing, such as /24, rather than the full IP address." > > As a note, there are some odd cases where mail from the cluster may come from > outside a /24 (IPv4). I suggest mentioning that it's the full IPv4 address. Although it is unlikely that such topologically diverse 'clusters' will demonstrate the kind of hand-off for sending of mail, you are right that it is possible. So the text should just add "This heuristic will not work for clusters having machines on different networks." > " There is no specific recommendation as to the specific choice of 4yz > code to be returned as a result of a greylisting delay." > > I prefer a recommendation about the choice of code as this is a policy reason > (see Section 4.2.2 and 4.3.2 of RFC 5321). DO you have a preference for which value should be recommended? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From msk@cloudmark.com Thu Feb 16 10:57:58 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 503F121E804F for ; Thu, 16 Feb 2012 10:57:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O9t0M5V4-7IC for ; Thu, 16 Feb 2012 10:57:53 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 464A721E802E for ; Thu, 16 Feb 2012 10:57:45 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 16 Feb 2012 10:57:44 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Thu, 16 Feb 2012 10:57:41 -0800 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Date: Thu, 16 Feb 2012 10:57:40 -0800 Thread-Topic: [apps-discuss] Comments on draft-ietf-appsawg-greylisting-03 Thread-Index: AczstR5cxFWODl53RLiL0ObX7HXHNgAJIBgA Message-ID: References: <6.2.5.6.2.20120215194417.098a0438@elandnews.com> <4F3D0EE5.9060008@dcrocker.net> In-Reply-To: <4F3D0EE5.9060008@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-greylisting-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 18:57:58 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] On Behalf Of Dave CROCKER > Sent: Thursday, February 16, 2012 6:13 AM > To: SM > Cc: apps-discuss@ietf.org > Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-greylisting-03 >=20 > > The last sentence seems incomplete. >=20 > should be 'is known as'. Fixed. > > The above is one way to look at greylisting. > > Another way would be to describe the SMTP angle which is to relying on > > SMTP retries to "reject" mail delivery on the first try if the SMTP > > client is not known to the SMTP server. That is mentioned in Section > > 1.1. I suggest having the Background Section first. >=20 > rejection is the goal that is most discussed, but note that this is > also a way to slow down incoming mail selectively. In line with Tony's suggestion, I've removed the text alleging that this go= al of greylisting is "less well-developed". In my experience, though, it's= not "the" reason people deploy greylisting these days, hence that language= . I think I prefer the current section ordering. The Introduction lays out t= he general subject area, and then the Background starts presenting the "how= 'd we get here?" material. > > 'Greylisting exploits this by rejecting mail from unfamiliar > > sources with a "soft fail" (4xx) [SMTP] error code' > > > > "soft fail" is an euphemism of Section 4.2.1 of RFC 5321. :-) maemuki n= i kento > > sasete itadakimasu. >=20 > Since the class of error codes is officially "Transient Negative Completi= on" I'm > inclined to suggest having the text say "transient (soft) fail". Done. > > This is actually one of the first and well-developed application of gre= ylisting > > (see http://projects.puremagic.com/greylisting/whitepaper.html ). I rec= ommend > > adding a reference to the paper as the author proposed the technique. >=20 > Since this is non-normative material, it's generally good to be especiall= y > inclusive. Including both your and Tony's citation nicely establishes > relatively long history for the mechanism. Done. > > Section 2.l is titled "Connection-level greylisting". This technique is= used by > > a well-known provider. It makes debugging difficult as 421 is a forced = shutdown > > when the SMTP service is unavailable. How does that impede debugging? A server that doesn't go the 421 route is = not guaranteed to give you more information. > > Section 2.4 mentions "the return email address" for the tuple. RFC 5321= uses the > > term "reverse-path". BTW, instead of "other recipients", you could use > > "recipients". >=20 > hmm. the email architecture document uses the term return address and th= at term > matches the actual semantics of the address better than the RFC821 label = that > RFC5321 uses. To add explicit linkage, I'll suggest "the return email ad= dress > (rfc5321.MailFrom)" Done, and fixed "recipients". > > In Section 5: > > > > "To accommodate those senders that have clusters of outgoing mail > > servers, greylisting servers MAY track CIDR blocks of a size of > > its own choosing, such as /24, rather than the full IP address." > > > > As a note, there are some odd cases where mail from the cluster may com= e from > > outside a /24 (IPv4). I suggest mentioning that it's the full IPv4 addr= ess. >=20 > Although it is unlikely that such topologically diverse 'clusters' will > demonstrate the kind of hand-off for sending of mail, you are right that = it is > possible. So the text should just add "This heuristic will not work for c= lusters > having machines on different networks." Done. > > " There is no specific recommendation as to the specific choice of 4yz > > code to be returned as a result of a greylisting delay." > > > > I prefer a recommendation about the choice of code as this is a policy = reason > > (see Section 4.2.2 and 4.3.2 of RFC 5321). >=20 > DO you have a preference for which value should be recommended? My point there is actually to say there's no effective difference between 4= 21 and any other 4yz in this context. But that said, I'd be happy to discu= ss suggestions others might have. What about saying 421 for sites that want to kill the connection immediatel= y, and 450 otherwise? -MSK From msk@cloudmark.com Thu Feb 16 11:15:05 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE35721E805B for ; Thu, 16 Feb 2012 11:15:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YAfKjeEzlvep for ; Thu, 16 Feb 2012 11:15:04 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 00A5E21E8053 for ; Thu, 16 Feb 2012 11:15:04 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 16 Feb 2012 11:15:03 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Thu, 16 Feb 2012 11:15:03 -0800 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Date: Thu, 16 Feb 2012 11:15:02 -0800 Thread-Topic: [apps-discuss] Comments on draft-ietf-appsawg-greylisting-03 Thread-Index: AczsbmufMWT7+DmgTMm13zi/w+LbOwAbxWWA Message-ID: References: <6.2.5.6.2.20120215194417.098a0438@elandnews.com> In-Reply-To: <6.2.5.6.2.20120215194417.098a0438@elandnews.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-greylisting-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 19:15:05 -0000 Covering the stuff Dave didn't address... > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] On Behalf Of SM > Sent: Wednesday, February 15, 2012 9:30 PM > To: apps-discuss@ietf.org > Subject: [apps-discuss] Comments on draft-ietf-appsawg-greylisting-03 >=20 > Here are some comments on draft-ietf-appsawg-greylisting-03. The title > of the document is "An Applicability Statement for SMTP". If we ignore > that greylisting is a antispam technique that reuses one of the > properties of SMTP, that might be appropriate. I think a specific use of a TS to implement a technique falls within the de= finition of an AS. > In Section 3: >=20 > "The most obvious benefit with any of the above techniques is that > spamware does not retry, and is therefore less likely to succeed, > absent a record of a previous delivery attempts." >=20 > Some "spamware" do retry nowadays. I'll put "generally" before "does". > In Section 4.2, I suggest using "SMTP client" instead of "client". I'll change it in the title of the section, rather than making that substit= ution everywhere in the section. > RFC 5598 should be a normative reference as it is mentioned in Section > 1.2.2. OK, though I think it's a bit odd to make an Informative document into a no= rmative reference. > The draft is well-written. It is ready for a Last Call. Thanks! Hopefully we get one more good round of feedback and then we can r= equest WGLC in Paris. Thanks for the review. -MSK From sm@elandsys.com Thu Feb 16 11:48:10 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFEB121E8087; Thu, 16 Feb 2012 11:48:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.596 X-Spam-Level: X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxFvngyXBD4Y; Thu, 16 Feb 2012 11:48:06 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id D925421E807B; Thu, 16 Feb 2012 11:48:05 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.236.65]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q1GJlldn010497 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Feb 2012 11:47:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1329421680; i=@elandsys.com; bh=bp1jJDATPD3GRZbBVUtHPHzvGWOCXy3sCH2r6T+z0wQ=; h=Message-Id:Date:To:From:Subject:Cc:Mime-Version:Content-Type; b=fPL4RLkvcHR46MNrVNKHr3cyUd+O20+I8UaSBHvrQJueJ0SgOxW0IeIcmoQ56Xpnq ooxSNI15ZtQnLYxE2cfkLgDmWCsrCOr2qKAvDPIBZGW8dsaJPE5w+Ft+0Ic8nvj4Uy my0yKD6nFAsgprcTnLY7ca75UUEC9UwyqkDc952g= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1329421680; i=@elandsys.com; bh=bp1jJDATPD3GRZbBVUtHPHzvGWOCXy3sCH2r6T+z0wQ=; h=Message-Id:Date:To:From:Subject:Cc:Mime-Version:Content-Type; b=O2Bi8dT/18+43r94Dxs+Kx437pLP1XAb8TX6BisqXzpXTw//o1drxq6JUa8QhueeY XTKYf8mNCpCFD3qQ7jJppTxy+xPigWKgFCHY5FSQpm/oRxQl7zGLxaAdPBQvSH95L1 5XTZKFDhHtXQOIchuB1Bty1No/UkawqIw4quUrds= Message-Id: <6.2.5.6.2.20120216094738.08f96280@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 16 Feb 2012 11:47:30 -0800 To: apps-discuss@ietf.org, draft-ietf-behave-64-analysis.all@tools.ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: behave@ietf.org Subject: [apps-discuss] APPSDIR review of draft-ietf-behave-64-analysis-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 19:48:10 -0000 I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-behave-64-analysis-05 Title: Analysis of Stateful 64 Translation Reviewer: S. Moonesamy Review Date: February 16, 2012 Summary: This draft is almost ready for publication as an Informational RFC. This draft evaluates how the new stateful translation mechanisms avoid the problems that caused the IETF to deprecate NAT-PT. It discusses about problems identified in RFC 4966. There is an analysis about an application protocol (FTP) in Section 2.2. Applications are mention in several places. I did not find any application issues. Major issues: None. Minor issues: In Section 2.2: "Analysis: This is not specific to NAT64 but to all stateful NAT flavors. The presence of single point of failures is deployment-specific." Wouldn't the anchoring of flows create a single point of failure? "Actually, this is not a limitation of 64 (or even NAT-PT) but a deployment context where shared IPv4 addresses managed by the NAT64 are not globally reachable." What is meant by "shared IPv4 addresses" in this context? In Section 2.3: "Application clients (e.g., VPN clients) are not aware of the timer configured in the NAT device. For unmanaged services, a conservative approach would be adopted by applications which issue frequent keepalive messages to be sure that an active mapping is still be maintained by any involved NAT64 device even if the NAT64 complies with TCP/UDP/ICMP BEHAVE WG specifications." I suggest point to the relevant IETF specifications. For what it's worth, this draft becomes an IETF specification instead of a WG specification once it is published as a RFC. "Address persistence can be therefore easily ensured by the NAT64 function (which complies with BEHAVE NAT recommendations [RFC4787][RFC5382])." I recommend against writing a draft from a working group perspective unless it is meant for IETF consumption only. In Section 5: "This document does not specify any new protocol or architecture. It only analyzes how BEHAVE WG 64 documents mitigate concerns raised in [RFC4966] and which ones are still unaddressed." From Section 1.1, I am given to understand that there are references to mechanisms defined in the RFCs mentioned in that section. There isn't any mention of BEHAVE WG 64 documents. I suggest referencing the documents. There is a normative reference to RFC 2766, which is Historic. Nits: The Requirements language section is oddly placed. In Section 2.3: "Creation of a DoS (Denial of Service)" That could be "Creation of a Denial of Service (DoS)". Some of the informative references are out of date. Regards, S. Moonesamy From sm@resistor.net Thu Feb 16 15:33:11 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D65621F853C for ; Thu, 16 Feb 2012 15:33:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.642 X-Spam-Level: X-Spam-Status: No, score=-102.642 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rxADCiQwjwz2 for ; Thu, 16 Feb 2012 15:33:05 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id CB3B821F84E2 for ; Thu, 16 Feb 2012 15:33:05 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q1GNWwBR024168 for ; Thu, 16 Feb 2012 15:33:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1329435183; i=@resistor.net; bh=OZ25EAzP3OSC/eQuTbziXV93BtzRk/4ubRvF0OWAQPI=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=Zw/NnQ4QqM9wAyRElhM4o8HT5fUmkz9/JGgTOiD2LsUrUyXi/gLho8a+yBrGzumNf +CwWEoSyjEKt/GRCyRspb6xpGVdv83ORC9+Me+UKyMnHIraH6KquxLJiHc4hflFPfx ZJw1cQJXVAxryAu6IyNw+t9eHI5MvBw/1gk8N9Bo= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1329435183; i=@resistor.net; bh=OZ25EAzP3OSC/eQuTbziXV93BtzRk/4ubRvF0OWAQPI=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=0u6mw8WKdwhds57o2CZ4mmGdqsIzlhelZHZjg53ycwt8lzyEbpOyLpvHlC4+Uhuor xPU1se4Of2j/OSQv5xFelOECGqoQVNV7KjbyZ7lYrljhfwUobcQqL/8WFjvRB39qnu yJAPJ12pHoln+o9+dLwz9dUZCciKo8P+uWfgBz8g= Message-Id: <6.2.5.6.2.20120216143635.09cc8660@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 16 Feb 2012 15:32:38 -0800 To: apps-discuss@ietf.org From: SM In-Reply-To: <4F3D0EE5.9060008@dcrocker.net> References: <6.2.5.6.2.20120215194417.098a0438@elandnews.com> <4F3D0EE5.9060008@dcrocker.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-greylisting-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 23:33:11 -0000 Hello, [replying to both Dave and Murray's messages] At 06:12 16-02-2012, Dave CROCKER wrote: >Since the class of error codes is officially "Transient Negative >Completion" I'm inclined to suggest having the text say "transient >(soft) fail". I'm ok with that. >Since this is non-normative material, it's generally good to be >especially inclusive. Including both your and Tony's citation >nicely establishes relatively long history for the mechanism. Thanks to Tony Finch for the reminder about sauce. >hmm. the email architecture document uses the term return address >and that term matches the actual semantics of the address better >than the RFC821 label that RFC5321 uses. To add explicit linkage, >I'll suggest "the return email address (rfc5321.MailFrom)" I forgot about that. >Although it is unlikely that such topologically diverse 'clusters' >will demonstrate the kind of hand-off for sending of mail, you are >right that it is possible. So the text should just add "This >heuristic will not work for clusters having machines on different networks." Ok. I don't mind if Murray just goes for the /24 to keep matters simple. >DO you have a preference for which value should be recommended? I'll comment below. At 10:57 16-02-2012, Murray S. Kucherawy wrote: >I think I prefer the current section ordering. The Introduction >lays out the general subject area, and then the Background starts >presenting the "how'd we get here?" material. Ok. >How does that impede debugging? A server that doesn't go the 421 >route is not guaranteed to give you more information. See comment below. >My point there is actually to say there's no effective difference >between 421 and any other 4yz in this context. But that said, I'd >be happy to discuss suggestions others might have. > >What about saying 421 for sites that want to kill the connection >immediately, and 450 otherwise? From RFC 5321: "450 Requested mail action not taken: mailbox unavailable (e.g., mailbox busy or temporarily blocked for policy reasons)" The 450 code is listed for RCPT and end of data indicator. Greylisting fits "policy reason". I'll suggest using 450 to keep this separate from non-policy conditions. That code does not fit it for connection establishment as the SMTP server kills the connection. There would have to be some text for the 421 exception. I have a strong preference for not encouraging the 421 (debugging comment) as it is hard to tell whether there is a problem or if this is policy stuff. At 11:15 16-02-2012, Murray S. Kucherawy wrote: >I think a specific use of a TS to implement a technique falls within >the definition of an AS. An Applicability Statement is about setting or adapting requirement levels for a specific use. I don't think that providing degraded service qualifies for it. >OK, though I think it's a bit odd to make an Informative document >into a normative reference. As it is already in the down-ref registry, there shouldn't be any process issue. Regards, -sm From msk@cloudmark.com Thu Feb 16 15:41:12 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC29321E8047 for ; Thu, 16 Feb 2012 15:41:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e71oLwTnGQbH for ; Thu, 16 Feb 2012 15:41:12 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 1A24F21E8040 for ; Thu, 16 Feb 2012 15:41:12 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 16 Feb 2012 15:41:11 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Thu, 16 Feb 2012 15:41:11 -0800 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Date: Thu, 16 Feb 2012 15:41:09 -0800 Thread-Topic: [apps-discuss] Comments on draft-ietf-appsawg-greylisting-03 Thread-Index: AcztA3e+C8IzKa38S6egzcROziHnyAAAIE2A Message-ID: References: <6.2.5.6.2.20120215194417.098a0438@elandnews.com> <4F3D0EE5.9060008@dcrocker.net> <6.2.5.6.2.20120216143635.09cc8660@resistor.net> In-Reply-To: <6.2.5.6.2.20120216143635.09cc8660@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-greylisting-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 23:41:13 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] On Behalf Of SM > Sent: Thursday, February 16, 2012 3:33 PM > To: apps-discuss@ietf.org > Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-greylisting-03 >=20 > >What about saying 421 for sites that want to kill the connection > >immediately, and 450 otherwise? >=20 > From RFC 5321: >=20 > "450 Requested mail action not taken: mailbox unavailable (e.g., > mailbox busy or temporarily blocked for policy reasons)" >=20 > The 450 code is listed for RCPT and end of data indicator. Greylisting > fits "policy reason". I'll suggest using 450 to keep this separate > from non-policy conditions. That code does not fit it for connection > establishment as the SMTP server kills the connection. There would > have to be some text for the 421 exception. I have a strong preference > for not encouraging the 421 (debugging comment) as it is hard to tell > whether there is a problem or if this is policy stuff. So we agree that if one doesn't go for 421, then 450 is appropriate. But a= server could say either one without any comment text and be equally un-use= ful to the client. That is, if a client does 421 and dumps the connection, versus doing 450 bu= t keeping the connection open (but probably unable to do anything), I don't= see the benefit of the latter for either party. Are you presuming that th= e 421 comment will be generic while a 450 might be descriptive? > >I think a specific use of a TS to implement a technique falls within > >the definition of an AS. >=20 > An Applicability Statement is about setting or adapting requirement > levels for a specific use. I don't think that providing degraded > service qualifies for it. The definition of AS from RFC2026 is: An Applicability Statement specifies how, and under what circumstances, one or more TSs may be applied to support a particular Internet capability. I would say abuse mitigation qualifies as a "capability". -MSK From sm@resistor.net Thu Feb 16 20:34:29 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26AA321E806C for ; Thu, 16 Feb 2012 20:34:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.642 X-Spam-Level: X-Spam-Status: No, score=-102.642 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ojawL0vxPZuT for ; Thu, 16 Feb 2012 20:34:23 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C079C21E8038 for ; Thu, 16 Feb 2012 20:34:23 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q1H4YISM029926 for ; Thu, 16 Feb 2012 20:34:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1329453263; i=@resistor.net; bh=bLsEecaPfM6K4YuEp59YM7iMGrLFQsDQ9yuDA6QWEk8=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=N6Nm/Uzf1X9cVKkkTQvAkHxUv3UEG3bgMbME6YoMKgjdVo4EL97PVhlDFeILFJ5SY Abeo0WrXEYdxBHw5P465ZgsFzo9AJRSIjUhQ29/1NlsZPGUmWSfKYE9x6gXNbT8Q2Y S13nbcqcHVoBNA98CZv1kOTcPk9mtpq/XJiQsmew= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1329453263; i=@resistor.net; bh=bLsEecaPfM6K4YuEp59YM7iMGrLFQsDQ9yuDA6QWEk8=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=p4S2FtMtEM5g/x2bPF5wsj6zMIxc8mpS3ZgLppWZjSxnt+ZVtCp0i8jZHV5RH7mdt YU/6V1eu4ySA6Dl8QRaImXyTIsM0iIqZgqx4rDIs6SYrQxXVseinCutehATeDe2fer er29V2QaJoMrOIc5Em6BmyVLS7kYEyWe1FYgMdK4= Message-Id: <6.2.5.6.2.20120216201037.0901f720@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 16 Feb 2012 20:34:09 -0800 To: apps-discuss@ietf.org From: SM In-Reply-To: References: <6.2.5.6.2.20120215194417.098a0438@elandnews.com> <4F3D0EE5.9060008@dcrocker.net> <6.2.5.6.2.20120216143635.09cc8660@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-greylisting-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 04:34:29 -0000 Hi Murray, At 15:41 16-02-2012, Murray S. Kucherawy wrote: >So we agree that if one doesn't go for 421, then 450 is >appropriate. But a server could say either one without any comment >text and be equally un-useful to the client. Yes, to the "returns a 421 SMTP reply" in Section 2.1 as I do not see any other alternative. For the rest, it would be 450. >That is, if a client does 421 and dumps the connection, versus doing >450 but keeping the connection open (but probably unable to do >anything), I don't see the benefit of the latter for either >party. Are you presuming that the 421 comment will be generic while >a 450 might be descriptive? If the SMTP server sends a 421, it would force the connection to close. The usual implementations usually provide some text with the 450. The 421 comment I have seen was generic. I'll presume that a 421 means "service unavailable" as described in RFC 5321. BTW, 421 is sometimes used for load shedding. >The definition of AS from RFC2026 is: > > An Applicability Statement specifies how, and under what > circumstances, one or more TSs may be applied to support a particular > Internet capability. > >I would say abuse mitigation qualifies as a "capability". Local policy in SMTP provides leeway. It can be used for abuse mitigation. In my opnion, that's not an Internet capability. Regards, -sm From msk@cloudmark.com Thu Feb 16 22:32:19 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8821721F8734 for ; Thu, 16 Feb 2012 22:32:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8bbJZsoPeDxP for ; Thu, 16 Feb 2012 22:32:19 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 0C78C21F8732 for ; Thu, 16 Feb 2012 22:32:18 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 16 Feb 2012 22:32:18 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Thu, 16 Feb 2012 22:32:18 -0800 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Date: Thu, 16 Feb 2012 22:32:17 -0800 Thread-Topic: [apps-discuss] Comments on draft-ietf-appsawg-greylisting-03 Thread-Index: AcztLXUQWsxG/6S8TDC74LT5IWd1awACbOQw Message-ID: References: <6.2.5.6.2.20120215194417.098a0438@elandnews.com> <4F3D0EE5.9060008@dcrocker.net> <6.2.5.6.2.20120216143635.09cc8660@resistor.net> <6.2.5.6.2.20120216201037.0901f720@resistor.net> In-Reply-To: <6.2.5.6.2.20120216201037.0901f720@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-greylisting-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 06:32:19 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] On Behalf Of SM > Sent: Thursday, February 16, 2012 8:34 PM > To: apps-discuss@ietf.org > Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-greylisting-03 >=20 > >That is, if a client does 421 and dumps the connection, versus doing > >450 but keeping the connection open (but probably unable to do > >anything), I don't see the benefit of the latter for either party. Are > >you presuming that the 421 comment will be generic while a 450 might be > >descriptive? >=20 > If the SMTP server sends a 421, it would force the connection to close. > The usual implementations usually provide some text with the 450. The > 421 comment I have seen was generic. >=20 > I'll presume that a 421 means "service unavailable" as described in RFC > 5321. BTW, 421 is sometimes used for load shedding. I don't think we can make the presumption that the text accompanying 421 wi= ll be more or less descriptive than the text accompanying 450. The impleme= ntation will decide in either case. Proscribing use of 421 by itself won't= compel implementers to make the 450 text more helpful. So the question comes down to whether or not the implementer wants to dump = the connection or let it linger. There's also the common argument that if = you've decided to greylist a client because it might be a spammer, you prob= ably don't want to be helpful to it at all anyway. I'll try to come up with some text that walks the line between the two pers= pectives. > > An Applicability Statement specifies how, and under what > > circumstances, one or more TSs may be applied to support a particula= r > > Internet capability. > > > >I would say abuse mitigation qualifies as a "capability". >=20 > Local policy in SMTP provides leeway. It can be used for abuse > mitigation. In my opnion, that's not an Internet capability. Since the work of greylisting involves an altered but still interoperable i= nteraction between clients and servers, I believe it does qualify. Do others want to weigh in on this? -MSK From msk@cloudmark.com Thu Feb 16 23:35:55 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F30421F8899 for ; Thu, 16 Feb 2012 23:35:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lXuOut9TiOrD for ; Thu, 16 Feb 2012 23:35:54 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id E945B21F8894 for ; Thu, 16 Feb 2012 23:35:54 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 16 Feb 2012 23:35:54 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Thu, 16 Feb 2012 23:35:54 -0800 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Date: Thu, 16 Feb 2012 23:35:54 -0800 Thread-Topic: A greylisting question Thread-Index: AcztRsfW5k8L11HGSwOVHMKjKtPY0A== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5833273385BB34F99288B3648C4F06F19C9A7DDDFEXCHC2corpclo_" MIME-Version: 1.0 Subject: [apps-discuss] A greylisting question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 07:35:55 -0000 --_000_F5833273385BB34F99288B3648C4F06F19C9A7DDDFEXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I suspect the IESG will ask this if we don't cover it, so let's put somethi= ng in about this now... The current draft only talks about IPv4, because that's what we have experi= ence with so far in terms of greylisting. How does our advice translate to= IPv6? Is it the same? -MSK --_000_F5833273385BB34F99288B3648C4F06F19C9A7DDDFEXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I suspect the IE= SG will ask this if we don’t cover it, so let’s put something i= n about this now…

 

The current draft only talks about IPv4, because = that’s what we have experience with so far in terms of greylisting.&n= bsp; How does our advice translate to IPv6?  Is it the same?

 

-MSK

= --_000_F5833273385BB34F99288B3648C4F06F19C9A7DDDFEXCHC2corpclo_-- From sm@elandsys.com Fri Feb 17 00:04:15 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14E4921E801C; Fri, 17 Feb 2012 00:04:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.596 X-Spam-Level: X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rdg3SrgRG1ev; Fri, 17 Feb 2012 00:04:10 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id B502E21E8015; Fri, 17 Feb 2012 00:04:10 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.236.65]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q1H83gfI011336 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Feb 2012 00:04:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1329465845; i=@elandsys.com; bh=9VAzFC1ICPygHuldwNx5RW2Tp2PiH+H1Y1N2prDWRtI=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=mlGChsB0wbWqWGItkR7rmUntXUrsEA2YBINQi54jCtGhX2JnypLdspqbDIytvJQFh Dzc5i0h3hYe4Ur6QD3PEFkBKB7zsRMoq3hXXMKyPDJMm55nztpEmR+XvqnK26Eqt1m zCt51XzrXchPDrkPS/leNQE7KHX00pd6fihler94= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1329465845; i=@elandsys.com; bh=9VAzFC1ICPygHuldwNx5RW2Tp2PiH+H1Y1N2prDWRtI=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=ZoEuGjgxtsLLkokg/Fn/R8nLvdfxAnsUoswSm2q/SyQfN7+yrTzyaEyt0YHRtgoqL F+dem0ET6BMeqJ8kMjNfUvcZc2gtDB0bK1gje2JnteR5u008iqf/2bO1cxX5W4dtgj 6PJj03W8jzD/RtG+7cTlDtd+HifSeYrfKnMUdN6k= Message-Id: <6.2.5.6.2.20120216232557.0915c0a0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 16 Feb 2012 23:57:04 -0800 To: mohamed.boucadair@orange.com, apps-discuss@ietf.org, draft-ietf-behave-64-analysis.all@tools.ietf.org From: S Moonesamy In-Reply-To: <94C682931C08B048B7A8645303FDC9F35D8868D387@PUEXCB1B.nanter re.francetelecom.fr> References: <6.2.5.6.2.20120216094738.08f96280@elandnews.com> <94C682931C08B048B7A8645303FDC9F35D8868D387@PUEXCB1B.nanterre.francetelecom.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: behave@ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-behave-64-analysis-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 08:04:15 -0000 Hi Med, At 22:51 16-02-2012, mohamed.boucadair@orange.com wrote: >In some deployment it can be SPOF but in others no. This depends if >the a distributed NAT model is adopted, if NAT state synchronization >mechanisms are enabled, etc. Do we need to clarify this in the document? It would help the reader if that could be clarified. >The IPv4 address pool used by the NAT64 to service IPv6 hosts. >Several IPv6 hosts may share the same IPv4 address. Do you think >this need a clarification in the document? I recommend a clarification as there is a proposal about shared address space. >Sorry, but I don't understand this comment. Can you please clarify? Thanks. If we are talking about the BEHAVE WG, IETF participants either know about it or can look it up. If you say "which complies with BEHAVE NAT", a wider audience would not know what BEHAVE is. It's easier to say "complies with NAT recommendations in [RFC4787][RFC5382]". >I can do but IMHO the document does not introduce new security concerns, no? I don't think so but I'll defer to the Security Directorate on this. Thanks for the feedback. Regards, S. Moonesamy From dhc@dcrocker.net Fri Feb 17 05:50:29 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB24621F86D5 for ; Fri, 17 Feb 2012 05:50:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.597 X-Spam-Level: X-Spam-Status: No, score=-6.597 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8F+jkcN0dGFw for ; Fri, 17 Feb 2012 05:50:29 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id C76A421F86D1 for ; Fri, 17 Feb 2012 05:50:28 -0800 (PST) Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q1HDoNgQ012807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 17 Feb 2012 05:50:28 -0800 Message-ID: <4F3E5B1B.7090200@dcrocker.net> Date: Fri, 17 Feb 2012 05:50:19 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1 MIME-Version: 1.0 To: apps-discuss@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 17 Feb 2012 05:50:28 -0800 (PST) Subject: Re: [apps-discuss] A greylisting question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 13:50:30 -0000 On 2/16/2012 11:35 PM, Murray S. Kucherawy wrote: > I suspect the IESG will ask this if we don’t cover it, so let’s put something in > about this now… > > The current draft only talks about IPv4, because that’s what we have experience > with so far in terms of greylisting. How does our advice translate to IPv6? Is > it the same? There will, at least, be some differences and possibly many. But since we have no experience with this stuff in that space, we can't be sure. There is no practice that we can declare 'best'. At most, we can add a comment acknowledging the topic and commenting on some basic issues. Something along the lines of: At the time of this writing, there is no widespread experience with greylisting as applied to sources using IPv6 addresses. The greater size of an IPv6 address seems likely to permit differences in behaviors by bad actors, and this could well mean needing to alter the details for applying greylisting; it might even negate any benefits in using greylisting at all. At a minimum, it is likely to call for different specific choices for any greylisting algorithm variables. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From julian.reschke@gmx.de Fri Feb 17 07:54:03 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBFE121F8775 for ; Fri, 17 Feb 2012 07:54:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.4 X-Spam-Level: X-Spam-Status: No, score=-104.4 tagged_above=-999 required=5 tests=[AWL=-1.801, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rK91kKIJV9c7 for ; Fri, 17 Feb 2012 07:54:02 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id EEB1421F858B for ; Fri, 17 Feb 2012 07:54:01 -0800 (PST) Received: (qmail invoked by alias); 17 Feb 2012 15:54:00 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.83]) [217.91.35.233] by mail.gmx.net (mp031) with SMTP; 17 Feb 2012 16:54:00 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18Ypg8M17AYMq1FTWcTZZYMH3KUHZUwNvevAUw9DF xTyLLCQag+LP3q Message-ID: <4F3E7816.4070709@gmx.de> Date: Fri, 17 Feb 2012 16:53:58 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1 MIME-Version: 1.0 To: ietf@ietf.org References: <20120217144555.26744.99147.idtracker@ietfa.amsl.com> In-Reply-To: <20120217144555.26744.99147.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: HTTP Working Group , IETF Apps Discuss Subject: Re: [apps-discuss] Last Call: (The Hypertext Transfer Protocol (HTTP) Status Code 308 (Permanent Redirect)) to Experimental RFC X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 15:54:04 -0000 (FYI) Also, an HTML version with feedback links is available at . Best regards, Julian On 2012-02-17 15:45, The IESG wrote: > > The IESG has received a request from an individual submitter to consider > the following document: > - 'The Hypertext Transfer Protocol (HTTP) Status Code 308 (Permanent > Redirect)' > as an Experimental RFC > > 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 2012-03-16. 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 specifies the additional HyperText Transfer Protocol > (HTTP) Status Code 308 (Permanent Redirect). > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-reschke-http-status-308/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-reschke-http-status-308/ > > > No IPR declarations have been submitted directly on this I-D. > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > From mohamed.boucadair@orange.com Thu Feb 16 22:51:51 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B32B21F8895; Thu, 16 Feb 2012 22:51:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.181 X-Spam-Level: X-Spam-Status: No, score=-2.181 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id svQlhriSaY9T; Thu, 16 Feb 2012 22:51:47 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 48A2D21F8894; Thu, 16 Feb 2012 22:51:47 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 0C1F13B41EB; Fri, 17 Feb 2012 07:51:46 +0100 (CET) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id E51C323804B; Fri, 17 Feb 2012 07:51:45 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Fri, 17 Feb 2012 07:51:45 +0100 From: To: S Moonesamy , "apps-discuss@ietf.org" , "draft-ietf-behave-64-analysis.all@tools.ietf.org" Date: Fri, 17 Feb 2012 07:51:44 +0100 Thread-Topic: APPSDIR review of draft-ietf-behave-64-analysis-05 Thread-Index: Aczs4/xoDCy4yfCrSsOUceIUrZ8WrgAWewGg Message-ID: <94C682931C08B048B7A8645303FDC9F35D8868D387@PUEXCB1B.nanterre.francetelecom.fr> References: <6.2.5.6.2.20120216094738.08f96280@elandnews.com> In-Reply-To: <6.2.5.6.2.20120216094738.08f96280@elandnews.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.2.17.61221 X-Mailman-Approved-At: Fri, 17 Feb 2012 11:59:01 -0800 Cc: "behave@ietf.org" Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-behave-64-analysis-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 06:51:51 -0000 Dear SM, Thank you for your review. Please see inline. Cheers, Med=20 > -----Message d'origine----- > De : S Moonesamy [mailto:sm+ietf@elandsys.com]=20 > Envoy=E9 : jeudi 16 f=E9vrier 2012 20:48 > =C0 : apps-discuss@ietf.org;=20 > draft-ietf-behave-64-analysis.all@tools.ietf.org > Cc : behave@ietf.org > Objet : APPSDIR review of draft-ietf-behave-64-analysis-05 >=20 > I have been selected as the Applications Area Directorate reviewer=20 > for this draft (for background on appsdir, please see=20 > http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsArea > Directorate ). >=20 > Please resolve these comments along with any other Last Call comments=20 > you may receive. Please wait for direction from your document=20 > shepherd or AD before posting a new version of the draft. >=20 > Document: draft-ietf-behave-64-analysis-05 > Title: Analysis of Stateful 64 Translation > Reviewer: S. Moonesamy > Review Date: February 16, 2012 >=20 > Summary: This draft is almost ready for publication as an=20 > Informational RFC. >=20 > This draft evaluates how the new stateful translation mechanisms=20 > avoid the problems that caused the IETF to deprecate NAT-PT. It=20 > discusses about problems identified in RFC 4966. There is an=20 > analysis about an application protocol (FTP) in Section=20 > 2.2. Applications are mention in several places. I did not find any=20 > application issues. >=20 > Major issues: >=20 > None. >=20 > Minor issues: >=20 > In Section 2.2: >=20 > "Analysis: This is not specific to NAT64 but to all stateful > NAT flavors. The presence of single point of failures is > deployment-specific." >=20 > Wouldn't the anchoring of flows create a single point of failure? In some deployment it can be SPOF but in others no. This depends if the a d= istributed NAT model is adopted, if NAT state synchronization mechanisms ar= e enabled, etc. Do we need to clarify this in the document? >=20 > "Actually, this is not a limitation of 64 (or even NAT-PT) but > a deployment context where shared IPv4 addresses managed by > the NAT64 are not globally reachable." >=20 > What is meant by "shared IPv4 addresses" in this context? The IPv4 address pool used by the NAT64 to service IPv6 hosts. Several IPv6= hosts may share the same IPv4 address. Do you think this need a clarificat= ion in the document? >=20 > In Section 2.3: >=20 > "Application clients (e.g., VPN clients) are not aware of the > timer configured in the NAT device. For unmanaged services, a > conservative approach would be adopted by applications which > issue frequent keepalive messages to be sure that an active > mapping is still be maintained by any involved NAT64 device > even if the NAT64 complies with TCP/UDP/ICMP BEHAVE WG > specifications." >=20 > I suggest point to the relevant IETF specifications. For what it's=20 > worth, this draft becomes an IETF specification instead of a WG=20 > specification once it is published as a RFC. Ok, changed to RFC4787, RFC5382 and RFC5508. >=20 > "Address persistence can be therefore easily ensured by the > NAT64 function (which complies with BEHAVE NAT recommendations > [RFC4787][RFC5382])." >=20 > I recommend against writing a draft from a working group perspective=20 > unless it is meant for IETF consumption only. Sorry, but I don't understand this comment. Can you please clarify? Thanks. >=20 > In Section 5: >=20 > "This document does not specify any new protocol or=20 > architecture. It > only analyzes how BEHAVE WG 64 documents mitigate=20 > concerns raised in > [RFC4966] and which ones are still unaddressed." >=20 > From Section 1.1, I am given to understand that there are references=20 > to mechanisms defined in the RFCs mentioned in that section. There=20 > isn't any mention of BEHAVE WG 64 documents. I suggest referencing=20 > the documents. I can do but IMHO the document does not introduce new security concerns, no= ? >=20 > There is a normative reference to RFC 2766, which is Historic. Moved to Informative Section. >=20 > Nits: >=20 > The Requirements language section is oddly placed. Fixed.=20 >=20 > In Section 2.3: >=20 > "Creation of a DoS (Denial of Service)" >=20 > That could be "Creation of a Denial of Service (DoS)". Ok. >=20 > Some of the informative references are out of date. >=20 > Regards, > S. Moonesamy >=20 > = From mohamed.boucadair@orange.com Fri Feb 17 01:16:03 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2392D21F887E; Fri, 17 Feb 2012 01:16:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.186 X-Spam-Level: X-Spam-Status: No, score=-2.186 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CsODJABMgQ+j; Fri, 17 Feb 2012 01:16:02 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 466EF21F885C; Fri, 17 Feb 2012 01:16:02 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id F105C3B4212; Fri, 17 Feb 2012 10:16:00 +0100 (CET) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id CBF384C060; Fri, 17 Feb 2012 10:16:00 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Fri, 17 Feb 2012 10:16:00 +0100 From: To: S Moonesamy , "apps-discuss@ietf.org" , "draft-ietf-behave-64-analysis.all@tools.ietf.org" Date: Fri, 17 Feb 2012 10:15:59 +0100 Thread-Topic: APPSDIR review of draft-ietf-behave-64-analysis-05 Thread-Index: AcztSr3tCEngTmJBQsGF8VcTugRUcAAB/jRg Message-ID: <94C682931C08B048B7A8645303FDC9F35D8868D42C@PUEXCB1B.nanterre.francetelecom.fr> References: <6.2.5.6.2.20120216094738.08f96280@elandnews.com> <94C682931C08B048B7A8645303FDC9F35D8868D387@PUEXCB1B.nanterre.francetelecom.fr> <6.2.5.6.2.20120216232557.0915c0a0@elandnews.com> In-Reply-To: <6.2.5.6.2.20120216232557.0915c0a0@elandnews.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.2.17.85414 X-Mailman-Approved-At: Fri, 17 Feb 2012 11:59:09 -0800 Cc: "behave@ietf.org" Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-behave-64-analysis-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 09:16:03 -0000 Re-, Thank you for the clarifications. I updated the document accordingly. Cheers, Med=20 > -----Message d'origine----- > De : S Moonesamy [mailto:sm+ietf@elandsys.com]=20 > Envoy=E9 : vendredi 17 f=E9vrier 2012 08:57 > =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; apps-discuss@ietf.org;=20 > draft-ietf-behave-64-analysis.all@tools.ietf.org > Cc : behave@ietf.org > Objet : RE: APPSDIR review of draft-ietf-behave-64-analysis-05 >=20 > Hi Med, > At 22:51 16-02-2012, mohamed.boucadair@orange.com wrote: > >In some deployment it can be SPOF but in others no. This depends if=20 > >the a distributed NAT model is adopted, if NAT state synchronization=20 > >mechanisms are enabled, etc. Do we need to clarify this in=20 > the document? >=20 > It would help the reader if that could be clarified. >=20 > >The IPv4 address pool used by the NAT64 to service IPv6 hosts.=20 > >Several IPv6 hosts may share the same IPv4 address. Do you think=20 > >this need a clarification in the document? >=20 > I recommend a clarification as there is a proposal about=20 > shared address space. >=20 > >Sorry, but I don't understand this comment. Can you please=20 > clarify? Thanks. >=20 > If we are talking about the BEHAVE WG, IETF participants either know=20 > about it or can look it up. If you say "which complies with BEHAVE=20 > NAT", a wider audience would not know what BEHAVE is. It's easier to=20 > say "complies with NAT recommendations in [RFC4787][RFC5382]". >=20 > >I can do but IMHO the document does not introduce new=20 > security concerns, no? >=20 > I don't think so but I'll defer to the Security Directorate on this. >=20 > Thanks for the feedback. >=20 > Regards, > S. Moonesamy=20 >=20 > = From johnl@iecc.com Fri Feb 17 12:26:59 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A82321F8647 for ; Fri, 17 Feb 2012 12:26:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.804 X-Spam-Level: X-Spam-Status: No, score=-109.804 tagged_above=-999 required=5 tests=[AWL=1.395, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gkMPGwutUl3y for ; Fri, 17 Feb 2012 12:26:58 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id C5C7D21F8624 for ; Fri, 17 Feb 2012 12:26:57 -0800 (PST) Received: (qmail 7955 invoked from network); 17 Feb 2012 20:26:56 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 17 Feb 2012 20:26:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4f3eb80f.xn--9vv.k1202; i=johnl@user.iecc.com; bh=b2xFUHcj6f88v1a2q+EWJf7AUGwrVQ9HEXkaG0Anmrg=; b=UGHb5jRwYCX0GaGCKLg8i1GgPDzlGMiBo7pAkhwWREUD3UjDAQVl3s8hGEv4kWcGJNQdwpigdJzY507wrgwQc89TE5JkrAVNJiJY9IDz9bw6Iv3smkBWiiPSjSCJwxpj2LLlXKo46QGAsUvn+GQAbnJ6Yn/3LHKDeW/0s1HRk/g= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4f3eb80f.xn--9vv.k1202; olt=johnl@user.iecc.com; bh=b2xFUHcj6f88v1a2q+EWJf7AUGwrVQ9HEXkaG0Anmrg=; b=huM82+Wk8COwOY9X1p5D9L4pd2r2qge4BV9lId1ecfGS1qYsK9El18kE75C6ZiA2kTdXAOk1C8jfYYVO2++ASsIYF7Os+Yq9Xt2kyPstHnXzhhKfv/luwlfvqPQpzSyRc4OmAx9PubT33OLKqeGrPaIRtSSDAEwNhAC4u6rZRDc= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 17 Feb 2012 20:26:33 -0000 Message-ID: <20120217202633.73871.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <6.2.5.6.2.20120216201037.0901f720@resistor.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-greylisting-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 20:26:59 -0000 >If the SMTP server sends a 421, it would force the connection to >close. The usual implementations usually provide some text with the >450. The 421 comment I have seen was generic. > >I'll presume that a 421 means "service unavailable" as described in >RFC 5321. BTW, 421 is sometimes used for load shedding. Quite possibly, but what would a client do differently? Remember that the client is software, it only looks at the code, not the text. My clients treat all 4xx the same, go away for a while, until the aggregate while gets so long that it gives up. R's, John From johnl@iecc.com Fri Feb 17 12:46:11 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2256121E8053 for ; Fri, 17 Feb 2012 12:46:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.822 X-Spam-Level: X-Spam-Status: No, score=-109.822 tagged_above=-999 required=5 tests=[AWL=1.377, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mlAry25LRJ9a for ; Fri, 17 Feb 2012 12:46:10 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id B9D3221E8020 for ; Fri, 17 Feb 2012 12:46:09 -0800 (PST) Received: (qmail 15283 invoked from network); 17 Feb 2012 20:46:08 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 17 Feb 2012 20:46:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4f3ebc90.xn--9vv.k1202; i=johnl@user.iecc.com; bh=VrMN2DLA2baY0ptBZ5FQk8lMrtpLJq+2dq8im1Cnk7o=; b=wMyI0rbUz4Hj7TGHZUzNnAzd6U0W3xJn7/Lk8GULkBzcbDXDxlqAy8Rx5I3oCitMv9y3PYjxgnkF2Q2Ls3QIB6KAZp+fUrbr7JXCg86aOfFpD5eER7ZBMbVXpU2+un5FOhVdNkrwWRTUSpLkUA7kqJAEULsaYZbF3dBy3KuGqKM= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4f3ebc90.xn--9vv.k1202; olt=johnl@user.iecc.com; bh=VrMN2DLA2baY0ptBZ5FQk8lMrtpLJq+2dq8im1Cnk7o=; b=rFy9CZGatKpiFecfkA/LHeUepRGFUbj8MLPx18xA51NgJnzwpOBvhra38mh5+JgIr5e1mwZGMS4mLfqLlWD5Pt3DcAwxWqHCxPT30KdEwsi1azpTJb/TrnY3f3ko6L6aCHOKYAnzNCVYkOAwZVOMkyuavdJrYOuPsPYe46apOrg= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 17 Feb 2012 20:45:46 -0000 Message-ID: <20120217204546.74515.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <4F3E5B1B.7090200@dcrocker.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: dcrocker@bbiw.net Subject: Re: [apps-discuss] A greylisting question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 20:46:11 -0000 >There will, at least, be some differences and possibly many. But since we have >no experience with this stuff in that space, we can't be sure. Yoo hoo. I've been greylisting IPv6 for a while. What I can mostly say is that the small number of IPv6 MTAs I see retry just like IPv4 MTAs. I don't think I've seen any bots except maybe one or two that went through a v4-v6 gateway of some sort without intending to. At this point, most of the v6 mail I see comes from a handful of senders who do it because it's cool (notably NANOG and IETF), or they're testing it. Most of the spam comes from insecure web hosts who are dual homed. So I agree that we have little to say about IPv6 at this point beyond nothing that the principle is the same. -- Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From sm@resistor.net Fri Feb 17 13:23:27 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6046111E8079 for ; Fri, 17 Feb 2012 13:23:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.64 X-Spam-Level: X-Spam-Status: No, score=-102.64 tagged_above=-999 required=5 tests=[AWL=-0.041, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T2nzhA3bKM21 for ; Fri, 17 Feb 2012 13:23:25 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id E299411E8076 for ; Fri, 17 Feb 2012 13:23:23 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q1HLNIGi007631; Fri, 17 Feb 2012 13:23:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1329513803; i=@resistor.net; bh=BXTbTIT67WAep6/7P1nEgu9WNpyxqlhzj8GG8ZtvdWI=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=Qu+6ZTeXp0KvcVgDWpfyE4B8iZ7xs51Bm+D8wFw3XwTf78C6JRj4/4wgitSH8QQ5K XB9LDldRd9cHLnOkxu7ghpSRG8fJZ4NhpXghOWqyn8TcSvJ9dfwDhqmuUbQiSpKSvz v4H/0+2y1rkm7iRvEtnzJtm1mL2DOMl8z/m1rVcY= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1329513803; i=@resistor.net; bh=BXTbTIT67WAep6/7P1nEgu9WNpyxqlhzj8GG8ZtvdWI=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=uLFbbA5PvldeJTdfF6tq1biPkOpXkuTHx0OtMIka8W83Ake8Yq7zjmHWmMp4mLzd4 J6xY0n0pXcsRV78EotuMoHS4NLoN1ZxGL7/b3QC66VVvxDfJ5XvzxmfgFiMSpciX00 zO4Hx2GQzayrsFFrkJYF1DuU75zgKYWFiIUpPrM0= Message-Id: <6.2.5.6.2.20120217131852.0a8c4248@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 17 Feb 2012 13:21:52 -0800 To: John Levine From: SM In-Reply-To: <20120217202633.73871.qmail@joyce.lan> References: <6.2.5.6.2.20120216201037.0901f720@resistor.net> <20120217202633.73871.qmail@joyce.lan> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-greylisting-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 21:23:27 -0000 Hi John, At 12:26 17-02-2012, John Levine wrote: >Quite possibly, but what would a client do differently? Remember >that the client is software, it only looks at the code, not the >text. My clients treat all 4xx the same, go away for a while, >until the aggregate while gets so long that it gives up. The SMTP client does not have to do anything differently as it on looks at the code. Regards, -sm From dhc@dcrocker.net Fri Feb 17 15:13:08 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EA8821F8540 for ; Fri, 17 Feb 2012 15:13:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.597 X-Spam-Level: X-Spam-Status: No, score=-6.597 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXnY5cZizvjb for ; Fri, 17 Feb 2012 15:13:06 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8B2A121F8532 for ; Fri, 17 Feb 2012 15:13:06 -0800 (PST) Received: from [192.168.1.9] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q1HNCxaq025669 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Feb 2012 15:13:05 -0800 Message-ID: <4F3EDEF8.2040908@dcrocker.net> Date: Fri, 17 Feb 2012 15:12:56 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1 MIME-Version: 1.0 To: John Levine References: <20120217204546.74515.qmail@joyce.lan> In-Reply-To: <20120217204546.74515.qmail@joyce.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 17 Feb 2012 15:13:05 -0800 (PST) Cc: dcrocker@bbiw.net, apps-discuss@ietf.org Subject: Re: [apps-discuss] A greylisting question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 23:13:08 -0000 On 2/17/2012 12:45 PM, John Levine wrote: >> There will, at least, be some differences and possibly many. But since we have >> no experience with this stuff in that space, we can't be sure. > > Yoo hoo. I've been greylisting IPv6 for a while. and therein lies the core problem with sampling error: there is no way that any current greylisting work with v6 has statistical significance relative to large-scale use. one anecdotal reportage out of a tiny percent of the global market simply can't represent the (yet to develop) global market. it /might/ be a bit interesting to hear about what /is/ done, but it can't possibly be significant to hear what isn't... yet... done. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From internet-drafts@ietf.org Fri Feb 17 19:44:31 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2C1121E8025; Fri, 17 Feb 2012 19:44:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l5RdGfqD-4Uj; Fri, 17 Feb 2012 19:44:30 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 180F921E8013; Fri, 17 Feb 2012 19:44:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p2 Message-ID: <20120218034410.18405.16630.idtracker@ietfa.amsl.com> Date: Fri, 17 Feb 2012 19:44:10 -0800 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-greylisting-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 03:44:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Worki= ng Group of the IETF. Title : Email Greylisting: An Applicability Statement for SMTP Author(s) : Murray S. Kucherawy D. Crocker Filename : draft-ietf-appsawg-greylisting-04.txt Pages : 14 Date : 2012-02-17 This memo describes the art of email greylisting, the practice of providing temporarily degraded service to unknown email clients as an anti-abuse mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-appsawg-greylisting-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-appsawg-greylisting-04.txt From johnl@iecc.com Fri Feb 17 20:29:14 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D051421F84F2 for ; Fri, 17 Feb 2012 20:29:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.874 X-Spam-Level: X-Spam-Status: No, score=-109.874 tagged_above=-999 required=5 tests=[AWL=1.325, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xhEUpz3bQ6ey for ; Fri, 17 Feb 2012 20:29:14 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 65A6321F84EF for ; Fri, 17 Feb 2012 20:29:12 -0800 (PST) Received: (qmail 54785 invoked from network); 18 Feb 2012 04:29:11 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 18 Feb 2012 04:29:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4f3f2916.xn--30v786c.k1202; i=johnl@user.iecc.com; bh=vMJAI3+scjHH2DJARCgd/Y6aSMEFbGAO1LoWBRHMhnI=; b=VsXtaho6Q7FnwI8CXvvZhCx0N5ymkEYfMNqVzHOSC0XPj/hbePPGJKY6E7C4nmEV19fNwhetVtavdHfua4HUzAsOihk6FtFaM8bw4aKhZkUokKdISU8zfNaJnI7FMHy0BzDAndibMGBGoWnEzLzUcUVzq7Qh2eqLhRWfspBBHNk= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4f3f2916.xn--30v786c.k1202; olt=johnl@user.iecc.com; bh=vMJAI3+scjHH2DJARCgd/Y6aSMEFbGAO1LoWBRHMhnI=; b=aINKhfWzjelZGqwrB656WwrWQiK5uQyaKQzDHGvQ3seMV2temOm9lYD4uTEGGRhbx144L9RPakmt/RvK2lBlloINpxebX0FfQQ0OaQzt24dgzC5PrEPHa2EN6HzZzWbe//Ripuk0IHrxlV+KTh26YC08s/cvZl40bDL8Zviej+Q= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 18 Feb 2012 04:28:48 -0000 Message-ID: <20120218042848.90000.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <20120217202633.73871.qmail@joyce.lan> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-greylisting-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 04:29:14 -0000 Looks pretty good. A few minor points: In section 3, I think that you should point out that a in a successful greylister, all the regular correspondents will be whitelisted, so the only mail that is delayed is mail from an IP that has never sent mail before, or sent mail so long ago that it's fallen out of the whitelist. In mail systems I've used, the vast majority of mail comes from places on the whitelist, so after a training period (which you can fake by watching traffic before you turn on the greylister and seed the whitelist with all the addresses you've seen) only a small proportion of mail should be affected. In section 3 and again in section 9.2, it refers to the size of the database. My total database is under 40,000 entries, including 92 IPv6 addresses. I expect a larger system would have a larger database, but it would be a pretty feeble server that would have trouble with a table even ten times that size. My manual whitelist has 62 entries, mostly CIDR ranges, probably half of which are stale but there's not much incentive to clean it out. R's, John From msk@cloudmark.com Fri Feb 17 20:41:35 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45FCA21E803E for ; Fri, 17 Feb 2012 20:41:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IHSpzpKQdiWf for ; Fri, 17 Feb 2012 20:41:34 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id C80D821E8013 for ; Fri, 17 Feb 2012 20:41:34 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 17 Feb 2012 20:41:34 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Fri, 17 Feb 2012 20:41:34 -0800 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Date: Fri, 17 Feb 2012 20:41:32 -0800 Thread-Topic: [apps-discuss] Comments on draft-ietf-appsawg-greylisting-04 Thread-Index: Aczt9eErj7RXBW1lSZeYvirwTcvEKQAAX4Ag Message-ID: References: <20120217202633.73871.qmail@joyce.lan> <20120218042848.90000.qmail@joyce.lan> In-Reply-To: <20120218042848.90000.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-greylisting-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 04:41:35 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] On Behalf Of John Levine > Sent: Friday, February 17, 2012 8:29 PM > To: apps-discuss@ietf.org > Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-greylisting-04 >=20 > Looks pretty good. A few minor points: >=20 > In section 3, I think that you should point out that a in a successful > greylister, all the regular correspondents will be whitelisted, so the > only mail that is delayed is mail from an IP that has never sent mail > before, or sent mail so long ago that it's fallen out of the whitelist. > In mail systems I've used, the vast majority of mail comes from places > on the whitelist, so after a training period (which you can fake by > watching traffic before you turn on the greylister and seed the > whitelist with all the addresses you've seen) only a small proportion > of mail should be affected. Sure, a description of the "steady state" would be a reasonable thing to ad= d. I'll schedule that for the next revision, probably late next week after MAA= WG. > In section 3 and again in section 9.2, it refers to the size of the > database. My total database is under 40,000 entries, including 92 > IPv6 addresses. I expect a larger system would have a larger database, > but it would be a pretty feeble server that would have trouble with a > table even ten times that size. My manual whitelist has 62 entries, > mostly CIDR ranges, probably half of which are stale but there's not > much incentive to clean it out. That's good news. I wonder if we can get a couple of other greylisting sit= es to provide their database sizes too so we know for sure that this is fai= rly consistent. Thanks, -MSK From john-ietf@jck.com Sat Feb 18 08:42:47 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E38721F85EC for ; Sat, 18 Feb 2012 08:42:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.926 X-Spam-Level: X-Spam-Status: No, score=-101.926 tagged_above=-999 required=5 tests=[AWL=-0.816, BAYES_05=-1.11, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oRJK2WXRBV6A for ; Sat, 18 Feb 2012 08:42:46 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 82FE621F85E6 for ; Sat, 18 Feb 2012 08:42:46 -0800 (PST) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1RynJ1-000Khj-Nu; Sat, 18 Feb 2012 11:38:39 -0500 Date: Sat, 18 Feb 2012 11:42:40 -0500 From: John C Klensin To: "Murray S. Kucherawy" , apps-discuss@ietf.org Message-ID: <858663F7C89EC31177B0ADA7@PST.JCK.COM> In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [apps-discuss] A greylisting question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 16:42:47 -0000 --On Thursday, February 16, 2012 23:35 -0800 "Murray S. Kucherawy" wrote: > I suspect the IESG will ask this if we don't cover it, so > let's put something in about this now... > > The current draft only talks about IPv4, because that's what > we have experience with so far in terms of greylisting. How > does our advice translate to IPv6? Is it the same? Murray, If you go down the path of commenting about things with which we have little experience, it could be interesting to explore the implications of large-scale (not just end-network) address translation as well, whether carried out by CGNs or other methods. But I think that just reinforces the view that, while a paragraph explaining what we don't know (or don't know with any certainty) could be useful, any attempt to identify specific best practices will just lead into rat holes. john From torsten@lodderstedt.net Sun Feb 19 09:16:43 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBF3321F852A; Sun, 19 Feb 2012 09:16:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.568 X-Spam-Level: X-Spam-Status: No, score=0.568 tagged_above=-999 required=5 tests=[AWL=-1.897, BAYES_40=-0.185, HELO_EQ_DE=0.35, MANGLED_LIST=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ODVjYHo+ajCm; Sun, 19 Feb 2012 09:16:42 -0800 (PST) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.25]) by ietfa.amsl.com (Postfix) with ESMTP id 3B36A21F8525; Sun, 19 Feb 2012 09:16:42 -0800 (PST) Received: from [79.253.29.122] (helo=[192.168.71.36]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1RzANL-0003Tq-Dk; Sun, 19 Feb 2012 18:16:39 +0100 Message-ID: <4F412E76.6080408@lodderstedt.net> Date: Sun, 19 Feb 2012 18:16:38 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Tim Bray References: <6.2.5.6.2.20120123134319.0a76c338@resistor.net> In-Reply-To: <6.2.5.6.2.20120123134319.0a76c338@resistor.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: S Moonesamy , apps-discuss@ietf.org, oauth@ietf.org Subject: Re: [apps-discuss] [OAUTH-WG] Apps Area review of draft-ietf-oauth-v2-threatmodel-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2012 17:16:43 -0000 Hi Tim, I just submitted the revised version of the OAuth 2.0 security document (http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-02). This revision should address the issues you raised in your AppsDir review. We especially removed all normative language from the document. We took the liberty to leave the back references in Section 5. We consider this back references to section 4 a valuable information for implementors since they justify the particular countermeasure. All to often security considerations are given without the corresponding rationales. And without a justification, the "unconvinced" implementor may tend to ignore or underestimate the respective controls. regards, Torsten. Am 23.01.2012 22:47, schrieb S Moonesamy: > The following is the AppsDir review performed by Tim Bray. It would > be appreciated if a reply is sent to Tim Bray with a copy to the > apps-discuss mailing list. > > I have been selected as the Applications Area Directorate reviewer for > this draft (for background on appsdir, please see > http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). > > > Please resolve these comments along with any other Last Call comments > you may receive. Please wait for direction from your document shepherd > or AD before posting a new version of the draft. > > Document: draft-ietf-oauth-v2-threatmodel-01 > Title: OAuth 2.0 Threat Model and Security Considerations > Reviewer: Tim Bray > Review Date: Jan 23, 2012 > > Summary: This needs some more editorial work, but is basically sound. > It's not clear, though, whether it wants to be an Informational RFC or > not; the use of RFC2119 language needs special attention. I think a > few of the "minor issues" are worthy of a little bit more work in > another draft. > > Major Issues: > > The use of 2119 MUST/SHOULD/etc doesn't seem fully thought through. I > normally wouldn't expect a "threat model" to include normative text. > The basic idea would be to say "Here is an enumeration of the threats, > and here are the tools available to OAUTH2 implementors to meet them." > I was impressed by the enumeration, which seemed very complete and > well thought through. But the usage of 2119, which makes statements > normative, seems inconsistent. I can think of 2 ways to address this: > > 1. Remove all the 2119 words, so this document isn't normative, and > publish it as an Informational RFC > 2. Go through and clean up the 2119 language so it's used > consistently; then this becomes a normative document. > > This is going to affect the references to this document from other > I-Ds in the OAuth suite, which are currently in last call. > > Here are all the section-numbered notes enumerating my issues around > 2119, as I encountered them: > > Section 2.3, I'm a little confused about the use of RFC2119 MAY in a > threat analysis. When you say "The following data elements MAY be > stored or accessible...", Is this saying that "The OAuth2 RFC says > that the following data elements MAY be..." or is it saying something > else. I don't think there's anything seriously wrong here, but a bit > more explanation might be in order. I note a comparative absence of > 2119-ese in section 5 describing countermeasures, where one would > expect to find it. > Also in 4.3.1, first bullet point, there's "Authorization servers > MUST..." > Also in: 4.4.1.1, 4.4.1.6, 4.4.1.12, 4.6.*, 5.1.4.1.5, 5.1.5.11 > Related: "SHALL"?! in 4.6.3 > Adding to the concern, there is use of lower-case "must"; note 2nd & > 3rd bullet points in 4.4.3, which use "MUST" and "must" respectively. > > Minor Issues: > > 4.1.2 first attack: It says "An attack may obtain the refresh tokens > issued to a web server client." This needs to be clearer... a "Web > server client" can be a browser or a native app. Do you mean, "the > refresh tokens issued by the web server to multiple clients?" > > 4.1.2 last attack. In the case where a device is cloned, wouldn't > "Utilize device lock to prevent unauthorized device access" still be a > countermeasure? In many devices, such cloning would carry along the > user's device-lock settings. > > 4.4.1.4 2nd bullet. The explanation of why this wouldn't work for > native clients wasn't comprehensible to me. I'm suspicious of any > such claims because I can emulate most things a browser can do in a > mobile client. Perhaps this would be obvious to someone who is an > OAuth2 implementor. > > 4.4.1.9 I think where it says "iFrame" it might mean "WebView", i.e. a > Web Browser control embedded in the native app. If that's not what it > means, I don't understand what it's saying. If this is true, then the > second bullet point is probably wrong. > > 4.6.6 1st bullet. I'm not convinced that the Cache-Control header > will *ensure* that a client protects information properly. Should say > something like "minimize the risk that authenticated content is not > protected" > > 5.* The enumeration, for some but not all of the countermeasures in > this section, of the threats against which this is a countermeasure, > reduces readability and, unless it's generated automatically from the > underlying source, is redundant information, which is unlikely to be > consistent between sections 4 and 5, and adds difficulty to > maintenance of this document without adding much value. I'd just wipe > all these bullet lists out. If it's generated automatically it's less > damaging, but still reduces readability. In the current draft, this > is there for some countermeasures but absent for others. Another good > reason to just take it out. > > 5.2.2.5 Device identifiers are very tricky. It's correct that IMEI is > not adequate, but there are ways to do it without SMS. For more, see > http://android-developers.blogspot.com/2011/03/identifying-app-installations.html > > > 5.3.4 Surely a little more could be said about device lock. On a > typical modern phone, "device lock" options include PINs, passwords, > "face recognition" and so on. These are *not* equal in their level of > security they provide. > > Nits: > > Formatting is lousy. There are notations, including ** and _whatever_ > that I'm not familiar with in the RFC context. > > Section 1.0: s/in-built into/built into/ > 2.1, last bullet point: "An example could by a..." s/by/be/ > 2.2, 1st bullet point s/eaves drop/eavesdrop/ > 2.3, 1st para, s/treat/threat/ > 2.3.1, last bullet, "per authorization process". Adjectival phrases > should be hyphenated: "per-authorization process" > 2.3.3, last bullet, ditto > 3.1, 1st para, "all kinds of tokens" should be "many kinds of tokens" > 3.1, 2nd para, should be ; not , after "within the authorization server" > s/protected/protect/ > s/different system/different systems/ > 3.4 1st para, s/intermediary/intermediate/ > list item 1. s/short-living/short-lived/ > 3.5 s/malicious client/malicious clients/ > 3.7 top of page 12, what is the underscore notation _client_id_ mean? > I'm not familiar with this in the RFC context. > 1st bullet point: s/token/token's/ > 2nd bullet point, multiple issues, 1st sentence should be " the > initial authorization and issuance of a token by an end-user > to a particular client, and subsequent requests by this client to > obtain tokens without user consent (automatic processing of repeated > authorization) > halfway down page 13, s/insures/ensures/ > s/validates the clients/validates the client's/ > 4. first sentence, s/this sections/this section/ > 4.1.2 first para, the last sentence is confusing. How about: "Before > enumerating the threats, here are some generally applicable > countermeasures:" > 4.2.4 2nd bullet s/could not be/can not be/ > 4.3.3 1st bullet, capitalized phrase "Confidentiality of Requests" - I > assume that's supposed to be a hyperlink to one of the 5.* sections? > 4.4.1.1 last bullet, s/referee/referrer/ - also, should note that the > referrer header may contain an Authorization code in a ?a=b style > argument > 4.4.1.2 first bullet, "can be employed" is inconsistent with style of > rest of doc > 4.4.1.3 first 2 bullets have un-labeled links. > 4.4.1.4 1st bullet s/authentication/authenticate/ > 4.4.1.4 2nd bullet s/mean/means/ > 4.4.1.7 2nd bullet s/tokens/token's/ > 4.4.1.10, 2nd para, s/requisiete/requisite/ s/embbed/embed/ > 4.4.1.10, 3rd bullet, s/aibility/ability/ > 4.4.1.10, toward bottom of page 30, s/e.t.c./etc./ > 4.4.1.12 I think the href to semicomplete.com needs to be turned into > an IETF-style reference > 4.4.2 " since HTTP user agents do not send fragments server requests." > What you mean to say is "Since HTTP user agents do not send the > fragment part of URIs to HTTP servers." > 4.4.2.2 s/browser/browser's/ > 5.1.4.1.3 s/consider to not store/refrain from storing/ > 5.* s/may consider to $(verb)/may consider $(verb)ing/ > 5.1.6 Needs some sort of sentence structure > 5.3.2 Needs some sort of sentence structure; or is this intended just > to be a title, with 5.3.3 etc nested under it? > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From msk@cloudmark.com Tue Feb 21 10:40:41 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0673421E8032 for ; Tue, 21 Feb 2012 10:40:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1zR2-X-fjqE for ; Tue, 21 Feb 2012 10:40:40 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 4274021F88E1 for ; Tue, 21 Feb 2012 10:40:37 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 21 Feb 2012 10:40:36 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 21 Feb 2012 10:40:36 -0800 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Date: Tue, 21 Feb 2012 10:40:37 -0800 Thread-Topic: [apps-discuss] A greylisting question Thread-Index: AczuXFtWr9SeRKCdQFaXlShVSSN4sgCa8pSQ Message-ID: References: <858663F7C89EC31177B0ADA7@PST.JCK.COM> In-Reply-To: <858663F7C89EC31177B0ADA7@PST.JCK.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [apps-discuss] A greylisting question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 18:40:41 -0000 > -----Original Message----- > From: John C Klensin [mailto:john-ietf@jck.com] > Sent: Saturday, February 18, 2012 8:43 AM > To: Murray S. Kucherawy; apps-discuss@ietf.org > Subject: Re: [apps-discuss] A greylisting question >=20 > If you go down the path of commenting about things with which we have > little experience, it could be interesting to explore the implications > of large-scale (not just end-network) address translation as well, > whether carried out by CGNs or other methods. But I think that just > reinforces the view that, while a paragraph explaining what we don't > know (or don't know with any certainty) could be useful, any attempt to > identify specific best practices will just lead into rat holes. Hi John, I think it would be fine to list this among the considerations that deserve= attention when one deploys greylisting (or, for that matter, address trans= lation), but I also quite agree that making any best practice recommendatio= ns in that area is to be avoided. Thanks for the comment. -MSK From msk@cloudmark.com Tue Feb 21 11:02:55 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5ACC21F88A2 for ; Tue, 21 Feb 2012 11:02:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dvCgrJqW46Xt for ; Tue, 21 Feb 2012 11:02:55 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 2978B21F8897 for ; Tue, 21 Feb 2012 11:02:55 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 21 Feb 2012 11:02:54 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Tue, 21 Feb 2012 11:02:54 -0800 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Date: Tue, 21 Feb 2012 11:02:56 -0800 Thread-Topic: [apps-discuss] Comments on draft-ietf-appsawg-greylisting-04 Thread-Index: Aczt9eErj7RXBW1lSZeYvirwTcvEKQC1Ttjw Message-ID: References: <20120217202633.73871.qmail@joyce.lan> <20120218042848.90000.qmail@joyce.lan> In-Reply-To: <20120218042848.90000.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-greylisting-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 19:02:55 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] On Behalf Of John Levine > Sent: Friday, February 17, 2012 8:29 PM > To: apps-discuss@ietf.org > Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-greylisting-04 >=20 > Looks pretty good. A few minor points: >=20 > In section 3, I think that you should point out that a in a successful > greylister, all the regular correspondents will be whitelisted, so the > only mail that is delayed is mail from an IP that has never sent mail > before, or sent mail so long ago that it's fallen out of the whitelist. > In mail systems I've used, the vast majority of mail comes from places > on the whitelist, so after a training period (which you can fake by > watching traffic before you turn on the greylister and seed the > whitelist with all the addresses you've seen) only a small proportion > of mail should be affected. I've added this paragraph to the bottom of Section 3: Presuming that known friendly senders will be manually configured as exceptions to the greylisting check, a steady state will eventually be reached wherein the only mail that is delayed is mail from an IP address that has never sent mail before. Experience suggests that the, the vast majority of mail comes from places on such a developed exception list, so after a training period, only a small proportion of mail is actually affected. The training period could be replaced by processing a history of email traffic and adding the IP addresses from which most traffic arrives to the exception list. Does that cover it? > In section 3 and again in section 9.2, it refers to the size of the > database. My total database is under 40,000 entries, including 92 > IPv6 addresses. I expect a larger system would have a larger database, > but it would be a pretty feeble server that would have trouble with a > table even ten times that size. My manual whitelist has 62 entries, > mostly CIDR ranges, probably half of which are stale but there's not > much incentive to clean it out. Added this to the end of 9.2, same question: In practice, this has not appeared as a serious concern, because any reasonable aging policy successfully moderates database growth. It is nevertheless identified here as a consideration as there may be implementations in some environments where this is indeed an issue. From msk@cloudmark.com Tue Feb 21 11:07:38 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C24C21E803B for ; Tue, 21 Feb 2012 11:07:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a91npyvEpee1 for ; Tue, 21 Feb 2012 11:07:38 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 06BFA21E802A for ; Tue, 21 Feb 2012 11:07:38 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 21 Feb 2012 11:07:37 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 21 Feb 2012 11:07:37 -0800 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Date: Tue, 21 Feb 2012 11:07:38 -0800 Thread-Topic: BCP, AS, something else? (was RE: [apps-discuss] Comments on draft-ietf-appsawg-greylisting-03) Thread-Index: AcztLXUQWsxG/6S8TDC74LT5IWd1awACbOQwAOUi9xA= Message-ID: References: <6.2.5.6.2.20120215194417.098a0438@elandnews.com> <4F3D0EE5.9060008@dcrocker.net> <6.2.5.6.2.20120216143635.09cc8660@resistor.net> <6.2.5.6.2.20120216201037.0901f720@resistor.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [apps-discuss] BCP, AS, something else? (was RE: Comments on draft-ietf-appsawg-greylisting-03) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 19:07:38 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] On Behalf Of Murray S. Kucherawy > Sent: Thursday, February 16, 2012 10:32 PM > To: apps-discuss@ietf.org > Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-greylisting-03 >=20 > > > An Applicability Statement specifies how, and under what > > > circumstances, one or more TSs may be applied to support a particu= lar > > > Internet capability. > > > > > >I would say abuse mitigation qualifies as a "capability". > > > > Local policy in SMTP provides leeway. It can be used for abuse > > mitigation. In my opnion, that's not an Internet capability. >=20 > Since the work of greylisting involves an altered but still > interoperable interaction between clients and servers, I believe it > does qualify. >=20 > Do others want to weigh in on this? I'd like to hear some other WG opinions on this. This document started out= as a BCP, but with some guidance from Pete and a re-read of RFC2026, cited= above, I believe this qualifies as an Applicability Statement, so I change= d its requested status accordingly. (I should have pointed this out when I= posted the revision; sorry about that.) SM disagrees; his is the middle c= ited text there. What's the group's consensus? -MSK From johnl@iecc.com Tue Feb 21 11:53:08 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE7021E809C for ; Tue, 21 Feb 2012 11:53:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.937 X-Spam-Level: X-Spam-Status: No, score=-109.937 tagged_above=-999 required=5 tests=[AWL=1.262, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nBvydp6Exn2j for ; Tue, 21 Feb 2012 11:53:03 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 287B221E8096 for ; Tue, 21 Feb 2012 11:53:03 -0800 (PST) Received: (qmail 79566 invoked from network); 21 Feb 2012 19:52:56 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 21 Feb 2012 19:52:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4f43f618.xn--hew.k1202; i=johnl@user.iecc.com; bh=HcIWA1AYXcNfXJBfjZywDLOk1ucN+SuRCPghmGB80yw=; b=JV0vd0VVtJm/66NQpxYnbDVKy6Rz4LG44yg5R+Sdyv85sn78+OtsUCm9D6r95bvJAQm0Zl0VgatE+uwga69fz8eUNIHU1KCBQwlc7qVpM7FCvma46VLkvZjNHyXH8japlEdYjKVe4cQfHJ/cD6vugdMboG4EfstQRF9x3RLOang= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4f43f618.xn--hew.k1202; olt=johnl@user.iecc.com; bh=HcIWA1AYXcNfXJBfjZywDLOk1ucN+SuRCPghmGB80yw=; b=TgaDgcxsEqB7dSQJ3LUFzud+OgypjdROdsjJaH2gFA3xhuebe7za7EjwvB4g2nSlJ28ij6c5VYi2OWIy9xZGUbv7pycenRuMWADsU+AEi+nOOeH5lWFTHIHrdRtHelNSf18AVKFauecycyTRjt4BPvc04KSmH9ysNXSOeVQhEOI= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 21 Feb 2012 19:52:34 -0000 Message-ID: <20120221195234.48946.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-greylisting-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 19:53:08 -0000 >I've added this paragraph to the bottom of Section 3: > > Presuming that known friendly senders will be manually configured as > exceptions to the greylisting check, see below > a steady state will eventually > be reached wherein the only mail that is delayed is mail from an IP > address that has never sent mail before. Experience suggests that > the, the vast majority of mail comes from places on such a developed > exception list, so after a training period, only a small proportion > of mail is actually affected. The training period could be replaced > by processing a history of email traffic and adding the IP addresses > from which most traffic arrives to the exception list. > >Does that cover it? The only sources that need to be configured manually are ones that either don't retry in a way the greylister will recognize, or send so rarely that they'll age out of the exception list. Any normal sender will enter the exception list the first time it retries, and never leave. >Added this to the end of 9.2, same question: > > In practice, this has not appeared as a serious concern, because any > reasonable aging policy successfully moderates database growth. It > is nevertheless identified here as a consideration as there may be > implementations in some environments where this is indeed an issue. Sure. I suppose a greylister in an embedded device might have space constraints. R's, John From msk@cloudmark.com Tue Feb 21 13:12:49 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B725611E808C for ; Tue, 21 Feb 2012 13:12:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.595 X-Spam-Level: X-Spam-Status: No, score=-102.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Owx+r4wxdAz for ; Tue, 21 Feb 2012 13:12:49 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 26A3B11E808A for ; Tue, 21 Feb 2012 13:12:48 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 21 Feb 2012 13:12:48 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Tue, 21 Feb 2012 13:12:48 -0800 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Date: Tue, 21 Feb 2012 13:12:50 -0800 Thread-Topic: [apps-discuss] Comments on draft-ietf-appsawg-greylisting-04 Thread-Index: Aczw0ms+FfulINNgSbiajOKI7CEI2QACxm6w Message-ID: References: <20120221195234.48946.qmail@joyce.lan> In-Reply-To: <20120221195234.48946.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-greylisting-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 21:12:49 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKb2huIExldmluZSBbbWFpbHRv OmpvaG5sQHRhdWdoLmNvbV0NCj4gU2VudDogVHVlc2RheSwgRmVicnVhcnkgMjEsIDIwMTIgMTE6 NTMgQU0NCj4gVG86IGFwcHMtZGlzY3Vzc0BpZXRmLm9yZw0KPiBDYzogTXVycmF5IFMuIEt1Y2hl cmF3eQ0KPiBTdWJqZWN0OiBSZTogW2FwcHMtZGlzY3Vzc10gQ29tbWVudHMgb24gZHJhZnQtaWV0 Zi1hcHBzYXdnLWdyZXlsaXN0aW5nLTA0DQo+IA0KPiBUaGUgb25seSBzb3VyY2VzIHRoYXQgbmVl ZCB0byBiZSBjb25maWd1cmVkIG1hbnVhbGx5IGFyZSBvbmVzIHRoYXQNCj4gZWl0aGVyIGRvbid0 IHJldHJ5IGluIGEgd2F5IHRoZSBncmV5bGlzdGVyIHdpbGwgcmVjb2duaXplLCBvciBzZW5kIHNv DQo+IHJhcmVseSB0aGF0IHRoZXknbGwgYWdlIG91dCBvZiB0aGUgZXhjZXB0aW9uIGxpc3QuICBB bnkgbm9ybWFsIHNlbmRlcg0KPiB3aWxsIGVudGVyIHRoZSBleGNlcHRpb24gbGlzdCB0aGUgZmly c3QgdGltZSBpdCByZXRyaWVzLCBhbmQgbmV2ZXINCj4gbGVhdmUuDQoNCkFkZGVkIHRvIHRoZSBl bmQgb2YgMi42Og0KDQogICBMaWtlbHkgY2FuZGlkYXRlcyB0byBiZSBleGNlcHRlZCBmcm9tIGdy ZXlsaXN0aW5nIGluY2x1ZGUgdGhvc2Uga25vd24NCiAgIG5vdCB0byByZXRyeSBhY2NvcmRpbmcg dG8gYSBwYXR0ZXJuIHRoYXQgd2lsbCBiZSBvYnNlcnZlZCBhcw0KICAgbGVnaXRpbWF0ZSwgYW5k IHRob3NlIHRoYXQgc2VuZCBzbyByYXJlbHkgdGhhdCB0aGV5IHdpbGwgYWdlIG91dCBvZg0KICAg dGhlIGRhdGFiYXNlLiAgSW4gYm90aCBjYXNlcyB0aGUgZXhjZXB0ZWQgc291cmNlIGlzIGtub3du IG5vdCB0byBiZQ0KICAgYW4gYWJ1c2l2ZSBvbmUgYnkgdGhlIHNpdGUgaW1wbGVtZW50aW5nIGdy ZXlsaXN0aW5nLiAgT3RoZXJ3aXNlLA0KICAgdHlwaWNhbCBub24tYWJ1c2l2ZSBzZW5kZXJzIHdp bGwgZW50ZXIgdGhlIGV4Y2VwdGlvbiBsaXN0IG9uIHRoZQ0KICAgZmlyc3QgcHJvcGVyIHJldHJ5 LCBhbmQgcmVtYWluIHRoZXJlIHBlcm1hbmVudGx5Lg0K From barryleiba.mailing.lists@gmail.com Tue Feb 21 13:36:50 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E37C21E8087 for ; Tue, 21 Feb 2012 13:36:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.957 X-Spam-Level: X-Spam-Status: No, score=-102.957 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QG43KaXt8LpG for ; Tue, 21 Feb 2012 13:36:50 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3F31721E8085 for ; Tue, 21 Feb 2012 13:36:44 -0800 (PST) Received: by ghbg16 with SMTP id g16so3615173ghb.31 for ; Tue, 21 Feb 2012 13:36:42 -0800 (PST) Received-SPF: pass (google.com: domain of barryleiba.mailing.lists@gmail.com designates 10.236.145.230 as permitted sender) client-ip=10.236.145.230; Authentication-Results: mr.google.com; spf=pass (google.com: domain of barryleiba.mailing.lists@gmail.com designates 10.236.145.230 as permitted sender) smtp.mail=barryleiba.mailing.lists@gmail.com; dkim=pass header.i=barryleiba.mailing.lists@gmail.com Received: from mr.google.com ([10.236.145.230]) by 10.236.145.230 with SMTP id p66mr37806704yhj.27.1329860202257 (num_hops = 1); Tue, 21 Feb 2012 13:36:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=pAAKyff79sDoREyeKw5s8LMLVQ2luzsHPuYUiuez+g0=; b=jnS9p8RNrD3aFOYugfIWzwJygSDr1DNKzSJvCPcafQu8jo4D+0lSCP4AaCcXGZGKit WH2xrskFRKCffmyh4ZJNQWinBUbcq9QaHBbWrcyy/Hf9fo1+rv1EgIJzlctnlBwI8vRU MBgrGrH4Wg1A1f4i/AOZRdqiSvas1IucO5AnU= MIME-Version: 1.0 Received: by 10.236.145.230 with SMTP id p66mr29406366yhj.27.1329860202204; Tue, 21 Feb 2012 13:36:42 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.58.20 with HTTP; Tue, 21 Feb 2012 13:36:42 -0800 (PST) In-Reply-To: References: <6.2.5.6.2.20120215194417.098a0438@elandnews.com> <4F3D0EE5.9060008@dcrocker.net> <6.2.5.6.2.20120216143635.09cc8660@resistor.net> <6.2.5.6.2.20120216201037.0901f720@resistor.net> Date: Tue, 21 Feb 2012 16:36:42 -0500 X-Google-Sender-Auth: 8_CXJlZduPI0V9f7gOBXG4ir6aI Message-ID: From: Barry Leiba To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=20cf3040eb32f40d5604b9803430 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] BCP, AS, something else? (was RE: Comments on draft-ietf-appsawg-greylisting-03) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 21:36:50 -0000 --20cf3040eb32f40d5604b9803430 Content-Type: text/plain; charset=ISO-8859-1 > > This document started out as a BCP, but with some guidance from Pete and a > re-read of RFC2026, cited above, I believe this qualifies as an > Applicability Statement, so I changed its requested status accordingly. (I > should have pointed this out when I posted the revision; sorry about that.) > SM disagrees; his is the middle cited text there. > For the record, as incoming AD, I concur that this fits fine as an AS, and that that target status works better for this document than BCP does. It describes how to apply SMTP to a particular use case. That said, this is a working-group document, and at the first level its target status has to reflect working-group consensus. So please, weigh in. Barry (as chair/AD) --20cf3040eb32f40d5604b9803430 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This document started out as a BCP, but with= some guidance from Pete and a re-read of RFC2026, cited above, I believe t= his qualifies as an Applicability Statement, so I changed its requested sta= tus accordingly. =A0(I should have pointed this out when I posted the revis= ion; sorry about that.) =A0SM disagrees; his is the middle cited text there= .

For the record, as incoming AD, I concur t= hat this fits fine as an AS, and that that target status works better for t= his document than BCP does. =A0It describes how to apply SMTP to a particul= ar use case.

That said, this is a working-group document, and at the= first level its target status has to reflect working-group consensus. =A0S= o please, weigh in.

Barry (as chair/AD)=A0
--20cf3040eb32f40d5604b9803430-- From ned.freed@mrochek.com Tue Feb 21 23:38:17 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66CEF21E808B for ; Tue, 21 Feb 2012 23:38:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id udEN18SQHU5A for ; Tue, 21 Feb 2012 23:38:16 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 9BDC221E8087 for ; Tue, 21 Feb 2012 23:38:16 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OC9QKS1LI8006A0G@mauve.mrochek.com> for apps-discuss@ietf.org; Tue, 21 Feb 2012 23:38:13 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OC8QYYHB0W00ZUIL@mauve.mrochek.com>; Tue, 21 Feb 2012 23:38:11 -0800 (PST) Message-id: <01OC9QKQISCS00ZUIL@mauve.mrochek.com> Date: Tue, 21 Feb 2012 23:34:15 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Tue, 21 Feb 2012 11:07:38 -0800" MIME-version: 1.0 Content-type: TEXT/PLAIN References: <6.2.5.6.2.20120215194417.098a0438@elandnews.com> <4F3D0EE5.9060008@dcrocker.net> <6.2.5.6.2.20120216143635.09cc8660@resistor.net> <6.2.5.6.2.20120216201037.0901f720@resistor.net> To: "Murray S. Kucherawy" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1329896296; bh=1rJ6p0DZ/+C29QReFtxnYqt7zcv8AephqK1nkWa8J7k=; h=Cc:Message-id:Date:From:Subject:In-reply-to:MIME-version: Content-type:References:To; b=KmVN9edrk7SMoN9ehRvR6IUJjRc8Mym40ua+wMWm5n3CzAe/nu05T78IgmKvyAHrV OAXyUrjyR8RE/WrqceqE9ZNgc2CMxEziix3EKYIXlN7Gb3O3Nayzt/A9ctcZmGPkEa nOlQJ2wIhwVkHMjzn37yMHgrAHgJujyRy16AGKhU= Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] BCP, AS, something else? (was RE: Comments on draft-ietf-appsawg-greylisting-03) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 07:38:17 -0000 > > -----Original Message----- > > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Murray S. Kucherawy > > Sent: Thursday, February 16, 2012 10:32 PM > > To: apps-discuss@ietf.org > > Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-greylisting-03 > > > > > > An Applicability Statement specifies how, and under what > > > > circumstances, one or more TSs may be applied to support a particular > > > > Internet capability. > > > > > > > >I would say abuse mitigation qualifies as a "capability". > > > > > > Local policy in SMTP provides leeway. It can be used for abuse > > > mitigation. In my opnion, that's not an Internet capability. > > > > Since the work of greylisting involves an altered but still > > interoperable interaction between clients and servers, I believe it > > does qualify. > > > > Do others want to weigh in on this? > I'd like to hear some other WG opinions on this. This document started out > as a BCP, but with some guidance from Pete and a re-read of RFC2026, cited > above, I believe this qualifies as an Applicability Statement, so I changed its > requested status accordingly. (I should have pointed this out when I posted > the revision; sorry about that.) SM disagrees; his is the middle cited text > there. > What's the group's consensus? AS seems like a good fit to me. It's not *the* applicability statment for SMTP by any means, but then again I've never viewed AS-on-foo as having to cover everything about protocol foo. I'd like to see more documents about applicability of various protocols to address various issues; this seems like a good step in that direction. Ned From hsivonen@gmail.com Wed Feb 22 05:25:12 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA00021F879B for ; Wed, 22 Feb 2012 05:25:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0bZ5bavtPYEu for ; Wed, 22 Feb 2012 05:25:08 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id DDDB121F864C for ; Wed, 22 Feb 2012 05:25:07 -0800 (PST) Received: by yhkk25 with SMTP id k25so13155yhk.31 for ; Wed, 22 Feb 2012 05:25:07 -0800 (PST) Received-SPF: pass (google.com: domain of hsivonen@gmail.com designates 10.236.161.232 as permitted sender) client-ip=10.236.161.232; Authentication-Results: mr.google.com; spf=pass (google.com: domain of hsivonen@gmail.com designates 10.236.161.232 as permitted sender) smtp.mail=hsivonen@gmail.com; dkim=pass header.i=hsivonen@gmail.com Received: from mr.google.com ([10.236.161.232]) by 10.236.161.232 with SMTP id w68mr42229558yhk.56.1329917107620 (num_hops = 1); Wed, 22 Feb 2012 05:25:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=WFASOV7LhhwZoaEhwSKborB43ZzImP6bO9FWqxLPsnw=; b=xmB6yI7CD9jfCuuNqXzniOPS0NNH0VNOLkXFzEniX2P10JoN/STsFFO7eixeuSRFxb AGWlF8MrvrxGpM5KXOv6fU20BDHsrFvrNhQyqIQWAc4Gy/o1f+3i9dvIEprExhR8snep z8ORcr2Oj0raYhvW8k1bS3dwm7UZIcs9mg3BQ= MIME-Version: 1.0 Received: by 10.236.161.232 with SMTP id w68mr32951524yhk.56.1329917102032; Wed, 22 Feb 2012 05:25:02 -0800 (PST) Sender: hsivonen@gmail.com Received: by 10.101.170.17 with HTTP; Wed, 22 Feb 2012 05:25:02 -0800 (PST) Date: Wed, 22 Feb 2012 15:25:02 +0200 X-Google-Sender-Auth: 9_1CRRtiXa-kDpUrhRzz36VRe9A Message-ID: From: Henri Sivonen To: apps-discuss@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Anne van Kesteren Subject: [apps-discuss] Feedback about "Update to MIME regarding Charset Parameter Handling in Textual Media Types" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 13:27:26 -0000 In reference to https://svn.tools.ietf.org/svn/wg/appsawg/draft-ietf-appsawg-mime-default-c= harset/latest/draft-ietf-appsawg-mime-default-charset.html First of all, thank you for finally taking on the much-needed update to RFC 2046 rules. Unfortunately, the draft doesn't address the problem the right way in my opinion. Quotes from the draft. > Each subtype of the "text" media type which uses the "charset" parameter = can define its own default value for the "charset" parameter, including abs= ence of any default. Additionally, media types should be able to define circumstances where in-band indicators override the charset parameter even if the charset parameter is present. In particular, media types should be allowed to override the charset parameter if the first two or three bytes of the payload look like an UTF-16 or UTF-8 BOM. See: https://www.w3.org/Bugs/Public/show_bug.cgi?id=3D15359 https://bugzilla.mozilla.org/show_bug.cgi?id=3D716579 https://bugzilla.mozilla.org/show_bug.cgi?id=3D687859 > In order to improve interoperability with deployed agents, "text/*" media= type definitions SHOULD either a) specify that the "charset" parameter is = not used for the defined subtype, because the charset information is transp= orted inside the payload (as in "text/xml") This seems wrong. If the charset parameter is present, it has an effect for text/xml. > or b) require explicit unconditional inclusion of the "charset" parameter= eliminating the need for a default value. This seems na=C3=AFve. Formats need to specify what happens when a charset parameter is missing, since no matter how much the format says it's "required", the party sending data can omit the charset parameter. > In accordance with option (a), above, "text/*" media types that can trans= port charset information inside the corresponding payloads, specifically in= cluding "text/html" and "text/xml", SHOULD NOT specify the use of a "charse= t" parameter, nor any default value, in order to avoid conflicting interpre= tations should the charset parameter value and the value specified in the p= ayload disagree. For backwards compatibility, pretty much every existing text/* type will have to violate this "SHOULD NOT". > New subtypes of the "text" media type, thus, SHOULD NOT define a default = "charset" value. If there is a strong reason to do so despite this advice, = they SHOULD use the "UTF-8" [RFC3629] charset as the default. Seems reasonable. > Specifications of how to specify the "charset" parameter, and what defaul= t value, if any, is used, are subtype-specific, NOT protocol-specific. Seems reasonable. > Protocols that use MIME, therefore, MUST NOT override default charset val= ues for "text/*" media types to be different for their specific protocol. T= he protocol definitions MUST leave that to the subtype definitions. Seems reasonable. > The default charset parameter value for text/plain is unchanged from [RFC= 2046] and remains as "US-ASCII". This is incompatible with reality. Web browsers, for instance, assume a configuration-dependent default (which correlates with browser localization) and may also (depending on configuration which, again, correlates with localization by default) perform a heuristic analysis on the payload. I suggest specifying the following instead of sections 3 and 4 of the draft= : 3. New rules for determining the character encoding for text/* media types Each text/* media type MUST specify an algorithm for establishing the character encoding of the entity body from the entity body (or preferably the first N bytes thereof, preferably with N =3D 1024), the charset parameter and Other Information. Other Information MAY include configuration, an encoding label supplied by the referrer, the previous encoding of an entity body retrieved from the same location or the encoding of the referrer. New text/* media types MUST not use Other Information in the algorithms they specify. New text/* media types SHOULD use the following algorithm: The character encoding is UTF-8. Terminate these steps. 4. Determining the character encoding for text/plain If the first 2 octets of the entity body are 0xFE followed by 0xFF, the character encoding is big-endian UTF-16. Terminate these steps. If the first 2 octets of the entity body are 0xFF followed by 0xFE, the character encoding is little-endian UTF-16. Terminate these steps. If the first 3 octets of the entity body are 0xEF followed by 0xBB followed by 0xBF, the character encoding is UTF-8. Terminate these steps. If the value of the charset parameter is a ASCII case-insensitive[1] match for a label[2] of a supported encoding, the character encoding is the encoding whose label was matched. Terminate these steps. If the entity is being navigate to in a browsing context[3] and the previous document had the same origin[4] as the text/plain entity, the character encoding is the encoding of the referring document. Terminate these steps. (Disclaimer: I'm not 100% sure that this step is in the right order relative to the others.) Optional: If a heuristic detector recognizes the octets of the entity body as being encoding according to an encoding, the character encoding is that encoding. Terminate these steps. This step SHOULD NOT be implemented for locales where it has not been implemented traditionally. If the entity is being loaded into a nested browsing context that has the same origin as the parent browsing context, the encoding is the encoding of the document loaded in the parent browsing context. Terminate these steps. If the entity is being loaded into a browsing context and is being fetched from a location from which an entity has been loaded before and the previous character encoding has been cached, the character encoding is the cached encoding. Terminate these steps. If the entity is being loaded via a non-browsing context mechanism (such as XMLHttpRequest) that defines a fallback encoding, use that encoding. Terminate these steps. Otherwise, the character encoding is a configuration-dependent encoding. The default configuration SHOULD depend on the locale of the user agent according to the table given in step 8 in [5]. Terminate these steps. [1] http://www.whatwg.org/specs/web-apps/current-work/#ascii-case-insensiti= ve [2] http://dvcs.w3.org/hg/encoding/raw-file/tip/Overview.html#concept-encod= ing-label [3] http://www.whatwg.org/specs/web-apps/current-work/#browsing-context [4] http://tools.ietf.org/html/rfc6454 [5] http://www.whatwg.org/specs/web-apps/current-work/#determining-the-char= acter-encoding --=20 Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/ From peter.wolanin@acquia.com Tue Feb 21 17:34:18 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7841821E8016 for ; Tue, 21 Feb 2012 17:34:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.827 X-Spam-Level: X-Spam-Status: No, score=-4.827 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MANGLED_LIST=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id alSaIJQ+HoEE for ; Tue, 21 Feb 2012 17:34:17 -0800 (PST) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with SMTP id ED00621E8023 for ; Tue, 21 Feb 2012 17:34:09 -0800 (PST) Received: from mail-lpp01m010-f42.google.com ([209.85.215.42]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKT0RGEe+dygJ9FPROLPjDaB9e9hYM2H+i@postini.com; Tue, 21 Feb 2012 17:34:10 PST Received: by mail-lpp01m010-f42.google.com with SMTP id k11so19310492lag.1 for ; Tue, 21 Feb 2012 17:34:09 -0800 (PST) Received-SPF: pass (google.com: domain of peter.wolanin@acquia.com designates 10.152.134.200 as permitted sender) client-ip=10.152.134.200; Authentication-Results: mr.google.com; spf=pass (google.com: domain of peter.wolanin@acquia.com designates 10.152.134.200 as permitted sender) smtp.mail=peter.wolanin@acquia.com Received: from mr.google.com ([10.152.134.200]) by 10.152.134.200 with SMTP id pm8mr21138738lab.34.1329874449001 (num_hops = 1); Tue, 21 Feb 2012 17:34:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.152.134.200 with SMTP id pm8mr17696933lab.34.1329874448840; Tue, 21 Feb 2012 17:34:08 -0800 (PST) Received: by 10.152.8.229 with HTTP; Tue, 21 Feb 2012 17:34:08 -0800 (PST) In-Reply-To: <4F412E76.6080408@lodderstedt.net> References: <6.2.5.6.2.20120123134319.0a76c338@resistor.net> <4F412E76.6080408@lodderstedt.net> Date: Tue, 21 Feb 2012 20:34:08 -0500 Message-ID: From: Peter Wolanin To: Torsten Lodderstedt Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmlcD0GbwMFpzMOjFtKC0WqLRe826QNW0H6rxZAEAhcU516XUBMLGMNB9T7TR9hL+cmmxMQ X-Mailman-Approved-At: Wed, 22 Feb 2012 08:01:37 -0800 Cc: S Moonesamy , apps-discuss@ietf.org, oauth@ietf.org Subject: Re: [apps-discuss] [OAUTH-WG] Apps Area review of draft-ietf-oauth-v2-threatmodel-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 01:34:18 -0000 Looking at this document, I don't see much discussion of the risk due to a tampered response except possibly 5.1.2. For example, injection of spam or phishing links into search results. Given the known issues with CA issuers, and the fact that some transactions may be carried out over non-SSL channels, can you include some discussion of the use of HMAC signing of the response body or other tactics for assuring the client that they received the genuine response from the server? -Peter On Sun, Feb 19, 2012 at 12:16 PM, Torsten Lodderstedt wrote: > > Hi Tim, > > I just submitted the revised version of the OAuth 2.0 security document (= http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-02). This revisi= on should address the issues you raised in your AppsDir review. We especial= ly removed all normative language from the document. > > We took the liberty to leave the back references in Section 5. We conside= r this back references to section 4 a valuable information for implementors= since they justify the particular countermeasure. All to often security co= nsiderations are given without the corresponding rationales. And without a = justification, the "unconvinced" implementor may tend to ignore or underest= imate the respective controls. > > > regards, > Torsten. > > Am 23.01.2012 22:47, schrieb S Moonesamy: >> >> The following is the AppsDir review performed by Tim Bray. =C2=A0It woul= d be appreciated if a reply is sent to Tim Bray with a copy to the apps-dis= cuss mailing list. >> >> >> I have been selected as the Applications Area Directorate reviewer for >> this draft (for background on appsdir, please see >> http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorat= e). >> >> Please resolve these comments along with any other Last Call comments >> you may receive. Please wait for direction from your document shepherd >> or AD before posting a new version of the draft. >> >> Document: draft-ietf-oauth-v2-threatmodel-01 >> Title: =C2=A0OAuth 2.0 Threat Model and Security Considerations >> Reviewer: Tim Bray >> Review Date: =C2=A0Jan 23, 2012 >> >> Summary: This needs some more editorial work, but is basically sound. >> It's not clear, though, whether it wants to be an Informational RFC or >> not; the use of RFC2119 language needs special attention. =C2=A0I think = a >> few of the "minor issues" are worthy of a little bit more work in >> another draft. >> >> Major Issues: >> >> The use of 2119 MUST/SHOULD/etc doesn't seem fully thought through. =C2= =A0I >> normally wouldn't expect a "threat model" to include normative text. >> The basic idea would be to say "Here is an enumeration of the threats, >> and here are the tools available to OAUTH2 implementors to meet them." >> =C2=A0I was impressed by the enumeration, which seemed very complete and >> well thought through. But the usage of 2119, which makes statements >> normative, seems inconsistent. =C2=A0I can think of 2 ways to address th= is: >> >> 1. Remove all the 2119 words, so this document isn't normative, and >> publish it as an Informational RFC >> 2. Go through and clean up the 2119 language so it's used >> consistently; then this becomes a normative document. >> >> This is going to affect the references to this document from other >> I-Ds in the OAuth suite, which are currently in last call. >> >> Here are all the section-numbered notes enumerating my issues around >> 2119, as I encountered them: >> >> Section 2.3, I'm a little confused about the use of RFC2119 MAY in a >> threat analysis. =C2=A0When you say "The following data elements MAY be >> stored or accessible...", Is this saying that "The OAuth2 RFC says >> that the following data elements MAY be..." or is it saying something >> else. I don't think there's anything seriously wrong here, but a bit >> more explanation might be in order. =C2=A0I note a comparative absence o= f >> 2119-ese in section 5 describing countermeasures, where one would >> expect to find it. >> Also in 4.3.1, first bullet point, there's "Authorization servers MUST..= ." >> Also in: 4.4.1.1, 4.4.1.6, 4.4.1.12, 4.6.*, 5.1.4.1.5, 5.1.5.11 >> Related: "SHALL"?! in 4.6.3 >> Adding to the concern, there is use of lower-case "must"; note 2nd & >> 3rd bullet points in 4.4.3, which use "MUST" and "must" respectively. >> >> Minor Issues: >> >> 4.1.2 first attack: It says "An attack may obtain the refresh tokens >> issued to a web server client." This needs to be clearer... a "Web >> server client" can be a browser or a native app. =C2=A0Do you mean, "the >> refresh tokens issued by the web server to multiple clients?" >> >> 4.1.2 last attack. =C2=A0In the case where a device is cloned, wouldn't >> "Utilize device lock to prevent unauthorized device access" still be a >> countermeasure? =C2=A0In many devices, such cloning would carry along th= e >> user's device-lock settings. >> >> 4.4.1.4 2nd bullet. =C2=A0The explanation of why this wouldn't work for >> native clients wasn't comprehensible to me. =C2=A0I'm suspicious of any >> such claims because I can emulate most things a browser can do in a >> mobile client. =C2=A0Perhaps this would be obvious to someone who is an >> OAuth2 implementor. >> >> 4.4.1.9 I think where it says "iFrame" it might mean "WebView", i.e. a >> Web Browser control embedded in the native app. =C2=A0If that's not what= it >> means, I don't understand what it's saying. =C2=A0If this is true, then = the >> second bullet point is probably wrong. >> >> 4.6.6 1st bullet. =C2=A0I'm not convinced that the Cache-Control header >> will *ensure* that a client protects information properly. =C2=A0Should = say >> something like "minimize the risk that authenticated content is not >> protected" >> >> 5.* The enumeration, for some but not all of the countermeasures in >> this section, of the threats against which this is a countermeasure, >> reduces readability and, unless it's generated automatically from the >> underlying source, is redundant information, which is unlikely to be >> consistent between sections 4 and 5, and adds difficulty to >> maintenance of this document without adding much value. =C2=A0I'd just w= ipe >> all these bullet lists out. =C2=A0If it's generated automatically it's l= ess >> damaging, but still reduces readability. =C2=A0In the current draft, thi= s >> is there for some countermeasures but absent for others. =C2=A0Another g= ood >> reason to just take it out. >> >> 5.2.2.5 Device identifiers are very tricky. =C2=A0It's correct that IMEI= is >> not adequate, but there are ways to do it without SMS. =C2=A0For more, s= ee >> http://android-developers.blogspot.com/2011/03/identifying-app-installat= ions.html >> >> 5.3.4 Surely a little more could be said about device lock. =C2=A0On a >> typical modern phone, "device lock" options include PINs, passwords, >> "face recognition" and so on. =C2=A0These are *not* equal in their level= of >> security they provide. >> >> Nits: >> >> Formatting is lousy. =C2=A0There are notations, including ** and _whatev= er_ >> that I'm not familiar with in the RFC context. >> >> Section 1.0: s/in-built into/built into/ >> 2.1, last bullet point: "An example could by a..." s/by/be/ >> 2.2, 1st bullet point s/eaves drop/eavesdrop/ >> 2.3, 1st para, s/treat/threat/ >> 2.3.1, last bullet, "per authorization process". =C2=A0Adjectival phrase= s >> should be hyphenated: "per-authorization process" >> 2.3.3, last bullet, ditto >> 3.1, 1st para, "all kinds of tokens" should be "many kinds of tokens" >> 3.1, 2nd para, should be ; not , after "within the authorization server" >> =C2=A0 =C2=A0 =C2=A0s/protected/protect/ >> =C2=A0 =C2=A0 =C2=A0s/different system/different systems/ >> 3.4 1st para, s/intermediary/intermediate/ >> =C2=A0 =C2=A0 =C2=A0list item 1. s/short-living/short-lived/ >> 3.5 s/malicious client/malicious clients/ >> 3.7 top of page 12, what is the underscore notation _client_id_ mean? >> I'm not familiar with this in the RFC context. >> =C2=A01st bullet point: s/token/token's/ >> =C2=A02nd bullet point, multiple issues, 1st sentence should be " the >> initial authorization and issuance of a token by an end-user >> =C2=A0 =C2=A0 to a particular client, and subsequent requests by this cl= ient to >> =C2=A0 =C2=A0 obtain tokens without user consent (automatic processing o= f repeated >> =C2=A0 =C2=A0 authorization) >> =C2=A0halfway down page 13, s/insures/ensures/ >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 s/validates the clients/valida= tes the client's/ >> 4. first sentence, s/this sections/this section/ >> 4.1.2 first para, the last sentence is confusing. How about: "Before >> enumerating the threats, here are some generally applicable >> countermeasures:" >> 4.2.4 2nd bullet s/could not be/can not be/ >> 4.3.3 1st bullet, capitalized phrase "Confidentiality of Requests" - I >> assume that's supposed to be a hyperlink to one of the 5.* sections? >> 4.4.1.1 last bullet, s/referee/referrer/ - also, should note that the >> referrer header may contain an Authorization code in a ?a=3Db style >> argument >> 4.4.1.2 first bullet, "can be employed" is inconsistent with style of >> rest of doc >> 4.4.1.3 first 2 bullets have un-labeled links. >> 4.4.1.4 1st bullet s/authentication/authenticate/ >> 4.4.1.4 2nd bullet s/mean/means/ >> 4.4.1.7 2nd bullet s/tokens/token's/ >> 4.4.1.10, 2nd para, s/requisiete/requisite/ s/embbed/embed/ >> 4.4.1.10, 3rd bullet, s/aibility/ability/ >> 4.4.1.10, toward bottom of page 30, s/e.t.c./etc./ >> 4.4.1.12 I think the href to semicomplete.com needs to be turned into >> an IETF-style reference >> 4.4.2 " since HTTP user agents do not send fragments server requests." >> What you mean to say is "Since HTTP user agents do not send the >> fragment part of URIs to HTTP servers." >> 4.4.2.2 s/browser/browser's/ >> 5.1.4.1.3 s/consider to not store/refrain from storing/ >> 5.* s/may consider to $(verb)/may consider $(verb)ing/ >> 5.1.6 Needs some sort of sentence structure >> 5.3.2 Needs some sort of sentence structure; or is this intended just >> to be a title, with 5.3.3 etc nested under it? >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth -- Peter M. Wolanin, Ph.D. =C2=A0 =C2=A0 =C2=A0: Momentum Specialist,=C2=A0 Ac= quia. Inc. peter.wolanin@acquia.com : 781-313-8322 "Get a free, hosted Drupal 7 site: http://www.drupalgardens.com" From mark.mcgloin@ie.ibm.com Wed Feb 22 06:57:41 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E08D721F87E0 for ; Wed, 22 Feb 2012 06:57:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.222 X-Spam-Level: X-Spam-Status: No, score=-1.222 tagged_above=-999 required=5 tests=[AWL=-0.923, BAYES_00=-2.599, MANGLED_LIST=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78KlSud3-mVb for ; Wed, 22 Feb 2012 06:57:37 -0800 (PST) Received: from e06smtp16.uk.ibm.com (e06smtp16.uk.ibm.com [195.75.94.112]) by ietfa.amsl.com (Postfix) with ESMTP id C369621F87DC for ; Wed, 22 Feb 2012 06:57:36 -0800 (PST) Received: from /spool/local by e06smtp16.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 22 Feb 2012 14:57:34 -0000 Received: from d06nrmr1806.portsmouth.uk.ibm.com (9.149.39.193) by e06smtp16.uk.ibm.com (192.168.101.146) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 22 Feb 2012 14:57:03 -0000 Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by d06nrmr1806.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q1MEv2Sw2093300; Wed, 22 Feb 2012 14:57:02 GMT Received: from d06av04.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q1MEv26V016565; Wed, 22 Feb 2012 07:57:02 -0700 Received: from d06ml091.portsmouth.uk.ibm.com (d06ml091.portsmouth.uk.ibm.com [9.149.104.170]) by d06av04.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q1MEv2gJ016561; Wed, 22 Feb 2012 07:57:02 -0700 In-Reply-To: References: <6.2.5.6.2.20120123134319.0a76c338@resistor.net> <4F412E76.6080408@lodderstedt.net> X-KeepSent: FE613B8D:4E554796-802579AC:00506D73; type=4; name=$KeepSent To: Peter Wolanin X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 Message-ID: From: Mark Mcgloin Date: Wed, 22 Feb 2012 14:56:56 +0000 X-MIMETrack: Serialize by Router on D06ML091/06/M/IBM(Release 8.5.2FP1 ZX852FP1HF12|September 28, 2011) at 22/02/2012 14:56:56 MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable x-cbid: 12022214-3548-0000-0000-0000011EAAA2 X-Mailman-Approved-At: Wed, 22 Feb 2012 08:01:37 -0800 Cc: oauth-bounces@ietf.org, apps-discuss@ietf.org, S Moonesamy , Torsten Lodderstedt , oauth@ietf.org Subject: Re: [apps-discuss] [OAUTH-WG] Apps Area review of draft-ietf-oauth-v2-threatmodel-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 14:57:42 -0000 Hi Peter The core oauth spec states that TLS MUST be used wherever tokens or passwords are being transmitted, except for the redirection_url but it = does recommend it use TLS in section 3.1.2.1 and explicitly states why. Regards Mark oauth-bounces@ietf.org wrote on 22/02/2012 01:34:08: > From: > > Peter Wolanin > > To: > > Torsten Lodderstedt > > Cc: > > Tim Bray , S Moonesamy , > apps-discuss@ietf.org, oauth@ietf.org > > Date: > > 22/02/2012 01:34 > > Subject: > > Re: [OAUTH-WG] [apps-discuss] Apps Area review of draft-ietf-oauth- > v2-threatmodel-01 > > Sent by: > > oauth-bounces@ietf.org > > Looking at this document, I don't see much discussion of the risk due= > to a tampered response except possibly 5.1.2. For example, injection= > of spam or phishing links into search results. > > Given the known issues with CA issuers, and the fact that some > transactions may be carried out over non-SSL channels, can you includ= e > some discussion of the use of HMAC signing of the response body or > other tactics for assuring the client that they received the genuine > response from the server? > > -Peter > > > On Sun, Feb 19, 2012 at 12:16 PM, Torsten Lodderstedt > wrote: > > > > Hi Tim, > > > > I just submitted the revised version of the OAuth 2.0 security docu= ment ( > http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-02). This > revision should address the issues you raised in your AppsDir > review. We especially removed all normative language from the documen= t. > > > > We took the liberty to leave the back references in Section 5. We > consider this back references to section 4 a valuable information > for implementors since they justify the particular countermeasure. > All to often security considerations are given without the > corresponding rationales. And without a justification, the > "unconvinced" implementor may tend to ignore or underestimate the > respective controls. > > > > > > regards, > > Torsten. > > > > Am 23.01.2012 22:47, schrieb S Moonesamy: > >> > >> The following is the AppsDir review performed by Tim Bray. =A0It > would be appreciated if a reply is sent to Tim Bray with a copy to > the apps-discuss mailing list. > >> > >> > >> I have been selected as the Applications Area Directorate reviewer= for > >> this draft (for background on appsdir, please see > >> http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectora= te). > >> > >> Please resolve these comments along with any other Last Call comme= nts > >> you may receive. Please wait for direction from your document shep= herd > >> or AD before posting a new version of the draft. > >> > >> Document: draft-ietf-oauth-v2-threatmodel-01 > >> Title: =A0OAuth 2.0 Threat Model and Security Considerations > >> Reviewer: Tim Bray > >> Review Date: =A0Jan 23, 2012 > >> > >> Summary: This needs some more editorial work, but is basically sou= nd. > >> It's not clear, though, whether it wants to be an Informational RF= C or > >> not; the use of RFC2119 language needs special attention. =A0I thi= nk a > >> few of the "minor issues" are worthy of a little bit more work in > >> another draft. > >> > >> Major Issues: > >> > >> The use of 2119 MUST/SHOULD/etc doesn't seem fully thought through= . =A0I > >> normally wouldn't expect a "threat model" to include normative tex= t. > >> The basic idea would be to say "Here is an enumeration of the thre= ats, > >> and here are the tools available to OAUTH2 implementors to meet th= em." > >> =A0I was impressed by the enumeration, which seemed very complete = and > >> well thought through. But the usage of 2119, which makes statement= s > >> normative, seems inconsistent. =A0I can think of 2 ways to address= this: > >> > >> 1. Remove all the 2119 words, so this document isn't normative, an= d > >> publish it as an Informational RFC > >> 2. Go through and clean up the 2119 language so it's used > >> consistently; then this becomes a normative document. > >> > >> This is going to affect the references to this document from other= > >> I-Ds in the OAuth suite, which are currently in last call. > >> > >> Here are all the section-numbered notes enumerating my issues arou= nd > >> 2119, as I encountered them: > >> > >> Section 2.3, I'm a little confused about the use of RFC2119 MAY in= a > >> threat analysis. =A0When you say "The following data elements MAY = be > >> stored or accessible...", Is this saying that "The OAuth2 RFC says= > >> that the following data elements MAY be..." or is it saying someth= ing > >> else. I don't think there's anything seriously wrong here, but a b= it > >> more explanation might be in order. =A0I note a comparative absenc= e of > >> 2119-ese in section 5 describing countermeasures, where one would > >> expect to find it. > >> Also in 4.3.1, first bullet point, there's "Authorization servers MUST..." > >> Also in: 4.4.1.1, 4.4.1.6, 4.4.1.12, 4.6.*, 5.1.4.1.5, 5.1.5.11 > >> Related: "SHALL"?! in 4.6.3 > >> Adding to the concern, there is use of lower-case "must"; note 2nd= & > >> 3rd bullet points in 4.4.3, which use "MUST" and "must" respective= ly. > >> > >> Minor Issues: > >> > >> 4.1.2 first attack: It says "An attack may obtain the refresh toke= ns > >> issued to a web server client." This needs to be clearer... a "Web= > >> server client" can be a browser or a native app. =A0Do you mean, "= the > >> refresh tokens issued by the web server to multiple clients?" > >> > >> 4.1.2 last attack. =A0In the case where a device is cloned, wouldn= 't > >> "Utilize device lock to prevent unauthorized device access" still = be a > >> countermeasure? =A0In many devices, such cloning would carry along= the > >> user's device-lock settings. > >> > >> 4.4.1.4 2nd bullet. =A0The explanation of why this wouldn't work f= or > >> native clients wasn't comprehensible to me. =A0I'm suspicious of a= ny > >> such claims because I can emulate most things a browser can do in = a > >> mobile client. =A0Perhaps this would be obvious to someone who is = an > >> OAuth2 implementor. > >> > >> 4.4.1.9 I think where it says "iFrame" it might mean "WebView", i.= e. a > >> Web Browser control embedded in the native app. =A0If that's not w= hat it > >> means, I don't understand what it's saying. =A0If this is true, th= en the > >> second bullet point is probably wrong. > >> > >> 4.6.6 1st bullet. =A0I'm not convinced that the Cache-Control head= er > >> will *ensure* that a client protects information properly. =A0Shou= ld say > >> something like "minimize the risk that authenticated content is no= t > >> protected" > >> > >> 5.* The enumeration, for some but not all of the countermeasures i= n > >> this section, of the threats against which this is a countermeasur= e, > >> reduces readability and, unless it's generated automatically from = the > >> underlying source, is redundant information, which is unlikely to = be > >> consistent between sections 4 and 5, and adds difficulty to > >> maintenance of this document without adding much value. =A0I'd jus= t wipe > >> all these bullet lists out. =A0If it's generated automatically it'= s less > >> damaging, but still reduces readability. =A0In the current draft, = this > >> is there for some countermeasures but absent for others. =A0Anothe= r good > >> reason to just take it out. > >> > >> 5.2.2.5 Device identifiers are very tricky. =A0It's correct that I= MEI is > >> not adequate, but there are ways to do it without SMS. =A0For more= , see > >> http://android-developers.blogspot.com/2011/03/identifying-app- > installations.html > >> > >> 5.3.4 Surely a little more could be said about device lock. =A0On = a > >> typical modern phone, "device lock" options include PINs, password= s, > >> "face recognition" and so on. =A0These are *not* equal in their le= vel of > >> security they provide. > >> > >> Nits: > >> > >> Formatting is lousy. =A0There are notations, including ** and _wha= tever_ > >> that I'm not familiar with in the RFC context. > >> > >> Section 1.0: s/in-built into/built into/ > >> 2.1, last bullet point: "An example could by a..." s/by/be/ > >> 2.2, 1st bullet point s/eaves drop/eavesdrop/ > >> 2.3, 1st para, s/treat/threat/ > >> 2.3.1, last bullet, "per authorization process". =A0Adjectival phr= ases > >> should be hyphenated: "per-authorization process" > >> 2.3.3, last bullet, ditto > >> 3.1, 1st para, "all kinds of tokens" should be "many kinds of toke= ns" > >> 3.1, 2nd para, should be ; not , after "within the authorization server" > >> =A0 =A0 =A0s/protected/protect/ > >> =A0 =A0 =A0s/different system/different systems/ > >> 3.4 1st para, s/intermediary/intermediate/ > >> =A0 =A0 =A0list item 1. s/short-living/short-lived/ > >> 3.5 s/malicious client/malicious clients/ > >> 3.7 top of page 12, what is the underscore notation _client_id_ me= an? > >> I'm not familiar with this in the RFC context. > >> =A01st bullet point: s/token/token's/ > >> =A02nd bullet point, multiple issues, 1st sentence should be " the= > >> initial authorization and issuance of a token by an end-user > >> =A0 =A0 to a particular client, and subsequent requests by this cl= ient to > >> =A0 =A0 obtain tokens without user consent (automatic processing o= f repeated > >> =A0 =A0 authorization) > >> =A0halfway down page 13, s/insures/ensures/ > >> =A0 =A0 =A0 =A0 =A0 =A0 s/validates the clients/validates the clie= nt's/ > >> 4. first sentence, s/this sections/this section/ > >> 4.1.2 first para, the last sentence is confusing. How about: "Befo= re > >> enumerating the threats, here are some generally applicable > >> countermeasures:" > >> 4.2.4 2nd bullet s/could not be/can not be/ > >> 4.3.3 1st bullet, capitalized phrase "Confidentiality of Requests"= - I > >> assume that's supposed to be a hyperlink to one of the 5.* section= s? > >> 4.4.1.1 last bullet, s/referee/referrer/ - also, should note that = the > >> referrer header may contain an Authorization code in a ?a=3Db styl= e > >> argument > >> 4.4.1.2 first bullet, "can be employed" is inconsistent with style= of > >> rest of doc > >> 4.4.1.3 first 2 bullets have un-labeled links. > >> 4.4.1.4 1st bullet s/authentication/authenticate/ > >> 4.4.1.4 2nd bullet s/mean/means/ > >> 4.4.1.7 2nd bullet s/tokens/token's/ > >> 4.4.1.10, 2nd para, s/requisiete/requisite/ s/embbed/embed/ > >> 4.4.1.10, 3rd bullet, s/aibility/ability/ > >> 4.4.1.10, toward bottom of page 30, s/e.t.c./etc./ > >> 4.4.1.12 I think the href to semicomplete.com needs to be turned i= nto > >> an IETF-style reference > >> 4.4.2 " since HTTP user agents do not send fragments server reques= ts." > >> What you mean to say is "Since HTTP user agents do not send the > >> fragment part of URIs to HTTP servers." > >> 4.4.2.2 s/browser/browser's/ > >> 5.1.4.1.3 s/consider to not store/refrain from storing/ > >> 5.* s/may consider to $(verb)/may consider $(verb)ing/ > >> 5.1.6 Needs some sort of sentence structure > >> 5.3.2 Needs some sort of sentence structure; or is this intended j= ust > >> to be a title, with 5.3.3 etc nested under it? > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > -- > Peter M. Wolanin, Ph.D. =A0 =A0 =A0: Momentum Specialist,=A0 Acquia. = Inc. > peter.wolanin@acquia.com : 781-313-8322 > > "Get a free, hosted Drupal 7 site: http://www.drupalgardens.com" > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth= From internet-drafts@ietf.org Wed Feb 22 10:45:58 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FC9421F85B5; Wed, 22 Feb 2012 10:45:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1cKpKe-kK+vA; Wed, 22 Feb 2012 10:45:57 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4556021F8593; Wed, 22 Feb 2012 10:45:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p2 Message-ID: <20120222184536.6635.42117.idtracker@ietfa.amsl.com> Date: Wed, 22 Feb 2012 10:45:36 -0800 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-greylisting-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 18:45:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Worki= ng Group of the IETF. Title : Email Greylisting: An Applicability Statement for SMTP Author(s) : Murray S. Kucherawy D. Crocker Filename : draft-ietf-appsawg-greylisting-05.txt Pages : 16 Date : 2012-02-22 This memo describes the art of email greylisting, the practice of providing temporarily degraded service to unknown email clients as an anti-abuse mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-appsawg-greylisting-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-appsawg-greylisting-05.txt From stpeter@stpeter.im Wed Feb 22 13:55:56 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF74C21E8046; Wed, 22 Feb 2012 13:55:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.542 X-Spam-Level: X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=-0.243, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Th8Ue6hzh1Ak; Wed, 22 Feb 2012 13:55:56 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 0184C21E8039; Wed, 22 Feb 2012 13:55:56 -0800 (PST) Received: from squire.local (unknown [64.101.72.114]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A6C5940058; Wed, 22 Feb 2012 15:07:10 -0700 (MST) Message-ID: <4F456465.6010509@stpeter.im> Date: Wed, 22 Feb 2012 14:55:49 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Robert Sparks , =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xycw==?= =?UTF-8?B?dCI=?= , Hannes Tschofenig , hgs+ecrit@cs.columbia.edu, mlinsner@cisco.com, ecrit@ietf.org, "apps-discuss@ietf.org" References: <1DE839B2-11F0-4DBF-9C3A-4CB1073B91A9@gmx.net> <4F1DE84A.9000600@nostrum.com> In-Reply-To: <4F1DE84A.9000600@nostrum.com> X-Enigmail-Version: 1.3.5 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [apps-discuss] review of draft-ietf-ecrit-lost-sync-12 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 21:55:56 -0000 Robert Sparks asked me to think about the namespaces issue... > -------- Original Message -------- Subject: Re: review of > draft-ietf-ecrit-lost-sync-12 Date: Fri, 13 Jan 2012 11:17:10 +0200 > From: Hannes Tschofenig To: "Martin J. > Dürst" CC: Hannes Tschofenig > , Henning Schulzrinne > , Marc Linsner , > Robert Sparks , "apps-review@ietf.org" > , ecrit@ietf.org > > >> From Martin: > >> Namespaces: It is overkill to define new namespaces for each spec. >> It's a well-known secret in the XML community that it's easily >> possible to add a number of new elements to an existing namespace. >> This would be very appropriate in this case, because the number of >> reused elements and attributes is quite large, and the number of >> new elements is low. This would simplify most of the examples. > > I guess you refer to the namespace registration in the IANA > consideration section, namely urn:ietf:params:xml:ns:lostsync1 > > In the RAI area we have (to my knowledge) always created new > namespaces for new schemas. But I am pleased to hear that this is not > needed. > > Could you explain what we should be doing instead? I don't see a problem with defining a new namespace for each iteration of an XML format (lostsync1, lostsync2, etc.), because I don't think there's a general case here -- backward compatibility can depend on the community of interest. One community might be doing strict schema checking, so that any new elements or attributes would be problematic. By contrast, another community might be more lax in its processing because they specify that applications must ignore unknown elements and attributes, even those qualified by an existing namespace. Just my centigram of silver. :) Peter -- Peter Saint-Andre https://stpeter.im/ From ben.vvalk@gmail.com Wed Feb 22 17:37:56 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3DEA21E8013 for ; Wed, 22 Feb 2012 17:37:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.887 X-Spam-Level: X-Spam-Status: No, score=-3.887 tagged_above=-999 required=5 tests=[AWL=-0.289, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CqdWwEvkTuB4 for ; Wed, 22 Feb 2012 17:37:55 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id ABE9921F8503 for ; Wed, 22 Feb 2012 17:37:39 -0800 (PST) Received: by iagf6 with SMTP id f6so954684iag.31 for ; Wed, 22 Feb 2012 17:37:33 -0800 (PST) Received-SPF: pass (google.com: domain of ben.vvalk@gmail.com designates 10.43.134.199 as permitted sender) client-ip=10.43.134.199; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ben.vvalk@gmail.com designates 10.43.134.199 as permitted sender) smtp.mail=ben.vvalk@gmail.com; dkim=pass header.i=ben.vvalk@gmail.com Received: from mr.google.com ([10.43.134.199]) by 10.43.134.199 with SMTP id id7mr34955440icc.21.1329961053975 (num_hops = 1); Wed, 22 Feb 2012 17:37:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=iT4MNGyL86fs/v2VCAHIeeNa7G7wAj0Crl8aK6PFtyY=; b=wiONSV928cGXWqosMxeQTPxvUpO/08oADNtNZxYX2bkVz5q6ZkJhL65yiciuMp9+YK v+qWlDAd+39+1TVm6BGOmAjkrw2Bjx9lXKKmtLneml3nnm2lB7T9hkZQZugM3/3Wy/8+ pXZQYpXrSDJcTMWfC9dSvQ5ZfV4vs/ze63zOk= MIME-Version: 1.0 Received: by 10.43.134.199 with SMTP id id7mr28121160icc.21.1329961053916; Wed, 22 Feb 2012 17:37:33 -0800 (PST) Received: by 10.42.137.1 with HTTP; Wed, 22 Feb 2012 17:37:33 -0800 (PST) Date: Wed, 22 Feb 2012 17:37:33 -0800 Message-ID: From: Ben Vandervalk To: apps-discuss@ietf.org Content-Type: multipart/alternative; boundary=20cf307f369e2f0eda04b997b08f Subject: [apps-discuss] request for review: draft-bvandervalk-sadi-00.txt (individual submission) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 01:37:56 -0000 --20cf307f369e2f0eda04b997b08f Content-Type: text/plain; charset=ISO-8859-1 Hi all, I have recently submitted an I-D (as an individual) regarding RDF/OWL-based web services called SADI (Semantic Automated Discovery and Integration). My intent is to put this I-D on the standards track, and I have been advised that the first step is to solicit comments/reviews on this list, in order to guage interest. There are currently three implementations of SADI in Java, Perl, and Python, which are available from http://sadi.googlecode.com/. The Java and Perl implementations were created by the authors, whereas the Python implementation was created independently by Jim McCusker of MSU. The Python implementation does not yet implement all of the features in the draft, but we think it is likely that Jim will expand his implementation in time, or that other parties will create additional implementations of SADI. I am unfamiliar with IETF procedures regarding individual submissions and would appreciate any advice in that regard as well. Thanks for your consideration! ====== A New Internet-Draft is available from the on-line Internet-Drafts directories. This is an Individual Submission. Title : SADI: Semantic Automated Discovery and Integration Author(s) : Ben Vandervalk, E. Luke McCarthy, Mark D. Wilkinson Filename : draft-bvandervalk-sadi-00.txt Pages : 31 Date : 2012-01-31 This document describes Semantic Automated Discovery and Integration (SADI), a set of best practices for implementing stateless web services that consume RDF data as input and generate RDF data as output. The goal of SADI is to establish conventions that will enable a much higher level of interoperability between web services from independent providers than is currently possible under the widespread use of WSDL/XML and RESTful services. Under SADI, interoperability depends on the shared use of predicate vocabularies, rather than the shared use of particular XML schemas, JSON structures, or ad hoc data formats. Through the use of OWL to describe service input and output datatypes, SADI enables: i) automated discovery of services that provide data or computations of interest, and ii) automated matchmaking between local data and available services. By iterative application of the former two capabilities, SADI enables semi-automated construction of arbitrarily complex workflows across independent service providers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bvandervalk-sadi-00.txt -- Ben Vandervalk Wilkinson Lab, University of British Columbia --20cf307f369e2f0eda04b997b08f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

I have recently submitted an I-D (as an individual) regardin= g RDF/OWL-based web services called SADI (Semantic Automated Discovery and = Integration).

My intent is to put this I-D on the standards track, a= nd I have been advised that the first step is to solicit comments/reviews o= n this list, in order to guage interest.

There are currently three implementations of SADI in Java, Perl, and Py= thon, which are available from http= ://sadi.googlecode.com/. The Java and Perl implementations were created= by the authors, whereas the Python implementation was created independentl= y by Jim McCusker of MSU. The Python implementation does not yet implement = all of the features in the draft, but we think it is likely that Jim will e= xpand his implementation in time, or that other parties will create additio= nal implementations of SADI.

I am unfamiliar with IETF procedures regarding individual submissions a= nd would appreciate any advice in that regard as well.=A0

Thanks fo= r your consideration!

=3D=3D=3D=3D=3D=3D

A New Internet-Draft= is available from the on-line Internet-Drafts directories. This is an Indi= vidual Submission.

=A0=A0=A0=A0=A0=A0 Title : SADI: Semantic Automated Discovery= and Integration=A0=A0=A0=A0=A0=A0
=A0=A0=A0=A0=A0=A0 Author(s) := Ben Vandervalk, E. Luke McCarthy, Mark D. Wilkinson
=A0=A0=A0=A0=A0=A0 = Filename : draft-bvandervalk-sadi-00.txt
=A0=A0=A0=A0=A0=A0 Pages : 31
=A0=A0=A0=A0=A0=A0 Date = : 2012-01-31

This document describes Semantic Automated Discovery= and Integration
(SADI), a set of best practices for implementing statel= ess web
services that consume RDF data as input and generate RDF data as=
output. The goal of SADI is to establish conventions that will
enable a= much higher level of interoperability between web services
from indepen= dent providers than is currently possible under the
widespread use of WS= DL/XML and RESTful services. Under SADI,
interoperability depends on the shared use of predicate vocabularies,
ra= ther than the shared use of particular XML schemas, JSON
structures, or = ad hoc data formats. Through the use of OWL to
describe service input a= nd output datatypes, SADI enables: i)
automated discovery of services that provide data or computations of
int= erest, and ii) automated matchmaking between local data and
available se= rvices. By iterative application of the former two
capabilities, SADI e= nables semi-automated construction of arbitrarily
complex workflows across independent service providers.

A URL for th= is Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-bvand= ervalk-sadi-00.txt


-- Ben Vandervalk
Wilkinson Lab, University of British Col= umbia







--20cf307f369e2f0eda04b997b08f-- From tbray@textuality.com Wed Feb 22 18:03:32 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5826B11E8073 for ; Wed, 22 Feb 2012 18:03:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IWZo9uYB3TaT for ; Wed, 22 Feb 2012 18:03:31 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7F1D511E8072 for ; Wed, 22 Feb 2012 18:03:31 -0800 (PST) Received: by obbwd15 with SMTP id wd15so943144obb.31 for ; Wed, 22 Feb 2012 18:03:31 -0800 (PST) Received-SPF: pass (google.com: domain of tbray@textuality.com designates 10.60.29.34 as permitted sender) client-ip=10.60.29.34; Authentication-Results: mr.google.com; spf=pass (google.com: domain of tbray@textuality.com designates 10.60.29.34 as permitted sender) smtp.mail=tbray@textuality.com Received: from mr.google.com ([10.60.29.34]) by 10.60.29.34 with SMTP id g2mr15095274oeh.72.1329962611089 (num_hops = 1); Wed, 22 Feb 2012 18:03:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.60.29.34 with SMTP id g2mr12922479oeh.72.1329962610966; Wed, 22 Feb 2012 18:03:30 -0800 (PST) Received: by 10.182.137.69 with HTTP; Wed, 22 Feb 2012 18:03:30 -0800 (PST) X-Originating-IP: [24.84.235.32] In-Reply-To: References: Date: Wed, 22 Feb 2012 18:03:30 -0800 Message-ID: From: Tim Bray To: Ben Vandervalk Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkixSdA8tswdxY5hPASgUyoaVNw/YawOC2WlfSASim18vfOuyDB001jjFKcKsGfnNh+kOsZ Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] request for review: draft-bvandervalk-sadi-00.txt (individual submission) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 02:03:32 -0000 My feeling is that this draft would not be a good investment of IETF time. The adoption RDF and OWL is moderate at best, and to the extent that this sort of highly semantic business-oriented thing needs standards-group attention, it probably doesn't need the IETF's. -Tim On Wed, Feb 22, 2012 at 5:37 PM, Ben Vandervalk wrote= : > Hi all, > > I have recently submitted an I-D (as an individual) regarding RDF/OWL-bas= ed > web services called SADI (Semantic Automated Discovery and Integration). > > My intent is to put this I-D on the standards track, and I have been advi= sed > that the first step is to solicit comments/reviews on this list, in order= to > guage interest. > > There are currently three implementations of SADI in Java, Perl, and Pyth= on, > which are available from http://sadi.googlecode.com/. The Java and Perl > implementations were created by the authors, whereas the Python > implementation was created independently by Jim McCusker of MSU. The Pyth= on > implementation does not yet implement all of the features in the draft, b= ut > we think it is likely that Jim will expand his implementation in time, or > that other parties will create additional implementations of SADI. > > I am unfamiliar with IETF procedures regarding individual submissions and > would appreciate any advice in that regard as well. > > Thanks for your consideration! > > =3D=3D=3D=3D=3D=3D > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This is an Individual Submission. > > =A0=A0=A0=A0=A0=A0 Title : SADI: Semantic Automated Discovery and Integra= tion > =A0=A0=A0=A0=A0=A0 Author(s) : Ben Vandervalk, E. Luke McCarthy, Mark D. = Wilkinson > =A0=A0=A0=A0=A0=A0 Filename : draft-bvandervalk-sadi-00.txt > =A0=A0=A0=A0=A0=A0 Pages : 31 > =A0=A0=A0=A0=A0=A0 Date : 2012-01-31 > > This document describes Semantic Automated Discovery and Integration > (SADI), a set of best practices for implementing stateless web > services that consume RDF data as input and generate RDF data as > output. The goal of SADI is to establish conventions that will > enable a much higher level of interoperability between web services > from independent providers than is currently possible under the > widespread use of WSDL/XML and RESTful services. Under SADI, > interoperability depends on the shared use of predicate vocabularies, > rather than the shared use of particular XML schemas, JSON > structures, or ad hoc data formats. Through the use of OWL to > describe service input and output datatypes, SADI enables: i) > automated discovery of services that provide data or computations of > interest, and ii) automated matchmaking between local data and > available services. By iterative application of the former two > capabilities, SADI enables semi-automated construction of arbitrarily > complex workflows across independent service providers. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-bvandervalk-sadi-00.txt > > > > -- Ben Vandervalk > Wilkinson Lab, University of British Columbia > > > > > > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From duerst@it.aoyama.ac.jp Wed Feb 22 21:53:41 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A800611E8075 for ; Wed, 22 Feb 2012 21:53:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.978 X-Spam-Level: X-Spam-Status: No, score=-100.978 tagged_above=-999 required=5 tests=[AWL=-1.188, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pVvdE1OCer7x for ; Wed, 22 Feb 2012 21:53:40 -0800 (PST) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 4771B21F85D8 for ; Wed, 22 Feb 2012 21:53:39 -0800 (PST) Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id q1N5rVoZ013936 for ; Thu, 23 Feb 2012 14:53:31 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 65f0_80ab_b715ca7c_5de2_11e1_83a3_001d096c566a; Thu, 23 Feb 2012 14:53:30 +0900 Received: from [IPv6:::1] ([133.2.210.1]:34006) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 23 Feb 2012 14:53:35 +0900 Message-ID: <4F45D452.9010702@it.aoyama.ac.jp> Date: Thu, 23 Feb 2012 14:53:22 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Henri Sivonen References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Anne van Kesteren , apps-discuss@ietf.org Subject: Re: [apps-discuss] Feedback about "Update to MIME regarding Charset Parameter Handling in Textual Media Types" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 05:53:42 -0000 Hello Henri, Alex, Some comments to Henri and some to Alex inline. On 2012/02/22 22:25, Henri Sivonen wrote: > In reference to > https://svn.tools.ietf.org/svn/wg/appsawg/draft-ietf-appsawg-mime-default-charset/latest/draft-ietf-appsawg-mime-default-charset.html > > First of all, thank you for finally taking on the much-needed update > to RFC 2046 rules. > > Unfortunately, the draft doesn't address the problem the right way in > my opinion. Quotes from the draft. > >> Each subtype of the "text" media type which uses the "charset" parameter can define its own default value for the "charset" parameter, including absence of any default. I'm not opposed to this in principle, but I'm worried that as written, it will lead to more and more unnecessarily different 'algorithms' and heuristics. The spec should make clear that where possible, established patters should be followed to reduce variety. >> In order to improve interoperability with deployed agents, "text/*" media type definitions SHOULD either a) specify that the "charset" parameter is not used for the defined subtype, because the charset information is transported inside the payload (as in "text/xml") > > This seems wrong. If the charset parameter is present, it has an > effect for text/xml. Yes indeed. >> or b) require explicit unconditional inclusion of the "charset" parameter eliminating the need for a default value. > > This seems naïve. Formats need to specify what happens when a charset > parameter is missing, since no matter how much the format says it's > "required", the party sending data can omit the charset parameter. > >> In accordance with option (a), above, "text/*" media types that can transport charset information inside the corresponding payloads, specifically including "text/html" and "text/xml", SHOULD NOT specify the use of a "charset" parameter, nor any default value, in order to avoid conflicting interpretations should the charset parameter value and the value specified in the payload disagree. > > For backwards compatibility, pretty much every existing text/* type > will have to violate this "SHOULD NOT". Yes. I think it's inappropriate to give such advice on existing formats. If we agree that changes are needed (which I think in the cases at hand would be somewhat wishful thinking), they should be specified directly, either in this document or preferably in an update to the spec of the format itself. >> The default charset parameter value for text/plain is unchanged from [RFC2046] and remains as "US-ASCII". > > This is incompatible with reality. Web browsers, for instance, assume > a configuration-dependent default (which correlates with browser > localization) and may also (depending on configuration which, again, > correlates with localization by default) perform a heuristic analysis > on the payload. > > I suggest specifying the following instead of sections 3 and 4 of the draft: > 4. Determining the character encoding for text/plain This looks like a very long algorithm. It may work pretty well in a Web context (definitely better than an US-ASCII default), but what about other contexts (e.g. mail)? [Part of the algorithm cut out to save electrons.] > If the entity is being loaded into a browsing context and is being > fetched from a location from which an entity has been loaded before > and the previous character encoding has been cached, the character > encoding is the cached encoding. Terminate these steps. > > If the entity is being loaded via a non-browsing context mechanism > (such as XMLHttpRequest) that defines a fallback encoding, use that > encoding. Terminate these steps. > > Otherwise, the character encoding is a configuration-dependent > encoding. The default configuration SHOULD depend on the locale of the > user agent according to the table given in step 8 in [5]. Terminate > these steps. What is missing here is that there is sometimes a need for user intervention if all else fails. While it may be possible to look at this as something outside of this algorithm, or as something subsumed under "configuration" or whatever, I'm afraid that the current text will give many implementers the impression that user overrides are not allowed. So I suggest adding something like: In an interactive context, the user may occasionally want to override the character encoding determined by this algorithm. Regards, Martin. > > [1] http://www.whatwg.org/specs/web-apps/current-work/#ascii-case-insensitive > [2] http://dvcs.w3.org/hg/encoding/raw-file/tip/Overview.html#concept-encoding-label > [3] http://www.whatwg.org/specs/web-apps/current-work/#browsing-context > [4] http://tools.ietf.org/html/rfc6454 > [5] http://www.whatwg.org/specs/web-apps/current-work/#determining-the-character-encoding > From ned.freed@mrochek.com Wed Feb 22 23:15:00 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57F9C11E8093 for ; Wed, 22 Feb 2012 23:14:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r2ju2elzCx-w for ; Wed, 22 Feb 2012 23:14:52 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id EF43011E8085 for ; Wed, 22 Feb 2012 23:14:51 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OCB421VNTS006M6P@mauve.mrochek.com> for apps-discuss@ietf.org; Wed, 22 Feb 2012 23:14:47 -0800 (PST) MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=utf-8 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OC8QYYHB0W00ZUIL@mauve.mrochek.com>; Wed, 22 Feb 2012 23:14:43 -0800 (PST) Message-id: <01OCB41ZCJES00ZUIL@mauve.mrochek.com> Date: Wed, 22 Feb 2012 19:59:01 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Wed, 22 Feb 2012 15:25:02 +0200" References: To: Henri Sivonen DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1329981292; bh=MP+Yi3jtFxWlvBL9biwPB2kVv9zKxr4nwrTMf692fi0=; h=MIME-version:Content-type:Cc:Message-id:Date:From:Subject: In-reply-to:References:To; b=kaDVwrogEZ2wfAWlIW50s+LVIGoRlIw0KehM0gzNrt1f67TR3Dxi03XPRmsuce+Xa EoTPsd5Hv5UHBRKvSqtf+0vnUvo14pftjp60WD4GTQ+Bm9gNvviOg2e5ePg+7rMsq9 yaU9rS+rZFAWQiPgp4Ubg312KrmaxLRh3UR8U7S8= Cc: Anne van Kesteren , apps-discuss@ietf.org Subject: Re: [apps-discuss] Feedback about "Update to MIME regarding Charset Parameter Handling in Textual Media Types" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 07:15:00 -0000 > In reference to > https://svn.tools.ietf.org/svn/wg/appsawg/draft-ietf-appsawg-mime-default-charset/latest/draft-ietf-appsawg-mime-default-charset.html > First of all, thank you for finally taking on the much-needed update > to RFC 2046 rules. > Unfortunately, the draft doesn't address the problem the right way in > my opinion. Quotes from the draft. > > Each subtype of the "text" media type which uses the "charset" parameter can define its own default value for the "charset" parameter, including absence of any default. > Additionally, media types should be able to define circumstances where > in-band indicators override the charset parameter even if the charset > parameter is present. That's a terrible way to do it - if the type is self-identifying in terms of charset, a charset parameter should simply not be defined for the type - exactly what the current specification says to do. The result is effectively the same as what you're proposing since undefined parameters are supposed to be ignored. The difference is your approach is effectively sanctioning active mislabelling, and that's a road we've already explored way too much in an informal fashion, especially in the CJK arena. Formalizing it is the last thing we should be doing. > In particular, media types should be allowed to override the charset > parameter if the first two or three bytes of the payload look like an > UTF-16 or UTF-8 BOM. There are quite a few charsets in existence where it is perfectly permissible for the first few bytes to match a BOM, except that it means something entirely different. > See: > https://www.w3.org/Bugs/Public/show_bug.cgi?id=15359 > https://bugzilla.mozilla.org/show_bug.cgi?id=716579 > https://bugzilla.mozilla.org/show_bug.cgi?id=687859 > > In order to improve interoperability with deployed agents, "text/*" media > type definitions SHOULD either a) specify that the "charset" parameter is not > used for the defined subtype, because the charset information is transported > inside the payload (as in "text/xml") > This seems wrong. If the charset parameter is present, it has an > effect for text/xml. That's only because the definition of test/xml did it incorrectly. I'll grant you, however, that the example is a little wierd. What it should say is that XML-based formats can and should self-identify the format. But this has no technical effect on the specification. > > or b) require explicit unconditional inclusion of the "charset" parameter > eliminating the need for a default value. > This seems naïve. Formats need to specify what happens when a charset > parameter is missing, since no matter how much the format says it's > "required", the party sending data can omit the charset parameter. Yep. They can also misspell the parameter name, misspell the charset name, use the wrong type/subtype, misspell the header field name, omit the field entirely, or any of a million other mistakes. And when (not if) this sort of thing happens, the receiver can elect to pursue whatever course of action it deems appropriate for invalid material. It can reject it, refuse to show it, use a default, sniff it and make a guess, prompt the user and ask what to do, whatever. Not allowing specification of a default in the type registration has no impact at all on the options an implementation has available. In fact it's the other way around - allowing specifiction of a default *limits* implementation choices. We learned long ago through multiple painful experiences that attempting to specify the handling of invalid stuff is an enormous rathole that is best given wide berth. And even if the cases where it is successful in producing some sort of advice, or worse making what should be illegal legal, that advice or approach is usually bound to a place and time and become the wrong advice or approach at some point in the future. So, far from being naive, it is your approach that has been shown, over and over, to the the naive one. > > In accordance with option (a), above, "text/*" media types that can transport charset information inside the corresponding payloads, specifically including "text/html" and "text/xml", SHOULD NOT specify the use of a "charset" parameter, nor any default value, in order to avoid conflicting interpretations should the charset parameter value and the value specified in the payload disagree. > For backwards compatibility, pretty much every existing text/* type > will have to violate this "SHOULD NOT". Yep. That's the main reason why it needs to be a SHOULD. > > New subtypes of the "text" media type, thus, SHOULD NOT define a default "charset" value. If there is a strong reason to do so despite this advice, they SHOULD use the "UTF-8" [RFC3629] charset as the default. > Seems reasonable. > > Specifications of how to specify the "charset" parameter, and what default value, if any, is used, are subtype-specific, NOT protocol-specific. > Seems reasonable. > > Protocols that use MIME, therefore, MUST NOT override default charset values for "text/*" media types to be different for their specific protocol. The protocol definitions MUST leave that to the subtype definitions. > Seems reasonable. > > The default charset parameter value for text/plain is unchanged from > > [RFC2046] and remains as "US-ASCII". Note that this has the effect of rendering any content that contains 8bit as being invalid. Implementation are then free to choose how to handle that, as above. Of course this leaves 7bit charsets in the lurch, notably the iso-2022-* group, which is the main reason why I'm not happy with the US-ASCII default, as I mention below. > This is incompatible with reality. Web browsers, for instance, assume > a configuration-dependent default (which correlates with browser > localization) and may also (depending on configuration which, again, > correlates with localization by default) perform a heuristic analysis > on the payload. Well, on this one you'll have to argue with someone else. I don't especially like the approach in the draft, but I have been unable to come up with any reasonable alternative. Your proposed alternative below, is totally unworkable. > I suggest specifying the following instead of sections 3 and 4 of the draft: > 3. New rules for determining the character encoding for text/* media types > Each text/* media type MUST specify an algorithm for establishing the > character encoding of the entity body from the entity body (or > preferably the first N bytes thereof, preferably with N = 1024), the > charset parameter and Other Information. Other Information MAY include > configuration, an encoding label supplied by the referrer, the > previous encoding of an entity body retrieved from the same location > or the encoding of the referrer. New text/* media types MUST not use > Other Information in the algorithms they specify. > New text/* media types SHOULD use the following algorithm: > The character encoding is UTF-8. Terminate these steps. This approach is ridiculous when you consider how general the usage of some text types are and the close similarity of many charsets in common use. It is not at all common for there to only be one or two characters that in a large document that display incorrectly when the wrong charset is selected. > 4. Determining the character encoding for text/plain > If the first 2 octets of the entity body are 0xFE followed by 0xFF, > the character encoding is big-endian UTF-16. Terminate these steps. > If the first 2 octets of the entity body are 0xFF followed by 0xFE, > the character encoding is little-endian UTF-16. Terminate these steps. See my note above about BOMs. > If the first 3 octets of the entity body are 0xEF followed by 0xBB > followed by 0xBF, the character encoding is UTF-8. Terminate these > steps. I've checked and I have yet to receive a single message in utf-8 with a leading BOM. But this sequence can show up in material in other charsets. > If the value of the charset parameter is a ASCII case-insensitive[1] > match for a label[2] of a supported encoding, the character encoding > is the encoding whose label was matched. Terminate these steps. So the label is secondary to sniffing. Totally unacceptable. It is also unacceptable to ignore a valid label just because you don't support the encoding. > If the entity is being navigate to in a browsing context[3] and the > previous document had the same origin[4] as the text/plain entity, the > character encoding is the encoding of the referring document. > Terminate these steps. (Disclaimer: I'm not 100% sure that this step > is in the right order relative to the others.) > Optional: If a heuristic detector recognizes the octets of the entity > body as being encoding according to an encoding, the character > encoding is that encoding. Terminate these steps. This step SHOULD NOT > be implemented for locales where it has not been implemented > traditionally. > If the entity is being loaded into a nested browsing context that has > the same origin as the parent browsing context, the encoding is the > encoding of the document loaded in the parent browsing context. > Terminate these steps. > If the entity is being loaded into a browsing context and is being > fetched from a location from which an entity has been loaded before > and the previous character encoding has been cached, the character > encoding is the cached encoding. Terminate these steps. > If the entity is being loaded via a non-browsing context mechanism > (such as XMLHttpRequest) that defines a fallback encoding, use that > encoding. Terminate these steps. > Otherwise, the character encoding is a configuration-dependent > encoding. The default configuration SHOULD depend on the locale of the > user agent according to the table given in step 8 in [5]. Terminate > these steps. Finally, I'd say the odds of any implementor following such a complex set of rules is remote in the extreme. > [1] http://www.whatwg.org/specs/web-apps/current-work/#ascii-case-insensitive > [2] http://dvcs.w3.org/hg/encoding/raw-file/tip/Overview.html#concept-encoding-label > [3] http://www.whatwg.org/specs/web-apps/current-work/#browsing-context > [4] http://tools.ietf.org/html/rfc6454 > [5] http://www.whatwg.org/specs/web-apps/current-work/#determining-the-character-encoding Ned From GK@ninebynine.org Thu Feb 23 00:12:18 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E14D21F8540 for ; Thu, 23 Feb 2012 00:12:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.842 X-Spam-Level: X-Spam-Status: No, score=-4.842 tagged_above=-999 required=5 tests=[AWL=1.757, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fb6p7Zos75hE for ; Thu, 23 Feb 2012 00:12:13 -0800 (PST) Received: from relay2.mail.ox.ac.uk (relay2.mail.ox.ac.uk [163.1.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 03E4521F84F7 for ; Thu, 23 Feb 2012 00:12:06 -0800 (PST) Received: from smtp2.mail.ox.ac.uk ([163.1.2.205]) by relay2.mail.ox.ac.uk with esmtp (Exim 4.75) (envelope-from ) id 1S0TmX-0000Dd-6W; Thu, 23 Feb 2012 08:12:05 +0000 Received: from gklyne.plus.com ([80.229.154.156] helo=Eskarina.local) by smtp2.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1S0TmW-0003y4-8f; Thu, 23 Feb 2012 08:12:04 +0000 Message-ID: <4F45F47A.4080801@ninebynine.org> Date: Thu, 23 Feb 2012 08:10:34 +0000 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Ben Vandervalk References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] request for review: draft-bvandervalk-sadi-00.txt (individual submission) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 08:12:18 -0000 I skimmed through this with some interest, but I feel (with some regret) that I must agree with Tim Bray that the IETF is probably not the right venue for this. I have two main technical reasons for saying this: (1) it does not really define any new protocol in the sense that IETF generally defines protocols; rather it defines a (quite reasonable) pattern of use for HTTP for a particular class of web services. (2) the "protocol" described is quite specific in the content types it deals with (just RDF), which I feel means it is not the kind of common infrastructure-layer element that the IETF would normally consider. None of this means that the work is without merit, or not worthy of wider review. In particular, I note that it may find early applicability outside bioinformatics in areas such as open government data applications where there is significant use of RDF. Suggestions I offer to present this to a wider audience are: - I would expect that a proposal like this would likely gain more traction in W3C. In the first instance, there might be a possibility to see if the W3C HCLS group would be interested to review this and publish it as a W3C Note. - If you feel it really has applicability to communities beyond those who engage with W3C activities, it might be a candidate for individual submission as an informational RFC; though there no guarantee that it will get extensive review on that route. (There is a "precedent" in BEEP (formerly BXXP) for specifications being first published by that route, and later becoming formally standardized as http://www.ietf.org/rfc/rfc3080.txt - though I don't know that it's widely used). There may well be other, better ways to develop this work - those are just a couple of suggestions that occur to me. Best, #g -- On 23/02/2012 01:37, Ben Vandervalk wrote: > Hi all, > > I have recently submitted an I-D (as an individual) regarding RDF/OWL-based > web services called SADI (Semantic Automated Discovery and Integration). > > My intent is to put this I-D on the standards track, and I have been > advised that the first step is to solicit comments/reviews on this list, in > order to guage interest. > > There are currently three implementations of SADI in Java, Perl, and > Python, which are available from http://sadi.googlecode.com/. The Java and > Perl implementations were created by the authors, whereas the Python > implementation was created independently by Jim McCusker of MSU. The Python > implementation does not yet implement all of the features in the draft, but > we think it is likely that Jim will expand his implementation in time, or > that other parties will create additional implementations of SADI. > > I am unfamiliar with IETF procedures regarding individual submissions and > would appreciate any advice in that regard as well. > > Thanks for your consideration! > > ====== > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This is an Individual Submission. > > Title : SADI: Semantic Automated Discovery and Integration > Author(s) : Ben Vandervalk, E. Luke McCarthy, Mark D. Wilkinson > Filename : draft-bvandervalk-sadi-00.txt > Pages : 31 > Date : 2012-01-31 > > This document describes Semantic Automated Discovery and Integration > (SADI), a set of best practices for implementing stateless web > services that consume RDF data as input and generate RDF data as > output. The goal of SADI is to establish conventions that will > enable a much higher level of interoperability between web services > from independent providers than is currently possible under the > widespread use of WSDL/XML and RESTful services. Under SADI, > interoperability depends on the shared use of predicate vocabularies, > rather than the shared use of particular XML schemas, JSON > structures, or ad hoc data formats. Through the use of OWL to > describe service input and output datatypes, SADI enables: i) > automated discovery of services that provide data or computations of > interest, and ii) automated matchmaking between local data and > available services. By iterative application of the former two > capabilities, SADI enables semi-automated construction of arbitrarily > complex workflows across independent service providers. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-bvandervalk-sadi-00.txt > > > > -- Ben Vandervalk > Wilkinson Lab, University of British Columbia > > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From hsivonen@gmail.com Thu Feb 23 01:51:38 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF10621F861B for ; Thu, 23 Feb 2012 01:51:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xg8frY4i5I3V for ; Thu, 23 Feb 2012 01:51:36 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id BADDE21F85D4 for ; Thu, 23 Feb 2012 01:51:36 -0800 (PST) Received: by ggnq2 with SMTP id q2so538186ggn.31 for ; Thu, 23 Feb 2012 01:51:36 -0800 (PST) Received-SPF: pass (google.com: domain of hsivonen@gmail.com designates 10.236.161.232 as permitted sender) client-ip=10.236.161.232; Authentication-Results: mr.google.com; spf=pass (google.com: domain of hsivonen@gmail.com designates 10.236.161.232 as permitted sender) smtp.mail=hsivonen@gmail.com; dkim=pass header.i=hsivonen@gmail.com Received: from mr.google.com ([10.236.161.232]) by 10.236.161.232 with SMTP id w68mr971051yhk.56.1329990696281 (num_hops = 1); Thu, 23 Feb 2012 01:51:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=cXO5JEuKEeQxmmDrrWtiz5vfsblFQR5H1BjwVQwjAnU=; b=J2QPip5C46cyeD5moGteIX5GteJXdqeCA+/fek5GCWXh6EJlUMDE8+xLF4aBr3THGV LLFl0r/qlXr6I+EhhxxsUGEXQgjtBV0LocSlKUrH1i8AJhwWXKXrFOjD8tY+j8lFZiE6 7Wa1aC6UNAZBqD/3cZzBtYPOdvYIrzAeKX6lk= MIME-Version: 1.0 Received: by 10.236.161.232 with SMTP id w68mr744459yhk.56.1329990696037; Thu, 23 Feb 2012 01:51:36 -0800 (PST) Sender: hsivonen@gmail.com Received: by 10.101.170.17 with HTTP; Thu, 23 Feb 2012 01:51:35 -0800 (PST) In-Reply-To: <4F45D452.9010702@it.aoyama.ac.jp> References: <4F45D452.9010702@it.aoyama.ac.jp> Date: Thu, 23 Feb 2012 11:51:35 +0200 X-Google-Sender-Auth: E7ChVdKWbIwwv1-w9XFXDkZceuE Message-ID: From: Henri Sivonen To: apps-discuss@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Anne van Kesteren Subject: Re: [apps-discuss] Feedback about "Update to MIME regarding Charset Parameter Handling in Textual Media Types" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 09:51:38 -0000 On Thu, Feb 23, 2012 at 7:53 AM, "Martin J. D=C3=BCrst" wrote: > I'm not opposed to this in principle, but I'm worried that as written, it > will lead to more and more unnecessarily different 'algorithms' and > heuristics. The spec should make clear that where possible, established > patters should be followed to reduce variety. I suggesting that new stuff be UTF-8 only. For old stuff, everything is a bit different. Off the top of my head: text/javascript uses HTTP charset or the BOM or declaration from the referrer (the charset=3D"" attribute on