 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
Hi Joseph, Joseph Yee wrote:
InlineOn 2009-09-10, at 5:11 PM, Alexey Melnikov <alexey.melnikov at isode.com> wrote:Barry Leiba wrote:Hi, Pete.Hi Barry,OLD The UTF8=ONLY capability implies the UTF8 base capability, the UTF8=ALL capability and the UTF8=APPEND capability. A server which advertises UTF8=ONLY need not advertise the three implicit capabilities.Oy. This makes parsing the capability string complicated, and shouldbe earlier in the document. It'd be good to make this clear at the beginning, when the UTF8 capability is first mentioned.I'm not sure what you want here. Something in the "UTF8" section that says, "See below"? Left as is for now. Fix in an RFC Editor Note if need be.When one starts reading the document, one gets to this: --------------------------------------------- 3. UTF8 IMAP Capability The basic "UTF8" capability indicates the server supports UTF-8 quoted strings, the "UTF8" parameter to SELECT and EXAMINE, and UTF-8 responses from the LIST and LSUB commands. --------------------------------------------- It's only later, when one gets to section 7, which I quote above, that one finds that it's not sufficient to look for "UTF8": one also has to look for "UTF8=ONLY". And we don't say that UTF8=ALL, UTF8=APPEND, or UTF8=USER imply the base UTF8. So if UTF8=ONLY is special, I think we need to say that right up there at the start of section 3, so it's clear. Or else we say that the presence of *any* "UTF8=" capability implies the base UTF8, and say *that* in section 3, so it's clear right up front as to what capability string(s) need to be checked for. D'you see what I'm getting at?(As the responsible AD) After rereading various pieces of the document, I agree this is not clear.(As a WG participant) Here is my understanding how things should work:UTF8=USER is useful by itself, so I think it should be independent of all other UTF8* capabilities. For example it should be possible to only support UTF8=USER (non EAI IMAP server, but which accepts UTF-8 usernames/passwords), or support all other EAI functions, without supporting UTF-8 username/password (e.g. a legacy authentication database).I agree with the second part and that's my understanding of the doc. Not sure of the first part. Allowing UTF8 login/password but not UTF8- IMAP capable? I don't think we need special capa for it, it can be done today...
The base IMAP spec (RFC 3501) doesn't explicitly allow for UTF-8 username/passwords. So a server supporting UTF-8 usernames/passwords needs to advertise it to the client.
I will double check this with the author of RFC 3501 though. RFC 5255 states that in section 5.1, but I don't see any text in RFC 3501 on this. If I am wrong on this, then the UTF-8=USER capability would need to be removed altogether.
I think UTF8=APPEND should be independent of other UTF8* capabilities. Allowing for EAI APPEND might require quite a bit of extra work.I personally think it can imply UTF8 but not any other UTF8-*.
I suppose that would be Ok as well. It is very unlikely that a server will only want to implement EAI APPEND, without wanting to implement the rest of EAI in IMAP.
Not sure if you mean the same from UTF8*Both UTF8=ALL and UTF8=ONLY are related to UTF8 capability. We can either define them as implying UTF8, or say that if one of them is advertised, then UTF8 MUST also be advertised. Moreover, I think UTF8=ONLY implies UTF8=ALL. One can also argue that UTF8=ONLY implies UTF8=APPEND. I would be Ok either way, but one way or another this needs to be stated explicitly.Section 7 of the doc makes it clear that UTF8-ONLY implies both ALL and APPEND. I have not fully read -08 yet, is it not there anymore?
No, you are correct. I've missed the following paragraph which is quite clear on this:
The UTF8=ONLY capability implies the UTF8 base capability, the UTF8=ALL capability and the UTF8=APPEND capability. A server that advertises UTF8=ONLY need not advertise the three implicit capabilities.