Subject: Re: LISTEXT draft
From: Philip Guenther <[email-masked]>
To: Rob Siemborski <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Date: Tue, 29 Jun 2004 15:22:14 -0700
List-Id: <ietf-imapext.imc.org>

Rob Siemborski <[email-masked]> writes:
>On Sun, 27 Jun 2004, Philip Guenther wrote:
...
>> Of course, all returned mailboxes must match the pattern, possibly
>> modified by the reference argument, regardless of whether the named
>> mailbox is selected or a child mailbox is selected.
>
>Why?  IMAP allows for unsolicited LIST responses at any time, just like 
>any other IMAP response.

True enough; perhaps I should have said that a returned mailbox
that doesn't match the pattern is effectively unaffiliated with the
LIST command that preceded it.

Hmm, that also means that LIST (SUBCRIBED) needs to 'mark' the
subscribed mailboxes as such, because it's otherwise ambiguous
whether any given LIST response is of a subscribed mailbox: the
server could just be sending random LIST responses for unsubscribed
mailboxes because it felt like it.  Should it mark them with a "list
flag" or a "list extended item"?

	* LIST (\IsSubscribed) "/" foo
or
	* LIST () "/" foo ((SUBSCRIBED ()))
?

Hmm, this may also tangle with REMOTE, depending on how server
treats a remote mailbox when the REMOTE option isn't used.  Should
a server act like the mailbox doesn't exist, even to the point of
sending \NonExistent, if it's remote but the REMOTE option wasn't
used?  If so, a LIST (REMOTE) could legally result in two different
responses for the same mailbox, say:
	* LIST () "/" foo ((REMOTE "imap:blahblah"))
	* LIST (\NonExistent) "/" foo
that second response being unrelated to the LIST (REMOTE), just
something the server felt like sending.  This complicates any future
effort to have server send LIST responses to indicate changes in
the mailbox hierarchy: you can't just indicate that a mailbox is
no longer there by sending a \NonExistent response, as that's
effectively a no-op for remote mailboxes.  The server would have
to use something like:
	* LIST (\NonExistent) "/" foo ((REMOTE ""))
to mean "it's really gone and doesn't even exist as a remote mailbox"

Philip Guenther

To: [email-masked]
From: [email-masked]
Date: Tue, 29 Jun 2004 15:28:04 -0400
Subject: I-D ACTION:draft-crispin-imap-urlauth-09.txt
Reply-To: [email-masked]
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Internet Message Access Protocol (IMAP) - URLAUTH Extension
	Author(s)	: M. Crispin, C. Newman
	Filename	: draft-crispin-imap-urlauth-09.txt
	Pages		: 8
	Date		: 2004-6-29
	
This document describes the URLAUTH extension to the Internet
Message Access Protocol (IMAP) (RFC 3501) and the IMAP URL Scheme
(IMAPURL) (RFC 2192).  This extension provides a means by which an
IMAP client can create 'signed' URLs which can be used to access
limited message data on the IMAP server.
An IMAP server which supports this extension indicates this with a
capability name of 'URLAUTH'.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-crispin-imap-urlauth-09.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-crispin-imap-urlauth-09.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:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-crispin-imap-urlauth-09.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="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-crispin-imap-urlauth-09.txt

--OtherAccess
Content-Type: Message/External-body; name="draft-crispin-imap-urlauth-09.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

--NextPart--

Date: Tue, 29 Jun 2004 15:10:40 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Philip Guenther <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>, Mark Crispin <[email-masked]>, Ken Murchison <[email-masked]>
Subject: Re: LISTEXT draft 
Sender: [email-masked]

On Sun, 27 Jun 2004, Philip Guenther wrote:

> Alexey Melnikov <[email-masked]> writes:
> ...
>> 2). Clarify that there are only two reasons for including a mailbox in
>> the responses to the LIST command: the mailbox itself may be selected
>> and matched and/or it may have at least one child mailbox that is
>> selected but not matched. If neither of those is true then there's no
>> reason to include a response for the mailbox.
>
> Of course, all returned mailboxes must match the pattern, possibly
> modified by the reference argument, regardless of whether the named
> mailbox is selected or a child mailbox is selected.

Why?  IMAP allows for unsolicited LIST responses at any time, just like 
any other IMAP response.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 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+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y?
------END GEEK CODE BLOCK-----

To: Alexey Melnikov <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>, Mark Crispin <[email-masked]>, Ken Murchison <[email-masked]>
From: Philip Guenther <[email-masked]>
Subject: Re: LISTEXT draft 
Date: Sun, 27 Jun 2004 18:36:01 -0700
Sender: [email-masked]

Alexey Melnikov <[email-masked]> writes:
...
>2). Clarify that there are only two reasons for including a mailbox in 
>the responses to the LIST command: the mailbox itself may be selected 
>and matched and/or it may have at least one child mailbox that is 
>selected but not matched. If neither of those is true then there's no 
>reason to include a response for the mailbox.

Of course, all returned mailboxes must match the pattern, possibly
modified by the reference argument, regardless of whether the named
mailbox is selected or a child mailbox is selected.

...
>Philip originally suggested to use the CHILDREN selection criterion 
>should be used instead of SUBMAILBOXES. I am not so sure about this. 
>Suggestions are welcome.

I have no strong feelings about what name should be used for this; it
merely started from my pondering the differences between \PlaceHolder
and \HasChildren and the observation that, unlike \HasChildren,
\PlaceHolder had a clear definition in the presence of other selection
criteria (in particular, SUBSCRIBED).

...
>(unspecified whether it has any selected and matched children).

This is to leave it up to the implementation what happens if the client
specifies a pattern that can match a mailbox and some, but not all of
its child mailboxes: an implementation could ignore the matched children
when deciding whether the \PlaceHolder or \HasSubmailboxes flag is
needed or it could decide which flag to return based just on whether any
children were matched.  I wouldn't expect this leeway to be a problem
for clients for two reasons:
1) it seems unlikely that a client would use such a pattern normally, and
2) there's only an ambiguity if at last one child mailbox was also
   returned, which probably resolves the real question that the client
   wanted answered.

For example, consider a hierarchy using slash as the delimiter with the
following mailboxes:
	foo2
	foo2/bar1
	foo2/bar2
	quux2/bar2

If the client sends the command
	A01 LIST (SUBMAILBOXES) "" "*2"

then the server MUST include
	* LIST () "/" "foo2/bar2"
	* LIST () "/" "quux2/bar2"
and exactly one of
	* LIST () "/" "foo2"
	* LIST (\HasSubmailboxes) "/" "foo2"
in its response.  It MAY also include
	* LIST (\NonExistent \PlaceHolder) "/" "quux2"

>After all those changes/clarifications, the table shown by Philip becomes:
>
>                       has selected child           returned
>exists     selected  that doesn't match pattern   LISTEXT flags
>---------------------------------------------------------------------------
> no           no               no               no response
>yes           no               no               no response
> no          yes               no               (\NonExistent)
>yes          yes               no               ()
> no           no              yes               (\NonExistent \PlaceHolder)
>yes           no              yes               (\PlaceHolder)
> no          yes              yes               (\NonExistent 
>\HasSubmailboxes)
>yes          yes              yes               (\HasSubmailboxes)

That third column should just be titled "has selected child".

(I'm obviously in favor of this change)

Philip Guenther

Date: Sat, 26 Jun 2004 23:10:55 +0100
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
CC: Philip Guenther <[email-masked]>, Mark Crispin <[email-masked]>, Ken Murchison <[email-masked]>
Subject: Re: LISTEXT draft
Sender: [email-masked]

Alexey Melnikov wrote:

> Philip Guenther wrote:
>
>> [...]
>> For any possible mailbox name that matches a LIST pattern, there
>> are eight possible situations to reflect the three conditions:
>> - does the name exist as a mailbox
>> - does the name match the selection criteria (LISTEXT options)
>> - does the name have at least one child mailbox which exists and
>>  matches the selection criteria, but *doesn't* match the pattern
>>
>>                 has selected child    returned
>> exists        selected    that doesn't match pat.    LISTEXT flags
>> --------------------------------------------------------------------------- 
>>
>>  no           no               no        no response
>> yes           no               no        no response
>>  no          yes               no        (\NonExistent)
>> yes          yes               no        ()
>>  no           no              yes        (???)    <- 1
>> yes           no              yes        (\PlaceHolder)
>>  no          yes              yes        (\NonExistent)
>> yes          yes              yes        ()    <- 2
>>
>>
>> Question #1:
>>   What should be returned in case #1 (line 5) above?  For a concrete
>> example, consider a Cyrus-like server on which the mailbox
>> "Vegis/Squash" was created and subscribed to, and then the "Vegis"
>> mailbox was deleted, removing it completely and _not_ leaving it
>> as a \NoSelect mailbox; should the command
>>     tag LIST (SUBSCRIBED) "" %
>>
>> return a LIST response for "Vegis",
>>
>> and if so, with what flags?
>>
> Hmm, this is a tricky case indeed. IMHO, \PlaceHolder should be 
> returned, as there are submailboxes that conform to the selection 
> criteria, but doesn't match the pattern. It also seems that 
> \NonExistent should be returned as well, as the mailbox doesn't exist. 
> (From the point of view of a client writer: the client need to know 
> which mailboxes should not be selected).
> However, the current definition for \NonExistent is:
> "\NonExistent", that indicates that a mailbox is subscribed to, but 
> does not actually exist.
>
> I am wondering if this definition should be changed to be more 
> generic, for example:
>
> "\NonExistent", that indicates that a mailbox satisfy the selection 
> criterion, but does not actually exist.
>
> But this might be too open ended. Alternatively, the draft can spell 
> out this case specifically and show an example.
> What other people think? 

Philip has found few underspecified cases. After discussing this off 
list with Philip I would propose the following changes to the LISTEXT 
document:

1). Clarify that for any mailbox name only a single LIST response must 
be returned.

2). Clarify that there are only two reasons for including a mailbox in 
the responses to the LIST command: the mailbox itself may be selected 
and matched and/or it may have at least one child mailbox that is 
selected but not matched. If neither of those is true then there's no 
reason to include a response for the mailbox.

3). Add a new selection criterion (e.g. SUBMAILBOXES) that requests that 
\PlaceHolder MUST be returned and MUST be precise.
In the absence of the criterion \PlaceHolder MAY be returned and it is 
not necessary precise.
(Clients need to handle the case when \PlaceHolder is returned and there 
are no submailboxes, as they were deleted/renamed after the LIST 
response was sent, but before the client had a chance to list/access them).

Philip originally suggested to use the CHILDREN selection criterion 
should be used instead of SUBMAILBOXES. I am not so sure about this. 
Suggestions are welcome.

4). Clarify the meaning of \PlaceHolder flag:

\PlaceHolder	mailbox is *not* selected but it has selected children
		(unspecified whether any, all, or none are matched)

Add a new mutually exclusive flag \HasSubmailboxes:

\HasSubmailboxes mailbox is selected *and* has selected children
		(unspecified whether any, all or none are matched)

Absence of both \PlaceHolder and \HasSubmailboxes means that the mailbox matches the selection criterion, but doesn't have any selected but unmatched children  (unspecified whether it has any selected and matched children).

5). Define \NonExistent as follows: "\NonExistent", that indicates that a mailbox satisfy the selection 
criterion, but does not actually exist.

6). Add more examples, clarify edge cases.

=========

After all those changes/clarifications, the table shown by Philip becomes:

                       has selected child           returned
exists     selected  that doesn't match pattern   LISTEXT flags
---------------------------------------------------------------------------
 no           no               no               no response
yes           no               no               no response
 no          yes               no               (\NonExistent)
yes          yes               no               ()
 no           no              yes               (\NonExistent \PlaceHolder)
yes           no              yes               (\PlaceHolder)
 no          yes              yes               (\NonExistent 
\HasSubmailboxes)
yes          yes              yes               (\HasSubmailboxes)

Comments?

Alexey

To: Alexey Melnikov <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
From: Philip Guenther <[email-masked]>
Subject: Re: LISTEXT draft 
Date: Thu, 24 Jun 2004 00:27:15 -0700
Sender: [email-masked]

Alexey Melnikov <[email-masked]> writes:
>
>Alexey Melnikov wrote:
>
>> Hmm, this is a tricky case indeed. IMHO, \PlaceHolder should be 
>> returned, as there are submailboxes that conform to the selection 
>> criteria, but doesn't match the pattern. [...] 
>
>On a related note: I was wondering if it is worth adding a selection 
>criterion saying that \PlaceHolder MUST be returned and MUST be precise?

I support this idea.

Indeed, an accurate version of the \PlaceHolder described in the current
draft could be construed as an improved version of \HasChildren, as it
actually has a well defined meaning when other selection criteria (such
as SUBSCRIBED) are used.

Looking at this another way: is there any objection to the idea that a
server MUST support a 100% accurate version** of \HasChildren to claim
LISTEXT compliancy?

Philip Guenther

** Not necessarily under the name \HasChildren or exactly as described
   in RFC 3348, but the same basic idea of "some mailbox under this one
   has a specified property"

Date: Tue, 22 Jun 2004 16:14:07 +0100
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
CC: Philip Guenther <[email-masked]>
Subject: Re: LISTEXT draft
Sender: [email-masked]

Alexey Melnikov wrote:

> Hmm, this is a tricky case indeed. IMHO, \PlaceHolder should be 
> returned, as there are submailboxes that conform to the selection 
> criteria, but doesn't match the pattern. [...] 

On a related note: I was wondering if it is worth adding a selection 
criterion saying that \PlaceHolder MUST be returned and MUST be precise?

Alexey

Date: Tue, 22 Jun 2004 13:58:19 +0100
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: Changes to LISTEXT draft
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> Alexey Melnikov writes:
>
>> I've updated the LISTEXT draft to use ACAP vendor registry. I will be 
>> sending a new revision shortly. There is also the following text in 
>> the draft now:
>>
>>   Standard LISTEXT option/extended data item names are case   
>> insensitive. Vendor specific LISTEXT option/extended data item   
>> names are case insensitive, if the vendor prefix is omitted. The   
>> vendor prefix itself is not case-sensitive, as it might contain   
>> non-ASCII characters.
>>
>> Does this text make any sense?
>
> A little bit too complex, perhaps? If the client's required to to do 
> case folding for the word föö, surely it can manage to fold the vendor 
> name möö as well.
>
>> What should be done for vendor prefixes that are completely comprised 
>> of ASCII characters? Should IANA be directed to prevent registrations 
>> that are completely in ASCII and only differ in case?
>
> The latter seems to offer a good way out.

The only procedural problem with this is that ACAP vendor registry is 
defined by the ACAP RFC, we don't want to revise it ;-).

Alexey

From: Arnt Gulbrandsen <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Subject: Re: Changes to LISTEXT draft
Cc: IMAP Extensions WG <[email-masked]>
Date: Tue, 22 Jun 2004 14:09:24 +0200
Sender: [email-masked]

Alexey Melnikov writes:
> I've updated the LISTEXT draft to use ACAP vendor registry. I will be 
> sending a new revision shortly. There is also the following text in 
> the draft now:
>
>   Standard LISTEXT option/extended data item names are case 
>   insensitive. Vendor specific LISTEXT option/extended data item 
>   names are case insensitive, if the vendor prefix is omitted. The 
>   vendor prefix itself is not case-sensitive, as it might contain 
>   non-ASCII characters.
>
> Does this text make any sense?

A little bit too complex, perhaps? If the client's required to to do 
case folding for the word föö, surely it can manage to fold the vendor 
name möö as well.

> What should be done for vendor prefixes that are completely comprised 
> of ASCII characters? Should IANA be directed to prevent registrations 
> that are completely in ASCII and only differ in case?

The latter seems to offer a good way out.

Arnt

Date: Mon, 21 Jun 2004 23:20:28 +0100
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Changes to LISTEXT draft
Sender: [email-masked]

I've updated the LISTEXT draft to use ACAP vendor registry. I will be 
sending a new revision shortly.
There is also the following text in the draft now:

   Standard LISTEXT option/extended data item names are case insensitive.
   Vendor specific LISTEXT option/extended data item names are case
   insensitive, if the vendor prefix is omitted. The vendor prefix itself
   is not case-sensitive, as it might contain non-ASCII characters.

Does this text make any sense? What should be done for vendor prefixes 
that are completely comprised of ASCII characters? Should IANA be 
directed to prevent registrations that are completely in ASCII and only 
differ in case?

Alexey

Date: Mon, 21 Jun 2004 22:29:06 +0100
From: Alexey Melnikov <[email-masked]>
To: Philip Guenther <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: LISTEXT draft
Sender: [email-masked]

Philip Guenther wrote:

>Please forgive me the disorganization of this note, I've having a
>hard time finding a good presentation for the thoughts and questions
>in it.  I came up with these questions while trying to figure out
>what it would take to implement LISTEXT in the IMAP server I work
>on.  Having pondered these questions, I understand less than when
>I started.
>
>
>For any possible mailbox name that matches a LIST pattern, there
>are eight possible situations to reflect the three conditions:
>- does the name exist as a mailbox
>- does the name match the selection criteria (LISTEXT options)
>- does the name have at least one child mailbox which exists and
>  matches the selection criteria, but *doesn't* match the pattern
>
>				has selected child	returned
>exists		selected	that doesn't match pat.	LISTEXT flags
>---------------------------------------------------------------------------
>  no		   no		       no		no response
> yes		   no		       no		no response
>  no		  yes		       no		(\NonExistent)
> yes		  yes		       no		()
>  no		   no		      yes		(???)	<- 1
> yes		   no		      yes		(\PlaceHolder)
>  no		  yes		      yes		(\NonExistent)
> yes		  yes		      yes		()	<- 2
>
>
>Question #1:
>   What should be returned in case #1 (line 5) above?  For a concrete
>example, consider a Cyrus-like server on which the mailbox
>"Vegis/Squash" was created and subscribed to, and then the "Vegis"
>mailbox was deleted, removing it completely and _not_ leaving it
>as a \NoSelect mailbox; should the command
>	tag LIST (SUBSCRIBED) "" %
>
>return a LIST response for "Vegis",
>
>and if so, with what flags?
>
Hmm, this is a tricky case indeed. IMHO, \PlaceHolder should be 
returned, as there are submailboxes that conform to the selection 
criteria, but doesn't match the pattern. It also seems that \NonExistent 
should be returned as well, as the mailbox doesn't exist. (From the 
point of view of a client writer: the client need to know which 
mailboxes should not be selected).
However, the current definition for \NonExistent is:
"\NonExistent", that indicates that a mailbox is subscribed to, but does 
not actually exist.

I am wondering if this definition should be changed to be more generic, 
for example:

"\NonExistent", that indicates that a mailbox satisfy the selection 
criterion, but does not actually exist.

But this might be too open ended. Alternatively, the draft can spell out 
this case specifically and show an example.
What other people think?

Alexey

Date: Mon, 21 Jun 2004 22:12:31 +0100
From: Alexey Melnikov <[email-masked]>
To: Lisa Dusseault <[email-masked]>
CC: Ken Murchison <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Collected issues with LISTEXT
Sender: [email-masked]

Lisa Dusseault wrote:

> Going through older mail now that I've reviewed LISTEXT myself, it 
> seems there a couple issues around what status LISTEXT has with 
> respect to two RFCs.  Please give your input if you've got any 
> background with these RFCs ... and let the group know to what extent 
> these RFCs are implemented, and whether the implementors intend to go 
> ahead with LISTEXT.
>
>>> or does LISTEXT automatically give you support for the functionality 
>>> in RFC 2193 and RFC 3348?
>>
>> LISTEXT gives the complete functionality of RFC 3348. However LIST 
>> (REMOTE) only replaces RLIST/RLSUB from RFC 2193, the rest of RFC 
>> 2193 is not affected.
>
> We probably need to be pretty clear about that role, in LISTEXT, 
> before going forward.  Is there general agreement about how LISTEXT 
> relates to RFC2193? 

I proposed earlier to publish a revision of RFC 2193 shortly after 
publishing LISTEXT.
I also wanted to add REFERRAL list data item to LIST response, but I 
don't feel there is any consensus on this. I intend to either publish a 
separate draft for REFERRAL, or fold it into revision of RFC 2193.

If anybody has any comments on this plan, please speak up now.

>>> I don't know, it seemed like common sense to me.  Is LISTEXT going 
>>> to deprecate RFC 3348?
>>
>> I think it effectively does. But does WG wants to officially state 
>> that in LISTEXT?
>
> To me it looks like LISTEXT should deprecate RFC3348, but we 
> definitely need to hear from people with a deeper background. 

As far as I know everybody agrees with this decision.
If anybody want to speak against it, please give your arguments now!

Alexey

Cc: Ken Murchison <[email-masked]>, IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Re: Collected issues with LISTEXT
Date: Sun, 20 Jun 2004 11:56:35 -0700
To: Alexey Melnikov <[email-masked]>
Sender: [email-masked]

Going through older mail now that I've reviewed LISTEXT myself, it 
seems there a couple issues around what status LISTEXT has with respect 
to two RFCs.  Please give your input if you've got any background with 
these RFCs ... and let the group know to what extent these RFCs are 
implemented, and whether the implementors intend to go ahead with 
LISTEXT.

>> or does LISTEXT automatically give you support for the functionality 
>> in RFC 2193 and RFC 3348?
>
> LISTEXT gives the complete functionality of RFC 3348. However LIST 
> (REMOTE) only replaces RLIST/RLSUB from RFC 2193, the rest of RFC 2193 
> is not affected.

We probably need to be pretty clear about that role, in LISTEXT, before 
going forward.  Is there general agreement about how LISTEXT relates to 
RFC2193?

>>
>> I don't know, it seemed like common sense to me.  Is LISTEXT going to 
>> deprecate RFC 3348?
>
> I think it effectively does. But does WG wants to officially state 
> that in LISTEXT?

To me it looks like LISTEXT should deprecate RFC3348, but we definitely 
need to hear from people with a deeper background.

Lisa

To: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: LISTEXT spec
Date: Fri, 18 Jun 2004 16:03:37 -0700
Sender: [email-masked]

I've reviewed the LISTEXT spec & I have only one issue that the authors 
are probably already aware of -- that the definition of PlaceHolder 
needs to be finished.

Otherwise, if the authors are ready for last call, I'll make that 
happen.

Lisa

From: Arnt Gulbrandsen <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Re: draft-ietf-imapext-i18n-03.txt
Cc: Ned Freed <[email-masked]>
Date: Fri, 18 Jun 2004 13:57:26 +0200
Sender: [email-masked]

Arnt Gulbrandsen writes:
> Chris Freeman's

I got that name wrong, didn't I? The sun must have baked my brain. Sorry.

Arnt

From: Arnt Gulbrandsen <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: draft-ietf-imapext-i18n-03.txt
Cc: Ned Freed <[email-masked]>
Date: Fri, 18 Jun 2004 13:55:49 +0200
Sender: [email-masked]

I think I worked through everyone's comments. If there's something I 
missed or you have new comments, please let me know.

Otherwise I'll just lounge in the sun, waiting for Ned Freed (cc:) to 
update Chris Freeman's comparator draft.

Arnt

To: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Fwd: 60th IETF Meeting - DRAFT Agenda
Date: Thu, 17 Jun 2004 10:00:36 -0700
Sender: [email-masked]

--Apple-Mail-12--337229252
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed

Note that IMAPEXT is meeting the afternoon of Monday, Aug 2.  We should 
have a new annotate draft by then, discuss private/shared issues if 
they're still open, and hopefully start some discussion of LISTEXT by 
then ( I still owe a review but others ought to review as well).

Lisa

Begin forwarded message:

> From: [email-masked]
> Date: June 16, 2004 2:49:27 PM PDT
> To: [email-masked], [email-masked]
> Cc: [email-masked]
> Subject: 60th IETF Meeting - DRAFT Agenda
>
>
> Draft Agenda of the Sixtieth IETF
> August 1 - 6, 2004
> As of 6/16/2004
>
> SUNDAY, August 1, 2004
> 1000-1700 IEPG Meeting - Marina 6
> 1200-1900 Registration - Harbor Island Foyer
> 1300-1400 Newcomer's Training  - Grande Ballroom A
> 1300-1500 Editor's Training - Marina 5
> 1300-1500 Intro WG Chairs Training -
> 1500-1700 Security Tutorial - Grande Ballroom A
> 1700-1900 Welcome Reception - Grande Ballroom B/C
>
> MONDAY, August 2, 2004
> 0800-2000 IETF Registration - Harbor Island Foyer
> 0800-0900 Continental Breakfast - Harbor Island Foyer
> 0900-1130 Morning Sessions
> APP   apparea   Applications Open Area Meeting
> GEN   newtrk    New IETF Standards Track Discussion WG
> INT   dnsext    DNS Extensions WG
> OPS   multi6    Site Multihoming for IPv6 WG
> OPS   hubmib    Ethernet Interfaces and Hub MIB WG
> RTG   manet     Mobile Ad-hoc Networks WG
> TSV   xcon      Centralized Conference WG
>
> 1130-1300 Break
> 1300-1500 Afternoon Sessions I
> APP   imapext   Internet Message Access Protocol Extension WG
> INT   rbridge   IP Subnets in Topologies Which are Flexible, Universal 
> and Nice BOF
> IRTF  mobopts   IP Mobility Optimizations
> RTG   forces    Forwarding and Control Element Separation WG
> SEC   perm      Protected Entertainment Rights Management BOF
> TSV   nsis      Next Steps in Signaling WG
>
> 1500-1530 Break (Refreshments provided) - Harbor Island Foyer
> 1530-1730 Afternoon Sessions II
> APP   simple    SIP for Instant Messaging and Presence Leveraging 
> Extensions WG
> GEN   genarea   General Area Open Meeting
> OPS   rmonmib   Remote Network Monitoring WG
> RTG   ospf      Open Shortest Path First WG
> TSV   dccp      Datagram Congestion Control Protocol WG
> TSV   pwe3      Pseudo Wire Emulation Edge to Edge WG
>
> 1730-1930 Break
> 1930-2200 Evening Sessions
> APP   lemonade  Enhancements to Internet email to Support Diverse 
> Service Environments WG
> INT   nemo      Network Mobility WG
> RTG   rtgarea   Routing Area Meeting
> SEC   mobike	IKEv2 Mobility and Multihoming WG
> OPS/  imss/     Internet and Management Support for Storage WG and
>  TSV   ips       IP Storage WG
>
> TUESDAY, August 3, 2004
> 0800-1800 IETF Registration - Harbor Island Foyer
> 0800-0900 Continental Breakfast - Harbor Island Foyer
> 0900-1130 Morning Sessions
> APP   simple    SIP for Instant Messaging and Presence Leveraging 
> Extensions WG
> INT   dhc       Dynamic Host Configuration WG
> IRTF  dtnrg     Delay-tolerant Networking Research Group
> OPS   psamp     Packet Sampling WG
> RTG   ccamp     Common Control and Measurement Plane WG
> TSV   avt       Audio/Video Transport WG
>
> 1130-1300 Break
> 1300-1400 Afternoon Sessions I
> APP   geopriv   Geographic Location/Privacy WG
> OPS   atommib   Atom MIB WG
> RTG   pim       Protocol Independent Multicast WG
> SEC   smime     S/MIME Mail Security WG
> TSV   nsis      Next Steps in Signaling WG
> TSV   speechsc  Speech Services Control WG
>
> 1415-1515 Afternoon Sessions II
> APP   geopriv   Geographic Location/Privacy WG
> INT   magma     Multicast & Anycast Group Membership WG
> OPS   aaa       Authentication, Authorization and Accounting WG
> RTG   vrrp      Virtual Router Redundancy Protocol WG
> SEC   enroll    Credential and Provisioning WG
> TSV   ieprep    Internet Emergency Preparedness WG
>
> 1515-1545 Break (Refreshments provided) - Harbor Island Foyer
> 1545-1645 Afternoon Sessions III
> SEC   sasl      Simple Authentication and Security Layer WG
> TSV   rohc      Robust Header Compression WG
>
> 1700-1800 Afternoon Sessions IV
> APP   ldapbis   LDAP (v3) Revision WG
> TSV   rohc      Robust Header Compression WG
>
>
> WEDNESDAY, August 4, 2004
> 0800-1700 IETF Registration - Harbor Island Foyer
> 0800-0900 Continental Breakfast - Harbor Island Foyer
> 0900-1130 Morning Sessions
> APP   marid     MTA Authorization Records in DNS WG
> INT   eap       Extensible Authentication Protocol WG
> OPS   mboned    MBONE Deployment WG
> SEC   pkix      Public Key Infrastructure WG
> TSV   rddp      Remote Direct Data Placement WG
> TSV   sip       Session Initiation Protocol WG
>
> 1130-1300 Break
> 1300-1500 Afternoon Sessions I	
> IRTF  asrg      Anti Spam Working Group
> OPS   capwap    Control and Provisioning of Wireless Access Points WG
> OPS   dnsop     Domain Name System Operations WG
> SEC   krbwg     Kerberos WG
> TSV   enum      Telephone and Number Mapping WG
> TSV   mmusic    Multiparty Multimedia Session Control WG
>
> 1500-1530 Break (Refreshments provided) - Harbor Island Foyer
> 1530-1730 Afternoon Sessions II
> APP   marid     MTA Authorization Records in DNS WG
> GEN   icar      Improved Cross-Area Review WG
> INT   ipv6      IP Version 6 WG
> OPS   ipfix     IP Flow Export WG
> RTG   isis      IS-IS for IP Internets WG
> SEC   pki4ipsec  Profiling Use of PKI in IPSEC WG
> TSV   avt       Audio/Video Transport WG
>
> 1730-1930 Break
> 1930-2200 Plenary - IETF Business Meeting - Grande Ballroom
>
> 		
> 2230             Late Night Session
> PGP Key Signing
>
>
> THURSDAY, August 5, 2004
> 0800-1700 IETF Registration - Harbor Island Foyer
> 0800-0900 Continental Breakfast - Harbor Island Foyer
> 0900-1130 Morning Sessions	
> INT   hip       Host Identity Protocol WG
> RTG   mpls      Multi Protocol Label Switching WG
> SEC   msec      Multicast Security WG
> TSV   tsvwg     Transport Area Working Group
>
> 1130-1300 Break
> 1300-1500 Afternoon Sessions I
> INT   ipdvb     IP over Digital Video Broadcast WG
> INT   l3vpn     Layer 3 Virtual Private Network WG
> SEC   ltans     Long-Term Archive and Notary WG
> TSV   rserpool  Reliable Server Pooling WG
> TSV   sip       Session Initiation Protocol WG
>
> 1500-1530 Break (Refreshments provided) - Harbor Island Foyer
> 1530-1730 Afternoon Sessions II
> APP   webdav    WWW Distributed Authoring and Versioning WG
> INT   dnsext    DNS Extensions WG
> OPS   grow      Global Routing Operations WG *
> SEC   saag      Open Security Area Directorate
> TSV   sipping   Session Initiation Protocol WG
>
> 1730-1930 Break
> 1930-2200 Plenary  - IETF Planning Meeting - Grande Ballroom
>
>
> Friday, August 6, 2004
> 0800-0900 Continental Breakfast - Harbor Island Foyer
> 0900-1130 Morning Sessions	
> APP   atompub   Atom Publishing Format and Protocol PWG
> OPS   netconf   Network Configuration WG
> RTG   rpsec     Routing Protocol Security Requirements WG
> TSV   sipping   Session Initiation Protocol WG
>

--Apple-Mail-12--337229252
Content-Transfer-Encoding: 7bit
Content-Type: text/enriched;
	charset=US-ASCII

Note that IMAPEXT is meeting the afternoon of Monday, Aug 2.  We
should have a new annotate draft by then, discuss private/shared
issues if they're still open, and hopefully start some discussion of
LISTEXT by then ( I still owe a review but others ought to review as
well).

Lisa

Begin forwarded message:

<excerpt><bold><color><param>0000,0000,0000</param>From:
</color></bold>[email-masked]

<bold><color><param>0000,0000,0000</param>Date: </color></bold>June
16, 2004 2:49:27 PM PDT

<bold><color><param>0000,0000,0000</param>To:
</color></bold>[email-masked], [email-masked]

<bold><color><param>0000,0000,0000</param>Cc:
</color></bold>[email-masked]

<bold><color><param>0000,0000,0000</param>Subject: </color>60th IETF
Meeting - DRAFT Agenda

</bold>

Draft Agenda of the Sixtieth IETF

August 1 - 6, 2004

As of 6/16/2004

SUNDAY, August 1, 2004

1000-1700 IEPG Meeting - Marina 6

1200-1900 Registration - Harbor Island Foyer

1300-1400 Newcomer's Training  - Grande Ballroom A

1300-1500 Editor's Training - Marina 5

1300-1500 Intro WG Chairs Training - 

1500-1700 Security Tutorial - Grande Ballroom A

1700-1900 Welcome Reception - Grande Ballroom B/C

MONDAY, August 2, 2004

0800-2000 IETF Registration - Harbor Island Foyer

0800-0900 Continental Breakfast - Harbor Island Foyer

0900-1130 Morning Sessions 

APP   apparea   Applications Open Area Meeting

GEN   newtrk    New IETF Standards Track Discussion WG

INT   dnsext    DNS Extensions WG

OPS   multi6    Site Multihoming for IPv6 WG

OPS   hubmib    Ethernet Interfaces and Hub MIB WG

RTG   manet     Mobile Ad-hoc Networks WG

TSV   xcon      Centralized Conference WG

1130-1300 Break 

1300-1500 Afternoon Sessions I

APP   imapext   Internet Message Access Protocol Extension WG

INT   rbridge   IP Subnets in Topologies Which are Flexible, Universal
and Nice BOF

IRTF  mobopts   IP Mobility Optimizations

RTG   forces    Forwarding and Control Element Separation WG

SEC   perm      Protected Entertainment Rights Management BOF

TSV   nsis      Next Steps in Signaling WG

1500-1530 Break (Refreshments provided) - Harbor Island Foyer

1530-1730 Afternoon Sessions II

APP   simple    SIP for Instant Messaging and Presence Leveraging
Extensions WG

GEN   genarea   General Area Open Meeting

OPS   rmonmib   Remote Network Monitoring WG

RTG   ospf      Open Shortest Path First WG

TSV   dccp      Datagram Congestion Control Protocol WG

TSV   pwe3      Pseudo Wire Emulation Edge to Edge WG

1730-1930 Break

1930-2200 Evening Sessions

APP   lemonade  Enhancements to Internet email to Support Diverse
Service Environments WG

INT   nemo      Network Mobility WG

RTG   rtgarea   Routing Area Meeting

SEC   mobike	IKEv2 Mobility and Multihoming WG

OPS/  imss/     Internet and Management Support for Storage WG and

 TSV   ips       IP Storage WG

TUESDAY, August 3, 2004

0800-1800 IETF Registration - Harbor Island Foyer

0800-0900 Continental Breakfast - Harbor Island Foyer

0900-1130 Morning Sessions

APP   simple    SIP for Instant Messaging and Presence Leveraging
Extensions WG

INT   dhc       Dynamic Host Configuration WG

IRTF  dtnrg     Delay-tolerant Networking Research Group

OPS   psamp     Packet Sampling WG

RTG   ccamp     Common Control and Measurement Plane WG

TSV   avt       Audio/Video Transport WG

1130-1300 Break

1300-1400 Afternoon Sessions I

APP   geopriv   Geographic Location/Privacy WG

OPS   atommib   Atom MIB WG

RTG   pim       Protocol Independent Multicast WG

SEC   smime     S/MIME Mail Security WG

TSV   nsis      Next Steps in Signaling WG

TSV   speechsc  Speech Services Control WG

1415-1515 Afternoon Sessions II

APP   geopriv   Geographic Location/Privacy WG

INT   magma     Multicast & Anycast Group Membership WG

OPS   aaa       Authentication, Authorization and Accounting WG

RTG   vrrp      Virtual Router Redundancy Protocol WG

SEC   enroll    Credential and Provisioning WG

TSV   ieprep    Internet Emergency Preparedness WG

1515-1545 Break (Refreshments provided) - Harbor Island Foyer

1545-1645 Afternoon Sessions III

SEC   sasl      Simple Authentication and Security Layer WG

TSV   rohc      Robust Header Compression WG

1700-1800 Afternoon Sessions IV

APP   ldapbis   LDAP (v3) Revision WG

TSV   rohc      Robust Header Compression WG

WEDNESDAY, August 4, 2004

0800-1700 IETF Registration - Harbor Island Foyer

0800-0900 Continental Breakfast - Harbor Island Foyer

0900-1130 Morning Sessions

APP   marid     MTA Authorization Records in DNS WG

INT   eap       Extensible Authentication Protocol WG

OPS   mboned    MBONE Deployment WG

SEC   pkix      Public Key Infrastructure WG

TSV   rddp      Remote Direct Data Placement WG

TSV   sip       Session Initiation Protocol WG

1130-1300 Break

1300-1500 Afternoon Sessions I	

IRTF  asrg      Anti Spam Working Group

OPS   capwap    Control and Provisioning of Wireless Access Points WG

OPS   dnsop     Domain Name System Operations WG

SEC   krbwg     Kerberos WG

TSV   enum      Telephone and Number Mapping WG

TSV   mmusic    Multiparty Multimedia Session Control WG

1500-1530 Break (Refreshments provided) - Harbor Island Foyer

1530-1730 Afternoon Sessions II

APP   marid     MTA Authorization Records in DNS WG

GEN   icar      Improved Cross-Area Review WG

INT   ipv6      IP Version 6 WG

OPS   ipfix     IP Flow Export WG

RTG   isis      IS-IS for IP Internets WG

SEC   pki4ipsec  Profiling Use of PKI in IPSEC WG

TSV   avt       Audio/Video Transport WG

1730-1930 Break

1930-2200 Plenary - IETF Business Meeting - Grande Ballroom

		

2230             Late Night Session

PGP Key Signing 

THURSDAY, August 5, 2004

0800-1700 IETF Registration - Harbor Island Foyer

0800-0900 Continental Breakfast - Harbor Island Foyer

0900-1130 Morning Sessions	

INT   hip       Host Identity Protocol WG

RTG   mpls      Multi Protocol Label Switching WG

SEC   msec      Multicast Security WG

TSV   tsvwg     Transport Area Working Group

1130-1300 Break

1300-1500 Afternoon Sessions I

INT   ipdvb     IP over Digital Video Broadcast WG

INT   l3vpn     Layer 3 Virtual Private Network WG

SEC   ltans     Long-Term Archive and Notary WG

TSV   rserpool  Reliable Server Pooling WG

TSV   sip       Session Initiation Protocol WG

1500-1530 Break (Refreshments provided) - Harbor Island Foyer

1530-1730 Afternoon Sessions II

APP   webdav    WWW Distributed Authoring and Versioning WG

INT   dnsext    DNS Extensions WG

OPS   grow      Global Routing Operations WG *

SEC   saag      Open Security Area Directorate

TSV   sipping   Session Initiation Protocol WG

1730-1930 Break

1930-2200 Plenary  - IETF Planning Meeting - Grande Ballroom

Friday, August 6, 2004

0800-0900 Continental Breakfast - Harbor Island Foyer

0900-1130 Morning Sessions	

APP   atompub   Atom Publishing Format and Protocol PWG

OPS   netconf   Network Configuration WG

RTG   rpsec     Routing Protocol Security Requirements WG

TSV   sipping   Session Initiation Protocol WG

</excerpt>
--Apple-Mail-12--337229252--

Cc: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Re: Issues on annotate-09
Date: Tue, 15 Jun 2004 10:31:41 -0700
To: Cyrus Daboo <[email-masked]>
Sender: [email-masked]

You are correct in pointing out all of these issues with the WebDAV 
property model or its equivalents.  We could argue how bad these 
problems are but that depends on the use cases.

Does anybody have any other property privacy schemes to propose?  
Anybody want to try to summarize the pros/cons of the ideas so far, or 
how the schemes relate to the most likely email use cases?  We need 
some more discussion in order to close on this issue.

Lisa

On Jun 15, 2004, at 10:24 AM, Cyrus Daboo wrote:

> Hi Lisa,
>
> --On Tuesday, June 15, 2004 9:27 AM -0700 Lisa Dusseault 
> <[email-masked]> wrote:
>
>>> Registering properties as private or shared is a non-starter in my
>>> opinion. Consider what a server would have to do in a case like that:
>>> the server would have to have some internal table tracking the
>>> private/shared status of each property (as defined in the registry) 
>>> so
>>> that it can determine whether the current user can access that
>>> property. It would be impossible to keep the server up to date with
>>> the registry.
>>
>> You know, this is exactly the way webDAV properties work, so I guess
>> there is a proof by existence.  Servers don't in fact have to keep
>> up-to-date with the standards defining protected properties.  Let's 
>> say
>> the "quota" property is registered in a standard, as a property that 
>> may
>> be read by the owner of the file and is protected from being written 
>> by
>> most users.  Then, if a server does advertise support for the 'quota'
>> draft, then clients can count on the property being protected as 
>> defined.
>> If the server does not advertise support for the 'quota' draft, then
>> clients can set a property with the name 'quota' but it's a dead 
>> property
>> and has no protection and no side-effects.  By definition in WebDAV, 
>> dead
>> properties are subject to regular access control as a group, rather 
>> than
>> special server-mediated protection rules depending on the specific
>> property.
>>
>> To generalize, the property registration scheme works if there's some 
>> way
>> for clients to tell which properties the server knows about and 
>> protects
>> in some way.  If the client knows that the server explicitly protects
>> 'foo' as defined in the registry, then the client can go ahead and use
>> 'foo'.  The client could either ask the server "what are your rules 
>> for
>> protecting 'foo'" or "what properties do you support and protect in 
>> some
>> manner".
>
> What you are suggesting is that every new property defined has to have 
> an associated CAPABILITY response so that the client knows that the 
> server supports it - or (to avoid CAPABILITY bloat but adding another 
> round-trip) a new 'ANNOTATEPROPS' command that returns the list of 
> known properties.
>
> However, how would you deal with the case of a client vendor that 
> wants to implement their own client-specific properties which need 
> varying access control restrictions (some shared, some private)?
>
> Also note that deployment of new versions of IMAP servers (and to a 
> lesser extent clients) tends to take a long time. I don't know how 
> that compares with http/webdav servers, but I would guess admins are 
> more willing to do frequent updates of those. That means that clients 
> that want to use a newly defined property will be stuck waiting on 
> server deployment, rather than being able to use it immediately in an 
> interoperable way.
>
> -- 
> Cyrus Daboo

Date: Tue, 15 Jun 2004 13:24:17 -0400
From: Cyrus Daboo <[email-masked]>
To: Lisa Dusseault <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Issues on annotate-09
Sender: [email-masked]

Hi Lisa,

--On Tuesday, June 15, 2004 9:27 AM -0700 Lisa Dusseault 
<[email-masked]> wrote:

>> Registering properties as private or shared is a non-starter in my
>> opinion. Consider what a server would have to do in a case like that:
>> the server would have to have some internal table tracking the
>> private/shared status of each property (as defined in the registry) so
>> that it can determine whether the current user can access that
>> property. It would be impossible to keep the server up to date with
>> the registry.
>
> You know, this is exactly the way webDAV properties work, so I guess
> there is a proof by existence.  Servers don't in fact have to keep
> up-to-date with the standards defining protected properties.  Let's say
> the "quota" property is registered in a standard, as a property that may
> be read by the owner of the file and is protected from being written by
> most users.  Then, if a server does advertise support for the 'quota'
> draft, then clients can count on the property being protected as defined.
> If the server does not advertise support for the 'quota' draft, then
> clients can set a property with the name 'quota' but it's a dead property
> and has no protection and no side-effects.  By definition in WebDAV, dead
> properties are subject to regular access control as a group, rather than
> special server-mediated protection rules depending on the specific
> property.
>
> To generalize, the property registration scheme works if there's some way
> for clients to tell which properties the server knows about and protects
> in some way.  If the client knows that the server explicitly protects
> 'foo' as defined in the registry, then the client can go ahead and use
> 'foo'.  The client could either ask the server "what are your rules for
> protecting 'foo'" or "what properties do you support and protect in some
> manner".

What you are suggesting is that every new property defined has to have an 
associated CAPABILITY response so that the client knows that the server 
supports it - or (to avoid CAPABILITY bloat but adding another round-trip) 
a new 'ANNOTATEPROPS' command that returns the list of known properties.

However, how would you deal with the case of a client vendor that wants to 
implement their own client-specific properties which need varying access 
control restrictions (some shared, some private)?

Also note that deployment of new versions of IMAP servers (and to a lesser 
extent clients) tends to take a long time. I don't know how that compares 
with http/webdav servers, but I would guess admins are more willing to do 
frequent updates of those. That means that clients that want to use a newly 
defined property will be stuck waiting on server deployment, rather than 
being able to use it immediately in an interoperable way.

-- 
Cyrus Daboo

Cc: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Re: Issues on annotate-09
Date: Tue, 15 Jun 2004 09:27:29 -0700
To: Cyrus Daboo <[email-masked]>
Sender: [email-masked]

>
> Registering properties as private or shared is a non-starter in my 
> opinion. Consider what a server would have to do in a case like that: 
> the server would have to have some internal table tracking the 
> private/shared status of each property (as defined in the registry) so 
> that it can determine whether the current user can access that 
> property. It would be impossible to keep the server up to date with 
> the registry.

You know, this is exactly the way webDAV properties work, so I guess 
there is a proof by existence.  Servers don't in fact have to keep 
up-to-date with the standards defining protected properties.  Let's say 
the "quota" property is registered in a standard, as a property that 
may be read by the owner of the file and is protected from being 
written by most users.  Then, if a server does advertise support for 
the 'quota' draft, then clients can count on the property being 
protected as defined. If the server does not advertise support for the 
'quota' draft, then clients can set a property with the name 'quota' 
but it's a dead property and has no protection and no side-effects.  By 
definition in WebDAV, dead properties are subject to regular access 
control as a group, rather than special server-mediated protection 
rules depending on the specific property.

To generalize, the property registration scheme works if there's some 
way for clients to tell which properties the server knows about and 
protects in some way.  If the client knows that the server explicitly 
protects 'foo' as defined in the registry, then the client can go ahead 
and use 'foo'.  The client could either ask the server "what are your 
rules for protecting 'foo'" or "what properties do you support and 
protect in some manner".

Lisa

To: IMAP Extensions WG <[email-masked]>
From: Philip Guenther <[email-masked]>
Subject: LISTEXT draft
Date: Tue, 08 Jun 2004 05:35:29 -0700
Sender: [email-masked]

Please forgive me the disorganization of this note, I've having a
hard time finding a good presentation for the thoughts and questions
in it.  I came up with these questions while trying to figure out
what it would take to implement LISTEXT in the IMAP server I work
on.  Having pondered these questions, I understand less than when
I started.

For any possible mailbox name that matches a LIST pattern, there
are eight possible situations to reflect the three conditions:
- does the name exist as a mailbox
- does the name match the selection criteria (LISTEXT options)
- does the name have at least one child mailbox which exists and
  matches the selection criteria, but *doesn't* match the pattern

				has selected child	returned
exists		selected	that doesn't match	LISTEXT flags
---------------------------------------------------------------------------
  no		   no		       no		no response
 yes		   no		       no		no response
  no		  yes		       no		(\NonExistent)
 yes		  yes		       no		()
  no		   no		      yes		(???)	<- 1
 yes		   no		      yes		(\PlaceHolder)
  no		  yes		      yes		(\NonExistent)
 yes		  yes		      yes		()	<- 2

Question #1:
   What should be returned in case #1 (line 5) above?  For a concrete
example, consider a Cyrus-like server on which the mailbox
"Vegis/Squash" was created and subscribed to, and then the "Vegis"
mailbox was deleted, removing it completely and _not_ leaving it
as a \NoSelect mailbox; should the command
	tag LIST (SUBSCRIBED) "" %

return a LIST response for "Vegis", and if so, with what flags?

Question #2:
  In the past, it has been argued that LSUB should return two
responses for a given name, one with \NoSelect and one without, if
the name was both subscribed and had subscribed children that did
not match the pattern, i.e., line 8 in the table above.  Others
have disagreed with this reading of RFC 3501.  Can LISTEXT please
state how a server should respond in that situation?  That is,
should the server send a response with the \PlaceHolder flag and
one without, or just one response?  (Maintainers of IMAP clients
should speak up here...)

Question #3:
  The LISTEXT syntax permits an empty options list, e.g.,
	tag LIST () "" %

Does that mean the "selection criteria" is "does the mailbox exist"?
Should the cited command return a LIST response for "Vegis", and
if so, with what flags?

Question #4:
  Consider the last four lines of the table at top.  Should any of
the responses change if the mailbox *also* has a selected child
that *does* match the pattern?

Question #5:
  Do any of your answers change if the pattern is "Veg%" instead of "%"?
What if the pattern is "Vegis"?

Philip Guenther
[email-masked]

Date: Mon, 07 Jun 2004 16:40:16 -0400
From: Cyrus Daboo <[email-masked]>
To: Lisa Dusseault <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Annotate draft comments
Sender: [email-masked]

Hi Lisa,

--On Wednesday, June 2, 2004 1:58 PM -0700 Lisa Dusseault 
<[email-masked]> wrote:

>
>
> Discussion kind of died down on my comments on the annotate draft.  Does
> anybody see a consensus on the private/public stuff, which generated the
> most discussion?  (this is also an invitation for other people to chime
> in who haven't already).  Do the authors plan another draft?
>
> Lisa
>

Here is the list of issues I have since the last draft came out:

1) Private/shared debate: this issue is still open. I think it would be 
useful if those proposing a change could clarify their positions given the 
recent debate.

2) Language attribute: I agree this should be present for any value that 
represents text that can be displayed to the user. There is no need for it 
for numeric or enumerated (boolean) values such as flags. I will add text 
for that.

3) Missing IANA registrations: I will add those.

4) Clarification of /comment and /altsubject. I will add those. However, I 
am somewhat unsure of exactly what requirements /altsubject places on 
clients - so if anyone else can suggest those that would be handy.

5) Security considerations inadequate: perhaps someone could suggest better 
text for that or point out other areas in ANNOTATE that the current text 
does not mention.

I would like to wait for the private/shared issue to be resolved before 
putting out another draft, but if we think that will take a while, I will 
go ahead and do a new draft with the other changes soon.

-- 
Cyrus Daboo

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-i18n-03.txt
Date: Mon, 07 Jun 2004 15:42:51 -0400
Sender: [email-masked]

--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		: Internet Message Access Protocol Internationalization
	Author(s)	: C. Newman, A. Gulbrandsen
	Filename	: draft-ietf-imapext-i18n-03.txt
	Pages		: 17
	Date		: 2004-6-7
	
Internet Message Access Protocol (IMAP) version 4rev1 has basic
    support for non-ASCII characters in mailbox names and search
    substrings.  It also supports non-ASCII message headers and content
    encoded as specified by Multipurpose Internet Mail Extensions
    (MIME).  This specification defines a collection of IMAP extensions
    which improve international support including comparator negotiation
    for search, sort and thread, language negotiation for international
    error text, and translations for namespace prefixes.

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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-i18n-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:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-imapext-i18n-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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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

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

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Sat, 05 Jun 2004 09:57:17 +0100
From: Alexey Melnikov <[email-masked]>
To: Lisa Dusseault <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: Annotate draft comments
Sender: [email-masked]

Lisa Dusseault wrote:

> Discussion kind of died down on my comments on the annotate draft.

We need to collect all issues in one place.

> Does anybody see a consensus on the private/public stuff, which 
> generated the most discussion?  (this is also an invitation for other 
> people to chime in who haven't already).

I think we've agreed to add more description about annotations like 
altsubject.

I think there is no consensus to change existing private/public 
annotation model, as described by Cyrus recently.

>   Do the authors plan another draft?
>
> Lisa

Alexey

To: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Annotate draft comments
Date: Wed, 2 Jun 2004 13:58:43 -0700
Sender: [email-masked]

Discussion kind of died down on my comments on the annotate draft.  
Does anybody see a consensus on the private/public stuff, which 
generated the most discussion?  (this is also an invitation for other 
people to chime in who haven't already).  Do the authors plan another 
draft?

Lisa

Date: Tue, 1 Jun 2004 08:24:31 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: [email-masked]
Subject: Re: imapext-i18n draft
Sender: [email-masked]

On Tue, 1 Jun 2004, Arnt Gulbrandsen wrote:
> If noone screams and stamps their feet, section 4.5 will die. Last warning 
> now.

Yes!  Death to 4.5.

-- Mark --

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

From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: imapext-i18n draft
Date: Tue, 1 Jun 2004 16:48:03 +0200
Sender: [email-masked]

Hi,

there's been a new draft there for a few days, incorporating suggestions 
and addressing concerns from various people.

If noone screams and stamps their feet, section 4.5 will die. Last warning now.

I'd like to know whether you all think the example in section 4.3 is 
sensible. I like it and it seems in tune with the (currently expired) 
comparator draft.

I can add some more examples if anyone thinks it's called for.

Arnt

To: Rob Siemborski <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
From: Philip Guenther <[email-masked]>
Subject: Re: LISTEXT draft 
Date: Tue, 29 Jun 2004 15:22:14 -0700
Sender: [email-masked]

Rob Siemborski <[email-masked]> writes:
>On Sun, 27 Jun 2004, Philip Guenther wrote:
...
>> Of course, all returned mailboxes must match the pattern, possibly
>> modified by the reference argument, regardless of whether the named
>> mailbox is selected or a child mailbox is selected.
>
>Why?  IMAP allows for unsolicited LIST responses at any time, just like 
>any other IMAP response.

True enough; perhaps I should have said that a returned mailbox
that doesn't match the pattern is effectively unaffiliated with the
LIST command that preceded it.

Hmm, that also means that LIST (SUBCRIBED) needs to 'mark' the
subscribed mailboxes as such, because it's otherwise ambiguous
whether any given LIST response is of a subscribed mailbox: the
server could just be sending random LIST responses for unsubscribed
mailboxes because it felt like it.  Should it mark them with a "list
flag" or a "list extended item"?

	* LIST (\IsSubscribed) "/" foo
or
	* LIST () "/" foo ((SUBSCRIBED ()))
?

Hmm, this may also tangle with REMOTE, depending on how server
treats a remote mailbox when the REMOTE option isn't used.  Should
a server act like the mailbox doesn't exist, even to the point of
sending \NonExistent, if it's remote but the REMOTE option wasn't
used?  If so, a LIST (REMOTE) could legally result in two different
responses for the same mailbox, say:
	* LIST () "/" foo ((REMOTE "imap:blahblah"))
	* LIST (\NonExistent) "/" foo
that second response being unrelated to the LIST (REMOTE), just
something the server felt like sending.  This complicates any future
effort to have server send LIST responses to indicate changes in
the mailbox hierarchy: you can't just indicate that a mailbox is
no longer there by sending a \NonExistent response, as that's
effectively a no-op for remote mailboxes.  The server would have
to use something like:
	* LIST (\NonExistent) "/" foo ((REMOTE ""))
to mean "it's really gone and doesn't even exist as a remote mailbox"

Philip Guenther

To: [email-masked]
From: [email-masked]
Date: Tue, 29 Jun 2004 15:28:04 -0400
Subject: I-D ACTION:draft-crispin-imap-urlauth-09.txt
Reply-To: [email-masked]
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Internet Message Access Protocol (IMAP) - URLAUTH Extension
	Author(s)	: M. Crispin, C. Newman
	Filename	: draft-crispin-imap-urlauth-09.txt
	Pages		: 8
	Date		: 2004-6-29
	
This document describes the URLAUTH extension to the Internet
Message Access Protocol (IMAP) (RFC 3501) and the IMAP URL Scheme
(IMAPURL) (RFC 2192).  This extension provides a means by which an
IMAP client can create 'signed' URLs which can be used to access
limited message data on the IMAP server.
An IMAP server which supports this extension indicates this with a
capability name of 'URLAUTH'.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-crispin-imap-urlauth-09.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-crispin-imap-urlauth-09.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:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-crispin-imap-urlauth-09.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="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-crispin-imap-urlauth-09.txt

--OtherAccess
Content-Type: Message/External-body; name="draft-crispin-imap-urlauth-09.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

--NextPart--

Date: Tue, 29 Jun 2004 15:10:40 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Philip Guenther <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>, Mark Crispin <[email-masked]>, Ken Murchison <[email-masked]>
Subject: Re: LISTEXT draft 
Sender: [email-masked]

On Sun, 27 Jun 2004, Philip Guenther wrote:

> Alexey Melnikov <[email-masked]> writes:
> ...
>> 2). Clarify that there are only two reasons for including a mailbox in
>> the responses to the LIST command: the mailbox itself may be selected
>> and matched and/or it may have at least one child mailbox that is
>> selected but not matched. If neither of those is true then there's no
>> reason to include a response for the mailbox.
>
> Of course, all returned mailboxes must match the pattern, possibly
> modified by the reference argument, regardless of whether the named
> mailbox is selected or a child mailbox is selected.

Why?  IMAP allows for unsolicited LIST responses at any time, just like 
any other IMAP response.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 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+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y?
------END GEEK CODE BLOCK-----

To: Alexey Melnikov <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>, Mark Crispin <[email-masked]>, Ken Murchison <[email-masked]>
From: Philip Guenther <[email-masked]>
Subject: Re: LISTEXT draft 
Date: Sun, 27 Jun 2004 18:36:01 -0700
Sender: [email-masked]

Alexey Melnikov <[email-masked]> writes:
...
>2). Clarify that there are only two reasons for including a mailbox in 
>the responses to the LIST command: the mailbox itself may be selected 
>and matched and/or it may have at least one child mailbox that is 
>selected but not matched. If neither of those is true then there's no 
>reason to include a response for the mailbox.

Of course, all returned mailboxes must match the pattern, possibly
modified by the reference argument, regardless of whether the named
mailbox is selected or a child mailbox is selected.

...
>Philip originally suggested to use the CHILDREN selection criterion 
>should be used instead of SUBMAILBOXES. I am not so sure about this. 
>Suggestions are welcome.

I have no strong feelings about what name should be used for this; it
merely started from my pondering the differences between \PlaceHolder
and \HasChildren and the observation that, unlike \HasChildren,
\PlaceHolder had a clear definition in the presence of other selection
criteria (in particular, SUBSCRIBED).

...
>(unspecified whether it has any selected and matched children).

This is to leave it up to the implementation what happens if the client
specifies a pattern that can match a mailbox and some, but not all of
its child mailboxes: an implementation could ignore the matched children
when deciding whether the \PlaceHolder or \HasSubmailboxes flag is
needed or it could decide which flag to return based just on whether any
children were matched.  I wouldn't expect this leeway to be a problem
for clients for two reasons:
1) it seems unlikely that a client would use such a pattern normally, and
2) there's only an ambiguity if at last one child mailbox was also
   returned, which probably resolves the real question that the client
   wanted answered.

For example, consider a hierarchy using slash as the delimiter with the
following mailboxes:
	foo2
	foo2/bar1
	foo2/bar2
	quux2/bar2

If the client sends the command
	A01 LIST (SUBMAILBOXES) "" "*2"

then the server MUST include
	* LIST () "/" "foo2/bar2"
	* LIST () "/" "quux2/bar2"
and exactly one of
	* LIST () "/" "foo2"
	* LIST (\HasSubmailboxes) "/" "foo2"
in its response.  It MAY also include
	* LIST (\NonExistent \PlaceHolder) "/" "quux2"

>After all those changes/clarifications, the table shown by Philip becomes:
>
>                       has selected child           returned
>exists     selected  that doesn't match pattern   LISTEXT flags
>---------------------------------------------------------------------------
> no           no               no               no response
>yes           no               no               no response
> no          yes               no               (\NonExistent)
>yes          yes               no               ()
> no           no              yes               (\NonExistent \PlaceHolder)
>yes           no              yes               (\PlaceHolder)
> no          yes              yes               (\NonExistent 
>\HasSubmailboxes)
>yes          yes              yes               (\HasSubmailboxes)

That third column should just be titled "has selected child".

(I'm obviously in favor of this change)

Philip Guenther

Date: Sat, 26 Jun 2004 23:10:55 +0100
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
CC: Philip Guenther <[email-masked]>, Mark Crispin <[email-masked]>, Ken Murchison <[email-masked]>
Subject: Re: LISTEXT draft
Sender: [email-masked]

Alexey Melnikov wrote:

> Philip Guenther wrote:
>
>> [...]
>> For any possible mailbox name that matches a LIST pattern, there
>> are eight possible situations to reflect the three conditions:
>> - does the name exist as a mailbox
>> - does the name match the selection criteria (LISTEXT options)
>> - does the name have at least one child mailbox which exists and
>>  matches the selection criteria, but *doesn't* match the pattern
>>
>>                 has selected child    returned
>> exists        selected    that doesn't match pat.    LISTEXT flags
>> --------------------------------------------------------------------------- 
>>
>>  no           no               no        no response
>> yes           no               no        no response
>>  no          yes               no        (\NonExistent)
>> yes          yes               no        ()
>>  no           no              yes        (???)    <- 1
>> yes           no              yes        (\PlaceHolder)
>>  no          yes              yes        (\NonExistent)
>> yes          yes              yes        ()    <- 2
>>
>>
>> Question #1:
>>   What should be returned in case #1 (line 5) above?  For a concrete
>> example, consider a Cyrus-like server on which the mailbox
>> "Vegis/Squash" was created and subscribed to, and then the "Vegis"
>> mailbox was deleted, removing it completely and _not_ leaving it
>> as a \NoSelect mailbox; should the command
>>     tag LIST (SUBSCRIBED) "" %
>>
>> return a LIST response for "Vegis",
>>
>> and if so, with what flags?
>>
> Hmm, this is a tricky case indeed. IMHO, \PlaceHolder should be 
> returned, as there are submailboxes that conform to the selection 
> criteria, but doesn't match the pattern. It also seems that 
> \NonExistent should be returned as well, as the mailbox doesn't exist. 
> (From the point of view of a client writer: the client need to know 
> which mailboxes should not be selected).
> However, the current definition for \NonExistent is:
> "\NonExistent", that indicates that a mailbox is subscribed to, but 
> does not actually exist.
>
> I am wondering if this definition should be changed to be more 
> generic, for example:
>
> "\NonExistent", that indicates that a mailbox satisfy the selection 
> criterion, but does not actually exist.
>
> But this might be too open ended. Alternatively, the draft can spell 
> out this case specifically and show an example.
> What other people think? 

Philip has found few underspecified cases. After discussing this off 
list with Philip I would propose the following changes to the LISTEXT 
document:

1). Clarify that for any mailbox name only a single LIST response must 
be returned.

2). Clarify that there are only two reasons for including a mailbox in 
the responses to the LIST command: the mailbox itself may be selected 
and matched and/or it may have at least one child mailbox that is 
selected but not matched. If neither of those is true then there's no 
reason to include a response for the mailbox.

3). Add a new selection criterion (e.g. SUBMAILBOXES) that requests that 
\PlaceHolder MUST be returned and MUST be precise.
In the absence of the criterion \PlaceHolder MAY be returned and it is 
not necessary precise.
(Clients need to handle the case when \PlaceHolder is returned and there 
are no submailboxes, as they were deleted/renamed after the LIST 
response was sent, but before the client had a chance to list/access them).

Philip originally suggested to use the CHILDREN selection criterion 
should be used instead of SUBMAILBOXES. I am not so sure about this. 
Suggestions are welcome.

4). Clarify the meaning of \PlaceHolder flag:

\PlaceHolder	mailbox is *not* selected but it has selected children
		(unspecified whether any, all, or none are matched)

Add a new mutually exclusive flag \HasSubmailboxes:

\HasSubmailboxes mailbox is selected *and* has selected children
		(unspecified whether any, all or none are matched)

Absence of both \PlaceHolder and \HasSubmailboxes means that the mailbox matches the selection criterion, but doesn't have any selected but unmatched children  (unspecified whether it has any selected and matched children).

5). Define \NonExistent as follows: "\NonExistent", that indicates that a mailbox satisfy the selection 
criterion, but does not actually exist.

6). Add more examples, clarify edge cases.

=========

After all those changes/clarifications, the table shown by Philip becomes:

                       has selected child           returned
exists     selected  that doesn't match pattern   LISTEXT flags
---------------------------------------------------------------------------
 no           no               no               no response
yes           no               no               no response
 no          yes               no               (\NonExistent)
yes          yes               no               ()
 no           no              yes               (\NonExistent \PlaceHolder)
yes           no              yes               (\PlaceHolder)
 no          yes              yes               (\NonExistent 
\HasSubmailboxes)
yes          yes              yes               (\HasSubmailboxes)

Comments?

Alexey

To: Alexey Melnikov <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
From: Philip Guenther <[email-masked]>
Subject: Re: LISTEXT draft 
Date: Thu, 24 Jun 2004 00:27:15 -0700
Sender: [email-masked]

Alexey Melnikov <[email-masked]> writes:
>
>Alexey Melnikov wrote:
>
>> Hmm, this is a tricky case indeed. IMHO, \PlaceHolder should be 
>> returned, as there are submailboxes that conform to the selection 
>> criteria, but doesn't match the pattern. [...] 
>
>On a related note: I was wondering if it is worth adding a selection 
>criterion saying that \PlaceHolder MUST be returned and MUST be precise?

I support this idea.

Indeed, an accurate version of the \PlaceHolder described in the current
draft could be construed as an improved version of \HasChildren, as it
actually has a well defined meaning when other selection criteria (such
as SUBSCRIBED) are used.

Looking at this another way: is there any objection to the idea that a
server MUST support a 100% accurate version** of \HasChildren to claim
LISTEXT compliancy?

Philip Guenther

** Not necessarily under the name \HasChildren or exactly as described
   in RFC 3348, but the same basic idea of "some mailbox under this one
   has a specified property"

Date: Tue, 22 Jun 2004 16:14:07 +0100
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
CC: Philip Guenther <[email-masked]>
Subject: Re: LISTEXT draft
Sender: [email-masked]

Alexey Melnikov wrote:

> Hmm, this is a tricky case indeed. IMHO, \PlaceHolder should be 
> returned, as there are submailboxes that conform to the selection 
> criteria, but doesn't match the pattern. [...] 

On a related note: I was wondering if it is worth adding a selection 
criterion saying that \PlaceHolder MUST be returned and MUST be precise?

Alexey

Date: Tue, 22 Jun 2004 13:58:19 +0100
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: Changes to LISTEXT draft
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> Alexey Melnikov writes:
>
>> I've updated the LISTEXT draft to use ACAP vendor registry. I will be 
>> sending a new revision shortly. There is also the following text in 
>> the draft now:
>>
>>   Standard LISTEXT option/extended data item names are case   
>> insensitive. Vendor specific LISTEXT option/extended data item   
>> names are case insensitive, if the vendor prefix is omitted. The   
>> vendor prefix itself is not case-sensitive, as it might contain   
>> non-ASCII characters.
>>
>> Does this text make any sense?
>
> A little bit too complex, perhaps? If the client's required to to do 
> case folding for the word föö, surely it can manage to fold the vendor 
> name möö as well.
>
>> What should be done for vendor prefixes that are completely comprised 
>> of ASCII characters? Should IANA be directed to prevent registrations 
>> that are completely in ASCII and only differ in case?
>
> The latter seems to offer a good way out.

The only procedural problem with this is that ACAP vendor registry is 
defined by the ACAP RFC, we don't want to revise it ;-).

Alexey

From: Arnt Gulbrandsen <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Subject: Re: Changes to LISTEXT draft
Cc: IMAP Extensions WG <[email-masked]>
Date: Tue, 22 Jun 2004 14:09:24 +0200
Sender: [email-masked]

Alexey Melnikov writes:
> I've updated the LISTEXT draft to use ACAP vendor registry. I will be 
> sending a new revision shortly. There is also the following text in 
> the draft now:
>
>   Standard LISTEXT option/extended data item names are case 
>   insensitive. Vendor specific LISTEXT option/extended data item 
>   names are case insensitive, if the vendor prefix is omitted. The 
>   vendor prefix itself is not case-sensitive, as it might contain 
>   non-ASCII characters.
>
> Does this text make any sense?

A little bit too complex, perhaps? If the client's required to to do 
case folding for the word föö, surely it can manage to fold the vendor 
name möö as well.

> What should be done for vendor prefixes that are completely comprised 
> of ASCII characters? Should IANA be directed to prevent registrations 
> that are completely in ASCII and only differ in case?

The latter seems to offer a good way out.

Arnt

Date: Mon, 21 Jun 2004 23:20:28 +0100
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Changes to LISTEXT draft
Sender: [email-masked]

I've updated the LISTEXT draft to use ACAP vendor registry. I will be 
sending a new revision shortly.
There is also the following text in the draft now:

   Standard LISTEXT option/extended data item names are case insensitive.
   Vendor specific LISTEXT option/extended data item names are case
   insensitive, if the vendor prefix is omitted. The vendor prefix itself
   is not case-sensitive, as it might contain non-ASCII characters.

Does this text make any sense? What should be done for vendor prefixes 
that are completely comprised of ASCII characters? Should IANA be 
directed to prevent registrations that are completely in ASCII and only 
differ in case?

Alexey

Date: Mon, 21 Jun 2004 22:29:06 +0100
From: Alexey Melnikov <[email-masked]>
To: Philip Guenther <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: LISTEXT draft
Sender: [email-masked]

Philip Guenther wrote:

>Please forgive me the disorganization of this note, I've having a
>hard time finding a good presentation for the thoughts and questions
>in it.  I came up with these questions while trying to figure out
>what it would take to implement LISTEXT in the IMAP server I work
>on.  Having pondered these questions, I understand less than when
>I started.
>
>
>For any possible mailbox name that matches a LIST pattern, there
>are eight possible situations to reflect the three conditions:
>- does the name exist as a mailbox
>- does the name match the selection criteria (LISTEXT options)
>- does the name have at least one child mailbox which exists and
>  matches the selection criteria, but *doesn't* match the pattern
>
>				has selected child	returned
>exists		selected	that doesn't match pat.	LISTEXT flags
>---------------------------------------------------------------------------
>  no		   no		       no		no response
> yes		   no		       no		no response
>  no		  yes		       no		(\NonExistent)
> yes		  yes		       no		()
>  no		   no		      yes		(???)	<- 1
> yes		   no		      yes		(\PlaceHolder)
>  no		  yes		      yes		(\NonExistent)
> yes		  yes		      yes		()	<- 2
>
>
>Question #1:
>   What should be returned in case #1 (line 5) above?  For a concrete
>example, consider a Cyrus-like server on which the mailbox
>"Vegis/Squash" was created and subscribed to, and then the "Vegis"
>mailbox was deleted, removing it completely and _not_ leaving it
>as a \NoSelect mailbox; should the command
>	tag LIST (SUBSCRIBED) "" %
>
>return a LIST response for "Vegis",
>
>and if so, with what flags?
>
Hmm, this is a tricky case indeed. IMHO, \PlaceHolder should be 
returned, as there are submailboxes that conform to the selection 
criteria, but doesn't match the pattern. It also seems that \NonExistent 
should be returned as well, as the mailbox doesn't exist. (From the 
point of view of a client writer: the client need to know which 
mailboxes should not be selected).
However, the current definition for \NonExistent is:
"\NonExistent", that indicates that a mailbox is subscribed to, but does 
not actually exist.

I am wondering if this definition should be changed to be more generic, 
for example:

"\NonExistent", that indicates that a mailbox satisfy the selection 
criterion, but does not actually exist.

But this might be too open ended. Alternatively, the draft can spell out 
this case specifically and show an example.
What other people think?

Alexey

Date: Mon, 21 Jun 2004 22:12:31 +0100
From: Alexey Melnikov <[email-masked]>
To: Lisa Dusseault <[email-masked]>
CC: Ken Murchison <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Collected issues with LISTEXT
Sender: [email-masked]

Lisa Dusseault wrote:

> Going through older mail now that I've reviewed LISTEXT myself, it 
> seems there a couple issues around what status LISTEXT has with 
> respect to two RFCs.  Please give your input if you've got any 
> background with these RFCs ... and let the group know to what extent 
> these RFCs are implemented, and whether the implementors intend to go 
> ahead with LISTEXT.
>
>>> or does LISTEXT automatically give you support for the functionality 
>>> in RFC 2193 and RFC 3348?
>>
>> LISTEXT gives the complete functionality of RFC 3348. However LIST 
>> (REMOTE) only replaces RLIST/RLSUB from RFC 2193, the rest of RFC 
>> 2193 is not affected.
>
> We probably need to be pretty clear about that role, in LISTEXT, 
> before going forward.  Is there general agreement about how LISTEXT 
> relates to RFC2193? 

I proposed earlier to publish a revision of RFC 2193 shortly after 
publishing LISTEXT.
I also wanted to add REFERRAL list data item to LIST response, but I 
don't feel there is any consensus on this. I intend to either publish a 
separate draft for REFERRAL, or fold it into revision of RFC 2193.

If anybody has any comments on this plan, please speak up now.

>>> I don't know, it seemed like common sense to me.  Is LISTEXT going 
>>> to deprecate RFC 3348?
>>
>> I think it effectively does. But does WG wants to officially state 
>> that in LISTEXT?
>
> To me it looks like LISTEXT should deprecate RFC3348, but we 
> definitely need to hear from people with a deeper background. 

As far as I know everybody agrees with this decision.
If anybody want to speak against it, please give your arguments now!

Alexey

Cc: Ken Murchison <[email-masked]>, IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Re: Collected issues with LISTEXT
Date: Sun, 20 Jun 2004 11:56:35 -0700
To: Alexey Melnikov <[email-masked]>
Sender: [email-masked]

Going through older mail now that I've reviewed LISTEXT myself, it 
seems there a couple issues around what status LISTEXT has with respect 
to two RFCs.  Please give your input if you've got any background with 
these RFCs ... and let the group know to what extent these RFCs are 
implemented, and whether the implementors intend to go ahead with 
LISTEXT.

>> or does LISTEXT automatically give you support for the functionality 
>> in RFC 2193 and RFC 3348?
>
> LISTEXT gives the complete functionality of RFC 3348. However LIST 
> (REMOTE) only replaces RLIST/RLSUB from RFC 2193, the rest of RFC 2193 
> is not affected.

We probably need to be pretty clear about that role, in LISTEXT, before 
going forward.  Is there general agreement about how LISTEXT relates to 
RFC2193?

>>
>> I don't know, it seemed like common sense to me.  Is LISTEXT going to 
>> deprecate RFC 3348?
>
> I think it effectively does. But does WG wants to officially state 
> that in LISTEXT?

To me it looks like LISTEXT should deprecate RFC3348, but we definitely 
need to hear from people with a deeper background.

Lisa

To: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: LISTEXT spec
Date: Fri, 18 Jun 2004 16:03:37 -0700
Sender: [email-masked]

I've reviewed the LISTEXT spec & I have only one issue that the authors 
are probably already aware of -- that the definition of PlaceHolder 
needs to be finished.

Otherwise, if the authors are ready for last call, I'll make that 
happen.

Lisa

From: Arnt Gulbrandsen <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Re: draft-ietf-imapext-i18n-03.txt
Cc: Ned Freed <[email-masked]>
Date: Fri, 18 Jun 2004 13:57:26 +0200
Sender: [email-masked]

Arnt Gulbrandsen writes:
> Chris Freeman's

I got that name wrong, didn't I? The sun must have baked my brain. Sorry.

Arnt

From: Arnt Gulbrandsen <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: draft-ietf-imapext-i18n-03.txt
Cc: Ned Freed <[email-masked]>
Date: Fri, 18 Jun 2004 13:55:49 +0200
Sender: [email-masked]

I think I worked through everyone's comments. If there's something I 
missed or you have new comments, please let me know.

Otherwise I'll just lounge in the sun, waiting for Ned Freed (cc:) to 
update Chris Freeman's comparator draft.

Arnt

To: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Fwd: 60th IETF Meeting - DRAFT Agenda
Date: Thu, 17 Jun 2004 10:00:36 -0700
Sender: [email-masked]

--Apple-Mail-12--337229252
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed

Note that IMAPEXT is meeting the afternoon of Monday, Aug 2.  We should 
have a new annotate draft by then, discuss private/shared issues if 
they're still open, and hopefully start some discussion of LISTEXT by 
then ( I still owe a review but others ought to review as well).

Lisa

Begin forwarded message:

> From: [email-masked]
> Date: June 16, 2004 2:49:27 PM PDT
> To: [email-masked], [email-masked]
> Cc: [email-masked]
> Subject: 60th IETF Meeting - DRAFT Agenda
>
>
> Draft Agenda of the Sixtieth IETF
> August 1 - 6, 2004
> As of 6/16/2004
>
> SUNDAY, August 1, 2004
> 1000-1700 IEPG Meeting - Marina 6
> 1200-1900 Registration - Harbor Island Foyer
> 1300-1400 Newcomer's Training  - Grande Ballroom A
> 1300-1500 Editor's Training - Marina 5
> 1300-1500 Intro WG Chairs Training -
> 1500-1700 Security Tutorial - Grande Ballroom A
> 1700-1900 Welcome Reception - Grande Ballroom B/C
>
> MONDAY, August 2, 2004
> 0800-2000 IETF Registration - Harbor Island Foyer
> 0800-0900 Continental Breakfast - Harbor Island Foyer
> 0900-1130 Morning Sessions
> APP   apparea   Applications Open Area Meeting
> GEN   newtrk    New IETF Standards Track Discussion WG
> INT   dnsext    DNS Extensions WG
> OPS   multi6    Site Multihoming for IPv6 WG
> OPS   hubmib    Ethernet Interfaces and Hub MIB WG
> RTG   manet     Mobile Ad-hoc Networks WG
> TSV   xcon      Centralized Conference WG
>
> 1130-1300 Break
> 1300-1500 Afternoon Sessions I
> APP   imapext   Internet Message Access Protocol Extension WG
> INT   rbridge   IP Subnets in Topologies Which are Flexible, Universal 
> and Nice BOF
> IRTF  mobopts   IP Mobility Optimizations
> RTG   forces    Forwarding and Control Element Separation WG
> SEC   perm      Protected Entertainment Rights Management BOF
> TSV   nsis      Next Steps in Signaling WG
>
> 1500-1530 Break (Refreshments provided) - Harbor Island Foyer
> 1530-1730 Afternoon Sessions II
> APP   simple    SIP for Instant Messaging and Presence Leveraging 
> Extensions WG
> GEN   genarea   General Area Open Meeting
> OPS   rmonmib   Remote Network Monitoring WG
> RTG   ospf      Open Shortest Path First WG
> TSV   dccp      Datagram Congestion Control Protocol WG
> TSV   pwe3      Pseudo Wire Emulation Edge to Edge WG
>
> 1730-1930 Break
> 1930-2200 Evening Sessions
> APP   lemonade  Enhancements to Internet email to Support Diverse 
> Service Environments WG
> INT   nemo      Network Mobility WG
> RTG   rtgarea   Routing Area Meeting
> SEC   mobike	IKEv2 Mobility and Multihoming WG
> OPS/  imss/     Internet and Management Support for Storage WG and
>  TSV   ips       IP Storage WG
>
> TUESDAY, August 3, 2004
> 0800-1800 IETF Registration - Harbor Island Foyer
> 0800-0900 Continental Breakfast - Harbor Island Foyer
> 0900-1130 Morning Sessions
> APP   simple    SIP for Instant Messaging and Presence Leveraging 
> Extensions WG
> INT   dhc       Dynamic Host Configuration WG
> IRTF  dtnrg     Delay-tolerant Networking Research Group
> OPS   psamp     Packet Sampling WG
> RTG   ccamp     Common Control and Measurement Plane WG
> TSV   avt       Audio/Video Transport WG
>
> 1130-1300 Break
> 1300-1400 Afternoon Sessions I
> APP   geopriv   Geographic Location/Privacy WG
> OPS   atommib   Atom MIB WG
> RTG   pim       Protocol Independent Multicast WG
> SEC   smime     S/MIME Mail Security WG
> TSV   nsis      Next Steps in Signaling WG
> TSV   speechsc  Speech Services Control WG
>
> 1415-1515 Afternoon Sessions II
> APP   geopriv   Geographic Location/Privacy WG
> INT   magma     Multicast & Anycast Group Membership WG
> OPS   aaa       Authentication, Authorization and Accounting WG
> RTG   vrrp      Virtual Router Redundancy Protocol WG
> SEC   enroll    Credential and Provisioning WG
> TSV   ieprep    Internet Emergency Preparedness WG
>
> 1515-1545 Break (Refreshments provided) - Harbor Island Foyer
> 1545-1645 Afternoon Sessions III
> SEC   sasl      Simple Authentication and Security Layer WG
> TSV   rohc      Robust Header Compression WG
>
> 1700-1800 Afternoon Sessions IV
> APP   ldapbis   LDAP (v3) Revision WG
> TSV   rohc      Robust Header Compression WG
>
>
> WEDNESDAY, August 4, 2004
> 0800-1700 IETF Registration - Harbor Island Foyer
> 0800-0900 Continental Breakfast - Harbor Island Foyer
> 0900-1130 Morning Sessions
> APP   marid     MTA Authorization Records in DNS WG
> INT   eap       Extensible Authentication Protocol WG
> OPS   mboned    MBONE Deployment WG
> SEC   pkix      Public Key Infrastructure WG
> TSV   rddp      Remote Direct Data Placement WG
> TSV   sip       Session Initiation Protocol WG
>
> 1130-1300 Break
> 1300-1500 Afternoon Sessions I	
> IRTF  asrg      Anti Spam Working Group
> OPS   capwap    Control and Provisioning of Wireless Access Points WG
> OPS   dnsop     Domain Name System Operations WG
> SEC   krbwg     Kerberos WG
> TSV   enum      Telephone and Number Mapping WG
> TSV   mmusic    Multiparty Multimedia Session Control WG
>
> 1500-1530 Break (Refreshments provided) - Harbor Island Foyer
> 1530-1730 Afternoon Sessions II
> APP   marid     MTA Authorization Records in DNS WG
> GEN   icar      Improved Cross-Area Review WG
> INT   ipv6      IP Version 6 WG
> OPS   ipfix     IP Flow Export WG
> RTG   isis      IS-IS for IP Internets WG
> SEC   pki4ipsec  Profiling Use of PKI in IPSEC WG
> TSV   avt       Audio/Video Transport WG
>
> 1730-1930 Break
> 1930-2200 Plenary - IETF Business Meeting - Grande Ballroom
>
> 		
> 2230             Late Night Session
> PGP Key Signing
>
>
> THURSDAY, August 5, 2004
> 0800-1700 IETF Registration - Harbor Island Foyer
> 0800-0900 Continental Breakfast - Harbor Island Foyer
> 0900-1130 Morning Sessions	
> INT   hip       Host Identity Protocol WG
> RTG   mpls      Multi Protocol Label Switching WG
> SEC   msec      Multicast Security WG
> TSV   tsvwg     Transport Area Working Group
>
> 1130-1300 Break
> 1300-1500 Afternoon Sessions I
> INT   ipdvb     IP over Digital Video Broadcast WG
> INT   l3vpn     Layer 3 Virtual Private Network WG
> SEC   ltans     Long-Term Archive and Notary WG
> TSV   rserpool  Reliable Server Pooling WG
> TSV   sip       Session Initiation Protocol WG
>
> 1500-1530 Break (Refreshments provided) - Harbor Island Foyer
> 1530-1730 Afternoon Sessions II
> APP   webdav    WWW Distributed Authoring and Versioning WG
> INT   dnsext    DNS Extensions WG
> OPS   grow      Global Routing Operations WG *
> SEC   saag      Open Security Area Directorate
> TSV   sipping   Session Initiation Protocol WG
>
> 1730-1930 Break
> 1930-2200 Plenary  - IETF Planning Meeting - Grande Ballroom
>
>
> Friday, August 6, 2004
> 0800-0900 Continental Breakfast - Harbor Island Foyer
> 0900-1130 Morning Sessions	
> APP   atompub   Atom Publishing Format and Protocol PWG
> OPS   netconf   Network Configuration WG
> RTG   rpsec     Routing Protocol Security Requirements WG
> TSV   sipping   Session Initiation Protocol WG
>

--Apple-Mail-12--337229252
Content-Transfer-Encoding: 7bit
Content-Type: text/enriched;
	charset=US-ASCII

Note that IMAPEXT is meeting the afternoon of Monday, Aug 2.  We
should have a new annotate draft by then, discuss private/shared
issues if they're still open, and hopefully start some discussion of
LISTEXT by then ( I still owe a review but others ought to review as
well).

Lisa

Begin forwarded message:

<excerpt><bold><color><param>0000,0000,0000</param>From:
</color></bold>[email-masked]

<bold><color><param>0000,0000,0000</param>Date: </color></bold>June
16, 2004 2:49:27 PM PDT

<bold><color><param>0000,0000,0000</param>To:
</color></bold>[email-masked], [email-masked]

<bold><color><param>0000,0000,0000</param>Cc:
</color></bold>[email-masked]

<bold><color><param>0000,0000,0000</param>Subject: </color>60th IETF
Meeting - DRAFT Agenda

</bold>

Draft Agenda of the Sixtieth IETF

August 1 - 6, 2004

As of 6/16/2004

SUNDAY, August 1, 2004

1000-1700 IEPG Meeting - Marina 6

1200-1900 Registration - Harbor Island Foyer

1300-1400 Newcomer's Training  - Grande Ballroom A

1300-1500 Editor's Training - Marina 5

1300-1500 Intro WG Chairs Training - 

1500-1700 Security Tutorial - Grande Ballroom A

1700-1900 Welcome Reception - Grande Ballroom B/C

MONDAY, August 2, 2004

0800-2000 IETF Registration - Harbor Island Foyer

0800-0900 Continental Breakfast - Harbor Island Foyer

0900-1130 Morning Sessions 

APP   apparea   Applications Open Area Meeting

GEN   newtrk    New IETF Standards Track Discussion WG

INT   dnsext    DNS Extensions WG

OPS   multi6    Site Multihoming for IPv6 WG

OPS   hubmib    Ethernet Interfaces and Hub MIB WG

RTG   manet     Mobile Ad-hoc Networks WG

TSV   xcon      Centralized Conference WG

1130-1300 Break 

1300-1500 Afternoon Sessions I

APP   imapext   Internet Message Access Protocol Extension WG

INT   rbridge   IP Subnets in Topologies Which are Flexible, Universal
and Nice BOF

IRTF  mobopts   IP Mobility Optimizations

RTG   forces    Forwarding and Control Element Separation WG

SEC   perm      Protected Entertainment Rights Management BOF

TSV   nsis      Next Steps in Signaling WG

1500-1530 Break (Refreshments provided) - Harbor Island Foyer

1530-1730 Afternoon Sessions II

APP   simple    SIP for Instant Messaging and Presence Leveraging
Extensions WG

GEN   genarea   General Area Open Meeting

OPS   rmonmib   Remote Network Monitoring WG

RTG   ospf      Open Shortest Path First WG

TSV   dccp      Datagram Congestion Control Protocol WG

TSV   pwe3      Pseudo Wire Emulation Edge to Edge WG

1730-1930 Break

1930-2200 Evening Sessions

APP   lemonade  Enhancements to Internet email to Support Diverse
Service Environments WG

INT   nemo      Network Mobility WG

RTG   rtgarea   Routing Area Meeting

SEC   mobike	IKEv2 Mobility and Multihoming WG

OPS/  imss/     Internet and Management Support for Storage WG and

 TSV   ips       IP Storage WG

TUESDAY, August 3, 2004

0800-1800 IETF Registration - Harbor Island Foyer

0800-0900 Continental Breakfast - Harbor Island Foyer

0900-1130 Morning Sessions

APP   simple    SIP for Instant Messaging and Presence Leveraging
Extensions WG

INT   dhc       Dynamic Host Configuration WG

IRTF  dtnrg     Delay-tolerant Networking Research Group

OPS   psamp     Packet Sampling WG

RTG   ccamp     Common Control and Measurement Plane WG

TSV   avt       Audio/Video Transport WG

1130-1300 Break

1300-1400 Afternoon Sessions I

APP   geopriv   Geographic Location/Privacy WG

OPS   atommib   Atom MIB WG

RTG   pim       Protocol Independent Multicast WG

SEC   smime     S/MIME Mail Security WG

TSV   nsis      Next Steps in Signaling WG

TSV   speechsc  Speech Services Control WG

1415-1515 Afternoon Sessions II

APP   geopriv   Geographic Location/Privacy WG

INT   magma     Multicast & Anycast Group Membership WG

OPS   aaa       Authentication, Authorization and Accounting WG

RTG   vrrp      Virtual Router Redundancy Protocol WG

SEC   enroll    Credential and Provisioning WG

TSV   ieprep    Internet Emergency Preparedness WG

1515-1545 Break (Refreshments provided) - Harbor Island Foyer

1545-1645 Afternoon Sessions III

SEC   sasl      Simple Authentication and Security Layer WG

TSV   rohc      Robust Header Compression WG

1700-1800 Afternoon Sessions IV

APP   ldapbis   LDAP (v3) Revision WG

TSV   rohc      Robust Header Compression WG

WEDNESDAY, August 4, 2004

0800-1700 IETF Registration - Harbor Island Foyer

0800-0900 Continental Breakfast - Harbor Island Foyer

0900-1130 Morning Sessions

APP   marid     MTA Authorization Records in DNS WG

INT   eap       Extensible Authentication Protocol WG

OPS   mboned    MBONE Deployment WG

SEC   pkix      Public Key Infrastructure WG

TSV   rddp      Remote Direct Data Placement WG

TSV   sip       Session Initiation Protocol WG

1130-1300 Break

1300-1500 Afternoon Sessions I	

IRTF  asrg      Anti Spam Working Group

OPS   capwap    Control and Provisioning of Wireless Access Points WG

OPS   dnsop     Domain Name System Operations WG

SEC   krbwg     Kerberos WG

TSV   enum      Telephone and Number Mapping WG

TSV   mmusic    Multiparty Multimedia Session Control WG

1500-1530 Break (Refreshments provided) - Harbor Island Foyer

1530-1730 Afternoon Sessions II

APP   marid     MTA Authorization Records in DNS WG

GEN   icar      Improved Cross-Area Review WG

INT   ipv6      IP Version 6 WG

OPS   ipfix     IP Flow Export WG

RTG   isis      IS-IS for IP Internets WG

SEC   pki4ipsec  Profiling Use of PKI in IPSEC WG

TSV   avt       Audio/Video Transport WG

1730-1930 Break

1930-2200 Plenary - IETF Business Meeting - Grande Ballroom

		

2230             Late Night Session

PGP Key Signing 

THURSDAY, August 5, 2004

0800-1700 IETF Registration - Harbor Island Foyer

0800-0900 Continental Breakfast - Harbor Island Foyer

0900-1130 Morning Sessions	

INT   hip       Host Identity Protocol WG

RTG   mpls      Multi Protocol Label Switching WG

SEC   msec      Multicast Security WG

TSV   tsvwg     Transport Area Working Group

1130-1300 Break

1300-1500 Afternoon Sessions I

INT   ipdvb     IP over Digital Video Broadcast WG

INT   l3vpn     Layer 3 Virtual Private Network WG

SEC   ltans     Long-Term Archive and Notary WG

TSV   rserpool  Reliable Server Pooling WG

TSV   sip       Session Initiation Protocol WG

1500-1530 Break (Refreshments provided) - Harbor Island Foyer

1530-1730 Afternoon Sessions II

APP   webdav    WWW Distributed Authoring and Versioning WG

INT   dnsext    DNS Extensions WG

OPS   grow      Global Routing Operations WG *

SEC   saag      Open Security Area Directorate

TSV   sipping   Session Initiation Protocol WG

1730-1930 Break

1930-2200 Plenary  - IETF Planning Meeting - Grande Ballroom

Friday, August 6, 2004

0800-0900 Continental Breakfast - Harbor Island Foyer

0900-1130 Morning Sessions	

APP   atompub   Atom Publishing Format and Protocol PWG

OPS   netconf   Network Configuration WG

RTG   rpsec     Routing Protocol Security Requirements WG

TSV   sipping   Session Initiation Protocol WG

</excerpt>
--Apple-Mail-12--337229252--

Cc: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Re: Issues on annotate-09
Date: Tue, 15 Jun 2004 10:31:41 -0700
To: Cyrus Daboo <[email-masked]>
Sender: [email-masked]

You are correct in pointing out all of these issues with the WebDAV 
property model or its equivalents.  We could argue how bad these 
problems are but that depends on the use cases.

Does anybody have any other property privacy schemes to propose?  
Anybody want to try to summarize the pros/cons of the ideas so far, or 
how the schemes relate to the most likely email use cases?  We need 
some more discussion in order to close on this issue.

Lisa

On Jun 15, 2004, at 10:24 AM, Cyrus Daboo wrote:

> Hi Lisa,
>
> --On Tuesday, June 15, 2004 9:27 AM -0700 Lisa Dusseault 
> <[email-masked]> wrote:
>
>>> Registering properties as private or shared is a non-starter in my
>>> opinion. Consider what a server would have to do in a case like that:
>>> the server would have to have some internal table tracking the
>>> private/shared status of each property (as defined in the registry) 
>>> so
>>> that it can determine whether the current user can access that
>>> property. It would be impossible to keep the server up to date with
>>> the registry.
>>
>> You know, this is exactly the way webDAV properties work, so I guess
>> there is a proof by existence.  Servers don't in fact have to keep
>> up-to-date with the standards defining protected properties.  Let's 
>> say
>> the "quota" property is registered in a standard, as a property that 
>> may
>> be read by the owner of the file and is protected from being written 
>> by
>> most users.  Then, if a server does advertise support for the 'quota'
>> draft, then clients can count on the property being protected as 
>> defined.
>> If the server does not advertise support for the 'quota' draft, then
>> clients can set a property with the name 'quota' but it's a dead 
>> property
>> and has no protection and no side-effects.  By definition in WebDAV, 
>> dead
>> properties are subject to regular access control as a group, rather 
>> than
>> special server-mediated protection rules depending on the specific
>> property.
>>
>> To generalize, the property registration scheme works if there's some 
>> way
>> for clients to tell which properties the server knows about and 
>> protects
>> in some way.  If the client knows that the server explicitly protects
>> 'foo' as defined in the registry, then the client can go ahead and use
>> 'foo'.  The client could either ask the server "what are your rules 
>> for
>> protecting 'foo'" or "what properties do you support and protect in 
>> some
>> manner".
>
> What you are suggesting is that every new property defined has to have 
> an associated CAPABILITY response so that the client knows that the 
> server supports it - or (to avoid CAPABILITY bloat but adding another 
> round-trip) a new 'ANNOTATEPROPS' command that returns the list of 
> known properties.
>
> However, how would you deal with the case of a client vendor that 
> wants to implement their own client-specific properties which need 
> varying access control restrictions (some shared, some private)?
>
> Also note that deployment of new versions of IMAP servers (and to a 
> lesser extent clients) tends to take a long time. I don't know how 
> that compares with http/webdav servers, but I would guess admins are 
> more willing to do frequent updates of those. That means that clients 
> that want to use a newly defined property will be stuck waiting on 
> server deployment, rather than being able to use it immediately in an 
> interoperable way.
>
> -- 
> Cyrus Daboo

Date: Tue, 15 Jun 2004 13:24:17 -0400
From: Cyrus Daboo <[email-masked]>
To: Lisa Dusseault <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Issues on annotate-09
Sender: [email-masked]

Hi Lisa,

--On Tuesday, June 15, 2004 9:27 AM -0700 Lisa Dusseault 
<[email-masked]> wrote:

>> Registering properties as private or shared is a non-starter in my
>> opinion. Consider what a server would have to do in a case like that:
>> the server would have to have some internal table tracking the
>> private/shared status of each property (as defined in the registry) so
>> that it can determine whether the current user can access that
>> property. It would be impossible to keep the server up to date with
>> the registry.
>
> You know, this is exactly the way webDAV properties work, so I guess
> there is a proof by existence.  Servers don't in fact have to keep
> up-to-date with the standards defining protected properties.  Let's say
> the "quota" property is registered in a standard, as a property that may
> be read by the owner of the file and is protected from being written by
> most users.  Then, if a server does advertise support for the 'quota'
> draft, then clients can count on the property being protected as defined.
> If the server does not advertise support for the 'quota' draft, then
> clients can set a property with the name 'quota' but it's a dead property
> and has no protection and no side-effects.  By definition in WebDAV, dead
> properties are subject to regular access control as a group, rather than
> special server-mediated protection rules depending on the specific
> property.
>
> To generalize, the property registration scheme works if there's some way
> for clients to tell which properties the server knows about and protects
> in some way.  If the client knows that the server explicitly protects
> 'foo' as defined in the registry, then the client can go ahead and use
> 'foo'.  The client could either ask the server "what are your rules for
> protecting 'foo'" or "what properties do you support and protect in some
> manner".

What you are suggesting is that every new property defined has to have an 
associated CAPABILITY response so that the client knows that the server 
supports it - or (to avoid CAPABILITY bloat but adding another round-trip) 
a new 'ANNOTATEPROPS' command that returns the list of known properties.

However, how would you deal with the case of a client vendor that wants to 
implement their own client-specific properties which need varying access 
control restrictions (some shared, some private)?

Also note that deployment of new versions of IMAP servers (and to a lesser 
extent clients) tends to take a long time. I don't know how that compares 
with http/webdav servers, but I would guess admins are more willing to do 
frequent updates of those. That means that clients that want to use a newly 
defined property will be stuck waiting on server deployment, rather than 
being able to use it immediately in an interoperable way.

-- 
Cyrus Daboo

Cc: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Re: Issues on annotate-09
Date: Tue, 15 Jun 2004 09:27:29 -0700
To: Cyrus Daboo <[email-masked]>
Sender: [email-masked]

>
> Registering properties as private or shared is a non-starter in my 
> opinion. Consider what a server would have to do in a case like that: 
> the server would have to have some internal table tracking the 
> private/shared status of each property (as defined in the registry) so 
> that it can determine whether the current user can access that 
> property. It would be impossible to keep the server up to date with 
> the registry.

You know, this is exactly the way webDAV properties work, so I guess 
there is a proof by existence.  Servers don't in fact have to keep 
up-to-date with the standards defining protected properties.  Let's say 
the "quota" property is registered in a standard, as a property that 
may be read by the owner of the file and is protected from being 
written by most users.  Then, if a server does advertise support for 
the 'quota' draft, then clients can count on the property being 
protected as defined. If the server does not advertise support for the 
'quota' draft, then clients can set a property with the name 'quota' 
but it's a dead property and has no protection and no side-effects.  By 
definition in WebDAV, dead properties are subject to regular access 
control as a group, rather than special server-mediated protection 
rules depending on the specific property.

To generalize, the property registration scheme works if there's some 
way for clients to tell which properties the server knows about and 
protects in some way.  If the client knows that the server explicitly 
protects 'foo' as defined in the registry, then the client can go ahead 
and use 'foo'.  The client could either ask the server "what are your 
rules for protecting 'foo'" or "what properties do you support and 
protect in some manner".

Lisa

To: IMAP Extensions WG <[email-masked]>
From: Philip Guenther <[email-masked]>
Subject: LISTEXT draft
Date: Tue, 08 Jun 2004 05:35:29 -0700
Sender: [email-masked]

Please forgive me the disorganization of this note, I've having a
hard time finding a good presentation for the thoughts and questions
in it.  I came up with these questions while trying to figure out
what it would take to implement LISTEXT in the IMAP server I work
on.  Having pondered these questions, I understand less than when
I started.

For any possible mailbox name that matches a LIST pattern, there
are eight possible situations to reflect the three conditions:
- does the name exist as a mailbox
- does the name match the selection criteria (LISTEXT options)
- does the name have at least one child mailbox which exists and
  matches the selection criteria, but *doesn't* match the pattern

				has selected child	returned
exists		selected	that doesn't match	LISTEXT flags
---------------------------------------------------------------------------
  no		   no		       no		no response
 yes		   no		       no		no response
  no		  yes		       no		(\NonExistent)
 yes		  yes		       no		()
  no		   no		      yes		(???)	<- 1
 yes		   no		      yes		(\PlaceHolder)
  no		  yes		      yes		(\NonExistent)
 yes		  yes		      yes		()	<- 2

Question #1:
   What should be returned in case #1 (line 5) above?  For a concrete
example, consider a Cyrus-like server on which the mailbox
"Vegis/Squash" was created and subscribed to, and then the "Vegis"
mailbox was deleted, removing it completely and _not_ leaving it
as a \NoSelect mailbox; should the command
	tag LIST (SUBSCRIBED) "" %

return a LIST response for "Vegis", and if so, with what flags?

Question #2:
  In the past, it has been argued that LSUB should return two
responses for a given name, one with \NoSelect and one without, if
the name was both subscribed and had subscribed children that did
not match the pattern, i.e., line 8 in the table above.  Others
have disagreed with this reading of RFC 3501.  Can LISTEXT please
state how a server should respond in that situation?  That is,
should the server send a response with the \PlaceHolder flag and
one without, or just one response?  (Maintainers of IMAP clients
should speak up here...)

Question #3:
  The LISTEXT syntax permits an empty options list, e.g.,
	tag LIST () "" %

Does that mean the "selection criteria" is "does the mailbox exist"?
Should the cited command return a LIST response for "Vegis", and
if so, with what flags?

Question #4:
  Consider the last four lines of the table at top.  Should any of
the responses change if the mailbox *also* has a selected child
that *does* match the pattern?

Question #5:
  Do any of your answers change if the pattern is "Veg%" instead of "%"?
What if the pattern is "Vegis"?

Philip Guenther
[email-masked]

Date: Mon, 07 Jun 2004 16:40:16 -0400
From: Cyrus Daboo <[email-masked]>
To: Lisa Dusseault <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Annotate draft comments
Sender: [email-masked]

Hi Lisa,

--On Wednesday, June 2, 2004 1:58 PM -0700 Lisa Dusseault 
<[email-masked]> wrote:

>
>
> Discussion kind of died down on my comments on the annotate draft.  Does
> anybody see a consensus on the private/public stuff, which generated the
> most discussion?  (this is also an invitation for other people to chime
> in who haven't already).  Do the authors plan another draft?
>
> Lisa
>

Here is the list of issues I have since the last draft came out:

1) Private/shared debate: this issue is still open. I think it would be 
useful if those proposing a change could clarify their positions given the 
recent debate.

2) Language attribute: I agree this should be present for any value that 
represents text that can be displayed to the user. There is no need for it 
for numeric or enumerated (boolean) values such as flags. I will add text 
for that.

3) Missing IANA registrations: I will add those.

4) Clarification of /comment and /altsubject. I will add those. However, I 
am somewhat unsure of exactly what requirements /altsubject places on 
clients - so if anyone else can suggest those that would be handy.

5) Security considerations inadequate: perhaps someone could suggest better 
text for that or point out other areas in ANNOTATE that the current text 
does not mention.

I would like to wait for the private/shared issue to be resolved before 
putting out another draft, but if we think that will take a while, I will 
go ahead and do a new draft with the other changes soon.

-- 
Cyrus Daboo

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-i18n-03.txt
Date: Mon, 07 Jun 2004 15:42:51 -0400
Sender: [email-masked]

--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		: Internet Message Access Protocol Internationalization
	Author(s)	: C. Newman, A. Gulbrandsen
	Filename	: draft-ietf-imapext-i18n-03.txt
	Pages		: 17
	Date		: 2004-6-7
	
Internet Message Access Protocol (IMAP) version 4rev1 has basic
    support for non-ASCII characters in mailbox names and search
    substrings.  It also supports non-ASCII message headers and content
    encoded as specified by Multipurpose Internet Mail Extensions
    (MIME).  This specification defines a collection of IMAP extensions
    which improve international support including comparator negotiation
    for search, sort and thread, language negotiation for international
    error text, and translations for namespace prefixes.

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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-i18n-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:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-imapext-i18n-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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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

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

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Sat, 05 Jun 2004 09:57:17 +0100
From: Alexey Melnikov <[email-masked]>
To: Lisa Dusseault <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: Annotate draft comments
Sender: [email-masked]

Lisa Dusseault wrote:

> Discussion kind of died down on my comments on the annotate draft.

We need to collect all issues in one place.

> Does anybody see a consensus on the private/public stuff, which 
> generated the most discussion?  (this is also an invitation for other 
> people to chime in who haven't already).

I think we've agreed to add more description about annotations like 
altsubject.

I think there is no consensus to change existing private/public 
annotation model, as described by Cyrus recently.

>   Do the authors plan another draft?
>
> Lisa

Alexey

To: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Annotate draft comments
Date: Wed, 2 Jun 2004 13:58:43 -0700
Sender: [email-masked]

Discussion kind of died down on my comments on the annotate draft.  
Does anybody see a consensus on the private/public stuff, which 
generated the most discussion?  (this is also an invitation for other 
people to chime in who haven't already).  Do the authors plan another 
draft?

Lisa

Date: Tue, 1 Jun 2004 08:24:31 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: [email-masked]
Subject: Re: imapext-i18n draft
Sender: [email-masked]

On Tue, 1 Jun 2004, Arnt Gulbrandsen wrote:
> If noone screams and stamps their feet, section 4.5 will die. Last warning 
> now.

Yes!  Death to 4.5.

-- Mark --

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

From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: imapext-i18n draft
Date: Tue, 1 Jun 2004 16:48:03 +0200
Sender: [email-masked]

Hi,

there's been a new draft there for a few days, incorporating suggestions 
and addressing concerns from various people.

If noone screams and stamps their feet, section 4.5 will die. Last warning now.

I'd like to know whether you all think the example in section 4.3 is 
sensible. I like it and it seems in tune with the (currently expired) 
comparator draft.

I can add some more examples if anyone thinks it's called for.

Arnt