i18n.txt
来自「广泛使用的邮件服务器!同时」· 文本 代码 · 共 1,141 行 · 第 1/3 页
TXT
1,141 行
command-any =/ language-cmd
; LANGUAGE command is valid in all states
language-cmd = "LANGUAGE" *(SP lang-range-quoted)
response-payload =/ language-data
language-data = "LANGUAGE" SP "(" lang-tag-quoted *(SP
lang-tag-quoted) ")"
namespace-trans = SP DQUOTE "TRANSLATION" DQUOTE SP "(" string ")"
; the string is encoded in Modified UTF-7.
; this is a subset of the syntax permitted by
; the Namespace-Response-Extension rule in [RFC4466]
lang-range-quoted = astring
; Once any literal wrapper or quoting is removed, this
; follows the language-range rule in [RFC4647]
lang-tag-quoted = astring
; Once any literal wrapper or quoting is removed, this follows
; the Language-Tag rule in [RFC4646]
resp-text = ["[" resp-text-code "]" SP ] UTF8-TEXT-CHAR
*(UTF8-TEXT-CHAR / "[")
; After the server is changed to a language other than
; i-default, this resp-text rule replaces the resp-text
; rule from [RFC3501].
UTF8-TEXT-CHAR = %x20-5A / %x5C-7E / UTF8-2 / UTF8-3 / UTF8-4
; UTF-8 excluding 7-bit control characters and "["
Newman & Co Expires August 2008 FF[Page 7]
Internet-draft February 2008
4. I18NLEVEL=1 and I18NLEVEL=2 Extensions
4.1 Introduction and Overview
IMAP4rev1 [RFC3501] includes the SEARCH command which can be used to
locate messages matching criteria including human-readable text.
The SORT extension [SORT] to IMAP allows the client to ask the
server to determine the order of messages based on criteria
including human-readable text. These mechanisms require the ability
to support non-English search and sort functions.
Section 4 defines two IMAP extensions for internationalizing IMAP
SEARCH, SORT and THREAD [SORT] using the comparator framework
[RFC4790].
The I18NLEVEL=1 extension updates SEARCH/SORT/THREAD to use
i;unicode-casemap comparator, as defined in [UCM]. See Sections 4.2
and 4.3 for more details.
The I18NLEVEL=2 extension is a superset of the I18NLEVEL=1
extension. It adds to I18NLEVEL=1 extension the ability to determine
the active comparator (see definition below) and negotiate use of
comparators using the COMPARATOR command. It also adds the
COMPARATOR response that indicates the active comparator and
possibly other available comparators. See Sections 4.2 and 4.4 for
more details.
4.2 Requirements common to both I18NLEVEL=1 and I18NLEVEL=2
The term "default comparator" refers to the comparator which is used
by SEARCH and SORT absent any negotiation using the COMPARATOR (see
Section 4.7) command. The term "active comparator" refers to the
comparator which will be used within a session e.g. by SEARCH and
SORT. The COMPARATOR command is used to change the active
comparator.
The active comparator applies to the following SEARCH keys: "BCC",
"BODY", "CC", "FROM", "SUBJECT", "TEXT", "TO" and "HEADER". If the
server also advertises the "SORT" extension, then the active
comparator applies to the following SORT keys: "CC", "FROM",
"SUBJECT" and "TO". If the server advertises THREAD=ORDEREDSUBJECT,
then the active comparator applies to the ORDEREDSUBJECT threading
algorithm. If the server advertises THREAD=REFERENCES, then the
active comparator applies to the subject field comparisons done by
REFERENCES threading algorithm. Future extensions may choose to
apply the active comparator to their SEARCH keys.
Newman & Co Expires August 2008 FF[Page 8]
Internet-draft February 2008
For SORT and THREAD, the pre-processing necessary to extract the
base subject text from a Subject header occurs prior to the
application of a comparator.
A server that advertises I18NLEVEL=1 or I18NLEVEL=2 extension MUST
implement the i;unicode-casemap comparator, as defined in [UCM].
A server that advertises I18NLEVEL=1 or I18NLEVEL=2 extension MUST
support UTF-8 as a SEARCH charset.
4.3 I18NLEVEL=1 Extension Requirements
An IMAP server that satisfies all requirements specified in sections
4.2 and 4.6 (and doesn't support/advertise any other I18NLEVEL=<n>
extension, where n > 1) MUST list the keyword I18NLEVEL=1 in its
CAPABILITY data once IMAP enters the authenticated state, and MAY
list that keyword in other states.
4.4 I18NLEVEL=2 Extension Requirements
IMAP server that satisfies all requirements specified in sections
4.2, 4.4, 4.6-4.10 (and doesn't support/advertise any other
I18NLEVEL=<n> extension, where n > 2) MUST list the keyword
I18NLEVEL=2 in its CAPABILITY data once IMAP enters the
authenticated state, and MAY list that keyword in other states.
A server that advertises this extension MUST implement the
i;unicode-casemap comparator, as defined in [UCM]. It MAY implement
other comparators from the IANA registry established by [RFC4790].
See also section 4.5 of this document.
A server that advertises this extension SHOULD use i;unicode-casemap
as the default comparator. (Note that i;unicode-casemap is the
default comparator for I18NLEVEL=1, but not necessarily the default
for I18NLEVEL=2.) The selection of the default comparator MAY be
adjustable by the server administrator, and MAY be sensitive to the
current user. Once the IMAP connection enters authenticated state,
the default comparator MUST remain static for the remainder of that
connection.
Note that since SEARCH uses the substring operation, IMAP servers
can only implement collations that offer the substring operation
(see [RFC4790 section 4.2.2). Since SORT uses ordering operation
(and by implication equality), IMAP servers which advertise the SORT
extension can only implement collations that offer all three
Newman & Co Expires August 2008 FF[Page 9]
Internet-draft February 2008
operations (see [RFC4790] sections 4.2.2-4).
If the active collation does not provide the operations needed by an
IMAP command, the server MUST respond with a tagged BAD.
4.5 Compatibility Notes
Several server implementations deployed prior to the publication of
this specification comply with I18NLEVEL=1 (see section 4.3), but do
not advertise that. Other legacy servers use the i;ascii-casemap
(see [RFC4790]) comparator.
There is no good way for a client to know which comparator that a
legacy server uses. If the client has to assume the worst, it may
end up doing expensive local operations to obtain i;unicode-casemap
comparisons even though the server implements it.
Legacy server implementations which comply with I18NLEVEL=1 should
be updated to advertise I18NLEVEL=1. All server implementations
should eventually be updated to comply with the I18NLEVEL=2
extension.
4.6 Comparators and Character Encodings
RFC 3501, section 6.4.4 says:
In all search keys that use strings, a message matches
the key if the string is a substring of the field. The
matching is case-insensitive.
When performing the SEARCH operation, the active comparator is
applied instead of the case-insensitive matching specified above.
An IMAP server which performs collation operations (e.g., as part of
commands such as SEARCH, SORT, THREAD) does so according to the
following procedure:
(a) MIME encoding (for example see [RFC2047] for headers and
[RFC2045] for body parts) MUST be removed in the texts being
collated.
If MIME encoding removal fails for a message (e.g., a body part
of the message has an unsupported Content-Transfer-Encoding,
uses characters not allowed by the Content-Transfer-Encoding,
etc.), the collation of this message is undefined by this
specification, and is handled in an implementation-dependent
Newman & Co Expires August 2008 FF[Page 10]
Internet-draft February 2008
manner.
(b) The decoded text from (a) MUST be converted to the charset
expected by the active comparator.
(c) For the substring operation:
If step (b) failed (e.g., the text is in an unknown charset,
contains a sequence which is not valid according in that
charset, etc.), the original decoded text from (a) (i.e.,
before the charset conversion attempt) is collated using the
i;octet comparator (see [RFC4790]).
If step (b) was successful, the converted text from (b) is
collated according to the active comparator.
For the ordering operation:
All strings that were successfully converted by step (b) are
separated from all strings that failed step (b). Strings in
each group are collated independently. All strings successfully
converted by step (b) are then validated by the active
comparator. Strings that pass validation are collated using the
active comparator. All strings that either fail step (b) or fail
the active collation's validity operation are collated (after
applying step (a)) using the i;octet comparator (see [RFC4790]).
The resulting sorted list is produced by appending all collated
"failed" strings after all strings collated using the active
comparator.
Example: The following example demonstrates ordering of 4
different strings using i;unicode-casemap [UCM] comparator.
Strings are represented using hexadecimal notation used by
ABNF [RFC4234].
(1) %xD0 %xC0 %xD0 %xBD %xD0 %xB4 %xD1 %x80 %xD0 %xB5
%xD0 %xB9 (labeled with charset=UTF-8)
(2) %xD1 %x81 %xD0 %x95 %xD0 %xA0 %xD0 %x93 %xD0 %x95
%xD0 %x99 (labeled with charset=UTF-8)
(3) %xD0 %x92 %xD0 %xB0 %xD1 %x81 %xD0 %xB8 %xD0 %xBB
%xD0 %xB8 %xFF %xB9 (labeled with charset=UTF-8)
(4) %xE1 %xCC %xC5 %xCB %xD3 %xC5 %xCA (labeled with
charset=KOI8-R)
Step (b) will convert string # 4 to the following
sequence of octets (in UTF-8):
Newman & Co Expires August 2008 FF[Page 11]
Internet-draft February 2008
%xD0 %x90 %xD0 %xBB %xD0 %xB5 %xD0 %xBA %xD1 %x81 %xD0
%xB5 %xD0 %xB9
and will reject strings (1) and (3), as they contain
octets not allowed in charset=UTF-8.
After that, using the i;unicode-casemap collation,
string (4) will collate before string (2). Using the
i;octet collation on the original strings, string (3)
will collate before string (1). So the final ordering
is as follows: (4) (2) (3) (1).
If the substring operation (e.g., IMAP SEARCH) of the active
comparator returns the "undefined" result (see section 4.2.3 of
[RFC4790]) for either the text specified in the SEARCH command or
the message text, then the operation is repeated on the result of
step (a) using the i;octet comparator.
The ordering operation (e.g., IMAP SORT and THREAD) SHOULD collate
the following together: strings encoded using unknown or invalid
character encodings, strings in unrecognized charsets, and invalid
input (as defined by the active collation).
4.7 COMPARATOR Command
Arguments: Optional comparator order arguments.
Response: A possible COMPARATOR response (see Section 4.8).
Result: OK - Command completed
NO - No matching comparator found
BAD - arguments invalid
The COMPARATOR command is valid in authenticated and selected
states.
The COMPARATOR command is used to determine or change the active
comparator. When issued with no arguments, it results in a
COMPARATOR response indicating the currently active comparator.
When issued with one or more comparator argument, it changes the
active comparator as directed. (If more than one installed
comparator is matched by an argument, the first argument wins.) The
COMPARATOR response lists all matching comparators if more than one
matches the specified patterns.
The argument "default" refers to the server's default comparator.
Newman & Co Expires August 2008 FF[Page 12]
Internet-draft February 2008
Otherwise each argument is an collation specification as defined in
the Internet Application Protocol Comparator Registry [RFC4790].
< The client requests activating a Czech comparator if possible,
or else a generic international comparator which it considers
suitable for Czech. The server picks the first supported
comparator. >
C: A001 COMPARATOR "cz;*" i;basic
S: * COMPARATOR i;basic
S: A001 OK Will use i;basic for collation
4.8 COMPARATOR Response
Contents: The active comparator.
An optional list of available matching comparators
The COMPARATOR response occurs as a result of a COMPARATOR command.
The first argument in the comparator response is the name of the
active comparator. The second argument is a list of comparators
which matched any of the arguments to the COMPARATOR command and is
present only if more than one match is found.
4.9 BADCOMPARATOR response code
This response code SHOULD be returned as a result of server failing
an IMAP command (returning NO), when the server knows that none of
the specified comparators match the requested comparator(s).
4.10 Formal Syntax
The following syntax specification inherits ABNF [RFC4234] rules
from IMAP4rev1 [RFC3501], and Internet Application Protocol
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?