Internet Message Access Protocol Internationalization
RFC 5255
Yes
No Objection
Recuse
Note: This ballot was opened for revision 15 and is now closed.
(Lisa Dusseault; former steering group member) Yes
(Cullen Jennings; former steering group member) No Objection
(Dan Romascanu; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
> 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?
(Jon Peterson; former steering group member) No Objection
(Magnus Westerlund; former steering group member) No Objection
(Ross Callon; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
(Sam Hartman; former steering group member) No Objection
(Tim Polk; former steering group member) (was Discuss) No Objection
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.
(Chris Newman; former steering group member) Recuse