RFC 7878 - Session Peering Provisioning (SPP) Protocol over SOAP 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc7878
タイトル : RFC 7878 - SOAPを介したセッションピアリングプロビジョニング（SPP）プロトコル
翻訳編集 : 自動生成

[要約] RFC 7878は、SOAPを介したセッションピアリングプロビジョニング（SPP）プロトコルに関する仕様です。このRFCの目的は、異なるセッションピアリングプロトコルを使用するネットワークエンティティ間での相互運用性を提供することです。

Internet Engineering Task Force (IETF)                     K. Cartwright
Request for Comments: 7878                                     V. Bhatia
Category: Standards Track                                            TNS
ISSN: 2070-1721                                                J-F. Mule
                                                              Apple Inc.
                                                            A. Mayrhofer
                                                             nic.at GmbH
                                                             August 2016

Session Peering Provisioning (SPP) Protocol over SOAP

SOAPを介したセッションピアリングプロビジョニング（SPP）プロトコル

Abstract

概要

The Session Peering Provisioning Framework (SPPF) specifies the data model and the overall structure to provision Session Establishment Data (SED) into Session Data Registries and SIP Service Provider data stores. To utilize this framework, one needs a substrate protocol. Given that the Simple Object Access Protocol (SOAP) is currently widely used for messaging between elements of such provisioning systems, this document specifies the usage of SOAP (via HTTPS) as the substrate protocol for SPPF. The benefits include leveraging prevalent expertise and a higher probability that existing provisioning systems will be able to easily migrate to using an SPPF-based protocol.

セッションピアリングプロビジョニングフレームワーク（SPPF）は、データモデルと全体構造を指定して、セッション確立データ（SED）をセッションデータレジストリとSIPサービスプロバイダーデータストアにプロビジョニングします。このフレームワークを利用するには、基質プロトコルが必要です。シンプルオブジェクトアクセスプロトコル（SOAP）は現在、このようなプロビジョニングシステムの要素間のメッセージングに広く使用されているため、このドキュメントでは、SPPFのサブストレートプロトコルとして（HTTPS経由の）SOAPの使用法を指定します。利点には、普及している専門知識を活用すること、および既存のプロビジョニングシステムがSPPFベースのプロトコルを使用して簡単に移行できる可能性が高くなることが含まれます。

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 7841.

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

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7878.

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

著作権表示

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.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  SOAP Features and Protocol Layering . . . . . . . . . . . . .   4
   4.  HTTP(S) Features and SPPP over SOAP . . . . . . . . . . . . .   7
   5.  Authentication, Integrity, and Confidentiality  . . . . . . .   7
   6.  Language Identification . . . . . . . . . . . . . . . . . . .   7
   7.  SPPP SOAP Data Structures . . . . . . . . . . . . . . . . . .   7
     7.1.  Concrete Object Key Types . . . . . . . . . . . . . . . .   8
       7.1.1.  Generic Object Key  . . . . . . . . . . . . . . . . .   8
       7.1.2.  Public Identifier Object Key  . . . . . . . . . . . .   9
       7.1.3.  SED Group Offer Key . . . . . . . . . . . . . . . . .  10
     7.2.  Operation Request and Response Structures . . . . . . . .  10
       7.2.1.  Add Operation Structure . . . . . . . . . . . . . . .  10
       7.2.2.  Delete Operation Structure  . . . . . . . . . . . . .  13
       7.2.3.  Accept Operation Structure  . . . . . . . . . . . . .  16
       7.2.4.  Reject Operation Structure  . . . . . . . . . . . . .  19
       7.2.5.  Batch Operation Structure . . . . . . . . . . . . . .  22
       7.2.6.  Get Operation Structure . . . . . . . . . . . . . . .  25
       7.2.7.  Get SED Group Offers Operation Structure  . . . . . .  26
       7.2.8.  Generic Query Response  . . . . . . . . . . . . . . .  28
       7.2.9.  Get Server Details Operation Structure  . . . . . . .  29
     7.3.  Response Codes and Messages . . . . . . . . . . . . . . .  30
     7.4.  Minor Version Identifier  . . . . . . . . . . . . . . . .  32
   8.  Protocol Operations . . . . . . . . . . . . . . . . . . . . .  32
   9.  SPPP over SOAP WSDL Definition  . . . . . . . . . . . . . . .  32
   10. SPPP over SOAP Examples . . . . . . . . . . . . . . . . . . .  44
     10.1.  Add Destination Group  . . . . . . . . . . . . . . . . .  44
     10.2.  Add SED Records  . . . . . . . . . . . . . . . . . . . .  46
     10.3.  Add SED Records -- URIType . . . . . . . . . . . . . . .  47
     10.4.  Add SED Group  . . . . . . . . . . . . . . . . . . . . .  49
     10.5.  Add Public Identifier -- Successful COR Claim  . . . . .  50

     10.6.  Add LRN  . . . . . . . . . . . . . . . . . . . . . . . .  52
     10.7.  Add TN Range . . . . . . . . . . . . . . . . . . . . . .  53
     10.8.  Add TN Prefix  . . . . . . . . . . . . . . . . . . . . .  54
     10.9.  Enable Peering -- SED Group Offer  . . . . . . . . . . .  56
     10.10. Enable Peering -- SED Group Offer Accept . . . . . . . .  58
     10.11. Add Egress Route . . . . . . . . . . . . . . . . . . . .  60
     10.12. Remove Peering -- SED Group Offer Reject . . . . . . . .  61
     10.13. Get Destination Group  . . . . . . . . . . . . . . . . .  62
     10.14. Get Public Identifier  . . . . . . . . . . . . . . . . .  64
     10.15. Get SED Group Request  . . . . . . . . . . . . . . . . .  66
     10.16. Get SED Group Offers Request . . . . . . . . . . . . . .  68
     10.17. Get Egress Route . . . . . . . . . . . . . . . . . . . .  70
     10.18. Delete Destination Group . . . . . . . . . . . . . . . .  72
     10.19. Delete Public Identifier . . . . . . . . . . . . . . . .  73
     10.20. Delete SED Group Request . . . . . . . . . . . . . . . .  74
     10.21. Delete SED Group Offers Request  . . . . . . . . . . . .  75
     10.22. Delete Egress Route  . . . . . . . . . . . . . . . . . .  76
     10.23. Batch Request  . . . . . . . . . . . . . . . . . . . . .  77
   11. Security Considerations . . . . . . . . . . . . . . . . . . .  80
     11.1.  Vulnerabilities  . . . . . . . . . . . . . . . . . . . .  80
   12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  81
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  81
     13.1.  Normative References . . . . . . . . . . . . . . . . . .  81
     13.2.  Informative References . . . . . . . . . . . . . . . . .  82
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  82
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  83

1. Introduction

1. はじめに

SPPF, defined in [RFC7877], is best supported by a transport and messaging infrastructure that is connection oriented, is request-response oriented, is easily secured, supports propagation through firewalls in a standard fashion, and is easily integrated into back-office systems. This is due to the fact that the client side of SPPF is likely to be integrated with organizations' operational support systems that facilitate transactional provisioning of user addresses and their associated SED. The server side of SPPF is likely to reside in a separate organization's network, resulting in the SPPF provisioning transactions traversing the Internet as they are propagated from the SPPF client to the SPPF server. Given the current state of industry practice and technologies, SOAP and HTTP(S) are well suited for this type of environment. This document describes the specification for transporting SPPF XML structures, using SOAP and HTTP(S) as substrates.

[RFC7877]で定義されているSPPFは、接続指向で、要求/応答指向であり、簡単に保護され、標準的な方法でファイアウォールを介した伝播をサポートし、バックオフィスシステムに簡単に統合できるトランスポートおよびメッセージングインフラストラクチャによって最もよくサポートされます。これは、SPPFのクライアント側が、ユーザーアドレスとそれに関連するSEDのトランザクションプロビジョニングを容易にする組織の運用サポートシステムと統合される可能性が高いためです。 SPPFのサーバー側は別の組織のネットワークに存在する可能性が高く、その結果、SPPFプロビジョニングトランザクションがSPPFクライアントからSPPFサーバーに伝播されるときにインターネットを通過します。業界の実践とテクノロジーの現状を考えると、SOAPとHTTP（S）はこのタイプの環境に適しています。このドキュメントでは、SOAPおよびHTTP（S）を基質として使用して、SPPF XML構造を転送するための仕様について説明します。

The specification in this document for transporting SPPF XML structures over SOAP and HTTP(S) is primarily comprised of five subjects: (1) a description of any applicable SOAP features, (2) any applicable HTTP features, (3) security considerations, (4) (perhaps most importantly) the Web Services Description Language (WSDL) definition for the SPP Protocol over SOAP, and (5) XML Schema Definition (XSD) types that are "substrate" specific.

SOAPおよびHTTP（S）を介してSPPF XML構造を転送するためのこのドキュメントの仕様は、主に5つの主題で構成されています：（1）該当するSOAP機能の説明、（2）該当するHTTP機能、（3）セキュリティに関する考慮事項、（ 4）（おそらく最も重要なこと）SPP Protocol over SOAPのWebサービス記述言語（WSDL）定義、および（5）「基板」固有のXMLスキーマ定義（XSD）タイプ。

2. Terminology

2. 用語

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

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

3. SOAP Features and Protocol Layering

3. SOAP機能とプロトコルレイヤー

The list of SOAP features that are explicitly used and required for SPPP over SOAP are limited. Most SOAP features are not necessary for SPPF. SPPP over SOAP primarily uses SOAP simply as a standard message-envelope technology. The SOAP message envelope is comprised of the SOAP header and body. As described in the SOAP specification [SOAPREF], the SOAP header can contain optional, application-specific, information about the message. The SOAP body contains the SPPF message itself, whose structure is defined by the combination of one of the WSDL operations defined in this document and the SPPF XML data structures defined in this document and the SPPF document. SPPF does not rely on any data elements in the SOAP header. All relevant data elements are defined in the SPPF XML Schema described in [RFC7877] and the SPPF WSDL types specification described in Section 9 of this document.

明示的に使用され、SPPP over SOAPに必要なSOAP機能のリストは限られています。ほとんどのSOAP機能はSPPFには必要ありません。 SPPP over SOAPは、主にSOAPを単に標準のメッセージエンベロープテクノロジーとして使用します。 SOAPメッセージエンベロープは、SOAPヘッダーと本文で構成されます。 SOAP仕様[SOAPREF]で説明されているように、SOAPヘッダーには、メッセージに関するオプションのアプリケーション固有の情報を含めることができます。 SOAP本体にはSPPFメッセージ自体が含まれます。その構造は、このドキュメントで定義されているWSDL操作の1つと、このドキュメントおよびSPPFドキュメントで定義されているSPPF XMLデータ構造の組み合わせによって定義されます。 SPPFはSOAPヘッダーのデータ要素に依存しません。関連するすべてのデータ要素は、[RFC7877]で説明されているSPPF XMLスキーマと、このドキュメントのセクション9で説明されているSPPF WSDLタイプ仕様で定義されています。

WSDL is a widely standardized and adopted technology for defining the top-level structures of the messages that are transported within the body of a SOAP message. The WSDL definition for the SPPF SOAP messages is defined later in this document, which imports by reference the XML data types contained in the SPPF schema. The IANA registry where the SPPF schema resides is described in "The IETF XML Registry" [RFC3688].

WSDLは、SOAPメッセージの本文内で転送されるメッセージの最上位構造を定義するために広く標準化され採用されているテクノロジーです。 SPPF SOAPメッセージのWSDL定義は、このドキュメントの後半で定義されており、SPPFスキーマに含まれているXMLデータ型を参照によってインポートします。 SPPFスキーマが存在するIANAレジストリについては、「IETF XMLレジストリ」[RFC3688]で説明されています。

There are multiple structural styles that WSDL allows. The best practice for this type of application is what is sometimes referred to as the "document/literal wrapped style". This style is generally regarded as an optimal approach that enhances maintainability, comprehension, portability, and, to a certain extent, performance. It is characterized by setting the soapAction binding style as "document", the soapAction encoding style as "literal", and then defining the SOAP messages to simply contain a single data element that "wraps" a data structure containing all the required input or output data elements. The figure below illustrates this high-level technical structure as conceptual layers 3 through 6.

WSDLが許可する複数の構造スタイルがあります。このタイプのアプリケーションのベストプラクティスは、「ドキュメント/リテラルラップスタイル」と呼ばれることもあります。このスタイルは一般に、保守性、理解力、移植性、およびある程度、パフォーマンスを向上させる最適なアプローチと見なされています。これは、soapActionバインディングスタイルを「ドキュメント」、soapActionエンコーディングスタイルを「リテラル」として設定し、必要なすべての入力または出力を含むデータ構造を「ラップ」する単一のデータ要素を単純に含むようにSOAPメッセージを定義することを特徴とします。データ要素。以下の図は、この高度な技術構造を概念的なレイヤー3〜6として示しています。

                                 +-------------+
                             (1) |  Transport  |Example:
                                 |  Protocol   |  TCP, TLS, BEEP, etc.
                                 +-------------+
                                        |
                                        V
                                 +-------------+
                             (2) |   Message   |Example:
                                 |   Envelope  | HTTP, SOAP, None, etc.
                                 +-------------+
                                        |
                                        V
                                +--------------+
                           +----|    SOAP      |---+
                           |(3) |  Operation   |   |
                  Contains |    +--------------+   | Contains
                           |        Example:       |
                           V      submitAddRqst    V
                  +--------------+           +-------------+
                  | SOAP Request |           |SOAP Response|
       Example:   |   Message    |  (4)      |   Message   | Example:
       spppAdd    |  (Operation  |           |  (Operation | spppAdd
       RequestMsg |   Input)     |           |   Output)   | ResponseMsg
                  +--------------+           +-------------+
                           |                       |
                  Contains |                       | Contains
                           |                       |
                           V                       V
                  +--------------+          +---------------+
       Example:   |   Wrapped    |  (5)     |    Wrapped    | Example:
       spppAdd    |Request Object|          |Response Object| spppAdd
       Request    +--------------+          +---------------+ Response
                           |                       |
                  Contains |                       | Contains
                           |                       |
                           V                       V
                  +--------------+          +---------------+
                  |    SPPF      |          |     SPPF      |
                  |  XML Types   |  (6)     |   XML Types   |
                  +--------------+          +---------------+

Legend: BEEP = Blocks Extensible Exchange Protocol TLS = Transport Layer Security

凡例：BEEP = Extensible Exchange Protocol TLSをブロック=トランスポート層セキュリティ

Figure 1: Layering and Technical Structure of SPPP over SOAP Messages The operations supported by SPPP over SOAP are normatively defined later in this document. Each SOAP operation defines a request/input message and a response/output message. Each such request and response message then contains a single object that wraps the SPPF XML data types that comprise the inputs and the outputs, respectively, of the SOAP operation.

図1：SPPP over SOAPメッセージの階層化と技術構造SPPP over SOAPでサポートされる操作は、このドキュメントの後半で規範的に定義されています。各SOAP操作は、要求/入力メッセージと応答/出力メッセージを定義します。そのような各要求および応答メッセージには、SOAP操作の入力と出力をそれぞれ構成するSPPF XMLデータ型をラップする単一のオブジェクトが含まれます。

SOAP faults are not used by the SPPP over SOAP. All success and error responses are specified in Section 7.3 of this document. However, if a SOAP fault were to occur, perhaps due to failures in the SOAP message handling layer of a SOAP library, the client application should capture and handle the fault. Specifics on how to handle such SOAP faults, if they should occur, will be specific to the chosen SOAP implementation.

SOAP障害は、SPPP over SOAPでは使用されません。すべての成功およびエラー応答は、このドキュメントのセクション7.3で指定されています。ただし、SOAPライブラリのSOAPメッセージ処理層の障害が原因でSOAPフォルトが発生した場合、クライアントアプリケーションはフォルトをキャプチャして処理する必要があります。そのようなSOAP障害を処理する方法の詳細は、発生した場合に、選択したSOAP実装に固有です。

Implementations MUST use SOAP 1.2 [SOAPREF] or higher and MUST support SOAP 1.2. Implementations SHOULD use WSDL 1.1 [WSDLREF] and MUST NOT use earlier versions. Use of WSDL versions greater than 1.1 may introduce interoperability problems with implementations that use 1.1.

実装はSOAP 1.2 [SOAPREF]以上を使用する必要があり、SOAP 1.2をサポートする必要があります。実装では、WSDL 1.1 [WSDLREF]を使用する必要があり、以前のバージョンを使用してはなりません（MUST NOT）。 1.1を超えるWSDLバージョンを使用すると、1.1を使用する実装で相互運用性の問題が発生する可能性があります。

SPPF is a request/reply framework that allows a client application to submit provisioning data and query requests to a server. The SPPF data structures are designed to be protocol agnostic. Concerns regarding encryption, non-repudiation, and authentication are beyond the scope of this document. For more details, please refer to Section 4 ("Transport Substrate Protocol Requirements") of [RFC7877].

SPPFは、クライアントアプリケーションがサーバーにプロビジョニングデータとクエリ要求を送信できるようにする要求/応答フレームワークです。 SPPFデータ構造は、プロトコルに依存しないように設計されています。暗号化、否認防止、および認証に関する懸念は、このドキュメントの範囲外です。詳細については、[RFC7877]のセクション4（ "Transport Substrate Protocol Requirements"）を参照してください。

As illustrated in the previous diagram, SPPF can be viewed as a set of layers that collectively define the structure of an SPPF request and response. Layers 1 and 2 represent the transport, envelope, and authentication technologies. This document defines layers 3, 4, 5, and 6 for SPPP over SOAP.

前の図に示されているように、SPPFは、SPPF要求と応答の構造を集合的に定義する一連のレイヤーと見なすことができます。レイヤー1および2は、トランスポート、エンベロープ、および認証テクノロジーを表します。このドキュメントでは、SPPP over SOAPのレイヤー3、4、5、および6を定義します。

1. Layer 1: The transport protocol layer represents the communication mechanism between the client and server. SPPF can be layered over any substrate protocol that provides a set of basic requirements defined in Section 4 of [RFC7877].

1. レイヤー1：トランスポートプロトコルレイヤーは、クライアントとサーバー間の通信メカニズムを表します。 SPPFは、[RFC7877]のセクション4で定義された一連の基本要件を提供する任意の基質プロトコルの上に重ねることができます。

2. Layer 2: The message-envelope layer is optional but can provide features that are above the transport technology layer but below the application messaging layer. Technologies such as HTTP and SOAP are examples of message-envelope technologies.

2. レイヤー2：メッセージエンベロープレイヤーはオプションですが、トランスポートテクノロジーレイヤーの上にあるが、アプリケーションメッセージングレイヤーの下にある機能を提供できます。 HTTPやSOAPなどのテクノロジーは、メッセージエンベロープテクノロジーの例です。

3. Layers 3, 4, 5, and 6: The operation and message layers provide an envelope-independent and substrate-independent wrapper for the SPPF data model objects that are being acted on (created, modified, and queried).

3. レイヤー3、4、5、および6：操作レイヤーとメッセージレイヤーは、操作対象（作成、変更、クエリ）のSPPFデータモデルオブジェクトに、エンベロープとラッパーに依存しないラッパーを提供します。

4. HTTP(S) Features and SPPP over SOAP

4. HTTP（S）機能とSPPP over SOAP

While SOAP is not tied to HTTP(S), for reasons described in the Introduction, HTTP(S) is a good choice as the substrate protocol for the SPP Protocol SOAP messages. HTTP 1.1 includes the "persistent connection" feature, which allows multiple HTTP request/response pairs to be transported across a single HTTP connection. This is an important performance optimization feature, particularly when the connection is an HTTPS connection where the relatively time-consuming TLS handshake has occurred.

SOAPはHTTP（S）に関連付けられていませんが、「はじめに」で説明されている理由により、HTTP（S）はSPPプロトコルSOAPメッセージのサブストレートプロトコルとして適切な選択です。 HTTP 1.1には、「永続的な接続」機能が含まれています。これにより、複数のHTTP要求/応答ペアを単一のHTTP接続を介して転送できます。これは、特に接続が比較的時間がかかるTLSハンドシェイクが発生したHTTPS接続である場合、重要なパフォーマンス最適化機能です。

Implementations compliant with this document MUST use HTTP 1.1 [RFC7230] or higher. Also, implementations SHOULD use persistent connections.

このドキュメントに準拠する実装では、HTTP 1.1 [RFC7230]以降を使用する必要があります。また、実装では永続的な接続を使用する必要があります（SHOULD）。

5. Authentication, Integrity, and Confidentiality

5. 認証、整合性、機密性

To accomplish authentication, conforming SPPP over SOAP clients and servers MUST use HTTP Digest Authentication as defined in [RFC7235].

認証を行うには、SPPP over SOAPクライアントとサーバーに準拠する場合、[RFC7235]で定義されているHTTPダイジェスト認証を使用する必要があります。

To achieve integrity and privacy, conforming SPPP over SOAP clients and servers MUST support TLS as defined in [RFC5246] as the secure transport mechanism. Use of TLS MUST follow the recommendations contained in [RFC7525]

整合性とプライバシーを実現するには、SOAPクライアントおよびサーバー上のSPPPに準拠することで、セキュアなトランスポートメカニズムとして[RFC5246]で定義されているTLSをサポートする必要があります。 TLSの使用は、[RFC7525]に含まれる推奨事項に従う必要があります

6. Language Identification

6. 言語識別

Section 9 of [RFC7877] requires protocols to provide a mechanism to transmit language tags together with human-readable messages. When conforming SPPP SOAP servers use such tagging, the XML "lang" attribute ([W3C.REC-xml-20081126], Section 2.12) MUST be used. Clients MAY use the HTTP "Accept-Language" header field (see Section 5.3.5 of [RFC7231]) in order to indicate their language preference.

[RFC7877]のセクション9では、言語タグを人間が読めるメッセージとともに送信するメカニズムを提供するプロトコルが必要です。適合SPPP SOAPサーバーがこのようなタグ付けを使用する場合、XMLの「lang」属性（[W3C.REC-xml-20081126]、セクション2.12）を使用する必要があります。クライアントは、言語設定を示すために、HTTP "Accept-Language"ヘッダーフィールド（[RFC7231]のセクション5.3.5を参照）を使用できます（MAY）。

7. SPPP SOAP Data Structures

7. SPPP SOAPデータ構造

SPPP over SOAP uses a set of XML-based data structures for all the supported operations and any parameters to which those operations are applied. As also mentioned earlier in this document, these XML structures are envelope independent and substrate independent. Refer to "Protocol Operations" (Section 8) of this document for a description of all the operations that MUST be supported.

SPPP over SOAPは、サポートされているすべての操作と、それらの操作が適用されるすべてのパラメーターに対して一連のXMLベースのデータ構造を使用します。このドキュメントで前述したように、これらのXML構造はエンベロープに依存せず、素材にも依存しません。サポートする必要があるすべての操作の説明については、このドキュメントの「プロトコル操作」（セクション8）を参照してください。

The following sections describe the definitions of all the XML data structures.

次のセクションでは、すべてのXMLデータ構造の定義について説明します。

7.1. Concrete Object Key Types

7.1. 具体的なオブジェクトキータイプ

Certain operations in SPPF require an object key that uniquely identifies the object(s) on which a given operation needs to be performed. SPPF defines the XML structure of any such object key in an abstract manner and delegates the concrete representation to any conforming substrate protocol. The following subsections define the various types of concrete object key types used in various operations in SPPP over SOAP.

SPPFの特定の操作には、特定の操作を実行する必要があるオブジェクトを一意に識別するオブジェクトキーが必要です。 SPPFは、そのようなオブジェクトキーのXML構造を抽象的な方法で定義し、具体的な表現を準拠する基板プロトコルに委任します。以下のサブセクションでは、SPPP over SOAPのさまざまな操作で使用される具体的なオブジェクトキータイプのさまざまなタイプを定義します。

7.1.1. Generic Object Key

7.1.1. ジェネリックオブジェクトキー

Most objects in SPPP over SOAP are uniquely identified by the attributes in the generic object key (Refer to "Generic Object Key Type", Section 5.2.1 of [RFC7877], for details). The concrete XML representation of ObjKeyType is as below:

SPPP over SOAPのほとんどのオブジェクトは、ジェネリックオブジェクトキーの属性によって一意に識別されます（詳細については、[RFC7877]の「ジェネリックオブジェクトキータイプ」のセクション5.2.1を参照してください）。 ObjKeyTypeの具体的なXML表現は次のとおりです。

      <complexType name="ObjKeyType">
       <complexContent>
        <extension base="sppfb:ObjKeyType">
         <sequence>
          <element name="rant" type="sppfb:OrgIdType"/>
          <element name="name" type="sppfb:ObjNameType"/>
          <element name="type" type="sppfs:ObjKeyTypeEnum"/>
         </sequence>
        </extension>
       </complexContent>
      </complexType>

The ObjKeyType has the data elements as described below:

ObjKeyTypeには、以下に説明するデータ要素があります。

o rant: The identifier of the Registrant organization that owns the object.

o rant：オブジェクトを所有する登録者組織の識別子。

o name: The character string that contains the name of the object.

o name：オブジェクトの名前を含む文字列。

o type: The enumeration value that represents the type of SPPF object. For example, both a Destination Group and a SED Group can have the same name "TestObj" and be associated with the same Registrant ID. Hence, to uniquely identify the object that represents a Destination Group with the name "TestObj", the type "DestGrp" must be specified when using this concrete ObjKeyType structure to identify the Destination Group "TestObj".

o type：SPPFオブジェクトのタイプを表す列挙値。たとえば、宛先グループとSEDグループの両方に同じ名前「TestObj」を付け、同じ登録者IDに関連付けることができます。したがって、「TestObj」という名前の宛先グループを表すオブジェクトを一意に識別するには、この具体的なObjKeyType構造体を使用して宛先グループ「TestObj」を識別するときに、タイプ「DestGrp」を指定する必要があります。

The object types in SPPP over SOAP MUST adhere to the above definition of generic object key and are defined as an enumeration in the XML data structure as follows:

SPPP over SOAPのオブジェクトタイプは、上記の汎用オブジェクトキーの定義に準拠する必要があり、XMLデータ構造の列挙として次のように定義されます。

    <simpleType name="ObjKeyTypeEnum">
      <restriction base="token">
        <enumeration value="SedGrp"/>
        <enumeration value="DestGrp"/>
        <enumeration value="SedRec"/>
        <enumeration value="EgrRte"/>
      </restriction>
    </simpleType>

7.1.2. Public Identifier Object Key

7.1.2. 公開識別子オブジェクトキー

Public Identifier type objects can further be of various sub-types like a Telephone Number (TN), Routing Number (RN), TN Prefix, URI, or TN Range and cannot be cleanly identified with the attributes in the generic ObjKeyType. The definition of PubIdKeyType is as below:

パブリック識別子タイプオブジェクトは、電話番号（TN）、ルーティング番号（RN）、TNプレフィックス、URI、またはTN範囲などのさまざまなサブタイプである可能性があり、一般的なObjKeyTypeの属性で明確に識別することはできません。 PubIdKeyTypeの定義は次のとおりです。

      <complexType name="PubIdKeyType">
       <complexContent>
        <extension base="sppfb:PubIdKeyType">
         <sequence>
          <element name="rant" type="sppfb:OrgIdType"/>
          <choice>
           <element name="number"
           type="sppfb:NumberType"/>
           <element name="range"
            type="sppfb:NumberRangeType"/>
           <element name="uri"
            type="anyURI"/>
          </choice>
         </sequence>
        </extension>
       </complexContent>
      </complexType>

The PubIdKeyType has data elements, as described below:

次に説明するように、PubIdKeyTypeにはデータ要素があります。

o rant: The identifier of the Registrant organization that owns the object.

o rant：オブジェクトを所有する登録者組織の識別子。

o number: An element of type NumberType (refer to Section 12 of [RFC7877]) that contains the value and type of a number.

o 数値：数値の値とタイプを含む、タイプNumberType（[RFC7877]のセクション12を参照）の要素。

o range: An element of type NumberRangeType (refer to Section 12 of [RFC7877]) that contains a range of numbers.

o range：数値の範囲を含む、タイプNumberRangeType（[RFC7877]のセクション12を参照）の要素。

o uri: A value that represents a Public Identifier.

o uri：公開識別子を表す値。

Any instance of PubIdKeyType MUST contain exactly one element from the following set of elements: "number", "range", "uri".

PubIdKeyTypeのインスタンスには、「番号」、「範囲」、「uri」の要素のセットから1つだけ要素を含める必要があります。

7.1.3. SED Group Offer Key

7.1.3. SEDグループオファーキー

In addition to the attributes in the generic ObjKeyType, a SED Group Offer object is uniquely identified by the organization ID of the organization to whom a SED Group has been offered. The definition of SedGrpOfferKeyType is as below:

ジェネリックObjKeyTypeの属性に加えて、SEDグループオファーオブジェクトは、SEDグループが提供された組織の組織IDによって一意に識別されます。 SedGrpOfferKeyTypeの定義は次のとおりです。

      <complexType name="SedGrpOfferKeyType">
       <complexContent>
        <extension base="sppfb:SedGrpOfferKeyType">
         <sequence>
          <element name="sedGrpKey" type="sppfs:ObjKeyType"/>
          <element name="offeredTo" type="sppfb:OrgIdType"/>
         </sequence>
        </extension>
       </complexContent>
      </complexType>

The SedGrpOfferKeyType has the data elements as described below:

SedGrpOfferKeyTypeには、以下に説明するデータ要素があります。

o sedGrpKey: Identifies the SED Group that was offered.

o sedGrpKey：提供されたSEDグループを識別します。

o offeredTo: The organization ID of the organization that was offered the SED Group object identified by the sedGrpKey.

o offerTo：sedGrpKeyによって識別されるSEDグループオブジェクトを提供された組織の組織ID。

7.2. Operation Request and Response Structures

7.2. 操作のリクエストとレスポンスの構造

An SPPF client interacts with an SPPF server by sending one or more requests to the server and by receiving corresponding responses from the server. The basic set of operations that an SPPF client can submit to an SPPF server and the semantics of those operations are defined in "Framework Operations", Section 7 of [RFC7877]. The following subsections describe the XML data structures that are used for each of those types of operations for an SPPP over SOAP implementation.

SPPFクライアントは、1つ以上の要求をサーバーに送信し、サーバーから対応する応答を受信することにより、SPPFサーバーと対話します。 SPPFクライアントがSPPFサーバーに送信できる操作の基本セットとそれらの操作のセマンティクスは、[RFC7877]のセクション7の「フレームワーク操作」で定義されています。次のサブセクションでは、SPPP over SOAP実装のこれらの各タイプの操作に使用されるXMLデータ構造について説明します。

7.2.1. Add Operation Structure

7.2.1. 操作構造を追加

In order to add (or modify) an object in the Registry, an authorized entity can send the spppAddRequest to the Registry.

レジストリにオブジェクトを追加（または変更）するために、承認されたエンティティはspppAddRequestをレジストリに送信できます。

An SPPP over SOAP Add request is wrapped within the <spppAddRequest> element while an SPPP over SOAP Add response is wrapped within an <spppAddResponse> element. The following sub-sections describe the <spppAddRequest> and <spppAddResponse> elements. Refer to Section 10 for an example of an Add operation on each type of SPPF object.

SPPP over SOAP Add要求は<spppAddRequest>要素内にラップされ、SPPP over SOAP Add応答は<spppAddResponse>要素内にラップされます。次のサブセクションでは、<spppAddRequest>および<spppAddResponse>要素について説明します。各タイプのSPPFオブジェクトに対するAdd操作の例については、セクション10を参照してください。

7.2.1.1. Add Request

7.2.1.1. リクエストを追加

An SPPP over SOAP Add request definition is contained within the generic <spppAddRequest> element.

SPPP over SOAP Addリクエストの定義は、一般的な<spppAddRequest>要素に含まれています。

      <element name="spppAddRequest">
       <complexType>
        <sequence>
         <element name="clientTransId"
          type="sppfb:TransIdType" minOccurs="0"/>
         <element name="minorVer"
          type="sppfb:MinorVerType" minOccurs="0"/>
         <element name="obj" type="sppfb:BasicObjType"
         maxOccurs="unbounded"/>
        </sequence>
       </complexType>
      </element>

The data elements within the <spppAddRequest> element are described as follows:

<spppAddRequest>要素内のデータ要素は次のとおりです。

o clientTransId: Zero or one client-generated transaction ID that, within the context of the SPPF client, identifies this request. This value can be used at the discretion of the SPPF client to track, log, or correlate requests and their responses. The SPPF server MUST echo back this value to the client in the corresponding response to the incoming request. The SPPF server will not check this value for uniqueness.

o clientTransId：SPPFクライアントのコンテキスト内でこの要求を識別する、ゼロまたは1つのクライアント生成トランザクションID。この値は、SPPFクライアントの裁量で、要求とその応答を追跡、ログ記録、または相関させるために使用できます。 SPPFサーバーは、着信要求への対応する応答でこの値をクライアントにエコーバックする必要があります。 SPPFサーバーはこの値の一意性をチェックしません。

o minorVer: Zero or one minor version identifier, as defined in Section 7.4.

o minorVer：セクション7.4で定義されているゼロまたは1つのマイナーバージョン識別子。

o obj: One or more elements of abstract type BasicObjType (defined in [RFC7877]). Each element contains all the attributes of an SPPF object that the client is requesting the SPPF server to add. Refer to Section 3.1 of [RFC7877] for the XML structure of all concrete types, for various SPPF objects, that extend from abstract BasicObjType and hence are eligible to be passed into this element. The elements are processed by the SPPF server in the order in which they are included in the request. With respect to the handling of error conditions, conforming SPPP SOAP servers MUST stop processing BasicObjType elements in the request at the first error and roll back any BasicObjType elements that had already been processed for that add request ("stop and roll back").

o obj：抽象型BasicObjTypeの1つ以上の要素（[RFC7877]で定義）。各要素には、クライアントがSPPFサーバーに追加を要求しているSPPFオブジェクトのすべての属性が含まれています。抽象BasicObjTypeから拡張され、したがってこの要素に渡すことができるさまざまなSPPFオブジェクトのすべての具象型のXML構造については、[RFC7877]のセクション3.1を参照してください。要素は、要求に含まれている順序でSPPFサーバーによって処理されます。エラー条件の処理に関して、適合SPPP SOAPサーバーは、最初のエラーで要求のBasicObjType要素の処理を停止し、その追加要求に対してすでに処理されていたBasicObjType要素をロールバックする必要があります（「停止してロールバック」）。

7.2.1.2. Add Response

7.2.1.2. 回答を追加

An SPPP over SOAP add response object is contained within the generic <spppAddResponse> element. This response structure is used for all types of SPPF objects that are provisioned by the SPPF client.

SPPP over SOAP追加応答オブジェクトは、一般的な<spppAddResponse>要素内に含まれています。この応答構造は、SPPFクライアントによってプロビジョニングされるすべてのタイプのSPPFオブジェクトに使用されます。

     <element name="spppAddResponse">
       <complexType>
         <sequence>
           <element name="clientTransId" type="sppfb:TransIdType"
            minOccurs="0"/>
           <element name="serverTransId" type="sppfb:TransIdType"/>
           <element name="overallResult" type="sppfs:ResultCodeType"/>
           <element name="detailResult" type="sppfs:ObjResultCodeType"
           minOccurs="0" maxOccurs="unbounded"/>
         </sequence>
       </complexType>
     </element>

     <complexType name="ResultCodeType">
       <sequence>
          <element name="code" type="int"/>
          <element name="msg" type="string"/>
       </sequence>
     </complexType>

      <complexType name="ObjResultCodeType">
       <complexContent>
        <extension base="sppfs:ResultCodeType">
         <sequence>
          <element name="obj" type="sppfb:BasicObjType"/>
         </sequence>
        </extension>
       </complexContent>
      </complexType>

An <spppAddResponse> contains the elements necessary for the SPPF client to precisely determine the overall result of the request, and if an error occurs, it provides information about the specific object(s) that caused the error.

<spppAddResponse>には、SPPFクライアントが要求の全体的な結果を正確に判断するために必要な要素が含まれ、エラーが発生した場合は、エラーの原因となった特定のオブジェクトに関する情報が提供されます。

The data elements within the SPPP over SOAP Add response are described as follows:

SPPP over SOAP Add応答内のデータ要素は次のとおりです。

o clientTransId: Zero or one client transaction ID. This value is simply an echo of the client transaction ID that the SPPF client passed into the SPPF update request. When included in the request, the SPPF server MUST return it in the corresponding response message.

o clientTransId：ゼロまたは1つのクライアントトランザクションID。この値は、SPPFクライアントがSPPF更新要求に渡したクライアントトランザクションIDの単なるエコーです。要求に含まれる場合、SPPFサーバーは対応する応答メッセージでそれを返す必要があります。

o serverTransId: Exactly one server transaction ID that identifies this request for tracking purposes. This value MUST be unique for a given SPPF server.

o serverTransId：追跡の目的でこの要求を識別する正確に1つのサーバートランザクションID。この値は、特定のSPPFサーバーに対して一意である必要があります。

o overallResult: Exactly one response code and message pair that explicitly identifies the result of the request. See Section 7.3 for further details.

o overallResult：リクエストの結果を明示的に識別する1つの応答コードとメッセージのペア。詳細については、セクション7.3を参照してください。

o detailResult: An optional response code, response message, and BasicObjType (as defined in [RFC7877]) triplet. This element will be present only if an object-level error has occurred. It indicates the error condition and the exact request object that contributed to the error. The response code will reflect the exact error. See Section 7.3 for further details.

o detailResult：オプションの応答コード、応答メッセージ、およびBasicObjType（[RFC7877]で定義）のトリプレット。この要素は、オブジェクトレベルのエラーが発生した場合にのみ存在します。これは、エラー状態と、エラーの原因となった正確な要求オブジェクトを示します。応答コードは正確なエラーを反映します。詳細については、セクション7.3を参照してください。

7.2.2. Delete Operation Structure

7.2.2. 操作構造の削除

In order to remove an object from the Registry, an authorized entity can send the spppDelRequest into the Registry. An SPPP over SOAP Delete request is wrapped within the <spppDelRequest> element while an SPPP over SOAP Delete response is wrapped within the generic <spppDelResponse> element. The following subsections describe the <spppDelRequest> and <spppDelResponse> elements. Refer to Section 10 for an example of the Delete operation on each type of SPPF object.

レジストリからオブジェクトを削除するために、承認されたエンティティはspppDelRequestをレジストリに送信できます。 SPPP over SOAP Delete要求は<spppDelRequest>要素内にラップされ、SPPP over SOAP Delete応答は一般的な<spppDelResponse>要素内にラップされます。次のサブセクションでは、<spppDelRequest>要素と<spppDelResponse>要素について説明します。各タイプのSPPFオブジェクトでの削除操作の例については、セクション10を参照してください。

7.2.2.1. Delete Request

7.2.2.1. リクエストを削除

An SPPP over SOAP Delete request definition is contained within the generic <spppDelRequest> element.

SPPP over SOAP Deleteリクエストの定義は、一般的な<spppDelRequest>要素に含まれています。

      <element name="spppDelRequest">
       <complexType>
        <sequence>
         <element name="clientTransId"
         type="sppfb:TransIdType" minOccurs="0"/>
         <element name="minorVer"
         type="sppfb:MinorVerType" minOccurs="0"/>
        <element name="objKey" type="sppfb:ObjKeyType"
         maxOccurs="unbounded"/>
        </sequence>
       </complexType>
      </element>

The data elements within the <spppDelRequest> element are described as follows:

<spppDelRequest>要素内のデータ要素は次のとおりです。

o clientTransId: Zero or one client-generated transaction ID that, within the context of the SPPF client, identifies this request. This value can be used at the discretion of the SPPF client to track, log, or correlate requests and their responses. The SPPF server MUST echo back this value to the client in the corresponding response to the incoming request. SPPF server will not check this value for uniqueness.

o minorVer: Zero or one minor version identifier, as defined in Section 7.4.

o minorVer：セクション7.4で定義されているゼロまたは1つのマイナーバージョン識別子。

o objKey: One or more elements of abstract type ObjKeyType (as defined in [RFC7877]). Each element contains attributes that uniquely identify the object that the client is requesting the server to delete. Refer to Section 7.1 for a description of all concrete object key types, for various SPPF objects, which are eligible to be passed into this element. The elements are processed by the SPPF server in the order in which they are included in the request. With respect to the handling of error conditions, conforming SPPP SOAP servers MUST stop processing ObjKeyType elements in the request at the first error and roll back any ObjKeyType elements that had already been processed for that Delete request ("stop and roll back").

o objKey：（[RFC7877]で定義されている）抽象型ObjKeyTypeの1つ以上の要素。各要素には、クライアントがサーバーに削除を要求しているオブジェクトを一意に識別する属性が含まれています。この要素に渡すのに適したさまざまなSPPFオブジェクトのすべての具体的なオブジェクトキータイプの説明については、セクション7.1を参照してください。要素は、要求に含まれている順序でSPPFサーバーによって処理されます。エラー条件の処理に関しては、適合するSPPP SOAPサーバーは、最初のエラーで要求内のObjKeyType要素の処理を停止し、その削除要求に対してすでに処理されていたすべてのObjKeyType要素をロールバックする必要があります（「停止してロールバック」）。

7.2.2.2. Delete Response

7.2.2.2. 回答を削除

An SPPP over SOAP delete response object is contained within the generic <sppDeleteResponse> element. This response structure is used for a Delete request on all types of SPPF objects that are provisioned by the SPPF client.

SPPP over SOAP削除応答オブジェクトは、一般的な<sppDeleteResponse>要素内に含まれています。この応答構造は、SPPFクライアントによってプロビジョニングされるすべてのタイプのSPPFオブジェクトの削除要求に使用されます。

   <element name="spppDelResponse">
    <complexType>
     <sequence>
      <element name="clientTransId" type="sppfb:TransIdType"
               minOccurs="0"/>
      <element name="serverTransId" type="sppfb:TransIdType"/>
      <element name="overallResult" type="sppfs:ResultCodeType"/>
      <element name="detailResult" type="sppfs:ObjKeyResultCodeType"
               minOccurs="0" maxOccurs="unbounded"/>
     </sequence>
    </complexType>
   </element>

   <complexType name="ResultCodeType">
    <sequence>
     <element name="code" type="int"/>
     <element name="msg" type="string"/>
    </sequence>
   </complexType>

   <complexType name="ObjKeyResultCodeType">
    <complexContent>
     <extension base="sppfs:ResultCodeType">
      <sequence>
       <element name="objKey" type="sppfb:ObjKeyType"/>
      </sequence>
     </extension>
    </complexContent>
   </complexType>

An <spppDelResponse> contains the elements necessary for the SPPF client to precisely determine the overall result of the request, and if an error occurs, it provides information about the specific object key(s) that caused the error.

<spppDelResponse>には、SPPFクライアントが要求の全体的な結果を正確に判断するために必要な要素が含まれ、エラーが発生した場合は、エラーの原因となった特定のオブジェクトキーに関する情報が提供されます。

The data elements within the SPPP over SOAP Delete response are described as follows:

SPPP over SOAP Delete応答内のデータ要素は次のとおりです。

o serverTransId: Exactly one server transaction ID that identifies this request for tracking purposes. This value MUST be unique for a given SPPF server.

o overallResult: Exactly one response code and message pair that explicitly identifies the result of the request. See Section 7.3 for further details.

o overallResult：リクエストの結果を明示的に識別する1つの応答コードとメッセージのペア。詳細については、セクション7.3を参照してください。

o detailResult: An optional response code, response message, and ObjKeyType (as defined in [RFC7877]) triplet. This element will be present only if a specific object key level error has occurred. It indicates the error condition and the exact request object key that contributed to the error. The response code will reflect the exact error. See Section 7.3 for further details.

o detailResult：オプションの応答コード、応答メッセージ、および（[RFC7877]で定義されている）ObjKeyTypeトリプレット。この要素は、特定のオブジェクトのキーレベルエラーが発生した場合にのみ存在します。これは、エラー状態と、エラーの原因となった正確なリクエストオブジェクトキーを示します。応答コードは正確なエラーを反映します。詳細については、セクション7.3を参照してください。

7.2.3. Accept Operation Structure

7.2.3. 操作構造を受け入れる

In SPPF, a SED Group Offer can be accepted or rejected by, or on behalf of, the Registrant to whom the SED Group has been offered (refer to Section 3.1 of [RFC7877] for a description of the SED Group Offer object). The Accept operation is used to accept such SED Group Offers by, or on behalf of, the Registrant. The request structure for an SPPP over SOAP Accept operation is wrapped within the <spppAcceptRequest> element while an SPPP over SOAP Accept response is wrapped within the generic <spppAcceptResponse> element. The following subsections describe the <spppAcceptRequest> and <spppAcceptResponse> elements. Refer to Section 10 for an example of the Accept operation on a SED Group Offer.

SPPFでは、SEDグループオファーは、SEDグループが提供された登録者によって、またはその代理人として承認または拒否できます（SEDグループオファーオブジェクトの説明については、[RFC7877]のセクション3.1を参照してください）。 Accept操作は、登録者によって、または登録者に代わって、そのようなSEDグループオファーを受け入れるために使用されます。 SPPP over SOAP Acceptオペレーションの要求構造は<spppAcceptRequest>要素内にラップされ、SPPP over SOAP Accept応答は一般的な<spppAcceptResponse>要素内にラップされます。次のサブセクションでは、<spppAcceptRequest>および<spppAcceptResponse>要素について説明します。 SEDグループオファーに対するAccept操作の例については、セクション10を参照してください。

7.2.3.1. Accept Request Structure

7.2.3.1. リクエスト構造を受け入れる

An SPPP over SOAP Accept request definition is contained within the generic <sppAcceptRequest> element.

SPPP over SOAP Acceptリクエストの定義は、一般的な<sppAcceptRequest>要素に含まれています。

      <element name="spppAcceptRequest">
       <complexType>
        <sequence>
         <element name="clientTransId"
         type="sppfb:TransIdType" minOccurs="0"/>
         <element name="minorVer"
         type="sppfb:MinorVerType" minOccurs="0"/>
         <element name="sedGrpOfferKey"
         type="sppfs:SedGrpOfferKeyType"
         maxOccurs="unbounded"/>
        </sequence>
       </complexType>
      </element>

The data elements within the <spppAcceptRequest> element are described as follows:

<spppAcceptRequest>要素内のデータ要素は次のとおりです。

o minorVer: Zero or one minor version identifier, as defined in Section 7.4.

o minorVer：セクション7.4で定義されているゼロまたは1つのマイナーバージョン識別子。

o sedGrpOfferKey: One or more elements of type SedGrpOfferKeyType (as defined in this document). Each element contains attributes that uniquely identify a SED Group Offer that the client is requesting the server to accept. The elements are processed by the SPPF server in the order in which they are included in the request. With respect to the handling of error conditions, conforming SPPP SOAP servers MUST stop processing SedGrpOfferKeyType elements in the request at the first error and roll back any SedGrpOfferKeyType elements that had already been processed for that Accept request ("stop and roll back").

o sedGrpOfferKey：タイプSedGrpOfferKeyType（このドキュメントで定義）の1つ以上の要素。各要素には、クライアントがサーバーに受け入れるように要求しているSEDグループオファーを一意に識別する属性が含まれています。要素は、要求に含まれている順序でSPPFサーバーによって処理されます。エラー条件の処理に関して、適合SPPP SOAPサーバーは、最初のエラーで要求のSedGrpOfferKeyType要素の処理を停止し、そのAccept要求に対してすでに処理されていたSedGrpOfferKeyType要素をロールバックする必要があります（「停止してロールバック」）。

7.2.3.2. Accept Response

7.2.3.2. 応答を受け入れる

An SPPP over SOAP accept response structure is contained within the generic <sppAcceptResponse> element. This response structure is used for an Accept request on a SED Group Offer.

SPPP over SOAPのAccept応答構造は、一般的な<sppAcceptResponse>要素に含まれています。この応答構造は、SEDグループオファーのAcceptリクエストに使用されます。

   <element name="spppAcceptResponse">
    <complexType>
     <sequence>
      <element name="clientTransId" type="sppfb:TransIdType"
               minOccurs="0"/>
      <element name="serverTransId" type="sppfb:TransIdType"/>
      <element name="overallResult" type="sppfs:ResultCodeType"/>
      <element name="detailResult"
               type="sppfs:SedGrpOfferKeyResultCodeType"
               minOccurs="0" maxOccurs="unbounded"/>
     </sequence>
    </complexType>
   </element>

   <complexType name="ResultCodeType">
    <sequence>
     <element name="code" type="int"/>
     <element name="msg" type="string"/>
    </sequence>
   </complexType>

   <complexType name="SedGrpOfferKeyResultCodeType">
    <complexContent>
     <extension base="sppfs:ResultCodeType">
      <sequence>
       <element name="sedGrpOfferKey" type="sppfs:SedGrpOfferKeyType"/>
      </sequence>
     </extension>
    </complexContent>
   </complexType>

An <spppAcceptResponse> contains the elements necessary for the SPPF client to precisely determine the overall result of the request, and if an error occurs, it provides information about the specific SED Group Offer key(s) that caused the error.

<spppAcceptResponse>には、SPPFクライアントが要求の全体的な結果を正確に判断するために必要な要素が含まれ、エラーが発生した場合は、エラーの原因となった特定のSEDグループオファーキーに関する情報が提供されます。

The data elements within the SPPP over SOAP Accept response are described as follows:

SPPP over SOAP Accept応答内のデータ要素は次のとおりです。

o serverTransId: Exactly one server transaction ID that identifies this request for tracking purposes. This value MUST be unique for a given SPPF server.

o overallResult: Exactly one response code and message pair that explicitly identifies the result of the request. See Section 7.3 for further details.

o overallResult：リクエストの結果を明示的に識別する1つの応答コードとメッセージのペア。詳細については、セクション7.3を参照してください。

o detailResult: An optional response code, response message, and SedGrpOfferKeyType (as defined in this document) triplet. This element will be present only if any specific SED Group Offer key level error has occurred. It indicates the error condition and the exact request SED Group Offer key that contributed to the error. The response code will reflect the exact error. See Section 7.3 for further details.

o detailResult：オプションの応答コード、応答メッセージ、およびSedGrpOfferKeyType（このドキュメントで定義）のトリプレット。この要素は、特定のSEDグループオファーのキーレベルエラーが発生した場合にのみ存在します。これは、エラー状態と、エラーの原因となった正確な要求SEDグループオファーキーを示します。応答コードは正確なエラーを反映します。詳細については、セクション7.3を参照してください。

7.2.4. Reject Operation Structure

7.2.4. 拒否操作の構造

In SPPF, a SED Group Offer can be accepted or rejected by, or on behalf of, the Registrant to whom the SED Group has been offered (refer to "Framework Data Model Objects", Section 6 of [RFC7877] for a description of the SED Group Offer object). The Reject operation is used to reject such SED Group Offers by, or on behalf of, the Registrant. The request structure for an SPPP over SOAP Reject operation is wrapped within the <spppRejectRequest> element while an SPPP over SOAP Reject response is wrapped within the generic <spppRejecResponse> element. The following subsections describe the <spppRejectRequest> and <spppRejecResponse> elements. Refer to Section 10 for an example of the Reject operation on a SED Group Offer.

SPPFでは、SEDグループオファーは、SEDグループが提供された登録者によって、またはその代理人として承認または拒否できます（詳細については、[RFC7877]の「フレームワークデータモデルオブジェクト」のセクション6を参照してください）。 SED Group Offerオブジェクト）。拒否操作は、登録者によって、または登録者に代わって、そのようなSEDグループオファーを拒否するために使用されます。 SPPP over SOAP拒否操作の要求構造は<spppRejectRequest>要素内にラップされ、SPPP over SOAP拒否応答は一般的な<spppRejecResponse>要素内にラップされます。次のサブセクションでは、<spppRejectRequest>および<spppRejecResponse>要素について説明します。 SEDグループオファーに対する拒否操作の例については、セクション10を参照してください。

7.2.4.1. Reject Request

7.2.4.1. リクエストを拒否

An SPPP over SOAP Reject request definition is contained within the generic <spppRejectRequest> element.

SPPP over SOAP拒否リクエストの定義は、一般的な<spppRejectRequest>要素に含まれています。

      <element name="spppRejectRequest">
       <complexType>
        <sequence>
         <element name="clientTransId"
         type="sppfb:TransIdType" minOccurs="0"/>
         <element name="minorVer"
         type="sppfb:MinorVerType" minOccurs="0"/>
         <element name="sedGrpOfferKey"
         type="sppfs:SedGrpOfferKeyType"
         maxOccurs="unbounded"/>
        </sequence>
       </complexType>
      </element>

The data elements within the <spppRejectRequest> element are described as follows:

<spppRejectRequest>要素内のデータ要素は次のとおりです。

o minorVer: Zero or one minor version identifier, as defined in Section 7.4.

o minorVer：セクション7.4で定義されているゼロまたは1つのマイナーバージョン識別子。

o sedGrpOfferKey: One or more elements of type SedGrpOfferKeyType (as defined in this document). Each element contains attributes that uniquely identify a SED Group Offer that the client is requesting the server to reject. The elements are processed by the SPPF server in the order in which they are included in the request. With respect to the handling of error conditions, conforming SPPF servers MUST stop processing SedGrpOfferKeyType elements in the request at the first error and roll back any SedGrpOfferKeyType elements that had already been processed for that Reject request ("stop and roll back").

o sedGrpOfferKey：タイプSedGrpOfferKeyType（このドキュメントで定義）の1つ以上の要素。各要素には、クライアントがサーバーに拒否を要求しているSEDグループオファーを一意に識別する属性が含まれています。要素は、要求に含まれている順序でSPPFサーバーによって処理されます。エラー条件の処理に関しては、適合SPPFサーバーは、最初のエラーで要求のSedGrpOfferKeyType要素の処理を停止し、その拒否要求に対してすでに処理されていたSedGrpOfferKeyType要素をロールバックする必要があります（「停止してロールバック」）。

7.2.4.2. Reject Response

7.2.4.2. 応答を拒否

An SPPP over SOAP reject response structure is contained within the generic <sppRejectResponse> element. This response structure is used for a Reject request on a SED Group Offer.

SPPP over SOAPの拒否応答構造は、一般的な<sppRejectResponse>要素内に含まれています。この応答構造は、SEDグループオファーの拒否リクエストに使用されます。

   <element name="spppRejectResponse">
    <complexType>
     <sequence>
      <element name="clientTransId" type="sppfb:TransIdType"
               minOccurs="0"/>
      <element name="serverTransId" type="sppfb:TransIdType"/>
      <element name="overallResult" type="sppfs:ResultCodeType"/>
      <element name="detailResult"
               type="sppfs:SedGrpOfferKeyResultCodeType"
               minOccurs="0" maxOccurs="unbounded"/>
     </sequence>
    </complexType>
   </element>

   <complexType name="ResultCodeType">
    <sequence>
     <element name="code" type="int"/>
     <element name="msg" type="string"/>
    </sequence>
   </complexType>

   <complexType name="SedGrpOfferKeyResultCodeType">
    <complexContent>
     <extension base="sppfs:ResultCodeType">
      <sequence>
       <element name="sedGrpOfferKey" type="sppfs:SedGrpOfferKeyType"/>
      </sequence>
     </extension>
    </complexContent>
   </complexType>

An <spppRejectResponse> contains the elements necessary for the SPPF client to precisely determine the overall result of the request, and if an error occurs, it provides information about the specific SED Group Offer key(s) that caused the error.

<spppRejectResponse>には、SPPFクライアントが要求の全体的な結果を正確に判断するために必要な要素が含まれ、エラーが発生した場合は、エラーの原因となった特定のSEDグループオファーキーに関する情報が提供されます。

The data elements within the SPPP over SOAP Reject response are described as follows:

SPPP over SOAP Reject応答内のデータ要素は次のとおりです。

o serverTransId: Exactly one server transaction ID that identifies this request for tracking purposes. This value MUST be unique for a given SPPF server.

o overallResult: Exactly one response code and message pair that explicitly identifies the result of the request. See Section 7.3 for further details.

o overallResult：リクエストの結果を明示的に識別する1つの応答コードとメッセージのペア。詳細については、セクション7.3を参照してください。

7.2.5. Batch Operation Structure

7.2.5. バッチ操作の構造

An SPPP over SOAP Batch request XML structure allows the SPPF client to send any of the Add, Del, Accept, or Reject operations together in one single request. This gives an SPPF client the flexibility to use one single request structure to perform more than operations (verbs). The batch request structure is wrapped within the <spppBatchRequest> element while an SPPF Batch response is wrapped within the <spppBatchResponse> element. The following subsections describe the <spppBatchRequest> and <spppBatchResponse> elements. Refer to Section 10 for an example of a Batch operation.

SPPP over SOAPバッチリクエストのXML構造により、SPPFクライアントは、追加、削除、承認、または拒否の操作を1つのリクエストでまとめて送信できます。これにより、SPPFクライアントは、単一の要求構造を使用して、操作（動詞）以外のものを実行する柔軟性を与えます。バッチ要求構造は<spppBatchRequest>要素内にラップされ、SPPFバッチ応答は<spppBatchResponse>要素内にラップされます。次のサブセクションでは、<spppBatchRequest>および<spppBatchResponse>要素について説明します。バッチ操作の例については、セクション10を参照してください。

7.2.5.1. Batch Request Structure

7.2.5.1. バッチリクエストの構造

An SPPP over SOAP Batch request definition is contained within the generic <spppBatchRequest> element.

SPPP over SOAP Batchリクエスト定義は、一般的な<spppBatchRequest>要素内に含まれています。

       <element name="spppBatchRequest">
       <complexType>
        <sequence>
         <element name="clientTransId"
         type="sppfb:TransIdType" minOccurs="0"/>
         <element name="minorVer"
         type="sppfb:MinorVerType" minOccurs="0"/>
          <choice minOccurs="1" maxOccurs="unbounded">
           <element name="addObj" type="sppfb:BasicObjType"/>
           <element name="delObj" type="sppfb:ObjKeyType"/>
           <element name="acceptSedGrpOffer"
           type="sppfs:SedGrpOfferKeyType"/>
           <element name="rejectSedGrpOffer"
           type="sppfs:SedGrpOfferKeyType"/>
          </choice>
        </sequence>
       </complexType>
      </element>

The data elements within the <sppBatchRequest> element are described as follows:

<sppBatchRequest>要素内のデータ要素は次のとおりです。

o minorVer: Zero or one minor version identifier, as defined in Section 7.4.

o minorVer：セクション7.4で定義されているゼロまたは1つのマイナーバージョン識別子。

o addObj: One or more elements of abstract type BasicObjType where each element identifies an object that needs to be added.

o addObj：抽象型BasicObjTypeの1つ以上の要素。各要素は、追加する必要があるオブジェクトを識別します。

o delObj: One or more elements of abstract type ObjKeyType where each element identifies a key for the object that needs to be deleted .

o delObj：抽象型ObjKeyTypeの1つ以上の要素。各要素は、削除する必要があるオブジェクトのキーを識別します。

o acceptSedGrpOffer: One or more elements of type SedGrpOfferKeyType where each element identifies a SED Group Offer that needs to be accepted.

o acceptSedGrpOffer：タイプSedGrpOfferKeyTypeの1つ以上のエレメント。各エレメントは、受け入れる必要があるSEDグループオファーを識別します。

o rejectSedGrpOffer: One or more elements of type SedGrpOfferKeyType where each element identifies a SED Group Offer that needs to be rejected.

o rejectSedGrpOffer：タイプSedGrpOfferKeyTypeの1つ以上のエレメント。各エレメントは、拒否する必要があるSEDグループオファーを識別します。

With respect to the handling of error conditions, conforming SPPP SOAP servers MUST stop processing elements in the request at the first error and roll back any elements that had already been processed for that Batch request ("stop and roll back").

エラー条件の処理に関しては、適合SPPP SOAPサーバーは、最初のエラーで要求内の要素の処理を停止し、そのバッチ要求に対してすでに処理されていた要素をすべてロールバックする必要があります（「停止およびロールバック」）。

7.2.5.2. Batch Response

7.2.5.2. バッチ応答

An SPPP over SOAP batch response structure is contained within the generic <sppBatchResponse> element. This response structure is used for a Batch request that contains many different types of SPPF operations.

SPPP over SOAPバッチ応答構造は、一般的な<sppBatchResponse>要素内に含まれています。この応答構造は、さまざまなタイプのSPPF操作を含むBatchリクエストに使用されます。

     <element name="spppBatchResponse">
       <complexType>
         <sequence>
           <element name="clientTransId" type="sppfb:TransIdType"
            minOccurs="0"/>
           <element name="serverTransId" type="sppfb:TransIdType"/>
           <element name="overallResult" type="sppfs:ResultCodeType"/>
           <choice minOccurs="0" maxOccurs="unbounded">
              <element name="addResult"
              type="sppfs:ObjResultCodeType"/>
              <element name="delResult"
              type="sppfs:ObjKeyResultCodeType"/>
              <element name="acceptResult"
              type="sppfs:SedGrpOfferKeyResultCodeType"/>
              <element name="rejectResult"
              type="sppfs:SedGrpOfferKeyResultCodeType"/>
            </choice>
         </sequence>
       </complexType>
     </element>

An <spppBatchResponse> contains the elements necessary for an SPPF client to precisely determine the overall result of various operations in the request, and if an error occurs, it provides information about the specific objects or keys in the request that caused the error.

<spppBatchResponse>には、SPPFクライアントがリクエスト内のさまざまな操作の全体的な結果を正確に判断するために必要な要素が含まれ、エラーが発生した場合、エラーの原因となったリクエスト内の特定のオブジェクトまたはキーに関する情報を提供します。

The data elements within the SPPP over SOAP Batch response are described as follows:

SPPP over SOAP Batch応答内のデータ要素は次のとおりです。

o serverTransId: Exactly one server transaction ID that identifies this request for tracking purposes. This value MUST be unique for a given SPPF server.

o overallResult: Exactly one response code and message pair that explicitly identifies the result of the request. See Section 7.3 for further details.

o overallResult：リクエストの結果を明示的に識別する1つの応答コードとメッセージのペア。詳細については、セクション7.3を参照してください。

o addResult: One or more elements of type ObjResultCodeType where each element identifies the result code, result message, and the specific object to which the result relates.

o addResult：ObjResultCodeTypeタイプの1つ以上の要素。各要素は、結果コード、結果メッセージ、および結果が関連する特定のオブジェクトを識別します。

o delResult: One or more elements of type ObjKeyResultCodeType where each element identifies the result code, result message, and the specific object key to which the result relates.

o delResult：ObjKeyResultCodeTypeタイプの1つ以上の要素。各要素は、結果コード、結果メッセージ、および結果が関連する特定のオブジェクトキーを識別します。

o acceptResult: One or more elements of type SedGrpOfferKeyResultCodeType where each element identifies the result code, result message, and the specific SED Group Offer key to which the result relates.

o acceptResult：タイプSedGrpOfferKeyResultCodeTypeの1つ以上のエレメント。各エレメントは、結果コード、結果メッセージ、および結果が関連する特定のSEDグループオファーキーを識別します。

o rejectResult: One or more elements of type SedGrpOfferKeyResultCodeType where each element identifies the result code, result message, and the specific SED Group Offer key to which the result relates.

o rejectResult：タイプSedGrpOfferKeyResultCodeTypeの1つ以上のエレメント。各エレメントは、結果コード、結果メッセージ、および結果が関連する特定のSEDグループオファーキーを識別します。

7.2.6. Get Operation Structure

7.2.6. 操作構造を取得

In order to query the details of an object from the Registry, an authorized entity can send the spppGetRequest to the Registry with a GetRqstType XML data structure containing one or more object keys that uniquely identify the object whose details are being queried. The following subsections describe the <spppGetRequest> and <spppGetResponse> elements. Refer to Section 10 for an example of the SPPP over SOAP Get operation on each type of SPPF object.

レジストリからオブジェクトの詳細を照会するために、承認されたエンティティは、詳細が照会されているオブジェクトを一意に識別する1つ以上のオブジェクトキーを含むGetRqstType XMLデータ構造を使用して、spppGetRequestをレジストリに送信できます。次のサブセクションでは、<spppGetRequest>および<spppGetResponse>要素について説明します。各タイプのSPPFオブジェクトでのSPPP over SOAP Get操作の例については、セクション10を参照してください。

7.2.6.1. Get Request

7.2.6.1. リクエストを取得

The request structure for an SPPP over SOAP Get operation is contained within the generic <spppGetRequest> element:

SPPP over SOAP Getオペレーションのリクエスト構造は、一般的な<spppGetRequest>要素に含まれています。

      <element name="spppGetRequest">
       <complexType>
        <sequence>
         <element name="minorVer"
         type="sppfb:MinorVerType" minOccurs="0"/>
         <element name="objKey"
         type="sppfb:ObjKeyType"
         maxOccurs="unbounded"/>
        </sequence>
       </complexType>
      </element>

The data elements within the <spppGetRequest> element are described as follows:

<spppGetRequest>要素内のデータ要素は次のとおりです。

o minorVer: Zero or one minor version identifier, as defined in Section 7.4.

o minorVer：セクション7.4で定義されているゼロまたは1つのマイナーバージョン識別子。

o objKey：（[RFC7877]で定義されている）抽象型ObjKeyTypeの1つ以上の要素。各要素には、クライアントがサーバーにクエリを要求しているオブジェクトを一意に識別する属性が含まれています。この要素に渡すのに適したさまざまなSPPFオブジェクトのすべての具象オブジェクトキータイプの説明については、このドキュメントのセクション7.1を参照してください。

7.2.6.2. Get Response

7.2.6.2. 応答を取得

The SPPP over SOAP Get response is wrapped within the generic <spppGetResponse> element, as described in Section 7.2.8.

セクション7.2.8で説明されているように、SPPP over SOAP Get応答は、汎用の<spppGetResponse>要素内にラップされています。

7.2.7. Get SED Group Offers Operation Structure

7.2.7. SEDグループオファーの操作構造を取得する

In addition to the ability to query the details of one or more SED Group Offers using a SED Group Offer key in the spppGetRequest, this operation also provides an additional, more flexible, structure to query for SED Group Offer objects. This additional structure is contained within the <getSedGrpOffersRequest> element while the response is wrapped within the generic <spppGetResponse> element. The following subsections describe the <getSedGrpOffersRequest> and <spppGetResponse> elements.

この操作は、spppGetRequestでSEDグループオファーキーを使用して1つ以上のSEDグループオファーの詳細をクエリする機能に加えて、SEDグループオファーオブジェクトをクエリするための追加のより柔軟な構造も提供します。この追加の構造は<getSedGrpOffersRequest>要素内に含まれ、応答は汎用の<spppGetResponse>要素内にラップされます。次のサブセクションでは、<getSedGrpOffersRequest>および<spppGetResponse>要素について説明します。

7.2.7.1. Get SED Group Offers Request

7.2.7.1. SEDグループオファーリクエストの取得

Using the details passed into this structure, the server will attempt to find SED Group Offer objects that satisfy all the criteria passed into the request. If no criteria are passed in, then the SPPF server will return the list of SED Group Offer objects that belong to the Registrant. If there are no matching SED Group Offers found, then an empty result set will be returned.

サーバーは、この構造に渡された詳細を使用して、要求に渡されたすべての基準を満たすSEDグループオファーオブジェクトを見つけようとします。基準が渡されない場合、SPPFサーバーは登録者に属するSEDグループオファーオブジェクトのリストを返します。一致するSEDグループオファーが見つからない場合、空の結果セットが返されます。

       <element name="getSedGrpOffersRequest">
       <complexType>
        <sequence>
         <element name="minorVer" type="sppfb:MinorVerType"
         minOccurs="0"/>
        <element name="offeredBy" type="sppfb:OrgIdType"
        minOccurs="0" maxOccurs="unbounded"/>
        <element name="offeredTo" type="sppfb:OrgIdType"
        minOccurs="0" maxOccurs="unbounded"/>
        <element name="status" type="sppfb:SedGrpOfferStatusType"
         minOccurs="0"/>
        <element name="sedGrpOfferKey" type="sppfs:SedGrpOfferKeyType"
        minOccurs="0" maxOccurs="unbounded"/>
        </sequence>
       </complexType>
      </element>

The data elements within the <getSedGrpOffersRequest> element are described as follows:

<getSedGrpOffersRequest>要素内のデータ要素は次のとおりです。

o minorVer: Zero or one minor version identifier, as defined in Section 7.4.

o minorVer：セクション7.4で定義されているゼロまたは1つのマイナーバージョン識別子。

o offeredBy: Zero or more organization IDs. Only offers that are offered to the organization IDs in this list should be included in the result set. The result set is also subject to other query criteria in the request.

o offerBy：0個以上の組織ID。このリストの組織IDに提供されているオファーのみが結果セットに含まれます。結果セットは、リクエスト内の他のクエリ基準にも影響を受けます。

o offeredTo: Zero or more organization IDs. Only offers that are offered by the organization IDs in this list should be included in the result set. The result set is also subject to other query criteria in the request.

o offerTo：0個以上の組織ID。このリストの組織IDによって提供されるオファーのみを結果セットに含める必要があります。結果セットは、リクエスト内の他のクエリ基準にも影響を受けます。

o status: The status of the offer, offered or accepted. Only offers in the specified status should be included in the result set. If this element is not present, then the status of the offer should not be considered in the query. The result set is also subject to other query criteria in the request.

o status：オファーのステータス、オファー済みまたは受け入れ済み。指定したステータスのオファーのみを結果セットに含める必要があります。この要素が存在しない場合、オファーのステータスはクエリで考慮されません。結果セットは、リクエスト内の他のクエリ基準にも影響を受けます。

o sedGrpOfferKey: Zero or more SED Group Offer keys. Only offers having one of these keys should be included in the result set. The result set is also subject to other query criteria in the request.

o sedGrpOfferKey：0個以上のSEDグループオファーキー。これらのキーの1つを持つオファーのみを結果セットに含める必要があります。結果セットは、リクエスト内の他のクエリ基準にも影響を受けます。

7.2.7.2. Get SED Group Offers Response

7.2.7.2. SED Group Offers Responseを取得する

The spppGetResponse element is described in Section 7.2.8.

spppGetResponse要素については、セクション7.2.8で説明しています。

7.2.8. Generic Query Response

7.2.8. 一般的なクエリ応答

An SPPP over SOAP query response object is contained within the generic <spppGetResponse> element.

SPPP over SOAPクエリ応答オブジェクトは、一般的な<spppGetResponse>要素内に含まれています。

      <element name="spppGetResponse">
       <complexType>
        <sequence>
         <element name="overallResult"
         type="sppfs:ResultCodeType"/>
         <element name="resultObj"
         type="sppfb:BasicObjType"
         minOccurs="0" maxOccurs="unbounded"/>
        </sequence>
       </complexType>
      </element>

An <spppGetResponse> contains the elements necessary for the SPPF client to precisely determine the overall result of the query and details of any SPPF objects that matched the criteria in the request.

<spppGetResponse>には、SPPFクライアントがクエリの全体的な結果と、リクエストの基準に一致したすべてのSPPFオブジェクトの詳細を正確に決定するために必要な要素が含まれています。

The data elements within the SPPP over SOAP query response are described as follows:

SPPP over SOAPクエリ応答内のデータ要素は、次のように説明されます。

o overallResult: Exactly one response code and message pair that explicitly identifies the result of the request. See Section 7.3 for further details.

o overallResult：リクエストの結果を明示的に識別する1つの応答コードとメッセージのペア。詳細については、セクション7.3を参照してください。

o resultObj: The set of zero or more objects that matched the query criteria. If no objects matched the query criteria, then the result object(s) MUST be empty and the overallResult value MUST indicate success (if no matches are found for the query criteria, the response is considered a success).

o resultObj：クエリ条件に一致した0個以上のオブジェクトのセット。クエリ基準に一致するオブジェクトがない場合、結果オブジェクトは空である必要があり、overallResult値は成功を示す必要があります（クエリ基準に一致するものが見つからない場合、応答は成功と見なされます）。

7.2.9. Get Server Details Operation Structure

7.2.9. サーバー詳細操作構造の取得

In order to query certain details of the SPPF server, such as the SPPF server's status and the major/minor version supported by the server, the Server Details operation structure SHOULD be used. This structure is contained within the <spppServerStatusRequest> element whereas an SPPF server status response is wrapped within the <spppServerStatusResponse> element. The following subsections describe the <spppServerStatusRequest> and <spppServerStatusResponse> elements.

SPPFサーバーのステータスやサーバーでサポートされているメジャー/マイナーバージョンなど、SPPFサーバーの特定の詳細をクエリするには、Server Details操作構造を使用する必要があります（SHOULD）。この構造は<spppServerStatusRequest>要素内に含まれていますが、SPPFサーバーステータス応答は<spppServerStatusResponse>要素内でラップされています。以下のサブセクションでは、<spppServerStatusRequest>および<spppServerStatusResponse>要素について説明します。

7.2.9.1. Get Server Details Request

7.2.9.1. サーバー詳細リクエストの取得

An SPPP over SOAP server details request structure is represented in the <spppServerStatusRequest> element as follows:

SPPP over SOAPサーバーの詳細要求構造は、<spppServerStatusRequest>要素で次のように表されます。

      <element name="spppServerStatusRequest">
       <complexType>
        <sequence>
         <element name="minorVer"
         type="sppfb:MinorVerType" minOccurs="0"/>
        </sequence>
       </complexType>
      </element>

The data elements within the <spppServerStatusRequest> element are described as follows:

<spppServerStatusRequest>要素内のデータ要素は次のとおりです。

o minorVer: Zero or one minor version identifier, as defined in Section 7.4.

o minorVer：セクション7.4で定義されているゼロまたは1つのマイナーバージョン識別子。

7.2.9.2. Get Server Details Response

7.2.9.2. サーバー詳細応答の取得

An SPPP over SOAP server details response structure is contained within the generic <spppServerStatusResponse> element.

SPPP over SOAPサーバーの詳細応答構造は、一般的な<spppServerStatusResponse>要素に含まれています。

      <element name="spppServerStatusResponse">
       <complexType>
        <sequence>
         <element name="overallResult" type="sppfs:ResultCodeType"/>
         <element name="svcMenu" type="sppfb:SvcMenuType"/>
        </sequence>
       </complexType>
      </element>

The data elements within the <spppServerStatusResponse> element are described as follows:

<spppServerStatusResponse>要素内のデータ要素は次のとおりです。

o overallResult: Exactly one response code and message pair that explicitly identifies the result of the request. See Section 7.3 for further details.

o overallResult：リクエストの結果を明示的に識別する1つの応答コードとメッセージのペア。詳細については、セクション7.3を参照してください。

o svcMenu: Exactly one element of type SvcMenuType that, in turn, contains the elements to return the server status, the major and minor versions of SPPP over SOAP supported by the SPPF server (refer to Section 12 of [RFC7877] for the definition of SvcMenuType).

o svcMenu：タイプSvcMenuTypeの1つの要素。これには、サーバーステータスを返す要素、SPPFサーバーでサポートされるSOAP上のSPPP over SOAPのメジャーバージョンとマイナーバージョンが含まれます（SvcMenuTypeの定義については、[RFC7877]のセクション12を参照してください））。

7.3. Response Codes and Messages

7.3. 応答コードとメッセージ

This section contains the listing of response codes and their corresponding human-readable text. These response codes are in conformance with the response types defined in Section 5.3 of [RFC7877].

このセクションには、応答コードとそれに対応する人間が読めるテキストのリストが含まれています。これらの応答コードは、[RFC7877]のセクション5.3で定義されている応答タイプに準拠しています。

The response code numbering scheme generally adheres to the theory formalized in Section 4.2.1 of [RFC5321]:

応答コードの番号付け方式は、一般に[RFC5321]のセクション4.2.1で形式化された理論に準拠しています。

o The first digit of the response code can only be 1 or 2: 1 = a positive result, and 2 = a negative result.

o 応答コードの最初の桁は1または2のみです。1=肯定的な結果、2 =否定的な結果。

o The second digit of the response code indicates the category: 0 = Protocol Syntax, 1 = Implementation Specific Business Rule, 2 = Security, and 3 = Server System.

o 応答コードの2桁目はカテゴリを示します。0=プロトコル構文、1 =実装固有のビジネスルール、2 =セキュリティ、3 =サーバーシステム。

o The third and fourth digits of the response code indicate the individual message event within the category defined by the first two digits.

o 応答コードの3桁目と4桁目は、最初の2桁で定義されたカテゴリ内の個々のメッセージイベントを示します。

The response codes are also categorized as to whether they are overall response codes that may only be returned in the overallResult data element in SPPF responses or object-level response codes that may only be returned in the detailResult element of the SPPF responses.

応答コードは、SPPF応答のOverallResultデータ要素でのみ返される可能性がある全体的な応答コードであるか、SPPF応答のdetailResult要素でのみ返される可能性があるオブジェクトレベルの応答コードであるかについても分類されます。

   +--------+--------------------------+-------------------------------+
   | Result | Result Message           | Overall or Object Level       |
   | Code   |                          |                               |
   +--------+--------------------------+-------------------------------+
   | 1000   | Request succeeded        | Overall Response Code         |
   | 2000   | Request syntax invalid   | Overall Response Code         |
   | 2001   | Request too large        | Overall Response Code         |
   |        | MaxSupported:[Maximum    |                               |
   |        | requests supported]      |                               |
   | 2002   | Version not supported    | Overall Response Code         |
   | 2100   | Command invalid          | Overall Response Code         |
   | 2300   | System temporarily       | Overall Response Code         |
   |        | unavailable              |                               |
   | 2301   | Unexpected internal      | Overall Response Code         |
   |        | system or server error   |                               |
   | 2101   | Attribute value invalid  | Object-Level Response Code    |
   |        | AttrName:[AttributeName] |                               |
   |        | AttrVal:[AttributeValue] |                               |
   | 2102   | Object does not exist    | Object-Level Response Code    |
   |        | AttrName:[AttributeName] |                               |
   |        | AttrVal:[AttributeValue] |                               |
   | 2103   | Object status or         | Object-Level Response Code    |
   |        | ownership does not allow |                               |
   |        | for operation            |                               |
   |        | AttrName:[AttributeName] |                               |
   |        | AttrVal:[AttributeValue] |                               |
   +--------+--------------------------+-------------------------------+

Table 1: Response Code Numbering Scheme and Messages

表1：応答コードの番号付け方式とメッセージ

The response message for response code 2001 is "parameterized" with the following parameter: "[Maximum requests supported]". When the request is too large, this parameter MUST be used to indicate the maximum number of requests supported by the server in a single protocol operation.

応答コード2001の応答メッセージは、「[サポートされている最大要求数]」というパラメーターで「パラメーター化」されています。リクエストが大きすぎる場合、このパラメータを使用して、単一のプロトコル操作でサーバーがサポートするリクエストの最大数を示す必要があります。

Response code 2000 SHOULD be used when the XML Schema validation of requests fails.

リクエストのXMLスキーマ検証が失敗した場合、レスポンスコード2000を使用する必要があります。

Each of the object-level response messages are "parameterized" with the following parameters: "AttributeName" and "AttributeValue".

オブジェクトレベルの各応答メッセージは、「AttributeName」と「AttributeValue」というパラメーターで「パラメーター化」されています。

For example, if an SPPF client sends a request to delete a Destination Group with a name "TestDG", and it does not already exist, then the error message returned should be: "Attribute value invalid. AttrName:dgName AttrVal:TestDG".

たとえば、SPPFクライアントが「TestDG」という名前の宛先グループを削除するリクエストを送信し、それがまだ存在しない場合、返されるエラーメッセージは「属性値が無効です。AttrName：dgName AttrVal：TestDG」です。

The use of these parameters MUST adhere to the rules defined in Section 5.3 of [RFC7877].

これらのパラメータの使用は、[RFC7877]のセクション5.3で定義されたルールに準拠する必要があります。

7.4. Minor Version Identifier

7.4. マイナーバージョン識別子

The minor version identifier element is defined as follows:

マイナーバージョン識別子要素は次のように定義されます。

o minorVer: Zero or one minor version identifier, indicating the minor version of the SPPP over SOAP API that the client is attempting to use. This is used in conjunction with the major version identifier in the XML Namespace to identify the version of SPPP over SOAP that the client is using. If the element is not present, the server assumes that the client is using the latest minor version of SPPP over SOAP supported by the SPPF server for the given major version. The versions of SPPP over SOAP supported by a given SPPF server can be retrieved by the client using this same spppServerStatusRequest without passing in the minorVer element.

o minorVer：ゼロまたは1つのマイナーバージョン識別子。クライアントが使用しようとしているSPPP over SOAP APIのマイナーバージョンを示します。これは、XML名前空間のメジャーバージョン識別子と共に使用され、クライアントが使用しているSPPP over SOAPのバージョンを識別します。要素が存在しない場合、サーバーは、クライアントが特定のメジャーバージョンのSPPFサーバーでサポートされるSOAPの最新のマイナーバージョンを使用していると想定します。特定のSPPFサーバーでサポートされているSPPP over SOAPのバージョンは、minorVer要素を渡さずに、この同じspppServerStatusRequestを使用してクライアントで取得できます。

8. Protocol Operations

8. プロトコル操作

Refer to Section 7 of [RFC7877] for a description of all SPPF operations and any necessary semantics that MUST be adhered to in order to conform with SPPF.

SPPFに準拠するために順守する必要があるすべてのSPPF操作と必要なセマンティクスについては、[RFC7877]のセクション7を参照してください。

9. SPPP over SOAP WSDL Definition

9. SPPP over SOAP WSDL定義

The SPPP over SOAP WSDL and data types are defined below. The WSDL design approach is commonly referred to as "Generic WSDL". It is generic in the sense that there is not a specific WSDL operation defined for each object type that is supported by the SPPF protocol. There is a single WSDL structure for each type of SPPF operation. Each such WSDL structure contains exactly one input structure and one output structure that wraps any data elements that are part of the incoming request and the outgoing response, respectively. The spppSOAPBinding in the WSDL defines the binding style as "document" and the encoding as "literal". It is this combination of "wrapped" input and output data structures, "document" binding style, and "literal" encoding that characterize the Document Literal Wrapped style of WSDL specifications.

SPPP over SOAPのWSDLとデータ型を以下に定義します。 WSDL設計アプローチは、一般に「汎用WSDL」と呼ばれます。 SPPFプロトコルでサポートされているオブジェクトタイプごとに定義された特定のWSDL操作がないという意味で、これは一般的です。 SPPF操作のタイプごとに1つのWSDL構造があります。このような各WSDL構造には、1つの入力構造と1つの出力構造が含まれており、それぞれ着信要求と発信応答の一部であるデータ要素をラップします。 WSDLのspppSOAPBindingは、バインディングスタイルを「ドキュメント」、エンコーディングを「リテラル」として定義しています。 WSDL仕様のDocument Literal Wrappedスタイルを特徴付けるのは、「ラップされた」入出力データ構造、「ドキュメント」バインディングスタイル、および「リテラル」エンコーディングのこの組み合わせです。

Notes: The following WSDL has been formatted (e.g., tabs, spaces) to meet IETF requirements. Deployments MUST replace "REPLACE_WITH_ACTUAL_URL" in the WSDL below with the URI of the SPPF server instance.

注：次のWSDLは、IETF要件を満たすようにフォーマットされています（タブ、スペースなど）。デプロイメントでは、以下のWSDLの「REPLACE_WITH_ACTUAL_URL」をSPPFサーバーインスタンスのURIに置き換える必要があります。

   <?xml version="1.0" encoding="UTF-8"?>
   <wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
   xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
   xmlns:xsd="http://www.w3.org/2001/XMLSchema"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:sppfb="urn:ietf:params:xml:ns:sppf:base:1"
   xmlns:sppfs="urn:ietf:params:xml:ns:sppf:soap:1"
   targetNamespace="urn:ietf:params:xml:ns:sppf:soap:1">
    <wsdl:types>
     <xsd:schema xmlns="http://www.w3.org/2001/XMLSchema"
     xmlns:sppfs="urn:ietf:params:xml:ns:sppf:soap:1"
     targetNamespace="urn:ietf:params:xml:ns:sppf:soap:1">
      <annotation>
       <documentation>
        ---- Import base schema ----
       </documentation>
      </annotation>
      <import namespace="urn:ietf:params:xml:ns:sppf:base:1"
      schemaLocation="sppfbase.xsd"/>
      <annotation>
       <documentation>
        ---- Key type(s) extended
        from base schema. ----
       </documentation>
      </annotation>
      <complexType name="ObjKeyType">
       <complexContent>
        <extension base="sppfb:ObjKeyType">
         <sequence>
          <element name="rant" type="sppfb:OrgIdType"/>
          <element name="name" type="sppfb:ObjNameType"/>
          <element name="type" type="sppfs:ObjKeyTypeEnum"/>
         </sequence>
        </extension>
       </complexContent>
      </complexType>
    <simpleType name="ObjKeyTypeEnum">
      <restriction base="token">
        <enumeration value="SedGrp"/>
        <enumeration value="DestGrp"/>
        <enumeration value="SedRec"/>
        <enumeration value="EgrRte"/>
      </restriction>
    </simpleType>

      <complexType name="SedGrpOfferKeyType">
       <complexContent>
        <extension base="sppfb:SedGrpOfferKeyType">

         <sequence>
          <element name="sedGrpKey"
          type="sppfs:ObjKeyType"/>
          <element name="offeredTo"
          type="sppfb:OrgIdType"/>
         </sequence>
        </extension>
       </complexContent>
      </complexType>

      <complexType name="PubIdKeyType">
       <complexContent>
        <extension base="sppfb:PubIdKeyType">
         <sequence>
          <element name="rant" type="sppfb:OrgIdType"/>
          <choice>
           <element name="number"
           type="sppfb:NumberType"/>
           <element name="range"
           type="sppfb:NumberRangeType"/>
          </choice>
         </sequence>
        </extension>
       </complexContent>
      </complexType>

      <annotation>
       <documentation>
        ---- Generic Request and
        Response Definitions ----
       </documentation>
      </annotation>
      <element name="spppAddRequest">
       <complexType>
        <sequence>
         <element name="clientTransId"
         type="sppfb:TransIdType" minOccurs="0"/>
         <element name="minorVer"
         type="sppfb:MinorVerType" minOccurs="0"/>
         <element name="obj" type="sppfb:BasicObjType"
         maxOccurs="unbounded"/>
        </sequence>
       </complexType>
      </element>
      <element name="spppDelRequest">
       <complexType>
        <sequence>
         <element name="clientTransId"
         type="sppfb:TransIdType" minOccurs="0"/>
         <element name="minorVer"
         type="sppfb:MinorVerType" minOccurs="0"/>
         <element name="objKey"
         type="sppfb:ObjKeyType" maxOccurs="unbounded"/>
        </sequence>
       </complexType>
      </element>
      <element name="spppAcceptRequest">
       <complexType>
        <sequence>
         <element name="clientTransId"
         type="sppfb:TransIdType" minOccurs="0"/>
         <element name="minorVer"
         type="sppfb:MinorVerType" minOccurs="0"/>
         <element name="sedGrpOfferKey"
         type="sppfs:SedGrpOfferKeyType"
         maxOccurs="unbounded"/>
        </sequence>
       </complexType>
      </element>
      <element name="spppRejectRequest">
       <complexType>
        <sequence>
         <element name="clientTransId"
         type="sppfb:TransIdType" minOccurs="0"/>
         <element name="minorVer"
         type="sppfb:MinorVerType" minOccurs="0"/>
         <element name="sedGrpOfferKey"
         type="sppfs:SedGrpOfferKeyType"
         maxOccurs="unbounded"/>
        </sequence>
       </complexType>
      </element>
      <element name="spppGetRequest">
       <complexType>
        <sequence>
         <element name="minorVer"
         type="sppfb:MinorVerType" minOccurs="0"/>
         <element name="objKey"
         type="sppfb:ObjKeyType"
         maxOccurs="unbounded"/>
        </sequence>
       </complexType>
      </element>
      <element name="spppBatchRequest">
       <complexType>
        <sequence>

         <element name="clientTransId"
         type="sppfb:TransIdType" minOccurs="0"/>
         <element name="minorVer"
         type="sppfb:MinorVerType" minOccurs="0"/>
          <choice minOccurs="1" maxOccurs="unbounded">
           <element name="addObj" type="sppfb:BasicObjType"/>
           <element name="delObj" type="sppfb:ObjKeyType"/>
           <element name="acceptSedGrpOffer"
           type="sppfs:SedGrpOfferKeyType"/>
           <element name="rejectSedGrpOffer"
           type="sppfs:SedGrpOfferKeyType"/>
          </choice>
        </sequence>
       </complexType>
      </element>
      <element name="spppServerStatusRequest">
       <complexType>
        <sequence>
         <element name="minorVer"
         type="sppfb:MinorVerType" minOccurs="0"/>
        </sequence>
       </complexType>
      </element>
      <element name="getSedGrpOffersRequest">
       <complexType>
        <sequence>
         <element name="minorVer"
         type="sppfb:MinorVerType" minOccurs="0"/>
        <element name="offeredBy"
        type="sppfb:OrgIdType" minOccurs="0"
        maxOccurs="unbounded"/>
        <element name="offeredTo" type="sppfb:OrgIdType"
        minOccurs="0" maxOccurs="unbounded"/>
        <element name="status"
        type="sppfb:SedGrpOfferStatusType" minOccurs="0"/>
        <element name="sedGrpOfferKey"
        type="sppfs:SedGrpOfferKeyType"
        minOccurs="0" maxOccurs="unbounded"/>
        </sequence>
       </complexType>
      </element>
      <element name="spppAddResponse">
       <complexType>
        <sequence>
         <element name="clientTransId"
         type="sppfb:TransIdType" minOccurs="0"/>
         <element name="serverTransId"
         type="sppfb:TransIdType"/>

         <element name="overallResult"
         type="sppfs:ResultCodeType"/>
         <element name="detailResult"
         type="sppfs:ObjResultCodeType"
         minOccurs="0" maxOccurs="unbounded"/>
        </sequence>
       </complexType>
      </element>
      <element name="spppDelResponse">
       <complexType>
        <sequence>
         <element name="clientTransId"
         type="sppfb:TransIdType" minOccurs="0"/>
         <element name="serverTransId"
         type="sppfb:TransIdType"/>
         <element name="overallResult"
         type="sppfs:ResultCodeType"/>
         <element name="detailResult"
         type="sppfs:ObjKeyResultCodeType"
         minOccurs="0" maxOccurs="unbounded"/>
        </sequence>
       </complexType>
      </element>
      <element name="spppAcceptResponse">
       <complexType>
        <sequence>
         <element name="clientTransId"
         type="sppfb:TransIdType" minOccurs="0"/>
         <element name="serverTransId"
         type="sppfb:TransIdType"/>
         <element name="overallResult"
         type="sppfs:ResultCodeType"/>
         <element name="detailResult"
         type="sppfs:SedGrpOfferKeyResultCodeType"
         minOccurs="0" maxOccurs="unbounded"/>
        </sequence>
       </complexType>
      </element>
      <element name="spppRejectResponse">
       <complexType>
        <sequence>
         <element name="clientTransId"
         type="sppfb:TransIdType" minOccurs="0"/>
         <element name="serverTransId"
         type="sppfb:TransIdType"/>
         <element name="overallResult"
         type="sppfs:ResultCodeType"/>
         <element name="detailResult"
         type="sppfs:SedGrpOfferKeyResultCodeType"
         minOccurs="0" maxOccurs="unbounded"/>
        </sequence>
       </complexType>
      </element>
       <element name="spppBatchResponse">
       <complexType>
        <sequence>
         <element name="clientTransId"
         type="sppfb:TransIdType" minOccurs="0"/>
         <element name="serverTransId"
         type="sppfb:TransIdType"/>
         <element name="overallResult"
         type="sppfs:ResultCodeType"/>
          <choice minOccurs="0" maxOccurs="unbounded">
           <element name="addResult"
                    type="sppfs:ObjResultCodeType"/>
           <element name="delResult"
                    type="sppfs:ObjKeyResultCodeType"/>
           <element name="acceptResult"
                    type="sppfs:SedGrpOfferKeyResultCodeType"/>
           <element name="rejectResult"
                  type="sppfs:SedGrpOfferKeyResultCodeType"/>
          </choice>
        </sequence>
       </complexType>
      </element>
      <element name="spppGetResponse">
       <complexType>
        <sequence>
         <element name="overallResult"
         type="sppfs:ResultCodeType"/>
         <element name="resultObj"
         type="sppfb:BasicObjType"
         minOccurs="0" maxOccurs="unbounded"/>
        </sequence>
       </complexType>
      </element>
      <element name="spppServerStatusResponse">
       <complexType>
        <sequence>
         <element name="overallResult"
         type="sppfs:ResultCodeType"/>
         <element name="svcMenu"
         type="sppfb:SvcMenuType"/>
        </sequence>
       </complexType>
      </element>

      <annotation>
       <documentation>
        ---- Operation Result Type
        Definitions ----
       </documentation>
      </annotation>
      <complexType name="ResultCodeType">
       <sequence>
        <element name="code" type="sppfs:ResultCodeValType"/>
        <element name="msg" type="sppfs:MsgType"/>
       </sequence>
      </complexType>

      <simpleType name="ResultCodeValType">
        <restriction base="unsignedShort">
          <enumeration value="1000"/>
          <enumeration value="2000"/>
          <enumeration value="2001"/>
          <enumeration value="2002"/>
          <enumeration value="2100"/>
          <enumeration value="2101"/>
          <enumeration value="2102"/>
          <enumeration value="2103"/>
          <enumeration value="2300"/>
          <enumeration value="2301"/>
        </restriction>
      </simpleType>

      <simpleType name="MsgType">
        <restriction base="token">
         <minLength value="3"/>
         <maxLength value="255"/>
        </restriction>
       </simpleType>

      <complexType name="ObjResultCodeType">
       <complexContent>
        <extension base="sppfs:ResultCodeType">
         <sequence>
          <element name="obj" type="sppfb:BasicObjType"/>
         </sequence>
        </extension>
       </complexContent>
      </complexType>
      <complexType name="ObjKeyResultCodeType">
       <complexContent>
        <extension base="sppfs:ResultCodeType">
         <sequence>

          <element name="objKey" type="sppfb:ObjKeyType"/>
         </sequence>
        </extension>
       </complexContent>
      </complexType>
         <complexType name="SedGrpOfferKeyResultCodeType">
       <complexContent>
        <extension base="sppfs:ResultCodeType">
         <sequence>
          <element name="sedGrpOfferKey"
          type="sppfs:SedGrpOfferKeyType"/>
         </sequence>
        </extension>
       </complexContent>
       </complexType>
     </xsd:schema>
    </wsdl:types>
    <wsdl:message name="spppAddRequestMsg">
     <wsdl:part name="rqst" element="sppfs:spppAddRequest"/>
    </wsdl:message>
    <wsdl:message name="spppDelRequestMsg">
     <wsdl:part name="rqst" element="sppfs:spppDelRequest"/>
    </wsdl:message>
    <wsdl:message name="spppAcceptRequestMsg">
     <wsdl:part name="rqst" element="sppfs:spppAcceptRequest"/>
    </wsdl:message>
    <wsdl:message name="spppRejectRequestMsg">
     <wsdl:part name="rqst" element="sppfs:spppRejectRequest"/>
    </wsdl:message>
    <wsdl:message name="spppBatchRequestMsg">
     <wsdl:part name="rqst" element="sppfs:spppBatchRequest"/>
    </wsdl:message>
    <wsdl:message name="spppGetRequestMsg">
     <wsdl:part name="rqst" element="sppfs:spppGetRequest"/>
    </wsdl:message>
    <wsdl:message name="spppGetSedGrpOffersRequestMsg">
     <wsdl:part name="rqst" element="sppfs:getSedGrpOffersRequest"/>
    </wsdl:message>
    <wsdl:message name="spppAddResponseMsg">
     <wsdl:part name="rspns" element="sppfs:spppAddResponse"/>
    </wsdl:message>
     <wsdl:message name="spppDelResponseMsg">
     <wsdl:part name="rspns" element="sppfs:spppDelResponse"/>
    </wsdl:message>
     <wsdl:message name="spppAcceptResponseMsg">
     <wsdl:part name="rspns" element="sppfs:spppAcceptResponse"/>
    </wsdl:message>
     <wsdl:message name="spppRejectResponseMsg">

     <wsdl:part name="rspns" element="sppfs:spppRejectResponse"/>
    </wsdl:message>
     <wsdl:message name="spppBatchResponseMsg">
     <wsdl:part name="rspns" element="sppfs:spppBatchResponse"/>
    </wsdl:message>
    <wsdl:message name="spppGetResponseMsg">
     <wsdl:part name="rspns" element="sppfs:spppGetResponse"/>
    </wsdl:message>
    <wsdl:message name="spppServerStatusRequestMsg">
     <wsdl:part name="rqst" element="sppfs:spppServerStatusRequest"/>
    </wsdl:message>
    <wsdl:message name="spppServerStatusResponseMsg">
     <wsdl:part name="rspns" element="sppfs:spppServerStatusResponse"/>
    </wsdl:message>
    <wsdl:portType name="spppPortType">
     <wsdl:operation name="submitAddRqst">
      <wsdl:input message="sppfs:spppAddRequestMsg"/>
      <wsdl:output message="sppfs:spppAddResponseMsg"/>
     </wsdl:operation>
     <wsdl:operation name="submitDelRqst">
      <wsdl:input message="sppfs:spppDelRequestMsg"/>
      <wsdl:output message="sppfs:spppDelResponseMsg"/>
     </wsdl:operation>
     <wsdl:operation name="submitAcceptRqst">
      <wsdl:input message="sppfs:spppAcceptRequestMsg"/>
      <wsdl:output message="sppfs:spppAcceptResponseMsg"/>
     </wsdl:operation>
     <wsdl:operation name="submitRejectRqst">
      <wsdl:input message="sppfs:spppRejectRequestMsg"/>
      <wsdl:output message="sppfs:spppRejectResponseMsg"/>
     </wsdl:operation>
     <wsdl:operation name="submitBatchRqst">
      <wsdl:input message="sppfs:spppBatchRequestMsg"/>
      <wsdl:output message="sppfs:spppBatchResponseMsg"/>
     </wsdl:operation>
     <wsdl:operation name="submitGetRqst">
      <wsdl:input message="sppfs:spppGetRequestMsg"/>
      <wsdl:output message="sppfs:spppGetResponseMsg"/>
     </wsdl:operation>
     <wsdl:operation name="submitGetSedGrpOffersRqst">
      <wsdl:input message="sppfs:spppGetSedGrpOffersRequestMsg"/>
      <wsdl:output message="sppfs:spppGetResponseMsg"/>
     </wsdl:operation>
     <wsdl:operation name="submitServerStatusRqst">
      <wsdl:input message="sppfs:spppServerStatusRequestMsg"/>
      <wsdl:output message="sppfs:spppServerStatusResponseMsg"/>
     </wsdl:operation>
    </wsdl:portType>

    <wsdl:binding name="spppSoapBinding" type="sppfs:spppPortType">
     <soap:binding style="document"
     transport="http://schemas.xmlsoap.org/soap/http"/>
     <wsdl:operation name="submitAddRqst">
      <soap:operation soapAction="submitAddRqst" style="document"/>
      <wsdl:input>
       <soap:body use="literal"/>
      </wsdl:input>
      <wsdl:output>
       <soap:body use="literal"/>
      </wsdl:output>
     </wsdl:operation>
     <wsdl:operation name="submitDelRqst">
      <soap:operation soapAction="submitDelRqst" style="document"/>
      <wsdl:input>
       <soap:body use="literal"/>
      </wsdl:input>
      <wsdl:output>
       <soap:body use="literal"/>
      </wsdl:output>
     </wsdl:operation>
     <wsdl:operation name="submitAcceptRqst">
      <soap:operation soapAction="submitAcceptRqst" style="document"/>
      <wsdl:input>
       <soap:body use="literal"/>
      </wsdl:input>
      <wsdl:output>
       <soap:body use="literal"/>
      </wsdl:output>
     </wsdl:operation>
     <wsdl:operation name="submitRejectRqst">
      <soap:operation soapAction="submitRejectRqst" style="document"/>
      <wsdl:input>
       <soap:body use="literal"/>
      </wsdl:input>
      <wsdl:output>
       <soap:body use="literal"/>
      </wsdl:output>
     </wsdl:operation>
     <wsdl:operation name="submitBatchRqst">
      <soap:operation soapAction="submitBatchRqst" style="document"/>
      <wsdl:input>
       <soap:body use="literal"/>
      </wsdl:input>
      <wsdl:output>
       <soap:body use="literal"/>
      </wsdl:output>
     </wsdl:operation>

     <wsdl:operation name="submitGetRqst">
      <soap:operation soapAction="submitGetRqst" style="document"/>
      <wsdl:input>
       <soap:body use="literal"/>
      </wsdl:input>
      <wsdl:output>
       <soap:body use="literal"/>
      </wsdl:output>
     </wsdl:operation>
     <wsdl:operation name="submitGetSedGrpOffersRqst">
      <soap:operation soapAction="submitGetSedGrpOffersRqst"
      style="document"/>
      <wsdl:input>
       <soap:body use="literal"/>
      </wsdl:input>
      <wsdl:output>
       <soap:body use="literal"/>
      </wsdl:output>
     </wsdl:operation>
     <wsdl:operation name="submitServerStatusRqst">
      <soap:operation soapAction="submitServerStatusRqst"
      style="document"/>
      <wsdl:input>
       <soap:body use="literal"/>
      </wsdl:input>
      <wsdl:output>
       <soap:body use="literal"/>
      </wsdl:output>
     </wsdl:operation>
    </wsdl:binding>
    <wsdl:service name="spppService">
     <wsdl:port name="spppPort" binding="sppfs:spppSoapBinding">
      <soap:address location="REPLACE_WITH_ACTUAL_URL"/>
     </wsdl:port>
    </wsdl:service>
   </wsdl:definitions>

Figure 2: WSDL

図2：WSDL

10. SPPP over SOAP Examples

10. SPPP over SOAPの例

This section shows an XML message exchange between two SIP Service Providers (SSPs) and a Registry. The messages in this section are valid XML instances that conform to the SPPP over SOAP schema version within this document. This section also relies on the XML data structures defined in the SPPF specification [RFC7877], which should also be referenced to understand XML object types embedded in these example messages.

このセクションでは、2つのSIPサービスプロバイダー（SSP）とレジストリ間のXMLメッセージ交換を示します。このセクションのメッセージは、このドキュメント内のSPPP over SOAPスキーマバージョンに準拠する有効なXMLインスタンスです。このセクションは、SPPF仕様[RFC7877]で定義されているXMLデータ構造にも依存しています。これらのメッセージは、これらのサンプルメッセージに埋め込まれているXMLオブジェクトタイプを理解するためにも参照する必要があります。

In this sample use-case scenario, SSP1 and SSP2 provision resource data in the Registry and use SPPF constructs to selectively share the SED Groups. In the figure below, SSP2 has two ingress Signaling Path Border Element (SBE) instances that are associated with the Public Identities with which SSP2 has the retail relationship. Also, the two SBE instances for SSP1 are used to show how to use SPPF to associate route preferences for the destination Ingress Routes and exercise greater control on outbound traffic to the peer's ingress SBEs.

このサンプルユースケースシナリオでは、SSP1およびSSP2がレジストリにリソースデータをプロビジョニングし、SPPF構成体を使用してSEDグループを選択的に共有します。次の図では、SSP2には2つの入力Signaling Path Border Element（SBE）インスタンスがあり、SSP2が小売り関係にあるパブリックIDに関連付けられています。また、SSP1の2つのSBEインスタンスを使用して、SPPFを使用して宛先の入力ルートのルート設定を関連付け、ピアの入力SBEへの送信トラフィックをより詳細に制御する方法を示します。

      ---------------+                      +------------------
                     |                      |
                 +------+               +------+
                 | sbe1 |               | sbe2 |
                 +------+               +------+
       SSP1          |                      |           SSP2
                 +------+               +------+
                 | sbe3 |               | sbe4 |
                 +------+               +------+
      iana-en:111    |                      |     iana-en:222
      ---------------+                      +------------------
              |                                     |
              |                                     |
              | SPPF   +------------------+   SPPF  |
              +------->|     Registry     |<--------+
                       +------------------+

Example Use-Case Infrastructure

ユースケースインフラストラクチャの例

10.1. Add Destination Group

10.1. 宛先グループを追加

SSP2 adds a Destination Group to the Registry for later use. The SSP2 SPPF client sets a unique transaction identifier "txn_1479" for tracking purposes. The name of the Destination Group is set to DEST_GRP_SSP2_1.

SSP2は、後で使用するために宛先グループをレジストリに追加します。 SSP2 SPPFクライアントは、追跡のために一意のトランザクション識別子「txn_1479」を設定します。宛先グループの名前はDEST_GRP_SSP2_1に設定されます。

   <?xml version="1.0" encoding="UTF-8"?>
   <soapenv:Envelope
   xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
   xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"
   xmlns:urn1="urn:ietf:params:xml:ns:sppf:base:1"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <soapenv:Header/>
    <soapenv:Body>
     <urn:spppAddRequest>
      <!--Optional:-->
      <clientTransId>txn_1479</clientTransId>
       <!--1 or more repetitions:-->
      <obj xsi:type="urn1:DestGrpType">
       <urn1:rant>iana-en:222</urn1:rant>
       <urn1:rar>iana-en:223</urn1:rar>
       <urn1:dgName>DEST_GRP_SSP2_1</urn1:dgName>
      </obj>
     </urn:spppAddRequest>
    </soapenv:Body>
   </soapenv:Envelope>

The Registry processes the request and returns a favorable response confirming successful creation of the named Destination Group. In addition to returning a unique server transaction identifier, the Registry returns the matching client transaction identifier from the request message back to the SPPF client.

レジストリは要求を処理し、指定された宛先グループが正常に作成されたことを確認する好ましい応答を返します。レジストリは、一意のサーバートランザクション識別子を返すだけでなく、一致するクライアントトランザクション識別子を要求メッセージからSPPFクライアントに返します。

   <?xml version="1.0" encoding="UTF-8"?>
   <S:Envelope
   xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
    <S:Body>
     <ns3:spppAddResponse
      xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
      xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
      <clientTransId>txn_1479</clientTransId>
      <serverTransId>tx_12345</serverTransId>
      <overallResult>
       <code>1000</code>
       <msg>Request Succeeded.</msg>
      </overallResult>
     </ns3:spppAddResponse>
    </S:Body>
   </S:Envelope>

10.2. Add SED Records

10.2. SEDレコードを追加する

SSP2 adds SED Records in the form of Ingress Routes to the Registry.

SSP2は、SEDレコードを入力ルートの形式でレジストリに追加します。

<?xml version="1.0" encoding="UTF-8"?> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1" xmlns:urn1="urn:ietf:params:xml:ns:sppf:base:1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Header/> <soapenv:Body> <urn:spppAddRequest>  <clientTransId>txn_1479</clientTransId>  <obj xsi:type="urn1:NAPTRType"> <urn1:rant>iana-en:222</urn1:rant> <urn1:rar>iana-en:223</urn1:rar> <urn1:sedName>SED_SSP2_SBE2</urn1:sedName> <urn1:isInSvc>true</urn1:isInSvc> <urn1:order>10</urn1:order> <urn1:flags>u</urn1:flags> <urn1:svcs>E2U+sip</urn1:svcs> <urn1:regx> <urn1:ere>^(.*)$</urn1:ere> <urn1:repl>sip:\1@sbe2.ssp2.example.com</urn1:repl> </urn1:regx> </obj> </urn:spppAddRequest> </soapenv:Body> </soapenv:Envelope> The Registry returns a success response.

<？xml version = "1.0" encoding = "UTF-8"？> <soapenv：Envelope xmlns：soapenv = "http://schemas.xmlsoap.org/soap/envelope/" xmlns：urn = "urn：ietf： params：xml：ns：sppf：soap：1 "xmlns：urn1 =" urn：ietf：params：xml：ns：sppf：base：1 "xmlns：xsi =" http://www.w3.org/2001/ XMLSchema-instance "> <soapenv：Header /> <soapenv：Body> <urn：spppAddRequest> <！-Optional：-> <clientTransId> txn_1479 </ clientTransId> <！-1回以上の繰り返し：-> <obj xsi：type = "urn1：NAPTRType"> <urn1：rant> iana-en：222 </ urn1：rant> <urn1：rar> iana-en：223 </ urn1：rar> <urn1：sedName> SED_SSP2_SBE2 </ urn1：sedName> <urn1：isInSvc> true </ urn1：isInSvc> <urn1：order> 10 </ urn1：order> <urn1：flags> u </ urn1：flags> <urn1：svcs> E2U + sip </ urn1：svcs> <urn1：regx> <urn1：ere> ^（。*）$ </ urn1：ere> <urn1：repl> sip：\ 1@sbe2.ssp2.example.com </ urn1：repl > </ urn1：regx> </ obj> </ urn：spppAddRequest> </ soapenv：Body> </ soapenv：Envelope>レジストリは成功の応答を返します。

   <?xml version="1.0" encoding="UTF-8"?>
   <S:Envelope
   xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
    <S:Body>
     <ns3:spppAddResponse
      xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
      xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
      <clientTransId>txn_1479</clientTransId>
      <serverTransId>tx_12345</serverTransId>
      <overallResult>
       <code>1000</code>
       <msg>Request Succeeded.</msg>
      </overallResult>
     </ns3:spppAddResponse>
    </S:Body>
   </S:Envelope>

10.3. Add SED Records -- URIType

10.3. SEDレコードの追加-URIType

SSP2 adds another SED Record to the Registry and makes use of URIType.

SSP2は別のSEDレコードをレジストリに追加し、URITypeを利用します。

   <?xml version="1.0" encoding="UTF-8"?>
   <S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
    <S:Body>
     <ns3:spppAddResponse
      xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
      xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
      <clientTransId>txn_1479</clientTransId>
      <serverTransId>tx_12345</serverTransId>
      <overallResult>
       <code>1000</code>
       <msg>Request Succeeded.</msg>
      </overallResult>
     </ns3:spppAddResponse>
    </S:Body>
   </S:Envelope>

10.4. Add SED Group

10.4. SEDグループを追加

SSP2 creates the grouping of SED Records (e.g., Ingress Routes) and chooses a higher precedence for SED_SSP2_SBE2 by setting a lower number for the "priority" attribute, a protocol agnostic precedence indicator.

SSP2は、SEDレコード（たとえば、入力ルート）のグループを作成し、プロトコルにとらわれない優先順位インジケーターである「優先度」属性に低い数値を設定することにより、SED_SSP2_SBE2に高い優先順位を選択します。

<?xml version="1.0" encoding="UTF-8"?> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1" xmlns:urn1="urn:ietf:params:xml:ns:sppf:base:1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Header/> <soapenv:Body> <urn:spppAddRequest> <clientTransId>txn_1479</clientTransId>  <obj xsi:type="urn1:SedGrpType"> <urn1:rant>iana-en:222</urn1:rant> <urn1:rar>iana-en:223</urn1:rar> <urn1:sedGrpName>SED_GRP_SSP2_1</urn1:sedGrpName> <urn1:sedRecRef> <urn1:sedKey xsi:type="urn:ObjKeyType"> <rant>iana-en:222</rant> <name>SED_SSP2_SBE2</name> <type>SedRec</type> </urn1:sedKey> <urn1:priority>100</urn1:priority> </urn1:sedRecRef> <urn1:dgName>DEST_GRP_SSP2_1</urn1:dgName> <urn1:isInSvc>true</urn1:isInSvc> <urn1:priority>10</urn1:priority> </obj> </urn:spppAddRequest> </soapenv:Body> </soapenv:Envelope> To confirm successful processing of this request, the Registry returns a well-known result code "1000" to the SSP2 client.

<？xml version = "1.0" encoding = "UTF-8"？> <soapenv：Envelope xmlns：soapenv = "http://schemas.xmlsoap.org/soap/envelope/" xmlns：urn = "urn：ietf： params：xml：ns：sppf：soap：1 "xmlns：urn1 =" urn：ietf：params：xml：ns：sppf：base：1 "xmlns：xsi =" http://www.w3.org/2001/ XMLSchema-instance "> <soapenv：Header /> <soapenv：Body> <urn：spppAddRequest> <clientTransId> txn_1479 </ clientTransId> <！-1以上の繰り返し：-> <obj xsi：type =" urn1： SedGrpType "> <urn1：rant> iana-en：222 </ urn1：rant> <urn1：rar> iana-en：223 </ urn1：rar> <urn1：sedGrpName> SED_GRP_SSP2_1 </ urn1：sedGrpName> <urn1： sedRecRef> <urn1：sedKey xsi：type = "urn：ObjKeyType"> <rant> iana-en：222 </ rant> <name> SED_SSP2_SBE2 </ name> <type> SedRec </ type> </ urn1：sedKey> <urn1：priority> 100 </ urn1：priority> </ urn1：sedRecRef> <urn1：dgName> DEST_GRP_SSP2_1 </ urn1：dgName> <urn1：isInSvc> true </ urn1：isInSvc> <urn1：priority> 10 </ urn1：priority> </ obj> </ urn：spppAddRequest> </ soapenv：Body> </ soapenv：Envelope>このリクエストが正常に処理されたことを確認するために、レジストリは既知の解像度を返しますSSP2クライアントへの最終コード「1000」。

   <?xml version="1.0" encoding="UTF-8"?>
   <S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
    <S:Body>
     <ns3:spppAddResponse
      xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
      xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
      <clientTransId>txn_1479</clientTransId>
      <serverTransId>tx_12345</serverTransId>
      <overallResult>
       <code>1000</code>
       <msg>Request Succeeded.</msg>
      </overallResult>
     </ns3:spppAddResponse>
    </S:Body>
   </S:Envelope>

10.5. Add Public Identifier -- Successful COR Claim

10.5. 公開識別子を追加-成功したCORクレーム

SSP2 activates a TN Public Identifier by associating it with a valid Destination Group. Further, SSP2 puts forth a claim that it is the carrier-of-record (COR) for the TN.

SSP2は、それを有効な宛先グループに関連付けることにより、TNパブリックIDをアクティブにします。さらに、SSP2は、それがTNの記録担体（COR）であるという主張を発表しています。

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1" xmlns:urn1="urn:ietf:params:xml:ns:sppf:base:1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Header/> <soapenv:Body> <urn:spppAddRequest> <clientTransId>txn_1479</clientTransId>  <obj xsi:type="urn1:TNType"> <urn1:rant>iana-en:222</urn1:rant> <urn1:rar>iana-en:223</urn1:rar> <urn1:dgName>DEST_GRP_SSP2_1</urn1:dgName> <urn1:tn>+12025556666</urn1:tn> <urn1:corInfo> <urn1:corClaim>true</urn1:corClaim> </urn1:corInfo> </obj> </urn:spppAddRequest> </soapenv:Body> </soapenv:Envelope> Assuming that the Registry has access to TN authority data and it performs the required checks to verify that SSP2 is in fact the SP of record for the given TN, the request is processed successfully. In the response message, the Registry sets the value of <cor> to "true" in order to confirm the SSP2 claim as the carrier-of-record, and the <corDate> reflects the time when the carrier-of-record claim is processed.

<soapenv：Envelope xmlns：soapenv = "http://schemas.xmlsoap.org/soap/envelope/" xmlns：urn = "urn：ietf：params：xml：ns：sppf：soap：1" xmlns：urn1 = " urn：ietf：params：xml：ns：sppf：base：1 "xmlns：xsi =" http://www.w3.org/2001/XMLSchema-instance "> <soapenv：Header /> <soapenv：Body> < urn：spppAddRequest> <clientTransId> txn_1479 </ clientTransId> <！-1回以上の繰り返し：-> <obj xsi：type = "urn1：TNType"> <urn1：rant> iana-en：222 </ urn1： rant> <urn1：rar> iana-en：223 </ urn1：rar> <urn1：dgName> DEST_GRP_SSP2_1 </ urn1：dgName> <urn1：tn> +12025556666 </ urn1：tn> <urn1：corInfo> <urn1 ：corClaim> true </ urn1：corClaim> </ urn1：corInfo> </ obj> </ urn：spppAddRequest> </ soapenv：Body> </ soapenv：Envelope>レジストリがTN権限データとそのデータにアクセスできると仮定必要なチェックを実行して、SSP2が実際に指定されたTNのレコードのSPであることを確認し、要求が正常に処理されます。応答メッセージでは、レジストリは<cor>の値を「true」に設定して、SSP2クレームを記録保持者として確認し、<corDate>は、記録保持キャリアの要求があった時刻を反映します。処理されました。

   <?xml version="1.0" encoding="UTF-8"?>
   <S:Envelope
    xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <S:Body>
     <ns3:spppAddResponse
      xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
      xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
      <clientTransId>txn_1479</clientTransId>
      <serverTransId>tx_12345</serverTransId>
      <overallResult>
       <code>1000</code>
       <msg>Request Succeeded.</msg>
      </overallResult>
      <detailResult>
       <code>1000</code>
       <msg>Request Succeeded.</msg>
       <obj xsi:type="ns2:TNType">
        <ns2:rant>iana-en:222</ns2:rant>
        <ns2:rar>iana-en:223</ns2:rar>
        <ns2:cDate>2010-05-30T09:30:10Z</ns2:cDate>
        <ns2:dgName>DEST_GRP_SSP2_1</ns2:dgName>
        <ns2:tn>+12025556666</ns2:tn>
        <ns2:corInfo>
         <ns2:corClaim>true</ns2:corClaim>
         <ns2:cor>true</ns2:cor>
         <ns2:corDate>2010-05-30T09:30:11Z</ns2:corDate>
        </ns2:corInfo>
       </obj>
      </detailResult>
     </ns3:spppAddResponse>
    </S:Body>
   </S:Envelope>

10.6. Add LRN

10.6. LRNを追加

If another entity that SSP2 shares SED (e.g., routes) with has access to Number Portability data, it may choose to perform route lookups by RN. Therefore, SSP2 associates an RN to a Destination Group in order to facilitate Ingress Route discovery.

SSP2がSED（ルートなど）を共有する別のエンティティが番号ポータビリティデータにアクセスできる場合、RNによるルートルックアップの実行を選択できます。したがって、SSP2は、イングレスルートの検出を容易にするために、RNを宛先グループに関連付けます。

   <?xml version="1.0" encoding="UTF-8"?>
   <S:Envelope
    xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
    <S:Body>
     <ns3:spppAddResponse
      xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
      xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
      <clientTransId>txn_1479</clientTransId>
      <serverTransId>tx_12345</serverTransId>
      <overallResult>
       <code>1000</code>
       <msg>Request Succeeded.</msg>
      </overallResult>
     </ns3:spppAddResponse>
    </S:Body>
   </S:Envelope>

10.7. Add TN Range

10.7. TN範囲を追加

Next, SSP2 activates a block of ten thousand TNs and associates it to a Destination Group.

次に、SSP2は1万のTNのブロックをアクティブにし、それを宛先グループに関連付けます。

   <?xml version="1.0" encoding="UTF-8"?>
   <S:Envelope
    xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
    <S:Body>
     <ns3:spppAddResponse
      xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
      xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
      <clientTransId>txn_1479</clientTransId>
      <serverTransId>tx_12345</serverTransId>
      <overallResult>
       <code>1000</code>
       <msg>Request Succeeded.</msg>
      </overallResult>
     </ns3:spppAddResponse>
    </S:Body>
   </S:Envelope>

10.8. Add TN Prefix

10.8. TNプレフィックスを追加

Next, SSP2 activates a block of ten thousand TNs by using the TNPType structure and identifying a TN prefix.

次に、SSP2は、TNPType構造を使用してTNプレフィックスを識別することにより、1万TNのブロックをアクティブにします。

   <?xml version="1.0" encoding="UTF-8"?>
   <S:Envelope
    xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
    <S:Body>
     <ns3:spppAddResponse
      xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
      xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
      <clientTransId>txn_1479</clientTransId>
      <serverTransId>tx_12345</serverTransId>
      <overallResult>
       <code>1000</code>
       <msg>Request Succeeded.</msg>
      </overallResult>
     </ns3:spppAddResponse>
    </S:Body>
   </S:Envelope>

10.9. Enable Peering -- SED Group Offer

10.9. ピアリングを有効にする-SEDグループオファー

In order for SSP1 to complete session establishment for a destination TN where the target subscriber has a retail relationship with SSP2, it first requires an asynchronous bidirectional handshake to show mutual consent. To start the process, SSP2 initiates the peering handshake by offering SSP1 access to its SED Group.

SSP1が、ターゲットサブスクライバーがSSP2とリテール関係にある宛先TNのセッション確立を完了するには、最初に非同期の双方向ハンドシェイクで相互の同意を示す必要があります。プロセスを開始するために、SSP2はSED1にSEDグループへのアクセスを提供することにより、ピアリングハンドシェイクを開始します。

<?xml version="1.0" encoding="UTF-8"?> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1" xmlns:urn1="urn:ietf:params:xml:ns:sppf:base:1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Header/> <soapenv:Body> <urn:spppAddRequest> <clientTransId>txn_1479</clientTransId>  <obj xsi:type="urn1:SedGrpOfferType"> <urn1:rant>iana-en:222</urn1:rant> <urn1:rar>iana-en:223</urn1:rar> <urn1:sedGrpOfferKey xsi:type="urn:SedGrpOfferKeyType"> <sedGrpKey xsi:type="urn:ObjKeyType"> <rant>iana-en:222</rant> <name>SED_GRP_SSP2_1</name> <type>SedGrp</type> </sedGrpKey> <offeredTo>iana-en:111</offeredTo> </urn1:sedGrpOfferKey> <urn1:status>offered</urn1:status> <urn1:offerDateTime> 2006-05-04T18:13:51.0Z </urn1:offerDateTime> </obj> </urn:spppAddRequest> </soapenv:Body> </soapenv:Envelope> The Registry completes the request successfully and confirms that the SSP1 will now have the opportunity to weigh in on the offer and either accept or reject it. The Registry may employ out-of-band notification mechanisms for quicker updates to SSP1 so they can act faster, though this topic is beyond the scope of this document.

<？xml version = "1.0" encoding = "UTF-8"？> <soapenv：Envelope xmlns：soapenv = "http://schemas.xmlsoap.org/soap/envelope/" xmlns：urn = "urn：ietf： params：xml：ns：sppf：soap：1 "xmlns：urn1 =" urn：ietf：params：xml：ns：sppf：base：1 "xmlns：xsi =" http://www.w3.org/2001/ XMLSchema-instance "> <soapenv：Header /> <soapenv：Body> <urn：spppAddRequest> <clientTransId> txn_1479 </ clientTransId> <！-1以上の繰り返し：-> <obj xsi：type =" urn1： SedGrpOfferType "> <urn1：rant> iana-en：222 </ urn1：rant> <urn1：rar> iana-en：223 </ urn1：rar> <urn1：sedGrpOfferKey xsi：type =" urn：SedGrpOfferKeyType "> < sedGrpKey xsi：type = "urn：ObjKeyType"> <rant> iana-en：222 </ rant> <name> SED_GRP_SSP2_1 </ name> <type> SedGrp </ type> </ sedGrpKey> <offeredTo> iana-en： 111 </ offeredTo> </ urn1：sedGrpOfferKey> <urn1：status> offered </ urn1：status> <urn1：offerDateTime> 2006-05-04T18：13：51.0Z </ urn1：offerDateTime> </ obj> </ urn：spppAddRequest> </ soapenv：Body> </ soapenv：Envelope>レジストリはリクエストを正常に完了し、SSP1に機会があることを確認しますオファーを検討し、それを受け入れるか拒否するか。レジストリでは、アウトオブバンド通知メカニズムを採用してSSP1をすばやく更新し、より迅速に動作できるようにしますが、このトピックはこのドキュメントの範囲外です。

   <?xml version="1.0" encoding="UTF-8"?>
   <S:Envelope
    xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
    <S:Body>
     <ns3:spppAddResponse
      xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
      xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
      <clientTransId>txn_1479</clientTransId>
      <serverTransId>tx_12345</serverTransId>
      <overallResult>
       <code>1000</code>
       <msg>Request Succeeded.</msg>
      </overallResult>
     </ns3:spppAddResponse>
    </S:Body>
   </S:Envelope>

10.10. Enable Peering -- SED Group Offer Accept

10.10. ピアリングを有効にする-SEDグループオファー受け入れ

SSP1 responds to the offer from SSP2 and agrees to have visibility to SSP2 SED (e.g., Ingress Routes).

SSP1はSSP2からのオファーに応答し、SSP2 SED（例：イングレスルート）を可視化することに同意します。

<?xml version="1.0" encoding="UTF-8"?> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"> <soapenv:Header/> <soapenv:Body> <urn:spppAcceptRequest>  <clientTransId>txn_1479</clientTransId>  <sedGrpOfferKey> <sedGrpKey> <rant>iana-en:222</rant> <name>SED_GRP_SSP2_1</name> <type>SedGrp</type> </sedGrpKey> <offeredTo>iana-en:111</offeredTo> </sedGrpOfferKey> </urn:spppAcceptRequest> </soapenv:Body> </soapenv:Envelope> The Registry confirms that the request has been processed successfully. From this point forward, if SSP1 looks up a Public Identifier through the query resolution server, where the Public Identifier is part of the Destination Group by way of "SED_GRP_SSP2_1" SED association, SSP2 ingress SBE information will be shared with SSP1.

<？xml version = "1.0" encoding = "UTF-8"？> <soapenv：Envelope xmlns：soapenv = "http://schemas.xmlsoap.org/soap/envelope/" xmlns：urn = "urn：ietf： params：xml：ns：sppf：soap：1 "> <soapenv：Header /> <soapenv：Body> <urn：spppAcceptRequest> <！-オプション：-> <clientTransId> txn_1479 </ clientTransId> <！- 1回以上の繰り返し：-> <sedGrpOfferKey> <sedGrpKey> <rant> iana-en：222 </ rant> <name> SED_GRP_SSP2_1 </ name> <type> SedGrp </ type> </ sedGrpKey> <offeredTo> iana -en：111 </ offeredTo> </ sedGrpOfferKey> </ urn：spppAcceptRequest> </ soapenv：Body> </ soapenv：Envelope>レジストリは、リクエストが正常に処理されたことを確認します。これ以降、SSP1がクエリ解決サーバーを通じてパブリック識別子を検索する場合、パブリック識別子は "SED_GRP_SSP2_1" SEDアソシエーションを介して宛先グループの一部であり、SSP2入力SBE情報はSSP1と共有されます。

   <?xml version="1.0" encoding="UTF-8"?>
   <S:Envelope
    xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
    <S:Body>
     <ns3:spppAcceptResponse
      xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
      xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
      <clientTransId>txn_1479</clientTransId>
      <serverTransId>tx_12350</serverTransId>
      <overallResult>
       <code>1000</code>
       <msg>Request Succeeded.</msg>
      </overallResult>
     </ns3:spppAcceptResponse>
    </S:Body>
   </S:Envelope>

10.11. Add Egress Route

10.11. 下りルートを追加

SSP1 wants to prioritize all outbound traffic to the Ingress Route associated with the "SED_GRP_SSP2_1" SED Group record, through "sbe1.ssp1.example.com".

SSP1は、「SED_GRP_SSP2_1」SEDグループレコードに関連付けられた入力ルートへのすべての送信トラフィックを「sbe1.ssp1.example.com」を通じて優先させたいと考えています。

<?xml version="1.0" encoding="UTF-8"?> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1" xmlns:urn1="urn:ietf:params:xml:ns:sppf:base:1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Header/> <soapenv:Body> <urn:spppAddRequest> <clientTransId>txn_1479</clientTransId>  <obj xsi:type="urn1:EgrRteType"> <urn1:rant>iana-en:222</urn1:rant> <urn1:rar>iana-en:223</urn1:rar> <urn1:egrRteName>EGR_RTE_01</urn1:egrRteName> <urn1:pref>50</urn1:pref> <urn1:regxRewriteRule> <urn1:ere>^(.*@)(.*)$</urn1:ere> <urn1:repl>\1\2?route=sbe1.ssp1.example.com</urn1:repl> </urn1:regxRewriteRule> <urn1:ingrSedGrp xsi:type="urn:ObjKeyType"> <rant>iana-en:222</rant> <name>SED_GRP_SSP2_1</name> <type>SedGrp</type> </urn1:ingrSedGrp> </obj> </urn:spppAddRequest> </soapenv:Body> </soapenv:Envelope> Since peering has already been established, the request to add the Egress Route has been successfully completed.

<？xml version = "1.0" encoding = "UTF-8"？> <soapenv：Envelope xmlns：soapenv = "http://schemas.xmlsoap.org/soap/envelope/" xmlns：urn = "urn：ietf： params：xml：ns：sppf：soap：1 "xmlns：urn1 =" urn：ietf：params：xml：ns：sppf：base：1 "xmlns：xsi =" http://www.w3.org/2001/ XMLSchema-instance "> <soapenv：Header /> <soapenv：Body> <urn：spppAddRequest> <clientTransId> txn_1479 </ clientTransId> <！-1回以上の繰り返し：-> <obj xsi：type =" urn1： EgrRteType "> <urn1：rant> iana-en：222 </ urn1：rant> <urn1：rar> iana-en：223 </ urn1：rar> <urn1：egrRteName> EGR_RTE_01 </ urn1：egrRteName> <urn1： pref> 50 </ urn1：pref> <urn1：regxRewriteRule> <urn1：ere> ^（。* @）（。*）$ </ urn1：ere> <urn1：repl> \ 1 \ 2？route = sbe1。 ssp1.example.com </ urn1：repl> </ urn1：regxRewriteRule> <urn1：ingrSedGrp xsi：type = "urn：ObjKeyType"> <rant> iana-en：222 </ rant> <name> SED_GRP_SSP2_1 </ name > <type> SedGrp </ type> </ urn1：ingrSedGrp> </ obj> </ urn：spppAddRequest> </ soapenv：Body> </ soapenv：Envelope>ピアリングがすでに確立されているため、下りを追加するリクエストルートは正常です完了しました。

   <?xml version="1.0" encoding="UTF-8"?>
   <S:Envelope
    xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
    <S:Body>
     <ns3:spppAddResponse
      xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
      xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
      <clientTransId>txn_1479</clientTransId>
      <serverTransId>tx_12345</serverTransId>
      <overallResult>
       <code>1000</code>
       <msg>Request Succeeded.</msg>
      </overallResult>
     </ns3:spppAddResponse>
    </S:Body>
   </S:Envelope>

10.12. Remove Peering -- SED Group Offer Reject

10.12. ピアリングの削除-SEDグループオファー拒否

Earlier, SSP1 had accepted having visibility to SSP2 SED. SSP1 now decides to no longer maintain this visibility; hence, it rejects the SED Group Offer.

以前は、SSP1はSSP2 SEDへの可視性を受け入れていました。 SSP1は、この可視性を維持しないことを決定しました。したがって、SEDグループオファーは拒否されます。

<?xml version="1.0" encoding="UTF-8"?> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"> <soapenv:Header/> <soapenv:Body> <urn:spppRejectRequest>  <clientTransId>txn_1479</clientTransId>  <sedGrpOfferKey> <sedGrpKey> <rant>iana-en:222</rant> <name>SED_GRP_SSP2_1</name> <type>SedGrp</type> </sedGrpKey> <offeredTo>iana-en:111</offeredTo> </sedGrpOfferKey> </urn:spppRejectRequest> </soapenv:Body> </soapenv:Envelope> The Registry confirms that the request has been processed successfully. From this point forward, if SSP1 looks up a Public Identifier through the query resolution server, where the Public Identifier is part of the Destination Group by way of "SED_GRP_SSP2_1" SED association, SSP2 ingress SBE information will not be shared with SSP1; hence, an SSP2 ingress SBE will not be returned in the query response.

<？xml version = "1.0" encoding = "UTF-8"？> <soapenv：Envelope xmlns：soapenv = "http://schemas.xmlsoap.org/soap/envelope/" xmlns：urn = "urn：ietf： params：xml：ns：sppf：soap：1 "> <soapenv：Header /> <soapenv：Body> <urn：spppRejectRequest> <！-オプション：-> <clientTransId> txn_1479 </ clientTransId> <！- 1回以上の繰り返し：-> <sedGrpOfferKey> <sedGrpKey> <rant> iana-en：222 </ rant> <name> SED_GRP_SSP2_1 </ name> <type> SedGrp </ type> </ sedGrpKey> <offeredTo> iana -en：111 </ offeredTo> </ sedGrpOfferKey> </ urn：spppRejectRequest> </ soapenv：Body> </ soapenv：Envelope>レジストリは、リクエストが正常に処理されたことを確認します。これ以降、SSP1がクエリ解決サーバーを通じてパブリック識別子を検索する場合、パブリック識別子は "SED_GRP_SSP2_1" SEDアソシエーションを介して宛先グループの一部であり、SSP2入力SBE情報はSSP1と共有されません。したがって、SSP2入力SBEはクエリ応答で返されません。

   <?xml version="1.0" encoding="UTF-8"?>
   <S:Envelope
    xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
    <S:Body>
     <ns3:spppRejectResponse
      xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
      xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
      <clientTransId>txn_1479</clientTransId>
      <serverTransId>tx_12350</serverTransId>
      <overallResult>
       <code>1000</code>
       <msg>Request Succeeded.</msg>
      </overallResult>
     </ns3:spppRejectResponse>
    </S:Body>
   </S:Envelope>

10.13. Get Destination Group

10.13. 宛先グループを取得

SSP2 uses the spppGetRequest operation to tally the last provisioned record for Destination Group DEST_GRP_SSP2_1.

SSP2はspppGetRequest操作を使用して、宛先グループDEST_GRP_SSP2_1の最後にプロビジョニングされたレコードを集計します。

<?xml version="1.0" encoding="UTF-8"?> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Header/> <soapenv:Body> <urn:spppGetRequest>  <objKey xsi:type="urn:ObjKeyType"> <rant>iana-en:222</rant> <name>DEST_GRP_SSP2_1</name> <type>DestGrp</type> </objKey> </urn:spppGetRequest> </soapenv:Body> </soapenv:Envelope> The Registry completes the request successfully and returns a favorable response.

<？xml version = "1.0" encoding = "UTF-8"？> <soapenv：Envelope xmlns：soapenv = "http://schemas.xmlsoap.org/soap/envelope/" xmlns：urn = "urn：ietf： params：xml：ns：sppf：soap：1 "xmlns：xsi =" http://www.w3.org/2001/XMLSchema-instance "> <soapenv：Header /> <soapenv：Body> <urn：spppGetRequest> <！-1回以上の繰り返し：-> <objKey xsi：type = "urn：ObjKeyType"> <rant> iana-en：222 </ rant> <name> DEST_GRP_SSP2_1 </ name> <type> DestGrp </ type> </ objKey> </ urn：spppGetRequest> </ soapenv：Body> </ soapenv：Envelope>レジストリはリクエストを正常に完了し、好ましい応答を返します。

   <?xml version="1.0" encoding="UTF-8"?>
   <S:Envelope
    xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <S:Body>
     <ns3:spppGetResponse
      xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
      xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
      <overallResult>
       <code>1000</code>
       <msg>success</msg>
      </overallResult>
      <resultObj xsi:type="ns2:DestGrpType">
       <ns2:rant>iana-en:222</ns2:rant>
       <ns2:rar>iana-en:223</ns2:rar>
       <ns2:cDate>2012-10-22T09:30:10Z</ns2:cDate>
       <ns2:dgName>DEST_GRP_SSP2_1</ns2:dgName>
      </resultObj>
     </ns3:spppGetResponse>
    </S:Body>
   </S:Envelope>

10.14. Get Public Identifier

10.14. 公開識別子を取得

SSP2 obtains the last provisioned record associated with a given TN.

SSP2は、特定のTNに関連付けられている最後にプロビジョニングされたレコードを取得します。

   <S:Envelope
    xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <S:Body>
     <ns3:spppGetResponse
      xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
      xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
      <overallResult>
       <code>1000</code>
       <msg>success</msg>
      </overallResult>
      <resultObj xsi:type="ns2:TNType">
       <ns2:rant>iana-en:222</ns2:rant>
       <ns2:rar>iana-en:223</ns2:rar>
       <ns2:cDate>2012-10-22T09:30:10Z</ns2:cDate>
       <ns2:dgName>DEST_GRP_SSP2_1</ns2:dgName>
       <ns2:tn>+12025556666</ns2:tn>
       <ns2:corInfo>
        <ns2:corClaim>true</ns2:corClaim>
        <ns2:cor>true</ns2:cor>
        <ns2:corDate>2010-05-30T09:30:10Z</ns2:corDate>
       </ns2:corInfo>
      </resultObj>
     </ns3:spppGetResponse>
    </S:Body>
   </S:Envelope>

10.15. Get SED Group Request

10.15. SEDグループリクエストを取得

SSP2 obtains the last provisioned record for the SED Group SED_GRP_SSP2_1.

SSP2は、SEDグループSED_GRP_SSP2_1の最後にプロビジョニングされたレコードを取得します。

<?xml version="1.0" encoding="UTF-8"?> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Header/> <soapenv:Body> <urn:spppGetRequest>  <objKey xsi:type="urn:ObjKeyType"> <rant>iana-en:222</rant> <name>SED_GRP_SSP2_1</name> <type>SedGrp</type> </objKey> </urn:spppGetRequest> </soapenv:Body> </soapenv:Envelope> The Registry completes the request successfully and returns a favorable response.

<？xml version = "1.0" encoding = "UTF-8"？> <soapenv：Envelope xmlns：soapenv = "http://schemas.xmlsoap.org/soap/envelope/" xmlns：urn = "urn：ietf： params：xml：ns：sppf：soap：1 "xmlns：xsi =" http://www.w3.org/2001/XMLSchema-instance "> <soapenv：Header /> <soapenv：Body> <urn：spppGetRequest> <！-1回以上の繰り返し：-> <objKey xsi：type = "urn：ObjKeyType"> <rant> iana-en：222 </ rant> <name> SED_GRP_SSP2_1 </ name> <type> SedGrp </ type> </ objKey> </ urn：spppGetRequest> </ soapenv：Body> </ soapenv：Envelope>レジストリは要求を正常に完了し、適切な応答を返します。

   <?xml version="1.0" encoding="UTF-8"?>
   <S:Envelope
    xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <S:Body>
     <ns3:spppGetResponse
      xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
      xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
      <overallResult>
       <code>1000</code>
       <msg>success</msg>
      </overallResult>
      <resultObj xsi:type="ns2:SedGrpType">
       <ns2:rant>iana-en:222</ns2:rant>
       <ns2:rar>iana-en:223</ns2:rar>
       <ns2:cDate>2012-10-22T09:30:10Z</ns2:cDate>
       <ns2:sedGrpName>SED_GRP_SSP2_1</ns2:sedGrpName>
       <ns2:sedRecRef>
        <ns2:sedKey xsi:type="ns3:ObjKeyType">
         <rant>iana-en:222</rant>
         <name>SED_SSP2_SBE2</name>
         <type>SedRec</type>
        </ns2:sedKey>
        <ns2:priority>100</ns2:priority>
       </ns2:sedRecRef>
       <ns2:sedRecRef>
        <ns2:sedKey xsi:type="ns3:ObjKeyType">
         <rant>iana-en:222</rant>
         <name>SED_SSP2_SBE4</name>
         <type>SedRec</type>
        </ns2:sedKey>
        <ns2:priority>101</ns2:priority>
       </ns2:sedRecRef>
       <ns2:dgName>DEST_GRP_SSP2_1</ns2:dgName>
       <ns2:isInSvc>true</ns2:isInSvc>
       <ns2:priority>10</ns2:priority>
      </resultObj>
     </ns3:spppGetResponse>
    </S:Body>
   </S:Envelope>

10.16. Get SED Group Offers Request

10.16. SEDグループオファーリクエストの取得

SSP2 fetches the last provisioned SED Group Offer to the <peeringOrg> SSP1.

SSP2は、最後にプロビジョニングされたSEDグループオファーを<peeringOrg> SSP1にフェッチします。

<?xml version="1.0" encoding="UTF-8"?> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"> <soapenv:Header/> <soapenv:Body> <urn:getSedGrpOffersRequest> <offeredTo>iana-en:111</offeredTo> </urn:getSedGrpOffersRequest> </soapenv:Body> </soapenv:Envelope> The Registry processes the request successfully and returns a favorable response.

<？xml version = "1.0" encoding = "UTF-8"？> <soapenv：Envelope xmlns：soapenv = "http://schemas.xmlsoap.org/soap/envelope/" xmlns：urn = "urn：ietf： params：xml：ns：sppf：soap：1 "> <soapenv：Header /> <soapenv：Body> <urn：getSedGrpOffersRequest> <offeredTo> iana-en：111 </ offeredTo> </ urn：getSedGrpOffersRequest> </ soapenv ：Body> </ soapenv：Envelope>レジストリは要求を正常に処理し、好ましい応答を返します。

   <?xml version="1.0" encoding="UTF-8"?>
   <S:Envelope
    xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <S:Body>
     <ns3:spppGetResponse
      xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
      xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
      <overallResult>
       <code>1000</code>
       <msg>success</msg>
      </overallResult>
      <resultObj xsi:type="ns2:SedGrpOfferType">
       <ns2:rant>iana-en:222</ns2:rant>
       <ns2:rar>iana-en:223</ns2:rar>
       <ns2:cDate>2012-10-22T09:30:10Z</ns2:cDate>
       <ns2:sedGrpOfferKey
        xsi:type="ns3:SedGrpOfferKeyType">
        <sedGrpKey>
         <rant>iana-en:222</rant>
         <name>SED_GRP_SSP2_1</name>
         <type>SedGrp</type>
        </sedGrpKey>
        <offeredTo>iana-en:111</offeredTo>
       </ns2:sedGrpOfferKey>
       <ns2:status>offered</ns2:status>
       <ns2:offerDateTime>
        2006-05-04T18:13:51.0Z
       </ns2:offerDateTime>
      </resultObj>
     </ns3:spppGetResponse>
    </S:Body>
   </S:Envelope>

10.17. Get Egress Route

10.17. 下りルートを取得

SSP1 wants to verify the last provisioned record for the Egress Route called EGR_RTE_01.

SSP1は、EGR_RTE_01という名前の出口ルート用にプロビジョニングされた最後のレコードを確認したいと考えています。

<?xml version="1.0" encoding="UTF-8"?> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Header/> <soapenv:Body> <urn:spppGetRequest>  <objKey xsi:type="urn:ObjKeyType"> <rant>iana-en:111</rant> <name>EGR_RTE_01</name> <type>EgrRte</type> </objKey> </urn:spppGetRequest> </soapenv:Body> </soapenv:Envelope> The Registry completes the request successfully and returns a favorable response.

<？xml version = "1.0" encoding = "UTF-8"？> <soapenv：Envelope xmlns：soapenv = "http://schemas.xmlsoap.org/soap/envelope/" xmlns：urn = "urn：ietf： params：xml：ns：sppf：soap：1 "xmlns：xsi =" http://www.w3.org/2001/XMLSchema-instance "> <soapenv：Header /> <soapenv：Body> <urn：spppGetRequest> <！-1回以上の繰り返し：-> <objKey xsi：type = "urn：ObjKeyType"> <rant> iana-en：111 </ rant> <name> EGR_RTE_01 </ name> <type> EgrRte </ type> </ objKey> </ urn：spppGetRequest> </ soapenv：Body> </ soapenv：Envelope>レジストリは要求を正常に完了し、適切な応答を返します。

   <?xml version="1.0" encoding="UTF-8"?>
   <S:Envelope
    xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <S:Body>
     <ns3:spppGetResponse
      xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
      xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
      <overallResult>
       <code>1000</code>
       <msg>success</msg>
      </overallResult>
      <resultObj xsi:type="ns2:EgrRteType">
       <ns2:rant>iana-en:222</ns2:rant>
       <ns2:rar>iana-en:223</ns2:rar>
       <ns2:cDate>2012-10-22T09:30:10Z</ns2:cDate>
       <ns2:egrRteName>EGR_RTE_01</ns2:egrRteName>
       <ns2:pref>50</ns2:pref>
       <ns2:regxRewriteRule>
        <ns2:ere>^(.*)$</ns2:ere>
        <ns2:repl>sip:\1@sbe1.ssp1.example.com</ns2:repl>
       </ns2:regxRewriteRule>
       <ns2:ingrSedGrp xsi:type="ns3:ObjKeyType">
        <rant>iana-en:222</rant>
        <name>SED_GRP_SSP2_1</name>
        <type>SedRec</type>
       </ns2:ingrSedGrp>
      </resultObj>
     </ns3:spppGetResponse>
    </S:Body>
   </S:Envelope>

10.18. Delete Destination Group

10.18. 宛先グループを削除

SSP2 initiates a request to delete the Destination Group DEST_GRP_SSP2_1.

SSP2は、宛先グループDEST_GRP_SSP2_1を削除する要求を開始します。

   <?xml version="1.0" encoding="UTF-8"?>
   <soapenv:Envelope
    xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <soapenv:Header/>
    <soapenv:Body>
     <urn:spppDelRequest>
       <!--1 or more repetitions:-->
      <objKey xsi:type="urn:ObjKeyType">
       <rant>iana-en:222</rant>
       <name>DEST_GRP_SSP2_1</name>
       <type>DestGrp</type>
      </objKey>
     </urn:spppDelRequest>
    </soapenv:Body>
   </soapenv:Envelope>

The Registry completes the request successfully and returns a favorable response.

レジストリは要求を正常に完了し、好ましい応答を返します。

   <?xml version="1.0" encoding="UTF-8"?>
   <S:Envelope
    xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
    <S:Body>
     <ns3:spppDelResponse
      xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
      xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
      <serverTransId>tx_12354</serverTransId>
      <overallResult>
       <code>1000</code>
       <msg>Request Succeeded.</msg>
      </overallResult>
     </ns3:spppDelResponse>
    </S:Body>
   </S:Envelope>

10.19. Delete Public Identifier

10.19. 公開識別子を削除

SSP2 chooses to deactivate the TN and remove it from the Registry.

SSP2は、TNを非アクティブにし、レジストリから削除することを選択します。

   <?xml version="1.0" encoding="UTF-8"?>
   <soapenv:Envelope
    xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"
    xmlns:urn1="urn:ietf:params:xml:ns:sppf:base:1"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <soapenv:Header/>
    <soapenv:Body>
     <urn:spppDelRequest>
      <!--1 or more repetitions:-->
      <objKey xsi:type="urn:PubIdKeyType">
       <rant>iana-en:222</rant>
       <number>
        <urn1:value>+12025556666</urn1:value>
        <urn1:type>TN</urn1:type>
       </number>
      </objKey>
     </urn:spppDelRequest>
    </soapenv:Body>
   </soapenv:Envelope>

The Registry completes the request successfully and returns a favorable response.

レジストリは要求を正常に完了し、好ましい応答を返します。

   <?xml version="1.0" encoding="UTF-8"?>
   <S:Envelope
    xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
    <S:Body>
     <ns3:spppDelResponse
      xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
      xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
      <serverTransId>tx_12354</serverTransId>
      <overallResult>
       <code>1000</code>
       <msg>Request Succeeded.</msg>
      </overallResult>
     </ns3:spppDelResponse>
    </S:Body>
   </S:Envelope>

10.20. Delete SED Group Request

10.20. SEDグループ要求の削除

SSP2 removes the SED Group called SED_GRP_SSP2_1.

SSP2は、SED_GRP_SSP2_1というSEDグループを削除します。

   <?xml version="1.0" encoding="UTF-8"?>
   <soapenv:Envelope
    xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <soapenv:Header/>
    <soapenv:Body>
     <urn:spppDelRequest>
       <!--1 or more repetitions:-->
      <objKey xsi:type="urn:ObjKeyType">
       <rant>iana-en:222</rant>
       <name>SED_GRP_SSP2_1</name>
       <type>SedGrp</type>
      </objKey>
     </urn:spppDelRequest>
    </soapenv:Body>
   </soapenv:Envelope>

The Registry completes the request successfully and returns a favorable response.

レジストリは要求を正常に完了し、好ましい応答を返します。

   <?xml version="1.0" encoding="UTF-8"?>
   <S:Envelope
    xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
    <S:Body>
     <ns3:spppDelResponse
      xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
      xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
      <serverTransId>tx_12354</serverTransId>
      <overallResult>
       <code>1000</code>
       <msg>Request Succeeded.</msg>
      </overallResult>
     </ns3:spppDelResponse>
    </S:Body>
   </S:Envelope>

10.21. Delete SED Group Offers Request

10.21. SEDグループオファーリクエストの削除

SSP2 no longer wants to share SED Group SED_GRP_SSP2_1 with SSP1.

SSP2は、SEDグループSED_GRP_SSP2_1をSSP1と共有する必要がなくなりました。

   <?xml version="1.0" encoding="UTF-8"?>
   <soapenv:Envelope
    xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <soapenv:Header/>
    <soapenv:Body>
     <urn:spppDelRequest>
       <!--1 or more repetitions:-->
      <objKey xsi:type="urn:SedGrpOfferKeyType">
       <sedGrpKey>
        <rant>iana-en:222</rant>
        <name>SED_GRP_SSP2_1</name>
        <type>SedGrp</type>
       </sedGrpKey>
       <offeredTo>iana-en:111</offeredTo>
      </objKey>
     </urn:spppDelRequest>
    </soapenv:Body>
   </soapenv:Envelope>

The Registry completes the request successfully and returns a favorable response. Restoring this resource sharing will require a new SED Group Offer from SSP2 to SSP1 followed by a successful SED Group Accept request from SSP1.

レジストリは要求を正常に完了し、好ましい応答を返します。このリソース共有を復元するには、SSP2からSSP1への新しいSEDグループオファーと、それに続くSSP1からの成功したSEDグループ受け入れリクエストが必要です。

   <?xml version="1.0" encoding="UTF-8"?>
   <S:Envelope
    xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
    <S:Body>
     <ns3:spppDelResponse
      xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
      xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
      <serverTransId>tx_12354</serverTransId>
      <overallResult>
       <code>1000</code>
       <msg>Request Succeeded.</msg>
      </overallResult>
     </ns3:spppDelResponse>
    </S:Body>
   </S:Envelope>

10.22. Delete Egress Route

10.22. 下りルートを削除

SSP1 decides to remove the Egress Route with the label EGR_RTE_01.

SSP1は、EGR_RTE_01というラベルの付いた出口ルートを削除することを決定します。

   <?xml version="1.0" encoding="UTF-8"?>
   <soapenv:Envelope
    xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <soapenv:Header/>
    <soapenv:Body>
     <urn:spppDelRequest>
      <!--1 or more repetitions:-->
      <objKey xsi:type="urn:ObjKeyType">
       <rant>iana-en:111</rant>
       <name>EGR_RTE_01</name>
       <type>EgrRte</type>
      </objKey>
     </urn:spppDelRequest>
    </soapenv:Body>
   </soapenv:Envelope>

The Registry completes the request successfully and returns a favorable response.

レジストリは要求を正常に完了し、好ましい応答を返します。

   <?xml version="1.0" encoding="UTF-8"?>
   <S:Envelope
    xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
    <S:Body>
     <ns3:spppDelResponse
      xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
      xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
      <serverTransId>tx_12354</serverTransId>
      <overallResult>
       <code>1000</code>
       <msg>Request Succeeded.</msg>
      </overallResult>
     </ns3:spppDelResponse>
    </S:Body>
   </S:Envelope>

10.23. Batch Request

10.23. バッチリクエスト

Following is an example of how some of the operations mentioned in previous sections MAY be performed by an SPPF client as a batch in one single SPPP over SOAP request.

以下は、前のセクションで説明した操作の一部を、SPPFクライアントが1つの単一のSPPP over SOAPリクエストのバッチとして実行する方法の例です。

In the sample request below, SSP1 wants to accept a SED Group Offer from SSP3, add a Destination Group, add a Naming Authority Pointer (NAPTR) SED Record, add a SED Group, add a SED Group Offer, delete a previously provisioned TN type Public Identifier, delete a previously provisioned SED Group, and reject a SED Group Offer from SSP4.

以下のサンプルリクエストでは、SSP1はSSP3からのSEDグループオファーを受け入れ、宛先グループを追加し、ネーミングオーソリティポインター（NAPTR）SEDレコードを追加し、SEDグループを追加し、SEDグループオファーを追加し、以前にプロビジョニングされたTNタイプを削除します公開識別子、以前にプロビジョニングされたSEDグループを削除し、SSP4からのSEDグループオファーを拒否します。

   <?xml version="1.0" encoding="UTF-8"?>
   <soapenv:Envelope
    xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"
    xmlns:urn1="urn:ietf:params:xml:ns:sppf:base:1"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <soapenv:Header/>
    <soapenv:Body>
     <urn:spppBatchRequest>
      <clientTransId>txn_1467</clientTransId>
      <minorVer>1</minorVer>

      <acceptSedGrpOffer>
       <sedGrpKey>
        <rant>iana-en:225</rant>
        <name>SED_SSP3_SBE1_Offered</name>
        <type>SedGrp</type>
       </sedGrpKey>
       <offeredTo>iana-en:222</offeredTo>
      </acceptSedGrpOffer>

      <addObj xsi:type="urn1:DestGrpType">
       <urn1:rant>iana-en:222</urn1:rant>
       <urn1:rar>iana-en:223</urn1:rar>
       <urn1:dgName>DEST_GRP_SSP2_1</urn1:dgName>
      </addObj>

      <addObj xsi:type="urn1:NAPTRType">
       <urn1:rant>iana-en:222</urn1:rant>
       <urn1:rar>iana-en:223</urn1:rar>
       <urn1:sedName>SED_SSP2_SBE2</urn1:sedName>
       <urn1:order>10</urn1:order>
       <urn1:flags>u</urn1:flags>
       <urn1:svcs>E2U+sip</urn1:svcs>

       <urn1:regx>
        <urn1:ere>^(.*)$</urn1:ere>
        <urn1:repl>sip:\1@sbe2.ssp2.example.com</urn1:repl>
       </urn1:regx>
      </addObj>

      <addObj xsi:type="urn1:SedGrpType">
       <urn1:rant>iana-en:222</urn1:rant>
       <urn1:rar>iana-en:223</urn1:rar>
       <urn1:sedGrpName>SED_GRP_SSP2_1</urn1:sedGrpName>
       <urn1:sedRecRef>
        <urn1:sedKey xsi:type="urn:ObjKeyType">
         <rant>iana-en:222</rant>
         <name>SED_SSP2_SBE2</name>
         <type>SedRec</type>
        </urn1:sedKey>
       <urn1:priority>100</urn1:priority>
       </urn1:sedRecRef>
        <urn1:dgName>DEST_GRP_SSP2_1</urn1:dgName>
        <urn1:isInSvc>true</urn1:isInSvc>
        <urn1:priority>10</urn1:priority>
      </addObj>

      <addObj xsi:type="urn1:SedGrpOfferType">
       <urn1:rant>iana-en:222</urn1:rant>
       <urn1:rar>iana-en:223</urn1:rar>
       <urn1:sedGrpOfferKey xsi:type="urn:SedGrpOfferKeyType">
        <sedGrpKey xsi:type="urn:ObjKeyType">
         <rant>iana-en:222</rant>
         <name>SED_GRP_SSP2_1</name>
         <type>SedGrp</type>
        </sedGrpKey>
        <offeredTo>iana-en:111</offeredTo>
       </urn1:sedGrpOfferKey>
       <urn1:status>offered</urn1:status>
       <urn1:offerDateTime>
        2006-05-04T18:13:51.0Z
       </urn1:offerDateTime>
      </addObj>

      <delObj xsi:type="urn:PubIdKeyType">
       <rant>iana-en:222</rant>
       <number>
        <urn1:value>+12025556666</urn1:value>
        <urn1:type>TN</urn1:type>
       </number>
      </delObj>

      <delObj xsi:type="urn:ObjKeyType">
       <rant>iana-en:222</rant>
       <name>SED_GRP_SSP2_Previous</name>
       <type>SedGrp</type>
      </delObj>

      <rejectSedGrpOffer>
       <sedGrpKey>
        <rant>iana-en:226</rant>
        <name>SED_SSP4_SBE1_Offered</name>
        <type>SedGrp</type>
       </sedGrpKey>
       <offeredTo>iana-en:222</offeredTo>
      </rejectSedGrpOffer>

     </urn:spppBatchRequest>
    </soapenv:Body>
   </soapenv:Envelope>

The Registry completes the request successfully and returns a favorable response.

レジストリは要求を正常に完了し、好ましい応答を返します。

   <?xml version="1.0" encoding="UTF-8"?>
   <S:Envelope
    xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
    <S:Body>
     <ns3:spppBatchResponse
      xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
      xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
      <serverTransId>tx_12354</serverTransId>
      <overallResult>
       <code>1000</code>
       <msg>Request Succeeded.</msg>
      </overallResult>
     </ns3:spppBatchResponse>
    </S:Body>
   </S:Envelope>

11. Security Considerations

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

The base security considerations of SPPP outlined in Section 9 of [RFC7877] also apply to SPPP over SOAP implementations. Additionally, the following must be considered:

[RFC7877]のセクション9で概説されているSPPPの基本的なセキュリティに関する考慮事項は、SPPP over SOAPの実装にも適用されます。さらに、以下を考慮する必要があります。

SPPP over SOAP is used to query and update session peering data and addresses, so the ability to access this protocol should be limited to users and systems that are authorized to query and update this data. Because this data is sent in both directions, it may not be sufficient for just the client or user to be authenticated with the server. The identity of the server should also be authenticated by the client, which is often accomplished using the TLS certificate exchange and validation described in [RFC2818].

SPPP over SOAPは、セッションピアリングデータとアドレスのクエリと更新に使用されるため、このプロトコルにアクセスする機能は、このデータのクエリと更新を許可されているユーザーとシステムに限定する必要があります。このデータは両方向に送信されるため、クライアントまたはユーザーだけをサーバーで認証するだけでは不十分な場合があります。サーバーのIDもクライアントによって認証される必要があります。これは、多くの場合、[RFC2818]で説明されているTLS証明書の交換と検証を使用して行われます。

11.1. Vulnerabilities

11.1. 脆弱性

Section 5 describes the use of HTTP and TLS as the underlying substrate protocols for SPPP over SOAP. These underlying protocols may have various vulnerabilities, and these may be inherited by SPPP over SOAP. SPPP over SOAP itself may have vulnerabilities because an authorization model is not explicitly specified in this document.

セクション5では、SPPP over SOAPの基盤となるプロトコルとしてのHTTPおよびTLSの使用について説明します。これらの基礎となるプロトコルにはさまざまな脆弱性があり、SPPP over SOAPによって継承される可能性があります。このドキュメントでは承認モデルが明示的に指定されていないため、SPPP over SOAP自体に脆弱性がある可能性があります。

During a TLS handshake, TLS servers can optionally request a certificate from a TLS client; that option is not a requirement for this protocol. This presents a denial-of-service risk in which unauthenticated clients can consume server CPU resources by creating TLS sessions. The risk is increased if the server supports client-initiated renegotiation. This risk can be mitigated by disabling client-initiated renegotiation on the server and by ensuring that other means (such as firewall access control lists) are used to restrict unauthenticated client access to servers.

TLSハンドシェイク中に、TLSサーバーはオプションでTLSクライアントに証明書を要求できます。このオプションは、このプロトコルの要件ではありません。これは、認証されていないクライアントがTLSセッションを作成することによってサーバーのCPUリソースを消費する可能性があるサービス拒否のリスクを示します。サーバーがクライアントが開始した再ネゴシエーションをサポートしている場合、リスクが高まります。このリスクは、サーバーでクライアントが開始した再ネゴシエーションを無効にし、他の手段（ファイアウォールアクセスコントロールリストなど）を使用してサーバーへの認証されていないクライアントアクセスを制限することで軽減できます。

In conjunction with the above, it is important that SPPP over SOAP implementations implement an authorization model that considers the source of each query or update request and determines whether it is reasonable to authorize that source to perform that specific query or update.

上記と併せて、SPPP over SOAP実装が、各クエリまたは更新リクエストのソースを考慮し、その特定のクエリまたは更新を実行するためにそのソースを承認することが妥当かどうかを判断する承認モデルを実装することが重要です。

12. IANA Considerations

12. IANAに関する考慮事項

This document uses URNs to describe XML Namespaces and XML Schemas. According to [RFC3688], IANA has performed the following URN assignment:

このドキュメントでは、URNを使用してXML名前空間とXMLスキーマについて説明します。 [RFC3688]によれば、IANAは次のURN割り当てを実行しました：

      URN: urn:ietf:params:xml:ns:sppf:soap:1

Registrant Contact: IESG

登録者の連絡先：IESG

XML: See Section 9 of [RFC7878]

XML：[RFC7878]のセクション9を参照

13. References

13. 参考文献

13.1. Normative References

13.1. 引用文献

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

[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <http://www.rfc-editor.org/info/rfc3688>.

[RFC3688] Mealling、M。、「The IETF XML Registry」、BCP 81、RFC 3688、DOI 10.17487 / RFC3688、2004年1月、<http://www.rfc-editor.org/info/rfc3688>。

[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.

[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、DOI 10.17487 / RFC5246、2008年8月、<http://www.rfc-editor.org/info / rfc5246>。

[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>.

[RFC7230]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Message Syntax and Routing」、RFC 7230、DOI 10.17487 / RFC7230、2014年6月、<http://www.rfc-editor.org/info/ rfc7230>。

[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <http://www.rfc-editor.org/info/rfc7231>.

[RFC7231]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Semantics and Content」、RFC 7231、DOI 10.17487 / RFC7231、2014年6月、<http://www.rfc-editor.org/info/rfc7231 >。

[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, DOI 10.17487/RFC7235, June 2014, <http://www.rfc-editor.org/info/rfc7235>.

[RFC7235]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Authentication」、RFC 7235、DOI 10.17487 / RFC7235、2014年6月、<http://www.rfc-editor.org/info/rfc7235>。

[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <http://www.rfc-editor.org/info/rfc7525>.

[RFC7525] Sheffer、Y.、Holz、R。、およびP. Saint-Andre、「Transport Layer Security（TLS）およびDatagram Transport Layer Security（DTLS）の安全な使用に関する推奨事項」、BCP 195、RFC 7525、DOI 10.17487 / RFC7525、2015年5月、<http://www.rfc-editor.org/info/rfc7525>。

[RFC7877] Cartwright, K., Bhatia, V., Ali, S., and D. Schwartz, "Session Peering Provisioning Framework (SPPF)", RFC 7877, DOI 10.17487/RFC7877, August 2016, <http://www.rfc-editor.org/info/rfc7877>.

[RFC7877] Cartwright、K.、Bhatia、V.、Ali、S。、およびD. Schwartz、「Session Peering Provisioning Framework（SPPF）」、RFC 7877、DOI 10.17487 / RFC7877、2016年8月、<http：// www .rfc-editor.org / info / rfc7877>。

[SOAPREF] Gudgin, M., Hadley, M., Moreau, J., and H. Nielsen, "SOAP Version 1.2 Part 1: Messaging Framework (Second Edition)", W3C Recommendation REC-SOAP12-part1-20070427, April 2007, <http://www.w3.org/TR/soap12-part1/>.

[SOAPREF] Gudgin、M.、Hadley、M.、Moreau、J。、およびH. Nielsen、「SOAPバージョン1.2パート1：メッセージングフレームワーク（第2版）」、W3C勧告REC-SOAP12-part1-20070427、2007年4月、<http://www.w3.org/TR/soap12-part1/>。

13.2. Informative References

13.2. 参考引用

[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, <http://www.rfc-editor.org/info/rfc2818>.

[RFC2818] Rescorla、E。、「HTTP Over TLS」、RFC 2818、DOI 10.17487 / RFC2818、2000年5月、<http://www.rfc-editor.org/info/rfc2818>。

[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, <http://www.rfc-editor.org/info/rfc5321>.

[RFC5321] Klensin、J。、「Simple Mail Transfer Protocol」、RFC 5321、DOI 10.17487 / RFC5321、2008年10月、<http://www.rfc-editor.org/info/rfc5321>。

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

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

[WSDLREF] Christensen, E., Curbera, F., Meredith, G., and S. Weerawarana, "Web Services Description Language (WSDL) 1.1", W3C Note NOTE-wsdl-20010315, March 2001, <http://www.w3.org/TR/2001/NOTE-wsdl-20010315>.

[WSDLREF] Christensen、E.、Curbera、F.、Meredith、G。、およびS. Weerawarana、「Webサービス記述言語（WSDL）1.1」、W3C Note NOTE-wsdl-20010315、2001年3月、<http：// www.w3.org/TR/2001/NOTE-wsdl-20010315>。

Acknowledgements

謝辞

This document is a result of various discussions held with the IETF DRINKS working group, specifically the protocol design team, with contributions from the following individuals, in alphabetical order: Syed Ali, Vikas Bhatia, Kenneth Cartwright, Sumanth Channabasappa, Lisa Dusseault, Deborah A. Guyton, Scott Hollenbeck, Otmar Lendl, Manjul Maharishi, Mickael Marrache, Alexander Mayrhofer, Samuel Melloul, Jean-Francois Mule, Peter Saint-Andre, David Schwartz, and Richard Shockey.

このドキュメントは、IETF DRINKSワーキンググループ、具体的にはプロトコル設計チームとのさまざまな議論の結果であり、次の個人からの貢献がアルファベット順に掲載されています。SyedAli、Vikas Bhatia、Kenneth Cartwright、Sumanth Channabasappa、Lisa Dusseault、Deborah Aガイトン、スコットホレンベック、オットマーレンドル、マンジュルマハリシ、ミカエルマラシェ、アレクサンダーマイヤーホーファー、サミュエルメロール、ジャンフランソワミュール、ピーターサンアンドレ、デビッドシュワルツ、リチャードショッキー。

Authors' Addresses

著者のアドレス

Kenneth Cartwright TNS 10740 Parkridge Boulevard Reston, VA 20191 United States

Kenneth Cartwright TNS 10740 Parkridge Boulevard Reston、VA 20191アメリカ合衆国

   Email: kcartwright@tnsi.com

Vikas Bhatia TNS 10740 Parkridge Boulevard Reston, VA 20191 United States

Vikas Bhatia TNS 10740 Parkridge Boulevard Reston、VA 20191アメリカ合衆国

   Email: vbhatia@tnsi.com

Jean-Francois Mule Apple Inc. 1 Infinite Loop Cupertino, CA 95014 United States

Jean-Francois Mule Apple Inc. 1 Infinite Loop Cupertino、CA 95014アメリカ合衆国

   Email: jfmule@apple.com

Alexander Mayrhofer nic.at GmbH Karlsplatz 1/2/9 Wien A-1010 Austria

Alexander Mayrhofer nic.at GmbH Karlsplatz 1/2/9ウィーンA-1010オーストリア

   Email: alexander.mayrhofer@nic.at