RFC5255 日本語訳
5255 Internet Message Access Protocol Internationalization. C. Newman,A. Gulbrandsen, A. Melnikov. June 2008. (Format: TXT=41403 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group C. Newman
Request for Comments: 5255 Sun Microsystems
Category: Standards Track A. Gulbrandsen
Oryx Mail Systems GmhH
A. Melnikov
Isode Limited
June 2008
コメントを求めるワーキンググループC.ニューマン要求をネットワークでつないでください: 5255年のサン・マイクロシステムズカテゴリ: 2008年6月に制限された標準化過程A.GulbrandsenオリックスメールシステムGmhH A.メリニコフIsode
Internet Message Access Protocol Internationalization
インターネットメッセージアクセス・プロトコル国際化
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
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 that improve international support including language negotiation for international error text, translations for namespace prefixes, and comparator negotiation for search, sort, and thread.
インターネットMessage Accessプロトコル(IMAP)バージョン4rev1はメールボックス名と検索サブストリングに非ASCII文字の基本的なサポートを持っています。 また、それは、非ASCIIがマルチパーパスインターネットメールエクステンション(MIME)によって指定されるようにコード化されたメッセージヘッダーと内容であるとサポートします。 この仕様は国際的な誤りテキストのための交渉、名前空間接頭語のための翻訳、および検索のための比較器交渉が分類する言語を含む国際支援を改良して、縫うように通るIMAP拡張子の収集を定義します。
Newman, et al. Standards Track [Page 1] RFC 5255 IMAP Internationalization June 2008
ニューマン、他 規格はIMAP国際化2008年6月にRFC5255を追跡します[1ページ]。
Table of Contents
目次
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................3
3. LANGUAGE Extension ..............................................3
3.1. LANGUAGE Extension Requirements ............................4
3.2. LANGUAGE Command ...........................................4
3.3. LANGUAGE Response ..........................................6
3.4. TRANSLATION Extension to the NAMESPACE Response ............7
3.5. Formal Syntax ..............................................8
4. I18NLEVEL=1 and I18NLEVEL=2 Extensions ..........................9
4.1. Introduction and Overview ..................................9
4.2. Requirements Common to Both I18NLEVEL=1 and I18NLEVEL=2 ....9
4.3. I18NLEVEL=1 Extension Requirements ........................10
4.4. I18NLEVEL=2 Extension Requirements ........................10
4.5. Compatibility Notes .......................................11
4.6. Comparators and Character Encodings .......................11
4.7. COMPARATOR Command ........................................13
4.8. COMPARATOR Response .......................................14
4.9. BADCOMPARATOR Response Code ...............................14
4.10. Formal Syntax ............................................14
5. Other IMAP Internationalization Issues .........................15
5.1. Unicode Userids and Passwords .............................15
5.2. UTF-8 Mailbox Names .......................................15
5.3. UTF-8 Domains, Addresses, and Mail Headers ................15
6. IANA Considerations ............................................16
7. Security Considerations ........................................16
8. Acknowledgements ...............................................16
9. Relevant Sources of Documents for Internationalized IMAP
Implementations ................................................17
10. Normative References ..........................................17
11. Informative References ........................................18
1. 序論…3 2. このドキュメントで中古のコンベンション…3 3. 言語拡張…3 3.1. 言語拡大要件…4 3.2. 言語コマンド…4 3.3. 言語応答…6 3.4. 名前空間応答への翻訳拡張子…7 3.5. 正式な構文…8 4. I18NLEVEL=1とI18NLEVEL=2拡張子…9 4.1. 序論と概要…9 4.2. I18NLEVEL=1とI18NLEVEL=2の両方に共通の要件…9 4.3. I18NLEVEL=1拡大要件…10 4.4. I18NLEVEL=2拡大要件…10 4.5. 互換性注意…11 4.6. 比較器と文字符号化…11 4.7. 比較器コマンド…13 4.8. 比較器応答…14 4.9. BADCOMPARATOR応答コード…14 4.10. 正式な構文…14 5. 他のIMAP国際化問題…15 5.1. ユニコードユーザIDとパスワード…15 5.2. UTF-8メールボックス名…15 5.3. UTF-8ドメイン、アドレス、およびメールヘッダ…15 6. IANA問題…16 7. セキュリティ問題…16 8. 承認…16 9. 国際化しているIMAP実装のためのドキュメントの関連源…17 10. 標準の参照…17 11. 有益な参照…18
Newman, et al. Standards Track [Page 2] RFC 5255 IMAP Internationalization June 2008
ニューマン、他 規格はIMAP国際化2008年6月にRFC5255を追跡します[2ページ]。
1. Introduction
1. 序論
This specification defines two IMAP4rev1 [RFC3501] extensions to enhance international support. These extensions can be advertised and implemented separately.
この仕様は、国際支援を機能アップするために2IMAP4rev1[RFC3501]拡張子を定義します。 別々にこれらの拡大は、広告を出して、実装することができます。
The LANGUAGE extension allows the client to request a suitable language for protocol error messages and in combination with the NAMESPACE extension [RFC2342] enables namespace translations.
LANGUAGE拡張子で、クライアントは、プロトコルエラーメッセージとNAMESPACE拡張子と組み合わせた適当な言語[RFC2342]が名前空間翻訳を可能にするよう要求できます。
The I18NLEVEL=2 extension allows the client to request a suitable collation that will modify the behavior of the base specification's SEARCH command as well as the SORT and THREAD extensions [SORT]. This leverages the collation registry [RFC4790]. The I18NLEVEL=1 extension updates SEARCH/SORT/THREAD to use i;unicode-casemap comparator, as defined in [UCM]. I18NLEVEL=1 is a simpler version of I18NLEVEL=2 with no ability to select a different collation.
I18NLEVEL=2拡張子で、クライアントはSORTとTHREAD拡張子[SORT]と同様に基礎仕様の検索命令の振舞いを変更する適当な照合を要求できます。 これは、照合が登録[RFC4790]であると利用します。 I18NLEVEL=1拡張子は[UCM]で定義されるように使用i; ユニコード-casemap比較器に検索/SORT/THREADをアップデートします。 I18NLEVEL=1は異なった照合を選択する能力のないI18NLEVEL=2の、より簡単なバージョンです。
2. Conventions Used in This Document
2. 本書では使用されるコンベンション
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
The formal syntax uses the Augmented Backus-Naur Form (ABNF) [RFC5234] notation including the core rules defined in Appendix A.
正式な構文はAppendix Aで定義されたコア規則を含むAugmented BN記法(ABNF)[RFC5234]記法を使用します。
The UTF-8-related productions are defined in [RFC3629].
UTF-8関連の創作は[RFC3629]で定義されます。
In examples, "C:" and "S:" indicate lines sent by the client and server respectively. If a single "C:" or "S:" label applies to multiple lines, then the line breaks between those lines are for editorial clarity only and are not part of the actual protocol exchange.
例で「C:」 そして、「S:」 クライアントとサーバによってそれぞれ送られた系列を示してください。 シングルである、「C:」 または、「S:」 ラベルが複数の系列に適用されて、そして、それらの系列の間のラインブレイクは、編集の明快だけためにあって、実際のプロトコル交換の一部ではありません。
3. LANGUAGE Extension
3. 言語拡張
IMAP allows server responses to include human-readable text that in many cases needs to be presented to the user. But that text is limited to US-ASCII by the IMAP specification [RFC3501] in order to preserve backwards compatibility with deployed IMAP implementations. This section specifies a way for an IMAP client to negotiate which language the server should use when sending human-readable text.
IMAPはサーバ応答に多くの場合、ユーザに提示される必要がある人間読み込み可能なテキストを含ませます。 しかし、IMAP仕様[RFC3501]でそのテキストは、後方に配布しているIMAP実装との互換性を保存するために米国-ASCIIに制限されます。 このセクションはIMAPクライアントが人間読み込み可能なテキストを送るときサーバが使用するべきであるどの言語を交渉するか方法を指定します。
Newman, et al. Standards Track [Page 3] RFC 5255 IMAP Internationalization June 2008
ニューマン、他 規格はIMAP国際化2008年6月にRFC5255を追跡します[3ページ]。
The LANGUAGE extension only provides a mechanism for altering fixed server strings such as response text and NAMESPACE folder names. Assigning localized language aliases to shared mailboxes would be done with a separate mechanism such as the proposed METADATA extension (see [METADATA]).
LANGUAGE拡張子は応答テキストやNAMESPACEフォルダー名などの固定サーバストリングを変更するのにメカニズムを提供するだけです。 提案されたMETADATA拡張子などの別々のメカニズムで共有されたメールボックスへの言語別名であるとローカライズされた割り当てをするでしょう([METADATA]を見てください)。
3.1. LANGUAGE Extension Requirements
3.1. 言語拡大要件
IMAP servers that support this extension MUST list the keyword LANGUAGE in their CAPABILITY response as well as in the greeting CAPABILITY data.
この拡大をサポートするIMAPサーバは彼らのCAPABILITY応答と挨拶CAPABILITYデータにキーワードLANGUAGEを記載しなければなりません。
A server that advertises this extension MUST use the language "i-default" as described in [RFC2277] as its default language until another supported language is negotiated by the client. A server MUST include "i-default" as one of its supported languages. IMAP servers SHOULD NOT advertise the LANGUAGE extension if they discover that they only support "i-default".
この拡大の広告を出すサーバは別のものが言語をサポートするまでデフォルト言語がクライアントによって交渉されるので[RFC2277]で説明されるように言語「i-デフォルト」を使用しなければなりません。 サーバはサポートされた言語の1つとして「i-デフォルト」を含まなければなりません。 「i-デフォルト」をサポートするだけであると発見するなら、IMAPサーバSHOULD NOTはLANGUAGE拡張子の広告を出します。
Clients and servers that support this extension MUST also support the NAMESPACE extension [RFC2342].
また、この拡大をサポートするクライアントとサーバは、NAMESPACEが拡大[RFC2342]であるとサポートしなければなりません。
The LANGUAGE command is valid in all states. Clients SHOULD issue LANGUAGE before authentication, since some servers send valuable user information as part of authentication (e.g., "password is correct, but expired"). If a security layer (such as SASL or TLS) is subsequently negotiated by the client, it MUST re-issue the LANGUAGE command in order to make sure that no previous active attack (if any) on LANGUAGE negotiation has effect on subsequent error messages. (See Section 7 for a more detailed explanation of the attack.)
LANGUAGEコマンドはすべての州で有効です。 クライアントSHOULDは認証の前にLANGUAGEを発行します、いくつかのサーバが認証の一部として貴重なユーザー情報を送るので(例えば、「パスワードは、正しいのですが、満期である」)。 セキュリティ層(SASLかTLSなどの)が次にクライアントによって交渉されるなら、それは、LANGUAGE交渉に対する前のどんな活発な攻撃(もしあれば)もその後のエラーメッセージで手答えがないのを確実にするためにLANGUAGEコマンドを再発行しなければなりません。 (攻撃の、より詳細な説明に関してセクション7を見てください。)
3.2. LANGUAGE Command
3.2. 言語コマンド
Arguments: Optional language range arguments.
議論: 任意の言語範囲議論。
Response: A possible LANGUAGE response (see Section 3.3).
A possible NAMESPACE response (see Section 3.4).
応答: 可能なLANGUAGE応答(セクション3.3を見ます)。 可能なNAMESPACE応答(セクション3.4を見ます)。
Result: OK - Command completed
NO - Could not complete command
BAD - Arguments invalid
結果: OK--コマンドの完成したノー--コマンドBADを完成できませんでした--議論病人
The LANGUAGE command requests that human-readable text emitted by the server be localized to a language matching one of the language range argument as described by Section 2 of [RFC4647].
LANGUAGEはサーバによって放たれた人間読み込み可能なテキストが[RFC4647]のセクション2によって説明されるように言語範囲議論の1つに合っている言語にローカライズされるという要求を命令します。
Newman, et al. Standards Track [Page 4] RFC 5255 IMAP Internationalization June 2008
ニューマン、他 規格はIMAP国際化2008年6月にRFC5255を追跡します[4ページ]。
If the command succeeds, the server will return human-readable responses in the first supported language specified. These responses will be in UTF-8 [RFC3629]. The server MUST send a LANGUAGE response specifying the language used, and the change takes effect immediately after the LANGUAGE response.
コマンドが成功すると、サーバは指定された言語であるとサポートされた1番目で人間読み込み可能な応答を返すでしょう。 これらの応答がUTF-8[RFC3629]にあるでしょう。 LANGUAGE応答はサーバで使用される言語を指定しなければなりません、そして、変化はLANGUAGE応答直後効きます。
If the command fails, the server continues to return human-readable responses in the language it was previously using.
コマンドが失敗するなら、サーバは、それが以前に使用していた言語における人間読み込み可能な応答を返し続けています。
The special "default" language range argument indicates a request to use a language designated as preferred by the server administrator. The preferred language MAY vary based on the currently active user.
特別な「デフォルト」言語範囲議論はサーバアドミニストレータによって好まれるように指定された言語を使用するという要求を示します。 都合のよい言語は現在活発なユーザに基づいて異なるかもしれません。
If a language range does not match a known language tag exactly but does match a language by the rules of [RFC4647], the server MUST send an untagged LANGUAGE response indicating the language selected.
言語範囲がまさに知られている言語タグを合わせませんが、[RFC4647]の規則で言語に合っているなら、サーバで、untagged LANGUAGE応答は、言語が選択したのを示さなければなりません。
If there aren't any arguments, the server SHOULD send an untagged LANGUAGE response listing the languages it supports. If the server is unable to enumerate the list of languages it supports it MAY return a tagged NO response to the enumeration request. If, after receiving a LANGUAGE request, the server discovers that it doesn't support any language other than i-default, it MUST return a tagged NO response to the enumeration request.
議論が少しのなければ、サーバSHOULDはuntagged LANGUAGE応答にそれがサポートする言語を記載させます。 サーバがそれがサポートする言語のリストを数え上げることができないなら、それは列挙要求へのタグ付けをされたいいえ応答を返すかもしれません。 LANGUAGE要求を受け取った後にサーバが、それがi-デフォルト以外の少しの言語もサポートしないと発見するなら、それは列挙要求へのタグ付けをされたいいえ応答を返さなければなりません。
< The server defaults to using English i-default responses until
the user explicitly changes the language. >
サーバがユーザまで明らかにイギリスのi-デフォルト応答を使用することでデフォルトとする<は言語を変えます。 >。
C: A001 LOGIN KAREN PASSWORD
S: A001 OK LOGIN completed
C: A001ログインカレンパスワードS: 完成したA001 OK LOGIN
< Client requested MUL language, which no server supports. >
<クライアントはMUL言語を要求しました。(どんなサーバもそれをサポートしません)。 >。
C: A002 LANGUAGE MUL
S: A002 NO Unsupported language MUL
C: A002言語MUL S: A002 NO Unsupported言語MUL
< A LANGUAGE command with no arguments is a request to enumerate
the list of languages the server supports. >
LANGUAGEが議論なしで命令する<はサーバがサポートする言語のリストを数え上げるという要求です。 >。
C: A003 LANGUAGE
S: * LANGUAGE (EN DE IT i-default)
S: A003 OK Supported languages have been enumerated
C: A003言語S: * LANGUAGE(EN DE IT i-デフォルト)S: A003 OK Supported言語を列挙してあります。
C: B001 LANGUAGE
S: B001 NO Server is unable to enumerate supported languages
C: B001言語S: B001 NO Serverはサポートされた言語を列挙できません。
Newman, et al. Standards Track [Page 5] RFC 5255 IMAP Internationalization June 2008
ニューマン、他 規格はIMAP国際化2008年6月にRFC5255を追跡します[5ページ]。
< Once the client changes the language, all responses will be in
that language starting after the LANGUAGE response. Note that
this includes the NAMESPACE response. Because RFCs are in US-
ASCII, this document uses an ASCII transcription rather than
UTF-8 text, e.g., "ue" in the word "ausgefuehrt" >
<、クライアントがいったん言語を変えると、LANGUAGE応答の後に始まるその言語にはすべての応答があるでしょう。 これがNAMESPACE応答を含んでいることに注意してください。 米国ASCIIにはRFCsがあるので、このドキュメントは>という単語"ausgefuehrt"でUTF-8テキスト、例えば、"ue"よりむしろASCII転写を使用します。
C: C001 LANGUAGE DE
S: * LANGUAGE (DE)
S: * NAMESPACE (("" "/")) (("Other Users/" "/" "TRANSLATION"
("Andere Ben&APw-tzer/"))) (("Public Folders/" "/"
"TRANSLATION" ("Gemeinsame Postf&AM8-cher/")))
S: C001 OK Sprachwechsel durch LANGUAGE-Befehl ausgefuehrt
C: C001LANGUAGE DE S: * 言語(DE)S: * 「名前空間、(「「「/」)、(「他のユーザ/」、」 /、」 「翻訳」(「AndereベンとAPw-tzer/」)、(「公共のフォルダー/」、」 /、」 「翻訳」(「Gemeinsame Postf&AM8-cher/」)S: C001 OK Sprachwechsel durch LANGUAGE-Befehl ausgefuehrt
< If a server does not support the requested primary language,
responses will continue to be returned in the current language
the server is using. >
サーバが、要求がプライマリ言語、応答であるとサポートしないと、<は、サーバが使用している現在の言語で返され続けるでしょう。 >。
C: D001 LANGUAGE FR
S: D001 NO Diese Sprache ist nicht unterstuetzt
C: D002 LANGUAGE DE-IT
S: * LANGUAGE (DE-IT)
S: * NAMESPACE (("" "/"))(("Other Users/" "/" "TRANSLATION"
("Andere Ben&APw-tzer/"))) (("Public Folders/" "/"
"TRANSLATION" ("Gemeinsame Postf&AM8-cher/")))
S: D002 OK Sprachwechsel durch LANGUAGE-Befehl ausgefuehrt
C: D003 LANGUAGE "default"
S: * LANGUAGE (DE)
S: D003 OK Sprachwechsel durch LANGUAGE-Befehl ausgefuehrt
C: D001言語フランS: D001 NO Diese Sprache ist nicht unterstuetzt C: D002言語反-IT S: * 言語(反-IT)S: * 「名前空間、(「「「/」)、(「他のユーザ/」、」 /、」 「翻訳」(「AndereベンとAPw-tzer/」)、(「公共のフォルダー/」、」 /、」 「翻訳」(「Gemeinsame Postf&AM8-cher/」)S: D002 OK Sprachwechsel durch LANGUAGE-Befehl ausgefuehrt C: D003言語「デフォルト」S: * 言語(DE)S: D003 OK Sprachwechsel durch LANGUAGE-Befehl ausgefuehrt
< Server does not speak French, but does speak English. User
speaks Canadian French and Canadian English. >
<サーバは、フランス語をしゃべりませんが、英語を話します。 ユーザはカナダ系のフランスとカナダ系の英語を話します。 >。
C: E001 LANGUAGE FR-CA EN-CA
S: * LANGUAGE (EN)
S: E001 OK Now speaking English
C: 001Eの言語FRカリフォルニアENカリフォルニアS: * 言語(アン)S: 現在英語を話す001EのOK
3.3. LANGUAGE Response
3.3. 言語応答
Contents: A list of one or more language tags.
コンテンツ: 1個以上の言語タグのリスト。
The LANGUAGE response occurs as a result of a LANGUAGE command. 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.
LANGUAGE応答はLANGUAGEコマンドの結果、起こります。 リストが単一の言語タグを入れてあているLANGUAGE応答は、サーバが現在その言語を使用しているのを示します。 リストが複数の言語タグを入れてあているLANGUAGE応答は、サーバが利用可能な言語のリストをクライアントに伝えているのを示します、そして、アクティブな言語の変更は全く行われていません。
Newman, et al. Standards Track [Page 6] RFC 5255 IMAP Internationalization June 2008
ニューマン、他 規格はIMAP国際化2008年6月にRFC5255を追跡します[6ページ]。
3.4. TRANSLATION Extension to the NAMESPACE Response
3.4. 名前空間応答への翻訳拡張子
If localized representations of the namespace prefixes are available in the selected language, the server SHOULD include these in the TRANSLATION extension to the NAMESPACE response.
名前空間接頭語のローカライズしている表現が選択された言語で利用可能であるなら、サーバSHOULDはTRANSLATION拡張子でNAMESPACE応答にこれらを含めます。
The TRANSLATION extension to the NAMESPACE response returns a single string, containing the modified UTF-7 [RFC3501] encoded translation of the namespace prefix. It is the responsibility of the client to convert between the namespace prefix and the translation of the namespace prefix when presenting mailbox names to the user.
NAMESPACE応答へのTRANSLATION拡張子は一連を返します、名前空間接頭語の変更されたUTF-7[RFC3501]のコード化された翻訳を含んでいて。 それはメールボックス名をユーザに提示するときクライアントが名前空間接頭語と名前空間接頭語に関する翻訳の間で変換する責任です。
In this example, a server supports the IMAP4 NAMESPACE command. It uses no prefix to the user's Personal Namespace, a prefix of "Other Users" to its Other Users' Namespace, and a prefix of "Public Folders" to its only Shared Namespace. Since a client will often display these prefixes to the user, the server includes a translation of them that can be presented to the user.
この例では、サーバは、IMAP4 NAMESPACEがコマンドであるとサポートします。 それはユーザのパーソナルNamespaceへの接頭語がなく、「他のユーザ」のOther UsersのNamespaceへの接頭語、および「公共のフォルダー」の唯一のShared Namespaceへの接頭語を使用します。 クライアントがしばしばこれらの接頭語をユーザに表示するので、サーバはユーザに提示できるそれらに関する翻訳を含んでいます。
C: A001 LANGUAGE DE-IT
S: * NAMESPACE (("" "/")) (("Other Users/" "/" "TRANSLATION"
("Andere Ben&APw-tzer/"))) (("Public Folders/" "/"
"TRANSLATION" ("Gemeinsame Postf&AM8-cher/")))
S: A001 OK LANGUAGE-Befehl ausgefuehrt
C: A001言語反-IT S: * 「名前空間、(「「「/」)、(「他のユーザ/」、」 /、」 「翻訳」(「AndereベンとAPw-tzer/」)、(「公共のフォルダー/」、」 /、」 「翻訳」(「Gemeinsame Postf&AM8-cher/」)S: A001 OK LANGUAGE-Befehl ausgefuehrt
Newman, et al. Standards Track [Page 7] RFC 5255 IMAP Internationalization June 2008
ニューマン、他 規格はIMAP国際化2008年6月にRFC5255を追跡します[7ページ]。
3.5. Formal Syntax
3.5. 正式な構文
The following syntax specification inherits ABNF [RFC5234] rules from IMAP4rev1 [RFC3501], IMAP4 Namespace [RFC2342], Tags for the Identifying Languages [RFC4646], UTF-8 [RFC3629], and Collected Extensions to IMAP4 ABNF [RFC4466].
以下の構文仕様はIMAP4rev1[RFC3501]、IMAP4 Namespace[RFC2342]、Identifying LanguagesのためのTags[RFC4646]、UTF-8[RFC3629]、およびCollected ExtensionsからIMAP4 ABNF[RFC4466]までABNF[RFC5234]規則を引き継ぎます。
command-any =/ language-cmd
; LANGUAGE command is valid in all states
いくらかコマンド言語=/cmd。 LANGUAGEコマンドはすべての州で有効です。
language-cmd = "LANGUAGE" *(SP lang-range-quoted)
言語-cmdは「言語」*と等しいです。(引用されたSP lang範囲)
response-payload =/ language-data
応答ペイロード=/言語データ
language-data = "LANGUAGE" SP "(" lang-tag-quoted *(SP
lang-tag-quoted) ")"
言語データは「(「引用されたラングタグ*(引用されたSP langタグ)」)」という「言語」SPと等しいです。
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]
名前空間、-、移-、「(「結ぶ」)」という=SP DQUOTE「翻訳」DQUOTE SP。 ストリングはModified UTF-7でコード化されます。 ; これは受入れられた構文の部分集合です。 中のNamespace応答拡張子規則[RFC4466]
lang-range-quoted = astring
; Once any literal wrapper or quoting is removed, this
; follows the language-range rule in [RFC4647]
引用されたlang範囲はastringと等しいです。 いったんどんな文字通りのラッパーや引用も取り除くと、これです。 言語範囲規則に中に従います。[RFC4647]
lang-tag-quoted = astring
; Once any literal wrapper or quoting is removed, this follows
; the Language-Tag rule in [RFC4646]
引用されたlangタグはastringと等しいです。 これは、かつてのどんな文字通りのラッパーや引用も取り除かれるのに続きます。 中のLanguage-タグ規則[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].
resp-テキストがUTF8テキスト炭の*と等しい、[「[「respテキストコード」]」SP](UTF8テキスト炭の/、「[「)、サーバが言語に変わった後、; i-デフォルト、このresp-テキスト規則はresp-テキストを置き換えます; [RFC3501]から統治してください、」
UTF8-TEXT-CHAR = %x20-5A / %x5C-7E / UTF8-2 / UTF8-3 / UTF8-4
; UTF-8 excluding 7-bit control characters and "["
UTF8テキスト炭=%x20-5A/%x5C-7E/UTF8-2/UTF8-3/UTF8-4。 そして、7ビットのコントロールキャラクタを除いたUTF-8、「[」
Newman, et al. Standards Track [Page 8] RFC 5255 IMAP Internationalization June 2008
ニューマン、他 規格はIMAP国際化2008年6月にRFC5255を追跡します[8ページ]。
4. I18NLEVEL=1 and I18NLEVEL=2 Extensions
4. I18NLEVEL=1とI18NLEVEL=2拡張子
4.1. Introduction and Overview
4.1. 序論と概要
IMAP4rev1 [RFC3501] includes the SEARCH command that 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.
IMAP4rev1[RFC3501]は人間読み込み可能なテキストを含む評価基準を合わせながらメッセージの場所を見つけるのに使用できる検索命令を含んでいます。 IMAPへのSORT拡張子[SORT]で、クライアントは、人間の読み込み可能なテキストを含む評価基準に基づくメッセージの順番を決定するようにサーバに頼むことができます。 これらのメカニズムは非イギリス人が捜すサポートとソート機能への能力を必要とします。
Section 4 defines two IMAP extensions for internationalizing IMAP SEARCH, SORT, and THREAD [SORT] using the comparator framework [RFC4790].
セクション4は、比較器フレームワーク[RFC4790]を使用することでIMAP SEARCH、SORT、およびTHREAD[SORT]を国際的にするために2つのIMAP拡張子を定義します。
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.
I18NLEVEL=1拡張子は[UCM]で定義されるように使用i; ユニコード-casemap比較器に検索/SORT/THREADをアップデートします。 その他の詳細に関してセクション4.2と4.3を見てください。
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 to 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.
I18NLEVEL=2拡張子はI18NLEVEL=1拡張子のスーパーセットです。 それはアクティブな比較器(以下での定義を見る)を決定して、COMPARATORコマンドを使用することで比較器の使用を交渉する能力をI18NLEVEL=1拡張子に追加します。 また、それはアクティブな比較器とことによると他の利用可能な比較器を示すCOMPARATOR応答を加えます。 その他の詳細に関してセクション4.2と4.4を見てください。
4.2. Requirements Common to Both I18NLEVEL=1 and I18NLEVEL=2
4.2. I18NLEVEL=1とI18NLEVEL=2の両方に共通の要件
The term "default comparator" refers to the comparator that is used by SEARCH and SORT absent any negotiation using the COMPARATOR command (see Section 4.7). 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.
「デフォルト比較器」という用語は検索で使用される比較器について言及します、そして、SORTはCOMPARATORコマンドを使用することでどんな交渉も欠席します(セクション4.7を見てください)。 「アクティブな比較器」という用語はセッション、例えば、検索とSORTによって使用される比較器について言及します。 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.
アクティブな比較器は以下の検索キーに適用されます: 「BCC」、「ボディー」、「CC」、“FROM"、「対象」、「テキスト」、“TO"、および「ヘッダー。」 また、サーバが「種類」拡大の広告を出すなら、アクティブな比較器は以下の分類用キーに適用されます: 「CC」、“FROM"、「対象」、および“TO"。 サーバがTHREAD=ORDEREDSUBJECTの広告を出すなら、アクティブな比較器はORDEREDSUBJECT縫うように通るアルゴリズムに適用されます。 サーバがTHREAD=REFERENCESの広告を出すなら、アクティブな比較器はアルゴリズムに糸を通すREFERENCESによって行われた対象の分野比較に適用されます。 将来の拡張子は、それらの検索キーにアクティブな比較器を適用するのを選ぶかもしれません。
Newman, et al. Standards Track [Page 9] RFC 5255 IMAP Internationalization June 2008
ニューマン、他 規格はIMAP国際化2008年6月にRFC5255を追跡します[9ページ]。
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.
ベース対象を抜粋するのに必要なSORTとTHREAD、前処理のために、Subjectヘッダーからのテキストは比較器のアプリケーションの前に起こります。
A server that advertises I18NLEVEL=1 or I18NLEVEL=2 extension MUST implement the i;unicode-casemap comparator, as defined in [UCM].
I18NLEVEL=1かI18NLEVEL=2拡張子の広告を出すサーバは[UCM]で定義されるようにi; ユニコード-casemap比較器を実装しなければなりません。
A server that advertises I18NLEVEL=1 or I18NLEVEL=2 extension MUST support UTF-8 as a SEARCH charset.
I18NLEVEL=1かI18NLEVEL=2拡張子の広告を出すサーバは検索charsetとしてUTF-8をサポートしなければなりません。
4.3. I18NLEVEL=1 Extension Requirements
4.3. I18NLEVEL=1拡大要件
An IMAP server that satisfies all requirements specified in Sections 4.2 and 4.6 (and that 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.
そして、すべての要件を満たすIMAPサーバがセクション4.2と4.6で指定した、(それは、<n>いかなる他のI18NLEVELも=拡張子のサポートするか、または広告を出しません、n>1)がIMAPがいったん認証された状態に入るとCAPABILITYデータにキーワードI18NLEVEL=1を記載しなければならなくて、他の州にそのキーワードをリストアップするかもしれないところで。
4.4. I18NLEVEL=2 Extension Requirements
4.4. I18NLEVEL=2拡大要件
An IMAP server that satisfies all requirements specified in Sections 4.2, 4.4, and 4.6-4.10 (and that 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.
そして、すべての要件を満たすIMAPサーバがセクション4.2、4.4、および4.6-4.10に指定した、(それは、<n>いかなる他のI18NLEVELも=拡張子のサポートするか、または広告を出しません、n>2)がIMAPがいったん認証された状態に入るとCAPABILITYデータにキーワードI18NLEVEL=2を記載しなければならなくて、他の州にそのキーワードをリストアップするかもしれないところで。
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.
この拡大の広告を出すサーバは[UCM]で定義されるようにi; ユニコード-casemap比較器を実装しなければなりません。 それは[RFC4790]によって確立されたIANA登録から他の比較器を実装するかもしれません。 また、このドキュメントのセクション4.5を見てください。
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.
この拡大SHOULD使用iの広告を出すサーバ; デフォルト比較器としてのユニコード-casemap。 (そのiに注意してください; I18NLEVEL=1であるときに、ユニコード-casemapはI18NLEVEL=2であることの必ずデフォルトではなく、デフォルト比較器です。) デフォルト比較器の選択は、サーバアドミニストレータが調整可能であるかもしれなく、現在のユーザにとって、敏感であるかもしれません。 IMAP接続がいったん認証された状態に入ると、デフォルト比較器はその接続の残りに静的に残らなければなりません。
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 the ordering operation (which in turn uses the equality operation), IMAP servers that advertise the SORT extension can only implement collations that offer all three operations (see [RFC4790], Sections 4.2.2-4.2.4).
検索がサブストリング操作を使用するのでIMAPサーバがサブストリング操作を提供する校合を実装することができるだけであることに注意してください([RFC4790]、セクション4.2.2を見てください)。 SORTが注文操作(順番に平等操作を使用する)を使用するので、SORT拡張子の広告を出すIMAPサーバはすべての3つの操作を提供する校合を実装することができるだけです([RFC4790]、セクション4.2.2-4.2.4を見てください)。
Newman, et al. Standards Track [Page 10] RFC 5255 IMAP Internationalization June 2008
ニューマン、他 規格はIMAP国際化2008年6月にRFC5255を追跡します[10ページ]。
If the active collation does not provide the operations needed by an IMAP command, the server MUST respond with a tagged BAD.
活発な照合がIMAPコマンドで必要である操作を提供しないなら、サーバはタグ付けをされたBADと共に反応しなければなりません。
4.5. Compatibility Notes
4.5. 互換性注意
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 comparator (see [RFC4790]).
この仕様の公表の前に配布されたいくつかのサーバ実装は、I18NLEVEL=1(セクション4.3を見る)に従いますが、それの広告を出しません。 他のレガシーサーバはiを使用します; ASCII-casemap比較器([RFC4790]を見ます)。
There is no good way for a client to know which comparator 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.
クライアントが、レガシーサーバがどの比較器を使用するかを知る早道が全くありません。 クライアントが最悪を仮定しなければならないなら、サーバはそれを実装しますが、それは結局、iを得る高価な地方の操作; ユニコード-casemap比較をするかもしれません。
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.
I18NLEVEL=1の広告を出すためにI18NLEVEL=1に従うレガシーサーバ実装をアップデートするべきです。 結局、I18NLEVEL=2拡張子に従うためにすべてのサーバ実装をアップデートするべきです。
4.6. Comparators and Character Encodings
4.6. 比較器と文字符号化
RFC 3501, Section 6.4.4, says:
RFC3501(セクション6.4.4)は言います:
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, and THREAD) does so according to the following procedure:
以下の手順によると、照合操作(例えば、検索や、SORTや、THREADなどのコマンドの一部としての)を実行するIMAPサーバはそうします:
(a) MIME encoding (for example, see [RFC2047] for headers and
[RFC2045] for body parts) MUST be removed in the texts being
collated.
(a) 照合されるテキストでMIMEコード化(例えば、ヘッダーのための[RFC2047]と[RFC2045]を身体の部分に見る)を取り除かなければなりません。
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 manner.
取り外しをコード化するMIMEがメッセージのために失敗するなら(例えば、メッセージの身体の部分には、サポートされないContent転送コード化、キャラクタがContent転送コード化で許容しなかった用途などがあります)、このメッセージの照合は、この仕様で未定義であり、実装依存する方法で扱われます。
(b) The decoded text from (a) MUST be converted to the charset
expected by the active comparator.
(b) アクティブな比較器によって予想されたcharsetに(a)からの解読されたテキストを変換しなければなりません。
Newman, et al. Standards Track [Page 11] RFC 5255 IMAP Internationalization June 2008
ニューマン、他 規格はIMAP国際化2008年6月にRFC5255を追跡します[11ページ]。
(c) For the substring operation:
サブストリング操作のための(c):
If step (b) failed (e.g., the text is in an unknown charset,
contains a sequence that 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]).
ステップ(b)が失敗したなら(例えば、テキストは、未知のcharsetにあって、系列をそれがそのcharsetなどで有効でない含んでいます)、(a)(すなわち、charset変換試みの前の)からのオリジナルの解読されたテキストはiを使用することで照合されます; 八重奏比較器([RFC4790]を見ます)。
If step (b) was successful, the converted text from (b) is
collated according to the active comparator.
ステップ(b)がうまくいったなら、アクティブな比較器に従って、(b)からの変換されたテキストは照合されます。
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.
ステップ(b)で首尾よく変換されたすべてのストリングがステップ(b)に失敗したすべてのストリングから分離されます。 各グループにおけるストリングは独自に照合されます。 そして、ステップ(b)で首尾よく変換されたすべてのストリングがアクティブな比較器によって有効にされます。 合法化を通過するストリングが、アクティブな比較器を使用することで照合されます。 ステップ(b)に失敗するか、または活発な照合の正当性操作に失敗するすべてのストリングがiを使用することで照合されます(ステップ(a)を適用した後に); 八重奏比較器([RFC4790]を見ます)。 結果として起こる分類されたリストは、すべての照合された「失敗した」ストリングをアクティブな比較器を使用することで照合されたすべてのストリングの後に追加することによって、作り出されます。
Example: The following example demonstrates ordering of 4
different strings using the i;unicode-casemap [UCM] comparator.
Strings are represented using hexadecimal notation used by ABNF
[RFC5234].
例: 以下の例は4個の異なったストリングを注文しながら、iを使用することで示されます; ユニコード-casemap[UCM]比較器。 ストリングは、ABNF[RFC5234]によって使用された16進法を使用することで表されます。
(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)
ラベル..ラベル..ラベル(charset=KOI8-Rで、ラベルされます)
Step (b) will convert string (4) to the following sequence of
octets (in UTF-8):
ステップ(b)は八重奏(UTF-8の)の以下の系列にストリング(4)を変換するでしょう:
%xD0 %x90 %xD0 %xBB %xD0 %xB5 %xD0 %xBA %xD1 %x81 %xD0
%xB5 %xD0 %xB9
%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.
そして、charset=UTF-8に許容されなかった八重奏を含むとき、ストリング(1)と(3)を拒絶するでしょう。
Newman, et al. Standards Track [Page 12] RFC 5255 IMAP Internationalization June 2008
ニューマン、他 規格はIMAP国際化2008年6月にRFC5255を追跡します[12ページ]。
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).
; i、ユニコード-casemapの照合、(4)が以前照合するストリングを使用するその後に、(2)を結んでください。 iを使用します; オリジナルのストリング、(3)がストリング(1)の前で照合するストリングにおける八重奏の照合。 それで、最終的な注文は以下の通りです: (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.
アクティブな比較器のサブストリング操作(例えば、IMAP SEARCH)が検索命令で指定されたテキストかメッセージ・テキストのどちらかのために、「未定義」の結果(.3セクション4.2[RFC4790]を見る)を返すなら、操作はステップ(a)の結果でiを使用することで繰り返されます; 八重奏比較器。
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).
注文操作(例えば、IMAP SORTとTHREAD)SHOULDは以下を一緒に照合します: ストリングは未知の、または、無効の文字符号化、認識されていないcharsetsのストリングを使用して、無効の入力をコード化しました(活発な照合で定義されるように)。
4.7. COMPARATOR Command
4.7. 比較器コマンド
Arguments: Optional comparator order arguments.
議論: 任意の比較器オーダー議論。
Response: A possible COMPARATOR response (see Section 4.8).
応答: 可能なCOMPARATOR応答(セクション4.8を見ます)。
Result: OK - Command completed
NO - No matching comparator found
BAD - Arguments invalid
結果: OK--コマンドはいいえ--合っているBADが見つけられた比較器がありません--議論病人を完成しました。
The COMPARATOR command is valid in authenticated and selected states.
COMPARATORコマンドは認証されて選択された州で有効です。
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.
COMPARATORコマンドは、アクティブな比較器を決定するか、または変えるのに使用されます。 議論なしで発行されると、それは現在アクティブな比較器を示すCOMPARATOR応答をもたらします。
When issued with one or more comparator arguments, 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.
1つ以上の比較器議論で発行されると、それは指示されるとしてアクティブな比較器を変えます。 (1個以上のインストールされた比較器が議論で合わせられているなら、最初の議論は得られます。) 1以上が指定されたパターンに合っているなら、COMPARATOR応答はすべての合っている比較器を記載します。
The argument "default" refers to the server's default comparator. Otherwise, each argument is a collation specification as defined in the Internet Application Protocol Comparator Registry [RFC4790].
議論「デフォルト」はサーバのデフォルト比較器を示します。 さもなければ、各議論はインターネットApplicationプロトコル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. >
クライアントの<はできれば、チェコの比較器を動かすか、またはそれがチェク語に適していると考えるジェネリックの国際的な比較器を要求します。 サーバは比較器であるとサポートされた1番目を選びます。 >。
Newman, et al. Standards Track [Page 13] RFC 5255 IMAP Internationalization June 2008
ニューマン、他 規格はIMAP国際化2008年6月にRFC5255を追跡します[13ページ]。
C: A001 COMPARATOR "cz;*" i;basic
S: * COMPARATOR i;basic
S: A001 OK Will use i;basic for collation
C: A001 COMPARATOR、「cz;、*、」 i; 基本的なS: * COMPARATOR i; 基礎S: 照合に、基本的なA001 OKウィル使用i
4.8. COMPARATOR Response
4.8. 比較器応答
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.
COMPARATOR応答はCOMPARATORコマンドの結果、起こります。 比較器応答における最初の議論はアクティブな比較器の名前です。 2番目の議論は、議論のいずれもCOMPARATORコマンドに合わせた比較器のリストであり、1個以上のマッチが見つけられる場合にだけ、存在しています。
4.9. BADCOMPARATOR Response Code
4.9. BADCOMPARATOR応答コード
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).
サーバがそれを知っているとき、IMAPコマンド(戻っているノー)に失敗するサーバの結果、この応答コードSHOULDを返して、指定された比較器のいずれも要求された比較器に合っていません。
4.10. Formal Syntax
4.10. 正式な構文
The following syntax specification inherits ABNF [RFC5234] rules from IMAP4rev1 [RFC3501] and the Internet Application Protocol Comparator Registry [RFC4790].
以下の構文仕様はIMAP4rev1[RFC3501]とインターネットApplicationプロトコルComparator Registry[RFC4790]からABNF[RFC5234]規則を引き継ぎます。
command-auth =/ comparator-cmd
コマンド-auth比較器=/cmd
resp-text-code =/ "BADCOMPARATOR"
respテキストコード=/"BADCOMPARATOR"
comparator-cmd = "COMPARATOR" *(SP comp-order-quoted)
比較器-cmdは「比較器」*と等しいです。(引用されたSPコンピュータオーダー)
response-payload =/ comparator-data
応答ペイロード比較器=/データ
comparator-data = "COMPARATOR" SP comp-sel-quoted [SP "("
comp-id-quoted *(SP comp-id-quoted) ")"]
比較器データはselが引用した「比較器」SPコンピュータと等しいです。[「(「引用されたコンピュータイド*(引用されたSPコンピュータイド)」)」というSP]
comp-id-quoted = astring
; Once any literal wrapper or quoting is removed, this
; follows the collation-id rule from [RFC4790]
引用されたコンピュータイドはastringと等しいです。 いったんどんな文字通りのラッパーや引用も取り除くと、これです。 照合イドが統治する尾行[RFC4790]
comp-order-quoted = astring
; Once any literal wrapper or quoting is removed, this
; follows the collation-order rule from [RFC4790]
オーダーが引用したコンピュータはastringと等しいです。 いったんどんな文字通りのラッパーや引用も取り除くと、これです。 照合命令が統治する尾行[RFC4790]
Newman, et al. Standards Track [Page 14] RFC 5255 IMAP Internationalization June 2008
ニューマン、他 規格はIMAP国際化2008年6月にRFC5255を追跡します[14ページ]。
comp-sel-quoted = astring
; Once any literal wrapper or quoting is removed, this
; follows the collation-selected rule from [RFC4790]
selが引用したコンピュータはastringと等しいです。 いったんどんな文字通りのラッパーや引用も取り除くと、これです。 照合によって選択にされるのが統治する尾行[RFC4790]
5. Other IMAP Internationalization Issues
5. 他のIMAP国際化問題
The following sections provide an overview of various other IMAP internationalization issues. These issues are not resolved by this specification, but could be resolved by other standards work, such as that being done by the EAI working group (see [IMAP-EAI]).
以下のセクションは他の様々なIMAP国際化問題の概要を提供します。 EAIワーキンググループによって行われながらそれなどの他の標準化作業で決議できるだろう以外に、これらの問題はこの仕様で解決されていません([IMAP-EAI]を見てください)。
5.1. Unicode Userids and Passwords
5.1. ユニコードユーザIDとパスワード
IMAP4rev1 currently restricts the userid and password fields of the LOGIN command to US-ASCII. The "userid" and "password" fields of the IMAP LOGIN command are restricted to US-ASCII only until a future standards track RFC states otherwise. Servers are encouraged to validate both fields to make sure they conform to the formal syntax of UTF-8 and to reject the LOGIN command if that syntax is violated. Servers MAY reject the LOGIN command if either the "userid" or "password" field contains an octet with the highest bit set.
IMAP4rev1は現在、LOGINコマンドのユーザIDとパスワード欄を米国-ASCIIに制限します。 IMAP LOGINコマンドの「ユーザID」と「パスワード」分野は別の方法で米国の未来までのしかASCIIでない標準化過程RFC州に制限されます。 その構文が違反されるなら、サーバがそれらがUTF-8の正式な構文に従うのを確実にして、LOGINコマンドを拒絶するために両方の分野を有効にするよう奨励されます。 「ユーザID」か「パスワード」分野が最も高い噛み付いているセットによる八重奏を含んでいるなら、サーバはLOGINコマンドを拒絶するかもしれません。
When AUTHENTICATE is used, some servers may support userids and passwords in Unicode [RFC3490] since SASL (see [RFC4422]) allows that. However, such userids cannot be used as part of email addresses.
AUTHENTICATEが使用されているとき、SASL([RFC4422]を見る)がそれを許容するので、いくつかのサーバがユニコード[RFC3490]によるユーザIDとパスワードをサポートするかもしれません。 しかしながら、Eメールアドレスの一部としてそのようなユーザIDを使用できません。
5.2. UTF-8 Mailbox Names
5.2. UTF-8メールボックス名
The modified UTF-7 mailbox naming convention described in Section 5.1.3 of RFC 3501 is best viewed as an transition from the status quo in 1996 when modified UTF-7 was first specified. At that time, there was widespread unofficial use of local character sets such as ISO- 8859-1 and Shift-JIS for non-ASCII mailbox names, with resultant non-interoperability.
.3セクション5.1RFC3501で説明された変更されたUTF-7メールボックス命名規則は変更されたUTF-7が最初に指定された1996年に変遷として現状から最も上手に見なされます。 その時、ISO8859-1やShift-JISなどのローカルキャラクターセットの非ASCIIメールボックス名の広範囲の非公式の使用がありました、結果の非相互運用性で。
The requirements in Section 5.1 of RFC 3501 are very important if we're ever going to be able to deploy UTF-8 mailbox names. Servers are encouraged to enforce them.
私たちがメールボックス名をUTF-8に配布することができるなら、RFC3501のセクション5.1における要件は非常に重要です。 サーバがそれらを実施するよう奨励されます。
5.3. UTF-8 Domains, Addresses, and Mail Headers
5.3. UTF-8ドメイン、アドレス、およびメールヘッダ
There is now an IETF standard for "Internationalizing Domain Names in Applications (IDNA)" [RFC3490]. While IMAP clients are free to support this standard, an argument can be made that it would be helpful to simple clients if the IMAP server could perform this conversion (the same argument would apply to MIME header encoding
現在、「アプリケーション(IDNA)におけるドメイン名を国際的にします」のIETF規格[RFC3490]があります。 IMAPクライアントが自由にこの規格をサポートすることができる間、純真なクライアントにとって、IMAPサーバがこの変換を実行できれば助かるだろうという主張をすることができる、(同じ議論はMIMEヘッダーコード化に適用されるでしょう。
Newman, et al. Standards Track [Page 15] RFC 5255 IMAP Internationalization June 2008
ニューマン、他 規格はIMAP国際化2008年6月にRFC5255を追跡します[15ページ]。
[RFC2047]). However, it would be unwise to move forward with such work until the work in progress to define the format of international email addresses is complete.
[RFC2047。) しかしながら、そのような国際的なEメールアドレスの書式を定義するためには進行中の仕事が完全になるまでの仕事を進めるのは賢明でないでしょう。
6. IANA Considerations
6. IANA問題
IANA added LANGUAGE, I18NLEVEL=1, and I18NLEVEL=2 to the IMAP4 Capabilities Registry.
IANAはLANGUAGE、I18NLEVEL=1、およびI18NLEVEL=2をIMAP4 Capabilities Registryに加えました。
7. Security Considerations
7. セキュリティ問題
The LANGUAGE extension makes a new command available in "Not Authenticated" state in IMAP. Some IMAP implementations run with root privilege when the server is in "Not Authenticated" state and do not revoke that privilege until after authentication is complete. Such implementations are particularly vulnerable to buffer overflow security errors at this stage and need to implement parsing of this command with extra care.
LANGUAGE拡張子で、新しいコマンドはIMAPで「認証されなかった」状態で利用可能になります。 いくつかのIMAP実装は、サーバが「認証されなかった」状態にあるとき、根の特権と共に稼働していて、認証が完全になった後までその特権を取り消しません。 そのような実装は、現在のところ、オーバーフローセキュリティ誤りをバッファリングして、付加的な注意でこのコマンドの構文解析を実装するのが必要であるように特に被害を受け易いです。
A LANGUAGE command issued prior to activation of a security layer is subject to an active attack that suppresses or modifies the negotiation, and thus makes STARTTLS or authentication error messages more difficult to interpret. This is not a new attack as the error messages themselves are subject to active attack. Clients MUST re- issue the LANGUAGE command once a security layer is active, in order to prevent this attack from impacting subsequent protocol operations.
セキュリティ層の起動の前に発行されたLANGUAGEコマンドは交渉を抑圧するか、または変更して、その結果STARTTLSか認証を解釈するのが、より難しいエラーメッセージにする活発な攻撃を受けることがあります。 エラーメッセージ自体は活発な攻撃を受けることがあるとき、これが新しい攻撃ではありません。 セキュリティ層がいったん活性になると、クライアントはLANGUAGEコマンドを再発行しなければなりません、この攻撃がその後のプロトコル操作に影響を与えるのを防ぐために。
LANGUAGE, I18NLEVEL=1, and I18NLEVEL=2 extensions use the UTF-8 charset; thus, the security considerations for UTF-8 [RFC3629] are relevant. However, neither uses UTF-8 for identifiers, so the most serious concerns do not apply.
LANGUAGE、I18NLEVEL=1、およびI18NLEVEL=2拡張子はUTF-8 charsetを使用します。 したがって、UTF-8[RFC3629]のためのセキュリティ問題は関連しています。 しかしながら、どちらも識別子にUTF-8を使用しないので、最も真剣な関心は申し込まれません。
8. Acknowledgements
8. 承認
The LANGUAGE extension is based on a previous document by Mike Gahrns, a substantial portion of the text in that section was written by him. Many people have participated in discussions about an IMAP Language extension in the various fora of the IETF and Internet working groups, so any list of contributors is bound to be incomplete. However, the authors would like to thank Andrew McCown for early work on the original proposal, John Myers for suggestions regarding the namespace issue, along with Jutta Degener, Mark Crispin, Mark Pustilnik, Larry Osterman, Cyrus Daboo, Martin Duerst, Timo Sirainen, Ben Campbell, and Magnus Nystrom for their many suggestions that have been incorporated into this document.
そのセクションのテキストのかなりの部分がLANGUAGE拡張子がマイクGahrnsによる前のドキュメントに基づいていると彼によって書かれました。 多くの人々がIETFとインターネットワーキンググループの様々なフォーラムでIMAP Language拡張子についての議論に参加したので、貢献者のどんなリストも不完全であることが制限されています。 しかしながら、作者は起案に対する早めの仕事のためのアンドリュー・マッカウン、名前空間問題に関する提案のためのジョン・マイアーズに感謝したがっています、このドキュメントに組み入れられた彼らの多くの提案のためのユッタDegener、マーク・クリスピン、マークPustilnik、ラリー・オスターマン、サイラスDaboo、マーチンDuerst、ティモSirainen、ベン・キャンベル、およびマグヌス・ニストロムと共に。
Initial discussion of the I18NLEVEL=2 extension involved input from Mark Crispin and other participants of the IMAP Extensions WG.
拡大がかかわったI18NLEVEL=2の初期の議論はマークからIMAP Extensions WGのクリスピンと他の関係者を入力しました。
Newman, et al. Standards Track [Page 16] RFC 5255 IMAP Internationalization June 2008
ニューマン、他 規格はIMAP国際化2008年6月にRFC5255を追跡します[16ページ]。
9. Relevant Sources of Documents for Internationalized IMAP
Implementations
9. 国際化しているIMAP実装のためのドキュメントの関連源
This is a non-normative list of sources to consider when implementing i18n-aware IMAP software.
これはi18n意識しているIMAPがソフトウェアであると実装するとき考えるソースの非標準のリストです。
o The LANGUAGE and I18NLEVEL=2 extensions to IMAP (this
specification).
o IMAP(この仕様)へのLANGUAGEとI18NLEVEL=2拡張子。
o The 8-bit rules for mailbox naming in Section 5.1 of RFC 3501.
o 8ビットはメールボックス命名のためにRFC3501のセクション5.1で統治されます。
o The Mailbox International Naming Convention in Section 5.1.3 of
RFC 3501.
o .3セクション5.1RFC3501におけるメールボックスの国際命名規則。
o MIME [RFC2045] for message bodies.
o メッセージ本体のためのMIME[RFC2045]。
o MIME header encoding [RFC2047] for message headers.
o メッセージヘッダーのためのMIMEヘッダーコード化[RFC2047]。
o The IETF EAI working group.
o IETF EAIワーキンググループ。
o MIME Parameter Value and Encoded Word Extensions [RFC2231] for
filenames. Quality IMAP server implementations will
automatically combine multipart parameters when generating the
BODYSTRUCTURE. There is also some deployed non-standard use of
MIME header encoding inside double quotes for filenames.
o ファイル名のためのMIME Parameter ValueとEncoded Word Extensions[RFC2231]。 BODYSTRUCTUREを生成するとき、上質のIMAPサーバ実装は自動的に複合パラメタを結合するでしょう。 二重引用符におけるMIMEヘッダーコード化のファイル名の標準的でない使用であると配布された何かもあります。
o IDNA [RFC3490] and punycode [RFC3492] for domain names
(currently only relevant to IMAP clients).
o ドメイン名(現在単にIMAPクライアントに関連している)のためのIDNA[RFC3490]とpunycode[RFC3492]。
o The UTF-8 charset [RFC3629].
o UTF-8 charset[RFC3629]。
o The IETF policy on Character Sets and Languages [RFC2277].
o 文字コードとLanguages[RFC2277]に関するIETF方針。
10. Normative References
10. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
Languages", BCP 18, RFC 2277, January 1998.
[RFC2277] Alvestrand、H.、「文字コードと言語に関するIETF方針」、BCP18、RFC2277、1998年1月。
[RFC2342] Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342, May
1998.
[RFC2342] Gahrns、M.、およびC.ニューマン(「IMAP4名前空間」、RFC2342)は1998がそうするかもしれません。
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, March 2003.
[RFC3501] クリスピン、M.、「バージョン4rev1"、RFC3501、2003年インターネットメッセージアクセス・プロトコル--3月。」
Newman, et al. Standards Track [Page 17] RFC 5255 IMAP Internationalization June 2008
ニューマン、他 規格はIMAP国際化2008年6月にRFC5255を追跡します[17ページ]。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau、F.、「UTF-8、ISO10646の変換形式」STD63、RFC3629、11月2003日
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", STD 68, RFC 5234, January
2008.
エド[RFC5234]クロッカー、D.、P.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、STD68、RFC5234、2008年1月。
[RFC4422] Melnikov, A., Ed., and K. Zeilenga, Ed., "Simple
Authentication and Security Layer (SASL)", RFC 4422, June
2006.
[RFC4422]メリニコフ、A.、エド、K.Zeilenga、エド、「簡易認証とセキュリティは(SASL)を層にする」RFC4422、6月2006日
[RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4
ABNF", RFC 4466, April 2006.
[RFC4466] メリニコフとA.とC.Daboo、「IMAP4 ABNFへの集まっている拡大」、RFC4466、2006年4月。
[RFC4646] Phillips, A. and M. Davis, "Tags for Identifying
Languages", BCP 47, RFC 4646, September 2006.
[RFC4646]フィリップス、A.とM.デイヴィス、「言語を特定するためのタグ」BCP47、2006年9月のRFC4646。
[RFC4647] Phillips, A. and M. Davis, "Matching of Language Tags",
BCP 47, RFC 4647, September 2006.
[RFC4647]フィリップス、A.とM.デイヴィス、「言語タグのマッチング」BCP47、2006年9月のRFC4647。
[RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet
Application Protocol Collation Registry", RFC 4790, March
2007.
[RFC4790] ニューマンとC.とDuerst、M.とA.Gulbrandsen、「インターネットアプリケーション・プロトコル照合登録」、RFC4790、2007年3月。
[SORT] Crispin, M. and K. Murchison, "Internet Message Access
Protocol - SORT and THREAD Extensions", RFC 5256, June
2008.
[種類]クリスピン、M.、およびK.マーチソン、「インターネットメッセージアクセス・プロトコル--拡大を分類して、糸を通す」RFC5256、2008年6月。
[UCM] Crispin, M., "i;unicode-casemap - Simple Unicode Collation
Algorithm", RFC 5051, October 2007.
[UCM] クリスピン、M.、「i; ユニコード-casemap--簡単なユニコード照合アルゴリズム」、RFC5051、2007年10月。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
解放された[RFC2045]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
Part Three: Message Header Extensions for Non-ASCII Text",
RFC 2047, November 1996.
[RFC2047]ムーア、K.、「パートThreeをまねてください(マルチパーパスインターネットメールエクステンション)」 「非ASCIIテキストのためのメッセージヘッダー拡張子」、RFC2047、1996年11月。
11. Informative References
11. 有益な参照
[RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded
Word Extensions: Character Sets, Languages, and
Continuations", RFC 2231, November 1997.
解放された[RFC2231]、N.、およびK.ムーア、「パラメタ値とコード化されたWord拡大をまねてください」 「文字コード、言語、および続刊」、RFC2231、11月1997日
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)",
RFC 3490, March 2003.
[RFC3490] Faltstrom、P.、ホフマン、P.、およびA.コステロ、「アプリケーション(IDNA)におけるドメイン名を国際的にします」、RFC3490、2003年3月。
Newman, et al. Standards Track [Page 18] RFC 5255 IMAP Internationalization June 2008
ニューマン、他 規格はIMAP国際化2008年6月にRFC5255を追跡します[18ページ]。
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode
for Internationalized Domain Names in Applications
(IDNA)", RFC 3492, March 2003.
[RFC3492]コステロ、A.、「Punycode:」 「Applications(IDNA)のInternationalized Domain Namesのためにユニコードをコード化するBootstring」、RFC3492、2003年3月。
[METADATA] Daboo, C., "IMAP METADATA Extension", Work in Progress,
April 2008.
C.、「IMAPメタデータ拡張子」という[メタデータ]Dabooは進歩、2008年4月に働いています。
[IMAP-EAI] Resnick, P., and C. Newman, "IMAP Support for UTF-8", Work
in Progress, November 2007.
[IMAP-EAI] レズニック、P.、およびC.ニューマン、「UTF-8インチ、処理中の作業、2007年11月のIMAPサポート。」
Authors' Addresses
作者のアドレス
Chris Newman Sun Microsystems 3401 Centrelake Dr., Suite 410 Ontario, CA 91761 US
クリスニューマンサン・マイクロシステムズ3401Centrelakeスイート410オンタリオ、カリフォルニア91761博士(米国)
EMail: chris.newman@sun.com
メール: chris.newman@sun.com
Arnt Gulbrandsen Oryx Mail Systems GmbH Schweppermannstr. 8 D-81671 Muenchen Germany
Arnt GulbrandsenオリックスメールシステムGmbH Schweppermannstr。 8 D-81671 Muenchenドイツ
EMail: arnt@oryx.com Fax: +49 89 4502 9758
メール: arnt@oryx.com Fax: +49 89 4502 9758
Alexey Melnikov Isode Limited 5 Castle Business Village, 36 Station Road, Hampton, Middlesex, TW12 2BX, UK
AlexeyメリニコフIsode株式会社5城のビジネス村、36駅の道路、ハンプトン、ミドルセックスTW12 2BX、イギリス
EMail: Alexey.Melnikov@isode.com
メール: Alexey.Melnikov@isode.com
Newman, et al. Standards Track [Page 19] RFC 5255 IMAP Internationalization June 2008
ニューマン、他 規格はIMAP国際化2008年6月にRFC5255を追跡します[19ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(2008)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。
Newman, et al. Standards Track [Page 20]
ニューマン、他 標準化過程[20ページ]
一覧
スポンサーリンク
