Subject: acl-08: questions
From: Lawrence Greenfield <[email-masked]>
To: [email-masked]
Date: Fri, 20 Jun 2003 13:37:29 -0400
List-Id: <ietf-imapext.imc.org>

. Why is there no 'anonymous' identifier in addition to 'anyone' and
'authuser'?

. Do we have any experience with servers that have tied rights with
the current ACL specification?

. I don't follow how ACL2=MOST-SPECIFIC works. When there are two
groups, which is more specific? What about "authuser" versus a group
that might contain "anonymous"?

There needs to be a formal definition of how to order two rules.

. The ABNF rule "rights = quoted" is unacceptable. We want to
encourage the use of literals, not create more special cases in the
protocol where only a subset of string representations are
allowed. It's not clear to me why this change was made.

How a string is sent is a lexical issue. Where strings are allowed is
a grammar issue. It's unfortunate that we specify both levels in a
single ABNF, but that's no reason to allow the two levels to mix.

Larry

Subject: Re: I-D ACTION:draft-ietf-imapext-acl-08.txt
From: Timo Sirainen <[email-masked]>
To: [email-masked]
Organization: 
Date: 19 Jun 2003 00:44:32 +0300
Sender: [email-masked]

> Note, that if the user has "l" right to a mailbox "A/B", but not to its
> mailbox "A", the LIST command should behave as if the mailbox "A" 
> doesn't exist, for example:
>
>               C: A777 LIST "" *
>               S: * LIST (\NoInferiors) "/" "A/B"
>               S: * LIST () "/" "C"
>               S: * LIST (\NoInferiors) "/" "C/D"
>               S: A777 OK LIST completed

That's now how IMAP currently works if A/B exists but A doesn't. It
should show A as \NoSelect folder. Also LIST "" % should most likely
show A as \NoSelect or clients can't even see it.

Except either way could be annoying to implement in servers, or even
impossible with filesystem ACLs if process doesn't have read-access to A
directory.

Date: Wed, 18 Jun 2003 07:49:59 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: Pete Resnick <[email-masked]>, [email-masked]
Subject: Re: Not meeting in Vienna - Objections?
Sender: [email-masked]

On Wed, 18 Jun 2003, Alexey Melnikov wrote:
> I've just submitted new revisions of CONDSTORE and ACL2.
> I hope this would be the last CONDSTORE revision (I will send a minor
> question shortly) and ACL2 is getting ready for Last Call as well.

I haven't had a chance to review ACL2 thoroughly yet, but I'll get to that
soon.

> UNSELECT was resubmitted recently. Let's Last Call it.

I agree.

-- Mark --

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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-acl-08.txt
Date: Wed, 18 Jun 2003 07:53:00 -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		: IMAP4 ACL extension
	Author(s)	: A. Melnikov
	Filename	: draft-ietf-imapext-acl-08.txt
	Pages		: 10
	Date		: 2003-6-17
	
The ACL (Access Control List) extension of the Internet Message Access
Protocol [IMAP4] permits mailbox access control lists to be manipulated
through the IMAP protocol.

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

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

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

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-condstore-02.txt
Date: Wed, 18 Jun 2003 07:52:55 -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		: IMAP Extension for Conditional STORE operation
	Author(s)	: A. Melnikov, S. Hole
	Filename	: draft-ietf-imapext-condstore-02.txt
	Pages		: 16
	Date		: 2003-6-17
	
Often, multiple IMAP clients need to coordinate changes to a common
IMAP mailbox.  Examples include different clients for the same user,
and multiple users accessing shared mailboxes. These clients
need a mechanism to synchronize state changes for messages within the
mailbox. They must be able to guarantee that only one client can change
message state (e.g., message flags or annotations) at any time.  An
example of such an application is use of an IMAP mailbox as a message
queue with multiple dequeueing clients.
The Conditional Store facility provides a protected update mechanism for
message state information that can detect and resolve conflicts between
multiple writing mail clients.

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

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

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

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

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

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

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

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

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

--OtherAccess--

--NextPart--

Date: Tue, 17 Jun 2003 13:31:51 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: Re: New ANNOTATEMORE draft
Sender: [email-masked]

On Wed, 21 May 2003, Cyrus Daboo wrote:

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

In addition to Ken's question, I note that the draft stipulates:

"Servers SHOULD allow annotations on all 'types' of mailbox, including
ones reporting \Noselect for their LIST response."

At the very least, we might need more text here (or a justification of the
SHOULD as opposed to a MAY, if we really want this at all).

Say we have:

user.rjs3
user.rjs3.foo.bar

Then, user.rjs3.foo may be returned as a \Noselect mailbox.

Say I set an annotation on user.rjs3.foo, and then delete the
user.rjs3.foo.bar mailbox.  What should be the behavior of the
annotation on user.rjs3.foo?

Does the annotation go away and then come back if I recreate user.foo.bar?
Does it continue to exist independently?  If either of these is true, does
this mean I SHOULD be able to set an annotation on
arbitrary.mailbox.that.may.not.exist.currently?  I don't think this sort
of behavior should be encouraged.

Perhaps some of this is confusion over when exactly \Noselect may be
returned.  RFC 3501 specifies that \Noselect may be returned for mailboxes
where "It is not possible to use this name as a selectable mailbox" which
seems a bit vague in this context (since any string that is a valid
mailbox name but not an actual mailbox can match this definition).
Granted, that doesn't mean a server is returning arbitrary strings in its
LIST 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+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----

Date: Mon, 16 Jun 2003 09:46:05 -0500
To: Mark Crispin <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: Not meeting in Vienna - Objections?
Cc: [email-masked]
Sender: [email-masked]

On 6/16/03 at 7:44 AM -0700, Mark Crispin wrote:

>I agree to defer the next meeting of IMAPEXT to the IETF after Vienna.
>Where will that be?

Minneapolis in November.

It would be very nice if we could use that meeting for simply Last 
Call issues. Let's all try to accomplish that.
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Mon, 16 Jun 2003 07:44:13 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Pete Resnick <[email-masked]>
cc: [email-masked]
Subject: Re: Not meeting in Vienna - Objections?
Sender: [email-masked]

On Mon, 16 Jun 2003, Pete Resnick wrote:
> Given the lack of enthusiasm to my post several weeks ago about
> meeting in Vienna (including 2 of the document editors saying they
> will not be there), I assumed that there will *not* be an IMAPEXT
> meeting there. Before the deadline comes around, any objections?

I agree to defer the next meeting of IMAPEXT to the IETF after Vienna.
Where will that be?

-- Mark --

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

Date: Mon, 16 Jun 2003 09:28:41 -0500
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: Not meeting in Vienna - Objections?
Sender: [email-masked]

Given the lack of enthusiasm to my post several weeks ago about 
meeting in Vienna (including 2 of the document editors saying they 
will not be there), I assumed that there will *not* be an IMAPEXT 
meeting there. Before the deadline comes around, any objections?

pr
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Fri, 20 Jun 2003 13:37:29 -0400
From: Lawrence Greenfield <[email-masked]>
To: [email-masked]
Subject: acl-08: questions
Sender: [email-masked]

. Why is there no 'anonymous' identifier in addition to 'anyone' and
'authuser'?

. Do we have any experience with servers that have tied rights with
the current ACL specification?

. I don't follow how ACL2=MOST-SPECIFIC works. When there are two
groups, which is more specific? What about "authuser" versus a group
that might contain "anonymous"?

There needs to be a formal definition of how to order two rules.

. The ABNF rule "rights = quoted" is unacceptable. We want to
encourage the use of literals, not create more special cases in the
protocol where only a subset of string representations are
allowed. It's not clear to me why this change was made.

How a string is sent is a lexical issue. Where strings are allowed is
a grammar issue. It's unfortunate that we specify both levels in a
single ABNF, but that's no reason to allow the two levels to mix.

Larry

Subject: Re: I-D ACTION:draft-ietf-imapext-acl-08.txt
From: Timo Sirainen <[email-masked]>
To: [email-masked]
Organization: 
Date: 19 Jun 2003 00:44:32 +0300
Sender: [email-masked]

> Note, that if the user has "l" right to a mailbox "A/B", but not to its
> mailbox "A", the LIST command should behave as if the mailbox "A" 
> doesn't exist, for example:
>
>               C: A777 LIST "" *
>               S: * LIST (\NoInferiors) "/" "A/B"
>               S: * LIST () "/" "C"
>               S: * LIST (\NoInferiors) "/" "C/D"
>               S: A777 OK LIST completed

That's now how IMAP currently works if A/B exists but A doesn't. It
should show A as \NoSelect folder. Also LIST "" % should most likely
show A as \NoSelect or clients can't even see it.

Except either way could be annoying to implement in servers, or even
impossible with filesystem ACLs if process doesn't have read-access to A
directory.

Date: Wed, 18 Jun 2003 07:49:59 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: Pete Resnick <[email-masked]>, [email-masked]
Subject: Re: Not meeting in Vienna - Objections?
Sender: [email-masked]

On Wed, 18 Jun 2003, Alexey Melnikov wrote:
> I've just submitted new revisions of CONDSTORE and ACL2.
> I hope this would be the last CONDSTORE revision (I will send a minor
> question shortly) and ACL2 is getting ready for Last Call as well.

I haven't had a chance to review ACL2 thoroughly yet, but I'll get to that
soon.

> UNSELECT was resubmitted recently. Let's Last Call it.

I agree.

-- Mark --

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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-acl-08.txt
Date: Wed, 18 Jun 2003 07:53:00 -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		: IMAP4 ACL extension
	Author(s)	: A. Melnikov
	Filename	: draft-ietf-imapext-acl-08.txt
	Pages		: 10
	Date		: 2003-6-17
	
The ACL (Access Control List) extension of the Internet Message Access
Protocol [IMAP4] permits mailbox access control lists to be manipulated
through the IMAP protocol.

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

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

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

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-condstore-02.txt
Date: Wed, 18 Jun 2003 07:52:55 -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		: IMAP Extension for Conditional STORE operation
	Author(s)	: A. Melnikov, S. Hole
	Filename	: draft-ietf-imapext-condstore-02.txt
	Pages		: 16
	Date		: 2003-6-17
	
Often, multiple IMAP clients need to coordinate changes to a common
IMAP mailbox.  Examples include different clients for the same user,
and multiple users accessing shared mailboxes. These clients
need a mechanism to synchronize state changes for messages within the
mailbox. They must be able to guarantee that only one client can change
message state (e.g., message flags or annotations) at any time.  An
example of such an application is use of an IMAP mailbox as a message
queue with multiple dequeueing clients.
The Conditional Store facility provides a protected update mechanism for
message state information that can detect and resolve conflicts between
multiple writing mail clients.

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

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

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

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

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

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

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

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

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

--OtherAccess--

--NextPart--

Date: Tue, 17 Jun 2003 13:31:51 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: Re: New ANNOTATEMORE draft
Sender: [email-masked]

On Wed, 21 May 2003, Cyrus Daboo wrote:

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

In addition to Ken's question, I note that the draft stipulates:

"Servers SHOULD allow annotations on all 'types' of mailbox, including
ones reporting \Noselect for their LIST response."

At the very least, we might need more text here (or a justification of the
SHOULD as opposed to a MAY, if we really want this at all).

Say we have:

user.rjs3
user.rjs3.foo.bar

Then, user.rjs3.foo may be returned as a \Noselect mailbox.

Say I set an annotation on user.rjs3.foo, and then delete the
user.rjs3.foo.bar mailbox.  What should be the behavior of the
annotation on user.rjs3.foo?

Does the annotation go away and then come back if I recreate user.foo.bar?
Does it continue to exist independently?  If either of these is true, does
this mean I SHOULD be able to set an annotation on
arbitrary.mailbox.that.may.not.exist.currently?  I don't think this sort
of behavior should be encouraged.

Perhaps some of this is confusion over when exactly \Noselect may be
returned.  RFC 3501 specifies that \Noselect may be returned for mailboxes
where "It is not possible to use this name as a selectable mailbox" which
seems a bit vague in this context (since any string that is a valid
mailbox name but not an actual mailbox can match this definition).
Granted, that doesn't mean a server is returning arbitrary strings in its
LIST 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+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----

Date: Mon, 16 Jun 2003 09:46:05 -0500
To: Mark Crispin <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: Not meeting in Vienna - Objections?
Cc: [email-masked]
Sender: [email-masked]

On 6/16/03 at 7:44 AM -0700, Mark Crispin wrote:

>I agree to defer the next meeting of IMAPEXT to the IETF after Vienna.
>Where will that be?

Minneapolis in November.

It would be very nice if we could use that meeting for simply Last 
Call issues. Let's all try to accomplish that.
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Mon, 16 Jun 2003 07:44:13 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Pete Resnick <[email-masked]>
cc: [email-masked]
Subject: Re: Not meeting in Vienna - Objections?
Sender: [email-masked]

On Mon, 16 Jun 2003, Pete Resnick wrote:
> Given the lack of enthusiasm to my post several weeks ago about
> meeting in Vienna (including 2 of the document editors saying they
> will not be there), I assumed that there will *not* be an IMAPEXT
> meeting there. Before the deadline comes around, any objections?

I agree to defer the next meeting of IMAPEXT to the IETF after Vienna.
Where will that be?

-- Mark --

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

Date: Mon, 16 Jun 2003 09:28:41 -0500
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: Not meeting in Vienna - Objections?
Sender: [email-masked]

Given the lack of enthusiasm to my post several weeks ago about 
meeting in Vienna (including 2 of the document editors saying they 
will not be there), I assumed that there will *not* be an IMAPEXT 
meeting there. Before the deadline comes around, any objections?

pr
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102