RFC 7877
Session Peering Provisioning Framework (SPPF)
Pages: 57
Proposed Standard
Proposed Standard
Part 1 of 3 – Pages 1 to 18
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)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. 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. 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.
Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. 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.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
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 . . . . . . . . . . . . . . . . . . . . . . . 571. Introduction
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]. 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). 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). *--------* *------------* *------------* | | (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 A "terminating" SSP provisions SED into the Registry to be selectively shared with other peer SSPs. 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. 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:
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.
2. A resolution system returns an LRF that comprises the location
(address) of the Signaling Function in the target domain (as
described in [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.
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.
This document is organized as follows:
o Section 2 provides the terminology
o Section 3 provides an overview of SPPF, including functional
entities and a data model
o Section 4 specifies requirements for SPPF substrate protocols
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 Section 6 provides a detailed description of the data model object
specifications
o Section 7 describes the operations that are supported by the data model o Section 8 defines XML considerations XML parsers must meet to conform to this specification o Sections 9 - 11 discuss security, internationalization, and IANA considerations, respectively o Section 12 normatively defines the SPPF using its XSD.2. Terminology
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]. This document reuses terms from [RFC3261], [RFC5486], use cases and requirements documented in [RFC6461], and the ENUM Validation Architecture [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. Client: In the context of SPPF, this is an application that initiates a provisioning request. It is sometimes referred to as a "Registry client". Server: In the context of SPPF, this is an application that receives a provisioning request and responds accordingly. Registry: The Registry operates a master database of SED for one or more Registrants. 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. Within the confines of a Registry, a Registrant is uniquely identified by the "rant" element.
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. Peering Organization: A peering organization is an entity to which a Registrant's SED Groups are made visible using the operations of SPPF.3. Framework High-Level Design
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.3.1. Framework Data Model
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 The logical structure presented below is consistent with the terminology and requirements defined in [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 Figure 2: Framework Data Model
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.
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).
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.
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 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 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.
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
common attribute "priority" that is meant for setting precedence
across the SED Records defined within a SED Group in a protocol-
agnostic fashion.
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 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.
3.2. Time Value
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.
"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.
3.3. Extensibility
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.
4. Substrate Protocol Requirements
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.4.1. Mandatory Substrate
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. 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.4.2. Connection Oriented
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.4.3. Request and Response Model
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. Therefore, a substrate protocol for SPPF will follow the request- response model by ensuring a response is sent to the request initiator.4.4. Connection Lifetime
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.4.5. Authentication
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.4.6. Authorization
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.4.7. Confidentiality and Integrity
SPPF objects that the Registry manages can be private in nature. Therefore, the substrate protocol MUST provide means for data integrity protection. 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.4.8. Near Real Time
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.4.9. Request and Response Sizes
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.
4.10. Request and Response Correlation
A substrate protocol suitable for SPPF MUST allow responses to be correlated with requests.4.11. Request Acknowledgement
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. 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. 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.5. Base Framework Data Structures and Response Codes
SPPF contains some common data structures for most of the supported object types. This section describes these common data structures.5.1. Basic Object Type and Organization Identifiers
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. <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: Strings used as OrgIdType Namespace identifiers MUST conform to the following syntax in the Augmented Backus-Naur Form (ABNF) [RFC5234]. namespace = ALPHA *(ALPHA/DIGIT/"-") See Section 11 for the corresponding IANA registry definition.5.2. Various Object Key Types
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. "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.5.2.1. Generic Object Key Type
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: Object Name: The name of the object. Registrant ID: The unique organization ID that identifies the Registrant. 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.
The structure of abstract ObjKeyType is as follows:
<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
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.
Following are the derived object keys in an SPPF data model:
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:
<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.
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:
* Registrant ID: The unique organization ID that identifies the
Registrant.
* 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.
o The structure of abstract PubIdKeyType is as follows:
<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.
5.3. Response Message Types
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.
+---------------------+---------------------------------------------+ | 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
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 The value for Attribute Value MUST be the value of the data
element to which the preceding Attribute Name refers.
o Response type "Attribute value invalid" MUST be used whenever an
element value does not adhere to data validation rules.
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.
(page 18 continued on part 2)