Return-Path: X-Original-To: apps-review@core3.amsl.com Delivered-To: apps-review@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9D1F3A6808 for ; Fri, 24 Dec 2010 08:36:20 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EpQTeBforcsU for ; Fri, 24 Dec 2010 08:36:19 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id B637E3A6804 for ; Fri, 24 Dec 2010 08:36:19 -0800 (PST) Received: from [192.168.1.63] (adsl-67-127-191-82.dsl.pltn13.pacbell.net [67.127.191.82]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id oBOGcDrg013706 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 24 Dec 2010 08:38:18 -0800 Message-ID: <4D14CC73.80703@dcrocker.net> Date: Fri, 24 Dec 2010 08:38:11 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: SM References: <4CF96768.1060704@isode.com> <6.2.5.6.2.20101222133204.0d4c2410@resistor.net> <4D1390F1.2060006@dcrocker.net> <6.2.5.6.2.20101223212912.08425b98@elandnews.com> In-Reply-To: <6.2.5.6.2.20101223212912.08425b98@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]); Fri, 24 Dec 2010 08:38:19 -0800 (PST) Cc: apps-review@ietf.org Subject: Re: [apps-review] Review of EAI documents by the Apps Review Team X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Dec 2010 16:36:20 -0000 On 12/23/2010 10:10 PM, SM wrote: >> SM, I cannot match this concern to anything I saw during the review process. >> Can you explain what "non-technical" issues might have been a concern? > > It's not directly related to the review of the EAI documents. > > Sometimes we might be reviewing a document which is more about IETF process than > a particular technology. There is one such review that is currently assigned. > While reviewing the usage of a technology, we might be of the opinion that it > raises privacy issues. ahh. ok. thanks for the clarification. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net Return-Path: X-Original-To: apps-review@core3.amsl.com Delivered-To: apps-review@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB5733A68F0 for ; Thu, 23 Dec 2010 22:09:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.465 X-Spam-Level: X-Spam-Status: No, score=-102.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PeO0q8PE-YqS for ; Thu, 23 Dec 2010 22:09:17 -0800 (PST) Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by core3.amsl.com (Postfix) with ESMTP id 393323A68EE for ; Thu, 23 Dec 2010 22:09:17 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.236.213]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id oBO6B686022989; Thu, 23 Dec 2010 22:11:12 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1293171073; bh=ohYcPJ0N1nU5IH5Ri/pNBU4w6pQ=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=eKoU7rPh4w4Nzvm1mcG1qvCx2eUjSkqTMREDIGBh/IQScr13YX8pVcu9wUgVpkVpt o7aATBovZR8PekIFSlamymYBZeKyiZclYhyurwGlOLGfut6pKHps45I9vddG8JG1jp 4/jxxhYZl0laoeSHPPKShJeAubfGZ11jtm+Zdi5M= Message-Id: <6.2.5.6.2.20101223212912.08425b98@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 23 Dec 2010 22:10:43 -0800 To: dcrocker@bbiw.net From: SM In-Reply-To: <4D1390F1.2060006@dcrocker.net> References: <4CF96768.1060704@isode.com> <6.2.5.6.2.20101222133204.0d4c2410@resistor.net> <4D1390F1.2060006@dcrocker.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-review@ietf.org Subject: Re: [apps-review] Review of EAI documents by the Apps Review Team X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Dec 2010 06:09:19 -0000 Hi Dave, At 10:12 23-12-10, Dave CROCKER wrote: >Just to emphasize SM's point, and possibly to encourage re-use of >the model for later reviews that are expected to raise challenges to >the working group: Thanks for providing an insight on the model we used. >SM, I cannot match this concern to anything I saw during the review >process. Can you explain what "non-technical" issues might have been a concern? It's not directly related to the review of the EAI documents. Sometimes we might be reviewing a document which is more about IETF process than a particular technology. There is one such review that is currently assigned. While reviewing the usage of a technology, we might be of the opinion that it raises privacy issues. I'll label such issues as strictly non-technical for simplicity. It can be argued that they are or are not within the purview of the Apps Review Team. Best regards, -sm Return-Path: X-Original-To: apps-review@core3.amsl.com Delivered-To: apps-review@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E8F33A6860 for ; Thu, 23 Dec 2010 10: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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oWty2moMnOFF for ; Thu, 23 Dec 2010 10:10:11 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 152FB3A685A for ; Thu, 23 Dec 2010 10:10:11 -0800 (PST) Received: from [192.168.1.43] (adsl-67-127-191-82.dsl.pltn13.pacbell.net [67.127.191.82]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id oBNIC2Qv017603 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 23 Dec 2010 10:12:08 -0800 Message-ID: <4D1390F1.2060006@dcrocker.net> Date: Thu, 23 Dec 2010 10:12:01 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: SM References: <4CF96768.1060704@isode.com> <6.2.5.6.2.20101222133204.0d4c2410@resistor.net> In-Reply-To: <6.2.5.6.2.20101222133204.0d4c2410@resistor.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Thu, 23 Dec 2010 10:12:08 -0800 (PST) Cc: apps-review@ietf.org Subject: Re: [apps-review] Review of EAI documents by the Apps Review Team X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Dec 2010 18:10:12 -0000 On 12/22/2010 3:23 PM, SM wrote: > The EAI documents were reviewed independently by each reviewer. There was some > off-list discussion about how to coordinate the work. Just to emphasize SM's point, and possibly to encourage re-use of the model for later reviews that are expected to raise challenges to the working group: Each of us did our independent reviews /privately/. We shared them /only/ after we had completed our first round of writing. We then discussed the reviews with each other. This was an open free-for all. The purpose of discussing our initial reviews privately, before circulating them to the working group, was to permit us to clarify our observations, both in terms of the details and in terms of the language. To the extent that we developed similar points, in different language, we explored the similarities and differences, to make sure we understood each other -- and possibly to correct misunderstandings. If a review might present a challenge to the working group, it helps to put this kind of effort into "packaging" it as helpfully as possible. In effect, this was like a design team effort, except each review still owned the review they offered. For reference, no one had "authority" in the discussion; they merely had their own views. The AD's authority concerned logistics to coordinate the handling of the reviews, but not about the content. (On the other hand, he has a background in the topic and was an active participant in the discussion, of course.) > From my short experience as Review Team Lead, the Apps ADs do not set any > restrictions on reviews; i.e. what the review can or cannot say. I may provide > private feedback if the reviewer asks me. The latest batch of reviews raised the > question of whether a review should be strictly technical. SM, I cannot match this concern to anything I saw during the review process. Can you explain what "non-technical" issues might have been a concern? Thanks. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net Return-Path: X-Original-To: apps-review@core3.amsl.com Delivered-To: apps-review@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC0753A6943 for ; Wed, 22 Dec 2010 15:31:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.459 X-Spam-Level: X-Spam-Status: No, score=-102.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FiLF45C8zYCe for ; Wed, 22 Dec 2010 15:31:21 -0800 (PST) Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by core3.amsl.com (Postfix) with ESMTP id 2C4AB3A68F7 for ; Wed, 22 Dec 2010 15:31:21 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.239.54]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id oBMNXDW7005125 for ; Wed, 22 Dec 2010 15:33:18 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1293060800; bh=5te2DbQqll5BbQSlzCMT3Fz7FZY=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type; b=fl5cbBnwp5u3vzXyhfw0NdgzS7vrsWvdw5mGo50+4jzTZ/6REeGTpskylajTEN2YG HnXI2Zv9o6lpt38KYCZEzQU+93Pq1pyReIbYpDvsfqK+Dc79TQSe9F73gfXLmmOux+ iYFQWC/sQaNkoz7YSMx+k9W+heKZPpne2Z/I6eWc= Message-Id: <6.2.5.6.2.20101222133204.0d4c2410@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 22 Dec 2010 15:23:25 -0800 To: apps-review@ietf.org From: SM In-Reply-To: <4CF96768.1060704@isode.com> References: <4CF96768.1060704@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [apps-review] Review of EAI documents by the Apps Review Team X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 23:31:24 -0000 Hello, First of all, I would like to thank Claudio Allocchio, Dave Crocker, Eliot Lear, Murray Kucherawy and Ted Hardie for reviewing EAI documents. These comments are not specifically about the EAI documents. It is up to the Review Team Lead to assign reviews. The assignments are rotated to spread the work unless a particular expertise is required for the review. In some cases, the Apps ADs may suggest a list of possible reviewers; they leave it to the Review Team Lead to select the reviewers. The EAI documents were reviewed independently by each reviewer. There was some off-list discussion about how to coordinate the work. As one of our tasks is also to help the Apps ADs, we may discuss a review with them if we think that there are significant issues that should be brought to their immediate attention. From my short experience as Review Team Lead, the Apps ADs do not set any restrictions on reviews; i.e. what the review can or cannot say. I may provide private feedback if the reviewer asks me. The latest batch of reviews raised the question of whether a review should be strictly technical. I personally prefer not to limit what goes into a review as long as it follows IETF practices. Best regards, -sm Return-Path: X-Original-To: apps-review@core3.amsl.com Delivered-To: apps-review@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 448D73A6925; Wed, 22 Dec 2010 10:03:04 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3n2X7E2rjUvK; Wed, 22 Dec 2010 10:03:00 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 279EC3A6909; Wed, 22 Dec 2010 10:03:00 -0800 (PST) Received: from [192.168.1.43] (adsl-67-127-191-82.dsl.pltn13.pacbell.net [67.127.191.82]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id oBMI4mYh013364 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 22 Dec 2010 10:04:53 -0800 Message-ID: <4D123DC0.2050501@dcrocker.net> Date: Wed, 22 Dec 2010 10:04:48 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Apps Discuss , ima@ietf.org, draft-ietf-eai-rfc5336bis@tools.ietf.org, SM , Alexey.Melnikov@isode.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]); Wed, 22 Dec 2010 10:04:55 -0800 (PST) X-Mailman-Approved-At: Thu, 23 Dec 2010 08:08:28 -0800 Subject: [apps-review] (private) draft review of: draft-ietf-eai-rfc5336bis-07.txt (v3) X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 18:03:04 -0000 IETF Applications Review I have been selected as an Applications Area Review Team reviewer for this draft. For background on apps-review, please see: 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-eai-rfc5336bis-07.txt Reviewer: Dave Crocker, Brandenburg InternetWorking Review Date: 2010-12-22 BACKGROUND: The document is a specification for an email transport-time option that is described in its Abstract as declaring support for "internationalized email addresses or header information" and in the Introduction as being "to support an internationalized email address". The extension specifies changes both in the transfer protocol and in the message being transferred, including its Body. Legacy Internet Mail only supports classic "network ASCII" for data representation and for data transfer encoding. The charter for the current work cites previous work that was issued as Experimental, and summarizes it as having been "... based on the use of an SMTP extension to enable the use of UTF-8 in envelope address local-parts, optionally in address domain-parts, and in mail headers." This text appears also to serve as the statement of scope for the current working group. With respect to the mail header, the scope is specified as covering
and constructs. An is a means of mapping Unicode strings onto classic, network ASCII, although the working group focus was on binary, UTF-8 support. RECOMMENDATIONS: This work represents an extremely important enhancement to Internet mail. It has been clear for twenty years that Internet applications need to be able to present data in a form that is natural to the user. The current work benefits from providing a Framework document and from distinguishing changes to the email header from changes to the SMTP protocol. 0. The documents do raise distinctions between ASCII and Unicode, versus between ASCII and UTF-8. However they do not apply them rigorously in the documents. I suggest that the term "internationalization" be used only during introductory discussion and never as part of normative text. ASCII vs. Unicode is a distinction between the underlying range of data being represented. ASCII vs. UTF-8 is a distinction between encoding environments. Text should explicitly indicate whether it means data representation versus data encoding and it should use Unicode for the former and UTF-8 for the latter. 1. The Framework document is normative and needs to be completed along with the other two specifications, since they quite reasonably state a normative dependence on the Framework document. 2. The SMTP extension draft needs to focus on SMTP and the direct support of UTF-8 in the message header. It needs to move all discussion and specification of Unicode support in the Header to the Header draft. 3. There probably needs to be definition of MIME message/uni-rfc822, specifying Unicode support within a message contained in MIME. I'm less clear whether there needs to be a MIME Content-Transfer-Encoding form specific to UTF-8. 4. The SMTP extension needs to have the client use an explicit signal when it is sending a message encoded in UTF-8. This is easiest as a parameter to the MAIL command. The current specification creates a more complex and almost heuristic model for distinguishing ASCII from UTF-8 use. 5. The SMTP extension needs to remove all restrictions it imposes on MIME content-type. A major reason that MIME was successful was that it was transparent to the transfer infrastructure. The current SMTP extension specification changes this model, which actually increases the barrier to adoption of Unicode in email. It needs to be easy for two MUAs that support Unicode in the email header to exchange mail even when the infrastructure does not support UTF-8. SUMMARY COMMENTS: The document conforms to the conventions for defining SMTP options. There are a number of significant issues with the specification. These are covered in detail, below, and are summarized here: * Framework -- The Framework document[1] is (correctly) referenced as required reading. It supplies essential terminology and architecture for this specification. In fact it is a specification, complete with formally normative vocabulary. This means that it must be a normative reference by rfc5336bis. It therefore also means that the Framework document needs to be completed before the current specification can be standardized. * Scope -- the specification appears to go significantly beyond the scope of the working group's charter, including revisions to basic SMTP that have no obvious requirement for support of Unicode during transport. In fact, at least one change is likely to /restrict/ system-wide adoption, rather than encourage it! In particular, the specification restricts the conditions under which some MIME content is allowed to be sent. (See next bullet.) * Infrastructure Requirement -- Unless this option is in force, carrying internationalized email in a MIME part is prohibited. This is out of scope for the working group and it is a counter-productive rule. Imagine if the same type of rule had been specified when MIME was created, saying that MIME could only be sent when an "attachments-supported" option were in force. This would have prevented the early adoption of MIME use by individual MUAs until the entire infrastructure supported MIME. (As an example of the very high barrier this raises, note the difference in real-world support and use of MDN versus DSN.) While it is reasonable for the working group to define a new MIME content-type that modifies message/rfc822 to support internationalized addresses, it is not appropriate for the working group to modify the SMTP transfer model to constrain what types of message content can be sent. * Beyond -- The work, here, appears to have two goals. One is to add support for Unicode in a ; that is, support for internationalized addresses. However note that and already accomplish this in a way that is transparent to the existing email infrastructure; only the end-systems need to understand it. The second goal is to support Unicode in the more "native" form of UTF-8. (The quotation marks are because UTF-8 is not native Unicode, either; it is a highly encoded form of Unicode...) This creates some confusion in the specification. Given that the option for SMTP is "UTF8SMTPbis", then the binary encoding goal seems to dominate the work. This is a certainly a reasonable goal, but it will help the clarity of the specification to make these two different goals more clear within the document and to apply them more carefully. * Terminology confusion -- The Framework document carefully distinguishes between "ASCII addresses and non-ASCII addresses. It equates "internationalized" first with "non-ASCII", but then with "UTF8SMTPbis". A core problem is that ASCII is part of the actual internationalized set of Unicode characters. So, to say that "international" characters are non-ASCII is exclude part of Unicode from the term "international". In addition, equating the term "internationalization" with UTF-8 encourages confusion between underlying or "native" data -- that is, Unicode -- with the way it is represented over the wire. UTF-8 is merely one means of over-the-wire representation. So, for example, and are two other means of encoding. It's clear that this core distinction really is understood by the authors of this and the Framework documents. However the vocabulary choices and their usage create a problem in the details of the specification. "Internationalization" should mean Unicode, not a particular binary representation of it within 8-bit chunks. The problem, here, is in using the term "internationalization" to refer to a subset of Unicode, that is, the subset that is not ASCII. I strongly suggest saying "Unicode" when intending to refer to the richer set of characters that are the goal of this work, and "UTF-8" when referring to the particular binary encoding of Unicode that is the focus of the SMTP extension work. * Non-UTF-8 Unicode support -- Can a message support Unicode without UTF-8? The existence of and constructs makes clear that the answer is yes. Hence, it should be possible to support Unicode messages, without this SMTP extension. Perhaps this is out of scope for this SMTP extension and perhaps it is handled by the Email Header draft, but I think it worth having this document cite this alternative mode, if only to a) make clear that the alternative exists, and b) make more clear what the specific and strong benefit of this extension is. * Partial enforcement -- Since ASCII is a subset of Unicode, having this extension be in force means that /everything/ is Unicode AND, apparently, is encoded in UTF-8. If the environment created by this extension supports UTF-8, then it supports UTF-8, meaning both ASCII and non-ASCII. Defining rules that depend on having this extension be in force but then still distinguish between ASCII and non-ASCII does not seem to make sense. * Complexity and Heuristics -- In a number of places, the specification defines highly contingent action, where one side can use UTF-8 only if the other side has done so. This makes the enhancement much more complicated than necessary or appropriate. The enhancement needs to work with an all-or-nothing model in which UTF-8 is in force or it is not. And, yes, this appears to be a major change in the model of this specification. My understanding is that these issues were discussed in the working group, but I do not understand why and nearly-heuristic approach was preferred. Instead I recommend the client to signal explicitly when UTF8-encoded addresses are present, such as a option () to the MAIL command. * 5321 vs. 5322 -- The specification seems to confuse -- or at least to mix -- some rules from RFC 5321 versus some from RFC 5322. is the major example. * Since an RFC 5322 message can and often does exist outside of the SMTP environment, any changes to the RFC 5322 specification should be in a document that is separate from this extension specification. This specification can then cite it. I suggest moving all RFC 5322 changes to the Header document[2] and merely citing it here. * UTF8SMTPbis -- The draft uses the string "UTF8SMTPbis" when referencing the SMTP option. The Framework document explains the choice, but IANA Considerations in this document needs to provide explicit handling instructions for it, since this is certain NOT to be the actual string that is used. * Redundant Specification - in a number of places, normative language from other specifications is repeated. This invites divergent specification and is generally out of scope for the current work. To the extent that the current specification needs to refer to normative parts of other specifications, it should do only that: cite it; do not repeat it. For example to highlight an important normative item from another specification, the current specification might describe the "topic" the external language covers, without saying what it says. In other cases, the key point is that the current specification is not changing requirements from another specification; that is what should be said, rather than repeating what that requirement is. In general, these references to external, normative behaviors should be reviewed for relevance to the current work. How is internationalized addresses relevant to the normative detail? * Rule Meta-Naming -- The 'u' preface for revised rules is a reasonable idea, but appears to be problematic. These rules replace existing rules in other specifications. There needs to be an explicit and decision about the handling of this, and it needs to be applied consistently, either directly replacing the rules or else re-naming them consistently, in a fashion that can be parsed (similar to the naming template that was done with RFC5322 obs-* rules.) If an initial string is to be used, I suggest UTF-8-* rather than u*, in order to make it possible to parse this meta-label more reliably. DETAILED COMMENTS: { I have included text from the draft that provides context, but have skipped sequences of text from the draft that do not. } > 1. Introduction > > The Simple Mail Transfer Protocol [RFC5321] provides a negotiation mechanism > about service extension with which clients can discover with which -> by which { or } through which { Either of these would be my stylistic preference. } > server capabilities and make decisions for further processing. This > document use this mechanism to support an internationalized email use -> uses > address. An extended overview of the extension model for { The option enables use of UTF-8 in the email header, beyond just addresses, therefore: } to support...address -> to support internationalized email addresses and internationalized characters for the email header. > internationalized addresses and headers appears in [RFC4952bis], headers -> the email header > referred to as "the framework document" or just as "framework" elsewhere in > this specification. This document specifies an SMTP extension to permit > internationalized email addresses in envelopes, envelopes -> the SMTP envelope { 1. Although 'envelope' is almost certainly unambiguous, its use over the years has been confusing, so it is worth being particularly clear in a specification. 2. The use of plurals in a specification can be confusing. I suggest using the singular form wherever it can work, so that remaining use of plurals becomes more precise. Also note the particular confusion with the word "headers" in email. Since a single email has only a single header, the use of plural means each header from a set of messages... } > and UNICODE characters (encoded in UTF-8) [RFC3629] in headers. headers -> the header > 1.1. Role of This Specification > > The framework document specifies the requirements for, and describes > components of, full internationalization of the electronic mail. A thorough > understanding of the information in that document and in the base Internet > email specifications [RFC5321] [RFC5322] is necessary to understand and > implement this specification. { This means that the Framework document is normative; it needs to be cited as such. Since understanding it is a pre-condition of reading the specification, it also requires that the Framework document be completed before this document. } > This document specifies an element of the email internationalization work, > specifically the definition of an SMTP extension for internationalized email > address transport delivery. { Since it also declares support for internationalization in the message header, it covers more than delivery. In effect, it is a transport-time flag for declaring internationalization of the entire email "environment". I'm not quite sure what exact language change to suggest, however. I also note that it does more than declare support for internationalized addresses: It declares support for encoding them into UTF-8. This is a significant, additional requirement and should be stated explicitly. } > 1.2. Terminology ... > This specification defines only those Augmented BNF (ABNF) [RFC5234] syntax > rules that are different from those of the base email specifications and, > where the earlier rules are upgraded or extended, gives them new names. > When the new rule is a small modification to { The wording in the first part of this paragraph seems awkward. I think the following is clearer: } This specification uses Augmented BNF (ABNF) rules [RFC5234], with some modifications. The modified rules are defined here and the rest are simply imported from [RFC5234]. New names are used, for rules that are upgraded or enhanced. When the ... > the older one, it is typically given a name starting with "u". Rules { The use of "typically" makes the description of this convention problematic. It needs to be always true or else not mentioned. Or perhaps alternative phrasing: } When a new...with "u". -> When a new rule has a name starting with "u", it is a small modification to an older rule. { This asserts what is true and ignores what is not true, such as rules that qualify for the "u" but did not get it... However I now believe that it is important to have a consistent meta-rule for naming the revised rules and that it be applied consistently to all rules that qualify for it. Further, the naming convention should be easily parseable, and therefore more like what is used in RFC5322, to cover "obsolete" rules. I suggest that new rules, here, be named UTF-8-*. To repeat: I believe that /all/ rules that resolve to UTF-8 must be renamed, so that implementers know what they need to change. } > that are undefined here may be found in the base email specifications { The specifications should be cited here, explicitly, even though they have been cited elsewhere. It is important to leave no ambiguity for the reader. } here may be -> here can be {"may" is a reserved word for normative specification. Normative meaning is not based on the use of capitalization. } > 3.2. The UTF8SMTPbis Extension > An SMTP server that announces this extension MUST be prepared to > accept a UTF-8 string [RFC3629] in any position in which RFC 5321 > specifies that a mailbox can appear. That string MUST be parsed only > as specified in [RFC5321], i.e., by separating the mailbox into { The 'i.e.' clause is an example of repeating normative text from another specification. The current document is not empowered to give directives about basic SMTP parsing, nor is there any internationalization requirement that it do so. At most, it should say that the changes specified in this document do not change any other aspect of SMTP processing. } > Once isolated by this parsing process, the local part MUST be > treated as opaque unless the SMTP server is the final delivery Mail > Transfer Agent (MTA). { The statement about handling of is redundant with the base RFC 5321 specification. The statement, here, should be that the handling of is unchanged from the base specification. Again, it should not repeat the normative language, unless it is changing it. If it is changing it, the change needs to be essential for support of internationalized addresses. } > Any domain names that are to be > compared to local strings SHOULD be checked for validity and then > MUST be compared as specified in section 3 of [RFC5891]. { Dictating use of RFC5891 is within scope. Dictating validation seems not to be. So...} -> Any domain name that is to be compared to a local string MUST use Section 3 of [RFC5891] as the basis for comparison. > An SMTP client that receives the UTF8SMTPbis extension keyword in response > to the EHLO command MAY transmit mailbox names within SMTP commands as > internationalized strings in UTF-8 form. It MAY send a UTF-8 header > [RFC5335bis] (which may also include mailbox names in UTF-8). It MAY > transmit the domain parts of mailbox names within SMTP commands or the > message header as A-labels or U-labels { I believe that the use of "MAY" is not correct. This would mean that the receiver needs a means of distinguishing whether the data are UTF-8 or not. This would border on requiring support of a heuristic, but it certainly adds a significant processing overhead and additional software complexity. The only alternative is to specify use of a MAIL command option that declares that the message supports internationalized addresses. Given the approach in this specification, I believe the intent is also to have it mean that UTF-8 encoding is supported. The core issue here is specifying an option which declares a message to have an EAI context for all of the message. So the processing context is fully EAI/UTF-8 or it is legacy net-ASCII. This is considerably simpler to specify and to process, than would be requiring parsing the incoming string and looking for non-ASCII UTF-8. Hence: } An SMTP client...U-labels -> An SMTP client that receives the UTF8SMTPbis extension keyword, in response to the EHLO command, will transmit within SMTP commands as internationalized strings in UTF-8 form. It will send the email header in UTF-8 [RFC5335bis] (which can also include names in UTF-8.) It also will transmit the domain parts of mailbox names within SMTP commands or the message header as A-labels or U-labels { Note - the term "mailbox names" is not defined here or in RFC 5321. In RFC 5321 it appears to be used to mean local-part; however becasue its precise meaning is unclear, I strongly urge NOT using it here at all. Instead I suggest using whatever ABNF rulename is appropriate. This guarantees clarity. Note: I changed 'may' to 'can'. Also, when an ABNF rule is being cited within prose text, such as for , it should be distinguished so that the reader knows it is a formal term. I have used <> to bracket the term mailbox. } > All labels in domain parts of mailbox names which are IDN > forms of A-labels or U-labels MUST be valid. { This is strange. Either it is repeating a normative requirement from SMTP or it is expanding SMTP to require special validation for IDN forms of domain names that is not present for ASCII forms. Neither interpretation seems like the right thing to be doing here. Such a modification to SMTP seems out of scope. Also, the term has different semantic definitions in RFC 5321 and RFC 5322. A strict reading of the differences could be a problem. A loose reading would note that both definitions reduce to include and components that are common to both specifications. I encourage you to review this issue carefully and put a note at the beginning of the document stating explicitly how you have chosen to handle it. My best recommendation is that this document should only refer to RFC 5321 ABNF and that it should move /all/ RFC 5322 modifications or enhancements to the EAI Header document (draft-ietf-eai-rfc5335bis). } > When a Mail User > Agent(MUA) submits a message to a Message Submission Server > ("MSA")[RFC4409], it is the responsibility of the MSA to ensure that > all domain labels are valid. { Given that this specification creates broad systemic effects and given that it needs to refer to components other than an SMTP client or server, it should cite RFC 5598, to give the reader an integrated view of the email service. I'll note that citing 5598 has become common for email specifications; so this is not a controversial suggestion. } >The presence of the UTF8SMTPbis > extension does not change the requirement of RFC 5321 that servers > relaying mail MUST NOT attempt to parse, evaluate, or transform the > local part in any way. { This sentence replicates normative language from a different specification. This is a very bad thing to do, in case the original specification changes its language. I suggest: } The presence of...in any way -> The presence of the UTF8SMTPbis extension does not change RFC 5321 server relaying behaviors. { this retains some text as a flag to the reader, but does not provide the specific semantics, which might change in the original specification. } > If the UTF8SMTPbis SMTP extension is not offered by the server, the SMTP > client MUST NOT transmit an internationalized address and MUST NOT transmit { This appears to prohibit the sending of internationalized addresses that are encoded in ASCII, rather than in UTF-8. The purpose of ASCII encoding is to eliminate the need for infrastructure support for Unicode characters. However the language here appears to be imposing the barrier of infrastructure support. If the concern is sending UTF-8, then that's the language that needs to be used. Messages with ASCII-encoding of internationalized addresses need to be permitted to be sent, without first requiring infrastructure support. } > a mail message containing internationalized mail headers as described in > [RFC5335bis] at any level within its MIME structure [RFC2045] and [RFC2047]. { The prohibition of internationalized mail headers within a MIME structure -- "at any level within its MIME structure" -- is out of scope for the working group and is a /major/ change to SMTP. It is also a really terrible rule! In terms of protocol modeling, it would have been like saying that no one could use MIME until the infrastructure supported it! It is one thing to give the reader a reminder that UTF-8 is illegal in the email header of a message and quite another to attempt to prohibit it in attachments. Attachments already carry all sorts of data. UTF-8 is merely one more type. I believe that there currently no SMTP constraints on the carriage of MIME; I also believe it essential that there not be, since such constraints impede adoption. (That is why MDN support is good and DNS support is poor.) Also note that MIME objects exist outside of email transport and that directives about legal or illegal MIME ought to be separated from SMTP... Also, perhaps mail with UTF-8 in the header needs a different MIME type, such as text/UTF-8-message?... } > 2. It may either reject the message during the SMTP transaction or accept may -> MAY { However, I note that this concerns a SMTP client, not a server. > 3.3. Extended Mailbox Address Syntax > > RFC 5321, Section 4.1.2, defines the syntax of a mailbox entirely in terms > of ASCII characters, using the production for a mailbox and those productions mailbox -> > on which it depends. > > The key changes made by this specification are, informally, to { I don't understand what it means to change RFC 5321 "informally". I think it is intended to mean that the list is not guaranteed to be complete. If so, I suggest wording such as: } -> The key changes made by this specification include: > o Change the definition of "Domain" to permit either the RFC 5321 definition > above or a UTF-8 string representing a DNS label that is conformant with > IDNA definitions [RFC5890]. { "either"??? That sounds completely ambiguous. } > o Change the definition of "Local-part" to permit either the definition > above or a UTF-8 string. That string MUST NOT contain any of the ASCII > characters (either graphics or controls) that are not permitted in "atext"; > it is otherwise unrestricted. { same concern as above. } > According to the description above, the syntax of an internationalized email > mailbox name (address) is defined in ABNF [RFC5234] as follows. > > uMailbox = uLocal-part "@" ( uDomain / address-literal ) ; Replace Mailbox > in RFC 5321, Section 4.1.2 { This implies that the option applies only to RFC5321 and not to RFC5322, but the later rules make clear that 5322 is also supposed to be covered. To repeat: I recommend that all RFC 5322 enhancements and ABNF should be moved to the EAI Header draft and that the SMTP extension should merely cite that draft. Note that RFC5322 is for an object that can and does exist outside of SMTP. Enhancements to RFC5322 well might need to apply when there is no SMTP, or at least long after it is relevant. } > UTF-8-non-ASCII = UTF-8-2 / UTF-8-3 / UTF-8-4 > > UTF-8-2 = > > UTF-8-3 = > > UTF-8-4 = { These rules are also defined in RFC5335 and draft-ietf-eai-rfc5335bis. Citing RFC 3629 is therefore confusing, and possibly can create specification divergence. I suspect that RFC 3629 is not the correct reference, here, since it would imply that RFC5335bis' definitions should be ignored... If RFC 3629 /is/ the correct reference, then I cannot guess why and I cannot guess why it will not create problems with divergent specification. } > The value of "uDomain" SHOULD be verified by IDNA definitions [RFC5890]. If { I do not understand what "SHOULD be verified by IDNA definitions" means. If it means that the uDomain "SHOULDbe verified" then it is out of scope for this specification. There is no reason that SMTP rules concerning verification of Unicode-based domains needs to be different from ASCII-based domains. In particular, verification of a Domain name is specified elsewhere. If it means that the uDomain "should be IDNA complaint" then I do not understand having the exceptions that a "should" allows. For this EAI work, I would think that when UTF8SMTPbis is in force, then IDNA compliance needs to be a MUST. } > that verification fails, the email address with that uDomain MUST NOT be > regarded as a valid email address. MUST NOT be regarded as a valid -> MUST BE regarded as an invalid { Stating this as an affirmative is stronger. } > 3.4. UTF-8 addresses and Response Codes > > An internationalized message MUST NOT be sent to an SMTP server that does > not support UTF8SMTPbis. Such a message should be rejected by a server if > it lacks the support of UTF8SMTPbis. { The first sentence is restating a normative rule already existing in other specifications. The second sentence is simply confusing. If the first sentence is applied, then the server does not support UTF8SMTPbis. I suspect what is actually meant in the second sentence is something like: } If a server receives email encoded in UTF-8, when UTF8SMTPbis is not in force, then the server SHOULD reject the message. { However, this means that the current specification is trying to dictate behavior in the legacy environment, and it cannot do that. I believe the rule that is actually intended is: } An SMTP client MUST only send a message containing UTF-8 to a server that supports UTF8SMTPbis. If the server does not support this option, then the client MUST terminate the delivery attempt with a permanent error, or else find another path. > The three-digit reply codes used in this section are consistent with their > meanings as defined in RFC 5321. { "consistent with"? I hope you actually mean that they are "the same"! Either they are the same as in 5321 or they are changed. } > When messages are rejected because the RCPT command requires an ASCII > address, the response code 553 is used with the meaning "mailbox name not used -> returned, > allowed". When messages are rejected for other reasons, such as the MAIL > command requiring an ASCII address, the response code 550 is used with the { RFC 5321 uses the terms "completion code", "reply code" and "response code" interchangeably. That probably makes the use of "response code" here legal. However the formal ABNF in RFC 5321 defines the rules: For clarity and precision, I strongly recommend using only those terms when referring to replies/responses/completion. Since the current document is cross-referencing a formal construct from another document, it will help the reader to resolve the reference by using only the most formal term.} > meaning "mailbox unavailable". When the server supports enhanced mail { "unavailable" sounds like a temporary error. More generally, the text here says that this set of rejections is "for other reasons". However it does not really mean all other rejections. Since there are many, different "other reasons" and some of them are temporary errors, this text needs to be revised. It needs to make clear the difference in handling temporary versus permanent errors and in particular it needs to define both types in terms that are specific to this enhancement, in order to distinguish them from all other SMTP reply-codes.} > system status codes [RFC3463], response code "X.6.7" [RFC5248] is used, > meaning that "UTF-8 addresses not permitted for that sender/recipient". > > If the response code is issued after the final "." of the DATA command, the > response code "554" is used with the meaning "Transaction failed". When the > server supports enhanced mail system status codes [RFC3463], response code > "X.6.9" [RFC5248] is used, meaning that "UTF-8 header message can not be > transferred to one or more recipient so the message must be rejected". > > 3.5. Body Parts and SMTP Extensions > > There is no ESMTP parameter to assert that a message is an internationalized > message. An SMTP server that requires accurate knowledge of whether a > message is internationalized is required to parse all message header fields > and MIME header fields [RFC2045] and [RFC2047] in the message body. { This is confusing. There is a rule against sending an internationalized message, unless UTF8SMTPbis is in force, but there is no requirement that the server be told explicitly when a message is internationalized??? As noted above, the simple and appropriate action to take is, instead, to have the MAIL command contain an that declares that the message supports internationalized addresses. My understanding is that this was discussed by the working group. Why was this not the choice of the working group? } > While this specification requires that servers support the 8BITMIME > extension [RFC1652] to ensure that servers have adequate handling capability > for 8-bit data and to avoid a number of complex encoding problems, the use > of internationalized addresses obviously does not require non-ASCII body > parts in the MIME message [RFC2045] and [RFC2047]. The UTF8SMTPbis extension > MAY be used with the BODY=8BITMIME parameter if that is appropriate given > the body content or, with the BODY=BINARYMIME parameter, if the server > advertises BINARYMIME [RFC3030] and that is appropriate. { This last sentence is either saying too much or too little. In general, this option does not specify MIME or Body details. Nor does there appear to be any reason that it should. As a consequence, I believe that any text about MIME or the Body needs to be non-normative. It's fine to provide a small amount of pedagogy about the carriage of MIME, but including normative language about it here merely invites confusion and possibly even divergent specifications. Also note that the reference to "BODY=" values does not explicitly cite RFC 1652. So the references require the reader to already know what is being referred to. This should be fixed.} > Assuming that the server advertises UTF8SMTPbis and 8BITMIME, and > receives at least one non-ASCII address, the precise interpretation of > "BODY=8BITMIME", and "BODY=BINARYMIME" in the MAIL command is: 1. If a { My reading of the current specification is that it does not change the handling of email Body or MIME mechanisms. Hence, DO NOT REPEAT NORMATIVE LANGUAGE FROM OTHER SPECIFICATIONS. It invites divergent specification. If the current specification is actually re-defining the semantics or syntax of RFC 1652, then it needs to say so. However my reading of the current specification is that it is quite independent of email Body issues. } > BODY=8BITMIME parameter is present, the header contains UTF-8 characters, > and some or all of the body parts contain 8-bit line-oriented data. 2. If a > BODY=BINARYMIME parameter is present, the header contains UTF-8 characters, > and some or all body parts contain binary data without restriction as to > line lengths or delimiters. { Also note that the items numbered 1 and 2 are not complete sentences. They only contain the conditional clause. "If...." is missing the "then". Hence, no actual "interpretation" is provided, contrary to the promise that is given.} > 3.6. Additional ESMTP Changes and Clarifications > > The information carried in the mail transport process involves addresses > ("mailboxes") and domain names in various contexts in addition to the MAIL > and RCPT commands and extended alternatives to them. In general, the rule > is that, when RFC 5321 specifies a mailbox, this specification expects UTF-8 this specification -> this SMTP extension { "this specification could be misread as meaning RFC 5321, since it is the most recent specification references...} > to be used for the entire string; when RFC 5321 specifies a domain name, the > name SHOULD be in the form of A-label if its raw form is non-ASCII. { the more serious problem is the continuing confusion about ASCII vs. non-ASCII and UTF-8 vs non-UTF-8. Again, I believe that having this extension be in force means that this data are /always/ UTF-8. Hence, it is not a matter of "expects". It is a matter of "requires".} > The following subsections list and discuss all of the relevant cases. > > 3.6.1. The Initial SMTP Exchange > > When an SMTP connection is opened, the server normally sends a "greeting" > response consisting of the 220 response code and some information. The { "normally"? what are the exceptions?} > client then sends the EHLO command. Since the client cannot know whether > the server supports UTF8SMTPbis until after it receives the response from > EHLO, the client must send only ASCII (LDH label [RFC5890] or A-label) > domains in the EHLO command and that, if the server provides domain names in > the EHLO response, they must be in the form of LDH labels or A-labels. > > 3.6.2. Mail eXchangers > > Organizations often authorize multiple servers to accept mail addressed to > them. For example, the organization may itself operate more than one may -> might or may -> can { normative vocabulary can only be used for normative statements. please do a global search and replace, where normative vocabulary are used in non-normative sentences.} > server, and may also or instead have an agreement with other organizations to > accept mail as a backup. Authorized servers are generally listed in MX > records as described in RFC 5321. When more than one server accepts mail for > the domain-part of a mailbox, it is strongly advised that either all or none > of them support the UTF8SMTPbis extension. { This last sentence sounds normative and I believe it should be. So... } it is strongly advised that either all or none of them support -> all or none of them SHOULD support > Otherwise, surprising rejections > can happen during temporary failures, which users might perceive as a serious { Probably not just temporary failures. Having services that are meant to be redundant with each other actually provide different semantic behavior is just plain dangerous. It is essentially guaranteed that they will cause problems.} > 3.6.3. Trace Information > > When an SMTP server receives a message for delivery or further > processing, RFC 5321 requires that it MUST insert trace ("time stamp" > or "Received") information at the beginning of the message content. > For the trace information, this memo updates the time stamp line and > the return path line [RFC5321] formally defined as follows: { Again, don't repeat normative language. I suggest simply deleting the first sentence. } > [RFC5321] formally defined as follows: > > uReturn-path-line = "Return-Path:" FWS uReverse-path ; Replaces > Return-path-line in Section 4.4 of RFC 5321 { On reflection, I think the "u" rule-naming convention is problematic. If the current specification is replacing a rule previously defined elsewhere, it needs to use the same rulename. This is simpler and clearer. Otherwise, all future references to the rule need to use the new name. Rather, where the draft is replacing a rule from another specification, the rule definition includes a comment that cites where the original rule is from; that should be sufficient. } > uReverse-path = uPath / "<>" ; Replace Reverse-path in RFC 5321, section > 4.1.2 > > uPath = "<" [ A-d-l ":" ] uMailbox ">" ; Replace Path in RFC 5321, section > 4.1.2 ; uMailbox is defined in section 3.3 of this document > > A-d-l = { Small improvement: Where a rule is defined elsewhere, I suggest having the descriptive text in the rule say rather than . } > 3.6.4. UTF-8 Strings in Replies > > 3.6.4.1. RCPT Commands > > If an SMTP client follows this specification and sends any RCPT commands > containing non-ASCII addresses, the SMTP server is permitted to use UTF-8 > characters in the email address associated with 251 and 551 response codes, > and the client MUST be able to accept and process them. { I assume that "follows this specification" means that the UTF8SMTPbis option is in force. If so, then say that, because it is simpler and more precise. But, then, it does require declaring /use/ of the option... However the meaning of the text here is odd. It implies that the server is not permitted to use UTF-8 unless it has already received UTF-8, even though the option is in force. I suspect that that is not the specification that is intended. Or, at least, I hope it is not. If it actually /is/ what is intended, it means that the enhanced environment is going to have all sorts of /additional/ conditional code, to check on whether a specific context in the state machine is allowed to act in one way or another. The simple and more reasonable model is that when the extension is in force, UTF-8 is allowed. Period. So... } If an SMTP session is using this extension, then the server is permitted to use UTF-8 characters in the email address associated with 251 and 551 reply-codes, and the client MUST be able to accept and process them. { I chose "SMTP session" to avoid the more complex discussion of the client/server 'negotiation' about using the extension. So, here it is either in force or it isn't and if it is in force, it is for client AND server. } > If a given RCPT > command does not include a non-ASCII envelope address, the server MUST NOT > return a 251 or 551 response containing a non-ASCII mailbox. Instead, it > MUST transform such responses into 250 or 550 responses that do not contain > non-ASCII addresses. { See above. I very strongly disagree with having the complexity this kind of conditional requirement creates. Or else there is a basic issue involved here that the document does not discuss but needs to, to justify the complexity. } > 3.6.4.2. VRFY and EXPN Commands and the UTF-8REPLY Parameter > > If the VRFY and EXPN commands are transmitted with the optional parameter > "UTF-8REPLY", it indicates the client can accept UTF-8 strings in replies to > those commands. This allows the server to use UTF-8 strings in mailbox { Is this extension trying to to say that a client might support UTF8SMTPbis but not be able to access UTF-8 replies??? Under what circumstance is this reasonable? } > names and full names that occur in replies without concern that the client > might be confused by them. An SMTP client that conforms to this { What does it mean to be "confused" by them? Because the extension is in force, we know that the client supports UTF-8. } > specification MUST accept and correctly process replies from the VRFY and > EXPN commands that contain UTF-8 strings. However, the SMTP server MUST NOT > use UTF-8 strings in replies if the SMTP client does not specifically allow > such replies by transmitting this parameter. Most replies do not require { Why is this constraint required? } > that a mailbox name be included in the returned text, and therefore UTF-8 is > not needed in them. Some replies, notably those resulting from successful > execution of the VRFY and EXPN commands, do include the mailbox, making the > provisions of this section important. > > VERIFY (VRFY) and EXPAND (EXPN) command syntaxes are changed to: > > vrfy = "VRFY" SP ( uLocal-part / uMailbox ) [ SP "UTF-8REPLY" ] CRLF ; > uLocal-part and uMailbox are defined in ; Section 3.3 of this document. > > expn = "EXPN" SP ( uLocal-part / uMailbox ) [ SP "UTF-8REPLY" ] CRLF ; > uLocal-part and uMailbox are defined in ; Section 3.3 of this document. { Note that these rules only specify UTF-8 support, without any contingency on use. That is, they do not cover the variability that is described in the prose, and that disparity from the prose specification is an example of the complexity created by having the use of UTF-8 in replies be so contingent on the actual data sent by the client. } > If a normal success response (i.e., 250) is returned, the response MAY > include the full name of the user and MUST include the mailbox of the user. > It MUST be in either of the following forms: > > User Name ; uMailbox is defined in Section 3.3 of this document. > ; User Name can contain non-ASCII characters. > > uMailbox ; uMailbox is defined in Section 3.3 of this document. { "User Name" needs to be specified as an abnf rule. It isn't. This appears to be intended to invoke the RFC 5322 definition of rather than the RFC 5321 definition. In any event, it is creating a semantic change to the response, from RFC 5321, beyond merely allowing UTF-8 characters. } > If the SMTP reply requires UTF-8 strings, but UTF-8 is not allowed in the > reply, and the server supports enhanced mail system status codes [RFC3463], > the enhanced response code is "X.6.8" [RFC5248], meaning "A reply containing > a UTF-8 string is required to show the mailbox name, but that form of > response is not permitted by the client". { "the mailbox name"? which string is that? } > If the SMTP client does not support the UTF8SMTPbisbis extension, but receives > a UTF-8 string in a reply, it may not be able to properly report the reply If a UTF-8 string is sent in a reply, when this extension is not in force, then it is a protocol violation. Period. > [RFC4952bis] Klensin, J. and Y. Ko, "Overview and Framework for > Internationalized Email", RFC 4952, July 2010. RFC4951 -> draft-ietf-eai-frmwrk-4952bis { It is not now, and never will be, RFC 4952; And RFC4952bis is currently dated September 2010. When it is an RFC, it will have a new number. Also, Internet Drafts, including -bis documents, usually follow a different citation labeling convention, such as I-D.rfc4952bis, to make clear that they are an I-D and not an RFC. } [1] draft-ietf-eai-frmwrk-4952bis-10 [2] draft-ietf-eai-rfc5335bis-03 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net Return-Path: X-Original-To: apps-review@core3.amsl.com Delivered-To: apps-review@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 314063A6B93; Wed, 22 Dec 2010 09:22:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qDWh19coFosJ; Wed, 22 Dec 2010 09:22:30 -0800 (PST) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [IPv6:2001:760:0:158::29]) by core3.amsl.com (Postfix) with ESMTP id C03B53A6B91; Wed, 22 Dec 2010 09:22:29 -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.4/8.14.4) with ESMTP id oBMHOHLc001829 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Dec 2010 18:24:17 +0100 (CET) X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 cyrus.dir.garr.it oBMHOHLc001829 DomainKey-Signature: a=rsa-sha1; s=mail; d=garr.it; c=simple; q=dns; b=roKPdmhQpHF81dShcG6jug9nCIiG1uJHA4qDeE/yLidzpQvZRcsXZLAuj83J1P/iE /xobSXJXNu1TnpF1LTnhB8U6GD6anCxXBZWa6h6+c9D0CgtHFkb6KOWd5DptoQ87NTy xL1MSfD127NKaQOdDrjmhfNaYeWd436MxOvJ04w= Date: Wed, 22 Dec 2010 18:24:11 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.elettra.trieste.it To: apps-discuss@ietf.org, ima@ietf.org, draft-ietf-eai-rfc5336bis@tools.ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Thu, 23 Dec 2010 08:08:19 -0800 Cc: Alexey.Melnikov@isode.com Subject: [apps-review] apps-team review of draft-ietf-eai-rfc5336bis X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 17:22:33 -0000 I have been selected as the Applications Area Review Team reviewer for this draft (for background on apps-review, please see http://www.apps.ietf.org/content/applications-area-review-team). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-eai-rfc5336bis Reviewer: Claudio Allocchio (GARR, Italian Research and Academic Network) Review Date: 2010-12-22 IETF Last Call Date: N/A IESG Telechat Date: N/A Summary: The document specifies how to apply internationalization to some SMTP elements, and to some Header elements which depends from the SMTP elements. However there seem to be a discrepancy from what the abstract states, and what is elaborated into the document details: the document also deals with quite a number of elements which involve bodyparts, and affect the whole email legacy system, and beyond, such as logs, traces, and wherever email addresses are used (certificates, etc.). This seems thus to go beyond what the summary states, even this fact is not explicitly discussed. It is unclear thus if this "update" of RFC5321 and RFC5322 is only limited in scope or not. My reading of the document say it goes beyond, and implicitly affects also what is being transported into the email system. This is thus a serious issue to be solved before the document can go to the Standard Track. Another big issue is about blending the boundaries of servers in the transport system (MTAs), clients (UAs) and their roles, when the document specify that servers shall use guessing techniques from looking into bodyparts to understand if what they're transporting is internationalized according to this specification or not. This is IMHO a basic violation of the role distiction in the legacy email system, and affects the MIME model al well. The document quite often repeats rules from other specifications, AND re-describes these rules. This is dangerous (it makes very difficult to keep aligned documents, and will lead to different interpretations) and not needed. The full specification probably needs a serious "english language" revision, because the language issues which I specified in "Minor Issues" seems to be a non neglegible number. I'll try to identify as many as possible and suggest changes. Major Issues: This specification updates a number of SMTP and Headers fields from RFC5321 and RFC5322. However these fields are also used in Gatewaying to other email systems, which are still existing. Section 3.7 in RFC5321 describes specific cases. However this memo provides no clue on possible effect that internationalized fields can have in case gatewaying occurs. Gatewaying functions strongly rely on these values, and the introduction of these modification should describe this scenario, too. I suggest to include a specific section about these issues, and suggest at least a number of possible actions which Gateways can take to survive this change. The EAI WG charter states that in handling email message we shall be "consistent with the long-term view that email with invalid addresses or syntax should be rejected, rather than fixed up in transit between submission servers and delivery servers.". However a number of sections in the specification seem to contradict this, where they suggest actions, by exammining message elements (in the SMTP and in the Headers and in the Bodyparts) in order to try to deliver anyhow. This is a subtle line between maximising the service chance to deliver, and "fixing" things during the transaction, and it can encourage implementors to do many of these acions, instead of stiching to the idea "not supported --> non delivery". Major Issues by sections. Abstract: " This document specifies an SMTP extension for transport and delivery of email messages with internationalized email addresses or header information." "internationalized" is not defined here in details. Sections 1 and 1.2 try to do this, but the language is not crystal clear: "to permit internationalized email addresses in envelopes, and UNICODE characters (encoded in UTF-8) [RFC3629] in headers." Are addresses in envelopes (SMTP envelopes!) also via UNICODE characters encoded in UTF-8? The reference to "the framework document" seem to come too late in the text to ensure the reader fully understand the relationship. 3.2 The UTF8SMTPbis Extension "An SMTP server that announces this extension MUST be prepared to accept a UTF-8 string [RFC3629] in any position in which RFC 5321 specifies that a mailbox can appear." s/mailbox// (it's a definition!). The specification does NOT suggest a preferred order among the 3 possible options when the SMTP server state it does not support UTF8SMTPbis. Having 3 "MAY" options at the same level can create a very uncertain email service behaviour, and a very bad user's experience! This is consistent with what happens in other cases for other "options" in the email system (like DSNs and MDNs), but there should be at least an informative document describing the various scenarios, and giving some guidance to implementors in order to avoid totally incosistent behaviours. If we do not specify a consistent procedure to try the 3 options, in many cases we will just in practice break the concept of universal email common service, creating islands which do not talk to each other. The 3.6.2 section gives some suggestions about this, but this is limited to MX listed servers for a single domain. My concern is more general. In 3.6.2 anyhow the language should be more precise. It states "orgnisations", which something totally undefined from a protocol point of view. MX records refer to "domains", not to "organisations". 3.3. Extended Mailbox Address Syntax The definition of uAtom = 1*ucharacter ; Replace Atom in RFC 5321, Section 4.1.2 ucharacter = atext / UTF8-non-ascii atext = permits that uAtom is either an atext OR an UTF8-non-ascii... which in the end allows a uMailbox to be a mixed contruction where some uAtom is in atext, while some other uAtom is in UTF8-non-ascii AT THE SAME TIME, e.g. a construct like some-ascii.some-UTF8-non-ascii@some-UTF8-non-ascii.some-ascii.tld is allowed. However the distinction here seems to be unneeded, as ASCII is a subset of UTF8. Section 3.6 tries to clarify that this is not allowed; owever there is normative language there apart on SHOULD for the domain name. I think this shold be fixed with a clearer normative specfication. This of course applies also to all other tokens where uAtom is used. 3.5 Body Parts and SMTP Extensions I have problems in understanding why an SMTP server should peek extensively into the message geing transfered to understand that it is handling an interationalzed message. "There is no ESMTP parameter to assert that a message is an internationalized message." in my opinion should be fixed in another way, by ADDING an appropriate ESMTP parameter to state this! This will solve already in the SMTP dialogue many isses which in this specification are handeled by guessing techinques. 3.6.1 "the server normally sends..." --> "the server sends" (sorry... we do not like ABnormal servers!) :-) Minor Issues: 1. Introduction The sentence "This document use this mechanism to support an internationalized email address." defintly needs a better form; if you do not know already know what we are talking about, it can be misleading. "This document uses this mechanism to allow internationalized email addresses support in SMTP elements." 3.1 Framework for the Internationalization Extension - bullet point 3. I do not see any need to state that clients MUST reject... and MUST be fully compliant... etc. This is implicit in any specification. If there is a specific need to add this detailed behaviour (to prevent wrong implementions? why?) either we shall ensure the text is clear and unambiguous, or we shall add an Implementers Note, as it was done in some other RFCs. 3.2 The UTF8SMTPbis Extension same general comment as per 3.1: in general the section states behaviours which do not need to be specified again, because they're alredy described seomewhere else. This might also become a Major issue if the specification of such behaviours are changed elsewhere. Just poit to extrnal references. (it seems editors are worried of implmentors which do not fully undesrtand or know the other email specifications... ) 3.3. Extended Mailbox Address Syntax What does the sentence "..., using the production for a mailbox and those productions on which it depends." mean? I assume you meant , is this correct? 5. Security Considerations there is one more issue: as internationalized items will also result into logs and traces, their presence may affects trouble ticket systems used by security operations teams (CERTs/CSIRTs). And they also can affect quick handling of incidents, has it may require more time to correctly read and understand logs and traces if they are not in current ascii form. This might even be a Major Issue. I propose adding this text in the section, besides pointing to the exteral reference: ---------------------- start of added text Beyond the use inside the email global system (in SMTP envelopes and message headers), internationalized email addresses will also show up inside other scenarios, in particular: - the logging systems of SMTP transactions and other logs to monitor the email systems; - the trouble ticket systems used by Security Teams to manage security incidents, when an email address is involved This will likely require extending support for full UTF8 also into these systems, in order to avoid problems, which could cause also important loss of data, or require to provide an adequate mechanism to map non ASCII strings into them. Another Security aspect to consider is related to the ability by Security Team members to quickly understand/read and identify email addresses from the logs, when they are tracking an incident. Mechanims to automatically and quickly provide the origin or ownership of an internationalized email address shall implemented for use also by log readers which cannot read easily non-ASCII information. --------------------------- end of added text Also, in Security Consideration, there is no mention of the fact that we are changing VRFY/EXPN commands to include internationalized addresses. VRFY/EXPN commands can exist ALSO in an SMTP transaction which is not supoused to transfer an email messages between MTAs. And their use has also do to with Security. Here is an additional text for this: ---------------------- start of added text The SMTP commands VRFY and EXPN are sometimes used in SMTP transactions where there is no message to transfer (by tools used to take automated actions in case potential spam messages are identified). RFC5321 section 3.5 and 7.3 give some detailed description of use and possible behaviours. Implementation of internationalized addrsses can affect also logs and actions by these tools. --------------------------- end of added text Nits: see http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-eai-rfc5336bis-07.txt Best Regards! ------------------------------------------------------------------------------ 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 Return-Path: X-Original-To: apps-review@core3.amsl.com Delivered-To: apps-review@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A42AE3A6768 for ; Sat, 18 Dec 2010 22:15:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.445 X-Spam-Level: X-Spam-Status: No, score=-102.445 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Q517mElWraj for ; Sat, 18 Dec 2010 22:15:46 -0800 (PST) Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by core3.amsl.com (Postfix) with ESMTP id 7A2A53A6765 for ; Sat, 18 Dec 2010 22:15:46 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.239.131]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id oBJ6GO9W004420; Sat, 18 Dec 2010 22:16:30 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1292739392; bh=M+F3GtAw83uaXalEc6y/uV5Vg14=; h=Message-Id:Date:To:From:Subject:Cc:Mime-Version:Content-Type; b=lm5SC2CaJ6vapKleNj108y3g2aREBg9nL1qYx+5Xxs2zShM8HWdMEGhXVOrI7FNgu rMTZ+SYB8Vyz1YiHoSHa/40jakTmmtd6pdxDVZBWqyF86JFfjm1sxHyeSjJZ8caafd ZzhE9SUtH27S202ziAnRecGEP6HSz38gBTgikxZ8= Message-Id: <6.2.5.6.2.20101218214653.0a654338@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 18 Dec 2010 22:15:18 -0800 To: Ted Hardie From: SM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-review@ietf.org Subject: [apps-review] Request for review: draft-lear-iana-timezone-database X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Dec 2010 06:15:48 -0000 Hi Ted, Eliot Lear requested a review of draft-lear-iana-timezone-database-01. The argument for the team to take on this review is because the Applications Area is the main consumer of the work. The review has been assigned to you and is due by January 4, 2010. If you need more time, please contact me. You can find information about the author and WG in the datatracker ( https://datatracker.ietf.org/doc/draft-lear-iana-timezone-database ). Some previous reviews from the Apps-review Team are accessible at http://www.apps.ietf.org/content/apps-review-template The review should be sent to apps-discuss, the author and the IESG. I suggest copying the ietf@ietf.org mailing list as well as the proposal requires wider discussion within the IETF. The subject of the email when submitting the review should be "apps-team review of draft-lear-iana-timezone-database-01". Best regards, -sm Return-Path: X-Original-To: apps-review@core3.amsl.com Delivered-To: apps-review@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F324728C0E9; Mon, 13 Dec 2010 09:59:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.58 X-Spam-Level: X-Spam-Status: No, score=-6.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id twXlJziGgSPQ; Mon, 13 Dec 2010 09:59:59 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 48BD228C0EC; Mon, 13 Dec 2010 09:59:59 -0800 (PST) Received: from [192.168.1.2] (ppp-67-124-89-109.dsl.pltn13.pacbell.net [67.124.89.109]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id oBDI1Via017477 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 13 Dec 2010 10:01:36 -0800 Message-ID: <4D065F79.1010205@dcrocker.net> Date: Mon, 13 Dec 2010 10:01:29 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Eliot Lear References: <252f1508ca393ec830c24fdf94d19cb5@gandalf.orthanc.ca> <4D0545C5.5040608@cisco.com> In-Reply-To: <4D0545C5.5040608@cisco.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, 13 Dec 2010 10:01:37 -0800 (PST) Cc: dhc@dcrocker.net, "Lyndon Nerenberg \(VE6BBM/VE7TFX\)" , apps-review@ietf.org, draft-ietf-eai-rfc5337bis-dsn@tools.ietf.org, discuss@apps.ietf.org, iesg@ietf.org Subject: Re: [apps-review] [apps-discuss] Review of draft-ietf-eai-rfc5337bis-dsn-1 X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 18:00:00 -0000 On 12/12/2010 1:59 PM, Eliot Lear wrote: > On 12/12/10 10:48 PM, Lyndon Nerenberg (VE6BBM/VE7TFX) wrote: >> The base IMAP RFC (3501) made this construct easy and (I think) >> relatively obvious. YMMV. If a grammar extension is globally >> applicable to a parent specification, ... > I take your point but then if you are calling out multiple > specifications someone has to go on a fishing expedition to understand > perhaps the single definition they want out of a specification. +1 I'm sympathetic to the desire to be "efficient" in writing this stuff, but specifications need to be very clear and very unambiguous. Anything that requires extra searching by the reader is a big negative in specification writing. There are different way of satisfying this requirement (that is, avoiding the searching or confusion.) As long as there is almost no change a reader can miss that it's an externally-defined rule nor miss the citation to the external specification for that rule, then it ought to be acceptable. The per-rule citation approach that I've suggested is by far the safest, but yes there are certainly situations where other approaches will work. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net Return-Path: X-Original-To: apps-review@core3.amsl.com Delivered-To: apps-review@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97A903A6E79; Sun, 12 Dec 2010 13:57:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.089 X-Spam-Level: X-Spam-Status: No, score=-110.089 tagged_above=-999 required=5 tests=[AWL=0.510, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SnNgqGni03nn; Sun, 12 Dec 2010 13:57:48 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id A59FC3A6E6B; Sun, 12 Dec 2010 13:57:47 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmAEADfUBE2Q/khLgWdsb2JhbACDXKAqFQEBFiIppgmKSY9RgSGDNXQEink X-IronPort-AV: E=Sophos;i="4.59,333,1288569600"; d="scan'208";a="71478366" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 12 Dec 2010 21:59:23 +0000 Received: from ams3-vpn-dhcp4641.cisco.com (ams3-vpn-dhcp4641.cisco.com [10.61.82.32]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id oBCLxN3J014633; Sun, 12 Dec 2010 21:59:23 GMT Message-ID: <4D0545C5.5040608@cisco.com> Date: Sun, 12 Dec 2010 22:59:33 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: "Lyndon Nerenberg (VE6BBM/VE7TFX)" References: <252f1508ca393ec830c24fdf94d19cb5@gandalf.orthanc.ca> In-Reply-To: <252f1508ca393ec830c24fdf94d19cb5@gandalf.orthanc.ca> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: draft-ietf-eai-rfc5337bis-dsn@tools.ietf.org, discuss@apps.ietf.org, dhc@dcrocker.net, iesg@ietf.org, apps-review@ietf.org Subject: Re: [apps-review] [apps-discuss] Review of draft-ietf-eai-rfc5337bis-dsn-1 X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Dec 2010 21:57:49 -0000 On 12/12/10 10:48 PM, Lyndon Nerenberg (VE6BBM/VE7TFX) wrote: > The base IMAP RFC (3501) made this construct easy and (I think) > relatively obvious. YMMV. If a grammar extension is globally > applicable to a parent specification, I think the subject document > reads easier if the extension is called out at the top of the grammar, > rather than littering each ABNF element with a callout comment. The > alternatives can get very noisy, especially if there is multiple > inheritance involved. I take your point but then if you are calling out multiple specifications someone has to go on a fishing expedition to understand perhaps the single definition they want out of a specification. Eliot Return-Path: X-Original-To: apps-review@core3.amsl.com Delivered-To: apps-review@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 935043A6D3C; Sun, 12 Dec 2010 13:47:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yL+pQRQJi5Bx; Sun, 12 Dec 2010 13:47:27 -0800 (PST) Received: from orthanc.ca (ve6bbm-1-pt.tunnel.tserv13.ash1.ipv6.he.net [IPv6:2001:470:7:139::2]) by core3.amsl.com (Postfix) with ESMTP id 410573A6CEE; Sun, 12 Dec 2010 13:47:27 -0800 (PST) Received: from orthanc.ca (localhost [127.0.0.1]) by orthanc.ca (8.14.4/8.14.4) with ESMTP id oBCLmqAU082703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Dec 2010 13:48:52 -0800 (PST) (envelope-from lyndon@gandalf.orthanc.ca) Received: (from uucp@localhost) by orthanc.ca (8.14.4/8.14.4/Submit) with UUCP id oBCLmq5e082702; Sun, 12 Dec 2010 13:48:52 -0800 (PST) (envelope-from lyndon@gandalf.orthanc.ca) Received: from gandalf.orthanc.ca (frodo.orthanc.ca [172.16.0.3]) by legolas.orthanc.ca (8.14.4/8.14.4) with ESMTP id oBCLmnE4051762; Sun, 12 Dec 2010 13:48:49 -0800 (PST) (envelope-from lyndon@gandalf.orthanc.ca) Message-ID: <252f1508ca393ec830c24fdf94d19cb5@gandalf.orthanc.ca> To: dhc@dcrocker.net, draft-ietf-eai-rfc5337bis-dsn@tools.ietf.org From: "Lyndon Nerenberg (VE6BBM/VE7TFX)" Date: Sun, 12 Dec 2010 13:48:48 -0800 In-Reply-To: <4D050373.40406@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 13 Dec 2010 09:49:06 -0800 Cc: discuss@apps.ietf.org, iesg@ietf.org, apps-review@ietf.org Subject: Re: [apps-review] [apps-discuss] Review of draft-ietf-eai-rfc5337bis-dsn-1 X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Dec 2010 21:47:27 -0000 > So I suggest having a citation for the original version of the rule be included > in a comment associated with the new rule. > > For example: > > generic-address =/ utf-8-enc-addr > ; updates Section 3.2.3 of [RFC3798] FWIW, this is what I did for IMAP Binary (3516); it doesn't seem to have caused any confusion: 7. Formal Protocol Syntax The following syntax specification uses the augmented Backus-Naur Form (ABNF) notation as used in [ABNF], and incorporates by reference the Core Rules defined in that document. This syntax augments the grammar specified in [IMAP4rev1]. append =/ "APPEND" SP mailbox [SP flag-list] [SP date-time] SP literal8 fetch-att =/ "BINARY" [".PEEK"] section-binary [partial] / "BINARY.SIZE" section-binary literal8 = "~{" number "}" CRLF *OCTET ; represents the number of OCTETs ; in the response string. msg-att-static =/ "BINARY" section-binary SP (nstring / literal8) / "BINARY.SIZE" section-binary SP number partial = "<" number "." nz-number ">" resp-text-code =/ "UNKNOWN-CTE" section-binary = "[" [section-part] "]" The base IMAP RFC (3501) made this construct easy and (I think) relatively obvious. YMMV. If a grammar extension is globally applicable to a parent specification, I think the subject document reads easier if the extension is called out at the top of the grammar, rather than littering each ABNF element with a callout comment. The alternatives can get very noisy, especially if there is multiple inheritance involved. --lyndon Return-Path: X-Original-To: apps-review@core3.amsl.com Delivered-To: apps-review@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 431C83A6DEC; Sun, 12 Dec 2010 09:15:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VoAuPyNymyLN; Sun, 12 Dec 2010 09:15:05 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id EA2653A6DE5; Sun, 12 Dec 2010 09:15:04 -0800 (PST) Received: from [192.168.1.2] (ppp-67-124-89-109.dsl.pltn13.pacbell.net [67.124.89.109]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id oBCHGZi5026913 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sun, 12 Dec 2010 09:16:40 -0800 Message-ID: <4D050373.40406@dcrocker.net> Date: Sun, 12 Dec 2010 09:16:35 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: draft-ietf-eai-rfc5337bis-dsn@tools.ietf.org References: <4CFDDD2F.2020201@cisco.com> <4D04FB1A.6030804@cisco.com> In-Reply-To: <4D04FB1A.6030804@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sun, 12 Dec 2010 09:16:41 -0800 (PST) Cc: Apps Discuss , 'IESG' , "apps-review@ietf.org" Subject: Re: [apps-review] [apps-discuss] Review of draft-ietf-eai-rfc5337bis-dsn-1 X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Dec 2010 17:15:07 -0000 On 12/12/2010 8:40 AM, Eliot Lear wrote: >> More importantly, the specification makes use of the =/ operator from RFC >> 5234, but for constructs that it does not control. I don't know if this was >> the original intent or not, but I am a little concerned that use of =/ in a >> construct that is not wholly controlled by a single specification is asking >> for confusion later. This is an optional specification, right? > > After discussing this a bit with Dave Crocker, perhaps this problem is all in my > head. Therefore, I recommend no change to the spec on this point. While I believe the current specification's use of =/ is not only legal but that it is in fact exactly the sort of use that was intended, I also note that it's a pretty unusual ABNF construct and that it might invite some confusion. Cross-referencing a rule from another specification strikes me as a big deal and that it's worth helping the reader as much as possible. So I suggest having a citation for the original version of the rule be included in a comment associated with the new rule. For example: generic-address =/ utf-8-enc-addr ; updates Section 3.2.3 of [RFC3798] d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net Return-Path: X-Original-To: apps-review@core3.amsl.com Delivered-To: apps-review@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 130DE28C0EF; Sun, 12 Dec 2010 08:39:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.035 X-Spam-Level: X-Spam-Status: No, score=-110.035 tagged_above=-999 required=5 tests=[AWL=0.563, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OBAtIES2YKFi; Sun, 12 Dec 2010 08:39:13 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id C477028B23E; Sun, 12 Dec 2010 08:39:12 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.59,332,1288569600"; d="scan'208,217";a="15107511" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 12 Dec 2010 16:40:48 +0000 Received: from ams3-vpn-dhcp4641.cisco.com (ams3-vpn-dhcp4641.cisco.com [10.61.82.32]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id oBCGel7F004241; Sun, 12 Dec 2010 16:40:47 GMT Message-ID: <4D04FB1A.6030804@cisco.com> Date: Sun, 12 Dec 2010 17:40:58 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Eliot Lear , Apps Discuss , "apps-review@ietf.org" , draft-ietf-eai-rfc5337bis-dsn@tools.ietf.org, "'IESG'" References: <4CFDDD2F.2020201@cisco.com> In-Reply-To: <4CFDDD2F.2020201@cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: multipart/alternative; boundary="------------020207080800030402090202" Subject: Re: [apps-review] [apps-discuss] Review of draft-ietf-eai-rfc5337bis-dsn-1 X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Dec 2010 16:39:14 -0000 This is a multi-part message in MIME format. --------------020207080800030402090202 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit I wrote: On 12/7/10 8:07 AM, Eliot Lear wrote: > I have been selected as the Applications Area Review Team reviewer for > this draft (for background on apps-review, please see > http://www.apps.ietf.org/content/applications-area-review-team). > Please resolve these comments along with any other Last Call comments > you may receive. Please wait for direction from your document shepherd > or AD before posting a new version of the draft. > > Document: draft-ietf-eai-rfc5337bis-01 > Title: Internationalized Delivery Status and Disposition Notifications > Reviewer: Eliot Lear > Review Date: 7 Dec 2010 > ... > More importantly, the specification makes use of the =/ operator from > RFC 5234, but for constructs that it does not control. I don't know > if this was the original intent or not, but I am a little concerned > that use of =/ in a construct that is not wholly controlled by a > single specification is asking for confusion later. This is an > optional specification, right? After discussing this a bit with Dave Crocker, perhaps this problem is all in my head. Therefore, I recommend no change to the spec on this point. Eliot --------------020207080800030402090202 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit I wrote:

On 12/7/10 8:07 AM, Eliot Lear wrote:
I have been selected as the Applications Area Review Team reviewer for this draft (for background on apps-review, please see http://www.apps.ietf.org/content/applications-area-review-team).
Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft.

Document: draft-ietf-eai-rfc5337bis-01
Title: Internationalized Delivery Status and Disposition Notifications
Reviewer: Eliot Lear
Review Date: 7 Dec 2010


...

More importantly, the specification makes use of the =/ operator  from RFC 5234, but for constructs that it does not control.  I don't know if this was the original intent or not, but I am a little concerned that use of =/ in a construct that is not wholly controlled by a single specification is asking for confusion later.  This is an optional specification, right?

After discussing this a bit with Dave Crocker, perhaps this problem is all in my head.  Therefore, I recommend no change to the spec on this point.

Eliot
--------------020207080800030402090202-- Return-Path: X-Original-To: apps-review@core3.amsl.com Delivered-To: apps-review@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63BED28C0D7 for ; Mon, 6 Dec 2010 16:35:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.889 X-Spam-Level: X-Spam-Status: No, score=-102.889 tagged_above=-999 required=5 tests=[AWL=-2.149, BAYES_20=-0.74, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xEQCND0Cn-of for ; Mon, 6 Dec 2010 16:35:15 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id 9527B3A68DC for ; Mon, 6 Dec 2010 16:35:15 -0800 (PST) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Mon, 6 Dec 2010 16:36:40 -0800 From: "Murray S. Kucherawy" To: "apps-review@ietf.org" Date: Mon, 6 Dec 2010 16:36:39 -0800 Thread-Topic: Request for review: draft-ietf-eai-rfc5335bis Thread-Index: AcuTgCKYM8FSU+q/QhSkuz8QGelcagCJpVkQ Message-ID: References: <6.2.5.6.2.20101203221116.0ad42aa8@elandnews.com> In-Reply-To: <6.2.5.6.2.20101203221116.0ad42aa8@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-review] Request for review: draft-ietf-eai-rfc5335bis X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2010 00:35:18 -0000 > -----Original Message----- > From: SM [mailto:sm+ietf@elandsys.com] > Sent: Friday, December 03, 2010 10:46 PM > To: Dave Cridland; Murray S. Kucherawy > Cc: apps-review@ietf.org > Subject: Request for review: draft-ietf-eai-rfc5335bis >=20 > Hi Dave, Murray, >=20 > Alexey requested a review of draft-ietf-eai-rfc5335bis from the EAI > WG. The assignment is due before December 16. > [...] Roger. Expect it sometime next week. -MSK Return-Path: X-Original-To: apps-review@core3.amsl.com Delivered-To: apps-review@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D6023A68D1 for ; Mon, 6 Dec 2010 13:54:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.436 X-Spam-Level: X-Spam-Status: No, score=-102.436 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BkKu+uYjScy7 for ; Mon, 6 Dec 2010 13:54:23 -0800 (PST) Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by core3.amsl.com (Postfix) with ESMTP id 91D313A68CB for ; Mon, 6 Dec 2010 13:54:23 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.232.174]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id oB6LtR5U000681; Mon, 6 Dec 2010 13:55:45 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1291672547; bh=0IMUTrnV+CYUXT4WSqafgmccweU=; h=Message-Id:Date:To:From:Subject:Cc:Mime-Version:Content-Type; b=QVNGExriFfYoRWRPRd3w3vB/zxAWIwXjxRYvDUN3ADLQZpdMJzA/Cws4Ssj5bVAl8 XkhPADCcxabKckbi0XiRnzg5UMwc+dqJEBeC6Fve8nJKsR3UR10r/4oaJyUKsNrWtB EW2HxzLVEblsKh2apKtXNw49PgpthD2MGU8UxgTQ= Message-Id: <6.2.5.6.2.20101206134723.0be346b0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 06 Dec 2010 13:50:53 -0800 To: Joe Hildebrand From: SM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-review@ietf.org Subject: [apps-review] Reminder: request for review of draft-salowey-secsh-uri X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2010 21:54:24 -0000 Hi Joe, I posted a message to the apps-review mailing list on November 29 [1] where the review of draft-salowey-secsh-uri was assigned to you. I am resending the request in case it has been missed. The review is due before December 16. Best regards, -sm 1. http://www.ietf.org/mail-archive/web/apps-review/current/msg00347.html Return-Path: X-Original-To: apps-review@core3.amsl.com Delivered-To: apps-review@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BF0C3A68D2 for ; Mon, 6 Dec 2010 13:54:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.427 X-Spam-Level: X-Spam-Status: No, score=-102.427 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNiJLEUImHq9 for ; Mon, 6 Dec 2010 13:54:20 -0800 (PST) Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by core3.amsl.com (Postfix) with ESMTP id 7EFBE3A68D1 for ; Mon, 6 Dec 2010 13:54:20 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.232.174]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id oB6LtR5S000681; Mon, 6 Dec 2010 13:55:42 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1291672544; bh=z2yGkpzCbLb0OVzjbrl8aECy998=; h=Message-Id:Date:To:From:Subject:Cc:Mime-Version:Content-Type; b=LG9i+n6GO3452iw8nk6kh2jwxd70dXfhvYD3/Mudu+aUFD5I5GAMPYwT1SKMGIG4g bLz2J1z2Im/CFRjLddm/JhAsUUFDuhBSfGB5KkLf+eK7kZtUGvP+1/wSQzGwkRuOI3 IAOEK46o8vWtCqvKiV0ri+R4sCe15ztmN0JryC0g= Message-Id: <6.2.5.6.2.20101206134344.0bf4a788@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 06 Dec 2010 13:47:07 -0800 To: Tim Bray From: SM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-review@ietf.org Subject: [apps-review] Request for review: draft-merrick-jms-uri X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2010 21:54:21 -0000 Hi Tim, Alexey requested a review of draft-merrick-jms-uri. The review has been assigned to you and is due before December 16. You can find information about the author and WG in the datatracker ( https://datatracker.ietf.org/doc/draft-merrick-jms-uri ). Some previous reviews from the Apps-review Team are accessible at http://www.apps.ietf.org/content/apps-review-template The review should be sent to apps-discuss, the author, WG Chair and document shepherd, if applicable, and the IESG. The subject of the email when submitting the review should be "apps-team review of draft-merrick-jms-uri-10". Best regards, -sm P.S. This draft has been previously reviewed by the Apps Area Review Team Return-Path: X-Original-To: apps-review@core3.amsl.com Delivered-To: apps-review@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBBB73A68CE for ; Mon, 6 Dec 2010 13:54:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.417 X-Spam-Level: X-Spam-Status: No, score=-102.417 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UHCTGbs1sHRw for ; Mon, 6 Dec 2010 13:54:14 -0800 (PST) Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by core3.amsl.com (Postfix) with ESMTP id A27AD3A68BE for ; Mon, 6 Dec 2010 13:54:14 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.232.174]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id oB6LtR5O000681; Mon, 6 Dec 2010 13:55:36 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1291672538; bh=ylgVmW/Z1uPJduBlHYRtK/tcwxc=; h=Message-Id:Date:To:From:Subject:Cc:Mime-Version:Content-Type; b=sHHmGaxVIAW4skcgwzvF0XAo2aD2hchdYH/17RmlCltBonu0CyDHt9M/SSwrCxA1u +ndTr6BhvgbOYbX+/gkpDlzBCs6vjG/4Ba1lTvooYbY+rMd8ek4W1uJVh+UzDOYx4H TGVpovg01td3P73Ck4DVAhSC51dHj5kROG9+7/uk= Message-Id: <6.2.5.6.2.20101206133912.0cc142f0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 06 Dec 2010 13:41:30 -0800 To: Aaron Stone From: SM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-review@ietf.org Subject: [apps-review] Request for review: draft-ietf-ipfix-mediators-framework X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2010 21:54:18 -0000 Hi Aaron, Alexey requested a review of draft-ietf-ipfix-mediators-framework. The review has been assigned to you and is due before December 16. You can find information about the author and WG in the datatracker ( https://datatracker.ietf.org/doc/draft-ietf-ipfix-mediators-framework ). Some previous reviews from the Apps-review Team are accessible at http://www.apps.ietf.org/content/apps-review-template The review should be sent to apps-discuss, the author, WG Chair and document shepherd, if applicable, and the IESG. The subject of the email when submitting the review should be "apps-team review of draft-ietf-ipfix-mediators-framework-09". Best regards, -sm Return-Path: X-Original-To: apps-review@core3.amsl.com Delivered-To: apps-review@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A39C3A68C7 for ; Mon, 6 Dec 2010 13:54:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.406 X-Spam-Level: X-Spam-Status: No, score=-102.406 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZTHBaSmR2DzM for ; Mon, 6 Dec 2010 13:54:11 -0800 (PST) Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by core3.amsl.com (Postfix) with ESMTP id A0AF33A68BE for ; Mon, 6 Dec 2010 13:54:11 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.232.174]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id oB6LtR5M000681; Mon, 6 Dec 2010 13:55:33 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1291672535; bh=BTZvAkUW2i+z0fWW+8f0VTETo14=; h=Message-Id:Date:To:From:Subject:Cc:Mime-Version:Content-Type; b=c+wjUtp2k2Ld1CI9/CtQ72BxrJlvPQ6+J0VoHrbEv6QunmvyQO97bS+9BMzY23G2S AjCTgZ6FCMlZW7ODD905gY2UNEtoKAFppQcZyKu/JePV/BKJweLgtFz8gIKFejvdJA 81nMITXc8tjRUOzeKW7AQc1SbU8KzpRiPBwrLwSc= Message-Id: <6.2.5.6.2.20101206133612.0bf4a1e8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 06 Dec 2010 13:39:10 -0800 To: Kurt Zeilenga From: SM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-review@ietf.org Subject: [apps-review] Request for review: draft-ietf-sipcore-sec-flows X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2010 21:54:14 -0000 Hi Kurt, Alexey requested a review of draft-ietf-sipcore-sec-flows. The review has been assigned to you and is due before December 16. You can find information about the author and WG in the datatracker ( https://datatracker.ietf.org/doc/draft-ietf-sipcore-sec-flows ). Some previous reviews from the Apps-review Team are accessible at http://www.apps.ietf.org/content/apps-review-template The review should be sent to apps-discuss, the author, WG Chair and document shepherd, if applicable, and the IESG. The subject of the email when submitting the review should be "apps-team review of draft-ietf-sipcore-sec-flows-06". Best regards, -sm Return-Path: X-Original-To: apps-review@core3.amsl.com Delivered-To: apps-review@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 928163A6AB2 for ; Sat, 4 Dec 2010 09:06:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.393 X-Spam-Level: X-Spam-Status: No, score=-102.393 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eBrT6PiPoPzj for ; Sat, 4 Dec 2010 09:06:43 -0800 (PST) Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by core3.amsl.com (Postfix) with ESMTP id 05B0D3A696C for ; Sat, 4 Dec 2010 09:06:42 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.239.143]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id oB4H7tIC016066; Sat, 4 Dec 2010 09:08:01 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1291482482; bh=GE4J7fRhUAuRKf11SgzbVQbIVAo=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=C22UwFcRzJaz29VBVjIi6GO1UJtf3funUtJFbZHXGhrgY+zWXuPqAtfpcjOXraWTC KMYMbgOFs9WdojpGZ+AJWwt2drNJ9jtfYSABHW/jkJPmh0YZrvAoy2MNrciU0nbQSP 5blu4G2ENic0xCqxA6tlv++JVB625sI2ZZxyu20k= Message-Id: <6.2.5.6.2.20101204085502.0be8a1d8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 04 Dec 2010 09:02:04 -0800 To: Alexey Melnikov From: SM In-Reply-To: <4CFA6D2F.9090000@isode.com> References: <6.2.5.6.2.20101203224633.0a7edaf0@elandnews.com> <4CFA38B3.9060105@dcrocker.net> <4CFA6D2F.9090000@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-review@ietf.org Subject: Re: [apps-review] Request for review: draft-ietf-eai-rfc5336bis X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Dec 2010 17:06:44 -0000 Hi Alexey, At 08:32 04-12-10, Alexey Melnikov wrote: >I would even prefer independent reviews, i.e. when whoever does the >review last doesn't look at the first review. This reminds me of the prisoner's dilemma (see RFC 970). :-) Best regards, -sm Return-Path: X-Original-To: apps-review@core3.amsl.com Delivered-To: apps-review@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E8F63A6AAB for ; Sat, 4 Dec 2010 08:44:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.058 X-Spam-Level: X-Spam-Status: No, score=-2.058 tagged_above=-999 required=5 tests=[AWL=-0.542, BAYES_00=-2.599, URIBL_RHS_DOB=1.083] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7zope1AhcTnt for ; Sat, 4 Dec 2010 08:44:23 -0800 (PST) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [IPv6:2001:760:0:158::29]) by core3.amsl.com (Postfix) with ESMTP id 834843A68D2 for ; Sat, 4 Dec 2010 08:44:22 -0800 (PST) Received: from webcam1-all.garrtest.units.it ([140.105.201.5]) (authenticated bits=0) by cyrus.dir.garr.it (8.14.4/8.14.4) with ESMTP id oB4GjTAX077017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 4 Dec 2010 17:45:30 +0100 (CET) X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 cyrus.dir.garr.it oB4GjTAX077017 DomainKey-Signature: a=rsa-sha1; s=mail; d=garr.it; c=simple; q=dns; b=Fg6alxOYIW9uDkPejztZrm+X3Mg9ob77khIkkcOSd9IVK5AbiVz8C5zpMnAOA2zCV 21SpcgodjQaE3lT00Woo5hJRAR2Y6bDf/0roS3HZKiPlHV1L/VJW33vbnfpv4JL0d5T 7JrWQIzrZj6UJbzqlNrDVc4d0kXrhkOPj7EjHiY= Date: Sat, 4 Dec 2010 17:45:29 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@webcam1-all.garrtest.units.it To: dcrocker@bbiw.net In-Reply-To: <4CFA6EBD.7010706@dcrocker.net> Message-ID: References: <6.2.5.6.2.20101203224633.0a7edaf0@elandnews.com> <4CFA38B3.9060105@dcrocker.net> <4CFA6D2F.9090000@isode.com> <4CFA6EBD.7010706@dcrocker.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Claudio Allocchio , apps-review@ietf.org Subject: Re: [apps-review] Request for review: draft-ietf-eai-rfc5336bis X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Dec 2010 16:44:26 -0000 > On 12/4/2010 8:32 AM, Alexey Melnikov wrote: >> I would even prefer independent reviews, i.e. when whoever does the review >> last >> doesn't look at the first review. > > except that the second person will see that they are the slow one... he he... it is not a race... it's a careful review. OK, let's stop chatting on a cold windy winter day... and let' start reading them. ;-) > > d/ > -- > > Dave Crocker > Brandenburg InternetWorking > bbiw.net > ------------------------------------------------------------------------------ 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 Return-Path: X-Original-To: apps-review@core3.amsl.com Delivered-To: apps-review@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EB3F3A6AEC for ; Sat, 4 Dec 2010 08:38:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.066 X-Spam-Level: X-Spam-Status: No, score=-6.066 tagged_above=-999 required=5 tests=[AWL=-0.550, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, URIBL_RHS_DOB=1.083] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WoN3Ik8HOJFi for ; Sat, 4 Dec 2010 08:38:25 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id AF38B3A6AAB for ; Sat, 4 Dec 2010 08:38:23 -0800 (PST) Received: from [192.168.1.3] (ppp-67-124-89-109.dsl.pltn13.pacbell.net [67.124.89.109]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id oB4GdXj5013902 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sat, 4 Dec 2010 08:39:39 -0800 Message-ID: <4CFA6EBD.7010706@dcrocker.net> Date: Sat, 04 Dec 2010 08:39:25 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Alexey Melnikov References: <6.2.5.6.2.20101203224633.0a7edaf0@elandnews.com> <4CFA38B3.9060105@dcrocker.net> <4CFA6D2F.9090000@isode.com> In-Reply-To: <4CFA6D2F.9090000@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sat, 04 Dec 2010 08:39:39 -0800 (PST) Cc: Claudio Allocchio , apps-review@ietf.org Subject: Re: [apps-review] Request for review: draft-ietf-eai-rfc5336bis X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Dec 2010 16:38:32 -0000 On 12/4/2010 8:32 AM, Alexey Melnikov wrote: > I would even prefer independent reviews, i.e. when whoever does the review last > doesn't look at the first review. except that the second person will see that they are the slow one... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net Return-Path: X-Original-To: apps-review@core3.amsl.com Delivered-To: apps-review@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9D7B3A6AAC for ; Sat, 4 Dec 2010 08:32:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K8wsgGyMp4Bb for ; Sat, 4 Dec 2010 08:32:01 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id B4BEA3A6AAB for ; Sat, 4 Dec 2010 08:32:00 -0800 (PST) Received: from [92.40.162.159] (92.40.162.159.sub.mbb.three.co.uk [92.40.162.159]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sat, 4 Dec 2010 16:33:16 +0000 Message-ID: <4CFA6D2F.9090000@isode.com> Date: Sat, 04 Dec 2010 16:32:47 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: dcrocker@bbiw.net, Claudio Allocchio References: <6.2.5.6.2.20101203224633.0a7edaf0@elandnews.com> <4CFA38B3.9060105@dcrocker.net> In-Reply-To: <4CFA38B3.9060105@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: apps-review@ietf.org Subject: Re: [apps-review] Request for review: draft-ietf-eai-rfc5336bis X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Dec 2010 16:32:01 -0000 Dave CROCKER wrote: > On 12/4/2010 1:00 AM, Claudio Allocchio wrote: > >> one question very pragmatic: I assume you expect a single review >> compiled by the >> two of us: correct? As it applies also to the other couples I post it >> to the list. > > Seems like (significant) extra work, for no obvious benefit. > > I don't see any problem with having more than one review, even if the > reviews diverge in their views. I agree. I would even prefer independent reviews, i.e. when whoever does the review last doesn't look at the first review. Return-Path: X-Original-To: apps-review@core3.amsl.com Delivered-To: apps-review@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3A8C28C0E5 for ; Sat, 4 Dec 2010 08:03:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.378 X-Spam-Level: X-Spam-Status: No, score=-102.378 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBprNbXuFz4o for ; Sat, 4 Dec 2010 08:03:07 -0800 (PST) Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by core3.amsl.com (Postfix) with ESMTP id AAF0B28C0E1 for ; Sat, 4 Dec 2010 08:03:07 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.239.143]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id oB4G44Ps012743; Sat, 4 Dec 2010 08:04:10 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1291478652; bh=Rmij7umi9lUSesRcugHFGlfn+s4=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=hEN445Dx/lQdH/eqvCWoPSd0UehsW0Xn/6F8NZPov8Ylcq4yJk/Qr1JoS8uMGlk9c vf6RluexXgLsoOzqLcd4QitoiOztAdT+YWVffbzHrO6mZ5+AY44AHC7GIUju3t3uPa ZXarjlu2s9LTnsFQmVhCGB1CMXJVRzevpq/fXMjo= Message-Id: <6.2.5.6.2.20101204065022.0ca0f1f0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 04 Dec 2010 08:03:04 -0800 To: Claudio Allocchio From: SM In-Reply-To: References: <6.2.5.6.2.20101203224633.0a7edaf0@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Dave Crocker , apps-review@ietf.org Subject: [apps-review] Review of EAI WG drafts (was: Request for review: draft-ietf-eai-rfc5336bis) X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Dec 2010 16:03:09 -0000 Hi Claudio, At 01:00 04-12-10, Claudio Allocchio wrote: >one question very pragmatic: I assume you expect a single review >compiled by the two of us: correct? As it applies also to the >other couples I post it to the list. The request from the AD was to have the drafts reviewed by team members with an email background. The drafts would also benefit from a careful review of the ABNF; hence the selection of at least one reviewer with a knowledge of ABNF. There are two alternatives: (a) Have the reviewers coordinate the work and compile one review. (b) Each reviewer submits a review. A joint review requires coordination between the two reviewers and it may require further discussion to come up with a common view. Having separate reviews encourages a diversity of views. There are advantages and disadvantages to that. I left it to each set of reviewers to determine how they wanted to get the work done. The only requirement is that there should be a detailed review of the ABNF. As Dave Crocker does not have any problem with having more than one review for draft-ietf-eai-rfc5336bis, I suggest that you both submit separate reviews. Other reviewers are free to follow whichever of the two alternatives they prefer. Best regards, -sm P.S. I did not take on any of the assignments as I have already commented on some of the EAI WG drafts. Return-Path: X-Original-To: apps-review@core3.amsl.com Delivered-To: apps-review@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E618728C0E3 for ; Sat, 4 Dec 2010 04:47:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=-0.583, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, URIBL_RHS_DOB=1.083] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E-OaRcdFIQsD for ; Sat, 4 Dec 2010 04:47:58 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 135B928C0CF for ; Sat, 4 Dec 2010 04:47:58 -0800 (PST) Received: from [192.168.1.3] (ppp-67-124-89-109.dsl.pltn13.pacbell.net [67.124.89.109]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id oB4Cn1IE029603 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sat, 4 Dec 2010 04:49:06 -0800 Message-ID: <4CFA38B3.9060105@dcrocker.net> Date: Sat, 04 Dec 2010 04:48:51 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Claudio Allocchio References: <6.2.5.6.2.20101203224633.0a7edaf0@elandnews.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]); Sat, 04 Dec 2010 04:49:07 -0800 (PST) Cc: Dave Crocker , apps-review@ietf.org Subject: Re: [apps-review] Request for review: draft-ietf-eai-rfc5336bis X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Dec 2010 12:47:59 -0000 On 12/4/2010 1:00 AM, Claudio Allocchio wrote: > one question very pragmatic: I assume you expect a single review compiled by the > two of us: correct? As it applies also to the other couples I post it to the list. Seems like (significant) extra work, for no obvious benefit. I don't see any problem with having more than one review, even if the reviews diverge in their views. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net Return-Path: X-Original-To: apps-review@core3.amsl.com Delivered-To: apps-review@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A08963A6A83 for ; Sat, 4 Dec 2010 00:59:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ux8QdAcTV2S for ; Sat, 4 Dec 2010 00:59:38 -0800 (PST) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [IPv6:2001:760:0:158::29]) by core3.amsl.com (Postfix) with ESMTP id F16173A6A82 for ; Sat, 4 Dec 2010 00:59:37 -0800 (PST) Received: from webcam1-all.garrtest.units.it ([140.105.201.5]) (authenticated bits=0) by cyrus.dir.garr.it (8.14.4/8.14.4) with ESMTP id oB490YDq070820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 4 Dec 2010 10:00:36 +0100 (CET) X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 cyrus.dir.garr.it oB490YDq070820 DomainKey-Signature: a=rsa-sha1; s=mail; d=garr.it; c=simple; q=dns; b=YtIrao8dLoGCM4lCf+xjFhF84rh+XF7t1W7xhpt1AWjGZqg6FrkjAPN22k09fB3vv r3WOwUDiaY8lswAeee9woYYlypRU/8lVOs39f4qGGX1oNNnNWZkQDW4cdRZFqsbcSR6 QEhFHW/MqI2H4eqX0g+TxY+3ma2zOrmfjM89/PI= Date: Sat, 4 Dec 2010 10:00:34 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@webcam1-all.garrtest.units.it To: SM In-Reply-To: <6.2.5.6.2.20101203224633.0a7edaf0@elandnews.com> Message-ID: References: <6.2.5.6.2.20101203224633.0a7edaf0@elandnews.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: apps-review@ietf.org, Claudio Allocchio , Dave Crocker Subject: Re: [apps-review] Request for review: draft-ietf-eai-rfc5336bis X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Dec 2010 08:59:39 -0000 On Fri, 3 Dec 2010, SM wrote: > Hi Claudio, Dave, > > Alexey requested a review of draft-ietf-eai-rfc5336bis from the EAI WG. The > assignment is due before December 16. ok. > The review is exceptionally being assigned to two people instead of one. > Please review the ABNF too. If you have any questions about the assignment, > please post a message to the apps-review mailing list or email me. one question very pragmatic: I assume you expect a single review compiled by the two of us: correct? As it applies also to the other couples I post it to the list. best regards, ------------------------------------------------------------------------------ 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 Return-Path: X-Original-To: apps-review@core3.amsl.com Delivered-To: apps-review@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B762C3A6A56 for ; Fri, 3 Dec 2010 22:53:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.457 X-Spam-Level: X-Spam-Status: No, score=-101.457 tagged_above=-999 required=5 tests=[AWL=-0.818, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7GDFLYjypAVf for ; Fri, 3 Dec 2010 22:53:36 -0800 (PST) Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by core3.amsl.com (Postfix) with ESMTP id 58D713A6A6D for ; Fri, 3 Dec 2010 22:53:36 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.239.82]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id oB46sR1q030557; Fri, 3 Dec 2010 22:54:37 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1291445679; bh=FjRHnD1kzC64mqYOMSD4p6TO8ns=; h=Message-Id:Date:To:From:Subject:Cc:Mime-Version:Content-Type; b=zPwtwOfnxenJmV7sMHBgklrL8V6iBfxhvEbBXImCBEIBlbbqvbCPdRNe/dFUMqMd4 7lhpBGazGKLPXTHoNSPpaglGgVHv2fvZ5MiN9HDUmiqQG/XHwcp7nDnCxOnikVa24/ C+previrdwcbZKo2QWf/etG7vw+LY3mhVOcty6Y8= Message-Id: <6.2.5.6.2.20101203224633.0a7edaf0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 03 Dec 2010 22:49:14 -0800 To: Claudio Allocchio , Dave Crocker From: SM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-review@ietf.org Subject: [apps-review] Request for review: draft-ietf-eai-rfc5336bis X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Dec 2010 06:53:39 -0000 Hi Claudio, Dave, Alexey requested a review of draft-ietf-eai-rfc5336bis from the EAI WG. The assignment is due before December 16. The review is exceptionally being assigned to two people instead of one. Please review the ABNF too. If you have any questions about the assignment, please post a message to the apps-review mailing list or email me. You can find information about the author and WG in the datatracker ( http://datatracker.ietf.org/doc/draft-ietf-eai-rfc5336bis/ ). Some previous reviews from the Apps-review Team are accessible at http://www.apps.ietf.org/content/apps-review-template The review should be sent to apps-discuss, the author, WG Chairs and document shepherd, if applicable, and the IESG. The subject of the email when submitting the review should be "apps-team review of draft-ietf-eai-rfc5336bis-07". Best regards, -sm Return-Path: X-Original-To: apps-review@core3.amsl.com Delivered-To: apps-review@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 952103A6A60 for ; Fri, 3 Dec 2010 22:53:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.605 X-Spam-Level: X-Spam-Status: No, score=-101.605 tagged_above=-999 required=5 tests=[AWL=-0.966, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z56WMPRHni5V for ; Fri, 3 Dec 2010 22:53:27 -0800 (PST) Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by core3.amsl.com (Postfix) with ESMTP id D85AF3A6A50 for ; Fri, 3 Dec 2010 22:53:27 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.239.82]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id oB46sR1s030557; Fri, 3 Dec 2010 22:54:41 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1291445683; bh=loYEwP5qeDV1zvhgD+o5ovYqrOk=; h=Message-Id:Date:To:From:Subject:Cc:Mime-Version:Content-Type; b=HeL2ojvC07UujlUz2BHk5pWnpJw1qtZYYBzQBzgrrp+qSjULox5rERF14PNRB/own IkVyVnrVa+ysW9rldfGAC0DOzJd1yxyFG+MaxPPR435QOChUtkhh2JU7hHGexzS9iG tSVn2BF7ojI4v6niSNozmlKCT+rKlwSlbxEp/HEk= Message-Id: <6.2.5.6.2.20101203224925.0ad23338@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 03 Dec 2010 22:54:12 -0800 To: Eliot.Lear.lear@cisco.com, Ted Hardie From: SM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-review@ietf.org Subject: [apps-review] Request for review: draft-ietf-eai-rfc5337bis-dsn X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Dec 2010 06:53:30 -0000 Hi Eliot, Ted, Alexey requested a review of draft-ietf-eai-rfc5337bis-dsn from the EAI WG. The assignment is due before December 16. The review is exceptionally being assigned to two people instead of one. Please review the ABNF too. If you have any questions about the assignment, please post a message to the apps-review mailing list or email me. You can find information about the author and WG in the datatracker ( http://datatracker.ietf.org/doc/draft-ietf-eai-rfc5337bis-dsn/ ). Some previous reviews from the Apps-review Team are accessible at http://www.apps.ietf.org/content/apps-review-template The review should be sent to apps-discuss, the author, WG Chairs and document shepherd, if applicable, and the IESG. The subject of the email when submitting the review should be "apps-team review of draft-ietf-eai-rfc5337bis-dsn-01". Best regards, -sm Return-Path: X-Original-To: apps-review@core3.amsl.com Delivered-To: apps-review@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 951E33A6A56 for ; Fri, 3 Dec 2010 22:53:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.525 X-Spam-Level: X-Spam-Status: No, score=-101.525 tagged_above=-999 required=5 tests=[AWL=-0.886, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kw+M-rr4pVMr for ; Fri, 3 Dec 2010 22:53:27 -0800 (PST) Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by core3.amsl.com (Postfix) with ESMTP id D86BB3A6A5D for ; Fri, 3 Dec 2010 22:53:27 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.239.82]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id oB46sR1o030557; Fri, 3 Dec 2010 22:54:33 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1291445675; bh=vX90HeIEaNh/fOkKl4RTUQgwx2o=; h=Message-Id:Date:To:From:Subject:Cc:Mime-Version:Content-Type; b=hnE8FHABoO8TU5+Wzu/GMcEimq3dXvdlDw3ncq+4Drz8r1cmM5JUoqZjSySjKq469 qby4rKGj+APb2pZShc+Xi4+MWrYgL2tUViLqJ0IFgJ41kbm66x1Gz4hMSj66JuKxE/ M/QMUylPq6ef/Ks/s1cs4hMFSsr8hibzujRS1Olo= Message-Id: <6.2.5.6.2.20101203221116.0ad42aa8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 03 Dec 2010 22:46:27 -0800 To: Dave Cridland , "Murray S. Kucherawy" From: SM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-review@ietf.org Subject: [apps-review] Request for review: draft-ietf-eai-rfc5335bis X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Dec 2010 06:53:30 -0000 Hi Dave, Murray, Alexey requested a review of draft-ietf-eai-rfc5335bis from the EAI WG. The assignment is due before December 16. The review is exceptionally being assigned to two people instead of one. Please review the ABNF too. If you have any questions about the assignment, please post a message to the apps-review mailing list or email me. You can find information about the author and WG in the datatracker ( http://datatracker.ietf.org/doc/draft-ietf-eai-rfc5335bis/ ). Some previous reviews from the Apps-review Team are accessible at http://www.apps.ietf.org/content/apps-review-template The review should be sent to apps-discuss, the author, WG Chairs and document shepherd, if applicable, and the IESG. The subject of the email when submitting the review should be "apps-team review of draft-ietf-eai-rfc5335bis-05". Best regards, -sm Return-Path: X-Original-To: apps-review@core3.amsl.com Delivered-To: apps-review@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 472633A69C5 for ; Wed, 1 Dec 2010 09:40:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kFpqueSp-qfr for ; Wed, 1 Dec 2010 09:40:53 -0800 (PST) Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by core3.amsl.com (Postfix) with ESMTP id 9F7F93A6B48 for ; Wed, 1 Dec 2010 09:40:53 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.239.135]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id oB1Hfo0E000446; Wed, 1 Dec 2010 09:41:56 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1291225319; bh=LycevRqELAIVheyoLAaf6+Oe/Hg=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Content-Transfer-Encoding; b=Ag5mpk7nFFc/wo2cigACm76qcFtY3VL//7htN45/EO7ttmT0I/smBUFFw4G3rrzoT V6B9zsxGvuXJIDTymdv1ta1YIOxXM/BCuXkUtgP8vdggj66vLmU89KpHVlHQDOR1VL QzV/5Az+nVVxkjYVFVn6KdWbe2p72es2/8uBmZy4= Message-Id: <6.2.5.6.2.20101201063146.09d127a0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 01 Dec 2010 06:56:31 -0800 To: apps-review@ietf.org From: SM In-Reply-To: <4CF6278B.5090009@it.aoyama.ac.jp> References: <4CF6160B.4060103@gmail.com> <6.2.5.6.2.20101201015058.07450da0@elandnews.com> <4CF6278B.5090009@it.aoyama.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: Claudio Allocchio Subject: Re: [apps-review] Author Review Request of draft-yevstifeyev-http-headers-not-recognized X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2010 17:40:57 -0000 Hi Martin, Claudio, Thanks for the feedback. At 02:46 01-12-10, Martin J. D=FCrst wrote: >I very much think the later. In general, we=20 >should save our resources for helping our ADs.=20 >There may be exceptions for drafts from other=20 >areas, in particular if an AD of that Agreed. >area asks us. If Mykyta wants wider review, why=20 >not ask him to just send his draft to apps-discuss? I'll suggest that to him. Best regards, -sm=20 Return-Path: X-Original-To: apps-review@core3.amsl.com Delivered-To: apps-review@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7F033A6CF4 for ; Wed, 1 Dec 2010 03:20:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L625HEf-o+v2 for ; Wed, 1 Dec 2010 03:20:50 -0800 (PST) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [IPv6:2001:760:0:158::29]) by core3.amsl.com (Postfix) with ESMTP id 999713A6B41 for ; Wed, 1 Dec 2010 03:20:49 -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.4/8.14.4) with ESMTP id oB1BLoqL082530 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Dec 2010 12:21:51 +0100 (CET) X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 cyrus.dir.garr.it oB1BLoqL082530 DomainKey-Signature: a=rsa-sha1; s=mail; d=garr.it; c=simple; q=dns; b=CBI2t57GfZ9bDj/dPS/Kqdx3RHX8S/J2vG0CFv9rlWNrHKU/qM7cOOpCVLyKsM/nj kQPMYvjnavfeoqIXABgmZiTxtQaNFSZiLKOldXbGalxvtt3VI0cf2wgvm3Y6qFVGM+p eMqdT71C/r+R7iuf8ALSAC96ZdARCbBcFfoLeXU= Date: Wed, 1 Dec 2010 12:21:45 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.elettra.trieste.it To: SM In-Reply-To: <6.2.5.6.2.20101201015058.07450da0@elandnews.com> Message-ID: References: <4CF6160B.4060103@gmail.com> <6.2.5.6.2.20101201015058.07450da0@elandnews.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: apps-review@ietf.org Subject: Re: [apps-review] Author Review Request of draft-yevstifeyev-http-headers-not-recognized X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2010 11:20:51 -0000 On Wed, 1 Dec 2010, SM wrote: > Should the Apps Area Team review the draft or should I ask the author to wait > for more feedback before the review is performed? wait for more... ------------------------------------------------------------------------------ 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 Return-Path: X-Original-To: apps-review@core3.amsl.com Delivered-To: apps-review@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E39D28C103 for ; Wed, 1 Dec 2010 02:45:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.185 X-Spam-Level: X-Spam-Status: No, score=-100.185 tagged_above=-999 required=5 tests=[AWL=-0.395, 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I0sUjJCs4pa1 for ; Wed, 1 Dec 2010 02:45:39 -0800 (PST) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by core3.amsl.com (Postfix) with ESMTP id 1100A3A6CFC for ; Wed, 1 Dec 2010 02:45:35 -0800 (PST) Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id oB1AkifH009916 for ; Wed, 1 Dec 2010 19:46:44 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 545c_4e23_49ef206c_fd38_11df_a157_001d096c566a; Wed, 01 Dec 2010 19:46:44 +0900 Received: from [IPv6:::1] ([133.2.210.1]:36675) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 1 Dec 2010 19:46:43 +0900 Message-ID: <4CF6278B.5090009@it.aoyama.ac.jp> Date: Wed, 01 Dec 2010 19:46:35 +0900 From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: SM References: <4CF6160B.4060103@gmail.com> <6.2.5.6.2.20101201015058.07450da0@elandnews.com> In-Reply-To: <6.2.5.6.2.20101201015058.07450da0@elandnews.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: apps-review@ietf.org Subject: Re: [apps-review] Author Review Request of draft-yevstifeyev-http-headers-not-recognized X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2010 10:45:41 -0000 On 2010/12/01 19:19, SM wrote: > Hello, > > Mykyta Yevstifeyev sent a review request of > draft-yevstifeyev-http-headers-not-recognized. > draft-yevstifeyev-http-headers-not-recognized-00 was submitted on > November 21 and the latest version > (draft-yevstifeyev-http-headers-not-recognized-04 {1]) was submitted on > November 29. There was some discussion of the draft on the HTTPBIS > (ietf-http-wg) mailing list [2]. > > Should the Apps Area Team review the draft or should I ask the author to > wait for more feedback before the review is performed? I very much think the later. In general, we should save our resources for helping our ADs. There may be exceptions for drafts from other areas, in particular if an AD of that area asks us. If Mykyta wants wider review, why not ask him to just send his draft to apps-discuss? Regards, Martin. -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp Return-Path: X-Original-To: apps-review@core3.amsl.com Delivered-To: apps-review@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9F6F3A6CC4 for ; Wed, 1 Dec 2010 02:19:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rVTP-mVe33uN for ; Wed, 1 Dec 2010 02:18:57 -0800 (PST) Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by core3.amsl.com (Postfix) with ESMTP id D390B3A69C5 for ; Wed, 1 Dec 2010 02:18:57 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.234.60]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id oB1AK1mu003197 for ; Wed, 1 Dec 2010 02:20:07 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1291198809; bh=0Kr2qlHq9tjkhc6NHlMc07uj6ZI=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type; b=pzGtgr1CKdLM6ezUBBJAKhs9g3HVrTCaF9MtgI6R27ugqNaaWdf8uzu2RNRSCU5wn wdTRk8tFmek92Per1idGqsOy3npvNe6Y/0Zm4043jedHsp+f7bieNbhXjnUSxF1Pi0 BzvAFoQKL6LCzUAOFiUqxV7JL2OYA/SmW65eGq1Q= Message-Id: <6.2.5.6.2.20101201015058.07450da0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 01 Dec 2010 02:19:39 -0800 To: apps-review@ietf.org From: SM In-Reply-To: <4CF6160B.4060103@gmail.com> References: <4CF6160B.4060103@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [apps-review] Author Review Request of draft-yevstifeyev-http-headers-not-recognized X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2010 10:19:03 -0000 Hello, Mykyta Yevstifeyev sent a review request of draft-yevstifeyev-http-headers-not-recognized. draft-yevstifeyev-http-headers-not-recognized-00 was submitted on November 21 and the latest version (draft-yevstifeyev-http-headers-not-recognized-04 {1]) was submitted on November 29. There was some discussion of the draft on the HTTPBIS (ietf-http-wg) mailing list [2]. Should the Apps Area Team review the draft or should I ask the author to wait for more feedback before the review is performed? Best regards, -sm 1. http://tools.ietf.org/html/draft-yevstifeyev-http-headers-not-recognized-04 2. http://lists.w3.org/Archives/Public/ietf-http-wg/2010OctDec/0487.html Return-Path: X-Original-To: apps-review@core3.amsl.com Delivered-To: apps-review@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02A0B3A6C5A for ; Wed, 1 Dec 2010 00:40:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CwaOGGeNu8yY for ; Wed, 1 Dec 2010 00:40:30 -0800 (PST) Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by core3.amsl.com (Postfix) with ESMTP id D91743A6BF6 for ; Wed, 1 Dec 2010 00:40:30 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.234.60]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id oB18fZDp030217; Wed, 1 Dec 2010 00:41:41 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1291192903; bh=UHfrOya+DdoFi/o9AKdBX4k8+hs=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=q/58NOQYHaTyEW1NyWJlKokSHK2FBMTQo17Sxq2J1WUFZQkSWmhIWdLV5aJqs7NHS zvv22VjogFEPCL469ajMg/8pMJI6Twl7eFlX+p5cLCqv2IyqhRfuxn4+kE94jA5FzD Y0g1KiySHLx7w3QM5GUpN4spsKIEpZHjOYCFWMgw= Message-Id: <6.2.5.6.2.20101201003646.0871f3d0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 01 Dec 2010 00:41:16 -0800 To: Joe Hildebrand From: SM In-Reply-To: References: <6.2.5.6.2.20101130094834.0bad5570@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-review@ietf.org Subject: Re: [apps-review] Request for review: draft-salowey-secsh-uri X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2010 08:40:32 -0000 Hi Joe, I incorrectly assigned the review of draft-salowey-secsh-uri to Mark Baker who isn't on the Apps Review Team. Would you be able to review the draft by December 9? You can find information about the author and WG in the datatracker ( https://datatracker.ietf.org/doc/draft-salowey-secsh-uri ). Some previous reviews from the Apps-review Team are accessible at http://www.apps.ietf.org/content/apps-review-template The review should be sent to apps-discuss, the author, WG Chair and document shepherd, if applicable, and the IESG. The subject of the email when submitting the review should be "apps-team review of draft-salowey-secsh-uri-00". Best regards, -sm