Subject: [lemonade] CATENATE draft

From: Pete Resnick <[email-masked]>
Date: Fri, 5 Dec 2003 20:15:43 -0800

I've just sent in a draft to the secretariat for the IMAP command to 
do composition. I've called it CATENATE. If you'd like to have a peek 
before it gets posted, you can look at:

<http://www.qualcomm.com/~presnick/draft-ietf-lemonade-catenate-00.txt>
<http://www.qualcomm.com/~presnick/draft-ietf-lemonade-catenate-00.html>
<http://www.qualcomm.com/~presnick/catenate.xml>

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 07 Dec 2003 14:28:57 +0000

> <http://www.qualcomm.com/~presnick/catenate.xml> 

I think I like using URLs better than "seq-number section [partial]" 
triples.
Besides, an implementation may choose to recognize *only* imap URLs and 
*only* in the current mailbox.

Alexey
__________________________________________
Isode Limited, http://www.isode.com

IETF standard related pages:
http://www.melnikov.ca/mel/devel/Links.html
__________________________________________

---

From: Randall Gellens <[email-masked]>
Date: Tue, 9 Dec 2003 00:58:58 -0800

I've sent in a first draft on the detailed protocol for IMAP push. 
If you'd like to look at it before it gets posted, you can get it 
from 
<ftp://ftp.pensive.org/Public/Randy/draft-gellens-lemon-push-00.txt>.

Please read soon and send me or the list your comments and 
suggestions so I can do an updated draft before the 17th (the 
deadline we agreed to in Minneapolis).
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Whenever people agree with me I always feel I must be wrong.
                                              --Oscar Wilde

---

From: Randall Gellens <[email-masked]>
Date: Tue, 9 Dec 2003 23:11:44 -0800

> deadline we agreed to in Minneapolis).

If you tried to get it from the FTP server and couldn't connect, 
please try again.  The system had some hardware problems (while I'm 
away on travel of course) but I understand it should be back up now.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
They're only trying to make me LOOK paranoid!

---

From: Ted Hardie <[email-masked]>
Date: Wed, 10 Dec 2003 13:53:45 -0800

So, reading this I kind of wonder what use case we believe will be
most common here.  I see what Randy has written as providing a
fairly complete annotation-based mechanism for generating the
envelope to use with a message "created" with APPEND or CATENATE.
Since it defaults to a pending/queued state, this message and envelope
could theoretically be developed in one client and the SUBMIT issued
by another (the value of annotations, really).  All of that seems like
goodness.

I'm wondering, though, whether the common use case isn't going to be
one which would be satisfied by a "bounce"-like simplicity.  My naive
thinking has been the most common use of this will be someone getting a message
to mailbox1 (say, on a cell phone) and wanting it on a different server
(say, their enterprise server).  No composition really, just a redirection.
If that is going to be the common case, then having an algorithm for
defaults for some of these might be very useful, as it would allow simple
clients to use the "bounce" version of this without having to use annotations
(much or at all).  Not that this would be the only way it would work (obviously,
the forward-with-comments and compose mechanisms have great utility), 
just that a profile of this that is that simple might be a good idea.

Thoughts?
				Ted

---

From: Rob Siemborski <[email-masked]>
Date: Wed, 10 Dec 2003 15:16:52 -0500 (EST)

> deadline we agreed to in Minneapolis).

If SUBMIT commands can be pipelined, how do you tell which untagged submit
responses go with which message.

Say I have two messages that I am sending to [email-masked]:

      C: a15 SUBMIT 12
      C: a16 SUBMIT 13
      S: * SUBMIT "RCPT TO:<[email-masked]>" "550 User over quota"
      S: * SUBMIT "MAIL FROM:<[email-masked]>" "450 Too many
         messages from <[email-masked]> in 5 minute period"
      S: a15 NO not my fault submission rejected by submit server
      S: a16 NO not my fault submission rejected by submit server

How do I know which message got which reply?  Or do we just not care?

Also, including the address in the name of the mail-from annotation
doesn't resonate well with me.  Sure, its consistent with "RCPT-to" but
this means I now have to pass a wildcard to get the mail-from information
if I don't already know it.  I don't think "being consistent" is a huge
win here.

Finally, aren't [annotate] and [annotatemore] normative for this spec?

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e++ h r- y?

---

From: Pete Resnick <[email-masked]>
Date: Sun, 14 Dec 2003 14:13:44 -0600

On 12/7/03 at 2:28 PM +0000, Alexey Melnikov wrote:

>I think I like using URLs better than "seq-number section [partial]" triples.
>Besides, an implementation may choose to recognize *only* imap URLs 
>and *only* in the current mailbox.

Three issues with using URLs:

1. Selecting multiple mailboxes: At least a couple of server folks 
told me that doing random mailbox access was a real pain 
implementation-wise because it would involve effectively doing a 
SELECT on multiple mailboxes. This was considered bad.

2. Which schemes are valid: How does the server indicate which URL 
schemes it allows? How can it further indicate that it only allows 
access to *this* server? Waiting until the server answers NO isn't 
really acceptable.

3. IMAP URLs don't allow byte ranges. I think those could turn out to 
be terribly handy.

Again, though it might be nice to do a grand "include anything here" 
kind of mechanism, I think that's a little over the top for the 
real-world need we are trying to address. To use a completely stolen 
line (from MTR who I think stole it from somewhere else): Using URLs 
fills a well-needed gap.

I'm willing to be convinced otherwise, but I'd like to hear from 
other folks too before I consider such a change.

pr

---

From: Lyndon Nerenberg <[email-masked]>
Date: Fri, 12 Dec 2003 10:00:14 -0700

> How do I know which message got which reply?  Or do we just not care?

S: * SUBMIT 12 "RCPT TO:<[email-masked]>" "550 User over quota"
S: * SUBMIT 13 "MAIL FROM:<[email-masked]>" "450 Too many
   messages from <[email-masked]> in 5 minute period"

This requires EXPUNGE to be blocked while any SUBMITs are in progress.

--lyndon

---

From: Rob Siemborski <[email-masked]>
Date: Fri, 12 Dec 2003 12:03:22 -0500 (EST)

> This requires EXPUNGE to be blocked while any SUBMITs are in progress.

The current draft doesn't retun the sequence numbers, but yes, that would
fix the problem.

I think EXPUNGE would need to be blocked while SUBMIT is in progress
anyway.

-Rob

-----BEGIN GEEK CODE BLOCK----
Version: 3.12

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 15 Dec 2003 18:08:57 +0000

> SELECT on multiple mailboxes. This was considered bad. 

Once again, a server can check if an URL points to a mailbox which is 
not currently open and fail the command.
We can define a new capability, saying that the server only supports 
catanating in the open mailbox (or vice versa: by default all server 
must support catanating in the open mailbox only, but some servers can 
support any mailboxes).

> access to *this* server?

IMAP CHANNEL extension is already dealing with a similar problem. I 
don't remember syntax of the top of my head.

> Waiting until the server answers NO isn't really acceptable.
>

IMHO, it is time to extend URL syntax for this anyway. I remember some 
talks about revision IMAP URL document.

> kind of mechanism,

Actually, my argument is about having a convenient (and extensible) 
representation of the described information.

> I think that's a little over the top for the real-world need we are 
> trying to address. To use a completely stolen line (from MTR who I 
> think stole it from somewhere else): Using URLs fills a well-needed gap.
>
> I'm willing to be convinced otherwise, but I'd like to hear from other 
> folks too before I consider such a change.

Alexey

---

From: Pete Resnick <[email-masked]>
Date: Tue, 23 Dec 2003 00:39:11 -0600

On 12/15/03 at 6:08 PM +0000, Alexey Melnikov wrote:

>Once again, a server can check if an URL points to a mailbox which 
>is not currently open and fail the command.

I think that's too late.

>must support catanating in the open mailbox only, but some servers 
>can support any mailboxes).

*If* we do this, I prefer the latter, where the server can say, "I 
allow CATENATEs from unselected mailboxes".

>don't remember syntax of the top of my head.

So basically if we create capabilities (perhaps not even in this 
document) for "I can catenate from unselected mailboxes", "I can 
catenate from other IMAP servers", and "I can catenate schemes other 
than IMAP", and make the default be that you can only catenate 
message parts from the currently selected mailbox, this comes down to 
strictly a syntax change, assuming we make the below change on byte 
ranges: We use relative IMAP URL syntax instead of "seq-number 
section [partial]".

>>3. IMAP URLs don't allow byte ranges. I think those could turn out 
>>to be terribly handy.
>
>IMHO, it is time to extend URL syntax for this anyway. I remember 
>some talks about revision IMAP URL document.

Does anyone know who is dealing with this?

Anybody else have input on this?

pr

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 23 Dec 2003 16:48:26 +0000

> allow CATENATEs from unselected mailboxes". 

Sure.

> than IMAP", and make the default be that you can only catenate message 
> parts from the currently selected mailbox, this comes down to strictly 
> a syntax change, assuming we make the below change on byte ranges: We 
> use relative IMAP URL syntax instead of "seq-number section [partial]".
>

I think Lyndon wanted to take this, but I am willing to do this as well. 
I just went through the IMAP URL text recently when I was doing HTTP 
AUTH URLs .

Alexey

---

From: Randall Gellens <[email-masked]>
Date: Tue, 23 Dec 2003 15:49:42 -0800

At 1:53 PM -0800 12/10/03, Ted Hardie wrote:

>  the most common use of this will be someone getting a message

Is your suggestion that the server, by default, create the envelope 
from the headers?  So if mail-to isn't specified, use To/Cc headers, 
and if mail-from isn't specified, use the From header?

I like the idea of making things simple, but I am concerned about 
encouraging a usage model that may lead to accidental disclosure of 
bcc recipients or other information.  Perhaps a strict prohibition on 
Bcc headers may help.  That is, if the spec clearly says that Bcc 
headers are not processed into rcpt-to commands we may be able to 
avoid the problem.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Stolen Painting Found by Tree
--Newspaper headline

---

From: Randall Gellens <[email-masked]>
Date: Tue, 23 Dec 2003 15:51:04 -0800

>  I think EXPUNGE would need to be blocked while SUBMIT is in progress

Both sound useful: return sequence number or UID (depending on SUBMIT 
versus UID SUBMIT) and block EXPUNGE between receipt of SUBMIT and 
return of response.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
There was a young poet named Dan,
Whose poetry never would scan.
        When told this was so,
        He said, "Yes, I know.
It's because I try to put every possible syllable into that last line t

---

From: Rob Siemborski <[email-masked]>
Date: Wed, 24 Dec 2003 00:02:56 -0500 (EST)

> versus UID SUBMIT) and block EXPUNGE between receipt of SUBMIT and

I would expect this to work similar to FETCH (you always get a sequence
number as the argument to the FETCH response, though UID FETCH commands
also return a UID).  If we sometimes return UID and sometimes return
sequence number, we need to be clear on which is being returned.  I think
that always using the sequence number is probably fine.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O-
M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y?

---

From: Lyndon Nerenberg <[email-masked]>
Date: Tue, 30 Dec 2003 12:46:40 -0700

> I think Lyndon wanted to take this,

I did? I nominate someone else -- I'm way too far behind on my other 
drafts to take on any more right now.

--lyndon

---

From: Pete Resnick <[email-masked]>
Date: Tue, 30 Dec 2003 13:57:09 -0600

>drafts to take on any more right now.

Alexey, do you want to do it or shall I?

pr

---

From: Mark Crispin <[email-masked]>
Date: Tue, 30 Dec 2003 12:40:52 -0800 (PST)

> Alexey, do you want to do it or shall I?

Given that Chris and I are currently working on IMAP URLs, don't you think
that it would have been nice if you had brought us into this little party?

-- Mark --

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

---

From: Pete Resnick <[email-masked]>
Date: Tue, 30 Dec 2003 17:23:17 -0600

On 12/30/03 at 12:40 PM -0800, Mark Crispin wrote:

On Tue, 30 Dec 2003, Pete Resnick wrote:
>Given that Chris and I are currently working on IMAP URLs, don't you 
>think that it would have been nice if you had brought us into this 
>little party?

If either of you would like what I took to be the relatively menial 
task of adding byte ranges to the syntax and perhaps updating the URI 
references, please feel free. I understood the task as a small 
pain-in-the-butt job that nobody would really want, which is why I 
put the query the way I did. I certainly didn't think it was going to 
be a "party" at all.

(And why am I wasting everyone's time sending this to the list?)
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

---

From: Mark Crispin <[email-masked]>
Date: Tue, 30 Dec 2003 15:39:53 -0800 (Pacific Standard Time)

On Tue, 30 Dec 2003, Pete Resnick wrote:
> If either of you would like what I took to be the relatively menial task of
> adding byte ranges to the syntax and perhaps updating the URI references,
> please feel free.

OK.  I think that there is arguably a requirement for more than just this.
Are byte ranges really sufficient, or would some kind of line range be
desirable?  What about some means to access envelope and/or bodystructure
via URL?

-- Mark --