Subject: [lemonade] Misc comments

From: Dave Cridland <[email-masked]>
Date: Fri, 11 Feb 2005 12:25:32 +0000

Hiya folks,

I've been looking at varius drafts with a view to implementing them in my client.

BURL:

BURL looks fine to me, although I do wonder if it could be enhanced to accept http scheme URLs - it's far from essential, but I can imagine a situation where a salesman on the road wishes to send a document to a customer which resides on, say, a WebDAV "office share".

I'd like to see some examples of use where BURL, CHUNKING, and BINARY are supported - I think this might be a very interesting case, and it's what I'm hoping to be capable of supporting.

URLAUTH:

For use with BURL (or CATENATE), this seems perfectly fine.

For use as a generalized "sharing a message" feature, I worry that URLFETCH doesn't allow for fetching subparts of messages, examination of messages before fetching, etc.

There's a certain amount of use, I feel, of being able to use URLAUTH to, in effect, publish individual messages within a mailbox.

To put it another way, I feel that URLAUTH is fine for its stated scope, but I think its scope could be made wider.

However, this could most likely be handled by a further extension, rather than changing the existing specification, which looks as if it'll be fine.

CATENATE:

1) I saw Mark Crispin's comments in the archive, and agree with them - much better to extend APPEND/MULTIAPPEND than create a new command.

2) I'd prefer it to work on authenticated state as well. APPEND does, so (1) implies this anyway. I consider both of these to be fairly minor.

3) A minor nit: I'd prefer it if the examples used different tags - it just makes it easier to refer to them.

4) I'm wondering whether a client could use this to, for instance, change the Content-Disposition of a part, or other MIME part-specific headers. Content-Description would be particularly useful as well.

5) It's unclear to me whether the server is strictly required to place suitable MIME headers based on a URL or not - the examples imply that this is so, but the text appears to specifically state this is not so:

Section 3, "[...] as if the literal returned in a FETCH BODY response were put in place of the message part specifier.", which appears to suggest, to me, that it's the BODY[x.y], not the BODY[x.y.MIME] as well.

Finally, while I think I'll have URLAUTH and CATENATE enabled IMAP servers to test against in the near future, I don't know of a BURL/BINARY/CHUNKING capable submission server - if anyone has such a beast, I'd gratefully appreciate access. In fact, any implementations of any submission or IMAP extensions would be very useful - I've had CONDSTORE support for a while I'm unable to test.

Anyone who wants a copy of the client - and the underlying library - is welcome to have it under a GPL license. It's written in Python, using wxPython as the UI, and is intended to be cross-platform across Windows, Linux, Mac OS X, etc. It requires an ACAP account, and I'll happily hand them out on the assumption that nobody has an ACAP server.

Dave.

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

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 11 Feb 2005 13:08:04 +0000

Dave Cridland wrote:

> BURL looks fine to me, although I do wonder if it could be enhanced to 
> accept http scheme URLs - it's far from essential, but I can imagine a 
> situation where a salesman on the road wishes to send a document to a 
> customer which resides on, say, a WebDAV "office share".

I think this is something some of us are keeping in mind.
I think the only thing required is that the Submission server advertises 
support of HTTP URLs?
[...]

> There's a certain amount of use, I feel, of being able to use URLAUTH 
> to, in effect, publish individual messages within a mailbox.
>
> To put it another way, I feel that URLAUTH is fine for its stated 
> scope, but I think its scope could be made wider.
>
> However, this could most likely be handled by a further extension, 
> rather than changing the existing specification, which looks as if 
> it'll be fine.

This can also be easily dealt with by extending IMAP URL syntax.

> CATENATE:
>
> [...]
> 4) I'm wondering whether a client could use this to, for instance, 
> change the Content-Disposition of a part, or other MIME part-specific 
> headers. Content-Description would be particularly useful as well.

I think IMAP URL "section" syntax allows for that.

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 11 Feb 2005 13:17:53 +0000

Dave Cridland wrote:

> 5) It's unclear to me whether the server is strictly required to place 
> suitable MIME headers based on a URL or not - the examples imply that 
> this is so, but the text appears to specifically state this is not so:
>
> Section 3, "[...] as if the literal returned in a FETCH BODY response 
> were put in place of the message part specifier.", which appears to 
> suggest, to me, that it's the BODY[x.y], not the BODY[x.y.MIME] as well.

IMAP URL allows you to do either:
<imap://[email-masked]/gray-council/;uid=20/;section=1.2.MIME>

---

From: Dave Cridland <[email-masked]>
Date: Fri, 11 Feb 2005 14:18:18 +0000

> <imap://[email-masked]/gray-council/;uid=20/;section=1.2.MIME>

Yes, that specifies purely the MIME headers. [...];section=1.2 specifies purely the body of the part, and not the MIME headers, but according to the examples, that's enough - I don't need to include the headers as well. According to that excerpt from section 3 above, though, I need to provide the headers.

I'd like to assume that CATENATE is clever enough that if I specify a part only, with no headers, it would use the headers from that part. But then, if I want to change the headers, then what, exactly, do I send?

To borrow the first example from Appendix A:

C: D001 CATENATE Drafts FLAGS (\Seen \Draft $MDNSent) URL "imap://imap.example.org/Drafts;UIDVALIDITY=385759045/;UID=20;section=HEADER" TEXT {40+}
--------------030308070208000400050907
 URL "imap://imap.example.org/Drafts;UIDVALIDITY=385759045/;UID=20;section=1.1" TEXT {N+}
--------------030308070208000400050907
Content-Disposition: attachment; filename=stuff.txt
 URL "imap://imap.example.org/Drafts;UIDVALIDITY=385759045/;UID=30" TEXT {44+}
--------------030308070208000400050907--

S: OK Catenate completed.

Now... When I added the Content-Disposition header, did I:

a) Also inadvertantly remove all the other MIME headers
b) Duplicate the Content-Disposition header
c) Form an invalid message.
d) Cause the server to discard any Content-Disposition header (there isn't one in this example), and add any required but missing MIME headers (Content-Type: message/rfc822)

Dave.

---

From: Pete Resnick <[email-masked]>
Date: Sat, 12 Feb 2005 10:08:14 -0600

On 2/11/05 at 2:18 PM +0000, Dave Cridland wrote:

>Yes, that specifies purely the MIME headers. [...];section=1.2 
>specifies purely the body of the part, and not the MIME headers, but 
>according to the examples, that's enough - I don't need to include 
>the headers as well. According to that excerpt from section 3 above, 
>though, I need to provide the headers.

Yes, I think that's an error in the examples. You are required to 
specify the MIME headers if they are not in the included part. Will 
fix.

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: Mon, 14 Feb 2005 17:07:46 +0000

Dave Cridland wrote:

>>> 5) It's unclear to me whether the server is strictly required to 
>>> place suitable MIME headers based on a URL or not - the examples 
>>> imply that this is so, but the text appears to specifically state 
>>> this is not so:
>>
I think I finally understood the issue you are talking about.

>>> Section 3, "[...] as if the literal returned in a FETCH BODY 
>>> response were put in place of the message part specifier.", which 
>>> appears to suggest, to me, that it's the BODY[x.y], not the 
>>> BODY[x.y.MIME] as well.
>>
> according to the examples, that's enough - I don't need to include the 
> headers as well. According to that excerpt from section 3 above, 

This is a bug in examples.

> I'd like to assume that CATENATE is clever enough that if I specify a 
> part only, with no headers, it would use the headers from that part.

No, the client should provide all MIME headers. But the server should 
verify correctness of the constructed message.

> But then, if I want to change the headers, then what, exactly, do I send?
>
> C: D001 CATENATE Drafts FLAGS (\Seen \Draft $MDNSent) URL 
> "imap://imap.example.org/Drafts;UIDVALIDITY=385759045/;UID=20;section=HEADER" 
> TEXT {40+}
> URL 
> "imap://imap.example.org/Drafts;UIDVALIDITY=385759045/;UID=20;section=1.1" 
> TEXT {N+}
> d) Cause the server to discard any Content-Disposition header (there 
> isn't one in this example), and add any required but missing MIME 
> headers (Content-Type: message/rfc822)

You did a)+c), because an extra CRLF (header/body separator) is required 
after the inserted "Content-Disposition" header.