Subject: Re: last call for 'MDN profile for IMAP (BCP)'
From: [email-masked]
To: Alexey Melnikov <[email-masked]>
Cc: Harrie Hazewinkel <[email-masked]>, Tony Hansen <[email-masked]>, imap-ext IETF <[email-masked]>
Date: Fri, 29 Nov 2002 16:01:31 -0800 (PST)
List-Id: <ietf-imapext.imc.org>

> Harrie Hazewinkel wrote:

> > On Wednesday, November 27, 2002, at 08:12 PM, Tony Hansen wrote:
> >
> > >
> > > As for the issue raised there in section 0, I'd be happy with changing
> > > the MUST NOT to a SHOULD NOT.
> >
> > That sounds better to me.
> > With that change you fix the document (it is the top of page 5, right?)
> > and you can drop the TODO.

> Done.

Alexey, if you're going to post a revised version you might as well
take care of these additional items I had slated for an RFC Editor
note:

(1) All the references in this document are normative and that needs to be
    stated in the title of section 10.
(2) The [IMAP4] reference should be changed to refer to
    draft-crispin-imapv-20.txt.

Thanks!

				Ned

Date: Fri, 29 Nov 2002 15:00:33 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Harrie Hazewinkel <[email-masked]>
CC: Tony Hansen <[email-masked]>, imap-ext IETF <[email-masked]>
Subject: Re: last call for 'MDN profile for IMAP (BCP)'
Sender: [email-masked]

Harrie Hazewinkel wrote:

> On Wednesday, November 27, 2002, at 08:12 PM, Tony Hansen wrote:
>
> >
> > As for the issue raised there in section 0, I'd be happy with changing
> > the MUST NOT to a SHOULD NOT.
>
> That sounds better to me.
> With that change you fix the document (it is the top of page 5, right?)
> and you can drop the TODO.

Done.

Cheers,
Alexey
__________________________________________
R & D, ACI Worldwide/MessagingDirect
Watford, UK

Work Phone: +44 1923 81 2877
Home Page: http://orthanc.ab.ca/mel

I speak for myself only, not for my employer.
__________________________________________

Date: Thu, 28 Nov 2002 09:23:20 +0100
Subject: Re: last call for 'MDN profile for IMAP (BCP)'
Cc: imap-ext IETF <[email-masked]>
To: Tony Hansen <[email-masked]>
From: Harrie Hazewinkel <[email-masked]>
Sender: [email-masked]

On Wednesday, November 27, 2002, at 08:12 PM, Tony Hansen wrote:

>
> As for the issue raised there in section 0, I'd be happy with changing 
> the MUST NOT to a SHOULD NOT.

That sounds better to me.
With that change you fix the document (it is the top of page 5, right?)
and you can drop the TODO.

>
> 	Tony
>
> [email-masked] wrote:
>>> While reading the draft draft-melnikov-imap-mdn-04.txt I wondered
>>> about the section '0. To do list and open issues'.
>>> There is still 1 item and how can this document then
>>> be in last call??
>> It is common for such sections to appear in documents that are last 
>> called.
>> They are always removed prior to publication. I already have an RFC 
>> Editor
>> note that says to do this along with several other things.

I know it happens, but it also creates a potential change (even though 
minor)
in the document not known yet.

>>> What would this todo item cause as changes in the document??
>> The presumption is that the issue, such as it is, will be left 
>> unresolved.
>> When I reviewed this I didn't think the issue was substantive. If it is
>> seen as substantive by someone, well, that's what last calls are for...

I agree this change is not substantive.

Harrie

Software developer, Technical Department

Date: Wed, 27 Nov 2002 22:45:16 -0800 (PST)
From: [email-masked]
Subject: Re: base spec clarification of UID command responses
To: Mark Crispin <[email-masked]>
Cc: Cyrus Daboo <[email-masked]>, IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

> On Wed, 27 Nov 2002 12:42:13 -0500, Cyrus Daboo wrote:
> > I think you can probably guess which - one which has other 'issues' with
> > the IMAP protocol.

> I did indeed guess that, and hence my response.  If there is a way that he can
> twist words around to break interoperability, he will find it.

> > I would suggest making the comment about FETCH vs UID FETCH a separate
> > sentence, so that the main statement requiring UID items stands by itself.
> > I guess that can go for the next set of revisions, if we find others have
> > made this mistake too.

> I'll ask the RFC editor if this can be done in the author's 48 hour process.

This is a reasonable change so I doubt this will be a problem.

				Ned

To: Mark Crispin <[email-masked]>
cc: IMAP Interest List <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: allow plaintext password if localhost connection? 
Date: Wed, 27 Nov 2002 13:57:44 -0700
From: Lyndon Nerenberg <[email-masked]>
Sender: [email-masked]

>I see no reason not to do this in UW imapd (and make a user very happy), but
>before I do it I'd like to get a sanity check from the community -- is there
>any reason why this might be a bad idea?

As long as you define "localhost" as "any interface that has the IFF_LOOPBACK
bit set" this should be fine.

I also allow plaintext authentication when the client and server talk
over named sockets (PF_UNIX).

--lyndon

Date: Wed, 27 Nov 2002 14:12:23 -0500
From: Tony Hansen <[email-masked]>
CC: imap-ext IETF <[email-masked]>
Subject: Re: last call for 'MDN profile for IMAP (BCP)'
Sender: [email-masked]

As for the issue raised there in section 0, I'd be happy with changing 
the MUST NOT to a SHOULD NOT.

	Tony

[email-masked] wrote:
> 
>> While reading the draft draft-melnikov-imap-mdn-04.txt I wondered
>> about the section '0. To do list and open issues'.
>> There is still 1 item and how can this document then
>> be in last call??
> 
> It is common for such sections to appear in documents that are last called.
> They are always removed prior to publication. I already have an RFC Editor
> note that says to do this along with several other things.
> 
>> What would this todo item cause as changes in the document??
> 
> The presumption is that the issue, such as it is, will be left unresolved.
> When I reviewed this I didn't think the issue was substantive. If it is
> seen as substantive by someone, well, that's what last calls are for...
> 
>                 Ned

Date: Wed, 27 Nov 2002 10:24:35 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: Re: base spec clarification of UID command responses
To: Cyrus Daboo <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

On Wed, 27 Nov 2002 12:42:13 -0500, Cyrus Daboo wrote:
> I think you can probably guess which - one which has other 'issues' with
> the IMAP protocol.

I did indeed guess that, and hence my response.  If there is a way that he can
twist words around to break interoperability, he will find it.

> I would suggest making the comment about FETCH vs UID FETCH a separate
> sentence, so that the main statement requiring UID items stands by itself.
> I guess that can go for the next set of revisions, if we find others have
> made this mistake too.

I'll ask the RFC editor if this can be done in the author's 48 hour process.

Date: Wed, 27 Nov 2002 12:42:13 -0500
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: base spec clarification of UID command responses
Sender: [email-masked]

Hi Mark,

--On Tuesday, November 26, 2002 3:58 PM -0800 Mark Crispin 
<[email-masked]> wrote:

| I agree with your interpretation; the text says "any FETCH response caused
| by a UID command".  Which server fails to return the UID item in FETCH
| responses?

I think you can probably guess which - one which has other 'issues' with 
the IMAP protocol. I actually now see that the user happened to have an old 
version of the server (dating from 2000) so I will tell them to upgrade and 
then see if this problem is still present.

| It may be more clear if the subsequent "to the FETCH" said "to a UID FETCH
| command."  Unfortunately, I fear that anyone who would argue that the
| existing wording meant that it only applied to UID FETCH commands would
| make the same argument to this wording.

I would suggest making the comment about FETCH vs UID FETCH a separate 
sentence, so that the main statement requiring UID items stands by itself. 
I guess that can go for the next set of revisions, if we find others have 
made this mistake too.

-- 
Cyrus Daboo

Date: Wed, 27 Nov 2002 09:01:13 -0800 (PST)
From: [email-masked]
Subject: Re: last call for 'MDN profile for IMAP (BCP)'
To: Harrie Hazewinkel <[email-masked]>
Cc: imap-ext IETF <[email-masked]>, [email-masked]
Sender: [email-masked]

> While reading the draft draft-melnikov-imap-mdn-04.txt I wondered
> about the section '0. To do list and open issues'.
> There is still 1 item and how can this document then
> be in last call??

It is common for such sections to appear in documents that are last called.
They are always removed prior to publication. I already have an RFC Editor
note that says to do this along with several other things.

> What would this todo item cause as changes in the document??

The presumption is that the issue, such as it is, will be left unresolved.
When I reviewed this I didn't think the issue was substantive. If it is
seen as substantive by someone, well, that's what last calls are for...

				Ned

Date: Wed, 27 Nov 2002 17:24:10 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: IMAP Interest List <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: allow plaintext password if localhost connection?
Sender: [email-masked]

Mark Crispin <[email-masked]>
> I recently received a request to allow plaintext passwords in unencrypted
> connections if the connection is localhost, even if plaintext passwords are
> otherwise forbidden in unencrypted connections.
> 
> I see no reason not to do this in UW imapd (and make a user very happy), but
> before I do it I'd like to get a sanity check from the community -- is there
> any reason why this might be a bad idea?

I'm inclined to agree with that user. Makes sense for stunnel port 993
tunnels etc.

But I'd think hard about whether there might be less benevolent tunnels
out there: http://www.bronnenberg.net/antispam/dsl.cable.redirect.html
suggests there are (in a different context).

--Arnt

Date: Wed, 27 Nov 2002 08:02:19 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: allow plaintext password if localhost connection?
To: IMAP Interest List <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

I recently received a request to allow plaintext passwords in unencrypted
connections if the connection is localhost, even if plaintext passwords are
otherwise forbidden in unencrypted connections.

I see no reason not to do this in UW imapd (and make a user very happy), but
before I do it I'd like to get a sanity check from the community -- is there
any reason why this might be a bad idea?

Date: Wed, 27 Nov 2002 15:58:01 +0100
Subject: last call for 'MDN profile for IMAP (BCP)'
Cc: [email-masked]
To: imap-ext IETF <[email-masked]>
From: Harrie Hazewinkel <[email-masked]>
Sender: [email-masked]

Hi,

While reading the draft draft-melnikov-imap-mdn-04.txt I wondered
about the section '0. To do list and open issues'.
There is still 1 item and how can this document then
be in last call??
What would this todo item cause as changes in the document??

 > APP	2002-12-06	MDN profile for IMAP (BCP)
 > draft-melnikov-imap-mdn-04.txt
 > Token:	Freed, Ned

Sorry, if it is already mentioned, but could not find
any comment in the archive of it.

Harrie

Software developer, Technical Department

Date: Wed, 27 Nov 2002 10:14:45 +0100
Subject: comments on draft-ietf-imapext-acl-06.txt
From: Harrie Hazewinkel <[email-masked]>
To: imap-ext IETF <[email-masked]>
Sender: [email-masked]

HI all,

Below I have some comments on the draft of
 >IMAPEXT Working Group                                     A. Melnikov
 >Internet Draft                                                 Editor
 >Document: draft-ietf-imapext-acl-06.txt                  October 2002

- During the document I see a lot of 'server implementation' speak,
so to say. I beleive the document improves readability if the
the formal protocol definition part and server implementation
guidelines are better seperated and indicated as such.

- Also an overall document roadmap helps to understand how
the author has organized the document. Also provide sometimes
a bit more text and what the purpose is of some parts.
IMHO, this document is well understood by people really into
the subject, but for outsiders it misses parts. This does not
mean I would like to see lots of duplicated text from for instance
rfc 2060, but a bit more self-sustainable improves it a lot.

- I seem to miss the real purpose of ACL in this document and
in perticular to what it applies. (Commented on below as well)

- I seem to miss a clear description of the
CAPABILITIES part for this IMAP extension.

- I seem to miss the behaviour of a server when the ACL is
changed on a shared mailbox and someone has the old ACL to this
mailbox still in his session or is his ACL reset during this
session. One time it only mentioned the rights to the
user (or authenticated id). In particular applicable to the
'ACL SET', but it influences also, for instance, 'ACL GET'.

 > 0.   Open issues

This would be better if combined with the TODO, I believe.

 >  1.   Abstract
 >
 >    The ACL extension of the Internet Message Access Protocol [IMAP4]
 >    permits access control lists to be manipulated through the IMAP
 >    protocol.

Some say no references in the abstract.
I also belive it would be better to extend ACL to 'access control'
and provde a samll description of what ACL means. Is the ACL for
message level or mailboxes level. It will improve readability.

 > 2.   Conventions Used in this Document
 >    In all examples "/" character is used as hierarchy separator.

Not sure, but it is not needed to have a single hierarchy seperator??
Agreed, this is maybe part of IMAP not this document.

 > 3.   Introduction and Overview

I do not see a sdescription of what ACL (access control) means here.
Is it per mailbox or per message. A short description would provide a
better readability.
One now assumes the reader laready knows, since in this section
various times an implementation is discussed. These implementation issues
are better to be placed in a seperate section with some name
as 'implementation guidelines' or so.

 >    The ACL extension is present in any IMAP4 implementation which
 >    returns a capability starting with "ACL2=" as one of the supported
 >    capabilities to the CAPABILITY command.

Does the '=' in 'ACL2=' stand for something?? Are the rights
listed after it??

 >    An access control list is a set of <identifier,rights> pairs.

This is not introduction anymore, but part of the ACL specification.
A seperate section is better.
 >
 >    Identifier is a UTF-8 string. An identifier may have one of the 
following
 >    forms:
 >      a). "anyone" - special identifier that refers to the universal 
identity
 >          (all authentications, including anonymous).
 >      b). "authuser" - special identifier that refer to all 
authenticated users,
 >          but not anonymous.
 >      c). "owner" - special identifier that refers to the owner of a 
mailbox
 >          (if any).
 >      d). "administrators" - special identifier that refers to all 
users with
 >          administrative rights.

How does one define who has administrator rigths?? Is this the 
administrator
of the mailbox or the server for instance.

 >      e). "user=<xxx>" - refers to a user. Here "<xxx>" is a user name 
string
 >          accepted by the LOGIN or AUTHENTICATE commands.
 >      f). "group=<xxx>" - refers to a group.

Why is '<xxx>' here not specified what it means??

 >      g). "-<identifier>", where <identifier> is one of a).-f). This is

How does one create a group via IMAP?? Or is this out-of-scope??
I am asking this, since I would believe that a user could potentially
create a mailbox for a big group and without the possibility
of creating a group the list of user=<xxx>,<rights> can become pretty
long.

 >          reserved for "negative rights", described below.

Why is the '-' sign in front of the identifier indicating the negative
rights?? Are they not supposed to be part of the rights?? So it should 
be in
front of the rights portion??

 > <<Reserve X- and V- prefixes?>>

What does this mean?? I presume author reminder??

 >    All other identifier names are reserved for future definition in an
 >    extension or revision to this specification (also known as ACL2).

How can one make implementation specific or better enterprise
specific identifiers??

 >    Rights is a string listing a (possibly empty) set of alphanumeric
 >    characters, each character listing a set of operations which is 
being
 >    controlled.  Letters are reserved for ''standard'' rights, listed
 >    below.  The set of standard rights may only be extended by a
 >    standards-track document.  Digits are reserved for implementation or
 >    site defined rights.

Here suddenly implementation or site defined rights. I believe it would
assist the implementor if a section is added for implementation specific
or enterprise specific right.

 >  The currently defined standard rights are:

A bit more eloborating on the rights would improve readability.

 >    l - lookup (mailbox is visible to LIST/LSUB commands, SUBSCRIBE 
mailbox)

Why is 'SUBSCRIBE' not a command??

 >    r - read (SELECT the mailbox, perform STATUS, CHECK, FETCH, SEARCH,
 >        COPY from mailbox)
 >    s - keep seen/unseen information across sessions (set or clear 
\SEEN flag
 >        via STORE, APPEND or COPY)

How does this work with multiple users sharing a mailbox??
Applies also to other rights.

 >    p - post (send mail to submission address for mailbox,
 >        not enforced by IMAP4 itself)

What is seen as the submission address??

 >    Server implementations are not required to support "negative right"
 >    identifiers.

How does one detect this?? Via the CAPABILITY??

 > 3.1. Rights required to perform different IMAP4rev1 commands

This is a more detailed part for the earlier rights. But in section
3 it is a little brief and here it is not done for all rights.

 > 4.   Commands

You introduce, for instance, directly 'all ACL commands' but what are 
these
commands for. I asume you mean here the commands that manipulate the 
access
control for mailboxes (or messages since not specified earlier).
improve readability.

 >     For simplicity the bahaviour of ACL STORE/DELETE/SET/GET/LIST 
commands

typo-> 'bahaviour' should be ' behaviour'.

 >     is described for a single mailbox case. When one or more mailbox 
pattern
 >     is specified, the server internally performs LIST command for all 
specified
 >     patterns and than it combines the results.

I understand the reason why one would like to explain it simple for a 
single
mailbox case, but I believe it helps an implementor a lot if the pattern
approach is discussed properly too.
This could be done in a subsection for instance. For an implementor I 
beleive
this is the most difficult part.

 >     Note, that only mailboxes for
 >     which the user has 'l' right are included in the combined result. 
If the
 >     combined result has no mailboxes, an ACL operation completes with 
success
 >    and the tagged OK response is sent. Otherwise the requested 
operation is
 >     performed for each mailbox in the combined result.

Do we not have a pattern approach here?? And it was mentioned only the 
single
mailbox approach is specified.

 > 4.1. ACL STORE

Some of the comments on this command do also apply
on the others, but are not repeated.

 >
 >    Arguments:  mailbox name or one or more mailbox masks
 >                authentication identifier
 >                access right modification

When having masks I can have multiple, but why not for specific
mailbox names??

 >    Data:       OPTIONAL untagged responses: ACLINFO
 >
 >    Result:     OK - ACL STORE completed
 >                NO - ACL STORE failure: can't set acl
 >                BAD - command unknown or arguments invalid
 >
 >       The ACL STORE command changes the access control list on the
 >       specified mailbox so that the specified identifier is granted
 >       permissions as specified in the third argument.

I see it is in line with the other drafts/RFCs, but why not first the
small description and then the precise definition??
What I believe is missing is the syntax of the commands, for instance,
<number> ACL STORE <.......

Also what is an argument?? Is the <number> in the command-line also
counted?? I would agree that it is specified in the IMAP RFC,
but repeating it here is not a problem, I beleive.

 >       The third argument is a string containing an optional plus ("+")
 >       or minus ("-") prefix, followed by zero or more rights 
characters.
 >       If the string starts with a plus, the following rights are added
 >       to any existing rights for the identifier.  If the string starts
 >       with a minus, the following rights are removed from any existing
 >       rights for the identifier.  If the string does not start with a
 >       plus or minus, the rights replace any existing rights for the
 >       identifier.
 >       Note, that for "ACL2=UNION" access calculation rule

Where does 'UNION' suddenly come from. It is mentioned earlier,
but I did not understood there what the purpose of it was.
This comes to a point that I believe where the CAPABILITIES
predefined or possible should be explained better in the beginning.
That should be done in a general sense, not like 'if an 
implementation...'
Now this document jumps between an 'implementation guideline' and
a specification of an IMAP extension.

Why here no example, since you do it later always for commands.

 > 6.   Formal Syntax
 >
 >    Formal syntax is defined using ABNF [ABNF] as modified by [IMAP4].
 >    Non-terminals referenced but not defined below are as defined by
 >    [IMAP4].
 >
 >    Except as noted otherwise, all alphabetic characters are
 >    case-insensitive.  The use of upper or lower case characters to
 >    define token strings is for editorial clarity only.  Implementations
 >    MUST accept these strings in a case-insensitive fashion.
 >
 >    acl2_command    = myrights | "ACL" SPACE acl2_subcommand

I understnad that the BNF al RFC 2060 is fixed, but an explaination
on how it fits in there is helpfull.
Even though, the command syntax is pretty clear.

7.1.  ACL access calculation rule Registration Template

    When an access calculation rule for ACL2 extension is registered, the
    following information is supplied:

    Rule Identification: specify a string that identifies this
       rule.  Unless the rule is registered with the IANA, the
       rule's identification must start with "X-".
       The server supporting a particular rule <rule-ID> MUST report
       "ACL2=<rule-ID>" in the capability list.

    Rule Semantics: specify how access rights for a mailbox are 
calculated.

    Negative rights allowed: specify whether "negative right" identifiers 
are
       allowed.

    Groups allowed: specify whether group identifiers are allowed.

    Special Identifiers: describe whether any implementation defined
       aliases are allowed and define their meaning.

    Contact Information: specify the postal and electronic contact
       information for the author of the feature.

8.   Initial Registrations

8.1.  Registration: UNION access calculation rule

    Rule Identification: UNION

    Rule Semantics: the union of the rights granted to
    the applicable identifiers minus the union of the negative rights.

    Negative rights allowed: Yes.

    Groups allowed: Yes, but not required.

    Special Identifiers: No.

    Contact Information: c.f., the "Editor's Address" section of this
       memo

8.2.  Registration: MOST-SPECIFIC access calculation rule

    Rule Identification: MOST-SPECIFIC

    Rule Semantics: the rights granted to the most specific identifier
       present in the ACL are used, i.e. if the user identifier is 
present,
       its ACL is used. If no user identifier is present, but a group that
       includes this user as a member is present, the group ACL is used.
       If neither user, nor group identifier is present, but an ACL for
       a special group "anyone" is present, the ACL for "anyone" is used.

    Negative rights allowed: No.

    Groups allowed: Yes, but not required.

    Special Identifiers: No.

    Contact Information: c.f., the "Editor's Address" section of this
       memo

 > 9.   Security Considerations
 >
 >    An implementation must make sure the ACL commands themselves do not
 >    give information about mailboxes with appropriately restricted 
ACL's.
 >    For example, a ACL GET command on a mailbox for which the user has
 >    insufficient rights should not admit the mailbox exists, much less
 >    return the mailbox's ACL.
 >
 >    IMAP clients implementing ACL2 that are able to modify ACLs SHOULD
 >    warn a user that wants to give full access to the special identifier
 >    "anyone".

What conditions of ACL must be met in order to retrieve the info
with 'ACL GET'??

 >    An ACL2 server MAY modify one or more ACL for one or more 
identifier as a
 >    side effect of modifying the ACL specified in ACL STORE/DELETE/SET.
 >    If the server does that it MUST send untagged ACL response to 
notify the
 >    client about the changes made.

I am not sure what this means, but I presume that if you change the
ACL for anyone it should also respond with the changed ACL for the
authenticated user itself??

Cheers,

Harrie

Software Developer, Technical Department

Date: Tue, 26 Nov 2002 15:58:43 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: base spec clarification of UID command responses
Organization: Networks & Distributed Computing
Sender: [email-masked]

Hi Cyrus -

I agree with your interpretation; the text says "any FETCH response caused
by a UID command".  Which server fails to return the UID item in FETCH
responses?

It may be more clear if the subsequent "to the FETCH" said "to a UID FETCH
command."  Unfortunately, I fear that anyone who would argue that the
existing wording meant that it only applied to UID FETCH commands would
make the same argument to this wording.

-- Mark --

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

Date: Tue, 26 Nov 2002 17:39:07 -0500
From: Cyrus Daboo <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: base spec clarification of UID command responses
Sender: [email-masked]

The UID command has the following text description included (from the 
latest draft):

      The number after the "*" in an untagged FETCH response is always a
      message sequence number, not a unique identifier, even for a UID
      command response.  However, server implementations MUST implicitly
      include the UID message data item as part of any FETCH response
      caused by a UID command, regardless of whether a UID was specified
      as a message data item to the FETCH.

I interpreted this to mean that any UID command, be it FETCH, STORE, COPY 
or SEARCH, has to always include UID items in any FETCH responses. However, 
I have come across at least one server that does not return the UID item in 
FETCH responses when doing a UID STORE. I'm concerned that the above 
paragraph might have been interpreted as meaning that the UID item is only 
required when UID FETCH is used, as opposed to the others.

The 'caused by' statement may be the problem - if a FETCH repsonse occurs 
during a COPY should those include UID items? Strictly speaking a COPY 
cannot change anything so 'caused by' cannot apply, so FETCH responses do 
not have to have UID items. I think this is ambiguous and needs to be 
cleared up (given that at least one implementor has done something 
different than the others).

-- 
Cyrus Daboo

Date: Thu, 21 Nov 2002 22:25:26 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: [email-masked]
Subject: Jabber Summarys
Sender: [email-masked]

The Jabber Summaries from the pre-meeting and the WG meeting are here:

http://www.jabber.com/chatbot/logs/conference.ietf.jabber.com/imapext/

The applicable files:
2002-11-20.html - Pre-Meeting
2002-11-21.html - WG Meeting.

-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: Thu, 21 Nov 2002 22:10:19 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: [email-masked]
Subject: imapext draft minutes
Sender: [email-masked]

Here are the minutes I took from the IETF IMAPEXT meeting.

Please review ;)

-Rob

---<cut here>---
Internet Message Access Protocol Extension WG minutes, Thu Nov 21 2002
reported by Rob Siemborski <[email-masked]>

Pete Resnick is chairing.

. Chair, introduction and agenda bashing

- This group is being stalled on various issues for too long, we need to
decide on what we need to get done and punt on what we can't.

. CONDSTORE - Alexey Melnikov
draft-melnikov-imap-condstore-08.txt

This draft is pretty much done with only minor open issues.

1. The inclusion of a shared flags response to the SELECT command.  The
purpose of the response would be to indicate which flags are shared
between users, and would be totally server-defined.

2. What kind of notification sequence should be returned if another
session modifies a flag with or without CONDSTORE?

Alexey will make a decision on both of these issues and post a final draft
before doing a last call (soon).

. ACL - Alexey Melnikov
draft-ietf-imapext-acl-06.txt

Minor issues:

1. Missing a section on compatibility with RFC2086.

Alexey has text and will include it in a new version of the draft.

2. Alexey added syntax to apply ACL commands to multiple mailboxes in
a single command, with individual failure notifications.

Larry Greenfield felt that this was unnecessary because it could be done
with pipelining of commands almost as easily and with no real loss in
functionality.  We also do not have a model for partial failures anywhere
else in IMAP, and is not sure if we really want to introduce one.

The chair asked Alexey to make a final decision and we'll see if people
scream on the list when the new draft is published.

Chris Newman expressed concerns that allowing different ACL models,
especially given that WebDAV's recent ACL draft was rejected by the IESG
for being too complicated.

Mark Crispin requested that we not put a minimum requirement on the
extension that implementors with legacy mail stores cannot meet, and that
this might be one of those requirements.

Ned Freed commented that WebDAV's rejection was not specifically for the ACL
models, but an overriding level of complexity.  He does not feel that IMAP
ACL even comes close.

Larry Greenfield commented that it is OK to have an extension that is
not implementable on all servers, and that it is also absolutely necessary
for all clients to understand how a server will react to ACL commands from
a security standpoint.  Currently we are using an IANA registry for this,
but will the clients be able to keep up?

Rough consensus to proceed down the current path, which is not as
complicated as webdav, and seek guidence from the security area.

3. The issue of tied rights.  Currently the client must do a LISTRIGHTS
before setting an ACL.  The proposal is to just have the client try to
set the ACL and return a NO with a LISTRIGHTS response code if rights do
happen to be tied and not all of them were specified.

No objections to this change.

- Cyrus commented that it might be nice to have a table in the draft of
which rights were required for which commands, even if such a table was
large.

. LISTEXT - Barry Leiba
(Expired Draft)

Issues:

1. Not including all LISTEXT capabilities in the CAPABILITIES response.
It was generally agreed that this isn't what we want to do.

2. Addition of extensible attribute value pairs at the end of the
response.  This was generally agreed to be a good idea.

3. Interaction with ANNOTATEMORE and ACL.  This would create some sort of
document dependency (one direction or another).

Mark Crispin prefers that all responses happen through the single LIST
interface.  No one saw a problem with this for ACL, and generally agreed
that it was a good idea.

Cyrus Daboo commented that we would need GETANNOTATION for /server
annotations atleast anyway.  General agreement that we should allow both
methods of fetching /mailbox annotations.  The chair suggested that we
will decide to deprecate one or the other once LISTEXT is available.

Larry Greenfield noted that if we are going down this path we want to be
absolutely certain that LISTEXT is extensible enough that we can get any
future per-mailbox information through a LISTEXT extension.

We will decide if ACL and ANNOTATEMORE depend on LISTEXT or the other
way around once we can see where LISTEXT is.  General preference appeared
to be that ANNOTATEMORE and ACL depend on LISTEXT.

Barry Leiba will have a new draft out next week.

. ANNOTATE[MORE] - Cyrus Daboo
draft-ietf-imapext-annotate-05.txt
draft-daboo-imap-annotatemore-01.txt

ANNOTATE Issues:

1. Dealing with system flags ('\' prefix), keywords ('$' prefix), and
'vendor flags' (no prefix)

Suggested solution was creating an IANA registry for keywords, and using
the ACAP vendor registry for vendor names, and using a hierarchy like:

/message/flag/XXX
/message/flag/vendor/YYY.ZZZ

Where XXX is a system flag or keyword without the prefix, YYY was a
registered vendor name, and ZZZ was the name of the vendor flag.

Mark Crispin noted that the vendor namespace doesn't make sense if a user
has their own flags.

Cyrus Daboo suggested creating a new prefix symbol to pull off the vendor
namespace, and perhaps adding a new annotation category for user flags.

Randall Gellens suggested the use of a single annotation that was a list
of all user flags.

This discussion was punted to the list.

2. Removing dependency on SORT, which will have i18n issues.  SORT would
add the ability to sort annotations back in.

3. Switch to using /message/envelope in ANNOTATE instead of
/message/smtp-envelope.  Specify that it contains RFC 2821 MAIL FROM And
RCPT TO stream data.  This requires attention in the Security
Considerations section as well.  We should probably break this out into a
separate document.

4. Add sieve-action annotation to ANNOTATE.  This should also probably be
a separate document.

The chair suggested removing as many of the annotations as possible and
placing them in an IANA registry.  Alexey will come up with a list of
which should be removed from the current draft.

Chris Newman wanted to add a caveat that sort on annotations was a
capability if both SORT and ANNOTATE was advertised.  Also, it would
be nice if SORT on annotations was left in the ANNOTATE document, even if
this meant that ANNOTATE was sitting in the IESG queue blocked on SORT.
(general agreement)

ANNOTATEMORE Issues:

1. Interaction with LISTEXT.

2. Right now we require an RFC to add an annotation to the IANA registry,
we want to change this to just require expert review.

Ned Freed stated that this sounded fine.

3. Barry Leiba expressed concerns about private vs. shared and
read-write vs read-only annotations in the /server hierarchy.

Cyrus Daboo commented that it was difficult because we lack ACLs for
/server.

Barry suggested that we just make a decision so that the behavior
was known.

4. Barry suggested that the ANNOTATION response should have defined
semantics as to when it is sent.  The suggestion is to always send /server
annotations, but only send /mailbox annotations for the currently selected
mailbox.  No objections.

. SORT/THREAD - Mark Crispin
draft-ietf-imapext-sort-10.txt
draft-ietf-imapext-thread-12.txt

Issues:

1. These drafts are being held up by the specification of a mandatory to
implement i18n solution.  Specifically, collation is problematic.

2. We might look into combining these two documents into a single
document, as they share a large amount of text.  This was left up to
whatever is easier for Mark.

3. Some have suggested other threading algorithms.  Mark felt that this
was a good idea as the threading document is already very complicated and
implementations are having trouble complying.  Future algorithms can be
provided in separate documents if this is desired.

. New i18n Document - Chris Newman

Randall Gellens and Chris Newman volunteered to create a single document
that would be an i18n spec for IMAP that could move everything forward.

Mark Crispin expressed nervousness about making it harder or more
confusing for implementations to comply, and that we would see binary
compare last much longer than it should.

Larry Greenfield suggested that the place for choosing the collation
mechanism is the ACAP comparator registry.  There isn't a good way to
allow SORT/THREAD to go forward without a mandatory to implement
comparator.

Chris suggested that we keep binary compare as the default, but
name a mandatory to implement comparator that is based on stringprep.
For example, binary compare on the output of stringprep.

The chair summarized the situation with the following steps:
  1. Convert to Unicode
  2. Run Stringprep
  3. Run your comparator (this may involve a conversion to UTF-8 if you
     are doing a binary compare).

. Search Extensions - Barry Leiba
(No Draft Available)

This is an extension from a while ago that recently some interest has been
expressed in again, especially given some discussion at the lemonade BOF.
We would like to be able to ask "for these folders do these searches and
give me back just the number of hits." This is related to
STATUS-COUNTERS, which would be a fast wrapper around the search
extensions.

Mark suggested adding the SCAN extension to the Search Extensions
draft.

. General Discussion

Chris Newman reminded everyone of the need review documents for nits
before submitting to the IESG.  There is a document at:
    http://www.ietf.org/ID-nits.html

The chair reminded the group that there is IMAP work going on in lemonade
that we should watch for.

Lyndon Nerenberg had commented on Jabber during the pre-meeting that he
had been having difficulty moving the CHANNEL extension forward, and
wanted to discuss it within imapext.

The chair commented that in actuality this draft had been picked up by
lemonade, and that was probably a good place for it to thrive.
---<cut here>---

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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: Sat, 16 Nov 2002 20:57:41 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Mark Crispin <[email-masked]>
CC: Pete Resnick <[email-masked]>, [email-masked]
Subject: Re: Agenda
Sender: [email-masked]

[Sorry, I've been on holidays this week.]

Mark Crispin wrote:

> On Wed, 13 Nov 2002 13:09:23 -0600, Pete Resnick wrote:
> > I am curious who told you that there was
> > "urgent" business
>
> Alexey, among others.

Yes, I did. We need to finish ACL2 and I think is it mostly complete.
Also, I would like to hear more feedback about other documents I am editing, in
particular QUOTA, UNSELECT, DISC and STATUS-COUNTERS.

> > So far, I have gotten no
> > feedback on the agenda except for the question from Ken. Do *you*
> > have any feedback on the proposed agenda?
>
> Past experience has caused me to hesitate to say much.  But if you insist:
>
> A look at the current IDs shows: QUOTA, ACL, ANNOTATE, CONDSTORE, DISC,
> KEYWORDS, MDN, UNSELECT, BINARY, CHANNEL, STATUS-COUNTERS, SORT, and THREAD.
> Why aren't all of these on the agenda?
>
> I, too, am disappointed to see nothing about LIST extensions, and feel that it
> should be on the agenda.
>
> I don't think IMAPEXT is anywhere near completion.  I am as weary of IMAPEXT
> as anyone else (remember, I opposed its creation in the first place).  But it
> needs to accomplish something before it is done.
>
> As far as I can tell, the only RFC is ID, and I forget if that's IMAPEXT or
> independent.  MULTIAPPEND got reviewed by IMAPEXT, and is in the RFC editor
> queue, but it too was independent.
>
> Most notably, IMAPEXT activity is still pending on four commonly-implemented
> extensions: ACL, QUOTA, SORT, and THREAD.

STATUS-COUNTERS should be discussed at LEMONADE on Thursday morning.
CONDSTORE is complete as far as I am concerned, but I have to fix couple small
open issues marked with <<>> in the document. Please, send me your feedback ASAP,
I am planning to request the Last Call soon.

Regards,
Alexey Melnikov
__________________________________________
R & D, ACI Worldwide/MessagingDirect
Watford, UK

Work Phone: +44 1923 81 2877
Home Page: http://orthanc.ab.ca/mel

I speak for myself only, not for my employer.
__________________________________________

Date: Sat, 16 Nov 2002 20:52:09 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Rob Siemborski <[email-masked]>
CC: [email-masked]
Subject: Re: Agenda
Sender: [email-masked]

Rob Siemborski wrote:

> On Wed, 13 Nov 2002, Pete Resnick wrote:
>
> > The silence around here is deafening. Who is coming to Atlanta? Do we
> > need to cancel this meeting? Does anyone have any comment?
>
> Both Larry and myself (and Walter) are planning on attending.

Chris is here as well.
Vladimir is coming Monday evening as well, unfortunately he is leaving on
Thursday.

Regards,
Alexey Melnikov
__________________________________________
R & D, ACI Worldwide/MessagingDirect
Watford, UK

Work Phone: +44 1923 81 2877
Home Page: http://orthanc.ab.ca/mel

I speak for myself only, not for my employer.
__________________________________________

Date: Sat, 16 Nov 2002 13:08:20 -0800 (PST)
From: [email-masked]
Subject: Re: Agenda
To: Mark Crispin <[email-masked]>
Cc: Lyndon Nerenberg <[email-masked]>, Pete Resnick <[email-masked]>, [email-masked]
Sender: [email-masked]

> On Fri, 15 Nov 2002 11:32:38 -0700, Lyndon Nerenberg wrote:
> > Binary and Channel aren't covered by the charter. And Binary is
> > finished, so it can come off that list.

> I still think that IMAPEXT ought to take a look.

> Can you elaborate what you mean by "finished"?  Has it been approved by the
> IESG?

Binary was last called 22-Jan-2002. Afer IESG review and some revisions it was
approved by the IESG on 14-Nov-2002. Channel has yet to be last called and it
is my understanding that the current draft isn't ready for AD review yet.

				Ned

Date: Fri, 15 Nov 2002 11:07:41 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: re: Binary status (was Re: Agenda)
To: Lyndon Nerenberg <[email-masked]>
cc: [email-masked]
Sender: [email-masked]

On Fri, 15 Nov 2002 12:06:24 -0700, Lyndon Nerenberg wrote:
> Well, the spec was seen and commented on by quite a few IMAPEXT
> participants. and ietf-imapext received the four week last call
> announcement.

Really?  I don't recall seeing it.

>      If the specified mailbox does not support the storage of binary
>      content, the server MUST fail the request and issue a "NO" response
>      that contains the "UNKNOWN-CTE" extended response code.

I am aware of this, but this requires the client to do two transmissions of
the data.  There should be a capability so that the client knows in advance
before wasting its time.

To: Mark Crispin <[email-masked]>
cc: [email-masked]
Subject: Binary status (was Re: Agenda)
Date: Fri, 15 Nov 2002 12:06:24 -0700
From: Lyndon Nerenberg <[email-masked]>
Sender: [email-masked]

>I still think that IMAPEXT ought to take a look.

Well, the spec was seen and commented on by quite a few IMAPEXT
participants. and ietf-imapext received the four week last call
announcement.

>Can you elaborate what you mean by "finished"?  Has it been approved by the
>IESG?

The last call IESG objections have been addressed, so I expect final
IESG approval any day now.

>In reviewing BINARY, I think that the ability to APPEND binary data should be
>indicated by a separate capability.  I'm likely to add support for binary
>fetching, but not for appending.

Section 6.4:

     [...]
     If the specified mailbox does not support the storage of binary
     content, the server MUST fail the request and issue a "NO" response
     that contains the "UNKNOWN-CTE" extended response code.

After this response a reasonable client will fall back to the basic
APPEND syntax (with encoding).

--lyndon

Date: Fri, 15 Nov 2002 10:44:10 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: Re: Agenda 
To: Lyndon Nerenberg <[email-masked]>
cc: Pete Resnick <[email-masked]>, [email-masked]
Sender: [email-masked]

On Fri, 15 Nov 2002 11:32:38 -0700, Lyndon Nerenberg wrote:
> Binary and Channel aren't covered by the charter. And Binary is
> finished, so it can come off that list.

I still think that IMAPEXT ought to take a look.

Can you elaborate what you mean by "finished"?  Has it been approved by the
IESG?

In reviewing BINARY, I think that the ability to APPEND binary data should be
indicated by a separate capability.  I'm likely to add support for binary
fetching, but not for appending.

To: Mark Crispin <[email-masked]>
cc: Pete Resnick <[email-masked]>, [email-masked]
Subject: Re: Agenda 
Date: Fri, 15 Nov 2002 11:32:38 -0700
From: Lyndon Nerenberg <[email-masked]>
Sender: [email-masked]

>A look at the current IDs shows: QUOTA, ACL, ANNOTATE, CONDSTORE, DISC,
>KEYWORDS, MDN, UNSELECT, BINARY, CHANNEL, STATUS-COUNTERS, SORT, and THREAD.
>Why aren't all of these on the agenda?

Binary and Channel aren't covered by the charter. And Binary is
finished, so it can come off that list.

Also, I will _not_ be going to Atlanta.

--lyndon

Date: Wed, 13 Nov 2002 14:27:30 -0800
From: Chris Newman <[email-masked]>
Subject: Re: Agenda
To: Pete Resnick <[email-masked]>, Ken Murchison <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

I will be there.  I think we should have a meeting at least to go over any 
remaining open issues on the drafts that were revised.  Perhaps also to 
discuss possible solutions to the i18n problem with SORT/THREAD.

                - Chris

begin  quotation by Pete Resnick on 2002/11/13 12:46 -0600:

>
> On 11/9/02 at 10:58 PM -0500, Ken Murchison wrote:
>
>>> It's time to make up the agenda for next week, folks. So far,
>>> here's what I've got:
>>>
>>> - Annotate
>>> - ACL
>>> - How to end the WG
>>>
>>> Please let me know what else there is to discuss. The WG has
>>> clearly (to my eyes) run out of steam and we need to get whatever
>>> we want to finish done quickly.
>>
>> Has LISTEXT fizzled out?
>
> The silence around here is deafening. Who is coming to Atlanta? Do we
> need to cancel this meeting? Does anyone have any comment?
>
> pr
> --
> Pete Resnick <mailto:[email-masked]>
> QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Wed, 13 Nov 2002 15:03:29 -0500
From: Cyrus Daboo <[email-masked]>
To: Pete Resnick <[email-masked]>
cc: [email-masked]
Subject: Re: Agenda
Sender: [email-masked]

Hi Pete,

--On Wednesday, November 13, 2002 12:46 PM -0600 Pete Resnick 
<[email-masked]> wrote:

| The silence around here is deafening. Who is coming to Atlanta? Do we
| need to cancel this meeting? Does anyone have any comment?

I should be present provided our major release actually gets done later 
today...

-- 
Cyrus Daboo

Date: Wed, 13 Nov 2002 14:40:54 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: [email-masked]
Subject: Re: Agenda
Sender: [email-masked]

On Wed, 13 Nov 2002, Pete Resnick wrote:

> The silence around here is deafening. Who is coming to Atlanta? Do we
> need to cancel this meeting? Does anyone have any comment?

Both Larry and myself (and Walter) are planning on attending.

-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: Wed, 13 Nov 2002 11:11:39 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: Re: Agenda
To: Pete Resnick <[email-masked]>
cc: [email-masked]
Sender: [email-masked]

On Wed, 13 Nov 2002 13:09:23 -0600, Pete Resnick wrote:
> I am curious who told you that there was
> "urgent" business

Alexey, among others.

> So far, I have gotten no
> feedback on the agenda except for the question from Ken. Do *you*
> have any feedback on the proposed agenda?

Past experience has caused me to hesitate to say much.  But if you insist:

A look at the current IDs shows: QUOTA, ACL, ANNOTATE, CONDSTORE, DISC,
KEYWORDS, MDN, UNSELECT, BINARY, CHANNEL, STATUS-COUNTERS, SORT, and THREAD.
Why aren't all of these on the agenda?

I, too, am disappointed to see nothing about LIST extensions, and feel that it
should be on the agenda.

I don't think IMAPEXT is anywhere near completion.  I am as weary of IMAPEXT
as anyone else (remember, I opposed its creation in the first place).  But it
needs to accomplish something before it is done.

As far as I can tell, the only RFC is ID, and I forget if that's IMAPEXT or
independent.  MULTIAPPEND got reviewed by IMAPEXT, and is in the RFC editor
queue, but it too was independent.

Most notably, IMAPEXT activity is still pending on four commonly-implemented
extensions: ACL, QUOTA, SORT, and THREAD.

From: Arnt Gulbrandsen <[email-masked]>
To: Pete Resnick <[email-masked]>
Subject: Re: Agenda
Cc: Ken Murchison <[email-masked]>, [email-masked]
Date: Wed, 13 Nov 2002 20:37:56 +0100
Sender: [email-masked]

Pete Resnick writes:
> The silence around here is deafening. Who is coming to Atlanta? Do we 
> need to cancel this meeting? Does anyone have any comment?

I'm not a WG member, I suppose, but I'll offer a comment: I don't see 
the WG's extensions being implemented, which would be a sure sign of 
death. Am I looking in the wrong places? Who implements Annotate, for 
example?

--Arnt (who'd love to see Annotate in a server)

Date: Wed, 13 Nov 2002 13:09:23 -0600
To: Mark Crispin <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: Agenda
Cc: [email-masked]
Sender: [email-masked]

On 11/13/02 at 10:59 AM -0800, Mark Crispin wrote:

>I am coming to Atlanta since I was informed there was urgent IMAPEXT 
>business to be conducted.

I know that Randy Gellens is going. I was also told that Barry and 
Alexey would be going. I am curious who told you that there was 
"urgent" business, because I expect that at least that person would 
have some feedback on the proposed agenda. So far, I have gotten no 
feedback on the agenda except for the question from Ken. Do *you* 
have any feedback on the proposed agenda?

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

Date: Wed, 13 Nov 2002 10:59:00 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: Re: Agenda
To: Pete Resnick <[email-masked]>
cc: Ken Murchison <[email-masked]>, [email-masked]
Sender: [email-masked]

On Wed, 13 Nov 2002 12:46:46 -0600, Pete Resnick wrote:
> The silence around here is deafening. Who is coming to Atlanta? Do we
> need to cancel this meeting? Does anyone have any comment?

I am coming to Atlanta since I was informed there was urgent IMAPEXT business
to be conducted.

If that is not the case, and the IMAPEXT meeting is to be cancelled, I would
appreciate being told so that I can cancel the trip and hopefully get back
some of the Washington state taxpayer's money from the already-purchased plane
ticket (the conference fee being already lost).

Date: Wed, 13 Nov 2002 12:46:46 -0600
To: Ken Murchison <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: Agenda
Cc: [email-masked]
Sender: [email-masked]

On 11/9/02 at 10:58 PM -0500, Ken Murchison wrote:

>>It's time to make up the agenda for next week, folks. So far, 
>>here's what I've got:
>>
>>- Annotate
>>- ACL
>>- How to end the WG
>>
>>Please let me know what else there is to discuss. The WG has 
>>clearly (to my eyes) run out of steam and we need to get whatever 
>>we want to finish done quickly.
>
>Has LISTEXT fizzled out?

The silence around here is deafening. Who is coming to Atlanta? Do we 
need to cancel this meeting? Does anyone have any comment?

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

Date: Sat, 09 Nov 2002 22:58:34 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: [email-masked]
Subject: Re: Agenda
Sender: [email-masked]

Pete Resnick wrote:
> 
> It's time to make up the agenda for next week, folks. So far, here's
> what I've got:
> 
> - Annotate
> - ACL
> - How to end the WG
> 
> Please let me know what else there is to discuss. The WG has clearly
> (to my eyes) run out of steam and we need to get whatever we want to
> finish done quickly.

Has LISTEXT fizzled out?

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

Date: Sat, 9 Nov 2002 21:07:33 -0600
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: Agenda
Sender: [email-masked]

It's time to make up the agenda for next week, folks. So far, here's 
what I've got:

- Annotate
- ACL
- How to end the WG

Please let me know what else there is to discuss. The WG has clearly 
(to my eyes) run out of steam and we need to get whatever we want to 
finish done quickly.

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

From: The IESG <[email-masked]>
To: All IETF Working Groups: ;
Subject: Note Well Statement
Date: Thu, 07 Nov 2002 15:11:40 -0500
Sender: [email-masked]

>From time to time, especially just before a meeting, this statement is to
be sent to each and every IETF working group mailing list.
===========================================================================

				NOTE WELL

All statements related to the activities of the IETF and addressed to the
IETF are subject to all provisions of Section 10 of RFC 2026, which grants
to the IETF and its participants certain licenses and rights in such
statements.

Such statements include verbal statements in IETF meetings, as well as
written and electronic communications made at any time or place, which are
addressed to

    - the IETF plenary session,
    - any IETF working group or portion thereof,
    - the IESG, or any member thereof on behalf of the IESG,
    - the IAB or any member thereof on behalf of the IAB,
    - any IETF mailing list, including the IETF list itself,
      any working group or design team list, or any other list
      functioning under IETF auspices,
    - the RFC Editor or the Internet-Drafts function

Statements made outside of an IETF meeting, mailing list or other function,
that are clearly not intended to be input to an IETF activity, group or
function, are not subject to these provisions.

Date: Wed, 6 Nov 2002 16:07:19 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: [email-masked], <[email-masked]>
Subject: ANNOTATEMORE question
Sender: [email-masked]

I took a quick look at -01, and I have two brief comments:

In section 8.1:

        C: a GETANNOTATION "/server/%" "value"
        S: * ANNOTATION "/server/comment" ("value.priv" "My comment")
                                          ("value.shared" "Your comment")
                        "/server/motd" ("value.priv" "Its sunny outside!"
                                       ("value.shared" "Today is a Holiday")
        S: a OK GETANNOTATION complete

According to the grammar, shouldn't this be:

        S: * ANNOTATION "/server/comment" ("value.priv" "My comment"
                                           "value.shared" "Your comment")
                        "/server/motd" ("value.priv" "Its sunny outside!"
                                     "value.shared" "Today is a Holiday")

I'm guessing this example was just missed because of the grammar change.

Also, in section 6.1:

This entry could include named
attributes such as "value", "modifiedsince", "acl" etc to represent
properties and data associated with the entry.

But then it doesn't go on to discuss the semantics of "acl" at all (though
I seem to remember from one of our previous discussions that we didn't
really want all the complexity of a full "acl" system).  I think that
using acl here is confusing.

-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-----

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-annotate-05.txt
Date: Wed, 06 Nov 2002 06:29:55 -0500
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 ANNOTATE Extension
	Author(s)	: R. Gellens, C. Daboo
	Filename	: draft-ietf-imapext-annotate-05.txt
	Pages		: 20
	Date		: 2002-11-5
	
The ANNOTATE extension to the Internet Message Access Protocol
[IMAP4] permits clients and servers to maintain 'metadata' for
messages stored in an IMAP4 mailbox.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-imapext-annotate-05.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-annotate-05.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-annotate-05.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-annotate-05.txt

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

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

--OtherAccess--

--NextPart--

Date: Fri, 29 Nov 2002 16:01:31 -0800 (PST)
From: [email-masked]
Subject: Re: last call for 'MDN profile for IMAP (BCP)'
To: Alexey Melnikov <[email-masked]>
Cc: Harrie Hazewinkel <[email-masked]>, Tony Hansen <[email-masked]>, imap-ext IETF <[email-masked]>
Sender: [email-masked]

> Harrie Hazewinkel wrote:

> > On Wednesday, November 27, 2002, at 08:12 PM, Tony Hansen wrote:
> >
> > >
> > > As for the issue raised there in section 0, I'd be happy with changing
> > > the MUST NOT to a SHOULD NOT.
> >
> > That sounds better to me.
> > With that change you fix the document (it is the top of page 5, right?)
> > and you can drop the TODO.

> Done.

Alexey, if you're going to post a revised version you might as well
take care of these additional items I had slated for an RFC Editor
note:

(1) All the references in this document are normative and that needs to be
    stated in the title of section 10.
(2) The [IMAP4] reference should be changed to refer to
    draft-crispin-imapv-20.txt.

Thanks!

				Ned

Date: Fri, 29 Nov 2002 15:00:33 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Harrie Hazewinkel <[email-masked]>
CC: Tony Hansen <[email-masked]>, imap-ext IETF <[email-masked]>
Subject: Re: last call for 'MDN profile for IMAP (BCP)'
Sender: [email-masked]

Harrie Hazewinkel wrote:

> On Wednesday, November 27, 2002, at 08:12 PM, Tony Hansen wrote:
>
> >
> > As for the issue raised there in section 0, I'd be happy with changing
> > the MUST NOT to a SHOULD NOT.
>
> That sounds better to me.
> With that change you fix the document (it is the top of page 5, right?)
> and you can drop the TODO.

Done.

Cheers,
Alexey
__________________________________________
R & D, ACI Worldwide/MessagingDirect
Watford, UK

Work Phone: +44 1923 81 2877
Home Page: http://orthanc.ab.ca/mel

I speak for myself only, not for my employer.
__________________________________________

Date: Thu, 28 Nov 2002 09:23:20 +0100
Subject: Re: last call for 'MDN profile for IMAP (BCP)'
Cc: imap-ext IETF <[email-masked]>
To: Tony Hansen <[email-masked]>
From: Harrie Hazewinkel <[email-masked]>
Sender: [email-masked]

On Wednesday, November 27, 2002, at 08:12 PM, Tony Hansen wrote:

>
> As for the issue raised there in section 0, I'd be happy with changing 
> the MUST NOT to a SHOULD NOT.

That sounds better to me.
With that change you fix the document (it is the top of page 5, right?)
and you can drop the TODO.

>
> 	Tony
>
> [email-masked] wrote:
>>> While reading the draft draft-melnikov-imap-mdn-04.txt I wondered
>>> about the section '0. To do list and open issues'.
>>> There is still 1 item and how can this document then
>>> be in last call??
>> It is common for such sections to appear in documents that are last 
>> called.
>> They are always removed prior to publication. I already have an RFC 
>> Editor
>> note that says to do this along with several other things.

I know it happens, but it also creates a potential change (even though 
minor)
in the document not known yet.

>>> What would this todo item cause as changes in the document??
>> The presumption is that the issue, such as it is, will be left 
>> unresolved.
>> When I reviewed this I didn't think the issue was substantive. If it is
>> seen as substantive by someone, well, that's what last calls are for...

I agree this change is not substantive.

Harrie

Software developer, Technical Department

Date: Wed, 27 Nov 2002 22:45:16 -0800 (PST)
From: [email-masked]
Subject: Re: base spec clarification of UID command responses
To: Mark Crispin <[email-masked]>
Cc: Cyrus Daboo <[email-masked]>, IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

> On Wed, 27 Nov 2002 12:42:13 -0500, Cyrus Daboo wrote:
> > I think you can probably guess which - one which has other 'issues' with
> > the IMAP protocol.

> I did indeed guess that, and hence my response.  If there is a way that he can
> twist words around to break interoperability, he will find it.

> > I would suggest making the comment about FETCH vs UID FETCH a separate
> > sentence, so that the main statement requiring UID items stands by itself.
> > I guess that can go for the next set of revisions, if we find others have
> > made this mistake too.

> I'll ask the RFC editor if this can be done in the author's 48 hour process.

This is a reasonable change so I doubt this will be a problem.

				Ned

To: Mark Crispin <[email-masked]>
cc: IMAP Interest List <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: allow plaintext password if localhost connection? 
Date: Wed, 27 Nov 2002 13:57:44 -0700
From: Lyndon Nerenberg <[email-masked]>
Sender: [email-masked]

>I see no reason not to do this in UW imapd (and make a user very happy), but
>before I do it I'd like to get a sanity check from the community -- is there
>any reason why this might be a bad idea?

As long as you define "localhost" as "any interface that has the IFF_LOOPBACK
bit set" this should be fine.

I also allow plaintext authentication when the client and server talk
over named sockets (PF_UNIX).

--lyndon

Date: Wed, 27 Nov 2002 14:12:23 -0500
From: Tony Hansen <[email-masked]>
CC: imap-ext IETF <[email-masked]>
Subject: Re: last call for 'MDN profile for IMAP (BCP)'
Sender: [email-masked]

As for the issue raised there in section 0, I'd be happy with changing 
the MUST NOT to a SHOULD NOT.

	Tony

[email-masked] wrote:
> 
>> While reading the draft draft-melnikov-imap-mdn-04.txt I wondered
>> about the section '0. To do list and open issues'.
>> There is still 1 item and how can this document then
>> be in last call??
> 
> It is common for such sections to appear in documents that are last called.
> They are always removed prior to publication. I already have an RFC Editor
> note that says to do this along with several other things.
> 
>> What would this todo item cause as changes in the document??
> 
> The presumption is that the issue, such as it is, will be left unresolved.
> When I reviewed this I didn't think the issue was substantive. If it is
> seen as substantive by someone, well, that's what last calls are for...
> 
>                 Ned

Date: Wed, 27 Nov 2002 10:24:35 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: Re: base spec clarification of UID command responses
To: Cyrus Daboo <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

On Wed, 27 Nov 2002 12:42:13 -0500, Cyrus Daboo wrote:
> I think you can probably guess which - one which has other 'issues' with
> the IMAP protocol.

I did indeed guess that, and hence my response.  If there is a way that he can
twist words around to break interoperability, he will find it.

> I would suggest making the comment about FETCH vs UID FETCH a separate
> sentence, so that the main statement requiring UID items stands by itself.
> I guess that can go for the next set of revisions, if we find others have
> made this mistake too.

I'll ask the RFC editor if this can be done in the author's 48 hour process.

Date: Wed, 27 Nov 2002 12:42:13 -0500
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: base spec clarification of UID command responses
Sender: [email-masked]

Hi Mark,

--On Tuesday, November 26, 2002 3:58 PM -0800 Mark Crispin 
<[email-masked]> wrote:

| I agree with your interpretation; the text says "any FETCH response caused
| by a UID command".  Which server fails to return the UID item in FETCH
| responses?

I think you can probably guess which - one which has other 'issues' with 
the IMAP protocol. I actually now see that the user happened to have an old 
version of the server (dating from 2000) so I will tell them to upgrade and 
then see if this problem is still present.

| It may be more clear if the subsequent "to the FETCH" said "to a UID FETCH
| command."  Unfortunately, I fear that anyone who would argue that the
| existing wording meant that it only applied to UID FETCH commands would
| make the same argument to this wording.

I would suggest making the comment about FETCH vs UID FETCH a separate 
sentence, so that the main statement requiring UID items stands by itself. 
I guess that can go for the next set of revisions, if we find others have 
made this mistake too.

-- 
Cyrus Daboo

Date: Wed, 27 Nov 2002 09:01:13 -0800 (PST)
From: [email-masked]
Subject: Re: last call for 'MDN profile for IMAP (BCP)'
To: Harrie Hazewinkel <[email-masked]>
Cc: imap-ext IETF <[email-masked]>, [email-masked]
Sender: [email-masked]

> While reading the draft draft-melnikov-imap-mdn-04.txt I wondered
> about the section '0. To do list and open issues'.
> There is still 1 item and how can this document then
> be in last call??

It is common for such sections to appear in documents that are last called.
They are always removed prior to publication. I already have an RFC Editor
note that says to do this along with several other things.

> What would this todo item cause as changes in the document??

The presumption is that the issue, such as it is, will be left unresolved.
When I reviewed this I didn't think the issue was substantive. If it is
seen as substantive by someone, well, that's what last calls are for...

				Ned

Date: Wed, 27 Nov 2002 17:24:10 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: IMAP Interest List <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: allow plaintext password if localhost connection?
Sender: [email-masked]

Mark Crispin <[email-masked]>
> I recently received a request to allow plaintext passwords in unencrypted
> connections if the connection is localhost, even if plaintext passwords are
> otherwise forbidden in unencrypted connections.
> 
> I see no reason not to do this in UW imapd (and make a user very happy), but
> before I do it I'd like to get a sanity check from the community -- is there
> any reason why this might be a bad idea?

I'm inclined to agree with that user. Makes sense for stunnel port 993
tunnels etc.

But I'd think hard about whether there might be less benevolent tunnels
out there: http://www.bronnenberg.net/antispam/dsl.cable.redirect.html
suggests there are (in a different context).

--Arnt

Date: Wed, 27 Nov 2002 08:02:19 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: allow plaintext password if localhost connection?
To: IMAP Interest List <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

I recently received a request to allow plaintext passwords in unencrypted
connections if the connection is localhost, even if plaintext passwords are
otherwise forbidden in unencrypted connections.

I see no reason not to do this in UW imapd (and make a user very happy), but
before I do it I'd like to get a sanity check from the community -- is there
any reason why this might be a bad idea?

Date: Wed, 27 Nov 2002 15:58:01 +0100
Subject: last call for 'MDN profile for IMAP (BCP)'
Cc: [email-masked]
To: imap-ext IETF <[email-masked]>
From: Harrie Hazewinkel <[email-masked]>
Sender: [email-masked]

Hi,

While reading the draft draft-melnikov-imap-mdn-04.txt I wondered
about the section '0. To do list and open issues'.
There is still 1 item and how can this document then
be in last call??
What would this todo item cause as changes in the document??

 > APP	2002-12-06	MDN profile for IMAP (BCP)
 > draft-melnikov-imap-mdn-04.txt
 > Token:	Freed, Ned

Sorry, if it is already mentioned, but could not find
any comment in the archive of it.

Harrie

Software developer, Technical Department

Date: Wed, 27 Nov 2002 10:14:45 +0100
Subject: comments on draft-ietf-imapext-acl-06.txt
From: Harrie Hazewinkel <[email-masked]>
To: imap-ext IETF <[email-masked]>
Sender: [email-masked]

HI all,

Below I have some comments on the draft of
 >IMAPEXT Working Group                                     A. Melnikov
 >Internet Draft                                                 Editor
 >Document: draft-ietf-imapext-acl-06.txt                  October 2002

- During the document I see a lot of 'server implementation' speak,
so to say. I beleive the document improves readability if the
the formal protocol definition part and server implementation
guidelines are better seperated and indicated as such.

- Also an overall document roadmap helps to understand how
the author has organized the document. Also provide sometimes
a bit more text and what the purpose is of some parts.
IMHO, this document is well understood by people really into
the subject, but for outsiders it misses parts. This does not
mean I would like to see lots of duplicated text from for instance
rfc 2060, but a bit more self-sustainable improves it a lot.

- I seem to miss the real purpose of ACL in this document and
in perticular to what it applies. (Commented on below as well)

- I seem to miss a clear description of the
CAPABILITIES part for this IMAP extension.

- I seem to miss the behaviour of a server when the ACL is
changed on a shared mailbox and someone has the old ACL to this
mailbox still in his session or is his ACL reset during this
session. One time it only mentioned the rights to the
user (or authenticated id). In particular applicable to the
'ACL SET', but it influences also, for instance, 'ACL GET'.

 > 0.   Open issues

This would be better if combined with the TODO, I believe.

 >  1.   Abstract
 >
 >    The ACL extension of the Internet Message Access Protocol [IMAP4]
 >    permits access control lists to be manipulated through the IMAP
 >    protocol.

Some say no references in the abstract.
I also belive it would be better to extend ACL to 'access control'
and provde a samll description of what ACL means. Is the ACL for
message level or mailboxes level. It will improve readability.

 > 2.   Conventions Used in this Document
 >    In all examples "/" character is used as hierarchy separator.

Not sure, but it is not needed to have a single hierarchy seperator??
Agreed, this is maybe part of IMAP not this document.

 > 3.   Introduction and Overview

I do not see a sdescription of what ACL (access control) means here.
Is it per mailbox or per message. A short description would provide a
better readability.
One now assumes the reader laready knows, since in this section
various times an implementation is discussed. These implementation issues
are better to be placed in a seperate section with some name
as 'implementation guidelines' or so.

 >    The ACL extension is present in any IMAP4 implementation which
 >    returns a capability starting with "ACL2=" as one of the supported
 >    capabilities to the CAPABILITY command.

Does the '=' in 'ACL2=' stand for something?? Are the rights
listed after it??

 >    An access control list is a set of <identifier,rights> pairs.

This is not introduction anymore, but part of the ACL specification.
A seperate section is better.
 >
 >    Identifier is a UTF-8 string. An identifier may have one of the 
following
 >    forms:
 >      a). "anyone" - special identifier that refers to the universal 
identity
 >          (all authentications, including anonymous).
 >      b). "authuser" - special identifier that refer to all 
authenticated users,
 >          but not anonymous.
 >      c). "owner" - special identifier that refers to the owner of a 
mailbox
 >          (if any).
 >      d). "administrators" - special identifier that refers to all 
users with
 >          administrative rights.

How does one define who has administrator rigths?? Is this the 
administrator
of the mailbox or the server for instance.

 >      e). "user=<xxx>" - refers to a user. Here "<xxx>" is a user name 
string
 >          accepted by the LOGIN or AUTHENTICATE commands.
 >      f). "group=<xxx>" - refers to a group.

Why is '<xxx>' here not specified what it means??

 >      g). "-<identifier>", where <identifier> is one of a).-f). This is

How does one create a group via IMAP?? Or is this out-of-scope??
I am asking this, since I would believe that a user could potentially
create a mailbox for a big group and without the possibility
of creating a group the list of user=<xxx>,<rights> can become pretty
long.

 >          reserved for "negative rights", described below.

Why is the '-' sign in front of the identifier indicating the negative
rights?? Are they not supposed to be part of the rights?? So it should 
be in
front of the rights portion??

 > <<Reserve X- and V- prefixes?>>

What does this mean?? I presume author reminder??

 >    All other identifier names are reserved for future definition in an
 >    extension or revision to this specification (also known as ACL2).

How can one make implementation specific or better enterprise
specific identifiers??

 >    Rights is a string listing a (possibly empty) set of alphanumeric
 >    characters, each character listing a set of operations which is 
being
 >    controlled.  Letters are reserved for ''standard'' rights, listed
 >    below.  The set of standard rights may only be extended by a
 >    standards-track document.  Digits are reserved for implementation or
 >    site defined rights.

Here suddenly implementation or site defined rights. I believe it would
assist the implementor if a section is added for implementation specific
or enterprise specific right.

 >  The currently defined standard rights are:

A bit more eloborating on the rights would improve readability.

 >    l - lookup (mailbox is visible to LIST/LSUB commands, SUBSCRIBE 
mailbox)

Why is 'SUBSCRIBE' not a command??

 >    r - read (SELECT the mailbox, perform STATUS, CHECK, FETCH, SEARCH,
 >        COPY from mailbox)
 >    s - keep seen/unseen information across sessions (set or clear 
\SEEN flag
 >        via STORE, APPEND or COPY)

How does this work with multiple users sharing a mailbox??
Applies also to other rights.

 >    p - post (send mail to submission address for mailbox,
 >        not enforced by IMAP4 itself)

What is seen as the submission address??

 >    Server implementations are not required to support "negative right"
 >    identifiers.

How does one detect this?? Via the CAPABILITY??

 > 3.1. Rights required to perform different IMAP4rev1 commands

This is a more detailed part for the earlier rights. But in section
3 it is a little brief and here it is not done for all rights.

 > 4.   Commands

You introduce, for instance, directly 'all ACL commands' but what are 
these
commands for. I asume you mean here the commands that manipulate the 
access
control for mailboxes (or messages since not specified earlier).
improve readability.

 >     For simplicity the bahaviour of ACL STORE/DELETE/SET/GET/LIST 
commands

typo-> 'bahaviour' should be ' behaviour'.

 >     is described for a single mailbox case. When one or more mailbox 
pattern
 >     is specified, the server internally performs LIST command for all 
specified
 >     patterns and than it combines the results.

I understand the reason why one would like to explain it simple for a 
single
mailbox case, but I believe it helps an implementor a lot if the pattern
approach is discussed properly too.
This could be done in a subsection for instance. For an implementor I 
beleive
this is the most difficult part.

 >     Note, that only mailboxes for
 >     which the user has 'l' right are included in the combined result. 
If the
 >     combined result has no mailboxes, an ACL operation completes with 
success
 >    and the tagged OK response is sent. Otherwise the requested 
operation is
 >     performed for each mailbox in the combined result.

Do we not have a pattern approach here?? And it was mentioned only the 
single
mailbox approach is specified.

 > 4.1. ACL STORE

Some of the comments on this command do also apply
on the others, but are not repeated.

 >
 >    Arguments:  mailbox name or one or more mailbox masks
 >                authentication identifier
 >                access right modification

When having masks I can have multiple, but why not for specific
mailbox names??

 >    Data:       OPTIONAL untagged responses: ACLINFO
 >
 >    Result:     OK - ACL STORE completed
 >                NO - ACL STORE failure: can't set acl
 >                BAD - command unknown or arguments invalid
 >
 >       The ACL STORE command changes the access control list on the
 >       specified mailbox so that the specified identifier is granted
 >       permissions as specified in the third argument.

I see it is in line with the other drafts/RFCs, but why not first the
small description and then the precise definition??
What I believe is missing is the syntax of the commands, for instance,
<number> ACL STORE <.......

Also what is an argument?? Is the <number> in the command-line also
counted?? I would agree that it is specified in the IMAP RFC,
but repeating it here is not a problem, I beleive.

 >       The third argument is a string containing an optional plus ("+")
 >       or minus ("-") prefix, followed by zero or more rights 
characters.
 >       If the string starts with a plus, the following rights are added
 >       to any existing rights for the identifier.  If the string starts
 >       with a minus, the following rights are removed from any existing
 >       rights for the identifier.  If the string does not start with a
 >       plus or minus, the rights replace any existing rights for the
 >       identifier.
 >       Note, that for "ACL2=UNION" access calculation rule

Where does 'UNION' suddenly come from. It is mentioned earlier,
but I did not understood there what the purpose of it was.
This comes to a point that I believe where the CAPABILITIES
predefined or possible should be explained better in the beginning.
That should be done in a general sense, not like 'if an 
implementation...'
Now this document jumps between an 'implementation guideline' and
a specification of an IMAP extension.

Why here no example, since you do it later always for commands.

 > 6.   Formal Syntax
 >
 >    Formal syntax is defined using ABNF [ABNF] as modified by [IMAP4].
 >    Non-terminals referenced but not defined below are as defined by
 >    [IMAP4].
 >
 >    Except as noted otherwise, all alphabetic characters are
 >    case-insensitive.  The use of upper or lower case characters to
 >    define token strings is for editorial clarity only.  Implementations
 >    MUST accept these strings in a case-insensitive fashion.
 >
 >    acl2_command    = myrights | "ACL" SPACE acl2_subcommand

I understnad that the BNF al RFC 2060 is fixed, but an explaination
on how it fits in there is helpfull.
Even though, the command syntax is pretty clear.

7.1.  ACL access calculation rule Registration Template

    When an access calculation rule for ACL2 extension is registered, the
    following information is supplied:

    Rule Identification: specify a string that identifies this
       rule.  Unless the rule is registered with the IANA, the
       rule's identification must start with "X-".
       The server supporting a particular rule <rule-ID> MUST report
       "ACL2=<rule-ID>" in the capability list.

    Rule Semantics: specify how access rights for a mailbox are 
calculated.

    Negative rights allowed: specify whether "negative right" identifiers 
are
       allowed.

    Groups allowed: specify whether group identifiers are allowed.

    Special Identifiers: describe whether any implementation defined
       aliases are allowed and define their meaning.

    Contact Information: specify the postal and electronic contact
       information for the author of the feature.

8.   Initial Registrations

8.1.  Registration: UNION access calculation rule

    Rule Identification: UNION

    Rule Semantics: the union of the rights granted to
    the applicable identifiers minus the union of the negative rights.

    Negative rights allowed: Yes.

    Groups allowed: Yes, but not required.

    Special Identifiers: No.

    Contact Information: c.f., the "Editor's Address" section of this
       memo

8.2.  Registration: MOST-SPECIFIC access calculation rule

    Rule Identification: MOST-SPECIFIC

    Rule Semantics: the rights granted to the most specific identifier
       present in the ACL are used, i.e. if the user identifier is 
present,
       its ACL is used. If no user identifier is present, but a group that
       includes this user as a member is present, the group ACL is used.
       If neither user, nor group identifier is present, but an ACL for
       a special group "anyone" is present, the ACL for "anyone" is used.

    Negative rights allowed: No.

    Groups allowed: Yes, but not required.

    Special Identifiers: No.

    Contact Information: c.f., the "Editor's Address" section of this
       memo

 > 9.   Security Considerations
 >
 >    An implementation must make sure the ACL commands themselves do not
 >    give information about mailboxes with appropriately restricted 
ACL's.
 >    For example, a ACL GET command on a mailbox for which the user has
 >    insufficient rights should not admit the mailbox exists, much less
 >    return the mailbox's ACL.
 >
 >    IMAP clients implementing ACL2 that are able to modify ACLs SHOULD
 >    warn a user that wants to give full access to the special identifier
 >    "anyone".

What conditions of ACL must be met in order to retrieve the info
with 'ACL GET'??

 >    An ACL2 server MAY modify one or more ACL for one or more 
identifier as a
 >    side effect of modifying the ACL specified in ACL STORE/DELETE/SET.
 >    If the server does that it MUST send untagged ACL response to 
notify the
 >    client about the changes made.

I am not sure what this means, but I presume that if you change the
ACL for anyone it should also respond with the changed ACL for the
authenticated user itself??

Cheers,

Harrie

Software Developer, Technical Department

Date: Tue, 26 Nov 2002 15:58:43 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: base spec clarification of UID command responses
Organization: Networks & Distributed Computing
Sender: [email-masked]

Hi Cyrus -

I agree with your interpretation; the text says "any FETCH response caused
by a UID command".  Which server fails to return the UID item in FETCH
responses?

It may be more clear if the subsequent "to the FETCH" said "to a UID FETCH
command."  Unfortunately, I fear that anyone who would argue that the
existing wording meant that it only applied to UID FETCH commands would
make the same argument to this wording.

-- Mark --

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

Date: Tue, 26 Nov 2002 17:39:07 -0500
From: Cyrus Daboo <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: base spec clarification of UID command responses
Sender: [email-masked]

The UID command has the following text description included (from the 
latest draft):

      The number after the "*" in an untagged FETCH response is always a
      message sequence number, not a unique identifier, even for a UID
      command response.  However, server implementations MUST implicitly
      include the UID message data item as part of any FETCH response
      caused by a UID command, regardless of whether a UID was specified
      as a message data item to the FETCH.

I interpreted this to mean that any UID command, be it FETCH, STORE, COPY 
or SEARCH, has to always include UID items in any FETCH responses. However, 
I have come across at least one server that does not return the UID item in 
FETCH responses when doing a UID STORE. I'm concerned that the above 
paragraph might have been interpreted as meaning that the UID item is only 
required when UID FETCH is used, as opposed to the others.

The 'caused by' statement may be the problem - if a FETCH repsonse occurs 
during a COPY should those include UID items? Strictly speaking a COPY 
cannot change anything so 'caused by' cannot apply, so FETCH responses do 
not have to have UID items. I think this is ambiguous and needs to be 
cleared up (given that at least one implementor has done something 
different than the others).

-- 
Cyrus Daboo

Date: Thu, 21 Nov 2002 22:25:26 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: [email-masked]
Subject: Jabber Summarys
Sender: [email-masked]

The Jabber Summaries from the pre-meeting and the WG meeting are here:

http://www.jabber.com/chatbot/logs/conference.ietf.jabber.com/imapext/

The applicable files:
2002-11-20.html - Pre-Meeting
2002-11-21.html - WG Meeting.

-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: Thu, 21 Nov 2002 22:10:19 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: [email-masked]
Subject: imapext draft minutes
Sender: [email-masked]

Here are the minutes I took from the IETF IMAPEXT meeting.

Please review ;)

-Rob

---<cut here>---
Internet Message Access Protocol Extension WG minutes, Thu Nov 21 2002
reported by Rob Siemborski <[email-masked]>

Pete Resnick is chairing.

. Chair, introduction and agenda bashing

- This group is being stalled on various issues for too long, we need to
decide on what we need to get done and punt on what we can't.

. CONDSTORE - Alexey Melnikov
draft-melnikov-imap-condstore-08.txt

This draft is pretty much done with only minor open issues.

1. The inclusion of a shared flags response to the SELECT command.  The
purpose of the response would be to indicate which flags are shared
between users, and would be totally server-defined.

2. What kind of notification sequence should be returned if another
session modifies a flag with or without CONDSTORE?

Alexey will make a decision on both of these issues and post a final draft
before doing a last call (soon).

. ACL - Alexey Melnikov
draft-ietf-imapext-acl-06.txt

Minor issues:

1. Missing a section on compatibility with RFC2086.

Alexey has text and will include it in a new version of the draft.

2. Alexey added syntax to apply ACL commands to multiple mailboxes in
a single command, with individual failure notifications.

Larry Greenfield felt that this was unnecessary because it could be done
with pipelining of commands almost as easily and with no real loss in
functionality.  We also do not have a model for partial failures anywhere
else in IMAP, and is not sure if we really want to introduce one.

The chair asked Alexey to make a final decision and we'll see if people
scream on the list when the new draft is published.

Chris Newman expressed concerns that allowing different ACL models,
especially given that WebDAV's recent ACL draft was rejected by the IESG
for being too complicated.

Mark Crispin requested that we not put a minimum requirement on the
extension that implementors with legacy mail stores cannot meet, and that
this might be one of those requirements.

Ned Freed commented that WebDAV's rejection was not specifically for the ACL
models, but an overriding level of complexity.  He does not feel that IMAP
ACL even comes close.

Larry Greenfield commented that it is OK to have an extension that is
not implementable on all servers, and that it is also absolutely necessary
for all clients to understand how a server will react to ACL commands from
a security standpoint.  Currently we are using an IANA registry for this,
but will the clients be able to keep up?

Rough consensus to proceed down the current path, which is not as
complicated as webdav, and seek guidence from the security area.

3. The issue of tied rights.  Currently the client must do a LISTRIGHTS
before setting an ACL.  The proposal is to just have the client try to
set the ACL and return a NO with a LISTRIGHTS response code if rights do
happen to be tied and not all of them were specified.

No objections to this change.

- Cyrus commented that it might be nice to have a table in the draft of
which rights were required for which commands, even if such a table was
large.

. LISTEXT - Barry Leiba
(Expired Draft)

Issues:

1. Not including all LISTEXT capabilities in the CAPABILITIES response.
It was generally agreed that this isn't what we want to do.

2. Addition of extensible attribute value pairs at the end of the
response.  This was generally agreed to be a good idea.

3. Interaction with ANNOTATEMORE and ACL.  This would create some sort of
document dependency (one direction or another).

Mark Crispin prefers that all responses happen through the single LIST
interface.  No one saw a problem with this for ACL, and generally agreed
that it was a good idea.

Cyrus Daboo commented that we would need GETANNOTATION for /server
annotations atleast anyway.  General agreement that we should allow both
methods of fetching /mailbox annotations.  The chair suggested that we
will decide to deprecate one or the other once LISTEXT is available.

Larry Greenfield noted that if we are going down this path we want to be
absolutely certain that LISTEXT is extensible enough that we can get any
future per-mailbox information through a LISTEXT extension.

We will decide if ACL and ANNOTATEMORE depend on LISTEXT or the other
way around once we can see where LISTEXT is.  General preference appeared
to be that ANNOTATEMORE and ACL depend on LISTEXT.

Barry Leiba will have a new draft out next week.

. ANNOTATE[MORE] - Cyrus Daboo
draft-ietf-imapext-annotate-05.txt
draft-daboo-imap-annotatemore-01.txt

ANNOTATE Issues:

1. Dealing with system flags ('\' prefix), keywords ('$' prefix), and
'vendor flags' (no prefix)

Suggested solution was creating an IANA registry for keywords, and using
the ACAP vendor registry for vendor names, and using a hierarchy like:

/message/flag/XXX
/message/flag/vendor/YYY.ZZZ

Where XXX is a system flag or keyword without the prefix, YYY was a
registered vendor name, and ZZZ was the name of the vendor flag.

Mark Crispin noted that the vendor namespace doesn't make sense if a user
has their own flags.

Cyrus Daboo suggested creating a new prefix symbol to pull off the vendor
namespace, and perhaps adding a new annotation category for user flags.

Randall Gellens suggested the use of a single annotation that was a list
of all user flags.

This discussion was punted to the list.

2. Removing dependency on SORT, which will have i18n issues.  SORT would
add the ability to sort annotations back in.

3. Switch to using /message/envelope in ANNOTATE instead of
/message/smtp-envelope.  Specify that it contains RFC 2821 MAIL FROM And
RCPT TO stream data.  This requires attention in the Security
Considerations section as well.  We should probably break this out into a
separate document.

4. Add sieve-action annotation to ANNOTATE.  This should also probably be
a separate document.

The chair suggested removing as many of the annotations as possible and
placing them in an IANA registry.  Alexey will come up with a list of
which should be removed from the current draft.

Chris Newman wanted to add a caveat that sort on annotations was a
capability if both SORT and ANNOTATE was advertised.  Also, it would
be nice if SORT on annotations was left in the ANNOTATE document, even if
this meant that ANNOTATE was sitting in the IESG queue blocked on SORT.
(general agreement)

ANNOTATEMORE Issues:

1. Interaction with LISTEXT.

2. Right now we require an RFC to add an annotation to the IANA registry,
we want to change this to just require expert review.

Ned Freed stated that this sounded fine.

3. Barry Leiba expressed concerns about private vs. shared and
read-write vs read-only annotations in the /server hierarchy.

Cyrus Daboo commented that it was difficult because we lack ACLs for
/server.

Barry suggested that we just make a decision so that the behavior
was known.

4. Barry suggested that the ANNOTATION response should have defined
semantics as to when it is sent.  The suggestion is to always send /server
annotations, but only send /mailbox annotations for the currently selected
mailbox.  No objections.

. SORT/THREAD - Mark Crispin
draft-ietf-imapext-sort-10.txt
draft-ietf-imapext-thread-12.txt

Issues:

1. These drafts are being held up by the specification of a mandatory to
implement i18n solution.  Specifically, collation is problematic.

2. We might look into combining these two documents into a single
document, as they share a large amount of text.  This was left up to
whatever is easier for Mark.

3. Some have suggested other threading algorithms.  Mark felt that this
was a good idea as the threading document is already very complicated and
implementations are having trouble complying.  Future algorithms can be
provided in separate documents if this is desired.

. New i18n Document - Chris Newman

Randall Gellens and Chris Newman volunteered to create a single document
that would be an i18n spec for IMAP that could move everything forward.

Mark Crispin expressed nervousness about making it harder or more
confusing for implementations to comply, and that we would see binary
compare last much longer than it should.

Larry Greenfield suggested that the place for choosing the collation
mechanism is the ACAP comparator registry.  There isn't a good way to
allow SORT/THREAD to go forward without a mandatory to implement
comparator.

Chris suggested that we keep binary compare as the default, but
name a mandatory to implement comparator that is based on stringprep.
For example, binary compare on the output of stringprep.

The chair summarized the situation with the following steps:
  1. Convert to Unicode
  2. Run Stringprep
  3. Run your comparator (this may involve a conversion to UTF-8 if you
     are doing a binary compare).

. Search Extensions - Barry Leiba
(No Draft Available)

This is an extension from a while ago that recently some interest has been
expressed in again, especially given some discussion at the lemonade BOF.
We would like to be able to ask "for these folders do these searches and
give me back just the number of hits." This is related to
STATUS-COUNTERS, which would be a fast wrapper around the search
extensions.

Mark suggested adding the SCAN extension to the Search Extensions
draft.

. General Discussion

Chris Newman reminded everyone of the need review documents for nits
before submitting to the IESG.  There is a document at:
    http://www.ietf.org/ID-nits.html

The chair reminded the group that there is IMAP work going on in lemonade
that we should watch for.

Lyndon Nerenberg had commented on Jabber during the pre-meeting that he
had been having difficulty moving the CHANNEL extension forward, and
wanted to discuss it within imapext.

The chair commented that in actuality this draft had been picked up by
lemonade, and that was probably a good place for it to thrive.
---<cut here>---

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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: Sat, 16 Nov 2002 20:57:41 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Mark Crispin <[email-masked]>
CC: Pete Resnick <[email-masked]>, [email-masked]
Subject: Re: Agenda
Sender: [email-masked]

[Sorry, I've been on holidays this week.]

Mark Crispin wrote:

> On Wed, 13 Nov 2002 13:09:23 -0600, Pete Resnick wrote:
> > I am curious who told you that there was
> > "urgent" business
>
> Alexey, among others.

Yes, I did. We need to finish ACL2 and I think is it mostly complete.
Also, I would like to hear more feedback about other documents I am editing, in
particular QUOTA, UNSELECT, DISC and STATUS-COUNTERS.

> > So far, I have gotten no
> > feedback on the agenda except for the question from Ken. Do *you*
> > have any feedback on the proposed agenda?
>
> Past experience has caused me to hesitate to say much.  But if you insist:
>
> A look at the current IDs shows: QUOTA, ACL, ANNOTATE, CONDSTORE, DISC,
> KEYWORDS, MDN, UNSELECT, BINARY, CHANNEL, STATUS-COUNTERS, SORT, and THREAD.
> Why aren't all of these on the agenda?
>
> I, too, am disappointed to see nothing about LIST extensions, and feel that it
> should be on the agenda.
>
> I don't think IMAPEXT is anywhere near completion.  I am as weary of IMAPEXT
> as anyone else (remember, I opposed its creation in the first place).  But it
> needs to accomplish something before it is done.
>
> As far as I can tell, the only RFC is ID, and I forget if that's IMAPEXT or
> independent.  MULTIAPPEND got reviewed by IMAPEXT, and is in the RFC editor
> queue, but it too was independent.
>
> Most notably, IMAPEXT activity is still pending on four commonly-implemented
> extensions: ACL, QUOTA, SORT, and THREAD.

STATUS-COUNTERS should be discussed at LEMONADE on Thursday morning.
CONDSTORE is complete as far as I am concerned, but I have to fix couple small
open issues marked with <<>> in the document. Please, send me your feedback ASAP,
I am planning to request the Last Call soon.

Regards,
Alexey Melnikov
__________________________________________
R & D, ACI Worldwide/MessagingDirect
Watford, UK

Work Phone: +44 1923 81 2877
Home Page: http://orthanc.ab.ca/mel

I speak for myself only, not for my employer.
__________________________________________

Date: Sat, 16 Nov 2002 20:52:09 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Rob Siemborski <[email-masked]>
CC: [email-masked]
Subject: Re: Agenda
Sender: [email-masked]

Rob Siemborski wrote:

> On Wed, 13 Nov 2002, Pete Resnick wrote:
>
> > The silence around here is deafening. Who is coming to Atlanta? Do we
> > need to cancel this meeting? Does anyone have any comment?
>
> Both Larry and myself (and Walter) are planning on attending.

Chris is here as well.
Vladimir is coming Monday evening as well, unfortunately he is leaving on
Thursday.

Regards,
Alexey Melnikov
__________________________________________
R & D, ACI Worldwide/MessagingDirect
Watford, UK

Work Phone: +44 1923 81 2877
Home Page: http://orthanc.ab.ca/mel

I speak for myself only, not for my employer.
__________________________________________

Date: Sat, 16 Nov 2002 13:08:20 -0800 (PST)
From: [email-masked]
Subject: Re: Agenda
To: Mark Crispin <[email-masked]>
Cc: Lyndon Nerenberg <[email-masked]>, Pete Resnick <[email-masked]>, [email-masked]
Sender: [email-masked]

> On Fri, 15 Nov 2002 11:32:38 -0700, Lyndon Nerenberg wrote:
> > Binary and Channel aren't covered by the charter. And Binary is
> > finished, so it can come off that list.

> I still think that IMAPEXT ought to take a look.

> Can you elaborate what you mean by "finished"?  Has it been approved by the
> IESG?

Binary was last called 22-Jan-2002. Afer IESG review and some revisions it was
approved by the IESG on 14-Nov-2002. Channel has yet to be last called and it
is my understanding that the current draft isn't ready for AD review yet.

				Ned

Date: Fri, 15 Nov 2002 11:07:41 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: re: Binary status (was Re: Agenda)
To: Lyndon Nerenberg <[email-masked]>
cc: [email-masked]
Sender: [email-masked]

On Fri, 15 Nov 2002 12:06:24 -0700, Lyndon Nerenberg wrote:
> Well, the spec was seen and commented on by quite a few IMAPEXT
> participants. and ietf-imapext received the four week last call
> announcement.

Really?  I don't recall seeing it.

>      If the specified mailbox does not support the storage of binary
>      content, the server MUST fail the request and issue a "NO" response
>      that contains the "UNKNOWN-CTE" extended response code.

I am aware of this, but this requires the client to do two transmissions of
the data.  There should be a capability so that the client knows in advance
before wasting its time.

To: Mark Crispin <[email-masked]>
cc: [email-masked]
Subject: Binary status (was Re: Agenda)
Date: Fri, 15 Nov 2002 12:06:24 -0700
From: Lyndon Nerenberg <[email-masked]>
Sender: [email-masked]

>I still think that IMAPEXT ought to take a look.

Well, the spec was seen and commented on by quite a few IMAPEXT
participants. and ietf-imapext received the four week last call
announcement.

>Can you elaborate what you mean by "finished"?  Has it been approved by the
>IESG?

The last call IESG objections have been addressed, so I expect final
IESG approval any day now.

>In reviewing BINARY, I think that the ability to APPEND binary data should be
>indicated by a separate capability.  I'm likely to add support for binary
>fetching, but not for appending.

Section 6.4:

     [...]
     If the specified mailbox does not support the storage of binary
     content, the server MUST fail the request and issue a "NO" response
     that contains the "UNKNOWN-CTE" extended response code.

After this response a reasonable client will fall back to the basic
APPEND syntax (with encoding).

--lyndon

Date: Fri, 15 Nov 2002 10:44:10 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: Re: Agenda 
To: Lyndon Nerenberg <[email-masked]>
cc: Pete Resnick <[email-masked]>, [email-masked]
Sender: [email-masked]

On Fri, 15 Nov 2002 11:32:38 -0700, Lyndon Nerenberg wrote:
> Binary and Channel aren't covered by the charter. And Binary is
> finished, so it can come off that list.

I still think that IMAPEXT ought to take a look.

Can you elaborate what you mean by "finished"?  Has it been approved by the
IESG?

In reviewing BINARY, I think that the ability to APPEND binary data should be
indicated by a separate capability.  I'm likely to add support for binary
fetching, but not for appending.

To: Mark Crispin <[email-masked]>
cc: Pete Resnick <[email-masked]>, [email-masked]
Subject: Re: Agenda 
Date: Fri, 15 Nov 2002 11:32:38 -0700
From: Lyndon Nerenberg <[email-masked]>
Sender: [email-masked]

>A look at the current IDs shows: QUOTA, ACL, ANNOTATE, CONDSTORE, DISC,
>KEYWORDS, MDN, UNSELECT, BINARY, CHANNEL, STATUS-COUNTERS, SORT, and THREAD.
>Why aren't all of these on the agenda?

Binary and Channel aren't covered by the charter. And Binary is
finished, so it can come off that list.

Also, I will _not_ be going to Atlanta.

--lyndon

Date: Wed, 13 Nov 2002 14:27:30 -0800
From: Chris Newman <[email-masked]>
Subject: Re: Agenda
To: Pete Resnick <[email-masked]>, Ken Murchison <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

I will be there.  I think we should have a meeting at least to go over any 
remaining open issues on the drafts that were revised.  Perhaps also to 
discuss possible solutions to the i18n problem with SORT/THREAD.

                - Chris

begin  quotation by Pete Resnick on 2002/11/13 12:46 -0600:

>
> On 11/9/02 at 10:58 PM -0500, Ken Murchison wrote:
>
>>> It's time to make up the agenda for next week, folks. So far,
>>> here's what I've got:
>>>
>>> - Annotate
>>> - ACL
>>> - How to end the WG
>>>
>>> Please let me know what else there is to discuss. The WG has
>>> clearly (to my eyes) run out of steam and we need to get whatever
>>> we want to finish done quickly.
>>
>> Has LISTEXT fizzled out?
>
> The silence around here is deafening. Who is coming to Atlanta? Do we
> need to cancel this meeting? Does anyone have any comment?
>
> pr
> --
> Pete Resnick <mailto:[email-masked]>
> QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Wed, 13 Nov 2002 15:03:29 -0500
From: Cyrus Daboo <[email-masked]>
To: Pete Resnick <[email-masked]>
cc: [email-masked]
Subject: Re: Agenda
Sender: [email-masked]

Hi Pete,

--On Wednesday, November 13, 2002 12:46 PM -0600 Pete Resnick 
<[email-masked]> wrote:

| The silence around here is deafening. Who is coming to Atlanta? Do we
| need to cancel this meeting? Does anyone have any comment?

I should be present provided our major release actually gets done later 
today...

-- 
Cyrus Daboo

Date: Wed, 13 Nov 2002 14:40:54 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: [email-masked]
Subject: Re: Agenda
Sender: [email-masked]

On Wed, 13 Nov 2002, Pete Resnick wrote:

> The silence around here is deafening. Who is coming to Atlanta? Do we
> need to cancel this meeting? Does anyone have any comment?

Both Larry and myself (and Walter) are planning on attending.

-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: Wed, 13 Nov 2002 11:11:39 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: Re: Agenda
To: Pete Resnick <[email-masked]>
cc: [email-masked]
Sender: [email-masked]

On Wed, 13 Nov 2002 13:09:23 -0600, Pete Resnick wrote:
> I am curious who told you that there was
> "urgent" business

Alexey, among others.

> So far, I have gotten no
> feedback on the agenda except for the question from Ken. Do *you*
> have any feedback on the proposed agenda?

Past experience has caused me to hesitate to say much.  But if you insist:

A look at the current IDs shows: QUOTA, ACL, ANNOTATE, CONDSTORE, DISC,
KEYWORDS, MDN, UNSELECT, BINARY, CHANNEL, STATUS-COUNTERS, SORT, and THREAD.
Why aren't all of these on the agenda?

I, too, am disappointed to see nothing about LIST extensions, and feel that it
should be on the agenda.

I don't think IMAPEXT is anywhere near completion.  I am as weary of IMAPEXT
as anyone else (remember, I opposed its creation in the first place).  But it
needs to accomplish something before it is done.

As far as I can tell, the only RFC is ID, and I forget if that's IMAPEXT or
independent.  MULTIAPPEND got reviewed by IMAPEXT, and is in the RFC editor
queue, but it too was independent.

Most notably, IMAPEXT activity is still pending on four commonly-implemented
extensions: ACL, QUOTA, SORT, and THREAD.

From: Arnt Gulbrandsen <[email-masked]>
To: Pete Resnick <[email-masked]>
Subject: Re: Agenda
Cc: Ken Murchison <[email-masked]>, [email-masked]
Date: Wed, 13 Nov 2002 20:37:56 +0100
Sender: [email-masked]

Pete Resnick writes:
> The silence around here is deafening. Who is coming to Atlanta? Do we 
> need to cancel this meeting? Does anyone have any comment?

I'm not a WG member, I suppose, but I'll offer a comment: I don't see 
the WG's extensions being implemented, which would be a sure sign of 
death. Am I looking in the wrong places? Who implements Annotate, for 
example?

--Arnt (who'd love to see Annotate in a server)

Date: Wed, 13 Nov 2002 13:09:23 -0600
To: Mark Crispin <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: Agenda
Cc: [email-masked]
Sender: [email-masked]

On 11/13/02 at 10:59 AM -0800, Mark Crispin wrote:

>I am coming to Atlanta since I was informed there was urgent IMAPEXT 
>business to be conducted.

I know that Randy Gellens is going. I was also told that Barry and 
Alexey would be going. I am curious who told you that there was 
"urgent" business, because I expect that at least that person would 
have some feedback on the proposed agenda. So far, I have gotten no 
feedback on the agenda except for the question from Ken. Do *you* 
have any feedback on the proposed agenda?

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

Date: Wed, 13 Nov 2002 10:59:00 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: Re: Agenda
To: Pete Resnick <[email-masked]>
cc: Ken Murchison <[email-masked]>, [email-masked]
Sender: [email-masked]

On Wed, 13 Nov 2002 12:46:46 -0600, Pete Resnick wrote:
> The silence around here is deafening. Who is coming to Atlanta? Do we
> need to cancel this meeting? Does anyone have any comment?

I am coming to Atlanta since I was informed there was urgent IMAPEXT business
to be conducted.

If that is not the case, and the IMAPEXT meeting is to be cancelled, I would
appreciate being told so that I can cancel the trip and hopefully get back
some of the Washington state taxpayer's money from the already-purchased plane
ticket (the conference fee being already lost).

Date: Wed, 13 Nov 2002 12:46:46 -0600
To: Ken Murchison <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: Agenda
Cc: [email-masked]
Sender: [email-masked]

On 11/9/02 at 10:58 PM -0500, Ken Murchison wrote:

>>It's time to make up the agenda for next week, folks. So far, 
>>here's what I've got:
>>
>>- Annotate
>>- ACL
>>- How to end the WG
>>
>>Please let me know what else there is to discuss. The WG has 
>>clearly (to my eyes) run out of steam and we need to get whatever 
>>we want to finish done quickly.
>
>Has LISTEXT fizzled out?

The silence around here is deafening. Who is coming to Atlanta? Do we 
need to cancel this meeting? Does anyone have any comment?

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

Date: Sat, 09 Nov 2002 22:58:34 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: [email-masked]
Subject: Re: Agenda
Sender: [email-masked]

Pete Resnick wrote:
> 
> It's time to make up the agenda for next week, folks. So far, here's
> what I've got:
> 
> - Annotate
> - ACL
> - How to end the WG
> 
> Please let me know what else there is to discuss. The WG has clearly
> (to my eyes) run out of steam and we need to get whatever we want to
> finish done quickly.

Has LISTEXT fizzled out?

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

Date: Sat, 9 Nov 2002 21:07:33 -0600
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: Agenda
Sender: [email-masked]

It's time to make up the agenda for next week, folks. So far, here's 
what I've got:

- Annotate
- ACL
- How to end the WG

Please let me know what else there is to discuss. The WG has clearly 
(to my eyes) run out of steam and we need to get whatever we want to 
finish done quickly.

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

From: The IESG <[email-masked]>
To: All IETF Working Groups: ;
Subject: Note Well Statement
Date: Thu, 07 Nov 2002 15:11:40 -0500
Sender: [email-masked]

>From time to time, especially just before a meeting, this statement is to
be sent to each and every IETF working group mailing list.
===========================================================================

				NOTE WELL

All statements related to the activities of the IETF and addressed to the
IETF are subject to all provisions of Section 10 of RFC 2026, which grants
to the IETF and its participants certain licenses and rights in such
statements.

Such statements include verbal statements in IETF meetings, as well as
written and electronic communications made at any time or place, which are
addressed to

    - the IETF plenary session,
    - any IETF working group or portion thereof,
    - the IESG, or any member thereof on behalf of the IESG,
    - the IAB or any member thereof on behalf of the IAB,
    - any IETF mailing list, including the IETF list itself,
      any working group or design team list, or any other list
      functioning under IETF auspices,
    - the RFC Editor or the Internet-Drafts function

Statements made outside of an IETF meeting, mailing list or other function,
that are clearly not intended to be input to an IETF activity, group or
function, are not subject to these provisions.

Date: Wed, 6 Nov 2002 16:07:19 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: [email-masked], <[email-masked]>
Subject: ANNOTATEMORE question
Sender: [email-masked]

I took a quick look at -01, and I have two brief comments:

In section 8.1:

        C: a GETANNOTATION "/server/%" "value"
        S: * ANNOTATION "/server/comment" ("value.priv" "My comment")
                                          ("value.shared" "Your comment")
                        "/server/motd" ("value.priv" "Its sunny outside!"
                                       ("value.shared" "Today is a Holiday")
        S: a OK GETANNOTATION complete

According to the grammar, shouldn't this be:

        S: * ANNOTATION "/server/comment" ("value.priv" "My comment"
                                           "value.shared" "Your comment")
                        "/server/motd" ("value.priv" "Its sunny outside!"
                                     "value.shared" "Today is a Holiday")

I'm guessing this example was just missed because of the grammar change.

Also, in section 6.1:

This entry could include named
attributes such as "value", "modifiedsince", "acl" etc to represent
properties and data associated with the entry.

But then it doesn't go on to discuss the semantics of "acl" at all (though
I seem to remember from one of our previous discussions that we didn't
really want all the complexity of a full "acl" system).  I think that
using acl here is confusing.

-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-----

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-annotate-05.txt
Date: Wed, 06 Nov 2002 06:29:55 -0500
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 ANNOTATE Extension
	Author(s)	: R. Gellens, C. Daboo
	Filename	: draft-ietf-imapext-annotate-05.txt
	Pages		: 20
	Date		: 2002-11-5
	
The ANNOTATE extension to the Internet Message Access Protocol
[IMAP4] permits clients and servers to maintain 'metadata' for
messages stored in an IMAP4 mailbox.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-imapext-annotate-05.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-annotate-05.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-annotate-05.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-annotate-05.txt

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

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

--OtherAccess--

--NextPart--