<xs:element name="DialledDigits" type="xs:token"
minOccurs="0" maxOccurs="1"/>
<xs:element name="Cell-ID" type="xs:token"
minOccurs="0" maxOccurs="1"/>
<xs:element name="Cause" type="tns:CauseType"
minOccurs="0" maxOccurs="1"/>
</xs:sequence>
<xs:attribute name="type" type="tns:PayloadType"
use="required"/>
<xs:attribute name="name" type="tns:EventNameType"
use="required"/>
<xs:attribute name="mode" type="tns:ModeType"
use="optional" default="N"/>
</xs:complexType>
<xs:simpleType name="PayloadType">
<!-- The <spirits-event> will contain either a list of -->
<!-- INDPs events or a list of userprof events -->
<xs:restriction base="xs:string">
<xs:enumeration value="INDPs"/>
<xs:enumeration value="userprof"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="EventNameType">
<xs:restriction base="xs:string">
<!-- These are the call related events (DPs). If the -->
<!-- PaylaodType is "INDPs", then the value of the "name" -->
<!-- attribute is one of these; example -->
<!-- <spirits-event type="INDPs" name="OCI"> -->
<xs:enumeration value="OAA"/>
<xs:enumeration value="OCI"/>
<xs:enumeration value="OAI"/>
<xs:enumeration value="OA"/>
<xs:enumeration value="OTS"/>
<xs:enumeration value="ONA"/>
<xs:enumeration value="OCPB"/>
<xs:enumeration value="ORSF"/>
<xs:enumeration value="OMC"/>
<xs:enumeration value="OAB"/>
<xs:enumeration value="OD"/>
<xs:enumeration value="TA"/>
<xs:enumeration value="TMC"/>
<xs:enumeration value="TAB"/>
<xs:enumeration value="TD"/>
<xs:enumeration value="TAA"/>
<xs:enumeration value="TFSA"/>
<xs:enumeration value="TB"/>
<!-- These are the non-call related events. If the -->
<!-- PayloadType is "user-prof", then the value of the -->
<!-- "name" attribute is one of these; example -->
<!-- <spirits-event type="userprof" name="LUDV"> -->
<xs:enumeration value="LUSV"/>
<xs:enumeration value="LUDV"/>
<xs:enumeration value="REG"/>
<xs:enumeration value="UNREGMS"/>
<xs:enumeration value="UNREGNTWK"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="ModeType">
<!-- One of two values: "N"otification or "R"equest -->
<xs:restriction base="xs:string">
<xs:enumeration value="N"/>
<xs:enumeration value="R"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="CauseType">
<xs:restriction base="xs:string">
<xs:enumeration value="Busy"/>
<xs:enumeration value="Unreachable"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
10. Acknowledgements
The authors are grateful to participants in the SPIRITS WG for the
discussion that contributed to this work. These include J-L. Bakker,
J. Bjorkner, J. Buller, J-E. Chapron, B. Chatras, O. Cleuziou,
L. Conroy, R. Forbes, F. Haerens, J. Humphrey, J. Kozik,
W. Montgomery, S. Nyckelgard, M. O’Doherty, A. Roach, J. Rosenberg,
H. Sinnreich, L. Slutsman, D. Varney, and W. Zeuch. The authors also
acknowledge Steve Bellovin, Allison Mankin and Jon Peterson for help
provided on the Security section.
11. Acronyms
ACL Access Control List
CS Capability Set
DP Detection Point
DTD Document Type Definition
EDP Event Detection Point
EDP-N Event Detection Point "Notification"
EDP-R Event Detection Point "Request"
IANA Internet Assigned Numbers Authority
ICW Internet Call Waiting
IMSI International Mobile Subscriber Identity
IN Intelligent Network
INAP Intelligent Network Application Protocol
IP Internet Protocol
ISP Internet Service Provider
ITU International Telecommunications Union
MIME Multipurpose Internet Mail Extensions
MS Mobile Station (or Mobile Subscriber)
OBCSM Originating Basic Call State Model
PIC Point In Call
PINT PSTN/Internet Interworking
PSTN Public Switched Telephone Network
SCF Service Control Function
SCP Service Control Point
SDP Session Description Protocol
SIP Session Initiation Protocol
SIP-T SIP for Telephones
SPIRITS Services in the PSTN/IN Requesting InTernet
Services
SSF Service Switching Function
SSP Service Switching Point
STD State Transition Diagram
TBCSM Terminating Basic Call State Model
TDP Trigger Detection Point
TDP-N Trigger Detection Point "Notification"
TDP-R Trigger Detection Point "Request"
TLS Transport Layer Security
UA User Agent
VLR Visitor Location Register
WIN Wireless Intelligent Network
XML Extensible Markup Language
12. References
12.1. Normative References
[1] Slutsman, L., Faynberg, I., Lu, H., and M. Weissman, "The
SPIRITS Architecture", RFC 3136, June 2001.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[4] Faynberg, I., Gato, J., Lu, H., and L. Slutsman, "Service in the
Public Switched Telephone Network/Intelligent Network (PSTN/IN)
Requesting InTernet Service (SPIRITS) Protocol Requirements",
RFC 3298, August 2002.
[5] 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.
12.2. Informative References
[6] M. Unmehopa, K. Vemuri, A. Brusilovsky, E. Dacloush, A. Zaki, F.
Haerens, J-L. Bakker, B. Chatras, and J. Dobrowolski, "On
selection of IN parameters to be carried by the SPIRITS
Protocol", Work In Progress, January 2003.
[7] Intelligent Network Capability Set 2. ITU-T, Recommendation
Q.1228.
[8] Petrack, S. and L. Conroy, "The PINT Service Protocol:
Extensions to SIP and SDP for IP Access to Telephone Call
Services", RFC 2848, June 2000.
[9] Murata, M., St.Laurent, S., and D. Kohn, "XML Media Types", RFC
3023, January 2001.
[10] Lu, H., Faynberg, I., Voelker, J., Weissman, M., Zhang, W.,
Rhim, S., Hwang, J., Ago, S., Moeenuddin, S., Hadvani, S.,
Nyckelgard, S., Yoakum, J., and L. Robart, "Pre-Spirits
Implementations of PSTN-initiated Services", RFC 2995, November
2000.
[11] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
(SIP): Locating SIP Servers", RFC 3263, June 2002.
[12] Thompson, H., Beech, D., Maloney, M. and N. Mendelsohn, "XML
Schema Part 1: Structures", W3C REC REC-xmlschema-1-20010502,
May 2001. <http://www.w3c.org/XML/>.
[13] "Interface recommendations for intelligent network capability
set 3: SCF-SSF interface", ITU-T Recommendation Q.1238.2, June
2000.
[14] Moats, R., "URN Syntax", RFC 2141, May 1997.
[15] Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
August 1999.
[16] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January
2004.
[17] Tim Bray, Dave Hollander, and Andrew Layman, "Namespaces in
XML", W3C recommendation: xml-names, 14th January 1999,
<http://www.w3.org/ TR/REC-xml-names>.
[18] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
(S/MIME) Version 3.1 Message Specification", RFC 3851, July
2004.
[19] Faynberg, I., L. Gabuzda, M. Kaplan, and N.Shah, "The
Intelligent Network Standards: Their Application to Services",
McGraw-Hill, 1997.
[20] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996.
Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, November
1996.
Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part
Three: Message Header Extensions for Non-ASCII Text ", RFC
2047, November 1996.
Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet
Mail Extensions (MIME) Part Four: Registration Procedures", BCP
13, RFC 2048, November 1996.
Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Five: Conformance Criteria and Examples",
RFC 2049, November 1996.
13. Contributors
Kumar Vemuri
Lucent Technologies, Inc.
2000 Naperville Rd.
Naperville, IL 60566
USA
EMail: vvkumar@lucent.com
14. Authors’ Addresses
Vijay K. Gurbani, Editor
2000 Lucent Lane
Rm 6G-440
Naperville, IL 60566
USA
EMail: vkg@lucent.com
Alec Brusilovsky
2601 Lucent Lane
Lisle, IL 60532-3640
USA
EMail: abrusilovsky@lucent.com
Igor Faynberg
Lucent Technologies, Inc.
101 Crawfords Corner Rd.
Holmdel, NJ 07733
USA
EMail: faynberg@lucent.com
Jorge Gato
Vodafone Espana
Isabel Colbrand, 22
28050 Madrid
Spain
EMail: jorge.gato@vodafone.com
Hui-Lan Lu
Bell Labs/Lucent Technologies
Room 4C-607A, 101 Crawfords Corner Road
Holmdel, New Jersey, 07733
Phone: (732) 949-0321
EMail: huilanlu@lucent.com
Musa Unmehopa
Lucent Technologies, Inc.
Larenseweg 50,
Postbus 1168
1200 BD, Hilversum,
The Netherlands
EMail: unmehopa@lucent.com
15. Full Copyright Statement
Copyright (C) The Internet Society (2004).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the IETF’s procedures with respect to rights in IETF Documents can
be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.