| DISPATCH | R. Avasarala, Ed. |
| Internet-Draft | Motorola Inc |
| Intended status: Informational | R. Jesske |
| Expires: July 28, 2012 | Deutsche Telekom |
| January 27, 2012 |
None
A Session Initiation Protocol (SIP) Event Package for Communication Barring Notification Information in support of the Dynamic Incoming Communication Barring (ICB) Notification service draft-avasarala-dispatch-comm-barring-notification-00.txt
3GPP is defining the protocol specification for the Communication Barring (CB) service using IP Multimedia (IM) Core Network (CN) subsystem supplementary service and more particularly the dynamic incoming communication barring service. As part of dynamic incoming communication barring (ICB) service, a SIP based Event package framework is used for notifying users about communication barrings (dynamic and rule based) of their incoming communication sessions. This document proposes a new SIP event package for allowing users to subscribe to and receive such notifications. Users can further define filters to control the rate and content of such notifications. The proposed event package is applicable to the ICB supplementary service in IMS and may not be applicable to the general internet.
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 28, 2012.
Copyright (c) 2012 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.
3GPP is currently maintaining and specifying incoming communication barring mechanisms which allow users to dynamically block incoming communications from callers whom they consider as unwanted or unsolicited. The intention of such mechanisms is to provide users with sufficient flexibility to manage their incoming communications in a better way. The most common example is the Anonymous Communication Rejection (ACR) where in the incoming communications from senders whose identity is marked as "Anonymous" is rejected. Similarly other variants of ICB include dynamically blocking a particular caller by the subscribers, called the dynamic ICB which is specified in 3GPP specification [3GPP.24.611].
However, with the increasing number of unwanted calls and increased usage of incoming communication barring services, users may have lot of callers being blocked from time to time and for different periods based on temporary or permanent block. For instance, a user may have blocked a particular caller for a temporary period and specified the period as 1 year. Though there are ways by which users can keep track of their communication barrings, there is no efficient mechanism for the users to get information of their communication barrings that get enacted in the network. This information would help them to verify their rules and rectify if required.
This document defines a SIP event package that allows a SIP User Agents to subscribe to and be notified of communication barrings enacted on their behalf.
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [RFC2119] and indicate requirement levels for compliant implementations.
It is believed that the SIP event package defined here is not applicable to the general Internet and has been designed to serve the architecture of the ICB services in IMS core networks. The aim of this memo is to follow the procedure indicated in RFC 5727 [RFC5727] and to register a new event package with event name "comm-bar-info" with IANA.
A comprehensive description of all the requirements that affect the ICB service developed by 3GPP can be found in the 3GPP specification [3GPP.22.173].
For the sake of simplicity, we briefly discuss here those requirements that affect the solution described in this document. These requirements can be summarized as follows:
These requirements lead to a solution whereby the user can indicate to a network node his interest in receiving certain type of notifications of communication blocking. Pushing these settings to a network node allows the network node to conserve scarce resources while still notifying the user of communication barrings enacting on the user's behalf.
This section fills in the details needed for an event package as defined in Section 4.4 of [RFC3265].
The SIP Events specification requires package definitions to specify the name of their package or template-package.
The name of this package is "comm-bar-info". As specified in [RFC3265], this value appears in the Event header present in SUBSCRIBE and NOTIFY requests.
The SIP Events specification [RFC3265] allows packages to define additional parameters. This event package "comm-bar-info" does not define additional parameters.
The SIP Events specification requires package or template-package definitions to define the usage, if any, of bodies in SUBSCRIBE requests.
A SUBSCRIBE for Communication Barring event MAY contain a body. The purpose of the body depends on its type. Subscriptions to the Comm-block-info event package SHALL only include a body of MIME type "application/comm-bar-info+xml".
A body of the SUBSCRIBE request with content type set to MIME type "application/comm-bar-info+xml" contains information about the communication barring notification information filter criteria and notification trigger criteria. This information is conveyed using the XML elements defined in Section 8.1.1.1.
The default expiration time for subscriptions within this package is 3600 seconds. As per [RFC3265], the subscriber MAY specify an alternate expiration in the Expires header field.
The SIP Events specification requires package definitions to define a default value for subscription durations, and to discuss reasonable choices for durations when they are explicitly specified.
The NOTIFY message contains bodies. This body is a format listed in the Accept header field of the SUBSCRIBE request or a package specific default format if the Accept header field was omitted from the SUBSCRIBE request.
In this event package, the body of the notification contains the communication barring information pertaining to the barring that occurred in the network on behalf of the subscriber. The format of the communication barring information is an XML document as per elements defined in Section 8.1.2. See Section 8.
All subscribers and notifiers of the "comm-bar-info" event package MUST support the "application/comm-bar-info+xml" data format described in Section 8. The SUBSCRIBE request MAY contain an Accept header field. If no such header field is present, it has a default value of "application/comm-bar-info+xml" (assuming Event header has a value of "comm-bar-info"). If the Accept header field is present, it MUST contain the value "application/comm-bar-info+xml".
The contents of a document containing comm-bar-info information can contain sensitive information that can reveal some privacy information. Therefore, such comm-bar-info documents MUST only be sent to authorized subscribers. In order to determine if a subscription originates in an authorized user, the subscriber MUST be authenticated as described in Section 6.6.1 and then the user MUST be authorized to be a subscriber as described in Section 6.6.2.
Notifiers MUST authenticate all subscription requests. This authentication can be done using any of the mechanisms defined in [RFC3261] and other authentication extensions.
Once authenticated, the notifier makes an authorization decision. A notifier MUST NOT accept a subscription unless authorization has been provided by the user. The means by which authorization are provided are outside the scope of this document. Authorization may have been provided ahead of time through access lists, perhaps specified in a web page. Authorization may have been provided by means of uploading some kind of standardized access control list document
The SIP Events specification details the formatting and structure of NOTIFY messages. However, packages are mandated to provide detailed information on when to send a NOTIFY, how to compute the state of the resource, how to generate neutral or fake state information, and whether state information is complete or partial. This section describes those details for the "comm-bar-info" event package.
A notifier MAY send a NOTIFY at any time. Typically, it will send one when a communication barring is enacted on behalf of the user. The NOTIFY request MAY contain a body containing a comm-bar-info document. The times at which the NOTIFY is sent for a particular subscriber, and the contents of the body within that notification, are subject to any rules specified by the authorization policy that governs the subscription and to preferences indicated at the time of subscription.
The body of the NOTIFY MUST be sent using the type "application/comm-bar-info+xml".
It is RECOMMENDED that the notifiers do maintain the history of last N communication barrings that occurred, where the value N >=1 as part of state information for that server. The value of N could be configured and is left to server policy to determine appropriate value.
The state information is retained even after the notification for those barrings are sent to the subscriber and changes when new barring occurs. So every time a new barring occurs, the state information changes to reflect the latest barring removing the oldest barring information.
The SIP Events specification expects event packages to describe the process followed by the subscriber upon receipt of a NOTIFY request. In this specification, each NOTIFY request contains a comm-bar-info document
The SIP Events specification requires each package to describe handling of forked Requests.
This specification only allows a single dialog to be constructed as a result of emitting an initial SUBSCRIBE request. This guarantees that only a single notifier is generating notifications for a particular subscription to a particular user.
The SIP Events specification requires each package to specify maximum rate at which notifications can be sent .
Comm-bar-info notifiers SHOULD NOT generate notifications for a single subscription at a rate of more than once every five seconds.
The notifers maintain the state of last N communication barrings, where N>=1 that occurred in the network on behalf of the subscriber even after the notifications for those N communications barrings are sent or unsent. This state information gets updated with the latest communication barring that occurs by removing the oldest communication barring and adding the latest barring while maintaining the number of barrings at N.
Thus at any point of time a subscriber MAY know the state of communication barrings enacted on his or her behalf by the server.
Comm-block-info document is an XML document [W3C.REC-xml-20001006] that MUST be well-formed and SHOULD be valid. Communication Barring Information documents MUST be based on XML 1.0 and MUST be encoded using UTF-8 [RFC4745].
A Communications Barring Information document starts with a "comm-bar-info" element. The comm-bar-info element has a series of elements describing the particular communication barring or the filter criteria for receiving the communication barring information.
The comm-bar-info element gives information about the specific communication barring or it could give information about a particular selection criteria for the user receiving the communication barring information.
The comm-block-subs-info element is used by the subscribing user to specify the communication barring information selection criteria and the communication barring notification trigger criteria. It contains the following elements:
This element contains information about communication barring information selection criteria. It contains following sub-elements for specifying the selection criteria.
This element specifies the originating user information for the communication i.e. the caller. This is specified in the form of "user-name" and "user-uri". E.g. sip:Alice@domain.com. The Username as well as User-URI specified will be compared with the originating user information of the current user and if there is a match, then information about the barring of this specific communication would be selected for notification to the Diverting user. It consists of the following sub-elements.
This element gives user details like username and URI. This element has further sub-elements for describing username and user URI
This element gives Username. "Alice".
This element gives User URI. E.g "sip:Alice@domain.com". It takes the form of any URI scheme like sip. sips, tel or any other URI scheme
This element specifies the type of barring set by the user. This element can have 2 values: temporary and permanent. The value temporary means that the caller identity is barred for a temporarty period specified by the user. The value permanent means that the caller identity is blocked for ever.
This element specifies the time range for receiving notifications. It contains following additional elements .
This element specifies the time range at which notifications for communication barrings can be sent to the subscriber. This could be specified in the form of a time-interval to enable periodic triggering of notifications of communication barrings which took place in that time-interval.
NOTE: If the time-range element is not specified, then notifications about every communication barring that occurs is sent to the subscriber.
This element specifies the start time for receiving notifications. Its value is expressed in YYYY:MM:DDTHH:MM:SSZ format.
This element specifies the end time for receiving notifications. Its value is expressed in YYYY:MM:DDTHH:MM:SSZ format.
This element contains the reason for communication barring. It contains following sub-element:
This element gives the actual reason for the communication barring. E.g. "ACR".
This element informs the server about the time at which the notification should be triggered.
This element gives the presence status of the subscriber, based on which the decision can be made, whether the subscriber wishes to receive notification information or not.
This element specifies the presence status of the subscriber within which the subscriber expects to receive notifications about communication barrings.
This element gives the notification information. This element has following sub-elements:
Refer to Section 8.1.1.1.1 for details of this element.
This element gives the time of communication barring. Its value is expressed in YYYY:MM:DDTHH:MM:SS format.
This element gives the actual reason for the communication barring.
This element gives the subscriber various to select communication barring information. This element has following sub-elements.
This element gives the subscriber option of adding originating user information to the notification information. The default value is false which means the subscriber wants the originating-user-info element to be present in the notification information.
This element gives the subscriber option of adding barring-type information to the notification information. The default value is false which means the subscriber wants the barring-type information to be present in the notification information.
This element gives the subscriber option of adding barring-reason information to the notification information. The default value is false which means the subscriber wants the barring-reason information to be present in the notification information.
This element gives the subscriber option of adding barring-rule information to the notification information. The default value is false which means the subscriber wants the barring-rule information to be present in the notification information.
The communication barring notification document instance shown below is the notification information for communication barring that occurred at 10AM as per the rule that says all communications from Telemarketer as Originating user should be blocked permanently.
<comm-bar-info>
<comm-block-subs-info>
<comm-block-selection-criteria>
<originating-user-selection-criteria>
<user-info>
<user-name>Telemarketer</user-name>
<user-URI>
sip:Telemarketer@xyz-service.com
</user-URI>
</user-info>
</originating-user-selection-criteria>
<barring-type-info>Permanent </barring-type-info>
<barring-time-info>2010:03:20::T10:00:00Z
</barring-time-info>
<barring-time-selection-criteria>
<time-range>0</time-range>
</barring-time-selection-criteria>
<barring-reason-selection-criteria>
<barring-reason-info>ACR</barring-reason-info>
</barring-reason-selection-criteria>
</comm-block-selection-criteria>
<comm-bar-ntfy-trigger-criteria>
<notification-time-selection-criteria>
<time-range>
<start-time>1999-05-31T13:20:00-05:00Z</start-time>
<end-time>2006-05-06T13:20:00-05:00Z</end-time>
</time-range>
</notification-time-selection-criteria>
</comm-bar-ntfy-trigger-criteria>
</comm-block-subs-info>
</comm-bar-info>
The communication barring notification document instance shown below is the notification information for communication barring that occurred at 9.20AM as per the rule that says all communications should be blocked from 9 AM to 10 AM everyday.
<comm-bar-info>
<comm-bar-ntfy-info>
<originating-user-info>
<user-name>Telemarketer</user-name>
<user-URI>sip:Telemarketer@xyz-service.com</user-URI>
</originating-user-info>
<barring-type-info>Temporary </barring-type-info>
<barring-time-info>T9:20:00Z
</barring-time-info>
<barring-time-range>
<start-time>T9:00:00Z</start-time>
<end-time>T10:00:00Z</end-time>
,/barring-time-range>
<barring-reason-info>RULE</barring-reason-info>
</comm-bar-ntfy-info>
</comm-bar-info>
<?xml version="1.0" encoding="UTF-8" ?>
<xs:schema
targetNamespace="http://uri.etsi.org/ngn/params/xml/comm-bar-info"
xmlns:tns="http://uri.etsi.org/ngn/params/xml/comm-bar-info"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="http://uri.etsi.org/ngn/params/xml/comm-bar-info"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<!--
This import brings in the XML language definition
-->
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/03/xml.xsd"/>
<!--
Communication Barring Information. This is the top-level XML element
-->
<xs:element name="comm-bar-info"
type="comm-bar-info-type" />
<!--
Communication Barring Information Type.
This is the top-level XML element
-->
<xs:complexType name="comm-bar-info-type">
<xs:sequence>
<xs:element name="comm-bar-subs-info"
type="comm-bar-subs-info-type" minOccurs="0" />
<xs:element name="comm-bar-ntfy-info"
type="comm-bar-ntfy-info-type" minOccurs="0" />
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="entity" type="xs:anyURI"
use="required"/>
</xs:complexType>
<!---
Communication Barring Subscription Type.
Used at Subscription time to
select Communication Barrings for notification,
when to notify them and
what to notify.
-->
<xs:complexType name="comm-bar-subs-info-type">
<xs:sequence>
<xs:element name="comm-bar-selection-criteria"
type="comm-bar-selection-criteria-type"
minOccurs="0" />
<xs:element name="comm-bar-ntfy-trigger-criteria"
type="comm-bar-ntfy-trigger-criteria-type"
minOccurs="0" />
<xs:element name="comm-bar-info-selection-criteria"
type="comm-bar-info-selection-criteria-type"
minOccurs="0" />
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<!---
Communication Barring Notification Information Type
Used while notifying the User about the Communication Barring
-->
<xs:complexType name="comm-bar-ntfy-info-type">
<xs:sequence>
<xs:element name="originating-user-info"
type="user-info-type" minOccurs="0" />
<xs:element name="barring-type-info"
type="barring-type-info-type" minOccurs="0" />
<xs:element name="barring-reason-info"
type="barring-reason-info-type" minOccurs="0" />
<xs:element name="barring-rule-info"
type="barring-rule-info-type" minOccurs="0" />
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<!--
COMMUNICATION BARRING SELECTION CRITERIA
-->
<xs:complexType name="comm-bar-selection-criteria-type">
<xs:sequence>
<xs:element name="originating-user-selection-criteria"
type="user-selection-criteria-type" minOccurs="0" />
<xs:element name="barring-type-selection-criteria"
type="type-selection-criteria-type" minOccurs="0" />
<xs:element name="barring-time-selection-criteria"
type="time-range-selection-criteria-type"
minOccurs="0" />
<xs:element name="barring-reason-selection-criteria"
type="barring-reason-selection-criteria-type"
minOccurs="0" />
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<!--
COMMUNICATION BARRING NOTIFICATION TRIGGER CRITERIA
-->
<xs:complexType name="comm-bar-ntfy-trigger-criteria-type">
<xs:sequence>
<xs:element name="notification-time-selection-criteria"
type="time-range-selection-criteria-type"
minOccurs="0" />
<xs:element name="presence-status-selection-criteria"
type="presence-status-selection-criteria-type"
minOccurs="0" />
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<!--
COMMUNICATION BARRING INFORMATION SELECTION CRITERIA
-->
<xs:complexType name="comm-bar-info-selection-criteria-type">
<xs:sequence>
<xs:element name="disable-originating-user-info"
type="xs:boolean" default="false" minOccurs="0" />
<xs:element name="disable-barring-type-info"
type="xs:boolean" default="false" minOccurs="0" />
<xs:element name="disable-barring-time-info"
type="xs:boolean" default="false" minOccurs="0" />
<xs:element name="disable-barring-reason-info"
type="xs:boolean" default="false" minOccurs="0" />
<xs:element name="disable-barring-rule-info"
type="xs:boolean" default="false" minOccurs="0" />
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<!-- User Info Type -->
<xs:complexType name="user-info-type">
<xs:sequence>
<xs:element name="user-name" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:element name="user-URI" type="xs:anyURI"/>
</xs:sequence>
</xs:complexType>
<!--
BARRING REASON INFO
-->
<xs:simpleType name="barring-reason-info-types">
<xs:list itemType="barring-reason-info-type"/>
</xs:simpleType>
<xs:simpleType name="barring-reason-info-type">
<xs:restriction base="xs:string">
<xs:enumeration value="ACR"/>
<xs:enumeration value="ICB"/>
</xs:restriction>
</xs:simpleType>
<!--
BARRING RULE INFO
-->
<xs:complexType name="barring-rule-info-type">
<xs:sequence>
<xs:element name="barring-rule" type="xs:string"/>
</xs:sequence>
</xs:complexType>
<!--
ORIGINATING USER SELECTION CRITERIA
-->
<xs:complexType name="user-selection-criteria-type">
<xs:sequence>
<xs:element name="user-info"
type="user-info-type" minOccurs="0"
maxOccurs="unbounded" />
</xs:sequence>
</xs:complexType>
<!--
BARRING TYPE SELECTION CRITERIA
-->
<xs:simpleType name="type-selection-criteria-type">
<xs:list itemType="barring-type-info-type"/>
</xs:simpleType>
<xs:simpleType name="barring-type-info-type">
<xs:restriction base="xs:string">
<xs:enumeration value="temporary"/>
<xs:enumeration value="permanent"/>
</xs:restriction>
</xs:simpleType>
<!--
BARRING REASON SELECTION CRITERIA
-->
<xs:complexType name="barring-reason-selection-criteria-type">
<xs:sequence>
<xs:element name="barring-reason-info"
type="barring-reason-info-types"/>
</xs:sequence>
</xs:complexType>
<!--
TIME RANGE SELECTION CRITERIA
-->
<xs:complexType name="time-range-selection-criteria-type">
<xs:sequence>
<xs:element name="time-range"
type="time-range-type" minOccurs="0"
maxOccurs="unbounded" />
</xs:sequence>
</xs:complexType>
<!--
TIME RANGE INFO
-->
<xs:complexType name="time-range-type">
<xs:sequence>
<xs:element name="start-time" type="xs:dateTime" />
<xs:element name="end-time" type="xs:dateTime" />
</xs:sequence>
</xs:complexType>
<!--
PRESENCE STATUS SELECTION CRITERIA
-->
<xs:complexType name="presence-status-selection-criteria-type">
<xs:sequence>
<xs:element name="presence-status-info"
type="presence-status-info-type" minOccurs="0"
maxOccurs="unbounded" />
</xs:sequence>
</xs:complexType>
<!--
PRESENCE STATUS INFO
-->
<xs:complexType name="presence-status-info-type">
<xs:sequence>
<xs:element name="presence-status" type="xs:string" />
</xs:sequence>
</xs:complexType>
</xs:schema>
Authentication and authorization of subscriptions have been discussed in Section 6.6. Lack of authentication or authorization may provide comm-bar-info information to unauthorized parties and can reveal sensitive information with regards to the user's call receiving patterns. For example, who calls the user and at what time, etc.
Integrity protection and confidentiality of notifications are also discussed in Section 6.7. If a notifier does not encrypt bodies of NOTIFY requests, an eavesdropper could learn the status of a SIP user agent and use it to create malicious sessions. If the notifier does not integrity protect the bodies of NOTIFY requests, a man-in- the-middle attacker or malicious SIP proxy could modify the contents of the comm-bar-info event package notification. Although this does not cause harm, it can create annoyances.
This document registers the new SIP Event Package.
Package Name: Comm-bar-info
Type: Package
Contact: Jon Merdith, <John.meredith@3gpp.org>
Published Specification: RFC XXXX (Note to RFC Editor)
The authors would like to thank Samir Saklikar and Subir Saha for being part of the initial discussions and Ban Al-Bakri for her valuable comments and suggestions.
| [1] | 3GPP, "IP Multimedia Core Network Subsystem (IMS) Multimedia Telephony Service and supplementary services; Stage 1", 3GPP TS 22.173 10.3.0, April 2011. |
| [2] | 3GPP, "Anonymous Communication Rejection (ACR) and Communication Barring (CB) using IP Multimedia (IM) Core Network (CN) subsystem; Protocol specification", 3GPP TS 24.611 10.2.0, December 2011. |
| [3] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [4] | Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. |
| [5] | Peterson, J., Jennings, C. and R. Sparks, "Change Process for the Session Initiation Protocol (SIP) and the Real-time Applications and Infrastructure Area", BCP 67, RFC 5727, March 2010. |
| [6] | Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. |
| [1] | Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Polk, J. and J. Rosenberg, "Common Policy: A Document Format for Expressing Privacy Preferences", RFC 4745, February 2007. |
| [2] | 3GPP, "IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3", 3GPP TS 24.229 10.5.0, September 2011. |
| [3] | Maler, E., Paoli, J., Bray, T. and C. Sperberg-McQueen, "Extensible Markup Language (XML) 1.0 (Second Edition)", World Wide Web Consortium FirstEdition REC-xml-20001006, October 2000. |
[RFC EDITOR NOTE: Please remove this section when publishing]