tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 7877

Proposed STD
Pages: 57
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: DRINKS

Session Peering Provisioning Framework (SPPF)

Part 1 of 3, p. 1 to 18
None       Next Section

 


Top       ToC       Page 1 
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.

[Page 2] 
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

Top      ToC       Page 3 
   7.  Framework Operations  . . . . . . . . . . . . . . . . . . . .  36
     7.1.  Add Operation . . . . . . . . . . . . . . . . . . . . . .  37
     7.2.  Delete Operation  . . . . . . . . . . . . . . . . . . . .  37
     7.3.  Get Operations  . . . . . . . . . . . . . . . . . . . . .  38
     7.4.  Accept Operations . . . . . . . . . . . . . . . . . . . .  38
     7.5.  Reject Operations . . . . . . . . . . . . . . . . . . . .  39
     7.6.  Get Server Details Operation  . . . . . . . . . . . . . .  39
   8.  XML Considerations  . . . . . . . . . . . . . . . . . . . . .  40
     8.1.  Namespaces  . . . . . . . . . . . . . . . . . . . . . . .  40
     8.2.  Versioning and Character Encoding . . . . . . . . . . . .  40
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  41
     9.1.  Confidentiality and Authentication  . . . . . . . . . . .  41
     9.2.  Authorization . . . . . . . . . . . . . . . . . . . . . .  41
     9.3.  Denial of Service . . . . . . . . . . . . . . . . . . . .  41
       9.3.1.  DoS Issues Inherited from the Substrate Mechanism . .  42
       9.3.2.  DoS Issues Specific to SPPF . . . . . . . . . . . . .  42
     9.4.  Information Disclosure  . . . . . . . . . . . . . . . . .  43
     9.5.  Non-repudiation . . . . . . . . . . . . . . . . . . . . .  43
     9.6.  Replay Attacks  . . . . . . . . . . . . . . . . . . . . .  43
     9.7.  Compromised or Malicious Intermediary . . . . . . . . . .  44
   10. Internationalization Considerations . . . . . . . . . . . . .  44
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  44
     11.1.  URN Assignments  . . . . . . . . . . . . . . . . . . . .  44
     11.2.  Organization Identifier Namespace Registry . . . . . . .  45
   12. Formal Specification  . . . . . . . . . . . . . . . . . . . .  45
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  54
     13.1.  Normative References . . . . . . . . . . . . . . . . . .  54
     13.2.  Informative References . . . . . . . . . . . . . . . . .  55
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  57
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  57

1.  Introduction

   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

Top      ToC       Page 4 
   (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.

Top      ToC       Page 5 
   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

Top      ToC       Page 6 
   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.

Top      ToC       Page 7 
   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].

Top      ToC       Page 8 
       +-------------+                        +-----------------+
       | 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

Top      ToC       Page 9 
   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

Top      ToC       Page 10 
      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.

Top      ToC       Page 11 
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.

Top      ToC       Page 12 
   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.

Top      ToC       Page 13 
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>

Top      ToC       Page 14 
   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.

Top      ToC       Page 15 
   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>

Top      ToC       Page 16 
      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.

Top      ToC       Page 17 
   +---------------------+---------------------------------------------+
   | 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

Top      ToC       Page 18 
   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)

Next Section