Subject: [lemonade] Comments on draft-ietf-lemonade-profile-02.txt

From: Randall Gellens <[email-masked]>
Date: Tue, 5 Jul 2005 14:47:51 -0700

I've made a large number of comments and suggested edits to profile-02.

Because of the number and extent of the comments and suggestions, I 
marked up a copy of the profile draft.  Please see 
<http://people.qualcomm.com/randy/draft-ietf-lemonade-profile-02-[rcg].txt> 
and look for lines starting with "]]]".
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
There is no human problem which could not be solved if people would
simply do as I advise.                                -- Gore Vidal

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

---

From: Pete Resnick <[email-masked]>
Date: Thu, 7 Jul 2005 00:24:30 -0500

On 7/5/05 at 2:47 PM -0700, Randall Gellens wrote:

>    The advent of client/server email using the [RFC3501] and [RFC2821]
>]]]                                                           ^^^^^^^
>]]]  This should be RFC 2476 instead of 2821.

I think both 2821 and 2476 should be included.

I'm personally not fond of 2.2 or 2.3. 2.2 calls out assembly, which 
I don't think is necessarily a distinct operation from initiation or 
editing. We shouldn't imply that there are always four steps. There 
may be only two or three. 2.3 is a bit muddled, not being clear on 
the difference between retrieving drafts from the server and 
retrieving parts of previous messages.

>    The [CATENATE] extension to [RFC3501] addresses the fcc problem.  It
>    requires making several simplifying assumptions:
>        (1a) there is one, and only one, fcc destination on a single
>    server
>        (2a) the server which holds the fcc is the same as the server
>    which stages the outgoing message for submission
>        (3a) it is desired that the fcc be a copy of the complete message
>    text with all external data inserted in the message

I don't understand 1a at all. 2a is certainly true. 3a might be an 
overstatement depending on the implementation of CATENATE (the 
external data may not be inserted into the message per se).

I'm share Randy's concerns about the quick reconnect section.

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

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 12 Jul 2005 21:16:38 +0100

> I think both 2821 and 2476 should be included.

I've added 2476.

> [...]
> I don't understand 1a at all.

FCC functionality is achieved by catenated APPEND. If the client wants 
to FCC to multiple locations, it has to copy the constructed message to 
one or more mailbox on the same or different server. So pure CATENATE 
can't do FCC to multiple locations.

> 2a is certainly true.

Yes.

> 3a might be an overstatement depending on the implementation of 
> CATENATE (the external data may not be inserted into the message per se).

Right, the catenated message may contain URLs in body parts. Should I 
just delete 3a?

Alexey

---

From: Dave Cridland <[email-masked]>
Date: Tue, 12 Jul 2005 23:45:14 +0100

On Tue Jul 12 21:16:38 2005, Alexey Melnikov wrote:
> FCC functionality is achieved by catenated APPEND. If the client 
> wants to FCC to multiple locations, it has to copy the constructed 
> message to one or more mailbox on the same or different server. So 
> pure CATENATE can't do FCC to multiple locations.
> 
> 
Kind of. CATENATE makes for a useful replacement for COPY, since it 
works in authenticated state. My implementation picks it where the 
source message is not in the currently selected mailbox, if any. So 
where CATENATE is supported (and I don't have access to a server 
implementation as yet), my client would use CATENATE for multiple 
folder destinations on the same host, most of the time.

> Yes.
Yes, there's no method for assembling a message from multiple servers 
with CATENATE. (There is with POSTADDRESS + BURL, of course).

> Right, the catenated message may contain URLs in body parts. Should 
> I just delete 3a?

You've lost me.

3a isn't true anyway - you could assemble a temporary message for 
submission purposes, and extract the text again with CATENATE to a 
new message which is kept.

But more importantly, surely CATENATE acts as if it assembles the 
message, copying all parts as required, regardless of whether it 
actually does or not? Thus if I copy sections from another message. 
and delete/expunge the original, the new message still has the data.

Dave.