From tss@iki.fi Wed Dec 9 14:06:15 2009 Return-Path: X-Original-To: morg@core3.amsl.com Delivered-To: morg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99E7C3A6A68 for ; Wed, 9 Dec 2009 14:06:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.603 X-Spam-Level: X-Spam-Status: No, score=-4.603 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6, MIME_QP_LONG_LINE=1.396, 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 Xwme7RNhrVa9 for ; Wed, 9 Dec 2009 14:06:14 -0800 (PST) Received: from dovecot.org (dovecot.org [82.118.211.50]) by core3.amsl.com (Postfix) with ESMTP id 2E4DA3A6A4C for ; Wed, 9 Dec 2009 14:06:14 -0800 (PST) Received: from [10.4.192.26] (unknown [74.205.24.229]) by dovecot.org (Postfix) with ESMTP id 295DFFA8F59; Thu, 10 Dec 2009 00:06:01 +0200 (EET) From: Timo Sirainen To: Chris Newman In-Reply-To: References: <20091018161501.91C3C3A6937@core3.amsl.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-AsCHykuSXc2BUiNJS9vj" Date: Wed, 09 Dec 2009 17:05:59 -0500 Message-ID: <1260396359.26478.45.camel@timo-desktop> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Cc: morg@ietf.org Subject: Re: [MORG] I-D Action:draft-ietf-morg-sortdisplay-02.txt X-BeenThere: morg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Messaging Organization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 22:06:15 -0000 --=-AsCHykuSXc2BUiNJS9vj Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2009-11-10 at 01:05 -0800, Chris Newman wrote: > I checked this against the X-DISPLAY-FROM, X-DISPLAY-TO and X-DISPLAY-CC=20 > extension sort keys in our server implementation. I note two differences= : >=20 > 1. We decode RFC 2047 to UTF-8. The draft does not specify charset, so a= n=20 > implementation which decoded 2047 to a different charset would sort=20 > differently. The algorithm in 5255 section 4.6 needs to be followed, whi= ch=20 > states the decoded text MUST be converted to a charset expected by the=20 > active comparator. I believe 5255 should have said that decoding to UTF-= 8=20 > SHOULD be used where the active comparator specifies multiple acceptable=20 > charsets including UTF-8. As it does not say that, I believe it would=20 > improve interoperability if this draft said that although I wouldn't=20 > consider that a blocking flaw. RFC 4790 states that any octet-based=20 > charset is acceptable for i;octet. The draft also refers to RFC 5256, which specifies decoding to UTF-8. But yes, explicitly mentioning UTF-8 would make it clearer. > 2. Our implementation also strips double-quotes from around the personal=20 > name field prior to comparing. I believe RFC 3501 is unclear about wheth= er=20 > double-quotes are stripped when an RFC 2822 mailbox is parsed into an IMA= P=20 > envelope. I'd like this draft to state double-quotes are stripped (or=20 > un-escaped) if present. I was somehow thinking that all of this came automatically if you parse the address using RFC2822 tokenizer. Like the address could be: From: "Timo" (hello world) "Sirainen" and the resulting personal name should still be "Timo Sirainen", without double-quotes. I guess it could be mentioned, but to me this seems kind of like band-aid to servers that already parse addresses wrong (if there are any such servers). --=-AsCHykuSXc2BUiNJS9vj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAksgH0cACgkQyUhSUUBVislCCACdEf01bCDlWvrlC929hW+EP4eY YMMAoJ/oawxOtMQu3kAWkMNJ6aN509wU =y0Z6 -----END PGP SIGNATURE----- --=-AsCHykuSXc2BUiNJS9vj-- From wwwrun@core3.amsl.com Mon Dec 21 11:03:31 2009 Return-Path: X-Original-To: morg@ietf.org Delivered-To: morg@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id EC6513A6A87; Mon, 21 Dec 2009 11:03:31 -0800 (PST) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20091221190331.EC6513A6A87@core3.amsl.com> Date: Mon, 21 Dec 2009 11:03:31 -0800 (PST) Cc: morg chair , morg mailing list , Internet Architecture Board , RFC Editor Subject: [MORG] Protocol Action: 'IMAP4 Extension for returning STATUS information in extended LIST' to Proposed Standard X-BeenThere: morg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Messaging Organization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2009 19:03:32 -0000 The IESG has approved the following document: - 'IMAP4 Extension for returning STATUS information in extended LIST ' as a Proposed Standard This document is the product of the Message Organization Working Group. The IESG contact persons are Lisa Dusseault and Alexey Melnikov. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-morg-status-in-list-01.txt Technical Summary Many IMAP clients display information about total number of messages/total number of unseen messages in IMAP mailboxes. In order to do that they are forced to issue a LIST or LSUB command, to list all available mailboxes, followed by a STATUS command for each mailbox found. This document provides an extension to LIST command that allows the client to request STATUS information for mailboxes together with other information typically returned by the LIST command. Working Group Summary There is concern that a client can adversely affect a mail server by misusing this command in a situation with an extremely large number of mailboxes, and/or where retrieving status information for the mailboxes is very slow. The reality, though, is that such clients will already have the same effect by sending -- perhaps pipelining -- a very large number of STATUS commands. This point is noted in the Security Considerations. Document Quality Several server implementors and at least a few client implementors are interested, and say they plan to implement this extension. There's at least one existing implementation, from Dovecot. There has been nothing of particular note related to reviews. RFC Editor Note Please shift [ACL] to be an informative reference. Please remove the note at the top of page 2. >> OLD >> >> 1. Conventions used in this document >> >> In examples, "C:" indicates lines sent by a client that is connected >> to a server. "S:" indicates lines sent by the server to the client. >> >> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this >> document are to be interpreted as described in RFC 2119 [Kwds]. >> >> >> NEW >> >> 1. Introduction >> >> Many IMAP clients display information about total number of messages/ >> total number of unseen messages in IMAP mailboxes. In order to do >> that they are forced to issue a LIST or LSUB command, to list all >> available mailboxes, followed by a STATUS command for each mailbox >> found. This document provides an extension to LIST command that >> allows the client to request STATUS information for mailboxes >> together with other information typically returned by the LIST >> command. >> >> 1.1 Conventions used in this document >> >> In examples, "C:" indicates lines sent by a client that is connected >> to a server. "S:" indicates lines sent by the server to the client. >> >> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this >> document are to be interpreted as described in RFC 2119 [Kwds].