headers
Internet-Drafts | 1 Mar 2006 21:50
Picon
Favicon

I-D ACTION:draft-ietf-imapext-i18n-06.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF.

	Title		: Internet Message Access Protocol Internationalization
	Author(s)	: C. Newman, et al.
	Filename	: draft-ietf-imapext-i18n-06.txt
	Pages		: 16
	Date		: 2006-3-1
	
Internet Message Access Protocol (IMAP) version 4rev1 has basic
support for non-ASCII characters in mailbox names and search
substrings.  It also supports non-ASCII message headers and content
encoded as specified by Multipurpose Internet Mail Extensions
(MIME).  This specification defines a collection of IMAP extensions
which improve international support including comparator negotiation
for search, sort and thread, language negotiation for international
error text, and translations for namespace prefixes.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-imapext-i18n-06.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-imapext-i18n-06.txt".
(Continue reading)

Permalink | Reply | 19 comments |
headers
Dave Cridland | 1 Mar 2006 22:52

Re: I-D ACTION:draft-ietf-imapext-i18n-06.txt


I did a quick review of this, really to compare it against the 
comparator draft, and partly to see how "ready" it's looking. The 
summary is pretty ready, but not quite there yet.

On Wed Mar  1 20:50:01 2006, Internet-Drafts <at> ietf.org wrote:
> 	Title		: Internet Message Access Protocol Internationalization
> 	Author(s)	: C. Newman, et al.
> 	Filename	: draft-ietf-imapext-i18n-06.txt
> 	Pages		: 16
> 	Date		: 2006-3-1
> 	
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-imapext-i18n-06.txt

Okay, a handful of comments and notes:

1) Section 3.2, the LANGUAGE command allows only a single language 
tag.

This is problematic, because it means the client has to discover the 
list of supported languages, and select a suitable one. Is there 
anything against allowing a client to list languages the user can 
handle, in order? This would eliminate a round-trip, whilst still 
allowing clients to discover supported languages.

For example, given the examples, one might add:

< Server does not speak French, but does speak English. User speaks 
Canadian French and Canadian English. >
(Continue reading)

Permalink | Reply | 18 comments |
headers
Mark Crispin | 2 Mar 2006 00:17

Re: I-D ACTION:draft-ietf-imapext-i18n-06.txt


On Wed, 1 Mar 2006, Dave Cridland wrote:
> 1) Section 3.2, the LANGUAGE command allows only a single language tag.
> This is problematic, because it means the client has to discover the list of 
> supported languages, and select a suitable one. Is there anything against 
> allowing a client to list languages the user can handle, in order?

I agree.  I also believe that the use of language-range adds unnecessary 
complexity, and that adding an untagged response is unnecessary.

I also note that the language-data rule is dangling, and RFC 3066 is being 
replaced.

Suggest the following:

 	command-any =/ language-cmd
 	resp-text-code =/ resp-lang / resp-langs

 	language = "LANGUAGE" *[SP lang-tag]

 	resp-langs = "LANGUAGES" [SP "(" lang-tag *(SP lang-tag) ")" ]
 	resp-lang = "LANGUAGE" SP lang-tag

 	lang-tag = astring
 		;; contains language-tag as described in [5]

Command semantics as follows:

LANGUAGE command with no argument: Return tagged OK with resp-langs 
containing the list of languages.
(Continue reading)

Permalink | Reply | 10 comments |
headers
Arnt Gulbrandsen | 2 Mar 2006 13:36
Picon
Favicon
Gravatar

Re: I-D ACTION:draft-ietf-imapext-i18n-06.txt


Dave Cridland writes:
> 4) Section 4.4:
>
> I suspect that COMPARATOR is weak, but good enough for some 
> circumstances, albeit I'd prefer a more complex SEARCH. One problem 
> is that as specified, the example sequence B123 to B125 cannot be 
> pipelined.
>
> Could we add a COMPARATOR SEARCH option, which would override the 
> comparator used for that command only? Something like:
>
> B123 SEARCH COMPARATOR (i;octet) OR BODY GIF87A BODY GIF89A
>
> I think Alexey's IMAP ABNF has the template syntax present for a 
> search option.

We had this and dropped it. 18 months ago? There weren't any good 
examples, which always makes me feel bad. If one can't dream up at 
least one good example for an extension, maybe that extension isn't so 
useful in practice... so I asked whether any clients would use this and 
whether anything would be lost by omitting the COMPARATOR search-key. 
As I recall, noone stepped forward to speak in favour of the extra 
search-key, and Mark spoke in favour of simplicity.

There are four options:

1. No way to change comparator within the search command. Simple to 
implement for servers. Clients must change comparator before/after the 
search command.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Arnt Gulbrandsen | 2 Mar 2006 13:41
Picon
Favicon
Gravatar

Re: I-D ACTION:draft-ietf-imapext-i18n-06.txt


> 3. A comparator thingy which can go between any two search-keys and 
> which changes the comparator used from that point onwards.
>
> ...
>
> Discussion, please.

Speaking only for myself, 3 leaves a bad taste in my mouth. Feels like 
bad design.

I don't care much about 1/2/4.

Arnt
Permalink | Reply | 1 comment |
headers
Alexey Melnikov | 2 Mar 2006 13:43
Favicon

Re: I-D ACTION:draft-ietf-imapext-i18n-06.txt


Dave Cridland wrote:

> Okay, a handful of comments and notes:
>
> 1) Section 3.2, the LANGUAGE command allows only a single language tag.
>
> This is problematic, because it means the client has to discover the 
> list of supported languages, and select a suitable one. Is there 
> anything against allowing a client to list languages the user can 
> handle, in order? This would eliminate a round-trip, whilst still 
> allowing clients to discover supported languages.
>
> For example, given the examples, one might add:
>
> < Server does not speak French, but does speak English. User speaks 
> Canadian French and Canadian English. >
>
> C: A008 LANGUAGE FR-CA EN-CA
> S: * LANGUAGE (EN)
> S: A008 OK Now speaking English

I like that.

[...]

> 5) Section 5.1:
>
> Isn't this out of date WRT saslprep?
(Continue reading)

Permalink | Reply | 2 comments |
headers
Arnt Gulbrandsen | 2 Mar 2006 14:17
Picon
Favicon
Gravatar

Re: I-D ACTION:draft-ietf-imapext-i18n-06.txt


Alexey Melnikov writes:
> Dave Cridland wrote:
>> A simpler solution might be to promote SASL PLAIN as the i18n 
>> plaintext login, since that either will be, or has been, fixed, and 
>> deprecate LOGIN for even that.
>
> I would rather the document just state that both LOGIN usernames and 
> passwords are UTF-8 now.

Much as I'm in favour of that, I feel that this document is the wrong 
place for it. This document specifies two extensions. Making an 
unconditional change to 3501 in the same document feels bad. A bit like 
the way RFC 2231 modifies RFC 2060: Two lines changing 2060 buried in 
the middle of a ten-page document.

I suppose section 5 could be beefed up, so it's not such a tiny change. 
It could allow UTF-8 logins, passwords and mailbox names?

> Related to this. The second paragraph says:
>
>    When AUTHENTICATE is used, some servers may support userids and
>    passwords in Unicode [13]. However, such userids cannot be used as
>    email addresses, and at present also seem to be incompatible with
>    the current latest ACL drafts. Unless the ACL drafts resolve this,
>    server authors are cautioned against supporting ACL and unicode
>    userids simultaneously.
>
> The updated ACL got published as RFC 4314. So the end of this 
> paragraph is wrong.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Arnt Gulbrandsen | 2 Mar 2006 16:32
Picon
Favicon
Gravatar

draft-newman-i18n-comparator-07.txt just submitted


The internet-drafts edit seems to have a 2-3 day lag right now.

It's not complete. I'm not happy. I know I have comments from Martin 
Dürst that I haven't worked in yet (very sorry, Martin), and some other 
people's comments are also incompletely processed.

But I wanted to get this submitted. There were so many comments in the 
past week, and the diff is big. The only way to get a new revision out 
was to send it out incomplete.

$ diff -u /tmp/draft-newman-i18n-comparator-0[67].txt | wc -l
1380

There will be another draft fairly soon where I resolve the sort-key 
situation, work in Martin's comments and hopefully use a better DTD. 
The DTD change will also necessitate some textual changes. Early next 
week, I hope.

Now I have to do some of my own work.

Arnt
Permalink | Reply | 3 comments |
headers
Alexey Melnikov | 2 Mar 2006 16:37
Favicon

Re: I-D ACTION:draft-ietf-imapext-i18n-06.txt


Arnt Gulbrandsen wrote:

>> Related to this. The second paragraph says:
>>
>>    When AUTHENTICATE is used, some servers may support userids and
>>    passwords in Unicode [13]. However, such userids cannot be used as
>>    email addresses, and at present also seem to be incompatible with
>>    the current latest ACL drafts. Unless the ACL drafts resolve this,
>>    server authors are cautioned against supporting ACL and unicode
>>    userids simultaneously.
>>
>> The updated ACL got published as RFC 4314. So the end of this 
>> paragraph is wrong.
>
> Simplify my life. Give me text ;)

Delete everything till the end of paragraph, starting from ",and at 
present also seem to be incompatible".
Permalink | Reply | 0 comments |
headers
Arnt Gulbrandsen | 2 Mar 2006 16:41
Picon
Favicon
Gravatar

Re: draft-newman-i18n-comparator-07.txt just submitted


Arnt Gulbrandsen writes:
> Early next week, I hope.

No. Just before the cutoff, early Monday afternoon by my time.

Wait for that to comment, or get a copy from  me by email.

Arnt
Permalink | Reply | 2 comments |

Gmane