Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 7877

Session Peering Provisioning Framework (SPPF)

Pages: 57
Proposed Standard
Part 3 of 3 – Pages 40 to 57
First   Prev   None

Top   ToC   RFC7877 - Page 40   prevText

8. XML Considerations

XML serves as the encoding format for SPPF, allowing complex hierarchical data to be expressed in a text format that can be read, saved, and manipulated with both traditional text tools and tools specific to XML. XML is case sensitive. Unless stated otherwise, the character casing of XML specifications in this document MUST be preserved to develop a conforming specification. This section discusses a small number of XML-related considerations pertaining to SPPF.

8.1. Namespaces

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

8.2. Versioning and Character Encoding

All XML instances SHOULD begin with an <?xml?> declaration to identify the version of XML that is being used, optionally identify use of the character encoding used, and optionally provide a hint to an XML parser that an external schema file is needed to validate the XML instance. Conformant XML parsers recognize both UTF-8 (defined in [RFC3629]) and UTF-16 (defined in [RFC2781]); per [RFC2277], UTF-8 is the RECOMMENDED character encoding for use with SPPF. Character encodings other than UTF-8 and UTF-16 are allowed by XML. UTF-8 is the default encoding assumed by XML in the absence of an "encoding" attribute or a byte order mark (BOM); thus, the "encoding" attribute in the XML declaration is OPTIONAL if UTF-8 encoding is used. SPPF clients and servers MUST accept a UTF-8 BOM if present, though emitting a UTF-8 BOM is NOT RECOMMENDED.
Top   ToC   RFC7877 - Page 41
   Example XML declarations:

   <?xml version="1.0" encoding="UTF-8" standalone="no"?>

9. Security Considerations

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

9.1. Confidentiality and Authentication

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

9.2. Authorization

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

9.3. Denial of Service

In general, guidance on Denial-of-Service (DoS) issues is given in "Internet Denial of Service Considerations" [RFC4732], which also gives a general vocabulary for describing the DoS issue. SPPF is a high-level client-server protocol that can be implemented on lower-level mechanisms such as remote procedure call and web- service API protocols. As such, it inherits any Denial-of-Service issues inherent to the specific lower-level mechanism used for any implementation of SPPF. SPPF also has its own set of higher-level exposures that are likely to be independent of lower-layer mechanism choices.
Top   ToC   RFC7877 - Page 42

9.3.1. DoS Issues Inherited from the Substrate Mechanism

In general, an SPPF implementation is dependent on the selection and implementation of a lower-level substrate protocol and a binding between that protocol and SPPF. The archetypal SPPF implementation uses XML [W3C.REC-xml-20081126] representation in a SOAP [SOAPREF] request/response framework over HTTP [RFC7230], probably also uses Transport Layer Security (TLS) [RFC5246] for on-the-wire data integrity and participant authentication, and might use HTTP Digest authentication [RFC2069]. The typical deployment scenario for SPPF is to have servers in a managed facility; therefore, techniques such as Network Ingress Filtering [RFC2827] are generally applicable. In short, any DoS mechanism affecting a typical HTTP implementation would affect such an SPPF implementation; therefore, the mitigation tools for HTTP in general also apply to SPPF. SPPF does not directly specify an authentication mechanism; instead, it relies on the lower-level substrate protocol to provide for authentication. In general, authentication is an expensive operation, and one apparent attack vector is to flood an SPPF server with repeated requests for authentication, thereby exhausting its resources. Therefore, SPPF implementations SHOULD be prepared to handle authentication floods, perhaps by noting repeated failed login requests from a given source address and blocking that source address.

9.3.2. DoS Issues Specific to SPPF

The primary defense mechanism against DoS within SPPF is authentication. Implementations MUST tightly control access to the SPPF service, SHOULD implement DoS and other policy control screening, and MAY employ a variety of policy violation reporting and response measures such as automatic blocking of specific users and alerting of operations personnel. In short, the primary SPPF response to DoS-like activity by a user is to block that user or subject their actions to additional review. SPPF allows a client to submit multiple-element or "batch" requests that may insert or otherwise affect a large amount of data with a single request. In the simplest case, the server progresses sequentially through each element in a batch, completing one before starting the next. Mid-batch failures are handled by stopping the batch and rolling back the data store to its pre-request state. This "stop and roll back" design provides a DoS opportunity. A hostile client could repeatedly issue large batch requests with one or more failing elements, causing the server to repeatedly stop and roll back
Top   ToC   RFC7877 - Page 43
   large transactions.  The suggested response is to monitor clients for
   such failures and take administrative action (such as blocking the
   user) when an excessive number of rollbacks is reported.

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

9.4. Information Disclosure

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

9.5. Non-repudiation

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

9.6. Replay Attacks

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

9.7. Compromised or Malicious Intermediary

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

10. Internationalization Considerations

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

11. IANA Considerations

11.1. URN Assignments

This document uses URNs to describe XML Namespaces and XML Schemas conforming to a Registry mechanism described in [RFC3688]. Two URI assignments have been made: Registration for the SPPF XML Namespace: urn:ietf:params:xml:ns:sppf:base:1 Registrant Contact: The IESG XML: None. Namespace URIs do not represent an XML specification. Registration request for the XML Schema: URI: urn:ietf:params:xml:schema:sppf:1 Registrant Contact: IESG XML: See "Formal Specification" (Section 12 of this document).
Top   ToC   RFC7877 - Page 45

11.2. Organization Identifier Namespace Registry

IANA has created and will maintain a registry titled "SPPF OrgIdType Namespaces". The formal syntax is described in Section 5.1. Assignments consist of the OrgIdType Namespace string and the definition of the associated Namespace. This document makes the following initial assignment for the OrgIdType Namespaces: OrgIdType Namespace string Namespace -------------------------- --------- IANA Enterprise Numbers iana-en Future assignments are to be made through the well-known IANA Policy "RFC Required" (see Section 4.1 of [RFC5226]). Such assignments will typically be requested when a new Namespace for identification of SPs is defined.

12. Formal Specification

This section provides the XSD for the SPPF protocol. <?xml version="1.0" encoding="UTF-8"?> <schema xmlns:sppfb="urn:ietf:params:xml:ns:sppf:base:1" xmlns="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:ietf:params:xml:ns:sppf:base:1" elementFormDefault="qualified" xml:lang="EN"> <annotation> <documentation> ---- Generic object key types to be defined by specific substrate/architecture. The types defined here can be extended by the specific architecture to define the Object Identifiers. ---- </documentation> </annotation> <complexType name="ObjKeyType" abstract="true"> <annotation> <documentation> ---- Generic type that represents the key for various objects in SPPF. ---- </documentation> </annotation> </complexType>
Top   ToC   RFC7877 - Page 46
    <complexType name="SedGrpOfferKeyType" abstract="true">
     <complexContent>
      <extension base="sppfb:ObjKeyType">
       <annotation>
        <documentation>
        ---- Generic type that represents
             the key for a SED Group Offer. ----
        </documentation>
       </annotation>
      </extension>
     </complexContent>
    </complexType>

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

    <annotation>
     <documentation>
       ---- Object Type Definitions ----
     </documentation>
    </annotation>

    <complexType name="SedGrpType">
     <complexContent>
      <extension base="sppfb:BasicObjType">
       <sequence>
        <element name="sedGrpName" type="sppfb:ObjNameType"/>
        <element name="sedRecRef" type="sppfb:SedRecRefType"
                 minOccurs="0" maxOccurs="unbounded"/>
        <element name="dgName" type="sppfb:ObjNameType"
                 minOccurs="0" maxOccurs="unbounded"/>
        <element name="peeringOrg" type="sppfb:OrgIdType"
                 minOccurs="0" maxOccurs="unbounded"/>
        <element name="sourceIdent" type="sppfb:SourceIdentType"
                 minOccurs="0" maxOccurs="unbounded"/>
        <element name="isInSvc" type="boolean"/>
        <element name="priority" type="unsignedShort"/>
Top   ToC   RFC7877 - Page 47
        <element name="ext"
        type="sppfb:ExtAnyType" minOccurs="0"/>
       </sequence>
      </extension>
     </complexContent>
    </complexType>
    <complexType name="DestGrpType">
     <complexContent>
      <extension base="sppfb:BasicObjType">
       <sequence>
        <element name="dgName"
        type="sppfb:ObjNameType"/>
       </sequence>
      </extension>
     </complexContent>
    </complexType>
    <complexType name="PubIdType" abstract="true">
     <complexContent>
      <extension base="sppfb:BasicObjType">
       <sequence>
        <element name="dgName" type="sppfb:ObjNameType"
                 minOccurs="0" maxOccurs="unbounded"/>
       </sequence>
      </extension>
     </complexContent>
    </complexType>
    <complexType name="TNType">
     <complexContent>
      <extension base="sppfb:PubIdType">
       <sequence>
        <element name="tn" type="sppfb:NumberValType"/>
        <element name="corInfo" type="sppfb:CORInfoType" minOccurs="0"/>
        <element name="sedRecRef" type="sppfb:SedRecRefType"
                 minOccurs="0" maxOccurs="unbounded"/>
       </sequence>
      </extension>
     </complexContent>
    </complexType>
    <complexType name="TNRType">
     <complexContent>
      <extension base="sppfb:PubIdType">
       <sequence>
        <element name="range" type="sppfb:NumberRangeType"/>
        <element name="corInfo" type="sppfb:CORInfoType" minOccurs="0"/>
       </sequence>
      </extension>
     </complexContent>
    </complexType>
Top   ToC   RFC7877 - Page 48
    <complexType name="TNPType">
     <complexContent>
      <extension base="sppfb:PubIdType">
       <sequence>
        <element name="tnPrefix" type="sppfb:NumberValType"/>
        <element name="corInfo" type="sppfb:CORInfoType" minOccurs="0"/>
       </sequence>
      </extension>
     </complexContent>
    </complexType>
    <complexType name="RNType">
     <complexContent>
      <extension base="sppfb:PubIdType">
       <sequence>
        <element name="rn" type="sppfb:NumberValType"/>
        <element name="corInfo" type="sppfb:CORInfoType" minOccurs="0"/>
       </sequence>
      </extension>
     </complexContent>
    </complexType>
     <complexType name="URIPubIdType">
     <complexContent>
      <extension base="sppfb:PubIdType">
       <sequence>
        <element name="uri" type="anyURI"/>
        <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
       </sequence>
      </extension>
     </complexContent>
    </complexType>
    <complexType name="SedRecType" abstract="true">
     <complexContent>
      <extension base="sppfb:BasicObjType">
       <sequence>
        <element name="sedName" type="sppfb:ObjNameType"/>
        <element name="sedFunction" type="sppfb:SedFunctionType"
                 minOccurs="0"/>
        <element name="isInSvc" type="boolean"/>
        <element name="ttl" type="positiveInteger" minOccurs="0"/>
       </sequence>
      </extension>
     </complexContent>
    </complexType>
    <complexType name="NAPTRType">
     <complexContent>
      <extension base="sppfb:SedRecType">
       <sequence>
        <element name="order" type="unsignedShort"/>
Top   ToC   RFC7877 - Page 49
        <element name="flags" type="sppfb:FlagsType" minOccurs="0"/>
        <element name="svcs" type="sppfb:SvcType"/>
        <element name="regx" type="sppfb:RegexParamType" minOccurs="0"/>
        <element name="repl" type="sppfb:ReplType" minOccurs="0"/>
        <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
       </sequence>
      </extension>
     </complexContent>
    </complexType>
    <complexType name="NSType">
     <complexContent>
      <extension base="sppfb:SedRecType">
       <sequence>
        <element name="hostName" type="token"/>
        <element name="ipAddr" type="sppfb:IPAddrType"
                 minOccurs="0" maxOccurs="unbounded"/>
        <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
       </sequence>
      </extension>
     </complexContent>
    </complexType>
    <complexType name="URIType">
     <complexContent>
      <extension base="sppfb:SedRecType">
       <sequence>
        <element name="ere" type="token" default="^(.*)$"/>
        <element name="uri" type="anyURI"/>
        <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
       </sequence>
      </extension>
     </complexContent>
    </complexType>
    <complexType name="SedGrpOfferType">
     <complexContent>
      <extension base="sppfb:BasicObjType">
       <sequence>
        <element name="sedGrpOfferKey" type="sppfb:SedGrpOfferKeyType"/>
        <element name="status" type="sppfb:SedGrpOfferStatusType"/>
        <element name="offerDateTime" type="dateTime"/>
        <element name="acceptDateTime" type="dateTime" minOccurs="0"/>
        <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
       </sequence>
      </extension>
     </complexContent>
    </complexType>
    <complexType name="EgrRteType">
     <complexContent>
      <extension base="sppfb:BasicObjType">
Top   ToC   RFC7877 - Page 50
       <sequence>
        <element name="egrRteName" type="sppfb:ObjNameType"/>
        <element name="pref" type="unsignedShort"/>
        <element name="regxRewriteRule" type="sppfb:RegexParamType"/>
        <element name="ingrSedGrp" type="sppfb:ObjKeyType"
                 minOccurs="0" maxOccurs="unbounded"/>
        <element name="svcs" type="sppfb:SvcType" minOccurs="0"/>
        <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
       </sequence>
      </extension>
     </complexContent>
    </complexType>
    <annotation>
     <documentation>
      ---- Abstract Object and Element Type Definitions ----
     </documentation>
    </annotation>
    <complexType name="BasicObjType" abstract="true">
     <sequence>
      <element name="rant" type="sppfb:OrgIdType"/>
      <element name="rar" type="sppfb:OrgIdType"/>
      <element name="cDate" type="dateTime" minOccurs="0"/>
      <element name="mDate" type="dateTime" minOccurs="0"/>
      <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
     </sequence>
    </complexType>
    <complexType name="RegexParamType">
     <sequence>
      <element name="ere" type="sppfb:RegexType" default="^(.*)$"/>
      <element name="repl" type="sppfb:ReplType"/>
     </sequence>
    </complexType>
    <complexType name="IPAddrType">
     <sequence>
      <element name="addr" type="sppfb:AddrStringType"/>
      <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
     </sequence>
     <attribute name="type" type="sppfb:IPType" default="v4"/>
    </complexType>
    <complexType name="SedRecRefType">
     <sequence>
      <element name="sedKey" type="sppfb:ObjKeyType"/>
      <element name="priority" type="unsignedShort"/>
      <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
     </sequence>
    </complexType>
    <complexType name="SourceIdentType">
     <sequence>
Top   ToC   RFC7877 - Page 51
      <element name="sourceIdentRegex" type="sppfb:RegexType"/>
      <element name="sourceIdentScheme"
               type="sppfb:SourceIdentSchemeType"/>
      <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
     </sequence>
    </complexType>
    <complexType name="CORInfoType">
     <sequence>
      <element name="corClaim" type="boolean" default="true"/>
      <element name="cor" type="boolean" default="false" minOccurs="0"/>
      <element name="corDate" type="dateTime" minOccurs="0"/>
     </sequence>
    </complexType>
    <complexType name="SvcMenuType">
     <sequence>
      <element name="serverStatus" type="sppfb:ServerStatusType"/>
      <element name="majMinVersion" type="token" maxOccurs="unbounded"/>
      <element name="objURI" type="anyURI" maxOccurs="unbounded"/>
      <element name="extURI" type="anyURI"
               minOccurs="0" maxOccurs="unbounded"/>
     </sequence>
    </complexType>
    <complexType name="ExtAnyType">
     <sequence>
      <any namespace="##other" maxOccurs="unbounded"/>
     </sequence>
    </complexType>
    <simpleType name="FlagsType">
     <restriction base="token">
      <length value="1"/>
      <pattern value="[A-Z]|[a-z]|[0-9]"/>
     </restriction>
    </simpleType>
    <simpleType name="SvcType">
     <restriction base="token">
      <minLength value="1"/>
     </restriction>
    </simpleType>
    <simpleType name="RegexType">
     <restriction base="token">
      <minLength value="1"/>
     </restriction>
    </simpleType>
    <simpleType name="ReplType">
     <restriction base="token">
      <minLength value="1"/>
      <maxLength value="255"/>
     </restriction>
Top   ToC   RFC7877 - Page 52
    </simpleType>
    <simpleType name="OrgIdType">
     <restriction base="token"/>
    </simpleType>
    <simpleType name="ObjNameType">
     <restriction base="token">
      <minLength value="3"/>
      <maxLength value="80"/>
     </restriction>
    </simpleType>
    <simpleType name="TransIdType">
     <restriction base="token">
      <minLength value="3"/>
      <maxLength value="120"/>
     </restriction>
    </simpleType>
    <simpleType name="MinorVerType">
     <restriction base="unsignedLong"/>
    </simpleType>
    <simpleType name="AddrStringType">
     <restriction base="token">
      <minLength value="3"/>
      <maxLength value="45"/>
     </restriction>
    </simpleType>
    <simpleType name="IPType">
     <restriction base="token">
      <enumeration value="v4"/>
      <enumeration value="v6"/>
     </restriction>
    </simpleType>
    <simpleType name="SourceIdentSchemeType">
     <restriction base="token">
      <enumeration value="uri"/>
      <enumeration value="ip"/>
      <enumeration value="rootDomain"/>
     </restriction>
    </simpleType>
    <simpleType name="ServerStatusType">
     <restriction base="token">
      <enumeration value="inService"/>
      <enumeration value="outOfService"/>
     </restriction>
    </simpleType>
    <simpleType name="SedGrpOfferStatusType">
     <restriction base="token">
      <enumeration value="offered"/>
      <enumeration value="accepted"/>
Top   ToC   RFC7877 - Page 53
     </restriction>
    </simpleType>
    <simpleType name="NumberValType">
     <restriction base="token">
      <maxLength value="20"/>
      <pattern value="\+?\d\d*"/>
     </restriction>
    </simpleType>
    <simpleType name="NumberTypeEnum">
     <restriction base="token">
      <enumeration value="TN"/>
      <enumeration value="TNPrefix"/>
      <enumeration value="RN"/>
     </restriction>
    </simpleType>
    <simpleType name="SedFunctionType">
     <restriction base="token">
      <enumeration value="routing"/>
      <enumeration value="lookup"/>
     </restriction>
    </simpleType>
    <complexType name="NumberType">
     <sequence>
      <element name="value" type="sppfb:NumberValType"/>
      <element name="type" type="sppfb:NumberTypeEnum"/>
     </sequence>
    </complexType>
    <complexType name="NumberRangeType">
     <sequence>
      <element name="startRange" type="sppfb:NumberValType"/>
      <element name="endRange" type="sppfb:NumberValType"/>
     </sequence>
    </complexType>
   </schema>
Top   ToC   RFC7877 - Page 54

13. References

13.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, DOI 10.17487/RFC2277, January 1998, <http://www.rfc-editor.org/info/rfc2277>. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <http://www.rfc-editor.org/info/rfc3629>. [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <http://www.rfc-editor.org/info/rfc3688>. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>. [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>. [RFC7878] Cartwright, K., Bhatia, V., Mule, J., and A. Mayrhofer, "Session Peering Provisioning (SPP) Protocol over SOAP", RFC 7878, DOI 10.17487/RFC7878, August 2016, <http://www.rfc-editor.org/info/rfc7878>. [W3C.REC-xml-20081126] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", World Wide Web Consortium Recommendation REC- xml-20081126, November 2008, <http://www.w3.org/TR/2008/REC-xml-20081126>.
Top   ToC   RFC7877 - Page 55

13.2. Informative References

[RFC2069] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., Luotonen, A., Sink, E., and L. Stewart, "An Extension to HTTP : Digest Access Authentication", RFC 2069, DOI 10.17487/RFC2069, January 1997, <http://www.rfc-editor.org/info/rfc2069>. [RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", RFC 2781, DOI 10.17487/RFC2781, February 2000, <http://www.rfc-editor.org/info/rfc2781>. [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, May 2000, <http://www.rfc-editor.org/info/rfc2827>. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <http://www.rfc-editor.org/info/rfc3261>. [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, DOI 10.17487/RFC3403, October 2002, <http://www.rfc-editor.org/info/rfc3403>. [RFC4725] Mayrhofer, A. and B. Hoeneisen, "ENUM Validation Architecture", RFC 4725, DOI 10.17487/RFC4725, November 2006, <http://www.rfc-editor.org/info/rfc4725>. [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet Denial-of-Service Considerations", RFC 4732, DOI 10.17487/RFC4732, December 2006, <http://www.rfc-editor.org/info/rfc4732>. [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, <http://www.rfc-editor.org/info/rfc4949>. [RFC5067] Lind, S. and P. Pfautz, "Infrastructure ENUM Requirements", RFC 5067, DOI 10.17487/RFC5067, November 2007, <http://www.rfc-editor.org/info/rfc5067>.
Top   ToC   RFC7877 - Page 56
   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246,
              DOI 10.17487/RFC5246, August 2008,
              <http://www.rfc-editor.org/info/rfc5246>.

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

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

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

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

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

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

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

Acknowledgements

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

Authors' Addresses

Kenneth Cartwright TNS 1939 Roland Clarke Place Reston, VA 20191 United States Email: kcartwright@tnsi.com Vikas Bhatia TNS 1939 Roland Clarke Place Reston, VA 20191 United States Email: vbhatia@tnsi.com Syed Wasim Ali NeuStar 46000 Center Oak Plaza Sterling, VA 20166 United States Email: syed.ali@neustar.biz David Schwartz XConnect 316 Regents Park Road London N3 2XJ United Kingdom Email: dschwartz@xconnect.net