RE: Protected message

I-D ACTION:draft-ietf-imapext-i18n-01.txt

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
	Filename	: draft-ietf-imapext-i18n-01.txt
	Pages		: 17
	Date		: 2004-4-6
	
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-01.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org 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-01.txt".

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

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

Send a message to:
	mailserv <at> ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-imapext-i18n-01.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.

I-D ACTION:draft-ietf-imapext-sort-15.txt

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 - SORT AND THREAD EXTENSION
	Author(s)	: M. Crispin, K. Murchison
	Filename	: draft-ietf-imapext-sort-15.txt
	Pages		: 0
	Date		: 2004-4-8
	
This document describes the base-level server-based sorting and
threading extensions to the [IMAP] protocol.  These extensions
provide substantial performance improvements for IMAP clients which
offer sorted and threaded views.

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

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org 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-sort-15.txt".

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

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

Send a message to:
	mailserv <at> ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-imapext-sort-15.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.

Collected issues with LISTEXT

Hi everyone,
Below is the list of issues raised for LISTEXT document in the last 
couple of years. With each issue I am giving my personal suggestion what 
to do.

1) One LISTEXT capability versa LIST-CHILDREN, LIST-SUBSCRIBED, LIST-REMOTE

Suggestion: no LIST-REMOTE capability (for servers that don't support 
remote mailboxes REMOTE option to the LIST command is ignored).
Do a separate revision of RFC 2193 (RFC 2193 - informative reference for 
LISTEXT).

Mark agreed earlier to support LIST (SUBSCRIBED) as a part of LISTEXT 
(no new capability).

I personally don't like CHILDREN, so I would like to see LIST-CHILDREN 
capability, as was suggested by Mark. But I can live with it being part 
of the LISTEXT extension.

(Related to this) Ken proposed:
Using <LIST () "" ""> to detect LISTEXT extensions:

. LIST () "" ""
* LIST (SUBSCRIBED CHILDREN ACL2) "." ""

Cyrus proposed:
CAPABILITYPLUS

I would rather not delay LISTEXT any further by making it a dependency 
of CAPABILITYPLUS.
But if the WG feels that Ken proposal is useful, this should be added to 
LISTEXT. I think Ken's proposal doesn't preclude any future work on 
CAPABILITYPLUS.

2). Discussion about CHILDREN/LISTEXT interaction. If the server should 
advertise CHILDREN if it supports LISTEXT. And how a client that only 
supports CHILDREN will work with a LISTEXT server. This is somewhat 
related to 1).

(I don't have any opinion on this. Should I start a new thread and post 
a digest of issues here?)

3). Extending LIST syntax to allow for additional parameter to a list 
option, e.g. something like LIST (SORT (NAME DATE)) "" %

No requirement for this right now, can be done later on. If you feel 
strongly about this speak up now!

4). Add more examples? I think this might be a good idea, considering 
the amount of questions on the mailing list regarding different flag 
combinations
for different options.

5). Allow for referral information to be returned in response to LIST 
(REFERRAL).

Suggestion: add REFERRAL LIST option and response data to the LISTEXT 
document, no new capability for this. Reason: referral data can be 
returned for a locally renamed mailbox (i.e. NEWNAME response code 
replacement), no need to support  RFC 2193 for this. If the server 
doesn't support referrals of any sort, this option will be ignored.

Related to this: do a revision of RFC 2193 that is using LISTEXT 
framework (in particular obsolete RLIST/RLSUB).

So, LISTEXT capability will mean: support for LIST option syntax, 
support for \PlaceHolder and \NonExistent flags, support for 
SUBSCRIBED/REMOTE/REFERRAL options (and maybe support for CHILDREN).

Alexey

List of changes for LISTEXT revision

I've just submitted an updated revision of
draft-ietf-imapext-list-extensions. It should be announced soon.
Below is the list of editorial changes I've made:

Abstract must not be numbered. Also found and fixed a wrong section
reference.
Added IPR and Full Copyright.
Updated IMAP4rev1 reference.
Fixed couple of typos.
Reformatted ABNF section for readability.
Split References into Normative and Informative.
Changed LIST response example not to reference ACL to avoid confusion
with ACL2 extension.
Added proper acknowledgments, let me know if I've missed someone.

Alexey

Re: Collected issues with LISTEXT

On Sun, 11 Apr 2004, Alexey Melnikov wrote:
> I personally don't like CHILDREN, so I would like to see LIST-CHILDREN 
> capability, as was suggested by Mark. But I can live with it being part of 
> the LISTEXT extension.

FWIW:

I do not think that a server should be obligated to advertise children 
unless a client explicitly says that it is interested in such information.

I do not think that mere use of LISTEXT instead of LIST suffices to 
indicate such interest.

As a compromise, I'm agreeable to children support being mandatory in 
LISTEXT without requiring a capability; but nevertheless a server should 
not be required to do the work unless the client specifically asks for 
children.

Put another way, I consider RFC 3348 to be broken, since it:
  1) adds an unnecessary CHILDREN extension
  2) requires a server supporting children to do the work even for a
     client that does not care.

I did not oppose RFC 3348, because LISTEXT wasn't ready, and instead 
simply urged that it be Informational.  However, the sooner we move 
towards LISTEXT and declaring RFC 3348 an obsolete false start, the better 
in my view.

-- Mark --

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

Re: Collected issues with LISTEXT

Alexey Melnikov <Alexey.Melnikov <at> isode.com> writes:
...
>5). Allow for referral information to be returned in response to LIST 
>(REFERRAL).
>
>Suggestion: add REFERRAL LIST option and response data to the LISTEXT 
>document, no new capability for this. Reason: referral data can be 
>returned for a locally renamed mailbox (i.e. NEWNAME response code 
>replacement), no need to support  RFC 2193 for this. If the server 
>doesn't support referrals of any sort, this option will be ignored.

So this is suggesting that LIST (REFERRAL) would show all the matching
mailboxes that either
a) currently exist locally, or
b) currently exist as a referral to another server, or
c) did exist and were renamed
with support for the mechanisms behind (b) and (c) being optional?

Item (c) seems really weird, such that I simultaneously have doubts
about its usefulness, the ambiguity it creates, the clutter it will add
to listing, and the possibly security implications.

In reverse order:
- what ACL controls whether you can see the referral for a mailbox that
  was renamed: the ACL on the new name or the ACL on the name at the
  time of the rename?  Is there any way to control that visibility
  independent of the visibility of the current name?

- is there any way to get rid of a "renamed" referral beyond, say,
  creating and deleting a new mailbox under that name, a method that has
  an obvious race condition with someone really trying to create the
  name?
  (New DoS attack: repeatedly rename a publicly visible folder, so that
	tag LIST (REFERRAL) "" *
  returns a few thousand "renamed" entries)

- will "renamed" referrals be flagged differently than "true" referrals
  and normal mailboxes in the listing?  If not, then you have a list of
  mailboxes that may or may not currently exist, which seems less than
  completely useful.

- what's a client supposed to do with a "renamed" referral anyway?  If
  it's for synchronization of disconnected clients then
  a) that's a pretty narrow target audience; wouldn't a narrow "renamed
     only" list extension be more useful for them?
  b) actually, wouldn't the "* NO [REFERRAL ....]" response be good
     enough for them?
  (Oh, and they're going to have a fun time synchronizing, given that
  the UIDVALIDITY on the mailbox was probably changed by the RENAME...)

Indeed, several of those also apply to the original NEWNAME response and
the alluded to use of REFERRAL responses in NEWNAME's place.  Can anyone
explain to me what NEWNAME was supposed to be used for and how any
existing (or pre-3501) clients react to it?  Without an understanding of
the problem being solved, I don't know whether LIST (REFERRAL) is
necessary or useful in solving it.

While I'm on the subject...

It's never been entirely clear to me how mailbox referrals (in the
rfc2193 sense) were intended to be presented by clients.  While I'm not
a client implementor and therefore don't *need* an answer to that, it
does seem to bear on whether it's wise to reuse the same mechanism for
the NEWNAME replacement as is used by the MAILBOX-REFERRALS extension.
When a client that displays the mailbox hierarchy in some form gets back
a referral response, should it use the referral to the alter/update the
display or should it hide the indirection from the end user?  For
example, should the user selecting a mailbox in a hierarchy display
result in a 'reparenting' of the selected mailbox if the original server
returned a referral specifying another server, or should it simply chase
the reference and display the folder in place?

>Related to this: do a revision of RFC 2193 that is using LISTEXT 
>framework (in particular obsolete RLIST/RLSUB).

It would be nice to clarify such points as whether a remote referral may
have a different path than the local name, what ACL controls the
visibility of a remote referrals (does it depend on the command?  Does
the referral have an ACL distinct from the target mailbox?), and what
section 4.2 means when it says "...because a home server is required to
maintain a listing of referred remote mailboxes..."

Philip Guenther
guenther <at> sendmail.com

Re: Collected issues with LISTEXT

Mark Crispin wrote:

> On Sun, 11 Apr 2004, Alexey Melnikov wrote:
>
>> I personally don't like CHILDREN, so I would like to see 
>> LIST-CHILDREN capability, as was suggested by Mark. But I can live 
>> with it being part of the LISTEXT extension.
>
>
> FWIW:
>
> I do not think that a server should be obligated to advertise children 
> unless a client explicitly says that it is interested in such 
> information.
>
> I do not think that mere use of LISTEXT instead of LIST suffices to 
> indicate such interest. 

Ok, is there anybody who will say "I will die if CHILDREN is not part of 
LISTEXT" ?

> As a compromise, I'm agreeable to children support being mandatory in 
> LISTEXT without requiring a capability; but nevertheless a server 
> should not be required to do the work unless the client specifically 
> asks for children. 

I think this is the case for LISTEXT as written now. I.e. unless the 
client specified LIST (CHILDREN), the server is not required to return 
\HasChildren or \HasNoChildren.

Mark would you prefer a separate LIST-CHILDREN capability (as I 
currently do), or can you live with the LISTEXT document as written?

> Put another way, I consider RFC 3348 to be broken, since it:
>  1) adds an unnecessary CHILDREN extension
>  2) requires a server supporting children to do the work even for a
>     client that does not care.
>
> I did not oppose RFC 3348, because LISTEXT wasn't ready, and instead 
> simply urged that it be Informational.  However, the sooner we move 
> towards LISTEXT and declaring RFC 3348 an obsolete false start, the 
> better in my view.

Alexey

Re: Collected issues with LISTEXT

On Mon, 12 Apr 2004, Alexey Melnikov wrote:
> I think this is the case for LISTEXT as written now. I.e. unless the client 
> specified LIST (CHILDREN), the server is not required to return \HasChildren 
> or \HasNoChildren.

This is fine with me.

> Mark would you prefer a separate LIST-CHILDREN capability (as I currently 
> do), or can you live with the LISTEXT document as written?

I don't care either way.  I can live with mandatory-to-implement children 
functionality as long as it is not mandatory-to-execute.

-- Mark --

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

Re: Collected issues with LISTEXT

Philip Guenther wrote:

>Alexey Melnikov <Alexey.Melnikov <at> isode.com> writes:
>...
>  
>
>>5). Allow for referral information to be returned in response to LIST 
>>(REFERRAL).
>>
>>Suggestion: add REFERRAL LIST option and response data to the LISTEXT 
>>document, no new capability for this. Reason: referral data can be 
>>returned for a locally renamed mailbox (i.e. NEWNAME response code 
>>replacement), no need to support  RFC 2193 for this. If the server 
>>doesn't support referrals of any sort, this option will be ignored.
>>    
>>
>
>So this is suggesting that LIST (REFERRAL) would show all the matching
>mailboxes that either
>a) currently exist locally, or
>  
>
Yes.

>b) currently exist as a referral to another server, or
>  
>
No, b) is only returned for LIST (REFERRAL REMOTE)

>c) did exist and were renamed
>  
>
Yes.

>with support for the mechanisms behind (b) and (c) being optional?
>
Yes (c) is optional)

>Item (c) seems really weird, such that I simultaneously have doubts
>about its usefulness, the ambiguity it creates, the clutter it will add
>to listing, and the possibly security implications.
>
>In reverse order:
>- what ACL controls whether you can see the referral for a mailbox that
>  was renamed: the ACL on the new name or the ACL on the name at the
>  time of the rename?  Is there any way to control that visibility
>  independent of the visibility of the current name?
>  
>
That is is a good question and I have to think about this .

>- is there any way to get rid of a "renamed" referral beyond, say,
>  creating and deleting a new mailbox under that name, a method that has
>  an obvious race condition with someone really trying to create the
>  name?
>  (New DoS attack: repeatedly rename a publicly visible folder, so that
>	tag LIST (REFERRAL) "" *
>  returns a few thousand "renamed" entries)
>  
>
I haven't thought about doing this through the IMAP, but an 
implementation may "expire" local referrals after some time.

>- will "renamed" referrals be flagged differently than "true" referrals
>
No, I can't see how is this different. "renamed" referral is a referral 
that points to the same server.

>  and normal mailboxes in the listing?
>
Yes. Normal mailboxes will not have "("REFERRAL" ...)" part in the 
corresponding untagged LIST response.

>  If not, then you have a list of
>  mailboxes that may or may not currently exist, which seems less than
>  completely useful.
>
>- what's a client supposed to do with a "renamed" referral anyway?  If
>  it's for synchronization of disconnected clients then
>
yes.

>  a) that's a pretty narrow target audience; wouldn't a narrow "renamed
>     only" list extension be more useful for them?
>  
>
If you don't want them, don't specify REFERRAL option in LIST.

>  b) actually, wouldn't the "* NO [REFERRAL ....]" response be good
>     enough for them?
>
This will work, but the client will have to SELECT each one of them in 
order to find out. A LIST will return this information in one go.

>  (Oh, and they're going to have a fun time synchronizing, given that
>  the UIDVALIDITY on the mailbox was probably changed by the RENAME...)
>
RENAME is required to preserve UIDVALIDITY.

>
>Indeed, several of those also apply to the original NEWNAME response and
>the alluded to use of REFERRAL responses in NEWNAME's place.  Can anyone
>explain to me what NEWNAME was supposed to be used for and how any
>existing (or pre-3501) clients react to it?  Without an understanding of
>the problem being solved, I don't know whether LIST (REFERRAL) is
>necessary or useful in solving it.
>
>
>While I'm on the subject...
>
>It's never been entirely clear to me how mailbox referrals (in the
>rfc2193 sense) were intended to be presented by clients.  While I'm not
>a client implementor and therefore don't *need* an answer to that, it
>does seem to bear on whether it's wise to reuse the same mechanism for
>the NEWNAME replacement as is used by the MAILBOX-REFERRALS extension.
>When a client that displays the mailbox hierarchy in some form gets back
>a referral response, should it use the referral to the alter/update the
>display or should it hide the indirection from the end user?
>
It depends. Some clients allow to configure different choices, like 
"resolve referrals automatically", "don't show referrals", etc. Other 
will show a different icon in a mailbox tree. The user has to double 
click on the icon to resolve it. I don't think there is a single right 
answer to this question.

>  For
>example, should the user selecting a mailbox in a hierarchy display
>result in a 'reparenting' of the selected mailbox if the original server
>returned a referral specifying another server, or should it simply chase
>the reference and display the folder in place?
>  
>
>>Related to this: do a revision of RFC 2193 that is using LISTEXT 
>>framework (in particular obsolete RLIST/RLSUB).
>>    
>>
>
>It would be nice to clarify such points as whether a remote referral may
>have a different path than the local name, what ACL controls the
>visibility of a remote referrals (does it depend on the command?  Does
>the referral have an ACL distinct from the target mailbox?),
>
I think this is related to one of the questions above, so I will think 
about this as well.

> and what
>section 4.2 means when it says "...because a home server is required to
>maintain a listing of referred remote mailboxes..."
>
>  
>
Alexey