Subject: RE: I-D ACTION:draft-daboo-imap-view-00.txt
From: Mark Crispin <[email-masked]>
To: [email-masked]
Cc: "'Alexey Melnikov'" <[email-masked]>, [email-masked], "'Cyrus Daboo'" <[email-masked]>
Date: Wed, 30 Jun 1999 17:05:30 -0700 (PDT)

On Wed, 30 Jun 1999 10:31:39 -0700, CJ Lofstedt wrote:
> I would also be interested in hearing why the "overloaded SELECT" (view as a
> folder) approach has been completely ruled out.

The short answer is "several people who work with IMAP don't like the idea of
overloading SELECT.  They think that they have a better way, and don't want to
do any work on what they consider to be inferior."

Basically, the problem with overloading SELECT is just that; it overloads an
existing mechanism and thus requires a server modality that changes existing
IMAP commands and responses, and too many incompatible changes need to be made
to the existing mechanism.

Another issue is that the client may want to change the view on the selected
mailbox.  With the VIEW architecture, this is simple; just do a new VIEW SET.
But, with overloaded SELECT, you have to issue a new SELECT.

Overloaded SELECT also limits the view mechanism to what is defined in the
overload.  VIEW, on the other hand, is designed to be extensible.

There's a few other issues, but these are the big ones.

These problems with overloaded SELECT aren't unsolvable.  However, (at least
in my opinion) the VIEW architecture is superior in all respects and there
really isn't much point to wasting time on overloaded SELECT.  It is superior
to add to IMAP instead of changing what is already there.

With all of the above in mind, I would not object to adding a means to do both
a SELECT and a VIEW SET in the same command, e.g. something like
	tag VIEW SELECT INBOX SEARCH FROM "Fred"
that is, a VIEW SELECT command whose first argument is the mailbox name to be
selected and subsequent arguments are as in VIEW SET.  It would have to be
stipulated that you can change the view with VIEW SET and don't need to issue
another VIEW SELECT -- so VIEW SELECT is just a way of reducing RTTs.

Reply-To: <[email-masked]>
From: "CJ Lofstedt" <[email-masked]>
To: "'Alexey Melnikov'" <[email-masked]>, <[email-masked]>, "'Cyrus Daboo'" <[email-masked]>
Subject: RE: I-D ACTION:draft-daboo-imap-view-00.txt
Date: Wed, 30 Jun 1999 10:31:39 -0700
Importance: Normal
Sender: [email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Alexey Melnikov
> Sent: Tuesday, June 29, 1999 4:19 PM
> To: Cyrus Daboo
> Cc: [email-masked]
> Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt
>
>
> Cyrus Daboo wrote:
>
> > Hi folks,
> > A new internet draft is available at:
> >
> > <http://www.ietf.org/internet-drafts/draft-daboo-imap-view-00.txt>
> >
> > [skipped]
> >
> > Note that this document proposes a mechanism different from
> that discussed
> > by various groups at recent IETF and IMC interop meetings.
> I can post a
> > list of reasons why we feel this approach is better if
> there is interest.
>
> I understand most of them (I didn't like the idea to overload
> SELECT from the
> beginning), but I would like to know them all.
>

I would also be interested in hearing why the "overloaded SELECT" (view as a
folder) approach has been completely ruled out.

/C-J Lofstedt

Date: Wed, 30 Jun 1999 08:08:52 -0400
From: Barry Leiba <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt
Originator-Info: login-id=leiba; server=mars.watson.ibm.com
Sender: [email-masked]

Cyrus says...
> No - a VIEW SET without a sub-command cancels the view mode.

As all three of you said; yes, I must have been distracted when I was
reading that part.  Sorry.

> Agreed. This document should define what commands are currently valid with
> VIEW SET, with provisions for future extensions to define new
> sub-commands.

I agree with Mark that we don't want to limit ourselves, but what Cyrus
says above was my intent when I made my comment: make it clear what
commands are appropriate now (and make it clear what the response will be
("BAD", I think) if you use an inappropriate command), and also make it
clear that future extensions may add commands to the "appropriate" list.

> Your're right. I guess I failed to pay full attention in my Latin classes!

:-)

> I think it must be a BAD. The document must say that clients MUST NOT
> issue the VIEW command when a VIEW SET is not operational, and servers
> MUST respond with BAD. This can be clarified in section 4.2.

Agreed.  Good.

Me:
>>   ...but you've already said that a VIEW fetch item must be included if
>>   a VIEW SET is in effect.  If I'm right in my previous note, then you
>>   probably shouldn't *also* say this.

Alexey:
> IMHO, it is not a big trouble to say something twice, especially in this
> case.

I'd generally agree, but the trouble here is that it's being said slightly
different, and I worry that the difference will confuse someone who's
reading the spec with only a marginal understanding of what's going on.

Cyrus:
> Actually 4.1(c) only refers to unsolicited FETCH responses. Perhaps this
> should be changed to 'all FETCH responses' in 4.1(c) and the section
> quoted above dropped.

Yeah, I like that answer.

>>   Understandable.  But that means that a client that receives an EXISTS
>>   in response to a FETCH must then go issue a NOOP to get the
>>   corresponding  VIEW response.  Can we think of a better way?
> 
> Hmm, that's a difficult one. I'm sure we can come up with a wy to deal
> with this.

Since I won't be in Oslo, if you discuss this there I'd like to see a
summary posted here.  Well, I suppose that someone'll take minutes of the
WG meeting and the whole thing'll be posted here anyway, so....

> No, you have to have the VIEW commands because there is no way to know how
> the UIDs map into the view. Clients must be able to say 'fetch the first
> ten messages in my sorted view'. Without VIEW FETCH the client has no way
> of knowing the sequence numbers or UIDs of these messages without first
> doing a 'FETCH 1:* (UID VIEW)', which would defeat the whole purpose of
> VIEW itself.

Well, duh.  Of course; I didn't think it out enough before I said what I
said.  Mark's also right about the hierarchy.  Of *course* we need the VIEW
FETCH command and so on.

> Having said that, with the 'dynamic' view approach it does need to be made
> clear that clients will need to maintain their own UID mappings, as they
> may need to access messages that move outside the view (as per your
> example).

Maybe a section on "implementation considerations" would be useful.  It
could highlight this, it could suggest when a client might want to use VIEW
(and when not), and that sort of thing.  Something brief, naturally, but it
might be nice to have.  (Again, I'm thinking of some of the questions we
see people asking about IMAP sometimes, which indicate that they're trying
to implement it without understanding it.)

Barry Leiba, Internet Messaging Technology   ([email-masked])
http://www.research.ibm.com/people/l/leiba

Date: Tue, 29 Jun 1999 20:22:42 -0400
From: Cyrus Daboo <[email-masked]>
To: Barry Leiba <[email-masked]>
cc: [email-masked]
Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt
Originator-Info: login-id=daboo; server=imap.cyrusoft.com:431
Sender: [email-masked]

--On Tue, Jun 29, 1999 3:21 PM -0400 Barry Leiba <[email-masked]>
wrote:

> * Section 4.1 refers to an "optional" sub-command, and (a) says that 
>   the  VIEW SET command selects messages that "match the results of the
>   sub-command".  It doesn't make it clear what happens if there's no
>   sub-command (all messages are selected, I presume).

No - a VIEW SET without a sub-command cancels the view mode. The server
then falls back to 'standard' IMAP4 behaviour and the VIEW ... commands are
invalid.

>   It also doesn't
>   say much about the sub-command; if "SEARCH" is the only command in
>   the base spec that applies, it should probably say so, to prevent
>   people from wondering what commands apply.  It might also say (which
>   is also said elsewhere) that it's intended that future SORT and 
>   THREAD commands may go here. 

Agreed. This document should define what commands are currently valid with
VIEW SET, with provisions for future extensions to define new sub-commands.

> * In 4.1 (b), "c.f." is properly abbreviated "cf.", and, anyway, is the
>   wrong Latin abbreviation here.  "cf." means "compare" (from the Latin
>   "confer"), and I don't think you want anyone to compare what you say
>   here to what's said in 4.2.  If you mean "see section 4.2", just say it.
>   (Sorry... pet peeve about misuse of Latin abbreviations.)

Your're right. I guess I failed to pay full attention in my Latin classes!

> * In 4.2 you should make it clear what, if anything, it means to use a
>   VIEW command without a VIEW SET being in effect.  It seems to me that
>   it's nonsensical (so should "VIEW FETCH" respond "NO" or "BAD" in that
>   case?).

I think it must be a BAD. The document must say that clients MUST NOT issue
the VIEW command when a VIEW SET is not operational, and servers MUST
respond with BAD. This can be clarified in section 4.2.

> * In 4.2, you say
>     command response.  However, server implementations MUST implicitly
>     include the VIEW fetch item as part of any FETCH response caused by
>     a VIEW command, regardless of whether a VIEW was specified as a
>     message data item to the FETCH.
> 
>   ...but you've already said that a VIEW fetch item must be included if
>   a VIEW SET is in effect.  If I'm right in my previous note, then you
>   probably shouldn't *also* say this.

Actually 4.1(c) only refers to unsolicited FETCH responses. Perhaps this
should be changed to 'all FETCH responses' in 4.1(c) and the section quoted
above dropped.

> * In 5.1.1:
>     A VIEW untagged response MUST NOT be sent when no command is in
>     progress; nor while responding to a FETCH, SEARCH or STORE command.
> 
>   Understandable.  But that means that a client that receives an EXISTS
>   in response to a FETCH must then go issue a NOOP to get the
>   corresponding  VIEW response.  Can we think of a better way?

Hmm, that's a difficult one. I'm sure we can come up with a wy to deal with
this.

> * In 5.1.2:
>     When the old view position number in the VIEW untagged response is
>     non-zero, the effect of VIEW is a message inserted into the view at
>     the position given by <new>.  The view position numbers of all
>     subsequent messages inthge current view are incremented.
> 
>     When the new view position number in the VIEW untagged response is
>     non-zero, the effect of VIEW is a message removed from the view at
>     the position given by <old>.  The view position numbers of all
>     subsequent messages inthe current view are decremented.
> 
>   In both of these, I think you mean "zero" where you say "non-zero".

Yup, that's wrong in the document.

>   Also also, since you explicitly talk about incrementing and decrementing
>   view position numbers, perhaps you should include a paragraph about what
>   happens if both the old and new positions are non-zero... which also
>   require renumbering other messages.  No, *I* don't think it needs to be
>   said, but, then, I'm always surprised at the interpretations that
>   sometimes happen when one fails to say something.  :-)

This can easily be added, and would be a good example to clarify things.

> * In the grammar:
>     position         ::= number ["." number]
>                          ;; position number of messages in the view
>                          ;; may be hierarchical if sub-command defines
>                          ;; hierarchic ordering of messages
> 
>   This makes some of the statements about "incrementing" and
>   "decrementing" view positions harder to understand.  Maybe all we
>   should say about what happens after a VIEW response is that "view
>   positions of subsequent [or intervening] messages must be adjusted
>   appropriately" or some such.

That phrase could be used together with the existing examples.

> * Finally, just to clarify things... we'd had an extended discussion about
>   whether it was reasonable to remove a message from a view, once it was
>   in the view.  Problems of side-effects and such -- for instance, what 
>   happens in the following case (abbreviating a little):
>     c: t0 VIEW SET SEARCH UNSEEN
>     s: * 25 VIEW 1234 0 4
>     c: t1 VIEW FETCH 4 BODY[1]
>     s: * 25 FETCH (FLAGS (\Seen) VIEW 4 BODY[1] ...
>     s: t1 OK done
>     c: t2 NOOP
>     s: * 25 VIEW 1234 4 0    [\Seen flag caused view to change]
>     s: t2 OK done
> 
>   Now, as a side-effect of the FETCH, the client can no longer use VIEW
>   FETCH on this message.  Other cases are easy to imagine.  It makes VIEW
>   FETCH of questionable use.
> 
>   Clearly, the decision made in writing this draft was to have messages 
>   disappear from the view (during earlier discussions, some thought they 
>   should not, though it came out that that makes reconnecting after
>   connection  failures difficult).
> 
>   I just wanted to point out, for the record, that there were two sides to
>   that discussion, and to point out, for the record, which one was
>   adopted. (And, for the record, I agree with the choice.)

I think the issue of 'static' vs 'dynamic' views still needs more
discussion. I've not ruled out one or the other or indeed both.

For example to do VIEW in static mode, we just remove the unsolicted VIEW
untagged response and add a 'VIEW UPDATE' command, which returns untagged
VIEWs for all changes since the last VIEW SET or VIEW UPDATE.

One could even envisage a situation where the client determines whether the
view is static or dynamic based on the command it issues.

>   But I would like to see some of these potential problems mentioned in
>   the  spec.  I would also like to see some encouragement to use UIDs
>   instead of view positions.  In fact, I'd go as far as to say that I
>   don't think we should *have* a VIEW FETCH, VIEW STORE, or VIEW COPY
>   command, and that we should clearly state that UIDs are the things to
>   use when you're using views.

No, you have to have the VIEW commands because there is no way to know how
the UIDs map into the view. Clients must be able to say 'fetch the first
ten messages in my sorted view'. Without VIEW FETCH the client has no way
of knowing the sequence numbers or UIDs of these messages without first
doing a 'FETCH 1:* (UID VIEW)', which would defeat the whole purpose of
VIEW itself.

Having said that, with the 'dynamic' view approach it does need to be made
clear that clients will need to maintain their own UID mappings, as they
may need to access messages that move outside the view (as per your
example).

--
Cyrus

Date: Tue, 29 Jun 1999 16:25:56 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt
To: Barry Leiba <[email-masked]>
cc: Cyrus Daboo <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

First, an apology.  My contribution to this document so far has been mostly
architectural, so if I say something that doesn't fully mesh with what the
document says, keep this in mind.

> * Section 4.1 refers to an "optional" sub-command, and (a) says that
>   the  VIEW SET command selects messages that "match the results of the
>   sub-command".  It doesn't make it clear what happens if there's no
>   sub-command (all messages are selected, I presume).

I thought that VIEW SET without a command was to cancel the view.  If this
isn't specified, it should be.

>   It also doesn't
>   say much about the sub-command; if "SEARCH" is the only command in
>   the base spec that applies, it should probably say so, to prevent
>   people from wondering what commands apply.  It might also say (which
>   is also said elsewhere) that it's intended that future SORT and
>   THREAD commands may go here.

Let's talk about the wordsmithing for this at Oslo.  VIEW SET's command
argument is a command that defines a set (and, potentially, ordering) of
messages.  I agree that this needs to be well-specified, but I don't want to
tag/limit it to SEARCH/SORT/THREAD even if that's the actual situation today.

> * In 4.2 you should make it clear what, if anything, it means to use a
>   VIEW command without a VIEW SET being in effect.  It seems to me that
>   it's nonsensical (so should "VIEW FETCH" respond "NO" or "BAD" in that
>   case?).

I think that it's a BAD.

>   I would also like to see some encouragement to use UIDs instead of
>   view positions.  In fact, I'd go as far as to say that I don't think we
>   should *have* a VIEW FETCH, VIEW STORE, or VIEW COPY command, and that we
>   should clearly state that UIDs are the things to use when you're using
>   views.

You need some way to express hierarchy in a VIEW (for threading), which is why
neither sequence numbers nor UIDs are good enough.  If you use either a
sequence number or UID (I don't think that one should be preferred over the
other, beyond what technical considerations indicate), then you have to
maintain the map or some portion of it.

The whole point for VIEW FETCH and friends is so you don't need to have the
map at all.

Date: Wed, 30 Jun 1999 03:28:32 +0400
From: Alexey Melnikov <[email-masked]>
To: Barry Leiba <[email-masked]>
CC: Cyrus Daboo <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt
Sender: [email-masked]

Barry Leiba wrote:

> First comment:  Can we take the IMAP mailing list out of the list on
> this discussion, and just hold it on the IMAPext mailing list?  It seems
> silly to post the same discussion to both lists -- why do we have the
> IMAPext list at all, if we're going to do that?
>
> Other comments:
> * Section 4.1 refers to an "optional" sub-command, and (a) says that
>   the  VIEW SET command selects messages that "match the results of the
>   sub-command".  It doesn't make it clear what happens if there's no
>   sub-command (all messages are selected, I presume).

Draft says that VIEW SET with out optional argument cancels VIEW state (section 4.1
point g)).

> * In 4.2 you should make it clear what, if anything, it means to use a
>   VIEW command without a VIEW SET being in effect.  It seems to me that
>   it's nonsensical (so should "VIEW FETCH" respond "NO" or "BAD" in that
>   case?).

Actually, I don't mind if VIEW returns OK, as if
"VIEW SET SEARCH ALL" has been issued.

> * In 4.2, you say
>     command response.  However, server implementations MUST implicitly
>     include the VIEW fetch item as part of any FETCH response caused by
>     a VIEW command, regardless of whether a VIEW was specified as a
>     message data item to the FETCH.
>
>   ...but you've already said that a VIEW fetch item must be included if
>   a VIEW SET is in effect.  If I'm right in my previous note, then you
>   probably shouldn't *also* say this.

IMHO, it is not a big trouble to say something twice, especially in this case.

> * Finally, just to clarify things... we'd had an extended discussion about
>   whether it was reasonable to remove a message from a view, once it was
>   in the view.  Problems of side-effects and such -- for instance, what
>   happens in the following case (abbreviating a little):
>   [skipped]

>   But I would like to see some of these potential problems mentioned in the
>   spec.  I would also like to see some encouragement to use UIDs instead of
>   view positions.  In fact, I'd go as far as to say that I don't think we
>   should *have* a VIEW FETCH, VIEW STORE, or VIEW COPY command, and that we
>   should clearly state that UIDs are the things to use when you're using views.

I am tend to support the idea.

--
Best Regards,
Alexey Melnikov

Date: Wed, 30 Jun 1999 03:18:52 +0400
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: [email-masked]
Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt
Sender: [email-masked]

Cyrus Daboo wrote:

> Hi folks,
> A new internet draft is available at:
>
> <http://www.ietf.org/internet-drafts/draft-daboo-imap-view-00.txt>
>
> [skipped]
>
> Note that this document proposes a mechanism different from that discussed
> by various groups at recent IETF and IMC interop meetings. I can post a
> list of reasons why we feel this approach is better if there is interest.

I understand most of them (I didn't like the idea to overload SELECT from the
beginning), but I would like to know them all.

Few comments in addition to what Barry wrote:

1). I am concerned about amount of responses sent when message moves into or
outside of the view.
I would rather add something like the following:

Server MUST NOT send extended EXISTS response when message moves into or
outside of the view,
but there is no changes to the total number of messages in the mailbox.

This is not clear from the current version of the draft.

2). According to the draft a server MUST send untagged VIEW for every new
message that arrives in the mailbox.
Again, there is no reason why server should send EXISTS ***after*** VIEW
response, because untagged VIEW
already contains all information about new message. (EXISTS still MUST be sent
right after VIEW SET)

--
Best Regards,
Alexey Melnikov

Date: Tue, 29 Jun 1999 15:21:52 -0400
From: Barry Leiba <[email-masked]>
Organization: Internet Messaging Technology; TR2_Xagent=WATSON
To: Cyrus Daboo <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt
Sender: [email-masked]

First comment:  Can we take the IMAP mailing list out of the list on
this discussion, and just hold it on the IMAPext mailing list?  It seems
silly to post the same discussion to both lists -- why do we have the
IMAPext list at all, if we're going to do that?

Other comments:
* Section 4.1 refers to an "optional" sub-command, and (a) says that 
  the  VIEW SET command selects messages that "match the results of the
  sub-command".  It doesn't make it clear what happens if there's no
  sub-command (all messages are selected, I presume).  It also doesn't
  say much about the sub-command; if "SEARCH" is the only command in
  the base spec that applies, it should probably say so, to prevent
  people from wondering what commands apply.  It might also say (which
  is also said elsewhere) that it's intended that future SORT and 
  THREAD commands may go here.

* In 4.1 (b), "c.f." is properly abbreviated "cf.", and, anyway, is the
  wrong Latin abbreviation here.  "cf." means "compare" (from the Latin
  "confer"), and I don't think you want anyone to compare what you say
  here to what's said in 4.2.  If you mean "see section 4.2", just say it.
  (Sorry... pet peeve about misuse of Latin abbreviations.)

* In the example in 4.1 (g), correct spelling of "SEARCH".

* In 4.2 you should make it clear what, if anything, it means to use a
  VIEW command without a VIEW SET being in effect.  It seems to me that
  it's nonsensical (so should "VIEW FETCH" respond "NO" or "BAD" in that
  case?).

* In 4.2, you say
    command response.  However, server implementations MUST implicitly
    include the VIEW fetch item as part of any FETCH response caused by
    a VIEW command, regardless of whether a VIEW was specified as a
    message data item to the FETCH.

  ...but you've already said that a VIEW fetch item must be included if
  a VIEW SET is in effect.  If I'm right in my previous note, then you
  probably shouldn't *also* say this.

* In 5.1.1:
    A VIEW untagged response MUST NOT be sent when no command is in
    progress; nor while responding to a FETCH, SEARCH or STORE command.

  Understandable.  But that means that a client that receives an EXISTS
  in response to a FETCH must then go issue a NOOP to get the corresponding 
  VIEW response.  Can we think of a better way?

  Also, it might not hurt to point out that IDLE can count as a command
  in progress.  But, then, maybe that's too obvious to have to mention.

* In 5.1.2:
    When the old view position number in the VIEW untagged response is
    non-zero, the effect of VIEW is a message inserted into the view at
    the position given by <new>.  The view position numbers of all
    subsequent messages inthge current view are incremented.

    When the new view position number in the VIEW untagged response is
    non-zero, the effect of VIEW is a message removed from the view at
    the position given by <old>.  The view position numbers of all
    subsequent messages inthe current view are decremented.

  In both of these, I think you mean "zero" where you say "non-zero".
  Also, fix "inthge" and "inthe".
  Also also, since you explicitly talk about incrementing and decrementing
  view position numbers, perhaps you should include a paragraph about what
  happens if both the old and new positions are non-zero... which also
  require renumbering other messages.  No, *I* don't think it needs to be
  said, but, then, I'm always surprised at the interpretations that sometimes
  happen when one fails to say something.  :-)

* In the grammar:
    position         ::= number ["." number]
                         ;; position number of messages in the view
                         ;; may be hierarchical if sub-command defines
                         ;; hierarchic ordering of messages

  This makes some of the statements about "incrementing" and "decrementing"
  view positions harder to understand.  Maybe all we should say about what
  happens after a VIEW response is that "view positions of subsequent [or
  intervening] messages must be adjusted appropriately" or some such.

* Finally, just to clarify things... we'd had an extended discussion about
  whether it was reasonable to remove a message from a view, once it was
  in the view.  Problems of side-effects and such -- for instance, what 
  happens in the following case (abbreviating a little):
    c: t0 VIEW SET SEARCH UNSEEN
    s: * 25 VIEW 1234 0 4
    c: t1 VIEW FETCH 4 BODY[1]
    s: * 25 FETCH (FLAGS (\Seen) VIEW 4 BODY[1] ...
    s: t1 OK done
    c: t2 NOOP
    s: * 25 VIEW 1234 4 0    [\Seen flag caused view to change]
    s: t2 OK done

  Now, as a side-effect of the FETCH, the client can no longer use VIEW FETCH
  on this message.  Other cases are easy to imagine.  It makes VIEW FETCH of
  questionable use.

  Clearly, the decision made in writing this draft was to have messages 
  disappear from the view (during earlier discussions, some thought they 
  should not, though it came out that that makes reconnecting after connection 
  failures difficult).

  I just wanted to point out, for the record, that there were two sides to
  that discussion, and to point out, for the record, which one was adopted.
  (And, for the record, I agree with the choice.)

  But I would like to see some of these potential problems mentioned in the 
  spec.  I would also like to see some encouragement to use UIDs instead of
  view positions.  In fact, I'd go as far as to say that I don't think we
  should *have* a VIEW FETCH, VIEW STORE, or VIEW COPY command, and that we
  should clearly state that UIDs are the things to use when you're using views.

Barry Leiba, Internet Messaging Technology  ([email-masked])
http://www.research.ibm.com/people/l/leiba

From: "Rubinstein, Dmitry" <[email-masked]>
To: [email-masked]
Subject: RE: Client ID extension
Date: Tue, 29 Jun 1999 12:41:52 +0300
Sender: [email-masked]

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

------_=_NextPart_000_01BEC213.9E2A9490
Content-Type: text/plain;
	charset="iso-8859-1"

> From: Mike Gahrns [mailto:[email-masked]]
> Given that there seems to be 
> reasonable
> number of people who concur that this type of functionality 
> would be useful,
> moving the extension forward should hopefully be rather 
> straight foward with
> only minor changes needed.  

OK then, what are the needed changes? Below is the original draft for your
reference. 

--
Dmitry Rubinstein 

------_=_NextPart_000_01BEC213.9E2A9490
Content-Type: text/plain;
	name="draft-tjs-id-01.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="draft-tjs-id-01.txt"

Network Working Group                                       T. =
Showalter
Not An Internet Draft                                    Carnegie =
Mellon
Document: untitled                                         February =
1997
Expire sometime after it's released

                           IMAP4 ID extension

Status of this Memo

    This document does not exist.

1.   Abstract

    The purpose of the ID extension to the IMAP4rev1 protocol is to
    allow the server and client to exchange identification information
    on their implementation in order to make bug reports and usage
    statistics more complete.

    Although the IMAP4rev1 protocol described in [IMAP4rev1] provides a
    method for accessing remote mail stores, there is no facility to
    advertise what program a client or server uses to provide service.
    This makes it difficult for implementors to get complete bug =
reports
    from users, as it is frequently difficult to know what client or
    server is in use.

    Additionally, some sites may wish to assemble usage statistics =
based
    on what clients are used, but in an an environment where users are
    permitted to obtain and maintain their own clients this is =
difficult
    to accomplish.

    The ID command provides a facility to advertise information on what
    programs are being used, along with contact information should bugs
    ever occur.

2.   Conventions Used in this Document

    The conventions used in this document are the same as specified in
    [IMAP4rev1]. In examples, "C:" and "S:" indicate lines sent by the
    client and server respectively.  Line breaks have been inserted for
    readability.

3.   Specification

    The ID extension is provided in order for clients and servers to
    exchange information on their implementations.

    This information may be submitted to a server by any client wishing
    to provide information for statistical purposes, provided the =
server
    advertises its willingness to take the information with the atom
    "ID" included in the list of capabilities returned by the =
CAPABILITY
    command.

    Implementations MUST NOT make operational changes based on the data
    sent as part of the ID command or response.

3.1.   ID Command

    Arguments:  client parameter list or NIL

    Responses:  OPTIONAL untagged response: ID

    Result:     OK    identification information accepted
                BAD   command unknown or arguments invalid

    Identification information is sent by the client with the ID
    command.  The information sent is in the form of a list of
    field/value pairs.  Fields are permitted to be any IMAP4 string, =
and
    values are permitted to be any IMAP4 string or NIL.  A value of NIL
    indicates that the client can not or will not specify this
    information.  The client may also send NIL instead of the list,
    indicating that it wants to send no information, but would still
    accept a server response.

    The avalible fields are defined in section 3.3.

    Example:
    C: a023 ID ("name" "sodr" "version" "19.34" "vendor" "Pink Floyd
        Music Limited")
    S: a023 OK ID completed

3.2.   ID Response

    Contents:	server parameter list

    In response to an ID command issued by the client, the server MAY
    reply with a tagged response containing information on its
    implementation.  The format is the same as the client list.

    Example:
    C: a023 ID NIL
    S: * ID ("name" "Cyrus" "version" "1.5" "os" "sunos" "os-version" =
"5.5"
        "email" "[email-masked]")
    S: a023 OK ID command completed

    The server is not required to send an ID response to an ID command.

3.3.   Defined Field Values

    Any string may be sent as a field, but the following are defined to
    describe certain values that might be sent.  Implementations are
    free to send none, any, or all of these.  Strings are not
    case-sensitive.

    name                     Name of the program
    version                  Version number of the program
    os                       Name of the operating system
    os-version               Version of the operating system
    vendor                   Vendor of the client/server
    contact                  Contact person for the client/server
    email                    Email address of contact/vendor
    phone                    Phone number of contact/vendor
    address                  Postal address of contact/vendor
    date                     Date program was released;
                               should be in a human-readable form
    command                  Command used to start the program
    arguments                Arguments supplied on the command line (if
                               any)
    environment              Description of environment (i.e., UNIX
                               environment variables or Windows =
registry
                               settings.

    Implementations MUST NOT use contact information to submit =
automatic
    bug reports.  Information supplied with the ID command is not
    necessarily complete or accurate.  Implementations may include
    such information in a report submitted.

    It is preferrable to find the name and version of the underlying
    operating system at runtime in cases where this is possible.

    Some of this information (specifically, the command, arguments, and
    environment fields) is likely to violate users' privacy.  See the
    section on security considerations below.

    Implementations may send the same tag more than once; for example,
    C: a001 ID ("client-name" NIL "client-name" "spooky" "client-name"
        NIL)
    S: a001 OK ID completed

4.   Formal Syntax

    This syntax is intended to augment the grammar specified in =
[IMAP4rev1]
    in order to provide for the ID command.  This specification uses =
the
    augmented Backus-Naur Form (BNF) notation as specified in [RFC-822]
    and modified by [IMAP4rev1].

    command_any ::=3D "CAPABILITY / "LOGOUT" / "NOOP" / x_command / id
	;; adds id command to command_any in [IMAP4rev1]

    id ::=3D "ID" SPACE id_params_list / nil

    id_response ::=3D "ID" SPACE id_params_list / nil

    id_params_list ::=3D "(" #(string SPACE nstring) ")" / nil
	;; list of field value pairs

    response_data ::=3D "*" (resp_cond_state / resp_cond_bye /
        mailbox_data / message_data / capability_data / id_response)

5.   References

    [IMAP4rev1] Crispin, M., "Internet Message Access Protocol - =
Version
        4rev1", RFC 2060, University of Washington, October, 1996.

    [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet
        Text Messages", STD 11, RFC 822.

6.   Security Considerations

    A client or server supporting ID may violate the privacy of users =
by
    sending information on the underlying implementation, or in some
    cases, information on how the mail client was invoked.  For this
    reason, it is highly desirable that client implementations provide =
a
    method of disabling ID support -- by either not sending ID at all,
    or by sending the command "ID NIL", or by controlling the level of
    detail of information sent.  A server may reply similarly in its
    untagged response ("* ID NIL"), or it may send no untagged =
response.

7.   Author's Address

    Tim Showalter
    Carnegie Mellon University
    5000 Forbes Avenue
    Pittsburgh, PA 15213

    Email: [email-masked]

------_=_NextPart_000_01BEC213.9E2A9490--

Date: Mon, 28 Jun 1999 18:40:54 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt
To: steve spear <[email-masked]>
cc: [email-masked], [email-masked]
Sender: [email-masked]

On Tue, 29 Jun 1999 00:38:15 +0000, steve spear wrote:
> Can someone explain how traffic is reduced by SORT over clients that are
> caching the headers and simply request messages headers they haven't seen
> before?

Most such clients are POP clients masquerading as IMAP clients.  Consider true
IMAP clients, which don't have a cache (and may well be a kiosk or other
shared machine which shouldn't cache!), and don't want to load all those
headers.

Date: Tue, 29 Jun 1999 00:38:15 +0000
From: steve spear <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt
Sender: [email-masked]

Can someone explain how traffic is reduced by SORT over clients that are
caching the headers and simply request messages headers they haven't seen
before?   As Tony Hansen pointed out - AT&T is trying to handle many millions
of users.  The thought of using more resources on the server instead of the
clients that are largely idle is a concern of ours.  We keep hearing about
thin-client's, but the memory available in the thin clients still boggles the
mind of those who had memory measured in Kilobytes ( not Megabytes ) 25+ years
ago.  If it makes sense we'll cheer for it,  but we'd like to understand where
the advantage is.

Steve Spear
AT&T Technology Consultant

Cyrus Daboo wrote:

> --On Mon, Jun 28, 1999 5:52 PM -0400 Tony Hansen <[email-masked]> wrote:
>
> > Our major problem with this proposal is not an issue with the extension
> > itself. Instead, we have an issue with its impact on server performance
> > when dealing with LARGE user populations (hundreds of thousands or
> > millions). Each proposal such as this does increase the server load.
>
> Actually the hope for this proposal (wrt to sorting) is to REDUCE the
> overall server load by removing the need for a client to download the
> envelopes of all messages in order to sort them for the end-user. It should
> also reduce client load and indeed allow thin-clients to present sorted or
> sub-set views without having to do much work.
>
> --
> Cyrus

Date: Mon, 28 Jun 1999 20:28:06 -0400
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
cc: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt
Originator-Info: login-id=daboo; server=imap.cyrusoft.com:431
Sender: [email-masked]

--On Mon, Jun 28, 1999 5:52 PM -0400 Tony Hansen <[email-masked]> wrote:

> Our major problem with this proposal is not an issue with the extension
> itself. Instead, we have an issue with its impact on server performance
> when dealing with LARGE user populations (hundreds of thousands or
> millions). Each proposal such as this does increase the server load.

Actually the hope for this proposal (wrt to sorting) is to REDUCE the
overall server load by removing the need for a client to download the
envelopes of all messages in order to sort them for the end-user. It should
also reduce client load and indeed allow thin-clients to present sorted or
sub-set views without having to do much work.

--
Cyrus

From: "Mike Gahrns" <[email-masked]>
To: <[email-masked]>
Subject: Re: Client ID extension
Date: Mon, 28 Jun 1999 15:58:23 -0700
Sender: [email-masked]

Cyrus Daboo writes:
> I think the client ID extension should be straightforward enough that it
> can be moved forward via the mailing list rather than needing to be added
> to the future WG. All it really needs is for someone to update the
document
> and to start the formal review process over again. Perhaps Tim (original
> author) could be persuaded to do this?
This echos a previous comment I had regarding the charter of the WG.  I'd
prefer that the WG concentrate on the "larger" issues already proposed:
SORT, ANNOTATE and ACL.

Smaller extensions will probably be better served taking them outside of the
WG.

In regards to ID, I think the original proposal was pretty much there.  The
dissention seemed to resolve around whether the premise of allowing this
functionality was good or bad.  Given that there seems to be reasonable
number of people who concur that this type of functionality would be useful,
moving the extension forward should hopefully be rather straight foward with
only minor changes needed.  I am not sure what Tim's thoughts are on moving
this forward, but I would be willing to help with this if he is unable to.

Date: Mon, 28 Jun 1999 15:05:38 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt
To: [email-masked]
cc: Cyrus Daboo <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

On Mon, 28 Jun 1999 17:52:36 -0400, Tony Hansen wrote:
> Our major problem with this proposal is not an issue with the extension
> itself. Instead, we have an issue with its impact on server performance
> when dealing with LARGE user populations (hundreds of thousands or
> millions). Each proposal such as this does increase the server load.

There's a tradeoff in all of these things.  Some people consider the
functionality of VIEW to be very important, and have blocked SORT and THREAD
unless this functionality is provided.  One of their concerns is that the SORT
command uses communication bandwidth; for example, sorting a 2000 message
mailbox results in a response that is 8900 octets long.

SORT and THREAD are very important for UW since these extensions make a *HUGE*
difference in Pine performance.  So, it's important for us to get these
concerns addressed, and preferably in an extensible mechanism.

Date: Mon, 28 Jun 1999 17:52:36 -0400
From: Tony Hansen <[email-masked]>
Reply-To: [email-masked]
Organization: AT&T Laboratories
To: Cyrus Daboo <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt
Sender: [email-masked]

Cyrus Daboo wrote:
> 
> A new internet draft is available at:
> <http://www.ietf.org/internet-drafts/draft-daboo-imap-view-00.txt>
> 
> This is the first cut at moving towards a standardised sorting mechanism
> for IMAP. The extension proposed in this draft is actually a more general
> extension that is used to allow a client to operate on a sub-set of
> messages (as determined right now by an IMAP SEARCH command) as opposed to
> the entire set of messages in the mailbox.
> 
> Basically this extension introduces a couple of new commands, together with
> some new responses, including a new FETCH item called 'VIEW' which is the
> message's position in the 'sub-set' or 'view'. Clients can then access
> messages by their view position using a new VIEW command that takes FETCH
> (and other commands) as arguments (inthe same way as the UID command
> already present in IMAP4).
> ...

Our major problem with this proposal is not an issue with the extension
itself. Instead, we have an issue with its impact on server performance
when dealing with LARGE user populations (hundreds of thousands or
millions). Each proposal such as this does increase the server load.

	Tony Hansen
	[email-masked]

Date: Mon, 28 Jun 1999 12:45:31 -0700
From: Mike Macgirvin <[email-masked]>
Organization: The Rebel Alliance
To: Mark Crispin <[email-masked]>
CC: Cyrus Daboo <[email-masked]>, [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt
Sender: [email-masked]

Mark Crispin wrote:
> 
> My only comment about multiple simultaneous views is that this makes VIEW much
> more complicated to implement; and as such presents a barrier to prospective
> implementors.  It may also contribute to the ongoing myth that IMAP is an
> expensive service to have on a machine.
> 
> Nevertheless, this is just an observation and I don't oppose your proposal.
> Please bring it up at Oslo.

I agree totally that it makes server implementation of this feature
non-trivial. Without it I think the client ends up having to work just as
hard by issuing multiple SEARCH and/or VIEW commands everytime anything in
the mailbox changes - or doing all the work client-side. We can do that
today without requiring any extensions, but it's hardly efficient. So this
draft presents a way to avoid a lot of client overhead as long as you only
define or "activate" only one view. Having worked a lot with views in the
past, one is not very typical. The bell curve fits around 5 and 20 at least
on INBOX and it's reasonable for a human to want to have all their views
active in the sense that message counts are propogated in as near to real
time as possible. 

I'll see if somebody else from here will be at Oslo and ask that they
present these arguments - unfortunately, I have other obligations.

Date: Mon, 28 Jun 1999 14:53:00 -0400
From: Cyrus Daboo <[email-masked]>
To: "Rubinstein, Dmitry" <[email-masked]>, [email-masked]
Subject: Re: Client ID extension
Originator-Info: login-id=daboo; server=imap.cyrusoft.com
Sender: [email-masked]

--On Monday, June 28, 1999, 9:03 PM +0300 "Rubinstein, Dmitry"
<[email-masked]> wrote:

> Hi, everybody!
> 
> There has been a long discussion regarding the need for <subj> on the
> [email-masked] mailing list (whose subscribers, if I'm not terribly
> misaken, are a superset of the current list's subscribers). The majority
> of speakers eventually supported the idea of adding Client ID extension
> and at least 3-4 developers expressed their willingness to add support to
> ClientID to their products. There is a draft that is about year old that
> describes the proposed extension. There was a talk of adding this
> extension to the charter of this WG. What does it take at this point to
> make it into a standard?
> 

Well there is no formal charter for this group as yet. That ought to be the
first item on the agenda for Oslo!

I think the client ID extension should be straightforward enough that it
can be moved forward via the mailing list rather than needing to be added
to the future WG. All it really needs is for someone to update the document
and to start the formal review process over again. Perhaps Tim (original
author) could be persuaded to do this?

--Cyrus

Date: Mon, 28 Jun 1999 14:38:06 -0400
From: Cyrus Daboo <[email-masked]>
To: Mike Macgirvin <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt
Originator-Info: login-id=daboo; server=imap.cyrusoft.com
Sender: [email-masked]

Hi Mike,

--On Monday, June 28, 1999, 10:56 AM -0700 Mike Macgirvin
<[email-masked]> wrote:

> This appears to have the side effect of limiting you to one view. Multiple
> active views would require extensive client polling, and the notification
> events would only be active on one of them. 
> 
> I'd like to propose a modest enhancement, where the client can provide a
> (client generated) view-id, and subsequent changes to that view are tagged
> with the view-id. This permits multiple active views. Granted, there is
> server overhead involved, but this is the price of moving it off the
> client in the first place. Having the client generate an ID is better
> than having to match an untagged response with a search string. 

Multiple views would be nice. I thought of doing something similar too.
However, I concluded that the added complexity of handling multiple views
is too much for now. It requires a lot more than just modifying EXISTS.

One major problem is that messages can be in more than one view. One way to
handle this would be to redefine the 'position' syntax to be a list of
'view number'/'view position' pairs. For example, an EXPUNGE for a message
in view #0001 and view #0003 would end up as:

a EXPUNGE
* 1 EXPUNGE 1234 ((0001 1)(0003 4))
a OK

My personal feeling is to keep VIEW simple for now and see how
implementation experience goes. There's no reason why later we can't define
a new command to deal with multiple named views and redefine the existing
VIEW syntax appropriately. e.g. 'VIEW SET' would be augmented by a 'VIEW
NAMEDSET' command that could redfine the 'position' formal syntax item to
be an S-Expression list (or whatever), and require a view name in addition
to the sub-command in a VIEW command.

--Cyrus

Date: Mon, 28 Jun 1999 11:14:00 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt
To: Mike Macgirvin <[email-masked]>
cc: Cyrus Daboo <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

My only comment about multiple simultaneous views is that this makes VIEW much
more complicated to implement; and as such presents a barrier to prospective
implementors.  It may also contribute to the ongoing myth that IMAP is an
expensive service to have on a machine.

Nevertheless, this is just an observation and I don't oppose your proposal.
Please bring it up at Oslo.

From: "Rubinstein, Dmitry" <[email-masked]>
To: [email-masked]
Subject: Client ID extension
Date: Mon, 28 Jun 1999 21:03:28 +0300
Sender: [email-masked]

Hi, everybody!

There has been a long discussion regarding the need for <subj> on the
[email-masked] mailing list (whose subscribers, if I'm not terribly
misaken, are a superset of the current list's subscribers). The majority of
speakers eventually supported the idea of adding Client ID extension and at
least 3-4 developers expressed their willingness to add support to ClientID
to their products. There is a draft that is about year old that describes
the proposed extension. There was a talk of adding this extension to the
charter of this WG. What does it take at this point to make it into a
standard?

TIA,

--
Dmitry Rubinstein 

Date: Mon, 28 Jun 1999 11:02:57 -0700
From: Mike Macgirvin <[email-masked]>
Organization: The Rebel Alliance
To: Cyrus Daboo <[email-masked]>, [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt
Sender: [email-masked]

Before somebody corrects me - yes I do know that EXISTS are untagged and
require *.

> It probably isn't necessary that the results be chained in the EXISTS
> response, i.e. 

>        S: * 172 EXISTS 0001 23
>        S: * 172 EXISTS 0002 6
............^

> would be just fine.

Date: Mon, 28 Jun 1999 10:56:26 -0700
From: Mike Macgirvin <[email-masked]>
Organization: The Rebel Alliance
To: Cyrus Daboo <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt
Sender: [email-masked]

This appears to have the side effect of limiting you to one view. Multiple
active views would require extensive client polling, and the notification
events would only be active on one of them. 

I'd like to propose a modest enhancement, where the client can provide a
(client generated) view-id, and subsequent changes to that view are tagged
with the view-id. This permits multiple active views. Granted, there is
server overhead involved, but this is the price of moving it off the client
in the first place. Having the client generate an ID is better than having
to match an untagged response with a search string. 

        C: A143 VIEW SET 0001 SEARCH FROM "Smith"
        S: * 172 EXISTS 0001 23
        S: A143 OK VIEW SET completed
	C: A144 VIEW SET 0002 SEARCH FROM "Myboss"
	S: * 172 EXISTS 0001 23 0002 6
	S: A144 OK VIEW SET completed

It probably isn't necessary that the results be chained in the EXISTS
response, i.e. 

	S: 172 EXISTS 0001 23
	S: 172 EXISTS 0002 6

would be just fine. 

This would alter other responses appropriately. This way mailbox events can
trigger updates of any active views.
Thinking one step further, something to shut down an active view would
likely be desirable in this model. 

	C: A145 VIEW REMOVE 0001
	S: A145 OK VIEW 0001 FROM "Smith" removed

If I'm missing something obvious and all this isn't necessary, please
correct me.

Date: Mon, 28 Jun 1999 13:16:45 -0400
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: I-D ACTION:draft-daboo-imap-view-00.txt
Originator-Info: login-id=daboo; server=imap.cyrusoft.com
Sender: [email-masked]

Hi folks,
A new internet draft is available at:

<http://www.ietf.org/internet-drafts/draft-daboo-imap-view-00.txt>

This is the first cut at moving towards a standardised sorting mechanism
for IMAP. The extension proposed in this draft is actually a more general
extension that is used to allow a client to operate on a sub-set of
messages (as determined right now by an IMAP SEARCH command) as opposed to
the entire set of messages in the mailbox.

Basically this extension introduces a couple of new commands, together with
some new responses, including a new FETCH item called 'VIEW' which is the
message's position in the 'sub-set' or 'view'. Clients can then access
messages by their view position using a new VIEW command that takes FETCH
(and other commands) as arguments (inthe same way as the UID command
already present in IMAP4).

It is proposed that a future SORT extension will be used with the VIEW
mechanism to allow sub-setting of sort results and to allow clients to
access the messages in sorted order as opposed to sequence number order.
Thus this draft represents the first step towards the goal of a sort
command acceptable to all - hopefully!

BTW that the VIEW mechanism can be used with other types of sub-setting we
might want to think about in the future (e.g. message threading based on
message-id/in-reply-to etc).

Note that this document proposes a mechanism different from that discussed
by various groups at recent IETF and IMC interop meetings. I can post a
list of reasons why we feel this approach is better if there is interest.

--Cyrus Daboo

Date: Wed, 23 Jun 1999 17:45:33 -0500
To: IMAP Extensions <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Fwd: 45th IETF: IMAPEXT
Sender: [email-masked]

--- begin forwarded text

Date: Wed, 23 Jun 1999 18:36:24 -0400
To: Pete Resnick <[email-masked]>
From: Marcia Beaulieu <[email-masked]>
Subject: 45th IETF: IMAPEXT
Cc: Keith Moore <[email-masked]>,
         Pätrik
   Faltström <[email-masked]>

IMAPEXT is scheduled as follows:

	Thursday, July 15 at 1300-1500
		other groups scheduled at that time: roamops, issll, 
ldapext, saag,
			mobileip, iptel

Please submit an agenda for this meeting as soon as possible to
[email-masked]
The deadline for submitting an agenda is July 1 at 1200 ET.

Thanks,

Marcia

--- end forwarded text

-- 
Pete Resnick <mailto:[email-masked]>
Eudora Engineering - QUALCOMM Incorporated
Ph: (217)337-6377 or (619)651-4478, Fax: (619)651-1102

From: "Glenn Parsons" <[email-masked]>
To: "'Dmitry Rubinstein'" <[email-masked]>
Cc: [email-masked], "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Oslo IETF meeting
Date: Tue, 22 Jun 1999 11:47:50 -0500
Sender: [email-masked]

Dmitry,

> I'd like to know what will be the agenda of the WG(s), that will
> deal with IMAP issues. In particular I'd like to know whether
> the following two drafts are going to be discussed:
> 
> 2. draft-ema-vpim-imap-00 (VPIM over IMAP)
> 
I hope to have a slightly updated version of this available soon based on
the various comments to date.  The goal of this draft is to list the
possible options to solve various requirements we have noted for retrieving
voice messages over IMAP.

> I'd appreciate it if whoever is preparing the agenda (assuming
> such preparations are being done) will tip us on the major
> points that are to be discussed. The agendas are only due within
> two weeks and will probably be written on the last night, but
> still...
> 
At previous meetings, the view was that this was sufficiently different that
we should create another list (IMAP-Voice) and have it discussed in a
different IETF session.  

I'd be happy to discuss it in IMAPEXT if folks wanted to talk about this and
revisit if it should be in the charter.

We will likely mention this draft in passing in the VPIM meeting -- though
we won't have time to look at any details.

Cheers,
Glenn.

Date: Wed, 02 Jun 1999 18:00:09 -0400
From: Cyrus Daboo <[email-masked]>
To: "Mike Gahrns (Platinum)" <[email-masked]>, [email-masked], [email-masked]
Subject: RE: Proposed WG worklist from March IMC
Originator-Info: login-id=daboo; server=imap.cyrusoft.com:431
Sender: [email-masked]

--On Wednesday, June 02, 1999, 2:38 PM -0700 "Mike Gahrns (Platinum)"
<[email-masked]> wrote:

> I believe the original proposed charter for the IMAPEXT WG was to cover
> SORT, Annotate and ACLs.  I did not put together that list, but it
> sounds look a good list to me.  

The last charter we had was the one posted to the list by John Myers (I've
quoted it below - obviously the target dates are wrong). This needs to be
taken over by the WG chair (Pete?) and processed through the usual IETF
channels, after discussion/approval on this list.

> From: John Gardiner Myers <[email-masked]>
> To: [email-masked]
> Subject: Proposed charter
> Date-Sent: 08/06/98, 3:17 PM -0700
> 
> To remind people, the proposed charter is as follows:
> 
> Chair(s):
> 
> TBD
> 
> Mailing Lists:
> 
> General discussion: [email-masked]
> To Subscribe: [email-masked]
> Archive: http://www.imc.org/ietf-imapext/
> 
> 
> Description of Working Group:
> 
> The IETF IMAP extensions Working Group shall revise and publish
> standards-track extensions to IMAP4 for performing the following
> functions:
> 
> 1) Access Control Lists
> 2) Sorting
> 3) Threading
> 4) Message-level annotations
> 
> Revising the base IMAP4rev1 specification is out of the scope of this
> WG.
> 
> 
> Goals and Milestones:
> 
> August 98       Approve charter
> 
> Dec 98          Submit revised ACL spec to IESG
> 
> Mar 99          Submit revised Sorting/Threading spec(s) to IESG
> 
> August 99       Submit annotation spec to IESG

--On Friday, April 10, 1998, 1:48 PM -0700 John Gardiner Myers
<[email-masked]> wrote:

> I'll propose the following addition to the charter:
> 
>	 Revising the base IMAP4rev1 spec is out of the scope of this WG.

--
Cyrus

From: "Mike Gahrns (Platinum)" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: RE: Proposed WG worklist from March IMC
Date: Wed, 2 Jun 1999 14:38:03 -0700
content-class: urn:content-classes:message/mail
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_2009A_01BEAD05.8609BF20
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

I believe the original proposed charter for the IMAPEXT WG was to cover
SORT, Annotate and ACLs.  I did not put together that list, but it
sounds look a good list to me.  

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: Wednesday, June 02, 1999 2:27 PM
To: [email-masked]
Subject: Proposed WG worklist from March IMC

I recall someone at the March IMAP interop putting together a list of
candidate items for the WG. I thought it was Mike G., but he claims
no knowledge of this. Would the guilty party please step forward with
that list?

------=_NextPart_000_2009A_01BEAD05.8609BF20
Content-Type: application/ms-tnef;
	name="winmail.dat"
Content-Transfer-Encoding: base64

------=_NextPart_000_2009A_01BEAD05.8609BF20--

Date: Wed, 2 Jun 1999 15:27:21 -0600
From: [email-masked]
Subject: Proposed WG worklist from March IMC
To: [email-masked]
Sender: [email-masked]

I recall someone at the March IMAP interop putting together a list of
candidate items for the WG. I thought it was Mike G., but he claims
no knowledge of this. Would the guilty party please step forward with
that list?

From: "Mike Gahrns (Platinum)" <[email-masked]>
To: "Cyrus Daboo" <[email-masked]>, "Pete Resnick" <[email-masked]>, <[email-masked]>
Subject: RE: IMAPEXT at Oslo?
Date: Wed, 2 Jun 1999 11:22:21 -0700
content-class: urn:content-classes:message/mail
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_1EE12_01BEACEA.2F828440
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

I agree whole heartily with Cyrus here.

There have been several informal discussions off the list in regards to
SORT.  As  Cyrus mentions, there are a couple of proposals that are
close to being issued as drafts.  A face to face meeting in Oslo will
prove extremely beneficial, as in the early stages of many proposals, a
lot more can be accomplished quicker through face to face discussions
rather than lengthy email exchanges.

At the last IMC interop event in San Jose a few months ago, I think the
general consensus of the room was that there should be an IMAPEXT WG at
the next meeting.

Although not entirely related to the orginal proposed charter of the WG,
there was a lot of discussion a few months back on the regular IMAP list
regarding LIST Extensions/Childmailbox, etc..  If there is an IMAPEXT
WG, a lot of the right people will likely be at OSLO to further discuss
this.

-----Original Message-----
From: Cyrus Daboo [mailto:[email-masked]]
Sent: Wednesday, June 02, 1999 10:22 AM
To: Pete Resnick; [email-masked]
Subject: Re: IMAPEXT at Oslo?

--On Wednesday, June 02, 1999, 10:11 AM -0700 Pete Resnick
<[email-masked]> wrote:

> There hasn't been a whole lot of action here to charter a WG or have 
> discussions. Do we want to BOF at Oslo for the purpose of chartering 
> a WG? What's the state of affairs? Deadlines are looming.

I think we should have a meeting. Ideally we should get the WG setup and
running before then so we can do 'real work' in Oslo, though a BOF would
be
just as good. What's currently holding up chartering of this group? I
thought we had a charter bashed out ready to go? Can we make sure a
request
goes in to the ADs for a meeting in Oslo (be it WG or BOF)?

I have a sort draft that is being reviewed by co-authors right now, and
hopefully we can get this out to the list soon. There will be some
serious
debate about this and a face-to-face in Oslo would proove extermely
beneficial IMHO.

--
Cyrus

------=_NextPart_000_1EE12_01BEACEA.2F828440
Content-Type: application/ms-tnef;
	name="winmail.dat"
Content-Transfer-Encoding: base64

------=_NextPart_000_1EE12_01BEACEA.2F828440--

Date: Wed, 02 Jun 1999 13:22:22 -0400
From: Cyrus Daboo <[email-masked]>
To: Pete Resnick <[email-masked]>, [email-masked]
Subject: Re: IMAPEXT at Oslo?
Originator-Info: login-id=daboo; server=imap.cyrusoft.com:431
Sender: [email-masked]

--On Wednesday, June 02, 1999, 10:11 AM -0700 Pete Resnick
<[email-masked]> wrote:

> There hasn't been a whole lot of action here to charter a WG or have 
> discussions. Do we want to BOF at Oslo for the purpose of chartering 
> a WG? What's the state of affairs? Deadlines are looming.

I think we should have a meeting. Ideally we should get the WG setup and
running before then so we can do 'real work' in Oslo, though a BOF would be
just as good. What's currently holding up chartering of this group? I
thought we had a charter bashed out ready to go? Can we make sure a request
goes in to the ADs for a meeting in Oslo (be it WG or BOF)?

I have a sort draft that is being reviewed by co-authors right now, and
hopefully we can get this out to the list soon. There will be some serious
debate about this and a face-to-face in Oslo would proove extermely
beneficial IMHO.

--
Cyrus

Date: Wed, 2 Jun 1999 10:11:57 -0700
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: IMAPEXT at Oslo?
Sender: [email-masked]

There hasn't been a whole lot of action here to charter a WG or have 
discussions. Do we want to BOF at Oslo for the purpose of chartering 
a WG? What's the state of affairs? Deadlines are looming.

pr
-- 
Pete Resnick <mailto:[email-masked]>
Eudora Engineering - QUALCOMM Incorporated
Ph: (217)337-6377 or (619)651-4478, Fax: (619)651-1102

Date: Wed, 30 Jun 1999 17:05:30 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: RE: I-D ACTION:draft-daboo-imap-view-00.txt
To: [email-masked]
cc: "'Alexey Melnikov'" <[email-masked]>, [email-masked], "'Cyrus Daboo'" <[email-masked]>
Sender: [email-masked]

On Wed, 30 Jun 1999 10:31:39 -0700, CJ Lofstedt wrote:
> I would also be interested in hearing why the "overloaded SELECT" (view as a
> folder) approach has been completely ruled out.

The short answer is "several people who work with IMAP don't like the idea of
overloading SELECT.  They think that they have a better way, and don't want to
do any work on what they consider to be inferior."

Basically, the problem with overloading SELECT is just that; it overloads an
existing mechanism and thus requires a server modality that changes existing
IMAP commands and responses, and too many incompatible changes need to be made
to the existing mechanism.

Another issue is that the client may want to change the view on the selected
mailbox.  With the VIEW architecture, this is simple; just do a new VIEW SET.
But, with overloaded SELECT, you have to issue a new SELECT.

Overloaded SELECT also limits the view mechanism to what is defined in the
overload.  VIEW, on the other hand, is designed to be extensible.

There's a few other issues, but these are the big ones.

These problems with overloaded SELECT aren't unsolvable.  However, (at least
in my opinion) the VIEW architecture is superior in all respects and there
really isn't much point to wasting time on overloaded SELECT.  It is superior
to add to IMAP instead of changing what is already there.

With all of the above in mind, I would not object to adding a means to do both
a SELECT and a VIEW SET in the same command, e.g. something like
	tag VIEW SELECT INBOX SEARCH FROM "Fred"
that is, a VIEW SELECT command whose first argument is the mailbox name to be
selected and subsequent arguments are as in VIEW SET.  It would have to be
stipulated that you can change the view with VIEW SET and don't need to issue
another VIEW SELECT -- so VIEW SELECT is just a way of reducing RTTs.

Reply-To: <[email-masked]>
From: "CJ Lofstedt" <[email-masked]>
To: "'Alexey Melnikov'" <[email-masked]>, <[email-masked]>, "'Cyrus Daboo'" <[email-masked]>
Subject: RE: I-D ACTION:draft-daboo-imap-view-00.txt
Date: Wed, 30 Jun 1999 10:31:39 -0700
Importance: Normal
Sender: [email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Alexey Melnikov
> Sent: Tuesday, June 29, 1999 4:19 PM
> To: Cyrus Daboo
> Cc: [email-masked]
> Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt
>
>
> Cyrus Daboo wrote:
>
> > Hi folks,
> > A new internet draft is available at:
> >
> > <http://www.ietf.org/internet-drafts/draft-daboo-imap-view-00.txt>
> >
> > [skipped]
> >
> > Note that this document proposes a mechanism different from
> that discussed
> > by various groups at recent IETF and IMC interop meetings.
> I can post a
> > list of reasons why we feel this approach is better if
> there is interest.
>
> I understand most of them (I didn't like the idea to overload
> SELECT from the
> beginning), but I would like to know them all.
>

I would also be interested in hearing why the "overloaded SELECT" (view as a
folder) approach has been completely ruled out.

/C-J Lofstedt

Date: Wed, 30 Jun 1999 08:08:52 -0400
From: Barry Leiba <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt
Originator-Info: login-id=leiba; server=mars.watson.ibm.com
Sender: [email-masked]

Cyrus says...
> No - a VIEW SET without a sub-command cancels the view mode.

As all three of you said; yes, I must have been distracted when I was
reading that part.  Sorry.

> Agreed. This document should define what commands are currently valid with
> VIEW SET, with provisions for future extensions to define new
> sub-commands.

I agree with Mark that we don't want to limit ourselves, but what Cyrus
says above was my intent when I made my comment: make it clear what
commands are appropriate now (and make it clear what the response will be
("BAD", I think) if you use an inappropriate command), and also make it
clear that future extensions may add commands to the "appropriate" list.

> Your're right. I guess I failed to pay full attention in my Latin classes!

:-)

> I think it must be a BAD. The document must say that clients MUST NOT
> issue the VIEW command when a VIEW SET is not operational, and servers
> MUST respond with BAD. This can be clarified in section 4.2.

Agreed.  Good.

Me:
>>   ...but you've already said that a VIEW fetch item must be included if
>>   a VIEW SET is in effect.  If I'm right in my previous note, then you
>>   probably shouldn't *also* say this.

Alexey:
> IMHO, it is not a big trouble to say something twice, especially in this
> case.

I'd generally agree, but the trouble here is that it's being said slightly
different, and I worry that the difference will confuse someone who's
reading the spec with only a marginal understanding of what's going on.

Cyrus:
> Actually 4.1(c) only refers to unsolicited FETCH responses. Perhaps this
> should be changed to 'all FETCH responses' in 4.1(c) and the section
> quoted above dropped.

Yeah, I like that answer.

>>   Understandable.  But that means that a client that receives an EXISTS
>>   in response to a FETCH must then go issue a NOOP to get the
>>   corresponding  VIEW response.  Can we think of a better way?
> 
> Hmm, that's a difficult one. I'm sure we can come up with a wy to deal
> with this.

Since I won't be in Oslo, if you discuss this there I'd like to see a
summary posted here.  Well, I suppose that someone'll take minutes of the
WG meeting and the whole thing'll be posted here anyway, so....

> No, you have to have the VIEW commands because there is no way to know how
> the UIDs map into the view. Clients must be able to say 'fetch the first
> ten messages in my sorted view'. Without VIEW FETCH the client has no way
> of knowing the sequence numbers or UIDs of these messages without first
> doing a 'FETCH 1:* (UID VIEW)', which would defeat the whole purpose of
> VIEW itself.

Well, duh.  Of course; I didn't think it out enough before I said what I
said.  Mark's also right about the hierarchy.  Of *course* we need the VIEW
FETCH command and so on.

> Having said that, with the 'dynamic' view approach it does need to be made
> clear that clients will need to maintain their own UID mappings, as they
> may need to access messages that move outside the view (as per your
> example).

Maybe a section on "implementation considerations" would be useful.  It
could highlight this, it could suggest when a client might want to use VIEW
(and when not), and that sort of thing.  Something brief, naturally, but it
might be nice to have.  (Again, I'm thinking of some of the questions we
see people asking about IMAP sometimes, which indicate that they're trying
to implement it without understanding it.)

Barry Leiba, Internet Messaging Technology   ([email-masked])
http://www.research.ibm.com/people/l/leiba

Date: Tue, 29 Jun 1999 20:22:42 -0400
From: Cyrus Daboo <[email-masked]>
To: Barry Leiba <[email-masked]>
cc: [email-masked]
Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt
Originator-Info: login-id=daboo; server=imap.cyrusoft.com:431
Sender: [email-masked]

--On Tue, Jun 29, 1999 3:21 PM -0400 Barry Leiba <[email-masked]>
wrote:

> * Section 4.1 refers to an "optional" sub-command, and (a) says that 
>   the  VIEW SET command selects messages that "match the results of the
>   sub-command".  It doesn't make it clear what happens if there's no
>   sub-command (all messages are selected, I presume).

No - a VIEW SET without a sub-command cancels the view mode. The server
then falls back to 'standard' IMAP4 behaviour and the VIEW ... commands are
invalid.

>   It also doesn't
>   say much about the sub-command; if "SEARCH" is the only command in
>   the base spec that applies, it should probably say so, to prevent
>   people from wondering what commands apply.  It might also say (which
>   is also said elsewhere) that it's intended that future SORT and 
>   THREAD commands may go here. 

Agreed. This document should define what commands are currently valid with
VIEW SET, with provisions for future extensions to define new sub-commands.

> * In 4.1 (b), "c.f." is properly abbreviated "cf.", and, anyway, is the
>   wrong Latin abbreviation here.  "cf." means "compare" (from the Latin
>   "confer"), and I don't think you want anyone to compare what you say
>   here to what's said in 4.2.  If you mean "see section 4.2", just say it.
>   (Sorry... pet peeve about misuse of Latin abbreviations.)

Your're right. I guess I failed to pay full attention in my Latin classes!

> * In 4.2 you should make it clear what, if anything, it means to use a
>   VIEW command without a VIEW SET being in effect.  It seems to me that
>   it's nonsensical (so should "VIEW FETCH" respond "NO" or "BAD" in that
>   case?).

I think it must be a BAD. The document must say that clients MUST NOT issue
the VIEW command when a VIEW SET is not operational, and servers MUST
respond with BAD. This can be clarified in section 4.2.

> * In 4.2, you say
>     command response.  However, server implementations MUST implicitly
>     include the VIEW fetch item as part of any FETCH response caused by
>     a VIEW command, regardless of whether a VIEW was specified as a
>     message data item to the FETCH.
> 
>   ...but you've already said that a VIEW fetch item must be included if
>   a VIEW SET is in effect.  If I'm right in my previous note, then you
>   probably shouldn't *also* say this.

Actually 4.1(c) only refers to unsolicited FETCH responses. Perhaps this
should be changed to 'all FETCH responses' in 4.1(c) and the section quoted
above dropped.

> * In 5.1.1:
>     A VIEW untagged response MUST NOT be sent when no command is in
>     progress; nor while responding to a FETCH, SEARCH or STORE command.
> 
>   Understandable.  But that means that a client that receives an EXISTS
>   in response to a FETCH must then go issue a NOOP to get the
>   corresponding  VIEW response.  Can we think of a better way?

Hmm, that's a difficult one. I'm sure we can come up with a wy to deal with
this.

> * In 5.1.2:
>     When the old view position number in the VIEW untagged response is
>     non-zero, the effect of VIEW is a message inserted into the view at
>     the position given by <new>.  The view position numbers of all
>     subsequent messages inthge current view are incremented.
> 
>     When the new view position number in the VIEW untagged response is
>     non-zero, the effect of VIEW is a message removed from the view at
>     the position given by <old>.  The view position numbers of all
>     subsequent messages inthe current view are decremented.
> 
>   In both of these, I think you mean "zero" where you say "non-zero".

Yup, that's wrong in the document.

>   Also also, since you explicitly talk about incrementing and decrementing
>   view position numbers, perhaps you should include a paragraph about what
>   happens if both the old and new positions are non-zero... which also
>   require renumbering other messages.  No, *I* don't think it needs to be
>   said, but, then, I'm always surprised at the interpretations that
>   sometimes happen when one fails to say something.  :-)

This can easily be added, and would be a good example to clarify things.

> * In the grammar:
>     position         ::= number ["." number]
>                          ;; position number of messages in the view
>                          ;; may be hierarchical if sub-command defines
>                          ;; hierarchic ordering of messages
> 
>   This makes some of the statements about "incrementing" and
>   "decrementing" view positions harder to understand.  Maybe all we
>   should say about what happens after a VIEW response is that "view
>   positions of subsequent [or intervening] messages must be adjusted
>   appropriately" or some such.

That phrase could be used together with the existing examples.

> * Finally, just to clarify things... we'd had an extended discussion about
>   whether it was reasonable to remove a message from a view, once it was
>   in the view.  Problems of side-effects and such -- for instance, what 
>   happens in the following case (abbreviating a little):
>     c: t0 VIEW SET SEARCH UNSEEN
>     s: * 25 VIEW 1234 0 4
>     c: t1 VIEW FETCH 4 BODY[1]
>     s: * 25 FETCH (FLAGS (\Seen) VIEW 4 BODY[1] ...
>     s: t1 OK done
>     c: t2 NOOP
>     s: * 25 VIEW 1234 4 0    [\Seen flag caused view to change]
>     s: t2 OK done
> 
>   Now, as a side-effect of the FETCH, the client can no longer use VIEW
>   FETCH on this message.  Other cases are easy to imagine.  It makes VIEW
>   FETCH of questionable use.
> 
>   Clearly, the decision made in writing this draft was to have messages 
>   disappear from the view (during earlier discussions, some thought they 
>   should not, though it came out that that makes reconnecting after
>   connection  failures difficult).
> 
>   I just wanted to point out, for the record, that there were two sides to
>   that discussion, and to point out, for the record, which one was
>   adopted. (And, for the record, I agree with the choice.)

I think the issue of 'static' vs 'dynamic' views still needs more
discussion. I've not ruled out one or the other or indeed both.

For example to do VIEW in static mode, we just remove the unsolicted VIEW
untagged response and add a 'VIEW UPDATE' command, which returns untagged
VIEWs for all changes since the last VIEW SET or VIEW UPDATE.

One could even envisage a situation where the client determines whether the
view is static or dynamic based on the command it issues.

>   But I would like to see some of these potential problems mentioned in
>   the  spec.  I would also like to see some encouragement to use UIDs
>   instead of view positions.  In fact, I'd go as far as to say that I
>   don't think we should *have* a VIEW FETCH, VIEW STORE, or VIEW COPY
>   command, and that we should clearly state that UIDs are the things to
>   use when you're using views.

No, you have to have the VIEW commands because there is no way to know how
the UIDs map into the view. Clients must be able to say 'fetch the first
ten messages in my sorted view'. Without VIEW FETCH the client has no way
of knowing the sequence numbers or UIDs of these messages without first
doing a 'FETCH 1:* (UID VIEW)', which would defeat the whole purpose of
VIEW itself.

Having said that, with the 'dynamic' view approach it does need to be made
clear that clients will need to maintain their own UID mappings, as they
may need to access messages that move outside the view (as per your
example).

--
Cyrus

Date: Tue, 29 Jun 1999 16:25:56 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt
To: Barry Leiba <[email-masked]>
cc: Cyrus Daboo <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

First, an apology.  My contribution to this document so far has been mostly
architectural, so if I say something that doesn't fully mesh with what the
document says, keep this in mind.

> * Section 4.1 refers to an "optional" sub-command, and (a) says that
>   the  VIEW SET command selects messages that "match the results of the
>   sub-command".  It doesn't make it clear what happens if there's no
>   sub-command (all messages are selected, I presume).

I thought that VIEW SET without a command was to cancel the view.  If this
isn't specified, it should be.

>   It also doesn't
>   say much about the sub-command; if "SEARCH" is the only command in
>   the base spec that applies, it should probably say so, to prevent
>   people from wondering what commands apply.  It might also say (which
>   is also said elsewhere) that it's intended that future SORT and
>   THREAD commands may go here.

Let's talk about the wordsmithing for this at Oslo.  VIEW SET's command
argument is a command that defines a set (and, potentially, ordering) of
messages.  I agree that this needs to be well-specified, but I don't want to
tag/limit it to SEARCH/SORT/THREAD even if that's the actual situation today.

> * In 4.2 you should make it clear what, if anything, it means to use a
>   VIEW command without a VIEW SET being in effect.  It seems to me that
>   it's nonsensical (so should "VIEW FETCH" respond "NO" or "BAD" in that
>   case?).

I think that it's a BAD.

>   I would also like to see some encouragement to use UIDs instead of
>   view positions.  In fact, I'd go as far as to say that I don't think we
>   should *have* a VIEW FETCH, VIEW STORE, or VIEW COPY command, and that we
>   should clearly state that UIDs are the things to use when you're using
>   views.

You need some way to express hierarchy in a VIEW (for threading), which is why
neither sequence numbers nor UIDs are good enough.  If you use either a
sequence number or UID (I don't think that one should be preferred over the
other, beyond what technical considerations indicate), then you have to
maintain the map or some portion of it.

The whole point for VIEW FETCH and friends is so you don't need to have the
map at all.

Date: Wed, 30 Jun 1999 03:28:32 +0400
From: Alexey Melnikov <[email-masked]>
To: Barry Leiba <[email-masked]>
CC: Cyrus Daboo <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt
Sender: [email-masked]

Barry Leiba wrote:

> First comment:  Can we take the IMAP mailing list out of the list on
> this discussion, and just hold it on the IMAPext mailing list?  It seems
> silly to post the same discussion to both lists -- why do we have the
> IMAPext list at all, if we're going to do that?
>
> Other comments:
> * Section 4.1 refers to an "optional" sub-command, and (a) says that
>   the  VIEW SET command selects messages that "match the results of the
>   sub-command".  It doesn't make it clear what happens if there's no
>   sub-command (all messages are selected, I presume).

Draft says that VIEW SET with out optional argument cancels VIEW state (section 4.1
point g)).

> * In 4.2 you should make it clear what, if anything, it means to use a
>   VIEW command without a VIEW SET being in effect.  It seems to me that
>   it's nonsensical (so should "VIEW FETCH" respond "NO" or "BAD" in that
>   case?).

Actually, I don't mind if VIEW returns OK, as if
"VIEW SET SEARCH ALL" has been issued.

> * In 4.2, you say
>     command response.  However, server implementations MUST implicitly
>     include the VIEW fetch item as part of any FETCH response caused by
>     a VIEW command, regardless of whether a VIEW was specified as a
>     message data item to the FETCH.
>
>   ...but you've already said that a VIEW fetch item must be included if
>   a VIEW SET is in effect.  If I'm right in my previous note, then you
>   probably shouldn't *also* say this.

IMHO, it is not a big trouble to say something twice, especially in this case.

> * Finally, just to clarify things... we'd had an extended discussion about
>   whether it was reasonable to remove a message from a view, once it was
>   in the view.  Problems of side-effects and such -- for instance, what
>   happens in the following case (abbreviating a little):
>   [skipped]

>   But I would like to see some of these potential problems mentioned in the
>   spec.  I would also like to see some encouragement to use UIDs instead of
>   view positions.  In fact, I'd go as far as to say that I don't think we
>   should *have* a VIEW FETCH, VIEW STORE, or VIEW COPY command, and that we
>   should clearly state that UIDs are the things to use when you're using views.

I am tend to support the idea.

--
Best Regards,
Alexey Melnikov

Date: Wed, 30 Jun 1999 03:18:52 +0400
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: [email-masked]
Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt
Sender: [email-masked]

Cyrus Daboo wrote:

> Hi folks,
> A new internet draft is available at:
>
> <http://www.ietf.org/internet-drafts/draft-daboo-imap-view-00.txt>
>
> [skipped]
>
> Note that this document proposes a mechanism different from that discussed
> by various groups at recent IETF and IMC interop meetings. I can post a
> list of reasons why we feel this approach is better if there is interest.

I understand most of them (I didn't like the idea to overload SELECT from the
beginning), but I would like to know them all.

Few comments in addition to what Barry wrote:

1). I am concerned about amount of responses sent when message moves into or
outside of the view.
I would rather add something like the following:

Server MUST NOT send extended EXISTS response when message moves into or
outside of the view,
but there is no changes to the total number of messages in the mailbox.

This is not clear from the current version of the draft.

2). According to the draft a server MUST send untagged VIEW for every new
message that arrives in the mailbox.
Again, there is no reason why server should send EXISTS ***after*** VIEW
response, because untagged VIEW
already contains all information about new message. (EXISTS still MUST be sent
right after VIEW SET)

--
Best Regards,
Alexey Melnikov

Date: Tue, 29 Jun 1999 15:21:52 -0400
From: Barry Leiba <[email-masked]>
Organization: Internet Messaging Technology; TR2_Xagent=WATSON
To: Cyrus Daboo <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt
Sender: [email-masked]

First comment:  Can we take the IMAP mailing list out of the list on
this discussion, and just hold it on the IMAPext mailing list?  It seems
silly to post the same discussion to both lists -- why do we have the
IMAPext list at all, if we're going to do that?

Other comments:
* Section 4.1 refers to an "optional" sub-command, and (a) says that 
  the  VIEW SET command selects messages that "match the results of the
  sub-command".  It doesn't make it clear what happens if there's no
  sub-command (all messages are selected, I presume).  It also doesn't
  say much about the sub-command; if "SEARCH" is the only command in
  the base spec that applies, it should probably say so, to prevent
  people from wondering what commands apply.  It might also say (which
  is also said elsewhere) that it's intended that future SORT and 
  THREAD commands may go here.

* In 4.1 (b), "c.f." is properly abbreviated "cf.", and, anyway, is the
  wrong Latin abbreviation here.  "cf." means "compare" (from the Latin
  "confer"), and I don't think you want anyone to compare what you say
  here to what's said in 4.2.  If you mean "see section 4.2", just say it.
  (Sorry... pet peeve about misuse of Latin abbreviations.)

* In the example in 4.1 (g), correct spelling of "SEARCH".

* In 4.2 you should make it clear what, if anything, it means to use a
  VIEW command without a VIEW SET being in effect.  It seems to me that
  it's nonsensical (so should "VIEW FETCH" respond "NO" or "BAD" in that
  case?).

* In 4.2, you say
    command response.  However, server implementations MUST implicitly
    include the VIEW fetch item as part of any FETCH response caused by
    a VIEW command, regardless of whether a VIEW was specified as a
    message data item to the FETCH.

  ...but you've already said that a VIEW fetch item must be included if
  a VIEW SET is in effect.  If I'm right in my previous note, then you
  probably shouldn't *also* say this.

* In 5.1.1:
    A VIEW untagged response MUST NOT be sent when no command is in
    progress; nor while responding to a FETCH, SEARCH or STORE command.

  Understandable.  But that means that a client that receives an EXISTS
  in response to a FETCH must then go issue a NOOP to get the corresponding 
  VIEW response.  Can we think of a better way?

  Also, it might not hurt to point out that IDLE can count as a command
  in progress.  But, then, maybe that's too obvious to have to mention.

* In 5.1.2:
    When the old view position number in the VIEW untagged response is
    non-zero, the effect of VIEW is a message inserted into the view at
    the position given by <new>.  The view position numbers of all
    subsequent messages inthge current view are incremented.

    When the new view position number in the VIEW untagged response is
    non-zero, the effect of VIEW is a message removed from the view at
    the position given by <old>.  The view position numbers of all
    subsequent messages inthe current view are decremented.

  In both of these, I think you mean "zero" where you say "non-zero".
  Also, fix "inthge" and "inthe".
  Also also, since you explicitly talk about incrementing and decrementing
  view position numbers, perhaps you should include a paragraph about what
  happens if both the old and new positions are non-zero... which also
  require renumbering other messages.  No, *I* don't think it needs to be
  said, but, then, I'm always surprised at the interpretations that sometimes
  happen when one fails to say something.  :-)

* In the grammar:
    position         ::= number ["." number]
                         ;; position number of messages in the view
                         ;; may be hierarchical if sub-command defines
                         ;; hierarchic ordering of messages

  This makes some of the statements about "incrementing" and "decrementing"
  view positions harder to understand.  Maybe all we should say about what
  happens after a VIEW response is that "view positions of subsequent [or
  intervening] messages must be adjusted appropriately" or some such.

* Finally, just to clarify things... we'd had an extended discussion about
  whether it was reasonable to remove a message from a view, once it was
  in the view.  Problems of side-effects and such -- for instance, what 
  happens in the following case (abbreviating a little):
    c: t0 VIEW SET SEARCH UNSEEN
    s: * 25 VIEW 1234 0 4
    c: t1 VIEW FETCH 4 BODY[1]
    s: * 25 FETCH (FLAGS (\Seen) VIEW 4 BODY[1] ...
    s: t1 OK done
    c: t2 NOOP
    s: * 25 VIEW 1234 4 0    [\Seen flag caused view to change]
    s: t2 OK done

  Now, as a side-effect of the FETCH, the client can no longer use VIEW FETCH
  on this message.  Other cases are easy to imagine.  It makes VIEW FETCH of
  questionable use.

  Clearly, the decision made in writing this draft was to have messages 
  disappear from the view (during earlier discussions, some thought they 
  should not, though it came out that that makes reconnecting after connection 
  failures difficult).

  I just wanted to point out, for the record, that there were two sides to
  that discussion, and to point out, for the record, which one was adopted.
  (And, for the record, I agree with the choice.)

  But I would like to see some of these potential problems mentioned in the 
  spec.  I would also like to see some encouragement to use UIDs instead of
  view positions.  In fact, I'd go as far as to say that I don't think we
  should *have* a VIEW FETCH, VIEW STORE, or VIEW COPY command, and that we
  should clearly state that UIDs are the things to use when you're using views.

Barry Leiba, Internet Messaging Technology  ([email-masked])
http://www.research.ibm.com/people/l/leiba

From: "Rubinstein, Dmitry" <[email-masked]>
To: [email-masked]
Subject: RE: Client ID extension
Date: Tue, 29 Jun 1999 12:41:52 +0300
Sender: [email-masked]

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

------_=_NextPart_000_01BEC213.9E2A9490
Content-Type: text/plain;
	charset="iso-8859-1"

> From: Mike Gahrns [mailto:[email-masked]]
> Given that there seems to be 
> reasonable
> number of people who concur that this type of functionality 
> would be useful,
> moving the extension forward should hopefully be rather 
> straight foward with
> only minor changes needed.  

OK then, what are the needed changes? Below is the original draft for your
reference. 

--
Dmitry Rubinstein 

------_=_NextPart_000_01BEC213.9E2A9490
Content-Type: text/plain;
	name="draft-tjs-id-01.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="draft-tjs-id-01.txt"

Network Working Group                                       T. =
Showalter
Not An Internet Draft                                    Carnegie =
Mellon
Document: untitled                                         February =
1997
Expire sometime after it's released

                           IMAP4 ID extension

Status of this Memo

    This document does not exist.

1.   Abstract

    The purpose of the ID extension to the IMAP4rev1 protocol is to
    allow the server and client to exchange identification information
    on their implementation in order to make bug reports and usage
    statistics more complete.

    Although the IMAP4rev1 protocol described in [IMAP4rev1] provides a
    method for accessing remote mail stores, there is no facility to
    advertise what program a client or server uses to provide service.
    This makes it difficult for implementors to get complete bug =
reports
    from users, as it is frequently difficult to know what client or
    server is in use.

    Additionally, some sites may wish to assemble usage statistics =
based
    on what clients are used, but in an an environment where users are
    permitted to obtain and maintain their own clients this is =
difficult
    to accomplish.

    The ID command provides a facility to advertise information on what
    programs are being used, along with contact information should bugs
    ever occur.

2.   Conventions Used in this Document

    The conventions used in this document are the same as specified in
    [IMAP4rev1]. In examples, "C:" and "S:" indicate lines sent by the
    client and server respectively.  Line breaks have been inserted for
    readability.

3.   Specification

    The ID extension is provided in order for clients and servers to
    exchange information on their implementations.

    This information may be submitted to a server by any client wishing
    to provide information for statistical purposes, provided the =
server
    advertises its willingness to take the information with the atom
    "ID" included in the list of capabilities returned by the =
CAPABILITY
    command.

    Implementations MUST NOT make operational changes based on the data
    sent as part of the ID command or response.

3.1.   ID Command

    Arguments:  client parameter list or NIL

    Responses:  OPTIONAL untagged response: ID

    Result:     OK    identification information accepted
                BAD   command unknown or arguments invalid

    Identification information is sent by the client with the ID
    command.  The information sent is in the form of a list of
    field/value pairs.  Fields are permitted to be any IMAP4 string, =
and
    values are permitted to be any IMAP4 string or NIL.  A value of NIL
    indicates that the client can not or will not specify this
    information.  The client may also send NIL instead of the list,
    indicating that it wants to send no information, but would still
    accept a server response.

    The avalible fields are defined in section 3.3.

    Example:
    C: a023 ID ("name" "sodr" "version" "19.34" "vendor" "Pink Floyd
        Music Limited")
    S: a023 OK ID completed

3.2.   ID Response

    Contents:	server parameter list

    In response to an ID command issued by the client, the server MAY
    reply with a tagged response containing information on its
    implementation.  The format is the same as the client list.

    Example:
    C: a023 ID NIL
    S: * ID ("name" "Cyrus" "version" "1.5" "os" "sunos" "os-version" =
"5.5"
        "email" "[email-masked]")
    S: a023 OK ID command completed

    The server is not required to send an ID response to an ID command.

3.3.   Defined Field Values

    Any string may be sent as a field, but the following are defined to
    describe certain values that might be sent.  Implementations are
    free to send none, any, or all of these.  Strings are not
    case-sensitive.

    name                     Name of the program
    version                  Version number of the program
    os                       Name of the operating system
    os-version               Version of the operating system
    vendor                   Vendor of the client/server
    contact                  Contact person for the client/server
    email                    Email address of contact/vendor
    phone                    Phone number of contact/vendor
    address                  Postal address of contact/vendor
    date                     Date program was released;
                               should be in a human-readable form
    command                  Command used to start the program
    arguments                Arguments supplied on the command line (if
                               any)
    environment              Description of environment (i.e., UNIX
                               environment variables or Windows =
registry
                               settings.

    Implementations MUST NOT use contact information to submit =
automatic
    bug reports.  Information supplied with the ID command is not
    necessarily complete or accurate.  Implementations may include
    such information in a report submitted.

    It is preferrable to find the name and version of the underlying
    operating system at runtime in cases where this is possible.

    Some of this information (specifically, the command, arguments, and
    environment fields) is likely to violate users' privacy.  See the
    section on security considerations below.

    Implementations may send the same tag more than once; for example,
    C: a001 ID ("client-name" NIL "client-name" "spooky" "client-name"
        NIL)
    S: a001 OK ID completed

4.   Formal Syntax

    This syntax is intended to augment the grammar specified in =
[IMAP4rev1]
    in order to provide for the ID command.  This specification uses =
the
    augmented Backus-Naur Form (BNF) notation as specified in [RFC-822]
    and modified by [IMAP4rev1].

    command_any ::=3D "CAPABILITY / "LOGOUT" / "NOOP" / x_command / id
	;; adds id command to command_any in [IMAP4rev1]

    id ::=3D "ID" SPACE id_params_list / nil

    id_response ::=3D "ID" SPACE id_params_list / nil

    id_params_list ::=3D "(" #(string SPACE nstring) ")" / nil
	;; list of field value pairs

    response_data ::=3D "*" (resp_cond_state / resp_cond_bye /
        mailbox_data / message_data / capability_data / id_response)

5.   References

    [IMAP4rev1] Crispin, M., "Internet Message Access Protocol - =
Version
        4rev1", RFC 2060, University of Washington, October, 1996.

    [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet
        Text Messages", STD 11, RFC 822.

6.   Security Considerations

    A client or server supporting ID may violate the privacy of users =
by
    sending information on the underlying implementation, or in some
    cases, information on how the mail client was invoked.  For this
    reason, it is highly desirable that client implementations provide =
a
    method of disabling ID support -- by either not sending ID at all,
    or by sending the command "ID NIL", or by controlling the level of
    detail of information sent.  A server may reply similarly in its
    untagged response ("* ID NIL"), or it may send no untagged =
response.

7.   Author's Address

    Tim Showalter
    Carnegie Mellon University
    5000 Forbes Avenue
    Pittsburgh, PA 15213

    Email: [email-masked]

------_=_NextPart_000_01BEC213.9E2A9490--

Date: Mon, 28 Jun 1999 18:40:54 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt
To: steve spear <[email-masked]>
cc: [email-masked], [email-masked]
Sender: [email-masked]

On Tue, 29 Jun 1999 00:38:15 +0000, steve spear wrote:
> Can someone explain how traffic is reduced by SORT over clients that are
> caching the headers and simply request messages headers they haven't seen
> before?

Most such clients are POP clients masquerading as IMAP clients.  Consider true
IMAP clients, which don't have a cache (and may well be a kiosk or other
shared machine which shouldn't cache!), and don't want to load all those
headers.

Date: Tue, 29 Jun 1999 00:38:15 +0000
From: steve spear <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt
Sender: [email-masked]

Can someone explain how traffic is reduced by SORT over clients that are
caching the headers and simply request messages headers they haven't seen
before?   As Tony Hansen pointed out - AT&T is trying to handle many millions
of users.  The thought of using more resources on the server instead of the
clients that are largely idle is a concern of ours.  We keep hearing about
thin-client's, but the memory available in the thin clients still boggles the
mind of those who had memory measured in Kilobytes ( not Megabytes ) 25+ years
ago.  If it makes sense we'll cheer for it,  but we'd like to understand where
the advantage is.

Steve Spear
AT&T Technology Consultant

Cyrus Daboo wrote:

> --On Mon, Jun 28, 1999 5:52 PM -0400 Tony Hansen <[email-masked]> wrote:
>
> > Our major problem with this proposal is not an issue with the extension
> > itself. Instead, we have an issue with its impact on server performance
> > when dealing with LARGE user populations (hundreds of thousands or
> > millions). Each proposal such as this does increase the server load.
>
> Actually the hope for this proposal (wrt to sorting) is to REDUCE the
> overall server load by removing the need for a client to download the
> envelopes of all messages in order to sort them for the end-user. It should
> also reduce client load and indeed allow thin-clients to present sorted or
> sub-set views without having to do much work.
>
> --
> Cyrus

Date: Mon, 28 Jun 1999 20:28:06 -0400
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
cc: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt
Originator-Info: login-id=daboo; server=imap.cyrusoft.com:431
Sender: [email-masked]

--On Mon, Jun 28, 1999 5:52 PM -0400 Tony Hansen <[email-masked]> wrote:

> Our major problem with this proposal is not an issue with the extension
> itself. Instead, we have an issue with its impact on server performance
> when dealing with LARGE user populations (hundreds of thousands or
> millions). Each proposal such as this does increase the server load.

Actually the hope for this proposal (wrt to sorting) is to REDUCE the
overall server load by removing the need for a client to download the
envelopes of all messages in order to sort them for the end-user. It should
also reduce client load and indeed allow thin-clients to present sorted or
sub-set views without having to do much work.

--
Cyrus

From: "Mike Gahrns" <[email-masked]>
To: <[email-masked]>
Subject: Re: Client ID extension
Date: Mon, 28 Jun 1999 15:58:23 -0700
Sender: [email-masked]

Cyrus Daboo writes:
> I think the client ID extension should be straightforward enough that it
> can be moved forward via the mailing list rather than needing to be added
> to the future WG. All it really needs is for someone to update the
document
> and to start the formal review process over again. Perhaps Tim (original
> author) could be persuaded to do this?
This echos a previous comment I had regarding the charter of the WG.  I'd
prefer that the WG concentrate on the "larger" issues already proposed:
SORT, ANNOTATE and ACL.

Smaller extensions will probably be better served taking them outside of the
WG.

In regards to ID, I think the original proposal was pretty much there.  The
dissention seemed to resolve around whether the premise of allowing this
functionality was good or bad.  Given that there seems to be reasonable
number of people who concur that this type of functionality would be useful,
moving the extension forward should hopefully be rather straight foward with
only minor changes needed.  I am not sure what Tim's thoughts are on moving
this forward, but I would be willing to help with this if he is unable to.

Date: Mon, 28 Jun 1999 15:05:38 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt
To: [email-masked]
cc: Cyrus Daboo <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

On Mon, 28 Jun 1999 17:52:36 -0400, Tony Hansen wrote:
> Our major problem with this proposal is not an issue with the extension
> itself. Instead, we have an issue with its impact on server performance
> when dealing with LARGE user populations (hundreds of thousands or
> millions). Each proposal such as this does increase the server load.

There's a tradeoff in all of these things.  Some people consider the
functionality of VIEW to be very important, and have blocked SORT and THREAD
unless this functionality is provided.  One of their concerns is that the SORT
command uses communication bandwidth; for example, sorting a 2000 message
mailbox results in a response that is 8900 octets long.

SORT and THREAD are very important for UW since these extensions make a *HUGE*
difference in Pine performance.  So, it's important for us to get these
concerns addressed, and preferably in an extensible mechanism.

Date: Mon, 28 Jun 1999 17:52:36 -0400
From: Tony Hansen <[email-masked]>
Reply-To: [email-masked]
Organization: AT&T Laboratories
To: Cyrus Daboo <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt
Sender: [email-masked]

Cyrus Daboo wrote:
> 
> A new internet draft is available at:
> <http://www.ietf.org/internet-drafts/draft-daboo-imap-view-00.txt>
> 
> This is the first cut at moving towards a standardised sorting mechanism
> for IMAP. The extension proposed in this draft is actually a more general
> extension that is used to allow a client to operate on a sub-set of
> messages (as determined right now by an IMAP SEARCH command) as opposed to
> the entire set of messages in the mailbox.
> 
> Basically this extension introduces a couple of new commands, together with
> some new responses, including a new FETCH item called 'VIEW' which is the
> message's position in the 'sub-set' or 'view'. Clients can then access
> messages by their view position using a new VIEW command that takes FETCH
> (and other commands) as arguments (inthe same way as the UID command
> already present in IMAP4).
> ...

Our major problem with this proposal is not an issue with the extension
itself. Instead, we have an issue with its impact on server performance
when dealing with LARGE user populations (hundreds of thousands or
millions). Each proposal such as this does increase the server load.

	Tony Hansen
	[email-masked]

Date: Mon, 28 Jun 1999 12:45:31 -0700
From: Mike Macgirvin <[email-masked]>
Organization: The Rebel Alliance
To: Mark Crispin <[email-masked]>
CC: Cyrus Daboo <[email-masked]>, [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt
Sender: [email-masked]

Mark Crispin wrote:
> 
> My only comment about multiple simultaneous views is that this makes VIEW much
> more complicated to implement; and as such presents a barrier to prospective
> implementors.  It may also contribute to the ongoing myth that IMAP is an
> expensive service to have on a machine.
> 
> Nevertheless, this is just an observation and I don't oppose your proposal.
> Please bring it up at Oslo.

I agree totally that it makes server implementation of this feature
non-trivial. Without it I think the client ends up having to work just as
hard by issuing multiple SEARCH and/or VIEW commands everytime anything in
the mailbox changes - or doing all the work client-side. We can do that
today without requiring any extensions, but it's hardly efficient. So this
draft presents a way to avoid a lot of client overhead as long as you only
define or "activate" only one view. Having worked a lot with views in the
past, one is not very typical. The bell curve fits around 5 and 20 at least
on INBOX and it's reasonable for a human to want to have all their views
active in the sense that message counts are propogated in as near to real
time as possible. 

I'll see if somebody else from here will be at Oslo and ask that they
present these arguments - unfortunately, I have other obligations.

Date: Mon, 28 Jun 1999 14:53:00 -0400
From: Cyrus Daboo <[email-masked]>
To: "Rubinstein, Dmitry" <[email-masked]>, [email-masked]
Subject: Re: Client ID extension
Originator-Info: login-id=daboo; server=imap.cyrusoft.com
Sender: [email-masked]

--On Monday, June 28, 1999, 9:03 PM +0300 "Rubinstein, Dmitry"
<[email-masked]> wrote:

> Hi, everybody!
> 
> There has been a long discussion regarding the need for <subj> on the
> [email-masked] mailing list (whose subscribers, if I'm not terribly
> misaken, are a superset of the current list's subscribers). The majority
> of speakers eventually supported the idea of adding Client ID extension
> and at least 3-4 developers expressed their willingness to add support to
> ClientID to their products. There is a draft that is about year old that
> describes the proposed extension. There was a talk of adding this
> extension to the charter of this WG. What does it take at this point to
> make it into a standard?
> 

Well there is no formal charter for this group as yet. That ought to be the
first item on the agenda for Oslo!

I think the client ID extension should be straightforward enough that it
can be moved forward via the mailing list rather than needing to be added
to the future WG. All it really needs is for someone to update the document
and to start the formal review process over again. Perhaps Tim (original
author) could be persuaded to do this?

--Cyrus

Date: Mon, 28 Jun 1999 14:38:06 -0400
From: Cyrus Daboo <[email-masked]>
To: Mike Macgirvin <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt
Originator-Info: login-id=daboo; server=imap.cyrusoft.com
Sender: [email-masked]

Hi Mike,

--On Monday, June 28, 1999, 10:56 AM -0700 Mike Macgirvin
<[email-masked]> wrote:

> This appears to have the side effect of limiting you to one view. Multiple
> active views would require extensive client polling, and the notification
> events would only be active on one of them. 
> 
> I'd like to propose a modest enhancement, where the client can provide a
> (client generated) view-id, and subsequent changes to that view are tagged
> with the view-id. This permits multiple active views. Granted, there is
> server overhead involved, but this is the price of moving it off the
> client in the first place. Having the client generate an ID is better
> than having to match an untagged response with a search string. 

Multiple views would be nice. I thought of doing something similar too.
However, I concluded that the added complexity of handling multiple views
is too much for now. It requires a lot more than just modifying EXISTS.

One major problem is that messages can be in more than one view. One way to
handle this would be to redefine the 'position' syntax to be a list of
'view number'/'view position' pairs. For example, an EXPUNGE for a message
in view #0001 and view #0003 would end up as:

a EXPUNGE
* 1 EXPUNGE 1234 ((0001 1)(0003 4))
a OK

My personal feeling is to keep VIEW simple for now and see how
implementation experience goes. There's no reason why later we can't define
a new command to deal with multiple named views and redefine the existing
VIEW syntax appropriately. e.g. 'VIEW SET' would be augmented by a 'VIEW
NAMEDSET' command that could redfine the 'position' formal syntax item to
be an S-Expression list (or whatever), and require a view name in addition
to the sub-command in a VIEW command.

--Cyrus

Date: Mon, 28 Jun 1999 11:14:00 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt
To: Mike Macgirvin <[email-masked]>
cc: Cyrus Daboo <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

My only comment about multiple simultaneous views is that this makes VIEW much
more complicated to implement; and as such presents a barrier to prospective
implementors.  It may also contribute to the ongoing myth that IMAP is an
expensive service to have on a machine.

Nevertheless, this is just an observation and I don't oppose your proposal.
Please bring it up at Oslo.

From: "Rubinstein, Dmitry" <[email-masked]>
To: [email-masked]
Subject: Client ID extension
Date: Mon, 28 Jun 1999 21:03:28 +0300
Sender: [email-masked]

Hi, everybody!

There has been a long discussion regarding the need for <subj> on the
[email-masked] mailing list (whose subscribers, if I'm not terribly
misaken, are a superset of the current list's subscribers). The majority of
speakers eventually supported the idea of adding Client ID extension and at
least 3-4 developers expressed their willingness to add support to ClientID
to their products. There is a draft that is about year old that describes
the proposed extension. There was a talk of adding this extension to the
charter of this WG. What does it take at this point to make it into a
standard?

TIA,

--
Dmitry Rubinstein 

Date: Mon, 28 Jun 1999 11:02:57 -0700
From: Mike Macgirvin <[email-masked]>
Organization: The Rebel Alliance
To: Cyrus Daboo <[email-masked]>, [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt
Sender: [email-masked]

Before somebody corrects me - yes I do know that EXISTS are untagged and
require *.

> It probably isn't necessary that the results be chained in the EXISTS
> response, i.e. 

>        S: * 172 EXISTS 0001 23
>        S: * 172 EXISTS 0002 6
............^

> would be just fine.

Date: Mon, 28 Jun 1999 10:56:26 -0700
From: Mike Macgirvin <[email-masked]>
Organization: The Rebel Alliance
To: Cyrus Daboo <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt
Sender: [email-masked]

This appears to have the side effect of limiting you to one view. Multiple
active views would require extensive client polling, and the notification
events would only be active on one of them. 

I'd like to propose a modest enhancement, where the client can provide a
(client generated) view-id, and subsequent changes to that view are tagged
with the view-id. This permits multiple active views. Granted, there is
server overhead involved, but this is the price of moving it off the client
in the first place. Having the client generate an ID is better than having
to match an untagged response with a search string. 

        C: A143 VIEW SET 0001 SEARCH FROM "Smith"
        S: * 172 EXISTS 0001 23
        S: A143 OK VIEW SET completed
	C: A144 VIEW SET 0002 SEARCH FROM "Myboss"
	S: * 172 EXISTS 0001 23 0002 6
	S: A144 OK VIEW SET completed

It probably isn't necessary that the results be chained in the EXISTS
response, i.e. 

	S: 172 EXISTS 0001 23
	S: 172 EXISTS 0002 6

would be just fine. 

This would alter other responses appropriately. This way mailbox events can
trigger updates of any active views.
Thinking one step further, something to shut down an active view would
likely be desirable in this model. 

	C: A145 VIEW REMOVE 0001
	S: A145 OK VIEW 0001 FROM "Smith" removed

If I'm missing something obvious and all this isn't necessary, please
correct me.

Date: Mon, 28 Jun 1999 13:16:45 -0400
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: I-D ACTION:draft-daboo-imap-view-00.txt
Originator-Info: login-id=daboo; server=imap.cyrusoft.com
Sender: [email-masked]

Hi folks,
A new internet draft is available at:

<http://www.ietf.org/internet-drafts/draft-daboo-imap-view-00.txt>

This is the first cut at moving towards a standardised sorting mechanism
for IMAP. The extension proposed in this draft is actually a more general
extension that is used to allow a client to operate on a sub-set of
messages (as determined right now by an IMAP SEARCH command) as opposed to
the entire set of messages in the mailbox.

Basically this extension introduces a couple of new commands, together with
some new responses, including a new FETCH item called 'VIEW' which is the
message's position in the 'sub-set' or 'view'. Clients can then access
messages by their view position using a new VIEW command that takes FETCH
(and other commands) as arguments (inthe same way as the UID command
already present in IMAP4).

It is proposed that a future SORT extension will be used with the VIEW
mechanism to allow sub-setting of sort results and to allow clients to
access the messages in sorted order as opposed to sequence number order.
Thus this draft represents the first step towards the goal of a sort
command acceptable to all - hopefully!

BTW that the VIEW mechanism can be used with other types of sub-setting we
might want to think about in the future (e.g. message threading based on
message-id/in-reply-to etc).

Note that this document proposes a mechanism different from that discussed
by various groups at recent IETF and IMC interop meetings. I can post a
list of reasons why we feel this approach is better if there is interest.

--Cyrus Daboo

Date: Wed, 23 Jun 1999 17:45:33 -0500
To: IMAP Extensions <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Fwd: 45th IETF: IMAPEXT
Sender: [email-masked]

--- begin forwarded text

Date: Wed, 23 Jun 1999 18:36:24 -0400
To: Pete Resnick <[email-masked]>
From: Marcia Beaulieu <[email-masked]>
Subject: 45th IETF: IMAPEXT
Cc: Keith Moore <[email-masked]>,
         Pätrik
   Faltström <[email-masked]>

IMAPEXT is scheduled as follows:

	Thursday, July 15 at 1300-1500
		other groups scheduled at that time: roamops, issll, 
ldapext, saag,
			mobileip, iptel

Please submit an agenda for this meeting as soon as possible to
[email-masked]
The deadline for submitting an agenda is July 1 at 1200 ET.

Thanks,

Marcia

--- end forwarded text

-- 
Pete Resnick <mailto:[email-masked]>
Eudora Engineering - QUALCOMM Incorporated
Ph: (217)337-6377 or (619)651-4478, Fax: (619)651-1102

From: "Glenn Parsons" <[email-masked]>
To: "'Dmitry Rubinstein'" <[email-masked]>
Cc: [email-masked], "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Oslo IETF meeting
Date: Tue, 22 Jun 1999 11:47:50 -0500
Sender: [email-masked]

Dmitry,

> I'd like to know what will be the agenda of the WG(s), that will
> deal with IMAP issues. In particular I'd like to know whether
> the following two drafts are going to be discussed:
> 
> 2. draft-ema-vpim-imap-00 (VPIM over IMAP)
> 
I hope to have a slightly updated version of this available soon based on
the various comments to date.  The goal of this draft is to list the
possible options to solve various requirements we have noted for retrieving
voice messages over IMAP.

> I'd appreciate it if whoever is preparing the agenda (assuming
> such preparations are being done) will tip us on the major
> points that are to be discussed. The agendas are only due within
> two weeks and will probably be written on the last night, but
> still...
> 
At previous meetings, the view was that this was sufficiently different that
we should create another list (IMAP-Voice) and have it discussed in a
different IETF session.  

I'd be happy to discuss it in IMAPEXT if folks wanted to talk about this and
revisit if it should be in the charter.

We will likely mention this draft in passing in the VPIM meeting -- though
we won't have time to look at any details.

Cheers,
Glenn.

Date: Wed, 02 Jun 1999 18:00:09 -0400
From: Cyrus Daboo <[email-masked]>
To: "Mike Gahrns (Platinum)" <[email-masked]>, [email-masked], [email-masked]
Subject: RE: Proposed WG worklist from March IMC
Originator-Info: login-id=daboo; server=imap.cyrusoft.com:431
Sender: [email-masked]

--On Wednesday, June 02, 1999, 2:38 PM -0700 "Mike Gahrns (Platinum)"
<[email-masked]> wrote:

> I believe the original proposed charter for the IMAPEXT WG was to cover
> SORT, Annotate and ACLs.  I did not put together that list, but it
> sounds look a good list to me.  

The last charter we had was the one posted to the list by John Myers (I've
quoted it below - obviously the target dates are wrong). This needs to be
taken over by the WG chair (Pete?) and processed through the usual IETF
channels, after discussion/approval on this list.

> From: John Gardiner Myers <[email-masked]>
> To: [email-masked]
> Subject: Proposed charter
> Date-Sent: 08/06/98, 3:17 PM -0700
> 
> To remind people, the proposed charter is as follows:
> 
> Chair(s):
> 
> TBD
> 
> Mailing Lists:
> 
> General discussion: [email-masked]
> To Subscribe: [email-masked]
> Archive: http://www.imc.org/ietf-imapext/
> 
> 
> Description of Working Group:
> 
> The IETF IMAP extensions Working Group shall revise and publish
> standards-track extensions to IMAP4 for performing the following
> functions:
> 
> 1) Access Control Lists
> 2) Sorting
> 3) Threading
> 4) Message-level annotations
> 
> Revising the base IMAP4rev1 specification is out of the scope of this
> WG.
> 
> 
> Goals and Milestones:
> 
> August 98       Approve charter
> 
> Dec 98          Submit revised ACL spec to IESG
> 
> Mar 99          Submit revised Sorting/Threading spec(s) to IESG
> 
> August 99       Submit annotation spec to IESG

--On Friday, April 10, 1998, 1:48 PM -0700 John Gardiner Myers
<[email-masked]> wrote:

> I'll propose the following addition to the charter:
> 
>	 Revising the base IMAP4rev1 spec is out of the scope of this WG.

--
Cyrus

From: "Mike Gahrns (Platinum)" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: RE: Proposed WG worklist from March IMC
Date: Wed, 2 Jun 1999 14:38:03 -0700
content-class: urn:content-classes:message/mail
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_2009A_01BEAD05.8609BF20
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

I believe the original proposed charter for the IMAPEXT WG was to cover
SORT, Annotate and ACLs.  I did not put together that list, but it
sounds look a good list to me.  

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: Wednesday, June 02, 1999 2:27 PM
To: [email-masked]
Subject: Proposed WG worklist from March IMC

I recall someone at the March IMAP interop putting together a list of
candidate items for the WG. I thought it was Mike G., but he claims
no knowledge of this. Would the guilty party please step forward with
that list?

------=_NextPart_000_2009A_01BEAD05.8609BF20
Content-Type: application/ms-tnef;
	name="winmail.dat"
Content-Transfer-Encoding: base64

------=_NextPart_000_2009A_01BEAD05.8609BF20--

Date: Wed, 2 Jun 1999 15:27:21 -0600
From: [email-masked]
Subject: Proposed WG worklist from March IMC
To: [email-masked]
Sender: [email-masked]

I recall someone at the March IMAP interop putting together a list of
candidate items for the WG. I thought it was Mike G., but he claims
no knowledge of this. Would the guilty party please step forward with
that list?

From: "Mike Gahrns (Platinum)" <[email-masked]>
To: "Cyrus Daboo" <[email-masked]>, "Pete Resnick" <[email-masked]>, <[email-masked]>
Subject: RE: IMAPEXT at Oslo?
Date: Wed, 2 Jun 1999 11:22:21 -0700
content-class: urn:content-classes:message/mail
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_1EE12_01BEACEA.2F828440
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

I agree whole heartily with Cyrus here.

There have been several informal discussions off the list in regards to
SORT.  As  Cyrus mentions, there are a couple of proposals that are
close to being issued as drafts.  A face to face meeting in Oslo will
prove extremely beneficial, as in the early stages of many proposals, a
lot more can be accomplished quicker through face to face discussions
rather than lengthy email exchanges.

At the last IMC interop event in San Jose a few months ago, I think the
general consensus of the room was that there should be an IMAPEXT WG at
the next meeting.

Although not entirely related to the orginal proposed charter of the WG,
there was a lot of discussion a few months back on the regular IMAP list
regarding LIST Extensions/Childmailbox, etc..  If there is an IMAPEXT
WG, a lot of the right people will likely be at OSLO to further discuss
this.

-----Original Message-----
From: Cyrus Daboo [mailto:[email-masked]]
Sent: Wednesday, June 02, 1999 10:22 AM
To: Pete Resnick; [email-masked]
Subject: Re: IMAPEXT at Oslo?

--On Wednesday, June 02, 1999, 10:11 AM -0700 Pete Resnick
<[email-masked]> wrote:

> There hasn't been a whole lot of action here to charter a WG or have 
> discussions. Do we want to BOF at Oslo for the purpose of chartering 
> a WG? What's the state of affairs? Deadlines are looming.

I think we should have a meeting. Ideally we should get the WG setup and
running before then so we can do 'real work' in Oslo, though a BOF would
be
just as good. What's currently holding up chartering of this group? I
thought we had a charter bashed out ready to go? Can we make sure a
request
goes in to the ADs for a meeting in Oslo (be it WG or BOF)?

I have a sort draft that is being reviewed by co-authors right now, and
hopefully we can get this out to the list soon. There will be some
serious
debate about this and a face-to-face in Oslo would proove extermely
beneficial IMHO.

--
Cyrus

------=_NextPart_000_1EE12_01BEACEA.2F828440
Content-Type: application/ms-tnef;
	name="winmail.dat"
Content-Transfer-Encoding: base64

------=_NextPart_000_1EE12_01BEACEA.2F828440--

Date: Wed, 02 Jun 1999 13:22:22 -0400
From: Cyrus Daboo <[email-masked]>
To: Pete Resnick <[email-masked]>, [email-masked]
Subject: Re: IMAPEXT at Oslo?
Originator-Info: login-id=daboo; server=imap.cyrusoft.com:431
Sender: [email-masked]

--On Wednesday, June 02, 1999, 10:11 AM -0700 Pete Resnick
<[email-masked]> wrote:

> There hasn't been a whole lot of action here to charter a WG or have 
> discussions. Do we want to BOF at Oslo for the purpose of chartering 
> a WG? What's the state of affairs? Deadlines are looming.

I think we should have a meeting. Ideally we should get the WG setup and
running before then so we can do 'real work' in Oslo, though a BOF would be
just as good. What's currently holding up chartering of this group? I
thought we had a charter bashed out ready to go? Can we make sure a request
goes in to the ADs for a meeting in Oslo (be it WG or BOF)?

I have a sort draft that is being reviewed by co-authors right now, and
hopefully we can get this out to the list soon. There will be some serious
debate about this and a face-to-face in Oslo would proove extermely
beneficial IMHO.

--
Cyrus

Date: Wed, 2 Jun 1999 10:11:57 -0700
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: IMAPEXT at Oslo?
Sender: [email-masked]

There hasn't been a whole lot of action here to charter a WG or have 
discussions. Do we want to BOF at Oslo for the purpose of chartering 
a WG? What's the state of affairs? Deadlines are looming.

pr
-- 
Pete Resnick <mailto:[email-masked]>
Eudora Engineering - QUALCOMM Incorporated
Ph: (217)337-6377 or (619)651-4478, Fax: (619)651-1102