Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1S03M911556 for ietf-imapext-bks; Thu, 27 Feb 2003 16:03:22 -0800 (PST)
Received: from max.kde.org (max.kde.org [134.2.170.93]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1S03LY11552 for <ietf-imapext@imc.org>; Thu, 27 Feb 2003 16:03:21 -0800 (PST)
Received: from 192.168.0.3 (ppp36-70.hrz.uni-bielefeld.de [129.70.36.70]) by max.kde.org (Postfix) with ESMTP id 21E95AFC4F for <ietf-imapext@imc.org>; Fri, 28 Feb 2003 01:03:25 +0100 (CET)
From: Marc Mutz <mutz@kde.org>
Organization: "Old Europe" - and proud
To: ietf-imapext@imc.org
Subject: Re: i18n support for sort & thread
Date: Fri, 28 Feb 2003 00:48:45 +0100
User-Agent: KMail/1.5.9
References: <2147483647.1046287578@nifty-jr.west.sun.com> <200302271752.57212@sendmail.mutz.com> <2147483647.1046358244@nifty-jr.west.sun.com>
In-Reply-To: <2147483647.1046358244@nifty-jr.west.sun.com>
X-PGP-Key: 0xBDBFE838
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_tPqX+4DSPEfS5u5"; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <200302280049.01187@sendmail.mutz.com>
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

--Boundary-02=_tPqX+4DSPEfS5u5
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Description: signed data
Content-Disposition: inline

On Friday 28 February 2003 00:04, Chris Newman wrote:
<snip>
> I explicitly do not want to create a comparator registry for all
> stringprep profiles -- there might be profiles used in narrow
> circumstances that aren't appropriate as comparators.  Furthermore,
> the namespace for stringprep profile names is unconstrained and thus
> may not fit the syntax for comparators.
<snip>

OK, my comment was prompted by the fact that there are already at least=20
four stringprep profiles (nameprep, kerberos5, xmpp (2x), mailprep(?))=20
are already in the works and it might be nice to indicate in the=20
comparator namimg that they're all stringprep-based.

Marc

=2D-=20
"Similia similibus curentur"
           -- Bush's new motto in fighting terrorism.

--Boundary-02=_tPqX+4DSPEfS5u5
Content-Type: application/pgp-signature
Content-Description: signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQA+XqPt3oWD+L2/6DgRAhIIAJ0fAEgAkRdhMb22Wco17Saz4zVOwwCeJ9Bo
42Gqp+OgnPaI9XJIclg1/8M=
=yK84
-----END PGP SIGNATURE-----

--Boundary-02=_tPqX+4DSPEfS5u5--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1RN4Hr10375 for ietf-imapext-bks; Thu, 27 Feb 2003 15:04:17 -0800 (PST)
Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1RN4GY10371 for <ietf-imapext@imc.org>; Thu, 27 Feb 2003 15:04:16 -0800 (PST)
Received: from esunmail ([129.147.58.120]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA11134 for <ietf-imapext@imc.org>; Thu, 27 Feb 2003 16:04:19 -0700 (MST)
Received: from xpa-fe1 ([129.147.58.198]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0HAZ00LSBPF6QI@edgemail1.Central.Sun.COM> for ietf-imapext@imc.org; Thu, 27 Feb 2003 16:04:19 -0700 (MST)
Received: from nifty-jr.west.sun.com ([129.153.12.95]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTPSA id <0HAZ00K5WPF43I@mail.sun.net> for ietf-imapext@imc.org; Thu, 27 Feb 2003 16:04:18 -0700 (MST)
Date: Thu, 27 Feb 2003 15:04:04 -0800
From: Chris Newman <Chris.Newman@Sun.COM>
Subject: Re: i18n support for sort & thread
In-reply-to: <200302271752.57212@sendmail.mutz.com>
To: Marc Mutz <mutz@kde.org>, ietf-imapext@imc.org
Message-id: <2147483647.1046358244@nifty-jr.west.sun.com>
MIME-version: 1.0
X-Mailer: Mulberry/3.0.0 (Mac OS X)
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-message-flag: Outlook: the best virus distribution system around
References: <2147483647.1046287578@nifty-jr.west.sun.com> <200302271752.57212@sendmail.mutz.com>
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

I explicitly do not want to create a comparator registry for all stringprep 
profiles -- there might be profiles used in narrow circumstances that 
aren't appropriate as comparators.  Furthermore, the namespace for 
stringprep profile names is unconstrained and thus may not fit the syntax 
for comparators.

The stringprep/nameprep specs allow unicode tables to be upgraded without a 
versioning or name change as long as certain requirements are met.  That's 
contrary to the desire for a comparator to be 100% predictable (so a 
disconnected client can emulate server behavior).  I also want to have the 
Unicode table version present in the name for all Unicode-based comparators 
as a matter of consistancy.

Thanks for raising the issue -- it's a good question and I'm glad you're 
reviewing the spec.

                - Chris

begin  quotation by Marc Mutz on 2003/2/27 17:52 +0100:

> On Thursday 27 February 2003 04:26, Chris Newman wrote:
>> 6.4 Nameprep Comparator
>>
>>    The "i;nameprep-rfc=YYYY-uv=3.2" comparator is an implementation
> <snip>
>
> Shouldn't this be "i;stringprep-profile=nameprep-rfc=YYYY", where YYYY
> is the rfc number of the profile? The listing of rfc number implies
> both the stringprep and the profile version and thus the Unicode
> version the comparator is based on.
>
> Marc
>
> --
> They [RIAA,MPAA] are trying to invent a new crime:
> interference with a business model.
>                            --Bruce Schneier, Crypto-Gram 08/2002




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1RMq5J10089 for ietf-imapext-bks; Thu, 27 Feb 2003 14:52:05 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1RMq4Y10084 for <ietf-imapext@imc.org>; Thu, 27 Feb 2003 14:52:04 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01KSXMZWYRKG002O3W@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ietf-imapext@imc.org; Thu, 27 Feb 2003 14:52:04 -0800 (PST)
Date: Thu, 27 Feb 2003 14:51:20 -0800 (PST)
From: ned+imapext@INNOSOFT.COM
Subject: Re: i18n support for sort & thread
In-reply-to: "Your message dated Thu, 27 Feb 2003 17:52:45 +0100" <200302271752.57212@sendmail.mutz.com>
To: Marc Mutz <mutz@kde.org>
Cc: ietf-imapext@imc.org
Message-id: <01KSXQ29RI8O002O3W@mauve.mrochek.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Content-transfer-encoding: 7BIT
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

> On Thursday 27 February 2003 04:26, Chris Newman wrote:
> > 6.4 Nameprep Comparator
> >
> >    The "i;nameprep-rfc=YYYY-uv=3.2" comparator is an implementation
> <snip>

> Shouldn't this be "i;stringprep-profile=nameprep-rfc=YYYY", where YYYY
> is the rfc number of the profile? The listing of rfc number implies
> both the stringprep and the profile version and thus the Unicode
> version the comparator is based on.

Using RFC numbers for this is a bad idea IMO. RFCs tend to get revised from
time to time...

				Ned


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1RMasn09643 for ietf-imapext-bks; Thu, 27 Feb 2003 14:36:54 -0800 (PST)
Received: from max.kde.org (max.kde.org [134.2.170.93]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1RMaqY09639 for <ietf-imapext@imc.org>; Thu, 27 Feb 2003 14:36:52 -0800 (PST)
Received: from 192.168.0.3 (ppp36-239.hrz.uni-bielefeld.de [129.70.36.239]) by max.kde.org (Postfix) with ESMTP id 150C8AFC1A for <ietf-imapext@imc.org>; Thu, 27 Feb 2003 23:36:53 +0100 (CET)
From: Marc Mutz <mutz@kde.org>
Organization: "Old Europe" - and proud
To: ietf-imapext@imc.org
Subject: Re: i18n support for sort & thread
Date: Thu, 27 Feb 2003 17:52:45 +0100
User-Agent: KMail/1.5.9
References: <2147483647.1046287578@nifty-jr.west.sun.com>
In-Reply-To: <2147483647.1046287578@nifty-jr.west.sun.com>
X-PGP-Key: 0xBDBFE838
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_pJkX+5+QlFZ+/bd"; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <200302271752.57212@sendmail.mutz.com>
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

--Boundary-02=_pJkX+5+QlFZ+/bd
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Description: signed data
Content-Disposition: inline

On Thursday 27 February 2003 04:26, Chris Newman wrote:
> 6.4 Nameprep Comparator
>
>    The "i;nameprep-rfc=3DYYYY-uv=3D3.2" comparator is an implementation
<snip>

Shouldn't this be "i;stringprep-profile=3Dnameprep-rfc=3DYYYY", where YYYY=
=20
is the rfc number of the profile? The listing of rfc number implies=20
both the stringprep and the profile version and thus the Unicode=20
version the comparator is based on.

Marc

=2D-=20
They [RIAA,MPAA] are trying to invent a new crime:
interference with a business model.
                           --Bruce Schneier, Crypto-Gram 08/2002

--Boundary-02=_pJkX+5+QlFZ+/bd
Content-Type: application/pgp-signature
Content-Description: signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQA+XkJp3oWD+L2/6DgRAl0XAKC7EX5r8ysAKq5TUAxlaeWVeJZP6QCePdgi
IPPTtqZAGvJljaOnk3Bg1UA=
=e6j5
-----END PGP SIGNATURE-----

--Boundary-02=_pJkX+5+QlFZ+/bd--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1R3QWp13367 for ietf-imapext-bks; Wed, 26 Feb 2003 19:26:32 -0800 (PST)
Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1R3QRY13362 for <ietf-imapext@imc.org>; Wed, 26 Feb 2003 19:26:27 -0800 (PST)
Received: from esunmail ([129.147.58.120]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA25564 for <ietf-imapext@imc.org>; Wed, 26 Feb 2003 20:26:31 -0700 (MST)
Received: from xpa-fe2 (esunmail [129.147.58.120]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0HAY007QS6W6XY@edgemail1.Central.Sun.COM> for ietf-imapext@imc.org; Wed, 26 Feb 2003 20:26:30 -0700 (MST)
Received: from nifty-jr.west.sun.com ([129.153.12.95]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTPSA id <0HAY00K2M6W3NC@mail.sun.net> for ietf-imapext@imc.org; Wed, 26 Feb 2003 20:26:30 -0700 (MST)
Date: Wed, 26 Feb 2003 19:26:18 -0800
From: Chris Newman <Chris.Newman@Sun.COM>
Subject: i18n support for sort & thread
To: IMAP Extensions WG <ietf-imapext@imc.org>
Message-id: <2147483647.1046287578@nifty-jr.west.sun.com>
MIME-version: 1.0
X-Mailer: Mulberry/3.0.0 (Mac OS X)
Content-type: multipart/mixed; boundary="Boundary_(ID_I25bkmf4RDmU78k34DhkmQ)"
X-message-flag: Outlook: the best virus distribution system around
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

--Boundary_(ID_I25bkmf4RDmU78k34DhkmQ)
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
Content-disposition: inline

I tried to make the I-D deadline for this and missed.  Turns out it was a 
significantly bigger project than I expected.

Attached is a preliminary draft for the "comparator registry" spec which 
also defines the "basic" ordering algorithm (by reference to the Unicode 
Collation Algorithm).  My understanding is that this is also the algorithm 
implemented by the widely regarded ICU open-source library.

The second piece I have not finished yet is an IMAP extension which adds a 
command to negotiate the comparator the server will use.  I also plan to 
fold the old language extension into this draft so both language and 
comparator can be negotiated in one round trip with a single "NEGOTIATE" 
command (structured so future extensions could share the command).

These two specs in combination with the current SORT and THREAD draft 
should make SORT and THREAD acceptable to the IESG on the grounds we have 
adequate facilities for i18n users.

Comments are welcome.

I will be seeking a wider audience for the comparator spec relatively soon, 
as it needs serious review by Unicode/i18n experts.  But this gives us 
something to start.

                - Chris

--Boundary_(ID_I25bkmf4RDmU78k34DhkmQ)
Content-type: text/plain; charset=iso-8859-1; name=comparator.txt
Content-transfer-encoding: 7BIT
Content-disposition: attachment; filename=comparator.txt; size=46765



Network Working Group                                          C. Newman
Internet-Draft                                          Sun Microsystems
Expires: August 27, 2003                               February 26, 2003


           Internet Application Protocol Comparator Registry
                draft-newman-i18n-comparator-00pre1.txt

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at http://
   www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 27, 2003.

Copyright Notice

   Copyright (C) The Internet Society (2003). All Rights Reserved.

Abstract

   Many Internet application protocols include string-based lookup,
   searching, or sorting operations.  However the problem space for
   searching and sorting international strings is large, not fully
   explored, and is outside the area of expertise for the Internet
   Engineering Task Force (IETF).  Rather than attempt to solve such a
   large problem, this specification creates an abstraction framework so
   that application protocols can precisely identify a comparison
   function and we can extend the repertoire of comparison functions in
   the future.







Newman                  Expires August 27, 2003                 [Page 1]

Internet-Draft            Comparator Registry              February 2003


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   1.1 Conventions Used in this Document  . . . . . . . . . . . . . .  3
   2.  Comparator Definition and Purpose  . . . . . . . . . . . . . .  3
   3.  Comparator Name Syntax . . . . . . . . . . . . . . . . . . . .  4
   4.  Comparator Specification Requirements  . . . . . . . . . . . .  5
   5.  Application Protocol Requirements  . . . . . . . . . . . . . .  7
   6.  Initial Comparators  . . . . . . . . . . . . . . . . . . . . .  8
   6.1 Octet Comparator . . . . . . . . . . . . . . . . . . . . . . .  8
   6.2 ASCII Numeric Comparator . . . . . . . . . . . . . . . . . . .  9
   6.3 ASCII Casemap Comparator . . . . . . . . . . . . . . . . . . . 10
   6.4 Nameprep Comparator  . . . . . . . . . . . . . . . . . . . . . 10
   6.5 Basic Comparator . . . . . . . . . . . . . . . . . . . . . . . 10
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   7.1 Comparator Registration Procedure  . . . . . . . . . . . . . . 13
   7.2 Comparator Registration Template . . . . . . . . . . . . . . . 14
   7.3 Octet Comparator Registration  . . . . . . . . . . . . . . . . 14
   7.4 ASCII Numeric Comparator Registration  . . . . . . . . . . . . 14
   7.5 ASCII Casemap Comparator Registration  . . . . . . . . . . . . 15
   7.6 Nameprep Comparator Registration . . . . . . . . . . . . . . . 15
   7.7 Basic Comparator Registration  . . . . . . . . . . . . . . . . 15
   7.8 Structure of Comparator Registry . . . . . . . . . . . . . . . 16
   7.9 Example Initial Registry . . . . . . . . . . . . . . . . . . . 17
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 19
   A.  Use by ACAP and Sieve  . . . . . . . . . . . . . . . . . . . . 19
   B.  Guidelines for Expert Reviewer . . . . . . . . . . . . . . . . 19
   C.  RFC Editor Directions  . . . . . . . . . . . . . . . . . . . . 20
       Normative References . . . . . . . . . . . . . . . . . . . . . 17
       Informative References . . . . . . . . . . . . . . . . . . . . 18
   D.  Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . . 20
       Intellectual Property and Copyright Statements . . . . . . . . 22


















Newman                  Expires August 27, 2003                 [Page 2]

Internet-Draft            Comparator Registry              February 2003


1. Introduction

   The ACAP [11] specification introduced the concept of a comparator,
   but failed to create an IANA registry.  With the introduction of
   stringprep [5], it is now time to create that registry and populate
   it with some initial values appropriate for an international
   community.  This specification replaces and generalizes the
   definition of a comparator in ACAP and creates a comparator registry.

1.1 Conventions Used in this Document

   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
   in this document are to be interpreted as defined in "Key words for
   use in RFCs to Indicate Requirement Levels" [1].

   The attribute syntax specifications use the Augmented Backus-Naur
   Form (ABNF) [2] notation including the core rules defined in Appendix
   A.  This also inherits ABNF rules from Language Tags [4].

2. Comparator Definition and Purpose

   A comparator is a named function which takes two arbitrary length
   octet strings (encoded in UTF-8 [3] for comparators which operate on
   characters) as input and can be used to perform one or more of three
   basic comparison operations: equality test, substring match and
   ordering test.

   Comparators provide a multi-protocol abstraction layer for comparsion
   functions so the details of a particular comparsion operation can be
   specified by someone with appropriate expertise independent of the
   application protocol that consumes that comparator.  This is similar
   to the way a charset [14] separates the details of octet to character
   mapping from a protocol specification such as MIME [8] or the way
   SASL [10] separates the details of an authentication mechanism with
   optional security layer from a protocol specification such as ACAP
   [11].















Newman                  Expires August 27, 2003                 [Page 3]

Internet-Draft            Comparator Registry              February 2003


   Here a a small diagram to help illustrate the value of this
   abstraction layer:

                                                 +-----------------+
                                                 | Octet           |
   +-------------------+                      +--| Comparator Spec |
   | IMAP i18n SEARCH  |--+                   |  +-----------------+
   +-------------------+  |  +-------------+  |  +-----------------+
                          +--| Comparator  |--+--| A stringprep    |
   +-------------------+  |  | Registry    |  |  | Comparator Spec |
   | ACAP i18n SEARCH  |--+  +-------------+  |  +-----------------+
   +-------------------+                      |  +-----------------+
                                              |  | locale-specific |
                                              +--| Comparator Spec |
                                                 +-----------------+

   Thus IMAP, ACAP and future application protocols with international
   search capability simply specify how to interface to the comparator
   registry instead of each protocol spec having to specify all the
   comparators it supports.

3. Comparator Name Syntax

   The comparator name itself is a single US-ASCII string beginning with
   a letter and made up of letters, digits, or one of the following 4
   symbols: "-", ";", "." or "=".  The name MUST NOT be longer than 255
   characters.

     comparator-char  =  ALPHA / DIGIT / "-" / ";" / "=" / "."

     comparator-name  =  ALPHA *254comparator-char

   The string a client uses to select a comparator MAY contain a
   wildcard ("*") character which matches zero or more comparator-chars.
   Wildcard characters MUST NOT be adjacent.  Clients which support
   disconnected operation SHOULD NOT use wildcards to select a
   comparator, but clients which provide comparator operations only when
   connected to the server MAY use wildcards.  If the wildcard string
   matches multiple comparators, the server SHOULD select the comparator
   with the broadest scope (perferably i18n), the most recent table
   versions and the greatest number of supported operations.  A single
   wildcard character ("*") specifies use of the mandatory-to-implement
   comparator as specified in the most recent application protocol
   standard to which the server complies.







Newman                  Expires August 27, 2003                 [Page 4]

Internet-Draft            Comparator Registry              February 2003


   When used as a protocol element for ordering, the comparator name MAY
   be prefixed by either "+" or "-" to explicitly specify an ordering
   direction.  As mentioned previously, "+" has no effect on the
   ordering function, while "-" negates the result of the ordering
   function.

     comparator-wild  =  ("*" / (ALPHA ["*"])) *(comparator-char ["*"])
                         ; MUST NOT exceed 255 characters total

     comparator-order =  ["+" / "-"] comparator-wild

   While this specification makes no absolute requirements on the
   structure of comparator names, naming consistancy is important, so
   the following initial guidelines are provided.

   Comparator names with an international audience typically begin with
   "i;".  Comparator names intended for a particular language or locale
   typically begin with a language tag [4] followed by a ";".  After the
   first ";" is normally the name of the general comparator algorithm
   followed by a series of algorithm modifications separated by the "-"
   delimiter.  Parameterized modifications will use "=" to delimit the
   parameter from the value.  The version numbers of any lookup tables
   used by the algorithm SHOULD be present as parameterized
   modifications.  This is typically followed by a ";" and a name for a
   set of customizations applied to the basic algorithm.

   Comparator names of the form *;vnd-domain.com;* are reserved for
   vendor-specific comparators created by the owner of the domain name
   following the "vnd-" prefix.  Registration of such comparators (or
   the namespace as a whole) with intended use of "Vendor" is encouraged
   when a public specification or open-source implementation is
   available, but is not required.

4. Comparator Specification Requirements

   A comparator specification MUST state which of the three basic
   functions are supported (equality, substring, ordering) and how to
   perform each of the supported functions on any two input
   octet-strings including empty strings.  Given a comparator with a
   specific name, and any two fixed input strings, the result MUST be
   the same.  The comparator specification MUST state whether the
   comparator operates on raw octets or on characters (in which case the
   UTF-8 charset is presumed).  Comparators MUST be transitive.

   Comparators which use tables in a documented format MUST assign
   numbers to the tables they use.  This permits an application protocol
   command to access the tables used by a server comparator.




Newman                  Expires August 27, 2003                 [Page 5]

Internet-Draft            Comparator Registry              February 2003


   o  The equality function always returns "match" or "no-match" when
      supplied valid input and MAY return "error" if the input strings
      are not valid UTF-8 strings or violate other comparator
      constraints.

   o  The substring matching function determines if the first string is
      a substring of the second string.  A comparator which supports
      substring matching will automatically support the two special
      cases of substring matching: prefix and suffix matching if those
      special cases are supported by the application protocol.  It
      returns "match" or "no-match" when supplied valid input and
      returns "error" when supplied invalid input.

   o  The ordering function determines how two octet strings are
      ordered.  It returns "-1" if the first string is listed before the
      second string according to the comparator, "+1" if the second
      string is listed before the first string, and "0" if the two
      strings are equal.  If the order of the two strings is reversed,
      the result of the ordering function of the comparator MUST be
      negated.  In general, comparators SHOULD NOT return "0" unless the
      two octet sequences are identical.

      Since ordering is normally used to sort a list of items, "error"
      is not a useful return value from the ordering function.  Strings
      with errors that prevent the sorting algorithm from functioning
      correctly should sort to the end of the list.  Thus if the first
      string is invalid UTF-8 while the second string is valid, the
      result will be "+1".  If the second string is invalid UTF-8 while
      the first string is valid, the result will be "-1".  If the
      comparator is character-based, and both strings are invalid UTF-8,
      the result SHOULD match the result from the "i;octet" comparator.

      When the comparator is used with a "+" prefix, the behavior is the
      same as when used with no prefix.  When the comparator is used
      with a "-" prefix, results which would be "+1" are instead "-1"
      and results which would be "-1" are instead "+1".

   Unless otherwise specified by the comparator or application protocol,
   a NULL string (as opposed to an empty string) is equal only to
   another NULL string, a NULL string is not a substring of any other
   string, and a NULL string sorts to a position after all non-NULL
   strings, but before strings which generate errors.

   Some application protocols will permit the use of a multi-value
   attributes with a comparator.  This paragraph describes the rules
   that apply unless otherwise specified by the comparator or
   application protocol.  The equality and substring comparator
   algorithms will be iterated over each pair of single values from the



Newman                  Expires August 27, 2003                 [Page 6]

Internet-Draft            Comparator Registry              February 2003


   two inputs.  If any combination produces an error, the result is an
   error.  Otherwise, if any combination produces a "match", the result
   is a match.  Otherwise the result is "no-match".  For the ordering
   function, the smallest ordinal octet string from the first set of
   values is compared to the smallest ordinal octet string from the
   second set of values.

   Application protocols MAY return position information for substring
   matches.  If this is done, the position information MUST include both
   the starting offset and the ending offset in the string.  This is
   important because canonicalization can cause strings with different
   numbers of characters to match.

   Comparator specifications intended for general use are expected to
   reference standards from other standards bodies with more experience
   dealing with the details of international character sets.

5. Application Protocol Requirements

   An application protocol which offers searching, substring matching
   and/or sorting and permits the use of characters outside the US-ASCII
   charset needs to consider the following requirements and issues:

   The protocol MUST provide a mechanism for the client to select the
   comparator to use with equality matching, substring matching and
   ordering.

   The protocol MUST specify at least one mandatory-to-implement
   comparator which provides basic results acceptable to multiple
   languages.  The mandatory-to-implement comparator MUST be specified
   in an IESG-approved RFC as suitable for that purpose.  The
   mandatory-to-implement comparator MUST support the subset of the
   three comparator operations that are likely to be used by the
   protocol and widely deployed extensions to the protocol.

   The protocol SHOULD provide a way to list available comparators
   matching a given wildcard pattern or patterns.

   If the protocol provides positional information for the results of a
   substring match, that positional information MUST fully specify the
   substring in the result that matches independent of the length of the
   search string.  For example, returning both the starting and ending
   offset of the match would suffice, as would the starting offset and a
   length.  Returning just the starting offset is not acceptable.

   If the protocol permits the use of comparators on stored character
   data which is not encoded with the UTF-8 charset, then the protocol
   specification has to describe relevant issues of the conversion.



Newman                  Expires August 27, 2003                 [Page 7]

Internet-Draft            Comparator Registry              February 2003


   Details to consider include how to handle unknown charsets, any
   charsets which are mandatory to support, any issues with byte-order
   that might apply, and any transfer encodings which need to be
   supported.

   If the protocol supports disconnected clients, then a mechanism for
   the client to precisely replicate the server's comparator algorithm
   is likely desirable.  Thus the protocol MAY wish to provide a command
   to fetch tables used by charset conversions and comparators.

   The protocol specification should consider assigning protocol error
   codes for the following circumstances:

   o  The client requests the use of a comparator by name or pattern,
      but no implemented comparator matches that pattern.

   o  The client attempts to use a comparator for a function that is not
      supported by that comparator.  For example, attempting to use the
      "i;ascii-numeric" comparator for a substring matching function.

   o  The client uses an equality or substring matching comparator and
      the result is an error.  It may be appropriate to distinguish
      between the two input strings, particularly when one is supplied
      by the client and one is stored by the server.  It might also be
      appropriate to distinguish the specific case of an invalid UTF-8
      string.

   If the protocol permits the use of a comparator with data structures
   beyond those described in this specification (octet strings, NULL
   string, array of octet strings), the protocol MUST describe the
   default behavior for a comparator with that data structure.

6. Initial Comparators

   This section describes an initial set of comparators for the
   comparator registry.

6.1 Octet Comparator

   The "i;octet" comparator is a simple and fast comparator intended for
   use on binary octet strings rather than on character data.  It never
   returns an "error" result.  It provides equality, substring and
   ordering functions.  The ordering algorithm is as follows:

   1.  If both strings are the empty string, return the result "0".

   2.  If the first string is empty and the second is not, return the
       result "-1".



Newman                  Expires August 27, 2003                 [Page 8]

Internet-Draft            Comparator Registry              February 2003


   3.  If the second string is empty and the first is not, return the
       result "+1".

   4.  If both strings begin with the same octet value, remove the first
       octet from both strings and repeat this algorithm from step 1.

   5.  If the unsigned value (0 to 255) of the first octet of the first
       string is less than the unsigned value of the first octet of the
       second string, then return "-1".

   6.  If this step is reached, return "+1".

   This algorithm is roughly equivalent to the C library function memcmp
   with appropriate length checks added.

   The matching function returns "match" if the sorting algorithm would
   return "0".  Otherwise the matching function returns "no-match".

   The substring function returns "match" if the first string is the
   empty string, or if there exists a substring of the second string of
   length equal to the length of the first string which would result in
   a "match" result from the equality function.  Otherwise the substring
   function returns "no-match".

6.2 ASCII Numeric Comparator

   The "i;ascii-numeric" comparator is a simple comparator intended for
   use with arbitrary sized decimal numbers stored as octet strings of
   US-ASCII digits (0x30 to 0x39).  It supports equality and ordering,
   but does not support the substring function.  The algorithm is as
   follows:

   1.  If neither string begins with a digit, return "error" if
       matching, or the result of the "i;octet" comparator for ordering.

   2.  If the first string begins with a digit and the second string
       does not, return "error" if matching and "-1" for ordering.

   3.  If the second string begins with a digit and the first string
       does not, return "error" if matching and "+1" for ordering.

   4.  Let "n" be the number of digits at the beginning of the first
       string, and "m" be the number of digits at the beginning of the
       second string.

   5.  If n is equal to m, return the result of the "i;octet"
       comparator.




Newman                  Expires August 27, 2003                 [Page 9]

Internet-Draft            Comparator Registry              February 2003


   6.  If n is greater than m, prepend a string of "n - m" zeros to the
       second string and return the result of the "i;octet" comparator.

   7.  If m is greater than n, prepend a string of "m - n" zeros to the
       first string and return the result of the "i;octet" comparator.


6.3 ASCII Casemap Comparator

   The "i;ascii-casemap" comparator is a simple comparator intended for
   use with English language text in pure US-ASCII.  It provides
   equality, substring and ordering functions.  The algorithm first
   applies a mapping to both input strings which subtracts 32 (0x20)
   from all octet values between the range 97 (0x61) and 122 (0x7A)
   inclusive.  The result of the comparator is then the same as the
   result of the "i;octet" comparator for the resulting strings.  Note
   that this comparator is _not_ equivalent to the strcasecmp or stricmp
   functions available on some platforms which are often
   locale-sensitive.

   This comparator is deprecated for the following two reasons: 1. It
   should have been called "en;ascii-casemap" rather than
   "i;ascii-casemap" (it has not been renamed in order to retain
   compatibility with the ACAP and Sieve specifications). 2. It is
   undesirable to have an ordering algorithm return "0" when the two
   input strings are not identical as this can produce inconsistent
   results when the ordering function is used to sort a list.

6.4 Nameprep Comparator

   The "i;nameprep-rfc=YYYY-uv=3.2" comparator is an implementation of
   the nameprep [6] FIXME specification as documented in RFC YYYY and
   based on normalization tables from Unicode version 3.2.  This
   comparator provides equality and substring matching, but does not
   provide the ordering function.  This comparator is suitable for use
   as the only mandatory-to-implement comparator for a protocol which
   does not offer ordering or sorting in the base spec and is unlikely
   to do so in a widely implemented protocol extension.

   If the nameprep specification is revised without any changes that
   would produce different results when given different input octet
   strings, then the name of this comparator will remain unchanged.

6.5 Basic Comparator

   The basic comparator is intended to privide tolerable results for a
   number of languages for all three functions (equality, substring and
   ordering) so it is suitable as a mandatory-to-implement comparator



Newman                  Expires August 27, 2003                [Page 10]

Internet-Draft            Comparator Registry              February 2003


   for protocols which include ordering support.  The ordering function
   of the basic comparator is the  version 9 (UCAv9).

   The equality and substring functions are created as described in
   UCAv9 section 8.  While that section is informative to UCAv9, it is
   normative to this comparator specification.

   This comparator is based on Unicode version 3.2, with the following
   tables relevant:

   1.  For the normalization step, UnicodeData-3.2.0.txt [16] is used.
       Column 5 is used to determine the canonical decomposition, while
       column 3 contains the canonical combining classes necessary to
       attain canonical order.

   2.  The table of characters which require a logical order exception
       is a subset of the table in PropList-3.2.0.txt [17] and is
       included here:

   0E40..0E44    ; Logical_Order_Exception
   # Lo   [5] THAI CHARACTER SARA E..THAI CHARACTER SARA AI MAIMALAI
   0EC0..0EC4    ; Logical_Order_Exception
   # Lo   [5] LAO VOWEL SIGN E..LAO VOWEL SIGN AI

   # Total code points: 10

   3.  The table used to translate normalized code points to a sort key
       is allkeys-3.1.1.txt [18].

   UCAv9 includes a number of configurable parameters and steps labelled
   as potentially optional.  The following list summarizes the defaults
   used by this comparator:

   o  The logical order exception step is mandatory by default to
      support the largest number of languages.

   o  Steps 2.1.1 to 2.1.3 are mandatory as the repertoire of the basic
      comparator is intended to be large.

   o  The second level in the sort key is evaluated forwards by default.

   o  The variable weighting uses the "non-ignorable" option by default.

   o  The semi-stable option is not used by default.

   o  Support for exactly three levels of collation is the default
      behavior.




Newman                  Expires August 27, 2003                [Page 11]

Internet-Draft            Comparator Registry              February 2003


   o  No preprocessing step is used by the basic comparator prior to
      applying the UCAv9 algorithm.  Note that an application protocol
      specification MAY require pre-processing prior to the use of any
      comparators.

   o  The equality and substring algorithms exclude differences at level
      2 and 3 by default (thus it is case-insensitive and ignores
      accentual distinctions.

   o  The equality and substring algorithms use the "Whole Characters
      Only" feature described in UCAv9 section 8 by default.

   The exact comparator name with these defaults is
   "i;basic-uca=3.1.1-uv=3.2".  When a specification states that the
   basic comparator is mandatory-to-implement, only this specific name
   is mandatory-to-implement.

   In order to allow modification of the optional behaviors, the
   following ABNF is used for variations of the basic comparator:

     basic-comparator  =  ("i" / Language-Tag) ";basic" basic-modifiers
                          "-uca=3.1.1-uv=3.2" [";custom=" 1*comparator-char ]

     basic-modifiers   =  ["-2backwards"]
                          ["-blanked" / "-shifted" / "-shift-trimmed"]
                          ["-semi-stable"]
                          ["-quatlu"]
                          ["-match=accent" / "-match=case"]

   If multiple modifiers appear, they MUST appear in the order described
   above.  The modifiers have the following meanings:

   2backwards When this modifier is selected, the order of the second
      level sort keys is reversed.  This is useful for French
      customizations.

   blanked Use the "blanked" variable weighting option described in
      UCAv9 section 3.2.2 rather than the default "non-ignorable".

   shifted Use the "shifted" variable weighting option described in
      UCAv9 section 3.2.2. rather than the default "non-ignorable".

   shift-trimmed Use the "shift-trimmed" variable weighting option
      described in UCAv9 section 3.2.2. rather than the default
      "non-ignorable".






Newman                  Expires August 27, 2003                [Page 12]

Internet-Draft            Comparator Registry              February 2003


   semi-stable Use the "semi-stable" option.  This involves appending
      the input string to the end of the computed sort keys so that only
      two identical strings will produce a result of "0" from the order
      function.

   quatlu Use the 4th level weight from the allkeys file for the
      ordering function.

   match=accent Both the first and second levels of the sort keys are
      considered relevent to the equality and substring operations
      (rather than the default of first level only).  This makes the
      matching functions sensitive to accentual distinctions.

   match=case The first three levels of sort keys are considered
      relevent to the equality and substring operations.  This makes the
      matching functions sensitive to both case and accentual
      distinctions.

   Finally, the UCAv9 algorithm permits the "allkeys" table to be
   customized.  People who make a quality customizations are encouraged
   to register those customizations.  Customization names beginning with
   "x" are reserved for experimental use, are treated as "Limited use"
   and MUST NOT match wildcards if any registered comparator is
   available that does match.

7. IANA Considerations

7.1 Comparator Registration Procedure

   IANA will create a mailing list comparator@iana.org which can be used
   for public discussion of comparator proposals prior to registration.
   Use of the mailing list is encouraged but not required.  The actual
   registration procedure will not begin until the completed
   registration template is sent to iana@iana.org.  The IESG will
   appoint a designated expert who will monitor the comparator@iana.org
   mailing list and review registrations forwarded from IANA.  The
   designated expert is expected to tell IANA and the submittor of the
   registration within two weeks whether the registration is approved,
   approved with minor changes, or rejected with cause.  When a
   registration is rejected with cause, if it can be re-submitted if the
   concerns listed in the cause are addressed.  Decisions made by the
   designated expert can be appealed to the IESG and subsequently follow
   the normal appeals procedure for IESG decisions.

   Comparator registrations in a standards track, BCP or IESG-approved
   experimental RFC are owned by the IESG and changes to the
   registration follow normal procedures for updating such documents.
   Comparator registrations in other RFCs are owned by the RFC



Newman                  Expires August 27, 2003                [Page 13]

Internet-Draft            Comparator Registry              February 2003


   author(s).  Other comparator registrations are owned by the
   individual(s) listed in the contact field of the registration and
   IANA will perserve this information.  Changes to a registration MUST
   be approved by the owner.  In the event the owner can't be contacted
   for a period of one month and a change is deemed necessary, the IESG
   MAY re-assign ownership to an appropriate party (preferably from the
   same organization as the original owner).

7.2 Comparator Registration Template

   Comparator Name: {see comparator-wild syntax (Section 3)}

   Published Specification(s):

   Supported Functions: {one or more of "equality", "substring" and
   "order"}

   Scope: {"i18n", "Local", "Other"}

   Intended Use: {"Common", "Limited", "Vendor", "Deprecated"}

   Person and email address to contact for further information:

7.3 Octet Comparator Registration

   Comparator Name: i;octet

   Published Specification: RFC XXXX Section 6.1

   Supported Functions: equality, substring, order

   Scope: Other

   Intended Use: Common

   Person and email address to contact for further information:

   See the "Author's Address" section near the end of this
   specification.

7.4 ASCII Numeric Comparator Registration

   Comparator Name: i;ascii-numeric

   Published Specification: RFC XXXX Section 6.2

   Supported Functions: equality, order




Newman                  Expires August 27, 2003                [Page 14]

Internet-Draft            Comparator Registry              February 2003


   Scope: Other

   Intended Use: Limited

   Person and email address to contact for further information:

   See the "Author's Address" section near the end of this
   specification.

7.5 ASCII Casemap Comparator Registration

   Comparator Name: i;ascii-casemap

   Published Specification: RFC XXXX Section 6.3

   Supported Functions: equality, substring, order

   Scope: Local

   Intended Use: Deprecated

   Person and email address to contact for further information:

   See the "Author's Address" section near the end of this
   specification.

7.6 Nameprep Comparator Registration

   Comparator Name: i;nameprep-RFC=YYYY-uv=3.2

   Published Specification: RFC XXXX Section 6.4

   Supported Functions: equality, substring

   Scope: i18n

   Intended Use: Common

   Person and email address to contact for further information:

   See the "Author's Address" section near the end of this
   specification.

7.7 Basic Comparator Registration

   Comparator Name: i;basic-*uca=3.1.1-uv=3.2

   Published Specification: RFC XXXX Section 6.5



Newman                  Expires August 27, 2003                [Page 15]

Internet-Draft            Comparator Registry              February 2003


   Supported Functions: equality, substring, order

   Scope: i18n

   Intended Use: Common

   Person and email address to contact for further information:

   See the "Author's Address" section near the end of this
   specification.

7.8 Structure of Comparator Registry

   The comparator registry itself is divided into four sections.  The
   first section is for comparators intended for common use.  This
   section is intended for comparator registrations published in IESG
   approved RFCs or for locally scoped comparators from the primary
   standards body for that locale.  The designated expert is encouraged
   to reject a comparator registrations with an intended use of "common"
   if the expert believes it should be "limited", as it is desirable to
   keep the number of "common" registrations small and high quality.
   The second section is reserved for limited use comparators.  The
   third section is reserved for registered vendor specific comparators.
   The final section is reserved for depreated comparators.



























Newman                  Expires August 27, 2003                [Page 16]

Internet-Draft            Comparator Registry              February 2003


7.9 Example Initial Registry

   The following is an example of how IANA might structure the initial
   registry:

     Comparator                        Functions Scope Reference
     ----------                        --------- ----- ---------
   Common Use Comparators:
     i;octet                           e, s, o   Other [RFC XXXX]
     i;nameprep-rfc=YYYY-uv=3.2        e, s      i18n  [RFC XXXX]
     i;basic-*uca=3.1.1-uv=3.1.1       e, s, o   i18n  [RFC XXXX]

   Limited Use Comparators:
     i;ascii-numeric                   e, o      Other [RFC XXXX]

   Vendor Comparators:

   Deprecated Comparators:
     i;ascii-casemap                   e, s, o   Local [RFC XXXX]


   References
   ----------
   [RFC XXXX]  Newman, C., "Internet Application Protocol Comparator
               Registry", RFC XXXX, Sun Microsystems, February 2003.


8. Security Considerations

   Comparators will normally be used with UTF-8 strings.  Thus the
   security considerations for UTF-8 [3] and stringprep [5] also apply
   and are normative to this specification.

Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [2]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
        Specifications: ABNF", RFC 2234, November 1997.

   [3]  Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
        2279, January 1998.

   [4]  Alvestrand, H., "Tags for the Identification of Languages", BCP
        47, RFC 3066, January 2001.

   [5]  Hoffman, P. and M. Blanchet, "Preparation of Internationalized



Newman                  Expires August 27, 2003                [Page 17]

Internet-Draft            Comparator Registry              February 2003


        Strings ("stringprep")", RFC 3454, December 2002.

   [6]  Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile for
        Internationalized Domain Names", draft-ietf-idn-nameprep-11
        (work in progress), June 2002.

   [7]  Davis, M. and K. Whistler, "Unicode Collation Algorithm version
        9", July 2002, <http://www.unicode.org/reports/tr10/
        tr10-9.html>.

Informative References

   [8]   Freed, N. and N. Borenstein, "Multipurpose Internet Mail
         Extensions (MIME) Part One: Format of Internet Message Bodies",
         RFC 2045, November 1996.

   [9]   Freed, N. and N. Borenstein, "Multipurpose Internet Mail
         Extensions (MIME) Part Two: Media Types", RFC 2046, November
         1996.

   [10]  Myers, J., "Simple Authentication and Security Layer (SASL)",
         RFC 2222, October 1997.

   [11]  Newman, C. and J. Myers, "ACAP -- Application Configuration
         Access Protocol", RFC 2244, November 1997.

   [12]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
         Considerations Section in RFCs", BCP 26, RFC 2434, October
         1998.

   [13]  Resnick, P., "Internet Message Format", RFC 2822, April 2001.

   [14]  Freed, N. and J. Postel, "IANA Charset Registration
         Procedures", BCP 19, RFC 2978, October 2000.

   [15]  Showalter, T., "Sieve: A Mail Filtering Language", RFC 3028,
         January 2001.

URIs

   [16]  <http://www.unicode.org/Public/3.2-Update/
         UnicodeData-3.2.0.txt>

   [17]  <http://www.unicode.org/Public/3.2-Update/PropList-3.2.0.txt>

   [18]  <http://www.unicode.org/reports/tr10/allkeys-3.1.1.txt>





Newman                  Expires August 27, 2003                [Page 18]

Internet-Draft            Comparator Registry              February 2003


Author's Address

   Chris Newman
   Sun Microsystems
   1050 Lakes Drive
   West Covina, CA  91790
   US

   EMail: chris.newman@sun.com

Appendix A. Use by ACAP and Sieve

   Both ACAP [11] and Sieve [15] are standards track protocols which
   used comparators prior to the creation of this specification.  Those
   standards do not meet all the application protocol requirements
   described in section Section 5.  It is expected that if ACAP is
   revised, the basic comparator will be mandatory to implement, and if
   Sieve is revised, the nameprep comparator will be mandatory to
   implement.

Appendix B. Guidelines for Expert Reviewer

   The expert reviewer appointed by the IESG has fairly broad lattitude
   for this registry.  While a number of comparators are expected
   particularly customizations of the basic comparator for localized
   use, an explosion of comparators (particularly common use
   comparators) is not desirable for widespread interoperability.
   However, it is important for the expert reviewer to provide cause
   when rejecting a registration, and when possible to describe
   corrective action to permit the registration to proceed.  The
   following table includes some possible reasons to reject a
   registration with cause:

   o  The registration has intended use of "common", but there is no
      evidence the comparator will be widely deployed so it should be
      listed as "limited".

   o  The registration has intended use of "common", but is redundant
      with the functionality of a previously registered "common"
      comparator.

   o  The comparator name fails to precisely identify the version
      numbers of relevant tables to use.

   o  The registration fails to meet one of the "MUST" requirements in
      section Section 4.

   o  The comparator name fails to meet the syntax in Section 3.



Newman                  Expires August 27, 2003                [Page 19]

Internet-Draft            Comparator Registry              February 2003


   o  The comparator specification referenced in the registration is
      vague or has optional features without a clear behavior specified.

   o  The referenced specification does not adequately address security
      considerations specific to that comparator.


Appendix C. RFC Editor Directions

   Please replace all occurances of "XXXX" with the assigned RFC number
   for this specification.  Please replace all occurances of "YYYY" with
   the assigned RFC number for the nameprep [6] FIXME specification.

Appendix D. Open Issues

   1.  Should we permit non-ASCII characters in the comparator name?
       The benefit of allowing non-ASCII characters in the comparator
       name is it would make presenting comparators to an end-user
       simple, particularly if comparator names were structured to
       include a user-friendly name as part of the conventional
       structure.  However, because there are other solutions to the
       problem of user friendly selection of a comparator which would
       add less complexity to the common case, the author has errored on
       the side of simplicity.  As long as the set of common use
       comparators (excluding versions) is relatively small, user
       friendly names can be part of the client (ideally admin
       configuration for the client).  If the registry becomes large,
       then a lookup service could be used to translate a comparator
       name into a user-friendly name.

   2.  Is any Nameprep processing appropriate for the basic comparator?
       Because a result of "0" from an ordering algorithm is
       undesirable, much of the nameprep processing is inappropriate.
       Furthermore, a result of "error" which is important for nameprep
       is generally inappropriate as an internal result in an ordering
       algorithm since it makes the results less intuitive.  The sort
       key table also eliminates most problematic characters from
       consideration if the appropriate comparator modifier is used.
       Finally, exact compatibility with the Unicode Collation Algorithm
       is deemed desirable by the author, as even the smallest variation
       may require implementation of largely duplicate code.  However,
       this decision is outside my expertise, so I welcome alternate
       viewpoints.

   3.  The ICU implementation of the UCA algorithm includes additional
       algorithmic customizations such as the ability to be
       case-sensitive while at the same time being insensitive to
       accents.  Should these customizations be added to this



Newman                  Expires August 27, 2003                [Page 20]

Internet-Draft            Comparator Registry              February 2003


       specification?

   4.  Should a format for customization data for the basic comparator
       be defined so that disconnected clients might have the option of
       downloading that information.














































Newman                  Expires August 27, 2003                [Page 21]

Internet-Draft            Comparator Registry              February 2003


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive
   Director.


Full Copyright Statement

   Copyright (C) The Internet Society (2003). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION



Newman                  Expires August 27, 2003                [Page 22]

Internet-Draft            Comparator Registry              February 2003


   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.











































Newman                  Expires August 27, 2003                [Page 23]


--Boundary_(ID_I25bkmf4RDmU78k34DhkmQ)--


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1OJuH925509 for ietf-imapext-bks; Mon, 24 Feb 2003 11:56:17 -0800 (PST)
Received: from eagle.oceana.com ([208.17.123.12]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1OJuGd25505 for <ietf-imapext@imc.org>; Mon, 24 Feb 2003 11:56:16 -0800 (PST)
Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.7/8.12.7) with ESMTP id h1OJtfms007220; Mon, 24 Feb 2003 14:55:41 -0500
Message-ID: <3E5A7945.20166E02@oceana.com>
Date: Mon, 24 Feb 2003 14:57:57 -0500
From: Ken Murchison <ken@oceana.com>
Organization: Oceana Matrix Ltd.
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Cyrus Daboo <daboo@cyrusoft.com>
CC: Barry Leiba <leiba@watson.ibm.com>, IMAP extensions Mailing List <ietf-imapext@imc.org>
Subject: Re: I-D ACTION:draft-ietf-imapext-list-extensions-03.txt
References: <200302241146.GAA09097@ietf.org>	 <1046094255.788.81.camel@hurina>	 <020d01c2dc14$9eb9f980$40280209@watson.ibm.com> <2147483647.1046084494@[63.163.82.24]> <3E5A680A.DCE57D65@oceana.com> <2147483647.1046096120@[63.163.82.24]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

Cyrus Daboo wrote:
> 
> Hi Ken,
> 
> --On Monday, February 24, 2003 1:44 PM -0500 Ken Murchison <ken@oceana.com>
> wrote:
> 
> |> Leave it as it is. Future list option extensions (if there are any) can
> |> simply extend the option syntax for their own set of options and
> |> advertise that via CAPABILITY. However, I think the following statement
> |> in the first paragrph of Section 4:
> |
> | Correct me if I'm wrong, but if we don't state up front that an option
> | may be a sublist, won't parsers based on the current grammar fail on the
> | example above?  If I'm just looking for atoms, neither "(NAME" nor
> | "DATE)" are valid, so we'll always get a BAD response.
> 
> Each option can only be legitimately used if advertised by the server. So
> if there were a LISTEXT-SORT extension and that defined a 'SORT' option
> that had an argument that was a parenthesized list then both the server and
> client would know how to deal with that along with all the other options.

Understood.  But in your original message, you suggested returning a NO
when the option isn't recognized by the server (presumably when a client
tries to use an option not advertised by the server -- how else would it
be unrecognized).  I don't care whether we return NO or BAD in this
case, but I just wanted to point out that there might be a difference
between unrecognized and unparsable.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1OJFUX24033 for ietf-imapext-bks; Mon, 24 Feb 2003 11:15:30 -0800 (PST)
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1OJFTd24024 for <ietf-imapext@imc.org>; Mon, 24 Feb 2003 11:15:29 -0800 (PST)
Received: from [63.163.82.24] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id OAA19920; Mon, 24 Feb 2003 14:12:04 -0500 (EST)
Date: Mon, 24 Feb 2003 14:15:20 -0500
From: Cyrus Daboo <daboo@cyrusoft.com>
To: Ken Murchison <ken@oceana.com>
cc: Barry Leiba <leiba@watson.ibm.com>, IMAP extensions Mailing List <ietf-imapext@imc.org>
Subject: Re: I-D ACTION:draft-ietf-imapext-list-extensions-03.txt
Message-ID: <2147483647.1046096120@[63.163.82.24]>
In-Reply-To: <3E5A680A.DCE57D65@oceana.com>
References: <200302241146.GAA09097@ietf.org>	 <1046094255.788.81.camel@hurina>	 <020d01c2dc14$9eb9f980$40280209@watson.ibm.com> <2147483647.1046084494@[63.163.82.24]> <3E5A680A.DCE57D65@oceana.com>
X-Mailer: Mulberry/3.0.2 (Mac OS/PPC)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

Hi Ken,

--On Monday, February 24, 2003 1:44 PM -0500 Ken Murchison <ken@oceana.com> 
wrote:

|> Leave it as it is. Future list option extensions (if there are any) can
|> simply extend the option syntax for their own set of options and
|> advertise that via CAPABILITY. However, I think the following statement
|> in the first paragrph of Section 4:
|
| Correct me if I'm wrong, but if we don't state up front that an option
| may be a sublist, won't parsers based on the current grammar fail on the
| example above?  If I'm just looking for atoms, neither "(NAME" nor
| "DATE)" are valid, so we'll always get a BAD response.

Each option can only be legitimately used if advertised by the server. So 
if there were a LISTEXT-SORT extension and that defined a 'SORT' option 
that had an argument that was a parenthesized list then both the server and 
client would know how to deal with that along with all the other options. 
There are some things to be aware of. In particular it should probably be 
stated that if future listext options require arguments, they should be 
placed in a parenthesized list to ensure they won't get confused with other 
options. Barry could probably express that in the formal grammar.

-- 
Cyrus Daboo


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1OIgpM20601 for ietf-imapext-bks; Mon, 24 Feb 2003 10:42:51 -0800 (PST)
Received: from eagle.oceana.com ([208.17.123.12]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1OIgnd20595 for <ietf-imapext@imc.org>; Mon, 24 Feb 2003 10:42:50 -0800 (PST)
Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.7/8.12.7) with ESMTP id h1OIgAms005946; Mon, 24 Feb 2003 13:42:11 -0500
Message-ID: <3E5A680A.DCE57D65@oceana.com>
Date: Mon, 24 Feb 2003 13:44:26 -0500
From: Ken Murchison <ken@oceana.com>
Organization: Oceana Matrix Ltd.
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Cyrus Daboo <daboo@cyrusoft.com>
CC: Barry Leiba <leiba@watson.ibm.com>, IMAP extensions Mailing List <ietf-imapext@imc.org>
Subject: Re: I-D ACTION:draft-ietf-imapext-list-extensions-03.txt
References: <200302241146.GAA09097@ietf.org> <1046094255.788.81.camel@hurina> <020d01c2dc14$9eb9f980$40280209@watson.ibm.com> <2147483647.1046084494@[63.163.82.24]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

Cyrus Daboo wrote:
> 
> Hi Barry,
> 
> --On Monday, February 24, 2003 9:54 AM -0500 Barry Leiba
> <leiba@watson.ibm.com> wrote:
> 
> |> Should list-options support more than just atoms list? I'm thinking of
> |> some extra options that the atoms might have. For example:
> |> LIST (SORT (NAME DATE)) "" %
> |
> | Hm, maybe.  Anyone else have thoughts on this?  We discussed this sort of
> | thing when we first started formulating LIST extensions, and we decided to
> | keep it simple... but this sort of thing might still be sufficiently
> | simple. Should we allow it?
> 
> Leave it as it is. Future list option extensions (if there are any) can
> simply extend the option syntax for their own set of options and advertise
> that via CAPABILITY. However, I think the following statement in the first
> paragrph of Section 4:

Correct me if I'm wrong, but if we don't state up front that an option
may be a sublist, won't parsers based on the current grammar fail on the
example above?  If I'm just looking for atoms, neither "(NAME" nor
"DATE)" are valid, so we'll always get a BAD response.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1OHrUg17466 for ietf-imapext-bks; Mon, 24 Feb 2003 09:53:30 -0800 (PST)
Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1OHrSd17462 for <ietf-imapext@imc.org>; Mon, 24 Feb 2003 09:53:28 -0800 (PST)
Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [9.2.112.57]) by igw2.watson.ibm.com (8.11.4/8.11.4) with ESMTP id h1OHrNj29764 for <ietf-imapext@imc.org>; Mon, 24 Feb 2003 12:53:24 -0500
Received: from mars.watson.ibm.com (mars.watson.ibm.com [9.2.40.64]) by sp1n293en1.watson.ibm.com (8.11.4/8.11.4) with ESMTP id h1OHrNV53470 for <ietf-imapext@imc.org>; Mon, 24 Feb 2003 12:53:23 -0500
Date: Mon, 24 Feb 2003 12:53:23 -0500
From: Barry Leiba <leiba@watson.ibm.com>
To: IMAP extensions Mailing List <ietf-imapext@imc.org>
Subject: Re: I-D ACTION:draft-ietf-imapext-list-extensions-03.txt
Message-ID: <879056031.1046091203@mars.watson.ibm.com>
In-Reply-To: <1046108039.785.124.camel@hurina>
References: <200302241146.GAA09097@ietf.org>	 <1046094255.788.81.camel@hurina>	 <020d01c2dc14$9eb9f980$40280209@watson.ibm.com>	 <2147483647.1046084494@[63.163.82.24]> <1046108039.785.124.camel@hurina>
X-Mailer: Mulberry/3.0.0 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

> Another thing. If I have a mailbox named "foo.bar" with "." as
> hierarchy separator, but there's no "foo" mailbox, should LIST () ""
> % return \PlaceHolder or \Noselect for it?

"\noselect".  "\placeholder" means that it doesn't match the selection 
criteria but has a child that does, and both of those conditions are 
false (that is, it *does* match, and its children do NOT).

What's really happening here is that *logically* (if not physically, 
and remember that what IMAP is really doing is taking a physical mail 
store and exposing a logical view of it) there *is* a mailbox called 
"foo" that is not selectable (it's not selectable because it doesn't 
*physically* exist).  That's exactly what "\noselect" is there for.

Barry

--
Barry Leiba, Internet Messaging Technology  (leiba@watson.ibm.com)
http://www.research.ibm.com/people/l/leiba



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1OHqdR17433 for ietf-imapext-bks; Mon, 24 Feb 2003 09:52:39 -0800 (PST)
Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1OHqcd17429 for <ietf-imapext@imc.org>; Mon, 24 Feb 2003 09:52:38 -0800 (PST)
Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout2.cac.washington.edu (8.12.1+UW01.12/8.12.1+UW02.12) with ESMTP id h1OHq1GD029122; Mon, 24 Feb 2003 09:52:06 -0800
Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by smtp.washington.edu (8.12.1+UW01.12/8.12.1+UW02.12) with ESMTP id h1OHq1Fl028007 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 24 Feb 2003 09:52:01 -0800
Date: Mon, 24 Feb 2003 09:52:00 -0800 (PST)
From: Mark Crispin <mrc@cac.washington.edu>
To: Timo Sirainen <tss@iki.fi>
cc: Cyrus Daboo <daboo@cyrusoft.com>, Barry Leiba <leiba@watson.ibm.com>, IMAP extensions Mailing List <ietf-imapext@imc.org>
Subject: Re: I-D ACTION:draft-ietf-imapext-list-extensions-03.txt
In-Reply-To: <1046108039.785.124.camel@hurina>
Message-ID: <Pine.LNX.4.55.0302240950260.10564@shiva0.cac.washington.edu>
References: <200302241146.GAA09097@ietf.org>  <1046094255.788.81.camel@hurina> <020d01c2dc14$9eb9f980$40280209@watson.ibm.com>  <2147483647.1046084494@[63.163.82.24]> <1046108039.785.124.camel@hurina>
Organization: Networks and Distributed Computing
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

On Mon, 24 Feb 2003, Timo Sirainen wrote:
> > 'A server MUST respond to unrecognized options with a NO response.'
> Shouldn't it be BAD response?

It depends.

If the client has a way of knowing in advance that the option will not be
recognized, then BAD would the proper response.

If, on the other hand, the only way for the client to know is to try,
*and* if the grammar has a rule indicating arbitrary atom as an option
name (for future expansion), then NO is proper.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1OHY0H15818 for ietf-imapext-bks; Mon, 24 Feb 2003 09:34:00 -0800 (PST)
Received: from oma.irssi.org (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1OHXwd15810 for <ietf-imapext@imc.org>; Mon, 24 Feb 2003 09:33:58 -0800 (PST)
Received: by oma.irssi.org (Postfix, from userid 1000) id BED245E01F94; Mon, 24 Feb 2003 19:33:59 +0200 (EET)
Subject: Re: I-D ACTION:draft-ietf-imapext-list-extensions-03.txt
From: Timo Sirainen <tss@iki.fi>
To: Cyrus Daboo <daboo@cyrusoft.com>
Cc: Barry Leiba <leiba@watson.ibm.com>, IMAP extensions Mailing List <ietf-imapext@imc.org>
In-Reply-To: <2147483647.1046084494@[63.163.82.24]>
References: <200302241146.GAA09097@ietf.org> <1046094255.788.81.camel@hurina> <020d01c2dc14$9eb9f980$40280209@watson.ibm.com> <2147483647.1046084494@[63.163.82.24]>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: 
Message-Id: <1046108039.785.124.camel@hurina>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 
Date: 24 Feb 2003 19:33:59 +0200
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

On Mon, 2003-02-24 at 18:01, Cyrus Daboo wrote:
> Leave it as it is. Future list option extensions (if there are any) can 
> simply extend the option syntax for their own set of options and advertise 
> that via CAPABILITY.

Right, that's better.

> 'A server MUST respond to unrecognized options with a NO response.'

Shouldn't it be BAD response?

Another thing. If I have a mailbox named "foo.bar" with "." as hierarchy
separator, but there's no "foo" mailbox, should LIST () "" % return
\PlaceHolder or \Noselect for it?



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1OGRNY13559 for ietf-imapext-bks; Mon, 24 Feb 2003 08:27:23 -0800 (PST)
Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1OGRMd13555 for <ietf-imapext@imc.org>; Mon, 24 Feb 2003 08:27:22 -0800 (PST)
Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [9.2.112.57]) by igw2.watson.ibm.com (8.11.4/8.11.4) with ESMTP id h1OGRIj82026 for <ietf-imapext@imc.org>; Mon, 24 Feb 2003 11:27:18 -0500
Received: from mars.watson.ibm.com (mars.watson.ibm.com [9.2.40.64]) by sp1n293en1.watson.ibm.com (8.11.4/8.11.4) with ESMTP id h1OGRIV51700 for <ietf-imapext@imc.org>; Mon, 24 Feb 2003 11:27:18 -0500
Date: Mon, 24 Feb 2003 11:27:18 -0500
From: Barry Leiba <leiba@watson.ibm.com>
To: IMAP extensions Mailing List <ietf-imapext@imc.org>
Subject: Re: I-D ACTION:draft-ietf-imapext-list-extensions-03.txt
Message-ID: <873890515.1046086038@mars.watson.ibm.com>
In-Reply-To: <2147483647.1046084494@[63.163.82.24]>
References: <200302241146.GAA09097@ietf.org> <1046094255.788.81.camel@hurina> <020d01c2dc14$9eb9f980$40280209@watson.ibm.com> <2147483647.1046084494@[63.163.82.24]>
X-Mailer: Mulberry/3.0.0 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

> Leave it as it is. Future list option extensions (if there are any)
> can simply extend the option syntax for their own set of options

Good point -- there's nothing that says that another extension can't 
change the syntax further.  OTOH, there's something to be said for 
having a flexible syntax from the start.

> 'A server MAY ignore options it does not recognize.'
>
> should be changed to:
>
> 'A server MUST respond to unrecognized options with a NO response.'
>
> That will ensure that accidental attempts by clients to use 'compound
> options' won't trigger a legitimate option if there happens to be an
> overlap between a compound option argument and a legitimate option.
> Besides I think its better to always return a NO when something is
> not recognized in a command sent by the client - that helps dumb
> client developers like me debug their implementations more easily!

I'm certainly happy to change that... I used the "MAY" wording to allow 
servers to be flexible.  Do others also prefer that clients that don't 
pay attention to CAPABILITY responses have their hands slapped?

Barry

--
Barry Leiba, Internet Messaging Technology  (leiba@watson.ibm.com)
http://www.research.ibm.com/people/l/leiba



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1OGOkk13487 for ietf-imapext-bks; Mon, 24 Feb 2003 08:24:46 -0800 (PST)
Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1OGOid13481 for <ietf-imapext@imc.org>; Mon, 24 Feb 2003 08:24:44 -0800 (PST)
Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [9.2.112.57]) by igw2.watson.ibm.com (8.11.4/8.11.4) with ESMTP id h1OGOej29940 for <ietf-imapext@imc.org>; Mon, 24 Feb 2003 11:24:40 -0500
Received: from mars.watson.ibm.com (mars.watson.ibm.com [9.2.40.64]) by sp1n293en1.watson.ibm.com (8.11.4/8.11.4) with ESMTP id h1OGOeV63650 for <ietf-imapext@imc.org>; Mon, 24 Feb 2003 11:24:40 -0500
Date: Mon, 24 Feb 2003 11:24:40 -0500
From: Barry Leiba <leiba@watson.ibm.com>
To: IMAP extensions Mailing List <ietf-imapext@imc.org>
Subject: Re: I-D ACTION:draft-ietf-imapext-list-extensions-03.txt
Message-ID: <873732906.1046085880@mars.watson.ibm.com>
In-Reply-To: <1046103597.787.111.camel@hurina>
References: <200302241146.GAA09097@ietf.org>	 <1046094255.788.81.camel@hurina>	 <020d01c2dc14$9eb9f980$40280209@watson.ibm.com> <1046103597.787.111.camel@hurina>
X-Mailer: Mulberry/3.0.0 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

> After update I see it in my mailbox and get reminded of it's
> existence. I guess I should read all of the drafts carefully through
> some day.

:-)

> You mean things like ACLs that would make existing mailboxes
> non-selectable? Does the difference matter to any clients?

Exactly, or mailboxes that may contain other mailboxes but not mail 
messages.  I don't know whether the difference matters to existing 
clients, but I think (and the consensus of the group was) that the 
server should make the distinction.  A client might display "\noselect" 
mailboxes as anchor points for expansion in the GUI.  A client might 
choose not to display "\nonexistent" mailboxes, or may show them in 
another way that makes it clear that they may be "old" subscriptions, 
and gives the user a chance to unsubscribe (or not, as appropriate).

Barry

--
Barry Leiba, Internet Messaging Technology  (leiba@watson.ibm.com)
http://www.research.ibm.com/people/l/leiba



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1OGJx613265 for ietf-imapext-bks; Mon, 24 Feb 2003 08:19:59 -0800 (PST)
Received: from oma.irssi.org (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1OGJvd13261 for <ietf-imapext@imc.org>; Mon, 24 Feb 2003 08:19:57 -0800 (PST)
Received: by oma.irssi.org (Postfix, from userid 1000) id 033445E01F94; Mon, 24 Feb 2003 18:19:58 +0200 (EET)
Subject: Re: I-D ACTION:draft-ietf-imapext-list-extensions-03.txt
From: Timo Sirainen <tss@iki.fi>
To: Barry Leiba <leiba@watson.ibm.com>
Cc: IMAP extensions Mailing List <ietf-imapext@imc.org>
In-Reply-To: <020d01c2dc14$9eb9f980$40280209@watson.ibm.com>
References: <200302241146.GAA09097@ietf.org> <1046094255.788.81.camel@hurina> <020d01c2dc14$9eb9f980$40280209@watson.ibm.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: 
Message-Id: <1046103597.787.111.camel@hurina>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 
Date: 24 Feb 2003 18:19:57 +0200
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

On Mon, 2003-02-24 at 16:54, Barry Leiba wrote:
> Ah, I'll never figure out why we don't get these comments until *after* we
> post the updated version, ya know?  Grumble, grumble....

After update I see it in my mailbox and get reminded of it's existence.
I guess I should read all of the drafts carefully through some day.

> "\Noselect" means that the mailbox exists but mayn't be SELECTed; there
> may be an assortment of reasons for this.  "\NonExistent" means that the
> mailbox doesn't exist, but a subscription to it remains.  What part of
> that distinction don't you understand, and I'll try to explain it more.

You mean things like ACLs that would make existing mailboxes
non-selectable? Does the difference matter to any clients?

> > LIST (SORT (NAME DATE)) "" %
> Hm, maybe.  Anyone else have thoughts on this?  We discussed this sort of
> thing when we first started formulating LIST extensions, and we decided to
> keep it simple... but this sort of thing might still be sufficiently simple.
> Should we allow it?

I think that still keeps it simple and doesn't require yet another
listext2 extension when first extension that wants something similiar
comes.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1OG1bT12734 for ietf-imapext-bks; Mon, 24 Feb 2003 08:01:37 -0800 (PST)
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1OG1ad12730 for <ietf-imapext@imc.org>; Mon, 24 Feb 2003 08:01:36 -0800 (PST)
Received: from [63.163.82.24] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id KAA11640; Mon, 24 Feb 2003 10:58:16 -0500 (EST)
Date: Mon, 24 Feb 2003 11:01:34 -0500
From: Cyrus Daboo <daboo@cyrusoft.com>
To: Barry Leiba <leiba@watson.ibm.com>, IMAP extensions Mailing List <ietf-imapext@imc.org>
Subject: Re: I-D ACTION:draft-ietf-imapext-list-extensions-03.txt
Message-ID: <2147483647.1046084494@[63.163.82.24]>
In-Reply-To: <020d01c2dc14$9eb9f980$40280209@watson.ibm.com>
References: <200302241146.GAA09097@ietf.org> <1046094255.788.81.camel@hurina> <020d01c2dc14$9eb9f980$40280209@watson.ibm.com>
X-Mailer: Mulberry/3.0.2 (Mac OS/PPC)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

Hi Barry,

--On Monday, February 24, 2003 9:54 AM -0500 Barry Leiba 
<leiba@watson.ibm.com> wrote:

|> Should list-options support more than just atoms list? I'm thinking of
|> some extra options that the atoms might have. For example:
|> LIST (SORT (NAME DATE)) "" %
|
| Hm, maybe.  Anyone else have thoughts on this?  We discussed this sort of
| thing when we first started formulating LIST extensions, and we decided to
| keep it simple... but this sort of thing might still be sufficiently
| simple. Should we allow it?

Leave it as it is. Future list option extensions (if there are any) can 
simply extend the option syntax for their own set of options and advertise 
that via CAPABILITY. However, I think the following statement in the first 
paragrph of Section 4:

'A server MAY ignore options it does not recognize.'

should be changed to:

'A server MUST respond to unrecognized options with a NO response.'

That will ensure that accidental attempts by clients to use 'compound 
options' won't trigger a legitimate option if there happens to be an 
overlap between a compound option argument and a legitimate option. Besides 
I think its better to always return a NO when something is not recognized 
in a command sent by the client - that helps dumb client developers like me 
debug their implementations more easily!

-- 
Cyrus Daboo


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1OEsTG07518 for ietf-imapext-bks; Mon, 24 Feb 2003 06:54:29 -0800 (PST)
Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1OEsSd07513 for <ietf-imapext@imc.org>; Mon, 24 Feb 2003 06:54:28 -0800 (PST)
Received: from sp1n294en1.watson.ibm.com (sp1n294en1.watson.ibm.com [9.2.112.58]) by igw2.watson.ibm.com (8.11.4/8.11.4) with ESMTP id h1OEsOj87660 for <ietf-imapext@imc.org>; Mon, 24 Feb 2003 09:54:24 -0500
Received: from mars (mars.watson.ibm.com [9.2.40.64]) by sp1n294en1.watson.ibm.com (8.11.4/8.11.4) with SMTP id h1OEsOi43434 for <ietf-imapext@imc.org>; Mon, 24 Feb 2003 09:54:24 -0500
Message-ID: <020d01c2dc14$9eb9f980$40280209@watson.ibm.com>
From: "Barry Leiba" <leiba@watson.ibm.com>
To: "IMAP extensions Mailing List" <ietf-imapext@imc.org>
References: <200302241146.GAA09097@ietf.org> <1046094255.788.81.camel@hurina>
Subject: Re: I-D ACTION:draft-ietf-imapext-list-extensions-03.txt
Date: Mon, 24 Feb 2003 09:54:23 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

Ah, I'll never figure out why we don't get these comments until *after* we
post the updated version, ya know?  Grumble, grumble....

> Looks like it's moved into 3348 nowadays. 3328 doesn't exist.

Yeah, that's a typo; I'll fix it.  Thanks.

> Why is LIST-SUBSCRIBED optional? Doesn't seem to be much of a job to
> implement.

It's optional because if you implement "subscribe" the way Mark intends
it, as a separate list that's not related to the actual mailbox store,
then it can be expensive to go through the list and then, for each entry,
go over to the actual mailboxes and get the required info.  I strongly
recommend implementing it because a client that wants it will get it by
using a combination of LSUB and LIST anyway, as now, but a server
implementer might want to leave LSUB and LIST separated.

Whether it's "much of a job to implement" depends upon the server and
the mail store and the subscription model, all put together.

> What's the difference between \Noselect and \NonExistent? Just so that
> clients wouldn't confuse \Noselect with old behaviour? Doesn't seem
> worth it.

"\Noselect" means that the mailbox exists but mayn't be SELECTed; there
may be an assortment of reasons for this.  "\NonExistent" means that the
mailbox doesn't exist, but a subscription to it remains.  What part of
that distinction don't you understand, and I'll try to explain it more.

> Should list-options support more than just atoms list? I'm thinking of
> some extra options that the atoms might have. For example:
> LIST (SORT (NAME DATE)) "" %

Hm, maybe.  Anyone else have thoughts on this?  We discussed this sort of
thing when we first started formulating LIST extensions, and we decided to
keep it simple... but this sort of thing might still be sufficiently simple.
Should we allow it?

> How about replacing ACL2's MYRIGHTS with LIST (MYRIGHTS)? I think
> clients would want to get their ACL rights more than one at a time, and
> this way looks pretty nice to me.

At the last IETF we decided that after the LISText draft was solid, we'd
look at how ACL and Annotate and AnnotateMore fit in, and what bits of
those commands should be done with LIST options instead.  So that will
follow this.

Barry
--
Barry Leiba, Internet Messaging Technology  (leiba@watson.ibm.com)
http://www.research.ibm.com/people/l/leiba


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1ODiMr03997 for ietf-imapext-bks; Mon, 24 Feb 2003 05:44:22 -0800 (PST)
Received: from oma.irssi.org (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1ODiKd03993 for <ietf-imapext@imc.org>; Mon, 24 Feb 2003 05:44:20 -0800 (PST)
Received: by oma.irssi.org (Postfix, from userid 1000) id 344AE5E01F94; Mon, 24 Feb 2003 15:44:15 +0200 (EET)
Subject: Re: I-D ACTION:draft-ietf-imapext-list-extensions-03.txt
From: Timo Sirainen <tss@iki.fi>
To: ietf-imapext@imc.org
In-Reply-To: <200302241146.GAA09097@ietf.org>
References: <200302241146.GAA09097@ietf.org>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: 
Message-Id: <1046094255.788.81.camel@hurina>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 
Date: 24 Feb 2003 15:44:15 +0200
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

"We are also defining the mechanism to request extended mailbox
information, such as is described in the now-expired "Child Mailbox
Extension" draft [ChildMbox]."

"[ChildMbox]; Gahrns, M. & Cheng, R.; "IMAP4 Child Mailbox Extension";
RFC 3328; Microsoft Corporation; July 2002."

Looks like it's moved into 3348 nowadays. 3328 doesn't exist.

Why is LIST-SUBSCRIBED optional? Doesn't seem to be much of a job to
implement.

What's the difference between \Noselect and \NonExistent? Just so that
clients wouldn't confuse \Noselect with old behaviour? Doesn't seem
worth it.

Should list-options support more than just atoms list? I'm thinking of
some extra options that the atoms might have. For example:
LIST (SORT (NAME DATE)) "" %

How about replacing ACL2's MYRIGHTS with LIST (MYRIGHTS)? I think
clients would want to get their ACL rights more than one at a time, and
this way looks pretty nice to me.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1OBoIS01362 for ietf-imapext-bks; Mon, 24 Feb 2003 03:50:18 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1OBoHd01358 for <ietf-imapext@imc.org>; Mon, 24 Feb 2003 03:50:17 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09097; Mon, 24 Feb 2003 06:46:24 -0500 (EST)
Message-Id: <200302241146.GAA09097@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ietf-imapext@imc.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-imapext-list-extensions-03.txt
Date: Mon, 24 Feb 2003 06:46:24 -0500
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF.

	Title		: IMAP4 LIST Command Extensions
	Author(s)	: B. Leiba
	Filename	: draft-ietf-imapext-list-extensions-03.txt
	Pages		: 8
	Date		: 2003-2-21
	
IMAP4 has two commands for listing mailboxes: LIST and LSUB.  As we
have added extensions that have required specialized lists (see
[MboxRefer] for an example) we have had to expand the number of list
commands, since each extension must add its function to both LIST and
LSUB, and these commands are not, as they are defined, extensible.
If we've needed the extensions to work together, we've had to add a
set of commands to mix the different options, the set increasing in
size with each new extension.  This document describes an extension
to the base LIST command that will allow these additions to be done
with mutually compatible options to the LIST command, avoiding the
exponential increase in specialized list commands.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-imapext-list-extensions-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-imapext-list-extensions-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-imapext-list-extensions-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-2-21161251.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-imapext-list-extensions-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-imapext-list-extensions-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-2-21161251.I-D@ietf.org>

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1JM3JS11532 for ietf-imapext-bks; Wed, 19 Feb 2003 14:03:19 -0800 (PST)
Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1JM3Hd11528 for <ietf-imapext@imc.org>; Wed, 19 Feb 2003 14:03:18 -0800 (PST)
Received: from GOBO-6NET.andrew.cmu.edu (GOBO-6NET.andrew.cmu.edu [128.2.6.104]) (user=rjs3 mech=KERBEROS_V4 (0 bits)) by lin1.andrew.cmu.edu (8.12.7.Beta1/8.12.3.Beta2) with ESMTP id h1JM3E0V001052; Wed, 19 Feb 2003 17:03:14 -0500
Date: Wed, 19 Feb 2003 17:03:15 -0500 (EST)
From: Rob Siemborski <rjs3@andrew.cmu.edu>
To: Mark Crispin <MRC@cac.washington.edu>
cc: Timo Sirainen <tss@iki.fi>, ietf-imapext@imc.org
Subject: Re: ACL2 models
In-Reply-To: <Pine.WNT.4.55.0302191401200.4528@Tomobiki-Cho.CAC.Washington.EDU>
Message-ID: <Pine.LNX.4.53L-031.0302191702240.8235@gobo.andrew.cmu.edu>
References: <1045687758.21737.108.camel@hurina> <Pine.LNX.4.53L-031.0302191616250.8215@gobo.andrew.cmu.edu> <Pine.WNT.4.55.0302191401200.4528@Tomobiki-Cho.CAC.Washington.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

On Wed, 19 Feb 2003, Mark Crispin wrote:

> On Wed, 19 Feb 2003, Rob Siemborski wrote:
> > In any case, there's a bigger problem.  With the UNION model, this results
> > in no user being able to use the mailbox at all (since negative rights
> > have to take affect after all positivie rights are unioned, otherwise they
> > don't really make any sense... you don't start with any rights on the
> > mailbox).
>
> Isn't this the entire point of negative rights?

I misinterpreted Timo's first message, I think, to imply that he wanted a
right of

-anyone <all>

by default on all mailboxes.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1JM28O11494 for ietf-imapext-bks; Wed, 19 Feb 2003 14:02:08 -0800 (PST)
Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1JM27d11490 for <ietf-imapext@imc.org>; Wed, 19 Feb 2003 14:02:07 -0800 (PST)
Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout4.cac.washington.edu (8.12.1+UW01.12/8.12.1+UW02.12) with ESMTP id h1JM24q6008184; Wed, 19 Feb 2003 14:02:04 -0800
Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.12.1+UW01.12/8.12.1+UW02.12) with ESMTP id h1JM24Fl029521 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 19 Feb 2003 14:02:04 -0800
Date: Wed, 19 Feb 2003 14:02:04 -0800 (Pacific Standard Time)
From: Mark Crispin <MRC@cac.washington.edu>
To: Rob Siemborski <rjs3@andrew.cmu.edu>
cc: Timo Sirainen <tss@iki.fi>, ietf-imapext@imc.org
Subject: Re: ACL2 models
In-Reply-To: <Pine.LNX.4.53L-031.0302191616250.8215@gobo.andrew.cmu.edu>
Message-ID: <Pine.WNT.4.55.0302191401200.4528@Tomobiki-Cho.CAC.Washington.EDU>
References: <1045687758.21737.108.camel@hurina> <Pine.LNX.4.53L-031.0302191616250.8215@gobo.andrew.cmu.edu>
Organization: Networks & Distributed Computing
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

On Wed, 19 Feb 2003, Rob Siemborski wrote:
> In any case, there's a bigger problem.  With the UNION model, this results
> in no user being able to use the mailbox at all (since negative rights
> have to take affect after all positivie rights are unioned, otherwise they
> don't really make any sense... you don't start with any rights on the
> mailbox).

Isn't this the entire point of negative rights?

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1JLwLR11420 for ietf-imapext-bks; Wed, 19 Feb 2003 13:58:21 -0800 (PST)
Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1JLwKd11413 for <ietf-imapext@imc.org>; Wed, 19 Feb 2003 13:58:20 -0800 (PST)
Received: from GOBO-6NET.andrew.cmu.edu (GOBO-6NET.andrew.cmu.edu [128.2.6.104]) (user=rjs3 mech=KERBEROS_V4 (0 bits)) by lin1.andrew.cmu.edu (8.12.7.Beta1/8.12.3.Beta2) with ESMTP id h1JLwG0V001039; Wed, 19 Feb 2003 16:58:16 -0500
Date: Wed, 19 Feb 2003 16:58:17 -0500 (EST)
From: Rob Siemborski <rjs3@andrew.cmu.edu>
To: Timo Sirainen <tss@iki.fi>
cc: ietf-imapext@imc.org
Subject: Re: ACL2 models
In-Reply-To: <1045691137.9912.121.camel@hurina>
Message-ID: <Pine.LNX.4.53L-031.0302191653190.8235@gobo.andrew.cmu.edu>
References: <1045687758.21737.108.camel@hurina>  <Pine.LNX.4.53L-031.0302191616250.8215@gobo.andrew.cmu.edu> <1045691137.9912.121.camel@hurina>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

On Wed, 19 Feb 2003, Timo Sirainen wrote:

> Sorry, I haven't looked ACLs much yet so my thoughts went a bit wrong. I
> meant something like this:
>
> group=foo -cxteda lrswip
> rjs3 -wipcxteda lrs
>
> Negative flags don't seem to be possible currently, but would adding
> support for them be a problem?

This looks a lot more tedious to me, and it means that clients are
enforcing the ACL policy and not the server (well, the server could
enforce it too, but then you might as well define which semantics you're
using).

And there are currently negative rights, you could do the above with:

-group=foo cxteda
group=foo lrswip
-rjs3 wipcxteda
rjs3 lrs

or even:

group=foo lrswip
-rjs3 wipcxteda
rjs3 lrs

Since servers aren't required to implement both ACL models, I guess I
don't see why we would want to obfuscate the MOST-SPECIFIC model inside of
UNION.  Perhaps this simplifies clients somewhat, but I think it gives
less control to administrators when enforcing their policies.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1JLjdt11191 for ietf-imapext-bks; Wed, 19 Feb 2003 13:45:39 -0800 (PST)
Received: from oma.irssi.org (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1JLjad11183 for <ietf-imapext@imc.org>; Wed, 19 Feb 2003 13:45:37 -0800 (PST)
Received: by oma.irssi.org (Postfix, from userid 1000) id 501855E01F68; Wed, 19 Feb 2003 23:45:38 +0200 (EET)
Subject: Re: ACL2 models
From: Timo Sirainen <tss@iki.fi>
To: Rob Siemborski <rjs3@andrew.cmu.edu>
Cc: ietf-imapext@imc.org
In-Reply-To: <Pine.LNX.4.53L-031.0302191616250.8215@gobo.andrew.cmu.edu>
References: <1045687758.21737.108.camel@hurina> <Pine.LNX.4.53L-031.0302191616250.8215@gobo.andrew.cmu.edu>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: 
Message-Id: <1045691137.9912.121.camel@hurina>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.1 
Date: 19 Feb 2003 23:45:38 +0200
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

On Wed, 2003-02-19 at 23:20, Rob Siemborski wrote:
> > Is it really a good idea to have separate UNION and MOST-SPECIFIC
> > models? If UNION acls were evaluated in most-specific-rule-last order,
> > MOST-SPECIFIC behaviour could be done just by prepending "-anyone" to
> > rules. I'd think that would make it simpler for implementors since they
> > wouldn't have to deal with two different models.
> 
> I don't agree. Say you have the UNION ACL:
> 
> -anyone lrswipcxteda
> group=foo lrswip
> rjs3 lrs

Sorry, I haven't looked ACLs much yet so my thoughts went a bit wrong. I
meant something like this:

group=foo -cxteda lrswip
rjs3 -wipcxteda lrs

Negative flags don't seem to be possible currently, but would adding
support for them be a problem?


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1JLKfQ10612 for ietf-imapext-bks; Wed, 19 Feb 2003 13:20:41 -0800 (PST)
Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1JLKdd10608 for <ietf-imapext@imc.org>; Wed, 19 Feb 2003 13:20:39 -0800 (PST)
Received: from GOBO-6NET.andrew.cmu.edu (GOBO-6NET.andrew.cmu.edu [128.2.6.104]) (user=rjs3 mech=KERBEROS_V4 (0 bits)) by lin1.andrew.cmu.edu (8.12.7.Beta1/8.12.3.Beta2) with ESMTP id h1JLKT0V000990; Wed, 19 Feb 2003 16:20:29 -0500
Date: Wed, 19 Feb 2003 16:20:32 -0500 (EST)
From: Rob Siemborski <rjs3@andrew.cmu.edu>
To: Timo Sirainen <tss@iki.fi>
cc: ietf-imapext@imc.org
Subject: Re: ACL2 models
In-Reply-To: <1045687758.21737.108.camel@hurina>
Message-ID: <Pine.LNX.4.53L-031.0302191616250.8215@gobo.andrew.cmu.edu>
References: <1045687758.21737.108.camel@hurina>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

On Wed, 19 Feb 2003, Timo Sirainen wrote:

> Is it really a good idea to have separate UNION and MOST-SPECIFIC
> models? If UNION acls were evaluated in most-specific-rule-last order,
> MOST-SPECIFIC behaviour could be done just by prepending "-anyone" to
> rules. I'd think that would make it simpler for implementors since they
> wouldn't have to deal with two different models.

I don't agree. Say you have the UNION ACL:

-anyone lrswipcxteda
group=foo lrswip
rjs3 lrs

and rjs3 is in the foo group.

Using your method, rjs3 has lrswip, but with MOST-SPECIFIC, rjs3 has only
lrs.

In any case, there's a bigger problem.  With the UNION model, this results
in no user being able to use the mailbox at all (since negative rights
have to take affect after all positivie rights are unioned, otherwise they
don't really make any sense... you don't start with any rights on the
mailbox).

-Rob



-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1JKncG09691 for ietf-imapext-bks; Wed, 19 Feb 2003 12:49:38 -0800 (PST)
Received: from oma.irssi.org (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1JKnMd09609 for <ietf-imapext@imc.org>; Wed, 19 Feb 2003 12:49:23 -0800 (PST)
Received: by oma.irssi.org (Postfix, from userid 1000) id 342B25E01F68; Wed, 19 Feb 2003 22:49:18 +0200 (EET)
Subject: ACL2 models
From: Timo Sirainen <tss@iki.fi>
To: ietf-imapext@imc.org
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: 
Message-Id: <1045687758.21737.108.camel@hurina>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.1 
Date: 19 Feb 2003 22:49:18 +0200
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

Is it really a good idea to have separate UNION and MOST-SPECIFIC
models? If UNION acls were evaluated in most-specific-rule-last order,
MOST-SPECIFIC behaviour could be done just by prepending "-anyone" to
rules. I'd think that would make it simpler for implementors since they
wouldn't have to deal with two different models.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1JJcNG04978 for ietf-imapext-bks; Wed, 19 Feb 2003 11:38:23 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1JJcId04974 for <ietf-imapext@imc.org>; Wed, 19 Feb 2003 11:38:19 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06196; Wed, 19 Feb 2003 14:34:29 -0500 (EST)
Message-Id: <200302191934.OAA06196@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ietf-imapext@imc.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-imapext-acl-07.txt
Date: Wed, 19 Feb 2003 14:34:29 -0500
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF.

	Title		: IMAP4 ACL extension
	Author(s)	: A. Melnikov
	Filename	: draft-ietf-imapext-acl-07.txt
	Pages		: 10
	Date		: 2003-2-18
	
The ACL (Access Control List) extension of the Internet Message Access
Protocol [IMAP4] permits mailbox access control lists to be manipulated
through the IMAP protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-imapext-acl-07.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-imapext-acl-07.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-imapext-acl-07.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-2-19145339.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-imapext-acl-07.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-imapext-acl-07.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-2-19145339.I-D@ietf.org>

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1EBm0S22847 for ietf-imapext-bks; Fri, 14 Feb 2003 03:48:00 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1EBlwd22843 for <ietf-imapext@imc.org>; Fri, 14 Feb 2003 03:47:59 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16891; Fri, 14 Feb 2003 06:44:13 -0500 (EST)
Message-Id: <200302141144.GAA16891@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ietf-imapext@imc.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-imapext-list-extensions-02.txt
Date: Fri, 14 Feb 2003 06:44:13 -0500
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF.

	Title		: IMAP4 LIST Command Extensions
	Author(s)	: B. Leiba
	Filename	: draft-ietf-imapext-list-extensions-02.txt
	Pages		: 8
	Date		: 2003-2-13
	
IMAP4 has two commands for listing mailboxes: LIST and LSUB.  As we
have added extensions that have required specialized lists (see
[MboxRefer] for an example) we have had to expand the number of list
commands, since each extension must add its function to both LIST and
LSUB, and these commands are not, as they are defined, extensible.
If we've needed the extensions to work together, we've had to add a
set of commands to mix the different options, the set increasing in
size with each new extension.  This document describes an extension
to the base LIST command that will allow these additions to be done
with mutually compatible options to the LIST command, avoiding the
exponential increase in specialized list commands.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-imapext-list-extensions-02.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-imapext-list-extensions-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-imapext-list-extensions-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-2-13152807.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-imapext-list-extensions-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-imapext-list-extensions-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-2-13152807.I-D@ietf.org>

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1CFgqj21046 for ietf-imapext-bks; Wed, 12 Feb 2003 07:42:52 -0800 (PST)
Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1CFgpd21042 for <ietf-imapext@imc.org>; Wed, 12 Feb 2003 07:42:51 -0800 (PST)
Received: from sp1n294en1.watson.ibm.com (sp1n294en1.watson.ibm.com [9.2.112.58]) by igw2.watson.ibm.com (8.11.4/8.11.4) with ESMTP id h1CFglo24348 for <ietf-imapext@imc.org>; Wed, 12 Feb 2003 10:42:47 -0500
Received: from mars.watson.ibm.com (mars.watson.ibm.com [9.2.40.64]) by sp1n294en1.watson.ibm.com (8.11.4/8.11.4) with ESMTP id h1CFglG44238 for <ietf-imapext@imc.org>; Wed, 12 Feb 2003 10:42:47 -0500
Date: Wed, 12 Feb 2003 10:42:47 -0500
From: Barry Leiba <leiba@watson.ibm.com>
To: IMAP extensions Mailing  List <ietf-imapext@imc.org>
Subject: spurious message
Message-ID: <1727104687.1045046567@mars.watson.ibm.com>
X-Mailer: Mulberry/3.0.0 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

Hm, an old message that I was looking at appears to've gotten re-sent 
to the list.  Sorry 'bout that.

Barry

--
Barry Leiba, Internet Messaging Technology  (leiba@watson.ibm.com)
http://www.research.ibm.com/people/l/leiba



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1CFfh320990 for ietf-imapext-bks; Wed, 12 Feb 2003 07:41:43 -0800 (PST)
Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1CFffd20986 for <ietf-imapext@imc.org>; Wed, 12 Feb 2003 07:41:41 -0800 (PST)
Received: from sp1n294en1.watson.ibm.com (sp1n294en1.watson.ibm.com [9.2.112.58]) by igw2.watson.ibm.com (8.11.4/8.11.4) with ESMTP id h1CFfbo66148 for <ietf-imapext@imc.org>; Wed, 12 Feb 2003 10:41:37 -0500
Received: from mars.watson.ibm.com (mars.watson.ibm.com [9.2.40.64]) by sp1n294en1.watson.ibm.com (8.11.4/8.11.4) with ESMTP id h1CFfbG34140 for <ietf-imapext@imc.org>; Wed, 12 Feb 2003 10:41:37 -0500
Date: Wed, 12 Feb 2003 10:41:37 -0500
From: Barry Leiba <leiba@watson.ibm.com>
To: IMAP extensions Mailing  List <ietf-imapext@imc.org>
Subject: draft-ietf-imapext-list-extensions-02
Message-ID: <1727034640.1045046497@mars.watson.ibm.com>
X-Mailer: Mulberry/3.0.0 (Win32)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="==========1727055152=========="
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

--==========1727055152==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I've just sent the attached update to 
draft-ietf-imapext-list-extensions-02 to the I-D editor.  It contains 
the changes that were brought up here, including a correction to the 
grammar for the LIST response extension (as pointed out by Alexey) and 
some text explaining the LIST response extension.

Barry

--
Barry Leiba, Internet Messaging Technology  (leiba@watson.ibm.com)
http://www.research.ibm.com/people/l/leiba

--==========1727055152==========
Content-Type: text/plain; charset=iso-8859-1;
 name="draft-ietf-imapext-list-extensions-02.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="draft-ietf-imapext-list-extensions-02.txt"; size=19493


IMAP Extensions Working Group                                   B. =
Leiba
Internet Draft                           IBM T.J. Watson Research =
Center
Document: draft-ietf-imapext-list-extensions-02.txt        February =
2003
                                                     Expires August =
2003
                     IMAP4 LIST Command Extensions
Status of this Document
   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.  Internet-Drafts are =
working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.
   Internet-Drafts are draft documents valid for a maximum of six =
months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."
     The list of current Internet-Drafts can be accessed at
     http://www.ietf.org/ietf/1id-abstracts.txt
     The list of Internet-Draft Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html.
   A revised version of this draft document will be submitted to the =
RFC
   editor as an Proposed Standard for the Internet Community.
   Discussion and suggestions for improvement are requested, and should
   be sent to ietf-imapext@imc.org.  This document will expire before =
31
   August 2003.  Distribution of this memo is unlimited.
1. Abstract
   IMAP4 has two commands for listing mailboxes: LIST and LSUB.  As we
   have added extensions that have required specialized lists (see
   [MboxRefer] for an example) we have had to expand the number of list
   commands, since each extension must add its function to both LIST =
and
   LSUB, and these commands are not, as they are defined, extensible.
   If we've needed the extensions to work together, we've had to add a
   set of commands to mix the different options, the set increasing in
   size with each new extension.  This document describes an extension
   to the base LIST command that will allow these additions to be done
   with mutually compatible options to the LIST command, avoiding the
   exponential increase in specialized list commands.
B. Leiba                  Expires August 2003                  [Page =
1]=0C
Internet DRAFT       IMAP4 LIST Command Extensions        February 2003
2. 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 words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" are
   used in this document as specified in RFC 2119 [Keywords].
3. Introduction
   The extensions to the LIST command will be accomplished by amending
   the syntax to allow options to be specified.  The list of options
   will replace the several commands that are currently used to mix and
   match the information requested.  The new syntax is backward-
   compatible, with no ambiguity: if the first word after the command
   name begins with a parenthesis, the new syntax is being used; if it
   does not, it's in the original syntax.
   By adding options to the LIST command, we are announcing the intent
   to phase out and eventually to deprecate the RLIST and RLSUB =
commands
   described in [MboxRefer].  We are also defining the mechanism to
   request extended mailbox information, such as is described in the
   now-expired "Child Mailbox Extension" draft [ChildMbox].  The base
   LSUB command is not deprecated by this extension; rather, this
   extension adds a way to obtain subscription information with more
   options, with those server implementations that support it.  Clients
   that simply need a list of subscribed mailboxes, as provided by the
   LSUB command, SHOULD continue to use that command.
4. LIST Command Options
   The LIST command syntax is extended by adding a parenthesized list =
of
   command options between the command name and the reference name (see
   the formal syntax in section 6 for specific details).  Command
   options will be defined in this document and in approved extension
   documents; each option will be enabled by a capability string (one
   capability may enable multiple options), and a client MUST NOT send
   an option for which the server has not advertised support.  A server
   MAY ignore options it does not recognize.
   This extension is identified by the capability string "LISTEXT", and
   support for it is a prerequisite for any future extensions that
   require specialized forms of the LIST command.  Such extensions MUST
   refer to this document and MUST add their function through command
   options as described herein.  This document also defines the "LIST-
B. Leiba                  Expires August 2003                  [Page =
2]=0C
Internet DRAFT       IMAP4 LIST Command Extensions        February 2003
   SUBSCRIBED" capability string; see the "SUBSCRIBED" option below.
   This extension also defines extensions to the LIST response, =
allowing
   a series of extended fields at the end, a parenthesized list of
   attriobute/value pairs.  Each attribute is a string, each value may
   be a string or a nested parenthesized list of the same
   attribute/value pairs.  An example of this extended set might be
       (("ACL" (("user" "fred")("access" "rwi")))("X-Sample" "text"))
   See the formal grammar, below, for the full syntatic details.
   The options defined in this specification are
       SUBSCRIBED - causes the LIST command to list subscribed
          mailboxes, rather than the actual mailboxes.  This will often
          be a subset of the actual mailboxes.  It's also possible for
          this list to contain the names of mailboxes that don't exist.
          In any case, the list MUST include exactly those mailbox =
names
          that match the selection criteria and are subscribed to.  =
This
          option is intended to supplement the LSUB command, and =
support
          for it is optional -- a server that supports the SUBSCRIBED
          option indicates so through the LIST-SUBSCRIBED capability.
          Of particular note are the mailbox flags as returned by this
          option, compared with what is returned by LSUB.  With the
          latter, the flags returned may not reflect the actual flag
          status on the mailbox, and the \NoSelect flag has a special
          meaning (it indicates that this mailbox is not, itself,
          subscribed, but that it has child mailboxes that are).  With
          the SUBSCRIBED option described here, the flags are accurate
          and complete, and have no special meanings.
          "LSUB" and "LIST (SUBSCRIBED)" are, thus, not the same thing,
          and some servers must do significant extra work to respond to
          "LIST (SUBSCRIBED)".  Because of this, clients SHOULD =
continue
          to use "LSUB" unless they specifically want the additional
          information offered by "LIST (SUBSCRIBED)".  At the same =
time,
          servers SHOULD support the LIST-SUBSCRIBED capability even if
          it entails extra work, because a client that wants the
          information will still obtain it by using LSUB followed by a
          series of LIST commands, so servers might as well make it
          easier.
          This option defines a new mailbox flag, "\NonExistent", that
          indicates that a mailbox is subscribed to, but does not
          actually exist.  The "\NonExistent" flag MUST be supported =
and
          MUST be accurately computed.
       REMOTE - causes the LIST command to show remote mailboxes as
          well as local ones, as described in [MboxRefer].  This option
B. Leiba                  Expires August 2003                  [Page =
3]=0C
Internet DRAFT       IMAP4 LIST Command Extensions        February 2003
          is intended to replace the RLIST command and, in conjunction
          with the SUBSCRIBED option, the RLSUB command.  This option =
is
          only available on servers that also support RFC-2193.
       CHILDREN - Requests mailbox child information as originally
          proposed in [ChildMbox].  See section 5, below, for details.
          Support for this is optional, but this option MUST be =
accepted
          by all servers (though it MAY be ignored).
   The LISTEXT capability also defines a new mailbox flag,
   "\PlaceHolder", that indicates that the designated mailbox does not
   meet the selection criteria of the given LIST command, but that it
   has one or more child mailboxes that do [EDITORIAL NOTE: "might"?].
   The LSUB command indicates this condition by using the "\NoSelect"
   flag, but the LIST (SUBSCRIBED) command MUST NOT do that, since
   "\NoSelect" retains its original meaning here.  Further, the
   "\PlaceHolder" flag is more general, in that it can be used with any
   extended set of selection criteria.
5. The CHILDREN Option
   The CHILDREN option implements the Child Mailbox Extension,
   originally proposed by Mike Gahrns and Raymond Cheng, of Microsoft
   Corporation.  Most of the information in this section is taken
   directly from their original specification [ChildMbox].  The =
CHILDREN
   option is simply an indication that the client wants this
   information; a server MAY provide it even if the option is not
   specified, or MAY ignore the option entirely.
   Many IMAP4 [IMAP4] clients present to the user a hierarchical view =
of
   the mailboxes that a user has access to.  Rather than initially
   presenting to the user the entire mailbox hierarchy, it is often
   preferable to show to the user a collapsed outline list of the
   mailbox hierarchy (particularly if there is a large number of
   mailboxes).  The user can then expand the collapsed outline =
hierarchy
   as needed.  It is common to include within the collapsed hierarchy a
   visual clue (such as a ''+'') to indicate that there are child
   mailboxes under a particular mailbox.   When the visual clue is
   clicked the hierarchy list is expanded to show the child mailboxes.
   The Child Mailbox Extension provides a mechanism for a client to
   efficiently determine if a particular mailbox has children, without
   issuing a LIST '' * or a LIST '' % for each mailbox name.
   The Child Mailbox Extension defines two new attributes that MAY be
   returned within a LIST response: \HasChildren and \HasNoChildren.
   While these attributes MAY be returned in response to any LIST
   command, the CHILDREN option is provided to indicate that the client
B. Leiba                  Expires August 2003                  [Page =
4]=0C
Internet DRAFT       IMAP4 LIST Command Extensions        February 2003
   particularly wants this information.  If the CHILDREN option is
   present, the server SHOULD return these attributes even if their
   computation is expensive.
\HasChildren - The presence of this attribute indicates that the =
mailbox
       has child mailboxes.
       A server SHOULD NOT set this attribute if there are child
       mailboxes, and the user does not have permissions to access any
       of them. In this case, \HasNoChildren SHOULD be used.
       In many cases, however, a server may not be able to efficiently
       compute whether a user has access to all child mailboxes.  As
       such a client MUST be prepared to accept the \HasChildren
       attribute as a hint.  That is, a mailbox MAY be flagged with the
       \HasChildren attribute, but no child mailboxes will appear in
       the LIST response.
\HasNoChildren - The presence of this attribute indicates that the
       mailbox has NO child mailboxes that are accessible to the
       currently authenticated user.
   In some instances a server that supports the Child Mailbox Extension
   might not be able to determine whether a mailbox has children.  For
   example it may have difficulty determining whether there are child
   mailboxes when LISTing mailboxes while operating in a particular
   namespace.
   In these cases, a server MAY exclude both the \HasChildren and
   \HasNoChildren attributes in the LIST response.  As such, a client
   can not make any assumptions about whether a mailbox has children
   based upon the absence of a single attribute.  In particular, some
   servers may not be able to combine the SUBSCRIBED and CHILDREN
   options.  Such servers MUST honour the SUBSCRIBED option, and they
   will simply ignore the CHILDREN option if both are requested.
   It is an error for the server to return both a \HasChildren and a
   \HasNoChildren attribute in a LIST response.
   Note: the \HasNoChildren attribute should not be confused with the
   IMAP4 [IMAP4] defined attribute \NoInferiors which indicates that no
   child mailboxes exist now and none can be created in the future.
6. Examples
   The first example shows the complete local hierarchy that will be
   used for the other examples.
B. Leiba                  Expires August 2003                  [Page =
5]=0C
Internet DRAFT       IMAP4 LIST Command Extensions        February 2003
       C: A01 LIST "" "*"
       S: * LIST (\Marked \NoInferiors) "/" "inbox"
       S: * LIST () "/" "Fruit"
       S: * LIST () "/" "Fruit/Apple"
       S: * LIST () "/" "Fruit/Banana"
       S: * LIST () "/" "Tofu"
       S: * LIST () "/" "Vegetable"
       S: * LIST () "/" "Vegetable/Broccoli"
       S: A01 OK done
   In the next example, we'll see the subscribed mailboxes.  This is
   similar, but not equivalent, to <LSUB "" "*">.  Note that the =
mailbox
   called "Fruit/Peach" is subscribed to, but does not actually exist
   (perhaps it was deleted while still subscribed).  And the "Fruit"
   mailbox is not subscribed to, but it has two subscribed children.
       C: A02 LIST (SUBSCRIBED) "" "*"
       S: * LIST (\Marked \NoInferiors) "/" "inbox"
       S: * LIST (\PlaceHolder) "/" "Fruit"
       S: * LIST () "/" "Fruit/Banana"
       S: * LIST (\NonExistent) "/" "Fruit/Peach"
       S: A02 OK done
   The next example shows the use of the CHILDREN option.  The client,
   without having to list the second level of hierarchy, now knows =
which
   of the top-level mailboxes have sub-mailboxes (children) and which =
do
   not.  Note that it's not necessary for the server to return the
   \HasNoChildren flag for the inbox, because the \NoInferiors flag
   already implies that, and has a stronger meaning.
       C: A03 LIST (CHILDREN) "" "%"
       S: * LIST (\Marked \NoInferiors) "/" "inbox"
       S: * LIST (\HasChildren) "/" "Fruit"
       S: * LIST (\HasNoChildren) "/" "Tofu"
       S: * LIST (\HasChildren) "/" "Vegetable"
       S: A03 OK done
   In this example we see more mailboxes, which reside on another =
server
   to which we may obtain referrals.  This is similar to the command
   <RLIST "" "%">.  We also see the mixing of two options.  Note that =
in
   the case of the remote mailboxes, the server might or might not be
   able to include CHILDREN information; it includes it if it can, and
   omits it if it can't.
       C: A04 LIST (REMOTE CHILDREN) "" "%"
       S: * LIST (\Marked \NoInferiors) "/" "inbox"
       S: * LIST (\HasChildren) "/" "Fruit"
       S: * LIST (\HasNoChildren) "/" "Tofu"
       S: * LIST (\HasChildren) "/" "Vegetable"
B. Leiba                  Expires August 2003                  [Page =
6]=0C
Internet DRAFT       IMAP4 LIST Command Extensions        February 2003
       S: * LIST () "/" "Bread"
       S: * LIST (\HasChildren) "/" "Meat"
       S: A04 OK done
7. Formal Syntax
   The following syntax specification uses the augmented Backus-Naur
   Form (BNF) as described in [ABNF].  Terms not defined here are taken
   from [IMAP4].
   child-mbox-flag =3D "\HasChildren" / "\HasNoChildren"
                      ; flags for Child Mailbox Extension, at most one
                      ; possible per LIST response
   list            =3D "LIST" [SP list-options] SP mailbox SP =
list-mailbox
   list-options    =3D "(" [option *(SP option)] ")"
   mailbox-list    =3D "(" [mbx-list-flags] ")" SP
                      (DQUOTE QUOTED-CHAR DQUOTE / nil) SP mailbox
                      [SP mbox-list-extended]
   mbox-list-extended =3D "(" mbox-list-extended-item
                        *(SP mbox-list-extended-item) ")"
   mbox-list-extended-item =3D "(" string SP (string / =
mbox-list-extended-
   item) ")"
                             / mailbox-list-extended
   mbox-list-oflag :=3D child-mbox-flag / "\NonExistent" / =
"\PlaceHolder"
   option           =3D "SUBSCRIBED" / "CHILDREN" / "REMOTE" /
                     option-extension
   option-extension =3D atom
8. Security Considerations
   This document describes syntactic changes to the specification of =
the
   IMAP4 commands LIST, LSUB, RLIST, and RLSUB, and the modified LIST
   command has the same security considerations as those commands.  =
They
   are described in [IMAP4] and [MboxRefer].
   The Child Mailbox Extension provides a client a more efficient means
   of determining whether a particular mailbox has children.  If a
   mailbox has children, but the currently authenticated user does not
   have access to any of them, the server SHOULD respond with a
B. Leiba                  Expires August 2003                  [Page =
7]=0C
Internet DRAFT       IMAP4 LIST Command Extensions        February 2003
   \HasNoChildren attribute.  In many cases, however, a server may not
   be able to efficiently compute whether a user has access to all =
child
   mailboxes.  If such a server responds with a \HasChildren attribute,
   when in fact the currently authenticated user does not have access =
to
   any child mailboxes, potentially more information is conveyed about
   the mailbox than intended.   In most situations this will not be a
   security concern, because if information regarding whether a mailbox
   has children is considered sensitive, a user would not be granted
   access to that mailbox in the first place.
9. References
   [IMAP4]; Crispin, M.; "Internet Message Access Protocol - Version
   4rev1"; RFC 2060; University of Washington; December 1996.
   [MboxRefer]; Gahrns, M.; "IMAP4 Mailbox Referrals"; RFC 2193;
   Microsoft Corporation; September 1997.
   [ChildMbox]; Gahrns, M. & Cheng, R.; "IMAP4 Child Mailbox =
Extension";
   RFC 3328; Microsoft Corporation; July 2002.
   [Keywords]; Bradner, S.; "Key words for use in RFCs to Indicate
   Requirement Levels"; RFC 2119; Harvard University; March 1997.
   [ABNF]; Crocker, D., and Overell, P. "Augmented BNF for Syntax
   Specifications: ABNF", RFC 2234, November 1997.
10. Acknowledgements
   Mike Gahrns and Raymond Cheng of Microsoft Corporation originally
   devised the Child Mailbox Extension and proposed it in 1997; the
   idea, as well as most of the text in section 5, is theirs.
11. Author's Address
   Barry Leiba
   IBM T.J. Watson Research Center
   30 Saw Mill River Road
   Hawthorne, NY  10532
   Phone: 1-914-784-7941
   Email: leiba@watson.ibm.com
B. Leiba                  Expires August 2003                  [Page 8]
--==========1727055152==========--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1CFW3u20676 for ietf-imapext-bks; Wed, 12 Feb 2003 07:32:03 -0800 (PST)
Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1CFW2d20672 for <ietf-imapext@imc.org>; Wed, 12 Feb 2003 07:32:02 -0800 (PST)
Received: from sp1n294en1.watson.ibm.com (sp1n294en1.watson.ibm.com [9.2.112.58]) by igw2.watson.ibm.com (8.11.4/8.11.4) with ESMTP id h1CFVwo31650 for <ietf-imapext@imc.org>; Wed, 12 Feb 2003 10:31:58 -0500
Received: from mars.watson.ibm.com (mars.watson.ibm.com [9.2.40.64]) by sp1n294en1.watson.ibm.com (8.11.4/8.11.4) with ESMTP id h1CFVwG32732; Wed, 12 Feb 2003 10:31:58 -0500
Date: Wed, 12 Feb 2003 10:31:56 -0500
From: Barry Leiba <leiba@watson.ibm.com>
To: Barry Leiba <leiba@watson.ibm.com>, IMAP extensions Mailing List <ietf-imapext@imc.org>
Subject: Re: LIST Extensions draft
Message-ID: <1726453750.1045045916@mars.watson.ibm.com>
X-Mailer: Mulberry/3.0.0 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

>OK, how about this?:
>
>--------
>IMAP4 has two commands for listing mailboxes: LIST and LSUB.  As we
have 
>added extensions that have require specialized lists (see [MboxRefer]
for 
>an example) we have expand the number of list commands, since each 
>extension must add its function to both LIST and LSUB, and these
commands 
>are not, as they are defined, extensible.  This document describes 
>extensions to the LIST command that allow these additions to be done
with 
>mutually compatible options to the LIST command, avoiding the
exponential 
>increase in specialized list commands.

Ah, now it is making sense to me.  Thanks.  I see that a large part of
my puzzlement stemmed from my interpretation of "since each extension
must add its function to both LIST and LSUB".  I was understanding that
as meaning adding capability into LIST and LSUB which is exactly what
the new proposal does and what the old extensions did not.  But you
mean supplementing the functionality of LIST and LSUB, right?

May I suggest a couple of improvements along the lines of:

IMAP4 has two commands for listing mailboxes: LIST and LSUB.  As we
have added extensions that required specialized lists (see [MboxRefer]
for an example), we have done so by defining new list commands, for
example RLIST and RLSUB.  Each such extension has served to supplement
LIST and LSUB since these commands, as currently defined, are not
intrinsically extensible.  This document describes an extension to the
LIST command that allows such additions to be made with mutually
compatible options thereby avoiding exponential increase in the number
of specialized list commands.

Note that I have changed "extensions" to "extension" in the last
sentence.  This may well be debatable but I see the addition of a new
argument as essentially a single change.

Pete

Barry

--
Barry Leiba, Internet Messaging Technology  (leiba@watson.ibm.com)
http://www.research.ibm.com/people/l/leiba



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1CENqG18100 for ietf-imapext-bks; Wed, 12 Feb 2003 06:23:52 -0800 (PST)
Received: from il-tlv-smtpout2.icomverse.com (comversegw.icomverse.com [192.118.48.248]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1CENod18092 for <ietf-imapext@imc.org>; Wed, 12 Feb 2003 06:23:51 -0800 (PST)
Received: from il-tlv-mbdg1.comverse.com (localhost.localdomain [127.0.0.1]) by il-tlv-smtpout2.icomverse.com (8.11.6/8.11.6) with ESMTP id h1CENef27978 for <ietf-imapext@imc.org>; Wed, 12 Feb 2003 16:23:40 +0200
Received: by il-tlv-mbdg1.comverse.com with Internet Mail Service (5.5.2655.55) id <1W08JG4M>; Wed, 12 Feb 2003 16:23:48 +0200
Message-ID: <7D4344E32B34D511A6500002A560C602230C62@il-tlv-mail4.comverse.com>
From: Shiv Amir <Amir.Shiv@comverse.com>
To: "'ietf-imapext@imc.org'" <ietf-imapext@imc.org>
Subject: RE: FETCH versus CHANNEL
Date: Wed, 12 Feb 2003 16:23:46 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D2A2.2C8A9FD4"
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C2D2A2.2C8A9FD4
Content-Type: text/plain;
	charset="windows-1255"


RFC 2060 says: "The FETCH command retrieves data associated with a
message...". Since the  URL is a data associated  with a message or part of
a message, the FETCH command seems the  most natural and consistent way.

The CHANNEL draft introduces a new data type, the <channel-set>, which is a
list of msg:section  pairs. This data type is limited only to multi-part
messages. In case of a "single-part" message an  error or NIL should be
returned, hence it does not support this kind of messages. Also it is not
possible to specify a different scheme as per each requested URL.

The following example fetches the URLs for sections 2 and 3 of message
number 1. Note that for  each body-part a different protocol/scheme is
specified:

C: A005 FETCH 1 (URL[2 (rtsp mms)] URL[3 (http imap)])

S: * 1 FETCH (URL[2] {21}
S: rtsp://part1/part2/file.mpg
S:
S: URL[3] {28}
S: http://www.part1.com/part2/file.mp3
S:
S: )
S: A005 OK FETCH complete

The FETCH command provides the (standard) protocol frame. It does not
contradict internal  operations like transcoding or transferring message's
data.

The CHANNEL draft demonstrates a scenario where different body-parts from
different messages  are retrieved in a single command. In that sense FETCH
is indeed somewhat limited.

Amir Shiv 
Comverse


-----Original Message-----
From: Chris Newman [mailto:Chris.Newman@Sun.COM]
Sent: Tuesday, February 11, 2003 3:40 AM
To: Eric Burger; ietf-imapext@imc.org
Cc: IETF LEMONADE (E-mail)
Subject: Re: FETCH versus CHANNEL



I can not answer this question without more protocol details about the 
contrasting proposals.

What would the FETCH proposal look like on the wire?

If we're operating on MIME body parts rather than an entire message, then 
leveraging the existing FETCH infrastructure probably makes sense.  But you 
need to get the semantics correct.  Look at the difference between partial 
fetches in 1730 and 2060 for one sort of mistake.  Look at the BINARY 
extension for one example of how to do this correctly.

                - Chris

begin  quotation by Eric Burger on 2003/2/10 1:11 -0500:

>
> Shiv proposed using FETCH instead of CHANNEL for requesting non-IMAP
> retrieval (e.g., streaming) of messages.  There were a bunch of "yes --
> that sounds right" messages.
>
> Does anyone object?  Do we have consensus to move forward?


------_=_NextPart_001_01C2D2A2.2C8A9FD4
Content-Type: text/html;
	charset="windows-1255"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dwindows-1255">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2655.35">
<TITLE>RE: FETCH versus CHANNEL</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">RFC 2060 says: &quot;The FETCH command =
retrieves data associated with a message...&quot;. Since the&nbsp; URL =
is a data associated&nbsp; with a message or part of a message, the =
FETCH command seems the&nbsp; most natural and consistent =
way.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The CHANNEL draft introduces a new =
data type, the &lt;channel-set&gt;, which is a list of =
msg:section&nbsp; pairs. This data type is limited only to multi-part =
messages. In case of a &quot;single-part&quot; message an&nbsp; error =
or NIL should be returned, hence it does not support this kind of =
messages. Also it is not&nbsp; possible to specify a different scheme =
as per each requested URL.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The following example fetches the URLs =
for sections 2 and 3 of message number 1. Note that for&nbsp; each =
body-part a different protocol/scheme is specified:</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">C: A005 FETCH 1 (URL[2 (rtsp mms)] =
URL[3 (http imap)])</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">S: * 1 FETCH (URL[2] {21}</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">S: rtsp://part1/part2/file.mpg</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">S:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">S: URL[3] {28}</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">S: <A =
HREF=3D"http://www.part1.com/part2/file.mp3" =
TARGET=3D"_blank">http://www.part1.com/part2/file.mp3</A></FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">S:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">S: )</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">S: A005 OK FETCH complete</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The FETCH command provides the =
(standard) protocol frame. It does not contradict internal&nbsp; =
operations like transcoding or transferring message's data.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The CHANNEL draft demonstrates a =
scenario where different body-parts from different messages&nbsp; are =
retrieved in a single command. In that sense FETCH is indeed somewhat =
limited.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Amir Shiv </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Comverse</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">From: Chris Newman [<A =
HREF=3D"mailto:Chris.Newman@Sun.COM">mailto:Chris.Newman@Sun.COM</A>]</F=
ONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Sent: Tuesday, February 11, 2003 3:40 =
AM</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">To: Eric Burger; =
ietf-imapext@imc.org</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Cc: IETF LEMONADE (E-mail)</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Subject: Re: FETCH versus =
CHANNEL</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">I can not answer this question without =
more protocol details about the </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">contrasting proposals.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">What would the FETCH proposal look =
like on the wire?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">If we're operating on MIME body parts =
rather than an entire message, then </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">leveraging the existing FETCH =
infrastructure probably makes sense.&nbsp; But you </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">need to get the semantics =
correct.&nbsp; Look at the difference between partial </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">fetches in 1730 and 2060 for one sort =
of mistake.&nbsp; Look at the BINARY </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">extension for one example of how to =
do this correctly.</FONT>
</P>

<P><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Chris</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">begin&nbsp; quotation by Eric Burger =
on 2003/2/10 1:11 -0500:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Shiv proposed using FETCH =
instead of CHANNEL for requesting non-IMAP</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; retrieval (e.g., streaming) of =
messages.&nbsp; There were a bunch of &quot;yes --</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; that sounds right&quot; =
messages.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Does anyone object?&nbsp; Do we =
have consensus to move forward?</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C2D2A2.2C8A9FD4--


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1CDDu812768 for ietf-imapext-bks; Wed, 12 Feb 2003 05:13:56 -0800 (PST)
Received: from il-tlv-smtpout2.icomverse.com (il-tlv-firewall-main.icomverse.com [192.118.48.248]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1CDDsd12758 for <ietf-imapext@imc.org>; Wed, 12 Feb 2003 05:13:54 -0800 (PST)
Received: from il-tlv-mbdg2.comverse.com (localhost.localdomain [127.0.0.1]) by il-tlv-smtpout2.icomverse.com (8.11.6/8.11.6) with ESMTP id h1CDDcv20892 for <ietf-imapext@imc.org>; Wed, 12 Feb 2003 15:13:43 +0200
Received: by il-tlv-mbdg2.comverse.com with Internet Mail Service (5.5.2655.55) id <1XAC3BPH>; Wed, 12 Feb 2003 15:13:45 +0200
Message-ID: <7D4344E32B34D511A6500002A560C602230C61@il-tlv-mail4.comverse.com>
From: Shiv Amir <Amir.Shiv@comverse.com>
To: ietf-imapext@imc.org
Subject: RE: FETCH versus CHANNEL
Date: Wed, 12 Feb 2003 15:13:45 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D298.92401872"
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C2D298.92401872
Content-Type: text/plain;
	charset="iso-8859-1"


RFC 2060 says: "The FETCH command retrieves data associated with a
message...". Since the URL is a data associated  with a message or part of a
message, the FETCH command seems the most natural and consistent way.

The CHANNEL draft introduces a new data type, the <channel-set>, which is a
list of msg:section pairs. This data type  is limited only to multi-part
messages. In case of a "single-part" message an error or NIL should be
returned, hence it does not support this kind of messages. Also it is not
possible to specify a different scheme as per each requested URL.

The following example fetches the URLs for sections 2 and 3 of message
number 1. Note that for each body-part a  different protocol/scheme is
specified:

C: A005 FETCH 1 (URL[2 (rtsp mms)] URL[3 (http imap)])

S: * 1 FETCH (URL[2] {21}
S: rtsp://part1/part2/file.mpg
S:
S: URL[3] {28}
S: http://www.part1.com/part2/file.mp3
S:
S: )
S: A005 OK FETCH complete

The FETCH command provides the (standard) protocol frame. It does not
contradict internal operations like transcoding  or transferring message's
data.

The CHANNEL draft demonstrates a scenario where different body-parts from
different messages are retrieved in a  single command. In that sense FETCH
is indeed somewhat limited.

Amir Shiv 
Comverse


-----Original Message-----
From: Chris Newman [mailto:Chris.Newman@Sun.COM]
Sent: Tuesday, February 11, 2003 3:40 AM
To: Eric Burger; ietf-imapext@imc.org
Cc: IETF LEMONADE (E-mail)
Subject: Re: FETCH versus CHANNEL



I can not answer this question without more protocol details about the 
contrasting proposals.

What would the FETCH proposal look like on the wire?

If we're operating on MIME body parts rather than an entire message, then 
leveraging the existing FETCH infrastructure probably makes sense.  But you 
need to get the semantics correct.  Look at the difference between partial 
fetches in 1730 and 2060 for one sort of mistake.  Look at the BINARY 
extension for one example of how to do this correctly.

                - Chris

begin  quotation by Eric Burger on 2003/2/10 1:11 -0500:

>
> Shiv proposed using FETCH instead of CHANNEL for requesting non-IMAP
> retrieval (e.g., streaming) of messages.  There were a bunch of "yes --
> that sounds right" messages.
>
> Does anyone object?  Do we have consensus to move forward?


------_=_NextPart_001_01C2D298.92401872
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2655.35">
<TITLE>RE: FETCH versus CHANNEL</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=3D2>RFC 2060 says: &quot;The FETCH command retrieves data =
associated with a message...&quot;. Since the URL is a data =
associated&nbsp; with a message or part of a message, the FETCH command =
seems the most natural and consistent way.</FONT></P>

<P><FONT SIZE=3D2>The CHANNEL draft introduces a new data type, the =
&lt;channel-set&gt;, which is a list of msg:section pairs. This data =
type&nbsp; is limited only to multi-part messages. In case of a =
&quot;single-part&quot; message an error or NIL should be returned, =
hence it does not support this kind of messages. Also it is not =
possible to specify a different scheme as per each requested =
URL.</FONT></P>

<P><FONT SIZE=3D2>The following example fetches the URLs for sections 2 =
and 3 of message number 1. Note that for each body-part a&nbsp; =
different protocol/scheme is specified:</FONT></P>

<P><FONT SIZE=3D2>C: A005 FETCH 1 (URL[2 (rtsp mms)] URL[3 (http =
imap)])</FONT>
</P>

<P><FONT SIZE=3D2>S: * 1 FETCH (URL[2] {21}</FONT>
<BR><FONT SIZE=3D2>S: rtsp://part1/part2/file.mpg</FONT>
<BR><FONT SIZE=3D2>S:</FONT>
<BR><FONT SIZE=3D2>S: URL[3] {28}</FONT>
<BR><FONT SIZE=3D2>S: <A HREF=3D"http://www.part1.com/part2/file.mp3" =
TARGET=3D"_blank">http://www.part1.com/part2/file.mp3</A></FONT>
<BR><FONT SIZE=3D2>S:</FONT>
<BR><FONT SIZE=3D2>S: )</FONT>
<BR><FONT SIZE=3D2>S: A005 OK FETCH complete</FONT>
</P>

<P><FONT SIZE=3D2>The FETCH command provides the (standard) protocol =
frame. It does not contradict internal operations like =
transcoding&nbsp; or transferring message's data.</FONT></P>

<P><FONT SIZE=3D2>The CHANNEL draft demonstrates a scenario where =
different body-parts from different messages are retrieved in a&nbsp; =
single command. In that sense FETCH is indeed somewhat =
limited.</FONT></P>

<P><FONT SIZE=3D2>Amir Shiv </FONT>
<BR><FONT SIZE=3D2>Comverse</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Chris Newman [<A =
HREF=3D"mailto:Chris.Newman@Sun.COM">mailto:Chris.Newman@Sun.COM</A>]</F=
ONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, February 11, 2003 3:40 AM</FONT>
<BR><FONT SIZE=3D2>To: Eric Burger; ietf-imapext@imc.org</FONT>
<BR><FONT SIZE=3D2>Cc: IETF LEMONADE (E-mail)</FONT>
<BR><FONT SIZE=3D2>Subject: Re: FETCH versus CHANNEL</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>I can not answer this question without more protocol =
details about the </FONT>
<BR><FONT SIZE=3D2>contrasting proposals.</FONT>
</P>

<P><FONT SIZE=3D2>What would the FETCH proposal look like on the =
wire?</FONT>
</P>

<P><FONT SIZE=3D2>If we're operating on MIME body parts rather than an =
entire message, then </FONT>
<BR><FONT SIZE=3D2>leveraging the existing FETCH infrastructure =
probably makes sense.&nbsp; But you </FONT>
<BR><FONT SIZE=3D2>need to get the semantics correct.&nbsp; Look at the =
difference between partial </FONT>
<BR><FONT SIZE=3D2>fetches in 1730 and 2060 for one sort of =
mistake.&nbsp; Look at the BINARY </FONT>
<BR><FONT SIZE=3D2>extension for one example of how to do this =
correctly.</FONT>
</P>

<P><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; - Chris</FONT>
</P>

<P><FONT SIZE=3D2>begin&nbsp; quotation by Eric Burger on 2003/2/10 =
1:11 -0500:</FONT>
</P>

<P><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Shiv proposed using FETCH instead of CHANNEL =
for requesting non-IMAP</FONT>
<BR><FONT SIZE=3D2>&gt; retrieval (e.g., streaming) of messages.&nbsp; =
There were a bunch of &quot;yes --</FONT>
<BR><FONT SIZE=3D2>&gt; that sounds right&quot; messages.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Does anyone object?&nbsp; Do we have consensus =
to move forward?</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C2D298.92401872--


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1B2TVv27119 for ietf-imapext-bks; Mon, 10 Feb 2003 18:29:31 -0800 (PST)
Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1B2TUd27115 for <ietf-imapext@imc.org>; Mon, 10 Feb 2003 18:29:30 -0800 (PST)
Received: from esunmail ([129.147.58.120]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA27709 for <ietf-imapext@imc.org>; Mon, 10 Feb 2003 18:40:11 -0700 (MST)
Received: from xpa-fe1 (esunmail [129.147.58.120]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec  6 2002)) with ESMTP id <0HA400CNHFAZ79@edgemail1.Central.Sun.COM> for ietf-imapext@imc.org; Mon, 10 Feb 2003 18:40:11 -0700 (MST)
Received: from nifty-jr.west.sun.com ([129.153.12.95]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec  6 2002)) with ESMTPSA id <0HA400I9MFAWHC@mail.sun.net> for ietf-imapext@imc.org; Mon, 10 Feb 2003 18:40:11 -0700 (MST)
Date: Mon, 10 Feb 2003 17:39:57 -0800
From: Chris Newman <Chris.Newman@Sun.COM>
Subject: Re: FETCH versus CHANNEL
In-reply-to: <4A3384433CE2AB46A63468CB207E209D248778@zoe.office.snowshore.com>
To: Eric Burger <eburger@snowshore.com>, ietf-imapext@imc.org
Cc: "IETF LEMONADE (E-mail)" <um@snowshore.com>
Message-id: <2147483647.1044898797@nifty-jr.west.sun.com>
MIME-version: 1.0
X-Mailer: Mulberry/3.0.0 (Mac OS X)
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-message-flag: Outlook: the best virus distribution system around
References: <4A3384433CE2AB46A63468CB207E209D248778@zoe.office.snowshore.com>
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

I can not answer this question without more protocol details about the 
contrasting proposals.

What would the FETCH proposal look like on the wire?

If we're operating on MIME body parts rather than an entire message, then 
leveraging the existing FETCH infrastructure probably makes sense.  But you 
need to get the semantics correct.  Look at the difference between partial 
fetches in 1730 and 2060 for one sort of mistake.  Look at the BINARY 
extension for one example of how to do this correctly.

                - Chris

begin  quotation by Eric Burger on 2003/2/10 1:11 -0500:

>
> Shiv proposed using FETCH instead of CHANNEL for requesting non-IMAP
> retrieval (e.g., streaming) of messages.  There were a bunch of "yes --
> that sounds right" messages.
>
> Does anyone object?  Do we have consensus to move forward?




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1AK0Kk16307 for ietf-imapext-bks; Mon, 10 Feb 2003 12:00:20 -0800 (PST)
Received: from orthanc.ab.ca (orthanc.ab.ca [216.123.230.114]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1AK0Id16302 for <ietf-imapext@imc.org>; Mon, 10 Feb 2003 12:00:18 -0800 (PST)
Received: from orthanc.ab.ca (localhost4 [127.0.0.1]) by orthanc.ab.ca (8.12.6/8.12.6) with ESMTP id h1AK0Fvu073880; Mon, 10 Feb 2003 13:00:15 -0700 (MST) (envelope-from lyndon@orthanc.ab.ca)
Message-Id: <200302102000.h1AK0Fvu073880@orthanc.ab.ca>
To: Erev Ari <Ari.Erev@comverse.com>
cc: "'ietf-imapext@imc.org'" <ietf-imapext@imc.org>, "'um@snowshore.com'" <um@snowshore.com>
Subject: Re: [UM] FETCH versus CHANNEL 
In-Reply-To: Message from Erev Ari <Ari.Erev@comverse.com>  of "Mon, 10 Feb 2003 17:18:53 +0200." <7D4344E32B34D511A6500002A560C60204D88D59@il-tlv-mail4.comverse.com> 
X-Mailer: MH-E 7.1+cvs; nmh 1.0.4; GNU Emacs 21.2.2
Date: Mon, 10 Feb 2003 13:00:14 -0700
From: Lyndon Nerenberg <lyndon@orthanc.ab.ca>
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

Overloading Fetch to support the semantics of Channel would add a lot
of complexity to the parser. The arguments to Fetch don't apply to
a Channel-style retrieval, URIs don't look anything like message sets,
and the Fetch response won't allow for returned URLs or the individual
status responses required when the request specifies multiple URIs and
messages.

The only sane way to do this is with a new command.

--lyndon


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1AFJ4M01603 for ietf-imapext-bks; Mon, 10 Feb 2003 07:19:04 -0800 (PST)
Received: from il-tlv-smtpout2.icomverse.com (il-tlv-firewall-main.icomverse.com [192.118.48.248]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1AFJ1d01599 for <ietf-imapext@imc.org>; Mon, 10 Feb 2003 07:19:01 -0800 (PST)
Received: from il-tlv-mbdg2.comverse.com (localhost.localdomain [127.0.0.1]) by il-tlv-smtpout2.icomverse.com (8.11.6/8.11.6) with ESMTP id h1AFImR19419; Mon, 10 Feb 2003 17:18:48 +0200
Received: by il-tlv-mbdg2.comverse.com with Internet Mail Service (5.5.2655.55) id <DWYV82X4>; Mon, 10 Feb 2003 17:18:56 +0200
Message-ID: <7D4344E32B34D511A6500002A560C60204D88D59@il-tlv-mail4.comverse.com>
From: Erev Ari <Ari.Erev@comverse.com>
To: "'ietf-imapext@imc.org'" <ietf-imapext@imc.org>
Cc: "'um@snowshore.com'" <um@snowshore.com>
Subject: [UM] FETCH versus CHANNEL 
Date: Mon, 10 Feb 2003 17:18:53 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D117.B8B11A24"
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C2D117.B8B11A24
Content-Type: text/plain;
	charset="windows-1255"

Hello,

In response to Eric Burger's question - I am also for Amir's suggestion
(which is copied below so people can relate to it). 

> Hello, 
> I would like to suggest an alternative implementation to the proposed
CHANNEL extension. 
> The FETCH command is designed to retrieve properties of a message (flags,
UID...) 
> One can think of a URI to a message as another property of the message.
So, it looks more reasonable to me to extend the > existing FETCH command to
retrieve alternate URIs to messages (and message parts) rather than
introducing a new command (CHANNEL).
> 
> For example: 
> tag FETCH 1 BODY[2.URI (rtsp: http:)]
> 
> Isn't this much more simple and consistent with the IMAP model? 
> 
> Amir Shiv 
> Comverse 

Regards,
Ari

------_=_NextPart_001_01C2D117.B8B11A24
Content-Type: text/html;
	charset="windows-1255"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dwindows-1255">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2655.35">
<TITLE>[UM] FETCH versus CHANNEL </TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">Hello,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">In response to Eric Burger's question =
- I am also for Amir's suggestion (which is copied below so people can =
relate to it). </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; Hello, </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; I would like to suggest an =
alternative implementation to the proposed CHANNEL extension. </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; The FETCH command is designed to =
retrieve properties of a message (flags, UID...) </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; One can think of a URI to a =
message as another property of the message. So, it looks more =
reasonable to me to extend the &gt; existing FETCH command to retrieve =
alternate URIs to messages (and message parts) rather than introducing =
a new command (CHANNEL).</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; For example: </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; tag FETCH 1 BODY[2.URI (rtsp: =
http:)]</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Isn't this much more simple and =
consistent with the IMAP model? </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Amir Shiv </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Comverse </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Regards,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Ari</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C2D117.B8B11A24--


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1A6BCQ09083 for ietf-imapext-bks; Sun, 9 Feb 2003 22:11:12 -0800 (PST)
Received: from zoe.office.snowshore.com (goalie.snowshore.com [216.57.133.4]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1A6BAd09071 for <ietf-imapext@imc.org>; Sun, 9 Feb 2003 22:11:10 -0800 (PST)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="windows-1255"
Subject: FETCH versus CHANNEL
Date: Mon, 10 Feb 2003 01:11:10 -0500
Message-ID: <4A3384433CE2AB46A63468CB207E209D248778@zoe.office.snowshore.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Alternative to CHANNEL
Thread-Index: AcKZH52/SAHjiXucSpC67paMk9SWhw3jg6nw
From: "Eric Burger" <eburger@snowshore.com>
To: <ietf-imapext@imc.org>
Cc: "IETF LEMONADE (E-mail)" <um@snowshore.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h1A6BBd09073
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

Shiv proposed using FETCH instead of CHANNEL for requesting non-IMAP retrieval (e.g., streaming) of messages.  There were a bunch of "yes -- that sounds right" messages.

Does anyone object?  Do we have consensus to move forward?


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h15ATpS22152 for ietf-imapext-bks; Wed, 5 Feb 2003 02:29:51 -0800 (PST)
Received: from mid-2.inet.it (mid-2.inet.it [213.92.5.19]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h15ATnd22141 for <ietf-imapext@imc.org>; Wed, 5 Feb 2003 02:29:50 -0800 (PST)
Received: from  [::ffff:213.92.1.193] by mid-2.inet.it via I-SMTP-4.3.5-430 id ::ffff:213.92.1.193+b0YrPRU2PgAj; Wed, 05 Feb 2003 11:29:44 +0100
Date: Wed, 5 Feb 2003 11:31:24 +0100
Subject: Re: I-D ACTION:draft-hazewinkel-imap-vhost-00.txt (fwd)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v551)
Cc: Harrie Hazewinkel <harrie@inet.it>, Ken Murchison <ken@oceana.com>, Cyrus Daboo <daboo@cyrusoft.com>, IMAP Extensions WG <ietf-imapext@imc.org>
To: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
From: Harrie Hazewinkel <harrie@inet.it>
In-Reply-To: <68XxWxPXB4SK7HJyGdK7+A.md5@melkebalanse.gulbrandsen.priv.no>
Message-Id: <F9DDD7CB-38F4-11D7-A399-0003934A5A7E@inet.it>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.551)
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

On Monday, February 3, 2003, at 08:52 PM, Arnt Gulbrandsen wrote:

>
> I have one minor issue which hasn't been brought up so far: It 
> complicates the state diagram.

IMHO, it does not complicate the state diagram.
No new states are introduced, it has a similar approach
to the state diagram as STARTTLS.

> The proposal adds another non-authenticated, which does not seem to be 
> warranted.

Yes, a new command is added in the non-authenticated state.


Harrie
------------------------------------------------------------------
Author of MOD-SNMP, enabling SNMP management of Apache HTTP server



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h15ARNI21752 for ietf-imapext-bks; Wed, 5 Feb 2003 02:27:23 -0800 (PST)
Received: from hal-5.inet.it (hal-5.inet.it [213.92.5.24]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h15ARFd21722 for <ietf-imapext@imc.org>; Wed, 5 Feb 2003 02:27:16 -0800 (PST)
Received: from  [::ffff:213.92.1.193] by hal-5.inet.it via I-SMTP-4.3.6-430 id ::ffff:213.92.1.193+iMYUwy8ktYAr; Wed, 05 Feb 2003 11:27:13 +0100
Date: Wed, 5 Feb 2003 11:28:54 +0100
Subject: Re: I-D ACTION:draft-hazewinkel-imap-vhost-00.txt (fwd)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v551)
Cc: Harrie Hazewinkel <harrie@inet.it>, IMAP Extensions WG <ietf-imapext@imc.org>, IMAP Discusson List <imap@cac.washington.edu>
To: Cyrus Daboo <daboo@cyrusoft.com>
From: Harrie Hazewinkel <harrie@inet.it>
In-Reply-To: <1542173273.1044271731@[63.163.82.24]>
Message-Id: <A03EBE28-38F4-11D7-A399-0003934A5A7E@inet.it>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.551)
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

On Monday, February 3, 2003, at 05:28 PM, Cyrus Daboo wrote:

> Hi Harrie,
>
> --On Monday, February 3, 2003 9:45 AM +0100 Harrie Hazewinkel 
> <harrie@inet.it> wrote:
>
> | The main reason why I propose this is to seperate the domain from
> | the user identification. I understand that by commbining the two
> | you can have equal usernames int different domains. That is specified
> | in section 'Other considerations'.
> |
> | The benefits I see (maybe should be added in the draft) is that
> | - accounts in a multi domain environment can easier be managed.
> |    While manging an account you only care about the specific domain.
> |    This also allows a simpler and better distributed domain 
> management.
>
> The underlying account system can still separate out account 
> information by domain when domain-in-userid is used.



>
> | - domains can easier be distributed and re-distributed.
> |    When you move a virtual IMAP host to a different host, for the 
> client
> |    does not change. If he was 'forced' to use the VHOST the client
> |    transparantly connects to this new host.
>
> There are already a number of single front-end/multiple backend server 
> architectures that handle moving accounts between different host 
> machines.

This architectures I can immagine, but that is different.
I am here speaking of having a different/multiple front-end, handling 
all
a specific set of domains. With VHOST and doing VHOST forwarding (if I 
may
call it that way) you move a complete host whether it is a virtual host 
is
then not important.

>  We also have RLOGIN and RLIST extension to do referrals to new 
> machines.


>
> | - customers do not see that they are in a multi-domain environment.
> |    (Better for marketing of services.) For them it is no difference
> |    and is like they have there own server.
>
> Of course that is wrong - customers DO have to enter the domain 
> information somewhere in their client so that the client would know 
> what to use for VHOST. In the domain-in-userid approach its a simple 
> matter to 'hide' the concept of the domain by simply telling the user 
> to use their email address as their user id - I think that's a simple 
> enough concept for most users.

That depends. If an IMAP client is to discover the domain from its
server settings it is not needed.

>
> | - Could enable better load-balancing/load-distribution. Not added 
> yet,
> |    but I was thinking of adding 'response codes' to the response.
> |    The response code could indicate to a client that the virtual
> |    IMAP host is not available at the moment, or is moved to another
> |    host (temporarly or permanent). This option could facilitate
> |    a better load-balancing/distribution.
>
> Again front-end/back-end systems, RLOGIN etc already allow provide 
> this.

I cannot find 'RLOGIN' in some RFC or Internet-draft related to
IMAP, but I assume you mean RFC 2193 (referrals) correct??

Just a question to IMAP client vendors. Do all clients understand
referrals??

>
> | This as equal of what HTTP does. HTTP introduced virtual hosting
> | by creating a host-header to indicate, for instance, 
> www.example1.com or
> | www.exaple2.com on a single host. HTTP could also work with a single
> | hostname and adding a directory. For instance,
> | http://server.example.com/www.example1.com and
> | http://server.example.com/ www.exaple2.com.
> | For various reasons virtual hosting was introduced.
>
> That's fine but IMAP already supports virtual hosting using 
> capabilities available in its basic implementation.

I don't see this as such, maybe I am missing something.
I only understand you do need to embed the domain in the user
id of LOGIN or add it to the AUTHENTICATE command.
That is not what I think of virtual hosting.

> || Yes, I understand that clients need to be changed to implement it
> | where one could say little benefit. However, the benefit is on
> | the server side and this feature can is backwards compatible with
> | existing clients or servers.
>
> The domain-in-userid already provides the same benefits with the added 
> advantage of not having to change clients. I'm afraid I still don't 
> see the benefit of VHOST. Perhaps other server vendors can explain 
> existing problems with virtual hosting using domain-in-userid (if > 
> any)?

I agree, the VHOST command has no extreem benefit, but
some environments it would do, IMHO. The referal method is
at an command oriented level and a client could potentially
start jumpiong between the originated server and the referred
server. The VHOST problem would solve this by telling the
complete server is somewhere else in contrary to the per-mailbox
approach.

regards,

Harrie
------------------------------------------------------------------
Author of MOD-SNMP, enabling SNMP management of Apache HTTP server



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h15ANWM21349 for ietf-imapext-bks; Wed, 5 Feb 2003 02:23:32 -0800 (PST)
Received: from mid-1.inet.it (mid-1.inet.it [213.92.5.18]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h15ANUd21344 for <ietf-imapext@imc.org>; Wed, 5 Feb 2003 02:23:31 -0800 (PST)
Received: from  [::ffff:213.92.1.193] by mid-1.inet.it via I-SMTP-4.3.6-430 id ::ffff:213.92.1.193+fkS82X92mjUm; Wed, 05 Feb 2003 11:23:22 +0100
Date: Wed, 5 Feb 2003 11:24:59 +0100
Subject: Re: I-D ACTION:draft-hazewinkel-imap-vhost-00.txt (fwd)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v551)
Cc: Harrie Hazewinkel <harrie@inet.it>, Cyrus Daboo <daboo@cyrusoft.com>, IMAP Extensions WG <ietf-imapext@imc.org>, IMAP Discusson List <imap@cac.washington.edu>
To: Lawrence Greenfield <leg+@andrew.cmu.edu>
From: Harrie Hazewinkel <harrie@inet.it>
In-Reply-To: <5239163.1044282599@majormajor.WV.CC.CMU.EDU>
Message-Id: <142450BA-38F4-11D7-A399-0003934A5A7E@inet.it>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.551)
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

HI,

On Monday, February 3, 2003, at 08:29 PM, Lawrence Greenfield wrote:

>
> --On Monday, February 03, 2003 11:28 AM -0500 Cyrus Daboo 
> <daboo@cyrusoft.com> wrote:
>
>> The domain-in-userid already provides the same benefits with the added
>> advantage of not having to change clients. I'm afraid I still don't 
>> see
>> the benefit of VHOST. Perhaps other server vendors can explain 
>> existing
>> problems with virtual hosting using domain-in-userid (if any)?
>
> The biggest problem with domain-in-userid is that it comes after a 
> STARTTLS, which means that the server doesn't know what certificate to 
> present to the client.

Would that mean you believe a command like VHOST could solve this
problem?? I believe so. (Side effect not noted before by me).


Harrie
------------------------------------------------------------------
Author of MOD-SNMP, enabling SNMP management of Apache HTTP server



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h141gRR18785 for ietf-imapext-bks; Mon, 3 Feb 2003 17:42:27 -0800 (PST)
Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h141gPd18781 for <ietf-imapext@imc.org>; Mon, 3 Feb 2003 17:42:26 -0800 (PST)
Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout4.cac.washington.edu (8.12.1+UW01.12/8.12.1+UW02.12) with ESMTP id h141gMq6013155; Mon, 3 Feb 2003 17:42:22 -0800
Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.12.1+UW01.12/8.12.1+UW02.12) with ESMTP id h141gMup021283 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 3 Feb 2003 17:42:22 -0800
Date: Mon, 3 Feb 2003 17:42:23 -0800 (Pacific Standard Time)
From: Mark Crispin <MRC@cac.washington.edu>
To: Graham Freeman <graham@farwestern.com>
cc: IMAP Extensions WG <ietf-imapext@imc.org>, imap@u.washington.edu
Subject: Re: Misdirected messages
In-Reply-To: <2556531.1044271019@[192.168.0.74]>
Message-ID: <Pine.WNT.4.54.0302031715210.2220@Tomobiki-Cho.CAC.Washington.EDU>
References: <2556531.1044271019@[192.168.0.74]>
Organization: Networks & Distributed Computing
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

I do not enjoy receiving scolding messages, particularly when the scolding
is about something that (1) I did not do and (2) is not under my control.
As I told you a few weeks earlier, when you accused me of bcc'ing the IMAP
list, that nothing of the sort happened.  I was rather surprised when you
then responded that I "obviously" didn't know how to use my mail program.

You have neglected to consider a third possibility: that some mechanism
unique to you or your site is removing the line in the cc that indicates
where the message was sent.

I reviewed the copy I received of the message that you referred to.  In my
copy, the following cc list appears:
	Cc: Harrie Hazewinkel <harrie@inet.it>,
	   IMAP Extensions WG <ietf-imapext@imc.org>,
	   IMAP Discusson List <imap@cac.washington.edu>

You can also review the IMAP mailing list archives on
	ftp://ftp.cac.washington.edu/mail/imap_archive

The addresses "imap@cac.washington.edu" and "imap@u.washington.edu" are
exactly equivalent.  The former is the historical address (thus likely to
be in address books); the latter is the modern address.

Please do not make accusations until you have thoroughly investigated your
local system to make sure that it isn't a problem at your end.

On Mon, 3 Feb 2003, Graham Freeman wrote:
> At least three times in the recent past I've received messages which had
> "ietf-imapext@imc.org" somewhere in the To: or Cc: lines (plus an
> individual or two), but not any list that I'm actually subscribed to.
>
> Based on the headers of these messages, I think that one or both of the
> following are occurring:
> 1) "ietf-imapext@imc.org" has the imap.*washington\.edu list subscribed to
> it.  If so, that's silly - please don't do that.
> OR
> 2) People are putting the imap.*washington\.edu list in the Bcc: field of
> their messages.  If so, please don't do that.  It does more harm than good.
> Instead, put any/all list recipients in the To: or Cc: field.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h13KAbt10609 for ietf-imapext-bks; Mon, 3 Feb 2003 12:10:37 -0800 (PST)
Received: from spork.sendmail.com (spork.Sendmail.COM [209.246.26.39]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h13KAad10603 for <ietf-imapext@imc.org>; Mon, 3 Feb 2003 12:10:36 -0800 (PST)
Received: from katroo.Sendmail.COM (natted.Sendmail.COM [63.211.143.38]) by spork.sendmail.com (Switch-2.2.5/Switch-2.2.4) with ESMTP id h13KALw18360; Mon, 3 Feb 2003 12:10:21 -0800 (PST)
Received: from functor.smi.sendmail.com (functor.smi.sendmail.com [10.210.202.37]) by katroo.Sendmail.COM (8.11.6/8.11.6) with ESMTP id h13KBVV15836; Mon, 3 Feb 2003 12:11:31 -0800 (PST)
Message-Id: <200302032011.h13KBVV15836@katroo.Sendmail.COM>
To: Cyrus Daboo <daboo@cyrusoft.com>
Cc: Harrie Hazewinkel <harrie@inet.it>, IMAP Extensions WG <ietf-imapext@imc.org>, IMAP Discusson List <imap@cac.washington.edu>
Subject: Re: I-D ACTION:draft-hazewinkel-imap-vhost-00.txt (fwd) 
In-reply-to: <1542173273.1044271731@[63.163.82.24]> 
References: <E3377728-3753-11D7-A3AA-0003934A5A7E@inet.it>  <1542173273.1044271731@[63.163.82.24]> 
Date: Mon, 03 Feb 2003 12:01:05 -0800
From: Philip Guenther <guenther@sendmail.com>
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

Cyrus Daboo <daboo@cyrusoft.com> writes:
...
>The domain-in-userid already provides the same benefits with the added 
>advantage of not having to change clients. I'm afraid I still don't see the 
>benefit of VHOST. Perhaps other server vendors can explain existing 
>problems with virtual hosting using domain-in-userid (if any)?

As I see it, the current method has a single defect: ad-hoc parsing of
authentication IDs by servers.  Do you only split on '@' or do you also
fallback to splitting on '%' (for those MUAs that do their *own*
splitting on '@')?

However, that problem is already solved in those SASL mechanism that
pass the a 'realm' value separate from the username, such as DIGEST-MD5,
KERBEROS_V4, GSSAPI, and EXTERNAL w/TLS client certs.

Instead of defining a new command at the IMAP level for passing the
realm, I think would be better to
a) document/standardize common practice; and
b) encourage SASL mechanism designers to pass optional realm information
   separate from the username


Philip Guenther
Sendmail, Inc


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h13Jnqo10137 for ietf-imapext-bks; Mon, 3 Feb 2003 11:49:52 -0800 (PST)
Received: from melkebalanse.gulbrandsen.priv.no (melkebalanse.gulbrandsen.priv.no [217.19.171.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h13Jnod10133 for <ietf-imapext@imc.org>; Mon, 3 Feb 2003 11:49:50 -0800 (PST)
Message-Id: <68XxWxPXB4SK7HJyGdK7+A.md5@melkebalanse.gulbrandsen.priv.no>
From: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
To: Ken Murchison <ken@oceana.com>
Subject: Re: I-D ACTION:draft-hazewinkel-imap-vhost-00.txt (fwd)
Cc: Cyrus Daboo <daboo@cyrusoft.com>, Harrie Hazewinkel <harrie@inet.it>, IMAP Extensions WG <ietf-imapext@imc.org>
References: <E3377728-3753-11D7-A3AA-0003934A5A7E@inet.it> <3E3EC352.E32CE034@oceana.com>
In-Reply-To: <3E3EC352.E32CE034@oceana.com>
Content-Type: text/plain; format=flowed
MIME-Version: 1.0
Date: Mon, 3 Feb 2003 20:52:28 +0100
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

I have one minor issue which hasn't been brought up so far: It 
complicates the state diagram. The proposal adds another 
non-authenticated, which does not seem to be warranted.

--Arnt


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h13JUvW09672 for ietf-imapext-bks; Mon, 3 Feb 2003 11:30:57 -0800 (PST)
Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h13JUtd09668 for <ietf-imapext@imc.org>; Mon, 3 Feb 2003 11:30:56 -0800 (PST)
Received: from oceana.com (ny-kenton4a-b-98.buf.adelphia.net [24.51.29.98]) (authenticated bits=0) by eagle.oceana.com (8.12.7/8.12.7) with ESMTP id h13JUFAi031256 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Mon, 3 Feb 2003 14:30:15 -0500
Message-ID: <3E3EC352.E32CE034@oceana.com>
Date: Mon, 03 Feb 2003 14:30:26 -0500
From: Ken Murchison <ken@oceana.com>
Organization: Oceana Matrix Ltd.
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Harrie Hazewinkel <harrie@inet.it>
CC: Cyrus Daboo <daboo@cyrusoft.com>, IMAP Extensions WG <ietf-imapext@imc.org>
Subject: Re: I-D ACTION:draft-hazewinkel-imap-vhost-00.txt (fwd)
References: <E3377728-3753-11D7-A3AA-0003934A5A7E@inet.it>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

Harrie Hazewinkel wrote:
> 
> HI,
> 
> On Friday, January 31, 2003, at 07:08 PM, Cyrus Daboo wrote:
> [snip]
> ---------- End Forwarded Message ----------
> >
> > Just saw the above draft appear. I think this problem has already been
> > solved for the most part by having domain information expressed in
> > authentication ids. I did not understand the comment in the draft
> > about 'domain in auth-id' creating a 'single level list' and why that
> > is a problem. Can you explain in more detail the benefits that VHOST
> > offers over the 'domain in auth-id' approach? Its worth noting that
> > 'domain in auth-id' works right now without requiring modifications to
> > any clients, whereas VHOST would require client support.
> 
> The main reason why I propose this is to seperate the domain from
> the user identification. I understand that by commbining the two
> you can have equal usernames int different domains. That is specified
> in section 'Other considerations'.


I have two issues with your proposal:

1. The problem that you are trying to solve is an authentication problem
and we shouldn't clutter a message access protocol with commands that
provide "auxillary" authentication info.  This problem should be solved
within the authentication mechanisms already provided by IMAP.

2. There already exists at least two ways of providing the domain info
during authentication.  The first and probably most widely used is by
using fully qualified authids as Cyrus described.  The second would be
to use a SASL mechanism like DIGEST-MD5 in which the server provides a
list of realms that it serves, and the client chooses the one that it
wishes to be in.

My $.02
-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h13JU7B09623 for ietf-imapext-bks; Mon, 3 Feb 2003 11:30:07 -0800 (PST)
Received: from smtp5.andrew.cmu.edu (SMTP5.andrew.cmu.edu [128.2.10.85]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h13JU5d09619 for <ietf-imapext@imc.org>; Mon, 3 Feb 2003 11:30:05 -0800 (PST)
Received: from majormajor.WV.CC.CMU.EDU ([128.2.73.134]) (user=leg mech=GSSAPI (0 bits)) by smtp5.andrew.cmu.edu (8.12.3.Beta2/8.12.3.Beta2) with ESMTP id h13JTwDY005083 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 3 Feb 2003 14:29:58 -0500
Date: Mon, 03 Feb 2003 14:29:59 -0500
From: Lawrence Greenfield <leg+@andrew.cmu.edu>
To: Cyrus Daboo <daboo@cyrusoft.com>, Harrie Hazewinkel <harrie@inet.it>
cc: IMAP Extensions WG <ietf-imapext@imc.org>, IMAP Discusson List <imap@cac.washington.edu>
Subject: Re: I-D ACTION:draft-hazewinkel-imap-vhost-00.txt (fwd)
Message-ID: <5239163.1044282599@majormajor.WV.CC.CMU.EDU>
In-Reply-To: <1542173273.1044271731@[63.163.82.24]>
References: <E3377728-3753-11D7-A3AA-0003934A5A7E@inet.it> <1542173273.1044271731@[63.163.82.24]>
X-Mailer: Mulberry/3.0.0 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

--On Monday, February 03, 2003 11:28 AM -0500 Cyrus Daboo 
<daboo@cyrusoft.com> wrote:

> The domain-in-userid already provides the same benefits with the added
> advantage of not having to change clients. I'm afraid I still don't see
> the benefit of VHOST. Perhaps other server vendors can explain existing
> problems with virtual hosting using domain-in-userid (if any)?

The biggest problem with domain-in-userid is that it comes after a 
STARTTLS, which means that the server doesn't know what certificate to 
present to the client.

Larry



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h13GStp02574 for ietf-imapext-bks; Mon, 3 Feb 2003 08:28:55 -0800 (PST)
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h13GSsd02570 for <ietf-imapext@imc.org>; Mon, 3 Feb 2003 08:28:54 -0800 (PST)
Received: from [63.163.82.24] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id LAA21388; Mon, 3 Feb 2003 11:25:35 -0500 (EST)
Date: Mon, 03 Feb 2003 11:28:51 -0500
From: Cyrus Daboo <daboo@cyrusoft.com>
To: Harrie Hazewinkel <harrie@inet.it>
cc: IMAP Extensions WG <ietf-imapext@imc.org>, IMAP Discusson List <imap@cac.washington.edu>
Subject: Re: I-D ACTION:draft-hazewinkel-imap-vhost-00.txt (fwd)
Message-ID: <1542173273.1044271731@[63.163.82.24]>
In-Reply-To: <E3377728-3753-11D7-A3AA-0003934A5A7E@inet.it>
References:  <E3377728-3753-11D7-A3AA-0003934A5A7E@inet.it>
X-Mailer: Mulberry/3.0.0 (Mac OS/PPC)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

Hi Harrie,

--On Monday, February 3, 2003 9:45 AM +0100 Harrie Hazewinkel 
<harrie@inet.it> wrote:

| The main reason why I propose this is to seperate the domain from
| the user identification. I understand that by commbining the two
| you can have equal usernames int different domains. That is specified
| in section 'Other considerations'.
|
| The benefits I see (maybe should be added in the draft) is that
| - accounts in a multi domain environment can easier be managed.
|    While manging an account you only care about the specific domain.
|    This also allows a simpler and better distributed domain management.

The underlying account system can still separate out account information by 
domain when domain-in-userid is used.

| - domains can easier be distributed and re-distributed.
|    When you move a virtual IMAP host to a different host, for the client
|    does not change. If he was 'forced' to use the VHOST the client
|    transparantly connects to this new host.

There are already a number of single front-end/multiple backend server 
architectures that handle moving accounts between different host machines. 
We also have RLOGIN and RLIST extension to do referrals to new machines.

| - customers do not see that they are in a multi-domain environment.
|    (Better for marketing of services.) For them it is no difference
|    and is like they have there own server.

Of course that is wrong - customers DO have to enter the domain information 
somewhere in their client so that the client would know what to use for 
VHOST. In the domain-in-userid approach its a simple matter to 'hide' the 
concept of the domain by simply telling the user to use their email address 
as their user id - I think that's a simple enough concept for most users.

| - Could enable better load-balancing/load-distribution. Not added yet,
|    but I was thinking of adding 'response codes' to the response.
|    The response code could indicate to a client that the virtual
|    IMAP host is not available at the moment, or is moved to another
|    host (temporarly or permanent). This option could facilitate
|    a better load-balancing/distribution.

Again front-end/back-end systems, RLOGIN etc already allow provide this.

| This as equal of what HTTP does. HTTP introduced virtual hosting
| by creating a host-header to indicate, for instance, www.example1.com or
| www.exaple2.com on a single host. HTTP could also work with a single
| hostname and adding a directory. For instance,
| http://server.example.com/www.example1.com and
| http://server.example.com/ www.exaple2.com.
| For various reasons virtual hosting was introduced.

That's fine but IMAP already supports virtual hosting using capabilities 
available in its basic implementation.

|
| Yes, I understand that clients need to be changed to implement it
| where one could say little benefit. However, the benefit is on
| the server side and this feature can is backwards compatible with
| existing clients or servers.

The domain-in-userid already provides the same benefits with the added 
advantage of not having to change clients. I'm afraid I still don't see the 
benefit of VHOST. Perhaps other server vendors can explain existing 
problems with virtual hosting using domain-in-userid (if any)?

-- 
Cyrus Daboo


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h138iOC01000 for ietf-imapext-bks; Mon, 3 Feb 2003 00:44:24 -0800 (PST)
Received: from hal-5.inet.it (hal-5.inet.it [213.92.5.24]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h138iLd00996 for <ietf-imapext@imc.org>; Mon, 3 Feb 2003 00:44:21 -0800 (PST)
Received: from  [::ffff:213.92.1.193] by hal-5.inet.it via I-SMTP-4.3.6-430 id ::ffff:213.92.1.193+lMAyCmcPTqrU; Mon, 03 Feb 2003 09:44:11 +0100
Date: Mon, 3 Feb 2003 09:45:46 +0100
Subject: Re: I-D ACTION:draft-hazewinkel-imap-vhost-00.txt (fwd)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v551)
Cc: Harrie Hazewinkel <harrie@inet.it>, IMAP Extensions WG <ietf-imapext@imc.org>, IMAP Discusson List <imap@cac.washington.edu>
To: Cyrus Daboo <daboo@cyrusoft.com>
From: Harrie Hazewinkel <harrie@inet.it>
In-Reply-To: <2147483647.1044018480@[63.163.82.24]>
Message-Id: <E3377728-3753-11D7-A3AA-0003934A5A7E@inet.it>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.551)
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

HI,

On Friday, January 31, 2003, at 07:08 PM, Cyrus Daboo wrote:
[snip]
---------- End Forwarded Message ----------
>
> Just saw the above draft appear. I think this problem has already been 
> solved for the most part by having domain information expressed in 
> authentication ids. I did not understand the comment in the draft 
> about 'domain in auth-id' creating a 'single level list' and why that 
> is a problem. Can you explain in more detail the benefits that VHOST 
> offers over the 'domain in auth-id' approach? Its worth noting that 
> 'domain in auth-id' works right now without requiring modifications to 
> any clients, whereas VHOST would require client support.

The main reason why I propose this is to seperate the domain from
the user identification. I understand that by commbining the two
you can have equal usernames int different domains. That is specified
in section 'Other considerations'.

The benefits I see (maybe should be added in the draft) is that
- accounts in a multi domain environment can easier be managed.
   While manging an account you only care about the specific domain.
   This also allows a simpler and better distributed domain management.

- domains can easier be distributed and re-distributed.
   When you move a virtual IMAP host to a different host, for the client
   does not change. If he was 'forced' to use the VHOST the client
   transparantly connects to this new host.

- customers do not see that they are in a multi-domain environment.
   (Better for marketing of services.) For them it is no difference
   and is like they have there own server.

- Could enable better load-balancing/load-distribution. Not added yet,
   but I was thinking of adding 'response codes' to the response.
   The response code could indicate to a client that the virtual
   IMAP host is not available at the moment, or is moved to another
   host (temporarly or permanent). This option could facilitate
   a better load-balancing/distribution.

This as equal of what HTTP does. HTTP introduced virtual hosting
by creating a host-header to indicate, for instance, www.example1.com or
www.exaple2.com on a single host. HTTP could also work with a single
hostname and adding a directory. For instance,
http://server.example.com/www.example1.com and
http://server.example.com/ www.exaple2.com.
For various reasons virtual hosting was introduced.


Yes, I understand that clients need to be changed to implement it
where one could say little benefit. However, the benefit is on
the server side and this feature can is backwards compatible with
existing clients or servers.


regards,
Harrie
------------------------------------------------------------------
Author of MOD-SNMP, enabling SNMP management of Apache HTTP server



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1S03M911556 for ietf-imapext-bks; Thu, 27 Feb 2003 16:03:22 -0800 (PST)
Received: from max.kde.org (max.kde.org [134.2.170.93]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1S03LY11552 for <ietf-imapext@imc.org>; Thu, 27 Feb 2003 16:03:21 -0800 (PST)
Received: from 192.168.0.3 (ppp36-70.hrz.uni-bielefeld.de [129.70.36.70]) by max.kde.org (Postfix) with ESMTP id 21E95AFC4F for <ietf-imapext@imc.org>; Fri, 28 Feb 2003 01:03:25 +0100 (CET)
From: Marc Mutz <mutz@kde.org>
Organization: "Old Europe" - and proud
To: ietf-imapext@imc.org
Subject: Re: i18n support for sort & thread
Date: Fri, 28 Feb 2003 00:48:45 +0100
User-Agent: KMail/1.5.9
References: <2147483647.1046287578@nifty-jr.west.sun.com> <200302271752.57212@sendmail.mutz.com> <2147483647.1046358244@nifty-jr.west.sun.com>
In-Reply-To: <2147483647.1046358244@nifty-jr.west.sun.com>
X-PGP-Key: 0xBDBFE838
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_tPqX+4DSPEfS5u5"; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <200302280049.01187@sendmail.mutz.com>
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

--Boundary-02=_tPqX+4DSPEfS5u5
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Description: signed data
Content-Disposition: inline

On Friday 28 February 2003 00:04, Chris Newman wrote:
<snip>
> I explicitly do not want to create a comparator registry for all
> stringprep profiles -- there might be profiles used in narrow
> circumstances that aren't appropriate as comparators.  Furthermore,
> the namespace for stringprep profile names is unconstrained and thus
> may not fit the syntax for comparators.
<snip>

OK, my comment was prompted by the fact that there are already at least=20
four stringprep profiles (nameprep, kerberos5, xmpp (2x), mailprep(?))=20
are already in the works and it might be nice to indicate in the=20
comparator namimg that they're all stringprep-based.

Marc

=2D-=20
"Similia similibus curentur"
           -- Bush's new motto in fighting terrorism.

--Boundary-02=_tPqX+4DSPEfS5u5
Content-Type: application/pgp-signature
Content-Description: signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQA+XqPt3oWD+L2/6DgRAhIIAJ0fAEgAkRdhMb22Wco17Saz4zVOwwCeJ9Bo
42Gqp+OgnPaI9XJIclg1/8M=
=yK84
-----END PGP SIGNATURE-----

--Boundary-02=_tPqX+4DSPEfS5u5--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1RN4Hr10375 for ietf-imapext-bks; Thu, 27 Feb 2003 15:04:17 -0800 (PST)
Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1RN4GY10371 for <ietf-imapext@imc.org>; Thu, 27 Feb 2003 15:04:16 -0800 (PST)
Received: from esunmail ([129.147.58.120]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA11134 for <ietf-imapext@imc.org>; Thu, 27 Feb 2003 16:04:19 -0700 (MST)
Received: from xpa-fe1 ([129.147.58.198]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0HAZ00LSBPF6QI@edgemail1.Central.Sun.COM> for ietf-imapext@imc.org; Thu, 27 Feb 2003 16:04:19 -0700 (MST)
Received: from nifty-jr.west.sun.com ([129.153.12.95]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTPSA id <0HAZ00K5WPF43I@mail.sun.net> for ietf-imapext@imc.org; Thu, 27 Feb 2003 16:04:18 -0700 (MST)
Date: Thu, 27 Feb 2003 15:04:04 -0800
From: Chris Newman <Chris.Newman@Sun.COM>
Subject: Re: i18n support for sort & thread
In-reply-to: <200302271752.57212@sendmail.mutz.com>
To: Marc Mutz <mutz@kde.org>, ietf-imapext@imc.org
Message-id: <2147483647.1046358244@nifty-jr.west.sun.com>
MIME-version: 1.0
X-Mailer: Mulberry/3.0.0 (Mac OS X)
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-message-flag: Outlook: the best virus distribution system around
References: <2147483647.1046287578@nifty-jr.west.sun.com> <200302271752.57212@sendmail.mutz.com>
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

I explicitly do not want to create a comparator registry for all stringprep 
profiles -- there might be profiles used in narrow circumstances that 
aren't appropriate as comparators.  Furthermore, the namespace for 
stringprep profile names is unconstrained and thus may not fit the syntax 
for comparators.

The stringprep/nameprep specs allow unicode tables to be upgraded without a 
versioning or name change as long as certain requirements are met.  That's 
contrary to the desire for a comparator to be 100% predictable (so a 
disconnected client can emulate server behavior).  I also want to have the 
Unicode table version present in the name for all Unicode-based comparators 
as a matter of consistancy.

Thanks for raising the issue -- it's a good question and I'm glad you're 
reviewing the spec.

                - Chris

begin  quotation by Marc Mutz on 2003/2/27 17:52 +0100:

> On Thursday 27 February 2003 04:26, Chris Newman wrote:
>> 6.4 Nameprep Comparator
>>
>>    The "i;nameprep-rfc=YYYY-uv=3.2" comparator is an implementation
> <snip>
>
> Shouldn't this be "i;stringprep-profile=nameprep-rfc=YYYY", where YYYY
> is the rfc number of the profile? The listing of rfc number implies
> both the stringprep and the profile version and thus the Unicode
> version the comparator is based on.
>
> Marc
>
> --
> They [RIAA,MPAA] are trying to invent a new crime:
> interference with a business model.
>                            --Bruce Schneier, Crypto-Gram 08/2002




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1RMq5J10089 for ietf-imapext-bks; Thu, 27 Feb 2003 14:52:05 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1RMq4Y10084 for <ietf-imapext@imc.org>; Thu, 27 Feb 2003 14:52:04 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01KSXMZWYRKG002O3W@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ietf-imapext@imc.org; Thu, 27 Feb 2003 14:52:04 -0800 (PST)
Date: Thu, 27 Feb 2003 14:51:20 -0800 (PST)
From: ned+imapext@INNOSOFT.COM
Subject: Re: i18n support for sort & thread
In-reply-to: "Your message dated Thu, 27 Feb 2003 17:52:45 +0100" <200302271752.57212@sendmail.mutz.com>
To: Marc Mutz <mutz@kde.org>
Cc: ietf-imapext@imc.org
Message-id: <01KSXQ29RI8O002O3W@mauve.mrochek.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Content-transfer-encoding: 7BIT
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

> On Thursday 27 February 2003 04:26, Chris Newman wrote:
> > 6.4 Nameprep Comparator
> >
> >    The "i;nameprep-rfc=YYYY-uv=3.2" comparator is an implementation
> <snip>

> Shouldn't this be "i;stringprep-profile=nameprep-rfc=YYYY", where YYYY
> is the rfc number of the profile? The listing of rfc number implies
> both the stringprep and the profile version and thus the Unicode
> version the comparator is based on.

Using RFC numbers for this is a bad idea IMO. RFCs tend to get revised from
time to time...

				Ned


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1RMasn09643 for ietf-imapext-bks; Thu, 27 Feb 2003 14:36:54 -0800 (PST)
Received: from max.kde.org (max.kde.org [134.2.170.93]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1RMaqY09639 for <ietf-imapext@imc.org>; Thu, 27 Feb 2003 14:36:52 -0800 (PST)
Received: from 192.168.0.3 (ppp36-239.hrz.uni-bielefeld.de [129.70.36.239]) by max.kde.org (Postfix) with ESMTP id 150C8AFC1A for <ietf-imapext@imc.org>; Thu, 27 Feb 2003 23:36:53 +0100 (CET)
From: Marc Mutz <mutz@kde.org>
Organization: "Old Europe" - and proud
To: ietf-imapext@imc.org
Subject: Re: i18n support for sort & thread
Date: Thu, 27 Feb 2003 17:52:45 +0100
User-Agent: KMail/1.5.9
References: <2147483647.1046287578@nifty-jr.west.sun.com>
In-Reply-To: <2147483647.1046287578@nifty-jr.west.sun.com>
X-PGP-Key: 0xBDBFE838
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_pJkX+5+QlFZ+/bd"; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <200302271752.57212@sendmail.mutz.com>
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

--Boundary-02=_pJkX+5+QlFZ+/bd
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Description: signed data
Content-Disposition: inline

On Thursday 27 February 2003 04:26, Chris Newman wrote:
> 6.4 Nameprep Comparator
>
>    The "i;nameprep-rfc=3DYYYY-uv=3D3.2" comparator is an implementation
<snip>

Shouldn't this be "i;stringprep-profile=3Dnameprep-rfc=3DYYYY", where YYYY=
=20
is the rfc number of the profile? The listing of rfc number implies=20
both the stringprep and the profile version and thus the Unicode=20
version the comparator is based on.

Marc

=2D-=20
They [RIAA,MPAA] are trying to invent a new crime:
interference with a business model.
                           --Bruce Schneier, Crypto-Gram 08/2002

--Boundary-02=_pJkX+5+QlFZ+/bd
Content-Type: application/pgp-signature
Content-Description: signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQA+XkJp3oWD+L2/6DgRAl0XAKC7EX5r8ysAKq5TUAxlaeWVeJZP6QCePdgi
IPPTtqZAGvJljaOnk3Bg1UA=
=e6j5
-----END PGP SIGNATURE-----

--Boundary-02=_pJkX+5+QlFZ+/bd--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1R3QWp13367 for ietf-imapext-bks; Wed, 26 Feb 2003 19:26:32 -0800 (PST)
Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1R3QRY13362 for <ietf-imapext@imc.org>; Wed, 26 Feb 2003 19:26:27 -0800 (PST)
Received: from esunmail ([129.147.58.120]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA25564 for <ietf-imapext@imc.org>; Wed, 26 Feb 2003 20:26:31 -0700 (MST)
Received: from xpa-fe2 (esunmail [129.147.58.120]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0HAY007QS6W6XY@edgemail1.Central.Sun.COM> for ietf-imapext@imc.org; Wed, 26 Feb 2003 20:26:30 -0700 (MST)
Received: from nifty-jr.west.sun.com ([129.153.12.95]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTPSA id <0HAY00K2M6W3NC@mail.sun.net> for ietf-imapext@imc.org; Wed, 26 Feb 2003 20:26:30 -0700 (MST)
Date: Wed, 26 Feb 2003 19:26:18 -0800
From: Chris Newman <Chris.Newman@Sun.COM>
Subject: i18n support for sort & thread
To: IMAP Extensions WG <ietf-imapext@imc.org>
Message-id: <2147483647.1046287578@nifty-jr.west.sun.com>
MIME-version: 1.0
X-Mailer: Mulberry/3.0.0 (Mac OS X)
Content-type: multipart/mixed; boundary="Boundary_(ID_I25bkmf4RDmU78k34DhkmQ)"
X-message-flag: Outlook: the best virus distribution system around
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

--Boundary_(ID_I25bkmf4RDmU78k34DhkmQ)
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
Content-disposition: inline

I tried to make the I-D deadline for this and missed.  Turns out it was a 
significantly bigger project than I expected.

Attached is a preliminary draft for the "comparator registry" spec which 
also defines the "basic" ordering algorithm (by reference to the Unicode 
Collation Algorithm).  My understanding is that this is also the algorithm 
implemented by the widely regarded ICU open-source library.

The second piece I have not finished yet is an IMAP extension which adds a 
command to negotiate the comparator the server will use.  I also plan to 
fold the old language extension into this draft so both language and 
comparator can be negotiated in one round trip with a single "NEGOTIATE" 
command (structured so future extensions could share the command).

These two specs in combination with the current SORT and THREAD draft 
should make SORT and THREAD acceptable to the IESG on the grounds we have 
adequate facilities for i18n users.

Comments are welcome.

I will be seeking a wider audience for the comparator spec relatively soon, 
as it needs serious review by Unicode/i18n experts.  But this gives us 
something to start.

                - Chris

--Boundary_(ID_I25bkmf4RDmU78k34DhkmQ)
Content-type: text/plain; charset=iso-8859-1; name=comparator.txt
Content-transfer-encoding: 7BIT
Content-disposition: attachment; filename=comparator.txt; size=46765



Network Working Group                                          C. Newman
Internet-Draft                                          Sun Microsystems
Expires: August 27, 2003                               February 26, 2003


           Internet Application Protocol Comparator Registry
                draft-newman-i18n-comparator-00pre1.txt

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at http://
   www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 27, 2003.

Copyright Notice

   Copyright (C) The Internet Society (2003). All Rights Reserved.

Abstract

   Many Internet application protocols include string-based lookup,
   searching, or sorting operations.  However the problem space for
   searching and sorting international strings is large, not fully
   explored, and is outside the area of expertise for the Internet
   Engineering Task Force (IETF).  Rather than attempt to solve such a
   large problem, this specification creates an abstraction framework so
   that application protocols can precisely identify a comparison
   function and we can extend the repertoire of comparison functions in
   the future.







Newman                  Expires August 27, 2003                 [Page 1]

Internet-Draft            Comparator Registry              February 2003


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   1.1 Conventions Used in this Document  . . . . . . . . . . . . . .  3
   2.  Comparator Definition and Purpose  . . . . . . . . . . . . . .  3
   3.  Comparator Name Syntax . . . . . . . . . . . . . . . . . . . .  4
   4.  Comparator Specification Requirements  . . . . . . . . . . . .  5
   5.  Application Protocol Requirements  . . . . . . . . . . . . . .  7
   6.  Initial Comparators  . . . . . . . . . . . . . . . . . . . . .  8
   6.1 Octet Comparator . . . . . . . . . . . . . . . . . . . . . . .  8
   6.2 ASCII Numeric Comparator . . . . . . . . . . . . . . . . . . .  9
   6.3 ASCII Casemap Comparator . . . . . . . . . . . . . . . . . . . 10
   6.4 Nameprep Comparator  . . . . . . . . . . . . . . . . . . . . . 10
   6.5 Basic Comparator . . . . . . . . . . . . . . . . . . . . . . . 10
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   7.1 Comparator Registration Procedure  . . . . . . . . . . . . . . 13
   7.2 Comparator Registration Template . . . . . . . . . . . . . . . 14
   7.3 Octet Comparator Registration  . . . . . . . . . . . . . . . . 14
   7.4 ASCII Numeric Comparator Registration  . . . . . . . . . . . . 14
   7.5 ASCII Casemap Comparator Registration  . . . . . . . . . . . . 15
   7.6 Nameprep Comparator Registration . . . . . . . . . . . . . . . 15
   7.7 Basic Comparator Registration  . . . . . . . . . . . . . . . . 15
   7.8 Structure of Comparator Registry . . . . . . . . . . . . . . . 16
   7.9 Example Initial Registry . . . . . . . . . . . . . . . . . . . 17
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 19
   A.  Use by ACAP and Sieve  . . . . . . . . . . . . . . . . . . . . 19
   B.  Guidelines for Expert Reviewer . . . . . . . . . . . . . . . . 19
   C.  RFC Editor Directions  . . . . . . . . . . . . . . . . . . . . 20
       Normative References . . . . . . . . . . . . . . . . . . . . . 17
       Informative References . . . . . . . . . . . . . . . . . . . . 18
   D.  Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . . 20
       Intellectual Property and Copyright Statements . . . . . . . . 22


















Newman                  Expires August 27, 2003                 [Page 2]

Internet-Draft            Comparator Registry              February 2003


1. Introduction

   The ACAP [11] specification introduced the concept of a comparator,
   but failed to create an IANA registry.  With the introduction of
   stringprep [5], it is now time to create that registry and populate
   it with some initial values appropriate for an international
   community.  This specification replaces and generalizes the
   definition of a comparator in ACAP and creates a comparator registry.

1.1 Conventions Used in this Document

   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
   in this document are to be interpreted as defined in "Key words for
   use in RFCs to Indicate Requirement Levels" [1].

   The attribute syntax specifications use the Augmented Backus-Naur
   Form (ABNF) [2] notation including the core rules defined in Appendix
   A.  This also inherits ABNF rules from Language Tags [4].

2. Comparator Definition and Purpose

   A comparator is a named function which takes two arbitrary length
   octet strings (encoded in UTF-8 [3] for comparators which operate on
   characters) as input and can be used to perform one or more of three
   basic comparison operations: equality test, substring match and
   ordering test.

   Comparators provide a multi-protocol abstraction layer for comparsion
   functions so the details of a particular comparsion operation can be
   specified by someone with appropriate expertise independent of the
   application protocol that consumes that comparator.  This is similar
   to the way a charset [14] separates the details of octet to character
   mapping from a protocol specification such as MIME [8] or the way
   SASL [10] separates the details of an authentication mechanism with
   optional security layer from a protocol specification such as ACAP
   [11].















Newman                  Expires August 27, 2003                 [Page 3]

Internet-Draft            Comparator Registry              February 2003


   Here a a small diagram to help illustrate the value of this
   abstraction layer:

                                                 +-----------------+
                                                 | Octet           |
   +-------------------+                      +--| Comparator Spec |
   | IMAP i18n SEARCH  |--+                   |  +-----------------+
   +-------------------+  |  +-------------+  |  +-----------------+
                          +--| Comparator  |--+--| A stringprep    |
   +-------------------+  |  | Registry    |  |  | Comparator Spec |
   | ACAP i18n SEARCH  |--+  +-------------+  |  +-----------------+
   +-------------------+                      |  +-----------------+
                                              |  | locale-specific |
                                              +--| Comparator Spec |
                                                 +-----------------+

   Thus IMAP, ACAP and future application protocols with international
   search capability simply specify how to interface to the comparator
   registry instead of each protocol spec having to specify all the
   comparators it supports.

3. Comparator Name Syntax

   The comparator name itself is a single US-ASCII string beginning with
   a letter and made up of letters, digits, or one of the following 4
   symbols: "-", ";", "." or "=".  The name MUST NOT be longer than 255
   characters.

     comparator-char  =  ALPHA / DIGIT / "-" / ";" / "=" / "."

     comparator-name  =  ALPHA *254comparator-char

   The string a client uses to select a comparator MAY contain a
   wildcard ("*") character which matches zero or more comparator-chars.
   Wildcard characters MUST NOT be adjacent.  Clients which support
   disconnected operation SHOULD NOT use wildcards to select a
   comparator, but clients which provide comparator operations only when
   connected to the server MAY use wildcards.  If the wildcard string
   matches multiple comparators, the server SHOULD select the comparator
   with the broadest scope (perferably i18n), the most recent table
   versions and the greatest number of supported operations.  A single
   wildcard character ("*") specifies use of the mandatory-to-implement
   comparator as specified in the most recent application protocol
   standard to which the server complies.







Newman                  Expires August 27, 2003                 [Page 4]

Internet-Draft            Comparator Registry              February 2003


   When used as a protocol element for ordering, the comparator name MAY
   be prefixed by either "+" or "-" to explicitly specify an ordering
   direction.  As mentioned previously, "+" has no effect on the
   ordering function, while "-" negates the result of the ordering
   function.

     comparator-wild  =  ("*" / (ALPHA ["*"])) *(comparator-char ["*"])
                         ; MUST NOT exceed 255 characters total

     comparator-order =  ["+" / "-"] comparator-wild

   While this specification makes no absolute requirements on the
   structure of comparator names, naming consistancy is important, so
   the following initial guidelines are provided.

   Comparator names with an international audience typically begin with
   "i;".  Comparator names intended for a particular language or locale
   typically begin with a language tag [4] followed by a ";".  After the
   first ";" is normally the name of the general comparator algorithm
   followed by a series of algorithm modifications separated by the "-"
   delimiter.  Parameterized modifications will use "=" to delimit the
   parameter from the value.  The version numbers of any lookup tables
   used by the algorithm SHOULD be present as parameterized
   modifications.  This is typically followed by a ";" and a name for a
   set of customizations applied to the basic algorithm.

   Comparator names of the form *;vnd-domain.com;* are reserved for
   vendor-specific comparators created by the owner of the domain name
   following the "vnd-" prefix.  Registration of such comparators (or
   the namespace as a whole) with intended use of "Vendor" is encouraged
   when a public specification or open-source implementation is
   available, but is not required.

4. Comparator Specification Requirements

   A comparator specification MUST state which of the three basic
   functions are supported (equality, substring, ordering) and how to
   perform each of the supported functions on any two input
   octet-strings including empty strings.  Given a comparator with a
   specific name, and any two fixed input strings, the result MUST be
   the same.  The comparator specification MUST state whether the
   comparator operates on raw octets or on characters (in which case the
   UTF-8 charset is presumed).  Comparators MUST be transitive.

   Comparators which use tables in a documented format MUST assign
   numbers to the tables they use.  This permits an application protocol
   command to access the tables used by a server comparator.




Newman                  Expires August 27, 2003                 [Page 5]

Internet-Draft            Comparator Registry              February 2003


   o  The equality function always returns "match" or "no-match" when
      supplied valid input and MAY return "error" if the input strings
      are not valid UTF-8 strings or violate other comparator
      constraints.

   o  The substring matching function determines if the first string is
      a substring of the second string.  A comparator which supports
      substring matching will automatically support the two special
      cases of substring matching: prefix and suffix matching if those
      special cases are supported by the application protocol.  It
      returns "match" or "no-match" when supplied valid input and
      returns "error" when supplied invalid input.

   o  The ordering function determines how two octet strings are
      ordered.  It returns "-1" if the first string is listed before the
      second string according to the comparator, "+1" if the second
      string is listed before the first string, and "0" if the two
      strings are equal.  If the order of the two strings is reversed,
      the result of the ordering function of the comparator MUST be
      negated.  In general, comparators SHOULD NOT return "0" unless the
      two octet sequences are identical.

      Since ordering is normally used to sort a list of items, "error"
      is not a useful return value from the ordering function.  Strings
      with errors that prevent the sorting algorithm from functioning
      correctly should sort to the end of the list.  Thus if the first
      string is invalid UTF-8 while the second string is valid, the
      result will be "+1".  If the second string is invalid UTF-8 while
      the first string is valid, the result will be "-1".  If the
      comparator is character-based, and both strings are invalid UTF-8,
      the result SHOULD match the result from the "i;octet" comparator.

      When the comparator is used with a "+" prefix, the behavior is the
      same as when used with no prefix.  When the comparator is used
      with a "-" prefix, results which would be "+1" are instead "-1"
      and results which would be "-1" are instead "+1".

   Unless otherwise specified by the comparator or application protocol,
   a NULL string (as opposed to an empty string) is equal only to
   another NULL string, a NULL string is not a substring of any other
   string, and a NULL string sorts to a position after all non-NULL
   strings, but before strings which generate errors.

   Some application protocols will permit the use of a multi-value
   attributes with a comparator.  This paragraph describes the rules
   that apply unless otherwise specified by the comparator or
   application protocol.  The equality and substring comparator
   algorithms will be iterated over each pair of single values from the



Newman                  Expires August 27, 2003                 [Page 6]

Internet-Draft            Comparator Registry              February 2003


   two inputs.  If any combination produces an error, the result is an
   error.  Otherwise, if any combination produces a "match", the result
   is a match.  Otherwise the result is "no-match".  For the ordering
   function, the smallest ordinal octet string from the first set of
   values is compared to the smallest ordinal octet string from the
   second set of values.

   Application protocols MAY return position information for substring
   matches.  If this is done, the position information MUST include both
   the starting offset and the ending offset in the string.  This is
   important because canonicalization can cause strings with different
   numbers of characters to match.

   Comparator specifications intended for general use are expected to
   reference standards from other standards bodies with more experience
   dealing with the details of international character sets.

5. Application Protocol Requirements

   An application protocol which offers searching, substring matching
   and/or sorting and permits the use of characters outside the US-ASCII
   charset needs to consider the following requirements and issues:

   The protocol MUST provide a mechanism for the client to select the
   comparator to use with equality matching, substring matching and
   ordering.

   The protocol MUST specify at least one mandatory-to-implement
   comparator which provides basic results acceptable to multiple
   languages.  The mandatory-to-implement comparator MUST be specified
   in an IESG-approved RFC as suitable for that purpose.  The
   mandatory-to-implement comparator MUST support the subset of the
   three comparator operations that are likely to be used by the
   protocol and widely deployed extensions to the protocol.

   The protocol SHOULD provide a way to list available comparators
   matching a given wildcard pattern or patterns.

   If the protocol provides positional information for the results of a
   substring match, that positional information MUST fully specify the
   substring in the result that matches independent of the length of the
   search string.  For example, returning both the starting and ending
   offset of the match would suffice, as would the starting offset and a
   length.  Returning just the starting offset is not acceptable.

   If the protocol permits the use of comparators on stored character
   data which is not encoded with the UTF-8 charset, then the protocol
   specification has to describe relevant issues of the conversion.



Newman                  Expires August 27, 2003                 [Page 7]

Internet-Draft            Comparator Registry              February 2003


   Details to consider include how to handle unknown charsets, any
   charsets which are mandatory to support, any issues with byte-order
   that might apply, and any transfer encodings which need to be
   supported.

   If the protocol supports disconnected clients, then a mechanism for
   the client to precisely replicate the server's comparator algorithm
   is likely desirable.  Thus the protocol MAY wish to provide a command
   to fetch tables used by charset conversions and comparators.

   The protocol specification should consider assigning protocol error
   codes for the following circumstances:

   o  The client requests the use of a comparator by name or pattern,
      but no implemented comparator matches that pattern.

   o  The client attempts to use a comparator for a function that is not
      supported by that comparator.  For example, attempting to use the
      "i;ascii-numeric" comparator for a substring matching function.

   o  The client uses an equality or substring matching comparator and
      the result is an error.  It may be appropriate to distinguish
      between the two input strings, particularly when one is supplied
      by the client and one is stored by the server.  It might also be
      appropriate to distinguish the specific case of an invalid UTF-8
      string.

   If the protocol permits the use of a comparator with data structures
   beyond those described in this specification (octet strings, NULL
   string, array of octet strings), the protocol MUST describe the
   default behavior for a comparator with that data structure.

6. Initial Comparators

   This section describes an initial set of comparators for the
   comparator registry.

6.1 Octet Comparator

   The "i;octet" comparator is a simple and fast comparator intended for
   use on binary octet strings rather than on character data.  It never
   returns an "error" result.  It provides equality, substring and
   ordering functions.  The ordering algorithm is as follows:

   1.  If both strings are the empty string, return the result "0".

   2.  If the first string is empty and the second is not, return the
       result "-1".



Newman                  Expires August 27, 2003                 [Page 8]

Internet-Draft            Comparator Registry              February 2003


   3.  If the second string is empty and the first is not, return the
       result "+1".

   4.  If both strings begin with the same octet value, remove the first
       octet from both strings and repeat this algorithm from step 1.

   5.  If the unsigned value (0 to 255) of the first octet of the first
       string is less than the unsigned value of the first octet of the
       second string, then return "-1".

   6.  If this step is reached, return "+1".

   This algorithm is roughly equivalent to the C library function memcmp
   with appropriate length checks added.

   The matching function returns "match" if the sorting algorithm would
   return "0".  Otherwise the matching function returns "no-match".

   The substring function returns "match" if the first string is the
   empty string, or if there exists a substring of the second string of
   length equal to the length of the first string which would result in
   a "match" result from the equality function.  Otherwise the substring
   function returns "no-match".

6.2 ASCII Numeric Comparator

   The "i;ascii-numeric" comparator is a simple comparator intended for
   use with arbitrary sized decimal numbers stored as octet strings of
   US-ASCII digits (0x30 to 0x39).  It supports equality and ordering,
   but does not support the substring function.  The algorithm is as
   follows:

   1.  If neither string begins with a digit, return "error" if
       matching, or the result of the "i;octet" comparator for ordering.

   2.  If the first string begins with a digit and the second string
       does not, return "error" if matching and "-1" for ordering.

   3.  If the second string begins with a digit and the first string
       does not, return "error" if matching and "+1" for ordering.

   4.  Let "n" be the number of digits at the beginning of the first
       string, and "m" be the number of digits at the beginning of the
       second string.

   5.  If n is equal to m, return the result of the "i;octet"
       comparator.




Newman                  Expires August 27, 2003                 [Page 9]

Internet-Draft            Comparator Registry              February 2003


   6.  If n is greater than m, prepend a string of "n - m" zeros to the
       second string and return the result of the "i;octet" comparator.

   7.  If m is greater than n, prepend a string of "m - n" zeros to the
       first string and return the result of the "i;octet" comparator.


6.3 ASCII Casemap Comparator

   The "i;ascii-casemap" comparator is a simple comparator intended for
   use with English language text in pure US-ASCII.  It provides
   equality, substring and ordering functions.  The algorithm first
   applies a mapping to both input strings which subtracts 32 (0x20)
   from all octet values between the range 97 (0x61) and 122 (0x7A)
   inclusive.  The result of the comparator is then the same as the
   result of the "i;octet" comparator for the resulting strings.  Note
   that this comparator is _not_ equivalent to the strcasecmp or stricmp
   functions available on some platforms which are often
   locale-sensitive.

   This comparator is deprecated for the following two reasons: 1. It
   should have been called "en;ascii-casemap" rather than
   "i;ascii-casemap" (it has not been renamed in order to retain
   compatibility with the ACAP and Sieve specifications). 2. It is
   undesirable to have an ordering algorithm return "0" when the two
   input strings are not identical as this can produce inconsistent
   results when the ordering function is used to sort a list.

6.4 Nameprep Comparator

   The "i;nameprep-rfc=YYYY-uv=3.2" comparator is an implementation of
   the nameprep [6] FIXME specification as documented in RFC YYYY and
   based on normalization tables from Unicode version 3.2.  This
   comparator provides equality and substring matching, but does not
   provide the ordering function.  This comparator is suitable for use
   as the only mandatory-to-implement comparator for a protocol which
   does not offer ordering or sorting in the base spec and is unlikely
   to do so in a widely implemented protocol extension.

   If the nameprep specification is revised without any changes that
   would produce different results when given different input octet
   strings, then the name of this comparator will remain unchanged.

6.5 Basic Comparator

   The basic comparator is intended to privide tolerable results for a
   number of languages for all three functions (equality, substring and
   ordering) so it is suitable as a mandatory-to-implement comparator



Newman                  Expires August 27, 2003                [Page 10]

Internet-Draft            Comparator Registry              February 2003


   for protocols which include ordering support.  The ordering function
   of the basic comparator is the  version 9 (UCAv9).

   The equality and substring functions are created as described in
   UCAv9 section 8.  While that section is informative to UCAv9, it is
   normative to this comparator specification.

   This comparator is based on Unicode version 3.2, with the following
   tables relevant:

   1.  For the normalization step, UnicodeData-3.2.0.txt [16] is used.
       Column 5 is used to determine the canonical decomposition, while
       column 3 contains the canonical combining classes necessary to
       attain canonical order.

   2.  The table of characters which require a logical order exception
       is a subset of the table in PropList-3.2.0.txt [17] and is
       included here:

   0E40..0E44    ; Logical_Order_Exception
   # Lo   [5] THAI CHARACTER SARA E..THAI CHARACTER SARA AI MAIMALAI
   0EC0..0EC4    ; Logical_Order_Exception
   # Lo   [5] LAO VOWEL SIGN E..LAO VOWEL SIGN AI

   # Total code points: 10

   3.  The table used to translate normalized code points to a sort key
       is allkeys-3.1.1.txt [18].

   UCAv9 includes a number of configurable parameters and steps labelled
   as potentially optional.  The following list summarizes the defaults
   used by this comparator:

   o  The logical order exception step is mandatory by default to
      support the largest number of languages.

   o  Steps 2.1.1 to 2.1.3 are mandatory as the repertoire of the basic
      comparator is intended to be large.

   o  The second level in the sort key is evaluated forwards by default.

   o  The variable weighting uses the "non-ignorable" option by default.

   o  The semi-stable option is not used by default.

   o  Support for exactly three levels of collation is the default
      behavior.




Newman                  Expires August 27, 2003                [Page 11]

Internet-Draft            Comparator Registry              February 2003


   o  No preprocessing step is used by the basic comparator prior to
      applying the UCAv9 algorithm.  Note that an application protocol
      specification MAY require pre-processing prior to the use of any
      comparators.

   o  The equality and substring algorithms exclude differences at level
      2 and 3 by default (thus it is case-insensitive and ignores
      accentual distinctions.

   o  The equality and substring algorithms use the "Whole Characters
      Only" feature described in UCAv9 section 8 by default.

   The exact comparator name with these defaults is
   "i;basic-uca=3.1.1-uv=3.2".  When a specification states that the
   basic comparator is mandatory-to-implement, only this specific name
   is mandatory-to-implement.

   In order to allow modification of the optional behaviors, the
   following ABNF is used for variations of the basic comparator:

     basic-comparator  =  ("i" / Language-Tag) ";basic" basic-modifiers
                          "-uca=3.1.1-uv=3.2" [";custom=" 1*comparator-char ]

     basic-modifiers   =  ["-2backwards"]
                          ["-blanked" / "-shifted" / "-shift-trimmed"]
                          ["-semi-stable"]
                          ["-quatlu"]
                          ["-match=accent" / "-match=case"]

   If multiple modifiers appear, they MUST appear in the order described
   above.  The modifiers have the following meanings:

   2backwards When this modifier is selected, the order of the second
      level sort keys is reversed.  This is useful for French
      customizations.

   blanked Use the "blanked" variable weighting option described in
      UCAv9 section 3.2.2 rather than the default "non-ignorable".

   shifted Use the "shifted" variable weighting option described in
      UCAv9 section 3.2.2. rather than the default "non-ignorable".

   shift-trimmed Use the "shift-trimmed" variable weighting option
      described in UCAv9 section 3.2.2. rather than the default
      "non-ignorable".






Newman                  Expires August 27, 2003                [Page 12]

Internet-Draft            Comparator Registry              February 2003


   semi-stable Use the "semi-stable" option.  This involves appending
      the input string to the end of the computed sort keys so that only
      two identical strings will produce a result of "0" from the order
      function.

   quatlu Use the 4th level weight from the allkeys file for the
      ordering function.

   match=accent Both the first and second levels of the sort keys are
      considered relevent to the equality and substring operations
      (rather than the default of first level only).  This makes the
      matching functions sensitive to accentual distinctions.

   match=case The first three levels of sort keys are considered
      relevent to the equality and substring operations.  This makes the
      matching functions sensitive to both case and accentual
      distinctions.

   Finally, the UCAv9 algorithm permits the "allkeys" table to be
   customized.  People who make a quality customizations are encouraged
   to register those customizations.  Customization names beginning with
   "x" are reserved for experimental use, are treated as "Limited use"
   and MUST NOT match wildcards if any registered comparator is
   available that does match.

7. IANA Considerations

7.1 Comparator Registration Procedure

   IANA will create a mailing list comparator@iana.org which can be used
   for public discussion of comparator proposals prior to registration.
   Use of the mailing list is encouraged but not required.  The actual
   registration procedure will not begin until the completed
   registration template is sent to iana@iana.org.  The IESG will
   appoint a designated expert who will monitor the comparator@iana.org
   mailing list and review registrations forwarded from IANA.  The
   designated expert is expected to tell IANA and the submittor of the
   registration within two weeks whether the registration is approved,
   approved with minor changes, or rejected with cause.  When a
   registration is rejected with cause, if it can be re-submitted if the
   concerns listed in the cause are addressed.  Decisions made by the
   designated expert can be appealed to the IESG and subsequently follow
   the normal appeals procedure for IESG decisions.

   Comparator registrations in a standards track, BCP or IESG-approved
   experimental RFC are owned by the IESG and changes to the
   registration follow normal procedures for updating such documents.
   Comparator registrations in other RFCs are owned by the RFC



Newman                  Expires August 27, 2003                [Page 13]

Internet-Draft            Comparator Registry              February 2003


   author(s).  Other comparator registrations are owned by the
   individual(s) listed in the contact field of the registration and
   IANA will perserve this information.  Changes to a registration MUST
   be approved by the owner.  In the event the owner can't be contacted
   for a period of one month and a change is deemed necessary, the IESG
   MAY re-assign ownership to an appropriate party (preferably from the
   same organization as the original owner).

7.2 Comparator Registration Template

   Comparator Name: {see comparator-wild syntax (Section 3)}

   Published Specification(s):

   Supported Functions: {one or more of "equality", "substring" and
   "order"}

   Scope: {"i18n", "Local", "Other"}

   Intended Use: {"Common", "Limited", "Vendor", "Deprecated"}

   Person and email address to contact for further information:

7.3 Octet Comparator Registration

   Comparator Name: i;octet

   Published Specification: RFC XXXX Section 6.1

   Supported Functions: equality, substring, order

   Scope: Other

   Intended Use: Common

   Person and email address to contact for further information:

   See the "Author's Address" section near the end of this
   specification.

7.4 ASCII Numeric Comparator Registration

   Comparator Name: i;ascii-numeric

   Published Specification: RFC XXXX Section 6.2

   Supported Functions: equality, order




Newman                  Expires August 27, 2003                [Page 14]

Internet-Draft            Comparator Registry              February 2003


   Scope: Other

   Intended Use: Limited

   Person and email address to contact for further information:

   See the "Author's Address" section near the end of this
   specification.

7.5 ASCII Casemap Comparator Registration

   Comparator Name: i;ascii-casemap

   Published Specification: RFC XXXX Section 6.3

   Supported Functions: equality, substring, order

   Scope: Local

   Intended Use: Deprecated

   Person and email address to contact for further information:

   See the "Author's Address" section near the end of this
   specification.

7.6 Nameprep Comparator Registration

   Comparator Name: i;nameprep-RFC=YYYY-uv=3.2

   Published Specification: RFC XXXX Section 6.4

   Supported Functions: equality, substring

   Scope: i18n

   Intended Use: Common

   Person and email address to contact for further information:

   See the "Author's Address" section near the end of this
   specification.

7.7 Basic Comparator Registration

   Comparator Name: i;basic-*uca=3.1.1-uv=3.2

   Published Specification: RFC XXXX Section 6.5



Newman                  Expires August 27, 2003                [Page 15]

Internet-Draft            Comparator Registry              February 2003


   Supported Functions: equality, substring, order

   Scope: i18n

   Intended Use: Common

   Person and email address to contact for further information:

   See the "Author's Address" section near the end of this
   specification.

7.8 Structure of Comparator Registry

   The comparator registry itself is divided into four sections.  The
   first section is for comparators intended for common use.  This
   section is intended for comparator registrations published in IESG
   approved RFCs or for locally scoped comparators from the primary
   standards body for that locale.  The designated expert is encouraged
   to reject a comparator registrations with an intended use of "common"
   if the expert believes it should be "limited", as it is desirable to
   keep the number of "common" registrations small and high quality.
   The second section is reserved for limited use comparators.  The
   third section is reserved for registered vendor specific comparators.
   The final section is reserved for depreated comparators.



























Newman                  Expires August 27, 2003                [Page 16]

Internet-Draft            Comparator Registry              February 2003


7.9 Example Initial Registry

   The following is an example of how IANA might structure the initial
   registry:

     Comparator                        Functions Scope Reference
     ----------                        --------- ----- ---------
   Common Use Comparators:
     i;octet                           e, s, o   Other [RFC XXXX]
     i;nameprep-rfc=YYYY-uv=3.2        e, s      i18n  [RFC XXXX]
     i;basic-*uca=3.1.1-uv=3.1.1       e, s, o   i18n  [RFC XXXX]

   Limited Use Comparators:
     i;ascii-numeric                   e, o      Other [RFC XXXX]

   Vendor Comparators:

   Deprecated Comparators:
     i;ascii-casemap                   e, s, o   Local [RFC XXXX]


   References
   ----------
   [RFC XXXX]  Newman, C., "Internet Application Protocol Comparator
               Registry", RFC XXXX, Sun Microsystems, February 2003.


8. Security Considerations

   Comparators will normally be used with UTF-8 strings.  Thus the
   security considerations for UTF-8 [3] and stringprep [5] also apply
   and are normative to this specification.

Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [2]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
        Specifications: ABNF", RFC 2234, November 1997.

   [3]  Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
        2279, January 1998.

   [4]  Alvestrand, H., "Tags for the Identification of Languages", BCP
        47, RFC 3066, January 2001.

   [5]  Hoffman, P. and M. Blanchet, "Preparation of Internationalized



Newman                  Expires August 27, 2003                [Page 17]

Internet-Draft            Comparator Registry              February 2003


        Strings ("stringprep")", RFC 3454, December 2002.

   [6]  Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile for
        Internationalized Domain Names", draft-ietf-idn-nameprep-11
        (work in progress), June 2002.

   [7]  Davis, M. and K. Whistler, "Unicode Collation Algorithm version
        9", July 2002, <http://www.unicode.org/reports/tr10/
        tr10-9.html>.

Informative References

   [8]   Freed, N. and N. Borenstein, "Multipurpose Internet Mail
         Extensions (MIME) Part One: Format of Internet Message Bodies",
         RFC 2045, November 1996.

   [9]   Freed, N. and N. Borenstein, "Multipurpose Internet Mail
         Extensions (MIME) Part Two: Media Types", RFC 2046, November
         1996.

   [10]  Myers, J., "Simple Authentication and Security Layer (SASL)",
         RFC 2222, October 1997.

   [11]  Newman, C. and J. Myers, "ACAP -- Application Configuration
         Access Protocol", RFC 2244, November 1997.

   [12]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
         Considerations Section in RFCs", BCP 26, RFC 2434, October
         1998.

   [13]  Resnick, P., "Internet Message Format", RFC 2822, April 2001.

   [14]  Freed, N. and J. Postel, "IANA Charset Registration
         Procedures", BCP 19, RFC 2978, October 2000.

   [15]  Showalter, T., "Sieve: A Mail Filtering Language", RFC 3028,
         January 2001.

URIs

   [16]  <http://www.unicode.org/Public/3.2-Update/
         UnicodeData-3.2.0.txt>

   [17]  <http://www.unicode.org/Public/3.2-Update/PropList-3.2.0.txt>

   [18]  <http://www.unicode.org/reports/tr10/allkeys-3.1.1.txt>





Newman                  Expires August 27, 2003                [Page 18]

Internet-Draft            Comparator Registry              February 2003


Author's Address

   Chris Newman
   Sun Microsystems
   1050 Lakes Drive
   West Covina, CA  91790
   US

   EMail: chris.newman@sun.com

Appendix A. Use by ACAP and Sieve

   Both ACAP [11] and Sieve [15] are standards track protocols which
   used comparators prior to the creation of this specification.  Those
   standards do not meet all the application protocol requirements
   described in section Section 5.  It is expected that if ACAP is
   revised, the basic comparator will be mandatory to implement, and if
   Sieve is revised, the nameprep comparator will be mandatory to
   implement.

Appendix B. Guidelines for Expert Reviewer

   The expert reviewer appointed by the IESG has fairly broad lattitude
   for this registry.  While a number of comparators are expected
   particularly customizations of the basic comparator for localized
   use, an explosion of comparators (particularly common use
   comparators) is not desirable for widespread interoperability.
   However, it is important for the expert reviewer to provide cause
   when rejecting a registration, and when possible to describe
   corrective action to permit the registration to proceed.  The
   following table includes some possible reasons to reject a
   registration with cause:

   o  The registration has intended use of "common", but there is no
      evidence the comparator will be widely deployed so it should be
      listed as "limited".

   o  The registration has intended use of "common", but is redundant
      with the functionality of a previously registered "common"
      comparator.

   o  The comparator name fails to precisely identify the version
      numbers of relevant tables to use.

   o  The registration fails to meet one of the "MUST" requirements in
      section Section 4.

   o  The comparator name fails to meet the syntax in Section 3.



Newman                  Expires August 27, 2003                [Page 19]

Internet-Draft            Comparator Registry              February 2003


   o  The comparator specification referenced in the registration is
      vague or has optional features without a clear behavior specified.

   o  The referenced specification does not adequately address security
      considerations specific to that comparator.


Appendix C. RFC Editor Directions

   Please replace all occurances of "XXXX" with the assigned RFC number
   for this specification.  Please replace all occurances of "YYYY" with
   the assigned RFC number for the nameprep [6] FIXME specification.

Appendix D. Open Issues

   1.  Should we permit non-ASCII characters in the comparator name?
       The benefit of allowing non-ASCII characters in the comparator
       name is it would make presenting comparators to an end-user
       simple, particularly if comparator names were structured to
       include a user-friendly name as part of the conventional
       structure.  However, because there are other solutions to the
       problem of user friendly selection of a comparator which would
       add less complexity to the common case, the author has errored on
       the side of simplicity.  As long as the set of common use
       comparators (excluding versions) is relatively small, user
       friendly names can be part of the client (ideally admin
       configuration for the client).  If the registry becomes large,
       then a lookup service could be used to translate a comparator
       name into a user-friendly name.

   2.  Is any Nameprep processing appropriate for the basic comparator?
       Because a result of "0" from an ordering algorithm is
       undesirable, much of the nameprep processing is inappropriate.
       Furthermore, a result of "error" which is important for nameprep
       is generally inappropriate as an internal result in an ordering
       algorithm since it makes the results less intuitive.  The sort
       key table also eliminates most problematic characters from
       consideration if the appropriate comparator modifier is used.
       Finally, exact compatibility with the Unicode Collation Algorithm
       is deemed desirable by the author, as even the smallest variation
       may require implementation of largely duplicate code.  However,
       this decision is outside my expertise, so I welcome alternate
       viewpoints.

   3.  The ICU implementation of the UCA algorithm includes additional
       algorithmic customizations such as the ability to be
       case-sensitive while at the same time being insensitive to
       accents.  Should these customizations be added to this



Newman                  Expires August 27, 2003                [Page 20]

Internet-Draft            Comparator Registry              February 2003


       specification?

   4.  Should a format for customization data for the basic comparator
       be defined so that disconnected clients might have the option of
       downloading that information.














































Newman                  Expires August 27, 2003                [Page 21]

Internet-Draft            Comparator Registry              February 2003


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive
   Director.


Full Copyright Statement

   Copyright (C) The Internet Society (2003). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION



Newman                  Expires August 27, 2003                [Page 22]

Internet-Draft            Comparator Registry              February 2003


   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.











































Newman                  Expires August 27, 2003                [Page 23]


--Boundary_(ID_I25bkmf4RDmU78k34DhkmQ)--


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1OJuH925509 for ietf-imapext-bks; Mon, 24 Feb 2003 11:56:17 -0800 (PST)
Received: from eagle.oceana.com ([208.17.123.12]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1OJuGd25505 for <ietf-imapext@imc.org>; Mon, 24 Feb 2003 11:56:16 -0800 (PST)
Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.7/8.12.7) with ESMTP id h1OJtfms007220; Mon, 24 Feb 2003 14:55:41 -0500
Message-ID: <3E5A7945.20166E02@oceana.com>
Date: Mon, 24 Feb 2003 14:57:57 -0500
From: Ken Murchison <ken@oceana.com>
Organization: Oceana Matrix Ltd.
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Cyrus Daboo <daboo@cyrusoft.com>
CC: Barry Leiba <leiba@watson.ibm.com>, IMAP extensions Mailing List <ietf-imapext@imc.org>
Subject: Re: I-D ACTION:draft-ietf-imapext-list-extensions-03.txt
References: <200302241146.GAA09097@ietf.org>	 <1046094255.788.81.camel@hurina>	 <020d01c2dc14$9eb9f980$40280209@watson.ibm.com> <2147483647.1046084494@[63.163.82.24]> <3E5A680A.DCE57D65@oceana.com> <2147483647.1046096120@[63.163.82.24]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

Cyrus Daboo wrote:
> 
> Hi Ken,
> 
> --On Monday, February 24, 2003 1:44 PM -0500 Ken Murchison <ken@oceana.com>
> wrote:
> 
> |> Leave it as it is. Future list option extensions (if there are any) can
> |> simply extend the option syntax for their own set of options and
> |> advertise that via CAPABILITY. However, I think the following statement
> |> in the first paragrph of Section 4:
> |
> | Correct me if I'm wrong, but if we don't state up front that an option
> | may be a sublist, won't parsers based on the current grammar fail on the
> | example above?  If I'm just looking for atoms, neither "(NAME" nor
> | "DATE)" are valid, so we'll always get a BAD response.
> 
> Each option can only be legitimately used if advertised by the server. So
> if there were a LISTEXT-SORT extension and that defined a 'SORT' option
> that had an argument that was a parenthesized list then both the server and
> client would know how to deal with that along with all the other options.

Understood.  But in your original message, you suggested returning a NO
when the option isn't recognized by the server (presumably when a client
tries to use an option not advertised by the server -- how else would it
be unrecognized).  I don't care whether we return NO or BAD in this
case, but I just wanted to point out that there might be a difference
between unrecognized and unparsable.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1OJFUX24033 for ietf-imapext-bks; Mon, 24 Feb 2003 11:15:30 -0800 (PST)
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1OJFTd24024 for <ietf-imapext@imc.org>; Mon, 24 Feb 2003 11:15:29 -0800 (PST)
Received: from [63.163.82.24] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id OAA19920; Mon, 24 Feb 2003 14:12:04 -0500 (EST)
Date: Mon, 24 Feb 2003 14:15:20 -0500
From: Cyrus Daboo <daboo@cyrusoft.com>
To: Ken Murchison <ken@oceana.com>
cc: Barry Leiba <leiba@watson.ibm.com>, IMAP extensions Mailing List <ietf-imapext@imc.org>
Subject: Re: I-D ACTION:draft-ietf-imapext-list-extensions-03.txt
Message-ID: <2147483647.1046096120@[63.163.82.24]>
In-Reply-To: <3E5A680A.DCE57D65@oceana.com>
References: <200302241146.GAA09097@ietf.org>	 <1046094255.788.81.camel@hurina>	 <020d01c2dc14$9eb9f980$40280209@watson.ibm.com> <2147483647.1046084494@[63.163.82.24]> <3E5A680A.DCE57D65@oceana.com>
X-Mailer: Mulberry/3.0.2 (Mac OS/PPC)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

Hi Ken,

--On Monday, February 24, 2003 1:44 PM -0500 Ken Murchison <ken@oceana.com> 
wrote:

|> Leave it as it is. Future list option extensions (if there are any) can
|> simply extend the option syntax for their own set of options and
|> advertise that via CAPABILITY. However, I think the following statement
|> in the first paragrph of Section 4:
|
| Correct me if I'm wrong, but if we don't state up front that an option
| may be a sublist, won't parsers based on the current grammar fail on the
| example above?  If I'm just looking for atoms, neither "(NAME" nor
| "DATE)" are valid, so we'll always get a BAD response.

Each option can only be legitimately used if advertised by the server. So 
if there were a LISTEXT-SORT extension and that defined a 'SORT' option 
that had an argument that was a parenthesized list then both the server and 
client would know how to deal with that along with all the other options. 
There are some things to be aware of. In particular it should probably be 
stated that if future listext options require arguments, they should be 
placed in a parenthesized list to ensure they won't get confused with other 
options. Barry could probably express that in the formal grammar.

-- 
Cyrus Daboo


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1OIgpM20601 for ietf-imapext-bks; Mon, 24 Feb 2003 10:42:51 -0800 (PST)
Received: from eagle.oceana.com ([208.17.123.12]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1OIgnd20595 for <ietf-imapext@imc.org>; Mon, 24 Feb 2003 10:42:50 -0800 (PST)
Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.7/8.12.7) with ESMTP id h1OIgAms005946; Mon, 24 Feb 2003 13:42:11 -0500
Message-ID: <3E5A680A.DCE57D65@oceana.com>
Date: Mon, 24 Feb 2003 13:44:26 -0500
From: Ken Murchison <ken@oceana.com>
Organization: Oceana Matrix Ltd.
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Cyrus Daboo <daboo@cyrusoft.com>
CC: Barry Leiba <leiba@watson.ibm.com>, IMAP extensions Mailing List <ietf-imapext@imc.org>
Subject: Re: I-D ACTION:draft-ietf-imapext-list-extensions-03.txt
References: <200302241146.GAA09097@ietf.org> <1046094255.788.81.camel@hurina> <020d01c2dc14$9eb9f980$40280209@watson.ibm.com> <2147483647.1046084494@[63.163.82.24]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

Cyrus Daboo wrote:
> 
> Hi Barry,
> 
> --On Monday, February 24, 2003 9:54 AM -0500 Barry Leiba
> <leiba@watson.ibm.com> wrote:
> 
> |> Should list-options support more than just atoms list? I'm thinking of
> |> some extra options that the atoms might have. For example:
> |> LIST (SORT (NAME DATE)) "" %
> |
> | Hm, maybe.  Anyone else have thoughts on this?  We discussed this sort of
> | thing when we first started formulating LIST extensions, and we decided to
> | keep it simple... but this sort of thing might still be sufficiently
> | simple. Should we allow it?
> 
> Leave it as it is. Future list option extensions (if there are any) can
> simply extend the option syntax for their own set of options and advertise
> that via CAPABILITY. However, I think the following statement in the first
> paragrph of Section 4:

Correct me if I'm wrong, but if we don't state up front that an option
may be a sublist, won't parsers based on the current grammar fail on the
example above?  If I'm just looking for atoms, neither "(NAME" nor
"DATE)" are valid, so we'll always get a BAD response.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1OHrUg17466 for ietf-imapext-bks; Mon, 24 Feb 2003 09:53:30 -0800 (PST)
Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1OHrSd17462 for <ietf-imapext@imc.org>; Mon, 24 Feb 2003 09:53:28 -0800 (PST)
Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [9.2.112.57]) by igw2.watson.ibm.com (8.11.4/8.11.4) with ESMTP id h1OHrNj29764 for <ietf-imapext@imc.org>; Mon, 24 Feb 2003 12:53:24 -0500
Received: from mars.watson.ibm.com (mars.watson.ibm.com [9.2.40.64]) by sp1n293en1.watson.ibm.com (8.11.4/8.11.4) with ESMTP id h1OHrNV53470 for <ietf-imapext@imc.org>; Mon, 24 Feb 2003 12:53:23 -0500
Date: Mon, 24 Feb 2003 12:53:23 -0500
From: Barry Leiba <leiba@watson.ibm.com>
To: IMAP extensions Mailing List <ietf-imapext@imc.org>
Subject: Re: I-D ACTION:draft-ietf-imapext-list-extensions-03.txt
Message-ID: <879056031.1046091203@mars.watson.ibm.com>
In-Reply-To: <1046108039.785.124.camel@hurina>
References: <200302241146.GAA09097@ietf.org>	 <1046094255.788.81.camel@hurina>	 <020d01c2dc14$9eb9f980$40280209@watson.ibm.com>	 <2147483647.1046084494@[63.163.82.24]> <1046108039.785.124.camel@hurina>
X-Mailer: Mulberry/3.0.0 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

> Another thing. If I have a mailbox named "foo.bar" with "." as
> hierarchy separator, but there's no "foo" mailbox, should LIST () ""
> % return \PlaceHolder or \Noselect for it?

"\noselect".  "\placeholder" means that it doesn't match the selection 
criteria but has a child that does, and both of those conditions are 
false (that is, it *does* match, and its children do NOT).

What's really happening here is that *logically* (if not physically, 
and remember that what IMAP is really doing is taking a physical mail 
store and exposing a logical view of it) there *is* a mailbox called 
"foo" that is not selectable (it's not selectable because it doesn't 
*physically* exist).  That's exactly what "\noselect" is there for.

Barry

--
Barry Leiba, Internet Messaging Technology  (leiba@watson.ibm.com)
http://www.research.ibm.com/people/l/leiba



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1OHqdR17433 for ietf-imapext-bks; Mon, 24 Feb 2003 09:52:39 -0800 (PST)
Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1OHqcd17429 for <ietf-imapext@imc.org>; Mon, 24 Feb 2003 09:52:38 -0800 (PST)
Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout2.cac.washington.edu (8.12.1+UW01.12/8.12.1+UW02.12) with ESMTP id h1OHq1GD029122; Mon, 24 Feb 2003 09:52:06 -0800
Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by smtp.washington.edu (8.12.1+UW01.12/8.12.1+UW02.12) with ESMTP id h1OHq1Fl028007 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 24 Feb 2003 09:52:01 -0800
Date: Mon, 24 Feb 2003 09:52:00 -0800 (PST)
From: Mark Crispin <mrc@cac.washington.edu>
To: Timo Sirainen <tss@iki.fi>
cc: Cyrus Daboo <daboo@cyrusoft.com>, Barry Leiba <leiba@watson.ibm.com>, IMAP extensions Mailing List <ietf-imapext@imc.org>
Subject: Re: I-D ACTION:draft-ietf-imapext-list-extensions-03.txt
In-Reply-To: <1046108039.785.124.camel@hurina>
Message-ID: <Pine.LNX.4.55.0302240950260.10564@shiva0.cac.washington.edu>
References: <200302241146.GAA09097@ietf.org>  <1046094255.788.81.camel@hurina> <020d01c2dc14$9eb9f980$40280209@watson.ibm.com>  <2147483647.1046084494@[63.163.82.24]> <1046108039.785.124.camel@hurina>
Organization: Networks and Distributed Computing
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

On Mon, 24 Feb 2003, Timo Sirainen wrote:
> > 'A server MUST respond to unrecognized options with a NO response.'
> Shouldn't it be BAD response?

It depends.

If the client has a way of knowing in advance that the option will not be
recognized, then BAD would the proper response.

If, on the other hand, the only way for the client to know is to try,
*and* if the grammar has a rule indicating arbitrary atom as an option
name (for future expansion), then NO is proper.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1OHY0H15818 for ietf-imapext-bks; Mon, 24 Feb 2003 09:34:00 -0800 (PST)
Received: from oma.irssi.org (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1OHXwd15810 for <ietf-imapext@imc.org>; Mon, 24 Feb 2003 09:33:58 -0800 (PST)
Received: by oma.irssi.org (Postfix, from userid 1000) id BED245E01F94; Mon, 24 Feb 2003 19:33:59 +0200 (EET)
Subject: Re: I-D ACTION:draft-ietf-imapext-list-extensions-03.txt
From: Timo Sirainen <tss@iki.fi>
To: Cyrus Daboo <daboo@cyrusoft.com>
Cc: Barry Leiba <leiba@watson.ibm.com>, IMAP extensions Mailing List <ietf-imapext@imc.org>
In-Reply-To: <2147483647.1046084494@[63.163.82.24]>
References: <200302241146.GAA09097@ietf.org> <1046094255.788.81.camel@hurina> <020d01c2dc14$9eb9f980$40280209@watson.ibm.com> <2147483647.1046084494@[63.163.82.24]>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: 
Message-Id: <1046108039.785.124.camel@hurina>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 
Date: 24 Feb 2003 19:33:59 +0200
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

On Mon, 2003-02-24 at 18:01, Cyrus Daboo wrote:
> Leave it as it is. Future list option extensions (if there are any) can 
> simply extend the option syntax for their own set of options and advertise 
> that via CAPABILITY.

Right, that's better.

> 'A server MUST respond to unrecognized options with a NO response.'

Shouldn't it be BAD response?

Another thing. If I have a mailbox named "foo.bar" with "." as hierarchy
separator, but there's no "foo" mailbox, should LIST () "" % return
\PlaceHolder or \Noselect for it?



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1OGRNY13559 for ietf-imapext-bks; Mon, 24 Feb 2003 08:27:23 -0800 (PST)
Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1OGRMd13555 for <ietf-imapext@imc.org>; Mon, 24 Feb 2003 08:27:22 -0800 (PST)
Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [9.2.112.57]) by igw2.watson.ibm.com (8.11.4/8.11.4) with ESMTP id h1OGRIj82026 for <ietf-imapext@imc.org>; Mon, 24 Feb 2003 11:27:18 -0500
Received: from mars.watson.ibm.com (mars.watson.ibm.com [9.2.40.64]) by sp1n293en1.watson.ibm.com (8.11.4/8.11.4) with ESMTP id h1OGRIV51700 for <ietf-imapext@imc.org>; Mon, 24 Feb 2003 11:27:18 -0500
Date: Mon, 24 Feb 2003 11:27:18 -0500
From: Barry Leiba <leiba@watson.ibm.com>
To: IMAP extensions Mailing List <ietf-imapext@imc.org>
Subject: Re: I-D ACTION:draft-ietf-imapext-list-extensions-03.txt
Message-ID: <873890515.1046086038@mars.watson.ibm.com>
In-Reply-To: <2147483647.1046084494@[63.163.82.24]>
References: <200302241146.GAA09097@ietf.org> <1046094255.788.81.camel@hurina> <020d01c2dc14$9eb9f980$40280209@watson.ibm.com> <2147483647.1046084494@[63.163.82.24]>
X-Mailer: Mulberry/3.0.0 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

> Leave it as it is. Future list option extensions (if there are any)
> can simply extend the option syntax for their own set of options

Good point -- there's nothing that says that another extension can't 
change the syntax further.  OTOH, there's something to be said for 
having a flexible syntax from the start.

> 'A server MAY ignore options it does not recognize.'
>
> should be changed to:
>
> 'A server MUST respond to unrecognized options with a NO response.'
>
> That will ensure that accidental attempts by clients to use 'compound
> options' won't trigger a legitimate option if there happens to be an
> overlap between a compound option argument and a legitimate option.
> Besides I think its better to always return a NO when something is
> not recognized in a command sent by the client - that helps dumb
> client developers like me debug their implementations more easily!

I'm certainly happy to change that... I used the "MAY" wording to allow 
servers to be flexible.  Do others also prefer that clients that don't 
pay attention to CAPABILITY responses have their hands slapped?

Barry

--
Barry Leiba, Internet Messaging Technology  (leiba@watson.ibm.com)
http://www.research.ibm.com/people/l/leiba



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1OGOkk13487 for ietf-imapext-bks; Mon, 24 Feb 2003 08:24:46 -0800 (PST)
Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1OGOid13481 for <ietf-imapext@imc.org>; Mon, 24 Feb 2003 08:24:44 -0800 (PST)
Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [9.2.112.57]) by igw2.watson.ibm.com (8.11.4/8.11.4) with ESMTP id h1OGOej29940 for <ietf-imapext@imc.org>; Mon, 24 Feb 2003 11:24:40 -0500
Received: from mars.watson.ibm.com (mars.watson.ibm.com [9.2.40.64]) by sp1n293en1.watson.ibm.com (8.11.4/8.11.4) with ESMTP id h1OGOeV63650 for <ietf-imapext@imc.org>; Mon, 24 Feb 2003 11:24:40 -0500
Date: Mon, 24 Feb 2003 11:24:40 -0500
From: Barry Leiba <leiba@watson.ibm.com>
To: IMAP extensions Mailing List <ietf-imapext@imc.org>
Subject: Re: I-D ACTION:draft-ietf-imapext-list-extensions-03.txt
Message-ID: <873732906.1046085880@mars.watson.ibm.com>
In-Reply-To: <1046103597.787.111.camel@hurina>
References: <200302241146.GAA09097@ietf.org>	 <1046094255.788.81.camel@hurina>	 <020d01c2dc14$9eb9f980$40280209@watson.ibm.com> <1046103597.787.111.camel@hurina>
X-Mailer: Mulberry/3.0.0 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

> After update I see it in my mailbox and get reminded of it's
> existence. I guess I should read all of the drafts carefully through
> some day.

:-)

> You mean things like ACLs that would make existing mailboxes
> non-selectable? Does the difference matter to any clients?

Exactly, or mailboxes that may contain other mailboxes but not mail 
messages.  I don't know whether the difference matters to existing 
clients, but I think (and the consensus of the group was) that the 
server should make the distinction.  A client might display "\noselect" 
mailboxes as anchor points for expansion in the GUI.  A client might 
choose not to display "\nonexistent" mailboxes, or may show them in 
another way that makes it clear that they may be "old" subscriptions, 
and gives the user a chance to unsubscribe (or not, as appropriate).

Barry

--
Barry Leiba, Internet Messaging Technology  (leiba@watson.ibm.com)
http://www.research.ibm.com/people/l/leiba



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1OGJx613265 for ietf-imapext-bks; Mon, 24 Feb 2003 08:19:59 -0800 (PST)
Received: from oma.irssi.org (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1OGJvd13261 for <ietf-imapext@imc.org>; Mon, 24 Feb 2003 08:19:57 -0800 (PST)
Received: by oma.irssi.org (Postfix, from userid 1000) id 033445E01F94; Mon, 24 Feb 2003 18:19:58 +0200 (EET)
Subject: Re: I-D ACTION:draft-ietf-imapext-list-extensions-03.txt
From: Timo Sirainen <tss@iki.fi>
To: Barry Leiba <leiba@watson.ibm.com>
Cc: IMAP extensions Mailing List <ietf-imapext@imc.org>
In-Reply-To: <020d01c2dc14$9eb9f980$40280209@watson.ibm.com>
References: <200302241146.GAA09097@ietf.org> <1046094255.788.81.camel@hurina> <020d01c2dc14$9eb9f980$40280209@watson.ibm.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: 
Message-Id: <1046103597.787.111.camel@hurina>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 
Date: 24 Feb 2003 18:19:57 +0200
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

On Mon, 2003-02-24 at 16:54, Barry Leiba wrote:
> Ah, I'll never figure out why we don't get these comments until *after* we
> post the updated version, ya know?  Grumble, grumble....

After update I see it in my mailbox and get reminded of it's existence.
I guess I should read all of the drafts carefully through some day.

> "\Noselect" means that the mailbox exists but mayn't be SELECTed; there
> may be an assortment of reasons for this.  "\NonExistent" means that the
> mailbox doesn't exist, but a subscription to it remains.  What part of
> that distinction don't you understand, and I'll try to explain it more.

You mean things like ACLs that would make existing mailboxes
non-selectable? Does the difference matter to any clients?

> > LIST (SORT (NAME DATE)) "" %
> Hm, maybe.  Anyone else have thoughts on this?  We discussed this sort of
> thing when we first started formulating LIST extensions, and we decided to
> keep it simple... but this sort of thing might still be sufficiently simple.
> Should we allow it?

I think that still keeps it simple and doesn't require yet another
listext2 extension when first extension that wants something similiar
comes.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1OG1bT12734 for ietf-imapext-bks; Mon, 24 Feb 2003 08:01:37 -0800 (PST)
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1OG1ad12730 for <ietf-imapext@imc.org>; Mon, 24 Feb 2003 08:01:36 -0800 (PST)
Received: from [63.163.82.24] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id KAA11640; Mon, 24 Feb 2003 10:58:16 -0500 (EST)
Date: Mon, 24 Feb 2003 11:01:34 -0500
From: Cyrus Daboo <daboo@cyrusoft.com>
To: Barry Leiba <leiba@watson.ibm.com>, IMAP extensions Mailing List <ietf-imapext@imc.org>
Subject: Re: I-D ACTION:draft-ietf-imapext-list-extensions-03.txt
Message-ID: <2147483647.1046084494@[63.163.82.24]>
In-Reply-To: <020d01c2dc14$9eb9f980$40280209@watson.ibm.com>
References: <200302241146.GAA09097@ietf.org> <1046094255.788.81.camel@hurina> <020d01c2dc14$9eb9f980$40280209@watson.ibm.com>
X-Mailer: Mulberry/3.0.2 (Mac OS/PPC)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

Hi Barry,

--On Monday, February 24, 2003 9:54 AM -0500 Barry Leiba 
<leiba@watson.ibm.com> wrote:

|> Should list-options support more than just atoms list? I'm thinking of
|> some extra options that the atoms might have. For example:
|> LIST (SORT (NAME DATE)) "" %
|
| Hm, maybe.  Anyone else have thoughts on this?  We discussed this sort of
| thing when we first started formulating LIST extensions, and we decided to
| keep it simple... but this sort of thing might still be sufficiently
| simple. Should we allow it?

Leave it as it is. Future list option extensions (if there are any) can 
simply extend the option syntax for their own set of options and advertise 
that via CAPABILITY. However, I think the following statement in the first 
paragrph of Section 4:

'A server MAY ignore options it does not recognize.'

should be changed to:

'A server MUST respond to unrecognized options with a NO response.'

That will ensure that accidental attempts by clients to use 'compound 
options' won't trigger a legitimate option if there happens to be an 
overlap between a compound option argument and a legitimate option. Besides 
I think its better to always return a NO when something is not recognized 
in a command sent by the client - that helps dumb client developers like me 
debug their implementations more easily!

-- 
Cyrus Daboo


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1OEsTG07518 for ietf-imapext-bks; Mon, 24 Feb 2003 06:54:29 -0800 (PST)
Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1OEsSd07513 for <ietf-imapext@imc.org>; Mon, 24 Feb 2003 06:54:28 -0800 (PST)
Received: from sp1n294en1.watson.ibm.com (sp1n294en1.watson.ibm.com [9.2.112.58]) by igw2.watson.ibm.com (8.11.4/8.11.4) with ESMTP id h1OEsOj87660 for <ietf-imapext@imc.org>; Mon, 24 Feb 2003 09:54:24 -0500
Received: from mars (mars.watson.ibm.com [9.2.40.64]) by sp1n294en1.watson.ibm.com (8.11.4/8.11.4) with SMTP id h1OEsOi43434 for <ietf-imapext@imc.org>; Mon, 24 Feb 2003 09:54:24 -0500
Message-ID: <020d01c2dc14$9eb9f980$40280209@watson.ibm.com>
From: "Barry Leiba" <leiba@watson.ibm.com>
To: "IMAP extensions Mailing List" <ietf-imapext@imc.org>
References: <200302241146.GAA09097@ietf.org> <1046094255.788.81.camel@hurina>
Subject: Re: I-D ACTION:draft-ietf-imapext-list-extensions-03.txt
Date: Mon, 24 Feb 2003 09:54:23 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

Ah, I'll never figure out why we don't get these comments until *after* we
post the updated version, ya know?  Grumble, grumble....

> Looks like it's moved into 3348 nowadays. 3328 doesn't exist.

Yeah, that's a typo; I'll fix it.  Thanks.

> Why is LIST-SUBSCRIBED optional? Doesn't seem to be much of a job to
> implement.

It's optional because if you implement "subscribe" the way Mark intends
it, as a separate list that's not related to the actual mailbox store,
then it can be expensive to go through the list and then, for each entry,
go over to the actual mailboxes and get the required info.  I strongly
recommend implementing it because a client that wants it will get it by
using a combination of LSUB and LIST anyway, as now, but a server
implementer might want to leave LSUB and LIST separated.

Whether it's "much of a job to implement" depends upon the server and
the mail store and the subscription model, all put together.

> What's the difference between \Noselect and \NonExistent? Just so that
> clients wouldn't confuse \Noselect with old behaviour? Doesn't seem
> worth it.

"\Noselect" means that the mailbox exists but mayn't be SELECTed; there
may be an assortment of reasons for this.  "\NonExistent" means that the
mailbox doesn't exist, but a subscription to it remains.  What part of
that distinction don't you understand, and I'll try to explain it more.

> Should list-options support more than just atoms list? I'm thinking of
> some extra options that the atoms might have. For example:
> LIST (SORT (NAME DATE)) "" %

Hm, maybe.  Anyone else have thoughts on this?  We discussed this sort of
thing when we first started formulating LIST extensions, and we decided to
keep it simple... but this sort of thing might still be sufficiently simple.
Should we allow it?

> How about replacing ACL2's MYRIGHTS with LIST (MYRIGHTS)? I think
> clients would want to get their ACL rights more than one at a time, and
> this way looks pretty nice to me.

At the last IETF we decided that after the LISText draft was solid, we'd
look at how ACL and Annotate and AnnotateMore fit in, and what bits of
those commands should be done with LIST options instead.  So that will
follow this.

Barry
--
Barry Leiba, Internet Messaging Technology  (leiba@watson.ibm.com)
http://www.research.ibm.com/people/l/leiba


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1ODiMr03997 for ietf-imapext-bks; Mon, 24 Feb 2003 05:44:22 -0800 (PST)
Received: from oma.irssi.org (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1ODiKd03993 for <ietf-imapext@imc.org>; Mon, 24 Feb 2003 05:44:20 -0800 (PST)
Received: by oma.irssi.org (Postfix, from userid 1000) id 344AE5E01F94; Mon, 24 Feb 2003 15:44:15 +0200 (EET)
Subject: Re: I-D ACTION:draft-ietf-imapext-list-extensions-03.txt
From: Timo Sirainen <tss@iki.fi>
To: ietf-imapext@imc.org
In-Reply-To: <200302241146.GAA09097@ietf.org>
References: <200302241146.GAA09097@ietf.org>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: 
Message-Id: <1046094255.788.81.camel@hurina>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 
Date: 24 Feb 2003 15:44:15 +0200
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

"We are also defining the mechanism to request extended mailbox
information, such as is described in the now-expired "Child Mailbox
Extension" draft [ChildMbox]."

"[ChildMbox]; Gahrns, M. & Cheng, R.; "IMAP4 Child Mailbox Extension";
RFC 3328; Microsoft Corporation; July 2002."

Looks like it's moved into 3348 nowadays. 3328 doesn't exist.

Why is LIST-SUBSCRIBED optional? Doesn't seem to be much of a job to
implement.

What's the difference between \Noselect and \NonExistent? Just so that
clients wouldn't confuse \Noselect with old behaviour? Doesn't seem
worth it.

Should list-options support more than just atoms list? I'm thinking of
some extra options that the atoms might have. For example:
LIST (SORT (NAME DATE)) "" %

How about replacing ACL2's MYRIGHTS with LIST (MYRIGHTS)? I think
clients would want to get their ACL rights more than one at a time, and
this way looks pretty nice to me.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1OBoIS01362 for ietf-imapext-bks; Mon, 24 Feb 2003 03:50:18 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1OBoHd01358 for <ietf-imapext@imc.org>; Mon, 24 Feb 2003 03:50:17 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09097; Mon, 24 Feb 2003 06:46:24 -0500 (EST)
Message-Id: <200302241146.GAA09097@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ietf-imapext@imc.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-imapext-list-extensions-03.txt
Date: Mon, 24 Feb 2003 06:46:24 -0500
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF.

	Title		: IMAP4 LIST Command Extensions
	Author(s)	: B. Leiba
	Filename	: draft-ietf-imapext-list-extensions-03.txt
	Pages		: 8
	Date		: 2003-2-21
	
IMAP4 has two commands for listing mailboxes: LIST and LSUB.  As we
have added extensions that have required specialized lists (see
[MboxRefer] for an example) we have had to expand the number of list
commands, since each extension must add its function to both LIST and
LSUB, and these commands are not, as they are defined, extensible.
If we've needed the extensions to work together, we've had to add a
set of commands to mix the different options, the set increasing in
size with each new extension.  This document describes an extension
to the base LIST command that will allow these additions to be done
with mutually compatible options to the LIST command, avoiding the
exponential increase in specialized list commands.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-imapext-list-extensions-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-imapext-list-extensions-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-imapext-list-extensions-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-2-21161251.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-imapext-list-extensions-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-imapext-list-extensions-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-2-21161251.I-D@ietf.org>

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1JM3JS11532 for ietf-imapext-bks; Wed, 19 Feb 2003 14:03:19 -0800 (PST)
Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1JM3Hd11528 for <ietf-imapext@imc.org>; Wed, 19 Feb 2003 14:03:18 -0800 (PST)
Received: from GOBO-6NET.andrew.cmu.edu (GOBO-6NET.andrew.cmu.edu [128.2.6.104]) (user=rjs3 mech=KERBEROS_V4 (0 bits)) by lin1.andrew.cmu.edu (8.12.7.Beta1/8.12.3.Beta2) with ESMTP id h1JM3E0V001052; Wed, 19 Feb 2003 17:03:14 -0500
Date: Wed, 19 Feb 2003 17:03:15 -0500 (EST)
From: Rob Siemborski <rjs3@andrew.cmu.edu>
To: Mark Crispin <MRC@cac.washington.edu>
cc: Timo Sirainen <tss@iki.fi>, ietf-imapext@imc.org
Subject: Re: ACL2 models
In-Reply-To: <Pine.WNT.4.55.0302191401200.4528@Tomobiki-Cho.CAC.Washington.EDU>
Message-ID: <Pine.LNX.4.53L-031.0302191702240.8235@gobo.andrew.cmu.edu>
References: <1045687758.21737.108.camel@hurina> <Pine.LNX.4.53L-031.0302191616250.8215@gobo.andrew.cmu.edu> <Pine.WNT.4.55.0302191401200.4528@Tomobiki-Cho.CAC.Washington.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

On Wed, 19 Feb 2003, Mark Crispin wrote:

> On Wed, 19 Feb 2003, Rob Siemborski wrote:
> > In any case, there's a bigger problem.  With the UNION model, this results
> > in no user being able to use the mailbox at all (since negative rights
> > have to take affect after all positivie rights are unioned, otherwise they
> > don't really make any sense... you don't start with any rights on the
> > mailbox).
>
> Isn't this the entire point of negative rights?

I misinterpreted Timo's first message, I think, to imply that he wanted a
right of

-anyone <all>

by default on all mailboxes.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1JM28O11494 for ietf-imapext-bks; Wed, 19 Feb 2003 14:02:08 -0800 (PST)
Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1JM27d11490 for <ietf-imapext@imc.org>; Wed, 19 Feb 2003 14:02:07 -0800 (PST)
Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout4.cac.washington.edu (8.12.1+UW01.12/8.12.1+UW02.12) with ESMTP id h1JM24q6008184; Wed, 19 Feb 2003 14:02:04 -0800
Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.12.1+UW01.12/8.12.1+UW02.12) with ESMTP id h1JM24Fl029521 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 19 Feb 2003 14:02:04 -0800
Date: Wed, 19 Feb 2003 14:02:04 -0800 (Pacific Standard Time)
From: Mark Crispin <MRC@cac.washington.edu>
To: Rob Siemborski <rjs3@andrew.cmu.edu>
cc: Timo Sirainen <tss@iki.fi>, ietf-imapext@imc.org
Subject: Re: ACL2 models
In-Reply-To: <Pine.LNX.4.53L-031.0302191616250.8215@gobo.andrew.cmu.edu>
Message-ID: <Pine.WNT.4.55.0302191401200.4528@Tomobiki-Cho.CAC.Washington.EDU>
References: <1045687758.21737.108.camel@hurina> <Pine.LNX.4.53L-031.0302191616250.8215@gobo.andrew.cmu.edu>
Organization: Networks & Distributed Computing
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

On Wed, 19 Feb 2003, Rob Siemborski wrote:
> In any case, there's a bigger problem.  With the UNION model, this results
> in no user being able to use the mailbox at all (since negative rights
> have to take affect after all positivie rights are unioned, otherwise they
> don't really make any sense... you don't start with any rights on the
> mailbox).

Isn't this the entire point of negative rights?

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1JLwLR11420 for ietf-imapext-bks; Wed, 19 Feb 2003 13:58:21 -0800 (PST)
Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1JLwKd11413 for <ietf-imapext@imc.org>; Wed, 19 Feb 2003 13:58:20 -0800 (PST)
Received: from GOBO-6NET.andrew.cmu.edu (GOBO-6NET.andrew.cmu.edu [128.2.6.104]) (user=rjs3 mech=KERBEROS_V4 (0 bits)) by lin1.andrew.cmu.edu (8.12.7.Beta1/8.12.3.Beta2) with ESMTP id h1JLwG0V001039; Wed, 19 Feb 2003 16:58:16 -0500
Date: Wed, 19 Feb 2003 16:58:17 -0500 (EST)
From: Rob Siemborski <rjs3@andrew.cmu.edu>
To: Timo Sirainen <tss@iki.fi>
cc: ietf-imapext@imc.org
Subject: Re: ACL2 models
In-Reply-To: <1045691137.9912.121.camel@hurina>
Message-ID: <Pine.LNX.4.53L-031.0302191653190.8235@gobo.andrew.cmu.edu>
References: <1045687758.21737.108.camel@hurina>  <Pine.LNX.4.53L-031.0302191616250.8215@gobo.andrew.cmu.edu> <1045691137.9912.121.camel@hurina>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

On Wed, 19 Feb 2003, Timo Sirainen wrote:

> Sorry, I haven't looked ACLs much yet so my thoughts went a bit wrong. I
> meant something like this:
>
> group=foo -cxteda lrswip
> rjs3 -wipcxteda lrs
>
> Negative flags don't seem to be possible currently, but would adding
> support for them be a problem?

This looks a lot more tedious to me, and it means that clients are
enforcing the ACL policy and not the server (well, the server could
enforce it too, but then you might as well define which semantics you're
using).

And there are currently negative rights, you could do the above with:

-group=foo cxteda
group=foo lrswip
-rjs3 wipcxteda
rjs3 lrs

or even:

group=foo lrswip
-rjs3 wipcxteda
rjs3 lrs

Since servers aren't required to implement both ACL models, I guess I
don't see why we would want to obfuscate the MOST-SPECIFIC model inside of
UNION.  Perhaps this simplifies clients somewhat, but I think it gives
less control to administrators when enforcing their policies.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1JLjdt11191 for ietf-imapext-bks; Wed, 19 Feb 2003 13:45:39 -0800 (PST)
Received: from oma.irssi.org (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1JLjad11183 for <ietf-imapext@imc.org>; Wed, 19 Feb 2003 13:45:37 -0800 (PST)
Received: by oma.irssi.org (Postfix, from userid 1000) id 501855E01F68; Wed, 19 Feb 2003 23:45:38 +0200 (EET)
Subject: Re: ACL2 models
From: Timo Sirainen <tss@iki.fi>
To: Rob Siemborski <rjs3@andrew.cmu.edu>
Cc: ietf-imapext@imc.org
In-Reply-To: <Pine.LNX.4.53L-031.0302191616250.8215@gobo.andrew.cmu.edu>
References: <1045687758.21737.108.camel@hurina> <Pine.LNX.4.53L-031.0302191616250.8215@gobo.andrew.cmu.edu>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: 
Message-Id: <1045691137.9912.121.camel@hurina>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.1 
Date: 19 Feb 2003 23:45:38 +0200
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

On Wed, 2003-02-19 at 23:20, Rob Siemborski wrote:
> > Is it really a good idea to have separate UNION and MOST-SPECIFIC
> > models? If UNION acls were evaluated in most-specific-rule-last order,
> > MOST-SPECIFIC behaviour could be done just by prepending "-anyone" to
> > rules. I'd think that would make it simpler for implementors since they
> > wouldn't have to deal with two different models.
> 
> I don't agree. Say you have the UNION ACL:
> 
> -anyone lrswipcxteda
> group=foo lrswip
> rjs3 lrs

Sorry, I haven't looked ACLs much yet so my thoughts went a bit wrong. I
meant something like this:

group=foo -cxteda lrswip
rjs3 -wipcxteda lrs

Negative flags don't seem to be possible currently, but would adding
support for them be a problem?


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1JLKfQ10612 for ietf-imapext-bks; Wed, 19 Feb 2003 13:20:41 -0800 (PST)
Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1JLKdd10608 for <ietf-imapext@imc.org>; Wed, 19 Feb 2003 13:20:39 -0800 (PST)
Received: from GOBO-6NET.andrew.cmu.edu (GOBO-6NET.andrew.cmu.edu [128.2.6.104]) (user=rjs3 mech=KERBEROS_V4 (0 bits)) by lin1.andrew.cmu.edu (8.12.7.Beta1/8.12.3.Beta2) with ESMTP id h1JLKT0V000990; Wed, 19 Feb 2003 16:20:29 -0500
Date: Wed, 19 Feb 2003 16:20:32 -0500 (EST)
From: Rob Siemborski <rjs3@andrew.cmu.edu>
To: Timo Sirainen <tss@iki.fi>
cc: ietf-imapext@imc.org
Subject: Re: ACL2 models
In-Reply-To: <1045687758.21737.108.camel@hurina>
Message-ID: <Pine.LNX.4.53L-031.0302191616250.8215@gobo.andrew.cmu.edu>
References: <1045687758.21737.108.camel@hurina>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

On Wed, 19 Feb 2003, Timo Sirainen wrote:

> Is it really a good idea to have separate UNION and MOST-SPECIFIC
> models? If UNION acls were evaluated in most-specific-rule-last order,
> MOST-SPECIFIC behaviour could be done just by prepending "-anyone" to
> rules. I'd think that would make it simpler for implementors since they
> wouldn't have to deal with two different models.

I don't agree. Say you have the UNION ACL:

-anyone lrswipcxteda
group=foo lrswip
rjs3 lrs

and rjs3 is in the foo group.

Using your method, rjs3 has lrswip, but with MOST-SPECIFIC, rjs3 has only
lrs.

In any case, there's a bigger problem.  With the UNION model, this results
in no user being able to use the mailbox at all (since negative rights
have to take affect after all positivie rights are unioned, otherwise they
don't really make any sense... you don't start with any rights on the
mailbox).

-Rob



-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1JKncG09691 for ietf-imapext-bks; Wed, 19 Feb 2003 12:49:38 -0800 (PST)
Received: from oma.irssi.org (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1JKnMd09609 for <ietf-imapext@imc.org>; Wed, 19 Feb 2003 12:49:23 -0800 (PST)
Received: by oma.irssi.org (Postfix, from userid 1000) id 342B25E01F68; Wed, 19 Feb 2003 22:49:18 +0200 (EET)
Subject: ACL2 models
From: Timo Sirainen <tss@iki.fi>
To: ietf-imapext@imc.org
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: 
Message-Id: <1045687758.21737.108.camel@hurina>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.1 
Date: 19 Feb 2003 22:49:18 +0200
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

Is it really a good idea to have separate UNION and MOST-SPECIFIC
models? If UNION acls were evaluated in most-specific-rule-last order,
MOST-SPECIFIC behaviour could be done just by prepending "-anyone" to
rules. I'd think that would make it simpler for implementors since they
wouldn't have to deal with two different models.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1JJcNG04978 for ietf-imapext-bks; Wed, 19 Feb 2003 11:38:23 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1JJcId04974 for <ietf-imapext@imc.org>; Wed, 19 Feb 2003 11:38:19 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06196; Wed, 19 Feb 2003 14:34:29 -0500 (EST)
Message-Id: <200302191934.OAA06196@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ietf-imapext@imc.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-imapext-acl-07.txt
Date: Wed, 19 Feb 2003 14:34:29 -0500
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF.

	Title		: IMAP4 ACL extension
	Author(s)	: A. Melnikov
	Filename	: draft-ietf-imapext-acl-07.txt
	Pages		: 10
	Date		: 2003-2-18
	
The ACL (Access Control List) extension of the Internet Message Access
Protocol [IMAP4] permits mailbox access control lists to be manipulated
through the IMAP protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-imapext-acl-07.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-imapext-acl-07.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-imapext-acl-07.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-2-19145339.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-imapext-acl-07.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-imapext-acl-07.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-2-19145339.I-D@ietf.org>

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1EBm0S22847 for ietf-imapext-bks; Fri, 14 Feb 2003 03:48:00 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1EBlwd22843 for <ietf-imapext@imc.org>; Fri, 14 Feb 2003 03:47:59 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16891; Fri, 14 Feb 2003 06:44:13 -0500 (EST)
Message-Id: <200302141144.GAA16891@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ietf-imapext@imc.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-imapext-list-extensions-02.txt
Date: Fri, 14 Feb 2003 06:44:13 -0500
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF.

	Title		: IMAP4 LIST Command Extensions
	Author(s)	: B. Leiba
	Filename	: draft-ietf-imapext-list-extensions-02.txt
	Pages		: 8
	Date		: 2003-2-13
	
IMAP4 has two commands for listing mailboxes: LIST and LSUB.  As we
have added extensions that have required specialized lists (see
[MboxRefer] for an example) we have had to expand the number of list
commands, since each extension must add its function to both LIST and
LSUB, and these commands are not, as they are defined, extensible.
If we've needed the extensions to work together, we've had to add a
set of commands to mix the different options, the set increasing in
size with each new extension.  This document describes an extension
to the base LIST command that will allow these additions to be done
with mutually compatible options to the LIST command, avoiding the
exponential increase in specialized list commands.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-imapext-list-extensions-02.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-imapext-list-extensions-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-imapext-list-extensions-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-2-13152807.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-imapext-list-extensions-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-imapext-list-extensions-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-2-13152807.I-D@ietf.org>

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1CFgqj21046 for ietf-imapext-bks; Wed, 12 Feb 2003 07:42:52 -0800 (PST)
Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1CFgpd21042 for <ietf-imapext@imc.org>; Wed, 12 Feb 2003 07:42:51 -0800 (PST)
Received: from sp1n294en1.watson.ibm.com (sp1n294en1.watson.ibm.com [9.2.112.58]) by igw2.watson.ibm.com (8.11.4/8.11.4) with ESMTP id h1CFglo24348 for <ietf-imapext@imc.org>; Wed, 12 Feb 2003 10:42:47 -0500
Received: from mars.watson.ibm.com (mars.watson.ibm.com [9.2.40.64]) by sp1n294en1.watson.ibm.com (8.11.4/8.11.4) with ESMTP id h1CFglG44238 for <ietf-imapext@imc.org>; Wed, 12 Feb 2003 10:42:47 -0500
Date: Wed, 12 Feb 2003 10:42:47 -0500
From: Barry Leiba <leiba@watson.ibm.com>
To: IMAP extensions Mailing  List <ietf-imapext@imc.org>
Subject: spurious message
Message-ID: <1727104687.1045046567@mars.watson.ibm.com>
X-Mailer: Mulberry/3.0.0 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

Hm, an old message that I was looking at appears to've gotten re-sent 
to the list.  Sorry 'bout that.

Barry

--
Barry Leiba, Internet Messaging Technology  (leiba@watson.ibm.com)
http://www.research.ibm.com/people/l/leiba



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1CFfh320990 for ietf-imapext-bks; Wed, 12 Feb 2003 07:41:43 -0800 (PST)
Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1CFffd20986 for <ietf-imapext@imc.org>; Wed, 12 Feb 2003 07:41:41 -0800 (PST)
Received: from sp1n294en1.watson.ibm.com (sp1n294en1.watson.ibm.com [9.2.112.58]) by igw2.watson.ibm.com (8.11.4/8.11.4) with ESMTP id h1CFfbo66148 for <ietf-imapext@imc.org>; Wed, 12 Feb 2003 10:41:37 -0500
Received: from mars.watson.ibm.com (mars.watson.ibm.com [9.2.40.64]) by sp1n294en1.watson.ibm.com (8.11.4/8.11.4) with ESMTP id h1CFfbG34140 for <ietf-imapext@imc.org>; Wed, 12 Feb 2003 10:41:37 -0500
Date: Wed, 12 Feb 2003 10:41:37 -0500
From: Barry Leiba <leiba@watson.ibm.com>
To: IMAP extensions Mailing  List <ietf-imapext@imc.org>
Subject: draft-ietf-imapext-list-extensions-02
Message-ID: <1727034640.1045046497@mars.watson.ibm.com>
X-Mailer: Mulberry/3.0.0 (Win32)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="==========1727055152=========="
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

--==========1727055152==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I've just sent the attached update to 
draft-ietf-imapext-list-extensions-02 to the I-D editor.  It contains 
the changes that were brought up here, including a correction to the 
grammar for the LIST response extension (as pointed out by Alexey) and 
some text explaining the LIST response extension.

Barry

--
Barry Leiba, Internet Messaging Technology  (leiba@watson.ibm.com)
http://www.research.ibm.com/people/l/leiba

--==========1727055152==========
Content-Type: text/plain; charset=iso-8859-1;
 name="draft-ietf-imapext-list-extensions-02.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="draft-ietf-imapext-list-extensions-02.txt"; size=19493


IMAP Extensions Working Group                                   B. =
Leiba
Internet Draft                           IBM T.J. Watson Research =
Center
Document: draft-ietf-imapext-list-extensions-02.txt        February =
2003
                                                     Expires August =
2003
                     IMAP4 LIST Command Extensions
Status of this Document
   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.  Internet-Drafts are =
working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.
   Internet-Drafts are draft documents valid for a maximum of six =
months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."
     The list of current Internet-Drafts can be accessed at
     http://www.ietf.org/ietf/1id-abstracts.txt
     The list of Internet-Draft Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html.
   A revised version of this draft document will be submitted to the =
RFC
   editor as an Proposed Standard for the Internet Community.
   Discussion and suggestions for improvement are requested, and should
   be sent to ietf-imapext@imc.org.  This document will expire before =
31
   August 2003.  Distribution of this memo is unlimited.
1. Abstract
   IMAP4 has two commands for listing mailboxes: LIST and LSUB.  As we
   have added extensions that have required specialized lists (see
   [MboxRefer] for an example) we have had to expand the number of list
   commands, since each extension must add its function to both LIST =
and
   LSUB, and these commands are not, as they are defined, extensible.
   If we've needed the extensions to work together, we've had to add a
   set of commands to mix the different options, the set increasing in
   size with each new extension.  This document describes an extension
   to the base LIST command that will allow these additions to be done
   with mutually compatible options to the LIST command, avoiding the
   exponential increase in specialized list commands.
B. Leiba                  Expires August 2003                  [Page =
1]=0C
Internet DRAFT       IMAP4 LIST Command Extensions        February 2003
2. 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 words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" are
   used in this document as specified in RFC 2119 [Keywords].
3. Introduction
   The extensions to the LIST command will be accomplished by amending
   the syntax to allow options to be specified.  The list of options
   will replace the several commands that are currently used to mix and
   match the information requested.  The new syntax is backward-
   compatible, with no ambiguity: if the first word after the command
   name begins with a parenthesis, the new syntax is being used; if it
   does not, it's in the original syntax.
   By adding options to the LIST command, we are announcing the intent
   to phase out and eventually to deprecate the RLIST and RLSUB =
commands
   described in [MboxRefer].  We are also defining the mechanism to
   request extended mailbox information, such as is described in the
   now-expired "Child Mailbox Extension" draft [ChildMbox].  The base
   LSUB command is not deprecated by this extension; rather, this
   extension adds a way to obtain subscription information with more
   options, with those server implementations that support it.  Clients
   that simply need a list of subscribed mailboxes, as provided by the
   LSUB command, SHOULD continue to use that command.
4. LIST Command Options
   The LIST command syntax is extended by adding a parenthesized list =
of
   command options between the command name and the reference name (see
   the formal syntax in section 6 for specific details).  Command
   options will be defined in this document and in approved extension
   documents; each option will be enabled by a capability string (one
   capability may enable multiple options), and a client MUST NOT send
   an option for which the server has not advertised support.  A server
   MAY ignore options it does not recognize.
   This extension is identified by the capability string "LISTEXT", and
   support for it is a prerequisite for any future extensions that
   require specialized forms of the LIST command.  Such extensions MUST
   refer to this document and MUST add their function through command
   options as described herein.  This document also defines the "LIST-
B. Leiba                  Expires August 2003                  [Page =
2]=0C
Internet DRAFT       IMAP4 LIST Command Extensions        February 2003
   SUBSCRIBED" capability string; see the "SUBSCRIBED" option below.
   This extension also defines extensions to the LIST response, =
allowing
   a series of extended fields at the end, a parenthesized list of
   attriobute/value pairs.  Each attribute is a string, each value may
   be a string or a nested parenthesized list of the same
   attribute/value pairs.  An example of this extended set might be
       (("ACL" (("user" "fred")("access" "rwi")))("X-Sample" "text"))
   See the formal grammar, below, for the full syntatic details.
   The options defined in this specification are
       SUBSCRIBED - causes the LIST command to list subscribed
          mailboxes, rather than the actual mailboxes.  This will often
          be a subset of the actual mailboxes.  It's also possible for
          this list to contain the names of mailboxes that don't exist.
          In any case, the list MUST include exactly those mailbox =
names
          that match the selection criteria and are subscribed to.  =
This
          option is intended to supplement the LSUB command, and =
support
          for it is optional -- a server that supports the SUBSCRIBED
          option indicates so through the LIST-SUBSCRIBED capability.
          Of particular note are the mailbox flags as returned by this
          option, compared with what is returned by LSUB.  With the
          latter, the flags returned may not reflect the actual flag
          status on the mailbox, and the \NoSelect flag has a special
          meaning (it indicates that this mailbox is not, itself,
          subscribed, but that it has child mailboxes that are).  With
          the SUBSCRIBED option described here, the flags are accurate
          and complete, and have no special meanings.
          "LSUB" and "LIST (SUBSCRIBED)" are, thus, not the same thing,
          and some servers must do significant extra work to respond to
          "LIST (SUBSCRIBED)".  Because of this, clients SHOULD =
continue
          to use "LSUB" unless they specifically want the additional
          information offered by "LIST (SUBSCRIBED)".  At the same =
time,
          servers SHOULD support the LIST-SUBSCRIBED capability even if
          it entails extra work, because a client that wants the
          information will still obtain it by using LSUB followed by a
          series of LIST commands, so servers might as well make it
          easier.
          This option defines a new mailbox flag, "\NonExistent", that
          indicates that a mailbox is subscribed to, but does not
          actually exist.  The "\NonExistent" flag MUST be supported =
and
          MUST be accurately computed.
       REMOTE - causes the LIST command to show remote mailboxes as
          well as local ones, as described in [MboxRefer].  This option
B. Leiba                  Expires August 2003                  [Page =
3]=0C
Internet DRAFT       IMAP4 LIST Command Extensions        February 2003
          is intended to replace the RLIST command and, in conjunction
          with the SUBSCRIBED option, the RLSUB command.  This option =
is
          only available on servers that also support RFC-2193.
       CHILDREN - Requests mailbox child information as originally
          proposed in [ChildMbox].  See section 5, below, for details.
          Support for this is optional, but this option MUST be =
accepted
          by all servers (though it MAY be ignored).
   The LISTEXT capability also defines a new mailbox flag,
   "\PlaceHolder", that indicates that the designated mailbox does not
   meet the selection criteria of the given LIST command, but that it
   has one or more child mailboxes that do [EDITORIAL NOTE: "might"?].
   The LSUB command indicates this condition by using the "\NoSelect"
   flag, but the LIST (SUBSCRIBED) command MUST NOT do that, since
   "\NoSelect" retains its original meaning here.  Further, the
   "\PlaceHolder" flag is more general, in that it can be used with any
   extended set of selection criteria.
5. The CHILDREN Option
   The CHILDREN option implements the Child Mailbox Extension,
   originally proposed by Mike Gahrns and Raymond Cheng, of Microsoft
   Corporation.  Most of the information in this section is taken
   directly from their original specification [ChildMbox].  The =
CHILDREN
   option is simply an indication that the client wants this
   information; a server MAY provide it even if the option is not
   specified, or MAY ignore the option entirely.
   Many IMAP4 [IMAP4] clients present to the user a hierarchical view =
of
   the mailboxes that a user has access to.  Rather than initially
   presenting to the user the entire mailbox hierarchy, it is often
   preferable to show to the user a collapsed outline list of the
   mailbox hierarchy (particularly if there is a large number of
   mailboxes).  The user can then expand the collapsed outline =
hierarchy
   as needed.  It is common to include within the collapsed hierarchy a
   visual clue (such as a ''+'') to indicate that there are child
   mailboxes under a particular mailbox.   When the visual clue is
   clicked the hierarchy list is expanded to show the child mailboxes.
   The Child Mailbox Extension provides a mechanism for a client to
   efficiently determine if a particular mailbox has children, without
   issuing a LIST '' * or a LIST '' % for each mailbox name.
   The Child Mailbox Extension defines two new attributes that MAY be
   returned within a LIST response: \HasChildren and \HasNoChildren.
   While these attributes MAY be returned in response to any LIST
   command, the CHILDREN option is provided to indicate that the client
B. Leiba                  Expires August 2003                  [Page =
4]=0C
Internet DRAFT       IMAP4 LIST Command Extensions        February 2003
   particularly wants this information.  If the CHILDREN option is
   present, the server SHOULD return these attributes even if their
   computation is expensive.
\HasChildren - The presence of this attribute indicates that the =
mailbox
       has child mailboxes.
       A server SHOULD NOT set this attribute if there are child
       mailboxes, and the user does not have permissions to access any
       of them. In this case, \HasNoChildren SHOULD be used.
       In many cases, however, a server may not be able to efficiently
       compute whether a user has access to all child mailboxes.  As
       such a client MUST be prepared to accept the \HasChildren
       attribute as a hint.  That is, a mailbox MAY be flagged with the
       \HasChildren attribute, but no child mailboxes will appear in
       the LIST response.
\HasNoChildren - The presence of this attribute indicates that the
       mailbox has NO child mailboxes that are accessible to the
       currently authenticated user.
   In some instances a server that supports the Child Mailbox Extension
   might not be able to determine whether a mailbox has children.  For
   example it may have difficulty determining whether there are child
   mailboxes when LISTing mailboxes while operating in a particular
   namespace.
   In these cases, a server MAY exclude both the \HasChildren and
   \HasNoChildren attributes in the LIST response.  As such, a client
   can not make any assumptions about whether a mailbox has children
   based upon the absence of a single attribute.  In particular, some
   servers may not be able to combine the SUBSCRIBED and CHILDREN
   options.  Such servers MUST honour the SUBSCRIBED option, and they
   will simply ignore the CHILDREN option if both are requested.
   It is an error for the server to return both a \HasChildren and a
   \HasNoChildren attribute in a LIST response.
   Note: the \HasNoChildren attribute should not be confused with the
   IMAP4 [IMAP4] defined attribute \NoInferiors which indicates that no
   child mailboxes exist now and none can be created in the future.
6. Examples
   The first example shows the complete local hierarchy that will be
   used for the other examples.
B. Leiba                  Expires August 2003                  [Page =
5]=0C
Internet DRAFT       IMAP4 LIST Command Extensions        February 2003
       C: A01 LIST "" "*"
       S: * LIST (\Marked \NoInferiors) "/" "inbox"
       S: * LIST () "/" "Fruit"
       S: * LIST () "/" "Fruit/Apple"
       S: * LIST () "/" "Fruit/Banana"
       S: * LIST () "/" "Tofu"
       S: * LIST () "/" "Vegetable"
       S: * LIST () "/" "Vegetable/Broccoli"
       S: A01 OK done
   In the next example, we'll see the subscribed mailboxes.  This is
   similar, but not equivalent, to <LSUB "" "*">.  Note that the =
mailbox
   called "Fruit/Peach" is subscribed to, but does not actually exist
   (perhaps it was deleted while still subscribed).  And the "Fruit"
   mailbox is not subscribed to, but it has two subscribed children.
       C: A02 LIST (SUBSCRIBED) "" "*"
       S: * LIST (\Marked \NoInferiors) "/" "inbox"
       S: * LIST (\PlaceHolder) "/" "Fruit"
       S: * LIST () "/" "Fruit/Banana"
       S: * LIST (\NonExistent) "/" "Fruit/Peach"
       S: A02 OK done
   The next example shows the use of the CHILDREN option.  The client,
   without having to list the second level of hierarchy, now knows =
which
   of the top-level mailboxes have sub-mailboxes (children) and which =
do
   not.  Note that it's not necessary for the server to return the
   \HasNoChildren flag for the inbox, because the \NoInferiors flag
   already implies that, and has a stronger meaning.
       C: A03 LIST (CHILDREN) "" "%"
       S: * LIST (\Marked \NoInferiors) "/" "inbox"
       S: * LIST (\HasChildren) "/" "Fruit"
       S: * LIST (\HasNoChildren) "/" "Tofu"
       S: * LIST (\HasChildren) "/" "Vegetable"
       S: A03 OK done
   In this example we see more mailboxes, which reside on another =
server
   to which we may obtain referrals.  This is similar to the command
   <RLIST "" "%">.  We also see the mixing of two options.  Note that =
in
   the case of the remote mailboxes, the server might or might not be
   able to include CHILDREN information; it includes it if it can, and
   omits it if it can't.
       C: A04 LIST (REMOTE CHILDREN) "" "%"
       S: * LIST (\Marked \NoInferiors) "/" "inbox"
       S: * LIST (\HasChildren) "/" "Fruit"
       S: * LIST (\HasNoChildren) "/" "Tofu"
       S: * LIST (\HasChildren) "/" "Vegetable"
B. Leiba                  Expires August 2003                  [Page =
6]=0C
Internet DRAFT       IMAP4 LIST Command Extensions        February 2003
       S: * LIST () "/" "Bread"
       S: * LIST (\HasChildren) "/" "Meat"
       S: A04 OK done
7. Formal Syntax
   The following syntax specification uses the augmented Backus-Naur
   Form (BNF) as described in [ABNF].  Terms not defined here are taken
   from [IMAP4].
   child-mbox-flag =3D "\HasChildren" / "\HasNoChildren"
                      ; flags for Child Mailbox Extension, at most one
                      ; possible per LIST response
   list            =3D "LIST" [SP list-options] SP mailbox SP =
list-mailbox
   list-options    =3D "(" [option *(SP option)] ")"
   mailbox-list    =3D "(" [mbx-list-flags] ")" SP
                      (DQUOTE QUOTED-CHAR DQUOTE / nil) SP mailbox
                      [SP mbox-list-extended]
   mbox-list-extended =3D "(" mbox-list-extended-item
                        *(SP mbox-list-extended-item) ")"
   mbox-list-extended-item =3D "(" string SP (string / =
mbox-list-extended-
   item) ")"
                             / mailbox-list-extended
   mbox-list-oflag :=3D child-mbox-flag / "\NonExistent" / =
"\PlaceHolder"
   option           =3D "SUBSCRIBED" / "CHILDREN" / "REMOTE" /
                     option-extension
   option-extension =3D atom
8. Security Considerations
   This document describes syntactic changes to the specification of =
the
   IMAP4 commands LIST, LSUB, RLIST, and RLSUB, and the modified LIST
   command has the same security considerations as those commands.  =
They
   are described in [IMAP4] and [MboxRefer].
   The Child Mailbox Extension provides a client a more efficient means
   of determining whether a particular mailbox has children.  If a
   mailbox has children, but the currently authenticated user does not
   have access to any of them, the server SHOULD respond with a
B. Leiba                  Expires August 2003                  [Page =
7]=0C
Internet DRAFT       IMAP4 LIST Command Extensions        February 2003
   \HasNoChildren attribute.  In many cases, however, a server may not
   be able to efficiently compute whether a user has access to all =
child
   mailboxes.  If such a server responds with a \HasChildren attribute,
   when in fact the currently authenticated user does not have access =
to
   any child mailboxes, potentially more information is conveyed about
   the mailbox than intended.   In most situations this will not be a
   security concern, because if information regarding whether a mailbox
   has children is considered sensitive, a user would not be granted
   access to that mailbox in the first place.
9. References
   [IMAP4]; Crispin, M.; "Internet Message Access Protocol - Version
   4rev1"; RFC 2060; University of Washington; December 1996.
   [MboxRefer]; Gahrns, M.; "IMAP4 Mailbox Referrals"; RFC 2193;
   Microsoft Corporation; September 1997.
   [ChildMbox]; Gahrns, M. & Cheng, R.; "IMAP4 Child Mailbox =
Extension";
   RFC 3328; Microsoft Corporation; July 2002.
   [Keywords]; Bradner, S.; "Key words for use in RFCs to Indicate
   Requirement Levels"; RFC 2119; Harvard University; March 1997.
   [ABNF]; Crocker, D., and Overell, P. "Augmented BNF for Syntax
   Specifications: ABNF", RFC 2234, November 1997.
10. Acknowledgements
   Mike Gahrns and Raymond Cheng of Microsoft Corporation originally
   devised the Child Mailbox Extension and proposed it in 1997; the
   idea, as well as most of the text in section 5, is theirs.
11. Author's Address
   Barry Leiba
   IBM T.J. Watson Research Center
   30 Saw Mill River Road
   Hawthorne, NY  10532
   Phone: 1-914-784-7941
   Email: leiba@watson.ibm.com
B. Leiba                  Expires August 2003                  [Page 8]
--==========1727055152==========--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1CFW3u20676 for ietf-imapext-bks; Wed, 12 Feb 2003 07:32:03 -0800 (PST)
Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1CFW2d20672 for <ietf-imapext@imc.org>; Wed, 12 Feb 2003 07:32:02 -0800 (PST)
Received: from sp1n294en1.watson.ibm.com (sp1n294en1.watson.ibm.com [9.2.112.58]) by igw2.watson.ibm.com (8.11.4/8.11.4) with ESMTP id h1CFVwo31650 for <ietf-imapext@imc.org>; Wed, 12 Feb 2003 10:31:58 -0500
Received: from mars.watson.ibm.com (mars.watson.ibm.com [9.2.40.64]) by sp1n294en1.watson.ibm.com (8.11.4/8.11.4) with ESMTP id h1CFVwG32732; Wed, 12 Feb 2003 10:31:58 -0500
Date: Wed, 12 Feb 2003 10:31:56 -0500
From: Barry Leiba <leiba@watson.ibm.com>
To: Barry Leiba <leiba@watson.ibm.com>, IMAP extensions Mailing List <ietf-imapext@imc.org>
Subject: Re: LIST Extensions draft
Message-ID: <1726453750.1045045916@mars.watson.ibm.com>
X-Mailer: Mulberry/3.0.0 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

>OK, how about this?:
>
>--------
>IMAP4 has two commands for listing mailboxes: LIST and LSUB.  As we
have 
>added extensions that have require specialized lists (see [MboxRefer]
for 
>an example) we have expand the number of list commands, since each 
>extension must add its function to both LIST and LSUB, and these
commands 
>are not, as they are defined, extensible.  This document describes 
>extensions to the LIST command that allow these additions to be done
with 
>mutually compatible options to the LIST command, avoiding the
exponential 
>increase in specialized list commands.

Ah, now it is making sense to me.  Thanks.  I see that a large part of
my puzzlement stemmed from my interpretation of "since each extension
must add its function to both LIST and LSUB".  I was understanding that
as meaning adding capability into LIST and LSUB which is exactly what
the new proposal does and what the old extensions did not.  But you
mean supplementing the functionality of LIST and LSUB, right?

May I suggest a couple of improvements along the lines of:

IMAP4 has two commands for listing mailboxes: LIST and LSUB.  As we
have added extensions that required specialized lists (see [MboxRefer]
for an example), we have done so by defining new list commands, for
example RLIST and RLSUB.  Each such extension has served to supplement
LIST and LSUB since these commands, as currently defined, are not
intrinsically extensible.  This document describes an extension to the
LIST command that allows such additions to be made with mutually
compatible options thereby avoiding exponential increase in the number
of specialized list commands.

Note that I have changed "extensions" to "extension" in the last
sentence.  This may well be debatable but I see the addition of a new
argument as essentially a single change.

Pete

Barry

--
Barry Leiba, Internet Messaging Technology  (leiba@watson.ibm.com)
http://www.research.ibm.com/people/l/leiba



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1CENqG18100 for ietf-imapext-bks; Wed, 12 Feb 2003 06:23:52 -0800 (PST)
Received: from il-tlv-smtpout2.icomverse.com (comversegw.icomverse.com [192.118.48.248]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1CENod18092 for <ietf-imapext@imc.org>; Wed, 12 Feb 2003 06:23:51 -0800 (PST)
Received: from il-tlv-mbdg1.comverse.com (localhost.localdomain [127.0.0.1]) by il-tlv-smtpout2.icomverse.com (8.11.6/8.11.6) with ESMTP id h1CENef27978 for <ietf-imapext@imc.org>; Wed, 12 Feb 2003 16:23:40 +0200
Received: by il-tlv-mbdg1.comverse.com with Internet Mail Service (5.5.2655.55) id <1W08JG4M>; Wed, 12 Feb 2003 16:23:48 +0200
Message-ID: <7D4344E32B34D511A6500002A560C602230C62@il-tlv-mail4.comverse.com>
From: Shiv Amir <Amir.Shiv@comverse.com>
To: "'ietf-imapext@imc.org'" <ietf-imapext@imc.org>
Subject: RE: FETCH versus CHANNEL
Date: Wed, 12 Feb 2003 16:23:46 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D2A2.2C8A9FD4"
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C2D2A2.2C8A9FD4
Content-Type: text/plain;
	charset="windows-1255"


RFC 2060 says: "The FETCH command retrieves data associated with a
message...". Since the  URL is a data associated  with a message or part of
a message, the FETCH command seems the  most natural and consistent way.

The CHANNEL draft introduces a new data type, the <channel-set>, which is a
list of msg:section  pairs. This data type is limited only to multi-part
messages. In case of a "single-part" message an  error or NIL should be
returned, hence it does not support this kind of messages. Also it is not
possible to specify a different scheme as per each requested URL.

The following example fetches the URLs for sections 2 and 3 of message
number 1. Note that for  each body-part a different protocol/scheme is
specified:

C: A005 FETCH 1 (URL[2 (rtsp mms)] URL[3 (http imap)])

S: * 1 FETCH (URL[2] {21}
S: rtsp://part1/part2/file.mpg
S:
S: URL[3] {28}
S: http://www.part1.com/part2/file.mp3
S:
S: )
S: A005 OK FETCH complete

The FETCH command provides the (standard) protocol frame. It does not
contradict internal  operations like transcoding or transferring message's
data.

The CHANNEL draft demonstrates a scenario where different body-parts from
different messages  are retrieved in a single command. In that sense FETCH
is indeed somewhat limited.

Amir Shiv 
Comverse


-----Original Message-----
From: Chris Newman [mailto:Chris.Newman@Sun.COM]
Sent: Tuesday, February 11, 2003 3:40 AM
To: Eric Burger; ietf-imapext@imc.org
Cc: IETF LEMONADE (E-mail)
Subject: Re: FETCH versus CHANNEL



I can not answer this question without more protocol details about the 
contrasting proposals.

What would the FETCH proposal look like on the wire?

If we're operating on MIME body parts rather than an entire message, then 
leveraging the existing FETCH infrastructure probably makes sense.  But you 
need to get the semantics correct.  Look at the difference between partial 
fetches in 1730 and 2060 for one sort of mistake.  Look at the BINARY 
extension for one example of how to do this correctly.

                - Chris

begin  quotation by Eric Burger on 2003/2/10 1:11 -0500:

>
> Shiv proposed using FETCH instead of CHANNEL for requesting non-IMAP
> retrieval (e.g., streaming) of messages.  There were a bunch of "yes --
> that sounds right" messages.
>
> Does anyone object?  Do we have consensus to move forward?


------_=_NextPart_001_01C2D2A2.2C8A9FD4
Content-Type: text/html;
	charset="windows-1255"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dwindows-1255">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2655.35">
<TITLE>RE: FETCH versus CHANNEL</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">RFC 2060 says: &quot;The FETCH command =
retrieves data associated with a message...&quot;. Since the&nbsp; URL =
is a data associated&nbsp; with a message or part of a message, the =
FETCH command seems the&nbsp; most natural and consistent =
way.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The CHANNEL draft introduces a new =
data type, the &lt;channel-set&gt;, which is a list of =
msg:section&nbsp; pairs. This data type is limited only to multi-part =
messages. In case of a &quot;single-part&quot; message an&nbsp; error =
or NIL should be returned, hence it does not support this kind of =
messages. Also it is not&nbsp; possible to specify a different scheme =
as per each requested URL.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The following example fetches the URLs =
for sections 2 and 3 of message number 1. Note that for&nbsp; each =
body-part a different protocol/scheme is specified:</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">C: A005 FETCH 1 (URL[2 (rtsp mms)] =
URL[3 (http imap)])</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">S: * 1 FETCH (URL[2] {21}</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">S: rtsp://part1/part2/file.mpg</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">S:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">S: URL[3] {28}</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">S: <A =
HREF=3D"http://www.part1.com/part2/file.mp3" =
TARGET=3D"_blank">http://www.part1.com/part2/file.mp3</A></FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">S:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">S: )</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">S: A005 OK FETCH complete</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The FETCH command provides the =
(standard) protocol frame. It does not contradict internal&nbsp; =
operations like transcoding or transferring message's data.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The CHANNEL draft demonstrates a =
scenario where different body-parts from different messages&nbsp; are =
retrieved in a single command. In that sense FETCH is indeed somewhat =
limited.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Amir Shiv </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Comverse</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">From: Chris Newman [<A =
HREF=3D"mailto:Chris.Newman@Sun.COM">mailto:Chris.Newman@Sun.COM</A>]</F=
ONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Sent: Tuesday, February 11, 2003 3:40 =
AM</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">To: Eric Burger; =
ietf-imapext@imc.org</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Cc: IETF LEMONADE (E-mail)</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Subject: Re: FETCH versus =
CHANNEL</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">I can not answer this question without =
more protocol details about the </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">contrasting proposals.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">What would the FETCH proposal look =
like on the wire?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">If we're operating on MIME body parts =
rather than an entire message, then </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">leveraging the existing FETCH =
infrastructure probably makes sense.&nbsp; But you </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">need to get the semantics =
correct.&nbsp; Look at the difference between partial </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">fetches in 1730 and 2060 for one sort =
of mistake.&nbsp; Look at the BINARY </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">extension for one example of how to =
do this correctly.</FONT>
</P>

<P><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Chris</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">begin&nbsp; quotation by Eric Burger =
on 2003/2/10 1:11 -0500:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Shiv proposed using FETCH =
instead of CHANNEL for requesting non-IMAP</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; retrieval (e.g., streaming) of =
messages.&nbsp; There were a bunch of &quot;yes --</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; that sounds right&quot; =
messages.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Does anyone object?&nbsp; Do we =
have consensus to move forward?</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C2D2A2.2C8A9FD4--


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1CDDu812768 for ietf-imapext-bks; Wed, 12 Feb 2003 05:13:56 -0800 (PST)
Received: from il-tlv-smtpout2.icomverse.com (il-tlv-firewall-main.icomverse.com [192.118.48.248]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1CDDsd12758 for <ietf-imapext@imc.org>; Wed, 12 Feb 2003 05:13:54 -0800 (PST)
Received: from il-tlv-mbdg2.comverse.com (localhost.localdomain [127.0.0.1]) by il-tlv-smtpout2.icomverse.com (8.11.6/8.11.6) with ESMTP id h1CDDcv20892 for <ietf-imapext@imc.org>; Wed, 12 Feb 2003 15:13:43 +0200
Received: by il-tlv-mbdg2.comverse.com with Internet Mail Service (5.5.2655.55) id <1XAC3BPH>; Wed, 12 Feb 2003 15:13:45 +0200
Message-ID: <7D4344E32B34D511A6500002A560C602230C61@il-tlv-mail4.comverse.com>
From: Shiv Amir <Amir.Shiv@comverse.com>
To: ietf-imapext@imc.org
Subject: RE: FETCH versus CHANNEL
Date: Wed, 12 Feb 2003 15:13:45 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D298.92401872"
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C2D298.92401872
Content-Type: text/plain;
	charset="iso-8859-1"


RFC 2060 says: "The FETCH command retrieves data associated with a
message...". Since the URL is a data associated  with a message or part of a
message, the FETCH command seems the most natural and consistent way.

The CHANNEL draft introduces a new data type, the <channel-set>, which is a
list of msg:section pairs. This data type  is limited only to multi-part
messages. In case of a "single-part" message an error or NIL should be
returned, hence it does not support this kind of messages. Also it is not
possible to specify a different scheme as per each requested URL.

The following example fetches the URLs for sections 2 and 3 of message
number 1. Note that for each body-part a  different protocol/scheme is
specified:

C: A005 FETCH 1 (URL[2 (rtsp mms)] URL[3 (http imap)])

S: * 1 FETCH (URL[2] {21}
S: rtsp://part1/part2/file.mpg
S:
S: URL[3] {28}
S: http://www.part1.com/part2/file.mp3
S:
S: )
S: A005 OK FETCH complete

The FETCH command provides the (standard) protocol frame. It does not
contradict internal operations like transcoding  or transferring message's
data.

The CHANNEL draft demonstrates a scenario where different body-parts from
different messages are retrieved in a  single command. In that sense FETCH
is indeed somewhat limited.

Amir Shiv 
Comverse


-----Original Message-----
From: Chris Newman [mailto:Chris.Newman@Sun.COM]
Sent: Tuesday, February 11, 2003 3:40 AM
To: Eric Burger; ietf-imapext@imc.org
Cc: IETF LEMONADE (E-mail)
Subject: Re: FETCH versus CHANNEL



I can not answer this question without more protocol details about the 
contrasting proposals.

What would the FETCH proposal look like on the wire?

If we're operating on MIME body parts rather than an entire message, then 
leveraging the existing FETCH infrastructure probably makes sense.  But you 
need to get the semantics correct.  Look at the difference between partial 
fetches in 1730 and 2060 for one sort of mistake.  Look at the BINARY 
extension for one example of how to do this correctly.

                - Chris

begin  quotation by Eric Burger on 2003/2/10 1:11 -0500:

>
> Shiv proposed using FETCH instead of CHANNEL for requesting non-IMAP
> retrieval (e.g., streaming) of messages.  There were a bunch of "yes --
> that sounds right" messages.
>
> Does anyone object?  Do we have consensus to move forward?


------_=_NextPart_001_01C2D298.92401872
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2655.35">
<TITLE>RE: FETCH versus CHANNEL</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=3D2>RFC 2060 says: &quot;The FETCH command retrieves data =
associated with a message...&quot;. Since the URL is a data =
associated&nbsp; with a message or part of a message, the FETCH command =
seems the most natural and consistent way.</FONT></P>

<P><FONT SIZE=3D2>The CHANNEL draft introduces a new data type, the =
&lt;channel-set&gt;, which is a list of msg:section pairs. This data =
type&nbsp; is limited only to multi-part messages. In case of a =
&quot;single-part&quot; message an error or NIL should be returned, =
hence it does not support this kind of messages. Also it is not =
possible to specify a different scheme as per each requested =
URL.</FONT></P>

<P><FONT SIZE=3D2>The following example fetches the URLs for sections 2 =
and 3 of message number 1. Note that for each body-part a&nbsp; =
different protocol/scheme is specified:</FONT></P>

<P><FONT SIZE=3D2>C: A005 FETCH 1 (URL[2 (rtsp mms)] URL[3 (http =
imap)])</FONT>
</P>

<P><FONT SIZE=3D2>S: * 1 FETCH (URL[2] {21}</FONT>
<BR><FONT SIZE=3D2>S: rtsp://part1/part2/file.mpg</FONT>
<BR><FONT SIZE=3D2>S:</FONT>
<BR><FONT SIZE=3D2>S: URL[3] {28}</FONT>
<BR><FONT SIZE=3D2>S: <A HREF=3D"http://www.part1.com/part2/file.mp3" =
TARGET=3D"_blank">http://www.part1.com/part2/file.mp3</A></FONT>
<BR><FONT SIZE=3D2>S:</FONT>
<BR><FONT SIZE=3D2>S: )</FONT>
<BR><FONT SIZE=3D2>S: A005 OK FETCH complete</FONT>
</P>

<P><FONT SIZE=3D2>The FETCH command provides the (standard) protocol =
frame. It does not contradict internal operations like =
transcoding&nbsp; or transferring message's data.</FONT></P>

<P><FONT SIZE=3D2>The CHANNEL draft demonstrates a scenario where =
different body-parts from different messages are retrieved in a&nbsp; =
single command. In that sense FETCH is indeed somewhat =
limited.</FONT></P>

<P><FONT SIZE=3D2>Amir Shiv </FONT>
<BR><FONT SIZE=3D2>Comverse</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Chris Newman [<A =
HREF=3D"mailto:Chris.Newman@Sun.COM">mailto:Chris.Newman@Sun.COM</A>]</F=
ONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, February 11, 2003 3:40 AM</FONT>
<BR><FONT SIZE=3D2>To: Eric Burger; ietf-imapext@imc.org</FONT>
<BR><FONT SIZE=3D2>Cc: IETF LEMONADE (E-mail)</FONT>
<BR><FONT SIZE=3D2>Subject: Re: FETCH versus CHANNEL</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>I can not answer this question without more protocol =
details about the </FONT>
<BR><FONT SIZE=3D2>contrasting proposals.</FONT>
</P>

<P><FONT SIZE=3D2>What would the FETCH proposal look like on the =
wire?</FONT>
</P>

<P><FONT SIZE=3D2>If we're operating on MIME body parts rather than an =
entire message, then </FONT>
<BR><FONT SIZE=3D2>leveraging the existing FETCH infrastructure =
probably makes sense.&nbsp; But you </FONT>
<BR><FONT SIZE=3D2>need to get the semantics correct.&nbsp; Look at the =
difference between partial </FONT>
<BR><FONT SIZE=3D2>fetches in 1730 and 2060 for one sort of =
mistake.&nbsp; Look at the BINARY </FONT>
<BR><FONT SIZE=3D2>extension for one example of how to do this =
correctly.</FONT>
</P>

<P><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; - Chris</FONT>
</P>

<P><FONT SIZE=3D2>begin&nbsp; quotation by Eric Burger on 2003/2/10 =
1:11 -0500:</FONT>
</P>

<P><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Shiv proposed using FETCH instead of CHANNEL =
for requesting non-IMAP</FONT>
<BR><FONT SIZE=3D2>&gt; retrieval (e.g., streaming) of messages.&nbsp; =
There were a bunch of &quot;yes --</FONT>
<BR><FONT SIZE=3D2>&gt; that sounds right&quot; messages.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Does anyone object?&nbsp; Do we have consensus =
to move forward?</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C2D298.92401872--


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1B2TVv27119 for ietf-imapext-bks; Mon, 10 Feb 2003 18:29:31 -0800 (PST)
Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1B2TUd27115 for <ietf-imapext@imc.org>; Mon, 10 Feb 2003 18:29:30 -0800 (PST)
Received: from esunmail ([129.147.58.120]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA27709 for <ietf-imapext@imc.org>; Mon, 10 Feb 2003 18:40:11 -0700 (MST)
Received: from xpa-fe1 (esunmail [129.147.58.120]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec  6 2002)) with ESMTP id <0HA400CNHFAZ79@edgemail1.Central.Sun.COM> for ietf-imapext@imc.org; Mon, 10 Feb 2003 18:40:11 -0700 (MST)
Received: from nifty-jr.west.sun.com ([129.153.12.95]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec  6 2002)) with ESMTPSA id <0HA400I9MFAWHC@mail.sun.net> for ietf-imapext@imc.org; Mon, 10 Feb 2003 18:40:11 -0700 (MST)
Date: Mon, 10 Feb 2003 17:39:57 -0800
From: Chris Newman <Chris.Newman@Sun.COM>
Subject: Re: FETCH versus CHANNEL
In-reply-to: <4A3384433CE2AB46A63468CB207E209D248778@zoe.office.snowshore.com>
To: Eric Burger <eburger@snowshore.com>, ietf-imapext@imc.org
Cc: "IETF LEMONADE (E-mail)" <um@snowshore.com>
Message-id: <2147483647.1044898797@nifty-jr.west.sun.com>
MIME-version: 1.0
X-Mailer: Mulberry/3.0.0 (Mac OS X)
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-message-flag: Outlook: the best virus distribution system around
References: <4A3384433CE2AB46A63468CB207E209D248778@zoe.office.snowshore.com>
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

I can not answer this question without more protocol details about the 
contrasting proposals.

What would the FETCH proposal look like on the wire?

If we're operating on MIME body parts rather than an entire message, then 
leveraging the existing FETCH infrastructure probably makes sense.  But you 
need to get the semantics correct.  Look at the difference between partial 
fetches in 1730 and 2060 for one sort of mistake.  Look at the BINARY 
extension for one example of how to do this correctly.

                - Chris

begin  quotation by Eric Burger on 2003/2/10 1:11 -0500:

>
> Shiv proposed using FETCH instead of CHANNEL for requesting non-IMAP
> retrieval (e.g., streaming) of messages.  There were a bunch of "yes --
> that sounds right" messages.
>
> Does anyone object?  Do we have consensus to move forward?




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1AK0Kk16307 for ietf-imapext-bks; Mon, 10 Feb 2003 12:00:20 -0800 (PST)
Received: from orthanc.ab.ca (orthanc.ab.ca [216.123.230.114]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1AK0Id16302 for <ietf-imapext@imc.org>; Mon, 10 Feb 2003 12:00:18 -0800 (PST)
Received: from orthanc.ab.ca (localhost4 [127.0.0.1]) by orthanc.ab.ca (8.12.6/8.12.6) with ESMTP id h1AK0Fvu073880; Mon, 10 Feb 2003 13:00:15 -0700 (MST) (envelope-from lyndon@orthanc.ab.ca)
Message-Id: <200302102000.h1AK0Fvu073880@orthanc.ab.ca>
To: Erev Ari <Ari.Erev@comverse.com>
cc: "'ietf-imapext@imc.org'" <ietf-imapext@imc.org>, "'um@snowshore.com'" <um@snowshore.com>
Subject: Re: [UM] FETCH versus CHANNEL 
In-Reply-To: Message from Erev Ari <Ari.Erev@comverse.com>  of "Mon, 10 Feb 2003 17:18:53 +0200." <7D4344E32B34D511A6500002A560C60204D88D59@il-tlv-mail4.comverse.com> 
X-Mailer: MH-E 7.1+cvs; nmh 1.0.4; GNU Emacs 21.2.2
Date: Mon, 10 Feb 2003 13:00:14 -0700
From: Lyndon Nerenberg <lyndon@orthanc.ab.ca>
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

Overloading Fetch to support the semantics of Channel would add a lot
of complexity to the parser. The arguments to Fetch don't apply to
a Channel-style retrieval, URIs don't look anything like message sets,
and the Fetch response won't allow for returned URLs or the individual
status responses required when the request specifies multiple URIs and
messages.

The only sane way to do this is with a new command.

--lyndon


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1AFJ4M01603 for ietf-imapext-bks; Mon, 10 Feb 2003 07:19:04 -0800 (PST)
Received: from il-tlv-smtpout2.icomverse.com (il-tlv-firewall-main.icomverse.com [192.118.48.248]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1AFJ1d01599 for <ietf-imapext@imc.org>; Mon, 10 Feb 2003 07:19:01 -0800 (PST)
Received: from il-tlv-mbdg2.comverse.com (localhost.localdomain [127.0.0.1]) by il-tlv-smtpout2.icomverse.com (8.11.6/8.11.6) with ESMTP id h1AFImR19419; Mon, 10 Feb 2003 17:18:48 +0200
Received: by il-tlv-mbdg2.comverse.com with Internet Mail Service (5.5.2655.55) id <DWYV82X4>; Mon, 10 Feb 2003 17:18:56 +0200
Message-ID: <7D4344E32B34D511A6500002A560C60204D88D59@il-tlv-mail4.comverse.com>
From: Erev Ari <Ari.Erev@comverse.com>
To: "'ietf-imapext@imc.org'" <ietf-imapext@imc.org>
Cc: "'um@snowshore.com'" <um@snowshore.com>
Subject: [UM] FETCH versus CHANNEL 
Date: Mon, 10 Feb 2003 17:18:53 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D117.B8B11A24"
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C2D117.B8B11A24
Content-Type: text/plain;
	charset="windows-1255"

Hello,

In response to Eric Burger's question - I am also for Amir's suggestion
(which is copied below so people can relate to it). 

> Hello, 
> I would like to suggest an alternative implementation to the proposed
CHANNEL extension. 
> The FETCH command is designed to retrieve properties of a message (flags,
UID...) 
> One can think of a URI to a message as another property of the message.
So, it looks more reasonable to me to extend the > existing FETCH command to
retrieve alternate URIs to messages (and message parts) rather than
introducing a new command (CHANNEL).
> 
> For example: 
> tag FETCH 1 BODY[2.URI (rtsp: http:)]
> 
> Isn't this much more simple and consistent with the IMAP model? 
> 
> Amir Shiv 
> Comverse 

Regards,
Ari

------_=_NextPart_001_01C2D117.B8B11A24
Content-Type: text/html;
	charset="windows-1255"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dwindows-1255">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2655.35">
<TITLE>[UM] FETCH versus CHANNEL </TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">Hello,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">In response to Eric Burger's question =
- I am also for Amir's suggestion (which is copied below so people can =
relate to it). </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; Hello, </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; I would like to suggest an =
alternative implementation to the proposed CHANNEL extension. </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; The FETCH command is designed to =
retrieve properties of a message (flags, UID...) </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; One can think of a URI to a =
message as another property of the message. So, it looks more =
reasonable to me to extend the &gt; existing FETCH command to retrieve =
alternate URIs to messages (and message parts) rather than introducing =
a new command (CHANNEL).</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; For example: </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; tag FETCH 1 BODY[2.URI (rtsp: =
http:)]</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Isn't this much more simple and =
consistent with the IMAP model? </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Amir Shiv </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Comverse </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Regards,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Ari</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C2D117.B8B11A24--


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1A6BCQ09083 for ietf-imapext-bks; Sun, 9 Feb 2003 22:11:12 -0800 (PST)
Received: from zoe.office.snowshore.com (goalie.snowshore.com [216.57.133.4]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1A6BAd09071 for <ietf-imapext@imc.org>; Sun, 9 Feb 2003 22:11:10 -0800 (PST)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="windows-1255"
Subject: FETCH versus CHANNEL
Date: Mon, 10 Feb 2003 01:11:10 -0500
Message-ID: <4A3384433CE2AB46A63468CB207E209D248778@zoe.office.snowshore.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Alternative to CHANNEL
Thread-Index: AcKZH52/SAHjiXucSpC67paMk9SWhw3jg6nw
From: "Eric Burger" <eburger@snowshore.com>
To: <ietf-imapext@imc.org>
Cc: "IETF LEMONADE (E-mail)" <um@snowshore.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h1A6BBd09073
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

Shiv proposed using FETCH instead of CHANNEL for requesting non-IMAP retrieval (e.g., streaming) of messages.  There were a bunch of "yes -- that sounds right" messages.

Does anyone object?  Do we have consensus to move forward?


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h15ATpS22152 for ietf-imapext-bks; Wed, 5 Feb 2003 02:29:51 -0800 (PST)
Received: from mid-2.inet.it (mid-2.inet.it [213.92.5.19]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h15ATnd22141 for <ietf-imapext@imc.org>; Wed, 5 Feb 2003 02:29:50 -0800 (PST)
Received: from  [::ffff:213.92.1.193] by mid-2.inet.it via I-SMTP-4.3.5-430 id ::ffff:213.92.1.193+b0YrPRU2PgAj; Wed, 05 Feb 2003 11:29:44 +0100
Date: Wed, 5 Feb 2003 11:31:24 +0100
Subject: Re: I-D ACTION:draft-hazewinkel-imap-vhost-00.txt (fwd)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v551)
Cc: Harrie Hazewinkel <harrie@inet.it>, Ken Murchison <ken@oceana.com>, Cyrus Daboo <daboo@cyrusoft.com>, IMAP Extensions WG <ietf-imapext@imc.org>
To: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
From: Harrie Hazewinkel <harrie@inet.it>
In-Reply-To: <68XxWxPXB4SK7HJyGdK7+A.md5@melkebalanse.gulbrandsen.priv.no>
Message-Id: <F9DDD7CB-38F4-11D7-A399-0003934A5A7E@inet.it>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.551)
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

On Monday, February 3, 2003, at 08:52 PM, Arnt Gulbrandsen wrote:

>
> I have one minor issue which hasn't been brought up so far: It 
> complicates the state diagram.

IMHO, it does not complicate the state diagram.
No new states are introduced, it has a similar approach
to the state diagram as STARTTLS.

> The proposal adds another non-authenticated, which does not seem to be 
> warranted.

Yes, a new command is added in the non-authenticated state.


Harrie
------------------------------------------------------------------
Author of MOD-SNMP, enabling SNMP management of Apache HTTP server



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h15ARNI21752 for ietf-imapext-bks; Wed, 5 Feb 2003 02:27:23 -0800 (PST)
Received: from hal-5.inet.it (hal-5.inet.it [213.92.5.24]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h15ARFd21722 for <ietf-imapext@imc.org>; Wed, 5 Feb 2003 02:27:16 -0800 (PST)
Received: from  [::ffff:213.92.1.193] by hal-5.inet.it via I-SMTP-4.3.6-430 id ::ffff:213.92.1.193+iMYUwy8ktYAr; Wed, 05 Feb 2003 11:27:13 +0100
Date: Wed, 5 Feb 2003 11:28:54 +0100
Subject: Re: I-D ACTION:draft-hazewinkel-imap-vhost-00.txt (fwd)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v551)
Cc: Harrie Hazewinkel <harrie@inet.it>, IMAP Extensions WG <ietf-imapext@imc.org>, IMAP Discusson List <imap@cac.washington.edu>
To: Cyrus Daboo <daboo@cyrusoft.com>
From: Harrie Hazewinkel <harrie@inet.it>
In-Reply-To: <1542173273.1044271731@[63.163.82.24]>
Message-Id: <A03EBE28-38F4-11D7-A399-0003934A5A7E@inet.it>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.551)
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

On Monday, February 3, 2003, at 05:28 PM, Cyrus Daboo wrote:

> Hi Harrie,
>
> --On Monday, February 3, 2003 9:45 AM +0100 Harrie Hazewinkel 
> <harrie@inet.it> wrote:
>
> | The main reason why I propose this is to seperate the domain from
> | the user identification. I understand that by commbining the two
> | you can have equal usernames int different domains. That is specified
> | in section 'Other considerations'.
> |
> | The benefits I see (maybe should be added in the draft) is that
> | - accounts in a multi domain environment can easier be managed.
> |    While manging an account you only care about the specific domain.
> |    This also allows a simpler and better distributed domain 
> management.
>
> The underlying account system can still separate out account 
> information by domain when domain-in-userid is used.



>
> | - domains can easier be distributed and re-distributed.
> |    When you move a virtual IMAP host to a different host, for the 
> client
> |    does not change. If he was 'forced' to use the VHOST the client
> |    transparantly connects to this new host.
>
> There are already a number of single front-end/multiple backend server 
> architectures that handle moving accounts between different host 
> machines.

This architectures I can immagine, but that is different.
I am here speaking of having a different/multiple front-end, handling 
all
a specific set of domains. With VHOST and doing VHOST forwarding (if I 
may
call it that way) you move a complete host whether it is a virtual host 
is
then not important.

>  We also have RLOGIN and RLIST extension to do referrals to new 
> machines.


>
> | - customers do not see that they are in a multi-domain environment.
> |    (Better for marketing of services.) For them it is no difference
> |    and is like they have there own server.
>
> Of course that is wrong - customers DO have to enter the domain 
> information somewhere in their client so that the client would know 
> what to use for VHOST. In the domain-in-userid approach its a simple 
> matter to 'hide' the concept of the domain by simply telling the user 
> to use their email address as their user id - I think that's a simple 
> enough concept for most users.

That depends. If an IMAP client is to discover the domain from its
server settings it is not needed.

>
> | - Could enable better load-balancing/load-distribution. Not added 
> yet,
> |    but I was thinking of adding 'response codes' to the response.
> |    The response code could indicate to a client that the virtual
> |    IMAP host is not available at the moment, or is moved to another
> |    host (temporarly or permanent). This option could facilitate
> |    a better load-balancing/distribution.
>
> Again front-end/back-end systems, RLOGIN etc already allow provide 
> this.

I cannot find 'RLOGIN' in some RFC or Internet-draft related to
IMAP, but I assume you mean RFC 2193 (referrals) correct??

Just a question to IMAP client vendors. Do all clients understand
referrals??

>
> | This as equal of what HTTP does. HTTP introduced virtual hosting
> | by creating a host-header to indicate, for instance, 
> www.example1.com or
> | www.exaple2.com on a single host. HTTP could also work with a single
> | hostname and adding a directory. For instance,
> | http://server.example.com/www.example1.com and
> | http://server.example.com/ www.exaple2.com.
> | For various reasons virtual hosting was introduced.
>
> That's fine but IMAP already supports virtual hosting using 
> capabilities available in its basic implementation.

I don't see this as such, maybe I am missing something.
I only understand you do need to embed the domain in the user
id of LOGIN or add it to the AUTHENTICATE command.
That is not what I think of virtual hosting.

> || Yes, I understand that clients need to be changed to implement it
> | where one could say little benefit. However, the benefit is on
> | the server side and this feature can is backwards compatible with
> | existing clients or servers.
>
> The domain-in-userid already provides the same benefits with the added 
> advantage of not having to change clients. I'm afraid I still don't 
> see the benefit of VHOST. Perhaps other server vendors can explain 
> existing problems with virtual hosting using domain-in-userid (if > 
> any)?

I agree, the VHOST command has no extreem benefit, but
some environments it would do, IMHO. The referal method is
at an command oriented level and a client could potentially
start jumpiong between the originated server and the referred
server. The VHOST problem would solve this by telling the
complete server is somewhere else in contrary to the per-mailbox
approach.

regards,

Harrie
------------------------------------------------------------------
Author of MOD-SNMP, enabling SNMP management of Apache HTTP server



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h15ANWM21349 for ietf-imapext-bks; Wed, 5 Feb 2003 02:23:32 -0800 (PST)
Received: from mid-1.inet.it (mid-1.inet.it [213.92.5.18]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h15ANUd21344 for <ietf-imapext@imc.org>; Wed, 5 Feb 2003 02:23:31 -0800 (PST)
Received: from  [::ffff:213.92.1.193] by mid-1.inet.it via I-SMTP-4.3.6-430 id ::ffff:213.92.1.193+fkS82X92mjUm; Wed, 05 Feb 2003 11:23:22 +0100
Date: Wed, 5 Feb 2003 11:24:59 +0100
Subject: Re: I-D ACTION:draft-hazewinkel-imap-vhost-00.txt (fwd)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v551)
Cc: Harrie Hazewinkel <harrie@inet.it>, Cyrus Daboo <daboo@cyrusoft.com>, IMAP Extensions WG <ietf-imapext@imc.org>, IMAP Discusson List <imap@cac.washington.edu>
To: Lawrence Greenfield <leg+@andrew.cmu.edu>
From: Harrie Hazewinkel <harrie@inet.it>
In-Reply-To: <5239163.1044282599@majormajor.WV.CC.CMU.EDU>
Message-Id: <142450BA-38F4-11D7-A399-0003934A5A7E@inet.it>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.551)
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

HI,

On Monday, February 3, 2003, at 08:29 PM, Lawrence Greenfield wrote:

>
> --On Monday, February 03, 2003 11:28 AM -0500 Cyrus Daboo 
> <daboo@cyrusoft.com> wrote:
>
>> The domain-in-userid already provides the same benefits with the added
>> advantage of not having to change clients. I'm afraid I still don't 
>> see
>> the benefit of VHOST. Perhaps other server vendors can explain 
>> existing
>> problems with virtual hosting using domain-in-userid (if any)?
>
> The biggest problem with domain-in-userid is that it comes after a 
> STARTTLS, which means that the server doesn't know what certificate to 
> present to the client.

Would that mean you believe a command like VHOST could solve this
problem?? I believe so. (Side effect not noted before by me).


Harrie
------------------------------------------------------------------
Author of MOD-SNMP, enabling SNMP management of Apache HTTP server



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h141gRR18785 for ietf-imapext-bks; Mon, 3 Feb 2003 17:42:27 -0800 (PST)
Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h141gPd18781 for <ietf-imapext@imc.org>; Mon, 3 Feb 2003 17:42:26 -0800 (PST)
Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout4.cac.washington.edu (8.12.1+UW01.12/8.12.1+UW02.12) with ESMTP id h141gMq6013155; Mon, 3 Feb 2003 17:42:22 -0800
Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.12.1+UW01.12/8.12.1+UW02.12) with ESMTP id h141gMup021283 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 3 Feb 2003 17:42:22 -0800
Date: Mon, 3 Feb 2003 17:42:23 -0800 (Pacific Standard Time)
From: Mark Crispin <MRC@cac.washington.edu>
To: Graham Freeman <graham@farwestern.com>
cc: IMAP Extensions WG <ietf-imapext@imc.org>, imap@u.washington.edu
Subject: Re: Misdirected messages
In-Reply-To: <2556531.1044271019@[192.168.0.74]>
Message-ID: <Pine.WNT.4.54.0302031715210.2220@Tomobiki-Cho.CAC.Washington.EDU>
References: <2556531.1044271019@[192.168.0.74]>
Organization: Networks & Distributed Computing
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

I do not enjoy receiving scolding messages, particularly when the scolding
is about something that (1) I did not do and (2) is not under my control.
As I told you a few weeks earlier, when you accused me of bcc'ing the IMAP
list, that nothing of the sort happened.  I was rather surprised when you
then responded that I "obviously" didn't know how to use my mail program.

You have neglected to consider a third possibility: that some mechanism
unique to you or your site is removing the line in the cc that indicates
where the message was sent.

I reviewed the copy I received of the message that you referred to.  In my
copy, the following cc list appears:
	Cc: Harrie Hazewinkel <harrie@inet.it>,
	   IMAP Extensions WG <ietf-imapext@imc.org>,
	   IMAP Discusson List <imap@cac.washington.edu>

You can also review the IMAP mailing list archives on
	ftp://ftp.cac.washington.edu/mail/imap_archive

The addresses "imap@cac.washington.edu" and "imap@u.washington.edu" are
exactly equivalent.  The former is the historical address (thus likely to
be in address books); the latter is the modern address.

Please do not make accusations until you have thoroughly investigated your
local system to make sure that it isn't a problem at your end.

On Mon, 3 Feb 2003, Graham Freeman wrote:
> At least three times in the recent past I've received messages which had
> "ietf-imapext@imc.org" somewhere in the To: or Cc: lines (plus an
> individual or two), but not any list that I'm actually subscribed to.
>
> Based on the headers of these messages, I think that one or both of the
> following are occurring:
> 1) "ietf-imapext@imc.org" has the imap.*washington\.edu list subscribed to
> it.  If so, that's silly - please don't do that.
> OR
> 2) People are putting the imap.*washington\.edu list in the Bcc: field of
> their messages.  If so, please don't do that.  It does more harm than good.
> Instead, put any/all list recipients in the To: or Cc: field.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h13KAbt10609 for ietf-imapext-bks; Mon, 3 Feb 2003 12:10:37 -0800 (PST)
Received: from spork.sendmail.com (spork.Sendmail.COM [209.246.26.39]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h13KAad10603 for <ietf-imapext@imc.org>; Mon, 3 Feb 2003 12:10:36 -0800 (PST)
Received: from katroo.Sendmail.COM (natted.Sendmail.COM [63.211.143.38]) by spork.sendmail.com (Switch-2.2.5/Switch-2.2.4) with ESMTP id h13KALw18360; Mon, 3 Feb 2003 12:10:21 -0800 (PST)
Received: from functor.smi.sendmail.com (functor.smi.sendmail.com [10.210.202.37]) by katroo.Sendmail.COM (8.11.6/8.11.6) with ESMTP id h13KBVV15836; Mon, 3 Feb 2003 12:11:31 -0800 (PST)
Message-Id: <200302032011.h13KBVV15836@katroo.Sendmail.COM>
To: Cyrus Daboo <daboo@cyrusoft.com>
Cc: Harrie Hazewinkel <harrie@inet.it>, IMAP Extensions WG <ietf-imapext@imc.org>, IMAP Discusson List <imap@cac.washington.edu>
Subject: Re: I-D ACTION:draft-hazewinkel-imap-vhost-00.txt (fwd) 
In-reply-to: <1542173273.1044271731@[63.163.82.24]> 
References: <E3377728-3753-11D7-A3AA-0003934A5A7E@inet.it>  <1542173273.1044271731@[63.163.82.24]> 
Date: Mon, 03 Feb 2003 12:01:05 -0800
From: Philip Guenther <guenther@sendmail.com>
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

Cyrus Daboo <daboo@cyrusoft.com> writes:
...
>The domain-in-userid already provides the same benefits with the added 
>advantage of not having to change clients. I'm afraid I still don't see the 
>benefit of VHOST. Perhaps other server vendors can explain existing 
>problems with virtual hosting using domain-in-userid (if any)?

As I see it, the current method has a single defect: ad-hoc parsing of
authentication IDs by servers.  Do you only split on '@' or do you also
fallback to splitting on '%' (for those MUAs that do their *own*
splitting on '@')?

However, that problem is already solved in those SASL mechanism that
pass the a 'realm' value separate from the username, such as DIGEST-MD5,
KERBEROS_V4, GSSAPI, and EXTERNAL w/TLS client certs.

Instead of defining a new command at the IMAP level for passing the
realm, I think would be better to
a) document/standardize common practice; and
b) encourage SASL mechanism designers to pass optional realm information
   separate from the username


Philip Guenther
Sendmail, Inc


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h13Jnqo10137 for ietf-imapext-bks; Mon, 3 Feb 2003 11:49:52 -0800 (PST)
Received: from melkebalanse.gulbrandsen.priv.no (melkebalanse.gulbrandsen.priv.no [217.19.171.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h13Jnod10133 for <ietf-imapext@imc.org>; Mon, 3 Feb 2003 11:49:50 -0800 (PST)
Message-Id: <68XxWxPXB4SK7HJyGdK7+A.md5@melkebalanse.gulbrandsen.priv.no>
From: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
To: Ken Murchison <ken@oceana.com>
Subject: Re: I-D ACTION:draft-hazewinkel-imap-vhost-00.txt (fwd)
Cc: Cyrus Daboo <daboo@cyrusoft.com>, Harrie Hazewinkel <harrie@inet.it>, IMAP Extensions WG <ietf-imapext@imc.org>
References: <E3377728-3753-11D7-A3AA-0003934A5A7E@inet.it> <3E3EC352.E32CE034@oceana.com>
In-Reply-To: <3E3EC352.E32CE034@oceana.com>
Content-Type: text/plain; format=flowed
MIME-Version: 1.0
Date: Mon, 3 Feb 2003 20:52:28 +0100
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

I have one minor issue which hasn't been brought up so far: It 
complicates the state diagram. The proposal adds another 
non-authenticated, which does not seem to be warranted.

--Arnt


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h13JUvW09672 for ietf-imapext-bks; Mon, 3 Feb 2003 11:30:57 -0800 (PST)
Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h13JUtd09668 for <ietf-imapext@imc.org>; Mon, 3 Feb 2003 11:30:56 -0800 (PST)
Received: from oceana.com (ny-kenton4a-b-98.buf.adelphia.net [24.51.29.98]) (authenticated bits=0) by eagle.oceana.com (8.12.7/8.12.7) with ESMTP id h13JUFAi031256 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Mon, 3 Feb 2003 14:30:15 -0500
Message-ID: <3E3EC352.E32CE034@oceana.com>
Date: Mon, 03 Feb 2003 14:30:26 -0500
From: Ken Murchison <ken@oceana.com>
Organization: Oceana Matrix Ltd.
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Harrie Hazewinkel <harrie@inet.it>
CC: Cyrus Daboo <daboo@cyrusoft.com>, IMAP Extensions WG <ietf-imapext@imc.org>
Subject: Re: I-D ACTION:draft-hazewinkel-imap-vhost-00.txt (fwd)
References: <E3377728-3753-11D7-A3AA-0003934A5A7E@inet.it>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

Harrie Hazewinkel wrote:
> 
> HI,
> 
> On Friday, January 31, 2003, at 07:08 PM, Cyrus Daboo wrote:
> [snip]
> ---------- End Forwarded Message ----------
> >
> > Just saw the above draft appear. I think this problem has already been
> > solved for the most part by having domain information expressed in
> > authentication ids. I did not understand the comment in the draft
> > about 'domain in auth-id' creating a 'single level list' and why that
> > is a problem. Can you explain in more detail the benefits that VHOST
> > offers over the 'domain in auth-id' approach? Its worth noting that
> > 'domain in auth-id' works right now without requiring modifications to
> > any clients, whereas VHOST would require client support.
> 
> The main reason why I propose this is to seperate the domain from
> the user identification. I understand that by commbining the two
> you can have equal usernames int different domains. That is specified
> in section 'Other considerations'.


I have two issues with your proposal:

1. The problem that you are trying to solve is an authentication problem
and we shouldn't clutter a message access protocol with commands that
provide "auxillary" authentication info.  This problem should be solved
within the authentication mechanisms already provided by IMAP.

2. There already exists at least two ways of providing the domain info
during authentication.  The first and probably most widely used is by
using fully qualified authids as Cyrus described.  The second would be
to use a SASL mechanism like DIGEST-MD5 in which the server provides a
list of realms that it serves, and the client chooses the one that it
wishes to be in.

My $.02
-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h13JU7B09623 for ietf-imapext-bks; Mon, 3 Feb 2003 11:30:07 -0800 (PST)
Received: from smtp5.andrew.cmu.edu (SMTP5.andrew.cmu.edu [128.2.10.85]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h13JU5d09619 for <ietf-imapext@imc.org>; Mon, 3 Feb 2003 11:30:05 -0800 (PST)
Received: from majormajor.WV.CC.CMU.EDU ([128.2.73.134]) (user=leg mech=GSSAPI (0 bits)) by smtp5.andrew.cmu.edu (8.12.3.Beta2/8.12.3.Beta2) with ESMTP id h13JTwDY005083 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 3 Feb 2003 14:29:58 -0500
Date: Mon, 03 Feb 2003 14:29:59 -0500
From: Lawrence Greenfield <leg+@andrew.cmu.edu>
To: Cyrus Daboo <daboo@cyrusoft.com>, Harrie Hazewinkel <harrie@inet.it>
cc: IMAP Extensions WG <ietf-imapext@imc.org>, IMAP Discusson List <imap@cac.washington.edu>
Subject: Re: I-D ACTION:draft-hazewinkel-imap-vhost-00.txt (fwd)
Message-ID: <5239163.1044282599@majormajor.WV.CC.CMU.EDU>
In-Reply-To: <1542173273.1044271731@[63.163.82.24]>
References: <E3377728-3753-11D7-A3AA-0003934A5A7E@inet.it> <1542173273.1044271731@[63.163.82.24]>
X-Mailer: Mulberry/3.0.0 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

--On Monday, February 03, 2003 11:28 AM -0500 Cyrus Daboo 
<daboo@cyrusoft.com> wrote:

> The domain-in-userid already provides the same benefits with the added
> advantage of not having to change clients. I'm afraid I still don't see
> the benefit of VHOST. Perhaps other server vendors can explain existing
> problems with virtual hosting using domain-in-userid (if any)?

The biggest problem with domain-in-userid is that it comes after a 
STARTTLS, which means that the server doesn't know what certificate to 
present to the client.

Larry



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h13GStp02574 for ietf-imapext-bks; Mon, 3 Feb 2003 08:28:55 -0800 (PST)
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h13GSsd02570 for <ietf-imapext@imc.org>; Mon, 3 Feb 2003 08:28:54 -0800 (PST)
Received: from [63.163.82.24] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id LAA21388; Mon, 3 Feb 2003 11:25:35 -0500 (EST)
Date: Mon, 03 Feb 2003 11:28:51 -0500
From: Cyrus Daboo <daboo@cyrusoft.com>
To: Harrie Hazewinkel <harrie@inet.it>
cc: IMAP Extensions WG <ietf-imapext@imc.org>, IMAP Discusson List <imap@cac.washington.edu>
Subject: Re: I-D ACTION:draft-hazewinkel-imap-vhost-00.txt (fwd)
Message-ID: <1542173273.1044271731@[63.163.82.24]>
In-Reply-To: <E3377728-3753-11D7-A3AA-0003934A5A7E@inet.it>
References:  <E3377728-3753-11D7-A3AA-0003934A5A7E@inet.it>
X-Mailer: Mulberry/3.0.0 (Mac OS/PPC)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

Hi Harrie,

--On Monday, February 3, 2003 9:45 AM +0100 Harrie Hazewinkel 
<harrie@inet.it> wrote:

| The main reason why I propose this is to seperate the domain from
| the user identification. I understand that by commbining the two
| you can have equal usernames int different domains. That is specified
| in section 'Other considerations'.
|
| The benefits I see (maybe should be added in the draft) is that
| - accounts in a multi domain environment can easier be managed.
|    While manging an account you only care about the specific domain.
|    This also allows a simpler and better distributed domain management.

The underlying account system can still separate out account information by 
domain when domain-in-userid is used.

| - domains can easier be distributed and re-distributed.
|    When you move a virtual IMAP host to a different host, for the client
|    does not change. If he was 'forced' to use the VHOST the client
|    transparantly connects to this new host.

There are already a number of single front-end/multiple backend server 
architectures that handle moving accounts between different host machines. 
We also have RLOGIN and RLIST extension to do referrals to new machines.

| - customers do not see that they are in a multi-domain environment.
|    (Better for marketing of services.) For them it is no difference
|    and is like they have there own server.

Of course that is wrong - customers DO have to enter the domain information 
somewhere in their client so that the client would know what to use for 
VHOST. In the domain-in-userid approach its a simple matter to 'hide' the 
concept of the domain by simply telling the user to use their email address 
as their user id - I think that's a simple enough concept for most users.

| - Could enable better load-balancing/load-distribution. Not added yet,
|    but I was thinking of adding 'response codes' to the response.
|    The response code could indicate to a client that the virtual
|    IMAP host is not available at the moment, or is moved to another
|    host (temporarly or permanent). This option could facilitate
|    a better load-balancing/distribution.

Again front-end/back-end systems, RLOGIN etc already allow provide this.

| This as equal of what HTTP does. HTTP introduced virtual hosting
| by creating a host-header to indicate, for instance, www.example1.com or
| www.exaple2.com on a single host. HTTP could also work with a single
| hostname and adding a directory. For instance,
| http://server.example.com/www.example1.com and
| http://server.example.com/ www.exaple2.com.
| For various reasons virtual hosting was introduced.

That's fine but IMAP already supports virtual hosting using capabilities 
available in its basic implementation.

|
| Yes, I understand that clients need to be changed to implement it
| where one could say little benefit. However, the benefit is on
| the server side and this feature can is backwards compatible with
| existing clients or servers.

The domain-in-userid already provides the same benefits with the added 
advantage of not having to change clients. I'm afraid I still don't see the 
benefit of VHOST. Perhaps other server vendors can explain existing 
problems with virtual hosting using domain-in-userid (if any)?

-- 
Cyrus Daboo


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h138iOC01000 for ietf-imapext-bks; Mon, 3 Feb 2003 00:44:24 -0800 (PST)
Received: from hal-5.inet.it (hal-5.inet.it [213.92.5.24]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h138iLd00996 for <ietf-imapext@imc.org>; Mon, 3 Feb 2003 00:44:21 -0800 (PST)
Received: from  [::ffff:213.92.1.193] by hal-5.inet.it via I-SMTP-4.3.6-430 id ::ffff:213.92.1.193+lMAyCmcPTqrU; Mon, 03 Feb 2003 09:44:11 +0100
Date: Mon, 3 Feb 2003 09:45:46 +0100
Subject: Re: I-D ACTION:draft-hazewinkel-imap-vhost-00.txt (fwd)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v551)
Cc: Harrie Hazewinkel <harrie@inet.it>, IMAP Extensions WG <ietf-imapext@imc.org>, IMAP Discusson List <imap@cac.washington.edu>
To: Cyrus Daboo <daboo@cyrusoft.com>
From: Harrie Hazewinkel <harrie@inet.it>
In-Reply-To: <2147483647.1044018480@[63.163.82.24]>
Message-Id: <E3377728-3753-11D7-A3AA-0003934A5A7E@inet.it>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.551)
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

HI,

On Friday, January 31, 2003, at 07:08 PM, Cyrus Daboo wrote:
[snip]
---------- End Forwarded Message ----------
>
> Just saw the above draft appear. I think this problem has already been 
> solved for the most part by having domain information expressed in 
> authentication ids. I did not understand the comment in the draft 
> about 'domain in auth-id' creating a 'single level list' and why that 
> is a problem. Can you explain in more detail the benefits that VHOST 
> offers over the 'domain in auth-id' approach? Its worth noting that 
> 'domain in auth-id' works right now without requiring modifications to 
> any clients, whereas VHOST would require client support.

The main reason why I propose this is to seperate the domain from
the user identification. I understand that by commbining the two
you can have equal usernames int different domains. That is specified
in section 'Other considerations'.

The benefits I see (maybe should be added in the draft) is that
- accounts in a multi domain environment can easier be managed.
   While manging an account you only care about the specific domain.
   This also allows a simpler and better distributed domain management.

- domains can easier be distributed and re-distributed.
   When you move a virtual IMAP host to a different host, for the client
   does not change. If he was 'forced' to use the VHOST the client
   transparantly connects to this new host.

- customers do not see that they are in a multi-domain environment.
   (Better for marketing of services.) For them it is no difference
   and is like they have there own server.

- Could enable better load-balancing/load-distribution. Not added yet,
   but I was thinking of adding 'response codes' to the response.
   The response code could indicate to a client that the virtual
   IMAP host is not available at the moment, or is moved to another
   host (temporarly or permanent). This option could facilitate
   a better load-balancing/distribution.

This as equal of what HTTP does. HTTP introduced virtual hosting
by creating a host-header to indicate, for instance, www.example1.com or
www.exaple2.com on a single host. HTTP could also work with a single
hostname and adding a directory. For instance,
http://server.example.com/www.example1.com and
http://server.example.com/ www.exaple2.com.
For various reasons virtual hosting was introduced.


Yes, I understand that clients need to be changed to implement it
where one could say little benefit. However, the benefit is on
the server side and this feature can is backwards compatible with
existing clients or servers.


regards,
Harrie
------------------------------------------------------------------
Author of MOD-SNMP, enabling SNMP management of Apache HTTP server