Subject: [lemonade] Comments on implementing BURL, CATENATE, and URLAUTH

From: Dave Cridland <[email-masked]>
Date: Wed, 30 Nov 2005 23:21:36 +0000

As well as the point about ipartial support in CATENATE/URLAUTH, 
whilst actively testing (and heartily rewriting) suppport for the 
triad, I've noted a few issues, all fairly minor, that I've found 
when actually implementing them.

I'm using Ken's implementation of CATENATE and URLAUTH in the Cyrus 
IMAPd 2.3.0 CVS branch, but I've written both client support and a 
prototype submission server. Both support Lemonade Profile 1 (or are 
intended to), but the client is not restricted to Lemonade Profile 1 
- it'll use whatever extensions are available. The client is GPL 
licensed, available at http://dave.cridland.net/acap/polymer.html and 
the submission server is unreleased, although I'm happy to give 
access to it (and a corresponding Cyrus 2.3 server) for testing 
purposes.

I'm saying this to stress that I'm not talking about theoretical 
problems but actual ones I've encountered.

1) I ran into an almost immediate problem with URLAUTH in that the 
server didn't recognise the hostname in the URL as being its own. I 
used 'mail' rather than the server's canonical hostname.

It occurs to me that if GENURLAUTH accepted a relative URL (either to 
the server URL, or to the currently selected mailbox as with 
CATENATE), this problem would vanish. The server is always in a 
better position than the client to construct the URL to the server.

And think of all those octets we'll save. ;-)

2) There's no way to know whether a submission server you're talking 
to:

a) Is authorized by the IMAP server to access "submit+" URLAUTH URLs.

b) Will understand and use "anonymous" URLAUTH URLs, or simply 
anonymous URLs.

The BURL draft says that submission servers advertising "BURL imap" 
can resolve "submit+" URLAUTH URLs "within the same domain", but 
that's a little vague.

For a Lemonade-restricted client, I don't think this is an issue, but 
I'd like to see it considered for the future.

FWIW, my own submission server handles any anonymous access URLs 
(URLAUTH or not) it's given, and I'm intending to solve problem (a) 
by making the somewhat ugly assumption that the specified draft 
folder is on a server that authorizes the submission server as 
"submit+".

3) I found it unclear what response BURL generates when used with 
CHUNKING. It seems natural that, given that RFC3030 clearly shows a 
250 response for non-LAST chunks with BDAT, that BURL should also, 
but in section 6, a "354" response code is listed. I have chosen to 
expect, and emit, 250 response codes, in line with BDAT.

4) I found it unclear whether URLFETCH should accept relative URLs or 
not. I have no opinion on whether it should or not, either, given 
that the only purposes I can think of would be stateless access to 
message bodies, and I'm not sure that's within the spirit of things.

I'd be very interested to know if other client implementors have run 
into the same problems.

If, in areas where I state a lack of clarity, I'm merely being 
foolish, please correct me.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

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

---

From: Mark Crispin <[email-masked]>
Date: Wed, 30 Nov 2005 17:16:14 -0800 (Pacific Standard Time)

On Wed, 30 Nov 2005, Dave Cridland wrote:
> 1) I ran into an almost immediate problem with URLAUTH in that the server 
> didn't recognise the hostname in the URL as being its own. I used 'mail' 
> rather than the server's canonical hostname.

For better or worse, I think that a server needs to recognize its name(s) 
and not assume a canonicalization.  Canonicalization implies chasing CNAME 
and possibly a PTR lookup.

> It occurs to me that if GENURLAUTH accepted a relative URL (either to the 
> server URL, or to the currently selected mailbox as with CATENATE), this 
> problem would vanish. The server is always in a better position than the 
> client to construct the URL to the server.

I question whether this is really so, given virtual hosts and other such 
complications.

> 2) There's no way to know whether a submission server you're talking to:
> b) Will understand and use "anonymous" URLAUTH URLs, or simply anonymous 
> URLs.

I always thought that this was something that this would be knowledge that 
is configured into the client, either by the human user or by some system 
configuration tool.

> 4) I found it unclear whether URLFETCH should accept relative URLs or not. I 
> have no opinion on whether it should or not, either, given that the only 
> purposes I can think of would be stateless access to message bodies, and I'm 
> not sure that's within the spirit of things.

I thought that in LEMONADE we require absolute.

Stateless access to message bodies is certainly a possibility, considered 
from the inception of URLAUTH.  I'm not sure if I consider it to be "good" 
or "bad" (I tend towards the latter) but it certainly was considered.

:-)

-- Mark --

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