Subject: Re: IMAPExt discussion at 44th IETF
From: Barry Leiba <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Tue, 30 Mar 1999 15:49:44 -0500

Arnaud Taddei says...
> I don't know if this should be discussed here or if it is the right

First, let's please *not* start discussing things in two places.  One thing
is clear: the IMAPEXT working group does not have this issue on its charter,
so let's keep any discussion of this on the IMAP mailing list.  Please remove
the cc for imapext from any replies to this.

> timing for that but some long time ago it was discussed the possibility
> to have a CLIENTINFO command. I believe that this command doesn't exist
> for IMAP. Although I can see some drawbacks, it would be extremely
> useful from a service point of view to capture a string which would
> declare what client from which platform is connecting to the IMAP
> server.

There's an obsolete draft by Tim Showalter for the "ID" command, which 
allows a client to announce its name, vendor, version number, and such to 
the server and get the server's corresponding information in return.  In
fact, my server implements this, just because it was trivial to do, but I
know of no other server or client that does.

There simply wasn't enough interest in it to carry it further, and people
were worried (rightly so) that some implementations would use this to
tailor their behaviour to certain other implementations, at the expense
of interoperability.

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

From: "Barry Leiba" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: IMAPExt discussion at 44th IETF
Date: Tue, 30 Mar 1999 15:48:06 -0500
Sender: [email-masked]

Arnaud Taddei says...
> I don't know if this should be discussed here or if it is the right

First, let's please *not* start discussing things in two places.  One thing
is clear: the IMAPEXT working group does not have this issue on its charter,
so let's keep any discussion of this on the IMAP mailing list.  Please remove
the cc for imapext from any replies to this.

> timing for that but some long time ago it was discussed the possibility
> to have a CLIENTINFO command. I believe that this command doesn't exist
> for IMAP. Although I can see some drawbacks, it would be extremely
> useful from a service point of view to capture a string which would
> declare what client from which platform is connecting to the IMAP
> server.

There's an obsolete draft by Tim Showalter for the "ID" command, which 
allows a client to announce its name, vendor, version number, and such to 
the server and get the server's corresponding information in return.  In
fact, my server implements this, just because it was trivial to do, but I
know of no other server or client that does.

There simply wasn't enough interest in it to carry it further, and people
were worried (rightly so) that some implementations would use this to
tailor their behaviour to certain other implementations, at the expense
of interoperability.

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

From: "Barry Leiba" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: IMAPExt discussion at 44th IETF
Date: Tue, 30 Mar 1999 15:47:57 -0500
Sender: [email-masked]

Arnaud Taddei says...
> I don't know if this should be discussed here or if it is the right

First, let's please *not* start discussing things in two places.  One thing
is clear: the IMAPEXT working group does not have this issue on its charter,
so let's keep any discussion of this on the IMAP mailing list.  Please remove
the cc for imapext from any replies to this.

> timing for that but some long time ago it was discussed the possibility
> to have a CLIENTINFO command. I believe that this command doesn't exist
> for IMAP. Although I can see some drawbacks, it would be extremely
> useful from a service point of view to capture a string which would
> declare what client from which platform is connecting to the IMAP
> server.

There's an obsolete draft by Tim Showalter for the "ID" command, which 
allows a client to announce its name, vendor, version number, and such to 
the server and get the server's corresponding information in return.  In
fact, my server implements this, just because it was trivial to do, but I
know of no other server or client that does.

There simply wasn't enough interest in it to carry it further, and people
were worried (rightly so) that some implementations would use this to
tailor their behaviour to certain other implementations, at the expense
of interoperability.

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

From: "Barry Leiba" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: IMAPExt discussion at 44th IETF
Date: Tue, 30 Mar 1999 15:47:54 -0500
Sender: [email-masked]

Arnaud Taddei says...
> I don't know if this should be discussed here or if it is the right

First, let's please *not* start discussing things in two places.  One thing
is clear: the IMAPEXT working group does not have this issue on its charter,
so let's keep any discussion of this on the IMAP mailing list.  Please remove
the cc for imapext from any replies to this.

> timing for that but some long time ago it was discussed the possibility
> to have a CLIENTINFO command. I believe that this command doesn't exist
> for IMAP. Although I can see some drawbacks, it would be extremely
> useful from a service point of view to capture a string which would
> declare what client from which platform is connecting to the IMAP
> server.

There's an obsolete draft by Tim Showalter for the "ID" command, which 
allows a client to announce its name, vendor, version number, and such to 
the server and get the server's corresponding information in return.  In
fact, my server implements this, just because it was trivial to do, but I
know of no other server or client that does.

There simply wasn't enough interest in it to carry it further, and people
were worried (rightly so) that some implementations would use this to
tailor their behaviour to certain other implementations, at the expense
of interoperability.

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

From: "Barry Leiba" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: IMAPExt discussion at 44th IETF
Date: Tue, 30 Mar 1999 15:47:44 -0500
Sender: [email-masked]

Arnaud Taddei says...
> I don't know if this should be discussed here or if it is the right

First, let's please *not* start discussing things in two places.  One thing
is clear: the IMAPEXT working group does not have this issue on its charter,
so let's keep any discussion of this on the IMAP mailing list.  Please remove
the cc for imapext from any replies to this.

> timing for that but some long time ago it was discussed the possibility
> to have a CLIENTINFO command. I believe that this command doesn't exist
> for IMAP. Although I can see some drawbacks, it would be extremely
> useful from a service point of view to capture a string which would
> declare what client from which platform is connecting to the IMAP
> server.

There's an obsolete draft by Tim Showalter for the "ID" command, which 
allows a client to announce its name, vendor, version number, and such to 
the server and get the server's corresponding information in return.  In
fact, my server implements this, just because it was trivial to do, but I
know of no other server or client that does.

There simply wasn't enough interest in it to carry it further, and people
were worried (rightly so) that some implementations would use this to
tailor their behaviour to certain other implementations, at the expense
of interoperability.

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

Date: Tue, 30 Mar 1999 22:36:04 +0200
From: Arnaud Taddei <[email-masked]>
To: Barry Leiba <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: IMAPExt discussion at 44th IETF
Sender: [email-masked]

I don't know if this should be discussed here or if it is the right
timing for that but some long time ago it was discussed the possibility
to have a CLIENTINFO command. I believe that this command doesn't exist
for IMAP. Although I can see some drawbacks, it would be extremely
useful from a service point of view to capture a string which would
declare what client from which platform is connecting to the IMAP
server.

There are rather clear needs for user support and statistics/service
deployment point of view. Any chance to see this as an IMAP extension?
Is it that terrible?

Barry Leiba wrote:
> 
> Those of us who were at the 44th IETF in Minneapolis got together on
> Wednesday afternoon to discuss some IMAP extensions issues and to get ready
> to get the IMAPEXT working group started for real.  I took some notes at
> the gathering, and I'm posting them here to start some discussion.  They
> aren't terribly detailed, so details will have to be filled in during the
> discussion.  I can also post, if someone would like, the notes my Mark
> Pustilnik and Chris Newman, proposing (and counter-proposing) how the
> extended SELECT, referred to below, should work.
> 
> Of course, people should feel free to correct errors and fill in gaps in my
> notes, as appropriate.
> 
> Barry Leiba, Internet Messaging Technology  ([email-masked])
> http://www.research.ibm.com/people/l/leiba
> 
> --------
> IMAP Ext
> --------
> Goal: start IMAPext activity in Oslo.
> Work items: Sort, Thread, ACL, Annotate  (not I18n)
> 
> Authors...
> Annotate: Chris -transfer to-> Cyrus & Steve
> Sort: Mark C
> Sorted view: ?  ask Mark P
> Thread: Mark C has ideas
> ACL: ?
> 
> Discussion of Mark P/Chris proposal.
>   Server advertises capability.
>   Optional sort & search parameters on select/examine.
>   Sequence numbers now reflect sorted order -- client behaves as usual.
>   New/changed server responses (MOVE, REMOVE, NEW, VIEW?).
> 1. Should client be told about messages outside view?
> 2. Should view change or be static (add only)?
> 3. How does this dovetail (or not) with Mark C's sort & view?
> 
> Discussion of threads
> 1. How to represent the tree/graph
> 2. Multiple parents are difficult.
> 3. Does this interact with view?
> 4. Is it sufficient to give, for each message, the UID of the nearest
>    parent that's in the view, and the number of missing levels (not in view)?
> 
> Thread experimental?
> Limit thread to simple hierarchy (no multi-parent)?
> Can we do sort *before* thread, without worrying too much about interaction?
> Thread on view: "Show me the treeness of this set" (Pete R)
> 
> Consensus:
> Select extension is good... go ahead with it.
> Continue working on thread -- orthogonal.
> Threading, using additional fetch attributes -- investigate.
> 
> Pete prompts Mark P to draft something & post to mailing list.  Alexei is
> second choice, maybe Cyrus.
> -----------------------------------------------------------------

-- 
------------------------------------------------------------
Arnaud Taddei           tel:  +41 22 767 9349
IT Division  31 1-016   fax:  +41 22 767 7155
CERN                    mail: [email-masked]
CH-1211 Geneve 23       URL:  http://wwwinfo.cern.ch/~taddei
------------------------------------------------------------

From: Barry Leiba <[email-masked]>
Date: Tue, 30 Mar 1999 10:06:14 -0500
To: [email-masked]
Subject: IMAPExt discussion at 44th IETF
Sender: [email-masked]

Those of us who were at the 44th IETF in Minneapolis got together on 
Wednesday afternoon to discuss some IMAP extensions issues and to get ready
to get the IMAPEXT working group started for real.  I took some notes at 
the gathering, and I'm posting them here to start some discussion.  They 
aren't terribly detailed, so details will have to be filled in during the 
discussion.  I can also post, if someone would like, the notes my Mark 
Pustilnik and Chris Newman, proposing (and counter-proposing) how the 
extended SELECT, referred to below, should work.

Of course, people should feel free to correct errors and fill in gaps in my
notes, as appropriate.

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

--------
IMAP Ext
--------
Goal: start IMAPext activity in Oslo.
Work items: Sort, Thread, ACL, Annotate  (not I18n)

Authors...
Annotate: Chris -transfer to-> Cyrus & Steve
Sort: Mark C
Sorted view: ?  ask Mark P
Thread: Mark C has ideas
ACL: ?

Discussion of Mark P/Chris proposal.
  Server advertises capability.
  Optional sort & search parameters on select/examine.
  Sequence numbers now reflect sorted order -- client behaves as usual.
  New/changed server responses (MOVE, REMOVE, NEW, VIEW?).
1. Should client be told about messages outside view?
2. Should view change or be static (add only)?
3. How does this dovetail (or not) with Mark C's sort & view?

Discussion of threads
1. How to represent the tree/graph
2. Multiple parents are difficult.
3. Does this interact with view?
4. Is it sufficient to give, for each message, the UID of the nearest
   parent that's in the view, and the number of missing levels (not in view)?

Thread experimental?
Limit thread to simple hierarchy (no multi-parent)?
Can we do sort *before* thread, without worrying too much about interaction?
Thread on view: "Show me the treeness of this set" (Pete R)

Consensus:
Select extension is good... go ahead with it.
Continue working on thread -- orthogonal.
Threading, using additional fetch attributes -- investigate.

Pete prompts Mark P to draft something & post to mailing list.  Alexei is 
second choice, maybe Cyrus.
-----------------------------------------------------------------

From: Barry Leiba <[email-masked]>
Date: Tue, 30 Mar 1999 15:49:44 -0500
To: [email-masked]
Subject: Re: IMAPExt discussion at 44th IETF
Cc: [email-masked]
Sender: [email-masked]

Arnaud Taddei says...
> I don't know if this should be discussed here or if it is the right

First, let's please *not* start discussing things in two places.  One thing
is clear: the IMAPEXT working group does not have this issue on its charter,
so let's keep any discussion of this on the IMAP mailing list.  Please remove
the cc for imapext from any replies to this.

> timing for that but some long time ago it was discussed the possibility
> to have a CLIENTINFO command. I believe that this command doesn't exist
> for IMAP. Although I can see some drawbacks, it would be extremely
> useful from a service point of view to capture a string which would
> declare what client from which platform is connecting to the IMAP
> server.

There's an obsolete draft by Tim Showalter for the "ID" command, which 
allows a client to announce its name, vendor, version number, and such to 
the server and get the server's corresponding information in return.  In
fact, my server implements this, just because it was trivial to do, but I
know of no other server or client that does.

There simply wasn't enough interest in it to carry it further, and people
were worried (rightly so) that some implementations would use this to
tailor their behaviour to certain other implementations, at the expense
of interoperability.

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

From: "Barry Leiba" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: IMAPExt discussion at 44th IETF
Date: Tue, 30 Mar 1999 15:48:06 -0500
Sender: [email-masked]

Arnaud Taddei says...
> I don't know if this should be discussed here or if it is the right

First, let's please *not* start discussing things in two places.  One thing
is clear: the IMAPEXT working group does not have this issue on its charter,
so let's keep any discussion of this on the IMAP mailing list.  Please remove
the cc for imapext from any replies to this.

> timing for that but some long time ago it was discussed the possibility
> to have a CLIENTINFO command. I believe that this command doesn't exist
> for IMAP. Although I can see some drawbacks, it would be extremely
> useful from a service point of view to capture a string which would
> declare what client from which platform is connecting to the IMAP
> server.

There's an obsolete draft by Tim Showalter for the "ID" command, which 
allows a client to announce its name, vendor, version number, and such to 
the server and get the server's corresponding information in return.  In
fact, my server implements this, just because it was trivial to do, but I
know of no other server or client that does.

There simply wasn't enough interest in it to carry it further, and people
were worried (rightly so) that some implementations would use this to
tailor their behaviour to certain other implementations, at the expense
of interoperability.

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

From: "Barry Leiba" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: IMAPExt discussion at 44th IETF
Date: Tue, 30 Mar 1999 15:47:57 -0500
Sender: [email-masked]

Arnaud Taddei says...
> I don't know if this should be discussed here or if it is the right

First, let's please *not* start discussing things in two places.  One thing
is clear: the IMAPEXT working group does not have this issue on its charter,
so let's keep any discussion of this on the IMAP mailing list.  Please remove
the cc for imapext from any replies to this.

> timing for that but some long time ago it was discussed the possibility
> to have a CLIENTINFO command. I believe that this command doesn't exist
> for IMAP. Although I can see some drawbacks, it would be extremely
> useful from a service point of view to capture a string which would
> declare what client from which platform is connecting to the IMAP
> server.

There's an obsolete draft by Tim Showalter for the "ID" command, which 
allows a client to announce its name, vendor, version number, and such to 
the server and get the server's corresponding information in return.  In
fact, my server implements this, just because it was trivial to do, but I
know of no other server or client that does.

There simply wasn't enough interest in it to carry it further, and people
were worried (rightly so) that some implementations would use this to
tailor their behaviour to certain other implementations, at the expense
of interoperability.

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

From: "Barry Leiba" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: IMAPExt discussion at 44th IETF
Date: Tue, 30 Mar 1999 15:47:54 -0500
Sender: [email-masked]

Arnaud Taddei says...
> I don't know if this should be discussed here or if it is the right

First, let's please *not* start discussing things in two places.  One thing
is clear: the IMAPEXT working group does not have this issue on its charter,
so let's keep any discussion of this on the IMAP mailing list.  Please remove
the cc for imapext from any replies to this.

> timing for that but some long time ago it was discussed the possibility
> to have a CLIENTINFO command. I believe that this command doesn't exist
> for IMAP. Although I can see some drawbacks, it would be extremely
> useful from a service point of view to capture a string which would
> declare what client from which platform is connecting to the IMAP
> server.

There's an obsolete draft by Tim Showalter for the "ID" command, which 
allows a client to announce its name, vendor, version number, and such to 
the server and get the server's corresponding information in return.  In
fact, my server implements this, just because it was trivial to do, but I
know of no other server or client that does.

There simply wasn't enough interest in it to carry it further, and people
were worried (rightly so) that some implementations would use this to
tailor their behaviour to certain other implementations, at the expense
of interoperability.

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

From: "Barry Leiba" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: IMAPExt discussion at 44th IETF
Date: Tue, 30 Mar 1999 15:47:44 -0500
Sender: [email-masked]

Arnaud Taddei says...
> I don't know if this should be discussed here or if it is the right

First, let's please *not* start discussing things in two places.  One thing
is clear: the IMAPEXT working group does not have this issue on its charter,
so let's keep any discussion of this on the IMAP mailing list.  Please remove
the cc for imapext from any replies to this.

> timing for that but some long time ago it was discussed the possibility
> to have a CLIENTINFO command. I believe that this command doesn't exist
> for IMAP. Although I can see some drawbacks, it would be extremely
> useful from a service point of view to capture a string which would
> declare what client from which platform is connecting to the IMAP
> server.

There's an obsolete draft by Tim Showalter for the "ID" command, which 
allows a client to announce its name, vendor, version number, and such to 
the server and get the server's corresponding information in return.  In
fact, my server implements this, just because it was trivial to do, but I
know of no other server or client that does.

There simply wasn't enough interest in it to carry it further, and people
were worried (rightly so) that some implementations would use this to
tailor their behaviour to certain other implementations, at the expense
of interoperability.

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

Date: Tue, 30 Mar 1999 22:36:04 +0200
From: Arnaud Taddei <[email-masked]>
To: Barry Leiba <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: IMAPExt discussion at 44th IETF
Sender: [email-masked]

I don't know if this should be discussed here or if it is the right
timing for that but some long time ago it was discussed the possibility
to have a CLIENTINFO command. I believe that this command doesn't exist
for IMAP. Although I can see some drawbacks, it would be extremely
useful from a service point of view to capture a string which would
declare what client from which platform is connecting to the IMAP
server.

There are rather clear needs for user support and statistics/service
deployment point of view. Any chance to see this as an IMAP extension?
Is it that terrible?

Barry Leiba wrote:
> 
> Those of us who were at the 44th IETF in Minneapolis got together on
> Wednesday afternoon to discuss some IMAP extensions issues and to get ready
> to get the IMAPEXT working group started for real.  I took some notes at
> the gathering, and I'm posting them here to start some discussion.  They
> aren't terribly detailed, so details will have to be filled in during the
> discussion.  I can also post, if someone would like, the notes my Mark
> Pustilnik and Chris Newman, proposing (and counter-proposing) how the
> extended SELECT, referred to below, should work.
> 
> Of course, people should feel free to correct errors and fill in gaps in my
> notes, as appropriate.
> 
> Barry Leiba, Internet Messaging Technology  ([email-masked])
> http://www.research.ibm.com/people/l/leiba
> 
> --------
> IMAP Ext
> --------
> Goal: start IMAPext activity in Oslo.
> Work items: Sort, Thread, ACL, Annotate  (not I18n)
> 
> Authors...
> Annotate: Chris -transfer to-> Cyrus & Steve
> Sort: Mark C
> Sorted view: ?  ask Mark P
> Thread: Mark C has ideas
> ACL: ?
> 
> Discussion of Mark P/Chris proposal.
>   Server advertises capability.
>   Optional sort & search parameters on select/examine.
>   Sequence numbers now reflect sorted order -- client behaves as usual.
>   New/changed server responses (MOVE, REMOVE, NEW, VIEW?).
> 1. Should client be told about messages outside view?
> 2. Should view change or be static (add only)?
> 3. How does this dovetail (or not) with Mark C's sort & view?
> 
> Discussion of threads
> 1. How to represent the tree/graph
> 2. Multiple parents are difficult.
> 3. Does this interact with view?
> 4. Is it sufficient to give, for each message, the UID of the nearest
>    parent that's in the view, and the number of missing levels (not in view)?
> 
> Thread experimental?
> Limit thread to simple hierarchy (no multi-parent)?
> Can we do sort *before* thread, without worrying too much about interaction?
> Thread on view: "Show me the treeness of this set" (Pete R)
> 
> Consensus:
> Select extension is good... go ahead with it.
> Continue working on thread -- orthogonal.
> Threading, using additional fetch attributes -- investigate.
> 
> Pete prompts Mark P to draft something & post to mailing list.  Alexei is
> second choice, maybe Cyrus.
> -----------------------------------------------------------------

-- 
------------------------------------------------------------
Arnaud Taddei           tel:  +41 22 767 9349
IT Division  31 1-016   fax:  +41 22 767 7155
CERN                    mail: [email-masked]
CH-1211 Geneve 23       URL:  http://wwwinfo.cern.ch/~taddei
------------------------------------------------------------

From: Barry Leiba <[email-masked]>
Date: Tue, 30 Mar 1999 10:06:14 -0500
To: [email-masked]
Subject: IMAPExt discussion at 44th IETF
Sender: [email-masked]

Those of us who were at the 44th IETF in Minneapolis got together on 
Wednesday afternoon to discuss some IMAP extensions issues and to get ready
to get the IMAPEXT working group started for real.  I took some notes at 
the gathering, and I'm posting them here to start some discussion.  They 
aren't terribly detailed, so details will have to be filled in during the 
discussion.  I can also post, if someone would like, the notes my Mark 
Pustilnik and Chris Newman, proposing (and counter-proposing) how the 
extended SELECT, referred to below, should work.

Of course, people should feel free to correct errors and fill in gaps in my
notes, as appropriate.

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

--------
IMAP Ext
--------
Goal: start IMAPext activity in Oslo.
Work items: Sort, Thread, ACL, Annotate  (not I18n)

Authors...
Annotate: Chris -transfer to-> Cyrus & Steve
Sort: Mark C
Sorted view: ?  ask Mark P
Thread: Mark C has ideas
ACL: ?

Discussion of Mark P/Chris proposal.
  Server advertises capability.
  Optional sort & search parameters on select/examine.
  Sequence numbers now reflect sorted order -- client behaves as usual.
  New/changed server responses (MOVE, REMOVE, NEW, VIEW?).
1. Should client be told about messages outside view?
2. Should view change or be static (add only)?
3. How does this dovetail (or not) with Mark C's sort & view?

Discussion of threads
1. How to represent the tree/graph
2. Multiple parents are difficult.
3. Does this interact with view?
4. Is it sufficient to give, for each message, the UID of the nearest
   parent that's in the view, and the number of missing levels (not in view)?

Thread experimental?
Limit thread to simple hierarchy (no multi-parent)?
Can we do sort *before* thread, without worrying too much about interaction?
Thread on view: "Show me the treeness of this set" (Pete R)

Consensus:
Select extension is good... go ahead with it.
Continue working on thread -- orthogonal.
Threading, using additional fetch attributes -- investigate.

Pete prompts Mark P to draft something & post to mailing list.  Alexei is 
second choice, maybe Cyrus.
-----------------------------------------------------------------