headers
Arnt Gulbrandsen | 1 Dec 2006 20:23
Favicon

Re: LANGUAGE/COMPARATOR review


Alexey Melnikov writes:
> Arnt, can you remind me why you removed "server MUST sends NAMEPSPACE 
> response on LANGUAGE command, if the user is in authenticated state"?

I sort of reinstated it now. There now is a honest requirement that 
server and client bot support NAMESPACE.

Arnt
Permalink | Reply | 0 comments |
headers
Arnt Gulbrandsen | 1 Dec 2006 23:18
Favicon

Re: LANGUAGE/COMPARATOR review


I don't have access to the version history here, but from memory, the 
draft has always said that the translated namespace prefixes are just 
that, translated namespace prefixes.

The client can use them to present something on-screen, or it can throw 
them away, that's all. The translations NEVER are used as arguments to 
SELECT.

I too thought about sending all the translations, but didn't see much 
point in it. What client will ever send LANGAGE more than once? 
Defining what happens when ANGAGE is sent more than once is necessary 
for completeness, but not useful, IMNSHO.

Arnt
Permalink | Reply | 1 comment |
headers
Arnt Gulbrandsen | 1 Dec 2006 20:29
Favicon

Re: LANGUAGE/COMPARATOR review


Mark Crispin writes:
> It wouldn't hurt to make LANGUAGE require NAMESPACE.

I did so now. The obvious best choice. Can't imagine why I didn't think 
of that long ago.

Arnt
Permalink | Reply | 0 comments |
headers
Alexey Melnikov | 2 Dec 2006 20:00
Favicon

Re: LANGUAGE/COMPARATOR review


Arnt Gulbrandsen wrote:

> I too thought about sending all the translations, but didn't see much 
> point in it. What client will ever send LANGAGE more than once? 

I can't think of any.
Besides, if the translation prefixes are provided by an OS library, it 
might not be possible to list them all.

> Defining what happens when LANGAGE is sent more than once is necessary 
> for completeness, but not useful, IMNSHO.
Permalink | Reply | 0 comments |
headers
Alexey Melnikov | 6 Dec 2006 18:23
Favicon

Re: [Imap-protocol] ESEARCH extension (RFC 4731)


Mark Crispin wrote:

> How many client implementations of RFC 4731 are there currently?

Mark, I am not going to answer this question, but in the last month I 
know that 3 more servers have added support for this RFC.
Permalink | Reply | 2 comments |
headers
Mark Crispin | 6 Dec 2006 19:23

Re: [Imap-protocol] ESEARCH extension (RFC 4731)

On Wed, 6 Dec 2006, Alexey Melnikov wrote:
> Mark Crispin wrote:
> > How many client implementations of RFC 4731 are there currently?
> Mark, I am not going to answer this question, but in the last month I 
> know that 3 more servers have added support for this RFC.

The reason why I asked is that I am considering adding support for it in 
UW imapd.  It seems easy enough to do in a server, but if it won't be 
widely used then it will become a potential source of inexplicable bugs.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
_______________________________________________
Imap-protocol mailing list
Imap-protocol <at> u.washington.edu
https://mailman1.u.washington.edu/mailman/listinfo/imap-protocol
Permalink | Reply | 0 comments |
headers
Pete Resnick | 8 Dec 2006 21:55

Minutes - comments?


Anyone care to comment on these?

IMAPEXT - Minutes of IETF 67 Meeting (San Diego, CA, US)
Thursday, November 9, 2006
1510-1610
Chair: Pete Resnick
Note taker: Eric Burger
Jabber log: <http://www.ietf.org/meetings/ietf-logs/imapext/2006-11-09.html>

The IMAPEXT group is basically in FINWAIT for its documents. There 
have been discussions on the list about how to finish up and some 
non-working-group issues which we used this time to address.

Discussion:

ANNOTATE Draft. In IETF last call. Some discussion about switching 
back from Experimental to Proposed Standard. No strong arguments for 
doing so, so we're sticking with Experimental and will advanced to 
Proposed in the future.

Internationalization Drafts: The SORT draft needs to be re-reviewed 
in light of the new drafts. Phillip, Tony, Cyrus, Barry, and Ken sign 
up to do said review by 22 November. Discussion was had about whether 
an i;basic comparator document is needed. Arnt will submit his draft.

METADATA (ANNOTATEMORE) Draft. Cyrus asks for more reviews. Ken 
volunteers to get comments by 22 November. Alexey wants an exact 
match operator and multi-value attributes. Exact match discussion 
will be brought to the list. No support (especially from the author)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Internet-Drafts | 21 Dec 2006 00:50
Picon
Favicon

I-D ACTION:draft-ietf-imapext-i18n-08.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)	: A. Gulbrandsen, C. Newman
	Filename	: draft-ietf-imapext-i18n-08.txt
	Pages		: 16
	Date		: 2006-12-20
	
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-08.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
(Continue reading)

Permalink | Reply | 1 comment |
headers
Mark Crispin | 21 Dec 2006 01:18

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


Currently, the document says:
     A server that advertises this extension MUST implement the i;ascii-
     casemap and i;octet comparators, as defined in [RFCxxxx].  A server
     intended to be deployed globally MUST implement the i;basic
     comparator, as defined in [BASIC].

     A server that advertises this extension SHOULD use i;ascii-casemap
     as the default comparator. [...]

Perhaps i;unicode-casemap should also be mentioned, e.g.:

     A server that implements i;unicode-casemap MAY treat i;ascii-casemap
     as equivalent to i;unicode-casemap.  That is, it MAY use
     i;unicode-casemap as its default comparator, and it MAY treat a
     client request for i;ascii-casemap as being for i;unicode-casemap.

The intent here is that all modern servers will do i;unicode-casemap, and 
i;ascii-casemap is only for legacy servers.  I don't really want to 
implement i;ascii-casemap separately, and see no point to doing so.  But 
I'm not going to fight too vigorously for that.  Thus, here's my fallback:

     A server that advertises this extension MUST implement the i;octet
     and i;ascii-casemap comparators, as defined in [RFCxxxx]; and SHOULD
     implement the i;unicode-casemap comparator, as defined in [RFCyyyy].
     A server intended to be deployed globally MUST implement the i;basic
     comparator, as defined in [BASIC].

     A server that advertises this extension SHOULD use i;unicode-casemap
     as the default comparator.  If the server does not support
(Continue reading)

Permalink | Reply | 0 comments |

Gmane