draft-ietf-drinks-spp-framework-00.txt   draft-ietf-drinks-spp-framework-01.txt 
DRINKS J-F. Mule DRINKS J-F. Mule
Internet-Draft CableLabs Internet-Draft CableLabs
Intended status: Standards Track K. Cartwright Intended status: Standards Track K. Cartwright
Expires: August 2, 2012 TNS Expires: September 13, 2012 TNS
S. Ali S. Ali
NeuStar NeuStar
A. Mayrhofer A. Mayrhofer
enum.at GmbH enum.at GmbH
V. Bhatia V. Bhatia
TNS TNS
January 30, 2012 March 12, 2012
Session Peering Provisioning Framework (SPPF) Session Peering Provisioning Framework (SPPF)
draft-ietf-drinks-spp-framework-00 draft-ietf-drinks-spp-framework-01
Abstract Abstract
This document specifies the data model and the overall structure for This document specifies the data model and the overall structure for
a framework to provision session establishment data into Session Data a framework to provision session establishment data into Session Data
Registries and SIP Service Provider data stores. The framework is Registries and SIP Service Provider data stores. The framework is
called the Session Peering Provisioning Framework (SPPF). The called the Session Peering Provisioning Framework (SPPF). The
provisioned data is typically used by network elements for session provisioned data is typically used by network elements for session
peering. peering.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 2, 2012. This Internet-Draft will expire on September 13, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 35 skipping to change at page 2, line 35
4.5. Authorization . . . . . . . . . . . . . . . . . . . . . . 14 4.5. Authorization . . . . . . . . . . . . . . . . . . . . . . 14
4.6. Confidentiality and Integrity . . . . . . . . . . . . . . 14 4.6. Confidentiality and Integrity . . . . . . . . . . . . . . 14
4.7. Near Real Time . . . . . . . . . . . . . . . . . . . . . . 14 4.7. Near Real Time . . . . . . . . . . . . . . . . . . . . . . 14
4.8. Request and Response Sizes . . . . . . . . . . . . . . . . 14 4.8. Request and Response Sizes . . . . . . . . . . . . . . . . 14
4.9. Request and Response Correlation . . . . . . . . . . . . . 14 4.9. Request and Response Correlation . . . . . . . . . . . . . 14
4.10. Request Acknowledgement . . . . . . . . . . . . . . . . . 14 4.10. Request Acknowledgement . . . . . . . . . . . . . . . . . 14
4.11. Mandatory Transport . . . . . . . . . . . . . . . . . . . 15 4.11. Mandatory Transport . . . . . . . . . . . . . . . . . . . 15
5. Base Framework Data Structures and Response Codes . . . . . . 16 5. Base Framework Data Structures and Response Codes . . . . . . 16
5.1. Basic Object Type and Organization Identifiers . . . . . . 16 5.1. Basic Object Type and Organization Identifiers . . . . . . 16
5.2. Various Object Key Types . . . . . . . . . . . . . . . . . 16 5.2. Various Object Key Types . . . . . . . . . . . . . . . . . 16
5.2.1. Generic Object Key Type . . . . . . . . . . . . . . . 16 5.2.1. Generic Object Key Type . . . . . . . . . . . . . . . 17
5.2.2. Derived Object Key Types . . . . . . . . . . . . . . . 17 5.2.2. Derived Object Key Types . . . . . . . . . . . . . . . 17
5.3. Response Message Types . . . . . . . . . . . . . . . . . . 19 5.3. Response Message Types . . . . . . . . . . . . . . . . . . 19
6. Framework Data Model Objects . . . . . . . . . . . . . . . . . 22 6. Framework Data Model Objects . . . . . . . . . . . . . . . . . 22
6.1. Destination Group . . . . . . . . . . . . . . . . . . . . 22 6.1. Destination Group . . . . . . . . . . . . . . . . . . . . 22
6.2. Public Identifier . . . . . . . . . . . . . . . . . . . . 23 6.2. Public Identifier . . . . . . . . . . . . . . . . . . . . 23
6.3. Route Group . . . . . . . . . . . . . . . . . . . . . . . 27 6.3. Route Group . . . . . . . . . . . . . . . . . . . . . . . 28
6.4. Route Record . . . . . . . . . . . . . . . . . . . . . . . 31 6.4. Route Record . . . . . . . . . . . . . . . . . . . . . . . 32
6.5. Route Group Offer . . . . . . . . . . . . . . . . . . . . 35 6.5. Route Group Offer . . . . . . . . . . . . . . . . . . . . 36
6.6. Egress Route . . . . . . . . . . . . . . . . . . . . . . . 38 6.6. Egress Route . . . . . . . . . . . . . . . . . . . . . . . 38
7. Framework Operations . . . . . . . . . . . . . . . . . . . . . 40 7. Framework Operations . . . . . . . . . . . . . . . . . . . . . 40
7.1. Add Operation . . . . . . . . . . . . . . . . . . . . . . 40 7.1. Add Operation . . . . . . . . . . . . . . . . . . . . . . 40
7.2. Delete Operation . . . . . . . . . . . . . . . . . . . . . 40 7.2. Delete Operation . . . . . . . . . . . . . . . . . . . . . 40
7.3. Get Operations . . . . . . . . . . . . . . . . . . . . . . 41 7.3. Get Operations . . . . . . . . . . . . . . . . . . . . . . 41
7.4. Accept Operations . . . . . . . . . . . . . . . . . . . . 41 7.4. Accept Operations . . . . . . . . . . . . . . . . . . . . 41
7.5. Reject Operations . . . . . . . . . . . . . . . . . . . . 42 7.5. Reject Operations . . . . . . . . . . . . . . . . . . . . 42
7.6. Get Server Details Operation . . . . . . . . . . . . . . . 42 7.6. Get Server Details Operation . . . . . . . . . . . . . . . 42
8. XML Considerations . . . . . . . . . . . . . . . . . . . . . . 43 8. XML Considerations . . . . . . . . . . . . . . . . . . . . . . 43
8.1. Namespaces . . . . . . . . . . . . . . . . . . . . . . . . 43 8.1. Namespaces . . . . . . . . . . . . . . . . . . . . . . . . 43
skipping to change at page 6, line 14 skipping to change at page 6, line 14
which in turn helps determine the actual location of the which in turn helps determine the actual location of the
Signaling Function in that domain. Signaling Function in that domain.
2. A resolution system returns both a Look-Up function (LUF) and 2. A resolution system returns both a Look-Up function (LUF) and
Location Routing Function (LRF) to locate the SED data fully. Location Routing Function (LRF) to locate the SED data fully.
In terms of framework design, SPPF is agnostic to the transport In terms of framework design, SPPF is agnostic to the transport
protocol. This document includes the specification of the data model protocol. This document includes the specification of the data model
and identifies, but does not specify, the means to enable protocol and identifies, but does not specify, the means to enable protocol
operations within a request and response structure. That aspect of operations within a request and response structure. That aspect of
the specification has been delegated to the "transport" specification the specification has been delegated to the "protocol" specification
for the protocol. To encourage interoperability, the framework for the framework. To encourage interoperability, the framework
supports extensibility aspects. supports extensibility aspects.
Transport requirements are provided in this document to help with the Transport requirements are provided in this document to help with the
selection of the optimum transport mechanism. The SPP Protocol over selection of the optimum transport mechanism. The SPP Protocol over
SOAP document identifies a protocol for SPPF that uses SOAP/HTTP as SOAP document identifies a protocol for SPPF that uses SOAP/HTTP as
the transport mechanism. the transport mechanism.
This document is organized as follows: This document is organized as follows:
o Section 2 provides the terminology; o Section 2 provides the terminology;
o Section 3 provides an overview of SPPF, including the functional o Section 3 provides an overview of SPPF, including the functional
entities and data model; entities and data model;
o Section 4 specifies requirements for SPPF transport protocols; o Section 4 specifies requirements for SPPF transport protocols;
o Section 5 describes the base framework data structures, the o Section 5 describes the base framework data structures, the
generic response types that MUST be supported by a conforming generic response types that MUST be supported by a conforming
"transport" specification, and the basic object type most first "protocol" specification, and the basic object type most first
class objects extend from; class objects extend from;
o Section 6 detailed descriptoins of the data model object o Section 6 detailed description of the data model object
specifications; specifications;
o Section 8 defines XML considerations that XML parsers must meet o Section 8 defines XML considerations that XML parsers must meet
to conform to this specification; to conform to this specification;
o Section 11 normatively defines the SPPF using its XML Schema o Section 11 normatively defines the SPPF using its XML Schema
Definition. Definition.
2. Terminology 2. Terminology
skipping to change at page 8, line 16 skipping to change at page 8, line 16
from [RFC4725]. A Registrar is an entity that performs from [RFC4725]. A Registrar is an entity that performs
provisioning operations on behalf of a Registrant by interacting provisioning operations on behalf of a Registrant by interacting
with the Registry via SPPF operations. In other words the with the Registry via SPPF operations. In other words the
Registrar is the SPPF Client. The Registrar and Registrant roles Registrar is the SPPF Client. The Registrar and Registrant roles
are logically separate to allow, but not require, a single are logically separate to allow, but not require, a single
Registrar to perform provisioning operations on behalf of more Registrar to perform provisioning operations on behalf of more
than one Registrant. than one Registrant.
Peering Organization: A Peering Organization is an entity to which Peering Organization: A Peering Organization is an entity to which
a Registrant's Route Groups are made visible using the operations a Registrant's Route Groups are made visible using the operations
of SPPP. of SPPF.
3. Framework High Level Design 3. Framework High Level Design
This section introduces the structure of the data model and provides This section introduces the structure of the data model and provides
the information framework for the SPPF. An overview of the protocol the information framework for the SPPF. The data model is defined
operations is first provided with a typical deployment scenario. The along with all the objects manipulated by the protocol and their
data model is then defined along with all the objects manipulated by relationships.
the protocol and their relationships.
3.1. Framework Data Model 3.1. Framework Data Model
The data model illustrated and described in Figure 2 defines the The data model illustrated and described in Figure 2 defines the
logical objects and the relationships between these objects that the logical objects and the relationships between these objects that the
SPPF protocol supports. SPPF defines the protocol operations through SPPF protocol supports. SPPF defines the protocol operations through
which an SPPF client populates a registry with these logical objects. which an SPPF client populates a registry with these logical objects.
Various clients belonging to different registrars may use the Various clients belonging to different registrars may use the
protocol for populating the registry's data. protocol for populating the registry's data.
The logical structure presented below is consistent with the The logical structure presented below is consistent with the
terminology and requirements defined in [RFC6461]. terminology and requirements defined in [RFC6461].
+-------------+ +------------------+ +-------------+ +----------------+
| all object | |Organization: | | all object | |Egress Route: |
| types |----->|orgId | | types | | rant, |
+------+------+ | | +-------------+ | egrRteName, |
All objects are +------------------+ 0..n | | regxRewriteRule|
associated with an ^ | 2 | ingrRteRec |
organization to |A Route Group is +----------------------+ | |
identify the |associated with +-----[abstract]-+ |Organization: | +----------------+
object's registrant |zero or more Peering | Route Record: | | orgId | | 0..n
|Organizations | rrName, | +----------------------+ |
| | priority, | |0..n |
+--------+--------------+ | extension | | |
|Route Group: |------->| | |A Route Group is | 0..n
| rant, | +----------------+ |associated with +-----[abstract]-+
| rgName, | ^ |zero or more Peering | |
| destGrpRef, | | |Organizations | Route Record: |
| isInSvc, | |Various types | | rant, |
| rrRef, | |of Route | | rrName, |0..n
| peeringOrg, | |Records... 0..n| | isInSvc |--------|
| sourceIdent, | +-----+------------+ +--------+--------------+0..n 0..n| | |
| priority, | | | | |Route Group: |-----------------| | |
| extension | +----+ +-------+ +----+ | rant, | +----------------+ |
+-----------------------+ | URI| | NAPTR | | NS | | rgName, | ^ |
| +----+ +-------+ +----+ | isInSvc, | |Various types |
| | rrRef, | |of Route |
| +----------[abstract]-+ | peeringOrg, | |Records |
| |Public Identifier: | | sourceIdent, | +-----+------------+ |
| | | | priority, | | | | |
| | rant, | | dgName | +----+ +-------+ +----+ |
v | publicIdentifier, | +-----------------------+ | URI| | NAPTR | | NS | |
+----------------------+ | destGrpRef, | |0..n +----+ +-------+ +----+ |
| Dest Group: |<----| rrRef, | | |
| rant, | | extension | | +----------[abstract]-+ |
| dgName, | +---------------------+ | |Public Identifier: | |
| extension | ^ | | rant, | |
+----------------------+ |Various types |0..n | publicIdentifier, | |
|of Public +----------------------+0..n 0..n| destGrpRef, | |
|Identifiers... | Dest Group: |--------------| rrRef | |
+---------+-------+------------... | rant, | | | |
| | | | | dgName | +---------------------+ |
+------+ +-----+ +-----+ +-----+ +----------------------+ ^Various types |
| TN | | TNP | | TNR | | RN | |of Public |
+------+ +-----+ +-----+ +-----+ |Identifiers |
+---------+-------+------+----------+ |
SPPF Data Model | | | | | |
+------+ +-----+ +-----+ +-----+ +------+ |
| URI | | TNP | | TNR | | RN | |TN |-----------
+------+ +-----+ +-----+ +-----+ +------+ 0..n
Figure 2 Figure 2
The objects and attributes that comprise the data model can be The objects and attributes that comprise the data model can be
described as follows (objects listed from the bottom up): described as follows (objects listed from the bottom up):
o Public Identifier: o Public Identifier:
From a broad perspective a public identifier is a well-known From a broad perspective a public identifier is a well-known
attribute that is used as the key to perform resolution lookups. attribute that is used as the key to perform resolution lookups.
Within the context of SPPF, a public identifier object can be a Within the context of SPPF, a public identifier object can be a
telephone number, a range of telephone numbers, a PSTN Routing Telephone Number (TN), a range of Telephone Numbers, a PSTN
Number (RN), or a TN prefix. Routing Number (RN), a TN prefix, or a URI.
An SPPF Public Identifier is associated with a Destination Group An SPPF Public Identifier is associated with a Destination Group
to create a logical grouping of Public Identifiers that share a to create a logical grouping of Public Identifiers that share a
common set of Routes. common set of Routes.
A TN Public Identifier may optionally be associated with zero or A TN Public Identifier may optionally be associated with zero or
more individual Route Records. This ability for a Public more individual Route Records. This ability for a Public
Identifier to be directly associated with a set of Route Records Identifier to be directly associated with a set of Route Records
(e.g. target URI), as opposed to being associated with a (e.g. target URI), as opposed to being associated with a
Destination Group, supports the use cases where the target URI Destination Group, supports the use cases where the target URI
skipping to change at page 12, line 4 skipping to change at page 12, line 6
Group and source based routing, refer to the definitions and Group and source based routing, refer to the definitions and
descriptions of the Route Group operations found later in this descriptions of the Route Group operations found later in this
document. document.
o Route Record: o Route Record:
A Route Record contains the data that a resolution system returns A Route Record contains the data that a resolution system returns
in response to a successful query for a Public Identifier. Route in response to a successful query for a Public Identifier. Route
Records are generally associated with a Route Group when the SED Records are generally associated with a Route Group when the SED
within is not specific to a Public Identifier. within is not specific to a Public Identifier.
To support the use cases defined in [RFC6461], SPPF framework To support the use cases defined in [RFC6461], SPPF framework
defines three type of Route Records: URIType, NAPTRType, and defines three type of Route Records: URIRteRecType, NAPTRType, and
NSType. These Route Records extend the abstract type RteRecType NSType. These Route Records extend the abstract type RteRecType
and inherit the common attribute 'priority' that is meant for and inherit the common attribute 'priority' that is meant for
setting precedence across the route records defined within a Route setting precedence across the route records defined within a Route
Group in a protocol agnostic fashion. Group in a protocol agnostic fashion.
o Organization: o Organization:
An Organization is an entity that may fulfill any combination of An Organization is an entity that may fulfill any combination of
three roles: Registrant, Registrar, and Peering Organization. All three roles: Registrant, Registrar, and Peering Organization. All
objects in SPPF framework are associated with two organization objects in SPPF framework are associated with two organization
identifiers to identify each object's registrant and registrar. A identifiers to identify each object's registrant and registrar. A
skipping to change at page 14, line 39 skipping to change at page 14, line 39
4.7. Near Real Time 4.7. Near Real Time
Many use cases require near real-time responses from the server. Many use cases require near real-time responses from the server.
Therefore, a DRINKS transport protocol MUST support near real-time Therefore, a DRINKS transport protocol MUST support near real-time
response to requests submitted by the client. response to requests submitted by the client.
4.8. Request and Response Sizes 4.8. Request and Response Sizes
Use of SPPF may involve simple updates that may consist of small Use of SPPF may involve simple updates that may consist of small
number of bytes, such as, update of a single public identifier. number of bytes, such as, update of a single public identifier.
Other provisioning operations may constitute large number of datasets Other provisioning operations may constitute large number of dataset
as in adding millions records to a registry. As a result, a suitable as in adding millions records to a registry. As a result, a suitable
transport protocol for SPPF SHOULD accommodate datasets of various transport protocol for SPPF SHOULD accommodate dataset of various
sizes. sizes.
4.9. Request and Response Correlation 4.9. Request and Response Correlation
A transport protocol suitable for SPPF MUST allow responses to be A transport protocol suitable for SPPF MUST allow responses to be
correlated with requests. correlated with requests.
4.10. Request Acknowledgement 4.10. Request Acknowledgement
Data transported in the SPPF is likely crucial for the operation of Data transported in the SPPF is likely crucial for the operation of
skipping to change at page 16, line 42 skipping to change at page 16, line 42
</complexType> </complexType>
The identifiers used for registrants (rant), registrars (rar), and The identifiers used for registrants (rant), registrars (rar), and
peering organizations (peeringOrg) are instances of OrgIdType. The peering organizations (peeringOrg) are instances of OrgIdType. The
OrgIdType is defined as a string and all OrgIdType instances SHOULD OrgIdType is defined as a string and all OrgIdType instances SHOULD
follow the textual convention: "namespace:value" (for example "iana- follow the textual convention: "namespace:value" (for example "iana-
en:32473"). See the IANA Consideration section for more details. en:32473"). See the IANA Consideration section for more details.
5.2. Various Object Key Types 5.2. Various Object Key Types
5.2.1. Generic Object Key Type The SPPF data model contains various object relationships. In some
cases, these object relationships are established by embedding the
The SPPF data model contains some object relationships. In some
cases these object relationships are established by embedding the
unique identity of the related object inside the relating object. In unique identity of the related object inside the relating object. In
addition, an object's unique identity is required to Delete or Get addition, an object's unique identity is required to Delete or Get
the details of an object. The abstract type called ObjKeyType is the details of an object. The following sub-sections normatively
where this unique identity is housed. Because this object key type define the various object keys in SPPF and the attributes of those
is abstract, it MUST be specified in a concrete form in any keys .
conforming SPPF transport protocol specification.
5.2.1. Generic Object Key Type
Most objects in SPPF are uniquely identified by an object key that Most objects in SPPF are uniquely identified by an object key that
has the object's name, object's type and its registrant's has the object's name, object's type and its registrant's
organization ID as its attributes. Consequently, any concrete organization ID as its attributes. The abstract type called
ObjKeyType is where this unique identity is housed. Any concrete
representation of the ObjKeyType MUST contain the following: representation of the ObjKeyType MUST contain the following:
Object Name: The name of the object. Object Name: The name of the object.
Registrant Id: The unique organization ID that identifies the Registrant Id: The unique organization ID that identifies the
Registrant. Registrant.
Type: The enumeration value that represents the type of SPPF Type: The value that represents the type of SPPF object that.
object that. This is required as different types of objects in This is required as different types of objects in SPPF, that
SPPF, that belong to the same registrant, can have the same name. belong to the same registrant, can have the same name.
The structure of abstract ObjKeyType is as follows: The structure of abstract ObjKeyType is as follows:
<complexType name="ObjKeyType" abstract="true"> <complexType name="ObjKeyType" abstract="true">
<annotation> <annotation>
<documentation> <documentation>
---- Generic type that represents the ---- Generic type that represents the
key for various objects in SPPP. ---- key for various objects in SPPF. ----
</documentation> </documentation>
</annotation> </annotation>
</complexType> </complexType>
The object types in SPPF that MUST adhere to this definition of
generic object key are defined as an enumeration in the XML data
structure. The structure of the the enumeration is as follows:
<simpleType name="ObjKeyTypeEnum">
<restriction base="token">
<enumeration value="RteGrp"/>
<enumeration value="DestGrp"/>
<enumeration value="RteRec"/>
<enumeration value="EgrRte"/>
</restriction>
</simpleType>
5.2.2. Derived Object Key Types 5.2.2. Derived Object Key Types
The SPPF data model contains certain objects that are uniquely The SPPF data model contains certain objects that are uniquely
identified by attributes, different from or in addition to, the identified by attributes, different from or in addition to, the
attributes in the generic object key described in previous section. attributes in the generic object key described in previous section.
These kind of object keys are derived from the abstract ObjKeyType These kind of object keys are derived from the abstract ObjKeyType
and defined in there own abstract key types. Because these object and defined in there own abstract key types. Because these object
key types are abstract, these MUST be specified in a concrete form in key types are abstract, these MUST be specified in a concrete form in
any conforming SPPF "transport" specification. These are used in any conforming SPPF "protocol" specification. These are used in
Delete and Get operations, and may also be used in Accept and Reject Delete and Get operations, and may also be used in Accept and Reject
operations. operations.
Following are the derived object keys in SPPF data model: Following are the derived object keys in SPPF data model:
o RteGrpOfferKeyType: This uniquely identifies a Route Group o RteGrpOfferKeyType: This uniquely identifies a Route Group
object offer. This key type extends from ObjKeyType and MUST object offer. This key type extends from ObjKeyType and MUST
also have the organization ID of the Registrant to whom the also have the organization ID of the Registrant to whom the
object is being offered, as one of its attributes. In addition object is being offered, as one of its attributes. In addition
to the Delete and Get operations, these key types are used in to the Delete and Get operations, these key types are used in
skipping to change at page 19, line 35 skipping to change at page 19, line 27
</complexContent> </complexContent>
</complexType> </complexType>
A Public Identity object MUST use attributes of PubIdKeyType for its A Public Identity object MUST use attributes of PubIdKeyType for its
unique identification . Refer the "Framework Data Model Objects" unique identification . Refer the "Framework Data Model Objects"
section of this document for a description of Public Identity object. section of this document for a description of Public Identity object.
5.3. Response Message Types 5.3. Response Message Types
This section contains the listing of response types that MUST be This section contains the listing of response types that MUST be
defined by the conforming "transport" specification and implemented defined by the conforming "protocol" specification and implemented by
by a conforming SPPF server. a conforming SPPF server.
+---------------------+---------------------------------------------+ +---------------------+---------------------------------------------+
| Response Type | Description | | Response Type | Description |
+---------------------+---------------------------------------------+ +---------------------+---------------------------------------------+
| Request Succeeded | Any conforming specification MUST define a | | Request Succeeded | Any conforming specification MUST define a |
| | response to indicate that a given request | | | response to indicate that a given request |
| | succeeded. | | | succeeded. |
| | | | | |
| Request syntax | Any conforming specification MUST define a | | Request syntax | Any conforming specification MUST define a |
| invalid | response to indicate that a syntax of a | | invalid | response to indicate that a syntax of a |
skipping to change at page 22, line 11 skipping to change at page 22, line 11
pre-existing object do not exist. If the data elements used to pre-existing object do not exist. If the data elements used to
uniquely identify an object are malformed, then response type uniquely identify an object are malformed, then response type
"Attribute value invalid" SHOULD be returned. "Attribute value invalid" SHOULD be returned.
6. Framework Data Model Objects 6. Framework Data Model Objects
This section provides a description of the specification of each This section provides a description of the specification of each
supported data model object (the nouns) and identifies the commands supported data model object (the nouns) and identifies the commands
(the verbs) that MUST be supported for each data model object. (the verbs) that MUST be supported for each data model object.
However, the specification of the data structures necessary to However, the specification of the data structures necessary to
support each command is delegated to the "transport" specification. support each command is delegated to the "protocol" specification.
6.1. Destination Group 6.1. Destination Group
As described in the introductory sections, a Destination Group As described in the introductory sections, a Destination Group
represents a set of Public Identifiers with common routing represents a set of Public Identifiers with common routing
information. The transport protocol MUST support the ability to information. The transport protocol MUST support the ability to
Create, Modify, Get, and Delete Destination Groups (refer the Create, Modify, Get, and Delete Destination Groups (refer the
"Framework Operations" section of this document for a generic "Framework Operations" section of this document for a generic
description of various operations). description of various operations).
skipping to change at page 23, line 18 skipping to change at page 23, line 18
6.2. Public Identifier 6.2. Public Identifier
A Public Identifier is the search key used for locating the session A Public Identifier is the search key used for locating the session
establishment data (SED). In many cases, a Public Identifier is establishment data (SED). In many cases, a Public Identifier is
attributed to the end user who has a retail relationship with the attributed to the end user who has a retail relationship with the
service provider or registrant organization. SPPF supports the service provider or registrant organization. SPPF supports the
notion of the carrier-of-record as defined in [RFC5067]. Therefore, notion of the carrier-of-record as defined in [RFC5067]. Therefore,
the registrant under whom the Public Identity is being created can the registrant under whom the Public Identity is being created can
optionally claim to be a carrier-of-record. optionally claim to be a carrier-of-record.
SPPF identifies two types of Public Identifiers: telephone numbers SPPF identifies three types of Public Identifiers: telephone numbers
(TN), and the routing numbers (RN). SPPF provides structures to (TN), routing numbers (RN), and URI type of Public Identifiers (like
manage a single TN, a contiguous range of TNs, and a TN prefix. The an email address). SPPF provides structures to manage a single TN, a
transport protocol MUST support the ability to Create, Modify, Get, contiguous range of TNs, and a TN prefix. The transport protocol
and Delete Public Identifiers (refer the "Framework Operations" MUST support the ability to Create, Modify, Get, and Delete Public
section of this document for a generic description of various Identifiers (refer the "Framework Operations" section of this
operations). document for a generic description of various operations).
A Public Identity object MUST be uniquely identified by attributes as A Public Identity object MUST be uniquely identified by attributes as
defined in the description of "PubIdKeyType" in the section "Derived defined in the description of "PubIdKeyType" in the section "Derived
Object Key Types" of this document. Object Key Types" of this document.
The abstract XML schema type definition PubIDType is a generalization The abstract XML schema type definition PubIDType is a generalization
for the concrete the Public Identifier schema types. PubIDType for the concrete Public Identifier schema types. PubIDType element
element 'dgName' represents the name of the destination group that a 'dgName' represents the name of the destination group that a given
given Public Identifier MAY be a member of. The PubIDType object Public Identifier MAY be a member of. The PubIDType object structure
structure is defined as follows: is defined as follows:
<complexType name="PubIdType" abstract="true"> <complexType name="PubIdType" abstract="true">
<complexContent> <complexContent>
<extension base="sppfb:BasicObjType"> <extension base="sppfb:BasicObjType">
<sequence> <sequence>
<element name="dgName" type="sppfb:ObjNameType" <element name="dgName" type="sppfb:ObjNameType"
minOccurs="0"/> minOccurs="0"/>
</sequence> </sequence>
</extension> </extension>
</complexContent> </complexContent>
skipping to change at page 25, line 4 skipping to change at page 25, line 4
</restriction> </restriction>
</simpleType> </simpleType>
TNType consists of the following attributes: TNType consists of the following attributes:
o tn: Telephone number to be added to the registry. o tn: Telephone number to be added to the registry.
o rrRef: Optional reference to route records that are directly o rrRef: Optional reference to route records that are directly
associated with the TN Public Identifier. Following the SPPF associated with the TN Public Identifier. Following the SPPF
data model, the route record could be a protocol agnostic data model, the route record could be a protocol agnostic
URIType or another type. URIRteRecType or another type.
o corInfo: corInfo is an optional parameter of type CORInfoType o corInfo: corInfo is an optional parameter of type CORInfoType
that allows the registrant organization to set forth a claim to that allows the registrant organization to set forth a claim to
be the carrier-of-record (see [RFC5067]). This is done by be the carrier-of-record (see [RFC5067]). This is done by
setting the value of <corClaim> element of the CORInfoType setting the value of <corClaim> element of the CORInfoType
object structure to "true". The other two parameters of the object structure to "true". The other two parameters of the
CORInfoType, <cor> and <corDate> are set by the registry to CORInfoType, <cor> and <corDate> are set by the registry to
describe the outcome of the carrier-of-record claim by the describe the outcome of the carrier-of-record claim by the
registrant. In general, inclusion of <corInfo> parameter is registrant. In general, inclusion of <corInfo> parameter is
useful if the registry has the authority information, such as, useful if the registry has the authority information, such as,
skipping to change at page 27, line 33 skipping to change at page 27, line 33
</extension> </extension>
</complexContent> </complexContent>
</complexType> </complexType>
TNPType consists of the following attributes: TNPType consists of the following attributes:
o tnPrefix: The telephone number prefix o tnPrefix: The telephone number prefix
o corInfo: Optional <corInfo> element of type CORInfoType. o corInfo: Optional <corInfo> element of type CORInfoType.
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 the unique key of its parent Destination Group (dgName
and rantId). URIPubIdType is defined as follows:
<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:
o uri: The value that acts a Public Identifier.
o ext: Point of extensibility.
6.3. Route Group 6.3. Route Group
As described in the introductory sections, a Route Group represents a As described in the introductory sections, a Route Group represents a
combined grouping of Route Records that define route information, combined grouping of Route Records that define route information,
Destination Groups that contain a set of Public Identifiers with Destination Groups that contain a set of Public Identifiers with
common routing information, and the list of peer organizations that common routing information, and the list of peer organizations that
have access to these public identifiers using this route information. have access to these public identifiers using this route information.
It is this indirect linking of public identifiers to their route It is this indirect linking of public identifiers to their route
information that significantly improves the scalability and information that significantly improves the scalability and
manageability of the peering data. Additions and changes to routing manageability of the peering data. Additions and changes to routing
skipping to change at page 32, line 9 skipping to change at page 32, line 37
MUST support the ability to Create, Modify, Get, and Delete Route MUST support the ability to Create, Modify, Get, and Delete Route
Records (refer the "Framework Operations" section of this document Records (refer the "Framework Operations" section of this document
for a generic description of various operations). for a generic description of various operations).
A Route Record object MUST be uniquely identified by attributes as A Route Record object MUST be uniquely identified by attributes as
defined in the description of "ObjKeyType" in the section "Generic defined in the description of "ObjKeyType" in the section "Generic
Object Key Type" of this document. Object Key Type" of this document.
The RteRecType object structure is defined as follows: The RteRecType object structure is defined as follows:
<complexType name="RteRecType" abstract="true"> <complexType name="RteRecType" abstract="true">
<complexContent> <complexContent>
<extension base="sppfb:BasicObjType"> <extension base="sppfb:BasicObjType">
<sequence> <sequence>
<element name="rrName" type="sppfb:ObjNameType"/> <element name="rrName"
<element name="priority" type="unsignedShort" type="sppfb:ObjNameType"/>
<element name="isInSvc" type="boolean"/>
<element name="ttl" type="positiveInteger"
minOccurs="0"/> minOccurs="0"/>
</sequence> </sequence>
</extension> </extension>
</complexContent> </complexContent>
</complexType> </complexType>
The RteRecType object is composed of the following elements: The RteRecType object is composed of the following elements:
o base: All first class objects extend BasicObjType that contains o base: All first class objects extend BasicObjType that contains
the ID of the registrant organization that owns this object, the the ID of the registrant organization that owns this object, the
date and time that the object was created by the server, and the date and time that the object was created by the server, and the
date and time that the object was last modified. If the client date and time that the object was last modified. If the client
passes in either the created date or the modification date, the passes in either the created date or the modification date, the
server will ignore them. The server sets these two date/time server will ignore them. The server sets these two date/time
values. values.
o rrName: The character string that contains the name of the Route o rrName: The character string that contains the name of the Route
Record. It uniquely identifies this object within the context Record. It uniquely identifies this object within the context
of the registrant ID (a child element of the base element as of the registrant ID (a child element of the base element as
described above). described above).
o priority: Zero or one priority value that can be used to provide o isInSvc: A boolean element that defines whether this Route
a relative value weighting of one Route Record over another. Record is in service or not. The routing information contained
The manner in which this value is used, perhaps in conjunction in a Route Record which is in service is a candidate for
with other factors, is a matter of policy. inclusion in resolution responses for Telephone Numbers that are
either directly associated to this Route Record, or for Public
Identities residing in a Destination Group that is associated to
a Route Group which in turn has an association to this Route
Record.
o ttl: Number of seconds that an addressing server may cache a
particular Route Record.
As described above, route records are based on an abstract type: As described above, route records are based on an abstract type:
RteRecType. The concrete types that use RteRecType as an extension RteRecType. The concrete types that use RteRecType as an extension
base are NAPTRType, NSType, and URIType. The definitions of these base are NAPTRType, NSType, and URIType. The definitions of these
types are included below. The NAPTRType object is comprised of the types are included below. The NAPTRType object is comprised of the
data elements necessary for a NAPTR that contains routing information data elements necessary for a NAPTR that contains routing information
for a Route Group. The NSType object is comprised of the data for a Route Group. The NSType object is comprised of the data
elements necessary for a DNS name server that points to another DNS elements necessary for a DNS name server that points to another DNS
server that contains the desired routing information. The NSType is server that contains the desired routing information. The NSType is
relevant only when the resolution protocol is ENUM. The URIType relevant only when the resolution protocol is ENUM. The
object is comprised of the data elements necessary to house a URI. URIRteRecType object is comprised of the data elements necessary to
house a URI.
The data provisioned in a registry can be leveraged for many purposes The data provisioned in a registry can be leveraged for many purposes
and queried using various protocols including SIP, ENUM and others. and queried using various protocols including SIP, ENUM and others.
It is for this reason that a route record type offers a choice of URI It is for this reason that a route record type offers a choice of URI
and DNS resource record types. URIType fulfills the need for both and DNS resource record types. URIRteRecType fulfills the need for
SIP and ENUM protocols. When a given URIType is associated to a both SIP and ENUM protocols. When a given URIRteRecType is
destination group, the user part of the replacement string <uri> that associated to a destination group, the user part of the replacement
may require the Public Identifier cannot be preset. As a SIP string <uri> that may require the Public Identifier cannot be preset.
Redirect, the resolution server will apply <ere> pattern on the input As a SIP Redirect, the resolution server will apply <ere> pattern on
Public Identifier in the query and process the replacement string by the input Public Identifier in the query and process the replacement
substituting any back reference(s) in the <uri> to arrive at the string by substituting any back reference(s) in the <uri> to arrive
final URI that is returned in the SIP Contact header. For an ENUM at the final URI that is returned in the SIP Contact header. For an
query, the resolution server will simply return the value of the ENUM query, the resolution server will simply return the value of the
<ere> and <uri> members of the URIType in the NAPTR REGEX parameter. <ere> and <uri> members of the URIRteRecType in the NAPTR REGEX
parameter.
<complexType name="NAPTRType"> <complexType name="NAPTRType">
<complexContent> <complexContent>
<extension base="sppfb:RteRecType"> <extension base="sppfb:RteRecType">
<sequence> <sequence>
<element name="order" type="unsignedShort"/> <element name="order" type="unsignedShort"/>
<element name="flags" type="sppfb:FlagsType" <element name="flags" type="sppfb:FlagsType"
minOccurs="0"/> minOccurs="0"/>
<element name="svcs" type="sppfb:SvcType"/> <element name="svcs" type="sppfb:SvcType"/>
<element name="regx" type="sppfb:RegexParamType" <element name="regx" type="sppfb:RegexParamType"
minOccurs="0"/> minOccurs="0"/>
<element name="repl" type="sppfb:ReplType" <element name="repl" type="sppfb:ReplType"
minOccurs="0"/> minOccurs="0"/>
<element name="ttl" type="positiveInteger"
minOccurs="0"/>
<element name="ext" type="sppfb:ExtAnyType" <element name="ext" type="sppfb:ExtAnyType"
minOccurs="0"/> minOccurs="0"/>
</sequence> </sequence>
</extension> </extension>
</complexContent> </complexContent>
</complexType> </complexType>
<complexType name="NSType"> <complexType name="NSType">
<complexContent> <complexContent>
<extension base="sppfb:RteRecType"> <extension base="sppfb:RteRecType">
<sequence> <sequence>
<element name="hostName" type="token"/> <element name="hostName" type="token"/>
<element name="ipAddr" type="sppfb:IPAddrType" <element name="ipAddr" type="sppfb:IPAddrType"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
<element name="ttl" type="positiveInteger"
minOccurs="0"/>
<element name="ext" type="sppfb:ExtAnyType" <element name="ext" type="sppfb:ExtAnyType"
minOccurs="0"/> minOccurs="0"/>
</sequence> </sequence>
</extension> </extension>
</complexContent> </complexContent>
</complexType> </complexType>
<complexType name="IPAddrType"> <complexType name="IPAddrType">
<sequence> <sequence>
<element name="addr" type="sppfb:AddrStringType"/> <element name="addr" type="sppfb:AddrStringType"/>
<element name="ext" type="sppfb:ExtAnyType" <element name="ext" type="sppfb:ExtAnyType"
minOccurs="0"/> minOccurs="0"/>
</sequence> </sequence>
skipping to change at page 34, line 18 skipping to change at page 35, line 4
<complexType name="IPAddrType"> <complexType name="IPAddrType">
<sequence> <sequence>
<element name="addr" type="sppfb:AddrStringType"/> <element name="addr" type="sppfb:AddrStringType"/>
<element name="ext" type="sppfb:ExtAnyType" <element name="ext" type="sppfb:ExtAnyType"
minOccurs="0"/> minOccurs="0"/>
</sequence> </sequence>
<attribute name="type" type="sppfb:IPType" <attribute name="type" type="sppfb:IPType"
default="v4"/> default="v4"/>
</complexType> </complexType>
<simpleType name="IPType"> <simpleType name="IPType">
<restriction base="token"> <restriction base="token">
<enumeration value="IPv4"/> <enumeration value="IPv4"/>
<enumeration value="IPv6"/> <enumeration value="IPv6"/>
</restriction> </restriction>
</simpleType> </simpleType>
<complexType name="URIType"> <complexType name="URIRteRecType">
<complexContent> <complexContent>
<extension base="sppfb:RteRecType"> <extension base="sppfb:RteRecType">
<sequence> <sequence>
<element name="ere" type="token" <element name="ere" type="token"
default="^(.*)$"/> default="^(.*)$"/>
<element name="uri" type="anyURI"/> <element name="uri" type="anyURI"/>
<element name="ext" type="sppfb:ExtAnyType" <element name="ext" type="sppfb:ExtAnyType"
minOccurs="0"/> minOccurs="0"/>
</sequence> </sequence>
</extension> </extension>
skipping to change at page 35, line 16 skipping to change at page 35, line 48
value must be of the form specified in [RFC6116] (e.g., E2U+ value must be of the form specified in [RFC6116] (e.g., E2U+
pstn:sip+sip). The allowable values are a matter of policy and pstn:sip+sip). The allowable values are a matter of policy and
not limited by this protocol. not limited by this protocol.
o regx: NAPTR's regular expression field. If this is not included o regx: NAPTR's regular expression field. If this is not included
then the Repl field must be included. then the Repl field must be included.
o repl: NAPTR replacement field, should only be provided if the o repl: NAPTR replacement field, should only be provided if the
Regex field is not provided, otherwise the server will ignore it Regex field is not provided, otherwise the server will ignore it
o ttl: Number of seconds that an addressing server may cache this
NAPTR.
o ext: Point of extensibility described in a previous section of o ext: Point of extensibility described in a previous section of
this document. this document.
The NSType object is composed of the following elements: The NSType object is composed of the following elements:
o hostName: Fully qualified host name of the name server. o hostName: Fully qualified host name of the name server.
o ipAddr: Zero or more objects of type IpAddrType. Each object o ipAddr: Zero or more objects of type IpAddrType. Each object
holds an IP Address and the IP Address type, IPv4 or IP v6. holds an IP Address and the IP Address type, IPv4 or IP v6.
o ttl: Number of seconds that an addressing server may cache this
DNS name server.
o ext: Point of extensibility described in a previous section of o ext: Point of extensibility described in a previous section of
this document. this document.
The URIType object is composed of the following elements: The URIRteRecType object is composed of the following elements:
o ere: The POSIX Extended Regular Expression (ere) as defined in o ere: The POSIX Extended Regular Expression (ere) as defined in
[RFC3986]. [RFC3986].
o uri: the URI as defined in [RFC3986]. In some cases, this will 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 serve as the replacement string and it will be left to the
resolution server to arrive at the final usable URI. resolution server to arrive at the final usable URI.
6.5. Route Group Offer 6.5. Route Group Offer
skipping to change at page 40, line 9 skipping to change at page 40, line 9
o ingrRteRec: The ingress route records that the egress route o ingrRteRec: The ingress route records that the egress route
should be used for. should be used for.
o ext: Point of extensibility described in a previous section of o ext: Point of extensibility described in a previous section of
this document. this document.
7. Framework Operations 7. Framework Operations
7.1. Add Operation 7.1. Add Operation
Any conforming "transport" specification MUST provide a definition Any conforming "protocol" specification MUST provide a definition for
for the operation that adds one or more SPPF objects into the the operation that adds one or more SPPF objects into the registry.
registry. If the object, as identified by the request attributes If the object, as identified by the request attributes that form part
that form part of the object's key, does not exist, then the registry of the object's key, does not exist, then the registry MUST create
MUST create the object. If the object does exist, then the registry the object. If the object does exist, then the registry MUST replace
MUST replace the current properties of the object with the properties the current properties of the object with the properties passed in as
passed in as part of the Add operation. part of the Add operation.
If the entity that issued the command is not authorized to perform If the entity that issued the command is not authorized to perform
this operation an appropriate error message MUST be returned from this operation an appropriate error message MUST be returned from
amongst the response messages defined in "Response Message Types" amongst the response messages defined in "Response Message Types"
section of the document. section of the document.
7.2. Delete Operation 7.2. Delete Operation
Any conforming "transport" specification MUST provide a definition Any conforming "protocol" specification MUST provide a definition for
for the operation that deletes one or more SPPF objects from the the operation that deletes one or more SPPF objects from the registry
registry using the object's key. using the object's key.
If the entity that issued the command is not authorized to perform If the entity that issued the command is not authorized to perform
this operation an appropriate error message MUST be returned from this operation an appropriate error message MUST be returned from
amongst the response messages defined in "Response Message Types" amongst the response messages defined in "Response Message Types"
section of the document. section of the document.
When an object is deleted, any references to that object must of When an object is deleted, any references to that object must of
course also be removed as the SPPF server implementation fulfills the course also be removed as the SPPF server implementation fulfills the
deletion request. Furthermore, the deletion of a composite object deletion request. Furthermore, the deletion of a composite object
must also result in the deletion of the objects it contains. As a must also result in the deletion of the objects it contains. As a
skipping to change at page 41, line 30 skipping to change at page 41, line 30
request. request.
7.3. Get Operations 7.3. Get Operations
At times, on behalf of the registrant, the registrar may need to have At times, on behalf of the registrant, the registrar may need to have
access to SPPF objects that were previously provisioned in the access to SPPF objects that were previously provisioned in the
registry. A few examples include logging, auditing, and pre- registry. A few examples include logging, auditing, and pre-
provisioning dependency checking. This query mechanism is limited to provisioning dependency checking. This query mechanism is limited to
aid provisioning scenarios and should not be confused with query aid provisioning scenarios and should not be confused with query
protocols provided as part of the resolution system (e.g. ENUM and protocols provided as part of the resolution system (e.g. ENUM and
SIP). Any conforming "transport" specification MUST provide a SIP). Any conforming "protocol" specification MUST provide a
definition for the operation that queries the details of one or more 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 SPPF objects from the registry using the object's key. If the entity
that issued the command is not authorized to perform this operation that issued the command is not authorized to perform this operation
an appropriate error message MUST be returned from amongst the an appropriate error message MUST be returned from amongst the
response messages defined in "Response Message Types" section of the response messages defined in "Response Message Types" section of the
document. document.
7.4. Accept Operations 7.4. Accept Operations
In SPPF, a Route Group Offer can be accepted or rejected by, or on In SPPF, a Route Group Offer can be accepted or rejected by, or on
behalf of, the registrant to whom the Route Group has been offered behalf of, the registrant to whom the Route Group has been offered
(refer "Framework Data Model Objects" section of this document for a (refer "Framework Data Model Objects" section of this document for a
description of the Route Group Offer object). The Accept operation description of the Route Group Offer object). The Accept operation
is used to accept the Route Group Offers. Any conforming "transport" is used to accept the Route Group Offers. Any conforming "protocol"
specification MUST provide a definition for the operation to accept specification MUST provide a definition for the operation to accept
Route Group Offers by, or on behalf of the Registrant, using the Route Group Offers by, or on behalf of the Registrant, using the
Route Group Offer object key. Route Group Offer object key.
Not until access to a Route Group has been offered and accepted will Not until access to a Route Group has been offered and accepted will
the registrant's organization ID be included in the peeringOrg list the registrant's organization ID be included in the peeringOrg list
in that Route Group object, and that Route Group's peering in that Route Group object, and that Route Group's peering
information become a candidate for inclusion in the responses to the information become a candidate for inclusion in the responses to the
resolution requests submitted by that registrant. A Route Group resolution requests submitted by that registrant. A Route Group
Offer that is in the "offered" status is accepted by, or on behalf Offer that is in the "offered" status is accepted by, or on behalf
skipping to change at page 42, line 28 skipping to change at page 42, line 28
In SPPF, a Route Group Offer object can be accepted or rejected by, In SPPF, a Route Group Offer object can be accepted or rejected by,
or on behalf of, the registrant to whom the Route Group has been or on behalf of, the registrant to whom the Route Group has been
offered (refer "Framework Data Model Objects" section of this offered (refer "Framework Data Model Objects" section of this
document for a description of the Route Group Offer object). document for a description of the Route Group Offer object).
Furthermore, that offer may be rejected, regardless of whether or not Furthermore, that offer may be rejected, regardless of whether or not
it has been previously accepted. The Reject operation is used to it has been previously accepted. The Reject operation is used to
reject the Route Group Offers. When the Route Group Offer is reject the Route Group Offers. When the Route Group Offer is
rejected that Route Group Offer is deleted, and, if appropriate, the rejected that Route Group Offer is deleted, and, if appropriate, the
data recipient's organization ID is removed from the list of data recipient's organization ID is removed from the list of
peeringOrg IDs for that Route Group. Any conforming "transport" peeringOrg IDs for that Route Group. Any conforming "protocol"
specification MUST provide a definition for the operation to reject specification MUST provide a definition for the operation to reject
Route Group Offers by, or on behalf of the Registrant, using the Route Group Offers by, or on behalf of the Registrant, using the
Route Group Offer object key. Route Group Offer object key.
If the entity that issued the command is not authorized to perform If the entity that issued the command is not authorized to perform
this operation an appropriate error message MUST be returned from this operation an appropriate error message MUST be returned from
amongst the response messages defined in "Response Message Types" amongst the response messages defined in "Response Message Types"
section of the document. section of the document.
7.6. Get Server Details Operation 7.6. Get Server Details Operation
In SPPF, Get Server Details operation can be used to request certain In SPPF, Get Server Details operation can be used to request certain
details about the SPPF server that include the SPPF server's current details about the SPPF server that include the SPPF server's current
status, the major/minor version of the SPPF protocol supported by the status, the major/minor version of the SPPF protocol supported by the
SPPF server. SPPF server.
Any conforming "transport" specification MUST provide a definition Any conforming "protocol" specification MUST provide a definition for
for the operation to request such details from the SPPF server. If the operation to request such details from the SPPF server. If the
the entity that issued the command is not authorized to perform this entity that issued the command is not authorized to perform this
operation an appropriate error message MUST be returned from amongst operation an appropriate error message MUST be returned from amongst
the response messages defined in "Response Message Types" section of the response messages defined in "Response Message Types" section of
the document. the document.
8. XML Considerations 8. XML Considerations
XML serves as the encoding format for SPPF, allowing complex XML serves as the encoding format for SPPF, allowing complex
hierarchical data to be expressed in a text format that can be read, hierarchical data to be expressed in a text format that can be read,
saved, and manipulated with both traditional text tools and tools saved, and manipulated with both traditional text tools and tools
specific to XML. specific to XML.
XML is case sensitive. Unless stated otherwise, XML specifications XML is case sensitive. Unless stated otherwise, XML specifications
and examples provided in this document MUST be interpreted in the and examples provided in this document MUST be interpreted in the
character case presented to develop a conforming implementation. character case presented to develop a conforming implementation.
This section discusses a small number of XML-related considerations This section discusses a small number of XML-related considerations
pertaining to SPPP. pertaining to SPPF.
8.1. Namespaces 8.1. Namespaces
All SPPF elements are defined in the namespaces in the IANA All SPPF elements are defined in the namespaces in the IANA
Considerations section and in the Formal Framework Specification Considerations section and in the Formal Framework Specification
section of this document. section of this document.
8.2. Versioning and Character Encoding 8.2. Versioning and Character Encoding
All XML instances SHOULD begin with an <?xml?> declaration to All XML instances SHOULD begin with an <?xml?> declaration to
identify the version of XML that is being used, optionally identify identify the version of XML that is being used, optionally identify
use of the character encoding used, and optionally provide a hint to 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 an XML parser that an external schema file is needed to validate the
XML instance. XML instance.
Conformant XML parsers recognize both UTF-8 (defined in [RFC3629]) Conformant XML parsers recognize both UTF-8 (defined in [RFC3629])
and UTF-16 (defined in [RFC2781]); per [RFC2277] UTF-8 is the and UTF-16 (defined in [RFC2781]); per [RFC2277] UTF-8 is the
RECOMMENDED character encoding for use with SPPP. RECOMMENDED character encoding for use with SPPF.
Character encodings other than UTF-8 and UTF-16 are allowed by XML. 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 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" "encoding" attribute or a byte order mark (BOM); thus, the "encoding"
attribute in the XML declaration is OPTIONAL if UTF-8 encoding is 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, used. SPPF clients and servers MUST accept a UTF-8 BOM if present,
though emitting a UTF-8 BOM is NOT RECOMMENDED. though emitting a UTF-8 BOM is NOT RECOMMENDED.
Example XML declarations: Example XML declarations:
skipping to change at page 44, line 27 skipping to change at page 44, line 27
integrity protection. Refer to that section and the resulting integrity protection. Refer to that section and the resulting
transport protocol specification document for the specific solutions transport protocol specification document for the specific solutions
to authentication and confidentiality. to authentication and confidentiality.
With respect to authorization, the SPPF server implementation must With respect to authorization, the SPPF server implementation must
define and implement a set of authorization rules that precisely define and implement a set of authorization rules that precisely
address (1) which registrars will be authorized to create/modify/ address (1) which registrars will be authorized to create/modify/
delete each SPPF object type for given registrant(s) and (2) which delete each SPPF object type for given registrant(s) and (2) which
registrars will be authorized to view/get each SPPF object type for registrars will be authorized to view/get each SPPF object type for
given registrant(s). These authorization rules are a matter of given registrant(s). These authorization rules are a matter of
policy and are not specified within the context of SPPP. However, policy and are not specified within the context of SPPF. However,
any SPPF implementation must specify these authorization rules in any SPPF implementation must specify these authorization rules in
order to function in a reliable and safe manner. order to function in a reliable and safe manner.
In some situations, it may be required to protect against denial of In some situations, it may be required to protect against denial of
involvement (see [RFC4949]) and tackle non-repudiation concerns in involvement (see [RFC4949]) and tackle non-repudiation concerns in
regards to SPPF messages. This type of protection is useful to regards to SPPF messages. This type of protection is useful to
satisfy authenticity concerns related to SPPF messages beyond the satisfy authenticity concerns related to SPPF messages beyond the
end-to-end connection integrity, confidentiality, and authentication end-to-end connection integrity, confidentiality, and authentication
protection that the transport layer provides. This is an optional protection that the transport layer provides. This is an optional
feature and some SPPF implementations MAY provide support for it. feature and some SPPF implementations MAY provide support for it.
skipping to change at page 47, line 32 skipping to change at page 47, line 32
specific architecture to specific architecture to
define the Object Identifiers ---- define the Object Identifiers ----
</documentation> </documentation>
</annotation> </annotation>
<complexType name="ObjKeyType" <complexType name="ObjKeyType"
abstract="true"> abstract="true">
<annotation> <annotation>
<documentation> <documentation>
---- Generic type that ---- Generic type that
represents the key for various represents the key for various
objects in SPPP. ---- objects in SPPF. ----
</documentation> </documentation>
</annotation> </annotation>
</complexType> </complexType>
<complexType name="RteGrpOfferKeyType" abstract="true"> <complexType name="RteGrpOfferKeyType" abstract="true">
<complexContent> <complexContent>
<extension base="sppfb:ObjKeyType"> <extension base="sppfb:ObjKeyType">
<annotation> <annotation>
<documentation> <documentation>
---- Generic type ---- Generic type
that represents that represents
the key for a route the key for a route
group offer. ---- group offer. ----
</documentation> </documentation>
skipping to change at page 50, line 21 skipping to change at page 50, line 23
<extension base="sppfb:PubIdType"> <extension base="sppfb:PubIdType">
<sequence> <sequence>
<element name="rn" <element name="rn"
type="sppfb:NumberValType"/> type="sppfb:NumberValType"/>
<element name="corInfo" <element name="corInfo"
type="sppfb:CORInfoType" minOccurs="0"/> type="sppfb:CORInfoType" minOccurs="0"/>
</sequence> </sequence>
</extension> </extension>
</complexContent> </complexContent>
</complexType> </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="RteRecType" abstract="true"> <complexType name="RteRecType" abstract="true">
<complexContent> <complexContent>
<extension base="sppfb:BasicObjType"> <extension base="sppfb:BasicObjType">
<sequence> <sequence>
<element name="rrName" <element name="rrName"
type="sppfb:ObjNameType"/> type="sppfb:ObjNameType"/>
<element name="priority" <element name="isInSvc" type="boolean"/>
type="unsignedShort" minOccurs="0"/> <element name="ttl" type="positiveInteger"
minOccurs="0"/>
</sequence> </sequence>
</extension> </extension>
</complexContent> </complexContent>
</complexType> </complexType>
<complexType name="NAPTRType"> <complexType name="NAPTRType">
<complexContent> <complexContent>
<extension base="sppfb:RteRecType"> <extension base="sppfb:RteRecType">
<sequence> <sequence>
<element name="order" type="unsignedShort"/> <element name="order" type="unsignedShort"/>
<element name="flags" type="sppfb:FlagsType" minOccurs="0"/> <element name="flags" type="sppfb:FlagsType" minOccurs="0"/>
<element name="svcs" type="sppfb:SvcType"/> <element name="svcs" type="sppfb:SvcType"/>
<element name="regx" type="sppfb:RegexParamType" minOccurs="0"/> <element name="regx" type="sppfb:RegexParamType" minOccurs="0"/>
<element name="repl" type="sppfb:ReplType" minOccurs="0"/> <element name="repl" type="sppfb:ReplType" minOccurs="0"/>
<element name="ttl" type="positiveInteger" minOccurs="0"/>
<element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/> <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
</sequence> </sequence>
</extension> </extension>
</complexContent> </complexContent>
</complexType> </complexType>
<complexType name="NSType"> <complexType name="NSType">
<complexContent> <complexContent>
<extension base="sppfb:RteRecType"> <extension base="sppfb:RteRecType">
<sequence> <sequence>
<element name="hostName" type="token"/> <element name="hostName" type="token"/>
<element name="ipAddr" type="sppfb:IPAddrType" <element name="ipAddr" type="sppfb:IPAddrType"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
<element name="ttl" type="positiveInteger" minOccurs="0"/>
<element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/> <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
</sequence> </sequence>
</extension> </extension>
</complexContent> </complexContent>
</complexType> </complexType>
<complexType name="URIType"> <complexType name="URIRteRecType">
<complexContent> <complexContent>
<extension base="sppfb:RteRecType"> <extension base="sppfb:RteRecType">
<sequence> <sequence>
<element name="ere" type="token" default="^(.*)$"/> <element name="ere" type="token" default="^(.*)$"/>
<element name="uri" type="anyURI"/> <element name="uri" type="anyURI"/>
<element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/> <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
</sequence> </sequence>
</extension> </extension>
</complexContent> </complexContent>
</complexType> </complexType>
skipping to change at page 55, line 20 skipping to change at page 55, line 33
<element name="value" type="sppfb:NumberValType"/> <element name="value" type="sppfb:NumberValType"/>
<element name="type" type="sppfb:NumberTypeEnum"/> <element name="type" type="sppfb:NumberTypeEnum"/>
</sequence> </sequence>
</complexType> </complexType>
<complexType name="NumberRangeType"> <complexType name="NumberRangeType">
<sequence> <sequence>
<element name="startRange" type="sppfb:NumberValType"/> <element name="startRange" type="sppfb:NumberValType"/>
<element name="endRange" type="sppfb:NumberValType"/> <element name="endRange" type="sppfb:NumberValType"/>
</sequence> </sequence>
</complexType> </complexType>
<simpleType name="ObjKeyTypeEnum">
<restriction base="token">
<enumeration value="RteGrp"/>
<enumeration value="DestGrp"/>
<enumeration value="RteRec"/>
<enumeration value="EgrRte"/>
</restriction>
</simpleType>
</schema> </schema>
12. Acknowledgments 12. Acknowledgments
This document is a result of various discussions held in the DRINKS This document is a result of various discussions held in the DRINKS
working group and within the DRINKS protocol design team, which is working group and within the DRINKS protocol design team, which is
comprised of the following individuals, in alphabetical order: comprised of the following individuals, in alphabetical order:
Alexander Mayrhofer, David Schwartz, Deborah A Guyton, Lisa Alexander Mayrhofer, David Schwartz, Deborah A Guyton, Lisa
Dusseault, Manjul Maharishi, Mickael Marrache, Otmar Lendl, Richard Dusseault, Manjul Maharishi, Mickael Marrache, Otmar Lendl, Richard
Shockey, Samuel Melloul, and Sumanth Channabasappa. Shockey, Samuel Melloul, and Sumanth Channabasappa.
 End of changes. 61 change blocks. 
181 lines changed or deleted 198 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/