RFC 7622 - Extensible Messaging and Presence Protocol (XMPP): Address Format 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc7622
タイトル : RFC 7622 - Extensible Messaging and Presence Protocol（XMPP）：Address Format
翻訳編集 : 自動生成

[要約] RFC 7622は、XMPPのアドレス形式に関する仕様であり、XMPPアドレスの構造と解釈方法を定義しています。このRFCの目的は、XMPPのアドレスの一貫性と拡張性を確保し、異なるアドレス形式の間での相互運用性を向上させることです。

Internet Engineering Task Force (IETF)                    P. Saint-Andre
Request for Comments: 7622                                          &yet
Obsoletes: 6122                                           September 2015
Category: Standards Track
ISSN: 2070-1721

Extensible Messaging and Presence Protocol (XMPP): Address Format

Extensible Messaging and Presence Protocol（XMPP）：Address Format

Abstract

概要

This document defines the address format for the Extensible Messaging and Presence Protocol (XMPP), including support for code points outside the ASCII range. This document obsoletes RFC 6122.

このドキュメントでは、ASCII範囲外のコードポイントのサポートを含む、Extensible Messaging and Presence Protocol（XMPP）のアドレス形式を定義します。このドキュメントはRFC 6122を廃止します。

Status of This Memo

本文書の状態

This is an Internet Standards Track document.

これはInternet Standards Trackドキュメントです。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション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/rfc7622.

このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7622で入手できます。

著作権表示

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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

   1. Introduction ....................................................2
   2. Terminology .....................................................3
   3. Addresses .......................................................3
      3.1. Fundamentals ...............................................3
      3.2. Domainpart .................................................5
      3.3. Localpart ..................................................7
      3.4. Resourcepart ...............................................8
      3.5. Examples ...................................................9
   4. Enforcement in JIDs and JID Parts ..............................13
   5. Internationalization Considerations ............................15
   6. IANA Considerations ............................................16
      6.1. Stringprep Profiles Registry ..............................16
   7. Security Considerations ........................................16
      7.1. Reuse of PRECIS ...........................................16
      7.2. Reuse of Unicode ..........................................16
      7.3. Address Spoofing ..........................................16
   8. Conformance Requirements .......................................19
   9. References .....................................................21
      9.1. Normative References ......................................21
      9.2. Informative References ....................................22
   Appendix A. Differences from RFC 6122 .............................26
   Acknowledgements ..................................................27
   Author's Address ..................................................27

1. Introduction

1. はじめに

The Extensible Messaging and Presence Protocol (XMPP) [RFC6120] is an application profile of the Extensible Markup Language [XML] for streaming XML data in close to real time between any two or more network-aware entities. The address format for XMPP entities was originally developed in the Jabber open-source community in 1999, first described by [XEP-0029] in 2002, and then defined canonically by [RFC3920] in 2004 and [RFC6122] in 2011.

Extensible Messaging and Presence Protocol（XMPP）[RFC6120]は、2つ以上のネットワーク対応エンティティ間でリアルタイムでXMLデータをストリーミングするためのExtensible Markup Language [XML]のアプリケーションプロファイルです。 XMPPエンティティのアドレス形式は、1999年にJabberオープンソースコミュニティで最初に開発され、2002年に[XEP-0029]によって最初に記述され、次に2004年に[RFC3920]、2011年に[RFC6122]によって標準的に定義されました。

As specified in RFCs 3920 and 6122, the XMPP address format used the "stringprep" technology for preparation and comparison of non-ASCII characters [RFC3454]. Following the movement of internationalized domain names away from stringprep, this document defines the XMPP address format in a way that no longer depends on stringprep (see the Preparation, Enforcement, and Comparison of Internationalized Strings (PRECIS) problem statement [RFC6885]). Instead, this document builds upon the internationalization framework defined by the IETF's PRECIS working group [RFC7564].

RFC 3920および6122で指定されているように、XMPPアドレス形式は、非ASCII文字の準備と比較に「stringprep」テクノロジーを使用していました[RFC3454]。このドキュメントでは、国際化ドメイン名がstringprepから離れたため、stringprepに依存しない方法でXMPPアドレス形式を定義しています（国際化文字列の準備、実施、比較（PRECIS）問題ステートメント[RFC6885]を参照）。代わりに、このドキュメントは、IETFのPRECISワーキンググループ[RFC7564]によって定義された国際化フレームワークに基づいています。

Although every attempt has been made to ensure that the characters allowed in Jabber Identifiers (JIDs) under stringprep are still allowed and handled in the same way under PRECIS, there is no guarantee of strict backward compatibility because of changes in Unicode and the fact that PRECIS handling is based on Unicode properties, not a hardcoded table of characters. Because it is possible that previously valid JIDs might no longer be valid (or previously invalid JIDs might now be valid), operators of XMPP services are advised to perform careful testing before migrating accounts and other data (see Section 6 of [RFC7613] for guidance).

stringprepのJabber Identifiers（JID）で許可されている文字がPRECISでも引き続き許可され、同じ方法で処理されるようにするためのあらゆる試みが行われましたが、Unicodeの変更とPRECISの事実により、厳密な下位互換性の保証はありません。処理は、ハードコードされた文字テーブルではなく、Unicodeプロパティに基づいています。以前は有効だったJIDが無効になる可能性があるため（または以前は無効だったJIDが有効になる可能性があるため）、XMPPサービスのオペレーターは、アカウントやその他のデータを移行する前に慎重なテストを行うことをお勧めします（ガイダンスについては、[RFC7613]のセクション6を参照してください））。

This document obsoletes RFC 6122.

このドキュメントはRFC 6122を廃止します。

2. Terminology

2. 用語

Many important terms used in this document are defined in [RFC7564], [RFC5890], [RFC6120], [RFC6365], and [Unicode].

このドキュメントで使用される多くの重要な用語は、[RFC7564]、[RFC5890]、[RFC6120]、[RFC6365]、および[Unicode]で定義されています。

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこの文書の "は、[RFC2119]で説明されているように解釈されます。

3. Addresses

3. 住所

3.1. Fundamentals

3.1. 基礎

An XMPP entity is anything that can communicate using XMPP. For historical reasons, the network address of an XMPP entity is called a JID. A valid JID is a string of Unicode code points [Unicode], encoded using UTF-8 [RFC3629], and structured as an ordered sequence of localpart, domainpart, and resourcepart, where the first two parts are demarcated by the '@' character used as a separator and the last two parts are similarly demarcated by the '/' character (e.g., <juliet@example.com/balcony>).

XMPPエンティティは、XMPPを使用して通信できるすべてのものです。歴史的な理由により、XMPPエンティティのネットワークアドレスはJIDと呼ばれます。有効なJIDは、UTF-8 [RFC3629]を使用してエンコードされたUnicodeコードポイント[Unicode]の文字列で、localpart、domainpart、およびresourcepartの順序付けされたシーケンスとして構造化されます。最初の2つの部分は「@」文字で区切られますセパレータとして使用され、最後の2つの部分も同様に「/」文字で区切られます（例：<juliet@example.com/balcony>）。

The syntax for a JID is defined as follows, using the Augmented Backus-Naur Form (ABNF) as specified in [RFC5234].

JIDの構文は、[RFC5234]で指定されているAugmented Backus-Naur Form（ABNF）を使用して、次のように定義されます。

      jid          = [ localpart "@" ] domainpart [ "/" resourcepart ]
      localpart    = 1*1023(userbyte)
                     ;
                     ; a "userbyte" is a byte used to represent a
                     ; UTF-8 encoded Unicode code point that can be
                     ; contained in a string that conforms to the
                     ; UsernameCaseMapped profile of the PRECIS
                     ; IdentifierClass defined in RFC 7613
                     ;
      domainpart   = IP-literal / IPv4address / ifqdn
                     ;
                     ; the "IPv4address" and "IP-literal" rules are
                     ; defined in RFCs 3986 and 6874, respectively,
                     ; and the first-match-wins (a.k.a. "greedy")
                     ; algorithm described in Appendix B of RFC 3986
                     ; applies to the matching process
                     ;
      ifqdn        = 1*1023(domainbyte)
                     ;
                     ; a "domainbyte" is a byte used to represent a
                     ; UTF-8 encoded Unicode code point that can be
                     ; contained in a string that conforms to RFC 5890
                     ;
      resourcepart = 1*1023(opaquebyte)
                     ;
                     ; an "opaquebyte" is a byte used to represent a
                     ; UTF-8 encoded Unicode code point that can be
                     ; contained in a string that conforms to the
                     ; OpaqueString profile of the PRECIS
                     ; FreeformClass defined in RFC 7613
                     ;

All JIDs are based on the foregoing structure. However, note that the formal syntax provided above does not capture all of the rules and restrictions that apply to JIDs, which are described below.

すべてのJIDは、前述の構造に基づいています。ただし、上記の正式な構文は、以下で説明するJIDに適用されるすべてのルールと制限をキャプチャするわけではないことに注意してください。

Each allowable portion of a JID (localpart, domainpart, and resourcepart) is 1 to 1023 octets in length, resulting in a maximum total size (including the '@' and '/' separators) of 3071 octets.

JIDの許容される各部分（localpart、domainpart、およびresourcepart）は、長さが1〜1023オクテットであり、その結果、最大合計サイズ（「@」および「/」セパレーターを含む）は3071オクテットになります。

Implementation Note: The length limits on JIDs and parts of JIDs are based on octets (bytes), not characters. UTF-8 encoding can result in more than one octet per character.

実装上の注意：KIDおよびKIDの一部の長さ制限は、文字ではなくオクテット（バイト）に基づいています。 UTF-8エンコーディングでは、文字ごとに複数のオクテットが生じる可能性があります。

Implementation Note: When dividing a JID into its component parts, an implementation needs to match the separator characters '@' and '/' before applying any transformation algorithms, which might decompose certain Unicode code points to the separator characters.

実装に関する注意：JIDをコンポーネント部分に分割する場合、実装では、変換アルゴリズムを適用する前に区切り文字「@」と「/」を一致させる必要があります。これにより、特定のUnicodeコードポイントが区切り文字に分解される場合があります。

Implementation Note: Reuse of the IP-literal rule from [RFC6874] implies that IPv6 addresses are enclosed within square brackets (i.e., beginning with '[' and ending with ']'), which was not the case with the definition of the XMPP address format in [RFC3920] but which was changed in [RFC6122]. Also note that the IP-literal rule was updated between [RFC3986] and [RFC6874] to optionally add a zone identifier to any literal address.

実装上の注意：[RFC6874]のIPリテラルルールの再利用は、IPv6アドレスが角かっこで囲まれていることを意味します（つまり、「[」で始まり、「]」で終わる）。これは、XMPPの定義には当てはまりませんでした。 [RFC3920]のアドレス形式ですが、[RFC6122]で変更されました。また、IPリテラルルールが[RFC3986]と[RFC6874]の間で更新され、オプションで任意のリテラルアドレスにゾーン識別子を追加したことにも注意してください。

This document defines the native format for JIDs; see [RFC5122] for information about the representation of a JID as a Uniform Resource Identifier (URI) [RFC3986] or Internationalized Resource Identifier (IRI) [RFC3987] and the extraction of a JID from an XMPP URI or IRI.

このドキュメントでは、JIDのネイティブ形式を定義しています。 JIDのUniform Resource Identifier（URI）[RFC3986]またはInternationalized Resource Identifier（IRI）[RFC3987]としての表現、およびXMPP URIまたはIRIからのJIDの抽出については、[RFC5122]を参照してください。

3.2. Domainpart

3.2. ドメインパート

The domainpart of a JID is the portion that remains once the following parsing steps are taken:

JIDのドメイン部分は、次の解析手順を実行した後に残る部分です。

1. Remove any portion from the first '/' character to the end of the string (if there is a '/' character present).

1. 最初の「/」文字から文字列の末尾までの部分を削除します（「/」文字がある場合）。

2. Remove any portion from the beginning of the string to the first '@' character (if there is an '@' character present).

2. 文字列の先頭から最初の '@'文字までの部分を削除します（ '@'文字がある場合）。

This parsing order is important, as illustrated by example 15 in Section 3.5.

セクション3.5の例15に示すように、この解析順序は重要です。

The domainpart is the primary identifier and is the only REQUIRED element of a JID (a mere domainpart is a valid JID). Typically, a domainpart identifies the "home" server to which clients connect for XML routing and data management functionality. However, it is not necessary for an XMPP domainpart to identify an entity that provides core XMPP server functionality (e.g., a domainpart can identify an entity such as a multi-user chat service [XEP-0045], a publish-subscribe service [XEP-0060], or a user directory).

domainpartはプライマリ識別子であり、JIDの唯一の必須要素です（単なるdomainpartは有効なJIDです）。通常、domainpartは、クライアントがXMLルーティングおよびデータ管理機能のために接続する「ホーム」サーバーを識別します。ただし、XMPPドメインパーツがコアXMPPサーバー機能を提供するエンティティを識別する必要はありません（たとえば、ドメインパーツはマルチユーザーチャットサービス[XEP-0045]、パブリッシュサブスクライブサービス[XEP -0060]、またはユーザーディレクトリ）。

The domainpart for every XMPP service MUST be a fully qualified domain name (FQDN), an IPv4 address, an IPv6 address, or an unqualified hostname (i.e., a text label that is resolvable on a local network).

すべてのXMPPサービスのドメイン部分は、完全修飾ドメイン名（FQDN）、IPv4アドレス、IPv6アドレス、または非修飾ホスト名（つまり、ローカルネットワークで解決可能なテキストラベル）でなければなりません。

Informational Note: The term "fully qualified domain name" is not well defined. In [RFC1034], it is also called an absolute domain name, and the two terms are associated in [RFC1535]. The earliest use of the term can be found in [RFC1123]. References to those older specifications ought not to be construed as limiting the characters of a fully qualified domain name to the ASCII range; for example, [RFC5890] mentions that a fully qualified domain name can contain one or more U-labels.

情報メモ：「完全修飾ドメイン名」という用語は明確に定義されていません。 [RFC1034]では、これは絶対ドメイン名とも呼ばれ、[RFC1535]では2つの用語が関連付けられています。この用語の最も早い使用法は[RFC1123]にあります。これらの古い仕様への参照は、完全修飾ドメイン名の文字をASCII範囲に制限するものとして解釈されるべきではありません。たとえば、[RFC5890]は、完全修飾ドメイン名に1つ以上のUラベルを含めることができると述べています。

Interoperability Note: Domainparts that are IP addresses might not be accepted by other services for the purpose of server-to-server communication, and domainparts that are unqualified hostnames cannot be used on public networks because they are resolvable only on a local network.

相互運用性の注意：IPアドレスであるドメインパーツは、サーバー間通信の目的で他のサービスによって受け入れられない場合があり、非修飾ホスト名であるドメインパーツは、ローカルネットワークでのみ解決できるため、パブリックネットワークでは使用できません。

If the domainpart includes a final character considered to be a label separator (dot) by [RFC1034], this character MUST be stripped from the domainpart before the JID of which it is a part is used for the purpose of routing an XML stanza, comparing against another JID, or constructing an XMPP URI or IRI [RFC5122]. In particular, such a character MUST be stripped before any other canonicalization steps are taken.

[RFC1034]によってドメインパーツにラベルセパレーター（ドット）と見なされる最後の文字が含まれている場合、この文字は、XMLスタンザをルーティングする目的で使用される前に、ドメインパーツから削除する必要があります。別のJIDに対して、またはXMPP URIまたはIRI [RFC5122]を構築します。特に、そのような文字は、他の正規化手順が実行される前に削除する必要があります。

In general, the content of a domainpart is an Internationalized Domain Name (IDN) as described in the specifications for Internationalized Domain Names in Applications (commonly called "IDNA2008"), and a domainpart is an "IDNA-aware domain name slot" as defined in [RFC5890].

一般に、ドメインパートのコンテンツは、アプリケーションの国際化ドメイン名（一般に「IDNA2008」と呼ばれる）の仕様に記載されている国際化ドメイン名（IDN）であり、ドメインパートは定義された「IDNA対応ドメイン名スロット」です[RFC5890]。

After any and all normalization, conversion, and mapping of code points as well as encoding of the string as UTF-8, a domainpart MUST NOT be zero octets in length and MUST NOT be more than 1023 octets in length. (Naturally, the length limits of [RFC1034] apply, and nothing in this document is to be interpreted as overriding those more fundamental limits.)

コードポイントの正規化、変換、マッピングのほか、文字列をUTF-8としてエンコードした後、domainpartの長さは0オクテットであってはならず、1023オクテットを超えてはいけません。（当然、[RFC1034]の長さの制限が適用されます。このドキュメントでは、これらのより基本的な制限をオーバーライドするものとして解釈されるものはありません。）

Detailed rules and considerations for preparation, enforcement, and comparison are provided in the following sections.

以下のセクションでは、準備、施行、比較に関する詳細なルールと考慮事項について説明します。

3.2.1. Preparation

3.2.1. 準備

An entity that prepares a string for inclusion in an XMPP domainpart slot MUST ensure that the string consists only of Unicode code points that are allowed in NR-LDH labels or U-labels as defined in [RFC5890]. This implies that the string MUST NOT include A-labels as defined in [RFC5890]; each A-label MUST be converted to a U-label during preparation of a string for inclusion in a domainpart slot. In addition, the string MUST be encoded as UTF-8 [RFC3629].

XMPPドメインパーツスロットに含めるための文字列を準備するエンティティは、[RFC5890]で定義されているように、文字列がNR-LDHラベルまたはUラベルで許可されているUnicodeコードポイントのみで構成されていることを確認する必要があります。これは、[RFC5890]で定義されているように、文字列にAラベルを含めてはならないことを意味します。 domainpartスロットに含める文字列の準備中に、各AラベルをUラベルに変換する必要があります。さらに、文字列はUTF-8 [RFC3629]としてエンコードする必要があります。

3.2.2. Enforcement

3.2.2. 執行

An entity that performs enforcement in XMPP domainpart slots MUST prepare a string as described in Section 3.2.1 and MUST also apply the normalization, case-mapping, and width-mapping rules defined in [RFC5892].

XMPPドメインパーツスロットで施行を実行するエンティティは、セクション3.2.1で説明されているように文字列を準備しなければならず、[RFC5892]で定義されている正規化、大文字小文字マッピング、および幅マッピングルールも適用する必要があります。

Informational Note: The order in which the rules are applied for IDNA2008 (see [RFC5892] and [RFC5895]) is different from the order for localparts and resourceparts as described under Sections 3.3 and 3.4.

情報メモ：セクション3.3および3.4で説明されているように、IDNA2008（[RFC5892]および[RFC5895]を参照）にルールが適用される順序は、ローカルパーツおよびリソースパーツの順序とは異なります。

3.2.3. Comparison

3.2.3. 比較

An entity that performs comparison of two strings before or after their inclusion in XMPP domainpart slots MUST prepare each string as specified in Section 3.2.1 and then enforce the normalization, case-mapping, and width-mapping rules specified in Section 3.2.2. The two strings are to be considered equivalent if they are an exact octet-for-octet match (sometimes called "bit-string identity").

XMPPドメインパーツスロットに含める前または後に2つの文字列の比較を実行するエンティティは、セクション3.2.1で指定されているように各文字列を準備してから、セクション3.2.2で指定されている正規化、大文字小文字マッピング、および幅マッピングルールを適用する必要があります。 2つの文字列は、オクテットごとに完全に一致する場合（「ビット文字列ID」と呼ばれることもあります）、同等であると見なされます。

3.3. Localpart

3.3. ローカルパート

The localpart of a JID is an optional identifier placed before the domainpart and separated from the latter by the '@' character. Typically, a localpart uniquely identifies the entity requesting and using network access provided by a server (i.e., a local account), although it can also represent other kinds of entities (e.g., a chatroom associated with a multi-user chat service [XEP-0045]). The entity represented by an XMPP localpart is addressed within the context of a specific domain (i.e., <localpart@domainpart>).

JIDのローカル部分は、ドメイン部分の前に置かれ、 '@'文字によって後者から分離されるオプションの識別子です。通常、ローカルパーツは、サーバーによって提供されるネットワークアクセスを要求および使用するエンティティ（つまり、ローカルアカウント）を一意に識別しますが、他の種類のエンティティ（たとえば、マルチユーザーチャットサービスに関連付けられたチャットルーム[XEP- 0045）。 XMPPローカルパートで表されるエンティティは、特定のドメインのコンテキスト内でアドレス指定されます（つまり、<localpart @ domainpart>）。

The localpart of a JID MUST NOT be zero octets in length and MUST NOT be more than 1023 octets in length. This rule is to be enforced after any normalization and mapping of code points as well as encoding of the string as UTF-8.

JIDのローカル部分は、長さが0オクテットであってはならず、長さが1023オクテットを超えてはなりません。このルールは、コードポイントの正規化とマッピング、および文字列のUTF-8としてのエンコード後に適用されます。

The localpart of a JID is an instance of the UsernameCaseMapped profile of the PRECIS IdentifierClass, which is specified in [RFC7613]. The rules and considerations provided in that specification MUST be applied to XMPP localparts.

JIDのローカル部分は、[RFC7613]で指定されているPRECIS IdentifierClassのUsernameCaseMappedプロファイルのインスタンスです。その仕様で提供されているルールと考慮事項は、XMPPローカルパートに適用する必要があります。

Implementation Note: XMPP uses the Simple Authentication and Security Layer (SASL) [RFC4422] for authentication. At the time of this writing, some SASL mechanisms use SASLprep [RFC4013] for the handling of usernames and passwords; in the future, these SASL mechanisms will likely transition to the use of PRECIS-based handling rules as specified in [RFC7613]. For a detailed discussion about the implications of that transition (including the potential need to modify or remove certain characters in the underlying account database), see both Section 6 and Appendix A of [RFC7613].

実装上の注意：XMPPは、認証にSimple Authentication and Security Layer（SASL）[RFC4422]を使用します。この記事の執筆時点では、一部のSASLメカニズムは、ユーザー名とパスワードの処理にSASLprep [RFC4013]を使用しています。将来、これらのSASLメカニズムは、[RFC7613]で指定されているPRECISベースの処理ルールの使用に移行する可能性があります。その移行の影響（基礎となるアカウントデータベースの特定の文字を変更または削除する必要がある可能性を含む）の詳細については、セクション6と[RFC7613]の付録Aの両方を参照してください。

3.3.1. Further Excluded Characters

3.3.1. さらに除外された文字

In XMPP, the following characters are explicitly disallowed in XMPP localparts, even though they are allowed by the IdentifierClass base class and the UsernameCaseMapped profile:

XMPPでは、次の文字は、IdentifierClass基本クラスとUsernameCaseMappedプロファイルで許可されていても、XMPPローカルパーツでは明示的に禁止されています。

" U+0022 (QUOTATION MARK)

"U + 0022（引用符）

& U+0026 (AMPERSAND)

＆U + 0026（アンパサンド）

' U+0027 (APOSTROPHE)

'+ 0027（アポストロフィ）

/ U+002F (SOLIDUS)

／う＋００２Ｆ（そぃづＳ）

: U+003A (COLON)

：U + 003A（コロン）

< U+003C (LESS-THAN SIGN)

<U + 003C（符号なし）

> U+003E (GREATER-THAN SIGN)

> U + 003E（サインより大きい）

@ U+0040 (COMMERCIAL AT)

@ U + 0040（コマーシャルAT）

Implementation Note: An XMPP-specific method for escaping the foregoing characters (along with U+0020, i.e., ASCII space) has been defined in the JID Escaping specification [XEP-0106].

実装メモ：上記の文字をエスケープするためのXMPP固有の方法（U + 0020、つまりASCIIスペースとともに）は、JIDエスケープ仕様[XEP-0106]で定義されています。

3.4. Resourcepart

3.4. リソースパート

The resourcepart of a JID is an optional identifier placed after the domainpart and separated from the latter by the '/' character. A resourcepart can modify either a <localpart@domainpart> address or a mere <domainpart> address. Typically, a resourcepart uniquely identifies a specific connection (e.g., a device or location) or object (e.g., an occupant in a multi-user chatroom [XEP-0045]) belonging to the entity associated with an XMPP localpart at a domain (i.e., <localpart@domainpart/resourcepart>).

JIDのリソースパートは、ドメインパートの後に配置され、「/」文字によってドメインパートから分離されるオプションの識別子です。 resourcepartは、<localpart @ domainpart>アドレスまたは単なる<domainpart>アドレスを変更できます。通常、リソースパートは、特定の接続（例：デバイスまたは場所）またはオブジェクト（例：マルチユーザーチャットルーム[XEP-0045]の占有者）をドメインでXMPPローカルパートに関連付けられたエンティティ（例：、<localpart @ domainpart / resourcepart>）。

XMPP entities SHOULD consider resourceparts to be opaque strings and SHOULD NOT impute meaning to any given resourcepart. In particular:

XMPPエンティティは、リソースパーツを不透明な文字列であると見なすべきであり（SHOULD NOT）、与えられたリソースパーツに意味を持たせるべきではない（SHOULD NOT）。特に：

o Use of the '/' character as a separator between the domainpart and the resourcepart does not imply that XMPP addresses are hierarchical in the way that, say, HTTP URIs are hierarchical (see [RFC3986] for general discussion); thus, for example, an XMPP address of the form <localpart@domainpart/foo/bar> does not identify a resource "bar" that exists below a resource "foo" in a hierarchy of resources associated with the entity "localpart@domainpart".

o ドメインパートとリソースパートの間の区切り文字として「/」文字を使用しても、XMPPアドレスが、たとえばHTTP URIが階層的であるように階層的であるとは限りません（一般的な説明については[RFC3986]を参照）。したがって、たとえば、<localpart @ domainpart / foo / bar>という形式のXMPPアドレスは、エンティティ「localpart @ domainpart」に関連付けられたリソースの階層でリソース「foo」の下に存在するリソース「bar」を識別しません。。

o The '@' character is allowed in the resourcepart and is often used in the "handle" shown in XMPP chatrooms [XEP-0045]. For example, the JID <room@chat.example.com/user@host> describes an entity who is an occupant of the room <room@chat.example.com> with a handle of <user@host>. However, chatroom services do not necessarily check such an asserted handle against the occupant's real JID.

o '@'文字はリソース部分で使用でき、XMPPチャットルーム[XEP-0045]に示されている「ハンドル」でよく使用されます。たとえば、JID <room @ chat.example.com / user @ host>は、<user @ host>のハンドルを持つ部屋<room@chat.example.com>の占有者であるエンティティを示しています。ただし、チャットルームサービスは、必ずしもそのようなアサートされたハンドルを居住者の実際のJIDに対してチェックするわけではありません。

The resourcepart of a JID MUST NOT be zero octets in length and MUST NOT be more than 1023 octets in length. This rule is to be enforced after any normalization and mapping of code points as well as encoding of the string as UTF-8.

JIDのリソース部分は、長さが0オクテットであってはならず、長さが1023オクテットを超えてはなりません。このルールは、コードポイントの正規化とマッピング、および文字列のUTF-8としてのエンコード後に適用されます。

The resourcepart of a JID is an instance of the OpaqueString profile of the PRECIS FreeformClass, which is specified in [RFC7613]. The rules and considerations provided in that specification MUST be applied to XMPP resourceparts.

JIDのリソースパートは、[RFC7613]で指定されているPRECIS FreeformClassのOpaqueStringプロファイルのインスタンスです。その仕様で提供されている規則と考慮事項は、XMPPリソースパーツに適用する必要があります。

3.4.1. Applicability to XMPP Extensions

3.4.1. XMPP拡張機能への適用性

In some contexts, it might be appropriate to apply more restrictive rules to the preparation, enforcement, and comparison of XMPP resourceparts. For example, in XMPP Multi-User Chat [XEP-0045] it might be appropriate to apply the rules specified in [PRECIS-Nickname]. However, the application of more restrictive rules is out of scope for resourceparts in general and is properly defined in specifications for the relevant XMPP extensions.

状況によっては、XMPPリソースパーツの準備、適用、比較に、より制限的なルールを適用することが適切な場合があります。たとえば、XMPPマルチユーザーチャット[XEP-0045]では、[PRECIS-Nickname]で指定されたルールを適用することが適切な場合があります。ただし、より制限的なルールの適用は、一般的にリソースパーツの範囲外であり、関連するXMPP拡張機能の仕様で適切に定義されています。

3.5. Examples

3.5. 例

The following examples illustrate a small number of JIDs that are consistent with the format defined above (note that the characters "<" and ">" are used to delineate the actual JIDs and are not part of the JIDs themselves).

次の例は、上記で定義されたフォーマットと一致する少数のJIDを示しています（文字「<」および「>」は実際のJIDを表すために使用され、JID自体の一部ではないことに注意してください）。

   +----------------------------------+-------------------------------+
   | # | JID                          | Notes                         |
   +----------------------------------+-------------------------------+
   | 1 | <juliet@example.com>         | A "bare JID"                  |
   +----------------------------------+-------------------------------+
   | 2 | <juliet@example.com/foo>     | A "full JID"                  |
   +----------------------------------+-------------------------------+
   | 3 | <juliet@example.com/foo bar> | Single space in resourcepart  |
   +----------------------------------+-------------------------------+
   | 4 | <juliet@example.com/foo@bar> | "At" sign in resourcepart     |
   +----------------------------------+-------------------------------+
   | 5 | <foo\20bar@example.com>      | Single space in localpart, as |
   |   |                              | optionally escaped using the  |
   |   |                              | XMPP JID Escaping extension   |
   +----------------------------------+-------------------------------+
   | 6 | <fussball@example.com>       | Another bare JID              |
   +----------------------------------+-------------------------------+
   | 7 | <fu&#xDF;ball@example.com>   | The third character is LATIN  |
   |   |                              | SMALL LETTER SHARP S (U+00DF) |
   +----------------------------------+-------------------------------+
   | 8 | <&#x3C0;@example.com>        | A localpart of GREEK SMALL    |
   |   |                              | LETTER PI (U+03C0)            |
   +----------------------------------+-------------------------------+
   | 9 | <&#x3A3;@example.com/foo>    | A localpart of GREEK CAPITAL  |
   |   |                              | LETTER SIGMA (U+03A3)         |
   +----------------------------------+-------------------------------+
   | 10| <&#x3C3;@example.com/foo>    | A localpart of GREEK SMALL    |
   |   |                              | LETTER SIGMA (U+03C3)         |
   +----------------------------------+-------------------------------+
   | 11| <&#x3C2;@example.com/foo>    | A localpart of GREEK SMALL    |
   |   |                              | LETTER FINAL SIGMA (U+03C2)   |
   +----------------------------------+-------------------------------+
   | 12| <king@example.com/&#x265A>;  | A resourcepart of the Unicode |
   |   |                              | character BLACK CHESS KING    |
   |   |                              | (U+265A)                      |
   +----------------------------------+-------------------------------+
   | 13| <example.com>                | A domainpart                  |
   +----------------------------------+-------------------------------+
   | 14| <example.com/foobar>         | A domainpart and resourcepart |
   +----------------------------------+-------------------------------+
   | 15| <a.example.com/b@example.net>| A domainpart followed by a    |
   |   |                              | resourcepart that contains an |
   |   |                              | "at" sign                     |
   +----------------------------------+-------------------------------+

Table 1: A Sample of Legal JIDs

表1：法的KIDのサンプル

Several points are worth noting. Regarding examples 6 and 7: although in German the character esszett (LATIN SMALL LETTER SHARP S (U+00DF)) can mostly be used interchangeably with the two characters "ss", the localparts in these examples are different, and (if desired) a server would need to enforce a registration policy that disallows one of them if the other is registered. Regarding examples 9, 10, and 11: case-mapping of GREEK CAPITAL LETTER SIGMA (U+03A3) to lowercase (i.e., to GREEK SMALL LETTER SIGMA (U+03C3)) during comparison would result in matching the JIDs in examples 9 and 10; however, because the PRECIS mapping rules do not account for the special status of GREEK SMALL LETTER FINAL SIGMA (U+03C2), the JIDs in examples 9 and 11 or examples 10 and 11 would not be matched. Regarding example 12: symbol characters such as BLACK CHESS KING (U+265A) are allowed by the PRECIS FreeformClass and thus can be used in resourceparts. Regarding examples 14 and 15: JIDs consisting of a domainpart and resourcepart are rarely seen in the wild but are allowed according to the XMPP address format. Example 15 illustrates the need for careful extraction of the domainpart as described in Section 3.2.

注目すべき点がいくつかあります。例6と7について：ドイツ語では、文字esszett（ラテン小文字S（U + 00DF））は2つの文字「ss」とほとんど同じ意味で使用できますが、これらの例のローカル部分は異なり、（必要に応じて）サーバーは、もう一方が登録されている場合、一方を許可しない登録ポリシーを実施する必要があります。例9、10、および11に関して：比較中にギリシャ語の大文字のシグマ（U + 03A3）を小文字に（つまり、ギリシャ語の小文字のシグマ（U + 03C3）に）マッピングすると、例9と9のJIDが一致します。 10;ただし、PRECISマッピングルールではギリシャ語の小文字の最終シグマ（U + 03C2）の特別なステータスが考慮されていないため、例9と11または例10と11のJIDは一致しません。例12について：BLACK CHESS KING（U + 265A）などの記号文字は、PRECIS FreeformClassで許可されているため、リソースパーツで使用できます。例14と15について：domainpartとresourcepartで構成されるJIDが実際に見られることはほとんどありませんが、XMPPアドレス形式に従って許可されています。例15は、セクション3.2で説明されているように、ドメインパーツを慎重に抽出する必要性を示しています。

The following examples illustrate strings that are not JIDs because they violate the format defined above.

次の例は、上記で定義された形式に違反しているためにJIDではない文字列を示しています。

   +----------------------------------+-------------------------------+
   | # | Non-JID string               | Notes                         |
   +----------------------------------+-------------------------------+
   | 16| <"juliet"@example.com>       | Quotation marks (U+0022) in   |
   |   |                              | localpart                     |
   +----------------------------------+-------------------------------+
   | 17| <foo bar@example.com>        | Space (U+0020) in localpart   |
   +----------------------------------+-------------------------------+
   | 18| <juliet@example.com/ foo>    | Leading space in resourcepart |
   +----------------------------------+-------------------------------+
   | 19| <@example.com/>              | Zero-length localpart and     |
   |   |                              | resourcepart                  |
   +----------------------------------+-------------------------------+
   | 20| <henry&#x2163;@example.com>  | The sixth character is ROMAN  |
   |   |                              | NUMERAL FOUR (U+2163)         |
   +----------------------------------+-------------------------------+
   | 21| <&#x265A;@example.com>       | A localpart of BLACK CHESS    |
   |   |                              | KING (U+265A)                 |
   +----------------------------------+-------------------------------+
   | 22| <juliet@>                    | A localpart without a         |
   |   |                              | domainpart                    |
   +----------------------------------+-------------------------------+
   | 23| </foobar>                    | A resourcepart without a      |
   |   |                              | domainpart                    |
   +----------------------------------+-------------------------------+

Table 2: A Sample of Strings That Violate the JID Rules

表2：JIDルールに違反する文字列のサンプル

Here again, several points are worth noting. Regarding example 17: even though ASCII space (U+0020) is disallowed in the PRECIS IdentifierClass, it can be escaped to "\20" in XMPP localparts by using the JID Escaping rules defined in [XEP-0106], as illustrated by example 5 in Table 1. Regarding example 20: the Unicode character ROMAN NUMERAL FOUR (U+2163) has a compatibility equivalent of the string formed of LATIN CAPITAL LETTER I (U+0049) and LATIN CAPITAL LETTER V (U+0056), but characters with compatibility equivalents are not allowed in the PRECIS IdentifierClass. Regarding example 21: symbol characters such as BLACK CHESS KING (U+265A) are not allowed in the PRECIS IdentifierClass; however, both of the non-ASCII characters in examples 20 and 21 are allowed in the PRECIS FreeformClass and therefore in the XMPP resourcepart (as illustrated for U+265A by example 12 in Table 1). Regarding examples 22 and 23: the domainpart is required in a JID.

ここでも、いくつかの点に注意する必要があります。例17について：PRECIS IdentifierClassでASCIIスペース（U + 0020）が許可されていなくても、[XEP-0106]で定義されているJIDエスケープルールを使用して、XMPPローカルパーツで「\ 20」にエスケープできます。表1の5。例20について：Unicode文字のローマ数字4（U + 2163）は、ラテン大文字I（U + 0049）とラテン大文字V（U + 0056）で構成される文字列と互換性がありますが、 PRECIS IdentifierClassでは、互換性のある同等の文字を使用できません。例21について：BLACK CHESS KING（U + 265A）などの記号文字は、PRECIS IdentifierClassでは許可されていません。ただし、例20と21の非ASCII文字はどちらもPRECIS FreeformClassで、したがってXMPPリソースパーツで許可されます（表1の例12でU + 265Aに示されているように）。例22と23について：domainpartはJIDで必要です。

4. Enforcement in JIDs and JID Parts

4. KIDおよびJIDパーツの適用

Enforcement entails applying all of the rules specified in this document. Enforcement of the XMPP address format rules is the responsibility of XMPP servers. Although XMPP clients SHOULD prepare complete JIDs and parts of JIDs in accordance with this document before including them in protocol slots within XML streams, XMPP servers MUST enforce the rules wherever possible and reject stanzas and other XML elements that violate the rules (for stanzas, by returning a <jid-malformed/> error to the sender as described in Section 8.3.3.8 of [RFC6120]).

施行には、このドキュメントで指定されているすべてのルールを適用する必要があります。 XMPPアドレス形式ルールの実施は、XMPPサーバーの責任です。 XMPPクライアントは、XMLストリーム内のプロトコルスロットに含める前に、このドキュメントに従って完全なJIDとJIDの一部を準備する必要があります（SHOULD）が、XMPPサーバーは可能な限りルールを実施し、ルールに違反するスタンザやその他のXML要素を拒否する必要があります（スタンザの場合、 [RFC6120]のセクション8.3.3.8で説明されているように、送信者に<jid-malformed />エラーを返します）。

Entities that enforce the rules specified in this document are encouraged to be liberal in what they accept by following this procedure:

このドキュメントで指定されているルールを適用するエンティティは、次の手順に従って、受け入れるものに寛大であることが推奨されます。

1. Where possible, map characters (e.g., through width mapping, additional mapping, special mapping, case mapping, or normalization) and accept the mapped string.

1. 可能な場合は、文字をマッピングし（たとえば、幅マッピング、追加のマッピング、特別なマッピング、ケースマッピング、または正規化によって）、マッピングされた文字列を受け入れます。

2. If mapping is not possible (e.g., because a character is disallowed in the FreeformClass), reject the string and return a <jid-malformed/> error.

2. マッピングが不可能な場合（たとえば、FreeformClassで文字が許可されていないため）、文字列を拒否し、<jid-malformed />エラーを返します。

Enforcement applies to complete JIDs and to parts of JIDs. To facilitate implementation, this document defines the concepts of "JID slot", "localpart slot", and "resourcepart slot" (similar to the concept of a "domain name slot" for IDNA2008 as defined in Section 2.3.2.6 of [RFC5890]):

施行は、完全なJIDとJIDの一部に適用されます。実装を容易にするために、このドキュメントでは、「JIDスロット」、「localpartスロット」、および「resourcepartスロット」の概念を定義しています（[RFC5890]のセクション2.3.2.6で定義されているIDNA2008の「ドメイン名スロット」の概念に類似しています））：

JID Slot: An XML element or attribute explicitly designated in XMPP or in XMPP extensions for carrying a complete JID.

JIDスロット：完全なJIDを伝達するためにXMPPまたはXMPP拡張機能で明示的に指定されたXML要素または属性。

Localpart Slot: An XML element or attribute explicitly designated in XMPP or in XMPP extensions for carrying the localpart of a JID.

ローカルパートスロット：JIDのローカルパートを運ぶためにXMPPまたはXMPP拡張で明示的に指定されたXML要素または属性。

Resourcepart Slot: An XML element or attribute explicitly designated in XMPP or in XMPP extensions for carrying the resourcepart of a JID.

Resourcepart Slot：JIDのresourcepartを運ぶためにXMPPまたはXMPP拡張で明示的に指定されたXML要素または属性。

A server is responsible for enforcing the address format rules when receiving protocol elements from clients where the server is expected to handle such elements directly or to use them for purposes of routing a stanza to another domain or delivering a stanza to a local entity; two examples from [RFC6120] are the 'to' attribute on XML stanzas (which is a JID slot used by XMPP servers for routing of outbound stanzas) and the <resource/> child of the <bind/> element (which is a resourcepart slot used by XMPP servers for binding of a resource to an account for routing of stanzas between the server and a particular client). An example from [RFC6121] is the 'jid' attribute of the roster <item/> element.

サーバーは、サーバーがプロトコル要素を直接処理する、またはスタンザを別のドメインにルーティングしたり、スタンザをローカルエンティティに配信したりする目的で使用することが予想されるクライアントからプロトコル要素を受信するときに、アドレス形式ルールを適用する責任があります。 [RFC6120]の2つの例は、XMLスタンザの「to」属性（XMPPサーバーがアウトバウンドスタンザのルーティングに使用するJIDスロットです）と、<bind />要素の<resource />子（リソースパーツ）ですサーバーと特定のクライアント間のスタンザのルーティングのためにアカウントにリソースをバインドするためにXMPPサーバーによって使用されるスロット）。 [RFC6121]の例は、名簿の<item />要素の「jid」属性です。

A server is not responsible for enforcing the rules when the protocol elements are intended for communication among other entities, typically within the payload of a stanza that the server is merely routing to another domain or delivering to a local entity. Two examples are the 'initiator' attribute in the Jingle extension [XEP-0166] (which is a JID slot used for client-to-client coordination of multimedia sessions) and the 'nick' attribute in the Multi-User Chat extension [XEP-0045] (which is a resourcepart slot used for administrative purposes in the context of XMPP chatrooms). In such cases, the entities involved SHOULD enforce the rules themselves and not depend on the server to do so, and client implementers need to understand that not enforcing the rules can lead to a degraded user experience or to security vulnerabilities. However, when an add-on service (e.g., a multi-user chat service) handles a stanza directly, it ought to enforce the rules as well, as defined in the relevant specification for that type of service.

プロトコル要素が他のエンティティ間の通信を意図している場合、通常はサーバーが別のドメインにルーティングするか、ローカルエンティティに配信しているだけのスタンザのペイロード内にある場合、サーバーはルールを強制しません。 2つの例は、ジングル拡張[XEP-0166]（マルチメディアセッションのクライアント間調整に使用されるJIDスロット）の「開始者」属性と、マルチユーザーチャット拡張[XEPの「ニック」属性です。 -0045（これは、XMPPチャットルームのコンテキストで管理目的で使用されるリソースパートスロットです）。このような場合、関係するエンティティはルール自体を強制する必要があり、そうするためにサーバーに依存しません。クライアントの実装者は、ルールを強制しないとユーザーエクスペリエンスの低下やセキュリティの脆弱性につながる可能性があることを理解する必要があります。ただし、アドオンサービス（マルチユーザーチャットサービスなど）がスタンザを直接処理する場合は、そのタイプのサービスに関連する仕様で定義されているルールも適用する必要があります。

This document does not provide an exhaustive list of JID slots, localpart slots, or resourcepart slots. However, implementers of core XMPP servers are advised to consider as JID slots at least the following elements and attributes when they are handled directly or used for purposes of routing to another domain or delivering to a local entity:

このドキュメントでは、JIDスロット、localpartスロット、またはresourcepartスロットの完全なリストは提供していません。ただし、コアXMPPサーバーの実装者は、直接処理されるか、別のドメインへのルーティングまたはローカルエンティティへの配信の目的で使用される場合、少なくとも次の要素と属性をJIDスロットと見なすことをお勧めします。

o The 'from' and 'to' stream attributes and the 'from' and 'to' stanza attributes [RFC6120].

o 'from'および 'to'ストリーム属性と 'from'および 'to'スタンザ属性[RFC6120]。

o The 'jid' attribute of the roster <item/> element for contact list management [RFC6121].

o 連絡先リスト管理用の名簿の<item />要素の「jid」属性[RFC6121]。

o The 'value' attribute of the <item/> element for Privacy Lists [RFC3921] [XEP-0016] when the value of the 'type' attribute is "jid".

o 'type'属性の値が「jid」の場合のプライバシーリスト[RFC3921] [XEP-0016]の<item />要素の 'value'属性。

o The 'jid' attribute of the <item/> element for Service Discovery defined in [XEP-0030].

o [XEP-0030]で定義されているService Discoveryの<item />要素の「jid」属性。

o The <value/> element for Data Forms [XEP-0004] when the 'type' attribute is "jid-single" or "jid-multi".

o 「type」属性が「jid-single」または「jid-multi」の場合のデータフォーム[XEP-0004]の<value />要素。

o The 'jid' attribute of the <conference/> element for Bookmark Storage [XEP-0048].

o Bookmark Storage [XEP-0048]の<conference />要素の「jid」属性。

o The <JABBERID/> of the <vCard/> element for vCard 3.0 [XEP-0054] and the <uri/> child of the <impp/> element for vCard 4.0 [XEP-0292] when the XML character data identifies an XMPP URI [RFC5122].

o XML文字データがXMPPを識別する場合、vCard 3.0の<vCard />要素の<JABBERID /> [XEP-0054]およびvCard 4.0の<impp />要素の<uri />子[XEP-0292] URI [RFC5122]。

o The 'from' attribute of the <delay/> element for Delayed Delivery [XEP-0203].

o 遅延配信[XEP-0203]の<delay />要素の「from」属性。

o The 'jid' attribute of the <item/> element for the Blocking Command [XEP-0191].

o Blocking Command [XEP-0191]の<item />要素の「jid」属性。

o The 'from' and 'to' attributes of the <result/> and <verify/> elements for Server Dialback [XEP-0220].

o サーバーダイヤルバックの<result />および<verify />要素の「from」および「to」属性[XEP-0220]。

o The 'from' and 'to' attributes of the <iq/>, <message/>, and <presence/> elements for the Jabber Component Protocol [XEP-0114].

o Jabberコンポーネントプロトコル[XEP-0114]の<iq />、<message />、および<presence />要素の「from」および「to」属性。

Developers of XMPP clients and specialized XMPP add-on services are advised to check the appropriate specifications for JID slots, localpart slots, and resourcepart slots in XMPP protocol extensions such as Service Discovery [XEP-0030], Multi-User Chat [XEP-0045], Publish-Subscribe [XEP-0060], SOCKS5 Bytestreams [XEP-0065], In-Band Registration [XEP-0077], Roster Item Exchange [XEP-0144], and Jingle [XEP-0166].

XMPPクライアントおよび特殊なXMPPアドオンサービスの開発者は、Service Discovery [XEP-0030]、マルチユーザーチャット[XEP-0045]などのXMPPプロトコル拡張のJIDスロット、localpartスロット、およびresourcepartスロットの適切な仕様を確認することをお勧めします]、Publish-Subscribe [XEP-0060]、SOCKS5バイトストリーム[XEP-0065]、インバンド登録[XEP-0077]、Roster Item Exchange [XEP-0144]、およびJingle [XEP-0166]。

5. Internationalization Considerations

5. 国際化に関する考慮事項

XMPP applications MUST support IDNA2008 for domainparts as described under Section 3.2, the UsernameCaseMapped profile for localparts as described under Section 3.3, and the OpaqueString profile for resourceparts as described under Section 3.4. This enables XMPP addresses to include a wide variety of characters outside the ASCII range. Rules for enforcement of the XMPP address format are provided in [RFC6120] and specifications for various XMPP extensions.

XMPPアプリケーションは、セクション3.2で説明されているドメインパーツのIDNA2008、セクション3.3で説明されているローカルパーツのUsernameCaseMappedプロファイル、およびセクション3.4で説明されているリソースパーツのOpaqueStringプロファイルをサポートする必要があります。これにより、XMPPアドレスにASCII範囲外のさまざまな文字を含めることができます。 XMPPアドレス形式の施行規則は、[RFC6120]とさまざまなXMPP拡張機能の仕様で提供されています。

Interoperability Note: For backward compatibility, many existing XMPP implementations and deployments support IDNA2003 [RFC3490] for domainparts, and the stringprep [RFC3454] profiles Nodeprep and Resourceprep [RFC3920] for localparts and resourceparts.

相互運用性の注意：下位互換性のために、既存のXMPP実装とデプロイメントの多くは、ドメインパーツのIDNA2003 [RFC3490]と、ローカルパーツとリソースパーツのstringprep [RFC3454]プロファイルNodeprepとResourceprep [RFC3920]をサポートしています。

6. IANA Considerations

6. IANAに関する考慮事項

6.1. Stringprep Profiles Registry

6.1. Stringprepプロファイルレジストリ

The stringprep specification [RFC3454] did not provide for entries in the "Stringprep Profiles" registry to have any state except "Current" or "Not Current". Because this document obsoletes RFC 6122, which registered the Nodeprep and Resourceprep profiles of stringprep, IANA has marked those profiles as "Not Current" and cited this document as an additional reference.

stringprep仕様[RFC3454]では、 "Stringprep Profiles"レジストリのエントリが "Current"または "Not Current"以外の状態になることはありませんでした。このドキュメントは、stringprepのNodeprepおよびResourceprepプロファイルを登録したRFC 6122を廃止したため、IANAはこれらのプロファイルを「最新ではない」としてマークし、このドキュメントを追加の参照として引用しました。

7. Security Considerations

7. セキュリティに関する考慮事項

7.1. Reuse of PRECIS

7.1. PRECISの再利用

The security considerations described in [RFC7564] apply to the IdentifierClass and FreeformClass base string classes used in this document for XMPP localparts and resourceparts, respectively. The security considerations described in [RFC5890] apply to internationalized domain names, which are used here for XMPP domainparts.

[RFC7564]で説明されているセキュリティの考慮事項は、このドキュメントでXMPP localpartsとresourcepartsに対してそれぞれ使用されるIdentifierClassおよびFreeformClass基本文字列クラスに適用されます。 [RFC5890]で説明されているセキュリティ上の考慮事項は、XMPPドメインパーツに使用される国際化ドメイン名に適用されます。

7.2. Reuse of Unicode

7.2. Unicodeの再利用

The security considerations described in [UTS39] apply to the use of Unicode characters in XMPP addresses.

[UTS39]で説明されているセキュリティの考慮事項は、XMPPアドレスでのUnicode文字の使用に適用されます。

7.3. Address Spoofing

7.3. アドレスのなりすまし

There are two forms of address spoofing: forging and mimicking.

アドレスのなりすましには、偽造と模倣の2つの形式があります。

7.3.1. Address Forging

7.3.1. アドレス偽造

In the context of XMPP technologies, address forging occurs when an entity is able to generate an XML stanza whose 'from' address does not correspond to the account credentials with which the entity authenticated onto the network (or an authorization identity provided during negotiation of SASL authentication [RFC4422] as described in [RFC6120]). For example, address forging occurs if an entity that authenticated as "juliet@im.example.com" is able to send XML stanzas from "nurse@im.example.com" or "romeo@example.net".

XMPPテクノロジーのコンテキストでは、エンティティがネットワークから認証されたアカウント資格情報（またはSASLのネゴシエーション中に提供された承認ID）に対応しない「開始」アドレスのXMLスタンザをエンティティが生成できる場合、アドレス偽造が発生します[RFC6120]で説明されている認証[RFC4422]）。たとえば、「juliet@im.example.com」として認証されたエンティティが「nurse@im.example.com」または「romeo@example.net」からXMLスタンザを送信できる場合、アドレス偽造が発生します。

Address forging is difficult in XMPP systems, given the requirement for sending servers to stamp 'from' addresses and for receiving servers to verify sending domains via server-to-server authentication (see [RFC6120]). However, address forging is possible if:

XMPPシステムでは、アドレスの偽造は困難です。送信サーバーに「差出人」アドレスをスタンプし、受信サーバーがサーバー間認証を介して送信ドメインを確認する必要があるためです（[RFC6120]を参照）。ただし、次の場合はアドレス偽造が可能です。

o A poorly implemented server ignores the requirement for stamping the 'from' address. This would enable any entity that authenticated with the server to send stanzas from any localpart@domainpart as long as the domainpart matches the sending domain of the server.

o 適切に実装されていないサーバーは、「差出人」アドレスをスタンプする要件を無視します。これにより、domainpartがサーバーの送信ドメインと一致する限り、サーバーで認証されたすべてのエンティティがlocalpart @ domainpartからスタンザを送信できるようになります。

o An actively malicious server generates stanzas on behalf of any registered account at the domain or domains hosted at that server.

o アクティブに悪意のあるサーバーは、そのサーバーでホストされている1つまたは複数のドメインに登録されているアカウントに代わってスタンザを生成します。

Therefore, an entity outside the security perimeter of a particular server cannot reliably distinguish between JIDs of the form <localpart@domainpart> at that server and thus can authenticate only the domainpart of such JIDs with any level of assurance. This specification does not define methods for discovering or counteracting the kind of poorly implemented or rogue servers just described. However, the end-to-end authentication or signing of XMPP stanzas could help to mitigate this risk, because it would require the rogue server to generate false credentials for signing or encryption of each stanza, in addition to modifying 'from' addresses.

したがって、特定のサーバーのセキュリティ境界の外側にあるエンティティは、そのサーバーで<localpart @ domainpart>形式のJIDを確実に区別できず、そのため、そのようなJIDのドメイン部分のみを任意のレベルの保証で認証できます。この仕様は、今説明した種類の不十分に実装された、または不正なサーバーを検出または相殺する方法を定義していません。ただし、XMPPスタンザのエンドツーエンド認証または署名は、「from」アドレスの変更に加えて、不正なサーバーが各スタンザの署名または暗号化のために誤った資格情報を生成する必要があるため、このリスクを軽減するのに役立ちます。

7.3.2. Address Mimicking

7.3.2. アドレス模倣

Address mimicking occurs when an entity provides legitimate authentication credentials for, and sends XML stanzas from, an account whose JID appears to a human user to be the same as another JID. Because many characters are visually similar, it is relatively easy to mimic JIDs in XMPP systems. As one simple example, the localpart "ju1iet" (using the Arabic numeral one as the third character) might appear the same as the localpart "juliet" (using lowercase "L" as the third character).

エンティティが正当な認証資格情報を提供し、XMLスタンザを送信したときに、アドレスの模倣が発生します。そのアカウントのJIDは、人間のユーザーには別のJIDと同じであるように見えます。多くの文字は視覚的に類似しているため、XMPPシステムでJIDを模倣することは比較的簡単です。簡単な例の1つとして、ローカルパーツ "ju1iet"（アラビア数字の1を3番目の文字として使用）は、ローカルパーツ "juliet"（3番目の文字として小文字の "L"を使用）と同じように見える場合があります。

As explained in [RFC5890], [RFC7564], [UTR36], and [UTS39], there is no straightforward solution to the problem of visually similar characters. Furthermore, IDNA and PRECIS technologies do not attempt to define such a solution. As a result, XMPP domainparts, localparts, and resourceparts could contain such characters, leading to security vulnerabilities such as the following:

[RFC5890]、[RFC7564]、[UTR36]、および[UTS39]で説明されているように、視覚的に類似した文字の問題に対する簡単な解決策はありません。さらに、IDNAおよびPRECISテクノロジーは、このようなソリューションを定義しようとするものではありません。その結果、XMPPドメインパーツ、ローカルパーツ、およびリソースパーツにこのような文字が含まれる可能性があり、次のようなセキュリティの脆弱性が発生します。

o A domainpart is always employed as one part of an entity's address in XMPP. One common usage is as the address of a server or server-side service, such as a multi-user chat service [XEP-0045]. The security of such services could be compromised based on different interpretations of the internationalized domainpart; for example, a user might authorize a malicious entity at a fake server to view the user's presence information, or a user could join chatrooms at a fake multi-user chat service.

o domainpartは常にXMPPのエンティティのアドレスの一部として使用されます。一般的な使用法の1つは、マルチユーザーチャットサービス[XEP-0045]などのサーバーまたはサーバー側サービスのアドレスとして使用することです。そのようなサービスのセキュリティは、国際化されたドメイン部分の異なる解釈に基づいて危険にさらされる可能性があります。たとえば、ユーザーは偽のサーバーで悪意のあるエンティティにユーザーのプレゼンス情報の表示を許可したり、偽のマルチユーザーチャットサービスでチャットルームに参加したりすることができます。

o A localpart can be employed as one part of an entity's address in XMPP. One common usage is as the username of an instant messaging user; another is as the name of a multi-user chatroom; and many other kinds of entities could use localparts as part of their addresses. The security of such services could be compromised based on different interpretations of the internationalized localpart; for example, a user entering a single internationalized localpart could access another user's account information, or a user could gain access to a hidden or otherwise restricted chatroom or service.

o ローカルパートは、XMPPでエンティティのアドレスの一部として使用できます。一般的な使用法の1つは、インスタントメッセージングユーザーのユーザー名です。もう1つは、マルチユーザーチャットルームの名前です。他の多くの種類のエンティティは、ローカルパーツをアドレスの一部として使用できます。そのようなサービスのセキュリティは、国際化されたローカル部分の異なる解釈に基づいて侵害される可能性があります。たとえば、ユーザーが単一の国際化されたローカルパーツを入力すると、別のユーザーのアカウント情報にアクセスしたり、非表示の、または制限されたチャットルームやサービスにアクセスしたりできます。

o A resourcepart can be employed as one part of an entity's address in XMPP. One common usage is as the name for an instant messaging user's connected resource; another is as the nickname of a user in a multi-user chatroom; and many other kinds of entities could use resourceparts as part of their addresses. The security of such services could be compromised based on different interpretations of the internationalized resourcepart; for example, two or more confusable resources could be bound at the same time to the same account (resulting in inconsistent authorization decisions in an XMPP application that uses full JIDs), or a user could send a private message to someone other than the intended recipient in a multi-user chatroom.

o リソースパーツは、XMPPでエンティティのアドレスの一部として使用できます。一般的な使用法の1つは、インスタントメッセージングユーザーの接続リソースの名前です。もう1つは、マルチユーザーチャットルームのユーザーのニックネームです。また、他の多くの種類のエンティティは、アドレスの一部としてリソースパーツを使用できます。このようなサービスのセキュリティは、国際化されたリソース部分のさまざまな解釈に基づいて侵害される可能性があります。たとえば、2つ以上の混乱しやすいリソースが同時に同じアカウントにバインドされる（完全なJIDを使用するXMPPアプリケーションで一貫性のない承認決定が発生する）、またはユーザーが目的の受信者以外の誰かにプライベートメッセージを送信する可能性があります。マルチユーザーのチャットルーム。

XMPP services and clients are strongly encouraged to define and implement consistent policies regarding the registration, storage, and presentation of visually similar characters in XMPP systems. In particular, service providers and software implementers are strongly encouraged to apply the policies recommended in [RFC7564].

XMPPサービスとクライアントは、XMPPシステムでの視覚的に類似した文字の登録、保存、および表示に関する一貫したポリシーを定義して実装することを強くお勧めします。特に、サービスプロバイダーとソフトウェアの実装者は、[RFC7564]で推奨されているポリシーを適用することを強くお勧めします。

8. Conformance Requirements

8. 適合要件

This section describes a protocol feature set that summarizes the conformance requirements of this specification (similar feature sets are provided for XMPP in [RFC6120] and [RFC6121]). The summary is purely informational, and the conformance keywords of [RFC2119] as used here are intended only to briefly describe the referenced normative text from the body of this specification. This feature set is appropriate for use in software certification, interoperability testing, and implementation reports. For each feature, this section provides the following information:

このセクションでは、この仕様の適合要件を要約したプロトコル機能セットについて説明します（[RFC6120]と[RFC6121]のXMPPにも同様の機能セットが提供されています）。概要は純粋に情報提供であり、ここで使用される[RFC2119]の適合キーワードは、この仕様の本文から参照される規範的なテキストを簡単に説明することのみを目的としています。この機能セットは、ソフトウェア認定、相互運用性テスト、および実装レポートでの使用に適しています。このセクションでは、機能ごとに次の情報を提供します。

o A human-readable name

o 人間が読める名前

o An informational description

o 情報の説明

o A reference to the particular section of this document that normatively defines the feature

o 機能を規範的に定義するこのドキュメントの特定のセクションへの参照

o Whether the feature applies to the client role, the server role, or both (where "N/A" signifies that the feature is not applicable to the specified role)

o 機能がクライアントの役割、サーバーの役割、またはその両方に適用されるかどうか（「N / A」は、機能が指定された役割に適用されないことを示します）

o Whether the feature MUST or SHOULD be implemented, where the capitalized terms are to be understood as described in [RFC2119]

o [RFC2119]で説明されているように、大文字の用語を理解する必要がある場合は、機能を実装する必要があるか、実装する必要があります。

The feature set specified here provides a basis for interoperability testing and follows the spirit of a proposal made by Larry Masinter within the IETF's NEWTRK working group in 2005 [INTEROP].

ここで指定された機能セットは相互運用性テストの基礎を提供し、2005年にIETFのNEWTRKワーキンググループ内でLarry Masinterが作成した提案の精神に従います[INTEROP]。

Feature: address-domain-length

機能：アドレスドメイン長

Description: Ensure that the domainpart of an XMPP address is at least one octet in length and at most 1023 octets in length, and that it conforms to the underlying length limits of the DNS.

説明：XMPPアドレスのドメイン部分の長さが少なくとも1オクテット、最大で1023オクテットであり、DNSの基本的な長さ制限に準拠していることを確認してください。

Section: Section 3.2

セクション：セクション3.2

Roles: Server MUST, client SHOULD.

役割：サーバーは必須、クライアントは必須です。

Feature: address-domain-prep

機能：address-domain-prep

Description: Ensure that the domainpart of an XMPP address conforms to IDNA2008, that it contains only NR-LDH labels and U-labels (not A-labels), and that all uppercase and titlecase code points are mapped to their lowercase equivalents.

説明：XMPPアドレスのドメイン部分がIDNA2008に準拠し、NR-LDHラベルとUラベル（Aラベルではない）のみが含まれていること、およびすべての大文字とタイトルケースのコードポイントが対応する小文字にマップされていることを確認してください。

Section: Section 3.2

セクション：セクション3.2

Roles: Server MUST, client SHOULD.

役割：サーバーは必須、クライアントは必須です。

Feature: address-localpart-length

機能：address-localpart-length

Description: Ensure that the localpart of an XMPP address is at least one octet in length and at most 1023 octets in length.

説明：XMPPアドレスのローカル部分の長さが少なくとも1オクテット、最大で1023オクテットであることを確認してください。

Section: Section 3.3

セクション：セクション3.3

Roles: Server MUST, client SHOULD.

役割：サーバーは必須、クライアントは必須です。

Feature: address-localpart-prep

機能：address-localpart-prep

Description: Ensure that the localpart of an XMPP address conforms to the UsernameCaseMapped profile of the PRECIS IdentifierClass.

説明：XMPPアドレスのローカル部分がPRECIS IdentifierClassのUsernameCaseMappedプロファイルに準拠していることを確認してください。

Section: Section 3.3

セクション：セクション3.3

Roles: Server MUST, client SHOULD.

役割：サーバーは必須、クライアントは必須です。

Feature: address-resource-length

機能：アドレスリソース長

Description: Ensure that the resourcepart of an XMPP address is at least one octet in length and at most 1023 octets in length.

説明：XMPPアドレスのリソース部分の長さが少なくとも1オクテット、最大で1023オクテットであることを確認してください。

Section: Section 3.4

セクション：セクション3.4

Roles: Server MUST, client SHOULD.

役割：サーバーは必須、クライアントは必須です。

Feature: address-resource-prep

機能：address-resource-prep

Description: Ensure that the resourcepart of an XMPP address conforms to the OpaqueString profile of the PRECIS FreeformClass.

説明：XMPPアドレスのリソース部分がPRECIS FreeformClassのOpaqueStringプロファイルに準拠していることを確認してください。

Section: Section 3.4

セクション：セクション3.4

Roles: Server MUST, client SHOULD.

役割：サーバーは必須、クライアントは必須です。

9. References

9. 参考文献

9.1. Normative References

9.1. 引用文献

[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <http://www.rfc-editor.org/info/rfc1034>.

[RFC1034] Mockapetris、P。、「ドメイン名-概念と機能」、STD 13、RFC 1034、DOI 10.17487 / RFC1034、1987年11月、<http://www.rfc-editor.org/info/rfc1034>。

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。

[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <http://www.rfc-editor.org/info/rfc3629>.

[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、DOI 10.17487 / RFC3629、2003年11月、<http://www.rfc-editor.org/info/ rfc3629>。

[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.

[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、DOI 10.17487 / RFC3986、2005年1月、<http：/ /www.rfc-editor.org/info/rfc3986>。

[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.

[RFC5234] Crocker、D.、Ed。、およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、DOI 10.17487 / RFC5234、2008年1月、<http：//www.rfc-editor .org / info / rfc5234>。

[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, <http://www.rfc-editor.org/info/rfc5890>.

[RFC5890] Klensin、J。、「Internationalized Domain Names for Applications（IDNA）：Definitions and Document Framework」、RFC 5890、DOI 10.17487 / RFC5890、2010年8月、<http://www.rfc-editor.org/info/ rfc5890>。

[RFC5892] Faltstrom, P., Ed., "The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)", RFC 5892, DOI 10.17487/RFC5892, August 2010, <http://www.rfc-editor.org/info/rfc5892>.

[RFC5892] Faltstrom、P。、編、「アプリケーションのUnicodeコードポイントと国際化ドメイン名（IDNA）」、RFC 5892、DOI 10.17487 / RFC5892、2010年8月、<http://www.rfc-editor.org / info / rfc5892>。

[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, March 2011, <http://www.rfc-editor.org/info/rfc6120>.

[RFC6120] Saint-Andre、P。、「Extensible Messaging and Presence Protocol（XMPP）：Core」、RFC 6120、DOI 10.17487 / RFC6120、2011年3月、<http://www.rfc-editor.org/info/rfc6120 >。

[RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in Internationalization in the IETF", BCP 166, RFC 6365, DOI 10.17487/RFC6365, September 2011, <http://www.rfc-editor.org/info/rfc6365>.

[RFC6365] Hoffman、P。およびJ. Klensin、「IETFの国際化で使用される用語」、BCP 166、RFC 6365、DOI 10.17487 / RFC6365、2011年9月、<http://www.rfc-editor.org/info / rfc6365>。

[RFC6874] Carpenter, B., Cheshire, S., and R. Hinden, "Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers", RFC 6874, DOI 10.17487/RFC6874, February 2013, <http://www.rfc-editor.org/info/rfc6874>.

[RFC6874]カーペンター、B。、チェシャー、S。、およびR.ヒンデン、「アドレスリテラルおよびユニフォームリソース識別子でのIPv6ゾーン識別子の表現」、RFC 6874、DOI 10.17487 / RFC6874、2013年2月、<http：// www。 rfc-editor.org/info/rfc6874>。

[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>。

[Unicode] The Unicode Consortium, "The Unicode Standard", <http://www.unicode.org/versions/latest/>.

[Unicode] Unicodeコンソーシアム、「The Unicode Standard」、<http://www.unicode.org/versions/latest/>。

[UTR36] Unicode Technical Report #36, "Unicode Security Considerations", edited by Mark Davis and Michel Suignard, <http://www.unicode.org/reports/tr36/>.

[UTR36] Unicodeテクニカルレポート＃36、「Unicodeのセキュリティに関する考慮事項」、Mark DavisおよびMichel Suignardによる編集、<http://www.unicode.org/reports/tr36/>。

9.2. Informative References

9.2. 参考引用

[INTEROP] Masinter, L., "Formalizing IETF Interoperability Reporting", Work in Progress, draft-ietf-newtrk-interop-reports-00, October 2005.

[INTEROP] Masinter、L。、「正式なIETF相互運用性レポート」、進行中の作業、draft-ietf-newtrk-interop-reports-00、2005年10月。

[PRECIS-Nickname] Saint-Andre, P., "Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames", Work in Progress, draft-ietf-precis-nickname-18, June 2015.

[PRECIS-Nickname] Saint-Andre、P.、「ニックネームを表す国際化された文字列の準備、実施、比較」、進行中の作業、draft-ietf-precis-nickname-18、2015年6月。

[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, DOI 10.17487/RFC1123, October 1989, <http://www.rfc-editor.org/info/rfc1123>.

[RFC1123] Braden、R。、編、「インターネットホストの要件-アプリケーションとサポート」、STD 3、RFC 1123、DOI 10.17487 / RFC1123、1989年10月、<http://www.rfc-editor.org/info / rfc1123>。

[RFC1535] Gavron, E., "A Security Problem and Proposed Correction With Widely Deployed DNS Software", RFC 1535, DOI 10.17487/RFC1535, October 1993, <http://www.rfc-editor.org/info/rfc1535>.

[RFC1535] Gavron、E。、「広く展開されているDNSソフトウェアでのセキュリティの問題と修正案」、RFC 1535、DOI 10.17487 / RFC1535、1993年10月、<http://www.rfc-editor.org/info/rfc1535> 。

[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, DOI 10.17487/RFC3454, December 2002, <http://www.rfc-editor.org/info/rfc3454>.

[RFC3454] Hoffman、P.およびM. Blanchet、「Preparation of Internationalized Strings（ "stringprep"）」、RFC 3454、DOI 10.17487 / RFC3454、2002年12月、<http://www.rfc-editor.org/info/ rfc3454>。

[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, DOI 10.17487/RFC3490, March 2003, <http://www.rfc-editor.org/info/rfc3490>.

[RFC3490] Faltstrom、P.、Hoffman、P。、およびA. Costello、「Internationalizing Domain Names in Applications（IDNA）」、RFC 3490、DOI 10.17487 / RFC3490、2003年3月、<http：//www.rfc-editor .org / info / rfc3490>。

[RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 3920, DOI 10.17487/RFC3920, October 2004, <http://www.rfc-editor.org/info/rfc3920>.

[RFC3920] Saint-Andre、P。、編、「Extensible Messaging and Presence Protocol（XMPP）：Core」、RFC 3920、DOI 10.17487 / RFC3920、2004年10月、<http://www.rfc-editor.org/ info / rfc3920>。

[RFC3921] Saint-Andre, P., Ed., "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence", RFC 3921, DOI 10.17487/RFC3921, October 2004, <http://www.rfc-editor.org/info/rfc3921>.

[RFC3921] Saint-Andre、P。、編、「Extensible Messaging and Presence Protocol（XMPP）：Instant Messaging and Presence」、RFC 3921、DOI 10.17487 / RFC3921、2004年10月、<http：//www.rfc-editor .org / info / rfc3921>。

[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987, January 2005, <http://www.rfc-editor.org/info/rfc3987>.

[RFC3987] Duerst、M。およびM. Suignard、「Internationalized Resource Identifiers（IRIs）」、RFC 3987、DOI 10.17487 / RFC3987、2005年1月、<http://www.rfc-editor.org/info/rfc3987>。

[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, DOI 10.17487/RFC4013, February 2005, <http://www.rfc-editor.org/info/rfc4013>.

[RFC4013] Zeilenga、K。、「SASLprep：Stringprep Profile for User Names and Passwords」、RFC 4013、DOI 10.17487 / RFC4013、2005年2月、<http://www.rfc-editor.org/info/rfc4013>。

[RFC4422] Melnikov, A., Ed., and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, DOI 10.17487/RFC4422, June 2006, <http://www.rfc-editor.org/info/rfc4422>.

[RFC4422] Melnikov、A.、Ed。およびK. Zeilenga、Ed。、 "Simple Authentication and Security Layer（SASL）"、RFC 4422、DOI 10.17487 / RFC4422、June 2006、<http：//www.rfc- editor.org/info/rfc4422>。

[RFC5122] Saint-Andre, P., "Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP)", RFC 5122, DOI 10.17487/RFC5122, February 2008, <http://www.rfc-editor.org/info/rfc5122>.

[RFC5122] Saint-Andre、P。、「Extensible Messaging and Presence Protocol（XMPP）の国際化リソース識別子（IRI）およびUniform Resource Identifiers（URIs）」、RFC 5122、DOI 10.17487 / RFC5122、2008年2月、<http： //www.rfc-editor.org/info/rfc5122>。

[RFC5895] Resnick, P. and P. Hoffman, "Mapping Characters for Internationalized Domain Names in Applications (IDNA) 2008", RFC 5895, DOI 10.17487/RFC5895, September 2010, <http://www.rfc-editor.org/info/rfc5895>.

[RFC5895] Resnick、P。およびP. Hoffman、「アプリケーションの国際化ドメイン名のマッピング文字（IDNA）2008」、RFC 5895、DOI 10.17487 / RFC5895、2010年9月、<http://www.rfc-editor.org / info / rfc5895>。

[RFC6121] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence", RFC 6121, DOI 10.17487/RFC6121, March 2011, <http://www.rfc-editor.org/info/rfc6121>.

[RFC6121] Saint-Andre、P。、「Extensible Messaging and Presence Protocol（XMPP）：Instant Messaging and Presence」、RFC 6121、DOI 10.17487 / RFC6121、2011年3月、<http://www.rfc-editor.org/ info / rfc6121>。

[RFC6122] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Address Format", RFC 6122, DOI 10.17487/RFC6122, March 2011, <http://www.rfc-editor.org/info/rfc6122>.

[RFC6122] Saint-Andre、P。、「Extensible Messaging and Presence Protocol（XMPP）：Address Format」、RFC 6122、DOI 10.17487 / RFC6122、2011年3月、<http://www.rfc-editor.org/info/ rfc6122>。

[RFC6885] Blanchet, M. and A. Sullivan, "Stringprep Revision and Problem Statement for the Preparation and Comparison of Internationalized Strings (PRECIS)", RFC 6885, DOI 10.17487/RFC6885, March 2013, <http://www.rfc-editor.org/info/rfc6885>.

[RFC6885] Blanchet、M。およびA. Sullivan、「国際化された文字列（PRECIS）の準備と比較のためのStringprepの改訂と問題の説明」、RFC 6885、DOI 10.17487 / RFC6885、2013年3月、<http：//www.rfc -editor.org/info/rfc6885>。

[UTS39] Unicode Technical Standard #39, "Unicode Security Mechanisms", edited by Mark Davis and Michel Suignard, <http://unicode.org/reports/tr39/>.

[UTS39] Unicode技術標準＃39、「Unicode Security Mechanisms」、Mark DavisおよびMichel Suignardにより編集、<http://unicode.org/reports/tr39/>。

[XEP-0004] Eatmon, R., Hildebrand, J., Miller, J., Muldowney, T., and P. Saint-Andre, "Data Forms", XSF XEP 0004, August 2007, <http://xmpp.org/extensions/xep-0004.html>.

[XEP-0004] Eatmon、R.、Hildebrand、J.、Miller、J.、Muldowney、T。、およびP. Saint-Andre、「Data Forms」、XSF XEP 0004、2007年8月、<http：// xmpp .org / extensions / xep-0004.html>。

[XEP-0016] Millard, P. and P. Saint-Andre, "Privacy Lists", XSF XEP 0016, February 2007, <http://xmpp.org/extensions/xep-0016.html>.

[XEP-0016] Millard、P。およびP. Saint-Andre、「プライバシーリスト」、XSF XEP 0016、2007年2月、<http://xmpp.org/extensions/xep-0016.html>。

[XEP-0029] Kaes, C., "Definition of Jabber Identifiers (JIDs)", XSF XEP 0029, October 2003, <http://xmpp.org/extensions/xep-0029.html>.

[XEP-0029] Kaes、C。、「Definition of Jabber Identifiers（JIDs）」、XSF XEP 0029、2003年10月、<http://xmpp.org/extensions/xep-0029.html>。

[XEP-0030] Hildebrand, J., Millard, P., Eatmon, R., and P. Saint-Andre, "Service Discovery", XSF XEP 0030, June 2008, <http://xmpp.org/extensions/xep-0030.html>.

[XEP-0030] Hildebrand、J.、Millard、P.、Eatmon、R。、およびP. Saint-Andre、「Service Discovery」、XSF XEP 0030、2008年6月、<http://xmpp.org/extensions/ xep-0030.html>。

[XEP-0045] Saint-Andre, P., "Multi-User Chat", XSF XEP 0045, February 2012, <http://xmpp.org/extensions/xep-0045.html>.

[XEP-0045] Saint-Andre、P。、「マルチユーザーチャット」、XSF XEP 0045、2012年2月、<http://xmpp.org/extensions/xep-0045.html>。

[XEP-0048] Blackman, R., Millard, P., and P. Saint-Andre, "Bookmarks", XSF XEP 0048, November 2007, <http://xmpp.org/extensions/xep-0048.html>.

[XEP-0048] Blackman、R.、Millard、P。、およびP. Saint-Andre、「ブックマーク」、XSF XEP 0048、2007年11月、<http://xmpp.org/extensions/xep-0048.html> 。

[XEP-0054] Saint-Andre, P., "vcard-temp", XSF XEP 0054, July 2008, <http://xmpp.org/extensions/xep-0054.html>.

[XEP-0054] Saint-Andre、P。、「vcard-temp」、XSF XEP 0054、2008年7月、<http://xmpp.org/extensions/xep-0054.html>。

[XEP-0060] Millard, P., Saint-Andre, P., and R. Meijer, "Publish-Subscribe", XSF XEP 0060, July 2010, <http://xmpp.org/extensions/xep-0060.html>.

[XEP-0060] Millard、P.、Saint-Andre、P。、およびR. Meijer、「Publish-Subscribe」、XSF XEP 0060、2010年7月、<http://xmpp.org/extensions/xep-0060。 html>。

[XEP-0065] Smith, D., Miller, M., Saint-Andre, P., and J. Karneges, "SOCKS5 Bytestreams", XSF XEP 0065, April 2011, <http://xmpp.org/extensions/xep-0065.html>.

[XEP-0065] Smith、D.、Miller、M.、Saint-Andre、P。、およびJ. Karneges、「SOCKS5 Bytestreams」、XSF XEP 0065、2011年4月、<http://xmpp.org/extensions/ xep-0065.html>。

[XEP-0077] Saint-Andre, P., "In-Band Registration", XSF XEP 0077, January 2012, <http://xmpp.org/extensions/xep-0077.html>.

[XEP-0077] Saint-Andre、P。、「インバンド登録」、XSF XEP 0077、2012年1月、<http://xmpp.org/extensions/xep-0077.html>。

[XEP-0106] Hildebrand, J. and P. Saint-Andre, "JID Escaping", XSF XEP 0106, June 2007, <http://xmpp.org/extensions/xep-0106.html>.

[XEP-0106] Hildebrand、J。およびP. Saint-Andre、「JID Escaping」、XSF XEP 0106、2007年6月、<http://xmpp.org/extensions/xep-0106.html>。

[XEP-0114] Saint-Andre, P., "Jabber Component Protocol", XSF XEP 0114, January 2012, <http://xmpp.org/extensions/xep-0114.html>.

[XEP-0114] Saint-Andre、P。、「Jabber Component Protocol」、XSF XEP 0114、2012年1月、<http://xmpp.org/extensions/xep-0114.html>。

[XEP-0144] Saint-Andre, P., "Roster Item Exchange", XSF XEP 0144, August 2005, <http://xmpp.org/extensions/xep-0144.html>.

[XEP-0144] Saint-Andre、P。、「Roster Item Exchange」、XSF XEP 0144、2005年8月、<http://xmpp.org/extensions/xep-0144.html>。

[XEP-0166] Ludwig, S., Beda, J., Saint-Andre, P., McQueen, R., Egan, S., and J. Hildebrand, "Jingle", XSF XEP 0166, December 2009, <http://xmpp.org/extensions/xep-0166.html>.

[XEP-0166]ルートヴィヒ、S、ベダ、J、セントアンドレ、P、マックイーン、R、イーガン、S、およびJヒルデブランド、「ジングル」、XSF XEP 0166、2009年12月、<http ：//xmpp.org/extensions/xep-0166.html>。

[XEP-0191] Saint-Andre, P., "Blocking Command", XSF XEP 0191, July 2012, <http://xmpp.org/extensions/xep-0191.html>.

[XEP-0191] Saint-Andre、P。、「Blocking Command」、XSF XEP 0191、2012年7月、<http://xmpp.org/extensions/xep-0191.html>。

[XEP-0203] Saint-Andre, P., "Delayed Delivery", XSF XEP 0203, September 2009, <http://xmpp.org/extensions/xep-0203.html>.

[XEP-0203] Saint-Andre、P。、「遅延配信」、XSF XEP 0203、2009年9月、<http://xmpp.org/extensions/xep-0203.html>。

[XEP-0220] Miller, J., Saint-Andre, P., and P. Hancke, "Server Dialback", XSF XEP 0220, August 2014, <http://xmpp.org/extensions/xep-0220.html>.

[XEP-0220] Miller、J.、Saint-Andre、P。、およびP. Hancke、「Server Dialback」、XSF XEP 0220、2014年8月、<http://xmpp.org/extensions/xep-0220.html >。

[XEP-0292] Saint-Andre, P. and S. Mizzi, "vCard4 Over XMPP", XSF XEP 0292, September 2013, <http://xmpp.org/extensions/xep-0292.html>.

[XEP-0292] Saint-Andre、P。およびS. Mizzi、「vCard4 Over XMPP」、XSF XEP 0292、2013年9月、<http://xmpp.org/extensions/xep-0292.html>。

[XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", World Wide Web Consortium Recommendation REC-xml-20081126, November 2008, <http://www.w3.org/TR/2008/REC-xml-20081126>.

[XML] Bray、T.、Paoli、J.、Sperberg-McQueen、C.、Maler、E。、およびF. Yergeau、「Extensible Markup Language（XML）1.0（Fifth Edition）」、World Wide Web Consortium Recommendation REC -xml-20081126、2008年11月、<http://www.w3.org/TR/2008/REC-xml-20081126>。

Appendix A. Differences from RFC 6122

付録A. RFC 6122との違い

Based on consensus derived from working group discussion, implementation and deployment experience, and formal interoperability testing, the following substantive modifications were made from RFC 6122.

ワーキンググループディスカッション、実装と展開の経験、および正式な相互運用性テストから導き出された合意に基づいて、RFC 6122から次の実質的な変更が行われました。

o Changed domainpart preparation to use IDNA2008 (instead of IDNA2003).

o （IDNA2003の代わりに）IDNA2008を使用するようにドメインパートの準備を変更しました。

o Changed localpart preparation to use the UsernameCaseMapped profile of the PRECIS IdentifierClass (instead of the Nodeprep profile of stringprep).

o （stringprepのNodeprepプロファイルの代わりに）PRECIS IdentifierClassのUsernameCaseMappedプロファイルを使用するようにローカルパーツの準備を変更しました。

o Changed resourcepart preparation to use the OpaqueString profile of the PRECIS FreeformClass (instead of the Resourceprep profile of stringprep).

o （stringprepのResourceprepプロファイルの代わりに）PRECIS FreeformClassのOpaqueStringプロファイルを使用するようにresourcepartの準備を変更しました。

o Specified that internationalized labels within domainparts must be U-labels (instead of "should be" U-labels).

o domainparts内の国際化されたラベルはUラベルでなければならないことを指定（「すべき」Uラベルではなく）。

o Specified that fullwidth and halfwidth characters must be mapped to their decomposition mappings (previously handled through the use of Normalization Form KC).

o 全角文字と半角文字を分解マッピングにマッピングする必要があることを指定しました（以前は正規化フォームKCを使用して処理されていました）。

o Specified the use of Unicode Normalization Form C (instead of Unicode Normalization Form KC as specified in the Nodeprep and Resourceprep profiles of stringprep).

o Unicode正規化フォームCの使用を指定しました（stringprepのNodeprepおよびResourceprepプロファイルで指定されているUnicode正規化フォームKCの代わり）。

o Specified that servers must enforce the address-formatting rules.

o サーバーがアドレスフォーマット規則を適用する必要があることを指定しました。

Acknowledgements

謝辞

Thanks to Ben Campbell, Dave Cridland, Miguel Garcia, Joe Hildebrand, Jonathan Lennox, Matt Miller, Florian Schmaus, Sam Whited, and Florian Zeitz for their input during working group discussion.

ワーキンググループディスカッションでの意見を提供してくれたBen Campbell、Dave Cridland、Miguel Garcia、Joe Hildebrand、Jonathan Lennox、Matt Miller、Florian Schmaus、Sam Whited、Florian Zeitzに感謝します。

Dan Romascanu completed a helpful review on behalf of the General Area Review Team.

Dan RomascanuがGeneral Area Review Teamに代わって役立つレビューを完了しました。

During IESG review, Alissa Cooper, Brian Haberman, and Barry Leiba provided comments that led to improvements in the document.

IESGのレビュー中に、アリッサクーパー、ブライアンハーバーマン、バリーレイバは、ドキュメントの改善につながるコメントを提供しました。

Thanks also to Matt Miller in his role as document shepherd, Joe Hildebrand in his role as working group chair, and Ben Campbell in his role as sponsoring Area Director.

ドキュメントシェパードとしての役割を果たしたマットミラー、ワーキンググループチェアとしての役割を果たしたジョーヒルデブランド、およびエリアディレクターのスポンサーとしての役割を果たしたベンキャンベルにも感謝します。

The author wishes to acknowledge Cisco Systems, Inc., for employing him during his work on earlier draft versions of this document.

著者は、このドキュメントの以前のドラフトバージョンでの作業中に彼を採用したCisco Systems、Inc.を認めたいと思います。

Author's Address

著者のアドレス

Peter Saint-Andre &yet

ピーターサンタンドレ＆まだ

   Email: peter@andyet.com
   URI:   https://andyet.com/