Subject: [lemonade] catenate-04 submitted

From: Pete Resnick <[email-masked]>
Date: Wed, 16 Feb 2005 17:00:46 -0600

I've done a re-write using the APPEND command. It's submitted to the 
I-D editor. In the meanwhile, you can find the draft here:

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

We've still got time to get one more draft in over the weekend. 
Please have a look and let me know. Alexey especially wanted someone 
to scour the examples. Either way, I think this should delay the 
completion of the WGLC.

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: Pete Resnick <[email-masked]>
Date: Wed, 16 Feb 2005 21:01:29 -0600

On 2/16/05 at 5:00 PM -0600, Pete Resnick wrote:

>I've done a re-write using the APPEND command.

Already, Mark has made some suggestions privately, and I've changed 
my editing copy:

1. s/modifies/extends in the Abstract and Introduction.
2. Insert the leading CRLF of the MIME boundaries in the Examples.
3. Beef up the second to last paragraph of section 3 to read:

The client is responsible for making sure that the catenated message 
is in the format of an RFC 2822 message. In particular, when a URL is 
catenated, the server copies octets, unchanged, from the indicated 
message or message part to the catenated message. It does no data 
conversion (e.g. MIME transfer encodings); nor any verification that 
the data is appropriate for the MIME part of the message into which 
it is inserted. The client is also responsible for inserting 
appropriate MIME boundaries between body parts, and writing MIME 
Content-Type and Content-Transfer-Encoding lines as needed in the 
appropriate places.

Please, make comments before the weekend just in case I want to float 
another draft before the deadline.

pr
QUALCOMM Incorporated

---

From: Philip Guenther <[email-masked]>
Date: Fri, 18 Feb 2005 22:18:41 -0800

Something is missing from the fourth sentence in the second paragraph of
section 1: "...can create a message in the its own IMAP store..."

Should the third paragraph of section 1 begin "The updated APPEND
command..." or perhaps "The modified APPEND command..."?

s/token "CATENATE"/atom "CATENATE"/

Should the CATENATE extension permit relative URLs, specifying that the
base URL is "imap://currentuser@servername/" in the authenticated state
or "imap://currentuser@servername/encoded-selected-mailbox" in the
selected state?

Should the TOOBIG response be changed to include the maximum the server
will permit in that mailbox?

In the syntax, I would tend to move the space-separated-list logic into
the append-catenate rule, ala:
   append-catenate = "CATENATE" SP "(" catenate-part *(SP catenate-part) ")"

   catenate-part = text-literal / url

If I'm reading RFC 2192 (imap URL scheme), section 3, correctly, the
examples should include ";AUTH=*@", else they would be implicitly
specifying the anonymous user.  Specifying a base URL for the URLs in
the CATENATE command would let that be solved by removing the
"imap://imap.example.org/" from each URL.

The third example should note that the server may validate URLs as they
are received and therefore could return the tagged NO response with
BADURL response-code in place of any continuation request after the URL
was received (i.e., one or two "S: " lines earlier).

Philip Guenther

---

From: Pete Resnick <[email-masked]>
Date: Sat, 19 Feb 2005 08:59:39 -0600

On 2/18/05 at 10:18 PM -0800, Philip Guenther wrote:

>Something is missing from the fourth sentence in the second 
>paragraph of section 1: "...can create a message in the its own IMAP 
>store..."

Strike "the". Done.

>command..." or perhaps "The modified APPEND command..."?

"The extended APPEND command" seems good. Done.

>s/token "CATENATE"/atom "CATENATE"/

I know "CATENATE" is an ABNF "atom", but I'm not sure this sentence 
should use that word. Care to explain?

>Should the CATENATE extension permit relative URLs, specifying that 
>the base URL is "imap://currentuser@servername/" in the 
>authenticated state or 
>"imap://currentuser@servername/encoded-selected-mailbox" in the 
>selected state?

That seems perfectly reasonable. See below with regard to ";AUTH=".

>Should the TOOBIG response be changed to include the maximum the 
>server will permit in that mailbox?

I think that's included in "the server specific message size limit", 
but I could change it to "any message size limit imposed by the 
server."

>In the syntax, I would tend to move the space-separated-list logic 
>into the append-catenate rule, ala:

That exceeds the 72 character line limit. If folks think it's 
important (it is only aesthetics), I could wrap the line.

>specifying the anonymous user.

2192 does say, "If no user name is  specified and no appropriate 
authentication mechanisms are  available, the client SHOULD fall back 
to anonymous login as  described above." We can give specific 
guidance to violate the SHOULD in this case, as the URL is being used 
in the authenticated state of an IMAP session. I think a full 
discussion of this can go with the discussion of the base URL issue. 
How's about the following, inserted before the "Note:" in section 3?

Message URLs are interpreted according to the rules of RFC2192. 
However, since the APPEND command is valid in the authenticated state 
of an IMAP session, no further LOGIN or AUTHENTICATE command is 
performed for URLs specified in the APPEND command, and therefore no 
";AUTH=" string is required in the URL. A URL without an ";AUTH=" 
string refers to a message from the currently authenticated IMAP 
session. Furthermore, for relative IMAP URLs, the base URL is 
considered "imap://currentuser@servername/", where "currentuser" is 
the username of the currently authenticated user, and "servername" is 
the domain name of the current server. When in the selected state, 
the base URL is considered 
"imap://currentuser@servername/selectedmailbox", where 
"selectedmailbox" is the encoded name of the currently selected 
mailbox.

>The third example should note that the server may validate URLs as 
>they are received and therefore could return the tagged NO response 
>with BADURL response-code in place of any continuation request after 
>the URL was received (i.e., one or two "S: " lines earlier).

Seems OK to me.

pr

---

From: Philip Guenther <[email-masked]>
Date: Sat, 19 Feb 2005 14:15:55 -0800

>On 2/18/05 at 10:18 PM -0800, Philip Guenther wrote:
...
>should use that word. Care to explain?

Hmm, I was going to say that it sounded more natural to me with 'atom',
but after checking other IMAP RFCs, I see they generally use neither
'atom' nor 'token'.  Indeed, that's how "URL" appears in the
parenthetical remark two sentences later.  That suggest making it just 
	If the new form is used, "CATENATE" and a parenthesized list...

At the least, I think
	(indicated by the "TEXT")
should be changed to
	(indicated by "TEXT")
to match "indicated by "URL"".

...
>but I could change it to "any message size limit imposed by the 

Sorry, let me clarify my query: should the syntax of the TOOBIG
response-code be changed to

   toobig_response_code = "TOOBIG" SP nz-number

so that the server can return to the client the exact value of the limit
that it exceeded?  On reflection, I'm not sure that would truly be
useful to the client and I can imagine servers where determining the
exact limit (i.e., space available) would be onerous, so it's probably
better left the way it is.

...
<regarding base urls>
>"selectedmailbox" is the encoded name of the currently selected 

Since you explain the words in the base URL, I would suggest either
changing "currentuser" to "user", "servername" to "server", and
"selectedmailbox" to "encoded-mailbox" OR adding hyphens to make the
existing words more readable.  (I used the compound words because I was
too lazy to write out their explanations; once you have explanations I
think the shorter words scan better.)  That's only a minor nit, though.
I think your new text is excellent.

Philip Guenther

---

From: Pete Resnick <[email-masked]>
Date: Sat, 19 Feb 2005 18:10:43 -0600

On 2/19/05 at 2:15 PM -0800, Philip Guenther wrote:

>...suggest making it just

Done.

>	(indicated by the "TEXT")

Done.

>so that the server can return to the client the exact value of the 
>limit that it exceeded?  On reflection, I'm not sure that would 
>truly be useful to the client and I can imagine servers where 
>determining the exact limit (i.e., space available) would be 
>onerous, so it's probably better left the way it is.

Leaving it as is.

>changing "currentuser" to "user", "servername" to "server"

Done.

>"selectedmailbox" to "encoded-mailbox"

Changed to simply "mailbox".

Thanks.

pr

---

From: Philip Guenther <[email-masked]>
Date: Wed, 23 Feb 2005 14:50:54 -0800

>How about :
>
>    append-catenate = "CATENATE" SP "(" cat-part *(SP cat-part) ")"

Looks good.

...
>I have one remaining concern: If folks use relative URLs in the 
>selected state, how can they indicate a mailbox other than the 
>selected mailbox?

If the supplied URL starts with a single slash, then it's an
absolute-path reference and starts from the top of the hierarchy on the
current server.

There's also the possibility of relative-path references, though they're
practically useless in folder namespaces that don't use slash as the
hierarchy delimiter.  Clients may be well advised to avoid them simply
to avoid having to consider that case.

Philip Guenther

---

From: Pete Resnick <[email-masked]>
Date: Tue, 22 Feb 2005 16:39:02 -0600

On 2/22/05 at 1:06 PM +0000, Alexey Melnikov wrote:

>I like Philip's suggestion.

So you would like the above, but wrap the line?

>>>If I'm reading RFC 2192 (imap URL scheme), section 3, correctly, 
>>>the examples should include ";AUTH=*@", else they would be 
>>>implicitly specifying the anonymous user.
>>
>>authentication mechanisms are  available, the client SHOULD fall 
>>back to anonymous login as  described above." We can give specific 
>>guidance to violate the SHOULD in this case, as the URL is being 
>>used in the authenticated state of an IMAP session. I think a full 
>>discussion of this can go with the discussion of the base URL 
>>issue. How's about the following, inserted before the "Note:" in 
>>section 3?
>
>IMHO, examples must be fixed to have a proper username.

I don't see why. A username should be unnecessary. In fact, perhaps I 
should add to the paragraph:

Message URLs are interpreted according to the rules of RFC2192. 
However, since the APPEND command is valid in the authenticated state 
of an IMAP session, no further LOGIN or AUTHENTICATE command is 
performed for URLs specified in the APPEND command, and therefore no 
";AUTH=" string is required in the URL. A URL without an ";AUTH=" 
string refers to a message from the currently authenticated IMAP 
session. Furthermore, the username is not required, nor for that 
matter is a fully qualified IMAP URL with the "imap:" scheme and 
server name; relative URLs are perfectly acceptable. For relative 
URLs, the base URL is considered "imap://user@server/", where "user" 
is the username of the currently authenticated user, and "server" is 
the domain name of the current server. When in the selected state, 
the base URL is considered "imap://user@server/mailbox", where 
"mailbox" is the encoded name of the currently selected mailbox.

>>>they are received and therefore could return the tagged NO 
>>>response with BADURL response-code in place of any continuation 
>>>request after the URL was received (i.e., one or two "S: " lines 
>>>earlier).
>>
>>Seems OK to me.
>
>And to me.

You mean the *fourth* example, right?

pr

---

From: Pete Resnick <[email-masked]>
Date: Wed, 23 Feb 2005 13:43:10 -0600

On 2/23/05 at 12:47 PM +0000, Alexey Melnikov wrote:

>Pete Resnick wrote:
>Yes.

How about :

>>I don't see why. A username should be unnecessary.
>
>I would prefer that the client specifies relative URLs in this case, 
>so no special handling would be needed.

2192 already accounts for no username: "If the URL doesn't  supply a 
user name, the program interpreting the IMAP URL SHOULD  request one 
from the user if necessary." So, I'm inclined to make the paragraph 
read:

Message URLs are interpreted according to the rules of RFC 2192. 
However, since the APPEND command is valid in the authenticated state 
of an IMAP  session, no further LOGIN or AUTHENTICATE command is 
performed for URLs specified in  the APPEND command, and therefore no 
";AUTH=" string is required in the URL. A URL  without an ";AUTH=" 
string refers to a message from the currently authenticated IMAP 
session. Furthermore, the user name is not required and, if not 
supplied, is the  user name of the currently authenticated user. For 
relative IMAP URLs, the base URL  is considered 
"imap://user@server/", where "user" is the user name of the currently 
authenticated user, and "server" is the domain name of the current 
server. When in  the selected state, the base URL is considered 
"imap://user@server/mailbox", where  "mailbox" is the encoded name of 
the currently selected mailbox.

pr

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 22 Feb 2005 13:06:43 +0000

Pete Resnick wrote:

>> the base URL is "imap://currentuser@servername/" in the authenticated 
>> state or "imap://currentuser@servername/encoded-selected-mailbox" in 
>> the selected state?
>
> That seems perfectly reasonable.

I agree.

> See below with regard to ";AUTH=".

[...]

> to anonymous login as  described above." We can give specific guidance 
> to violate the SHOULD in this case, as the URL is being used in the 
> authenticated state of an IMAP session. I think a full discussion of 
> this can go with the discussion of the base URL issue. How's about the 
> following, inserted before the "Note:" in section 3?

IMHO, examples must be fixed to have a proper username. After that, I am 
not sure that your text about missing ";AUTH=" is relevant.

> the domain name of the current server. When in the selected state, the 
> base URL is considered 
> "selectedmailbox" is the encoded name of the currently selected mailbox.

Looks good to me (after proposed Philip's changes).

And to me.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 23 Feb 2005 12:47:14 +0000

Yes.

> base URL is considered "imap://user@server/mailbox", where "mailbox" 
> is the encoded name of the currently selected mailbox.

I would prefer that the client specifies relative URLs in this case, so 
no special handling would be needed.

>>>> with BADURL response-code in place of any continuation request 
>>>> after the URL was received (i.e., one or two "S: " lines earlier).
>>>
>>> Seems OK to me.
>>
>> And to me.
>

Yes.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 23 Feb 2005 22:10:42 +0000

>> from the user if necessary." So, I'm inclined to make the paragraph 
It sounds wrong to me that we redefine behavior of existing constructs 
while there is a perfectly acceptable way of doing the same: if the 
client doesn't want to send username (and in this case hostname should 
be omitted too), it should use a relative URL.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 23 Feb 2005 21:48:06 +0000

>    append-catenate = "CATENATE" SP "(" cat-part *(SP cat-part) ")"

Fine with me.

> from the user if necessary." So, I'm inclined to make the paragraph read:
>
> string refers to a message from the currently authenticated IMAP session.

I would change the last sentence to "A URL  without an ";AUTH=" string 
refers to a message accessible from the currently authenticated IMAP 
session."
This will also allow for "imap://<otheruser>@<server>/<mailbox>", where 
<otheruser> != current user.

BTW, how does CATENATE interact with URLAUTH URLs?

> Furthermore, the user name is not required and, if not supplied, is 
> the  user name of the currently authenticated user. For relative IMAP 
> is the user name of the currently authenticated user, and "server" is 

"/Drafts;UIDVALIDITY=385759045/;UID=20;section=HEADER"
?

I think it is better to use the same base URL "imap://user@server/" in 
all states. This seems to make any URL generation logic simpler in clients.

Alexey

---

From: Dave Cridland <[email-masked]>
Date: Thu, 24 Feb 2005 13:35:38 +0000

On Wed Feb 23 22:10:42 2005, Alexey Melnikov wrote:
>>>> I would prefer that the client specifies relative URLs in this case, so no special handling would be needed.
>>> 
>>> 2192 already accounts for no username: "If the URL doesn't  supply a user name, the program interpreting the IMAP URL SHOULD  request one from the user if necessary." So, I'm inclined to make the paragraph read:
>> 
> It sounds wrong to me that we redefine behavior of existing constructs while there is a perfectly acceptable way of doing the same: if the client doesn't want to send username (and in this case hostname should be omitted too), it should use a relative URL.

I'd be inclined to say MUST. Otherwise an IMAP server has to know all possible hostnames for itself, to detirmine whether it's being asked to CATENATE a part from another message in its own store, or whether it's URLAUTH, or simply an anonymous access IMAP server that it needs to fetch the part from.

Most ISPs, for instance, tend to provide a CNAME or A record for every domain they manage pointing to their mail servers - that's a common practise unlikely to change and very difficult to handle the full URL case - if we later expand this to interact with URLAUTH and other IMAP URLs.

Dave.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 24 Feb 2005 13:44:52 +0000

Dave Cridland wrote:

>>>>> I would prefer that the client specifies relative URLs in this 
>>>>> case, so no special handling would be needed.
>>>>
>>>> 2192 already accounts for no username: "If the URL doesn't  supply 
>>>> a user name, the program interpreting the IMAP URL SHOULD  request 
>>>> one from the user if necessary." So, I'm inclined to make the 
>>>> paragraph read:
>>>
>> It sounds wrong to me that we redefine behavior of existing 
>> constructs while there is a perfectly acceptable way of doing the 
>> same: if the client doesn't want to send username (and in this case 
>> hostname should be omitted too), it should use a relative URL.
>
> I'd be inclined to say MUST. Otherwise an IMAP server has to know all 
> possible hostnames for itself, to detirmine whether it's being asked 
> to CATENATE a part from another message in its own store, or whether 
> it's URLAUTH, or simply an anonymous access IMAP server that it needs 
> to fetch the part from.

Good point. If the client specifies a hostname, the server must verify 
it, for example by doing a DNS lookup.

> Most ISPs, for instance, tend to provide a CNAME or A record for every 
> domain they manage pointing to their mail servers - that's a common 
> practise unlikely to change and very difficult to handle the full URL 
> case - if we later expand this to interact with URLAUTH and other IMAP 
> URLs.

---

From: Dave Cridland <[email-masked]>
Date: Thu, 24 Feb 2005 15:45:17 +0000

On Thu Feb 24 13:44:52 2005, Alexey Melnikov wrote:
> Good point. If the client specifies a hostname, the server must verify it, for example by doing a DNS lookup.
> 

Then  it has to know all possible IP addresses for itself, including those on NAT port redirectors, etc. It's a smaller problem, but still a problem. Forcing relative URLs avoids this problem entirely.

Also, if you further restrict clients to using URLs relative to the server (as opposed to the selected mailbox if any), then spotting invalid URLs is quite easy [Is the first character not '/'?], and APPEND doesn't change its behaviour depending on state.

I doubt whether many clients would use URLs relative to the currently selected mailbox anyway.

That merely leaves the question of whether a server should reject URLs without UIDVALIDITY included, which I think needs to be a MUST, to avoid accidental sending of the wrong data.

Of course, none of this applies if the URL was begat from URLAUTH, or was an anonymous imap URL, or was some other scheme entirely, but as I understand things, that's all outside the scope of CATENATE at this stage. But this way such URLs would be easier to process, I'd have thought.

Dave.

---

From: Pete Resnick <[email-masked]>
Date: Fri, 25 Feb 2005 10:41:21 -0600

On 2/23/05 at 9:48 PM +0000, Alexey Melnikov wrote:

>Pete Resnick wrote:
>
>>A URL  without an ";AUTH=" string refers to a message from the 
>>currently authenticated IMAP session.
>
>I would change the last sentence to "A URL  without an ";AUTH=" 
>string refers to a message accessible from the currently 
>authenticated IMAP session."
>This will also allow for "imap://<otheruser>@<server>/<mailbox>", 
>where <otheruser> != current user.

I see what you're getting at. How about this: "When a URL has an 
";AUTH=*" string, or does not have an ";AUTH=" string at all, the 
current authenticated session is used."

>BTW, how does CATENATE interact with URLAUTH URLs?

I don't see why they should be a problem. Is there anything you think 
needs pointing out?

Yup, of course. As Philip Guenther wrote on 2/23/05 at 2:50 PM -0800:

>absolute-path reference and starts from the top of the hierarchy on 
>the current server.

That's in the definition of relative URLs. Of course that makes sense.

>There's also the possibility of relative-path references, though 
>they're practically useless in folder namespaces that don't use 
>slash as the hierarchy delimiter.  Clients may be well advised to 
>avoid them simply to avoid having to consider that case.

That advice is in RFC 2192.

On 2/24/05 at 3:45 PM +0000, Dave Cridland wrote:
>>>>same: if the client doesn't want to send username (and in this 
>>>>case hostname should be omitted too), it should use a relative 
>>>>URL.

Actually, I think I now believe Alexey. 2192 also says, "If no user 
name or authentication  mechanism is supplied, the user name 
"anonymous" is used..." So, I'll remove the bit about leaving out the 
user name. If you want to do that, use a relative URL.

>>>I'd be inclined to say MUST. Otherwise an IMAP server has to know 
>>>all possible hostnames for itself, to detirmine whether it's being 
>>>asked to CATENATE a part from another message in its own store, or 
>>>whether it's URLAUTH, or simply an anonymous access IMAP server 
>>>that it needs to fetch the part from.
>>
>>Good point. If the client specifies a hostname, the server must 
>>verify it, for example by doing a DNS lookup.
>
>Then  it has to know all possible IP addresses for itself, including 
>those on NAT port redirectors, etc. It's a smaller problem, but 
>still a problem. Forcing relative URLs avoids this problem entirely.

But it does mean that you can't access IMAP messages that are on the 
local server but in another user's (or anonymous) readable space. 
That's not currently a limitation in the spec. Are you suggesting it 
should be?

Is there no way for the server to determine "this domain name is me"?

>Also, if you further restrict clients to using URLs relative to the 
>server (as opposed to the selected mailbox if any), then spotting 
>invalid URLs is quite easy [Is the first character not '/'?], and 
>APPEND doesn't change its behaviour depending on state.

I can understand not wanting the base to change according to state. I 
can remove that bit about the selected mailbox if you all think 
that's what you want. But I'm not convinced that a server should 
reject *all* absolute URLs, even if a server knows that a URL refers 
to itself.

>currently selected mailbox anyway.

Right now, clients SELECT a mailbox, FETCH a message, and then APPEND 
it to the server. I can see a client replacing simply the 
FETCH/APPEND part by doing doing:

APPEND blah blah URL "UID=50" blah blah

That way you don't have to have the context of which mailbox you're 
FETCHing from in the routine that does the APPEND.

>That merely leaves the question of whether a server should reject 
>URLs without UIDVALIDITY included, which I think needs to be a MUST, 
>to avoid accidental sending of the wrong data.

Again, I can see a client having a set of routines that does a SELECT 
followed by a series of commands. I can see a client depending on 
UIDVALIDITY being stable during the selected state and not passing 
around that value to routines that need to do FETCHes. I don't see 
why we should require UIDVALIDITY if the client knows what it's 
asking for.

pr

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 25 Feb 2005 17:40:20 +0000

Pete Resnick wrote:

>> those on NAT port redirectors, etc. It's a smaller problem, but still 
>> a problem. Forcing relative URLs avoids this problem entirely.
>

I think the client should be able to do that, but it shouldn't make 
server work harder. Relative URLs should be easier for the server.

> can remove that bit about the selected mailbox if you all think that's 
> what you want.

I certainly want to see this change.

> But I'm not convinced that a server should reject *all* absolute URLs, 
> even if a server knows that a URL refers to itself.

I don't think we should reject all absolute URLs.

> it to the server. I can see a client replacing simply the FETCH/APPEND 
> part by doing doing:
>
> around that value to routines that need to do FETCHes. I don't see why 
> we should require UIDVALIDITY if the client knows what it's asking for.

Hmm, your basic assumption is that IMAP URLs are short-lived.
URLAUTH urls are long-lived, so they should have UIDVALIDITY.

---

From: Pete Resnick <[email-masked]>
Date: Fri, 25 Feb 2005 12:21:47 -0600

On 2/25/05 at 5:40 PM +0000, Alexey Melnikov wrote:

>>>Then  it has to know all possible IP addresses for itself, 
>>>including those on NAT port redirectors, etc. It's a smaller 
>>>problem, but still a problem. Forcing relative URLs avoids this 
>>>problem entirely.
>>
>>But it does mean that you can't access IMAP messages that are on 
>>the local server but in another user's (or anonymous) readable 
>>space. That's not currently a limitation in the spec. Are you 
>>suggesting it should be?
>

So you're saying that relative URLs are *not* required. I tend to 
agree with that. I agree that relative URLs are easier on the server, 
but I don't think we can require them. Any change to the current text 
in that regard?

>>I can understand not wanting the base to change according to state. 
>>I can remove that bit about the selected mailbox if you all think 
>>that's what you want.
>

So you don't buy the argument that clients will want to SELECT and 
then use UID without having to specify the mailbox in each URL? Like:

>>Right now, clients SELECT a mailbox, FETCH a message, and then 
>>APPEND it to the server. I can see a client replacing simply the 

That's why I wanted to have the base switch in the selected state.

>>But I'm not convinced that a server should reject *all* absolute 
>>URLs, even if a server knows that a URL refers to itself.
>

Works for me.

>>>URLs without UIDVALIDITY included, which I think needs to be a 
>>>MUST, to avoid accidental sending of the wrong data.
>>
>>Again, I can see a client having a set of routines that does a 
>>SELECT followed by a series of commands. I can see a client 
>>depending on UIDVALIDITY being stable during the selected state and 
>>not passing around that value to routines that need to do FETCHes. 
>>I don't see why we should require UIDVALIDITY if the client knows 
>>what it's asking for.
>

David was suggesting that we *require* UIDVALIDITY on *all* URLs 
passed in the new APPEND command. That doesn't make sense to me.

pr

---

From: Dave Cridland <[email-masked]>
Date: Sat, 26 Feb 2005 10:34:08 +0000

On Fri Feb 25 18:21:47 2005, Pete Resnick wrote:
> So you're saying that relative URLs are *not* required. I tend to agree with that. I agree that relative URLs are easier on the server, but I don't think we can require them. Any change to the current text in that regard?
> 

Yes, I'm not thinking about all cases - where the name of a mailbox changes depending on the current user, then you do indeed need an absolute URL. Which is a shame, it means extra configuration, since a client can only form a URL which *it* can then use to access the server, not one that the server can use.

One option might be to mandate that, where a local absolute URL is used, the hostname used should be "localhost".

> 
>>> I can understand not wanting the base to change according to state. I can remove that bit about the selected mailbox if you all think that's what you want.
>> 
> So you don't buy the argument that clients will want to SELECT and then use UID without having to specify the mailbox in each URL? Like:
> 
> 
>>> Right now, clients SELECT a mailbox, FETCH a message, and then APPEND it to the server. I can see a client replacing simply the FETCH/APPEND part by doing doing:
>>> 
>>> That way you don't have to have the context of which mailbox you're FETCHing from in the routine that does the APPEND.
> 

Yes, I agree this is a common use-case - in fact, probably the most common. I'm wary, though, of having the usable syntax of a command change dependent on state.

As far as I'm aware, no other commands do this - they're simply valid or not in a given state, and don't actually change.

> 
>>> But I'm not convinced that a server should reject *all* absolute URLs, even if a server knows that a URL refers to itself.
>> 

I'm quite happy to accept I've been proved wrong on this, let's keep them.

I'd suggest that URLs intended to specify a local mailbox, using the name suitable for the local user, SHOULD be relative, though.

>>> Again, I can see a client having a set of routines that does a SELECT followed by a series of commands. I can see a client depending on UIDVALIDITY being stable during the selected state and not passing around that value to routines that need to do FETCHes. I don't see why we should require UIDVALIDITY if the client knows what it's asking for.
>> 
> David was suggesting that we *require* UIDVALIDITY on *all* URLs passed in the new APPEND command. That doesn't make sense to me.

It depends on whether you want the APPEND command to change dependent on state, in order to allow "UID=50" style URLs. In this one case, you don't need UIDVALIDITY, in all others, you do.

The chance of a client being caught out by a UIDVALIDITY change it is unaware of is small, but possible. (And a nightmare to track down.)

Dave.