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 CF9A83A68E7 for ; Fri, 12 Mar 2010 15:57:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 14TlVoMcUUrB for ; Fri, 12 Mar 2010 15:57:56 -0800 (PST) Received: from mail-iw0-f186.google.com (mail-iw0-f186.google.com [209.85.223.186]) by core3.amsl.com (Postfix) with ESMTP id 1039B3A68D5 for ; Fri, 12 Mar 2010 15:57:55 -0800 (PST) Received: by iwn16 with SMTP id 16so674576iwn.31 for ; Fri, 12 Mar 2010 15:57:58 -0800 (PST) MIME-Version: 1.0 Sender: mark@coactus.com Received: by 10.231.151.197 with SMTP id d5mr326131ibw.73.1268438278107; Fri, 12 Mar 2010 15:57:58 -0800 (PST) In-Reply-To: <4B894872.3080003@stpeter.im> References: <4B894872.3080003@stpeter.im> Date: Fri, 12 Mar 2010 18:57:58 -0500 X-Google-Sender-Auth: 055d9e317ad417ba Message-ID: From: Mark Baker To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Cc: "apps-review@ietf.org" Subject: Re: [APPS-REVIEW] Fwd: Re: [xml-dir] XML Directorate Review Request for draft-ietf-ecrit-lost-sync-08.txt X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2010 23:57:59 -0000 I've had a read through the whole document now, and the only major problem I've identified with it, which I mentioned before, is that it uses HTTP as if it were a transport protocol. It's particularly problematic here because the motivating scenarios described in the introduction seem very well suited to HTTP as designed; as a transfer protocol. Concretely, what I mean is that when one node wants to request mappings from another node, it should use HTTP GET instead of tunneling a "getMappingsRequest" request inside an HTTP POST request. Also, the response need not contain the "getMappingsResponse" wrapper because it will be obvious what the response is by its media type. For similar reasons, the use of "pushMappingsRequest" is redundant; HTTP POST *is* the correct method to use to submit data, but the receiving node needs no more information than the URI and the set of mappings (with media type). And as with "getMappingsResponse", the "pushMappingsResponse" wrapper is redundant. This would also provide for cleaner layering between media type and the transfer semantics, permitting the media type to evolve independently of those semantics. As is, the media type has two different ways to represent the same set of mappings; wrapped with "getMappingsResponse" and with "pushMappingsRequest". A clear layering violation, if ever I saw one. I also note the draft makes no reference to BCP 56. Note that I'm on vacation next week so won't have the opportunity to respond to comments until the 22nd at the earliest. Mark. 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 5D3DA3A67E7 for ; Mon, 8 Mar 2010 00:27:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.21 X-Spam-Level: X-Spam-Status: No, score=0.21 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3] 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 255Mwk6wTU+z for ; Mon, 8 Mar 2010 00:27:57 -0800 (PST) Received: from scmailgw02.scop.aoyama.ac.jp (scmailgw02.scop.aoyama.ac.jp [133.2.251.42]) by core3.amsl.com (Postfix) with ESMTP id 110BA3A6768 for ; Mon, 8 Mar 2010 00:27:56 -0800 (PST) Received: from scmse01.scbb.aoyama.ac.jp (scmse01.scbb.aoyama.ac.jp [133.2.253.158]) by scmailgw02.scop.aoyama.ac.jp (secret/secret) with SMTP id o288RniO022019 for ; Mon, 8 Mar 2010 17:27:49 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 6f53_349e_7b4cae42_2a8c_11df_9637_001d096c566a; Mon, 08 Mar 2010 17:27:49 +0900 Received: from [IPv6:::1] ([133.2.210.1]:55888) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 8 Mar 2010 17:27:47 +0900 Message-ID: <4B94B4F1.5080107@it.aoyama.ac.jp> Date: Mon, 08 Mar 2010 17:27:29 +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.1) Gecko/20090902 Eudora/3.0b3 MIME-Version: 1.0 To: dcrocker@bbiw.net References: <4B11367F.8070403@isode.com> <4B183FD0.1040004@dcrocker.net> In-Reply-To: <4B183FD0.1040004@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "apps-review@ietf.org" Subject: Re: [APPS-REVIEW] Request for reviews of draft-duerst-mailto-bis-07.txt X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 08:27:59 -0000 Hello Dave, Sorry for being so late to reply to your comments. On 2009/12/04 7:46, Dave CROCKER wrote: > > > As with Eliot, I'm only claiming a single scan: > > >> This specification does not address the needs of the ongoing Email >> Address Internationalization effort (see [RFC4952]). In particular, > > I am usually a vigorous opponent of references to future work, except in > the > most bland and generic fashion, given that the future is entirely > unknowable and > almost always develops differently than we expect. This spec seems to be an > exception, probably because there is such massive of the massive, global > interest in the enhancements and especially because there is an RFC to > cite. On top of that, please note that this 'future work' is referenced with a negative connotation. >> This may be fixed in a future version of this specification. > -> > This could be fixed in a future version of this specification. > > Particularly given that the next paragraph reserves 'may' to be > normative... > > But in fact, the sentence should be removed. Anything can happen in the > future. Something might be fixed and it might not. The sentence > therefore provides no information. Done. > >> to = [ addr-spec *("%2C" addr-spec ) ] > > I believe the quotation marks should be removed. If, instead, this is an > example of characters that must be percent-encoded /in the mailto spec/ > then it's confusing not to see comma mentioned in Note 1, below this. Very good catch. I think in parallel with http://tools.ietf.org/html/rfc5322#section-3.6.3, it should be to = [ addr-spec *("," addr-spec ) ] That would also simplify two examples. RFC 2368 said that all URI-reserved characters have to be escaped, which included the comma, but at least since RFC 3986, the idea is that escaping is only needed for URI characters in a 'payload' role where the same character can have a syntactic function. As we don't use the comma, we don't need to escape it, although it still can be escaped. > Note 4: >> When the internationalized domain name is used to compose a >> message, the name MUST be transformed to the IDNA encoding where >> appropriate [RFC3490]. URI producers SHOULD provide these domain > > How is the reader supposed to know "where appropriate" applies? By reading RFC 3490. >> Within 'mailto' URIs, the characters "?", "=", and "&" are reserved, >> serving as delimiters. They have to be escaped (as "%3F", "%3D", and >> "%26", respectively) when not serving as delimiters. > > Why isn't this reflected in the ANBF for mailto? To avoid copying more and more of RFC 5322 over to this document. >> >> is equivalent to >> >> is equivalent to >> >> However, the latter form is NOT RECOMMENDED. > > Why isn't "to=" simply prohibited, so that there is one, fixed way to do > addressing? Because "to=" was allowed already in RFC 2368, and we can't simply disallow it. >> Implementations SHOULD NOT produce two "To:" header fields in a > > This provides a nice example of the reason "to=" should be disallowed. The SHOULD NOT above was changed to a MUST NOT. Unfortunately, I don't think we can do much more at this point. >> Creators of 'mailto' URIs SHOULD avoid using the same >> multiple times in the same URI to avoid interoperability problems. >> If the same appears multiple times in an URI, behavior >> varies widely for different user agents, and for each . >> Examples include only using the first or last / >> pair, combining each by simple concatenation, or in a way >> appropriate for the corresponding header field, or creating multiple >> header fields. > > At a minimum, "SHOULD avoid using" -> "SHOULD NOT use", to make the > language match the usual RFC specification form. Done. > More substantively, why not simply prohibit multiple, identical hfnames? > Interoperability is about simplicity, which is largely the message of > this text in the document, except that it does not them follow through > on the point. That might have been a valid choice earlier in the drafting process. >> resolution. The character '#' in hfvalues MUST be escaped as %23. > > Why isn't this in the ABNF? It is mentioned immediately below the ABNF. >> A 'mailto' URI designates an "internet resource", which is the >> mailbox specified in the address. When additional header fields are >> supplied, the resource designated is the same address, but with an >> additional profile for accessing the resource. > > I found this confusing. I think it is trying to say: > > A 'mailto' that consists only of an address refers to the mailbox > associated with that address. A 'mailto' that consists of an address and > additional header fields specifies a message that is to be sent to the > references mailbox. > > At the least, I don't know what "an additional profile for accessing the > resource" means. This is more or less philosophic text that has been argued about quite a bit. I don't want to change it at this stage in the process. >> While there are >> Internet resources that can only be accessed via electronic mail, the >> 'mailto' URI is not intended as a way of retrieving such objects >> automatically. > > > Retrieving??? mailto isn't for retrieving, is it? That's exactly that the text above says ("is not intended"). >> The 'mailto' URI has unusual semantics because resolving such a URI >> does not cause an immediate interaction. Instead, the client creates >> a message to the designated address with the various header fields >> set as default. The user can edit the message, send this message >> > > "creates a message" sounds like interaction to me. (and of course, it > isn't the user creating the message, it's an MUA or pre-MUA agent > working on the user's behalf, when they click the mailto... You have to read this in context. The paragraph starts talking about interaction between clients and servers, and then says that mailto: doesn't produce such an interaction immediately. I added "with a server" to make it easier to read. >> The user agent interpreting a 'mailto' URI SHOULD choose not to >> create a message if any of the header fields are considered > > > SHOULD choose not to create -> SHOULD NOT create Done. >> The creator of a 'mailto' URI cannot expect the resolver of a URI to >> understand more than the "subject" header field and "body". > > -> Creators and resolvers of a 'mailto' URI MUST support correct process > of "subject" and "body" hfnames (and their hfields.) It says so later in the same paragraph: "Clients that resolve 'mailto' URIs into mail messages MUST be able to correctly create -compliant mail messages using the "subject" header field and "body"." (for resolvers, not for creators, because creators in my view do not process). > They MAY support > additional hfnames. > > I suspect this paragraph belongs earlier in the document. I understand > the safety motivation for placing it here, but the normative impact is > much more basic. Putting it earlier would be a possibility indeed. But then this section would look way too short. > // sorry, but i skipped the examples, due to time limits /d // > > >> Programs that interpret 'mailto' URIs SHOULD ensure that the SMTP >> "From" address (the SMTP envelope return path given as an argument to > > "From" -> "Mail From" > > although it might be simpler to have the sentence say: > > ... ensure that the SMTP envelope return path address, that is given as an > argument to the SMTP MAIL FROM command)... > > This avoid any possibility of confusing the reference with an actual > From: address... Done (with "that is given" -> "which is given"). > >> harvesting. This applies to all mail addresses included in the > > included in the -> that are part of the > > to avoid the 'include' twice in the same sentence fixed. 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 768093A692E for ; Sun, 7 Mar 2010 23:29:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.21 X-Spam-Level: X-Spam-Status: No, score=0.21 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3] 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 diVaqe+xUkih for ; Sun, 7 Mar 2010 23:29:53 -0800 (PST) Received: from scmailgw02.scop.aoyama.ac.jp (scmailgw02.scop.aoyama.ac.jp [133.2.251.42]) by core3.amsl.com (Postfix) with ESMTP id 7A5D93A677D for ; Sun, 7 Mar 2010 23:29:53 -0800 (PST) Received: from scmse01.scbb.aoyama.ac.jp (scmse01.scbb.aoyama.ac.jp [133.2.253.158]) by scmailgw02.scop.aoyama.ac.jp (secret/secret) with SMTP id o287TtU5026022 for ; Mon, 8 Mar 2010 16:29:55 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 6f60_8841_6468f15c_2a84_11df_9637_001d096c566a; Mon, 08 Mar 2010 16:29:55 +0900 Received: from [IPv6:::1] ([133.2.210.1]:53808) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 8 Mar 2010 16:29:53 +0900 Message-ID: <4B94A75F.8040603@it.aoyama.ac.jp> Date: Mon, 08 Mar 2010 16:29: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.1) Gecko/20090902 Eudora/3.0b3 MIME-Version: 1.0 To: Eliot Lear References: <4B11367F.8070403@isode.com> <4B13C3BF.3090802@cisco.com> In-Reply-To: <4B13C3BF.3090802@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "apps-review@ietf.org" Subject: Re: [APPS-REVIEW] Request for reviews of draft-duerst-mailto-bis-07.txt X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 07:29:55 -0000 Hello Eliot, others, Sorry for being so late with this reply. On 2009/11/30 22:08, Eliot Lear wrote: > Alexey, > > You asked for a review of draft-duerst-mailto-bis-07.txt. I'm taking a > few moments to comment, but I don't have time for a full review, as your > document is in front of it ;-) > > Overall my only real question is this (not even a concern at this point): > > Apart from Bcc, is this change opaque to legacy implementations? It > seems so, but perhaps I'm not thinking right. No, it's not. Up to now, only a very restricted subset of US-ASCII characters was allowed e.g. in body=...; this has been extended to allow percent-encoding and therefore the wide range of Unicode characters. Many newer browsers for example already support this, but of course there will be old legacy that doesn't support it. > Nits?: > > > In Section 2, there's a lot of non-normative language that should be > normative, IMHO. For example: > >> 1. A number of characters that can appear in have to be >> percent-encoded. > > s/have to/MUST/ Done. > Similarly: > >> 2. and as defined in [RFC5322] are not >> allowed. > > s/are not allowed/MUST NOT be used/. Done. > And of course directly below it: > >> 3. Whitespace and comments within and are not >> allowed. > s/are not allowed/MUST NOT be used/. Done. > Martin wrote: > >> >>> Implementations SHOULD NOT produce two "To:" header fields in a >>> message; the "To:" header field may occur at most once in a message >>> ([RFC5322], Section 3.6). Also, creators of 'mailto' URIs SHOULD NOT >>> include other message header fields multiple times if these header >>> fields can only be used once in a message. >>> >>> >> Any reasons why these SHOULD NOTs are not MUST NOTs? >> >> Not being a mail expert, I have no experience on what goes wrong if >> these restrictions are not met. If you think a MUST is more >> appropriate, that's fine with me. > > IMHO MUST is appropriate. That table is meant to be normative. The usual > rule "be conservative.. be liberal.." also implies this should be a > MUST, and I can tell you that spam catching software will prefer > conservative. Done. Regards, Martin. > Eliot > _______________________________________________ > APPS-REVIEW mailing list > APPS-REVIEW@ietf.org > https://www.ietf.org/mailman/listinfo/apps-review > -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp