headers
Chris Newman | 3 Aug 2000 14:29

Minutes from IMAPEXT WG

Here are the raw minutes from the WG meeting in Pittsburgh.  Please speak 
up if I got something wrong, or missed something

IMAP extensions WG 2000-31-07 15:30

Chair: Pete Resnick
Minute Taker: Chris Newman

Chair says he will have more time to keep working group running on 
September 1.

VIEW draft
----------
One comment that the new flag-based model looks good.

Barry suggested that the extended SELECT command have the VIEW SET argument 
put in parens.
Agreed.

Alexey was unsure if we had rough concensus on the issue of COPY perserving 
VIEW order. Rough concensus that we did.

Question about view search response: why is it "* VIEW SEARCH" instead of 
"* SEARCH".
There is preference at the meeting to remove VIEW from the response to 
match UID SEARCH model.

Note "* VIEW SEARCH" might use a "0" to indicate a match outside of view.
Not desirable since it could put extra load on server.
(Continue reading)

Permalink | Reply | 56 comments |
headers
Mark Crispin | 4 Aug 2000 00:24

re: Minutes from IMAPEXT WG

> Long discussion about separate "SORT" and "THREAD" commands.  Rough
> concensus that we want to move "SORT" and "THREAD" to historical, and that
> WG will only design VIEW=SORT and VIEW=THREAD for use within the VIEW
> framework.

I am completely opposed to this proposal.

The functionality of VIEW should be limited to a framework for dealing with a
subset of messages in a mailbox.  Adding functionality that is only accessible
via VIEW is not the way to go.

I do not understand the purpose of this proposal.  It does not convey any
benefit that I can discern.  It removes functionality and severely impairs the
usefulness of VIEW for us.  It effectively reduces VIEW to little more than a
more complex mechanism of sorting and threading than we already have.

We need sorting and threading that is decoupled from VIEW; to be able to
SORT/THREAD one set of messages while VIEWing a different set.
Permalink | Reply | 55 comments |
headers
Pete Resnick | 4 Aug 2000 01:36

Re: SORT, THREAD, and VIEW

Please, change the subject if this is issue specific rather than 
about the minutes per se. Other folks, please respond to this 
message; I will keep the entire text of Mark's message in tact here.

On 8/3/00 at 3:24 PM -0700, Mark Crispin wrote:

>>Long discussion about separate "SORT" and "THREAD" commands.  Rough 
>>concensus that we want to move "SORT" and "THREAD" to historical, 
>>and that WG will only design VIEW=SORT and VIEW=THREAD for use 
>>within the VIEW framework.
>
>I am completely opposed to this proposal.
>
>The functionality of VIEW should be limited to a framework for dealing with a
>subset of messages in a mailbox.  Adding functionality that is only accessible
>via VIEW is not the way to go.
>
>I do not understand the purpose of this proposal.  It does not 
>convey any benefit that I can discern.

Please explain *why* you think this is "not the way to go". Just 
saying that it is not will not suffice as an argument.

The consensus of the room was (from my understanding of it) that the 
benefits were:

1. There will be less confusion in the long run if there aren't a new 
set of commands with similar names that do different things. (One 
comment was that the current text would disallow a command called 
"SORT2" because it starts with the same characters as the older SORT
(Continue reading)

Permalink | Reply | 54 comments |
headers
Internet-Drafts | 8 Aug 2000 16:17
Picon
Favicon

I-D ACTION:draft-ietf-imapext-thread-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF.

	Title		: INTERNET MESSAGE ACCESS PROTOCOL - THREAD EXTENSION
	Author(s)	: M. Crispin
	Filename	: draft-ietf-imapext-thread-00.txt
	Pages		: 7
	Date		: 27-Jul-00
	
This document describes the server-based threading extension to the
IMAP4rev1 protocol.  This extension provides substantial performance
improvements for IMAP clients which offer threaded views.
A server which supports this extension indicates this with more or
more capability names consisting of 'THREAD-' followed by a supported
threading algorithm name as described in this document.  This
provides for future upwards-compatible extensions.

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

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

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

Internet-Drafts can also be obtained by e-mail.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Internet-Drafts | 8 Aug 2000 16:17
Picon
Favicon

I-D ACTION:draft-ietf-imapext-regex-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF.

	Title		: IMAP Regular Expressions SEARCH Extension
	Author(s)	: R. Gellens
	Filename	: draft-ietf-imapext-regex-00.txt
	Pages		: 6
	Date		: 27-Jul-00
	
This memo describes a regular-expression search facility for the
[IMAP] protocol.
A server advertises support for this facility by the capability name
REGEX.

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

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

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

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

Send a message to:
	mailserv <at> ietf.org.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jon Miner | 8 Aug 2000 17:26
Picon

Re: I-D ACTION:draft-ietf-imapext-thread-00.txt

Just wanted to note (as has probably already been noted) that message
threading is better based on the "In-Reply-To:" header and the
"References:" header.  Using these fields makes subthreading much
easier.  This didn't seem to be mentioned in the document.

thanks,

jon

* Internet-Drafts <at> ietf.org (Internet-Drafts <at> ietf.org) [000808 09:35]:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF.
> 
> 	Title		: INTERNET MESSAGE ACCESS PROTOCOL - THREAD EXTENSION
> 	Author(s)	: M. Crispin
> 	Filename	: draft-ietf-imapext-thread-00.txt
> 	Pages		: 7
> 	Date		: 27-Jul-00
> 	
> This document describes the server-based threading extension to the
> IMAP4rev1 protocol.  This extension provides substantial performance
> improvements for IMAP clients which offer threaded views.
> A server which supports this extension indicates this with more or
> more capability names consisting of 'THREAD-' followed by a supported
> threading algorithm name as described in this document.  This
> provides for future upwards-compatible extensions.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-imapext-thread-00.txt
>
(Continue reading)

Permalink | Reply | 3 comments |
headers
Mark Crispin | 8 Aug 2000 18:44

Re: I-D ACTION:draft-ietf-imapext-thread-00.txt

On Tue, 8 Aug 2000 10:26:23 -0500, Jon Miner wrote:
> Just wanted to note (as has probably already been noted) that message
> threading is better based on the "In-Reply-To:" header and the
> "References:" header.  Using these fields makes subthreading much
> easier.  This didn't seem to be mentioned in the document.

We are working on the specification (and reference implementation) for the
REFERENCES algorithm and have been for the past month.  Please be patient.

What you should look at in the current document is the framework provided
(e.g. new algorithms can be added at any time, representation of trees, etc.)
Permalink | Reply | 2 comments |
headers
fred | 10 Aug 2000 15:02
Picon
Favicon

draft-ietf-imapext-thread-00.txt

I notice that you recently posted a new internet draft. A document that
might be worth reading is http://www.ietf.org/ID-nits.html

This document was put together by members of the IESG to help the
community know what are the most common problems that we see in
documents, whether from working groups or individual submissions, and
pro-actively avoid them.

This is an automatic email; please don't conclude that I have
discovered something awful about your draft, as I haven't even read it
yet. Rather, I'm just letting you know that there is a list of common
issues that get raised over and over again in IESG reviews, and I'd
like to save you the hassle by letting you see for yourself whether any
of them apply.

Let me know if you have any questions I can answer.
Permalink | Reply | 0 comments |
headers
Paul Overell | 11 Aug 2000 18:47

Re: I-D ACTION:draft-ietf-imapext-thread-00.txt

In article <MailManager.965753074.4273.mrc <at> Ikkoku-Kan.Panda.COM>, Mark
Crispin <MRC <at> cac.washington.edu> writes
>On Tue, 8 Aug 2000 10:26:23 -0500, Jon Miner wrote:
>> Just wanted to note (as has probably already been noted) that message
>> threading is better based on the "In-Reply-To:" header and the
>> "References:" header.  Using these fields makes subthreading much
>> easier.  This didn't seem to be mentioned in the document.
>
>We are working on the specification (and reference implementation) for the
>REFERENCES algorithm and have been for the past month.  Please be patient.
>
>What you should look at in the current document is the framework provided
>(e.g. new algorithms can be added at any time, representation of trees, etc.)
>

Will the REFERENCES specification deal with referenced, but unavailable,
messages?

For example, message C references B references A and, for whatever
reason, messages A and C are available but B is not available.

Then I would still want B to be represented in the thread structure -
otherwise it would give the false impression that C replied to A.

The syntax in the draft currently can only return sequence numbers or
UIDs whereas for message B all that is known is its message-id.

Suggestion:

If A is message 1, and B has message-id <x <at> y>, and C is message 3 then
(Continue reading)

Permalink | Reply | 1 comment |
headers
Mark Crispin | 11 Aug 2000 19:03

Re: I-D ACTION:draft-ietf-imapext-thread-00.txt

On Fri, 11 Aug 2000 17:47:08 +0100, Paul Overell wrote:
> Will the REFERENCES specification deal with referenced, but unavailable,
> messages?

I submitted the version with the REFERENCES specification yesterday.  I think
that it answers your questions.
Permalink | Reply | 0 comments |

Gmane