[要約] RFC 7997は、RFC文書で非ASCII文字を使用するためのガイドラインです。その目的は、国際化と多言語サポートを向上させ、RFC文書の可読性と相互運用性を高めることです。
Internet Architecture Board (IAB) H. Flanagan, Ed.
Request for Comments: 7997 RFC Editor
Updates: 7322 December 2016
Category: Informational
ISSN: 2070-1721
The Use of Non-ASCII Characters in RFCs
RFCでの非ASCII文字の使用
Abstract
概要
In order to support the internationalization of protocols and a more diverse Internet community, the RFC Series must evolve to allow for the use of non-ASCII characters in RFCs. While English remains the required language of the Series, the encoding of future RFCs will be in UTF-8, allowing for a broader range of characters than typically used in the English language. This document describes the RFC Editor requirements and gives guidance regarding the use of non-ASCII characters in RFCs.
プロトコルの国際化とより多様なインターネットコミュニティをサポートするために、RFCシリーズは、RFCで非ASCII文字を使用できるように進化する必要があります。シリーズの必須言語は英語のままですが、将来のRFCのエンコーディングはUTF-8になるため、通常英語で使用される文字よりも幅広い文字を使用できます。このドキュメントでは、RFCエディタの要件について説明し、RFCでの非ASCII文字の使用に関するガイダンスを示します。
This document updates RFC 7322. Please view this document in PDF form to see the full text.
このドキュメントはRFC 7322を更新します。全文を表示するには、このドキュメントをPDF形式で表示してください。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Architecture Board (IAB) and represents information that the IAB has deemed valuable to provide for permanent record. It represents the consensus of the Internet Architecture Board (IAB). Documents approved for publication by the IAB are not a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、インターネットアーキテクチャボード（IAB）の製品であり、IABが永続的な記録を提供するために価値があると見なした情報を表しています。これは、インターネットアーキテクチャボード（IAB）のコンセンサスを表しています。 IABによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7997.
このドキュメントの現在の状態、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7997で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Basic Requirements . . . . . . . . . . . . . . . . . . . . . 3
3. Rules for the Use of Non-ASCII Characters . . . . . . . . . . 4
3.1. General Usage throughout a Document . . . . . . . . . . . 4
3.2. Person Names . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Company Names . . . . . . . . . . . . . . . . . . . . . . 6
3.4. Body of the Document . . . . . . . . . . . . . . . . . . 7
3.5. Tables . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.6. Code Components . . . . . . . . . . . . . . . . . . . . . 11
3.7. Bibliographic Text . . . . . . . . . . . . . . . . . . . 11
3.8. Keywords and Citation Tags . . . . . . . . . . . . . . . 11
3.9. Address Information . . . . . . . . . . . . . . . . . . . 12
4. Normalization Forms . . . . . . . . . . . . . . . . . . . . . 12
5. XML Markup . . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Internationalization Considerations . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. Informative References . . . . . . . . . . . . . . . . . . . 13
IAB Members at the Time of Approval . . . . . . . . . . . . . . . 14
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
Please review the PDF version of this draft.
このドラフトのPDFバージョンを確認してください。
For much of the history of the RFC Series, the character encoding used for RFCs has been ASCII [RFC20]. This was a sensible choice at the time: the language of the Series has always been English, a language that primarily uses ASCII-encoded characters (ignoring for a moment words borrowed from more richly decorated alphabets); and, ASCII is the "lowest common denominator" for character encoding, making cross-platform viewing trivial.
RFCシリーズの歴史の大部分で、RFCに使用される文字エンコーディングはASCII [RFC20]でした。これは当時は賢明な選択でした。シリーズの言語は常に英語であり、主にASCIIエンコード文字を使用する言語です（しばらくの間、より豊かに装飾されたアルファベットから借用された単語は無視されます）。また、ASCIIは文字エンコーディングの「最も一般的な最小要素」であり、クロスプラットフォームの表示を簡単にします。
There are limits to ASCII, however, that hinder its continued use as the exclusive character encoding for the Series. The increasing need for easily readable, internationalized content suggests it is time to allow non-ASCII characters in RFCs where necessary. To support this move away from ASCII, RFCs will switch to supporting UTF-8 as the default character encoding and will allow support for a broad range of Unicode characters [UnicodeCurrent]. Note that the RFC Editor may reject any code point that does not render adequately across all formats or in enough rendering engines using the v3 tooling.
ただし、ASCIIには制限があり、シリーズの専用文字エンコーディングとしての継続的な使用が妨げられます。読みやすく国際化されたコンテンツへのニーズが高まっていることから、必要に応じてRFCで非ASCII文字を使用できるようにする必要があります。このASCIIからの移行をサポートするために、RFCはデフォルトの文字エンコードとしてUTF-8のサポートに切り替え、幅広いUnicode文字のサポートを許可します[UnicodeCurrent]。 RFC Editorは、すべてのフォーマットにわたって、またはv3ツールを使用した十分なレンダリングエンジンで適切にレンダリングされないコードポイントを拒否する場合があることに注意してください。
Given the continuing goal of maximum readability across platforms, the use of non-ASCII characters should be limited to only where necessary within the text. This document describes the rules under which non-ASCII characters may be used in an RFC. These rules will be applied as the necessary changes are made to submission checking and editorial tools.
プラットフォーム全体で可読性を最大にするという継続的な目標を考えると、ASCII以外の文字の使用は、テキスト内で必要な場合のみに制限する必要があります。このドキュメントでは、ASCII以外の文字をRFCで使用する場合の規則について説明します。これらのルールは、提出チェックおよび編集ツールに必要な変更が加えられたときに適用されます。
This document updates the RFC Style Guide [RFC7322].
このドキュメントは、RFCスタイルガイド[RFC7322]を更新します。
The details included in this document are expected to change based on experience gained in implementing the new publication toolsets. Revised documents will be published capturing those changes as the toolsets are completed. Other implementers must not expect those changes to remain backwards compatible with the details included in this document.
このドキュメントに含まれる詳細は、新しいパブリケーションツールセットの実装で得られた経験に基づいて変更されることが予想されます。ツールセットが完成すると、変更されたドキュメントが公開され、変更が記録されます。他の実装者は、これらの変更がこのドキュメントに含まれる詳細との後方互換性を維持することを期待してはなりません。
Two fundamental requirements inform the guidance and examples provided in this document. They are:
2つの基本的な要件は、このドキュメントで提供されるガイダンスと例を示しています。彼らです：
o Searches against RFC indexes and database tables need to return expected results and support appropriate Unicode string matching behaviors;
o RFCインデックスとデータベーステーブルに対する検索は、期待される結果を返し、適切なUnicode文字列照合動作をサポートする必要があります。
o RFCs must be able to be displayed correctly across a wide range of readers and browsers. People whose systems do not have the fonts needed to display a particular RFC need to be able to read the various publication formats and the XML correctly in order to understand and implement the information described in the document.
o RFCは、さまざまなリーダーやブラウザーで正しく表示できる必要があります。特定のRFCを表示するために必要なフォントをシステムに持たない人々は、ドキュメントに記載されている情報を理解して実装するために、さまざまな公開形式とXMLを正しく読み取ることができる必要があります。
This section describes the guidelines for the use of non-ASCII characters in an RFC. If the RFC Editor identifies areas where the use of non-ASCII characters negatively impacts the readability of the text, they will request alternate text.
このセクションでは、RFCでの非ASCII文字の使用に関するガイドラインについて説明します。 RFCエディタが非ASCII文字の使用がテキストの読みやすさに悪影響を与える領域を特定した場合、彼らは代替テキストを要求します。
The RFC Editor may, in cases of entire words represented in non-ASCII characters, ask for a set of reviewers to verify the meaning, spelling, characters, and grammar of the text.
RFCエディターは、ASCII以外の文字で表される単語全体の場合、テキストの意味、スペル、文字、および文法を確認するために一連の校閲者を要求する場合があります。
Where the use of non-ASCII characters is purely part of an example and not otherwise required for correct protocol operation, escaping the non-ASCII character is not required. Note, however, that as the language of the RFC Series is English, the use of non-ASCII characters is based on the spelling of words commonly used in the English language following the guidance in the Merriam-Webster dictionary [MerrWeb].
非ASCII文字の使用が純粋に例の一部であり、それ以外の場合は正しいプロトコル操作に必要ではない場合、非ASCII文字のエスケープは必要ありません。ただし、RFCシリーズの言語は英語であるため、非ASCII文字の使用はMerriam-Webster辞書[MerrWeb]のガイダンスに従って、英語で一般的に使用される単語のスペルに基づいていることに注意してください。
The RFC Editor will use the primary spelling listed in that dictionary by default.
RFCエディターは、デフォルトでその辞書にリストされている主要なスペルを使用します。
Example of non-ASCII characters that do not require escaping (example from Section 3.1.1.12 of RFC 4475 [RFC4475], with a hex dump replaced by the actual character glyphs):
エスケープを必要としない非ASCII文字の例（RFC 4475 [RFC4475]のセクション3.1.1.12の例。16進ダンプが実際の文字グリフに置き換えられています）：
This particular response contains unreserved and non-ASCII UTF-8 characters. This response is well formed. A parser must accept this message.
この特定の応答には、予約されていない非ASCII UTF-8文字が含まれています。この応答は整形式です。パーサーはこのメッセージを受け入れる必要があります。
Message Details : unreason
メッセージの詳細：unreason
SIP/2.0 200 = 2**3 * 5**2 (See PDF for non-ASCII character string)
Via: SIP/2.0/UDP 192.0.2.198;branch=z9hG4bK1324923
Call-ID: unreason.1234ksdfak3j2erwedfsASdf
CSeq: 35 INVITE
From: sip:user@example.com;tag=11141343
To: sip:user@example.edu;tag=2229 Content-Length: 154
Content-Type: application/sdp
Person names may appear in several places within an RFC (e.g., the header, Acknowledgements, and References). When a script outside the Unicode Latin blocks [UNICODE-CHART] is used for an individual name, an author-provided, ASCII-only identifier will appear immediately after the non-Latin characters, surrounded by parentheses. This will improve general readability of the text.
個人名は、RFC内のいくつかの場所に表示されることがあります（たとえば、ヘッダー、謝辞、参照）。 Unicodeラテン語ブロックの外側のスクリプト[UNICODE-CHART]が個々の名前に使用されると、著者が提供するASCIIのみの識別子が、ラテン語以外の文字の直後に括弧で囲まれて表示されます。これにより、テキストの読みやすさが向上します。
Example header:
ヘッダーの例：
OLD:
古い：
Internet Engineering Task Force (IETF) J. Tong Request for Comments: 7380 C. Bi, Ed. Category: Standards Track China Telecom ISSN: 2070-1721 R. Even Q. Wu, Ed. R. Huang Huawei November 2014
Internet Engineering Task Force（IETF）J. Tong Request for Comments：7380 C. Bi、Ed。カテゴリ：規格の追跡China Telecom ISSN：2070-1721 R. Even Q. Wu、Ed。 R. Huang Huawei 2014年11月
PROPOSED/NEW:
提案/新規：
Internet Engineering Task Force (IETF) J. Tong Request for Comments: 7380 C. Bi, Ed. Category: Standards Track China Telecom ISSN: 2070-1721 (See PDF for non-ASCII character string) (R. Even) (See PDF for non-ASCII character string) (Q. Wu), Ed. R. Huang Huawei November 2014
Internet Engineering Task Force（IETF）J. Tong Request for Comments：7380 C. Bi、Ed。カテゴリ：規格追跡China Telecom ISSN：2070-1721（非ASCII文字列についてはPDFを参照）（R.偶数）（非ASCII文字列についてはPDFを参照）（Q. Wu）、Ed。 R. Huang Huawei 2014年11月
Example Acknowledgements section:
謝辞セクションの例：
OLD:
古い：
The following people contributed significant text to early versions of this draft: Patrik Faltstrom, William Chan, and Fred Baker.
次の人々は、このドラフトの初期バージョンに重要なテキストを寄稿しました：Patrik Faltstrom、William Chan、およびFred Baker。
PROPOSED/NEW:
提案/新規：
The following people contributed significant text to early versions of this draft: Patrik (See PDF for non-ASCII character string) (Faltstrom), (See PDF for non-ASCII character string) (William Chan), and Fred Baker.
以下の人々は、このドラフトの初期バージョンに重要なテキストを寄稿しました：Patrik（非ASCII文字列についてはPDFを参照）（Faltstrom）（非ASCII文字列についてはPDFを参照）（William Chan）、およびFred Baker。
Example reference entry:
参照エントリの例：
OLD:
古い：
[RFC6630] Cao, Z., Deng, H., Wu, Q., and G. Zorn, Ed., "EAP Re-authentication Protocol Extensions for Authenticated Anticipatory Keying (ERP/AAK)", RFC 6630, June 2012.
[RFC6630] Cao、Z.、Deng、H.、Wu、Q。、およびG. Zorn、編、「Authenticated Anticipatory Keying（ERP / AAK）のEAP再認証プロトコル拡張」、RFC 6630、2012年6月。
NEW
新着
[RFC6630] Cao, Z., Deng, H., (See PDF for non-ASCII character string) (Wu, Q.), and G. Zorn, Ed., "EAP Re-authentication Protocol Extensions for Authenticated Anticipatory Keying (ERP/AAK)", RFC 6630, June 2012.
[RFC6630] Cao、Z.、Deng、H。（非ASCII文字列についてはPDFを参照）（Wu、Q。）、およびG. Zorn編、「認証された予測キーイング用のEAP再認証プロトコル拡張（ ERP / AAK）」、RFC 6630、2012年6月。
Company names may appear in several places within an RFC. In all cases, valid Unicode is required. For names that include characters outside of the Unicode Latin and Latin Extended scripts, an author-provided, ASCII-only identifier is required to assist in searching and indexing of the document.
RFC内のいくつかの場所に会社名が表示される場合があります。すべての場合において、有効なUnicodeが必要です。 Unicode LatinおよびLatin Extendedスクリプト以外の文字を含む名前の場合、ドキュメントの検索とインデックス作成を支援するために、作成者が提供するASCIIのみの識別子が必要です。
When the mention of non-ASCII characters is required for correct protocol operation and understanding, the characters' Unicode code points must be used in the text. The addition of each character name is encouraged.
プロトコルを正しく操作して理解するために非ASCII文字について言及する必要がある場合は、文字のUnicodeコードポイントをテキストで使用する必要があります。各キャラクター名の追加をお勧めします。
o Non-ASCII characters will require identifying the Unicode code point.
o 非ASCII文字は、Unicodeコードポイントを識別する必要があります。
o Use of the actual UTF-8 character (e.g., (See PDF for non-ASCII character string)) is encouraged so that a reader can more easily see what the character is, if their device can render the text.
o 実際のUTF-8文字（たとえば、（ASCII以外の文字列についてはPDFを参照））を使用することをお勧めします。これにより、デバイスがテキストをレンダリングできる場合に、リーダーが文字を簡単に確認できるようになります。
o The use of the Unicode character names like "INCREMENT" in addition to the use of Unicode code points is also encouraged. When used, Unicode character names should be in all capital letters.
o Unicodeコードポイントの使用に加えて、 "INCREMENT"などのUnicode文字名の使用も推奨されます。使用する場合、Unicode文字名はすべて大文字にする必要があります。
Examples:
例：
OLD [RFC7564]:
古い[RFC7564]：
However, the problem is made more serious by introducing the full range of Unicode code points into protocol strings. For example, the characters U+13DA U+13A2 U+13B5 U+13AC U+13A2 U+13AC U+13D2 from the Cherokee block look similar to the ASCII characters "STPETER" as they might appear when presented using a "creative" font family.
ただし、プロトコル文字列にすべてのUnicodeコードポイントを導入することで、問題はさらに深刻になります。たとえば、チェロキーブロックの文字U + 13DA U + 13A2 U + 13B5 U + 13AC U + 13A2 U + 13AC U + 13D2は、「クリエイティブ」を使用して表示されると表示される可能性があるため、ASCII文字「STPETER」に似ています。フォントファミリー。
NEW/ALLOWED:
新規/許可：
However, the problem is made more serious by introducing the full range of Unicode code points into protocol strings. For example, the characters U+13DA U+13A2 U+13B5 U+13AC U+13A2 U+13AC U+13D2 ((See PDF for non-ASCII character string)) from the Cherokee block look similar to the ASCII characters "STPETER" as they might appear when presented using a "creative" font family.
ただし、プロトコル文字列にすべてのUnicodeコードポイントを導入することで、問題はさらに深刻になります。たとえば、チェロキーブロックの文字U + 13DA U + 13A2 U + 13B5 U + 13AC U + 13A2 U + 13AC U + 13D2（（ASCII以外の文字列についてはPDFを参照））は、ASCII文字「STPETER 「クリエイティブな」フォントファミリーを使用して表示されたときに表示される場合があります。
ALSO ACCEPTABLE:
また受け入れ可能：
However, the problem is made more serious by introducing the full range of Unicode code points into protocol strings. For example, the characters "(See PDF for non-ASCII character string)" (U+13DA U+13A2 U+13B5 U+13AC U+13A2 U+13AC U+13D2) from the Cherokee block look similar to the ASCII characters "STPETER" as they might appear when presented using a "creative" font family.
ただし、プロトコル文字列にすべてのUnicodeコードポイントを導入することで、問題はさらに深刻になります。たとえば、チェロキーブロックの文字「（ASCII以外の文字列についてはPDFを参照）」（U + 13DA U + 13A2 U + 13B5 U + 13AC U + 13A2 U + 13AC U + 13D2）は、ASCII文字に似ています。 「クリエイティブ」フォントファミリーを使用して表示されると表示される「STPETER」。
Example of proper identification of Unicode characters in an RFC:
RFCでのUnicode文字の適切な識別の例：
Acceptable:
許容できる：
o Temperature changes in the Temperature Control Protocol are indicated by the U+2206 character.
o 温度制御プロトコルの温度変化は、U + 2206文字で示されます。
Preferred:
優先：
1. Temperature changes in the Temperature Control Protocol are indicated by the U+2206 character ("(See PDF for non-ASCII character string)").
1. 温度制御プロトコルの温度変化は、U + 2206文字で示されます（「（非ASCII文字列についてはPDFを参照）」）。
2. Temperature changes in the Temperature Control Protocol are indicated by the U+2206 character (INCREMENT).
2. 温度制御プロトコルの温度変化は、U + 2206文字（INCREMENT）で示されます。
3. Temperature changes in the Temperature Control Protocol are indicated by the U+2206 character ("(See PDF for non-ASCII character string)", INCREMENT).
3. 温度制御プロトコルの温度変化は、U + 2206文字（「（非ASCII文字列についてはPDFを参照）」、INCREMENTで示されます。
4. Temperature changes in the Temperature Control Protocol are indicated by the U+2206 character (INCREMENT, "(See PDF for non-ASCII character string)").
4. 温度制御プロトコルの温度変化はU + 2206文字で示されます（インクリメント、「（ASCII以外の文字列についてはPDFを参照）」）。
5. Temperature changes in the Temperature Control Protocol are indicated by the "Delta" character "(See PDF for non-ASCII character string)" (U+2206).
5. 温度制御プロトコルの温度変化は、「Delta」文字「（ASCII以外の文字列についてはPDFを参照）」（U + 2206）で示されます。
6. Temperature changes in the Temperature Control Protocol are indicated by the character "(See PDF for non-ASCII character string)" (INCREMENT, U+2206).
6. 温度制御プロトコルの温度変化は、「（非ASCII文字列についてはPDFを参照）」という文字で示されます（インクリメント、U + 2206）。
Which option of (1), (2), (3), (4), (5), or (6) is preferred may depend on context and the specific character(s) in question. All are acceptable within an RFC. "US-ASCII Escaping of Unicode Character" [BCP137] describes the pros and cons of different options for identifying Unicode characters and may help authors decide how to represent the non-ASCII characters in their documents.
（1）、（2）、（3）、（4）、（5）、または（6）のどちらのオプションが好ましいかは、問題の特定の文字と状況によって異なります。 RFC内ではすべて許容されます。 「Unicode文字のUS-ASCIIエスケープ」[BCP137]では、Unicode文字を識別するためのさまざまなオプションの長所と短所を説明し、作成者がドキュメントで非ASCII文字を表現する方法を決定するのに役立つ場合があります。
Tables follow the same rules for identifiers and characters as in "Body of the Document" (Section 3.4). If it is sensible (i.e., more understandable for a reader) for a given document to have two tables, -- one including the identifiers and non-ASCII characters and a second with just the non-ASCII characters -- then that will be allowed at the discretion of the authors.
表は、「ドキュメントの本文」（セクション3.4）と同じ識別子と文字の規則に従います。特定のドキュメントに2つのテーブル（識別子と非ASCII文字を含むテーブルと、非ASCII文字のみを含むテーブル）を用意するのが賢明（つまり、読者にとって理解しやすい）場合は、許可されます。著者の裁量で。
Original text from "Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords" [RFC7613].
「ユーザー名とパスワードを表す国際化された文字列の準備、施行、比較」の原文[RFC7613]。
Table 3: A sample of legal passwords
表3：正当なパスワードのサンプル
+------------------------------------+------------------------------+
| # | Password | Notes |
+------------------------------------+------------------------------+
| 12| <correct horse battery staple> | ASCII space is allowed |
+------------------------------------+------------------------------+
| 13| <Correct Horse Battery Staple> | Different from example 12 |
+------------------------------------+------------------------------+
| 14| <πßå> | Non-ASCII letters are OK |
| | | (e.g., GREEK SMALL LETTER |
| | | PI, U+03C0) |
+------------------------------------+------------------------------+
| 15| <Jack of ♦s> | Symbols are OK (e.g., BLACK |
| | | DIAMOND SUIT, U+2666) |
+------------------------------------+------------------------------+
| 16| <foo bar> | OGHAM SPACE MARK, U+1680, is |
| | | mapped to U+0020 and thus |
| | | the full string is mapped to |
| | | <foo bar> |
+------------------------------------+------------------------------+
Preferred text:
優先テキスト：
Table 3: A sample of legal passwords
表3：正当なパスワードのサンプル
+------------------------------------+------------------------------+
| # | Password | Notes |
+------------------------------------+------------------------------+
| 12| <correct horse battery staple> | ASCII space is allowed |
+------------------------------------+------------------------------+
| 13| <Correct Horse Battery Staple> | Different from example 12 |
+------------------------------------+------------------------------+
| 14| <(See PDF for non-ASCII | Non-ASCII letters are OK |
| | character string)> | (e.g., GREEK SMALL LETTER |
| | | PI, U+03C0; LATIN SMALL |
| | | LETTER SHARP S, U+00DF; THAI |
| | | DIGIT SEVEN, U+0E57) |
+------------------------------------+------------------------------+
| 15| <Jack of (See PDF for non- | Symbols are OK (e.g., BLACK |
| | ASCII character string)s> | DIAMOND SUIT, U+2666) |
+------------------------------------+------------------------------+
| 16| <foo(See PDF for non-ASCII | OGHAM SPACE MARK, U+1680, is |
| | character string)bar> | mapped to U+0020 and thus |
| | | the full string is mapped to |
| | | <foo bar> |
+------------------------------------+------------------------------+
The RFC Editor encourages the use of the U+ notation except within a code component where one must follow the rules of the programming language in which the code is being written.
RFCエディターは、コードが記述されているプログラミング言語の規則に従う必要があるコードコンポーネント内を除き、U +表記の使用を推奨しています。
Code components are generally expected to use fixed-width fonts. Where such fonts are not available for a particular script, the best script-appropriate font will be used for that part of the code component.
コードコンポーネントは通常、固定幅フォントを使用することが想定されています。このようなフォントが特定のスクリプトで使用できない場合、コードコンポーネントのその部分には、スクリプトに適した最適なフォントが使用されます。
The reference entry must be in English; whatever subfields are present must be available in ASCII-encoded characters. For references to RFCs and Internet-Drafts, the author's name will be formatted in the reference as per current RFC Style Guide recommendations. As long as good sense is used, the reference entry may also include non-ASCII characters at the author's discretion and as provided by the author. The RFC Editor may request that a third party, such as a language specialist or subject matter expert, review of any non-ASCII reference. This applies to both normative and informative references.
参照エントリは英語である必要があります。存在するサブフィールドはすべて、ASCIIエンコード文字で使用できる必要があります。 RFCおよびInternet-Draftへの参照については、著者の名前は、現在のRFCスタイルガイドの推奨事項に従って参照でフォーマットされます。適切な意味が使用されている限り、参照エントリには、作成者の裁量で、作成者が提供する非ASCII文字も含めることができます。 RFCエディターは、言語の専門家や主題の専門家などのサードパーティに、ASCII以外の参照のレビューを要求する場合があります。これは、規範的および有益な参照の両方に適用されます。
Example:
例：
[GOST3410] "Information technology. Cryptographic data security. Signature and verification processes of [electronic] digital signature.", GOST R 34.10-2001, Gosudarstvennyi Standard of Russian Federation, Government Committee of Russia for Standards, 2001. (In Russian)
[GOST3410]「情報技術。暗号化データセキュリティ。[電子]デジタル署名の署名と検証プロセス。」、GOST R 34.10-2001、ロシア連邦のGosudarstvennyi標準、ロシア政府標準委員会、2001。（ロシア語）
Allowable addition to the above citation: (See PDF for non-ASCII character strings)
上記の引用に許容される追加：（非ASCII文字列についてはPDFを参照）
Alternatively: [GOST3410] "Information technology. Cryptographic data security. Signature and verification processes of [electronic] digital signature.", GOST R 34.10-2001, Gosudarstvennyi Standard of Russian Federation, (See PDF for non-ASCII character strings) (Government Committee of Russia for Standards), 2001. (In Russian)
または：[GOST3410]「情報技術。暗号化データセキュリティ。[電子]デジタル署名の署名と検証プロセス。」、GOST R 34.10-2001、ロシア連邦のGosudarstvennyi標準（非ASCII文字列についてはPDFを参照）（政府ロシア規格委員会）、2001年。（ロシア語）
Keywords (as tagged with the <keyword> element in XML) and citation tags (as defined in the anchor attributes of <reference> elements) must contain only ASCII characters.
キーワード（XMLの<keyword>要素でタグ付けされている）および引用タグ（<reference>要素のアンカー属性で定義されている）には、ASCII文字のみを含める必要があります。
The purpose of providing address information, either postal or email, is to assist readers of an RFC in contacting the author or authors. Authors may include the official postal address as recognized by their company or local postal service without additional non-ASCII character escapes. If the email address includes non-ASCII characters and is a valid email address at the time of publication, non-ASCII character escapes are not required.
郵便または電子メールのいずれかでアドレス情報を提供する目的は、RFCの読者が著者に連絡するのを支援することです。著者は、ASCII以外の文字エスケープを行わずに、会社または地域の郵便局によって認められた公式の郵便アドレスを含めることができます。電子メールアドレスに非ASCII文字が含まれていて、発行時に有効な電子メールアドレスである場合、非ASCII文字のエスケープは必要ありません。
Example:
例：
Qin Wu (editor) Huawei 101 Software Avenue, Yuhua District Nanjing, Jiangsu 210012 China
Q in W U（editor）hu A is 101 software avenue、Y U draw draws District NaN京、Jiangsu 210012 China
Additional contact information: (See PDF for non-ASCII character strings)
追加の連絡先情報：（ASCII以外の文字列についてはPDFを参照してください）
------
Roni Even Huawei 14 David Hamelech Tel Aviv 64953 Israel
Roni Even Huawei 14 David Hamelech Tel Aviv 64953 Israel
Additional contact information: (See PDF for non-ASCII character strings)
追加の連絡先情報：（ASCII以外の文字列についてはPDFを参照してください）
Authors should not expect normalization forms [UNICODE-NORM]to be preserved. If a particular normalization form is expected, note that in the text of the RFC.
著者は、正規化形式[UNICODE-NORM]が保持されることを期待すべきではありません。特定の正規化形式が予想される場合は、RFCのテキストに注意してください。
As described above, use of non-ASCII characters in areas such as email, company name, address, and name is allowed. In order to make it easier for code to identify the appropriate ASCII alternatives, authors must include an "ascii" attribute to their XML markup when an ASCII alternative is required. See [RFC7991] for more detail on how to tag ASCII alternatives.
上記のように、電子メール、会社名、住所、名前などの領域での非ASCII文字の使用が許可されています。コードが適切なASCII代替を識別しやすくするために、作成者は、ASCII代替が必要な場合、XMLマークアップに「ascii」属性を含める必要があります。 ASCII代替にタグを付ける方法の詳細については、[RFC7991]を参照してください。
The ability to use non-ASCII characters in RFCs in a clear and consistent manner will improve the ability to describe internationalized protocols and will recognize the diversity of authors. However, the goal of readability will override the use of non-ASCII characters within the text.
RFCで非ASCII文字を明確かつ一貫した方法で使用できることにより、国際化されたプロトコルを記述する能力が向上し、作者の多様性が認識されます。ただし、読みやすさの目標は、テキスト内の非ASCII文字の使用をオーバーライドします。
Valid Unicode that matches the expected text must be verified in order to preserve expected behavior and protocol information.
期待される動作とプロトコル情報を保持するには、期待されるテキストと一致する有効なUnicodeを検証する必要があります。
[BCP137] Klensin, J., "ASCII Escaping of Unicode Characters", BCP 137, RFC 5137, February 2008, <http://www.rfc-editor.org/info/bcp137>.
[BCP137] Klensin、J。、「ASCII Escaping of Unicode Characters」、BCP 137、RFC 5137、2008年2月、<http://www.rfc-editor.org/info/bcp137>。
[MerrWeb] Merriam-Webster, Inc., "Merriam-Webster's Collegiate Dictionary, 11th Edition", 2009.
[MerrWeb] Merriam-Webster、Inc。、「Merriam-Webster's Collegiate Dictionary、11th Edition」、2009年。
[RFC20] Cerf, V., "ASCII format for network interchange", STD 80, RFC 20, DOI 10.17487/RFC0020, October 1969, <http://www.rfc-editor.org/info/rfc20>.
[RFC20] Cerf、V。、「ネットワーク交換用のASCII形式」、STD 80、RFC 20、DOI 10.17487 / RFC0020、1969年10月、<http://www.rfc-editor.org/info/rfc20>。
[RFC4475] Sparks, R., Ed., Hawrylyshen, A., Johnston, A., Rosenberg, J., and H. Schulzrinne, "Session Initiation Protocol (SIP) Torture Test Messages", RFC 4475, DOI 10.17487/RFC4475, May 2006, <http://www.rfc-editor.org/info/rfc4475>.
[RFC4475] Sparks、R.、Ed。、Hawrylyshen、A.、Johnston、A.、Rosenberg、J.、and H. Schulzrinne、 "Session Initiation Protocol（SIP）Torture Test Messages"、RFC 4475、DOI 10.17487 / RFC4475 、2006年5月、<http://www.rfc-editor.org/info/rfc4475>。
[RFC7322] Flanagan, H. and S. Ginoza, "RFC Style Guide", RFC 7322, DOI 10.17487/RFC7322, September 2014, <http://www.rfc-editor.org/info/rfc7322>.
[RFC7322] Flanagan、H。およびS. Ginoza、「RFCスタイルガイド」、RFC 7322、DOI 10.17487 / RFC7322、2014年9月、<http://www.rfc-editor.org/info/rfc7322>。
[RFC7564] Saint-Andre, P. and M. Blanchet, "PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols", RFC 7564, DOI 10.17487/RFC7564, May 2015, <http://www.rfc-editor.org/info/rfc7564>.
[RFC7564] Saint-Andre、P。およびM. Blanchet、「PRECIS Framework：Preparation、Enforcement、and Comparison of Internationalized Strings in Application Protocols」、RFC 7564、DOI 10.17487 / RFC7564、2015年5月、<http：// www。 rfc-editor.org/info/rfc7564>。
[RFC7613] Saint-Andre, P. and A. Melnikov, "Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords", RFC 7613, DOI 10.17487/RFC7613, August 2015, <http://www.rfc-editor.org/info/rfc7613>.
[RFC7613] Saint-Andre、P。およびA. Melnikov、「ユーザー名とパスワードを表す国際化された文字列の準備、適用、比較」、RFC 7613、DOI 10.17487 / RFC7613、2015年8月、<http：//www.rfc- editor.org/info/rfc7613>。
[RFC7991] Hoffman, P., "The "xml2rfc" Version 3 Vocabulary", RFC 7991, DOI 10.17487/RFC7991, December 2016, <http://www.rfc-editor.org/info/rfc7991>.
[RFC7991] Hoffman、P。、「The "xml2rfc" Version 3 Vocabulary」、RFC 7991、DOI 10.17487 / RFC7991、2016年12月、<http://www.rfc-editor.org/info/rfc7991>。
[UNICODE-CHART] The Unicode Consortium, "The Unicode Standard", <http://www.unicode.org/charts>.
[UNICODE-CHART] Unicodeコンソーシアム、「The Unicode Standard」、<http://www.unicode.org/charts>。
[UNICODE-NORM] The Unicode Consortium, "Unicode Standard Annex #15: Unicode Normalization Forms", 2016, <http://www.unicode.org/reports/tr15/>.
[UNICODE-NORM] Unicodeコンソーシアム、「Unicode Standard Annex＃15：Unicode Normalization Forms」、2016、<http://www.unicode.org/reports/tr15/>。
[UnicodeCurrent] The Unicode Consortium, "The Unicode Standard", <http://www.unicode.org/versions/latest/>.
[UnicodeCurrent] Unicodeコンソーシアム、「The Unicode Standard」、<http://www.unicode.org/versions/latest/>。
IAB Members at the Time of Approval
承認時のIABメンバー
The IAB members at the time this memo was approved were (in alphabetical order):
このメモが承認されたときのIABメンバーは（アルファベット順）でした。
Jari Arkko Ralph Droms Ted Hardie Joe Hildebrand Russ Housley Lee Howard Erik Nordmark Robert Sparks Andrew Sullivan Dave Thaler Martin Thomson Brian Trammell Suzanne Woolf
ジャリアルコラルフドロムステッドハーディジョーヒルデブランドラスハウズリーリーハワードエリックノードマークロバートスパークスアンドリューサリバンデイブターラーマーティントムソンブライアントラメルスザンヌウルフ
Acknowledgements
謝辞
With many thanks to the members of the IAB i18n program. Also, many thanks to the RFC Format Design Team for their efforts in making this transition successful: Nevil Brownlee (ISE), Tony Hansen, Joe Hildebrand, Paul Hoffman, Ted Lemon, Julian Reschke, Adam Roach, Alice Russo, Robert Sparks (Tools Team liaison), and Dave Thaler.
IAB i18nプログラムのメンバーに感謝します。また、この移行を成功させるための取り組みについてRFCフォーマットデザインチームに感謝します。NevilBrownlee（ISE）、Tony Hansen、Joe Hildebrand、Paul Hoffman、Ted Lemon、Julian Reschke、Adam Roach、Alice Russo、Robert Sparks（Toolsチームリエゾン）、およびデイブターラー。
Author's Address
著者のアドレス
Heather Flanagan (editor) RFC Editor
Heather Flanagan（editor）RFC Editor
Email: rse@rfc-editor.org
URI: http://orcid.org/0000-0002-2647-2220