Subject: Re: draft-nerenberg-imap-binary-00.txt
From: Chris Newman <[email-masked]>
To: Lyndon Nerenberg <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>, [email-masked]
Date: Wed, 29 Nov 2000 15:37:09 -0800
List-Id: <ietf-imapext.imc.org>

I read that spec.  It addresses point 3 from my previous post, and 
partially addresses point 1.  However, it introduces additional syntax 
issues:

(1a) I'm not convinced that the syntax model is appropriately general for 
similar conversion operations.  While I'm not opposed to binary moving 
forward by itself, it shouldn't move forward until we are confident that 
we're not creating lots of special case syntax variants.

(1b) I'm not convinced the restriction to leaf nodes is a good idea.  For 
example, a disconnected client which is caching entire messages could 
recognize a significant performance benefit if it fetched the entire 
message with all base64/QP encoding that's not in a security multipart 
removed.

(1c) It does not specify a syntax to request the size of a decoded body 
part.

A minor nit -- I wouldn't call a binary literal "literal8".  Vanilla IMAP 
literals already support 8-bit (when appropriately labelled).

		- Chris

--On Wednesday, November 29, 2000 11:33 -0700 Lyndon Nerenberg 
<[email-masked]> wrote:

> Chris, have you seen the -01 version of the draft? It contains two
> substantial changes:
>
> 1) The command syntax was changed to "FETCH n BINARY[x.y]"
>
> 2) The literal8 syntax is now "~{nnn}CRLF..."
>
> The -01 document was submitted last week but isn't yet in the
> repository. For now you can FTP it from:
>
> ftp://ftp.messagingdirect.com/pub/staff/lyndon/drafts/draft-nerenberg-ima
> p-bina ry-01.txt
>
> --lyndon
>

From: Lyndon Nerenberg <[email-masked]>
To: Chris Newman <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>, [email-masked]
Subject: Re: draft-nerenberg-imap-binary-00.txt 
Date: Wed, 29 Nov 2000 11:33:33 -0700
Sender: [email-masked]

Chris, have you seen the -01 version of the draft? It contains two
substantial changes:

1) The command syntax was changed to "FETCH n BINARY[x.y]"

2) The literal8 syntax is now "~{nnn}CRLF..."

The -01 document was submitted last week but isn't yet in the
repository. For now you can FTP it from:

ftp://ftp.messagingdirect.com/pub/staff/lyndon/drafts/draft-nerenberg-imap-bina
ry-01.txt

--lyndon

Date: Tue, 28 Nov 2000 16:20:14 -0800
From: Chris Newman <[email-masked]>
To: Lyndon Nerenberg <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>, [email-masked]
Subject: Re: draft-nerenberg-imap-binary-00.txt
Sender: [email-masked]

Issues with the binary extension:

(1) I concur with Mark's comments about syntax.  The current proposed 
syntax is unacceptable, the XFETCH strawman seems workable (with associated 
XFETCH response).  I could also deal with a fetch-item modifier as an 
alternative to a new command:
	C: A002 FETCH 1:5 <BINARY>BODY[1]
	S: * 1 FETCH (<BINARY>BODY[1] {#}...)
or
	C: A002 FETCH 1:5 <CHARSET=UTF8><BINARY>BODY[1]
        S: * 1 FETCH (<CHARSET=UTF8><BINARY>BODY[1] {#}...)
With that syntax, each modifier would have to describe how it interacts 
with various fetch items, for example, <BINARY>SIZE would return the size 
after removal of base64/QP encoding.

(2) I am currently opposed to a distinguished syntax for binary literals on 
the grounds that it introduces two silly states: a binary literal with 
non-binary content and a non-binary literal with binary content.  (In 
unextended IMAP, the latter is simply a protocol violation which robust 
implementations should detect.)  I would much prefer the statement that if 
the server advertises XFETCH BINARY, then the prohibition on the client 
sending binary literals for message content is lifted, and if the client 
issues the XFETCH command with BINARY option, then the prohibition on the 
server sending binary message content is lifted.

(3) If the concensus is against me on point 2, then I object to using a 
suffix to indicate a binary literal on the grounds that it breaks existing 
LITERAL+ detectors.  That objection would not apply to a prefix character.

(4) If a server advertises XFETCH BINARY, that should permit the use of 
binary CTE and binary literal content in APPEND.

(5) An unextended IMAP server is required to convert a body part with a 
binary CTE to base64.  An IMAP message store could receive a binary body 
part via the binary SMTP extension or an APPEND command (it is currently 
illegal protocol to have a true binary CTE in an APPEND).  If we ever want 
to support binary body parts signed by PGP or S/MIME, then we need a way to 
distinguish the canonical CTE from the requested/supplied CTE.  I don't 
have a strong opinion one way or the other, but the issue needs to be 
considered.

(6) BINARY and CHARSET=UTF8 conversions are no brainers (since an IMAP 
server with a halfway decent SEARCH command already implements them 
internally).  But the CHANNEL model is both very important for conversions 
not likely to be built into an IMAP server and rather tricky to get right 
due to security/firewall issues.

(7) I suggest we have an XFETCH (MD5) modifier, which computes the MD5 hash 
of the specified fetch BODY item -- MD5 is just a content conversion which 
happens to have a fixed size output.  May make channel security issues 
simpler, and could permit verification of PGP or S/MIME signatures without 
fetching all parts.

Note that I believe the CHANNEL mechanism in combination with an extension 
to the SMTP-SUBMIT protocol is the correct way to provide the ability to 
forward/resend an attachment without downloading it.

		- Chris

From: Lyndon Nerenberg <[email-masked]>
To: IMAP Extensions WG <[email-masked]>, [email-masked]
Subject: IMAP BINARY -01 draft available
Date: Fri, 24 Nov 2000 11:57:13 -0700
Sender: [email-masked]

This is a multipart MIME message.

--==_Exmh_-19606496970
Content-Type: text/plain; charset=us-ascii

I've upodated the draft to include this weeks feedback. I also fleshed
out the missing pieces. At this point I consider it pretty much complete.
The I-D submission autoreponder message isn't clear (to me) about whether
this will get published before the San Diego meeting. Meanwhile, you can
grab a copy from:

ftp://ftp.esys.ca/pub/staff/lyndon/drafts/draft-nerenberg-imap-binary-01.txt

--lyndon

--==_Exmh_-19606496970
Content-Type: message/external-body;
	name="draft-nerenberg-imap-binary-01.txt";
	site="ftp.messagingdirect.com";
	access-type=ANON-FTP;
	directory="/pub/staff/lyndon/drafts";
	mode="ascii"
Content-Description: draft-nerenberg-imap-binary-01.txt
Content-Disposition: attachment; filename="imap-binary-extref"

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

--==_Exmh_-19606496970--

Date: Fri, 24 Nov 2000 09:03:02 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: re: Commands starting with X
To: Paul Overell <[email-masked]>
cc: [email-masked]
Sender: [email-masked]

On Fri, 24 Nov 2000 09:56:29 +0000, Paul Overell wrote:
> Is it a good idea to invent new commands starting with X (XLIST XFETCH
> etc)?

XLIST and XFETCH are just placeholders for the purpose of discussion; the
actual names will be something else.

IMAP forbids the use of "X" in a standards-track command name.

Date: Fri, 24 Nov 2000 09:56:29 +0000
To: [email-masked]
From: Paul Overell <[email-masked]>
Subject: Commands starting with X
Sender: [email-masked]

Is it a good idea to invent new commands starting with X (XLIST XFETCH
etc)?

I only raise this as X is commonly used for non-standard or experimental
features, whereas these new commands are presumably intended to become
mainstream.

C.f. The NNTP group are sufficiently bothered by this to want to rename
XOVER and XPAT as OVER and PAT.

Regards
- -- 
Paul Overell                                             T U R N P I K E

From: "Caleb Clausen" <[email-masked]>
To: IMAP Extensions WG <[email-masked]>, [email-masked]
Date: Wed, 22 Nov 2000 16:24:35 -0800
Subject: Re: draft-nerenberg-imap-binary-00.txt 
Sender: [email-masked]

From:           	Lyndon Nerenberg <[email-masked]>
> > I believe therefore that this functionality belongs in a new command, e.g.
> > something like
> > 	tag XFETCH (BINARY) 1 BODY[x.y]
> > 	tag XFETCH (CHARSET=UTF-8) 1 BODY[x.y]
> > 	tag XFETCH (BINARY CHANNEL=[1.2.3.4]:432) 1 BODY[x.y]
> > etc.  These examples are to demonstrate the concept; the exact syntax to be
> > determined.
> 
> I hadn't realized that you and Steve had been discussing this, otherwise
> I would have held off with BINARY for a bit. I like the XFETCH architecture,
> however I'm not convinced (yet) that a server should have to implement
> external channel support just to get BINARY. At this point I think the

i would like to go on the record as one imap client implementor that 
would be very much interested in a BINARY FETCH. we have no 
use for CHANNEL at the moment... so i think these 2 concepts 
definitely should be separated.

i'd also like to enumerate some of the problems i see with 
CHANNEL as sketched out in the example above.

transport protocol
it isn't too clear from the example whether udp or tcp transport is 
envisioned. i think that the original impetus for this proposal within 
vpim was to enable the voice data to be delivered via voip (that is, 
rtp over udp.) in that context, tcp transport doesn't gain anything.

if udp is used for delivery, you then have to consider what happens 
when a packet gets dropped. voip uses fancy error-tolerant codecs 
to handle this case. the codec currently on the table for ivm (gsm) 
has no such abilities, so when a packet gets dropped, the rest of 
the file will be corrupted. 

of course, you could have the server translate the voice data into a 
fancy error-tolerant codec on the fly. probably a good use for the 
data-conversion feature of XFETCH?

nat
embedding ip addresses and port numbers within tcp payload is a 
sure way to break network address translators. it also makes imap 
dependant on ipv4, complicating the transition to ipv6. these are 
two reasons to avoid it altogether.

if ip addresses and ports must be embedded, you should at least 
try to avoid the minor disaster that ftp creates for nat by always 0-
padding the ip address octets and the port so that they always 
come out to exactly the same length. for example, instead of:

tag XFETCH (BINARY CHANNEL=[1.2.3.4]:432) 1 BODY[x.y]

you'd have:

tag XFETCH (BINARY CHANNEL=[001.002.003.004]:00432) 1 
BODY[x.y]

(sorry about the line wrap.)
this will still break nat, of course, but at least it will be easier to 
write a custom nat protocol handler for imap.

"The battle 
 for mental territory 
            is glory. 
            End of story."
                           --KRS-ONE

From: "Caleb Clausen" <[email-masked]>
To: IMAP Extensions WG <[email-masked]>, [email-masked]
Date: Wed, 22 Nov 2000 16:24:35 -0800
Subject: RE: draft-nerenberg-imap-binary-00.txt
Sender: [email-masked]

From:           	Lyndon Nerenberg <[email-masked]>
> > Steve indicated to me last week that he would combine the first two into one
> > proposal.  Do we expect two proposals now?
> 
> Steve's proposal for XFETCH includes support for both binary fetch and
> specifying external transfer channels for a fetch. (Among other
> things.)
> 
> My proposal provides binary fetch (only) for servers that don't want/need
> to support XFETCH.
> 
> The two can live side-by-side. Time will show if BINARY has enough
> support (in the presence of XFETCH) to move forward.

since everyone likes the XFETCH syntax so much better, why not 
do this: have separate capabilities for XFETCH itself, as well as all 
of it's options. so, the XFETCH document would define the following 
capabilities:
XFETCH
XFETCH-BINARY
XFETCH-CHANNEL
XFETCH-CHARSET
etc.

that way, servers which just want to provide a binary version of 
fetch could declare just XFETCH and XFETCH-BINARY. servers 
that want all of it would declare all the XFETCH capabilities.

or is this too great a proliferation of capabilities?

one question: will XFETCH work with the UID command? ie, will i 
be able to say,

tag UID XFETCH (BINARY) 1009 etc...

"The battle 
 for mental territory 
            is glory. 
            End of story."
                           --KRS-ONE

Date: Wed, 22 Nov 2000 15:36:35 -0700 (MST)
From: Lyndon Nerenberg <[email-masked]>
To: Glenn Parsons <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>, [email-masked]
Subject: RE: draft-nerenberg-imap-binary-00.txt
Sender: [email-masked]

> Steve indicated to me last week that he would combine the first two into one
> proposal.  Do we expect two proposals now?

Steve's proposal for XFETCH includes support for both binary fetch and
specifying external transfer channels for a fetch. (Among other
things.)

My proposal provides binary fetch (only) for servers that don't want/need
to support XFETCH.

The two can live side-by-side. Time will show if BINARY has enough
support (in the presence of XFETCH) to move forward.

--lyndon

To: Mark Crispin <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>, [email-masked]
Subject: Re: draft-nerenberg-imap-binary-00.txt 
Date: Tue, 21 Nov 2000 15:38:20 -0700
From: Lyndon Nerenberg <[email-masked]>
Sender: [email-masked]

> Isn't converting QP and BASE64 to BINARY a form of data conversion?

No, it's a change of transport encoding. The contents of the body
part at the client matches the contents of what the sender sent
regardless of where the transport encoding is undone (i.e. at the
client vs. at the server). The decoded data is the same, so it's not
a data conversion.

If, however, the server _also_ does character set manipulations on
the way through, the decoded data at the client might not match what
the sender initially sent. _That_ I consider to be data conversion.

> > I hadn't realized that you and Steve had been discussing this, otherwise
> > I would have held off with BINARY for a bit.

> That's why I was a bit surprised to see your document!  :-)

So was Steve :-)  I apologise for starting all this confusion.

> I suggest some added little token in literal8, perhaps {###}~ instead of {###}
> to indicate its special nature.

I can live with that. If people are okay with the syntax I'll incorporate
that into the next draft. Any suggestions for a modified FETCH...BINARY
syntax while we're at it?

--lyndon

Date: Tue, 21 Nov 2000 14:10:31 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: Re: draft-nerenberg-imap-binary-00.txt 
To: Lyndon Nerenberg <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>, [email-masked]
Sender: [email-masked]

On Tue, 21 Nov 2000 15:08:50 -0700, Lyndon Nerenberg wrote:
> > However, I object strongly to the "BODY[x.y.BINARY]" syntax.
> I'll agree with that. I'm not particularly happy with that syntax either.
> I needed something as a starting point

OK, good.  I'm happy with a stipulation that we're going to fix that.  I don't
want to stand in the way of the functionality, but that particular syntax has
got to go.

> And this is something VPIM originally requested (general conversions). I
> don't like overloading (or combining, I guess) BINARY with data conversion.

Isn't converting QP and BASE64 to BINARY a form of data conversion?

> I hadn't realized that you and Steve had been discussing this, otherwise
> I would have held off with BINARY for a bit.

That's why I was a bit surprised to see your document!  :-)

> I like the XFETCH architecture,
> however I'm not convinced (yet) that a server should have to implement
> external channel support just to get BINARY. At this point I think the
> two are really distinct issues, and should be separate extensions.

OK with me.

My guiding principle (consider XLIST) is that if it's trivial to bundle two
things together and less work than having them separate, then bundle them; but
if there's a reason why someone may want one and not the other, then keep them
separate.

If you feel that BINARY vs. external channel support is the latter, I won't
squawk.  [I'd appreciate the return favor when we talk about XLIST vs.
subscriptions........]

> > XFETCH that would output on the IMAP channel, so the client can
> > distinguish a literal8 from an ordinary literal.
> This shouldn't be necessary. The server will only send a literal8 at
> the specific request of the client, and they will never show up in
> an unsolicited response. It's not a big deal, though. If concensus is
> for a unique syntax for literal8 that's an easy change to make.

Mr. IMAP Architecture says that it's presumptious to say that "they will never
show up in an unsolicited responses."

The presumption may be valid for literal8 (and certainly right now it is), but
it isn't for literal; and that's what creates the ambiguity.  We don't want
the situation where a client gets a literal and thinks that it's a literal8.

I suggest some added little token in literal8, perhaps {###}~ instead of {###}
to indicate its special nature.

From: Lyndon Nerenberg <[email-masked]>
To: [email-masked]
Subject: (resend) Re; BINARY
Date: Tue, 21 Nov 2000 15:21:10 -0700
Sender: [email-masked]

[Sorry folks, this bounced first time around. >> == Mark, > == me.]

>>  The subject draft attempts to fufill a needed requirement for the 
>>VPIM folks.
>
>Initially that was the case, although I certainly think this extension has
>a use outside of that context.
>
>>  However, I object strongly to the "BODY[x.y.BINARY]" syntax.  Unlike other
>>  section specifiers, this one would stipulate a transformation of a section
>>  rather than identify a unique section.  It also adds complexity 
>>(the "terminal
>>  MIME body part" rule) as a side effect of overloading location syntax (the
>>  section specifier) with transformation instructions ("BINARY").
>
>I'll agree with that. I'm not particularly happy with that syntax either.
>I needed something as a starting point (and was under the gun to meet
>the submission deadline, so I didn't have a chance to work out anything
>better), so I went with the syntax in the original VPIM proposal.
>
>>  Furthermore, this extension does not really address the complete need, 
which
>>  is a general ability to transform/deliver message data in extended 
>>forms.  For
>>  example, a streaming application may wish to specify a separate 
>>host/port for
>>  delivery of the data.  It may be desireable to request the server 
>>to transform
>>  text data to UTF-8.
>
>And this is something VPIM originally requested (general conversions). I
>don't like overloading (or combining, I guess) BINARY with data conversion.
>BINARY provides a single piece of functionality: undoing of content
>transfer encodings. This is neutral to the actual content. If there is
>a need to do actual conversion of the underlying data, that should be
>handled separately. Character set conversions (such as your UTF8 example)
>are a bit fuzzy, sitting in between BINARY and general data conversions.
>I'm not sure where that actually fits in, but again I think that's a
>separate issue from BINARY itself.
>
>>  I believe therefore that this functionality belongs in a new command, e.g.
>>  something like
>>	tag XFETCH (BINARY) 1 BODY[x.y]
>>	tag XFETCH (CHARSET=UTF-8) 1 BODY[x.y]
>>	tag XFETCH (BINARY CHANNEL=[1.2.3.4]:432) 1 BODY[x.y]
>>  etc.  These examples are to demonstrate the concept; the exact syntax to be
>>  determined.
>
>I hadn't realized that you and Steve had been discussing this, otherwise
>I would have held off with BINARY for a bit. I like the XFETCH architecture,
>however I'm not convinced (yet) that a server should have to implement
>external channel support just to get BINARY. At this point I think the
>two are really distinct issues, and should be separate extensions. I don't
>think implementing channel necessarily requires the BINARY extensions
>be present. The external channel may already be 8bit clean, and the
>specification for that profile of the channel target mechanism could
>explicitly state that the channel is 8bit clean, therefore there's
>no need for the server to also implement BINARY if the implementer doesn't
>feel it adds significant value. It's still very early in the game, though,
>so I don't consider any of this cast in stone. I'm looking forward to
>seeing a more complete specification for XFETCH.
>
>>  We should also have a syntax for literal8s that are output in the case of 
an
>>  XFETCH that would output on the IMAP channel, so the client can 
>>distinguish a
>>  literal8 from an ordinary literal.  Otherwise there would be an 
>>ambiguity due
>>  to the unsolicited data model of IMAP, and the client would have to depend
>>  upon a command modality that IMAP espressly forbids.
>
>This shouldn't be necessary. The server will only send a literal8 at
>the specific request of the client, and they will never show up in
>an unsolicited response. It's not a big deal, though. If concensus is
>for a unique syntax for literal8 that's an easy change to make.
>
>--lyndon

Date: Tue, 21 Nov 2000 16:52:33 -0500
From: Cyrus Daboo <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: View draft for San Diego
Sender: [email-masked]

I'd like to get an update to the VIEW draft out before the deadline (and 
before the current one expires, though I could just re-sub,it it as it is 
with a change of expiry date).

The debate on VIEW was left somewhat open-ended after the last round of 
discussions on the list (a couple of months ago now). I think the issues 
wrt SORT & THREAD working with VIEW may best be left for the meeting, but a 
couple of issues for VIEW did come out of that round of discussions:

1) VIEW responses are too chatty. The proposal I had to solve this 
(Message-ID: <[email-masked]>) was to collapse 
all the VIEW 'position changed' responses into a single * VIEW response 
with three parts to it:

> Right now we have a * VIEW for each change. We could compress this down
> to a single * VIEW for all changes during the command in progress.
> Something along the lines off:
>
> * VIEW (1:3,5) (10 11 15 16) (1:2,20)
>
> The three groups represent:
>
> 1) View positions of messages removed from the view
> 2) Pairs of view positions for messages moving in the view
> 3) View positions of new messages added to the view
>
> This removes both UIDs and sequence numbers from the original * VIEW
> response.

2) Clients need a way to get the VIEW-UID map so that they can utilise 
existing cached data when changing from one view to another. There was a 
proposal to add a new VIEW WINDOW command that would allow this to work:

tag VIEW WINDOW <start-pos> <end-pos> ... <other options>

This would return a list of message UIDs corresponding to the range of view 
position ids requested. There are some issues about how to make this work 
with threads where the positions may represent different levels of 
hierarchy.

Are there any objections to these changes? Should we just wait until San 
Diego before deciding on ANY changes to VIEW, to allow the issues with SORT 
etc to be resolved first?

-- 
Cyrus Daboo

Date: Tue, 21 Nov 2000 14:46:09 -0700
From: Alexey Melnikov <[email-masked]>
To: Mark Crispin <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: draft-nerenberg-imap-binary-00.txt
Sender: [email-masked]

Oops. Hit Send button too fast. Sorry :-(.

To the best of my knowledge Lyndon will be writing another draft (superset of the
current) that will address VPIM stuff (general ability to transform/deliver message
in a different format or over a different channel). The draft that Lyndon submitted
is generally useful for conserving bandwidth.
It is possible that in the future there will be only a single extension.

Alexey

Date: Tue, 21 Nov 2000 14:41:16 -0700
From: Alexey Melnikov <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: draft-nerenberg-imap-binary-00.txt
Sender: [email-masked]

Mark Crispin wrote:

> The subject draft attempts to fufill a needed requirement for the VPIM folks.
>
> However, I object strongly to the "BODY[x.y.BINARY]" syntax.  Unlike other
> section specifiers, this one would stipulate a transformation of a section
> rather than identify a unique section.  It also adds complexity (the "terminal
> MIME body part" rule) as a side effect of overloading location syntax (the
> section specifier) with transformation instructions ("BINARY").
>
> Furthermore, this extension does not really address the complete need, which
> is a general ability to transform/deliver message data in extended forms.  For
> example, a streaming application may wish to specify a separate host/port for
> delivery of the data.  It may be desireable to request the server to transform
> text data to UTF-8.
>
> I believe therefore that this functionality belongs in a new command, e.g.
> something like
>         tag XFETCH (BINARY) 1 BODY[x.y]
>         tag XFETCH (CHARSET=UTF-8) 1 BODY[x.y]
>         tag XFETCH (BINARY CHANNEL=[1.2.3.4]:432) 1 BODY[x.y]
> etc.  These examples are to demonstrate the concept; the exact syntax to be
> determined.
>
> We should also have a syntax for literal8s that are output in the case of an
> XFETCH that would output on the IMAP channel, so the client can distinguish a
> literal8 from an ordinary literal.  Otherwise there would be an ambiguity due
> to the unsolicited data model of IMAP, and the client would have to depend
> upon a command modality that IMAP espressly forbids.

Date: Tue, 21 Nov 2000 12:58:19 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: draft-nerenberg-imap-binary-00.txt
To: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

The subject draft attempts to fufill a needed requirement for the VPIM folks.

However, I object strongly to the "BODY[x.y.BINARY]" syntax.  Unlike other
section specifiers, this one would stipulate a transformation of a section
rather than identify a unique section.  It also adds complexity (the "terminal
MIME body part" rule) as a side effect of overloading location syntax (the
section specifier) with transformation instructions ("BINARY").

Furthermore, this extension does not really address the complete need, which
is a general ability to transform/deliver message data in extended forms.  For
example, a streaming application may wish to specify a separate host/port for
delivery of the data.  It may be desireable to request the server to transform
text data to UTF-8.

I believe therefore that this functionality belongs in a new command, e.g.
something like
	tag XFETCH (BINARY) 1 BODY[x.y]
	tag XFETCH (CHARSET=UTF-8) 1 BODY[x.y]
	tag XFETCH (BINARY CHANNEL=[1.2.3.4]:432) 1 BODY[x.y]
etc.  These examples are to demonstrate the concept; the exact syntax to be
determined.

We should also have a syntax for literal8s that are output in the case of an
XFETCH that would output on the IMAP channel, so the client can distinguish a
literal8 from an ordinary literal.  Otherwise there would be an ambiguity due
to the unsolicited data model of IMAP, and the client would have to depend
upon a command modality that IMAP espressly forbids.

Date: Fri, 17 Nov 2000 14:56:19 -0700
From: Alexey Melnikov <[email-masked]>
To: Chris Newman <[email-masked]>
CC: Steve Hole <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: LIST Extensions Requirements
Sender: [email-masked]

> > One thing I would ask.   Can you keep track of the individual requirements
> > that progress through the discussion?
>
> I'm too busy to do a good job keeping track of such a list (I only get to
> IMAPEXT every couple weeks).  Furthermore, someone who is more neutral than
> I on some of the controversial issues would be better.  The WG chair or
> document editor would be a better choice, IMHO.

I can try to compile the list if there are no objections.

Alexey

Date: Fri, 17 Nov 2000 12:18:20 -0800
From: Chris Newman <[email-masked]>
To: Steve Hole <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: LIST Extensions Requirements
Sender: [email-masked]

--On Thursday, November 16, 2000 9:46 -0700 Steve Hole 
<[email-masked]> wrote:
> One thing I would ask.   Can you keep track of the individual requirements
> that progress through the discussion?

I'm too busy to do a good job keeping track of such a list (I only get to 
IMAPEXT every couple weeks).  Furthermore, someone who is more neutral than 
I on some of the controversial issues would be better.  The WG chair or 
document editor would be a better choice, IMHO.

		- Chris

Date: Thu, 16 Nov 2000 09:47:23 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: re: RFC 2193 & RFC 2221
To: [email-masked]
cc: [email-masked]
Sender: [email-masked]

On Thu, 16 Nov 2000 12:40:04 -0500, [email-masked] wrote:
> Interested in RFC 2193 IMAP4 Mailbox Referrals & RFC 2221IMAP4 Login
> Referrals.  How well adopted are these ?  What's happening in this area ?

Pine and most other good-quality client implementations fully implement
referrals at the client level.

I am aware of at least two servers which support referrals, either with a full
implementation or with hooks to a local management facility.

From: [email-masked]
To: [email-masked]
Subject: RFC 2193 & RFC 2221
Date: Thu, 16 Nov 2000 12:40:04 -0500
Sender: [email-masked]

This is a multipart message in MIME format.
--=_alternative 0060C73E85256999_=
Content-Type: text/plain; charset="us-ascii"

All,   
Interested in RFC 2193 IMAP4 Mailbox Referrals & RFC 2221IMAP4 Login 
Referrals.  How well adopted are these ?  What's happening in this area ? 
Any assistance would be greatly appreciated. 

Cynthia Mamacos
Lotus Development Corp.

--=_alternative 0060C73E85256999_=
Content-Type: text/html; charset="us-ascii"

<br><font size=2 face="sans-serif">All, &nbsp;</font><font size=3> <br>
</font><font size=2 face="sans-serif">Interested in RFC 2193 IMAP4 Mailbox Referrals &amp; RFC 2221IMAP4 Login Referrals. &nbsp;How well adopted are these ? &nbsp;What's happening in this area ?</font><font size=3> </font><font size=2 face="sans-serif"><br>
Any assistance would be greatly appreciated.</font><font size=3> <br>
</font>
<br><font size=2 face="sans-serif">Cynthia Mamacos<br>
Lotus Development Corp.<br>
</font>
--=_alternative 0060C73E85256999_=--

From: Steve Hole <[email-masked]>
Date: Thu, 16 Nov 2000 09:46:01 -0700
To: Chris Newman <[email-masked]>
Subject: Re: LIST Extensions Requirements
Cc: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

On Wed, 15 Nov 2000 12:04:59 -0800 Chris Newman <[email-masked]>
wrote:

>  Here's a first shot at requirements for the "XLIST" command.  This is a
>  brainstorm of ideas I recall being mentioned or have thought about, so
>  please don't assume you know my position just because an item showed up
>  in the list.

Looks good Chris.   There are things that I would like to discuss about
the namespace issues and reference arguments, but that should wait for a
face-to-face.

One thing I would ask.   Can you keep track of the individual requirements
that progress through the discussion?    I think that we want to collect a
requirements table that lists all the requirements that people propose,
along with a state that is one of:

  Accepted   - concensus to include as a requirement
  Rejected   - concensus to reject as a requirement
  Discussion - further discussion required to reach accept or reject
  Proposed   - proposed requirement but no discussion had yet

There are probably other states, but that should do for a starter.   If
you can't, then can someone else do this?   It will greatly improve our
ability to have a rational design discussion if we avoid rehashing things
that we have already reached concensus on.

Good work Chris.

Cheers.

---
Steve Hole
Chief Technical Officer
Messaging Direct
Mailto:[email-masked]
Phone: 780-424-4922

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-thread-05.txt
Date: Thu, 16 Nov 2000 06:28:09 -0500
Sender: [email-masked]

--NextPart

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

	Title		: INTERNET MESSAGE ACCESS PROTOCOL - THREAD EXTENSION
	Author(s)	: M. Crispin, K. Murchison
	Filename	: draft-ietf-imapext-thread-05.txt
	Pages		: 13
	Date		: 15-Nov-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-05.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-05.txt".

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-imapext-thread-05.txt

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

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

--OtherAccess--

--NextPart--

Date: Wed, 15 Nov 2000 14:54:58 -0800
From: Chris Newman <[email-masked]>
To: Simon Josefsson <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: LIST Extensions Requirements
Sender: [email-masked]

--On Wednesday, November 15, 2000 23:21 +0100 Simon Josefsson 
<[email-masked]> wrote:
> * It must not break old mailbox names -- if `/' is the new delimiter
>   there must be a way to escape `/' within a mailbox name.

That's not a requirement for XLIST, IMHO.  If you want to use "/" as a 
character in a mailbox names, then don't implement XLIST.

> * Because escaping might be ugly, I suggest that we could consider a
>   delimiter agnostic solution -- * XLIST ... "INBOX" "whatever"
>   "whatother"

I'd rather not.  That's too much work to parse, manage and map to URL 
semantics (which use "/" as the one true delimiter).

> * I feel the "display delimiter" might be as complicated as the
>   current delimiter situation, is it really worth having?

I'd prefer to do without it, but it's certainly simpler than the status quo 
where a client has to support all delimiters (including NIL) and translate 
mailbox names accordingly.  With a "display delimiter", the majority of 
clients which use hierarchy don't care, only those which display full paths 
to mailboxes need to worry about it.

> * Permit a facility to discover mailboxes with newly arrived mail

How do you define "newly arrived mail"?  Mailboxes with unseen messages? 
Or Mailboxes with \Recent messages (meaning messages have arrived since the 
last time you or perhaps someone else selected the mailbox).

>> * Layered facility for virtual scrollbars in very large mailbox list
>>    (e.g. #news/alt/%)
>>
>> * Limit on number of returned mailboxes (with limit exceeded notice)
>
> IMHO these should be optional and only used upon client request.

For the former I'd agree.  For the later, I'd actually be tempted to force 
clients to always specify the maximum number of returned mailboxes they can 
deal with.  I'm sick and tired of clients that crash or hang my machine 
when I point them at a server with too many mailboxes.

		- Chris

Date: Wed, 15 Nov 2000 14:28:59 -0800
From: Chris Newman <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: re: LIST Extensions Requirements
Sender: [email-masked]

--On Wednesday, November 15, 2000 12:14 -0800 Mark Crispin 
<[email-masked]> wrote:
> Server MUST be able to refuse LSUB or STATUS functionality.  Consequently
> extended LIST will never deprecate LSUB or STATUS, and clients MUST be
> able to use LSUB and STATUS.

That point is controversial and I doubt further debate on the list would be 
productive.  I _suggest_ resolving face to face.

> This has the potential to be a major rathole.  Suggest that debate on
> this be deferred to the end and/or be time-limited ahead of time.
>
> I believe that "generic extensible command" is a solution in search of a
> problem.

I concur.  I don't mind people structuring the command using some sort of 
extensible command model, as long as it isn't a separate document and 
doesn't waste a lot of time.

>> * Only permit "/" as delimiter in new list command.
>
> How does this interact with newsgroups?
>
> How did URLs solve the problem?  Did they make the newsgroup namespace
> flat? I don't think that #news/comp/mail/misc will please the users, but
> maybe #news/comp.mail.misc is OK.  This would make % equivalent to *, but
> as a practical matter this seems to be how many clients treat news anyway.

The newsgroup namespace is flat in URLs (news:<groupname>).  I suspect 
that's the right answer.

>> * Always use UTF-8 in new list command.
>
> Yes, definitely.

That was my thought at first, but now I'm unsure.  If UTF-8 shows up in 
mailbox names from extended list, then SELECT, CREATE, DELETE, etc. all 
have to support UTF-8.  Should the presence of the extended LIST modify the 
behavior of other commands?  I'd like to see more discussion.  Perhaps use 
of UTF-8 is inherently orthogonal to extended list and thus has to be a 
separate independent extension (unfortunately)?

>> * Permit a facility to discover newly created mailboxes.
>> * Permit a facility to discover newly deleted mailboxes.
>> * Permit a facility to discover mailboxes which have changed
>>    since last disconnected synchronization.
>> * Layered facility for virtual scrollbars in very large mailbox list
>>    (e.g. #news/alt/%)
>
> ...Umm...as long as it is server-optional.

That's the direction I lean as well.  But IMAP's lack of the ability to get 
a list of newly created newsgroups is the major protocol reason people 
won't migrate from NNTP to IMAP for client access, so I hope most servers 
will choose to implement that facility.

> ... due to the incorrect implementation in Cyrus;

The Cyrus implementation was done in good faith and complied with RFC 2060. 
John and I had a long discussion of what is a "breakout" character in a 
news-style namespace.  The conclusion we came to was that when a user types 
"comp.sys.mac" they are always referring to a top-level news folder.  News 
didn't have a way to refer to relative namespaces, but the obvious choice 
was to use a "." prefix for relative names, since names lacking a prefix 
"." were absolute.  We were trying our best to interpret the reference 
argument reasonably given the namespace semantics we were using.

When URLs came along and made Unix path semantics the standard path 
semantics for the Internet, our interpretation (and choice of path 
delimiter) became inappropriate.  When Pine came along and used the 
reference argument in a way we didn't expect, it failed to interoperate 
with Cyrus.  The best fix at that point was to change Cyrus (and derivative 
servers) to match the URL path semantics which Pine assumed.

		- Chris

To: Chris Newman <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
Subject: Re: LIST Extensions Requirements
From: Simon Josefsson <[email-masked]>
Date: 15 Nov 2000 23:21:41 +0100
Lines: 35
Sender: [email-masked]

Some random thoughts about some of the issues...

> * Only permit "/" as delimiter in new list command.
>    (Possibly have "display delimiter" attribute for clients that display
>    full mailbox names).

* It must not break old mailbox names -- if `/' is the new delimiter
  there must be a way to escape `/' within a mailbox name.

* Because escaping might be ugly, I suggest that we could consider a
  delimiter agnostic solution -- * XLIST ... "INBOX" "whatever" "whatother"

* I feel the "display delimiter" might be as complicated as the
  current delimiter situation, is it really worth having?

> * Permit a facility to discover newly created mailboxes.
> 
> * Permit a facility to discover newly deleted mailboxes.
> 
> * Permit a facility to discover mailboxes which have changed
>    since last disconnected synchronization.

I'll add another idea:

* Permit a facility to discover mailboxes with newly arrived mail

> * Layered facility for virtual scrollbars in very large mailbox list
>    (e.g. #news/alt/%)
> 
> * Limit on number of returned mailboxes (with limit exceeded notice)

IMHO these should be optional and only used upon client request.

Thanks

Date: Wed, 15 Nov 2000 12:14:45 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: re: LIST Extensions Requirements
To: Chris Newman <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

On Wed, 15 Nov 2000 12:04:59 -0800, Chris Newman wrote:
> * The command should be structured so that clients only request the
>   information they really need and will actually use.

Yes, definitely

> * New list command subsumes functionality of LIST, LSUB, RLIST, RLSUB and
>   STATUS commands.

Server MUST be able to refuse LSUB or STATUS functionality.  Consequently
extended LIST will never deprecate LSUB or STATUS, and clients MUST be able to
use LSUB and STATUS.

> * New list command subsumes child mailbox functionality.
> * The command should have the option of returning ACL and myrights
>   information for mailboxes.
> * The command should support mailbox annotations
> * Avoid silly states.  Use tri-state or multi-state variables instead of
>   interrelated flags to avoid them.

All these are fine.

> * Design around a "generic extensible command" model

This has the potential to be a major rathole.  Suggest that debate on this be
deferred to the end and/or be time-limited ahead of time.

I believe that "generic extensible command" is a solution in search of a
problem.

> * Only permit "/" as delimiter in new list command.

How does this interact with newsgroups?

How did URLs solve the problem?  Did they make the newsgroup namespace flat?
I don't think that #news/comp/mail/misc will please the users, but maybe
#news/comp.mail.misc is OK.  This would make % equivalent to *, but as a
practical matter this seems to be how many clients treat news anyway.

> * Always use UTF-8 in new list command.

Yes, definitely.

> * Permit a facility to discover newly created mailboxes.
> * Permit a facility to discover newly deleted mailboxes.
> * Permit a facility to discover mailboxes which have changed
>    since last disconnected synchronization.
> * Layered facility for virtual scrollbars in very large mailbox list
>    (e.g. #news/alt/%)

...Umm...as long as it is server-optional.

> * Limit on number of returned mailboxes (with limit exceeded notice)

Yes.

> * Way to request Quota information?

Need review/overhaul of existing QUOTA specification.

> * Don't include the reference argument in the replacement list command
>   (only using the "/" delimiter is the prerequisite for this).

No.

The only way to avoid the reference argument is to have a CWD command in IMAP.

The last time this issue came up it wasted at least a year of everybody's time
several years ago.  It wasted time again a few years later due to the
incorrect implementation in Cyrus; fortunately that is now fixed, and we had
to leave a monument in RFC 2683 as to why the old Cyrus implementation was
incorrect.  However, in the meantime many users of Cyrus IMAP servers were
inconvenienced.

Reviving this dead issue will waste everybody's time all over again, and with
many people this time the potential time wasted is worse than a year.

>   Explicitly note for clients that permit users to type a mailbox
>   name in context that if a user refers to ~/... or ~user/..., that
>   is likely shorthand for the Personal or Other Users namespaces
>   respectively.

That proposal would create a UNIX-centric kludge.  The need for context is
wider than UNIX, and as such these kludges would need to be specified for
every operating system (and future operating systems).

The reference argument solves the problem, in a far simpler and cleaner way
than such kludges.  The reference argument also has the advantage of being in
the IMAP base today.  Let's leave it alone.

> * What should be required for the base list replacement command

If it is a "LIST replacement", then it must NOT replace LSUB or STATUS.

Date: Wed, 15 Nov 2000 12:04:59 -0800
From: Chris Newman <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: LIST Extensions Requirements
Sender: [email-masked]

Here's a first shot at requirements for the "XLIST" command.  This is a
brainstorm of ideas I recall being mentioned or have thought about, so
please don't assume you know my position just because an item showed up in
the list.

Believed Non-Controversial Requirements:
----------------------------------------

* The command should be structured so that clients only request the
  information they really need and will actually use.

   * Clients which don't need subscription flag won't ask for it.
   * Clients which care about remote mailboxes, but don't need referrals
     until select time can request that.

* New list command subsumes functionality of LIST, LSUB, RLIST, RLSUB and
  STATUS commands.

   CAVEAT:  Controversy exists as to what set of these should be required as
   part of the XLIST base spec and which ones should be layered XLIST
   extensions with their own capability string.

* New list command subsumes child mailbox functionality.

* The command should have the option of returning ACL and myrights
  information for mailboxes.

* The command should support mailbox annotations

   CAVEAT: per-user and shared issue will rear its ugly head.  As will
   annotation namespace issue.

* Avoid silly states.  Use tri-state or multi-state variables instead of
  interrelated flags to avoid them.

* Design around a "generic extensible command" model that could be applied 
to
  other IMAP command extension situtations.

   CAVEAT: Controversy over whether "generic extensible command" model 
should
   be a separate standard.

Ideas for requirements which need debate:
-----------------------------------------

* Only permit "/" as delimiter in new list command.
   (Possibly have "display delimiter" attribute for clients that display
   full mailbox names).

* Always use UTF-8 in new list command.

* Permit a facility to discover newly created mailboxes.

* Permit a facility to discover newly deleted mailboxes.

* Permit a facility to discover mailboxes which have changed
   since last disconnected synchronization.

* Layered facility for virtual scrollbars in very large mailbox list
   (e.g. #news/alt/%)

* Limit on number of returned mailboxes (with limit exceeded notice)

* Way to request Quota information?

* Don't include the reference argument in the replacement list command
  (only using the "/" delimiter is the prerequisite for this).
  Explicitly note for clients that permit users to type a mailbox
  name in context that if a user refers to ~/... or ~user/..., that
  is likely shorthand for the Personal or Other Users namespaces
  respectively.

Controversial requirement ideas:
--------------------------------

* What should be required for the base list replacement command, as opposed
  to extensions to the list replacement command?

   Proposed litmus test: If it is common practice for IMAP clients to
   kludge around a deficiency in the LIST/LSUB/etc suite, then that
   facility should be part of the base XLIST command.  For example, many
   clients currently do "LIST "" %" and "LIST "" %/%" when \HasChildren
   information isn't available.  When XLIST is implemented this kludge
   should never be necessary.

   Additional litmus test: If there's a reasonable trivial implemention to
   comply, then include it in the XLIST base spec.  For example, a
   non-referral IMAP server can support clients that request referrals
   simply by never returning any.

   Anything not meeting one of these litmus tests should be an XLIST
   extension.

* Have "generic extensible command" model as a separate standard.

		- Chris

Date: Sat, 4 Nov 2000 15:26:43 -0500
To: "RL 'Bob' Morgan" <[email-masked]>
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <[email-masked]>
Subject: RE: moderate or restrict IMAPEXT
Cc: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

At 10.17 -0800 00-11-04, RL 'Bob' Morgan wrote:
>Having seen this issue go by on several mailing lists, and seen more or
>less the same answer be suggested, I wonder whether this wisdom is
>captured anywhere official?

http://www.ietf.org/IESG/STATEMENTS/moderated-lists.txt

    paf

>
>  - RL "Bob"
>
>>  As an IESG member which _IS_ subscribed to the list, let me explain
>>  what we normally say in these cases:
>>
>>  This is the algorithm which we think is ok:
>>
>>    IF the sender address is subscribed to the mailing list, OR
>>       on a special list for "approved subscribers" THEN
>>        Send the mail to the mailing list
>>    ELSE
>>       forward the mail to a human
>>       IF the mail is spam THEN
>>          >/dev/null
>>       FI
>>       IF the mail is not according to list policy THEN
>>          return message to sender, informing of what happened
>>       FI
>>       forward the mail to the mailing list
>>    FI
>>
>>  I.e. filtering is ok, but you need a human which manually takes care
>>  of rejected messages.

Date: Sat, 4 Nov 2000 12:49:56 -0600
To: IMAP Extensions WG <[email-masked]>
From: "RL 'Bob' Morgan" (<[email-masked]>) <[email-masked]>
Subject: RE: moderate or restrict IMAPEXT
Sender: [email-masked]

Having seen this issue go by on several mailing lists, and seen more or
less the same answer be suggested, I wonder whether this wisdom is
captured anywhere official?

  - RL "Bob"

>  As an IESG member which _IS_ subscribed to the list, let me explain
>  what we normally say in these cases:
>
>  This is the algorithm which we think is ok:
>
>    IF the sender address is subscribed to the mailing list, OR
>       on a special list for "approved subscribers" THEN
>        Send the mail to the mailing list
>    ELSE
>       forward the mail to a human
>       IF the mail is spam THEN
>          >/dev/null
>       FI
>       IF the mail is not according to list policy THEN
>          return message to sender, informing of what happened
>       FI
>       forward the mail to the mailing list
>    FI
>
>  I.e. filtering is ok, but you need a human which manually takes care
>  of rejected messages.

Date: Sat, 4 Nov 2000 12:48:41 -0600
To: [email-masked]
From: Lawrence Greenfield (<[email-masked]>) <[email-masked]>
Subject: Re: comments on LIST extensions
Sender: [email-masked]

    From: "Mike Gahrns" <[email-masked]>
    Cc: <[email-masked]>
    Date: Fri, 3 Nov 2000 16:18:33 -0800

[...]
    How about something like the following?

    3a) tag LIST "" % (REMOTE)
    includes in the LIST response folders that are remote and somehow marked as
    such in the LIST response

    3b)tag LIST "" % (REFERRAL)
    include in the LIST response folders that are remote along with their remote
    URL referral data

    However, I am somewhat unsure as to the scenario where it would be desirable
    for the client to request to have the folder's referral URL returned to it
    in the LIST command, rather than obtaining this info on demand when needed
    during the SELECT command.

I really want advisory referrals---I have a server that will silently
proxy for non-referral aware clients and handout referrals to clients
that execute an RLIST or RLSUB (yes, it's a mode, and yes, it's an
ugly hack).

So I'd like the way that referrals are discovered to happen before a
SELECT---even an advisory referral on SELECT will require my proxy
server to open a connection to the backend server, to give the rest of
the data on SELECT.

Larry

Date: Sat, 4 Nov 2000 12:25:06 -0500
From: Lawrence Greenfield <[email-masked]>
To: Mike Gahrns <[email-masked]>
Cc: [email-masked]
Subject: Re: comments on LIST extensions
Sender: [email-masked]

   From: "Mike Gahrns" <[email-masked]>
   Cc: <[email-masked]>
   Date: Fri, 3 Nov 2000 16:18:33 -0800

[...]
   How about something like the following?

   3a) tag LIST "" % (REMOTE)
   includes in the LIST response folders that are remote and somehow marked as
   such in the LIST response

   3b)tag LIST "" % (REFERRAL)
   include in the LIST response folders that are remote along with their remote
   URL referral data

   However, I am somewhat unsure as to the scenario where it would be desirable
   for the client to request to have the folder's referral URL returned to it
   in the LIST command, rather than obtaining this info on demand when needed
   during the SELECT command.

I really want advisory referrals---I have a server that will silently
proxy for non-referral aware clients and handout referrals to clients
that execute an RLIST or RLSUB (yes, it's a mode, and yes, it's an
ugly hack).

So I'd like the way that referrals are discovered to happen before a
SELECT---even an advisory referral on SELECT will require my proxy
server to open a connection to the backend server, to give the rest of
the data on SELECT.

Larry

Date: Sat, 4 Nov 2000 11:23:44 -0600
To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=  <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: RE: moderate or restrict IMAPEXT
Cc: "Eric Burger" <[email-masked]>, "Mark Crispin" <[email-masked]>, "IMAP Extensions WG" <[email-masked]>
Sender: [email-masked]

On 11/4/00 at 12:19 PM -0500, Patrik Fältström wrote:

>I.e. filtering is ok, but you need a human which manually takes care 
>of rejected messages.

Yes, I got e-mail from Paul (our list manager), and what you describe 
is exactly what we will do.

pr

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

Date: Sat, 4 Nov 2000 12:19:21 -0500
To: Pete Resnick <[email-masked]>, "Eric Burger" <[email-masked]>
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <[email-masked]>
Subject: RE: moderate or restrict IMAPEXT
Cc: "Mark Crispin" <[email-masked]>, "IMAP Extensions WG" <[email-masked]>
Sender: [email-masked]

At 16.54 -0600 00-11-03, Pete Resnick wrote:
>On 11/3/00 at 5:38 PM -0500, Eric Burger wrote:
>
>>What if we just limit posting to subscribers?  That reduces the chance of an
>>amature spammer succeeding, without the pain for the moderator.
>
>And it would proceed to disallow people like IESG members and others 
>who don't subscribe to the list from posting. I heavily object to 
>that. I'll moderate if we can work that out.

As an IESG member which _IS_ subscribed to the list, let me explain 
what we normally say in these cases:

This is the algorithm which we think is ok:

  IF the sender address is subscribed to the mailing list, OR
     on a special list for "approved subscribers" THEN
      Send the mail to the mailing list
  ELSE
     forward the mail to a human
     IF the mail is spam THEN
        >/dev/null
     FI
     IF the mail is not according to list policy THEN
        return message to sender, informing of what happened
     FI
     forward the mail to the mailing list
  FI

I.e. filtering is ok, but you need a human which manually takes care 
of rejected messages.

      Patrik

From: "Mike Gahrns" <[email-masked]>
To: "Mark Crispin" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: comments on LIST extensions
Date: Fri, 3 Nov 2000 16:18:33 -0800
Sender: [email-masked]

Mark Crispin writes:
>So, would it work for you that:
>
> 1) tag LIST "" %
>  does not include referral mailboxes
>
> 2) tag RLIST "" %
>   tag LIST "" % ()
>   include referral mailboxes, but do not return referal data
>
> 3) tag LIST "" % (REFERRAL)
>   include referral mailboxes and return referral data

*** If we went the LIST extension route,  I think I would like to see RLIST
eventually deprecated.
As such, I think there would need to be a way to get just the list of remote
mailboxes, and not their remote url location for the perf reasons I
mentioned in my previous post.  The remote url location for can be easily
obtained via SELECT, and saves having the server need to supply the info on
a potentially large number of folders that may never be accessed during the
session.  (Hopefully clients smart enough to use this extension would not be
blindly getting a whole public folder tree, but none-the-less it would still
be common to have potentially hundreds of folders in a single level of
hierarchy.)

How about something like the following?

3a) tag LIST "" % (REMOTE)
includes in the LIST response folders that are remote and somehow marked as
such in the LIST response

3b)tag LIST "" % (REFERRAL)
include in the LIST response folders that are remote along with their remote
URL referral data

However, I am somewhat unsure as to the scenario where it would be desirable
for the client to request to have the folder's referral URL returned to it
in the LIST command, rather than obtaining this info on demand when needed
during the SELECT command.

From: "Eric Burger" <[email-masked]>
To: "Pete Resnick" <[email-masked]>, "Mark Crispin" <[email-masked]>
Cc: "IMAP Extensions WG" <[email-masked]>
Subject: RE: moderate or restrict IMAPEXT
Date: Fri, 3 Nov 2000 18:49:53 -0500
Importance: Normal
Sender: [email-masked]

What if we just limit posting to subscribers?  That reduces the chance of an
amature spammer succeeding, without the pain for the moderator.

--
- Eric

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Pete Resnick
Sent: Friday, November 03, 2000 1:24 PM
To: Mark Crispin
Cc: IMAP Extensions WG
Subject: Re: moderate or restrict IMAPEXT

On 11/3/00 at 9:48 AM -0800, Mark Crispin wrote:

>Please establish moderation on IMAPEXT

Paul, I'm perfectly willing to do this if you have a method. If we
can use IMAP mailboxes to do this (perhaps an incoming IMAP mailbox
on your server that I moderate and transfer to another mailbox on
your server that you send out to the list), it would be perfectly
easy for me.

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

Date: Fri, 3 Nov 2000 15:16:34 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: Re: comments on LIST extensions
To: Mike Gahrns <[email-masked]>
cc: Barry Leiba <[email-masked]>, [email-masked]
Sender: [email-masked]

On Fri, 3 Nov 2000 14:38:42 -0800, Mike Gahrns wrote:
> *** For Exchange, there will be some hit in getting the referral data.
> Probably not devasting, but likely noticeable in the time it takes the LIST
> response to come back.  From a general design point of view, it is probably
> best to not include the referral details in a response.  Why generate this
> info until it is needed?  Not to mention sending the extra info across the
> wire, (which if there are multiple replicas could get large).

So, would it work for you that:

1) tag LIST "" %
   does not include referral mailboxes

2) tag RLIST "" %
   tag LIST "" % ()
   include referral mailboxes, but do not return referal data

3) tag LIST "" % (REFERRAL)
   include referral mailboxes and return referral data

Date: Fri, 3 Nov 2000 15:10:20 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: Re: comments on LIST extensions
To: Mike Gahrns <[email-masked]>
cc: [email-masked]
Sender: [email-masked]

On Fri, 3 Nov 2000 14:01:57 -0800, Mike Gahrns wrote:
> How did you envision your suggestion working?

Assuming that the LIST command is extended with a third argument, containing a
parenthesized list of additional attributes desired, then:

A two-argument LIST command will work as now; it may have expansion attributes
in the response but will never return additional data.

A three-argument LIST command will result in responses that include referral
messages and possibly also referral data.

The replacement for RLIST is a three-argument LIST with zero members in the
additional attribute list.

Date: Fri, 03 Nov 2000 18:08:37 -0500
From: Cyrus Daboo <[email-masked]>
To: Pete Resnick <[email-masked]>, Eric Burger <[email-masked]>
cc: Mark Crispin <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: RE: moderate or restrict IMAPEXT
Sender: [email-masked]

--On Friday, November 3, 2000 4:54 PM -0600 Pete Resnick 
<[email-masked]> wrote:

>> What if we just limit posting to subscribers?  That reduces the chance
>> of an amature spammer succeeding, without the pain for the moderator.
>
> And it would proceed to disallow people like IESG members and others who
> don't subscribe to the list from posting. I heavily object to that. I'll
> moderate if we can work that out.

Also a number of us don't subscribe directly but instead pipe the list into 
a shared imap mailbox via a specific email address - one of the many useful 
features of IMAP!

-- 
Cyrus Daboo

From: "Mike Gahrns" <[email-masked]>
To: "Barry Leiba" <[email-masked]>, <[email-masked]>
Subject: Re: comments on LIST extensions
Date: Fri, 3 Nov 2000 14:38:42 -0800
Sender: [email-masked]

Barry Leiba writes:
> The only concern I have here is that a referral-capable server might
> know quickly that a mailbox is remote, but might have a slower time
> actually retrieving the referral information.  So there *might* be some
use
> in letting the server tell you "this mailbox exists somewhere else", but
> not actually tell you *where* until you try to do something with it (if,
> for example, there are 50 remote mailboxes and it takes 1 second to
> retrieve the referral data for each, adding 50 seconds to the LIST
> (REFERRALS) command would be bad, and it might be better to make you try
> a SELECT when you actually want to use one of them).  Do any servers
> besides Exchange support mailbox referrals now?  How fast is it for
Exchange (or
> other servers) to retrieve the referral details?
*** For Exchange, there will be some hit in getting the referral data.
Probably not devasting, but likely noticeable in the time it takes the LIST
response to come back.  From a general design point of view, it is probably
best to not include the referral details in a response.  Why generate this
info until it is needed?  Not to mention sending the extra info across the
wire, (which if there are multiple replicas could get large).

Date: Fri, 3 Nov 2000 16:54:04 -0600
To: "Eric Burger" <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: RE: moderate or restrict IMAPEXT
Cc: "Mark Crispin" <[email-masked]>, "IMAP Extensions WG" <[email-masked]>
Sender: [email-masked]

On 11/3/00 at 5:38 PM -0500, Eric Burger wrote:

>What if we just limit posting to subscribers?  That reduces the chance of an
>amature spammer succeeding, without the pain for the moderator.

And it would proceed to disallow people like IESG members and others 
who don't subscribe to the list from posting. I heavily object to 
that. I'll moderate if we can work that out.

pr

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

From: "Eric Burger" <[email-masked]>
To: "Pete Resnick" <[email-masked]>, "Mark Crispin" <[email-masked]>
Cc: "IMAP Extensions WG" <[email-masked]>
Subject: RE: moderate or restrict IMAPEXT
Date: Fri, 3 Nov 2000 17:38:58 -0500
Importance: Normal
Sender: [email-masked]

What if we just limit posting to subscribers?  That reduces the chance of an
amature spammer succeeding, without the pain for the moderator.

--
- Eric

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Pete Resnick
Sent: Friday, November 03, 2000 1:24 PM
To: Mark Crispin
Cc: IMAP Extensions WG
Subject: Re: moderate or restrict IMAPEXT

On 11/3/00 at 9:48 AM -0800, Mark Crispin wrote:

>Please establish moderation on IMAPEXT

Paul, I'm perfectly willing to do this if you have a method. If we
can use IMAP mailboxes to do this (perhaps an incoming IMAP mailbox
on your server that I moderate and transfer to another mailbox on
your server that you send out to the list), it would be perfectly
easy for me.

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

From: "Mike Gahrns" <[email-masked]>
To: "Mark Crispin" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: comments on LIST extensions
Date: Fri, 3 Nov 2000 14:01:57 -0800
Sender: [email-masked]

Mark Crispin writes:
> My idea was that you would not show referrals unless you asked for
referral
> information in the extended LIST.
This could work.  My assumptions were that the extended LIST info would be
always coming back.

How did you envision your suggestion working?

Are you proposing a command to turn on extend LIST responses, or a command
to include referral info in an extended LIST response?  This seems like it
would be adding "modes" to IMAP, which I thought there were strong
objections to in the past...

With a command like XLIST, it was explicit that the client was requesting
this additional info and had to be prepared to handle it.

Date: Fri, 3 Nov 2000 13:53:07 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: Re: comments on LIST extensions
To: Mike Gahrns <[email-masked]>
cc: Steve Hole <[email-masked]>, Tony Hansen <[email-masked]>, Barry Leiba <[email-masked]>, [email-masked]
Sender: [email-masked]

On Fri, 3 Nov 2000 13:51:06 -0800, Mike Gahrns wrote:
> *** One drawback of extending LIST through upwards-compatible syntax instead
> of creating a new command like XLIST,  is that it will create problems in
> the referral case.

My idea was that you would not show referrals unless you asked for referral
information in the extended LIST.

From: "Mike Gahrns" <[email-masked]>
To: "Mark Crispin" <[email-masked]>, "Steve Hole" <[email-masked]>
Cc: "Tony Hansen" <[email-masked]>, "Barry Leiba" <[email-masked]>, <[email-masked]>
Subject: Re: comments on LIST extensions
Date: Fri, 3 Nov 2000 13:51:06 -0800
Sender: [email-masked]

Mark Crispin writes:
> I am not yet convinced that we can not extend LIST through
upwards-compatible
> syntax.  Shouldn't we proceed as if we can do so, with the understanding
that
> XLIST is not out of the question if we hit an otherwise insurmountable
> obstacle?
*** One drawback of extending LIST through upwards-compatible syntax instead
of creating a new command like XLIST,  is that it will create problems in
the referral case.  Even if we add referral info in a LIST response that
presumably would be ignored by non-referral enabled clients, these
non-referral enabled clients would still likely show these remote folders to
their users.  This was deemed undesirable during the initial referral
discussions.  e.g.  The user experience would be bad in that users would try
to select these remote folders, and have the SELECT command fail when
accessed.

Date: Fri, 3 Nov 2000 13:43:57 -0600
To: Barry Leiba <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: comments on LIST extensions
Cc: [email-masked]
Sender: [email-masked]

On 11/3/00 at 2:26 PM -0500, Barry Leiba wrote:

>OK, then... since all the discussions about what XLIST might be have 
>so far been ad hoc discussion among a few of us, why don't we get 
>some time on the agenda at San Diego and have a proper discussion of 
>it.  I'll take that discussion and come up with a first pass at the 
>requirements, and then we can discuss it further on the mailing list.
>
>If that's the way everyone wants to go, then I'll not make any 
>updates to the LIST Extensions draft now, and the next revision will 
>just be the first draft of the new XLIST command.  Shall we do it 
>that way?

Barry, I am more inclined to have you write *something* before the 
meeting if you can, even if it is just a straw man to bat around.

We've still got two weeks to discuss this a bit on the list and maybe 
get Barry enough stuff to throw into an I-D before the November 17 
deadline. If we can't, such is life, but let's see what we can do. In 
either case, this will still be an important item on the agenda.

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

Date: Fri, 3 Nov 2000 12:24:02 -0600
To: Mark Crispin <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: moderate or restrict IMAPEXT
Cc: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

On 11/3/00 at 9:48 AM -0800, Mark Crispin wrote:

>Please establish moderation on IMAPEXT

Paul, I'm perfectly willing to do this if you have a method. If we 
can use IMAP mailboxes to do this (perhaps an incoming IMAP mailbox 
on your server that I moderate and transfer to another mailbox on 
your server that you send out to the list), it would be perfectly 
easy for me.

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

Date: Fri, 03 Nov 2000 14:26:16 -0500
From: Barry Leiba <[email-masked]>
To: [email-masked]
Subject: Re: comments on LIST extensions
Sender: [email-masked]

> Mark is right, we need a set of requirements that we can get concensus on.
> From there we can design the thing we want.

OK, then... since all the discussions about what XLIST might be have so far 
been ad hoc discussion among a few of us, why don't we get some time on the 
agenda at San Diego and have a proper discussion of it.  I'll take that 
discussion and come up with a first pass at the requirements, and then we 
can discuss it further on the mailing list.

If that's the way everyone wants to go, then I'll not make any updates to 
the LIST Extensions draft now, and the next revision will just be the first 
draft of the new XLIST command.  Shall we do it that way?

Barry Leiba, Living Lab Services  ([email-masked])
http://www.research.ibm.com/people/l/leiba

Date: Fri, 3 Nov 2000 10:46:54 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: Re: comments on LIST extensions
To: Steve Hole <[email-masked]>
cc: Tony Hansen <[email-masked]>, Barry Leiba <[email-masked]>, [email-masked]
Sender: [email-masked]

Obviously, base LIST and LSUB have to be left alone.  However, base LIST and
LSUB does have an extension mechanism for attributes, so the server can utter
extraneous attributes to a base client.

I am not yet convinced that we can not extend LIST through upwards-compatible
syntax.  Shouldn't we proceed as if we can do so, with the understanding that
XLIST is not out of the question if we hit an otherwise insurmountable
obstacle?

Unless I'm completely off-base, there are three things that need to be done:
 1) Add additional attributes.  Completely compatible with base spec.
 2) Add additional arguments to LIST command.  Must be governed by capability.
 3) Add additional return values to LIST response.  Must be governed by use of
    an extended LIST command from (2).

Whether or not we also do XLIST, I think that we should do these steps to
LIST.

From: Steve Hole <[email-masked]>
Date: Fri, 3 Nov 2000 11:41:48 -0700
To: Mark Crispin <[email-masked]>
Subject: Re: comments on LIST extensions
Cc: Tony Hansen <[email-masked]>, Barry Leiba <[email-masked]>, [email-masked]
Sender: [email-masked]

On Fri, 3 Nov 2000 10:12:18 -0800 (PST) Mark Crispin 
<[email-masked]> wrote:

> Leaving aside the issue of LIST vs. XLIST, I recommend that there be a
> statement or position paper about these "actual requirements."
> 
> This is to ensure that we are all on the same wavelength.  What you feel that
> "we have learned" may be very different from what people here that "we have
> learned."
> 
> Having created and agreed to such a list, we should use that list in the
> resulting design.  We get into trouble when we don't have a fixed (and mutual)
> statement of requirements.

Sounds good to me.

> This statement scares me.  Backward compatibility is a good thing, and should
> be abandoned only with a great deal of reluctance.
> 
> The current LIST architecture definitely has problems, but those problems
> happened for a reason.

Ya ... it sounds worse than it was meant to.   I think my point is that 
LIST did happen for a reason and it was successful in providing a bridge 
from pre-IMAP4 functionality to IMAP4.    That is why I would like to 
leave LIST and LSUB alone.   It is part of the base spec and mandatory to 
implement.

With XLIST we have an opportunity to take the good stuff from LIST (like 
the basic mailbox metaphor) and create a new command that has all of that,
plus all of the good stuff from the other extensions to LIST (like 
referrals etc.) and unify it all together.   I think we can do that 
because everyone has to implement LIST and LSUB no matter what and we can 
make sure that everyone interoperates.

The risk is that we try to build something that is mutually incompatible 
from a basic principles point of view and that makes implementation on the
server (and possibly in the client) completely impractical.    We just 
shouldn't do that.   Of course, it is exactly this issue that has gotten 
us into trouble before -- where is the line for impractical 
implementation.

Mark is right, we need a set of requirements that we can get concensus on.
>From there we can design the thing we want.

Cheers.

---
Steve Hole
Chief Technology Officer
MessagingDirect Ltd.
<mailto:[email-masked]>
Phone: 780-424-4922

Date: Fri, 3 Nov 2000 10:34:31 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: Re: comments on LIST extensions
To: Barry Leiba <[email-masked]>
cc: [email-masked]
Sender: [email-masked]

On Fri, 03 Nov 2000 13:29:42 -0500, Barry Leiba wrote:
> Right, but I think that what Steve means is that we should leave LIST and
> LSUB alone, and that provides the backward compatibility... and then we can
> make a new XLIST command that's unencumbered by those issues.

That's OK as far as it goes.  However, the underlying reasons for why those
issues came to be can't be ignored.

For example, although I understand the desire for greater client control over
server behavior, nonetheless you can't forbid the server from making decisions
that overrule client desires.  Servers have a right (some would say
obligation) to protect themselves.

LIST * is the obvious example of this.

A possible solution may be to expand responses so that it is clear when the
server is declining to give information (or otherwise do something).  Suppose,
for example, there was a \Select and an \Inferiors attribute in LIST; in that
case () would mean "server declines to say" rather than ambiguous between that
and (\Select \Inferiors).

However, this brings us to the "silly state" argument whenever we have a three
way state such as this represented by binary flags; there's a fourth, silly,
state.  I abhor such silly states as bad architecture.  Plus, sooner or later,
some clown will do it, and software has to figure out what to do.

So, when designing this facility, we should use mechanisms that avoid silly
states.  In other words, if it's a three-way state, then use a three-way
protocol mechanism instead of a pair of binary mechanisms.

Date: Fri, 03 Nov 2000 13:28:48 -0500
From: Cyrus Daboo <[email-masked]>
To: Steve Hole <[email-masked]>, Tony Hansen <[email-masked]>
cc: Barry Leiba <[email-masked]>, [email-masked]
Subject: Re: comments on LIST extensions
Sender: [email-masked]

--On Friday, November 3, 2000 10:52 AM -0700 Steve Hole 
<[email-masked]> wrote:

>> I think the charter has us, among other things, working on
>> augmenting/fixing LIST. I don't think the charter constrains us to the
>> form those augmentations or fixes must take.
>
> Exactly.   Even if the charter did constrain, I would suggest cutting
> LIST  extension out of imapext and proceeding with an XLIST outside of
> imapext.  Mark is exactly right that messing with LIST and LSUB has two
> major  problems:
>
> 1.  It constrains the final solution unacceptibly because we have a
> learned a great deal about the actual requirements for managing mailbox
> namespaces.    We will be forced to tradeoffs for backward compatibility
> that we don't want to make.
>
> 2.  It will confuse new developers tremendously.   The interoperability
> with LIST and LSUB will get worse than it already is.

I think your XLIST is really covered under the auspices of the mailbox 
annotations extension, which I believe we did agree to cover in the WG, 
once the message annotation issues were worked out.

Note that mailbox annotations can encompose a lot of other extensions 
through unification. It would naturally include all the existing LIST 
flags, and include CHILDREN and RLIST. But it can go further and include 
STATUS, access control and quota information, in addition to arbitrary 
attribute-value data, thus giving a single command syntax to cover nearly 
all mailbox specific operations.

-- 
Cyrus Daboo

Date: Fri, 03 Nov 2000 13:29:42 -0500
From: Barry Leiba <[email-masked]>
To: [email-masked]
Subject: Re: comments on LIST extensions
Sender: [email-masked]

>> We will be forced to tradeoffs for backward compatibility
>> that we don't want to make.
>
> This statement scares me.  Backward compatibility is a good thing, and
> should be abandoned only with a great deal of reluctance.

Right, but I think that what Steve means is that we should leave LIST and 
LSUB alone, and that provides the backward compatibility... and then we can 
make a new XLIST command that's unencumbered by those issues.

Barry

Date: Fri, 3 Nov 2000 10:12:18 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: Re: comments on LIST extensions
To: Steve Hole <[email-masked]>
cc: Tony Hansen <[email-masked]>, Barry Leiba <[email-masked]>, [email-masked]
Sender: [email-masked]

On Fri, 3 Nov 2000 10:52:38 -0700, Steve Hole wrote:
> 1.  It constrains the final solution unacceptibly because we have a
> learned a great deal about the actual requirements for managing mailbox
> namespaces.

Leaving aside the issue of LIST vs. XLIST, I recommend that there be a
statement or position paper about these "actual requirements."

This is to ensure that we are all on the same wavelength.  What you feel that
"we have learned" may be very different from what people here that "we have
learned."

Having created and agreed to such a list, we should use that list in the
resulting design.  We get into trouble when we don't have a fixed (and mutual)
statement of requirements.

> We will be forced to tradeoffs for backward compatibility
> that we don't want to make.

This statement scares me.  Backward compatibility is a good thing, and should
be abandoned only with a great deal of reluctance.

The current LIST architecture definitely has problems, but those problems
happened for a reason.

Date: Fri, 03 Nov 2000 13:19:53 -0500
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: moderate or restrict IMAPEXT
Sender: [email-masked]

--On Friday, November 3, 2000 9:48 AM -0800 Mark Crispin 
<[email-masked]> wrote:

> It happened again today.  IMAPEXT polluted my mailbox with a spam for a
> fake love potion.
>
> No, I do not want to hear offers for quack medicines, dirty pictures,
> pyramid schemes, et nauseum.
>
> Please establish moderation on IMAPEXT; or at least restrict posting
> privileges to list members.
>
> -- Mark --
>
> http://staff.washington.edu/mrc
> Science does not emerge from voting, party politics, or public debate.
>

>From what I can see the 'spam' arriving on this list has not included 
imapext in To, CC addresses. There were two messages in that category that 
were not spam, but I think its reasonable to expect posts to this list to 
contain the imapext address in either the To or CC headers. Thus a simple 
SIEVE script like the following would work as a reasonable filter for the 
time being:

# SIEVE Script
# Name: imapext spam discard
# Date: Fri, 03 Nov 2000 13:18:32 -0500
# User-Agent : Mulberry 2.1.0d1

# Rule 1: imapext spam discard
# Generated from GUI
if not address :contains ["To", "CC"] "[email-masked]" {
	discard;
}

# SIEVE Script ends here

-- 
Cyrus Daboo

From: Steve Hole <[email-masked]>
Date: Fri, 3 Nov 2000 10:52:38 -0700
To: Tony Hansen <[email-masked]>
Subject: Re: comments on LIST extensions
Cc: Barry Leiba <[email-masked]>, [email-masked]
Sender: [email-masked]

On Fri, 03 Nov 2000 10:02:06 -0500 Tony Hansen <[email-masked]> wrote:

> I think the charter has us, among other things, working on
> augmenting/fixing LIST. I don't think the charter constrains us to the
> form those augmentations or fixes must take.

Exactly.   Even if the charter did constrain, I would suggest cutting LIST 
extension out of imapext and proceeding with an XLIST outside of imapext. 
Mark is exactly right that messing with LIST and LSUB has two major 
problems:

1.  It constrains the final solution unacceptibly because we have a 
learned a great deal about the actual requirements for managing mailbox 
namespaces.    We will be forced to tradeoffs for backward compatibility 
that we don't want to make.

2.  It will confuse new developers tremendously.   The interoperability 
with LIST and LSUB will get worse than it already is.

Cheers.
---
Steve Hole
Chief Technology Officer
MessagingDirect Ltd.
<mailto:[email-masked]>
Phone: 780-424-4922

Date: Fri, 3 Nov 2000 09:48:16 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: moderate or restrict IMAPEXT
Organization: Networks & Distributed Computing
Sender: [email-masked]

It happened again today.  IMAPEXT polluted my mailbox with a spam for a
fake love potion.

No, I do not want to hear offers for quack medicines, dirty pictures,
pyramid schemes, et nauseum.

Please establish moderation on IMAPEXT; or at least restrict posting
privileges to list members.

-- Mark --

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

Date: Fri, 03 Nov 2000 10:02:06 -0500
From: Tony Hansen <[email-masked]>
Organization: AT&T Laboratories
To: Barry Leiba <[email-masked]>
CC: [email-masked]
Subject: Re: comments on LIST extensions
Sender: [email-masked]

I think the charter has us, among other things, working on
augmenting/fixing LIST. I don't think the charter constrains us to the
form those augmentations or fixes must take.

	Tony

Barry Leiba wrote:
> 
> > Actually Barry, while I applaud the extensible LIST argument attempt, what
> > I am most interested in is an entirely new, all consuming LIST command.
> > Call it XLIST for the purpose of discussion.
> 
> Yes, we've talked about this, and I agree, and I want to work on that.  It
> was my understanding, though, that doing that was beyond the scope of the
> IMAPExt WG, and that the LIST extensions that the WG decided to work on
> were of the sort described in this draft.  Pete R., can you clarify?  I'll
> be happy to shift this draft toward a complete revision of the LIST
> command, if the WG considers it to be within its scope.  Otherwise I'll
> continue with this as the interim answer, and work on the "XLIST" (or
> whatever) afterward.

Date: Fri, 03 Nov 2000 09:09:31 -0500
From: Barry Leiba <[email-masked]>
To: [email-masked]
Subject: Re: comments on LIST extensions
Sender: [email-masked]

> Remember, subscriptions were defined specifically to support a
> pre-existing functionality, and that this functionality is in use.
> Compatibility with this functionality must be retained.
>
> If I understand your proposal correctly, you're doing this.

Yes, by keeping LSUB as is and recommending its continued use.

>> 2. Maybe add wording to clarify that flags returned by LSUB may not be
>> accurate.  This should probably be in the base spec, actually.
>
> It isn't that the flags are inaccurate; they are different.  For example,
> \NoSelect means something different in LSUB.

The list of flags may also not include flags that would be included in a 
LIST.  I don't mean to say that flags would appear spuriously, so it's 
probably more accurate to say that "the flags returned by LSUB may be 
incomplete, and some may have different meanings."  The point is that a 
client can't know whether "()" means there are no flags set or that this 
server can't return the list of flags in LSUB.  In fact, there's nothing 
stopping a server from returning, say, "(\Marked)" in response to LSUB and 
"(\Marked \NoInferiors)" in response to LIST (or some other similar 
example).

> I'll be happy to consider suggested changes to the base spec wording for
> this. Please review what's in the current draft, not RFC 2060.

I'll do that and post something separately about it; thanks.

> OK, so by omitting LIST-SUBSCRIBED, I can implement the other options
> (and use them), correct?
>
> Put another way, there is no requirement to implement LIST-SUBSCRIBED in
> order to implement any other piece of this technology, correct?

Exactly; that's the intent here.  I'm recommending that you implement 
LIST-SUBSCRIBED, because clients can and will get that information anyway 
if they really want it, at greater cost... but its implementation is 
entirely optional.

> "\NonExistant" => "\NonExistent"

Glrf.  Thanks.  I hate when I misspel things.
:-)

>> 6. Add a new mailbox flag, "\PlaceHolder" (alternative name?), intended
>> to indicate, when necessary, that "this mailbox does not meet your
>> selection criteria, but it has a child that might (or, stronger, does?)".
>
> How will this work with LSUB, given the need to maintain compatibility?  I
> suggest that it be allowed in LSUB, but *with* the overloaded \NoSelect,
> e.g. * LSUB (\NoSelect \PlaceHolder) "/" foo
> to make it unambiguous that the \NoSelect is the overloaded form.

Yes, that was also the intent, and I didn't mention that.  To be general: 
LSUB MUST behave as it always has, but MAY also include the new flags. 
Clients MAY use the new flags for the information they convey, but MUST NOT 
assume that their absence means anything.

Side issue here: if a client sees "\NonExistent" or "\PlaceHolder" in one 
LSUB response line, can it now assume that their absence in other response 
lines is meaningful?  Maybe it's best not to address this.

> I think that we should do it.  I've been convinced that we should have
> another value in the LIST response, containing a parenthesized list of
> property/value pairs.
>     * LIST () "/" foo (REFERRAL "..." BLOOP soop)
>
> The purpose of the parentheses is to enable to addition of another value
> in the response in the future if it turns out that attribute or
> property/value aren't enough.

Absolutely, on the parentheses; I think it's valuable to group things that 
way for extensibility.  OK, since everyone who's chimed in agrees that the 
referral data should be presented(*), I'll work that in.  Should that go in 
this spec, or into a revision of the MAILBOX-REFERRALS spec?

(*) The only concern I have here is that a referral-capable server might 
know quickly that a mailbox is remote, but might have a slower time 
actually retrieving the referral information.  So there *might* be some use 
in letting the server tell you "this mailbox exists somewhere else", but 
not actually tell you *where* until you try to do something with it (if, 
for example, there are 50 remote mailboxes and it takes 1 second to 
retrieve the referral data for each, adding 50 seconds to the LIST 
(REFERRALS) command would be bad, and it might be better to make you try a 
SELECT when you actually want to use one of them).  Do any servers besides 
Exchange support mailbox referrals now?  How fast is it for Exchange (or 
other servers) to retrieve the referral details?

Barry Leiba, Living Lab Services  ([email-masked])
http://www.research.ibm.com/people/l/leiba

Date: Fri, 03 Nov 2000 08:51:18 -0500
From: Barry Leiba <[email-masked]>
To: [email-masked]
Subject: Re: comments on LIST extensions
Sender: [email-masked]

> Actually Barry, while I applaud the extensible LIST argument attempt, what
> I am most interested in is an entirely new, all consuming LIST command.
> Call it XLIST for the purpose of discussion.

Yes, we've talked about this, and I agree, and I want to work on that.  It 
was my understanding, though, that doing that was beyond the scope of the 
IMAPExt WG, and that the LIST extensions that the WG decided to work on 
were of the sort described in this draft.  Pete R., can you clarify?  I'll 
be happy to shift this draft toward a complete revision of the LIST 
command, if the WG considers it to be within its scope.  Otherwise I'll 
continue with this as the interim answer, and work on the "XLIST" (or 
whatever) afterward.

> 1.   I would like to see the orginal extension framework draft revived,
> Included the restriction on applicable command set if people still feel
> it  is necessary.

I agree, and I think that I asked for comments on this resurrection a while 
ago and got insufficient support, considering the objections from Mark and 
Chris.  If there's enough support for it to try to get past their 
objections, I'm certainly eager to pursue it, and I think Cyrus is too. 
I'd rather discuss it here, unless Pete objects, rather than on the IMAP 
list, but I think it's outside the scope of the IMAPExt WG.

Barry Leiba, Living Lab Services  ([email-masked])
http://www.research.ibm.com/people/l/leiba

Date: Fri, 3 Nov 2000 03:59:09 -0800 (PST)
From: [email-masked]
To: [email-masked]
Subject: At last, Herbal V, the all natural alternative to V----A!
Sender: [email-masked]

Herbal V: An Incredible All-Natural Healthy Alternative 

  Herbal V is the All Natural Approach to Male Virility,
  Vitality and Pleasure.

Available N o w ! 

Welcome to the New Sexual Revolution.

It's the all natural male potency and pleasure pill that men 
everywhere are buzzing about. Herbal V is safe, natural and
specifically formulated to help support male sexual function
and pleasure. You just take two easy-to-swallow tablets
one hour before sex. And there's more great news - you can
get Herbal V for less than $1 a pill.

Amazing word of mouth praise on Herbal V has been spreading 
like wildfire-already over 1,500,000 men  have chosen
Herbal V. Since it is 100% natural you will never have
to worry about safety. Try doctor-recommended Herbal V
today and have the greatest night of your life!

Herbal V... Bringing Back the Magic!

1,585,000 men can't be wrong. To date over 1 million men 
have tried the super supplement Herbal V.
Here is why: 

No Doctor Visit Required 
Available Over the Counter 
Not a Drug 
100% Natural 
Safe, No Worries 
Highest Quality Pharmaceutical-Grade Pure Nutriceuticals 
Guaranteed Potency & Purity 

Be a Real Man Again!

Questions and Answers

What is Herbal V?

Herbal V is a proprietary blend that was specifically
developed as a safe alternative for men who prefer
an all-natural approach to address impotence and boost
sexual performance. This amazing formula first became
popular with Hollywood insiders and the wealthy elite.
They were maximizing their sex lives, long before it 
was available to the general public. 

How does Herbal V work?

Developed by a team whose goal was to create the perfect 
all-natural aphrodisiac. Herbal V is the result of that
remarkable effort. The Herbal V formula contains a precise
blend of cutting edge pro-sexual nutrients from around
the world that provide nutritional support, making it
possible for a man to have a pleasurable sexual experience. 

What can Herbal V do for me?

Herbal V helps support male sexual function and 
pleasure in a safe and natural manner. Simply put, 
it can make your sex life incredible. 

Is Herbal V Safe?

One of the great things about Herbal V is that it is
not a drug. It is an incredible herbal dietary supplement
that provides nutritional support for male sexual function
and pleasure. One of the most comforting features of
Herbal V is that you never have to worry about safety. 

Herbal V: Safe - Natural - Exciting

Many have speculated that because Herbal V is so
popular with men, it must contain prescription drugs
or chemical components. Herbal V does not contain any 
elements or traces of any prescription drug. Herbal V 
is made using the world's most technologically advanced
state-of-the-art cold processing equipment to ensure
maximum purity. Herbal V has been independently analyzed
by the nation's premier testing facility to ensure purity,
quality and to end the rumors that, because it is so
popular, it must somehow be chemical. It is not.
Herbal V is natural - just as it says on the label.
Herbal V is simply fantastic! 

Herbal V: Ingredients

Yohimbe, saw palmetto, avena sativa, androstenedione,
guarana, taurine, siberian ginseng, tribulus terrestris. 
Tribulus Terrestis is certified to enhanced testosterone
levels by increasing Luteinzing hormone (LH) levels. 
Androstenedione which is a precursor to testosterone
unlocks bound testosterone and makes it biologically
active again quickly. This means a dramatic surge in 
desire. Avena Sativa Stimulates the neurotransmitter 
pleasure centers to maximum capacity. This greatly
intensifies pleasure.

Just listen to what Herbal V has done for the sex lives
of people like you!

“On a scale of 1 to 10, it's a 15. Electrifying. It's like 
a wonder pill!” 
— Justin Q B., New Haven, Texas

“I haven't had sexual relations in 11 years. Then with 
Herbal V it was... wow! It works again!” 
— Sid R., Lakeland, Florida

“I had sex four times in one night. It made me feel
like a 19-year-old again.” 
— Chip S, Beech Mountain, North Carolina

“Herbal V has turned my husband into a Sexual Superman! 
I like the fact that it's all natural and has no
side effects. It's bringing back the good old days.” 
— Jennifer B, Beverly Hills, California 

The above testimonials are from product literature, 
and we have not independently verified them.
However, the following testimonial is from a "senior"
gentleman who has purchased his second bottle of
Herbal V. When we heard his words with our own ears,
we asked his permission to print them here. 

 “Man! I'm wild as I can be! I feel like I'm 25 years old again! 
I'm not believing this!” 
                          — Mr. Murphy, age 64, Lampart, IL.

Risk Free: Double Your Money Back Guarantee

If Herbal V does not give the desired results as stated
above, simply return the unused portion for a
double-your money back refund. No questions asked ! 

Order Now: Safe, Fast, Secure, Private

Herbal V with its DOUBLE YOUR MONEY BACK GUARANTEE is
available only through this special promotional offer.
Herbal V arrives in plain packaging for your privacy.
Any and all information is kept strictly confidential.

Payment Methods

You may FAX or Postal Mail Checks, MasterCard, Visa,
& American Express.payments. Money Orders
are accepted only by Postal Mail. 

Each bottle of Herbal V contains 30 tablets, approximately
a 1 month supply.

Step 1: Place a check by your desired quanity.

______ 1 Bottle of Herbal V  $28

______ 2 Bottles of Herbal V $48

______ 3 Bottles of Herbal V $59

Please add $6 shipping and handling for any size order. 
[ Total cost including shipping & handling, 
1 bottle=$34, 2 bottles=$54, 3 bottles=$65 ]

International Orders
Please add $16 shipping and handling for any size order.
[ Total cost including shipping & handling,
1 bottle=$40, 2 bottles=$60, 3 bottles=$75 ]
We cannot accept foreign checks.
International money orders or credit cards only.

Step 2: Place a check by your desired payment method 
and complete fields if necessary.

_____Check or CHECK-BY-FAX [details below]

_____Money Order 

_____American Express 
Account Number__________________ Exp____/____

_____Visa
Account Number__________________ Exp____/____

_____MasterCard
Account Number__________________ Exp____/____

Please make your check or money order payable to
"Lion Sciences National".

Step 3: Please complete and print the following fields clearly.

Name ___________________________________________________ 

Address _________________________________________________

City ____________________________________________________ 

State ___________________________________________________ 

Zip _____________________________________________________ 

E-mail __________________________________________________ 

Signature _________________________________________________
[ required for check and credit card orders]

             Toll Free FAX Order Line: 1-800-940-6590
If faxing in your order, please state whether you require
a fax, email, or no confirmation at all. 
Allow up to one day for confirmation, if requested.
FAX orders are processed immediately.

  Or, print & mail to: LSN   
                       3502 N. Powerline Rd. #525 
                       Pompano Beach, FL 33069                

        ______________________________________________________

*CHECK BY FAX ORDERS: Complete the check as normal. Tape
the check in the area below. Below the check, clearly write
the check number, all numbers at the bottom of the check,
& your name. Tape the check below and fax the check to the
toll free FAX number above. Void the check. Our merchant
will electronically debit your account for the amount of 
the check; your reference number for this transaction will
be your check number. Nothing could be safer & easier !

                          TAPE CHECK BELOW

              _____________________________________________________________

This is a one time mailing: Removal is automatic and no further 
contact is necessary. Please Note: Herbal V is not intended to
diagnose, treat, cure or prevent any disease. As individuals differ,
so will results. Herbal V helps provide herbal and nutritional support
for male sexual performance. The FDA has not evaluated these 
statements. For details about our double your money back guarantee,
please write to the above address, attention consumer affairs 
department; enclose a self addressed stamped envelope for this and any 
requested contact information.
Thank You.

From: "Mike Gahrns" <[email-masked]>
To: "Barry Leiba" <[email-masked]>, <[email-masked]>
Subject: Re: comments on LIST extensions
Date: Thu, 2 Nov 2000 13:57:21 -0800
Sender: [email-masked]

Barry Leiba writes:
> We also have to do something with the REMOTE (or REFERRALS) option.  I
> agree with those who think that we should add referral information to the
> LIST response, but I'd really like to hear from Mike Gahrns or Raymond
> Cheng about it.
Yes,  including referral information in a "general LIST response type
extension" is a good idea, and something that many of us discussed at
various events like the IMC interops and IETF meetings.

Assuming we went with the approach Steve Hole suggested with a new command
like XLIST (insted of a general LIST response extension) this type of
mechanism could simplify referrals in removing the need for the RLIST
command.  Recall, RLIST was added to referrals since in general one would
not want a non-referral enabled client displaying remote mailboxes that
would not be accessible to a  user.
If a mailbox was flagged as \remote (or whatever was agreed upon), it would
need to be explicitly stated in the XLIST extension that the mailbox should
not be displayed to the user unless the client was a referral enabled
client.

Date: Thu, 2 Nov 2000 13:37:33 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: Re: comments on LIST extensions
To: Barry Leiba <[email-masked]>
cc: [email-masked]
Sender: [email-masked]

Barry -

I think that your latest message on this topic is good, and we can move
forward with it.  I figured that I should get *that* data point said before
going into the long response.

On Thu, 02 Nov 2000 14:35:31 -0500, Barry Leiba wrote:
> It seems that Mark's got the main complaint, and that complaint involves
> the interaction between subscriptions and other options.  Specifically, in
> Mark's model of how subscriptions work, it doesn't generally make sense to
> combine SUBSCRIBED with other options.

Remember, subscriptions were defined specifically to support a pre-existing
functionality, and that this functionality is in use.  Compatibility with this
functionality must be retained.

If I understand your proposal correctly, you're doing this.

> That said, many servers *do* implement "subscribed to" as a mailbox
> attribute, and in those servers it *does* make sense to have SUBSCRIBED be
> an option, and to allow its combination with other options.

I agree that it is alright as an option that does not break or otherwise
restrict existing software.  This implies that it should be permissible to
implement other options without implementing this one.

> 1. Change wording so it doesn't suggest deprecating LSUB.  Add wording to
> indicate that LSUB will remain *unchanged*, and that clients that don't
> need more function than is provided by LSUB should continue to use LSUB.

OK

> 2. Maybe add wording to clarify that flags returned by LSUB may not be
> accurate.  This should probably be in the base spec, actually.

It isn't that the flags are inaccurate; they are different.  For example,
\NoSelect means something different in LSUB.

I'll be happy to consider suggested changes to the base spec wording for this.
Please review what's in the current draft, not RFC 2060.

> 3. The LISTEXT capability will announce support for the general method of
> specifying LIST options and for the CHILDREN option.

OK.

> 4. The LIST-SUBSCRIBED capability will announce support for the SUBSCRIBED
> option.

OK, so by omitting LIST-SUBSCRIBED, I can implement the other options (and use
them), correct?

Put another way, there is no requirement to implement LIST-SUBSCRIBED in order
to implement any other piece of this technology, correct?

If the answer to both of these is "yes", you may consider my objections as
having been satisfied and consequently are dropped.

> Note that this means (and I will make it clear) that "LSUB" and "LIST
> (SUBSCRIBED)" are *not* the same, and that clients that do not need the
> extra function provided by the latter SHOULD NOT use it.

OK

> 5. Add a new mailbox flag, "\NonExistant", intended to be applied to a
> mailbox that's subscribed to but that doesn't actually exist.

"\NonExistant" => "\NonExistent"

> 6. Add a new mailbox flag, "\PlaceHolder" (alternative name?), intended to
> indicate, when necessary, that "this mailbox does not meet your selection
> criteria, but it has a child that might (or, stronger, does?)".

How will this work with LSUB, given the need to maintain compatibility?  I
suggest that it be allowed in LSUB, but *with* the overloaded \NoSelect, e.g.
    * LSUB (\NoSelect \PlaceHolder) "/" foo
to make it unambiguous that the \NoSelect is the overloaded form.

LIST-SUBSCRIBED, on the other hand, won't have \NoSelect.

> We also have to do something with the REMOTE (or REFERRALS) option.  I
> agree with those who think that we should add referral information to the
> LIST response, but I'd really like to hear from Mike Gahrns or Raymond
> Cheng about it.

I think that we should do it.  I've been convinced that we should have another
value in the LIST response, containing a parenthesized list of property/value
pairs.
    * LIST () "/" foo (REFERRAL "..." BLOOP soop)

The purpose of the parentheses is to enable to addition of another value in
the response in the future if it turns out that attribute or property/value
aren't enough.

From: Steve Hole <[email-masked]>
Date: Thu, 2 Nov 2000 14:01:20 -0700
To: Barry Leiba <[email-masked]>
Subject: Re: comments on LIST extensions
Cc: [email-masked]
Sender: [email-masked]

Actually Barry, while I applaud the extensible LIST argument attempt, what
I am most interested in is an entirely new, all consuming LIST command.   
Call it XLIST for the purpose of discussion.

All of the things that you put in your message, modulo the bits that define
interaction between LIST and LSUB, would go into the XLIST extension 
command.   In XLIST, mailboxes can express a number of different 
attributes, including user/application defined ones (annotations) and they
can all be searched/retrieved using the XLIST and related commands.   
Great.   People will either implement or not in the true spirit of the 
IMAP world -- if it is useful lots of people will do it.

Leave LIST and LSUB alone.   Their semantics are defined and implemented 
in a number of products, and messing with them is just going to cause 
confusion.    It will certainly cause lots of disagreement -- as it 
already has.

...

I also think that your original draft that provided a general IMAP command
argument extension framework was a damned good idea.   Certainly, the new 
XLIST command could employ it straight off.   Some people didn't like the 
possibility of command extension for the commands available in the 
non-authenticated state.   Fine.   Stipulate that that set of commands 
cannot be extended in this way.   Otherwise, if you want to extend the 
arguments for a base command, this is the way to do it.

Personally, I don't understand what the issue is for the commands 
available in the non-authenticated state.   And yes, I have heard the 
arguments -- please don't send them again.   I just don't agree with them.
In my opinion, they are not sound arguments and the examples provided are 
very much contrived. 

...

To summarize:

1.   I would like to see the orginal extension framework draft revived, 
Included the restriction on applicable command set if people still feel it 
is necessary.

2.   I would like to see a draft for a brand new command that can be used 
as an alternative to the existing LIST and LSUB commands that has the 
unified semantics of the various LIST extensions, plus an explicit 
extension mechanism for folder metadata.

Cheers.

---
Steve Hole
Chief Technology Officer
MessagingDirect Ltd.
<mailto:[email-masked]>
Phone: 780-424-4922

Date: Thu, 02 Nov 2000 14:35:31 -0500
From: Barry Leiba <[email-masked]>
To: [email-masked]
Subject: Re: comments on LIST extensions
Sender: [email-masked]

OK, it seems that the discussion has settled down -- nothing for a couple 
of weeks -- so I'll do a little summary and a proposal.

It seems that Mark's got the main complaint, and that complaint involves 
the interaction between subscriptions and other options.  Specifically, in 
Mark's model of how subscriptions work, it doesn't generally make sense to 
combine SUBSCRIBED with other options.  Further, the idea that SUBSCRIBED 
is an option on the LIST command implies that "being subscribed to" is an 
attribute of a mailbox, and that wasn't Mark's intent.  He strongly wants 
to keep the LSUB command separate, and that's partly to make it clear that 
the list of subscriptions is a completely separate list.

That said, many servers *do* implement "subscribed to" as a mailbox 
attribute, and in those servers it *does* make sense to have SUBSCRIBED be 
an option, and to allow its combination with other options.

Further, a client that wants to have an accurate list of mailbox flags on 
subscribed mailboxes (for instance) *will* get that information, and as it 
stands it has to do it by combinations of LSUB and multiple LIST commands.

OK, so here's what I propose as a change to the current LIST extensions 
draft:

1. Change wording so it doesn't suggest deprecating LSUB.  Add wording to 
indicate that LSUB will remain *unchanged*, and that clients that don't 
need more function than is provided by LSUB should continue to use LSUB.

2. Maybe add wording to clarify that flags returned by LSUB may not be 
accurate.  This should probably be in the base spec, actually.

3. The LISTEXT capability will announce support for the general method of 
specifying LIST options and for the CHILDREN option.

4. The LIST-SUBSCRIBED capability will announce support for the SUBSCRIBED 
option.  This option may be combined with other options, guarantees 
accurate flags, and so forth (I'll put in appropriate wording).

Note that this means (and I will make it clear) that "LSUB" and "LIST 
(SUBSCRIBED)" are *not* the same, and that clients that do not need the 
extra function provided by the latter SHOULD NOT use it.  Servers, such as 
Mark's, which have to do extra work to, for example, get accurate flags for 
subscribed mailboxes, MUST do so if they implement LIST-SUBSCRIBED.  I 
think such servers would do well to do so, since, as noted above, a client 
that wants the information will get it anyway, and at greater cost to both 
client and server.

5. Add a new mailbox flag, "\NonExistant", intended to be applied to a 
mailbox that's subscribed to but that doesn't actually exist.  This will 
distingush between
   * LIST () "/" "Banana"
and
   * LIST (\NonExistant) "/" "Banana"
The LSUB command MAY use the \NonExistant flag as a hint, but the "LIST 
(SUBSCRIBED)" MUST use it.

6. Add a new mailbox flag, "\PlaceHolder" (alternative name?), intended to 
indicate, when necessary, that "this mailbox does not meet your selection 
criteria, but it has a child that might (or, stronger, does?)".  This will 
eliminate the overloading of \NoSelect for this purpose, which, once we 
implement the SUBSCRIBED option, has to be done.

Example:
  A1 LIST (SUBSCRIBED CHILDREN) "" "%"
  * LIST (\NoInferiors) "/" "inbox"
  * LIST (\NoSelect \HasChildren) "/" "xyz"
  * LIST (\NonExistant) "/" "abc"
  * LIST (\PlaceHolder \HasChildren) "/" "def"
  * LIST (\HasChildren) "/" "ghi"
  A1 OK done
  A2 LIST (SUBSCRIBED CHILDREN) "" "%/%"
  * LIST (\HasChildren) "/" "def/xxx"
  * LIST (\HasNoChildren) "/" "ghi/yyy"
  * LIST (\HasNoChildren) "/" "ghi/zzz"
  A2 OK done

Here, note that "inbox" and "abc" do not have CHILDREN flags, because the 
\NoInferiors and \NonExistant flags make them unnecessary.  Mailbox "xyz" 
is subscribed to, but is not selectable; it has children, and, as it turns 
out, none of those children are subscribed to.  "abc" is subscribed to, but 
doesn't actually exist.  "def" is not subscribed to, but it has children 
that are.  "ghi" is subscribed to and has children; we don't know whether 
any of its children are subscribed to -- the second LIST shows us that they 
are.

Does this all make sense?  Mark, does it satisfy your concerns?  Others, 
does it meet your needs too?

We also have to do something with the REMOTE (or REFERRALS) option.  I 
agree with those who think that we should add referral information to the 
LIST response, but I'd really like to hear from Mike Gahrns or Raymond 
Cheng about it.

Barry Leiba, Living Lab Services  ([email-masked])
http://www.research.ibm.com/people/l/leiba

Date: Wed, 29 Nov 2000 15:37:09 -0800
From: Chris Newman <[email-masked]>
To: Lyndon Nerenberg <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>, [email-masked]
Subject: Re: draft-nerenberg-imap-binary-00.txt
Sender: [email-masked]

I read that spec.  It addresses point 3 from my previous post, and 
partially addresses point 1.  However, it introduces additional syntax 
issues:

(1a) I'm not convinced that the syntax model is appropriately general for 
similar conversion operations.  While I'm not opposed to binary moving 
forward by itself, it shouldn't move forward until we are confident that 
we're not creating lots of special case syntax variants.

(1b) I'm not convinced the restriction to leaf nodes is a good idea.  For 
example, a disconnected client which is caching entire messages could 
recognize a significant performance benefit if it fetched the entire 
message with all base64/QP encoding that's not in a security multipart 
removed.

(1c) It does not specify a syntax to request the size of a decoded body 
part.

A minor nit -- I wouldn't call a binary literal "literal8".  Vanilla IMAP 
literals already support 8-bit (when appropriately labelled).

		- Chris

--On Wednesday, November 29, 2000 11:33 -0700 Lyndon Nerenberg 
<[email-masked]> wrote:

> Chris, have you seen the -01 version of the draft? It contains two
> substantial changes:
>
> 1) The command syntax was changed to "FETCH n BINARY[x.y]"
>
> 2) The literal8 syntax is now "~{nnn}CRLF..."
>
> The -01 document was submitted last week but isn't yet in the
> repository. For now you can FTP it from:
>
> ftp://ftp.messagingdirect.com/pub/staff/lyndon/drafts/draft-nerenberg-ima
> p-bina ry-01.txt
>
> --lyndon
>

From: Lyndon Nerenberg <[email-masked]>
To: Chris Newman <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>, [email-masked]
Subject: Re: draft-nerenberg-imap-binary-00.txt 
Date: Wed, 29 Nov 2000 11:33:33 -0700
Sender: [email-masked]

Chris, have you seen the -01 version of the draft? It contains two
substantial changes:

1) The command syntax was changed to "FETCH n BINARY[x.y]"

2) The literal8 syntax is now "~{nnn}CRLF..."

The -01 document was submitted last week but isn't yet in the
repository. For now you can FTP it from:

ftp://ftp.messagingdirect.com/pub/staff/lyndon/drafts/draft-nerenberg-imap-bina
ry-01.txt

--lyndon

Date: Tue, 28 Nov 2000 16:20:14 -0800
From: Chris Newman <[email-masked]>
To: Lyndon Nerenberg <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>, [email-masked]
Subject: Re: draft-nerenberg-imap-binary-00.txt
Sender: [email-masked]

Issues with the binary extension:

(1) I concur with Mark's comments about syntax.  The current proposed 
syntax is unacceptable, the XFETCH strawman seems workable (with associated 
XFETCH response).  I could also deal with a fetch-item modifier as an 
alternative to a new command:
	C: A002 FETCH 1:5 <BINARY>BODY[1]
	S: * 1 FETCH (<BINARY>BODY[1] {#}...)
or
	C: A002 FETCH 1:5 <CHARSET=UTF8><BINARY>BODY[1]
        S: * 1 FETCH (<CHARSET=UTF8><BINARY>BODY[1] {#}...)
With that syntax, each modifier would have to describe how it interacts 
with various fetch items, for example, <BINARY>SIZE would return the size 
after removal of base64/QP encoding.

(2) I am currently opposed to a distinguished syntax for binary literals on 
the grounds that it introduces two silly states: a binary literal with 
non-binary content and a non-binary literal with binary content.  (In 
unextended IMAP, the latter is simply a protocol violation which robust 
implementations should detect.)  I would much prefer the statement that if 
the server advertises XFETCH BINARY, then the prohibition on the client 
sending binary literals for message content is lifted, and if the client 
issues the XFETCH command with BINARY option, then the prohibition on the 
server sending binary message content is lifted.

(3) If the concensus is against me on point 2, then I object to using a 
suffix to indicate a binary literal on the grounds that it breaks existing 
LITERAL+ detectors.  That objection would not apply to a prefix character.

(4) If a server advertises XFETCH BINARY, that should permit the use of 
binary CTE and binary literal content in APPEND.

(5) An unextended IMAP server is required to convert a body part with a 
binary CTE to base64.  An IMAP message store could receive a binary body 
part via the binary SMTP extension or an APPEND command (it is currently 
illegal protocol to have a true binary CTE in an APPEND).  If we ever want 
to support binary body parts signed by PGP or S/MIME, then we need a way to 
distinguish the canonical CTE from the requested/supplied CTE.  I don't 
have a strong opinion one way or the other, but the issue needs to be 
considered.

(6) BINARY and CHARSET=UTF8 conversions are no brainers (since an IMAP 
server with a halfway decent SEARCH command already implements them 
internally).  But the CHANNEL model is both very important for conversions 
not likely to be built into an IMAP server and rather tricky to get right 
due to security/firewall issues.

(7) I suggest we have an XFETCH (MD5) modifier, which computes the MD5 hash 
of the specified fetch BODY item -- MD5 is just a content conversion which 
happens to have a fixed size output.  May make channel security issues 
simpler, and could permit verification of PGP or S/MIME signatures without 
fetching all parts.

Note that I believe the CHANNEL mechanism in combination with an extension 
to the SMTP-SUBMIT protocol is the correct way to provide the ability to 
forward/resend an attachment without downloading it.

		- Chris

From: Lyndon Nerenberg <[email-masked]>
To: IMAP Extensions WG <[email-masked]>, [email-masked]
Subject: IMAP BINARY -01 draft available
Date: Fri, 24 Nov 2000 11:57:13 -0700
Sender: [email-masked]

This is a multipart MIME message.

--==_Exmh_-19606496970
Content-Type: text/plain; charset=us-ascii

I've upodated the draft to include this weeks feedback. I also fleshed
out the missing pieces. At this point I consider it pretty much complete.
The I-D submission autoreponder message isn't clear (to me) about whether
this will get published before the San Diego meeting. Meanwhile, you can
grab a copy from:

ftp://ftp.esys.ca/pub/staff/lyndon/drafts/draft-nerenberg-imap-binary-01.txt

--lyndon

--==_Exmh_-19606496970
Content-Type: message/external-body;
	name="draft-nerenberg-imap-binary-01.txt";
	site="ftp.messagingdirect.com";
	access-type=ANON-FTP;
	directory="/pub/staff/lyndon/drafts";
	mode="ascii"
Content-Description: draft-nerenberg-imap-binary-01.txt
Content-Disposition: attachment; filename="imap-binary-extref"

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

--==_Exmh_-19606496970--

Date: Fri, 24 Nov 2000 09:03:02 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: re: Commands starting with X
To: Paul Overell <[email-masked]>
cc: [email-masked]
Sender: [email-masked]

On Fri, 24 Nov 2000 09:56:29 +0000, Paul Overell wrote:
> Is it a good idea to invent new commands starting with X (XLIST XFETCH
> etc)?

XLIST and XFETCH are just placeholders for the purpose of discussion; the
actual names will be something else.

IMAP forbids the use of "X" in a standards-track command name.

Date: Fri, 24 Nov 2000 09:56:29 +0000
To: [email-masked]
From: Paul Overell <[email-masked]>
Subject: Commands starting with X
Sender: [email-masked]

Is it a good idea to invent new commands starting with X (XLIST XFETCH
etc)?

I only raise this as X is commonly used for non-standard or experimental
features, whereas these new commands are presumably intended to become
mainstream.

C.f. The NNTP group are sufficiently bothered by this to want to rename
XOVER and XPAT as OVER and PAT.

Regards
- -- 
Paul Overell                                             T U R N P I K E

From: "Caleb Clausen" <[email-masked]>
To: IMAP Extensions WG <[email-masked]>, [email-masked]
Date: Wed, 22 Nov 2000 16:24:35 -0800
Subject: Re: draft-nerenberg-imap-binary-00.txt 
Sender: [email-masked]

From:           	Lyndon Nerenberg <[email-masked]>
> > I believe therefore that this functionality belongs in a new command, e.g.
> > something like
> > 	tag XFETCH (BINARY) 1 BODY[x.y]
> > 	tag XFETCH (CHARSET=UTF-8) 1 BODY[x.y]
> > 	tag XFETCH (BINARY CHANNEL=[1.2.3.4]:432) 1 BODY[x.y]
> > etc.  These examples are to demonstrate the concept; the exact syntax to be
> > determined.
> 
> I hadn't realized that you and Steve had been discussing this, otherwise
> I would have held off with BINARY for a bit. I like the XFETCH architecture,
> however I'm not convinced (yet) that a server should have to implement
> external channel support just to get BINARY. At this point I think the

i would like to go on the record as one imap client implementor that 
would be very much interested in a BINARY FETCH. we have no 
use for CHANNEL at the moment... so i think these 2 concepts 
definitely should be separated.

i'd also like to enumerate some of the problems i see with 
CHANNEL as sketched out in the example above.

transport protocol
it isn't too clear from the example whether udp or tcp transport is 
envisioned. i think that the original impetus for this proposal within 
vpim was to enable the voice data to be delivered via voip (that is, 
rtp over udp.) in that context, tcp transport doesn't gain anything.

if udp is used for delivery, you then have to consider what happens 
when a packet gets dropped. voip uses fancy error-tolerant codecs 
to handle this case. the codec currently on the table for ivm (gsm) 
has no such abilities, so when a packet gets dropped, the rest of 
the file will be corrupted. 

of course, you could have the server translate the voice data into a 
fancy error-tolerant codec on the fly. probably a good use for the 
data-conversion feature of XFETCH?

nat
embedding ip addresses and port numbers within tcp payload is a 
sure way to break network address translators. it also makes imap 
dependant on ipv4, complicating the transition to ipv6. these are 
two reasons to avoid it altogether.

if ip addresses and ports must be embedded, you should at least 
try to avoid the minor disaster that ftp creates for nat by always 0-
padding the ip address octets and the port so that they always 
come out to exactly the same length. for example, instead of:

tag XFETCH (BINARY CHANNEL=[1.2.3.4]:432) 1 BODY[x.y]

you'd have:

tag XFETCH (BINARY CHANNEL=[001.002.003.004]:00432) 1 
BODY[x.y]

(sorry about the line wrap.)
this will still break nat, of course, but at least it will be easier to 
write a custom nat protocol handler for imap.

"The battle 
 for mental territory 
            is glory. 
            End of story."
                           --KRS-ONE

From: "Caleb Clausen" <[email-masked]>
To: IMAP Extensions WG <[email-masked]>, [email-masked]
Date: Wed, 22 Nov 2000 16:24:35 -0800
Subject: RE: draft-nerenberg-imap-binary-00.txt
Sender: [email-masked]

From:           	Lyndon Nerenberg <[email-masked]>
> > Steve indicated to me last week that he would combine the first two into one
> > proposal.  Do we expect two proposals now?
> 
> Steve's proposal for XFETCH includes support for both binary fetch and
> specifying external transfer channels for a fetch. (Among other
> things.)
> 
> My proposal provides binary fetch (only) for servers that don't want/need
> to support XFETCH.
> 
> The two can live side-by-side. Time will show if BINARY has enough
> support (in the presence of XFETCH) to move forward.

since everyone likes the XFETCH syntax so much better, why not 
do this: have separate capabilities for XFETCH itself, as well as all 
of it's options. so, the XFETCH document would define the following 
capabilities:
XFETCH
XFETCH-BINARY
XFETCH-CHANNEL
XFETCH-CHARSET
etc.

that way, servers which just want to provide a binary version of 
fetch could declare just XFETCH and XFETCH-BINARY. servers 
that want all of it would declare all the XFETCH capabilities.

or is this too great a proliferation of capabilities?

one question: will XFETCH work with the UID command? ie, will i 
be able to say,

tag UID XFETCH (BINARY) 1009 etc...

"The battle 
 for mental territory 
            is glory. 
            End of story."
                           --KRS-ONE

Date: Wed, 22 Nov 2000 15:36:35 -0700 (MST)
From: Lyndon Nerenberg <[email-masked]>
To: Glenn Parsons <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>, [email-masked]
Subject: RE: draft-nerenberg-imap-binary-00.txt
Sender: [email-masked]

> Steve indicated to me last week that he would combine the first two into one
> proposal.  Do we expect two proposals now?

Steve's proposal for XFETCH includes support for both binary fetch and
specifying external transfer channels for a fetch. (Among other
things.)

My proposal provides binary fetch (only) for servers that don't want/need
to support XFETCH.

The two can live side-by-side. Time will show if BINARY has enough
support (in the presence of XFETCH) to move forward.

--lyndon

To: Mark Crispin <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>, [email-masked]
Subject: Re: draft-nerenberg-imap-binary-00.txt 
Date: Tue, 21 Nov 2000 15:38:20 -0700
From: Lyndon Nerenberg <[email-masked]>
Sender: [email-masked]

> Isn't converting QP and BASE64 to BINARY a form of data conversion?

No, it's a change of transport encoding. The contents of the body
part at the client matches the contents of what the sender sent
regardless of where the transport encoding is undone (i.e. at the
client vs. at the server). The decoded data is the same, so it's not
a data conversion.

If, however, the server _also_ does character set manipulations on
the way through, the decoded data at the client might not match what
the sender initially sent. _That_ I consider to be data conversion.

> > I hadn't realized that you and Steve had been discussing this, otherwise
> > I would have held off with BINARY for a bit.

> That's why I was a bit surprised to see your document!  :-)

So was Steve :-)  I apologise for starting all this confusion.

> I suggest some added little token in literal8, perhaps {###}~ instead of {###}
> to indicate its special nature.

I can live with that. If people are okay with the syntax I'll incorporate
that into the next draft. Any suggestions for a modified FETCH...BINARY
syntax while we're at it?

--lyndon

Date: Tue, 21 Nov 2000 14:10:31 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: Re: draft-nerenberg-imap-binary-00.txt 
To: Lyndon Nerenberg <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>, [email-masked]
Sender: [email-masked]

On Tue, 21 Nov 2000 15:08:50 -0700, Lyndon Nerenberg wrote:
> > However, I object strongly to the "BODY[x.y.BINARY]" syntax.
> I'll agree with that. I'm not particularly happy with that syntax either.
> I needed something as a starting point

OK, good.  I'm happy with a stipulation that we're going to fix that.  I don't
want to stand in the way of the functionality, but that particular syntax has
got to go.

> And this is something VPIM originally requested (general conversions). I
> don't like overloading (or combining, I guess) BINARY with data conversion.

Isn't converting QP and BASE64 to BINARY a form of data conversion?

> I hadn't realized that you and Steve had been discussing this, otherwise
> I would have held off with BINARY for a bit.

That's why I was a bit surprised to see your document!  :-)

> I like the XFETCH architecture,
> however I'm not convinced (yet) that a server should have to implement
> external channel support just to get BINARY. At this point I think the
> two are really distinct issues, and should be separate extensions.

OK with me.

My guiding principle (consider XLIST) is that if it's trivial to bundle two
things together and less work than having them separate, then bundle them; but
if there's a reason why someone may want one and not the other, then keep them
separate.

If you feel that BINARY vs. external channel support is the latter, I won't
squawk.  [I'd appreciate the return favor when we talk about XLIST vs.
subscriptions........]

> > XFETCH that would output on the IMAP channel, so the client can
> > distinguish a literal8 from an ordinary literal.
> This shouldn't be necessary. The server will only send a literal8 at
> the specific request of the client, and they will never show up in
> an unsolicited response. It's not a big deal, though. If concensus is
> for a unique syntax for literal8 that's an easy change to make.

Mr. IMAP Architecture says that it's presumptious to say that "they will never
show up in an unsolicited responses."

The presumption may be valid for literal8 (and certainly right now it is), but
it isn't for literal; and that's what creates the ambiguity.  We don't want
the situation where a client gets a literal and thinks that it's a literal8.

I suggest some added little token in literal8, perhaps {###}~ instead of {###}
to indicate its special nature.

From: Lyndon Nerenberg <[email-masked]>
To: [email-masked]
Subject: (resend) Re; BINARY
Date: Tue, 21 Nov 2000 15:21:10 -0700
Sender: [email-masked]

[Sorry folks, this bounced first time around. >> == Mark, > == me.]

>>  The subject draft attempts to fufill a needed requirement for the 
>>VPIM folks.
>
>Initially that was the case, although I certainly think this extension has
>a use outside of that context.
>
>>  However, I object strongly to the "BODY[x.y.BINARY]" syntax.  Unlike other
>>  section specifiers, this one would stipulate a transformation of a section
>>  rather than identify a unique section.  It also adds complexity 
>>(the "terminal
>>  MIME body part" rule) as a side effect of overloading location syntax (the
>>  section specifier) with transformation instructions ("BINARY").
>
>I'll agree with that. I'm not particularly happy with that syntax either.
>I needed something as a starting point (and was under the gun to meet
>the submission deadline, so I didn't have a chance to work out anything
>better), so I went with the syntax in the original VPIM proposal.
>
>>  Furthermore, this extension does not really address the complete need, 
which
>>  is a general ability to transform/deliver message data in extended 
>>forms.  For
>>  example, a streaming application may wish to specify a separate 
>>host/port for
>>  delivery of the data.  It may be desireable to request the server 
>>to transform
>>  text data to UTF-8.
>
>And this is something VPIM originally requested (general conversions). I
>don't like overloading (or combining, I guess) BINARY with data conversion.
>BINARY provides a single piece of functionality: undoing of content
>transfer encodings. This is neutral to the actual content. If there is
>a need to do actual conversion of the underlying data, that should be
>handled separately. Character set conversions (such as your UTF8 example)
>are a bit fuzzy, sitting in between BINARY and general data conversions.
>I'm not sure where that actually fits in, but again I think that's a
>separate issue from BINARY itself.
>
>>  I believe therefore that this functionality belongs in a new command, e.g.
>>  something like
>>	tag XFETCH (BINARY) 1 BODY[x.y]
>>	tag XFETCH (CHARSET=UTF-8) 1 BODY[x.y]
>>	tag XFETCH (BINARY CHANNEL=[1.2.3.4]:432) 1 BODY[x.y]
>>  etc.  These examples are to demonstrate the concept; the exact syntax to be
>>  determined.
>
>I hadn't realized that you and Steve had been discussing this, otherwise
>I would have held off with BINARY for a bit. I like the XFETCH architecture,
>however I'm not convinced (yet) that a server should have to implement
>external channel support just to get BINARY. At this point I think the
>two are really distinct issues, and should be separate extensions. I don't
>think implementing channel necessarily requires the BINARY extensions
>be present. The external channel may already be 8bit clean, and the
>specification for that profile of the channel target mechanism could
>explicitly state that the channel is 8bit clean, therefore there's
>no need for the server to also implement BINARY if the implementer doesn't
>feel it adds significant value. It's still very early in the game, though,
>so I don't consider any of this cast in stone. I'm looking forward to
>seeing a more complete specification for XFETCH.
>
>>  We should also have a syntax for literal8s that are output in the case of 
an
>>  XFETCH that would output on the IMAP channel, so the client can 
>>distinguish a
>>  literal8 from an ordinary literal.  Otherwise there would be an 
>>ambiguity due
>>  to the unsolicited data model of IMAP, and the client would have to depend
>>  upon a command modality that IMAP espressly forbids.
>
>This shouldn't be necessary. The server will only send a literal8 at
>the specific request of the client, and they will never show up in
>an unsolicited response. It's not a big deal, though. If concensus is
>for a unique syntax for literal8 that's an easy change to make.
>
>--lyndon

Date: Tue, 21 Nov 2000 16:52:33 -0500
From: Cyrus Daboo <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: View draft for San Diego
Sender: [email-masked]

I'd like to get an update to the VIEW draft out before the deadline (and 
before the current one expires, though I could just re-sub,it it as it is 
with a change of expiry date).

The debate on VIEW was left somewhat open-ended after the last round of 
discussions on the list (a couple of months ago now). I think the issues 
wrt SORT & THREAD working with VIEW may best be left for the meeting, but a 
couple of issues for VIEW did come out of that round of discussions:

1) VIEW responses are too chatty. The proposal I had to solve this 
(Message-ID: <[email-masked]>) was to collapse 
all the VIEW 'position changed' responses into a single * VIEW response 
with three parts to it:

> Right now we have a * VIEW for each change. We could compress this down
> to a single * VIEW for all changes during the command in progress.
> Something along the lines off:
>
> * VIEW (1:3,5) (10 11 15 16) (1:2,20)
>
> The three groups represent:
>
> 1) View positions of messages removed from the view
> 2) Pairs of view positions for messages moving in the view
> 3) View positions of new messages added to the view
>
> This removes both UIDs and sequence numbers from the original * VIEW
> response.

2) Clients need a way to get the VIEW-UID map so that they can utilise 
existing cached data when changing from one view to another. There was a 
proposal to add a new VIEW WINDOW command that would allow this to work:

tag VIEW WINDOW <start-pos> <end-pos> ... <other options>

This would return a list of message UIDs corresponding to the range of view 
position ids requested. There are some issues about how to make this work 
with threads where the positions may represent different levels of 
hierarchy.

Are there any objections to these changes? Should we just wait until San 
Diego before deciding on ANY changes to VIEW, to allow the issues with SORT 
etc to be resolved first?

-- 
Cyrus Daboo

Date: Tue, 21 Nov 2000 14:46:09 -0700
From: Alexey Melnikov <[email-masked]>
To: Mark Crispin <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: draft-nerenberg-imap-binary-00.txt
Sender: [email-masked]

Oops. Hit Send button too fast. Sorry :-(.

To the best of my knowledge Lyndon will be writing another draft (superset of the
current) that will address VPIM stuff (general ability to transform/deliver message
in a different format or over a different channel). The draft that Lyndon submitted
is generally useful for conserving bandwidth.
It is possible that in the future there will be only a single extension.

Alexey

Date: Tue, 21 Nov 2000 14:41:16 -0700
From: Alexey Melnikov <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: draft-nerenberg-imap-binary-00.txt
Sender: [email-masked]

Mark Crispin wrote:

> The subject draft attempts to fufill a needed requirement for the VPIM folks.
>
> However, I object strongly to the "BODY[x.y.BINARY]" syntax.  Unlike other
> section specifiers, this one would stipulate a transformation of a section
> rather than identify a unique section.  It also adds complexity (the "terminal
> MIME body part" rule) as a side effect of overloading location syntax (the
> section specifier) with transformation instructions ("BINARY").
>
> Furthermore, this extension does not really address the complete need, which
> is a general ability to transform/deliver message data in extended forms.  For
> example, a streaming application may wish to specify a separate host/port for
> delivery of the data.  It may be desireable to request the server to transform
> text data to UTF-8.
>
> I believe therefore that this functionality belongs in a new command, e.g.
> something like
>         tag XFETCH (BINARY) 1 BODY[x.y]
>         tag XFETCH (CHARSET=UTF-8) 1 BODY[x.y]
>         tag XFETCH (BINARY CHANNEL=[1.2.3.4]:432) 1 BODY[x.y]
> etc.  These examples are to demonstrate the concept; the exact syntax to be
> determined.
>
> We should also have a syntax for literal8s that are output in the case of an
> XFETCH that would output on the IMAP channel, so the client can distinguish a
> literal8 from an ordinary literal.  Otherwise there would be an ambiguity due
> to the unsolicited data model of IMAP, and the client would have to depend
> upon a command modality that IMAP espressly forbids.

Date: Tue, 21 Nov 2000 12:58:19 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: draft-nerenberg-imap-binary-00.txt
To: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

The subject draft attempts to fufill a needed requirement for the VPIM folks.

However, I object strongly to the "BODY[x.y.BINARY]" syntax.  Unlike other
section specifiers, this one would stipulate a transformation of a section
rather than identify a unique section.  It also adds complexity (the "terminal
MIME body part" rule) as a side effect of overloading location syntax (the
section specifier) with transformation instructions ("BINARY").

Furthermore, this extension does not really address the complete need, which
is a general ability to transform/deliver message data in extended forms.  For
example, a streaming application may wish to specify a separate host/port for
delivery of the data.  It may be desireable to request the server to transform
text data to UTF-8.

I believe therefore that this functionality belongs in a new command, e.g.
something like
	tag XFETCH (BINARY) 1 BODY[x.y]
	tag XFETCH (CHARSET=UTF-8) 1 BODY[x.y]
	tag XFETCH (BINARY CHANNEL=[1.2.3.4]:432) 1 BODY[x.y]
etc.  These examples are to demonstrate the concept; the exact syntax to be
determined.

We should also have a syntax for literal8s that are output in the case of an
XFETCH that would output on the IMAP channel, so the client can distinguish a
literal8 from an ordinary literal.  Otherwise there would be an ambiguity due
to the unsolicited data model of IMAP, and the client would have to depend
upon a command modality that IMAP espressly forbids.

Date: Fri, 17 Nov 2000 14:56:19 -0700
From: Alexey Melnikov <[email-masked]>
To: Chris Newman <[email-masked]>
CC: Steve Hole <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: LIST Extensions Requirements
Sender: [email-masked]

> > One thing I would ask.   Can you keep track of the individual requirements
> > that progress through the discussion?
>
> I'm too busy to do a good job keeping track of such a list (I only get to
> IMAPEXT every couple weeks).  Furthermore, someone who is more neutral than
> I on some of the controversial issues would be better.  The WG chair or
> document editor would be a better choice, IMHO.

I can try to compile the list if there are no objections.

Alexey

Date: Fri, 17 Nov 2000 12:18:20 -0800
From: Chris Newman <[email-masked]>
To: Steve Hole <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: LIST Extensions Requirements
Sender: [email-masked]

--On Thursday, November 16, 2000 9:46 -0700 Steve Hole 
<[email-masked]> wrote:
> One thing I would ask.   Can you keep track of the individual requirements
> that progress through the discussion?

I'm too busy to do a good job keeping track of such a list (I only get to 
IMAPEXT every couple weeks).  Furthermore, someone who is more neutral than 
I on some of the controversial issues would be better.  The WG chair or 
document editor would be a better choice, IMHO.

		- Chris

Date: Thu, 16 Nov 2000 09:47:23 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: re: RFC 2193 & RFC 2221
To: [email-masked]
cc: [email-masked]
Sender: [email-masked]

On Thu, 16 Nov 2000 12:40:04 -0500, [email-masked] wrote:
> Interested in RFC 2193 IMAP4 Mailbox Referrals & RFC 2221IMAP4 Login
> Referrals.  How well adopted are these ?  What's happening in this area ?

Pine and most other good-quality client implementations fully implement
referrals at the client level.

I am aware of at least two servers which support referrals, either with a full
implementation or with hooks to a local management facility.

From: [email-masked]
To: [email-masked]
Subject: RFC 2193 & RFC 2221
Date: Thu, 16 Nov 2000 12:40:04 -0500
Sender: [email-masked]

This is a multipart message in MIME format.
--=_alternative 0060C73E85256999_=
Content-Type: text/plain; charset="us-ascii"

All,   
Interested in RFC 2193 IMAP4 Mailbox Referrals & RFC 2221IMAP4 Login 
Referrals.  How well adopted are these ?  What's happening in this area ? 
Any assistance would be greatly appreciated. 

Cynthia Mamacos
Lotus Development Corp.

--=_alternative 0060C73E85256999_=
Content-Type: text/html; charset="us-ascii"

<br><font size=2 face="sans-serif">All, &nbsp;</font><font size=3> <br>
</font><font size=2 face="sans-serif">Interested in RFC 2193 IMAP4 Mailbox Referrals &amp; RFC 2221IMAP4 Login Referrals. &nbsp;How well adopted are these ? &nbsp;What's happening in this area ?</font><font size=3> </font><font size=2 face="sans-serif"><br>
Any assistance would be greatly appreciated.</font><font size=3> <br>
</font>
<br><font size=2 face="sans-serif">Cynthia Mamacos<br>
Lotus Development Corp.<br>
</font>
--=_alternative 0060C73E85256999_=--

From: Steve Hole <[email-masked]>
Date: Thu, 16 Nov 2000 09:46:01 -0700
To: Chris Newman <[email-masked]>
Subject: Re: LIST Extensions Requirements
Cc: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

On Wed, 15 Nov 2000 12:04:59 -0800 Chris Newman <[email-masked]>
wrote:

>  Here's a first shot at requirements for the "XLIST" command.  This is a
>  brainstorm of ideas I recall being mentioned or have thought about, so
>  please don't assume you know my position just because an item showed up
>  in the list.

Looks good Chris.   There are things that I would like to discuss about
the namespace issues and reference arguments, but that should wait for a
face-to-face.

One thing I would ask.   Can you keep track of the individual requirements
that progress through the discussion?    I think that we want to collect a
requirements table that lists all the requirements that people propose,
along with a state that is one of:

  Accepted   - concensus to include as a requirement
  Rejected   - concensus to reject as a requirement
  Discussion - further discussion required to reach accept or reject
  Proposed   - proposed requirement but no discussion had yet

There are probably other states, but that should do for a starter.   If
you can't, then can someone else do this?   It will greatly improve our
ability to have a rational design discussion if we avoid rehashing things
that we have already reached concensus on.

Good work Chris.

Cheers.

---
Steve Hole
Chief Technical Officer
Messaging Direct
Mailto:[email-masked]
Phone: 780-424-4922

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-thread-05.txt
Date: Thu, 16 Nov 2000 06:28:09 -0500
Sender: [email-masked]

--NextPart

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

	Title		: INTERNET MESSAGE ACCESS PROTOCOL - THREAD EXTENSION
	Author(s)	: M. Crispin, K. Murchison
	Filename	: draft-ietf-imapext-thread-05.txt
	Pages		: 13
	Date		: 15-Nov-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-05.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-05.txt".

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-imapext-thread-05.txt

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

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

--OtherAccess--

--NextPart--

Date: Wed, 15 Nov 2000 14:54:58 -0800
From: Chris Newman <[email-masked]>
To: Simon Josefsson <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: LIST Extensions Requirements
Sender: [email-masked]

--On Wednesday, November 15, 2000 23:21 +0100 Simon Josefsson 
<[email-masked]> wrote:
> * It must not break old mailbox names -- if `/' is the new delimiter
>   there must be a way to escape `/' within a mailbox name.

That's not a requirement for XLIST, IMHO.  If you want to use "/" as a 
character in a mailbox names, then don't implement XLIST.

> * Because escaping might be ugly, I suggest that we could consider a
>   delimiter agnostic solution -- * XLIST ... "INBOX" "whatever"
>   "whatother"

I'd rather not.  That's too much work to parse, manage and map to URL 
semantics (which use "/" as the one true delimiter).

> * I feel the "display delimiter" might be as complicated as the
>   current delimiter situation, is it really worth having?

I'd prefer to do without it, but it's certainly simpler than the status quo 
where a client has to support all delimiters (including NIL) and translate 
mailbox names accordingly.  With a "display delimiter", the majority of 
clients which use hierarchy don't care, only those which display full paths 
to mailboxes need to worry about it.

> * Permit a facility to discover mailboxes with newly arrived mail

How do you define "newly arrived mail"?  Mailboxes with unseen messages? 
Or Mailboxes with \Recent messages (meaning messages have arrived since the 
last time you or perhaps someone else selected the mailbox).

>> * Layered facility for virtual scrollbars in very large mailbox list
>>    (e.g. #news/alt/%)
>>
>> * Limit on number of returned mailboxes (with limit exceeded notice)
>
> IMHO these should be optional and only used upon client request.

For the former I'd agree.  For the later, I'd actually be tempted to force 
clients to always specify the maximum number of returned mailboxes they can 
deal with.  I'm sick and tired of clients that crash or hang my machine 
when I point them at a server with too many mailboxes.

		- Chris

Date: Wed, 15 Nov 2000 14:28:59 -0800
From: Chris Newman <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: re: LIST Extensions Requirements
Sender: [email-masked]

--On Wednesday, November 15, 2000 12:14 -0800 Mark Crispin 
<[email-masked]> wrote:
> Server MUST be able to refuse LSUB or STATUS functionality.  Consequently
> extended LIST will never deprecate LSUB or STATUS, and clients MUST be
> able to use LSUB and STATUS.

That point is controversial and I doubt further debate on the list would be 
productive.  I _suggest_ resolving face to face.

> This has the potential to be a major rathole.  Suggest that debate on
> this be deferred to the end and/or be time-limited ahead of time.
>
> I believe that "generic extensible command" is a solution in search of a
> problem.

I concur.  I don't mind people structuring the command using some sort of 
extensible command model, as long as it isn't a separate document and 
doesn't waste a lot of time.

>> * Only permit "/" as delimiter in new list command.
>
> How does this interact with newsgroups?
>
> How did URLs solve the problem?  Did they make the newsgroup namespace
> flat? I don't think that #news/comp/mail/misc will please the users, but
> maybe #news/comp.mail.misc is OK.  This would make % equivalent to *, but
> as a practical matter this seems to be how many clients treat news anyway.

The newsgroup namespace is flat in URLs (news:<groupname>).  I suspect 
that's the right answer.

>> * Always use UTF-8 in new list command.
>
> Yes, definitely.

That was my thought at first, but now I'm unsure.  If UTF-8 shows up in 
mailbox names from extended list, then SELECT, CREATE, DELETE, etc. all 
have to support UTF-8.  Should the presence of the extended LIST modify the 
behavior of other commands?  I'd like to see more discussion.  Perhaps use 
of UTF-8 is inherently orthogonal to extended list and thus has to be a 
separate independent extension (unfortunately)?

>> * Permit a facility to discover newly created mailboxes.
>> * Permit a facility to discover newly deleted mailboxes.
>> * Permit a facility to discover mailboxes which have changed
>>    since last disconnected synchronization.
>> * Layered facility for virtual scrollbars in very large mailbox list
>>    (e.g. #news/alt/%)
>
> ...Umm...as long as it is server-optional.

That's the direction I lean as well.  But IMAP's lack of the ability to get 
a list of newly created newsgroups is the major protocol reason people 
won't migrate from NNTP to IMAP for client access, so I hope most servers 
will choose to implement that facility.

> ... due to the incorrect implementation in Cyrus;

The Cyrus implementation was done in good faith and complied with RFC 2060. 
John and I had a long discussion of what is a "breakout" character in a 
news-style namespace.  The conclusion we came to was that when a user types 
"comp.sys.mac" they are always referring to a top-level news folder.  News 
didn't have a way to refer to relative namespaces, but the obvious choice 
was to use a "." prefix for relative names, since names lacking a prefix 
"." were absolute.  We were trying our best to interpret the reference 
argument reasonably given the namespace semantics we were using.

When URLs came along and made Unix path semantics the standard path 
semantics for the Internet, our interpretation (and choice of path 
delimiter) became inappropriate.  When Pine came along and used the 
reference argument in a way we didn't expect, it failed to interoperate 
with Cyrus.  The best fix at that point was to change Cyrus (and derivative 
servers) to match the URL path semantics which Pine assumed.

		- Chris

To: Chris Newman <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
Subject: Re: LIST Extensions Requirements
From: Simon Josefsson <[email-masked]>
Date: 15 Nov 2000 23:21:41 +0100
Lines: 35
Sender: [email-masked]

Some random thoughts about some of the issues...

> * Only permit "/" as delimiter in new list command.
>    (Possibly have "display delimiter" attribute for clients that display
>    full mailbox names).

* It must not break old mailbox names -- if `/' is the new delimiter
  there must be a way to escape `/' within a mailbox name.

* Because escaping might be ugly, I suggest that we could consider a
  delimiter agnostic solution -- * XLIST ... "INBOX" "whatever" "whatother"

* I feel the "display delimiter" might be as complicated as the
  current delimiter situation, is it really worth having?

> * Permit a facility to discover newly created mailboxes.
> 
> * Permit a facility to discover newly deleted mailboxes.
> 
> * Permit a facility to discover mailboxes which have changed
>    since last disconnected synchronization.

I'll add another idea:

* Permit a facility to discover mailboxes with newly arrived mail

> * Layered facility for virtual scrollbars in very large mailbox list
>    (e.g. #news/alt/%)
> 
> * Limit on number of returned mailboxes (with limit exceeded notice)

IMHO these should be optional and only used upon client request.

Thanks

Date: Wed, 15 Nov 2000 12:14:45 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: re: LIST Extensions Requirements
To: Chris Newman <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

On Wed, 15 Nov 2000 12:04:59 -0800, Chris Newman wrote:
> * The command should be structured so that clients only request the
>   information they really need and will actually use.

Yes, definitely

> * New list command subsumes functionality of LIST, LSUB, RLIST, RLSUB and
>   STATUS commands.

Server MUST be able to refuse LSUB or STATUS functionality.  Consequently
extended LIST will never deprecate LSUB or STATUS, and clients MUST be able to
use LSUB and STATUS.

> * New list command subsumes child mailbox functionality.
> * The command should have the option of returning ACL and myrights
>   information for mailboxes.
> * The command should support mailbox annotations
> * Avoid silly states.  Use tri-state or multi-state variables instead of
>   interrelated flags to avoid them.

All these are fine.

> * Design around a "generic extensible command" model

This has the potential to be a major rathole.  Suggest that debate on this be
deferred to the end and/or be time-limited ahead of time.

I believe that "generic extensible command" is a solution in search of a
problem.

> * Only permit "/" as delimiter in new list command.

How does this interact with newsgroups?

How did URLs solve the problem?  Did they make the newsgroup namespace flat?
I don't think that #news/comp/mail/misc will please the users, but maybe
#news/comp.mail.misc is OK.  This would make % equivalent to *, but as a
practical matter this seems to be how many clients treat news anyway.

> * Always use UTF-8 in new list command.

Yes, definitely.

> * Permit a facility to discover newly created mailboxes.
> * Permit a facility to discover newly deleted mailboxes.
> * Permit a facility to discover mailboxes which have changed
>    since last disconnected synchronization.
> * Layered facility for virtual scrollbars in very large mailbox list
>    (e.g. #news/alt/%)

...Umm...as long as it is server-optional.

> * Limit on number of returned mailboxes (with limit exceeded notice)

Yes.

> * Way to request Quota information?

Need review/overhaul of existing QUOTA specification.

> * Don't include the reference argument in the replacement list command
>   (only using the "/" delimiter is the prerequisite for this).

No.

The only way to avoid the reference argument is to have a CWD command in IMAP.

The last time this issue came up it wasted at least a year of everybody's time
several years ago.  It wasted time again a few years later due to the
incorrect implementation in Cyrus; fortunately that is now fixed, and we had
to leave a monument in RFC 2683 as to why the old Cyrus implementation was
incorrect.  However, in the meantime many users of Cyrus IMAP servers were
inconvenienced.

Reviving this dead issue will waste everybody's time all over again, and with
many people this time the potential time wasted is worse than a year.

>   Explicitly note for clients that permit users to type a mailbox
>   name in context that if a user refers to ~/... or ~user/..., that
>   is likely shorthand for the Personal or Other Users namespaces
>   respectively.

That proposal would create a UNIX-centric kludge.  The need for context is
wider than UNIX, and as such these kludges would need to be specified for
every operating system (and future operating systems).

The reference argument solves the problem, in a far simpler and cleaner way
than such kludges.  The reference argument also has the advantage of being in
the IMAP base today.  Let's leave it alone.

> * What should be required for the base list replacement command

If it is a "LIST replacement", then it must NOT replace LSUB or STATUS.

Date: Wed, 15 Nov 2000 12:04:59 -0800
From: Chris Newman <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: LIST Extensions Requirements
Sender: [email-masked]

Here's a first shot at requirements for the "XLIST" command.  This is a
brainstorm of ideas I recall being mentioned or have thought about, so
please don't assume you know my position just because an item showed up in
the list.

Believed Non-Controversial Requirements:
----------------------------------------

* The command should be structured so that clients only request the
  information they really need and will actually use.

   * Clients which don't need subscription flag won't ask for it.
   * Clients which care about remote mailboxes, but don't need referrals
     until select time can request that.

* New list command subsumes functionality of LIST, LSUB, RLIST, RLSUB and
  STATUS commands.

   CAVEAT:  Controversy exists as to what set of these should be required as
   part of the XLIST base spec and which ones should be layered XLIST
   extensions with their own capability string.

* New list command subsumes child mailbox functionality.

* The command should have the option of returning ACL and myrights
  information for mailboxes.

* The command should support mailbox annotations

   CAVEAT: per-user and shared issue will rear its ugly head.  As will
   annotation namespace issue.

* Avoid silly states.  Use tri-state or multi-state variables instead of
  interrelated flags to avoid them.

* Design around a "generic extensible command" model that could be applied 
to
  other IMAP command extension situtations.

   CAVEAT: Controversy over whether "generic extensible command" model 
should
   be a separate standard.

Ideas for requirements which need debate:
-----------------------------------------

* Only permit "/" as delimiter in new list command.
   (Possibly have "display delimiter" attribute for clients that display
   full mailbox names).

* Always use UTF-8 in new list command.

* Permit a facility to discover newly created mailboxes.

* Permit a facility to discover newly deleted mailboxes.

* Permit a facility to discover mailboxes which have changed
   since last disconnected synchronization.

* Layered facility for virtual scrollbars in very large mailbox list
   (e.g. #news/alt/%)

* Limit on number of returned mailboxes (with limit exceeded notice)

* Way to request Quota information?

* Don't include the reference argument in the replacement list command
  (only using the "/" delimiter is the prerequisite for this).
  Explicitly note for clients that permit users to type a mailbox
  name in context that if a user refers to ~/... or ~user/..., that
  is likely shorthand for the Personal or Other Users namespaces
  respectively.

Controversial requirement ideas:
--------------------------------

* What should be required for the base list replacement command, as opposed
  to extensions to the list replacement command?

   Proposed litmus test: If it is common practice for IMAP clients to
   kludge around a deficiency in the LIST/LSUB/etc suite, then that
   facility should be part of the base XLIST command.  For example, many
   clients currently do "LIST "" %" and "LIST "" %/%" when \HasChildren
   information isn't available.  When XLIST is implemented this kludge
   should never be necessary.

   Additional litmus test: If there's a reasonable trivial implemention to
   comply, then include it in the XLIST base spec.  For example, a
   non-referral IMAP server can support clients that request referrals
   simply by never returning any.

   Anything not meeting one of these litmus tests should be an XLIST
   extension.

* Have "generic extensible command" model as a separate standard.

		- Chris

Date: Sat, 4 Nov 2000 15:26:43 -0500
To: "RL 'Bob' Morgan" <[email-masked]>
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <[email-masked]>
Subject: RE: moderate or restrict IMAPEXT
Cc: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

At 10.17 -0800 00-11-04, RL 'Bob' Morgan wrote:
>Having seen this issue go by on several mailing lists, and seen more or
>less the same answer be suggested, I wonder whether this wisdom is
>captured anywhere official?

http://www.ietf.org/IESG/STATEMENTS/moderated-lists.txt

    paf

>
>  - RL "Bob"
>
>>  As an IESG member which _IS_ subscribed to the list, let me explain
>>  what we normally say in these cases:
>>
>>  This is the algorithm which we think is ok:
>>
>>    IF the sender address is subscribed to the mailing list, OR
>>       on a special list for "approved subscribers" THEN
>>        Send the mail to the mailing list
>>    ELSE
>>       forward the mail to a human
>>       IF the mail is spam THEN
>>          >/dev/null
>>       FI
>>       IF the mail is not according to list policy THEN
>>          return message to sender, informing of what happened
>>       FI
>>       forward the mail to the mailing list
>>    FI
>>
>>  I.e. filtering is ok, but you need a human which manually takes care
>>  of rejected messages.

Date: Sat, 4 Nov 2000 12:49:56 -0600
To: IMAP Extensions WG <[email-masked]>
From: "RL 'Bob' Morgan" (<[email-masked]>) <[email-masked]>
Subject: RE: moderate or restrict IMAPEXT
Sender: [email-masked]

Having seen this issue go by on several mailing lists, and seen more or
less the same answer be suggested, I wonder whether this wisdom is
captured anywhere official?

  - RL "Bob"

>  As an IESG member which _IS_ subscribed to the list, let me explain
>  what we normally say in these cases:
>
>  This is the algorithm which we think is ok:
>
>    IF the sender address is subscribed to the mailing list, OR
>       on a special list for "approved subscribers" THEN
>        Send the mail to the mailing list
>    ELSE
>       forward the mail to a human
>       IF the mail is spam THEN
>          >/dev/null
>       FI
>       IF the mail is not according to list policy THEN
>          return message to sender, informing of what happened
>       FI
>       forward the mail to the mailing list
>    FI
>
>  I.e. filtering is ok, but you need a human which manually takes care
>  of rejected messages.

Date: Sat, 4 Nov 2000 12:48:41 -0600
To: [email-masked]
From: Lawrence Greenfield (<[email-masked]>) <[email-masked]>
Subject: Re: comments on LIST extensions
Sender: [email-masked]

    From: "Mike Gahrns" <[email-masked]>
    Cc: <[email-masked]>
    Date: Fri, 3 Nov 2000 16:18:33 -0800

[...]
    How about something like the following?

    3a) tag LIST "" % (REMOTE)
    includes in the LIST response folders that are remote and somehow marked as
    such in the LIST response

    3b)tag LIST "" % (REFERRAL)
    include in the LIST response folders that are remote along with their remote
    URL referral data

    However, I am somewhat unsure as to the scenario where it would be desirable
    for the client to request to have the folder's referral URL returned to it
    in the LIST command, rather than obtaining this info on demand when needed
    during the SELECT command.

I really want advisory referrals---I have a server that will silently
proxy for non-referral aware clients and handout referrals to clients
that execute an RLIST or RLSUB (yes, it's a mode, and yes, it's an
ugly hack).

So I'd like the way that referrals are discovered to happen before a
SELECT---even an advisory referral on SELECT will require my proxy
server to open a connection to the backend server, to give the rest of
the data on SELECT.

Larry

Date: Sat, 4 Nov 2000 12:25:06 -0500
From: Lawrence Greenfield <[email-masked]>
To: Mike Gahrns <[email-masked]>
Cc: [email-masked]
Subject: Re: comments on LIST extensions
Sender: [email-masked]

   From: "Mike Gahrns" <[email-masked]>
   Cc: <[email-masked]>
   Date: Fri, 3 Nov 2000 16:18:33 -0800

[...]
   How about something like the following?

   3a) tag LIST "" % (REMOTE)
   includes in the LIST response folders that are remote and somehow marked as
   such in the LIST response

   3b)tag LIST "" % (REFERRAL)
   include in the LIST response folders that are remote along with their remote
   URL referral data

   However, I am somewhat unsure as to the scenario where it would be desirable
   for the client to request to have the folder's referral URL returned to it
   in the LIST command, rather than obtaining this info on demand when needed
   during the SELECT command.

I really want advisory referrals---I have a server that will silently
proxy for non-referral aware clients and handout referrals to clients
that execute an RLIST or RLSUB (yes, it's a mode, and yes, it's an
ugly hack).

So I'd like the way that referrals are discovered to happen before a
SELECT---even an advisory referral on SELECT will require my proxy
server to open a connection to the backend server, to give the rest of
the data on SELECT.

Larry

Date: Sat, 4 Nov 2000 11:23:44 -0600
To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=  <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: RE: moderate or restrict IMAPEXT
Cc: "Eric Burger" <[email-masked]>, "Mark Crispin" <[email-masked]>, "IMAP Extensions WG" <[email-masked]>
Sender: [email-masked]

On 11/4/00 at 12:19 PM -0500, Patrik Fältström wrote:

>I.e. filtering is ok, but you need a human which manually takes care 
>of rejected messages.

Yes, I got e-mail from Paul (our list manager), and what you describe 
is exactly what we will do.

pr

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

Date: Sat, 4 Nov 2000 12:19:21 -0500
To: Pete Resnick <[email-masked]>, "Eric Burger" <[email-masked]>
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <[email-masked]>
Subject: RE: moderate or restrict IMAPEXT
Cc: "Mark Crispin" <[email-masked]>, "IMAP Extensions WG" <[email-masked]>
Sender: [email-masked]

At 16.54 -0600 00-11-03, Pete Resnick wrote:
>On 11/3/00 at 5:38 PM -0500, Eric Burger wrote:
>
>>What if we just limit posting to subscribers?  That reduces the chance of an
>>amature spammer succeeding, without the pain for the moderator.
>
>And it would proceed to disallow people like IESG members and others 
>who don't subscribe to the list from posting. I heavily object to 
>that. I'll moderate if we can work that out.

As an IESG member which _IS_ subscribed to the list, let me explain 
what we normally say in these cases:

This is the algorithm which we think is ok:

  IF the sender address is subscribed to the mailing list, OR
     on a special list for "approved subscribers" THEN
      Send the mail to the mailing list
  ELSE
     forward the mail to a human
     IF the mail is spam THEN
        >/dev/null
     FI
     IF the mail is not according to list policy THEN
        return message to sender, informing of what happened
     FI
     forward the mail to the mailing list
  FI

I.e. filtering is ok, but you need a human which manually takes care 
of rejected messages.

      Patrik

From: "Mike Gahrns" <[email-masked]>
To: "Mark Crispin" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: comments on LIST extensions
Date: Fri, 3 Nov 2000 16:18:33 -0800
Sender: [email-masked]

Mark Crispin writes:
>So, would it work for you that:
>
> 1) tag LIST "" %
>  does not include referral mailboxes
>
> 2) tag RLIST "" %
>   tag LIST "" % ()
>   include referral mailboxes, but do not return referal data
>
> 3) tag LIST "" % (REFERRAL)
>   include referral mailboxes and return referral data

*** If we went the LIST extension route,  I think I would like to see RLIST
eventually deprecated.
As such, I think there would need to be a way to get just the list of remote
mailboxes, and not their remote url location for the perf reasons I
mentioned in my previous post.  The remote url location for can be easily
obtained via SELECT, and saves having the server need to supply the info on
a potentially large number of folders that may never be accessed during the
session.  (Hopefully clients smart enough to use this extension would not be
blindly getting a whole public folder tree, but none-the-less it would still
be common to have potentially hundreds of folders in a single level of
hierarchy.)

How about something like the following?

3a) tag LIST "" % (REMOTE)
includes in the LIST response folders that are remote and somehow marked as
such in the LIST response

3b)tag LIST "" % (REFERRAL)
include in the LIST response folders that are remote along with their remote
URL referral data

However, I am somewhat unsure as to the scenario where it would be desirable
for the client to request to have the folder's referral URL returned to it
in the LIST command, rather than obtaining this info on demand when needed
during the SELECT command.

From: "Eric Burger" <[email-masked]>
To: "Pete Resnick" <[email-masked]>, "Mark Crispin" <[email-masked]>
Cc: "IMAP Extensions WG" <[email-masked]>
Subject: RE: moderate or restrict IMAPEXT
Date: Fri, 3 Nov 2000 18:49:53 -0500
Importance: Normal
Sender: [email-masked]

What if we just limit posting to subscribers?  That reduces the chance of an
amature spammer succeeding, without the pain for the moderator.

--
- Eric

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Pete Resnick
Sent: Friday, November 03, 2000 1:24 PM
To: Mark Crispin
Cc: IMAP Extensions WG
Subject: Re: moderate or restrict IMAPEXT

On 11/3/00 at 9:48 AM -0800, Mark Crispin wrote:

>Please establish moderation on IMAPEXT

Paul, I'm perfectly willing to do this if you have a method. If we
can use IMAP mailboxes to do this (perhaps an incoming IMAP mailbox
on your server that I moderate and transfer to another mailbox on
your server that you send out to the list), it would be perfectly
easy for me.

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

Date: Fri, 3 Nov 2000 15:16:34 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: Re: comments on LIST extensions
To: Mike Gahrns <[email-masked]>
cc: Barry Leiba <[email-masked]>, [email-masked]
Sender: [email-masked]

On Fri, 3 Nov 2000 14:38:42 -0800, Mike Gahrns wrote:
> *** For Exchange, there will be some hit in getting the referral data.
> Probably not devasting, but likely noticeable in the time it takes the LIST
> response to come back.  From a general design point of view, it is probably
> best to not include the referral details in a response.  Why generate this
> info until it is needed?  Not to mention sending the extra info across the
> wire, (which if there are multiple replicas could get large).

So, would it work for you that:

1) tag LIST "" %
   does not include referral mailboxes

2) tag RLIST "" %
   tag LIST "" % ()
   include referral mailboxes, but do not return referal data

3) tag LIST "" % (REFERRAL)
   include referral mailboxes and return referral data

Date: Fri, 3 Nov 2000 15:10:20 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: Re: comments on LIST extensions
To: Mike Gahrns <[email-masked]>
cc: [email-masked]
Sender: [email-masked]

On Fri, 3 Nov 2000 14:01:57 -0800, Mike Gahrns wrote:
> How did you envision your suggestion working?

Assuming that the LIST command is extended with a third argument, containing a
parenthesized list of additional attributes desired, then:

A two-argument LIST command will work as now; it may have expansion attributes
in the response but will never return additional data.

A three-argument LIST command will result in responses that include referral
messages and possibly also referral data.

The replacement for RLIST is a three-argument LIST with zero members in the
additional attribute list.

Date: Fri, 03 Nov 2000 18:08:37 -0500
From: Cyrus Daboo <[email-masked]>
To: Pete Resnick <[email-masked]>, Eric Burger <[email-masked]>
cc: Mark Crispin <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: RE: moderate or restrict IMAPEXT
Sender: [email-masked]

--On Friday, November 3, 2000 4:54 PM -0600 Pete Resnick 
<[email-masked]> wrote:

>> What if we just limit posting to subscribers?  That reduces the chance
>> of an amature spammer succeeding, without the pain for the moderator.
>
> And it would proceed to disallow people like IESG members and others who
> don't subscribe to the list from posting. I heavily object to that. I'll
> moderate if we can work that out.

Also a number of us don't subscribe directly but instead pipe the list into 
a shared imap mailbox via a specific email address - one of the many useful 
features of IMAP!

-- 
Cyrus Daboo

From: "Mike Gahrns" <[email-masked]>
To: "Barry Leiba" <[email-masked]>, <[email-masked]>
Subject: Re: comments on LIST extensions
Date: Fri, 3 Nov 2000 14:38:42 -0800
Sender: [email-masked]

Barry Leiba writes:
> The only concern I have here is that a referral-capable server might
> know quickly that a mailbox is remote, but might have a slower time
> actually retrieving the referral information.  So there *might* be some
use
> in letting the server tell you "this mailbox exists somewhere else", but
> not actually tell you *where* until you try to do something with it (if,
> for example, there are 50 remote mailboxes and it takes 1 second to
> retrieve the referral data for each, adding 50 seconds to the LIST
> (REFERRALS) command would be bad, and it might be better to make you try
> a SELECT when you actually want to use one of them).  Do any servers
> besides Exchange support mailbox referrals now?  How fast is it for
Exchange (or
> other servers) to retrieve the referral details?
*** For Exchange, there will be some hit in getting the referral data.
Probably not devasting, but likely noticeable in the time it takes the LIST
response to come back.  From a general design point of view, it is probably
best to not include the referral details in a response.  Why generate this
info until it is needed?  Not to mention sending the extra info across the
wire, (which if there are multiple replicas could get large).

Date: Fri, 3 Nov 2000 16:54:04 -0600
To: "Eric Burger" <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: RE: moderate or restrict IMAPEXT
Cc: "Mark Crispin" <[email-masked]>, "IMAP Extensions WG" <[email-masked]>
Sender: [email-masked]

On 11/3/00 at 5:38 PM -0500, Eric Burger wrote:

>What if we just limit posting to subscribers?  That reduces the chance of an
>amature spammer succeeding, without the pain for the moderator.

And it would proceed to disallow people like IESG members and others 
who don't subscribe to the list from posting. I heavily object to 
that. I'll moderate if we can work that out.

pr

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

From: "Eric Burger" <[email-masked]>
To: "Pete Resnick" <[email-masked]>, "Mark Crispin" <[email-masked]>
Cc: "IMAP Extensions WG" <[email-masked]>
Subject: RE: moderate or restrict IMAPEXT
Date: Fri, 3 Nov 2000 17:38:58 -0500
Importance: Normal
Sender: [email-masked]

What if we just limit posting to subscribers?  That reduces the chance of an
amature spammer succeeding, without the pain for the moderator.

--
- Eric

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Pete Resnick
Sent: Friday, November 03, 2000 1:24 PM
To: Mark Crispin
Cc: IMAP Extensions WG
Subject: Re: moderate or restrict IMAPEXT

On 11/3/00 at 9:48 AM -0800, Mark Crispin wrote:

>Please establish moderation on IMAPEXT

Paul, I'm perfectly willing to do this if you have a method. If we
can use IMAP mailboxes to do this (perhaps an incoming IMAP mailbox
on your server that I moderate and transfer to another mailbox on
your server that you send out to the list), it would be perfectly
easy for me.

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

From: "Mike Gahrns" <[email-masked]>
To: "Mark Crispin" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: comments on LIST extensions
Date: Fri, 3 Nov 2000 14:01:57 -0800
Sender: [email-masked]

Mark Crispin writes:
> My idea was that you would not show referrals unless you asked for
referral
> information in the extended LIST.
This could work.  My assumptions were that the extended LIST info would be
always coming back.

How did you envision your suggestion working?

Are you proposing a command to turn on extend LIST responses, or a command
to include referral info in an extended LIST response?  This seems like it
would be adding "modes" to IMAP, which I thought there were strong
objections to in the past...

With a command like XLIST, it was explicit that the client was requesting
this additional info and had to be prepared to handle it.

Date: Fri, 3 Nov 2000 13:53:07 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: Re: comments on LIST extensions
To: Mike Gahrns <[email-masked]>
cc: Steve Hole <[email-masked]>, Tony Hansen <[email-masked]>, Barry Leiba <[email-masked]>, [email-masked]
Sender: [email-masked]

On Fri, 3 Nov 2000 13:51:06 -0800, Mike Gahrns wrote:
> *** One drawback of extending LIST through upwards-compatible syntax instead
> of creating a new command like XLIST,  is that it will create problems in
> the referral case.

My idea was that you would not show referrals unless you asked for referral
information in the extended LIST.

From: "Mike Gahrns" <[email-masked]>
To: "Mark Crispin" <[email-masked]>, "Steve Hole" <[email-masked]>
Cc: "Tony Hansen" <[email-masked]>, "Barry Leiba" <[email-masked]>, <[email-masked]>
Subject: Re: comments on LIST extensions
Date: Fri, 3 Nov 2000 13:51:06 -0800
Sender: [email-masked]

Mark Crispin writes:
> I am not yet convinced that we can not extend LIST through
upwards-compatible
> syntax.  Shouldn't we proceed as if we can do so, with the understanding
that
> XLIST is not out of the question if we hit an otherwise insurmountable
> obstacle?
*** One drawback of extending LIST through upwards-compatible syntax instead
of creating a new command like XLIST,  is that it will create problems in
the referral case.  Even if we add referral info in a LIST response that
presumably would be ignored by non-referral enabled clients, these
non-referral enabled clients would still likely show these remote folders to
their users.  This was deemed undesirable during the initial referral
discussions.  e.g.  The user experience would be bad in that users would try
to select these remote folders, and have the SELECT command fail when
accessed.

Date: Fri, 3 Nov 2000 13:43:57 -0600
To: Barry Leiba <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: comments on LIST extensions
Cc: [email-masked]
Sender: [email-masked]

On 11/3/00 at 2:26 PM -0500, Barry Leiba wrote:

>OK, then... since all the discussions about what XLIST might be have 
>so far been ad hoc discussion among a few of us, why don't we get 
>some time on the agenda at San Diego and have a proper discussion of 
>it.  I'll take that discussion and come up with a first pass at the 
>requirements, and then we can discuss it further on the mailing list.
>
>If that's the way everyone wants to go, then I'll not make any 
>updates to the LIST Extensions draft now, and the next revision will 
>just be the first draft of the new XLIST command.  Shall we do it 
>that way?

Barry, I am more inclined to have you write *something* before the 
meeting if you can, even if it is just a straw man to bat around.

We've still got two weeks to discuss this a bit on the list and maybe 
get Barry enough stuff to throw into an I-D before the November 17 
deadline. If we can't, such is life, but let's see what we can do. In 
either case, this will still be an important item on the agenda.

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

Date: Fri, 3 Nov 2000 12:24:02 -0600
To: Mark Crispin <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: moderate or restrict IMAPEXT
Cc: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

On 11/3/00 at 9:48 AM -0800, Mark Crispin wrote:

>Please establish moderation on IMAPEXT

Paul, I'm perfectly willing to do this if you have a method. If we 
can use IMAP mailboxes to do this (perhaps an incoming IMAP mailbox 
on your server that I moderate and transfer to another mailbox on 
your server that you send out to the list), it would be perfectly 
easy for me.

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

Date: Fri, 03 Nov 2000 14:26:16 -0500
From: Barry Leiba <[email-masked]>
To: [email-masked]
Subject: Re: comments on LIST extensions
Sender: [email-masked]

> Mark is right, we need a set of requirements that we can get concensus on.
> From there we can design the thing we want.

OK, then... since all the discussions about what XLIST might be have so far 
been ad hoc discussion among a few of us, why don't we get some time on the 
agenda at San Diego and have a proper discussion of it.  I'll take that 
discussion and come up with a first pass at the requirements, and then we 
can discuss it further on the mailing list.

If that's the way everyone wants to go, then I'll not make any updates to 
the LIST Extensions draft now, and the next revision will just be the first 
draft of the new XLIST command.  Shall we do it that way?

Barry Leiba, Living Lab Services  ([email-masked])
http://www.research.ibm.com/people/l/leiba

Date: Fri, 3 Nov 2000 10:46:54 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: Re: comments on LIST extensions
To: Steve Hole <[email-masked]>
cc: Tony Hansen <[email-masked]>, Barry Leiba <[email-masked]>, [email-masked]
Sender: [email-masked]

Obviously, base LIST and LSUB have to be left alone.  However, base LIST and
LSUB does have an extension mechanism for attributes, so the server can utter
extraneous attributes to a base client.

I am not yet convinced that we can not extend LIST through upwards-compatible
syntax.  Shouldn't we proceed as if we can do so, with the understanding that
XLIST is not out of the question if we hit an otherwise insurmountable
obstacle?

Unless I'm completely off-base, there are three things that need to be done:
 1) Add additional attributes.  Completely compatible with base spec.
 2) Add additional arguments to LIST command.  Must be governed by capability.
 3) Add additional return values to LIST response.  Must be governed by use of
    an extended LIST command from (2).

Whether or not we also do XLIST, I think that we should do these steps to
LIST.

From: Steve Hole <[email-masked]>
Date: Fri, 3 Nov 2000 11:41:48 -0700
To: Mark Crispin <[email-masked]>
Subject: Re: comments on LIST extensions
Cc: Tony Hansen <[email-masked]>, Barry Leiba <[email-masked]>, [email-masked]
Sender: [email-masked]

On Fri, 3 Nov 2000 10:12:18 -0800 (PST) Mark Crispin 
<[email-masked]> wrote:

> Leaving aside the issue of LIST vs. XLIST, I recommend that there be a
> statement or position paper about these "actual requirements."
> 
> This is to ensure that we are all on the same wavelength.  What you feel that
> "we have learned" may be very different from what people here that "we have
> learned."
> 
> Having created and agreed to such a list, we should use that list in the
> resulting design.  We get into trouble when we don't have a fixed (and mutual)
> statement of requirements.

Sounds good to me.

> This statement scares me.  Backward compatibility is a good thing, and should
> be abandoned only with a great deal of reluctance.
> 
> The current LIST architecture definitely has problems, but those problems
> happened for a reason.

Ya ... it sounds worse than it was meant to.   I think my point is that 
LIST did happen for a reason and it was successful in providing a bridge 
from pre-IMAP4 functionality to IMAP4.    That is why I would like to 
leave LIST and LSUB alone.   It is part of the base spec and mandatory to 
implement.

With XLIST we have an opportunity to take the good stuff from LIST (like 
the basic mailbox metaphor) and create a new command that has all of that,
plus all of the good stuff from the other extensions to LIST (like 
referrals etc.) and unify it all together.   I think we can do that 
because everyone has to implement LIST and LSUB no matter what and we can 
make sure that everyone interoperates.

The risk is that we try to build something that is mutually incompatible 
from a basic principles point of view and that makes implementation on the
server (and possibly in the client) completely impractical.    We just 
shouldn't do that.   Of course, it is exactly this issue that has gotten 
us into trouble before -- where is the line for impractical 
implementation.

Mark is right, we need a set of requirements that we can get concensus on.
>From there we can design the thing we want.

Cheers.

---
Steve Hole
Chief Technology Officer
MessagingDirect Ltd.
<mailto:[email-masked]>
Phone: 780-424-4922

Date: Fri, 3 Nov 2000 10:34:31 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: Re: comments on LIST extensions
To: Barry Leiba <[email-masked]>
cc: [email-masked]
Sender: [email-masked]

On Fri, 03 Nov 2000 13:29:42 -0500, Barry Leiba wrote:
> Right, but I think that what Steve means is that we should leave LIST and
> LSUB alone, and that provides the backward compatibility... and then we can
> make a new XLIST command that's unencumbered by those issues.

That's OK as far as it goes.  However, the underlying reasons for why those
issues came to be can't be ignored.

For example, although I understand the desire for greater client control over
server behavior, nonetheless you can't forbid the server from making decisions
that overrule client desires.  Servers have a right (some would say
obligation) to protect themselves.

LIST * is the obvious example of this.

A possible solution may be to expand responses so that it is clear when the
server is declining to give information (or otherwise do something).  Suppose,
for example, there was a \Select and an \Inferiors attribute in LIST; in that
case () would mean "server declines to say" rather than ambiguous between that
and (\Select \Inferiors).

However, this brings us to the "silly state" argument whenever we have a three
way state such as this represented by binary flags; there's a fourth, silly,
state.  I abhor such silly states as bad architecture.  Plus, sooner or later,
some clown will do it, and software has to figure out what to do.

So, when designing this facility, we should use mechanisms that avoid silly
states.  In other words, if it's a three-way state, then use a three-way
protocol mechanism instead of a pair of binary mechanisms.

Date: Fri, 03 Nov 2000 13:28:48 -0500
From: Cyrus Daboo <[email-masked]>
To: Steve Hole <[email-masked]>, Tony Hansen <[email-masked]>
cc: Barry Leiba <[email-masked]>, [email-masked]
Subject: Re: comments on LIST extensions
Sender: [email-masked]

--On Friday, November 3, 2000 10:52 AM -0700 Steve Hole 
<[email-masked]> wrote:

>> I think the charter has us, among other things, working on
>> augmenting/fixing LIST. I don't think the charter constrains us to the
>> form those augmentations or fixes must take.
>
> Exactly.   Even if the charter did constrain, I would suggest cutting
> LIST  extension out of imapext and proceeding with an XLIST outside of
> imapext.  Mark is exactly right that messing with LIST and LSUB has two
> major  problems:
>
> 1.  It constrains the final solution unacceptibly because we have a
> learned a great deal about the actual requirements for managing mailbox
> namespaces.    We will be forced to tradeoffs for backward compatibility
> that we don't want to make.
>
> 2.  It will confuse new developers tremendously.   The interoperability
> with LIST and LSUB will get worse than it already is.

I think your XLIST is really covered under the auspices of the mailbox 
annotations extension, which I believe we did agree to cover in the WG, 
once the message annotation issues were worked out.

Note that mailbox annotations can encompose a lot of other extensions 
through unification. It would naturally include all the existing LIST 
flags, and include CHILDREN and RLIST. But it can go further and include 
STATUS, access control and quota information, in addition to arbitrary 
attribute-value data, thus giving a single command syntax to cover nearly 
all mailbox specific operations.

-- 
Cyrus Daboo

Date: Fri, 03 Nov 2000 13:29:42 -0500
From: Barry Leiba <[email-masked]>
To: [email-masked]
Subject: Re: comments on LIST extensions
Sender: [email-masked]

>> We will be forced to tradeoffs for backward compatibility
>> that we don't want to make.
>
> This statement scares me.  Backward compatibility is a good thing, and
> should be abandoned only with a great deal of reluctance.

Right, but I think that what Steve means is that we should leave LIST and 
LSUB alone, and that provides the backward compatibility... and then we can 
make a new XLIST command that's unencumbered by those issues.

Barry

Date: Fri, 3 Nov 2000 10:12:18 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: Re: comments on LIST extensions
To: Steve Hole <[email-masked]>
cc: Tony Hansen <[email-masked]>, Barry Leiba <[email-masked]>, [email-masked]
Sender: [email-masked]

On Fri, 3 Nov 2000 10:52:38 -0700, Steve Hole wrote:
> 1.  It constrains the final solution unacceptibly because we have a
> learned a great deal about the actual requirements for managing mailbox
> namespaces.

Leaving aside the issue of LIST vs. XLIST, I recommend that there be a
statement or position paper about these "actual requirements."

This is to ensure that we are all on the same wavelength.  What you feel that
"we have learned" may be very different from what people here that "we have
learned."

Having created and agreed to such a list, we should use that list in the
resulting design.  We get into trouble when we don't have a fixed (and mutual)
statement of requirements.

> We will be forced to tradeoffs for backward compatibility
> that we don't want to make.

This statement scares me.  Backward compatibility is a good thing, and should
be abandoned only with a great deal of reluctance.

The current LIST architecture definitely has problems, but those problems
happened for a reason.

Date: Fri, 03 Nov 2000 13:19:53 -0500
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: moderate or restrict IMAPEXT
Sender: [email-masked]

--On Friday, November 3, 2000 9:48 AM -0800 Mark Crispin 
<[email-masked]> wrote:

> It happened again today.  IMAPEXT polluted my mailbox with a spam for a
> fake love potion.
>
> No, I do not want to hear offers for quack medicines, dirty pictures,
> pyramid schemes, et nauseum.
>
> Please establish moderation on IMAPEXT; or at least restrict posting
> privileges to list members.
>
> -- Mark --
>
> http://staff.washington.edu/mrc
> Science does not emerge from voting, party politics, or public debate.
>

>From what I can see the 'spam' arriving on this list has not included 
imapext in To, CC addresses. There were two messages in that category that 
were not spam, but I think its reasonable to expect posts to this list to 
contain the imapext address in either the To or CC headers. Thus a simple 
SIEVE script like the following would work as a reasonable filter for the 
time being:

# SIEVE Script
# Name: imapext spam discard
# Date: Fri, 03 Nov 2000 13:18:32 -0500
# User-Agent : Mulberry 2.1.0d1

# Rule 1: imapext spam discard
# Generated from GUI
if not address :contains ["To", "CC"] "[email-masked]" {
	discard;
}

# SIEVE Script ends here

-- 
Cyrus Daboo

From: Steve Hole <[email-masked]>
Date: Fri, 3 Nov 2000 10:52:38 -0700
To: Tony Hansen <[email-masked]>
Subject: Re: comments on LIST extensions
Cc: Barry Leiba <[email-masked]>, [email-masked]
Sender: [email-masked]

On Fri, 03 Nov 2000 10:02:06 -0500 Tony Hansen <[email-masked]> wrote:

> I think the charter has us, among other things, working on
> augmenting/fixing LIST. I don't think the charter constrains us to the
> form those augmentations or fixes must take.

Exactly.   Even if the charter did constrain, I would suggest cutting LIST 
extension out of imapext and proceeding with an XLIST outside of imapext. 
Mark is exactly right that messing with LIST and LSUB has two major 
problems:

1.  It constrains the final solution unacceptibly because we have a 
learned a great deal about the actual requirements for managing mailbox 
namespaces.    We will be forced to tradeoffs for backward compatibility 
that we don't want to make.

2.  It will confuse new developers tremendously.   The interoperability 
with LIST and LSUB will get worse than it already is.

Cheers.
---
Steve Hole
Chief Technology Officer
MessagingDirect Ltd.
<mailto:[email-masked]>
Phone: 780-424-4922

Date: Fri, 3 Nov 2000 09:48:16 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: moderate or restrict IMAPEXT
Organization: Networks & Distributed Computing
Sender: [email-masked]

It happened again today.  IMAPEXT polluted my mailbox with a spam for a
fake love potion.

No, I do not want to hear offers for quack medicines, dirty pictures,
pyramid schemes, et nauseum.

Please establish moderation on IMAPEXT; or at least restrict posting
privileges to list members.

-- Mark --

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

Date: Fri, 03 Nov 2000 10:02:06 -0500
From: Tony Hansen <[email-masked]>
Organization: AT&T Laboratories
To: Barry Leiba <[email-masked]>
CC: [email-masked]
Subject: Re: comments on LIST extensions
Sender: [email-masked]

I think the charter has us, among other things, working on
augmenting/fixing LIST. I don't think the charter constrains us to the
form those augmentations or fixes must take.

	Tony

Barry Leiba wrote:
> 
> > Actually Barry, while I applaud the extensible LIST argument attempt, what
> > I am most interested in is an entirely new, all consuming LIST command.
> > Call it XLIST for the purpose of discussion.
> 
> Yes, we've talked about this, and I agree, and I want to work on that.  It
> was my understanding, though, that doing that was beyond the scope of the
> IMAPExt WG, and that the LIST extensions that the WG decided to work on
> were of the sort described in this draft.  Pete R., can you clarify?  I'll
> be happy to shift this draft toward a complete revision of the LIST
> command, if the WG considers it to be within its scope.  Otherwise I'll
> continue with this as the interim answer, and work on the "XLIST" (or
> whatever) afterward.

Date: Fri, 03 Nov 2000 09:09:31 -0500
From: Barry Leiba <[email-masked]>
To: [email-masked]
Subject: Re: comments on LIST extensions
Sender: [email-masked]

> Remember, subscriptions were defined specifically to support a
> pre-existing functionality, and that this functionality is in use.
> Compatibility with this functionality must be retained.
>
> If I understand your proposal correctly, you're doing this.

Yes, by keeping LSUB as is and recommending its continued use.

>> 2. Maybe add wording to clarify that flags returned by LSUB may not be
>> accurate.  This should probably be in the base spec, actually.
>
> It isn't that the flags are inaccurate; they are different.  For example,
> \NoSelect means something different in LSUB.

The list of flags may also not include flags that would be included in a 
LIST.  I don't mean to say that flags would appear spuriously, so it's 
probably more accurate to say that "the flags returned by LSUB may be 
incomplete, and some may have different meanings."  The point is that a 
client can't know whether "()" means there are no flags set or that this 
server can't return the list of flags in LSUB.  In fact, there's nothing 
stopping a server from returning, say, "(\Marked)" in response to LSUB and 
"(\Marked \NoInferiors)" in response to LIST (or some other similar 
example).

> I'll be happy to consider suggested changes to the base spec wording for
> this. Please review what's in the current draft, not RFC 2060.

I'll do that and post something separately about it; thanks.

> OK, so by omitting LIST-SUBSCRIBED, I can implement the other options
> (and use them), correct?
>
> Put another way, there is no requirement to implement LIST-SUBSCRIBED in
> order to implement any other piece of this technology, correct?

Exactly; that's the intent here.  I'm recommending that you implement 
LIST-SUBSCRIBED, because clients can and will get that information anyway 
if they really want it, at greater cost... but its implementation is 
entirely optional.

> "\NonExistant" => "\NonExistent"

Glrf.  Thanks.  I hate when I misspel things.
:-)

>> 6. Add a new mailbox flag, "\PlaceHolder" (alternative name?), intended
>> to indicate, when necessary, that "this mailbox does not meet your
>> selection criteria, but it has a child that might (or, stronger, does?)".
>
> How will this work with LSUB, given the need to maintain compatibility?  I
> suggest that it be allowed in LSUB, but *with* the overloaded \NoSelect,
> e.g. * LSUB (\NoSelect \PlaceHolder) "/" foo
> to make it unambiguous that the \NoSelect is the overloaded form.

Yes, that was also the intent, and I didn't mention that.  To be general: 
LSUB MUST behave as it always has, but MAY also include the new flags. 
Clients MAY use the new flags for the information they convey, but MUST NOT 
assume that their absence means anything.

Side issue here: if a client sees "\NonExistent" or "\PlaceHolder" in one 
LSUB response line, can it now assume that their absence in other response 
lines is meaningful?  Maybe it's best not to address this.

> I think that we should do it.  I've been convinced that we should have
> another value in the LIST response, containing a parenthesized list of
> property/value pairs.
>     * LIST () "/" foo (REFERRAL "..." BLOOP soop)
>
> The purpose of the parentheses is to enable to addition of another value
> in the response in the future if it turns out that attribute or
> property/value aren't enough.

Absolutely, on the parentheses; I think it's valuable to group things that 
way for extensibility.  OK, since everyone who's chimed in agrees that the 
referral data should be presented(*), I'll work that in.  Should that go in 
this spec, or into a revision of the MAILBOX-REFERRALS spec?

(*) The only concern I have here is that a referral-capable server might 
know quickly that a mailbox is remote, but might have a slower time 
actually retrieving the referral information.  So there *might* be some use 
in letting the server tell you "this mailbox exists somewhere else", but 
not actually tell you *where* until you try to do something with it (if, 
for example, there are 50 remote mailboxes and it takes 1 second to 
retrieve the referral data for each, adding 50 seconds to the LIST 
(REFERRALS) command would be bad, and it might be better to make you try a 
SELECT when you actually want to use one of them).  Do any servers besides 
Exchange support mailbox referrals now?  How fast is it for Exchange (or 
other servers) to retrieve the referral details?

Barry Leiba, Living Lab Services  ([email-masked])
http://www.research.ibm.com/people/l/leiba

Date: Fri, 03 Nov 2000 08:51:18 -0500
From: Barry Leiba <[email-masked]>
To: [email-masked]
Subject: Re: comments on LIST extensions
Sender: [email-masked]

> Actually Barry, while I applaud the extensible LIST argument attempt, what
> I am most interested in is an entirely new, all consuming LIST command.
> Call it XLIST for the purpose of discussion.

Yes, we've talked about this, and I agree, and I want to work on that.  It 
was my understanding, though, that doing that was beyond the scope of the 
IMAPExt WG, and that the LIST extensions that the WG decided to work on 
were of the sort described in this draft.  Pete R., can you clarify?  I'll 
be happy to shift this draft toward a complete revision of the LIST 
command, if the WG considers it to be within its scope.  Otherwise I'll 
continue with this as the interim answer, and work on the "XLIST" (or 
whatever) afterward.

> 1.   I would like to see the orginal extension framework draft revived,
> Included the restriction on applicable command set if people still feel
> it  is necessary.

I agree, and I think that I asked for comments on this resurrection a while 
ago and got insufficient support, considering the objections from Mark and 
Chris.  If there's enough support for it to try to get past their 
objections, I'm certainly eager to pursue it, and I think Cyrus is too. 
I'd rather discuss it here, unless Pete objects, rather than on the IMAP 
list, but I think it's outside the scope of the IMAPExt WG.

Barry Leiba, Living Lab Services  ([email-masked])
http://www.research.ibm.com/people/l/leiba

Date: Fri, 3 Nov 2000 03:59:09 -0800 (PST)
From: [email-masked]
To: [email-masked]
Subject: At last, Herbal V, the all natural alternative to V----A!
Sender: [email-masked]

Herbal V: An Incredible All-Natural Healthy Alternative 

  Herbal V is the All Natural Approach to Male Virility,
  Vitality and Pleasure.

Available N o w ! 

Welcome to the New Sexual Revolution.

It's the all natural male potency and pleasure pill that men 
everywhere are buzzing about. Herbal V is safe, natural and
specifically formulated to help support male sexual function
and pleasure. You just take two easy-to-swallow tablets
one hour before sex. And there's more great news - you can
get Herbal V for less than $1 a pill.

Amazing word of mouth praise on Herbal V has been spreading 
like wildfire-already over 1,500,000 men  have chosen
Herbal V. Since it is 100% natural you will never have
to worry about safety. Try doctor-recommended Herbal V
today and have the greatest night of your life!

Herbal V... Bringing Back the Magic!

1,585,000 men can't be wrong. To date over 1 million men 
have tried the super supplement Herbal V.
Here is why: 

No Doctor Visit Required 
Available Over the Counter 
Not a Drug 
100% Natural 
Safe, No Worries 
Highest Quality Pharmaceutical-Grade Pure Nutriceuticals 
Guaranteed Potency & Purity 

Be a Real Man Again!

Questions and Answers

What is Herbal V?

Herbal V is a proprietary blend that was specifically
developed as a safe alternative for men who prefer
an all-natural approach to address impotence and boost
sexual performance. This amazing formula first became
popular with Hollywood insiders and the wealthy elite.
They were maximizing their sex lives, long before it 
was available to the general public. 

How does Herbal V work?

Developed by a team whose goal was to create the perfect 
all-natural aphrodisiac. Herbal V is the result of that
remarkable effort. The Herbal V formula contains a precise
blend of cutting edge pro-sexual nutrients from around
the world that provide nutritional support, making it
possible for a man to have a pleasurable sexual experience. 

What can Herbal V do for me?

Herbal V helps support male sexual function and 
pleasure in a safe and natural manner. Simply put, 
it can make your sex life incredible. 

Is Herbal V Safe?

One of the great things about Herbal V is that it is
not a drug. It is an incredible herbal dietary supplement
that provides nutritional support for male sexual function
and pleasure. One of the most comforting features of
Herbal V is that you never have to worry about safety. 

Herbal V: Safe - Natural - Exciting

Many have speculated that because Herbal V is so
popular with men, it must contain prescription drugs
or chemical components. Herbal V does not contain any 
elements or traces of any prescription drug. Herbal V 
is made using the world's most technologically advanced
state-of-the-art cold processing equipment to ensure
maximum purity. Herbal V has been independently analyzed
by the nation's premier testing facility to ensure purity,
quality and to end the rumors that, because it is so
popular, it must somehow be chemical. It is not.
Herbal V is natural - just as it says on the label.
Herbal V is simply fantastic! 

Herbal V: Ingredients

Yohimbe, saw palmetto, avena sativa, androstenedione,
guarana, taurine, siberian ginseng, tribulus terrestris. 
Tribulus Terrestis is certified to enhanced testosterone
levels by increasing Luteinzing hormone (LH) levels. 
Androstenedione which is a precursor to testosterone
unlocks bound testosterone and makes it biologically
active again quickly. This means a dramatic surge in 
desire. Avena Sativa Stimulates the neurotransmitter 
pleasure centers to maximum capacity. This greatly
intensifies pleasure.

Just listen to what Herbal V has done for the sex lives
of people like you!

“On a scale of 1 to 10, it's a 15. Electrifying. It's like 
a wonder pill!” 
— Justin Q B., New Haven, Texas

“I haven't had sexual relations in 11 years. Then with 
Herbal V it was... wow! It works again!” 
— Sid R., Lakeland, Florida

“I had sex four times in one night. It made me feel
like a 19-year-old again.” 
— Chip S, Beech Mountain, North Carolina

“Herbal V has turned my husband into a Sexual Superman! 
I like the fact that it's all natural and has no
side effects. It's bringing back the good old days.” 
— Jennifer B, Beverly Hills, California 

The above testimonials are from product literature, 
and we have not independently verified them.
However, the following testimonial is from a "senior"
gentleman who has purchased his second bottle of
Herbal V. When we heard his words with our own ears,
we asked his permission to print them here. 

 “Man! I'm wild as I can be! I feel like I'm 25 years old again! 
I'm not believing this!” 
                          — Mr. Murphy, age 64, Lampart, IL.

Risk Free: Double Your Money Back Guarantee

If Herbal V does not give the desired results as stated
above, simply return the unused portion for a
double-your money back refund. No questions asked ! 

Order Now: Safe, Fast, Secure, Private

Herbal V with its DOUBLE YOUR MONEY BACK GUARANTEE is
available only through this special promotional offer.
Herbal V arrives in plain packaging for your privacy.
Any and all information is kept strictly confidential.

Payment Methods

You may FAX or Postal Mail Checks, MasterCard, Visa,
& American Express.payments. Money Orders
are accepted only by Postal Mail. 

Each bottle of Herbal V contains 30 tablets, approximately
a 1 month supply.

Step 1: Place a check by your desired quanity.

______ 1 Bottle of Herbal V  $28

______ 2 Bottles of Herbal V $48

______ 3 Bottles of Herbal V $59

Please add $6 shipping and handling for any size order. 
[ Total cost including shipping & handling, 
1 bottle=$34, 2 bottles=$54, 3 bottles=$65 ]

International Orders
Please add $16 shipping and handling for any size order.
[ Total cost including shipping & handling,
1 bottle=$40, 2 bottles=$60, 3 bottles=$75 ]
We cannot accept foreign checks.
International money orders or credit cards only.

Step 2: Place a check by your desired payment method 
and complete fields if necessary.

_____Check or CHECK-BY-FAX [details below]

_____Money Order 

_____American Express 
Account Number__________________ Exp____/____

_____Visa
Account Number__________________ Exp____/____

_____MasterCard
Account Number__________________ Exp____/____

Please make your check or money order payable to
"Lion Sciences National".

Step 3: Please complete and print the following fields clearly.

Name ___________________________________________________ 

Address _________________________________________________

City ____________________________________________________ 

State ___________________________________________________ 

Zip _____________________________________________________ 

E-mail __________________________________________________ 

Signature _________________________________________________
[ required for check and credit card orders]

             Toll Free FAX Order Line: 1-800-940-6590
If faxing in your order, please state whether you require
a fax, email, or no confirmation at all. 
Allow up to one day for confirmation, if requested.
FAX orders are processed immediately.

  Or, print & mail to: LSN   
                       3502 N. Powerline Rd. #525 
                       Pompano Beach, FL 33069                

        ______________________________________________________

*CHECK BY FAX ORDERS: Complete the check as normal. Tape
the check in the area below. Below the check, clearly write
the check number, all numbers at the bottom of the check,
& your name. Tape the check below and fax the check to the
toll free FAX number above. Void the check. Our merchant
will electronically debit your account for the amount of 
the check; your reference number for this transaction will
be your check number. Nothing could be safer & easier !

                          TAPE CHECK BELOW

              _____________________________________________________________

This is a one time mailing: Removal is automatic and no further 
contact is necessary. Please Note: Herbal V is not intended to
diagnose, treat, cure or prevent any disease. As individuals differ,
so will results. Herbal V helps provide herbal and nutritional support
for male sexual performance. The FDA has not evaluated these 
statements. For details about our double your money back guarantee,
please write to the above address, attention consumer affairs 
department; enclose a self addressed stamped envelope for this and any 
requested contact information.
Thank You.

From: "Mike Gahrns" <[email-masked]>
To: "Barry Leiba" <[email-masked]>, <[email-masked]>
Subject: Re: comments on LIST extensions
Date: Thu, 2 Nov 2000 13:57:21 -0800
Sender: [email-masked]

Barry Leiba writes:
> We also have to do something with the REMOTE (or REFERRALS) option.  I
> agree with those who think that we should add referral information to the
> LIST response, but I'd really like to hear from Mike Gahrns or Raymond
> Cheng about it.
Yes,  including referral information in a "general LIST response type
extension" is a good idea, and something that many of us discussed at
various events like the IMC interops and IETF meetings.

Assuming we went with the approach Steve Hole suggested with a new command
like XLIST (insted of a general LIST response extension) this type of
mechanism could simplify referrals in removing the need for the RLIST
command.  Recall, RLIST was added to referrals since in general one would
not want a non-referral enabled client displaying remote mailboxes that
would not be accessible to a  user.
If a mailbox was flagged as \remote (or whatever was agreed upon), it would
need to be explicitly stated in the XLIST extension that the mailbox should
not be displayed to the user unless the client was a referral enabled
client.

Date: Thu, 2 Nov 2000 13:37:33 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: Re: comments on LIST extensions
To: Barry Leiba <[email-masked]>
cc: [email-masked]
Sender: [email-masked]

Barry -

I think that your latest message on this topic is good, and we can move
forward with it.  I figured that I should get *that* data point said before
going into the long response.

On Thu, 02 Nov 2000 14:35:31 -0500, Barry Leiba wrote:
> It seems that Mark's got the main complaint, and that complaint involves
> the interaction between subscriptions and other options.  Specifically, in
> Mark's model of how subscriptions work, it doesn't generally make sense to
> combine SUBSCRIBED with other options.

Remember, subscriptions were defined specifically to support a pre-existing
functionality, and that this functionality is in use.  Compatibility with this
functionality must be retained.

If I understand your proposal correctly, you're doing this.

> That said, many servers *do* implement "subscribed to" as a mailbox
> attribute, and in those servers it *does* make sense to have SUBSCRIBED be
> an option, and to allow its combination with other options.

I agree that it is alright as an option that does not break or otherwise
restrict existing software.  This implies that it should be permissible to
implement other options without implementing this one.

> 1. Change wording so it doesn't suggest deprecating LSUB.  Add wording to
> indicate that LSUB will remain *unchanged*, and that clients that don't
> need more function than is provided by LSUB should continue to use LSUB.

OK

> 2. Maybe add wording to clarify that flags returned by LSUB may not be
> accurate.  This should probably be in the base spec, actually.

It isn't that the flags are inaccurate; they are different.  For example,
\NoSelect means something different in LSUB.

I'll be happy to consider suggested changes to the base spec wording for this.
Please review what's in the current draft, not RFC 2060.

> 3. The LISTEXT capability will announce support for the general method of
> specifying LIST options and for the CHILDREN option.

OK.

> 4. The LIST-SUBSCRIBED capability will announce support for the SUBSCRIBED
> option.

OK, so by omitting LIST-SUBSCRIBED, I can implement the other options (and use
them), correct?

Put another way, there is no requirement to implement LIST-SUBSCRIBED in order
to implement any other piece of this technology, correct?

If the answer to both of these is "yes", you may consider my objections as
having been satisfied and consequently are dropped.

> Note that this means (and I will make it clear) that "LSUB" and "LIST
> (SUBSCRIBED)" are *not* the same, and that clients that do not need the
> extra function provided by the latter SHOULD NOT use it.

OK

> 5. Add a new mailbox flag, "\NonExistant", intended to be applied to a
> mailbox that's subscribed to but that doesn't actually exist.

"\NonExistant" => "\NonExistent"

> 6. Add a new mailbox flag, "\PlaceHolder" (alternative name?), intended to
> indicate, when necessary, that "this mailbox does not meet your selection
> criteria, but it has a child that might (or, stronger, does?)".

How will this work with LSUB, given the need to maintain compatibility?  I
suggest that it be allowed in LSUB, but *with* the overloaded \NoSelect, e.g.
    * LSUB (\NoSelect \PlaceHolder) "/" foo
to make it unambiguous that the \NoSelect is the overloaded form.

LIST-SUBSCRIBED, on the other hand, won't have \NoSelect.

> We also have to do something with the REMOTE (or REFERRALS) option.  I
> agree with those who think that we should add referral information to the
> LIST response, but I'd really like to hear from Mike Gahrns or Raymond
> Cheng about it.

I think that we should do it.  I've been convinced that we should have another
value in the LIST response, containing a parenthesized list of property/value
pairs.
    * LIST () "/" foo (REFERRAL "..." BLOOP soop)

The purpose of the parentheses is to enable to addition of another value in
the response in the future if it turns out that attribute or property/value
aren't enough.

From: Steve Hole <[email-masked]>
Date: Thu, 2 Nov 2000 14:01:20 -0700
To: Barry Leiba <[email-masked]>
Subject: Re: comments on LIST extensions
Cc: [email-masked]
Sender: [email-masked]

Actually Barry, while I applaud the extensible LIST argument attempt, what
I am most interested in is an entirely new, all consuming LIST command.   
Call it XLIST for the purpose of discussion.

All of the things that you put in your message, modulo the bits that define
interaction between LIST and LSUB, would go into the XLIST extension 
command.   In XLIST, mailboxes can express a number of different 
attributes, including user/application defined ones (annotations) and they
can all be searched/retrieved using the XLIST and related commands.   
Great.   People will either implement or not in the true spirit of the 
IMAP world -- if it is useful lots of people will do it.

Leave LIST and LSUB alone.   Their semantics are defined and implemented 
in a number of products, and messing with them is just going to cause 
confusion.    It will certainly cause lots of disagreement -- as it 
already has.

...

I also think that your original draft that provided a general IMAP command
argument extension framework was a damned good idea.   Certainly, the new 
XLIST command could employ it straight off.   Some people didn't like the 
possibility of command extension for the commands available in the 
non-authenticated state.   Fine.   Stipulate that that set of commands 
cannot be extended in this way.   Otherwise, if you want to extend the 
arguments for a base command, this is the way to do it.

Personally, I don't understand what the issue is for the commands 
available in the non-authenticated state.   And yes, I have heard the 
arguments -- please don't send them again.   I just don't agree with them.
In my opinion, they are not sound arguments and the examples provided are 
very much contrived. 

...

To summarize:

1.   I would like to see the orginal extension framework draft revived, 
Included the restriction on applicable command set if people still feel it 
is necessary.

2.   I would like to see a draft for a brand new command that can be used 
as an alternative to the existing LIST and LSUB commands that has the 
unified semantics of the various LIST extensions, plus an explicit 
extension mechanism for folder metadata.

Cheers.

---
Steve Hole
Chief Technology Officer
MessagingDirect Ltd.
<mailto:[email-masked]>
Phone: 780-424-4922

Date: Thu, 02 Nov 2000 14:35:31 -0500
From: Barry Leiba <[email-masked]>
To: [email-masked]
Subject: Re: comments on LIST extensions
Sender: [email-masked]

OK, it seems that the discussion has settled down -- nothing for a couple 
of weeks -- so I'll do a little summary and a proposal.

It seems that Mark's got the main complaint, and that complaint involves 
the interaction between subscriptions and other options.  Specifically, in 
Mark's model of how subscriptions work, it doesn't generally make sense to 
combine SUBSCRIBED with other options.  Further, the idea that SUBSCRIBED 
is an option on the LIST command implies that "being subscribed to" is an 
attribute of a mailbox, and that wasn't Mark's intent.  He strongly wants 
to keep the LSUB command separate, and that's partly to make it clear that 
the list of subscriptions is a completely separate list.

That said, many servers *do* implement "subscribed to" as a mailbox 
attribute, and in those servers it *does* make sense to have SUBSCRIBED be 
an option, and to allow its combination with other options.

Further, a client that wants to have an accurate list of mailbox flags on 
subscribed mailboxes (for instance) *will* get that information, and as it 
stands it has to do it by combinations of LSUB and multiple LIST commands.

OK, so here's what I propose as a change to the current LIST extensions 
draft:

1. Change wording so it doesn't suggest deprecating LSUB.  Add wording to 
indicate that LSUB will remain *unchanged*, and that clients that don't 
need more function than is provided by LSUB should continue to use LSUB.

2. Maybe add wording to clarify that flags returned by LSUB may not be 
accurate.  This should probably be in the base spec, actually.

3. The LISTEXT capability will announce support for the general method of 
specifying LIST options and for the CHILDREN option.

4. The LIST-SUBSCRIBED capability will announce support for the SUBSCRIBED 
option.  This option may be combined with other options, guarantees 
accurate flags, and so forth (I'll put in appropriate wording).

Note that this means (and I will make it clear) that "LSUB" and "LIST 
(SUBSCRIBED)" are *not* the same, and that clients that do not need the 
extra function provided by the latter SHOULD NOT use it.  Servers, such as 
Mark's, which have to do extra work to, for example, get accurate flags for 
subscribed mailboxes, MUST do so if they implement LIST-SUBSCRIBED.  I 
think such servers would do well to do so, since, as noted above, a client 
that wants the information will get it anyway, and at greater cost to both 
client and server.

5. Add a new mailbox flag, "\NonExistant", intended to be applied to a 
mailbox that's subscribed to but that doesn't actually exist.  This will 
distingush between
   * LIST () "/" "Banana"
and
   * LIST (\NonExistant) "/" "Banana"
The LSUB command MAY use the \NonExistant flag as a hint, but the "LIST 
(SUBSCRIBED)" MUST use it.

6. Add a new mailbox flag, "\PlaceHolder" (alternative name?), intended to 
indicate, when necessary, that "this mailbox does not meet your selection 
criteria, but it has a child that might (or, stronger, does?)".  This will 
eliminate the overloading of \NoSelect for this purpose, which, once we 
implement the SUBSCRIBED option, has to be done.

Example:
  A1 LIST (SUBSCRIBED CHILDREN) "" "%"
  * LIST (\NoInferiors) "/" "inbox"
  * LIST (\NoSelect \HasChildren) "/" "xyz"
  * LIST (\NonExistant) "/" "abc"
  * LIST (\PlaceHolder \HasChildren) "/" "def"
  * LIST (\HasChildren) "/" "ghi"
  A1 OK done
  A2 LIST (SUBSCRIBED CHILDREN) "" "%/%"
  * LIST (\HasChildren) "/" "def/xxx"
  * LIST (\HasNoChildren) "/" "ghi/yyy"
  * LIST (\HasNoChildren) "/" "ghi/zzz"
  A2 OK done

Here, note that "inbox" and "abc" do not have CHILDREN flags, because the 
\NoInferiors and \NonExistant flags make them unnecessary.  Mailbox "xyz" 
is subscribed to, but is not selectable; it has children, and, as it turns 
out, none of those children are subscribed to.  "abc" is subscribed to, but 
doesn't actually exist.  "def" is not subscribed to, but it has children 
that are.  "ghi" is subscribed to and has children; we don't know whether 
any of its children are subscribed to -- the second LIST shows us that they 
are.

Does this all make sense?  Mark, does it satisfy your concerns?  Others, 
does it meet your needs too?

We also have to do something with the REMOTE (or REFERRALS) option.  I 
agree with those who think that we should add referral information to the 
LIST response, but I'd really like to hear from Mike Gahrns or Raymond 
Cheng about it.

Barry Leiba, Living Lab Services  ([email-masked])
http://www.research.ibm.com/people/l/leiba