Internet Engineering Task Force (IETF)                     K. Cartwright
Request for Comments: 7877                                     V. Bhatia
Category: Standards Track                                            TNS
ISSN: 2070-1721                                                   S. Ali
                                                                 NeuStar
                                                             D. Schwartz
                                                                XConnect
                                                             August 2016
        
Internet Engineering Task Force (IETF)                     K. Cartwright
Request for Comments: 7877                                     V. Bhatia
Category: Standards Track                                            TNS
ISSN: 2070-1721                                                   S. Ali
                                                                 NeuStar
                                                             D. Schwartz
                                                                XConnect
                                                             August 2016
        

Session Peering Provisioning Framework (SPPF)

会话对等资源调配框架(SPPF)

Abstract

摘要

This document specifies the data model and the overall structure for a framework to provision Session Establishment Data (SED) into Session Data Registries and SIP Service Provider (SSP) data stores. The framework is called the "Session Peering Provisioning Framework" (SPPF). The provisioned data is typically used by network elements for session establishment.

本文档指定了将会话建立数据(SED)提供给会话数据注册表和SIP服务提供商(SSP)数据存储的框架的数据模型和总体结构。该框架称为“会话对等资源调配框架”(SPPF)。所提供的数据通常由网络元件用于会话建立。

Status of This Memo

关于下段备忘

This is an Internet Standards Track document.

这是一份互联网标准跟踪文件。

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)的产品。它代表了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/rfc7877.

有关本文件当前状态、任何勘误表以及如何提供反馈的信息,请访问http://www.rfc-editor.org/info/rfc7877.

Copyright Notice

版权公告

Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.

版权所有(c)2016 IETF信托基金和确定为文件作者的人员。版权所有。

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)自本文件出版之日起生效。请仔细阅读这些文件,因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本,并提供简化BSD许可证中所述的无担保。

Table of Contents

目录

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   6
   3.  Framework High-Level Design . . . . . . . . . . . . . . . . .   7
     3.1.  Framework Data Model  . . . . . . . . . . . . . . . . . .   7
     3.2.  Time Value  . . . . . . . . . . . . . . . . . . . . . . .  10
     3.3.  Extensibility . . . . . . . . . . . . . . . . . . . . . .  10
   4.  Substrate Protocol Requirements . . . . . . . . . . . . . . .  11
     4.1.  Mandatory Substrate . . . . . . . . . . . . . . . . . . .  11
     4.2.  Connection Oriented . . . . . . . . . . . . . . . . . . .  11
     4.3.  Request and Response Model  . . . . . . . . . . . . . . .  11
     4.4.  Connection Lifetime . . . . . . . . . . . . . . . . . . .  11
     4.5.  Authentication  . . . . . . . . . . . . . . . . . . . . .  12
     4.6.  Authorization . . . . . . . . . . . . . . . . . . . . . .  12
     4.7.  Confidentiality and Integrity . . . . . . . . . . . . . .  12
     4.8.  Near Real Time  . . . . . . . . . . . . . . . . . . . . .  12
     4.9.  Request and Response Sizes  . . . . . . . . . . . . . . .  12
     4.10. Request and Response Correlation  . . . . . . . . . . . .  13
     4.11. Request Acknowledgement . . . . . . . . . . . . . . . . .  13
   5.  Base Framework Data Structures and Response Codes . . . . . .  13
     5.1.  Basic Object Type and Organization Identifiers  . . . . .  13
     5.2.  Various Object Key Types  . . . . . . . . . . . . . . . .  14
       5.2.1.  Generic Object Key Type . . . . . . . . . . . . . . .  14
       5.2.2.  Derived Object Key Types  . . . . . . . . . . . . . .  15
     5.3.  Response Message Types  . . . . . . . . . . . . . . . . .  16
   6.  Framework Data Model Objects  . . . . . . . . . . . . . . . .  18
     6.1.  Destination Group . . . . . . . . . . . . . . . . . . . .  18
     6.2.  Public Identifier . . . . . . . . . . . . . . . . . . . .  19
     6.3.  SED Group . . . . . . . . . . . . . . . . . . . . . . . .  25
     6.4.  SED Record  . . . . . . . . . . . . . . . . . . . . . . .  29
     6.5.  SED Group Offer . . . . . . . . . . . . . . . . . . . . .  33
     6.6.  Egress Route  . . . . . . . . . . . . . . . . . . . . . .  35
        
   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   6
   3.  Framework High-Level Design . . . . . . . . . . . . . . . . .   7
     3.1.  Framework Data Model  . . . . . . . . . . . . . . . . . .   7
     3.2.  Time Value  . . . . . . . . . . . . . . . . . . . . . . .  10
     3.3.  Extensibility . . . . . . . . . . . . . . . . . . . . . .  10
   4.  Substrate Protocol Requirements . . . . . . . . . . . . . . .  11
     4.1.  Mandatory Substrate . . . . . . . . . . . . . . . . . . .  11
     4.2.  Connection Oriented . . . . . . . . . . . . . . . . . . .  11
     4.3.  Request and Response Model  . . . . . . . . . . . . . . .  11
     4.4.  Connection Lifetime . . . . . . . . . . . . . . . . . . .  11
     4.5.  Authentication  . . . . . . . . . . . . . . . . . . . . .  12
     4.6.  Authorization . . . . . . . . . . . . . . . . . . . . . .  12
     4.7.  Confidentiality and Integrity . . . . . . . . . . . . . .  12
     4.8.  Near Real Time  . . . . . . . . . . . . . . . . . . . . .  12
     4.9.  Request and Response Sizes  . . . . . . . . . . . . . . .  12
     4.10. Request and Response Correlation  . . . . . . . . . . . .  13
     4.11. Request Acknowledgement . . . . . . . . . . . . . . . . .  13
   5.  Base Framework Data Structures and Response Codes . . . . . .  13
     5.1.  Basic Object Type and Organization Identifiers  . . . . .  13
     5.2.  Various Object Key Types  . . . . . . . . . . . . . . . .  14
       5.2.1.  Generic Object Key Type . . . . . . . . . . . . . . .  14
       5.2.2.  Derived Object Key Types  . . . . . . . . . . . . . .  15
     5.3.  Response Message Types  . . . . . . . . . . . . . . . . .  16
   6.  Framework Data Model Objects  . . . . . . . . . . . . . . . .  18
     6.1.  Destination Group . . . . . . . . . . . . . . . . . . . .  18
     6.2.  Public Identifier . . . . . . . . . . . . . . . . . . . .  19
     6.3.  SED Group . . . . . . . . . . . . . . . . . . . . . . . .  25
     6.4.  SED Record  . . . . . . . . . . . . . . . . . . . . . . .  29
     6.5.  SED Group Offer . . . . . . . . . . . . . . . . . . . . .  33
     6.6.  Egress Route  . . . . . . . . . . . . . . . . . . . . . .  35
        
   7.  Framework Operations  . . . . . . . . . . . . . . . . . . . .  36
     7.1.  Add Operation . . . . . . . . . . . . . . . . . . . . . .  37
     7.2.  Delete Operation  . . . . . . . . . . . . . . . . . . . .  37
     7.3.  Get Operations  . . . . . . . . . . . . . . . . . . . . .  38
     7.4.  Accept Operations . . . . . . . . . . . . . . . . . . . .  38
     7.5.  Reject Operations . . . . . . . . . . . . . . . . . . . .  39
     7.6.  Get Server Details Operation  . . . . . . . . . . . . . .  39
   8.  XML Considerations  . . . . . . . . . . . . . . . . . . . . .  40
     8.1.  Namespaces  . . . . . . . . . . . . . . . . . . . . . . .  40
     8.2.  Versioning and Character Encoding . . . . . . . . . . . .  40
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  41
     9.1.  Confidentiality and Authentication  . . . . . . . . . . .  41
     9.2.  Authorization . . . . . . . . . . . . . . . . . . . . . .  41
     9.3.  Denial of Service . . . . . . . . . . . . . . . . . . . .  41
       9.3.1.  DoS Issues Inherited from the Substrate Mechanism . .  42
       9.3.2.  DoS Issues Specific to SPPF . . . . . . . . . . . . .  42
     9.4.  Information Disclosure  . . . . . . . . . . . . . . . . .  43
     9.5.  Non-repudiation . . . . . . . . . . . . . . . . . . . . .  43
     9.6.  Replay Attacks  . . . . . . . . . . . . . . . . . . . . .  43
     9.7.  Compromised or Malicious Intermediary . . . . . . . . . .  44
   10. Internationalization Considerations . . . . . . . . . . . . .  44
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  44
     11.1.  URN Assignments  . . . . . . . . . . . . . . . . . . . .  44
     11.2.  Organization Identifier Namespace Registry . . . . . . .  45
   12. Formal Specification  . . . . . . . . . . . . . . . . . . . .  45
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  54
     13.1.  Normative References . . . . . . . . . . . . . . . . . .  54
     13.2.  Informative References . . . . . . . . . . . . . . . . .  55
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  57
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  57
        
   7.  Framework Operations  . . . . . . . . . . . . . . . . . . . .  36
     7.1.  Add Operation . . . . . . . . . . . . . . . . . . . . . .  37
     7.2.  Delete Operation  . . . . . . . . . . . . . . . . . . . .  37
     7.3.  Get Operations  . . . . . . . . . . . . . . . . . . . . .  38
     7.4.  Accept Operations . . . . . . . . . . . . . . . . . . . .  38
     7.5.  Reject Operations . . . . . . . . . . . . . . . . . . . .  39
     7.6.  Get Server Details Operation  . . . . . . . . . . . . . .  39
   8.  XML Considerations  . . . . . . . . . . . . . . . . . . . . .  40
     8.1.  Namespaces  . . . . . . . . . . . . . . . . . . . . . . .  40
     8.2.  Versioning and Character Encoding . . . . . . . . . . . .  40
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  41
     9.1.  Confidentiality and Authentication  . . . . . . . . . . .  41
     9.2.  Authorization . . . . . . . . . . . . . . . . . . . . . .  41
     9.3.  Denial of Service . . . . . . . . . . . . . . . . . . . .  41
       9.3.1.  DoS Issues Inherited from the Substrate Mechanism . .  42
       9.3.2.  DoS Issues Specific to SPPF . . . . . . . . . . . . .  42
     9.4.  Information Disclosure  . . . . . . . . . . . . . . . . .  43
     9.5.  Non-repudiation . . . . . . . . . . . . . . . . . . . . .  43
     9.6.  Replay Attacks  . . . . . . . . . . . . . . . . . . . . .  43
     9.7.  Compromised or Malicious Intermediary . . . . . . . . . .  44
   10. Internationalization Considerations . . . . . . . . . . . . .  44
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  44
     11.1.  URN Assignments  . . . . . . . . . . . . . . . . . . . .  44
     11.2.  Organization Identifier Namespace Registry . . . . . . .  45
   12. Formal Specification  . . . . . . . . . . . . . . . . . . . .  45
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  54
     13.1.  Normative References . . . . . . . . . . . . . . . . . .  54
     13.2.  Informative References . . . . . . . . . . . . . . . . .  55
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  57
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  57
        
1. Introduction
1. 介绍

Service Providers (SPs) and enterprises use routing databases known as Registries to make session routing decisions for Voice over IP, SMS, and Multimedia Messaging Service (MMS) traffic exchanges. This document is narrowly focused on the provisioning framework for these Registries. This framework prescribes a way for an entity to provision session-related data into a Session Peering Provisioning Protocol (SPPP) Registry (or "Registry"). The data being provisioned can be optionally shared with other participating peering entities. The requirements and use cases driving this framework have been documented in [RFC6461].

服务提供商(SP)和企业使用称为注册表的路由数据库为IP语音、SMS和彩信服务(MMS)流量交换做出会话路由决策。本文档仅关注这些注册中心的供应框架。该框架规定了实体将会话相关数据提供给会话对等设置协议(SPPP)注册表(或“注册表”)的方法。正在供应的数据可以选择性地与其他参与对等实体共享。驱动该框架的需求和用例已记录在[RFC6461]中。

Three types of provisioning flows have been described in the use case document: client to Registry, Registry to local data repository, and Registry to Registry. This document addresses client-to-Registry flow enabling the ability to provision Session Establishment Data

用例文档中描述了三种类型的供应流:客户机到注册表、注册表到本地数据存储库和注册表到注册表。本文档介绍了从客户端到注册表的流程,从而能够提供会话建立数据

(SED). The framework that supports the flow of messages to facilitate client-to-Registry provisioning is referred to as the "Session Peering Provisioning Framework" (SPPF).

(SED)。支持消息流以促进客户端到注册表资源调配的框架称为“会话对等资源调配框架”(SPPF)。

The roles of the "client" and the "server" only apply to the connection, and those roles are not related in any way to the type of entity that participates in a protocol exchange. For example, a Registry might also include a "client" when such a Registry initiates a connection (for example, for data distribution to an SSP).

“客户端”和“服务器”的角色仅适用于连接,这些角色与参与协议交换的实体类型没有任何关系。例如,当注册中心启动连接时(例如,将数据分发到SSP),注册中心还可能包括“客户机”。

   *--------*               *------------*               *------------*
   |        | (1) Client   |             | (3) Registry  |            |
   | Client | ------------> |  Registry  |<------------->|  Registry  |
   |        |   to Registry |            |  to Registry  |            |
   *--------*               *------------*               *------------*
                                 /  \                          \
                                /    \                          \
                               /      \                          \
                              /        \                          v
                             /          \                         ...
                            /            \
                           / (2) Distrib  \
                          / Registry data  \
                         /  to local data   \
                        V      store         V
                       +----------+       +----------+
                       |Local Data|       |Local Data|
                       |Repository|       |Repository|
                       +----------+       +----------+
        
   *--------*               *------------*               *------------*
   |        | (1) Client   |             | (3) Registry  |            |
   | Client | ------------> |  Registry  |<------------->|  Registry  |
   |        |   to Registry |            |  to Registry  |            |
   *--------*               *------------*               *------------*
                                 /  \                          \
                                /    \                          \
                               /      \                          \
                              /        \                          v
                             /          \                         ...
                            /            \
                           / (2) Distrib  \
                          / Registry data  \
                         /  to local data   \
                        V      store         V
                       +----------+       +----------+
                       |Local Data|       |Local Data|
                       |Repository|       |Repository|
                       +----------+       +----------+
        

Figure 1: Three Registry Provisioning Flows

图1:三个注册表配置流

A "terminating" SSP provisions SED into the Registry to be selectively shared with other peer SSPs.

将“终止”SSP条款写入注册表,以便有选择地与其他对等SSP共享。

SED is typically used by various downstream SIP-signaling systems to route a call to the next hop associated with the called domain. These systems typically use a local data store ("Local Data Repository") as their source of session routing information. More specifically, the SED is the set of parameters that the outgoing Signaling Path Border Elements (SBEs) need to initiate the session. See [RFC5486] for more details.

SED通常由各种下游SIP信令系统用于将呼叫路由到与被呼叫域相关联的下一跳。这些系统通常使用本地数据存储(“本地数据存储库”)作为会话路由信息的来源。更具体地说,SED是出站信令路径边界元素(sbe)启动会话所需的一组参数。有关更多详细信息,请参阅[RFC5486]。

A Registry may distribute the provisioned data into local data repositories or may additionally offer a central query-resolution service (not shown in the above figure) for query purposes.

注册表可以将配置的数据分发到本地数据存储库中,也可以另外提供一个用于查询目的的中央查询解决服务(上图中未显示)。

A key requirement for the SPPF is to be able to accommodate two basic deployment scenarios:

SPPF的关键要求是能够适应两种基本部署场景:

1. A resolution system returns a Lookup Function (LUF) that identifies the target domain to assist in call routing (as described in Section 4.3.3 of [RFC5486]). In this case, the querying entity may use other means to perform the Location Routing Function (LRF), which in turn helps determine the actual location of the Signaling Function in that domain.

1. 解析系统返回一个查找函数(LUF),该函数识别目标域以协助呼叫路由(如[RFC5486]第4.3.3节所述)。在这种情况下,查询实体可以使用其他手段来执行位置路由功能(LRF),这反过来有助于确定信令功能在该域中的实际位置。

2. A resolution system returns an LRF that comprises the location (address) of the Signaling Function in the target domain (as described in [RFC5486]).

2. 解析系统返回一个LRF,该LRF包含信号功能在目标域中的位置(地址)(如[RFC5486]中所述)。

In terms of framework design, SPPF is agnostic to the substrate protocol. This document includes the specification of the data model and identifies, but does not specify, the means to enable protocol operations within a request and response structure. That aspect of the specification has been delegated to the "protocol" specification for the framework. To encourage interoperability, the framework supports extensibility aspects.

在框架设计方面,SPPF与基板协议无关。本文档包括数据模型的规范,并确定但未指定在请求和响应结构中启用协议操作的方法。规范的这一方面已委托给框架的“协议”规范。为了鼓励互操作性,该框架支持可扩展性方面。

In this document, an XML Schema is used to describe the building blocks of the SPPF and to express the data types, semantic relationships between the various data types, and various constraints as a binding construct. However, a "protocol" specification is free to choose any data representation format as long as it meets the requirements laid out in the SPPF XML Schema Definition (XSD). As an example, XML and JSON are two widely used data representation formats.

在本文档中,XML模式用于描述SPPF的构建块,并将数据类型、各种数据类型之间的语义关系和各种约束表示为绑定构造。但是,“协议”规范可以自由选择任何数据表示格式,只要它满足SPPF XML模式定义(XSD)中列出的要求。例如,XML和JSON是两种广泛使用的数据表示格式。

This document is organized as follows:

本文件的组织结构如下:

o Section 2 provides the terminology

o 第2节提供了术语

o Section 3 provides an overview of SPPF, including functional entities and a data model

o 第3节概述了SPPF,包括功能实体和数据模型

o Section 4 specifies requirements for SPPF substrate protocols

o 第4节规定了SPPF基板协议的要求

o Section 5 describes the base framework data structures, the generic response types that MUST be supported by a conforming substrate "protocol" specification, and the basic object type from which most first-class objects extend

o 第5节描述了基本框架数据结构、必须由一致性基板“协议”规范支持的通用响应类型,以及大多数一级对象扩展的基本对象类型

o Section 6 provides a detailed description of the data model object specifications

o 第6节提供了数据模型对象规范的详细描述

o Section 7 describes the operations that are supported by the data model

o 第7节描述了数据模型支持的操作

o Section 8 defines XML considerations XML parsers must meet to conform to this specification

o 第8节定义了XML解析器必须满足的XML注意事项,以符合本规范

o Sections 9 - 11 discuss security, internationalization, and IANA considerations, respectively

o 第9-11节分别讨论了安全性、国际化和IANA考虑事项

o Section 12 normatively defines the SPPF using its XSD.

o 第12节使用其XSD规范性地定义了SPPF。

2. Terminology
2. 术语

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

本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。

This document reuses terms from [RFC3261], [RFC5486], use cases and requirements documented in [RFC6461], and the ENUM Validation Architecture [RFC4725].

本文档重用了[RFC3261]、[RFC5486]中的术语、[RFC6461]中记录的用例和需求以及枚举验证架构[RFC4725]。

This document defines the following additional terms:

本文件定义了以下附加术语:

SPPF: Session Peering Provisioning Framework, which is the framework used by a substrate protocol to provision data into a Registry (see arrow labeled "1" in Figure 1 of [RFC6461]). It is the primary scope of this document.

SPPF:Session Peering Provisioning Framework,是底层协议用于将数据提供给注册表的框架(参见[RFC6461]图1中标记为“1”的箭头)。这是本文件的主要范围。

Client: In the context of SPPF, this is an application that initiates a provisioning request. It is sometimes referred to as a "Registry client".

客户端:在SPPF的上下文中,这是一个启动配置请求的应用程序。它有时被称为“注册表客户端”。

Server: In the context of SPPF, this is an application that receives a provisioning request and responds accordingly.

服务器:在SPPF上下文中,这是一个接收配置请求并相应响应的应用程序。

Registry: The Registry operates a master database of SED for one or more Registrants.

注册表:注册表为一个或多个注册人运行SED主数据库。

Registrant: The definition of a Registrant is based on [RFC4725]. It is the end user, person, or organization that is the "holder" of the SED being provisioned into the Registry by a Registrar. For example, in [RFC6461], a Registrant is pictured as an SP in Figure 2.

注册人:注册人的定义基于[RFC4725]。最终用户、个人或组织是SED的“持有人”,该SED由注册机构提供到注册中心。例如,在[RFC6461]中,注册人在图2中被描绘成SP。

Within the confines of a Registry, a Registrant is uniquely identified by the "rant" element.

在注册处的范围内,注册人由“rant”元素唯一标识。

Registrar: The definition of a Registrar is based on [RFC4725]. It is an entity that performs provisioning operations on behalf of a Registrant by interacting with the Registry via SPPF operations. In other words, the Registrar is the SPPF client. The Registrar and Registrant roles are logically separate to allow, but not require, a single Registrar to perform provisioning operations on behalf of more than one Registrant.

注册商:注册商的定义基于[RFC4725]。它是通过SPPF操作与注册表交互,代表注册人执行资源调配操作的实体。换句话说,注册人是SPPF客户。注册者和注册者角色在逻辑上是分开的,允许但不要求一个注册者代表多个注册者执行供应操作。

Peering Organization: A peering organization is an entity to which a Registrant's SED Groups are made visible using the operations of SPPF.

对等组织:对等组织是指使用SPPF的操作使注册人的SED组可见的实体。

3. Framework High-Level Design
3. 框架高层设计

This section introduces the structure of the data model and provides the information framework for the SPPF. The data model is defined along with all the objects manipulated by a conforming substrate protocol and their relationships.

本节介绍数据模型的结构,并提供SPPF的信息框架。数据模型与由一致性基板协议操纵的所有对象及其关系一起定义。

3.1. Framework Data Model
3.1. 框架数据模型

The data model illustrated and described in Figure 2 defines the logical objects and the relationships between these objects supported by SPPF. SPPF defines protocol operations through which an SPPF client populates a Registry with these logical objects. SPPF clients belonging to different Registrars may provision data into the Registry using a conforming substrate protocol that implements these operations

图2中说明和描述的数据模型定义了SPPF支持的逻辑对象以及这些对象之间的关系。SPPF定义协议操作,SPPF客户机通过该协议操作使用这些逻辑对象填充注册表。属于不同注册商的SPPF客户可以使用实现这些操作的一致性基板协议向注册中心提供数据

The logical structure presented below is consistent with the terminology and requirements defined in [RFC6461].

下面给出的逻辑结构与[RFC6461]中定义的术语和要求一致。

       +-------------+                        +-----------------+
       | All object  |                        |Egress Route:    |
       | types       |                   0..n | rant,           |
       +-------------+                     +--| egrRteName,     |
             |0..n                        /   | pref,           |
             |                           /    | regxRewriteRule,|
             |2                         /     | ingrSedGrp,     |
   +----------------------+            /      | svcs            |
   |Organization:         |           /       +-----------------+
   | orgId                |          /
   +----------------------+         /
          |0..n                    /
          |                       /        ("rant" = Registrant)
          |A SED Group is        /
          |associated with      /
          |zero or more        /              +---[abstract]----+
          |peering            /               | SED Record:     |
          |organizations     /                |  rant,          |
          |                 /                 |  sedName,       |0..n
          |0..n            /                  |  sedFunction,   |------|
   +--------+--------------+0..n          0..n|  isInSvc,       |      |
   |SED Group:             |------------------|  ttl            |      |
   |  rant,                |                  +-----------------+      |
   |  sedGrpName,          |                      ^ Various types      |
   |  isInSvc,             |                      | of SED Records     |
   |  sedRecRef,           |                      |                    |
   |  peeringOrg,          |                +-----+------------+       |
   |  sourceIdent,         |                |        |         |       |
   |  priority,            |             +----+  +-------+  +----+     |
   |  dgName               |             | URI|  | NAPTR |  | NS |     |
   +-----------------------+             +----+  +-------+  +----+     |
          |0..n                                                        |
          |                                 +-----[abstract]------+    |
          |0..n                             |Public Identifier:   |    |
      +----------------------+0..n      0..n|  rant,              |    |
      | Dest Group:          |--------------|  publicIdentifier,  |    |
      |   rant,              |              |  dgName             |    |
      |   dgName             |              |                     |    |
      +----------------------+              +---------------------+    |
                                                     ^ Various types   |
                 +---------+-------+------+----------+ of Public       |
                 |         |       |      |          | Identifiers     |
              +------+  +-----+  +-----+ +-----+  +------+             |
              |  URI |  | TNP |  | TNR | | RN  |  |  TN  |-------------|
              +------+  +-----+  +-----+ +-----+  +------+  0..n
        
       +-------------+                        +-----------------+
       | All object  |                        |Egress Route:    |
       | types       |                   0..n | rant,           |
       +-------------+                     +--| egrRteName,     |
             |0..n                        /   | pref,           |
             |                           /    | regxRewriteRule,|
             |2                         /     | ingrSedGrp,     |
   +----------------------+            /      | svcs            |
   |Organization:         |           /       +-----------------+
   | orgId                |          /
   +----------------------+         /
          |0..n                    /
          |                       /        ("rant" = Registrant)
          |A SED Group is        /
          |associated with      /
          |zero or more        /              +---[abstract]----+
          |peering            /               | SED Record:     |
          |organizations     /                |  rant,          |
          |                 /                 |  sedName,       |0..n
          |0..n            /                  |  sedFunction,   |------|
   +--------+--------------+0..n          0..n|  isInSvc,       |      |
   |SED Group:             |------------------|  ttl            |      |
   |  rant,                |                  +-----------------+      |
   |  sedGrpName,          |                      ^ Various types      |
   |  isInSvc,             |                      | of SED Records     |
   |  sedRecRef,           |                      |                    |
   |  peeringOrg,          |                +-----+------------+       |
   |  sourceIdent,         |                |        |         |       |
   |  priority,            |             +----+  +-------+  +----+     |
   |  dgName               |             | URI|  | NAPTR |  | NS |     |
   +-----------------------+             +----+  +-------+  +----+     |
          |0..n                                                        |
          |                                 +-----[abstract]------+    |
          |0..n                             |Public Identifier:   |    |
      +----------------------+0..n      0..n|  rant,              |    |
      | Dest Group:          |--------------|  publicIdentifier,  |    |
      |   rant,              |              |  dgName             |    |
      |   dgName             |              |                     |    |
      +----------------------+              +---------------------+    |
                                                     ^ Various types   |
                 +---------+-------+------+----------+ of Public       |
                 |         |       |      |          | Identifiers     |
              +------+  +-----+  +-----+ +-----+  +------+             |
              |  URI |  | TNP |  | TNR | | RN  |  |  TN  |-------------|
              +------+  +-----+  +-----+ +-----+  +------+  0..n
        

Figure 2: Framework Data Model

图2:框架数据模型

The objects and attributes that comprise the data model can be described as follows (objects listed from the bottom up):

组成数据模型的对象和属性可以描述如下(从下到上列出的对象):

o Public Identifier: From a broad perspective, a Public Identifier is a well-known attribute that is used as the key to perform resolution lookups. Within the context of SPPF, a Public Identifier object can be a Telephone Number (TN), a range of TNs, a Public Switched Telephone Network (PSTN) Routing Number (RN), a TN prefix, or a URI.

o 公共标识符:从广泛的角度来看,公共标识符是一个众所周知的属性,用作执行解析查找的键。在SPPF的上下文中,公共标识符对象可以是电话号码(TN)、TN范围、公共交换电话网(PSTN)路由号码(RN)、TN前缀或URI。

An SPPF Public Identifier may be a member of zero or more Destination Groups to create logical groupings of Public Identifiers that share a common set of SED (e.g., routes).

SPPF公共标识符可以是零个或多个目的地组的成员,以创建共享一组公共SED(例如,路由)的公共标识符的逻辑分组。

A TN Public Identifier may optionally be associated with zero or more individual SED Records. This ability for a Public Identifier to be directly associated with a SED Record, as opposed to forcing membership in one or more Destination Groups, supports use cases where the SED Record contains data specifically tailored to an individual TN Public Identifier.

TN公共标识符可选择性地与零个或多个单独的SED记录相关联。与强制成为一个或多个目标组的成员相比,公共标识符直接与SED记录关联的这种能力支持SED记录包含专门针对单个公共标识符定制的数据的用例。

o Destination Group: A named logical grouping of zero or more Public Identifiers that can be associated with one or more SED Groups for the purpose of facilitating the management of their common SED.

o 目的地组:零个或多个公共标识符的命名逻辑分组,可与一个或多个SED组关联,以便于管理其公共SED。

o SED Group: A SED Group contains a set of SED Record references, a set of Destination Group references, and a set of peering organization identifiers. This is used to establish a three-part relationship between a set of Public Identifiers, the SED shared across these Public Identifiers, and the list of peering organizations whose query responses from the resolution system may include the SED contained in a given SED Group. In addition, the sourceIdent element within a SED Group, in concert with the set of peering organization identifiers, enables fine-grained source-based routing. For further details about the SED Group and source-based routing, refer to the definitions and descriptions in Section 6.1.

o SED组:SED组包含一组SED记录引用、一组目标组引用和一组对等组织标识符。这用于在一组公共标识符、这些公共标识符之间共享的SED和对等组织列表之间建立三部分关系,这些对等组织的查询响应可能包括给定SED组中包含的SED。此外,SED组中的sourceIdent元素与对等组织标识符集协同使用,支持细粒度的基于源的路由。有关SED组和基于源的路由的更多详细信息,请参阅第6.1节中的定义和说明。

o SED Record: A SED Record contains the data that a resolution system returns in response to a successful query for a Public Identifier. SED Records are generally associated with a SED Group when the SED within is not specific to a Public Identifier.

o SED记录:SED记录包含解析系统在成功查询公共标识符时返回的数据。当SED中的SED不特定于公共标识符时,SED记录通常与SED组关联。

To support the use cases defined in [RFC6461], the SPPF defines three types of SED Records: URIType, NAPTRType, and NSType. These SED Records extend the abstract type SedRecType and inherit the

为了支持[RFC6461]中定义的用例,SPPF定义了三种类型的SED记录:URIType、NAPTRType和NSType。这些SED记录扩展抽象类型sedrecype并继承

common attribute "priority" that is meant for setting precedence across the SED Records defined within a SED Group in a protocol-agnostic fashion.

公共属性“优先级”,用于以协议无关的方式在SED组中定义的SED记录之间设置优先级。

o Egress Route: In a high-availability environment, the originating SSP likely has more than one egress path to the ingress SBE of the target SSP. The Egress Route allows the originating SSP to choose a specific egress SBE to be associated with the target ingress SBE. The "svcs" element specifies ENUM services (e.g., E2U+pstn:sip+sip) that are used to identify the SED Records associated with the SED Group that will be modified by the originating SSP.

o 出口路由:在高可用性环境中,发起SSP可能有多条到目标SSP入口SBE的出口路径。出口路由允许发起SSP选择与目标入口SBE关联的特定出口SBE。“svcs”元素指定枚举服务(例如,E2U+pstn:sip+sip),用于标识与SED组关联的SED记录,该SED组将由发起SSP修改。

o Organization: An Organization is an entity that may fulfill any combination of three roles: Registrant, Registrar, and peering organization. All objects in SPPF are associated with two organization identifiers to identify each object's Registrant and Registrar. A SED Group object is also associated with a set of zero or more organization identifiers that identify the peering organization(s) whose resolution query responses may include the SED defined in the SED Records within that SED Group. A peering organization is an entity with which the Registrant intends to share the SED data.

o 组织:组织是一个实体,可以实现三种角色的任意组合:注册者、注册者和对等组织。SPPF中的所有对象都与两个组织标识符相关联,以标识每个对象的注册人和注册人。SED组对象还与一组零或多个组织标识符相关联,这些组织标识符标识对等组织,其解析查询响应可能包括在该SED组内的SED记录中定义的SED。对等组织是注册人打算与之共享SED数据的实体。

3.2. Time Value
3.2. 时间价值

Some request and response messages in SPPF include a time value or values defined as type xs:dateTime, a built-in W3C XML Schema Datatype. Use of an unqualified local time value is disallowed as it can lead to interoperability issues. The value of a time attribute MUST be expressed in Coordinated Universal Time (UTC) format without the time-zone digits.

SPPF中的一些请求和响应消息包含一个或多个时间值,定义为xs:dateTime类型,这是一种内置的W3CXML模式数据类型。不允许使用不合格的本地时间值,因为它可能导致互操作性问题。时间属性的值必须以协调世界时(UTC)格式表示,不带时区数字。

"2010-05-30T09:30:10Z" is an example of an acceptable time value for use in SPPF messages. "2010-05-30T06:30:10+3:00" is a valid UTC time but is not acceptable for use in SPPF messages.

“2010-05-30T09:30:10Z”是在SPPF消息中使用的可接受时间值的示例。“2010-05-30T06:30:10+3:00”是有效的UTC时间,但不可用于SPPF消息。

3.3. Extensibility
3.3. 扩展性

The framework contains various points of extensibility in the form of the "ext" elements. Extensions used beyond the scope of private SPPF installations need to be documented in an RFC, and the first such extension is expected to define an IANA registry, holding a list of documented extensions.

该框架以“ext”元素的形式包含各种扩展点。超出专用SPPF安装范围的扩展需要记录在RFC中,第一个此类扩展预计将定义IANA注册表,其中包含一个记录扩展列表。

4. Substrate Protocol Requirements
4. 基板协议要求

This section provides requirements for substrate protocols suitable to carry SPPF. More specifically, this section specifies the services, features, and assumptions that SPPF delegates to the chosen substrate and envelope technologies.

本节规定了适用于携带SPPF的基板协议的要求。更具体地说,本节规定了SPPF委托给所选基板和封装技术的服务、功能和假设。

4.1. Mandatory Substrate
4.1. 强制基质

None of the existing transport protocols carried directly over IP, appearing as "Protocol" in the IPv4 headers or "Next Header" in the IPv6 headers, meet the requirements listed in this section to carry SPPF.

直接通过IP承载的现有传输协议(在IPv4标头中显示为“协议”或在IPv6标头中显示为“下一个标头”)均不符合本节中列出的承载SPPF的要求。

Therefore, one choice to carry SPPF has been provided in "Session Peering Provisioning (SPP) Protocol over SOAP" [RFC7878], using SOAP as the substrate. To encourage interoperability, the SPPF server MUST provide support for this protocol. With time, it is possible that other choices may surface that comply with the requirements discussed above.

因此,在“基于SOAP的会话对等资源调配(SPP)协议”[RFC7878]中,使用SOAP作为基础,提供了一种携带SPPF的选择。为了鼓励互操作性,SPPF服务器必须为此协议提供支持。随着时间的推移,可能会出现符合上述要求的其他选择。

4.2. Connection Oriented
4.2. 面向连接

The SPPF follows a model where a client establishes a connection to a server in order to further exchange SPPF messages over such a point-to-point connection. Therefore, a substrate protocol for SPPF will be connection oriented.

SPPF遵循一种模式,其中客户端建立到服务器的连接,以便通过这种点到点连接进一步交换SPPF消息。因此,SPPF的基板协议将面向连接。

4.3. Request and Response Model
4.3. 请求和响应模型

Provisioning operations in SPPF follow the request-response model, where a client sends a request message to initiate a transaction and the server sends a response. Multiple subsequent request-response exchanges MAY be performed over a single persistent connection.

SPPF中的配置操作遵循请求-响应模型,其中客户端发送请求消息以启动事务,服务器发送响应。可以通过单个持久连接执行多个后续请求-响应交换。

Therefore, a substrate protocol for SPPF will follow the request-response model by ensuring a response is sent to the request initiator.

因此,SPPF的基板协议将遵循请求-响应模型,确保向请求发起方发送响应。

4.4. Connection Lifetime
4.4. 连接寿命

Some use cases involve provisioning a single request to a network element. Connections supporting such provisioning requests might be short-lived, and may be established only on demand, for the duration of a few seconds. Other use cases involve provisioning either a large dataset or a constant stream of small updates, both of which would likely require long-lived connections, spanning multiple hours or even days.

一些用例涉及向网元提供单个请求。支持此类资源调配请求的连接可能很短,并且可能仅在几秒钟内按需建立。其他用例包括提供大数据集或持续的小更新流,这两种情况都可能需要长时间的连接,跨越数小时甚至数天。

Therefore, a protocol suitable for SPPF SHOULD be able to support both short-lived and long-lived connections.

因此,适用于SPPF的协议应该能够支持短寿命和长寿命连接。

4.5. Authentication
4.5. 认证

All SPPF objects are associated with a Registrant identifier. An SPPF client provisions SPPF objects on behalf of Registrants. An authenticated SPP client is a Registrar. Therefore, the SPPF substrate protocol MUST provide means for an SPPF server to authenticate an SPPF client.

所有SPPF对象都与注册者标识符关联。SPPF客户代表注册人提供SPPF异议。经过身份验证的SPP客户端是注册器。因此,SPPF基板协议必须为SPPF服务器提供验证SPPF客户端的方法。

4.6. Authorization
4.6. 批准

After successful authentication of the SPPF client as a Registrar, the Registry performs authorization checks to determine if the Registrar is authorized to act on behalf of the Registrant whose identifier is included in the SPPF request. Refer to Section 9 for further guidance.

成功认证SPPF客户端为注册人后,注册处将执行授权检查,以确定注册人是否有权代表其标识符包含在SPPF请求中的注册人行事。请参阅第9节以获取更多指导。

4.7. Confidentiality and Integrity
4.7. 机密性和完整性

SPPF objects that the Registry manages can be private in nature. Therefore, the substrate protocol MUST provide means for data integrity protection.

注册表管理的SPPF对象本质上可以是私有的。因此,底层协议必须提供数据完整性保护手段。

If the data is compromised in-flight between the SPPF client and Registry, it will seriously affect the stability and integrity of the system. Therefore, the substrate protocol MUST provide means for data integrity protection.

如果SPPF客户端和注册表之间的数据在传输过程中受损,将严重影响系统的稳定性和完整性。因此,底层协议必须提供数据完整性保护手段。

4.8. Near Real Time
4.8. 近实时

Many use cases require responses in near real time from the server (in the range of a few multiples of round-trip time between the server and client). Therefore, a Data for Reachability of Inter-/Intra-NetworK SIP (DRINKS) substrate protocol MUST support near real-time responses to requests submitted by the client.

许多用例需要服务器近乎实时的响应(在服务器和客户端之间往返时间的几倍范围内)。因此,网络间/网络内SIP(饮料)底层协议的可达性数据必须支持对客户端提交的请求的近实时响应。

4.9. Request and Response Sizes
4.9. 请求和响应大小

Use of SPPF may involve simple updates that may consist of a small number of bytes, such as the update of a single Public Identifier. Other provisioning operations may constitute a large dataset, as in adding millions of records to a Registry. As a result, a suitable substrate protocol for SPPF SHOULD accommodate datasets of various sizes.

SPPF的使用可能涉及由少量字节组成的简单更新,例如单个公共标识符的更新。其他资源调配操作可能构成一个大型数据集,如向注册表添加数百万条记录。因此,SPPF的合适基板协议应适应各种大小的数据集。

4.10. Request and Response Correlation
4.10. 请求和响应相关性

A substrate protocol suitable for SPPF MUST allow responses to be correlated with requests.

适用于SPPF的基板协议必须允许响应与请求关联。

4.11. Request Acknowledgement
4.11. 请求确认

Data transported in the SPPF is likely crucial for the operation of the communication network that is being provisioned. An SPPF client responsible for provisioning SED to the Registry has a need to know if the submitted requests have been processed correctly.

在SPPF中传输的数据对于正在供应的通信网络的操作可能至关重要。负责向注册表提供SED的SPPF客户端需要知道提交的请求是否已正确处理。

Failed transactions can lead to situations where a subset of Public Identifiers or even SSPs might not be reachable or the provisioning state of the network is inconsistent.

失败的事务可能导致无法访问公共标识符的子集,甚至SSP,或者网络的配置状态不一致。

Therefore, a substrate protocol for SPPF MUST provide a response for each request, so that a client can identify whether a request succeeded or failed.

因此,SPPF的底层协议必须为每个请求提供响应,以便客户端能够识别请求是成功还是失败。

5. Base Framework Data Structures and Response Codes
5. 基本框架数据结构和响应代码

SPPF contains some common data structures for most of the supported object types. This section describes these common data structures.

对于大多数受支持的对象类型,SPPF包含一些通用数据结构。本节介绍这些常见的数据结构。

5.1. Basic Object Type and Organization Identifiers
5.1. 基本对象类型和组织标识符

All first-class objects extend the type BasicObjType. It consists of the Registrant organization, the Registrar organization, the date and time of object creation, and the last date and time the object was modified. The Registry MUST store the date and time of the object creation and modification, if applicable, for all Get operations (see Section 7). If the client passed in either date or time values, the Registry MUST ignore it. The Registrar performs the SPPF operations on behalf of the Registrant, the organization that owns the object.

所有一级对象都扩展了BasicObjType类型。它包括注册人组织、注册人组织、对象创建的日期和时间以及对象修改的最后日期和时间。注册表必须为所有Get操作存储对象创建和修改的日期和时间(如果适用)(请参阅第7节)。如果客户端传入日期或时间值,注册表必须忽略它。注册人代表注册人,即拥有标的物的组织,执行SPPF操作。

   <complexType name="BasicObjType" abstract="true">
    <sequence>
     <element name="rant" type="sppfb:OrgIdType"/>
     <element name="rar" type="sppfb:OrgIdType"/>
     <element name="cDate" type="dateTime" minOccurs="0"/>
     <element name="mDate" type="dateTime" minOccurs="0"/>
     <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
    </sequence>
   </complexType>
        
   <complexType name="BasicObjType" abstract="true">
    <sequence>
     <element name="rant" type="sppfb:OrgIdType"/>
     <element name="rar" type="sppfb:OrgIdType"/>
     <element name="cDate" type="dateTime" minOccurs="0"/>
     <element name="mDate" type="dateTime" minOccurs="0"/>
     <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
    </sequence>
   </complexType>
        

The identifiers used for Registrants (rant) and Registrars (rar) are instances of OrgIdType. The OrgIdType is defined as a string and all OrgIdType instances MUST follow the textual convention: "namespace:value" (for example, "iana-en:32473"). Specifically:

用于注册者(rant)和注册者(rar)的标识符是OrgIdType的实例。OrgIdType定义为字符串,所有OrgIdType实例必须遵循文本约定:“名称空间:值”(例如,“iana en:32473”)。明确地:

Strings used as OrgIdType Namespace identifiers MUST conform to the following syntax in the Augmented Backus-Naur Form (ABNF) [RFC5234].

用作OrgIdType命名空间标识符的字符串必须符合以下扩充的Backus Naur格式(ABNF)[RFC5234]的语法。

         namespace = ALPHA *(ALPHA/DIGIT/"-")
        
         namespace = ALPHA *(ALPHA/DIGIT/"-")
        

See Section 11 for the corresponding IANA registry definition.

有关相应的IANA注册表定义,请参见第11节。

5.2. Various Object Key Types
5.2. 各种对象键类型

The SPPF data model contains various object relationships. In some cases, these object relationships are established by embedding the unique identity of the related object inside the relating object. Note that an object's unique identity is required to Delete or Get the details of an object. The following subsections normatively define the various object keys in SPPF and the attributes of those keys.

SPPF数据模型包含各种对象关系。在某些情况下,这些对象关系是通过将相关对象的唯一标识嵌入到相关对象中来建立的。请注意,删除或获取对象的详细信息需要对象的唯一标识。以下小节规范性地定义了SPPF中的各种对象键以及这些键的属性。

"Name" attributes that are used as components of object key types MUST be compared using the toCasefold() function, as specified in Section 3.13 of [Unicode6.1] (or a newer version of Unicode). This function performs case-insensitive comparisons.

必须使用[Unicode 6.1](或更新版本的Unicode)第3.13节中指定的toCasefold()函数比较用作对象键类型组件的“名称”属性。此函数执行不区分大小写的比较。

5.2.1. Generic Object Key Type
5.2.1. 泛型对象键类型

Most objects in SPPF are uniquely identified by an object key that has the object's name, type, and Registrant's organization ID as attributes. The abstract type called ObjKeyType is where this unique identity is housed. Any concrete representation of the ObjKeyType MUST contain the following:

SPPF中的大多数对象都由对象密钥唯一标识,该密钥将对象的名称、类型和注册人的组织ID作为属性。称为ObjKeyType的抽象类型就是这个唯一标识所在的位置。ObjKeyType的任何具体表示必须包含以下内容:

Object Name: The name of the object.

对象名称:对象的名称。

Registrant ID: The unique organization ID that identifies the Registrant.

注册人ID:标识注册人的唯一组织ID。

Type: The value that represents the type of SPPF object. This is required as different types of objects in SPPF, that belong to the same Registrant, can have the same name.

类型:表示SPPF对象类型的值。这是必需的,因为SPPF中属于同一注册人的不同类型的对象可以具有相同的名称。

The structure of abstract ObjKeyType is as follows:

抽象ObjKeyType的结构如下:

   <complexType name="ObjKeyType" abstract="true">
    <annotation>
     <documentation>
     ---- Generic type that represents the
          key for various objects in SPPF. ----
     </documentation>
    </annotation>
   </complexType>
        
   <complexType name="ObjKeyType" abstract="true">
    <annotation>
     <documentation>
     ---- Generic type that represents the
          key for various objects in SPPF. ----
     </documentation>
    </annotation>
   </complexType>
        
5.2.2. Derived Object Key Types
5.2.2. 派生对象键类型

The SPPF data model contains certain objects that are uniquely identified by attributes, different from or in addition to the attributes in the generic object key described in the previous section. Object keys of this kind are derived from the abstract ObjKeyType and defined in their own abstract key types. Because these object key types are abstract, they MUST be specified in a concrete form in any SPPF-conforming substrate "protocol" specification. These are used in Delete and Get operations and may also be used in Accept and Reject operations.

SPPF数据模型包含某些由属性唯一标识的对象,这些属性与上一节中描述的通用对象键中的属性不同或不同。这类对象键派生自抽象ObjKeyType,并在它们自己的抽象键类型中定义。由于这些对象密钥类型是抽象的,因此必须在任何符合SPPF的“协议”规范中以具体形式指定它们。它们用于删除和获取操作,也可用于接受和拒绝操作。

Following are the derived object keys in an SPPF data model:

以下是SPPF数据模型中的派生对象键:

o SedGrpOfferKeyType: This uniquely identifies a SED Group object offer. This key type extends from ObjKeyType and MUST also have the organization ID of the Registrant to whom the object is being offered as one of its attributes. In addition to the Delete and Get operations, these key types are used in Accept and Reject operations on a SED Group Offer object. The structure of abstract SedGrpOfferKeyType is as follows:

o SedGrpOfferKeyType:它唯一标识SED组对象提供。此密钥类型从ObjKeyType扩展而来,还必须具有对象提供给的注册人的组织ID作为其属性之一。除了Delete和Get操作外,这些键类型还用于SED Group Offer对象的接受和拒绝操作。摘要SedGrpOfferKeyType的结构如下:

   <complexType name="SedGrpOfferKeyType"
   abstract="true">
       <complexContent>
           <extension base="sppfb:ObjKeyType">
               <annotation>
       <documentation>
       ---- Generic type that represents
            the key for an object offer. ----
       </documentation>
      </annotation>
     </extension>
    </complexContent>
   </complexType>
        
   <complexType name="SedGrpOfferKeyType"
   abstract="true">
       <complexContent>
           <extension base="sppfb:ObjKeyType">
               <annotation>
       <documentation>
       ---- Generic type that represents
            the key for an object offer. ----
       </documentation>
      </annotation>
     </extension>
    </complexContent>
   </complexType>
        

A SED Group Offer object MUST use SedGrpOfferKeyType. Refer to Section 6.5 for a description of the SED Group Offer object.

SED组提供对象必须使用SedGrpOfferKeyType。有关SED集团要约对象的说明,请参阅第6.5节。

o PubIdKeyType: This uniquely identifies a Public Identity object. This key type extends from the abstract ObjKeyType. Any concrete definition of PubIdKeyType MUST contain the elements that identify the value and type of Public Identity and also contain the organization ID of the Registrant that is the owner of the Public Identity object. A Public Identity object in SPPF is uniquely identified by the Registrant's organization ID, the value of the Public Identity, and the type of the Public Identity object. Consequently, any concrete representation of the PubIdKeyType MUST contain the following attributes:

o PubIdKeyType:它唯一标识公共标识对象。此键类型是从抽象ObjKeyType扩展而来的。PubIdKeyType的任何具体定义都必须包含标识公共标识的值和类型的元素,还必须包含作为公共标识对象所有者的注册人的组织ID。SPPF中的公共标识对象由注册人的组织ID、公共标识的值和公共标识对象的类型唯一标识。因此,PubIdKeyType的任何具体表示都必须包含以下属性:

* Registrant ID: The unique organization ID that identifies the Registrant.

* 注册人ID:标识注册人的唯一组织ID。

* Value: The value of the Public Identity.

* 价值:公众身份的价值。

* Type: The type of the Public Identity object.

* 类型:公共标识对象的类型。

The PubIdKeyType is used in Delete and Get operations on a Public Identifier object.

PubIdKeyType用于对公共标识符对象执行删除和获取操作。

o The structure of abstract PubIdKeyType is as follows:

o 抽象PubIdKeyType的结构如下:

   <complexType name="PubIdKeyType" abstract="true">
    <complexContent>
     <extension base="sppfb:ObjKeyType">
      <annotation>
       <documentation>
       ---- Generic type that represents the key for a Pub ID. ----
       </documentation>
      </annotation>
     </extension>
    </complexContent>
   </complexType>
        
   <complexType name="PubIdKeyType" abstract="true">
    <complexContent>
     <extension base="sppfb:ObjKeyType">
      <annotation>
       <documentation>
       ---- Generic type that represents the key for a Pub ID. ----
       </documentation>
      </annotation>
     </extension>
    </complexContent>
   </complexType>
        

A Public Identity object MUST use attributes of PubIdKeyType for its unique identification. Refer to Section 6 for a description of a Public Identity object.

公共标识对象必须使用PubIdKeyType属性作为其唯一标识。有关公共标识对象的说明,请参阅第6节。

5.3. Response Message Types
5.3. 响应消息类型

The following table contains the list of response types that MUST be defined for a substrate protocol used to carry SPPF. An SPPF server MUST implement all of the following at minimum.

下表列出了用于携带SPPF的基板协议必须定义的响应类型。SPPF服务器必须至少实现以下所有功能。

   +---------------------+---------------------------------------------+
   | Response Type       | Description                                 |
   +---------------------+---------------------------------------------+
   | Request succeeded   | A given request succeeded.                  |
   | Request syntax      | The syntax of a given request was found to  |
   | invalid             | be invalid.                                 |
   | Request too large   | The count of entities in the request is     |
   |                     | larger than the server is willing or able   |
   |                     | to process.                                 |
   | Version not         | The server does not support the version of  |
   | supported           | the SPPF protocol specified in the request. |
   | Command invalid     | The operation and/or command being          |
   |                     | requested by the client is invalid and/or   |
   |                     | not supported by the server.                |
   | System temporarily  | The SPPF server is temporarily not          |
   | unavailable         | available to serve the client request.      |
   | Unexpected internal | The SPPF server encountered an unexpected   |
   | system or server    | error that prevented the server from        |
   | error               | fulfilling the request.                     |
   | Attribute value     | The SPPF server encountered an attribute or |
   | invalid             | property in the request that had an         |
   |                     | invalid/bad value.  Optionally, the         |
   |                     | specification MAY provide a way to indicate |
   |                     | the Attribute Name and the Attribute Value  |
   |                     | to identify the object that was found to be |
   |                     | invalid.                                    |
   | Object does not     | An object present in the request does not   |
   | exist               | exist on the SPPF server. Optionally, the   |
   |                     | specification MAY provide a way to indicate |
   |                     | the Attribute Name and the Attribute Value  |
   |                     | that identifies the nonexistent object.     |
   | Object status or    | The operation requested on an object        |
   | ownership does not  | present in the request cannot be performed  |
   | allow for operation | because the object is in a status that does |
   |                     | not allow said operation, or the user       |
   |                     | requesting the operation is not authorized  |
   |                     | to perform said operation on the object.    |
   |                     | Optionally, the specification MAY provide a |
   |                     | way to indicate the Attribute Name and the  |
   |                     | Attribute Value that identifies the object. |
   +---------------------+---------------------------------------------+
        
   +---------------------+---------------------------------------------+
   | Response Type       | Description                                 |
   +---------------------+---------------------------------------------+
   | Request succeeded   | A given request succeeded.                  |
   | Request syntax      | The syntax of a given request was found to  |
   | invalid             | be invalid.                                 |
   | Request too large   | The count of entities in the request is     |
   |                     | larger than the server is willing or able   |
   |                     | to process.                                 |
   | Version not         | The server does not support the version of  |
   | supported           | the SPPF protocol specified in the request. |
   | Command invalid     | The operation and/or command being          |
   |                     | requested by the client is invalid and/or   |
   |                     | not supported by the server.                |
   | System temporarily  | The SPPF server is temporarily not          |
   | unavailable         | available to serve the client request.      |
   | Unexpected internal | The SPPF server encountered an unexpected   |
   | system or server    | error that prevented the server from        |
   | error               | fulfilling the request.                     |
   | Attribute value     | The SPPF server encountered an attribute or |
   | invalid             | property in the request that had an         |
   |                     | invalid/bad value.  Optionally, the         |
   |                     | specification MAY provide a way to indicate |
   |                     | the Attribute Name and the Attribute Value  |
   |                     | to identify the object that was found to be |
   |                     | invalid.                                    |
   | Object does not     | An object present in the request does not   |
   | exist               | exist on the SPPF server. Optionally, the   |
   |                     | specification MAY provide a way to indicate |
   |                     | the Attribute Name and the Attribute Value  |
   |                     | that identifies the nonexistent object.     |
   | Object status or    | The operation requested on an object        |
   | ownership does not  | present in the request cannot be performed  |
   | allow for operation | because the object is in a status that does |
   |                     | not allow said operation, or the user       |
   |                     | requesting the operation is not authorized  |
   |                     | to perform said operation on the object.    |
   |                     | Optionally, the specification MAY provide a |
   |                     | way to indicate the Attribute Name and the  |
   |                     | Attribute Value that identifies the object. |
   +---------------------+---------------------------------------------+
        

Table 1: Response Types

表1:响应类型

When the response messages are "parameterized" with the Attribute Name and Attribute Value, then the use of these parameters MUST adhere to the following rules:

当响应消息使用属性名称和属性值“参数化”时,这些参数的使用必须遵守以下规则:

o Any value provided for the Attribute Name parameter MUST be an exact XSD element name of the protocol data element to which the response message is referring. For example, valid values for "attribute name" are "dgName", "sedGrpName", "sedRec", etc.

o 为Attribute Name参数提供的任何值都必须是响应消息所引用的协议数据元素的确切XSD元素名称。例如,“属性名称”的有效值为“dgName”、“sedGrpName”、“sedRec”等。

o The value for Attribute Value MUST be the value of the data element to which the preceding Attribute Name refers.

o 属性值的值必须是前面属性名称所引用的数据元素的值。

o Response type "Attribute value invalid" MUST be used whenever an element value does not adhere to data validation rules.

o 只要元素值不符合数据验证规则,就必须使用响应类型“Attribute value invalid”。

o Response types "Attribute value invalid" and "Object does not exist" MUST NOT be used interchangeably. Response type "Object does not exist" MUST be returned by an Update/Del/Accept/Reject operation when the data element(s) used to uniquely identify a preexisting object does not exist. If the data elements used to uniquely identify an object are malformed, then response type "Attribute value invalid" MUST be returned.

o 响应类型“属性值无效”和“对象不存在”不能互换使用。当用于唯一标识先前存在的对象的数据元素不存在时,更新/删除/接受/拒绝操作必须返回响应类型“对象不存在”。如果用于唯一标识对象的数据元素格式不正确,则必须返回响应类型“Attribute value invalid”。

6. Framework Data Model Objects
6. 框架数据模型对象

This section provides a description of the specification of each supported data model object (the nouns) and identifies the commands (the verbs) that MUST be supported for each data model object. However, the specification of the data structures necessary to support each command is delegated to an SPPF-conforming substrate "protocol" specification.

本节介绍每个受支持的数据模型对象(名词)的规范,并确定每个数据模型对象必须支持的命令(动词)。然而,支持每个命令所需的数据结构规范被委托给符合SPPF的基板“协议”规范。

6.1. Destination Group
6.1. 目的地组

A Destination Group represents a logical grouping of Public Identifiers with common SED. The substrate protocol MUST support the ability to Add, Get, and Delete Destination Groups (refer to Section 7 for a generic description of various operations).

目标组表示具有公共SED的公共标识符的逻辑分组。基板协议必须支持添加、获取和删除目标组的功能(有关各种操作的一般说明,请参阅第7节)。

A Destination Group object MUST be uniquely identified by attributes as defined in the description of "ObjKeyType" in "Generic Object Key Type" (Section 5.2.1 of this document).

目标组对象必须由“通用对象密钥类型”(本文件第5.2.1节)中“ObjKeyType”描述中定义的属性唯一标识。

The DestGrpType object structure is defined as follows:

DestGrpType对象结构定义如下:

   <complexType name="DestGrpType">
    <complexContent>
     <extension base="sppfb:BasicObjType">
      <sequence>
       <element name="dgName" type="sppfb:ObjNameType"/>
      </sequence>
     </extension>
    </complexContent>
   </complexType>
        
   <complexType name="DestGrpType">
    <complexContent>
     <extension base="sppfb:BasicObjType">
      <sequence>
       <element name="dgName" type="sppfb:ObjNameType"/>
      </sequence>
     </extension>
    </complexContent>
   </complexType>
        

The DestGrpType object is composed of the following elements:

DestGrpType对象由以下元素组成:

o base: All first-class objects extend BasicObjType (see Section 5.1).

o 基本:所有一级对象都扩展了BasicObjType(参见第5.1节)。

o dgName: The character string that contains the name of the Destination Group.

o dgName:包含目标组名称的字符串。

o ext: Point of extensibility described in Section 3.3.

o ext:第3.3节中描述的扩展点。

6.2. Public Identifier
6.2. 公共标识符

A Public Identifier is the search key used for locating the SED. In many cases, a Public Identifier is attributed to the end user who has a retail relationship with the SP or Registrant organization. SPPF supports the notion of the carrier-of-record as defined in [RFC5067]. Therefore, the Registrant under which the Public Identifier is being created can optionally claim to be a carrier-of-record.

公共标识符是用于定位SED的搜索键。在许多情况下,公共标识符归属于与SP或注册机构有零售关系的最终用户。SPPF支持[RFC5067]中定义的记录载体概念。因此,创建公共标识符的注册人可以选择性地声称自己是记录载体。

SPPF identifies three types of Public Identifiers: TNs, RNs, and URIs. SPPF provides structures to manage a single TN, a contiguous range of TNs, and a TN prefix. The substrate protocol MUST support the ability to Add, Get, and Delete Public Identifiers (refer to Section 7 for a generic description of various operations).

SPPF识别三种类型的公共标识符:TNs、RNs和URI。SPPF提供用于管理单个TN、连续TN范围和TN前缀的结构。基板协议必须支持添加、获取和删除公共标识符的功能(有关各种操作的一般说明,请参阅第7节)。

A Public Identity object MUST be uniquely identified by attributes as defined in the description of "PubIdKeyType" in Section 5.2.2.

公共标识对象必须由第5.2.2节“PubIdKeyType”描述中定义的属性唯一标识。

The abstract XSD type PubIdType is a generalization for the concrete Public Identifier schema types. The PubIdType element "dgName" represents the name of a Destination Group of which a given Public Identifier may be a member. Note that this element may be present multiple times so that a given Public Identifier may be a member of multiple Destination Groups. The PubIdType object structure is defined as follows:

抽象XSD类型PubIdType是具体公共标识符模式类型的泛化。PubIdType元素“dgName”表示给定公共标识符可能是其成员的目标组的名称。注意,该元素可能多次出现,以便给定的公共标识符可能是多个目的地组的成员。PubIdType对象结构定义如下:

   <complexType name="PubIdType" abstract="true">
    <complexContent>
     <extension base="sppfb:BasicObjType">
      <sequence>
       <element name="dgName" type="sppfb:ObjNameType"
                minOccurs="0" maxOccurs="unbounded"/>
      </sequence>
     </extension>
    </complexContent>
   </complexType>
        
   <complexType name="PubIdType" abstract="true">
    <complexContent>
     <extension base="sppfb:BasicObjType">
      <sequence>
       <element name="dgName" type="sppfb:ObjNameType"
                minOccurs="0" maxOccurs="unbounded"/>
      </sequence>
     </extension>
    </complexContent>
   </complexType>
        

A Public Identifier may be a member of zero or more Destination Groups. When a Public Identifier is a member of a Destination Group, it is intended to be associated with SED through the SED Group(s) that is associated with the Destination Group. When a Public Identifier is not member of any Destination Group, it is intended to be associated with SED through the SED Records that are directly associated with the Public Identifier.

公共标识符可以是零个或多个目的地组的成员。当公共标识符是目标组的成员时,它将通过与目标组关联的SED组与SED关联。当公共标识符不是任何目标组的成员时,它将通过与公共标识符直接关联的SED记录与SED关联。

A TN is provisioned using the TNType, an extension of PubIdType. Each TNType object is uniquely identified by the combination of its value contained within the <tn> element and its Registrant ID. TNType is defined as follows:

TN是使用TNType(PubIdType的扩展)配置的。每个TNType对象通过其<tn>元素中包含的值及其注册者ID的组合进行唯一标识。TNType定义如下:

   <complexType name="TNType">
    <complexContent>
     <extension base="sppfb:PubIdType">
      <sequence>
       <element name="tn" type="sppfb:NumberValType"/>
       <element name="corInfo" type="sppfb:CORInfoType" minOccurs="0"/>
       <element name="sedRecRef" type="sppfb:SedRecRefType"
                minOccurs="0" maxOccurs="unbounded"/>
      </sequence>
     </extension>
    </complexContent>
   </complexType>
        
   <complexType name="TNType">
    <complexContent>
     <extension base="sppfb:PubIdType">
      <sequence>
       <element name="tn" type="sppfb:NumberValType"/>
       <element name="corInfo" type="sppfb:CORInfoType" minOccurs="0"/>
       <element name="sedRecRef" type="sppfb:SedRecRefType"
                minOccurs="0" maxOccurs="unbounded"/>
      </sequence>
     </extension>
    </complexContent>
   </complexType>
        
   <complexType name="CORInfoType">
    <sequence>
      <element name="corClaim" type="boolean" default="true"/>
      <element name="cor" type="boolean" default="false" minOccurs="0"/>
      <element name="corDate" type="dateTime" minOccurs="0"/>
    </sequence>
   </complexType>
        
   <complexType name="CORInfoType">
    <sequence>
      <element name="corClaim" type="boolean" default="true"/>
      <element name="cor" type="boolean" default="false" minOccurs="0"/>
      <element name="corDate" type="dateTime" minOccurs="0"/>
    </sequence>
   </complexType>
        
   <simpleType name="NumberValType">
    <restriction base="token">
     <maxLength value="20"/>
     <pattern value="\+?\d\d*"/>
    </restriction>
   </simpleType>
        
   <simpleType name="NumberValType">
    <restriction base="token">
     <maxLength value="20"/>
     <pattern value="\+?\d\d*"/>
    </restriction>
   </simpleType>
        

TNType consists of the following attributes:

TNType由以下属性组成:

o tn: Telephone number to be added to the Registry.

o tn:要添加到注册表的电话号码。

o sedRecRef: Optional reference to SED Records that are directly associated with the TN Public Identifier. Following the SPPF data model, the SED Record could be a protocol-agnostic URIType or another type.

o sedRecRef:对与TN公共标识符直接关联的SED记录的可选引用。根据SPPF数据模型,SED记录可以是协议不可知类型或其他类型。

o corInfo: corInfo is an optional parameter of type CORInfoType that allows the Registrant organization to set forth a claim to be the carrier-of-record (see [RFC5067]). This is done by setting the value of the <corClaim> element of the CORInfoType object structure to "true". The other two parameters of the CORInfoType, <cor> and <corDate>, are set by the Registry to describe the

o corInfo:corInfo是CORInfoType类型的可选参数,允许注册人组织提出作为记录载体的声明(参见[RFC5067])。这是通过将corinfo类型对象结构的<corClaim>元素的值设置为“true”来实现的。corinfo类型的另外两个参数,<cor>和<corDate>由注册表设置,用于描述

outcome of the carrier-of-record claim by the Registrant. In general, inclusion of the <corInfo> parameter is useful if the Registry has the authority information, such as the number portability data, etc., in order to qualify whether the Registrant claim can be satisfied. If the carrier-of-record claim disagrees with the authority data in the Registry, whether or not a TN Add operation fails is a matter of policy and is beyond the scope of this document.

登记人记录的承运人索赔结果。一般来说,如果登记处拥有权限信息,如号码可携带性数据等,则包含<corInfo>参数是有用的,以确定是否可以满足登记人的要求。如果记录载体索赔不同意登记处的授权数据,则TN Add操作是否失败是一个政策问题,超出了本文件的范围。

An RN is provisioned using the RNType, an extension of PubIDType. The Registrant organization can add the RN and associate it with the appropriate Destination Group(s) to share the route information. This allows SSPs to use the RN search key to derive the Ingress Routes for session establishment at the runtime resolution process (see [RFC6116]). Each RNType object is uniquely identified by the combination of its value inside the <rn> element and its Registrant ID. RNType is defined as follows:

RN是使用RNType(PubIDType的扩展)配置的。注册人组织可以添加RN并将其与适当的目的地组关联,以共享路线信息。这允许SSP使用RN搜索键导出入口路由,以便在运行时解析过程中建立会话(请参阅[RFC6116])。每个RNType对象通过其<rn>元素内的值及其注册者ID的组合进行唯一标识。RNType定义如下:

   <complexType name="RNType">
    <complexContent>
     <extension base="sppfb:PubIdType">
      <sequence>
       <element name="rn" type="sppfb:NumberValType"/>
       <element name="corInfo" type="sppfb:CORInfoType" minOccurs="0"/>
      </sequence>
     </extension>
    </complexContent>
   </complexType>
        
   <complexType name="RNType">
    <complexContent>
     <extension base="sppfb:PubIdType">
      <sequence>
       <element name="rn" type="sppfb:NumberValType"/>
       <element name="corInfo" type="sppfb:CORInfoType" minOccurs="0"/>
      </sequence>
     </extension>
    </complexContent>
   </complexType>
        

RNType has the following attributes:

RNType具有以下属性:

o rn: The RN used as the search key.

o rn:用作搜索键的rn。

o corInfo: corInfo is an optional parameter of type CORInfoType that allows the Registrant organization to set forth a claim to be the carrier-of-record (see [RFC5067]).

o corInfo:corInfo是CORInfoType类型的可选参数,允许注册人组织提出作为记录载体的声明(参见[RFC5067])。

TNRType structure is used to provision a contiguous range of TNs. The object definition requires a starting TN and an ending TN that together define the span of the TN range, including the starting and ending TN. Use of TNRType is particularly useful when expressing a TN range that does not include all the TNs within a TN block or prefix. The TNRType definition accommodates the open number plan as well such that the TNs that fall in the range between the start and end TN may include TNs with different length variance. Whether the Registry can accommodate the open number plan semantics is a matter of policy and is beyond the scope of this document. Each TNRType object is uniquely identified by the combination of its value that,

TNRType结构用于提供连续范围的tn。对象定义需要一个起始TN和一个结束TN,这两个TN一起定义TN范围的范围,包括起始TN和结束TN。当表示TN范围(不包括TN块或前缀中的所有TN)时,使用TNRType特别有用。TNRType定义也适用于开放编号计划,因此在起始和结束TN之间范围内的TN可能包括具有不同长度差异的TN。注册表是否能够适应开放编号计划语义是一个政策问题,超出了本文档的范围。每个TNRType对象都通过其值的组合进行唯一标识,

in turn, is a combination of the <startTn> and <endTn> elements and its Registrant ID. The TNRType object structure definition is as follows:

依次是<startTn>和<endTn>元素及其注册者ID的组合。TNRType对象结构定义如下:

   <complexType name="TNRType">
    <complexContent>
     <extension base="sppfb:PubIdType">
      <sequence>
       <element name="range" type="sppfb:NumberRangeType"/>
       <element name="corInfo" type="sppfb:CORInfoType" minOccurs="0"/>
      </sequence>
     </extension>
    </complexContent>
   </complexType>
        
   <complexType name="TNRType">
    <complexContent>
     <extension base="sppfb:PubIdType">
      <sequence>
       <element name="range" type="sppfb:NumberRangeType"/>
       <element name="corInfo" type="sppfb:CORInfoType" minOccurs="0"/>
      </sequence>
     </extension>
    </complexContent>
   </complexType>
        
   <complexType name="NumberRangeType">
    <sequence>
     <element name="startTn" type="sppfb:NumberValType"/>
     <element name="endTn" type="sppfb:NumberValType"/>
    </sequence>
   </complexType>
        
   <complexType name="NumberRangeType">
    <sequence>
     <element name="startTn" type="sppfb:NumberValType"/>
     <element name="endTn" type="sppfb:NumberValType"/>
    </sequence>
   </complexType>
        

TNRType has the following attributes:

TNRType具有以下属性:

o startTn: The starting TN in the TN range.

o startTn:TN范围内的起始TN。

o endTn: The last TN in the TN range.

o endTn:TN范围内的最后一个TN。

o corInfo: corInfo is an optional parameter of type CORInfoType that allows the Registrant organization to set forth a claim to be the carrier-of-record (see [RFC5067]).

o corInfo:corInfo是CORInfoType类型的可选参数,允许注册人组织提出作为记录载体的声明(参见[RFC5067])。

In some cases, it is useful to describe a set of TNs with the help of the first few digits of the TN, also referred to as the TN prefix or a block. A given TN prefix may include TNs with different length variance in support of the open number plan. Once again, whether the Registry supports the open number plan semantics is a matter of policy, and it is beyond the scope of this document. The TNPType data structure is used to provision a TN prefix. Each TNPType object is uniquely identified by the combination of its value in the <tnPrefix> element and its Registrant ID. TNPType is defined as follows:

在某些情况下,借助TN的前几个数字(也称为TN前缀或块)来描述一组TN是有用的。给定的TN前缀可能包括具有不同长度差异的TN,以支持开放号码计划。同样,注册表是否支持开放数字计划语义是一个策略问题,它超出了本文的范围。TNPType数据结构用于提供TN前缀。每个TNPType对象通过其在<tnPrefix>元素中的值及其注册者ID的组合进行唯一标识。TNPType定义如下:

   <complexType name="TNPType">
    <complexContent>
     <extension base="sppfb:PubIdType">
      <sequence>
       <element name="tnPrefix" type="sppfb:NumberValType"/>
       <element name="corInfo" type="sppfb:CORInfoType" minOccurs="0"/>
      </sequence>
     </extension>
    </complexContent>
   </complexType>
        
   <complexType name="TNPType">
    <complexContent>
     <extension base="sppfb:PubIdType">
      <sequence>
       <element name="tnPrefix" type="sppfb:NumberValType"/>
       <element name="corInfo" type="sppfb:CORInfoType" minOccurs="0"/>
      </sequence>
     </extension>
    </complexContent>
   </complexType>
        

TNPType consists of the following attributes:

TNPType由以下属性组成:

o tnPrefix: The TN prefix.

o tnPrefix:TN前缀。

o corInfo: corInfo is an optional parameter of type CORInfoType that allows the Registrant organization to set forth a claim to be the carrier-of-record (see [RFC5067]).

o corInfo:corInfo是CORInfoType类型的可选参数,允许注册人组织提出作为记录载体的声明(参见[RFC5067])。

In some cases, a Public Identifier may be a URI, such as an email address. The URIPubIdType object is comprised of the data element necessary to house such Public Identifiers. Each URIPubIdType object is uniquely identified by the combination of its value in the <uri> element and its Registrant ID. URIPubIdType is defined as follows:

在某些情况下,公共标识符可以是URI,例如电子邮件地址。URIPubIdType对象由容纳此类公共标识符所需的数据元素组成。每个URIPubIdType对象通过其在<uri>元素中的值及其注册者ID的组合进行唯一标识。URIPubIdType定义如下:

   <complexType name="URIPubIdType">
    <complexContent>
     <extension base="sppfb:PubIdType">
      <sequence>
       <element name="uri" type="anyURI"/>
       <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
      </sequence>
     </extension>
    </complexContent>
   </complexType>
        
   <complexType name="URIPubIdType">
    <complexContent>
     <extension base="sppfb:PubIdType">
      <sequence>
       <element name="uri" type="anyURI"/>
       <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
      </sequence>
     </extension>
    </complexContent>
   </complexType>
        

URIPubIdType consists of the following attributes:

URIPubIdType由以下属性组成:

o uri: The value that acts as the Public Identifier.

o uri:充当公共标识符的值。

o ext: Point of extensibility described in Section 3.3.

o ext:第3.3节中描述的扩展点。

6.3. SED Group
6.3. SED组

SED Group is a grouping of one or more Destination Groups, the common SED Records, and the list of peer organizations with access to the SED Records associated with a given SED Group. It is this indirect linking of Public Identifiers to their SED that significantly improves the scalability and manageability of the peering data. Additions and changes to SED information are reduced to a single operation on a SED Group or SED Record rather than millions of data updates to individual Public Identifier records that individually contain their peering data. The substrate protocol MUST support the ability to Add, Get, and Delete SED Groups (refer to Section 7 for a generic description of various operations).

SED组是由一个或多个目标组、公共SED记录和可访问与给定SED组关联的SED记录的对等组织列表组成的分组。正是这种将公共标识符间接链接到SED的方式显著提高了对等数据的可伸缩性和可管理性。对SED信息的添加和更改简化为对SED组或SED记录的单个操作,而不是对单独包含对等数据的单个公共标识符记录进行数百万次数据更新。基板协议必须支持添加、获取和删除SED组的功能(有关各种操作的一般说明,请参阅第7节)。

A SED Group object MUST be uniquely identified by attributes as defined in the description of "ObjKeyType" in "Generic Object Key Type" (Section 5.2.1 of this document).

SED组对象必须由“通用对象密钥类型”(本文件第5.2.1节)中“ObjKeyType”描述中定义的属性唯一标识。

The SedGrpType object structure is defined as follows:

SedGrpType对象结构定义如下:

   <complexType name="SedGrpType">
    <complexContent>
     <extension base="sppfb:BasicObjType">
      <sequence>
       <element name="sedGrpName" type="sppfb:ObjNameType"/>
       <element name="sedRecRef" type="sppfb:SedRecRefType"
                minOccurs="0" maxOccurs="unbounded"/>
       <element name="dgName" type="sppfb:ObjNameType"
                minOccurs="0" maxOccurs="unbounded"/>
       <element name="peeringOrg" type="sppfb:OrgIdType"
                minOccurs="0" maxOccurs="unbounded"/>
       <element name="sourceIdent" type="sppfb:SourceIdentType"
                minOccurs="0" maxOccurs="unbounded"/>
       <element name="isInSvc" type="boolean"/>
       <element name="priority" type="unsignedShort"/>
       <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
      </sequence>
     </extension>
    </complexContent>
   </complexType>
        
   <complexType name="SedGrpType">
    <complexContent>
     <extension base="sppfb:BasicObjType">
      <sequence>
       <element name="sedGrpName" type="sppfb:ObjNameType"/>
       <element name="sedRecRef" type="sppfb:SedRecRefType"
                minOccurs="0" maxOccurs="unbounded"/>
       <element name="dgName" type="sppfb:ObjNameType"
                minOccurs="0" maxOccurs="unbounded"/>
       <element name="peeringOrg" type="sppfb:OrgIdType"
                minOccurs="0" maxOccurs="unbounded"/>
       <element name="sourceIdent" type="sppfb:SourceIdentType"
                minOccurs="0" maxOccurs="unbounded"/>
       <element name="isInSvc" type="boolean"/>
       <element name="priority" type="unsignedShort"/>
       <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
      </sequence>
     </extension>
    </complexContent>
   </complexType>
        
   <complexType name="SedRecRefType">
    <sequence>
     <element name="sedKey" type="sppfb:ObjKeyType"/>
     <element name="priority" type="unsignedShort"/>
     <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
    </sequence>
   </complexType>
        
   <complexType name="SedRecRefType">
    <sequence>
     <element name="sedKey" type="sppfb:ObjKeyType"/>
     <element name="priority" type="unsignedShort"/>
     <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
    </sequence>
   </complexType>
        

The SedGrpType object is composed of the following elements:

SedGrpType对象由以下元素组成:

o base: All first-class objects extend BasicObjType (see Section 5.1).

o 基本:所有一级对象都扩展了BasicObjType(参见第5.1节)。

o sedGrpName: The character string that contains the name of the SED Group. It uniquely identifies this object within the context of the Registrant ID (a child element of the base element as described above).

o sedGrpName:包含SED组名称的字符串。它在注册者ID(如上所述的基本元素的子元素)的上下文中唯一地标识该对象。

o sedRecRef: Set of zero or more objects of type SedRecRefType that house the unique keys of the SED Records (containing the SED) that the SedGrpType object refers to and their relative priority within the context of this SED Group.

o SEDREF:一组零个或多个SEDREFTYPE类型的对象,其中包含SedGrpType对象引用的SED记录(包含SED)的唯一键及其在此SED组上下文中的相对优先级。

o dgName: Set of zero or more names of DestGrpType object instances. Each dgName name, in association with this SED Group's Registrant ID, uniquely identifies a DestGrpType object instance whose associated Public Identifiers are reachable using the SED housed in this SED Group. An intended side effect of this is that a SED Group cannot provide session establishment information for a Destination Group belonging to another Registrant.

o dgName:DestGrpType对象实例的零个或多个名称的集合。每个dgName名称与此SED组的注册者ID关联,唯一标识一个DestGrpType对象实例,该实例的关联公共标识符可使用此SED组中的SED访问。这样做的一个预期副作用是SED组不能为属于另一个注册者的目的地组提供会话建立信息。

o peeringOrg: Set of zero or more peering organization IDs that have accepted an offer to receive this SED Group's information. Note that this identifier "peeringOrg" is an instance of OrgIdType. The set of peering organizations in this list is not directly settable or modifiable using the addSedGrpsRqst operation. This set is instead controlled using the SED Offer and Accept operations.

o peeringOrg:一组零个或多个对等组织ID,它们接受了接收此SED组信息的要约。请注意,此标识符“peeringOrg”是OrgIdType的一个实例。此列表中的对等组织集不能使用addSedGrpsRqst操作直接设置或修改。而是使用SED提供和接受操作来控制此集合。

o sourceIdent: Set of zero or more SourceIdentType object instances. These objects, described further below, house the source identification schemes and identifiers that are applied at resolution time as part of source-based routing algorithms for the SED Group.

o sourceIdent:零个或多个sourceidentype对象实例的集合。这些对象(下文将进一步描述)包含源标识方案和标识符,这些方案和标识符在解析时作为SED组基于源的路由算法的一部分应用。

o isInSvc: A boolean element that defines whether this SED Group is in service. The SED contained in a SED Group that is in service is a candidate for inclusion in resolution responses for Public Identities residing in the Destination Group associated with this SED Group. The session establishment information contained in a SED Group that is not in service is not a candidate for inclusion in resolution responses.

o isInSvc:一个布尔元素,用于定义此SED组是否处于服务状态。服务中的SED组中包含的SED是驻留在与此SED组关联的目标组中的公共身份的解析响应中的候选。包含在未使用的SED组中的会话建立信息不可包含在解决响应中。

o priority: Priority value that can be used to provide a relative value weighting of one SED Group over another. The manner in which this value is used, perhaps in conjunction with other factors, is a matter of policy.

o 优先级:优先级值,可用于提供一个SED组相对于另一个SED组的相对值权重。该值的使用方式,可能与其他因素结合使用,是一个政策问题。

o ext: Point of extensibility described in Section 3.3.

o ext:第3.3节中描述的扩展点。

As described above, the SED Group contains a set of references to SED Record objects. A SED Record object is based on an abstract type: SedRecType. The concrete types that use SedRecType as an extension base are NAPTRType, NSType, and URIType. The definitions of these types are included in "SED Record" (Section 6.4 of this document).

如上所述,SED组包含一组对SED记录对象的引用。SED记录对象基于抽象类型:sedrecype。使用sedrecype作为扩展基的具体类型有NAPTRType、NSType和URIType。这些类型的定义包含在“SED记录”(本文件第6.4节)中。

The SedGrpType object provides support for source-based routing via the peeringOrg data element and more granular source-based routing via the source identity element. The source identity element provides the ability to specify zero or more of the following in association with a given SED Group: a regular expression that is

SedGrpType对象通过peeringOrg数据元素支持基于源的路由,通过source identity元素支持更细粒度的基于源的路由。sourceidentity元素提供了与给定SED组相关联的零个或多个以下项的功能:一个

matched against the resolution client IP address, a regular expression that is matched against the root domain name(s), and/or a regular expression that is matched against the calling party URI(s). The result will be that, after identifying the visible SED Groups whose associated Destination Group(s) contains the lookup key being queried and whose peeringOrg list contains the querying organization's organization ID, the resolution server will evaluate the characteristics of the Source URI, Source IP address, and root domain of the lookup key being queried. The resolution server then compares these criteria against the source identity criteria associated with the SED Groups. The SED contained in SED Groups that have source-based routing criteria will only be included in the resolution response if one or more of the criteria matches the source criteria from the resolution request. The source identity data element is of type SourceIdentType, whose structure is defined as follows:

与解析客户端IP地址匹配,与根域名匹配的正则表达式,和/或与调用方URI匹配的正则表达式。结果将是,在识别其关联的目标组包含被查询的查找键且其peeringOrg列表包含查询组织的组织ID的可见SED组后,解析服务器将评估源URI、源IP地址、,和正在查询的查找键的根域。然后,解析服务器将这些标准与与与SED组关联的源标识标准进行比较。只有当一个或多个条件与解析请求中的源条件匹配时,具有源路由条件的SED组中包含的SED才会包含在解析响应中。源标识数据元素的类型为SourceIdentity type,其结构定义如下:

   <complexType name="SourceIdentType">
    <sequence>
     <element name="sourceIdentRegex" type="sppfb:RegexType"/>
     <element name="sourceIdentScheme"
              type="sppfb:SourceIdentSchemeType"/>
     <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
    </sequence>
   </complexType>
        
   <complexType name="SourceIdentType">
    <sequence>
     <element name="sourceIdentRegex" type="sppfb:RegexType"/>
     <element name="sourceIdentScheme"
              type="sppfb:SourceIdentSchemeType"/>
     <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
    </sequence>
   </complexType>
        
   <simpleType name="SourceIdentSchemeType">
    <restriction base="token">
     <enumeration value="uri"/>
     <enumeration value="ip"/>
     <enumeration value="rootDomain"/>
    </restriction>
   </simpleType>
        
   <simpleType name="SourceIdentSchemeType">
    <restriction base="token">
     <enumeration value="uri"/>
     <enumeration value="ip"/>
     <enumeration value="rootDomain"/>
    </restriction>
   </simpleType>
        

The SourceIdentType object is composed of the following data elements:

SourceIdentintType对象由以下数据元素组成:

o sourceIdentScheme: The source identification scheme that this source identification criteria applies to and that the associated sourceIdentRegex should be matched against.

o SourceIdentintScheme:此源标识标准适用的源标识方案,并且应匹配关联的SourceIdentintRegex。

o sourceIdentRegex: The regular expression that should be used to test for a match against the portion of the resolution request that is dictated by the associated sourceIdentScheme.

o sourceIdentRegex:应用于测试与相关sourceIdentScheme指定的解析请求部分是否匹配的正则表达式。

o ext: Point of extensibility described in Section 3.3.

o ext:第3.3节中描述的扩展点。

6.4. SED Record
6.4. SED记录

SED Group represents a combined grouping of SED Records that define SED. However, SED Records need not be created to just serve a single SED Group. SED Records can be created and managed to serve multiple SED Groups. As a result, a change, for example, to the properties of a network node used for multiple routes would necessitate just a single update operation to change the properties of that node. The change would then be reflected in all the SED Groups whose SED Record set contains a reference to that node. The substrate protocol MUST support the ability to Add, Get, and Delete SED Records (refer to Section 7 for a generic description of various operations).

SED Group表示定义SED的SED记录的组合分组。但是,创建SED记录不需要仅为单个SED组服务。可以创建和管理SED记录以服务于多个SED组。因此,例如,对用于多个路由的网络节点的属性的更改将只需要一次更新操作来更改该节点的属性。然后,更改将反映在其SED记录集包含对该节点的引用的所有SED组中。基板协议必须支持添加、获取和删除SED记录的功能(有关各种操作的一般说明,请参阅第7节)。

A SED Record object MUST be uniquely identified by attributes as defined in the description of "ObjKeyType" in "Generic Object Key Type" (Section 5.2.1 of this document).

SED记录对象必须由“通用对象密钥类型”(本文件第5.2.1节)中“ObjKeyType”描述中定义的属性唯一标识。

The SedRecType object structure is defined as follows:

SedRecType对象结构定义如下:

   <complexType name="SedRecType" abstract="true">
    <complexContent>
     <extension base="sppfb:BasicObjType">
      <sequence>
       <element name="sedName" type="sppfb:ObjNameType"/>
       <element name="sedFunction" type="sppfb:SedFunctionType"
                minOccurs="0"/>
       <element name="isInSvc" type="boolean"/>
       <element name="ttl" type="positiveInteger" minOccurs="0"/>
      </sequence>
     </extension>
    </complexContent>
   </complexType>
        
   <complexType name="SedRecType" abstract="true">
    <complexContent>
     <extension base="sppfb:BasicObjType">
      <sequence>
       <element name="sedName" type="sppfb:ObjNameType"/>
       <element name="sedFunction" type="sppfb:SedFunctionType"
                minOccurs="0"/>
       <element name="isInSvc" type="boolean"/>
       <element name="ttl" type="positiveInteger" minOccurs="0"/>
      </sequence>
     </extension>
    </complexContent>
   </complexType>
        
   <simpleType name="SedFunctionType">
    <restriction base="token">
     <enumeration value="routing"/>
     <enumeration value="lookup"/>
    </restriction>
   </simpleType>
        
   <simpleType name="SedFunctionType">
    <restriction base="token">
     <enumeration value="routing"/>
     <enumeration value="lookup"/>
    </restriction>
   </simpleType>
        

The SedRecType object is composed of the following elements:

SedRecType对象由以下元素组成:

o base: All first-class objects extend BasicObjType (see Section 5.1).

o 基本:所有一级对象都扩展了BasicObjType(参见第5.1节)。

o sedName: The character string that contains the name of the SED Record. It uniquely identifies this object within the context of the Registrant ID (a child element of the base element as described above).

o sedName:包含SED记录名称的字符串。它在注册者ID(如上所述的基本元素的子元素)的上下文中唯一地标识该对象。

o sedFunction: As described in [RFC6461], SED falls primarily into one of two categories or functions: LUF and LRF. To remove any ambiguity as to the function a SED Record is intended to provide, this optional element allows the provisioning party to make its intentions explicit.

o SED功能:如[RFC6461]所述,SED主要分为两类或两种功能之一:LUF和LRF。为了消除SED记录要提供的功能的任何模糊性,此可选元素允许供应方明确其意图。

o isInSvc: A boolean element that defines whether or not this SED Record is in service. The session establishment information contained in a SED Record that is in service is a candidate for inclusion in resolution responses for TNs that are either directly associated to this SED Record or for Public Identities residing in a Destination Group that is associated to a SED Group, which, in turn, has an association to this SED Record.

o isInSvc:一个布尔元素,用于定义此SED记录是否处于服务状态。服务中的SED记录中包含的会话建立信息是直接关联到该SED记录的TNs或驻留在与该SED记录关联的目的地组中的公共身份的解析响应中包含的候选项,而该目的地组又与该SED记录关联。

o ttl: Number of seconds that an addressing server may cache a particular SED Record.

o ttl:寻址服务器缓存特定SED记录的秒数。

As described above, SED Records are based on abstract type SedRecType. The concrete types that use SedRecType as an extension base are NAPTRType, NSType, and URIType. The definitions of these types are included below. The NAPTRType object is comprised of the data elements necessary for a Naming Authority Pointer (NAPTR) (see [RFC3403]) that contains routing information for a SED Group. The NSType object is comprised of the data elements necessary for a DNS name server that points to another DNS server that contains the desired routing information. The NSType is relevant only when the resolution protocol is ENUM (see [RFC6116]). The URIType object is comprised of the data elements necessary to house a URI.

如上所述,SED记录基于抽象类型sedrecype。使用sedrecype作为扩展基的具体类型有NAPTRType、NSType和URIType。这些类型的定义如下所示。NAPTRType对象由包含SED组路由信息的命名机构指针(NAPTR)(请参见[RFC3403])所需的数据元素组成。NSType对象由指向另一个包含所需路由信息的DNS服务器的DNS名称服务器所需的数据元素组成。NSType仅在解析协议为ENUM时才相关(请参见[RFC6116])。URIType对象由容纳URI所需的数据元素组成。

The data provisioned in a Registry can be leveraged for many purposes and queried using various protocols including SIP, ENUM, and others. As such, the resolution data represented by the SED Records must be in a form suitable for transport using one of these protocols. In the NAPTRType, for example, if the URI is associated with a Destination Group, the user part of the replacement string <uri> that may require the Public Identifier cannot be preset. As a SIP Redirect, the resolution server will apply <ere> pattern on the input Public Identifier in the query and process the replacement string by substituting any back references in the <uri> to arrive at the final URI that is returned in the SIP Contact header. For an ENUM query, the resolution server will simply return the values of the <ere> and <uri> members of the URI.

注册表中提供的数据可用于多种用途,并可使用各种协议(包括SIP、ENUM等)进行查询。因此,由SED记录表示的分辨率数据必须采用适合使用这些协议之一进行传输的形式。例如,在NAPTRType中,如果URI与目标组关联,则无法预设可能需要公共标识符的替换字符串<URI>的用户部分。作为SIP重定向,解析服务器将在查询中的输入公共标识符上应用<ere>模式,并通过替换<uri>中的任何反向引用来处理替换字符串,以获得SIP联系人标头中返回的最终uri。对于枚举查询,解析服务器将只返回uri的<ere>和<uri>成员的值。

   <complexType name="NAPTRType">
    <complexContent>
     <extension base="sppfb:SedRecType">
      <sequence>
       <element name="order" type="unsignedShort"/>
       <element name="flags" type="sppfb:FlagsType" minOccurs="0"/>
       <element name="svcs" type="sppfb:SvcType"/>
       <element name="regx" type="sppfb:RegexParamType" minOccurs="0"/>
       <element name="repl" type="sppfb:ReplType" minOccurs="0"/>
       <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
      </sequence>
     </extension>
    </complexContent>
   </complexType>
        
   <complexType name="NAPTRType">
    <complexContent>
     <extension base="sppfb:SedRecType">
      <sequence>
       <element name="order" type="unsignedShort"/>
       <element name="flags" type="sppfb:FlagsType" minOccurs="0"/>
       <element name="svcs" type="sppfb:SvcType"/>
       <element name="regx" type="sppfb:RegexParamType" minOccurs="0"/>
       <element name="repl" type="sppfb:ReplType" minOccurs="0"/>
       <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
      </sequence>
     </extension>
    </complexContent>
   </complexType>
        
   <complexType name="NSType">
    <complexContent>
     <extension base="sppfb:SedRecType">
      <sequence>
       <element name="hostName" type="token"/>
       <element name="ipAddr" type="sppfb:IPAddrType"
                minOccurs="0" maxOccurs="unbounded"/>
       <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
      </sequence>
     </extension>
    </complexContent>
   </complexType>
        
   <complexType name="NSType">
    <complexContent>
     <extension base="sppfb:SedRecType">
      <sequence>
       <element name="hostName" type="token"/>
       <element name="ipAddr" type="sppfb:IPAddrType"
                minOccurs="0" maxOccurs="unbounded"/>
       <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
      </sequence>
     </extension>
    </complexContent>
   </complexType>
        
   <complexType name="IPAddrType">
    <sequence>
     <element name="addr" type="sppfb:AddrStringType"/>
     <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
    </sequence>
    <attribute name="type" type="sppfb:IPType" default="IPv4"/>
   </complexType>
        
   <complexType name="IPAddrType">
    <sequence>
     <element name="addr" type="sppfb:AddrStringType"/>
     <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
    </sequence>
    <attribute name="type" type="sppfb:IPType" default="IPv4"/>
   </complexType>
        
   <simpleType name="IPType">
    <restriction base="token">
     <enumeration value="IPv4"/>
     <enumeration value="IPv6"/>
    </restriction>
   </simpleType>
        
   <simpleType name="IPType">
    <restriction base="token">
     <enumeration value="IPv4"/>
     <enumeration value="IPv6"/>
    </restriction>
   </simpleType>
        
   <complexType name="URIType">
    <complexContent>
     <extension base="sppfb:SedRecType">
      <sequence>
       <element name="ere" type="token" default="^(.*)$"/>
        
   <complexType name="URIType">
    <complexContent>
     <extension base="sppfb:SedRecType">
      <sequence>
       <element name="ere" type="token" default="^(.*)$"/>
        
       <element name="uri" type="anyURI"/>
       <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
      </sequence>
     </extension>
    </complexContent>
   </complexType>
        
       <element name="uri" type="anyURI"/>
       <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
      </sequence>
     </extension>
    </complexContent>
   </complexType>
        
   <simpleType name="flagsType">
    <restriction base="token">
     <length value="1"/>
     <pattern value="[A-Z]|[a-z]|[0-9]"/>
    </restriction>
   </simpleType>
        
   <simpleType name="flagsType">
    <restriction base="token">
     <length value="1"/>
     <pattern value="[A-Z]|[a-z]|[0-9]"/>
    </restriction>
   </simpleType>
        

The NAPTRType object is composed of the following elements:

NAPTRType对象由以下元素组成:

o order: Order value in an ENUM NAPTR, relative to other NAPTRType objects in the same SED Group.

o 顺序:相对于同一SED组中的其他NAPTRType对象,枚举NAPTR中的顺序值。

o svcs: ENUM service(s) that is served by the SBE. This field's value must be of the form specified in [RFC6116] (e.g., E2U+pstn:sip+sip). The allowable values are a matter of policy and are not limited by this protocol.

o svcs:SBE提供的枚举服务。此字段的值必须采用[RFC6116]中指定的格式(例如,E2U+pstn:sip+sip)。允许值是政策问题,不受本协议限制。

o regx: NAPTR's regular expression field. If this is not included, then the repl field must be included.

o regx:NAPTR的正则表达式字段。如果未包括此字段,则必须包括repl字段。

o repl: NAPTR replacement field; it should only be provided if the regx field is not provided; otherwise, the server will ignore it.

o repl:NAPTR替换字段;仅当未提供regx字段时才应提供;否则,服务器将忽略它。

o ext: Point of extensibility described in Section 3.3.

o ext:第3.3节中描述的扩展点。

The NSType object is composed of the following elements:

NSType对象由以下元素组成:

o hostName: Root-relative host name of the name server.

o 主机名:名称服务器的根相对主机名。

o ipAddr: Zero or more objects of type IpAddrType. Each object holds an IP Address and the IP Address type ("IPv4" or "IPv6").

o ipAddr:零个或多个IpAddrType类型的对象。每个对象都拥有一个IP地址和IP地址类型(“IPv4”或“IPv6”)。

o ext: Point of extensibility described in Section 3.3.

o ext:第3.3节中描述的扩展点。

The URIType object is composed of the following elements:

URIType对象由以下元素组成:

o ere: The POSIX Extended Regular Expression (ere) as defined in [RFC3986].

o ere:[RFC3986]中定义的POSIX扩展正则表达式(ere)。

o uri: the URI as defined in [RFC3986]. In some cases, this will serve as the replacement string, and it will be left to the resolution server to arrive at the final usable URI.

o uri:[RFC3986]中定义的uri。在某些情况下,这将用作替换字符串,它将留给解析服务器来获得最终可用的URI。

6.5. SED Group Offer
6.5. SED集团报价

The list of peer organizations whose resolution responses can include the SED contained in a given SED Group is controlled by the organization to which a SED Group object belongs (its Registrant) and the peer organization that submits resolution requests (a data recipient, also known as a peering organization). The Registrant offers access to a SED Group by submitting a SED Group Offer. The data recipient can then accept or reject that offer. Not until access to a SED Group has been offered and accepted will the data recipient's organization ID be included in the peeringOrg list in a SED Group object, and that SED Group's peering information becomes a candidate for inclusion in the responses to the resolution requests submitted by that data recipient. The substrate protocol MUST support the ability to Add, Get, Delete, Accept, and Reject SED Group Offers (refer to Section 7 for a generic description of various operations).

其解决响应可包括给定SED组中包含的SED的对等组织列表由SED组对象所属的组织(其注册人)和提交解决请求的对等组织(数据接收方,也称为对等组织)控制。注册人通过提交SED集团报价提供访问SED集团的权限。然后,数据接收方可以接受或拒绝该提议。只有在提供并接受对SED组的访问权限后,数据接收方的组织ID才会包含在SED组对象的peeringOrg列表中,并且该SED组的对等信息将成为包含在该数据接收方提交的解决请求响应中的候选信息。基板协议必须支持添加、获取、删除、接受和拒绝SED组报价的能力(有关各种操作的一般说明,请参阅第7节)。

A SED Group Offer object MUST be uniquely identified by attributes as defined in the description of "SedGrpOfferKeyType" in "Derived Object Key Types" (Section 5.2.2 of this document).

SED集团要约对象必须由“派生对象密钥类型”(本文件第5.2.2节)中“SedGrpOfferKeyType”描述中定义的属性唯一标识。

The SedGrpOfferType object structure is defined as follows:

SedGrpOfferType对象结构定义如下:

   <complexType name="SedGrpOfferType">
    <complexContent>
     <extension base="sppfb:BasicObjType">
      <sequence>
       <element name="sedGrpOfferKey" type="sppfb:SedGrpOfferKeyType"/>
       <element name="status" type="sppfb:SedGrpOfferStatusType"/>
       <element name="offerDateTime" type="dateTime"/>
       <element name="acceptDateTime" type="dateTime" minOccurs="0"/>
       <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
      </sequence>
     </extension>
    </complexContent>
   </complexType>
        
   <complexType name="SedGrpOfferType">
    <complexContent>
     <extension base="sppfb:BasicObjType">
      <sequence>
       <element name="sedGrpOfferKey" type="sppfb:SedGrpOfferKeyType"/>
       <element name="status" type="sppfb:SedGrpOfferStatusType"/>
       <element name="offerDateTime" type="dateTime"/>
       <element name="acceptDateTime" type="dateTime" minOccurs="0"/>
       <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
      </sequence>
     </extension>
    </complexContent>
   </complexType>
        
   <complexType name="SedGrpOfferKeyType" abstract="true">
    <annotation>
     <documentation>
     -- Generic type that represents the key for a SED Group Offer. Must
        be defined in concrete form in a substrate "protocol"
        specification. --
     </documentation>
    </annotation>
   </complexType>
        
   <complexType name="SedGrpOfferKeyType" abstract="true">
    <annotation>
     <documentation>
     -- Generic type that represents the key for a SED Group Offer. Must
        be defined in concrete form in a substrate "protocol"
        specification. --
     </documentation>
    </annotation>
   </complexType>
        
   <simpleType name="SedGrpOfferStatusType">
    <restriction base="token">
     <enumeration value="offered"/>
     <enumeration value="accepted"/>
    </restriction>
   </simpleType>
        
   <simpleType name="SedGrpOfferStatusType">
    <restriction base="token">
     <enumeration value="offered"/>
     <enumeration value="accepted"/>
    </restriction>
   </simpleType>
        

The SedGrpOfferType object is composed of the following elements:

SedGrpOfferType对象由以下元素组成:

o base: All first-class objects extend BasicObjType (see Section 5.1).

o 基本:所有一级对象都扩展了BasicObjType(参见第5.1节)。

o sedGrpOfferKey: The object that identifies the SED that is or has been offered and the organization to which it is or has been offered.

o sedGrpOfferKey:标识已提供或已提供SED以及已提供或已提供SED的组织的对象。

o status: The status of the offer, offered or accepted. The server controls the status. It is automatically set to "offered" whenever a new SED Group Offer is added and is automatically set to "accepted" if and when that offer is accepted. The value of the element is ignored when passed in by the client.

o 状态:报价的状态,已报价或已接受。服务器控制状态。每当添加新的SED集团报价时,该报价将自动设置为“已报价”,如果该报价被接受,则该报价将自动设置为“已接受”。当客户端传入时,将忽略元素的值。

o offerDateTime: Date and time in UTC when the SED Group Offer was added.

o offerDateTime:添加SED集团报价时的UTC日期和时间。

o acceptDateTime: Date and time in UTC when the SED Group Offer was accepted.

o acceptDateTime:接受SED集团报价时的UTC日期和时间。

6.6. Egress Route
6.6. 出口路线

In a high-availability environment, the originating SSP likely has more than one egress path to the ingress SBE of the target SSP. If the originating SSP wants to exercise greater control and choose a specific egress SBE to be associated to the target ingress SBE, it can do so using the EgrRteType object.

在高可用性环境中,发起SSP可能有多条到目标SSP的入口SBE的出口路径。如果发起SSP希望实施更大的控制并选择与目标入口SBE关联的特定出口SBE,则可以使用EGRRETYPE对象来实现。

An Egress Route object MUST be uniquely identified by attributes as defined in the description of "ObjKeyType" in "Generic Object Key Type" (Section 5.2.1 of this document).

出口路线对象必须由“通用对象密钥类型”(本文件第5.2.1节)中“ObjKeyType”描述中定义的属性唯一标识。

Assume that the target SSP has offered, as part of its SED, to share one or more Ingress Routes and that the originating SSP has accepted the offer. In order to add the Egress Route to the Registry, the originating SSP uses a valid regular expression to rewrite the Ingress Route in order to include the egress SBE information. Also, more than one Egress Route can be associated with a given Ingress Route in support of fault-tolerant configurations. The supporting SPPF structure provides a way to include route precedence information to help manage traffic to more than one outbound egress SBE.

假设目标SSP已作为其SED的一部分提供共享一条或多条入口路由,且发起SSP已接受该提供。为了将出口路由添加到注册表,发起SSP使用有效的正则表达式重写入口路由,以便包括出口SBE信息。此外,可以将多个出口路由与给定的入口路由相关联,以支持容错配置。支持的SPPF结构提供了一种包含路由优先级信息的方法,以帮助管理到多个出站SBE的流量。

The substrate protocol MUST support the ability to Add, Get, and Delete Egress Routes (refer to Section 7 for a generic description of various operations). The EgrRteType object structure is defined as follows:

基板协议必须支持添加、获取和删除出口路由的能力(有关各种操作的一般说明,请参阅第7节)。EGRRETYPE对象结构定义如下:

   <complexType name="EgrRteType">
    <complexContent>
     <extension base="sppfb:BasicObjType">
      <sequence>
       <element name="egrRteName" type="sppfb:ObjNameType"/>
       <element name="pref" type="unsignedShort"/>
       <element name="regxRewriteRule" type="sppfb:RegexParamType"/>
       <element name="ingrSedGrp" type="sppfb:ObjKeyType"
                minOccurs="0" maxOccurs="unbounded"/>
       <element name="svcs" type="sppfb:SvcType" minOccurs="0"/>
       <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
      </sequence>
     </extension>
    </complexContent>
   </complexType>
        
   <complexType name="EgrRteType">
    <complexContent>
     <extension base="sppfb:BasicObjType">
      <sequence>
       <element name="egrRteName" type="sppfb:ObjNameType"/>
       <element name="pref" type="unsignedShort"/>
       <element name="regxRewriteRule" type="sppfb:RegexParamType"/>
       <element name="ingrSedGrp" type="sppfb:ObjKeyType"
                minOccurs="0" maxOccurs="unbounded"/>
       <element name="svcs" type="sppfb:SvcType" minOccurs="0"/>
       <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
      </sequence>
     </extension>
    </complexContent>
   </complexType>
        

The EgrRteType object is composed of the following elements:

EGRRETYPE对象由以下元素组成:

o base: All first-class objects extend BasicObjType (see Section 5.1).

o 基本:所有一级对象都扩展了BasicObjType(参见第5.1节)。

o egrRteName: The name of the Egress Route.

o egrRteName:出口路线的名称。

o pref: The preference of this Egress Route relative to other Egress Routes that may get selected when responding to a resolution request.

o pref:相对于响应解析请求时可能选择的其他出口路由,此出口路由的首选项。

o regxRewriteRule: The regular expression rewrite rule that should be applied to the regular expression of the ingress NAPTR(s) that belongs to the Ingress Route.

o regxRewriteRule:应应用于属于入口路由的入口NAPTR的正则表达式的正则表达式重写规则。

o ingrSedGrp: The ingress SED Group that the Egress Route should be used for.

o ingrSedGrp:出口路线应用于的入口SED组。

o svcs: ENUM service(s) that is served by an Egress Route. This element is used to identify the ingress NAPTRs associated with the SED Group to which an Egress Route's regxRewriteRule should be applied. If no ENUM service(s) is associated with an Egress Route, then the Egress Route's regxRewriteRule should be applied to all the NAPTRs associated with the SED Group. This field's value must be of the form specified in [RFC6116] (e.g., E2U+pstn:sip+sip). The allowable values are a matter of policy and are not limited by this protocol.

o svcs:出口路由提供的枚举服务。此元素用于标识与SED组相关联的入口NAPTR,出口路由的REGxREWRITE规则应应用于该SED组。如果没有与出口路由关联的枚举服务,则出口路由的regxRewriteRule应应用于与SED组关联的所有NAPTR。此字段的值必须采用[RFC6116]中指定的格式(例如,E2U+pstn:sip+sip)。允许值是政策问题,不受本协议限制。

o ext: Point of extensibility described in Section 3.3.

o ext:第3.3节中描述的扩展点。

7. Framework Operations
7. 框架操作

In addition to the operation-specific object types, all operations MAY specify the minor version of the protocol that when used in conjunction with the major version (which can be, for instance, specified in the protocol Namespace) can serve to identify the version of the SPPF protocol that the client is using. If the minor version is not specified, the latest minor version supported by the SPPF server for the given major version will be used. Additionally, operations that may potentially modify persistent protocol objects SHOULD include a transaction ID as well.

除了操作特定的对象类型外,所有操作都可以指定协议的次要版本,当与主要版本(例如,可以在协议名称空间中指定)一起使用时,可以用于标识客户端正在使用的SPPF协议的版本。如果未指定次要版本,则将使用SPPF服务器支持的给定主要版本的最新次要版本。此外,可能修改持久协议对象的操作还应包括事务ID。

7.1. Add Operation
7.1. 添加操作

Any conforming substrate "protocol" specification MUST provide a definition for the operation that adds one or more SPPF objects into the Registry. If the object, as identified by the request attributes that form part of the object's key, does not exist, then the Registry MUST create the object. If the object does exist, then the Registry MUST replace the current properties of the object with the properties passed in as part of the Add operation.

任何符合要求的基板“协议”规范必须为将一个或多个SPPF对象添加到注册表中的操作提供定义。如果由构成对象键一部分的请求属性标识的对象不存在,则注册表必须创建该对象。如果对象确实存在,则注册表必须将对象的当前属性替换为作为添加操作的一部分传入的属性。

Note that this effectively allows modification of a preexisting object.

请注意,这实际上允许修改先前存在的对象。

If the entity that issued the command is not authorized to perform this operation, an appropriate error message MUST be returned from amongst the response messages defined in "Response Message Types" (Section 5.3 of this document).

如果发出命令的实体无权执行此操作,则必须从“响应消息类型”(本文件第5.3节)中定义的响应消息中返回相应的错误消息。

7.2. Delete Operation
7.2. 删除操作

Any conforming substrate "protocol" specification MUST provide a definition for the operation that deletes one or more SPPF objects from the Registry using the object's key.

任何符合要求的基板“协议”规范必须为使用对象密钥从注册表中删除一个或多个SPPF对象的操作提供定义。

If the entity that issued the command is not authorized to perform this operation, an appropriate error message MUST be returned from amongst the response messages defined in "Response Message Types" (Section 5.3 of this document).

如果发出命令的实体无权执行此操作,则必须从“响应消息类型”(本文件第5.3节)中定义的响应消息中返回相应的错误消息。

When an object is deleted, any references to that object must of course also be removed as the SPPF server implementation fulfills the deletion request. Furthermore, the deletion of a composite object must also result in the deletion of the objects it contains. As a result, the following rules apply to the deletion of SPPF object types:

删除对象时,当然也必须删除对该对象的任何引用,因为SPPF服务器实现满足删除请求。此外,删除复合对象还必须导致删除其包含的对象。因此,以下规则适用于SPPF对象类型的删除:

o Destination Groups: When a Destination Group is deleted, any cross-references between that destination group and any SED Group must be automatically removed by the SPPF implementation as part of fulfilling the deletion request. Similarly, any cross-references between that Destination Group and any Public Identifier must be removed by the SPPF implementation.

o 目标组:删除目标组时,SPPF实现必须自动删除该目标组与任何SED组之间的任何交叉引用,作为完成删除请求的一部分。类似地,SPPF实现必须删除该目标组和任何公共标识符之间的任何交叉引用。

o SED Groups: When a SED Group is deleted, any references between that SED Group and any Destination Group must be automatically removed by the SPPF implementation as part of fulfilling the deletion request. Similarly, any cross-references between that SED Group and any SED Records must be removed by the SPPF

o SED组:删除SED组时,SPPF实现必须自动删除该SED组与任何目标组之间的任何引用,作为完成删除请求的一部分。同样,SPPF必须删除该SED组和任何SED记录之间的任何交叉引用

implementation as part of fulfilling the deletion request. Furthermore, SED Group Offers relating to that SED Group must also be deleted.

作为满足删除请求的一部分的实现。此外,还必须删除与该SED集团相关的SED集团报价。

o SED Records: When a SED Record is deleted, any cross-references between that SED Record and any SED Group must be removed by the SPPF implementation as part of fulfilling the deletion request. Similarly, any reference between that SED Record and any Public Identifier must be removed by the SPPF implementation.

o SED记录:删除SED记录时,SPPF实施部门必须删除该SED记录与任何SED组之间的任何交叉引用,作为完成删除请求的一部分。同样,该SED记录和任何公共标识符之间的任何引用都必须由SPPF实现删除。

o Public Identifiers: When a Public Identifier is deleted, any cross-references between that Public Identifier and any referenced Destination Group must be removed by the SPPF implementation as part of fulfilling the deletion request. Any references to SED Records associated directly to that Public Identifier must also be deleted by the SPPF implementation.

o 公共标识符:删除公共标识符时,SPPF实现必须删除该公共标识符与任何引用的目标组之间的任何交叉引用,作为完成删除请求的一部分。SPPF实现还必须删除对与该公共标识符直接关联的SED记录的任何引用。

Deletes MUST be atomic.

删除必须是原子的。

7.3. Get Operations
7.3. 获取操作

At times, on behalf of the Registrant, the Registrar may need to get information about SPPF objects that were previously provisioned in the Registry. A few examples include logging, auditing, and pre-provisioning dependency checking. This query mechanism is limited to aid provisioning scenarios and should not be confused with query protocols provided as part of the resolution system (e.g., ENUM and SIP).

有时,注册人可能需要代表注册人获取有关先前在注册处提供的SPPF对象的信息。一些示例包括日志记录、审核和预设置依赖项检查。此查询机制仅限于辅助供应场景,不应与作为解决系统一部分提供的查询协议(例如,ENUM和SIP)混淆。

Any conforming "protocol" specification MUST provide a definition for the operation that queries the details of one or more SPPF objects from the Registry using the object's key. If the entity that issued the command is not authorized to perform this operation, an appropriate error message MUST be returned from among the response messages defined in Section 5.3.

任何符合要求的“协议”规范必须为使用对象密钥从注册表查询一个或多个SPPF对象详细信息的操作提供定义。如果发出命令的实体无权执行此操作,则必须从第5.3节中定义的响应消息中返回相应的错误消息。

If the response to the Get operation includes an object(s) that extends the BasicObjType, the Registry MUST include the "cDate" and "mDate", if applicable.

如果Get操作的响应包含扩展BasicObjType的对象,则注册表必须包含“cDate”和“mDate”(如果适用)。

7.4. Accept Operations
7.4. 接受操作

In SPPF, a SED Group Offer can be accepted or rejected by, or on behalf of, the Registrant to which the SED Group has been offered (refer to Section 6.5 of this document for a description of the SED Group Offer object). The Accept operation is used to accept the SED Group Offers. Any conforming substrate "protocol" specification MUST provide a definition for the operation to accept SED Group Offers by,

在SPPF中,SED集团要约可由SED集团被要约的注册人或其代表接受或拒绝(有关SED集团要约对象的说明,请参阅本文件第6.5节)。接受操作用于接受SED组的报价。任何符合要求的基板“协议”规范必须为接受SED集团报价的操作提供定义,

or on behalf of, the Registrant, using the SED Group Offer object key.

或代表注册人,使用SED Group Offer对象密钥。

Not until access to a SED Group has been offered and accepted will the Registrant's organization ID be included in the peeringOrg list in that SED Group object, and that SED Group's peering information becomes a candidate for inclusion in the responses to the resolution requests submitted by that Registrant. A SED Group Offer that is in the "offered" status is accepted by, or on behalf of, the Registrant to which it has been offered. When the SED Group Offer is accepted, the SED Group Offer is moved to the "accepted" status and the data recipient's organization ID is added into the list of peerOrgIds for that SED Group.

只有在提供并接受SED组访问权限后,注册人的组织ID才会包含在该SED组对象的peeringOrg列表中,并且该SED组的peering信息成为该注册人提交的处置请求响应中的候选信息。处于“要约”状态的SED集团要约由被要约的注册人或其代表接受。当SED组报价被接受时,SED组报价将移至“已接受”状态,并且数据接收方的组织ID将添加到该SED组的peerorgid列表中。

If the entity that issued the command is not authorized to perform this operation, an appropriate error message MUST be returned from amongst the response messages defined in "Response Message Types" (Section 5.3 of this document).

如果发出命令的实体无权执行此操作,则必须从“响应消息类型”(本文件第5.3节)中定义的响应消息中返回相应的错误消息。

7.5. Reject Operations
7.5. 拒绝操作

In SPPF, a SED Group Offer object can be accepted or rejected by, or on behalf of, the Registrant to which the SED Group has been offered (refer to "Framework Data Model Objects", Section 6 of this document, for a description of the SED Group Offer object). Furthermore, that offer may be rejected, regardless of whether or not it has been previously accepted. The Reject operation is used to reject the SED Group Offer. When the SED Group Offer is rejected, that SED Group Offer is deleted, and, if appropriate, the data recipient's organization ID is removed from the list of peeringOrg IDs for that SED Group. Any conforming substrate "protocol" specification MUST provide a definition for the operation to reject SED Group Offers by, or on behalf of, the Registrant, using the SED Group Offer object key.

在SPPF中,SED集团要约对象可由SED集团被要约的注册人或其代表接受或拒绝(有关SED集团要约对象的说明,请参阅本文件第6节“框架数据模型对象”)。此外,该要约可能会被拒绝,无论之前是否被接受。拒绝操作用于拒绝SED组报价。当SED组报价被拒绝时,该SED组报价将被删除,如果合适,数据接收方的组织ID将从该SED组的peeringOrg ID列表中删除。任何符合要求的基板“协议”规范必须提供使用SED Group Offer object key拒绝注册人或其代表的SED Group Offer的操作定义。

If the entity that issued the command is not authorized to perform this operation, an appropriate error message MUST be returned from among the response messages defined in "Response Message Types" (Section 5.3 of this document).

如果发出命令的实体无权执行此操作,则必须从“响应消息类型”(本文件第5.3节)中定义的响应消息中返回相应的错误消息。

7.6. Get Server Details Operation
7.6. 获取服务器详细信息操作

In SPPF, the Get Server Details operation can be used to request certain details about the SPPF server that include the SPPF server's current status and the major/minor version of the SPPF protocol supported by the SPPF server.

在SPPF中,获取服务器详细信息操作可用于请求有关SPPF服务器的某些详细信息,包括SPPF服务器的当前状态以及SPPF服务器支持的SPPF协议的主要/次要版本。

Any conforming substrate "protocol" specification MUST provide a definition for the operation to request such details from the SPPF server. If the entity that issued the command is not authorized to perform this operation, an appropriate error message MUST be returned from among the response messages defined in "Response Message Types" (Section 5.3 of this document).

任何符合要求的基板“协议”规范都必须为从SPPF服务器请求此类详细信息的操作提供定义。如果发出命令的实体无权执行此操作,则必须从“响应消息类型”(本文件第5.3节)中定义的响应消息中返回相应的错误消息。

8. XML Considerations
8. XML注意事项

XML serves as the encoding format for SPPF, allowing complex hierarchical data to be expressed in a text format that can be read, saved, and manipulated with both traditional text tools and tools specific to XML.

XML作为SPPF的编码格式,允许以文本格式表示复杂的层次结构数据,该文本格式可以使用传统的文本工具和特定于XML的工具来读取、保存和操作。

XML is case sensitive. Unless stated otherwise, the character casing of XML specifications in this document MUST be preserved to develop a conforming specification.

XML区分大小写。除非另有说明,否则必须保留本文档中XML规范的字符大小写,以制定一致性规范。

This section discusses a small number of XML-related considerations pertaining to SPPF.

本节讨论与SPPF有关的少量XML相关注意事项。

8.1. Namespaces
8.1. 名称空间

All SPPF elements are defined in the Namespaces in the "IANA Considerations" and "Formal Framework Specification" sections of this document.

所有SPPF元素都在本文档“IANA注意事项”和“正式框架规范”部分的名称空间中定义。

8.2. Versioning and Character Encoding
8.2. 版本控制和字符编码

All XML instances SHOULD begin with an <?xml?> declaration to identify the version of XML that is being used, optionally identify use of the character encoding used, and optionally provide a hint to an XML parser that an external schema file is needed to validate the XML instance.

所有XML实例都应该以<?XML?>声明开始,以标识正在使用的XML版本,可以选择标识所用字符编码的使用,还可以选择向XML解析器提供提示,提示需要外部架构文件来验证XML实例。

Conformant XML parsers recognize both UTF-8 (defined in [RFC3629]) and UTF-16 (defined in [RFC2781]); per [RFC2277], UTF-8 is the RECOMMENDED character encoding for use with SPPF.

一致性XML解析器识别UTF-8(在[RFC3629]中定义)和UTF-16(在[RFC2781]中定义);根据[RFC2277],UTF-8是推荐用于SPPF的字符编码。

Character encodings other than UTF-8 and UTF-16 are allowed by XML. UTF-8 is the default encoding assumed by XML in the absence of an "encoding" attribute or a byte order mark (BOM); thus, the "encoding" attribute in the XML declaration is OPTIONAL if UTF-8 encoding is used. SPPF clients and servers MUST accept a UTF-8 BOM if present, though emitting a UTF-8 BOM is NOT RECOMMENDED.

XML允许UTF-8和UTF-16以外的字符编码。UTF-8是XML在没有“编码”属性或字节顺序标记(BOM)的情况下采用的默认编码;因此,如果使用UTF-8编码,XML声明中的“encoding”属性是可选的。SPPF客户端和服务器必须接受UTF-8 BOM(如果存在),但不建议发出UTF-8 BOM。

Example XML declarations:

XML声明示例:

   <?xml version="1.0" encoding="UTF-8" standalone="no"?>
        
   <?xml version="1.0" encoding="UTF-8" standalone="no"?>
        
9. Security Considerations
9. 安全考虑

Many SPPF implementations manage data that is considered confidential and critical. Furthermore, SPPF implementations can support provisioning activities for multiple Registrars and Registrants. As a result, any SPPF implementation must address the requirements for confidentiality, authentication, and authorization.

许多SPPF实现管理被认为是机密和关键的数据。此外,SPPF实现可以支持多个注册者和注册者的供应活动。因此,任何SPPF实现都必须满足保密性、身份验证和授权的要求。

9.1. Confidentiality and Authentication
9.1. 保密和认证

With respect to confidentiality and authentication, the substrate protocol requirements section of this document contains security properties that the substrate protocol must provide, so that authenticated endpoints can exchange data confidentially and with integrity protection. Refer to Section 4 of this document and [RFC7878] for the specific solutions to authentication and confidentiality.

关于机密性和身份验证,本文档的“基板协议要求”部分包含基板协议必须提供的安全属性,以便经过身份验证的端点可以在完整性保护的情况下秘密交换数据。有关认证和保密的具体解决方案,请参阅本文件第4节和[RFC7878]。

9.2. Authorization
9.2. 批准

With respect to authorization, the SPPF server implementation must define and implement a set of authorization rules that precisely address (1) which Registrars will be authorized to create/modify/ delete each SPPF object type for a given Registrant(s) and (2) which Registrars will be authorized to view/get each SPPF object type for a given Registrant(s). These authorization rules are a matter of policy and are not specified within the context of SPPF. However, any SPPF implementation must specify these authorization rules in order to function in a reliable and safe manner.

就授权而言,SPPF服务器实施必须定义并实施一套授权规则,以精确解决(1)哪些注册人将被授权为给定注册人创建/修改/删除每个SPPF对象类型和(2)哪些注册人将被授权查看/获取给定注册人的每个SPPF对象类型。这些授权规则属于策略问题,不在SPPF上下文中指定。但是,任何SPPF实现都必须指定这些授权规则,以便以可靠和安全的方式运行。

9.3. Denial of Service
9.3. 拒绝服务

In general, guidance on Denial-of-Service (DoS) issues is given in "Internet Denial of Service Considerations" [RFC4732], which also gives a general vocabulary for describing the DoS issue.

一般而言,“Internet拒绝服务注意事项”[RFC4732]中给出了拒绝服务(DoS)问题的指南,该指南还提供了描述DoS问题的通用词汇表。

SPPF is a high-level client-server protocol that can be implemented on lower-level mechanisms such as remote procedure call and web-service API protocols. As such, it inherits any Denial-of-Service issues inherent to the specific lower-level mechanism used for any implementation of SPPF. SPPF also has its own set of higher-level exposures that are likely to be independent of lower-layer mechanism choices.

SPPF是一种高级客户机-服务器协议,可以在较低级别的机制(如远程过程调用和web服务API协议)上实现。因此,它继承了用于任何SPPF实现的特定较低级别机制固有的任何拒绝服务问题。SPPF也有自己的高水平曝光集,可能独立于低层机制选择。

9.3.1. DoS Issues Inherited from the Substrate Mechanism
9.3.1. 从基板机制继承的DoS问题

In general, an SPPF implementation is dependent on the selection and implementation of a lower-level substrate protocol and a binding between that protocol and SPPF. The archetypal SPPF implementation uses XML [W3C.REC-xml-20081126] representation in a SOAP [SOAPREF] request/response framework over HTTP [RFC7230], probably also uses Transport Layer Security (TLS) [RFC5246] for on-the-wire data integrity and participant authentication, and might use HTTP Digest authentication [RFC2069].

通常,SPPF实现取决于较低级别基板协议的选择和实现以及该协议与SPPF之间的绑定。原型SPPF实现在HTTP[RFC7230]上的SOAP[SOAPREF]请求/响应框架中使用XML[W3C.REC-XML-20081126]表示,可能还使用传输层安全性(TLS)[RFC5246]实现在线数据完整性和参与者身份验证,并且可能使用HTTP摘要身份验证[RFC2069]。

The typical deployment scenario for SPPF is to have servers in a managed facility; therefore, techniques such as Network Ingress Filtering [RFC2827] are generally applicable. In short, any DoS mechanism affecting a typical HTTP implementation would affect such an SPPF implementation; therefore, the mitigation tools for HTTP in general also apply to SPPF.

SPPF的典型部署场景是在托管设施中部署服务器;因此,诸如网络入口过滤[RFC2827]之类的技术通常是适用的。简而言之,任何影响典型HTTP实现的DoS机制都会影响这样的SPPF实现;因此,HTTP缓解工具通常也适用于SPPF。

SPPF does not directly specify an authentication mechanism; instead, it relies on the lower-level substrate protocol to provide for authentication. In general, authentication is an expensive operation, and one apparent attack vector is to flood an SPPF server with repeated requests for authentication, thereby exhausting its resources. Therefore, SPPF implementations SHOULD be prepared to handle authentication floods, perhaps by noting repeated failed login requests from a given source address and blocking that source address.

SPPF不直接指定身份验证机制;相反,它依赖于较低级别的底层协议来提供身份验证。通常,认证是一种昂贵的操作,一个明显的攻击向量是用重复的请求来认证SPPF服务器,从而耗尽其资源。因此,SPPF实现应该准备好处理身份验证洪水,可能需要注意来自给定源地址的重复失败登录请求并阻止该源地址。

9.3.2. DoS Issues Specific to SPPF
9.3.2. 特定于SPPF的DoS问题

The primary defense mechanism against DoS within SPPF is authentication. Implementations MUST tightly control access to the SPPF service, SHOULD implement DoS and other policy control screening, and MAY employ a variety of policy violation reporting and response measures such as automatic blocking of specific users and alerting of operations personnel. In short, the primary SPPF response to DoS-like activity by a user is to block that user or subject their actions to additional review.

SPPF中针对DoS的主要防御机制是身份验证。实施必须严格控制对SPPF服务的访问,应实施DoS和其他策略控制筛选,并可能采用各种策略违规报告和响应措施,如自动阻止特定用户和提醒操作人员。简言之,SPPF对用户类似DoS的活动的主要响应是阻止该用户或对其操作进行额外审查。

SPPF allows a client to submit multiple-element or "batch" requests that may insert or otherwise affect a large amount of data with a single request. In the simplest case, the server progresses sequentially through each element in a batch, completing one before starting the next. Mid-batch failures are handled by stopping the batch and rolling back the data store to its pre-request state. This "stop and roll back" design provides a DoS opportunity. A hostile client could repeatedly issue large batch requests with one or more failing elements, causing the server to repeatedly stop and roll back

SPPF允许客户端提交多个元素或“批处理”请求,这些请求可能通过单个请求插入或以其他方式影响大量数据。在最简单的情况下,服务器按顺序处理批处理中的每个元素,在开始下一个元素之前完成一个元素。批中故障通过停止批处理并将数据存储回滚到其请求前状态来处理。这种“停止并回滚”设计提供了DoS机会。恶意客户端可能会重复发出带有一个或多个失败元素的大批量请求,导致服务器重复停止并回滚

large transactions. The suggested response is to monitor clients for such failures and take administrative action (such as blocking the user) when an excessive number of rollbacks is reported.

大额交易。建议的响应是监视客户端是否存在此类故障,并在报告回滚次数过多时采取管理操作(例如阻止用户)。

An additional suggested response is for an implementer to set their maximum allowable XML message size and their maximum allowable batch size at a level that they feel protects their operational instance, given the hardware sizing they have in place and the expected load and size needs that their users expect.

另外一个建议的响应是,实现者可以将其最大允许的XML消息大小和最大允许的批处理大小设置在他们认为可以保护其操作实例的级别上,考虑到他们现有的硬件大小以及他们的用户期望的预期负载和大小需求。

9.4. Information Disclosure
9.4. 信息披露

It is not uncommon for the logging systems to document on-the-wire messages for various purposes, such as debugging, auditing, and tracking. At the minimum, the various support and administration staff will have access to these logs. Also, if an unprivileged user gains access to the SPPF deployments and/or support systems, it will have access to the information that is potentially deemed confidential. To manage information disclosure concerns beyond the substrate level, SPPF implementations MAY provide support for encryption at the SPPF object level.

日志记录系统出于各种目的(如调试、审核和跟踪)记录在线消息并不少见。至少,各种支持和管理人员可以访问这些日志。此外,如果未经授权的用户能够访问SPPF部署和/或支持系统,则其将能够访问可能被视为机密的信息。为了管理基板级别以外的信息披露问题,SPPF实现可以在SPPF对象级别提供加密支持。

9.5. Non-repudiation
9.5. 不可抵赖

In some situations, it may be required to protect against denial of involvement (see [RFC4949]) and tackle non-repudiation concerns in regard to SPPF messages. This type of protection is useful to satisfy authenticity concerns related to SPPF messages beyond the end-to-end connection integrity, confidentiality, and authentication protection that the substrate layer provides. This is an optional feature, and some SPPF implementations MAY provide support for it.

在某些情况下,可能需要防止拒绝参与(请参见[RFC4949]),并解决与SPPF消息有关的不可否认性问题。这种类型的保护有助于满足与SPPF消息相关的真实性问题,而不仅仅是基底层提供的端到端连接完整性、机密性和身份验证保护。这是一个可选功能,一些SPPF实现可能会提供对它的支持。

9.6. Replay Attacks
9.6. 攻击回放

Anti-replay protection ensures that a given SPPF object replayed at a later time won't affect the integrity of the system. SPPF provides at least one mechanism to fight against replay attacks. Use of the optional client transaction identifier allows the SPPF client to correlate the request message with the response and to be sure that it is not a replay of a server response from earlier exchanges. Use of unique values for the client transaction identifier is highly encouraged to avoid chance matches to a potential replay message.

防重放保护可确保以后重放的给定SPPF对象不会影响系统的完整性。SPPF提供至少一种机制来对抗重放攻击。使用可选的客户端事务标识符允许SPPF客户端将请求消息与响应关联起来,并确保它不是来自早期交换的服务器响应的重播。强烈建议对客户端事务标识符使用唯一值,以避免与潜在重播消息的偶然匹配。

9.7. Compromised or Malicious Intermediary
9.7. 妥协或恶意中介

The SPPF client or Registrar can be a separate entity acting on behalf of the Registrant in facilitating provisioning transactions to the Registry. Therefore, even though the substrate layer provides end-to-end protection for each specific SPPP connection between client and server, data might be available in clear text before or after it traverses an SPPP connection. Therefore, a man-in-the-middle attack by one of the intermediaries is a possibility that could affect the integrity of the data that belongs to the Registrant and/or expose peering data to unintended actors.

SPPF客户或注册人可以是一个单独的实体,代表注册人促进向注册处的拨备交易。因此,即使基板层为客户机和服务器之间的每个特定SPPP连接提供端到端保护,数据也可能在穿越SPPP连接之前或之后以明文形式可用。因此,中间人攻击可能会影响属于注册人的数据的完整性和/或将对等数据暴露给非预期参与者。

10. Internationalization Considerations
10. 国际化考虑

Character encodings to be used for SPPF elements are described in Section 8.2. The use of time elements in the protocol is specified in Section 3.2. Where human-readable messages that are presented to an end user are used in the protocol, those messages SHOULD be tagged according to [RFC5646], and the substrate protocol MUST support a respective mechanism to transmit such tags together with those human-readable messages.

第8.2节描述了用于SPPF元素的字符编码。第3.2节规定了协议中时间元素的使用。如果在协议中使用呈现给最终用户的人类可读消息,则应根据[RFC5646]对这些消息进行标记,并且基板协议必须支持相应的机制,以将这些标记与这些人类可读消息一起传输。

11. IANA Considerations
11. IANA考虑
11.1. URN Assignments
11.1. 瓮分配

This document uses URNs to describe XML Namespaces and XML Schemas conforming to a Registry mechanism described in [RFC3688].

本文档使用URN来描述符合[RFC3688]中描述的注册表机制的XML名称空间和XML模式。

Two URI assignments have been made:

已完成两个URI分配:

Registration for the SPPF XML Namespace: urn:ietf:params:xml:ns:sppf:base:1 Registrant Contact: The IESG XML: None. Namespace URIs do not represent an XML specification.

SPPF XML命名空间的注册:urn:ietf:params:XML:ns:SPPF:base:1注册人联系人:IESG XML:None。命名空间URI不表示XML规范。

Registration request for the XML Schema:

XML架构的注册请求:

URI: urn:ietf:params:xml:schema:sppf:1 Registrant Contact: IESG XML: See "Formal Specification" (Section 12 of this document).

URI:urn:ietf:params:xml:schema:sppf:1注册人联系人:IESG-xml:参见“正式规范”(本文档第12节)。

11.2. Organization Identifier Namespace Registry
11.2. 组织标识符命名空间注册表

IANA has created and will maintain a registry titled "SPPF OrgIdType Namespaces". The formal syntax is described in Section 5.1.

IANA已经创建并将维护一个名为“SPPF OrgIdType命名空间”的注册表。第5.1节描述了形式语法。

Assignments consist of the OrgIdType Namespace string and the definition of the associated Namespace. This document makes the following initial assignment for the OrgIdType Namespaces:

分配由OrgIdType命名空间字符串和关联命名空间的定义组成。本文档对OrgIdType命名空间进行以下初始分配:

         OrgIdType Namespace string                       Namespace
         --------------------------                       ---------
         IANA Enterprise Numbers                          iana-en
        
         OrgIdType Namespace string                       Namespace
         --------------------------                       ---------
         IANA Enterprise Numbers                          iana-en
        

Future assignments are to be made through the well-known IANA Policy "RFC Required" (see Section 4.1 of [RFC5226]). Such assignments will typically be requested when a new Namespace for identification of SPs is defined.

未来的任务将通过众所周知的IANA政策“需要RFC”(见[RFC5226]第4.1节)进行。当定义了SP标识的新名称空间时,通常会请求此类分配。

12. Formal Specification
12. 形式规范

This section provides the XSD for the SPPF protocol.

本节提供了SPPF协议的XSD。

   <?xml version="1.0" encoding="UTF-8"?>
   <schema xmlns:sppfb="urn:ietf:params:xml:ns:sppf:base:1"
   xmlns="http://www.w3.org/2001/XMLSchema"
   targetNamespace="urn:ietf:params:xml:ns:sppf:base:1"
   elementFormDefault="qualified" xml:lang="EN">
    <annotation>
     <documentation>
      ---- Generic object key types to be defined by specific
           substrate/architecture.  The types defined here can
           be extended by the specific architecture to
           define the Object Identifiers. ----
     </documentation>
    </annotation>
    <complexType name="ObjKeyType"
     abstract="true">
     <annotation>
      <documentation>
       ---- Generic type that represents the
            key for various objects in SPPF. ----
      </documentation>
     </annotation>
    </complexType>
        
   <?xml version="1.0" encoding="UTF-8"?>
   <schema xmlns:sppfb="urn:ietf:params:xml:ns:sppf:base:1"
   xmlns="http://www.w3.org/2001/XMLSchema"
   targetNamespace="urn:ietf:params:xml:ns:sppf:base:1"
   elementFormDefault="qualified" xml:lang="EN">
    <annotation>
     <documentation>
      ---- Generic object key types to be defined by specific
           substrate/architecture.  The types defined here can
           be extended by the specific architecture to
           define the Object Identifiers. ----
     </documentation>
    </annotation>
    <complexType name="ObjKeyType"
     abstract="true">
     <annotation>
      <documentation>
       ---- Generic type that represents the
            key for various objects in SPPF. ----
      </documentation>
     </annotation>
    </complexType>
        
    <complexType name="SedGrpOfferKeyType" abstract="true">
     <complexContent>
      <extension base="sppfb:ObjKeyType">
       <annotation>
        <documentation>
        ---- Generic type that represents
             the key for a SED Group Offer. ----
        </documentation>
       </annotation>
      </extension>
     </complexContent>
    </complexType>
        
    <complexType name="SedGrpOfferKeyType" abstract="true">
     <complexContent>
      <extension base="sppfb:ObjKeyType">
       <annotation>
        <documentation>
        ---- Generic type that represents
             the key for a SED Group Offer. ----
        </documentation>
       </annotation>
      </extension>
     </complexContent>
    </complexType>
        
    <complexType name="PubIdKeyType" abstract="true">
     <complexContent>
      <extension base="sppfb:ObjKeyType">
       <annotation>
        <documentation>
         ----Generic type that
         represents the key
         for a Pub ID. ----
        </documentation>
       </annotation>
      </extension>
     </complexContent>
    </complexType>
        
    <complexType name="PubIdKeyType" abstract="true">
     <complexContent>
      <extension base="sppfb:ObjKeyType">
       <annotation>
        <documentation>
         ----Generic type that
         represents the key
         for a Pub ID. ----
        </documentation>
       </annotation>
      </extension>
     </complexContent>
    </complexType>
        
    <annotation>
     <documentation>
       ---- Object Type Definitions ----
     </documentation>
    </annotation>
        
    <annotation>
     <documentation>
       ---- Object Type Definitions ----
     </documentation>
    </annotation>
        
    <complexType name="SedGrpType">
     <complexContent>
      <extension base="sppfb:BasicObjType">
       <sequence>
        <element name="sedGrpName" type="sppfb:ObjNameType"/>
        <element name="sedRecRef" type="sppfb:SedRecRefType"
                 minOccurs="0" maxOccurs="unbounded"/>
        <element name="dgName" type="sppfb:ObjNameType"
                 minOccurs="0" maxOccurs="unbounded"/>
        <element name="peeringOrg" type="sppfb:OrgIdType"
                 minOccurs="0" maxOccurs="unbounded"/>
        <element name="sourceIdent" type="sppfb:SourceIdentType"
                 minOccurs="0" maxOccurs="unbounded"/>
        <element name="isInSvc" type="boolean"/>
        <element name="priority" type="unsignedShort"/>
        
    <complexType name="SedGrpType">
     <complexContent>
      <extension base="sppfb:BasicObjType">
       <sequence>
        <element name="sedGrpName" type="sppfb:ObjNameType"/>
        <element name="sedRecRef" type="sppfb:SedRecRefType"
                 minOccurs="0" maxOccurs="unbounded"/>
        <element name="dgName" type="sppfb:ObjNameType"
                 minOccurs="0" maxOccurs="unbounded"/>
        <element name="peeringOrg" type="sppfb:OrgIdType"
                 minOccurs="0" maxOccurs="unbounded"/>
        <element name="sourceIdent" type="sppfb:SourceIdentType"
                 minOccurs="0" maxOccurs="unbounded"/>
        <element name="isInSvc" type="boolean"/>
        <element name="priority" type="unsignedShort"/>
        
        <element name="ext"
        type="sppfb:ExtAnyType" minOccurs="0"/>
       </sequence>
      </extension>
     </complexContent>
    </complexType>
    <complexType name="DestGrpType">
     <complexContent>
      <extension base="sppfb:BasicObjType">
       <sequence>
        <element name="dgName"
        type="sppfb:ObjNameType"/>
       </sequence>
      </extension>
     </complexContent>
    </complexType>
    <complexType name="PubIdType" abstract="true">
     <complexContent>
      <extension base="sppfb:BasicObjType">
       <sequence>
        <element name="dgName" type="sppfb:ObjNameType"
                 minOccurs="0" maxOccurs="unbounded"/>
       </sequence>
      </extension>
     </complexContent>
    </complexType>
    <complexType name="TNType">
     <complexContent>
      <extension base="sppfb:PubIdType">
       <sequence>
        <element name="tn" type="sppfb:NumberValType"/>
        <element name="corInfo" type="sppfb:CORInfoType" minOccurs="0"/>
        <element name="sedRecRef" type="sppfb:SedRecRefType"
                 minOccurs="0" maxOccurs="unbounded"/>
       </sequence>
      </extension>
     </complexContent>
    </complexType>
    <complexType name="TNRType">
     <complexContent>
      <extension base="sppfb:PubIdType">
       <sequence>
        <element name="range" type="sppfb:NumberRangeType"/>
        <element name="corInfo" type="sppfb:CORInfoType" minOccurs="0"/>
       </sequence>
      </extension>
     </complexContent>
    </complexType>
        
        <element name="ext"
        type="sppfb:ExtAnyType" minOccurs="0"/>
       </sequence>
      </extension>
     </complexContent>
    </complexType>
    <complexType name="DestGrpType">
     <complexContent>
      <extension base="sppfb:BasicObjType">
       <sequence>
        <element name="dgName"
        type="sppfb:ObjNameType"/>
       </sequence>
      </extension>
     </complexContent>
    </complexType>
    <complexType name="PubIdType" abstract="true">
     <complexContent>
      <extension base="sppfb:BasicObjType">
       <sequence>
        <element name="dgName" type="sppfb:ObjNameType"
                 minOccurs="0" maxOccurs="unbounded"/>
       </sequence>
      </extension>
     </complexContent>
    </complexType>
    <complexType name="TNType">
     <complexContent>
      <extension base="sppfb:PubIdType">
       <sequence>
        <element name="tn" type="sppfb:NumberValType"/>
        <element name="corInfo" type="sppfb:CORInfoType" minOccurs="0"/>
        <element name="sedRecRef" type="sppfb:SedRecRefType"
                 minOccurs="0" maxOccurs="unbounded"/>
       </sequence>
      </extension>
     </complexContent>
    </complexType>
    <complexType name="TNRType">
     <complexContent>
      <extension base="sppfb:PubIdType">
       <sequence>
        <element name="range" type="sppfb:NumberRangeType"/>
        <element name="corInfo" type="sppfb:CORInfoType" minOccurs="0"/>
       </sequence>
      </extension>
     </complexContent>
    </complexType>
        
    <complexType name="TNPType">
     <complexContent>
      <extension base="sppfb:PubIdType">
       <sequence>
        <element name="tnPrefix" type="sppfb:NumberValType"/>
        <element name="corInfo" type="sppfb:CORInfoType" minOccurs="0"/>
       </sequence>
      </extension>
     </complexContent>
    </complexType>
    <complexType name="RNType">
     <complexContent>
      <extension base="sppfb:PubIdType">
       <sequence>
        <element name="rn" type="sppfb:NumberValType"/>
        <element name="corInfo" type="sppfb:CORInfoType" minOccurs="0"/>
       </sequence>
      </extension>
     </complexContent>
    </complexType>
     <complexType name="URIPubIdType">
     <complexContent>
      <extension base="sppfb:PubIdType">
       <sequence>
        <element name="uri" type="anyURI"/>
        <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
       </sequence>
      </extension>
     </complexContent>
    </complexType>
    <complexType name="SedRecType" abstract="true">
     <complexContent>
      <extension base="sppfb:BasicObjType">
       <sequence>
        <element name="sedName" type="sppfb:ObjNameType"/>
        <element name="sedFunction" type="sppfb:SedFunctionType"
                 minOccurs="0"/>
        <element name="isInSvc" type="boolean"/>
        <element name="ttl" type="positiveInteger" minOccurs="0"/>
       </sequence>
      </extension>
     </complexContent>
    </complexType>
    <complexType name="NAPTRType">
     <complexContent>
      <extension base="sppfb:SedRecType">
       <sequence>
        <element name="order" type="unsignedShort"/>
        
    <complexType name="TNPType">
     <complexContent>
      <extension base="sppfb:PubIdType">
       <sequence>
        <element name="tnPrefix" type="sppfb:NumberValType"/>
        <element name="corInfo" type="sppfb:CORInfoType" minOccurs="0"/>
       </sequence>
      </extension>
     </complexContent>
    </complexType>
    <complexType name="RNType">
     <complexContent>
      <extension base="sppfb:PubIdType">
       <sequence>
        <element name="rn" type="sppfb:NumberValType"/>
        <element name="corInfo" type="sppfb:CORInfoType" minOccurs="0"/>
       </sequence>
      </extension>
     </complexContent>
    </complexType>
     <complexType name="URIPubIdType">
     <complexContent>
      <extension base="sppfb:PubIdType">
       <sequence>
        <element name="uri" type="anyURI"/>
        <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
       </sequence>
      </extension>
     </complexContent>
    </complexType>
    <complexType name="SedRecType" abstract="true">
     <complexContent>
      <extension base="sppfb:BasicObjType">
       <sequence>
        <element name="sedName" type="sppfb:ObjNameType"/>
        <element name="sedFunction" type="sppfb:SedFunctionType"
                 minOccurs="0"/>
        <element name="isInSvc" type="boolean"/>
        <element name="ttl" type="positiveInteger" minOccurs="0"/>
       </sequence>
      </extension>
     </complexContent>
    </complexType>
    <complexType name="NAPTRType">
     <complexContent>
      <extension base="sppfb:SedRecType">
       <sequence>
        <element name="order" type="unsignedShort"/>
        
        <element name="flags" type="sppfb:FlagsType" minOccurs="0"/>
        <element name="svcs" type="sppfb:SvcType"/>
        <element name="regx" type="sppfb:RegexParamType" minOccurs="0"/>
        <element name="repl" type="sppfb:ReplType" minOccurs="0"/>
        <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
       </sequence>
      </extension>
     </complexContent>
    </complexType>
    <complexType name="NSType">
     <complexContent>
      <extension base="sppfb:SedRecType">
       <sequence>
        <element name="hostName" type="token"/>
        <element name="ipAddr" type="sppfb:IPAddrType"
                 minOccurs="0" maxOccurs="unbounded"/>
        <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
       </sequence>
      </extension>
     </complexContent>
    </complexType>
    <complexType name="URIType">
     <complexContent>
      <extension base="sppfb:SedRecType">
       <sequence>
        <element name="ere" type="token" default="^(.*)$"/>
        <element name="uri" type="anyURI"/>
        <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
       </sequence>
      </extension>
     </complexContent>
    </complexType>
    <complexType name="SedGrpOfferType">
     <complexContent>
      <extension base="sppfb:BasicObjType">
       <sequence>
        <element name="sedGrpOfferKey" type="sppfb:SedGrpOfferKeyType"/>
        <element name="status" type="sppfb:SedGrpOfferStatusType"/>
        <element name="offerDateTime" type="dateTime"/>
        <element name="acceptDateTime" type="dateTime" minOccurs="0"/>
        <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
       </sequence>
      </extension>
     </complexContent>
    </complexType>
    <complexType name="EgrRteType">
     <complexContent>
      <extension base="sppfb:BasicObjType">
        
        <element name="flags" type="sppfb:FlagsType" minOccurs="0"/>
        <element name="svcs" type="sppfb:SvcType"/>
        <element name="regx" type="sppfb:RegexParamType" minOccurs="0"/>
        <element name="repl" type="sppfb:ReplType" minOccurs="0"/>
        <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
       </sequence>
      </extension>
     </complexContent>
    </complexType>
    <complexType name="NSType">
     <complexContent>
      <extension base="sppfb:SedRecType">
       <sequence>
        <element name="hostName" type="token"/>
        <element name="ipAddr" type="sppfb:IPAddrType"
                 minOccurs="0" maxOccurs="unbounded"/>
        <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
       </sequence>
      </extension>
     </complexContent>
    </complexType>
    <complexType name="URIType">
     <complexContent>
      <extension base="sppfb:SedRecType">
       <sequence>
        <element name="ere" type="token" default="^(.*)$"/>
        <element name="uri" type="anyURI"/>
        <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
       </sequence>
      </extension>
     </complexContent>
    </complexType>
    <complexType name="SedGrpOfferType">
     <complexContent>
      <extension base="sppfb:BasicObjType">
       <sequence>
        <element name="sedGrpOfferKey" type="sppfb:SedGrpOfferKeyType"/>
        <element name="status" type="sppfb:SedGrpOfferStatusType"/>
        <element name="offerDateTime" type="dateTime"/>
        <element name="acceptDateTime" type="dateTime" minOccurs="0"/>
        <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
       </sequence>
      </extension>
     </complexContent>
    </complexType>
    <complexType name="EgrRteType">
     <complexContent>
      <extension base="sppfb:BasicObjType">
        
       <sequence>
        <element name="egrRteName" type="sppfb:ObjNameType"/>
        <element name="pref" type="unsignedShort"/>
        <element name="regxRewriteRule" type="sppfb:RegexParamType"/>
        <element name="ingrSedGrp" type="sppfb:ObjKeyType"
                 minOccurs="0" maxOccurs="unbounded"/>
        <element name="svcs" type="sppfb:SvcType" minOccurs="0"/>
        <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
       </sequence>
      </extension>
     </complexContent>
    </complexType>
    <annotation>
     <documentation>
      ---- Abstract Object and Element Type Definitions ----
     </documentation>
    </annotation>
    <complexType name="BasicObjType" abstract="true">
     <sequence>
      <element name="rant" type="sppfb:OrgIdType"/>
      <element name="rar" type="sppfb:OrgIdType"/>
      <element name="cDate" type="dateTime" minOccurs="0"/>
      <element name="mDate" type="dateTime" minOccurs="0"/>
      <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
     </sequence>
    </complexType>
    <complexType name="RegexParamType">
     <sequence>
      <element name="ere" type="sppfb:RegexType" default="^(.*)$"/>
      <element name="repl" type="sppfb:ReplType"/>
     </sequence>
    </complexType>
    <complexType name="IPAddrType">
     <sequence>
      <element name="addr" type="sppfb:AddrStringType"/>
      <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
     </sequence>
     <attribute name="type" type="sppfb:IPType" default="v4"/>
    </complexType>
    <complexType name="SedRecRefType">
     <sequence>
      <element name="sedKey" type="sppfb:ObjKeyType"/>
      <element name="priority" type="unsignedShort"/>
      <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
     </sequence>
    </complexType>
    <complexType name="SourceIdentType">
     <sequence>
        
       <sequence>
        <element name="egrRteName" type="sppfb:ObjNameType"/>
        <element name="pref" type="unsignedShort"/>
        <element name="regxRewriteRule" type="sppfb:RegexParamType"/>
        <element name="ingrSedGrp" type="sppfb:ObjKeyType"
                 minOccurs="0" maxOccurs="unbounded"/>
        <element name="svcs" type="sppfb:SvcType" minOccurs="0"/>
        <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
       </sequence>
      </extension>
     </complexContent>
    </complexType>
    <annotation>
     <documentation>
      ---- Abstract Object and Element Type Definitions ----
     </documentation>
    </annotation>
    <complexType name="BasicObjType" abstract="true">
     <sequence>
      <element name="rant" type="sppfb:OrgIdType"/>
      <element name="rar" type="sppfb:OrgIdType"/>
      <element name="cDate" type="dateTime" minOccurs="0"/>
      <element name="mDate" type="dateTime" minOccurs="0"/>
      <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
     </sequence>
    </complexType>
    <complexType name="RegexParamType">
     <sequence>
      <element name="ere" type="sppfb:RegexType" default="^(.*)$"/>
      <element name="repl" type="sppfb:ReplType"/>
     </sequence>
    </complexType>
    <complexType name="IPAddrType">
     <sequence>
      <element name="addr" type="sppfb:AddrStringType"/>
      <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
     </sequence>
     <attribute name="type" type="sppfb:IPType" default="v4"/>
    </complexType>
    <complexType name="SedRecRefType">
     <sequence>
      <element name="sedKey" type="sppfb:ObjKeyType"/>
      <element name="priority" type="unsignedShort"/>
      <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
     </sequence>
    </complexType>
    <complexType name="SourceIdentType">
     <sequence>
        
      <element name="sourceIdentRegex" type="sppfb:RegexType"/>
      <element name="sourceIdentScheme"
               type="sppfb:SourceIdentSchemeType"/>
      <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
     </sequence>
    </complexType>
    <complexType name="CORInfoType">
     <sequence>
      <element name="corClaim" type="boolean" default="true"/>
      <element name="cor" type="boolean" default="false" minOccurs="0"/>
      <element name="corDate" type="dateTime" minOccurs="0"/>
     </sequence>
    </complexType>
    <complexType name="SvcMenuType">
     <sequence>
      <element name="serverStatus" type="sppfb:ServerStatusType"/>
      <element name="majMinVersion" type="token" maxOccurs="unbounded"/>
      <element name="objURI" type="anyURI" maxOccurs="unbounded"/>
      <element name="extURI" type="anyURI"
               minOccurs="0" maxOccurs="unbounded"/>
     </sequence>
    </complexType>
    <complexType name="ExtAnyType">
     <sequence>
      <any namespace="##other" maxOccurs="unbounded"/>
     </sequence>
    </complexType>
    <simpleType name="FlagsType">
     <restriction base="token">
      <length value="1"/>
      <pattern value="[A-Z]|[a-z]|[0-9]"/>
     </restriction>
    </simpleType>
    <simpleType name="SvcType">
     <restriction base="token">
      <minLength value="1"/>
     </restriction>
    </simpleType>
    <simpleType name="RegexType">
     <restriction base="token">
      <minLength value="1"/>
     </restriction>
    </simpleType>
    <simpleType name="ReplType">
     <restriction base="token">
      <minLength value="1"/>
      <maxLength value="255"/>
     </restriction>
        
      <element name="sourceIdentRegex" type="sppfb:RegexType"/>
      <element name="sourceIdentScheme"
               type="sppfb:SourceIdentSchemeType"/>
      <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
     </sequence>
    </complexType>
    <complexType name="CORInfoType">
     <sequence>
      <element name="corClaim" type="boolean" default="true"/>
      <element name="cor" type="boolean" default="false" minOccurs="0"/>
      <element name="corDate" type="dateTime" minOccurs="0"/>
     </sequence>
    </complexType>
    <complexType name="SvcMenuType">
     <sequence>
      <element name="serverStatus" type="sppfb:ServerStatusType"/>
      <element name="majMinVersion" type="token" maxOccurs="unbounded"/>
      <element name="objURI" type="anyURI" maxOccurs="unbounded"/>
      <element name="extURI" type="anyURI"
               minOccurs="0" maxOccurs="unbounded"/>
     </sequence>
    </complexType>
    <complexType name="ExtAnyType">
     <sequence>
      <any namespace="##other" maxOccurs="unbounded"/>
     </sequence>
    </complexType>
    <simpleType name="FlagsType">
     <restriction base="token">
      <length value="1"/>
      <pattern value="[A-Z]|[a-z]|[0-9]"/>
     </restriction>
    </simpleType>
    <simpleType name="SvcType">
     <restriction base="token">
      <minLength value="1"/>
     </restriction>
    </simpleType>
    <simpleType name="RegexType">
     <restriction base="token">
      <minLength value="1"/>
     </restriction>
    </simpleType>
    <simpleType name="ReplType">
     <restriction base="token">
      <minLength value="1"/>
      <maxLength value="255"/>
     </restriction>
        
    </simpleType>
    <simpleType name="OrgIdType">
     <restriction base="token"/>
    </simpleType>
    <simpleType name="ObjNameType">
     <restriction base="token">
      <minLength value="3"/>
      <maxLength value="80"/>
     </restriction>
    </simpleType>
    <simpleType name="TransIdType">
     <restriction base="token">
      <minLength value="3"/>
      <maxLength value="120"/>
     </restriction>
    </simpleType>
    <simpleType name="MinorVerType">
     <restriction base="unsignedLong"/>
    </simpleType>
    <simpleType name="AddrStringType">
     <restriction base="token">
      <minLength value="3"/>
      <maxLength value="45"/>
     </restriction>
    </simpleType>
    <simpleType name="IPType">
     <restriction base="token">
      <enumeration value="v4"/>
      <enumeration value="v6"/>
     </restriction>
    </simpleType>
    <simpleType name="SourceIdentSchemeType">
     <restriction base="token">
      <enumeration value="uri"/>
      <enumeration value="ip"/>
      <enumeration value="rootDomain"/>
     </restriction>
    </simpleType>
    <simpleType name="ServerStatusType">
     <restriction base="token">
      <enumeration value="inService"/>
      <enumeration value="outOfService"/>
     </restriction>
    </simpleType>
    <simpleType name="SedGrpOfferStatusType">
     <restriction base="token">
      <enumeration value="offered"/>
      <enumeration value="accepted"/>
        
    </simpleType>
    <simpleType name="OrgIdType">
     <restriction base="token"/>
    </simpleType>
    <simpleType name="ObjNameType">
     <restriction base="token">
      <minLength value="3"/>
      <maxLength value="80"/>
     </restriction>
    </simpleType>
    <simpleType name="TransIdType">
     <restriction base="token">
      <minLength value="3"/>
      <maxLength value="120"/>
     </restriction>
    </simpleType>
    <simpleType name="MinorVerType">
     <restriction base="unsignedLong"/>
    </simpleType>
    <simpleType name="AddrStringType">
     <restriction base="token">
      <minLength value="3"/>
      <maxLength value="45"/>
     </restriction>
    </simpleType>
    <simpleType name="IPType">
     <restriction base="token">
      <enumeration value="v4"/>
      <enumeration value="v6"/>
     </restriction>
    </simpleType>
    <simpleType name="SourceIdentSchemeType">
     <restriction base="token">
      <enumeration value="uri"/>
      <enumeration value="ip"/>
      <enumeration value="rootDomain"/>
     </restriction>
    </simpleType>
    <simpleType name="ServerStatusType">
     <restriction base="token">
      <enumeration value="inService"/>
      <enumeration value="outOfService"/>
     </restriction>
    </simpleType>
    <simpleType name="SedGrpOfferStatusType">
     <restriction base="token">
      <enumeration value="offered"/>
      <enumeration value="accepted"/>
        
     </restriction>
    </simpleType>
    <simpleType name="NumberValType">
     <restriction base="token">
      <maxLength value="20"/>
      <pattern value="\+?\d\d*"/>
     </restriction>
    </simpleType>
    <simpleType name="NumberTypeEnum">
     <restriction base="token">
      <enumeration value="TN"/>
      <enumeration value="TNPrefix"/>
      <enumeration value="RN"/>
     </restriction>
    </simpleType>
    <simpleType name="SedFunctionType">
     <restriction base="token">
      <enumeration value="routing"/>
      <enumeration value="lookup"/>
     </restriction>
    </simpleType>
    <complexType name="NumberType">
     <sequence>
      <element name="value" type="sppfb:NumberValType"/>
      <element name="type" type="sppfb:NumberTypeEnum"/>
     </sequence>
    </complexType>
    <complexType name="NumberRangeType">
     <sequence>
      <element name="startRange" type="sppfb:NumberValType"/>
      <element name="endRange" type="sppfb:NumberValType"/>
     </sequence>
    </complexType>
   </schema>
        
     </restriction>
    </simpleType>
    <simpleType name="NumberValType">
     <restriction base="token">
      <maxLength value="20"/>
      <pattern value="\+?\d\d*"/>
     </restriction>
    </simpleType>
    <simpleType name="NumberTypeEnum">
     <restriction base="token">
      <enumeration value="TN"/>
      <enumeration value="TNPrefix"/>
      <enumeration value="RN"/>
     </restriction>
    </simpleType>
    <simpleType name="SedFunctionType">
     <restriction base="token">
      <enumeration value="routing"/>
      <enumeration value="lookup"/>
     </restriction>
    </simpleType>
    <complexType name="NumberType">
     <sequence>
      <element name="value" type="sppfb:NumberValType"/>
      <element name="type" type="sppfb:NumberTypeEnum"/>
     </sequence>
    </complexType>
    <complexType name="NumberRangeType">
     <sequence>
      <element name="startRange" type="sppfb:NumberValType"/>
      <element name="endRange" type="sppfb:NumberValType"/>
     </sequence>
    </complexType>
   </schema>
        
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>.

[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, DOI 10.17487/RFC2277, January 1998, <http://www.rfc-editor.org/info/rfc2277>.

[RFC2277]Alvestrand,H.,“IETF字符集和语言政策”,BCP 18,RFC 2277,DOI 10.17487/RFC2277,1998年1月<http://www.rfc-editor.org/info/rfc2277>.

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

[RFC3629]Yergeau,F.,“UTF-8,ISO 10646的转换格式”,STD 63,RFC 3629,DOI 10.17487/RFC3629,2003年11月<http://www.rfc-editor.org/info/rfc3629>.

[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.,“IETF XML注册表”,BCP 81,RFC 3688,DOI 10.17487/RFC3688,2004年1月<http://www.rfc-editor.org/info/rfc3688>.

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

[RFC3986]Berners Lee,T.,Fielding,R.,和L.Masinter,“统一资源标识符(URI):通用语法”,STD 66,RFC 3986,DOI 10.17487/RFC3986,2005年1月<http://www.rfc-editor.org/info/rfc3986>.

[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.

[RFC5226]Narten,T.和H.Alvestrand,“在RFCs中编写IANA注意事项部分的指南”,BCP 26,RFC 5226,DOI 10.17487/RFC5226,2008年5月<http://www.rfc-editor.org/info/rfc5226>.

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

[RFC5234]Crocker,D.,Ed.和P.Overell,“语法规范的扩充BNF:ABNF”,STD 68,RFC 5234,DOI 10.17487/RFC5234,2008年1月<http://www.rfc-editor.org/info/rfc5234>.

[RFC7878] Cartwright, K., Bhatia, V., Mule, J., and A. Mayrhofer, "Session Peering Provisioning (SPP) Protocol over SOAP", RFC 7878, DOI 10.17487/RFC7878, August 2016, <http://www.rfc-editor.org/info/rfc7878>.

[RFC7878]Cartwright,K.,Bhatia,V.,Mule,J.,和A.Mayrhofer,“SOAP上的会话对等设置(SPP)协议”,RFC 7878,DOI 10.17487/RFC7878,2016年8月<http://www.rfc-editor.org/info/rfc7878>.

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

[W3C.REC-xml-20081126]Bray,T.,Paoli,J.,Sperberg McQueen,C.,Maler,E.,和F.Yergeau,“可扩展标记语言(xml)1.0(第五版)”,万维网联盟建议REC-xml-20081126,2008年11月<http://www.w3.org/TR/2008/REC-xml-20081126>.

13.2. Informative References
13.2. 资料性引用

[RFC2069] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., Luotonen, A., Sink, E., and L. Stewart, "An Extension to HTTP : Digest Access Authentication", RFC 2069, DOI 10.17487/RFC2069, January 1997, <http://www.rfc-editor.org/info/rfc2069>.

[RFC2069]Franks,J.,Hallam Baker,P.,Hostetler,J.,Leach,P.,Lootonen,A.,Sink,E.,和L.Stewart,“HTTP的扩展:摘要访问认证”,RFC 2069,DOI 10.17487/RFC2069,1997年1月<http://www.rfc-editor.org/info/rfc2069>.

[RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", RFC 2781, DOI 10.17487/RFC2781, February 2000, <http://www.rfc-editor.org/info/rfc2781>.

[RFC2781]Hoffman,P.和F.Yergeau,“UTF-16,ISO 10646编码”,RFC 2781,DOI 10.17487/RFC2781,2000年2月<http://www.rfc-editor.org/info/rfc2781>.

[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, May 2000, <http://www.rfc-editor.org/info/rfc2827>.

[RFC2827]Ferguson,P.和D.Senie,“网络入口过滤:击败利用IP源地址欺骗的拒绝服务攻击”,BCP 38,RFC 2827,DOI 10.17487/RFC2827,2000年5月<http://www.rfc-editor.org/info/rfc2827>.

[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <http://www.rfc-editor.org/info/rfc3261>.

[RFC3261]Rosenberg,J.,Schulzrinne,H.,Camarillo,G.,Johnston,A.,Peterson,J.,Sparks,R.,Handley,M.,和E.Schooler,“SIP:会话启动协议”,RFC 3261,DOI 10.17487/RFC3261,2002年6月<http://www.rfc-editor.org/info/rfc3261>.

[RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, DOI 10.17487/RFC3403, October 2002, <http://www.rfc-editor.org/info/rfc3403>.

[RFC3403]Mealling,M,“动态委托发现系统(DDDS)第三部分:域名系统(DNS)数据库”,RFC 3403,DOI 10.17487/RFC3403,2002年10月<http://www.rfc-editor.org/info/rfc3403>.

[RFC4725] Mayrhofer, A. and B. Hoeneisen, "ENUM Validation Architecture", RFC 4725, DOI 10.17487/RFC4725, November 2006, <http://www.rfc-editor.org/info/rfc4725>.

[RFC4725]Mayrhofer,A.和B.Hoeneisen,“枚举验证体系结构”,RFC 4725,DOI 10.17487/RFC4725,2006年11月<http://www.rfc-editor.org/info/rfc4725>.

[RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet Denial-of-Service Considerations", RFC 4732, DOI 10.17487/RFC4732, December 2006, <http://www.rfc-editor.org/info/rfc4732>.

[RFC4732]Handley,M.,Ed.,Rescorla,E.,Ed.,和IAB,“互联网拒绝服务注意事项”,RFC 4732,DOI 10.17487/RFC4732,2006年12月<http://www.rfc-editor.org/info/rfc4732>.

[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, <http://www.rfc-editor.org/info/rfc4949>.

[RFC4949]Shirey,R.,“互联网安全词汇表,第2版”,FYI 36,RFC 4949,DOI 10.17487/RFC4949,2007年8月<http://www.rfc-editor.org/info/rfc4949>.

[RFC5067] Lind, S. and P. Pfautz, "Infrastructure ENUM Requirements", RFC 5067, DOI 10.17487/RFC5067, November 2007, <http://www.rfc-editor.org/info/rfc5067>.

[RFC5067]Lind,S.和P.Pfautz,“基础设施枚举要求”,RFC 5067,DOI 10.17487/RFC5067,2007年11月<http://www.rfc-editor.org/info/rfc5067>.

[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,“传输层安全(TLS)协议版本1.2”,RFC 5246,DOI 10.17487/RFC5246,2008年8月<http://www.rfc-editor.org/info/rfc5246>.

[RFC5486] Malas, D., Ed. and D. Meyer, Ed., "Session Peering for Multimedia Interconnect (SPEERMINT) Terminology", RFC 5486, DOI 10.17487/RFC5486, March 2009, <http://www.rfc-editor.org/info/rfc5486>.

[RFC5486]Malas,D.,Ed.和D.Meyer,Ed.,“多媒体互连(SPEERMINT)术语的会话对等”,RFC 5486,DOI 10.17487/RFC5486,2009年3月<http://www.rfc-editor.org/info/rfc5486>.

[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009, <http://www.rfc-editor.org/info/rfc5646>.

[RFC5646]Phillips,A.,Ed.和M.Davis,Ed.,“识别语言的标签”,BCP 47,RFC 5646,DOI 10.17487/RFC5646,2009年9月<http://www.rfc-editor.org/info/rfc5646>.

[RFC6116] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 6116, DOI 10.17487/RFC6116, March 2011, <http://www.rfc-editor.org/info/rfc6116>.

[RFC6116]Bradner,S.,Conroy,L.,和K.Fujiwara,“E.164到统一资源标识符(URI)动态委托发现系统(DDDS)应用程序(ENUM)”,RFC 6116DOI 10.17487/RFC6116,2011年3月<http://www.rfc-editor.org/info/rfc6116>.

[RFC6461] Channabasappa, S., Ed., "Data for Reachability of Inter-/Intra-NetworK SIP (DRINKS) Use Cases and Protocol Requirements", RFC 6461, DOI 10.17487/RFC6461, January 2012, <http://www.rfc-editor.org/info/rfc6461>.

[RFC6461]Channabasappa,S.,Ed.“网络间/网络内SIP(饮料)用例和协议要求的可达性数据”,RFC 6461,DOI 10.17487/RFC6461,2012年1月<http://www.rfc-editor.org/info/rfc6461>.

[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]Fielding,R.,Ed.和J.Reschke,Ed.,“超文本传输协议(HTTP/1.1):消息语法和路由”,RFC 7230,DOI 10.17487/RFC7230,2014年6月<http://www.rfc-editor.org/info/rfc7230>.

[SOAPREF] Gudgin, M., Hadley, M., Moreau, J., and H. Nielsen, "SOAP Version 1.2 Part 1: Messaging Framework", W3C REC REC-SOAP12-part1-20030624, June 2003, <http://www.w3.org/TR/soap12-part1/>.

[SOAPREF]Gudgin,M.,Hadley,M.,Moreau,J.,和H.Nielsen,“SOAP版本1.2第1部分:消息传递框架”,W3C REC-SOAP12-part1-200306242003年6月<http://www.w3.org/TR/soap12-part1/>.

[Unicode6.1] The Unicode Consortium, "The Unicode Standard, Version 6.1.0", (Mountain View, CA: The Unicode Consortium, 2012. ISBN 978-1-936213-02-3), <http://unicode.org/versions/Unicode6.1.0/>.

[Unicode 6.1]Unicode联盟,“Unicode标准,版本6.1.0”(加利福尼亚州山景城:Unicode联盟,2012年,ISBN 978-1-936213-02-3)<http://unicode.org/versions/Unicode6.1.0/>.

Acknowledgements

致谢

This document is a result of various discussions held in the DRINKS working group and within the DRINKS protocol design team, with contributions from the following individuals, in alphabetical order: Syed Ali, Jeremy Barkan, Vikas Bhatia, Sumanth Channabasappa, Lisa Dusseault, Deborah A. Guyton, Otmar Lendl, Manjul Maharishi, Mickael Marrache, Alexander Mayrhofer, Samuel Melloul, David Schwartz, and Richard Shockey.

本文件是饮料工作组和饮料协议设计团队中进行的各种讨论的结果,以下个人按字母顺序提供了意见:Syed Ali、Jeremy Barkan、Vikas Bhatia、Sumanth Channabasapa、Lisa Dusseault、Deborah a.Guyton、Otmar Lendl、Manjul Maharishi、Mickeel Marrache、,亚历山大·梅尔霍夫、塞缪尔·梅洛尔、大卫·施瓦茨和理查德·肖基。

Authors' Addresses

作者地址

Kenneth Cartwright TNS 1939 Roland Clarke Place Reston, VA 20191 United States

肯尼斯·卡特赖特TNS 1939美国弗吉尼亚州雷斯顿罗兰·克拉克广场20191

   Email: kcartwright@tnsi.com
        
   Email: kcartwright@tnsi.com
        

Vikas Bhatia TNS 1939 Roland Clarke Place Reston, VA 20191 United States

Vikas Bhatia TNS 1939美国弗吉尼亚州雷斯顿罗兰克拉克广场20191

   Email: vbhatia@tnsi.com
        
   Email: vbhatia@tnsi.com
        

Syed Wasim Ali NeuStar 46000 Center Oak Plaza Sterling, VA 20166 United States

Syed Wasim Ali NeuStar 46000中心奥克广场斯特林,弗吉尼亚州20166美国

   Email: syed.ali@neustar.biz
        
   Email: syed.ali@neustar.biz
        

David Schwartz XConnect 316 Regents Park Road London N3 2XJ United Kingdom

英国伦敦丽晶公园路316号大卫施瓦茨XConnect N3 2XJ

   Email: dschwartz@xconnect.net
        
   Email: dschwartz@xconnect.net