Internet Message Access Protocol Internationalization
RFC 5255

Note: This ballot was opened for revision 15 and is now closed.

(Lisa Dusseault) Yes

(Jari Arkko) No Objection

Comment (2008-03-05)
No email
send info
> Clients are urged to
> issue LANGUAGE before authentication, since some servers send
> valuable user information as part of authentication (e.g. "password
> is correct, but expired").

Clients SHOULD issue?

(Ross Callon) No Objection

(Sam Hartman) No Objection

(Russ Housley) No Objection

(Cullen Jennings) No Objection

(Jon Peterson) No Objection

(Tim Polk) (was Discuss) No Objection

Comment (2008-03-06)
No email
send info
The LANGUAGE response is ambiguous for the corner case where the LANGUAGE extension
is supported but only the i-default langauge is supported.  Specifically, Section 3.3 states:

    A LANGUAGE response with a list containing a single language tag
    indicates that the server is now using that language.  A LANGUAGE
    response with a list containing multiple language tags indicates the
    server is communicating a list of available languages to the client,
    and no change in the active language has been made.

However, for the corner case the server's list of langauges is just i-default.

Adding a requirements that "IMAP servers that support this extension MUST
support at least one langauge in addition to i-default" would correct this by
avoiding the corner case.   (Just an observation, I'm not set on any particular
solution.)

Is I18NLEVEL=1 defined in another specification?  The introductory text (Section2, final
paragraph) implies that only I18NLEVEL=2 is specified here, but section 4 includes
definitions for I18NLEVEL= 1 and 2.

(Dan Romascanu) No Objection

Magnus Westerlund No Objection

(Chris Newman) Recuse