[要約] RFC 7247は、SIPとXMPP間の相互運用性に関するアーキテクチャ、アドレス、エラーハンドリングについてのガイドラインです。このRFCの目的は、SIPとXMPPの間でのメッセージングとプレゼンス情報の交換を容易にするための標準化を提供することです。
Internet Engineering Task Force (IETF) P. Saint-Andre
Request for Comments: 7247 &yet
Category: Standards Track A. Houri
ISSN: 2070-1721 IBM
J. Hildebrand
Cisco Systems, Inc.
May 2014
Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Architecture, Addresses, and Error Handling
Session Initiation Protocol（SIP）とExtensible Messaging and Presence Protocol（XMPP）間のインターワーキング：アーキテクチャ、アドレス、およびエラー処理
Abstract
概要
As a foundation for the definition of bidirectional protocol mappings between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP), this document specifies the architectural assumptions underlying such mappings as well as the mapping of addresses and error conditions.
このドキュメントでは、Session Initiation Protocol（SIP）とExtensible Messaging and Presence Protocol（XMPP）の間の双方向プロトコルマッピングを定義するための基礎として、このようなマッピングの基礎となるアーキテクチャの前提と、アドレスおよびエラー条件のマッピングを指定します。
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/rfc7247.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7247で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 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. 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 ....................................................3
2. Intended Audience ...............................................3
3. Terminology .....................................................4
4. Architectural Assumptions .......................................4
5. Interdomain Federation ..........................................6
6. Address Mapping .................................................7
6.1. Overview ...................................................7
6.2. Local Part Mapping .........................................9
6.3. Instance-Specific Mapping .................................11
6.4. SIP to XMPP ...............................................11
6.5. XMPP to SIP ...............................................12
7. Error Mapping ..................................................14
7.1. XMPP to SIP ...............................................15
7.2. SIP to XMPP ...............................................17
8. Security Considerations ........................................20
9. References .....................................................21
9.1. Normative References ......................................21
9.2. Informative References ....................................22
Appendix A. Acknowledgements ......................................24
The IETF has worked on two signaling technologies that can be used for multimedia session negotiation, instant messaging, presence, capabilities discovery, notifications, and other functions served by real-time communication applications:
IETFは、マルチメディアセッションネゴシエーション、インスタントメッセージング、プレゼンス、機能検出、通知、およびリアルタイム通信アプリケーションによって提供されるその他の機能に使用できる2つのシグナリングテクノロジーに取り組んできました。
o The Session Initiation Protocol [RFC3261], along with various SIP extensions developed within the SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE) Working Group.
o セッション開始プロトコル[RFC3261]と、インスタントメッセージングおよびプレゼンスレバレッジ拡張（SIMPLE）ワーキンググループのSIP内で開発されたさまざまなSIP拡張。
o The Extensible Messaging and Presence Protocol [RFC6120], along with various XMPP extensions developed by the IETF as well as by the XMPP Standards Foundation (XSF).
o 拡張メッセージングおよびプレゼンスプロトコル[RFC6120]と、IETFおよびXMPP標準財団（XSF）によって開発されたさまざまなXMPP拡張機能。
Because these technologies are widely deployed, it is important to clearly define mappings between them for the sake of interworking. This document provides the basis for a series of SIP-XMPP interworking specifications by defining architectural assumptions, address translation methods, and error condition mappings. Other documents in this series define mappings for presence, messaging, and media sessions.
これらのテクノロジーは広く導入されているため、相互運用のために、テクノロジー間のマッピングを明確に定義することが重要です。このドキュメントは、アーキテクチャの前提、アドレス変換方法、およびエラー条件マッピングを定義することにより、一連のSIP-XMPPインターワーキング仕様の基礎を提供します。このシリーズの他のドキュメントでは、プレゼンス、メッセージング、およびメディアセッションのマッピングを定義しています。
The guidelines in this series are based on implementation and deployment experience, and they describe techniques that have worked well in the field with existing systems. In practice, interworking has been achieved through direct protocol mappings, not through mapping to an abstract model as described in, for example, [RFC3859] and [RFC3860]. Therefore, this series describes the direct mapping approach in enough detail for developers of new implementations to achieve practical interworking between SIP systems and XMPP systems.
このシリーズのガイドラインは、実装と展開の経験に基づいており、既存のシステムを使用して現場でうまく機能したテクニックについて説明しています。実際には、インターワーキングは、たとえば[RFC3859]や[RFC3860]で説明されているような抽象モデルへのマッピングではなく、直接プロトコルマッピングによって実現されています。したがって、このシリーズでは、新しい実装の開発者がSIPシステムとXMPPシステムの間の実用的なインターワーキングを実現するために、直接マッピングアプローチを十分に詳しく説明します。
The documents in this series are intended for use by software developers who have an existing system based on one of these technologies (e.g., SIP) and would like to enable communication from that existing system to systems based on the other technology (e.g., XMPP). With regard to this document, we assume that readers are familiar with the core specifications for both SIP and XMPP; with regard to the other documents in this series, we assume that readers are familiar with this document as well as with the relevant SIP and XMPP extensions.
このシリーズのドキュメントは、これらのテクノロジーの1つ（SIPなど）に基づく既存のシステムがあり、その既存のシステムから他のテクノロジー（XMPPなど）に基づくシステムへの通信を可能にするソフトウェア開発者による使用を目的としています。 。このドキュメントに関しては、読者がSIPとXMPPの両方のコア仕様に精通していることを前提としています。このシリーズの他のドキュメントに関しては、読者がこのドキュメントと、関連するSIPおよびXMPP拡張機能に精通していることを前提としています。
A number of terms used here are explained in [RFC3261] and [RFC6120].
ここで使用されるいくつかの用語は、[RFC3261]と[RFC6120]で説明されています。
Several examples use the "XML Notation" from the Internationalized Resource Identifier (IRI) specification [RFC3987] to represent Unicode characters outside the ASCII range (e.g., the string "ue" stands for the Unicode character [UNICODE] LATIN SMALL LETTER U WITH DIAERESIS, U+00FC).
いくつかの例では、国際化リソース識別子（IRI）仕様[RFC3987]の「XML表記」を使用して、ASCII範囲外のUnicode文字を表します（たとえば、文字列 "ue"はUnicode文字を表します[UNICODE]ラテン小文字Uダイアレシズ付き、U + 00FC）。
In architectural diagrams, SIP traffic is shown using arrows such as
"***>", whereas XMPP traffic is shown using arrows such as "...>".
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]で説明されているように解釈されます。
Protocol translation between SIP and XMPP could occur in a number of different entities, depending on the architecture of real-time communication deployments. For example, protocol translation could occur within a multiprotocol server (which uses protocol-specific connection managers to initiate traffic to and accept traffic from clients or other servers natively using SIP/SIMPLE, XMPP, etc.), within a multiprotocol client (which enables a user to establish connections natively with various servers using SIP/SIMPLE, XMPP, etc.), or within a gateway that acts as a dedicated protocol translator (which takes one protocol as input and provides another protocol as output).
SIPとXMPP間のプロトコル変換は、リアルタイム通信展開のアーキテクチャに応じて、さまざまなエンティティで発生する可能性があります。たとえば、プロトコル変換はマルチプロトコルサーバー（プロトコル固有の接続マネージャーを使用して、SIP / SIMPLE、XMPPなどをネイティブに使用してクライアントまたは他のサーバーへのトラフィックを開始および受信する）内で、マルチプロトコルクライアント（これにより、 SIP / SIMPLE、XMPPなどを使用してさまざまなサーバーとネイティブに接続を確立するユーザー）、または専用プロトコルトランスレーターとして機能するゲートウェイ内で（1つのプロトコルを入力として使用し、別のプロトコルを出力として提供する）。
This document assumes that the protocol translation will occur within a gateway, specifically:
このドキュメントでは、プロトコル変換がゲートウェイ内で発生することを前提としています。具体的には次のとおりです。
o When information needs to flow from an XMPP-based system to a SIP-based system, protocol translation will occur within an "XMPP-to-SIP gateway" that translates XMPP syntax and semantics on behalf of an "XMPP server" (together, these two logical functions comprise an "XMPP service").
o XMPPベースのシステムからSIPベースのシステムに情報を流す必要がある場合、「XMPPサーバー」に代わってXMPP構文とセマンティクスを変換する「XMPPからSIPゲートウェイ」内でプロトコル変換が行われます（まとめて、これら2つの論理機能が「XMPPサービス」を構成します。
o When information needs to flow from a SIP-based system to an XMPP-based system, protocol translation will occur within a "SIP-to-XMPP gateway" that translates SIP syntax and semantics on behalf of a "SIP server" (together, these two logical functions comprise a "SIP service").
o 情報がSIPベースのシステムからXMPPベースのシステムに流れる必要がある場合、「SIPサーバー」に代わってSIP構文とセマンティクスを変換する「SIP-to-XMPPゲートウェイ」内でプロトコル変換が発生します（まとめて、これら2つの論理機能が「SIPサービス」を構成します）。
Naturally, these logical functions could occur in one and the same actual entity; we differentiate between them mainly for explanatory purposes (although, in practice, such gateways are indeed fairly common).
当然のことながら、これらの論理機能は1つの同じ実体で発生する可能性があります。主に説明のためにこれらを区別します（実際には、そのようなゲートウェイは実際にかなり一般的ですが）。
Note: This assumption is not meant to discourage protocol translation within multiprotocol clients or servers; instead, this assumption is followed mainly to clarify the discussion and examples so that the protocol translation principles can be more easily understood and can be applied by client and server implementors with appropriate modifications to the examples and terminology.
注：この想定は、マルチプロトコルクライアントまたはサーバー内でのプロトコル変換を妨げることを意図したものではありません。代わりに、この仮定は主に説明と例を明確にするために使用されるため、プロトコル変換の原則はより簡単に理解でき、例と用語に適切な変更を加えてクライアントとサーバーの実装者が適用できます。
This document assumes that a gateway will translate directly from one protocol to the other. For the sake of the examples, we further assume that protocol translation will occur within a gateway in the source domain, so that information generated by the user of an XMPP system will be translated by a gateway within the trust domain of that XMPP system, and information generated by the user of a SIP system will be translated by a gateway within the trust domain of that SIP system. However, nothing in this document ought to be taken as recommending against protocol translation at the destination domain.
このドキュメントでは、ゲートウェイが1つのプロトコルから別のプロトコルに直接変換することを想定しています。例として、XMPPシステムのユーザーによって生成された情報がそのXMPPシステムの信頼ドメイン内のゲートウェイによって変換されるように、ソースドメインのゲートウェイ内でプロトコル変換が行われるとさらに想定します。 SIPシステムのユーザーによって生成された情報は、そのSIPシステムの信頼ドメイン内のゲートウェイによって変換されます。ただし、このドキュメントでは、宛先ドメインでのプロトコル変換を推奨しないと解釈されるべきではありません。
An architectural diagram for a possible gateway deployment is shown below, where the entities have the following significance and the "#" character is used to show the boundary of a trust domain:
可能なゲートウェイ配置のアーキテクチャ図を以下に示します。エンティティには次の意味があり、「＃」文字は信頼ドメインの境界を示すために使用されます。
o romeo@example.net -- a SIP user.
o romeo@example.net-SIPユーザー。
o example.net -- a SIP server with an associated gateway ("S2X GW") to XMPP.
o example.net-XMPPへのゲートウェイ（ "S2X GW"）が関連付けられたSIPサーバー。
o juliet@example.com -- an XMPP user.
o juliet@example.com-XMPPユーザー。
o example.com -- an XMPP server with an associated gateway ("X2S GW") to SIP.
o example.com-SIPへのゲートウェイ（「X2S GW」）が関連付けられたXMPPサーバー。
#########################################################
# #
# +-----+ #
# | S2X | #
# +-------------+ GW |<...........>+-------------+ #
# | SIP Server +-----+ | XMPP Server | #
# | example.net | +-----+ example.com | #
# +-------------+<***********>| X2S +-------------+ #
# * | GW | : #
# * +-----+ : #
# * : #
# romeo@example.net juliet@example.com #
# #
#########################################################
Legend:
XMPP = ... or :
SIP = *
Figure 1: Possible Gateway Deployment Architecture
図1：可能なゲートウェイ配置アーキテクチャ
Note that bidirectional communication between the SIP server and the XMPP server can be established over either SIP or XMPP. If the XMPP user initiates the interaction, then the XMPP server would invoke its XMPP-to-SIP gateway; thus, the communication would occur over SIP. If the SIP user initiates the interaction, then the SIP server would invoke its SIP-to-XMPP gateway; thus, the communication would occur over XMPP.
SIPサーバーとXMPPサーバー間の双方向通信は、SIPまたはXMPPを介して確立できることに注意してください。 XMPPユーザーが対話を開始すると、XMPPサーバーはXMPP-to-SIPゲートウェイを呼び出します。したがって、通信はSIPを介して行われます。 SIPユーザーが対話を開始した場合、SIPサーバーはSIP-to-XMPPゲートウェイを呼び出します。したがって、通信はXMPPを介して行われます。
The architectural assumptions underlying this document imply that communication between a SIP system and an XMPP system will take place using interdomain federation: the SIP server invokes its associated SIP-to-XMPP gateway, which communicates with the XMPP server using native XMPP server-to-server methods; similarly, the XMPP server invokes its associated XMPP-to-SIP gateway, which communicates with the SIP server using native SIP server-to-server methods.
このドキュメントの基礎となるアーキテクチャの前提は、SIPシステムとXMPPシステムの間の通信がドメイン間フェデレーションを使用して行われることを意味します。SIPサーバーは、関連するSIP-to-XMPPゲートウェイを呼び出します。サーバーメソッド。同様に、XMPPサーバーは、関連するXMPP-to-SIPゲートウェイを呼び出します。ゲートウェイは、ネイティブのSIPサーバー間メソッドを使用してSIPサーバーと通信します。
When an XMPP server receives an XMPP stanza whose 'to' address specifies or includes a domain other than the domain of the XMPP server, it needs to determine whether the destination domain communicates via XMPP or SIP. To do so, it performs one or more DNS SRV lookups [RFC2782] for "_xmpp-server" records as specified in [RFC6120]. If the response returns a hostname, the XMPP server can attempt XMPP communication. If not, it can determine the appropriate location for SIP communication at the target domain using the procedures specified in [RFC3263].
XMPPサーバーは、「宛先」アドレスがXMPPサーバーのドメイン以外のドメインを指定または含むXMPPスタンザを受信すると、宛先ドメインがXMPPまたはSIPのどちらを介して通信するかを決定する必要があります。これを行うには、[RFC6120]で指定されている「_xmpp-server」レコードに対して1つ以上のDNS SRVルックアップ[RFC2782]を実行します。応答がホスト名を返す場合、XMPPサーバーはXMPP通信を試行できます。そうでない場合、[RFC3263]で指定された手順を使用して、ターゲットドメインでのSIP通信の適切な場所を決定できます。
Similarly, when a SIP server receives a SIP message whose Request-URI or To header specifies or includes a domain other than the domain of the SIP server, it needs to determine whether the destination domain communicates via SIP or XMPP. To do so, it uses the procedures specified in [RFC3263]. If that response returns a hostname, the SIP server can attempt SIP communication. If not, it can perform one or more DNS SRV lookups [RFC2782] for "_xmpp-server" records as specified in [RFC6120].
同様に、SIPサーバーは、Request-URIまたはToヘッダーがSIPサーバーのドメイン以外のドメインを指定または含むSIPメッセージを受信すると、宛先ドメインがSIPとXMPPのどちらを介して通信するかを決定する必要があります。これを行うには、[RFC3263]で指定された手順を使用します。その応答がホスト名を返す場合、SIPサーバーはSIP通信を試行できます。そうでない場合、[RFC6120]で指定されている「_xmpp-server」レコードに対して1つ以上のDNS SRVルックアップ[RFC2782]を実行できます。
In both cases, the server in question might have previously determined that the foreign domain communicates via SIP or XMPP, in which case it would not need to perform the relevant DNS lookups. The caching of such information is a matter of implementation and local service policy and is therefore out of scope for this document.
どちらの場合も、問題のサーバーは以前に外部ドメインがSIPまたはXMPPを介して通信することを決定している可能性があります。その場合、関連するDNSルックアップを実行する必要はありません。このような情報のキャッシュは実装とローカルサービスポリシーの問題であるため、このドキュメントの範囲外です。
Existing SIP and XMPP server implementations do not typically include the ability to communicate using the other technology (XMPP for SIP implementations, SIP for XMPP implementations). One common architectural pattern is to associate a gateway with the core server implementation (e.g., in XMPP such a gateway might be called a "connection manager"). How exactly such a gateway interacts with the core server to complete tasks such as address lookups and communication with systems that use the other technology is a matter of implementation (e.g., the gateway might be an add-on module that is trusted by the core server to act as a fallback delivery mechanism if the remote domain does not support the server's native communication technology).
既存のSIPおよびXMPPサーバーの実装には、通常、他のテクノロジ（XMPP for SIP実装、SIP for XMPP実装）を使用して通信する機能は含まれていません。一般的なアーキテクチャパターンの1つは、ゲートウェイをコアサーバーの実装に関連付けることです（たとえば、XMPPでは、このようなゲートウェイは「接続マネージャー」と呼ばれる場合があります）。このようなゲートウェイがコアサーバーと対話して、アドレスルックアップや他のテクノロジーを使用するシステムとの通信などのタスクを実行する方法は、実装の問題です（たとえば、ゲートウェイはコアサーバーによって信頼されるアドオンモジュールである場合があります）リモートドメインがサーバーのネイティブ通信技術をサポートしていない場合に、フォールバック配信メカニズムとして機能します）。
Because [RFC6120] specifies a binding of XMPP to TCP, a gateway from SIP to XMPP will need to support TCP as the underlying transport protocol. By contrast, as specified in [RFC3261], either TCP or UDP can be used as the underlying transport for SIP messages, and a given SIP deployment might support only UDP; therefore, a gateway from XMPP to SIP might need to communicate with a SIP server using either TCP or UDP.
[RFC6120]はXMPPからTCPへのバインディングを指定しているため、SIPからXMPPへのゲートウェイは、基になるトランスポートプロトコルとしてTCPをサポートする必要があります。対照的に、[RFC3261]で指定されているように、TCPまたはUDPはSIPメッセージの基礎となるトランスポートとして使用でき、特定のSIPデプロイメントはUDPのみをサポートする場合があります。したがって、XMPPからSIPへのゲートウェイは、TCPまたはUDPを使用してSIPサーバーと通信する必要がある場合があります。
The basic SIP address format is a 'sip' or 'sips' URI as specified in [RFC3261]. When a SIP entity supports extensions for instant messaging it might be identified by an 'im' URI as specified in the Common Profile for Instant Messaging [RFC3860] (see [RFC3428]), and when a SIP entity supports extensions for presence it might be identified by a 'pres' URI as specified in the Common Profile for Presence [RFC3859] (see [RFC3856]). SIP entities typically also support the 'tel' URI scheme [RFC3966] and might support other URI schemes as well.
基本的なSIPアドレス形式は、[RFC3261]で指定されている「sip」または「sips」URIです。 SIPエンティティがインスタントメッセージングの拡張機能をサポートしている場合、インスタントメッセージングの共通プロファイル[RFC3860]（[RFC3428]を参照）で指定されている「im」URIで識別される場合があり、SIPエンティティがプレゼンスの拡張機能をサポートしている場合は、プレゼンスの共通プロファイル[RFC3859]（[RFC3856]を参照）で指定されている「pres」URIで識別されます。 SIPエンティティは通常、「tel」URIスキーム[RFC3966]もサポートし、他のURIスキームもサポートする場合があります。
The XMPP address format is specified in [RFC6122] (although note that XMPP URIs [RFC5122] are not used natively on the XMPP network); in addition, [RFC6121] encourages instant messaging and presence applications of XMPP to also support 'im' and 'pres' URIs as specified in [RFC3860] and [RFC3859], respectively, although such support might simply involve leaving resolution of such addresses up to an XMPP server.
XMPPアドレス形式は[RFC6122]で指定されています（ただし、XMPP URI [RFC5122]はXMPPネットワークでネイティブに使用されないことに注意してください）。さらに、[RFC6121]は、XMPPのインスタントメッセージングおよびプレゼンスアプリケーションが、それぞれ[RFC3860]および[RFC3859]で指定されている「im」および「pres」URIもサポートすることを奨励します。 XMPPサーバーに。
In this document we primarily describe mappings for addresses of the form <user@domain>; however, we also provide guidelines for mapping the addresses of specific user agent instances, which take the form of Globally Routable User Agent URIs (GRUUs) in SIP and "resourceparts" in XMPP. Mapping of protocol-specific identifiers (such as telephone numbers) is out of scope for this specification. In addition, we have ruled the mapping of domain names as out of scope for now, since that is a matter for the Domain Name System; specifically, the issue for interworking between SIP and XMPP relates to the translation of fully internationalized domain names (IDNs) into non-internationalized domain names (IDNs are not allowed in the SIP address format but are allowed in the XMPP address via Internationalized Domain Names in Applications; see [RFC6122] and [XMPP-ADDRESS-FORMAT]). Therefore, in the following sections we focus primarily on the local part of an address (these are called variously "usernames", "instant inboxes", "presentities", and "localparts" in the protocols at issue), secondarily on the instance-specific part of an address, and not at all on the domain-name part of an address.
このドキュメントでは、主に<user @ domain>という形式のアドレスのマッピングについて説明します。ただし、特定のユーザーエージェントインスタンスのアドレスをマッピングするためのガイドラインも提供します。これは、SIPではグローバルにルーティング可能なユーザーエージェントURI（GRUU）、XMPPでは「リソースパーツ」の形式をとります。プロトコル固有の識別子（電話番号など）のマッピングは、この仕様の範囲外です。また、ドメインネームシステムの問題であるため、ドメイン名のマッピングは現在のところ対象外としています。特に、SIPとXMPP間のインターワーキングの問題は、完全に国際化されたドメイン名（IDN）から非国際化ドメイン名への変換に関連しています（IDNはSIPアドレス形式では許可されていませんが、XMPPアドレスでは国際化ドメイン名を介して許可されていますアプリケーション。[RFC6122]および[XMPP-ADDRESS-FORMAT]を参照してください）。したがって、次のセクションでは、主にアドレスのローカル部分に焦点を当てます（これらは、問題のプロトコルではさまざまに「ユーザー名」、「インスタント受信トレイ」、「プレゼンティティ」、および「localparts」と呼ばれます）。アドレスのドメイン名部分ではなく、アドレスの特定の部分。
The 'sip'/'sips', 'im'/'pres', and XMPP address schemes allow different sets of characters (although all three allow alphanumeric characters and disallow both spaces and control characters). In some cases, characters allowed in one scheme are disallowed in others; these characters need to be mapped appropriately in order to ensure interworking across systems.
「sip」/「sips」、「im」/「pres」、およびXMPPアドレススキームでは、異なる文字セットを使用できます（ただし、3つすべてで英数字を使用でき、スペースと制御文字の両方を使用できません）。場合によっては、1つのスキームで許可されている文字が他のスキームでは許可されないことがあります。これらの文字は、システム間の相互作用を保証するために適切にマッピングする必要があります。
The local part of a 'sip'/'sips' URI inherits from the "userinfo" rule in [RFC3986] with several changes; here we discuss the SIP "user" rule only (using ABNF as defined in [RFC5234]):
'sip' / 'sips' URIのローカル部分は、[RFC3986]の "userinfo"ルールから継承され、いくつかの変更が加えられています。ここでは、SIP「ユーザー」ルールのみについて説明します（[RFC5234]で定義されているABNFを使用）。
user = 1*( unreserved / escaped / user-unreserved )
user-unreserved = "&" / "=" / "+" / "$" / "," / ";" / "?" / "/"
unreserved = alphanum / mark
mark = "-" / "_" / "." / "!" / "~" / "*" / "'"
/ "(" / ")"
Here we make the simplifying assumption that the local part of an 'im'/'pres' URI inherits from the "dot-atom-text" rule in [RFC5322] rather than the more complicated "local-part" rule:
ここでは、 'im' / 'pres' URIのローカル部分は、より複雑な "local-part"ルールではなく、[RFC5322]の "dot-atom-text"ルールから継承すると簡単に仮定しています。
dot-atom-text = 1*atext *("." 1*atext)
atext = ALPHA / DIGIT / ; Any character except
"!" / "#" / "$" / ; controls, SP, and
"%" / "&" / "'" / ; specials. Used for
"*" / "+" / "-" / ; atoms.
"/" / "=" / "?" /
"^" / "_" / "`" /
"{" / "|" / "}" /
"~"
The local part of an XMPP address allows any ASCII character except space, controls, and the " & ' / : < > @ characters.
XMPPアドレスのローカル部分では、スペース、コントロール、および "＆ '/：<> @文字を除くすべてのASCII文字を使用できます。
To summarize the foregoing information, the following table lists the allowed and disallowed characters in the local part of identifiers for each protocol (aside from the alphanumeric, space, and control characters), in order by hexadecimal character number (where each "A" row shows the allowed characters and each "D" row shows the disallowed characters).
上記の情報を要約すると、次の表は、各プロトコルの識別子のローカル部分で許可されている文字と許可されていない文字の一覧です（英数字、スペース、および制御文字は除く）。は許可されている文字を示し、各「D」行は許可されていない文字を示しています）。
+---+----------------------------------+
| SIP/SIPS CHARACTERS |
+---+----------------------------------+
| A | ! $ &'()*+,-./ ; = ? _ ~ |
| D | "# % : < > @[\]^ `{|} |
+---+----------------------------------+
| IM/PRES CHARACTERS |
+---+----------------------------------+
| A | ! #$%&' *+ - / = ? ^_`{|}~ |
| D | " () , . :;< > @[\] |
+---+----------------------------------+
| XMPP CHARACTERS |
+---+----------------------------------+
| A | ! #$% ()*+,-. ; = ? [\]^_`{|}~ |
| D | " &' /: < > @ |
+---+----------------------------------+
Table 1: Allowed and Disallowed Characters
表1：使用できる文字と使用できない文字
When transforming the local part of an address from one address format to another, an application SHOULD proceed as follows:
アドレスのローカル部分をあるアドレス形式から別の形式に変換する場合、アプリケーションは次のように処理する必要があります（SHOULD）。
1. Unescape any escaped characters in the source address (e.g., from SIP to XMPP unescape "%23" to "#" per [RFC3986], and from XMPP to SIP unescape "\27" to "'" per [XEP-0106]).
1. 送信元アドレスのエスケープ文字をエスケープ解除します（たとえば、[RFC3986]ごとにSIPからXMPP unescape "％23"から "＃"、[XEP-0106]ごとにXMPPからSIP unescape "\ 27"から "'"へ）。 。
2. Leave unmodified any characters that are allowed in the destination scheme.
2. 宛先スキームで許可されている文字は変更しないでください。
3. Escape any characters that are allowed in the source scheme but reserved in the destination scheme, as escaping is defined for the destination scheme. In particular:
3. エスケープは宛先スキーマに対して定義されているため、ソーススキーマでは許可されているが宛先スキーマでは予約されている文字をエスケープします。特に：
* Where the destination scheme is a URI (i.e., an 'im', 'pres', 'sip', or 'sips' URI), each reserved character MUST be percent-encoded to "%hexhex" as specified in Section 2.5 of [RFC3986] (e.g., when transforming from XMPP to SIP, encode "#" as "%23").
* 宛先スキームがURI（つまり、「im」、「pres」、「sip」、または「sips」URI）の場合、各予約文字は、[のセクション2.5で指定されているように「％hexhex」にパーセントエンコードする必要があります。 RFC3986]（たとえば、XMPPからSIPに変換するときは、「＃」を「％23」としてエンコードします）。
* Where the destination scheme is a native XMPP address, each reserved character MUST be encoded to "\hexhex" as specified in [XEP-0106] (e.g., when transforming from SIP to XMPP, encode "'" as "\27").
* 宛先スキームがネイティブXMPPアドレスである場合、各予約文字は[XEP-0106]で指定されているように「\ hexhex」にエンコードする必要があります（たとえば、SIPからXMPPに変換する場合、「 '」を「\ 27」としてエンコードします）。
The meaning of a resourcepart in XMPP (i.e., the portion of a Jabber ID (JID) after the slash character, such as "foo" in "user@example.com/foo") matches that of a Globally Routable User Agent URI (GRUU) in SIP [RFC5627]. In both cases, these constructs identify a particular device associated with the bare JID ("localpart@domainpart") of an XMPP entity or with the Address of Record (AOR) of a SIP entity. Therefore, it is reasonable to map the value of a "gr" URI parameter to an XMPP resourcepart and vice versa.
XMPPのリソースパートの意味（つまり、「user@example.com/foo」の「foo」などのスラッシュ文字の後のJabber ID（JID）の部分）は、グローバルにルーティング可能なユーザーエージェントURI（ GRUU）SIP [RFC5627]。どちらの場合でも、これらの構成体は、XMPPエンティティのベアJID（ "localpart @ domainpart"）またはSIPエンティティのレコードのアドレス（AOR）に関連付けられた特定のデバイスを識別します。したがって、 "gr" URIパラメーターの値をXMPPリソースパーツに、またはその逆にマップすることは妥当です。
The mapping described here does not apply to temporary GRUUs -- only to GRUUs associated with an Address of Record.
ここで説明するマッピングは、一時的なGRUUには適用されません。レコードのアドレスに関連付けられたGRUUにのみ適用されます。
The "gr" URI parameter in SIP can contain only characters from the ASCII range (although characters outside the ASCII range can be percent-encoded in accordance with [RFC3986]), whereas an XMPP resourcepart can contain nearly any Unicode character [UNICODE]. Therefore, Unicode characters outside the ASCII range need to be mapped to characters in the ASCII range, as described below.
SIPの「gr」URIパラメーターには、ASCII範囲の文字のみを含めることができます（ただし、[ASCII範囲外の文字は[RFC3986]に従ってパーセントでエンコードできます）。一方、XMPPリソースパーツには、ほぼすべてのUnicode文字[UNICODE]を含めることができます。したがって、ASCII範囲外のUnicode文字は、以下で説明するように、ASCII範囲内の文字にマップする必要があります。
The following is a high-level algorithm for mapping a 'sip', 'sips', 'im', or 'pres' URI to an XMPP address:
以下は、「sip」、「sips」、「im」、または「pres」URIをXMPPアドレスにマッピングするための高レベルのアルゴリズムです。
1. Remove URI scheme.
1. URIスキームを削除します。
2. Split at the first '@' character into local part and hostname (mapping the latter is out of scope).
2. 最初の「@」文字をローカル部分とホスト名に分割します（後者のマッピングは範囲外です）。
3. Translate any percent-encoded strings ("%hexhex") to percent-decoded octets.
3. パーセントエンコードされた文字列（ "％hexhex"）をパーセントデコードされたオクテットに変換します。
4. Treat result as a UTF-8 string.
4. 結果をUTF-8文字列として扱います。
5. Translate "&" to "\26", "'" to "\27", and "/" to "\2f", respectively in order to properly handle the characters disallowed in XMPP addresses but allowed in 'sip'/'sips' URIs and 'im'/'pres' URIs as shown in Table 1 above (this is consistent with [XEP-0106]).
5. XMPPアドレスで許可されていないが、 'sip' / 'sipsでは許可されている文字を適切に処理するために、「＆」を「\ 26」、「'」を「\ 27」、「/」を「\ 2f」にそれぞれ変換します。上記の表1に示すように、 'URIおよび' im '/' pres 'URI（これは[XEP-0106]と一致しています）。
6. Apply Nodeprep profile of stringprep [RFC3454] or its replacement (see [RFC6122] and [XMPP-ADDRESS-FORMAT]) for canonicalization (OPTIONAL).
6. stringprepのNodeprepプロファイル[RFC3454]またはその置換（[RFC6122]および[XMPP-ADDRESS-FORMAT]を参照）を正規化に適用します（オプション）。
7. Recombine local part with mapped hostname to form a bare JID ("localpart@domainpart").
7. ローカルパーツをマップされたホスト名と再結合して、ベアJID（ "localpart @ domainpart"）を作成します。
8. If the (SIP) address contained a "gr" URI parameter, append a slash character "/" and the "gr" value to the bare JID to form a full JID ("localpart@domainpart/resourcepart").
8. （SIP）アドレスに「gr」URIパラメーターが含まれている場合は、スラッシュ文字「/」と「gr」値をベアJIDに追加して、完全なJID（「localpart @ domainpart / resourcepart」）を形成します。
Several examples follow, illustrating steps 3, 5, and 8 described above.
上記のステップ3、5、および8を示すいくつかの例が続きます。
+----------------------------+--------------------------+
| SIP URI | XMPP Address |
+----------------------------+--------------------------+
| sip:f%C3%BC@sip.example | fü@sip.example |
+----------------------------+--------------------------+
| sip:o'malley@sip.example | o\27malley@sip.example |
+----------------------------+--------------------------+
| sip:foo@sip.example;gr=bar | foo@sip.example/bar |
+----------------------------+--------------------------+
In the first example, the string "%C3%BC" is a percent-encoded representation of the UTF-8-encoded Unicode character LATIN SMALL LETTER U WITH DIAERESIS (U+00FC), whereas the string "ü" is the same character shown for documentation purposes using the XML Notation defined in [RFC3987] (in XMPP, it would be sent directly as a UTF-8-encoded Unicode character and not percent-encoded as in a SIP URI to comply with the URI syntax defined in [RFC3986]).
最初の例では、文字列 "％C3％BC"は、UTF-8でエンコードされたUnicode文字のラテン文字の小文字U（DIAERESIS付き）（U + 00FC）をパーセントでエンコードしたものですが、文字列 "＆#xFC;"です。 [RFC3987]で定義されているXML表記を使用して文書化のために示されているのと同じ文字です（XMPPでは、URIに準拠するためにSIP URIのようにパーセントエンコードされず、UTF-8エンコードされたUnicode文字として直接送信されます） [RFC3986]で定義されている構文）。
The following is a high-level algorithm for mapping an XMPP address to a 'sip', 'sips', 'im', or 'pres' URI:
以下は、XMPPアドレスを「sip」、「sips」、「im」、または「pres」URIにマッピングするための高レベルのアルゴリズムです。
1. Split XMPP address into localpart (mapping described in remaining steps), domainpart (hostname; mapping is out of scope), and resourcepart (specifier for particular device or connection, for which an OPTIONAL mapping is described below).
1. XMPPアドレスをlocalpart（マッピングは残りの手順で説明）、domainpart（ホスト名、マッピングは範囲外）、およびresourcepart（特定のデバイスまたは接続の指定子。オプションのマッピングについては以下で説明します）に分割します。
2. Apply Nodeprep profile of stringprep [RFC3454] or its replacement (see [RFC6122] and [XMPP-ADDRESS-FORMAT]) for canonicalization of the XMPP localpart (OPTIONAL).
2. stringprep [RFC3454]またはその置換（[RFC6122]および[XMPP-ADDRESS-FORMAT]を参照）のNodeprepプロファイルを適用して、XMPPローカルパートを正規化します（オプション）。
3. Translate "\26" to "&", "\27" to "'", and "\2f" to "/", respectively (this is consistent with [XEP-0106]).
3. 「\ 26」を「＆」、「\ 27」を「 '」、「\ 2f」を「/」にそれぞれ変換します（これは[XEP-0106]と一致しています）。
4. Determine if the foreign domain supports 'im' and 'pres' URIs (discovered via [RFC2782] lookup as specified in [RFC6121]), else assume that the foreign domain supports 'sip'/'sips' URIs.
4. 外部ドメインが「im」および「pres」URI（[RFC6122]で指定された[RFC2782]ルックアップで検出）をサポートするかどうかを判別します。そうでない場合、外部ドメインが「sip」/「sips」URIをサポートすると想定します。
5. If converting into 'im' or 'pres' URI, for each byte, if the byte is in the set (),.;[\] or is a UTF-8 character outside the ASCII range, then percent-encode that byte to "%hexhex" format. If converting into 'sip' or 'sips' URI, for each byte, if the byte is in the set #%[\]^`{|} or is a UTF-8 character outside the ASCII range, then percent-encode that byte to "%hexhex" format.
5. 「im」または「pres」URIに変換する場合、バイトごとに、バイトがセット()、。; [\]にあるか、ASCII範囲外のUTF-8文字である場合、そのバイトを「％hexhex」形式。 「sip」または「sips」URIに変換する場合、バイトごとに、そのバイトがセット＃％[\] ^ `{|}にあるか、ASCII範囲外のUTF-8文字である場合、そのパーセントエンコード「％hexhex」形式のバイト。
6. Combine resulting local part with mapped hostname to form local@domain address.
6. 結果のローカル部分とマップされたホスト名を組み合わせて、local @ domainアドレスを形成します。
7. Prepend with the string 'im:' (for XMPP <message/> stanzas) or 'pres:' (for XMPP <presence/> stanzas) if foreign domain supports these, else prepend with the string 'sip:' or 'sips:' according to local service policy.
7. 外部ドメインがこれらをサポートする場合は、文字列「im：」（XMPP <message />スタンザの場合）または「pres：」（XMPP <presence />スタンザの場合）を前に付加します。それ以外の場合は、文字列「sip：」または「sips：を前に付加します。 'ローカルサービスポリシーに従って。
8. If the XMPP address included a resourcepart and the destination URI scheme is 'sip' or 'sips', optionally append the slash character '/' and then append the resourcepart (making sure to percent-encode any UTF-8 characters outside the ASCII range) as the "gr" URI parameter.
8. XMPPアドレスにリソースパーツが含まれ、宛先URIスキームが「sip」または「sips」の場合、オプションでスラッシュ文字「/」を追加してからリソースパーツを追加します（ASCII範囲外のUTF-8文字は必ずパーセントエンコードしてください） ） "gr" URIパラメータとして。
Several examples follow, illustrating steps 3, 5, and 8 described above.
上記のステップ3、5、および8を示すいくつかの例が続きます。
+---------------------------+---------------------------------+
| XMPP Address | SIP URI |
+---------------------------+---------------------------------+
| m\26m@xmpp.example | sip:m&m@xmpp.example |
| tschüss@xmpp.example | sip:tsch%C3%BCss@xmpp.example |
| baz@xmpp.example/qux | sip:baz@xmpp.example;gr=qux |
+---------------------------+---------------------------------+
As above, in the first example the string "ü" is the Unicode character LATIN SMALL LETTER U WITH DIAERESIS (U+00FC) shown for documentation purposes using the XML Notation defined in [RFC3987] (in XMPP, it would be sent directly as a UTF-8-encoded Unicode character and not percent-encoded, whereas the string "%C3%BC" is a percent-encoded representation of the same character.
上記のように、最初の例では、文字列 "＆#xFC;" [RFC3987]で定義されているXML表記を使用して文書化のために示されているUnicode文字のラテン小文字Uダイアレシス（U + 00FC）（XMPPでは、パーセントではなくUTF-8エンコードされたUnicode文字として直接送信されます）文字列 "％C3％BC"は、同じ文字をパーセントでエンコードしたものです。
Various differences between XMPP error conditions and SIP response codes make it hard to provide a comprehensive and consistent mapping between the protocols:
XMPPエラー条件とSIP応答コードのさまざまな違いにより、プロトコル間の包括的で一貫したマッピングを提供することが困難になっています。
o Whereas the set of XMPP error conditions is fixed in the core XMPP specification (and supplemented where needed by application-specific extensions), the set of SIP response codes is more open to change, as evidenced by the IANA registry of SIP response codes.
o XMPPエラー条件のセットはコアXMPP仕様で修正されています（アプリケーション固有の拡張機能によって必要に応じて補足されます）が、SIPレスポンスコードのIANAレジストリで証明されているように、SIPレスポンスコードのセットは変更に対してよりオープンです。
o XMPP has defined fewer error conditions related to stanza handling (22 are defined in [RFC6120]) than SIP has defined response codes related to message handling (at the date of this writing, 71 SIP response codes are registered with IANA as defined in [RFC3261] and numerous SIP extensions).
o XMPPで定義されているスタンザ処理に関連するエラー条件（22は[RFC6120]で定義されています）は、SIPがメッセージ処理に関連する応答コードを定義しています（この執筆時点で、71のSIP応答コードが[RFC3261で定義されているようにIANAに登録されています。 ]および多数のSIP拡張機能）。
o In many cases, the SIP response codes are more specific than the XMPP error conditions (e.g., from an XMPP perspective the SIP codes "413 Request Entity Too Large" and "414 Request-URI Too Long" are simply two different types of response to the same bad request, and the SIP codes "415 Unsupported Media Type" and "416 Unsupported URI Scheme" are two different responses to a request that is not acceptable).
o 多くの場合、SIP応答コードはXMPPエラー条件よりも具体的です（たとえば、XMPPの観点から、SIPコード「413 Request Entity Too Large」と「414 Request-URI Too Long」は、単に2つの異なるタイプの応答です。同じ不正な要求、およびSIPコード「415 Unsupported Media Type」と「416 Unsupported URI Scheme」は、受け入れられない要求に対する2つの異なる応答です）。
o SIP differentiates between responses about a particular endpoint or resource (the 4xx series) and responses about a user, i.e., all of a user's endpoints or resources (the 6xx series). There is no such distinction in XMPP, since the same error condition can be returned in relation to the "bare JID" (localpart@domainpart) of a user or the "full JID" (localpart@domainpart/resourcepart) of a particular endpoint or resource, depending on the 'to' address of the original request.
o SIPは、特定のエンドポイントまたはリソース（4xxシリーズ）に関する応答とユーザー、つまりユーザーのすべてのエンドポイントまたはリソース（6xxシリーズ）に関する応答を区別します。 XMPPにはそのような区別はありません。ユーザーの「ベアJID」（localpart @ domainpart）または特定のエンドポイントの「フルJID」（localpart @ domainpart / resourcepart）に関して同じエラー条件が返されるためです。元のリクエストの「宛先」アドレスに応じて、リソース。
As a result of these and other factors, the mapping of error conditions and response codes is more of an art than a science. This document provides suggested mappings, but implementations are free to deviate from these mappings if needed. Also, because no XMPP error conditions are equivalent to the provisional (1xx) and successful (2xx) response codes in SIP, this document suggests mappings only for the SIP redirection (3xx), request failure (4xx), server failure (5xx), and global failure (6xx) response code families.
これらの要因およびその他の要因の結果として、エラー状態と応答コードのマッピングは、科学というよりは芸術です。このドキュメントは推奨されるマッピングを提供しますが、実装は必要に応じてこれらのマッピングから自由に逸脱できます。また、XMPPエラー条件はSIPの暫定（1xx）および成功（2xx）応答コードに相当しないため、このドキュメントでは、SIPリダイレクション（3xx）、要求の失敗（4xx）、サーバーの失敗（5xx）、およびグローバル障害（6xx）応答コードファミリー。
Supplementary information about SIP response codes can be expressed in the "Reason-Phrase" in the Status-Line header, and detailed information about XMPP error conditions can be expressed in the <text/> child of the <error/> element. Although the semantics of these constructs are specified in a slightly different way, it is reasonable for a gateway to map these constructs to each other if they are found in a SIP response or XMPP error stanza.
SIP応答コードに関する補足情報は、Status-Lineヘッダーの「Reason-Phrase」で表すことができ、XMPPエラー条件に関する詳細情報は、<error />要素の<text />子で表すことができます。これらの構成のセマンティクスは少し異なる方法で指定されますが、SIP応答またはXMPPエラースタンザでこれらの構成が見つかった場合、ゲートウェイがこれらの構成を相互にマッピングすることは妥当です。
The mapping of specific XMPP error conditions to SIP response codes SHOULD be as described in the following table.
特定のXMPPエラー状態のSIP応答コードへのマッピングは、次の表で説明されているとおりである必要があります。
+------------------------------+---------------------+
| XMPP Error Condition | SIP Response Code |
+------------------------------+---------------------+
| <bad-request/> | 400 |
+------------------------------+---------------------+
| <conflict/> | 400 |
+------------------------------+---------------------+
| <feature-not-implemented/> | 405 or 501 (1) |
+------------------------------+---------------------+
| <forbidden/> | 403 or 603 (2) |
+------------------------------+---------------------+
| <gone/> | 301 or 410 (3) |
+------------------------------+---------------------+
| <internal-server-error/> | 500 |
+------------------------------+---------------------+
| <item-not-found/> | 404 or 604 (2) |
+------------------------------+---------------------+
| <jid-malformed/> | 400 |
+------------------------------+---------------------+
| <not-acceptable/> | 406 or 606 (2) |
+------------------------------+---------------------+
| <not-allowed/> | 403 |
+------------------------------+---------------------+
| <not-authorized/> | 401 |
+------------------------------+---------------------+
| <policy-violation/> | 403 |
+------------------------------+---------------------+
| <recipient-unavailable/> | 480 or 600 (2) |
+------------------------------+---------------------+
| <redirect/> | 302 |
+------------------------------+---------------------+
| <registration-required/> | 407 |
+------------------------------+---------------------+
| <remote-server-not-found/> | 404 or 408 (4) |
+------------------------------+---------------------+
| <remote-server-timeout/> | 408 |
+------------------------------+---------------------+
+------------------------------+---------------------+
| <resource-constraint/> | 500 |
+------------------------------+---------------------+
| <service-unavailable/> | see note (5) below |
+------------------------------+---------------------+
| <subscription-required/> | 400 |
+------------------------------+---------------------+
| <undefined-condition/> | 400 |
+------------------------------+---------------------+
| <unexpected-request/> | 491 or 400 |
+------------------------------+---------------------+
Table 2: Mapping of XMPP Error Conditions to SIP Response Codes
表2：XMPPエラー条件のSIP応答コードへのマッピング
(1) If the error relates to a "full JID" (localpart@domainpart/ resourcepart), the SIP 405 response code is RECOMMENDED. If the error relates to a "bare JID" (localpart@domainpart), the SIP 501 response code is RECOMMENDED.
（1）エラーが「完全なJID」（localpart @ domainpart / resourcepart）に関連している場合、SIP 405応答コードが推奨されます。エラーが「ベアJID」（localpart @ domainpart）に関連している場合、SIP 501応答コードが推奨されます。
(2) If the error relates to a "full JID" (localpart@domainpart/ resourcepart), the SIP response code from the 4xx series is RECOMMENDED. If the error relates to a "bare JID" (localpart@domainpart), the SIP response code from the 6xx series is RECOMMENDED.
（2）エラーが「完全なJID」（localpart @ domainpart / resourcepart）に関連している場合、4xxシリーズのSIP応答コードが推奨されます。エラーが「ベアJID」（localpart @ domainpart）に関連している場合、6xxシリーズのSIP応答コードが推奨されます。
(3) If the <gone/> element includes XML character data specifying the new address, the error MUST be mapped to SIP 301; if not, it MUST be mapped to SIP 410.
（3）<gone />要素に新しいアドレスを指定するXML文字データが含まれている場合、エラーはSIP 301にマップする必要があります。そうでない場合は、SIP 410にマップする必要があります。
(4) The XMPP <remote-server-not-found/> error can mean that the remote server either (a) does not exist or (b) cannot be resolved. SIP has two different response codes here: 404 to cover (a) and 408 to cover (b).
（4）XMPP <remote-server-not-found />エラーは、リモートサーバーが（a）存在しないか、（b）解決できないことを意味します。 SIPには、ここでは2つの異なる応答コードがあります。404は（a）をカバーし、408は（b）をカバーします。
(5) The XMPP <service-unavailable/> error condition is widely used to inform the requesting entity that the intended recipient does not support the relevant feature, to signal that a server cannot perform the requested service either generally or in relation to a particular user, and to avoid disclosing whether a given account exists at all. This is quite different from the semantics of the SIP 503 Service Unavailable response code, which is used to signal that communication with a server is impossible (e.g., even if the XMPP <service-unavailable/> error condition is returned in relation to a specific user, the SIP 503 response code will be interpreted as applying to all future requests to this server, not just requests for the specific user). Therefore, mapping the XMPP <service-unavailable/> error condition to the SIP 503 Service Unavailable response code is NOT RECOMMENDED. Although no precise mapping is available, the SIP 403 Forbidden and 405 Method Not Allowed response codes are closest in meaning to the XMPP <service-unavailable/> error condition.
（5）XMPP <service-unavailable />エラー条件は、意図された受信者が関連機能をサポートしていないことを要求エンティティに通知し、サーバーが要求されたサービスを一般的にまたは特定のサービスに関して実行できないことを通知するために広く使用されていますユーザー、および特定のアカウントが存在するかどうかの開示を避けるため。これは、サーバーとの通信が不可能であることを通知するために使用されるSIP 503 Service Unavailable応答コードのセマンティクスとはかなり異なります（たとえば、特定のXMPP <service-unavailable />エラー条件が返された場合でも）ユーザーの場合、SIP 503応答コードは、特定のユーザーの要求だけでなく、このサーバーへの今後のすべての要求に適用されると解釈されます。したがって、XMPP <service-unavailable />エラー条件をSIP 503 Service Unavailable応答コードにマッピングすることはお勧めしません。正確なマッピングはありませんが、SIP 403 Forbiddenおよび405 Method Not Allowed応答コードは、XMPP <service-unavailable />エラー状態に最も近い意味で応答します。
The mapping of SIP response codes to XMPP error conditions SHOULD be as described in the following table. If a gateway encounters a SIP response code that is not listed below, it SHOULD map a 3xx-series code to <redirect/>, a 4xx-series code to <bad-request/>, a 5xx-series code to <internal-server-error>, and a 6xx-series code to <recipient-unavailable/>.
SIP応答コードのXMPPエラー条件へのマッピングは、次の表に示すとおりである必要があります（SHOULD）。ゲートウェイが以下にリストされていないSIP応答コードを検出した場合、3xxシリーズのコードを<redirect />に、4xxシリーズのコードを<bad-request />に、5xxシリーズのコードを<internal- server-error>、および6xxシリーズのコードを<recipient-unavailable />に送信します。
+---------------------+---------------------------------+
| SIP Response Code | XMPP Error Condition |
+---------------------+---------------------------------+
| 3xx | <redirect/> |
+---------------------+---------------------------------+
| 300 | <redirect/> |
+---------------------+---------------------------------+
| 301 | <gone/> (1) |
+---------------------+---------------------------------+
| 302 | <redirect/> |
+---------------------+---------------------------------+
| 305 | <redirect/> |
+---------------------+---------------------------------+
| 380 | <not-acceptable/> |
+---------------------+---------------------------------+
| 4xx | <bad-request/> |
+---------------------+---------------------------------+
| 400 | <bad-request/> |
+---------------------+---------------------------------+
| 401 | <not-authorized/> |
+---------------------+---------------------------------+
| 402 | <bad-request/> (2) |
+---------------------+---------------------------------+
| 403 | <forbidden/> (3) |
+---------------------+---------------------------------+
| 404 | <item-not-found/> (4) |
+---------------------+---------------------------------+
| 405 | <feature-not-implemented/> |
+---------------------+---------------------------------+
| 406 | <not-acceptable/> |
+---------------------+---------------------------------+
| 407 | <registration-required/> |
+---------------------+---------------------------------+
+---------------------+---------------------------------+
| 408 | <remote-server-timeout/> (5) |
+---------------------+---------------------------------+
| 410 | <gone/> (1) |
+---------------------+---------------------------------+
| 413 | <policy-violation/> |
+---------------------+---------------------------------+
| 414 | <policy-violation/> |
+---------------------+---------------------------------+
| 415 | <not-acceptable/> |
+---------------------+---------------------------------+
| 416 | <not-acceptable/> |
+---------------------+---------------------------------+
| 420 | <feature-not-implemented/> |
+---------------------+---------------------------------+
| 421 | <not-acceptable/> |
+---------------------+---------------------------------+
| 423 | <resource-constraint/> |
+---------------------+---------------------------------+
| 430 | <recipient-unavailable/> (6) |
+---------------------+---------------------------------+
| 439 | <feature-not-implemented/> (6) |
+---------------------+---------------------------------+
| 440 | <policy-violation/> (7) |
+---------------------+---------------------------------+
| 480 | <recipient-unavailable/> |
+---------------------+---------------------------------+
| 481 | <item-not-found/> |
+---------------------+---------------------------------+
| 482 | <not-acceptable/> |
+---------------------+---------------------------------+
| 483 | <not-acceptable/> |
+---------------------+---------------------------------+
| 484 | <item-not-found/> |
+---------------------+---------------------------------+
| 485 | <item-not-found/> |
+---------------------+---------------------------------+
| 486 | <recipient-unavailable/> |
+---------------------+---------------------------------+
| 487 | <recipient-unavailable/> |
+---------------------+---------------------------------+
| 488 | <not-acceptable/> |
+---------------------+---------------------------------+
| 489 | <policy-violation/> (8) |
+---------------------+---------------------------------+
| 491 | <unexpected-request/> |
+---------------------+---------------------------------+
+---------------------+---------------------------------+
| 493 | <bad-request/> |
+---------------------+---------------------------------+
| 5xx | <internal-server-error/> |
+---------------------+---------------------------------+
| 500 | <internal-server-error/> |
+---------------------+---------------------------------+
| 501 | <feature-not-implemented/> |
+---------------------+---------------------------------+
| 502 | <remote-server-not-found/> |
+---------------------+---------------------------------+
| 503 | <internal-server-error/> (9) |
+---------------------+---------------------------------+
| 504 | <remote-server-timeout/> |
+---------------------+---------------------------------+
| 505 | <not-acceptable/> |
+---------------------+---------------------------------+
| 513 | <policy-violation/> |
+---------------------+---------------------------------+
| 6xx | <recipient-unavailable/> |
+---------------------+---------------------------------+
| 600 | <recipient-unavailable/> |
+---------------------+---------------------------------+
| 603 | <recipient-unavailable/> |
+---------------------+---------------------------------+
| 604 | <item-not-found/> |
+---------------------+---------------------------------+
| 606 | <not-acceptable/> |
+---------------------+---------------------------------+
Table 3: Mapping of SIP Response Codes to XMPP Error Conditions
表3：SIP応答コードのXMPPエラー条件へのマッピング
(1) When mapping SIP 301 to XMPP <gone/>, the <gone/> element MUST include XML character data specifying the new address. When mapping SIP 410 to XMPP <gone/>, the <gone/> element MUST NOT include XML character data specifying a new address.
（1）SIP 301をXMPP <gone />にマッピングする場合、<gone />要素には、新しいアドレスを指定するXML文字データを含める必要があります。 SIP 410をXMPP <gone />にマッピングする場合、<gone />要素には、新しいアドレスを指定するXML文字データを含めてはなりません（MUST NOT）。
(2) The XMPP <payment-required/> error condition was removed in [RFC6120]. Therefore, a mapping to XMPP <bad-request/> is suggested instead.
（2）XMPP <payment-required />エラー状態は[RFC6120]で削除されました。したがって、代わりにXMPP <bad-request />へのマッピングが推奨されます。
(3) Depending on the scenario, other possible translations for SIP 403 are <not-allowed/> and <policy-violation/>.
（3）シナリオに応じて、SIP 403の他の可能な変換は<not-allowed />および<policy-violation />です。
(4) Depending on the scenario, another possible translation for SIP 404 is <remote-server-not-found/>.
（4）シナリオによっては、SIP 404の別の可能な変換は<remote-server-not-found />です。
(5) Depending on the scenario, another possible translation for SIP 408 is <remote-server-not-found/>.
（5）シナリオに応じて、SIP 408の別の可能な変換は<remote-server-not-found />です。
(6) Codes 430 and 439 are defined in [RFC5626].
（6）コード430および439は[RFC5626]で定義されています。
(7) Code 440 is defined in [RFC5393].
（7）コード440は[RFC5393]で定義されています。
(8) Code 489 is defined in [RFC6665].
（8）コード489は[RFC6665]で定義されています。
(9) Regarding the semantic mismatch between XMPP <service-unavailable/> and SIP code 503, see note (5) in Section 7.1 of this document.
（9）XMPP <service-unavailable />とSIPコード503のセマンティックミスマッチについては、このドキュメントのセクション7.1のメモ（5）を参照してください。
Detailed security considerations for SIP and XMPP are given in [RFC3261] and [RFC6120], respectively.
SIPおよびXMPPの詳細なセキュリティの考慮事項は、それぞれ[RFC3261]および[RFC6120]に記載されています。
To protect information sent between SIP and XMPP systems, deployed gateways SHOULD use Transport Layer Security (TLS) [RFC5246] when communicating over TCP and Datagram Transport Layer Security (DTLS) [RFC6347] when communicating over UDP.
SIPとXMPPシステム間で送信される情報を保護するために、配備されたゲートウェイは、TCPで通信するときにトランスポート層セキュリティ（TLS）[RFC5246]を使用し、UDPで通信するときにデータグラムトランスポート層セキュリティ（DTLS）[RFC6347]を使用する必要があります。
As specified in Section 26.4.4 of [RFC3261] and updated by [RFC5630], a To header or a Request-URI containing a Session Initiation Protocol Secure (SIPS) URI is used to indicate that all hops in a communication path need to be protected using TLS. Because XMPP lacks a way to signal that all hops need to be protected, if the To header or Request-URI of a SIP message is a SIPS URI then the SIP-to-XMPP gateway MUST NOT translate the SIP message into an XMPP stanza and MUST NOT route it to the destination XMPP server (there might be exceptions to such a policy, such as explicit agreement among two operators to enforce per-hop security, but currently they are quite rare).
[RFC3261]のセクション26.4.4で指定され、[RFC5630]によって更新されると、Toヘッダーまたはセッション開始プロトコルセキュア（SIPS）URIを含むRequest-URIを使用して、通信パスのすべてのホップが必要であることを示しますTLSを使用して保護されています。 XMPPには、すべてのホップを保護する必要があることを通知する方法がないため、SIPメッセージのToヘッダーまたはRequest-URIがSIPS URIの場合、SIP-to-XMPPゲートウェイはSIPメッセージをXMPPスタンザに変換してはなりません。宛先XMPPサーバーにルーティングしないでください（ホップごとのセキュリティを実施するための2つのオペレーター間の明示的な合意など、このようなポリシーには例外が存在する可能性がありますが、現在は非常にまれです）。
A gateway between SIP and XMPP (in either direction) effectively acts as a SIP back-to-back user agent ("B2BUA"). The amplification vulnerability described in [RFC5393] can manifest itself with B2BUAs (see also [B2BUA-LOOP-DETECT]), and a gateway SHOULD implement the loop-detection methods defined in that specification to help mitigate the possibility of amplification attacks. Note that although it would be possible to signal the Max-Forwards and Max-Breadth SIP headers over XMPP using the Stanza Headers and Internet Metadata (SHIM) extension [XEP-0131], that extension is not widely implemented; therefore, defenses against excessive looping and amplification attacks when messages pass back and forth through SIP and XMPP networks are out of scope for this document. However, it ought to be addressed in the future, and implementations are strongly encouraged to incorporate appropriate countermeasures wherever possible.
SIPとXMPP間のゲートウェイ（どちらの方向でも）は、SIPバックツーバックユーザーエージェント（「B2BUA」）として効果的に機能します。 [RFC5393]で説明されている増幅の脆弱性は、B2BUA（[B2BUA-LOOP-DETECT]も参照）で顕在化する可能性があり、ゲートウェイは、その仕様で定義されているループ検出メソッドを実装して、増幅攻撃の可能性を軽減するのに役立ちます。スタンザヘッダーおよびインターネットメタデータ（SHIM）拡張[XEP-0131]を使用して、XMPPを介してMax-ForwardsおよびMax-Breadth SIPヘッダーをシグナリングすることは可能ですが、その拡張は広く実装されていません。したがって、メッセージがSIPおよびXMPPネットワークを介してやり取りされる場合の過度のループおよび増幅攻撃に対する防御策は、このドキュメントの範囲外です。ただし、今後対応する必要があり、実装には可能な限り適切な対策を組み込むことが強く推奨されます。
The ability to use a wide range of Unicode characters [UNICODE] can lead to security issues, especially the possibility of user confusion over identifiers containing visually similar characters (also called "confusable characters" or "confusables"). The PRECIS framework specification [PRECIS] describes some of these security issues, and additional guidance can be found in [UTS39].
さまざまなUnicode文字[UNICODE]を使用する機能は、セキュリティ上の問題、特に視覚的に類似した文字（「混同可能な文字」または「混同可能文字」とも呼ばれる）を含む識別子に対するユーザーの混乱の可能性につながる可能性があります。 PRECISフレームワーク仕様[PRECIS]には、これらのセキュリティ問題の一部が記載されており、[UTS39]に追加のガイダンスがあります。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：セッション開始プロトコル」 、RFC 3261、2002年6月。
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[RFC3263] Rosenberg、J。およびH. Schulzrinne、「Session Initiation Protocol（SIP）：Locating SIP Servers」、RFC 3263、2002年6月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、2005年1月。
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005.
[RFC3987] Duerst、M。およびM. Suignard、「Internationalized Resource Identifiers（IRIs）」、RFC 3987、2005年1月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、2008年1月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、2008年8月。
[RFC5393] Sparks, R., Lawrence, S., Hawrylyshen, A., and B. Campen, "Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Forking Proxies", RFC 5393, December 2008.
[RFC5393] Sparks、R.、Lawrence、S.、Hawrylyshen、A。、およびB. Campen、「Session Initiation Protocol（SIP）Forking Proxiesにおける増幅の脆弱性への対処」、RFC 5393、2008年12月。
[RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)", RFC 5627, October 2009.
[RFC5627] Rosenberg、J。、「Session Initiation Protocol（SIP）でグローバルにルーティング可能なユーザーエージェントURI（GRUU）を取得して使用する」、RFC 5627、2009年10月。
[RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)", RFC 5630, October 2009.
[RFC5630]オーデットF.、「セッション開始プロトコル（SIP）でのSIPS URIスキームの使用」、RFC 5630、2009年10月。
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, March 2011.
[RFC6120] Saint-Andre、P。、「Extensible Messaging and Presence Protocol（XMPP）：Core」、RFC 6120、2011年3月。
[RFC6122] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Address Format", RFC 6122, March 2011.
[RFC6122] Saint-Andre、P。、「Extensible Messaging and Presence Protocol（XMPP）：Address Format」、RFC 6122、2011年3月。
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012.
[RFC6347] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security Version 1.2」、RFC 6347、2012年1月。
[UNICODE] The Unicode Consortium, "The Unicode Standard, Version 6.3", 2013, <http://www.unicode.org/versions/Unicode6.3.0/>.
[UNICODE] Unicodeコンソーシアム、「The Unicode Standard、Version 6.3」、2013、<http://www.unicode.org/versions/Unicode6.3.0/>。
[B2BUA-LOOP-DETECT] Kaplan, H. and V. Pascual, "Loop Detection Mechanisms for Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs)", Work in Progress, February 2014.
[B2BUA-LOOP-DETECT] Kaplan、H。およびV. Pascual、「セッション開始プロトコル（SIP）バックツーバックユーザーエージェント（B2BUA）のループ検出メカニズム」、作業中、2014年2月。
[PRECIS] Saint-Andre, P. and M. Blanchet, "PRECIS Framework: Preparation and Comparison of Internationalized Strings in Application Protocols", Work in Progress, April 2014.
[PRECIS] Saint-Andre、P.およびM. Blanchet、「PRECIS Framework：Preparation and Comparison of Internationalized Strings in Application Protocols」、Work in Progress、2014年4月。
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[RFC2782] Gulbrandsen、A.、Vixie、P。、およびL. Esibov、「サービスの場所を指定するためのDNS RR（DNS SRV）」、RFC 2782、2000年2月。
[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.
[RFC3428] Campbell、B.、Rosenberg、J.、Schulzrinne、H.、Huitema、C。、およびD. Gurle、「インスタントメッセージング用のSession Initiation Protocol（SIP）Extension」、RFC 3428、2002年12月。
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.
[RFC3454] Hoffman、P.およびM. Blanchet、「Preparation of Internationalized Strings（ "stringprep"）」、RFC 3454、2002年12月。
[RFC3856] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.
[RFC3856] Rosenberg、J。、「セッション開始プロトコル（SIP）のプレゼンスイベントパッケージ」、RFC 3856、2004年8月。
[RFC3859] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, August 2004.
[RFC3859] Peterson、J。、「Common Profile for Presence（CPP）」、RFC 3859、2004年8月。
[RFC3860] Peterson, J., "Common Profile for Instant Messaging (CPIM)", RFC 3860, August 2004.
[RFC3860] Peterson、J。、「Common Profile for Instant Messaging（CPIM）」、RFC 3860、2004年8月。
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.
[RFC3966] Schulzrinne、H。、「電話番号のtel URI」、RFC 3966、2004年12月。
[RFC5122] Saint-Andre, P., "Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP)", RFC 5122, February 2008.
[RFC5122] Saint-Andre、P。、「Extensible Messaging and Presence Protocol（XMPP）の国際化リソース識別子（IRI）およびUniform Resource Identifiers（URIs）」、RFC 5122、2008年2月。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5322] Resnick、P。、編、「インターネットメッセージ形式」、RFC 5322、2008年10月。
[RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, October 2009.
[RFC5626] Jennings、C.、Mahy、R。、およびF. Audet、「Managing Client-Initiated Connections in the Session Initiation Protocol（SIP）」、RFC 5626、2009年10月。
[RFC6121] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence", RFC 6121, March 2011.
[RFC6121] Saint-Andre、P。、「Extensible Messaging and Presence Protocol（XMPP）：Instant Messaging and Presence」、RFC 6121、2011年3月。
[RFC6665] Roach, A., "SIP-Specific Event Notification", RFC 6665, July 2012.
[RFC6665] Roach、A。、「SIP固有のイベント通知」、RFC 6665、2012年7月。
[UTS39] The Unicode Consortium, "Unicode Technical Standard #39: Unicode Security Mechanisms", November 2013, <http://unicode.org/reports/tr39/>.
[UTS39] Unicodeコンソーシアム、「Unicode Technical Standard＃39：Unicode Security Mechanisms」、2013年11月、<http://unicode.org/reports/tr39/>。
[XEP-0106] Hildebrand, J. and P. Saint-Andre, "JID Escaping", XSF XEP 0106, June 2007, <http://www.xmpp.org/extensions/xep-0106.html>.
[XEP-0106] Hildebrand、J。およびP. Saint-Andre、「JID Escaping」、XSF XEP 0106、2007年6月、<http://www.xmpp.org/extensions/xep-0106.html>。
[XEP-0131] Saint-Andre, P. and J. Hildebrand, "Stanza Headers and Internet Metadata", XSF XEP 0131, July 2006, <http://xmpp.org/extensions/xep-0131.html>.
[XEP-0131] Saint-Andre、P。およびJ. Hildebrand、「スタンザヘッダーとインターネットメタデータ」、XSF XEP 0131、2006年7月、<http://xmpp.org/extensions/xep-0131.html>。
[XMPP-ADDRESS-FORMAT] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Address Format", Work in Progress, March 2014.
[XMPP-ADDRESS-FORMAT] Saint-Andre、P。、「Extensible Messaging and Presence Protocol（XMPP）：Address Format」、Work in Progress、2014年3月。
The authors wish to thank the following individuals for their feedback: Mary Barnes, Dave Cridland, Dave Crocker, Mike De Vries, Fabio Forno, Adrian Georgescu, Philipp Hancke, Saul Ibarra Corretge, Markus Isomaki, Olle Johansson, Paul Kyzivat, Salvatore Loreto, Daniel-Constantin Mierla, Tory Patnoe, and Robert Sparks.
著者は、フィードバックについて次の個人に感謝したいと思います。メアリーバーンズ、デイブクリドランド、デイブクロッカー、マイクデヴリース、ファビオフォルノ、エイドリアンジョルジェク、フィリップハンケ、サウルイバラコレッジェ、マーカスイソマキ、オレヨハンソン、ポールキジバット、サルヴァトーレロレート、 Daniel-Constantin Mierla、Tory Patnoe、およびRobert Sparks。
Dan Romascanu reviewed the document on behalf of the General Area Review Team.
Dan Romascanuは、General Area Review Teamに代わってドキュメントをレビューしました。
During IESG review, Stephen Farrell, Ted Lemon, Pete Resnick, and Sean Turner caught several issues that needed to be addressed.
IESGのレビュー中に、スティーブンファレル、テッドレモン、ピートレズニック、ショーンターナーは、対処する必要のあるいくつかの問題を見つけました。
The authors gratefully acknowledge the assistance of Markus Isomaki and Yana Stamcheva as the working group chairs and Gonzalo Camarillo as the sponsoring Area Director.
著者は、作業グループの議長としてのMarkus IsomakiとYana Stamchevaの支援、スポンサーとしてのArea DirectorとしてのGonzalo Camarilloに感謝の意を表します。
Peter Saint-Andre wishes to acknowledge Cisco Systems, Inc., for employing him during his work on earlier versions of this document.
Peter Saint-Andreは、このドキュメントの以前のバージョンでの作業中に彼を採用したCisco Systems、Inc.を認めたいと思います。
Authors' Addresses
著者のアドレス
Peter Saint-Andre &yet
ピーターサンタンドレ＆まだ
EMail: ietf@stpeter.im
Avshalom Houri IBM Rorberg Building, Pekris 3 Rehovot 76123 Israel
Avshalom Houri IBM Rorberg Building、Pekris 3 Rehovot 76123 Israel
EMail: avshalom@il.ibm.com
Joe Hildebrand Cisco Systems, Inc. 1899 Wynkoop Street, Suite 600 Denver, CO 80202 USA
Joe Hildebrand Cisco Systems、Inc. 1899 Wynkoop Street、Suite 600 Denver、CO 80202 USA
EMail: jhildebr@cisco.com