Internet Draft A Service Creation Markup Language November 2001
for scripting Next Generation Network Services
J.L. Bakker
Internet Draft R. Jain
Document: draft-bakker-jain-scml-00.txt Telcordia
Expires: May 2002 November 2001
A Service Creation Markup Language for Scripting
Next Generation Network Services
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
Several industry fora have joined forces and are developing an
information base from which APIs can be developed. These APIs,
exposed to the world in Java or OMG IDL, provide access to
capabilities of the converged (i.e., packet/circuit, wired/wireless)
Next Generation Network (NGN) in a network technology independent
fashion. Additionally, the SPIRITS protocol provides access to
these capabilities.
The Service Creation Markup Language (SCML) suite of XML Schemas
defines a simple and uniform way to create services on top of this
information base. SCML is API or protocol independent. This
document describes an architectural framework for such a set of
schemas.
1. Introduction
The Service Creation Markup Language (SCML) suite is the next
generation of service creation markup languages for scripting
applications or services in the Next Generation Network (NGN), where
the NGN consists of a converged packet/circuit, Internet/PSTN,
wired/wireless network. SCML is currently being developed in the
Java Service Creation Environment (JSCE) [1] working group of the
A Service Creation Markup Language November, 2001
for scripting Next Generation Network Services
JAIN(TM) (Java(TM) APIs for the Integrated Network) [2, 3] industry
standards forum, with liaison to the Parlay forum [9]. This
document describes the motivation behind SCML and provides a brief
overview of its capabilities. This document also proposes that SCML
be considered and developed further by the IETF as a standard high-
level scripting language for NGN in general and SPIRITS [17]
environments in particular.
In general, a Service Creation Environment (SCE) allows the
development of new service building blocks and the assembly of
services from these building blocks, typically using one or more
commercially available, off-the-shelf tools. Future value-added NGN
services will be assembled on the fly in a plug-and-play fashion,
drastically reducing the time and effort to develop these services.
Industry fora like Parlay, ETSI SPAN 12, JAIN and 3GPP [10] have
developed open standard Application Programming Interfaces (APIs) to
enable service creation in converged NGNs. While services can be
developed in traditional programming languages (e.g. Java or C++)
using these APIs, XML-based [4] scripting languages and its suite of
related technologies such as XSL [7], XSLT [5] and XML Schema [6]
allow one to write services more rapidly and easily. While not as
flexible or powerful as a programming language, XML-based scripting
languages are typically easier to learn, and are language and
platform independent.
For example, the value of the JAIN Java Call Control (JCC) API [11,
12, 13, 14] on a softswitch is that it hides the heterogeneity of
underlying networks (PSTN, IP) as well as signaling protocols (SIP,
H.323, ISUP etc.) and provides a powerful API for developing
services. A programmer is spared the complex and tedious details of
protocol timing, error recovery and state handling. The value of
the SCML scripting facility, on top of a Parlay or JAIN API in this
example, is that it provides language-independence and allows simple
services to be created quickly by programmers who are not
necessarily telecommunications experts.
The Parlay, ETSI SPAN 12, JAIN and 3GPP APIs offer convenient,
standardized, network-independent, high-level access to multiple
network capabilities, such as call control or user location. For
convenience, we assume each distinct capability is offered by a
distinct logical entity called a Capability Server. The SCML suite
of schemas will have separate schema defined per capability server.
These schemas are defined in such a fashion that they can be used
effectively together; for example, a developer must be able to use
Call Control and Mobility primitives in one script even though the
Call Control and Mobility primitives are each defined in independent
XML Schemas.
The next sections will discuss the system architecture for the
deployment and execution of SCML scripts.
Bakker, Jain Informational, May 2002 2
A Service Creation Markup Language November, 2001
for scripting Next Generation Network Services
1.1 Conventions of This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119.
2. SCML architecture components
The SCML Server relies on functionality provided by underlying
Capability Servers. Through SCML scripts the SCML Server subscribes
to events emitted by Capability Servers and processes them when they
occur. Processing typically ends with returning a
response/disposition. Both Servers and Usage Scenarios are further
illustrated in the remainder of this Section.
2.1 Capability Server
In general, there exist endpoints or end systems (such as phones or
PCs) at the edge of the NGN and what we generically refer to as
"capability servers" in the core of the network. End systems can
e.g. contribute in providing location information, originate calls,
and accept, reject, or forward incoming calls. On the other hand,
call servers (specializations of capability servers) can perform the
following operations on a call. They can be in:
+ proxy mode: forward the call on to one or more other capability
servers or end systems, subsequently calculating what to do with any
responses received.
+ redirect mode: informing the network of an alternate address for
the incoming call.
+ reject mode: inform the sending system that the setup request
could not be completed.
+ 3rd party controller mode: e.g., create a new call through
inviting two or more end systems in a coordinated fashion.
Typically, call servers support applications that may involve
charging, user location, mobility, etc., and thus interact with
other capability systems within the network, e.g. location
databases, billing systems, etc.
The Parlay, ETSI SPAN 12, JAIN and 3GPP OSA initiatives provide API
and information models to the functions provided by capability
servers in the network.
2.2 SCML Server
The SCML Server provides an environment in which SCML scripts can be
deployed and activated. An SCML script conforms to one or more of
the SCML schemas and describes a service.
Bakker, Jain Informational, May 2002 3
A Service Creation Markup Language November, 2001
for scripting Next Generation Network Services
An SCML compliant service script typically consists of SCML
fragments that register interest in specific events and fragments
containing service logic. An example of an event is an incoming
call notification and its parameters. The service logic is executed
following the occurrence of the specified event. Typically, the
logic provides a disposition for the incoming call. Events that can
activate a service are provided by an event source. Capability
servers are examples of event sources, but events may also originate
elsewhere, e.g. from a pre-configured timer.
The SCML service lifecycle consists of the following phases. A
service is created (or authored) resulting in an SCML script. The
service is then deployed, meaning that the script is installed and
any system-level configuration necessary for the service to execute
is carried out. The service is then provisioned, i.e., the
parameters of the service for a particular user are instantiated
(e.g. a userÆs buddy list for an Instant Messaging service is set
up). The service is then activated for a particular user. Finally,
the service can be deactivated for a particular user or undeployed
as a whole. (Clearly, other sequences of deployment, provisioning
and activation can take place, but we will assume the above sequence
for simplicity.)
A service is either authored on behalf of a (group of) end-user(s)
or on behalf of the service provider. An example of a service
authored on behalf of the service provider is one that limits call
origination when resource usage exceeds a certain threshold. An
example of a service authored on behalf of an end-user is one that
executes an intelligent form of call forwarding. SCML schemas can
be used in the authoring process; tools exist that verify compliancy
to XML schemas upon authoring of XML instance documents [* Ref? *].
Service provisioning can be achieved using XSL. XSL transformation
techniques are foreseen to aid in development of classes of
services. A class of service, e.g. call forwarding on busy, needs
only parameters such as the a lists of end users further divided
over groups, and, associated with the groups, addresses to where the
attempted call should be forwarded in case the callee is busy. XSL
rules can then transform this provisioning information into a script
that can be verified by one or more of the SCML schemas.
A service is deployed in the context of a deployer. If the deployer
has negotiated a certain agreement with the capability provider it
is assumed that the service executes according to that agreement.
Agreement breaches and subsequent repercussions are considered out
of scope with respect to the SCML suite of schemas.
SCML scripts can either be interpreted in real-time or can be
compiled offline into object code that is executed. In either case,
the service operates on demand, e.g. in response to an event from a
Capability Server.
Bakker, Jain Informational, May 2002 4
A Service Creation Markup Language November, 2001
for scripting Next Generation Network Services
2.3 Usage scenarios
The SCML suite of schemas would be useful for implementing services
in a number of different scenarios.
End user provisioning
In the most direct approach for creating a service with a SCML, an
end user simply creates a script describing their service. He or
she simply decides what service he or she wants, using an SCML-
compliant script, and then uploads it to a server.
End users could do service authoring or provisioning using web
interfaces. An SCML script could be used as the back-end to such
environments: a web application could create a SCML script on behalf
of a user, and the capability server could then implement the
services without either component having to be aware of the
specifics of the other.
Third party outsourcing
Because a SCML is a standardized set of schemas, it can also be used
to allow third parties to create or customize services for clients.
These scripts can then be uploaded to SCML servers.
Administrator service definition
An SCML script can also be used by system administrators to create
simple services or to describe policy for capability servers they
control.
3. SCML architectural environment
Figure 1 depicts the SCML environment, which includes the following
logical entities. (Note that some of these may be physically co-
located.):
1. Capability Server (e.g. SCF or softswitch), which executes the
commands issued by the SCML service logic, interacts with the
entities in the IP domain (e.g., the Gateway and SCML Server)
through the Client, and instructs the underlying transport network
elements on how to disposition the responses.
2. Client, which is responsible for receiving requests from the
Capability Server as well as sending responses back to it. It may
be co-located with the Capability Server. If not, it communicates
with the SCF over the C interface. In addition, it receives
requests from the Gateway and relays them to the Capability Server.
Bakker, Jain Informational, May 2002 5
A Service Creation Markup Language November, 2001
for scripting Next Generation Network Services
3. Gateway, which serves as an intermediary between the Server and
Client via the A and B interfaces, respectively.
4. SCML Server, which executes SCML scripts, issues requests to be
executed on the Capability Server, and terminates requests or events
from the Capability Server.
3.1 Service execution example
An example instance of this architecture is as follows. The SCML
server consists of software residing at a subscriberÆs machine in an
enterprise environment. The enterprise machine is connected via a
firewall to a Gateway. The Gateway in turn communicates via a
private IP network to a softswitch with e.g. a JAIN Java Call
Control (JCC) API. The enterprise subscriber creates an SCML
service script for intelligent call forwarding using an off-the-
shelf SCE. The script is deployed, provisioned and activated at the
SCML server.
The script registers interest in incoming call events. Suppose the
softswitch records an incoming call event e.g. via an incoming SIP
invite message. The softswitch generates a JCC event, which is
converted by the Client into e.g. an XML message delivered over
SPIRITS to the SCML server via the Gateway. The SCML server
executes the forwarding service script, and returns an XML message
to the Gateway instructing that the call be forwarded to a different
number. The Gateway converts the XML message to a JAIN JCC method
invocation on the softswitch, which in turn issues the SIP
redirected message.
The rest of the Section describes the entities Capability Server and
SCML Server, and the interfaces between the entities in detail.
These interfaces could well be populated with 3GPP/Parlay/ETSI/JAIN
APIs or the IETF SPIRITS protocol. These interfaces are relevant to
SCML as they constrain the capabilities that can be used within to
SCML-compliant scripts.
3.3 Interfaces
3.3.1 Interface A
This interface serves three main purposes: 1) to notify the
subscriber of an event previously registered for; 2) to send to the
Gateway the script's disposition of the call; and 3) to issue
commands to initiate services (e.g. to initiate a call).
+----------------+
| Subscriber's |
| IP Host |
| | +------------+
| +------------+ | | |
Bakker, Jain Informational, May 2002 6
A Service Creation Markup Language November, 2001
for scripting Next Generation Network Services
| | SCML | | A | Gateway |
| | Server |********************| |
| | | | +------------+
| +------------+ | *
+----------------+ *
* B
*
*
+++++++++++ Managed IP / PSTN / PLMN ++++++++++++++++++++
*
*
+--------------+
| Client |
+---+----- C ---------+--+
| |
| Capability Server |
| e.g. SCP/Softswitch|
| |
+-------------------------+
Figure 1: SCML Architecture
3.3.2 Interface B
This interface is used for communications between the Client and
Gateway. The Gateway may in turn communicate with the SCML Server,
or may act as a virtual server, terminating the requests without
sending them down to the Server.
3.3.3 Interface C
This interface is for communications between the Client and the
Capability Server (e.g. SCP or softswitch). Specifically, from the
SCP to the SPIRITS Client, the parameters associated with the
applicable IN triggers are sent. From the SPIRITS Client to SCP,
the subscriber's call disposition is sent. The SCP "transforms" the
user's disposition into appropriate actions, such as playing an
announcement to the caller, and resuming the suspended call
processing.
4. SCML Schema Examples
This version of the Internet Draft does not present the definitive
XML Schema underlying SCML as it is still under definition.
However, in this section we give examples of the SCML schema and a
simple SCML script.
The SCML Call Control XML Schema is defined using an XML Schema that
is derived from JCC. JCC provides an API to pure call control
related capabilities and can support traditional A/IN [8] services
as well as NGN services such as Click-to-Dial, and is independent of
Bakker, Jain Informational, May 2002 7
A Service Creation Markup Language November, 2001
for scripting Next Generation Network Services
the underlying network. JCC is truly protocol agnostic and can be
mapped on top of SIP [*REF*], INAP, ISUP, and H.323 [*REF*].
sip:smith@voicemail.example.com
Figure 2, Example SCML Fragment: Voicemail on Busy
An example script in SCML is shown in Figure 2 for the Voicemail on
Busy service. In this script the activation criteria are more
elaborate and are registered with the call server. The criteria are
the calleeÆs address, the fact that it concerns the terminating
portion of the call, and the condition that call setup disconnects
due to a busy callee. If these criteria apply, the scripts will be
executed and the call will be redirected through specifying an
alternative target address. The arguments XML node may contain more
XML nodes, e.g. redirected address node. If such nodes are not
specified, the call server is assumed to provide the appropriate
values; in case such arguments are given the NIL value, the call
server will clear existing values.
Figure 3, Example SCML Fragment: Wake Up Call
The example in Figure 3 is included to demonstrate some more
advanced features of SCML. It shows a Wake Up Call application; an
end user is called each weekday morning at 6:00h and she can briefly
recover from waking up while listing to some music. The script
creates a call, routes it or notifies the end-user in case of
failure by sending e-mail. As the script is not activated by an
originating or terminating fragment of call, the scripts has to
explicitly reference the call resources. The XML node
creates a call resource identified as ææwakeupCallÆÆ and the node
routes the call, where the connection routed to
wakeup.com is identified as ææwakeupMusicConnectionÆÆ.
As mentioned before, a simpler script that is converted using XSL
rules could generate the SCML in the Wake Up Call example. The
examples given only demonstrate the call control service. As at the
time or writing only the JAIN JCC API and Reference Implementation
is publicly available [*REF*], the SCML versions of other services,
such as mobility management or user interaction, have not yet been
attempted. Nevertheless, it is the intention to allow interworking
between the Call Control SCML and other XML schemas within the
telecommunication domains to enable scripting of feature-rich
services.
5. SCML script lifecycle and execution
A script can run in a SCML server. It controls the server's or
endpoint's functions: proxying (in case of a call server),
redirecting, originating, or rejecting calls. The default behavior
is in effect until processing in the call server completes, or a
script takes over control (and disposition) of that call e.g. in a
manner similar to triggers in A/IN. A script controls the call
based on the information made available through other functional
interfaces and based on settings controlled by the subscriber
(settings coded as rules in the script itself).
Typically, telecommunications scripts/applications are associated
with an address, subscriber information, a point in call (let be in
the originating and/or terminating portion of a call), and have
access to auxiliary information such as location data through
mobility management servers or an Interactive Voice Response (IVR)
unit. Note that there may also exist applications that are not
Bakker, Jain Informational, May 2002 9
A Service Creation Markup Language November, 2001
for scripting Next Generation Network Services
call-based. For example, an application that continuously tracks
the whereabouts of end users for administration purposes is not
necessarily activated through call-based conditions. For
illustrative purposes, the remainder of this section assumes call-
based scripts. However, the concepts discussed in the remainder can
easily be generalized and applied for activation of non-call based
scripts.
Three phases in the lifetime of a script have been discussed:
authoring, deployment, and activation. In the authoring phase the
script is created by a variety of possible means including XML tools
(e.g. XML or XSL editors, XSLT), direct input using a general-
purpose text editor, or an XML add-on to a traditional PSTN SCE. In
the deployment phase the script is validated for syntax and
executability, and stored in a repository if valid. An offline
service management program can query the repository and activate the
script by downloading it for execution to a specialized XML
processing engine (in this case, an SCML processor) that may have at
its disposal a library of basic scripts. The criteria for invoking
the script are checked by a criteria checker. The criteria may
consist of an A/IN style trigger or a JAIN/Parlay event in the call-
processing platform that is in turn caused by underlying signaling
events. Alternatively, the criteria may consist of other activation
conditions, such as time-based activation (e.g. Wake Up Call) or
activation from other elements (e.g. Click-to-Dial scenarios or IVR
interactions). As the script executes, it may in turn issue
commands to the call server e.g. after performing a number
translation or redirecting a call.
Note that access by the scripts to the call-processing platform is
expected to be restricted to authorized subscribers only.
Subscribers are supposed to engage in a trusted relationship with
the provider of the services. The Parlay Framework and JAIN Service
Provider API (SPA) provide means to manage and control this access.
The details of such authorization schemes may vary from
administrative domain to administrative domain and are not in scope
for this paper.
Scripts can have unwanted interactions within a system and between
systems. Let us discuss the case in which scripts within a system
interact. Assume a script S1 with activation conditions A and a
script S2 with activation conditions B. Assume S1 changes the
conditions such that B is satisfied and, consequently, S2 is invoked
upon termination of S1. S2, however, changes the conditions such
that A is satisfied and, consequently, S1 is invoked again upon
termination of S2. Obviously, the script execution support logic
must monitor for this form of indefinite recursion and take
appropriate corrective and informative actions. Note that it may
very well be the case that the underlying protocols signal such
loops. In general this issue is completely analogous to feature
interaction in A/IN systems and has been widely studied. We assume
that resolution of feature interaction is in general outside the
Bakker, Jain Informational, May 2002 10
A Service Creation Markup Language November, 2001
for scripting Next Generation Network Services
SCML itself, although an SCE could provide some support if so
desired.
6. Relationship with existing Service Creation approaches
This section focuses on some existing service creation solutions
such as the Parlay APIs, the JAIN APIs, and IETF's CPL [15, 16] and
SPIRITS. Note that SCML is also considered within the JAIN SCE
Working Group.
The Parlay and JAIN APIs constitute a service enabling environment.
The information model at the basis of Parlay and JAIN has large
overlap. The Parlay and JAIN APIs both offer object-oriented APIs
with many similar objects and methods and common underlying
capabilities. While there are some differences in details between
the APIs a service written for one is substantially similar to a
service written for the other. The SPIRITS protocol work indicates
that it aims at carrying the Parlay and JAIN defined events and
dispositions between SPIRITS clients and servers. Therefore,
SPIRITS is a suitable carrier for events between the capability
server and SCML server.
The Parlay and JAIN APIs abstract capability servers found in the
NGN. SCML complements these APIs a scripting language that greatly
simplifies the creation of services; the language is bound by the
capabilities offered by the capability servers. Through using XML
as the scripting language, a wealth of tools and developers becomes
available. Additionally, XML in combination with XSL gives
operators flexibility enabling new classes of services and their
outsourced authoring.
SCML is functionally richer than CPL, since it allows third-party
call control while CPL does not. Also, since it is related to the
APIs (such as JAIN Call Control) standardized by industry fora, it
is truly protocol and network independent. CPL as currently defined
interacts with call servers or other network servers that provide
mobility or user interaction functions. In contrast, SCML is
intended to work harmoniously with the suite of APIs defined by the
Parlay and JAIN groups that include a variety of functional
interfaces. Finally CPLÆs specification methodology is to use XML
DTDs, while SCML is defined using XML Schemas. The latter provide
not only language conveniences but are type safe and allow the
programmer to define, restrict, redefine and extend data types in a
manner similar to inheritance in object oriented programming
languages. Since the Parlay and JAIN APIs make extensive use of
inheritance this last capability is especially useful.
7. Security Considerations
Security issues are at play in many aspects from the SCML authoring
to activation life cycle. For starters, during script authoring the
Bakker, Jain Informational, May 2002 11
A Service Creation Markup Language November, 2001
for scripting Next Generation Network Services
script author should only use capabilities that are negotiated.
Fortunately, this can be ensured through a proper selection of SCML
schemas, possibly further constraining them through schemas that can
be transformed to SCML schemas using XSL.
During the deployment process scripts may be transported and stored.
This transport process and subsequent storage should be secured such
that non-authorized people are not capable of tampering with the
script or even reading it. Prior to deployment, the deployer should
be authenticated. Additionally, prior to registering the events
that activate the script, the deployment process should make sure
that SCML schemas referred to by this script are authorized for
usage by the deployer.
Finally, activated scripts should not be able to compromise the
integrity of the underlying capability servers and networks. To
protect the capability servers, they should meter and time the
script's activity and resource usage. As indicated earlier, service
agreements are supposedly in place between the capability servers
and the SCML servers. In the event of a service agreements breach
(e.g. timed out resource usage), the capability server should resort
to default procedures.
A. Authors' Addresses
John-Luc Bakker
Telcordia Technologies
445 South Street
Morristown, NJ
USA
Phone: 1-973-829-5062
Email: jbakker@telcordia.com
Ravi Jain
Telcordia Technologies
445 South Street
Morristown, NJ
USA
Phone: 1-973-829-3178
Email: rjain@telcordia.com
B Bibliography
[1] Sun Microsystems, ææJAIN Service Creation Environment (SCE) API
Java Specification Request (JSR) 100ÆÆ, 2001. See
http://jcp.org/jsr/detail/100.jsp
[2] Sun Microsystems, ææThe JAIN APIs: Integrated Network APIs for
the Java PlatformÆÆ, June 2001. See
http://java.sun.com/products/jain/WP2001.pdf
Bakker, Jain Informational, May 2002 12
A Service Creation Markup Language November, 2001
for scripting Next Generation Network Services
[3] Sun Microsystems, ææThe JAIN APIsÆÆ, August 2001. See
http://java.sun.com/products/jain/
[4] W3C, ææExtensible Markup Language (XML) 1.0 (Second Edition)ÆÆ,
W3C Recommendation, October 2000. See http://www.w3.org/TR/REC-xml
[5] W3C, ææXSL Transformations (XSLT) Version 1.0ÆÆ, W3C
Recommendation, November 1999. See http://www.w3.org/TR/xslt
[6] W3C, ææXML Schema Part 0: PrimerÆÆ, W3C Recommendation, May 2001.
See http://www.w3.org/TR/xmlschema-0/
[7] W3C, ææExtensible Stylesheet Language (XSL), Version 1.0ÆÆ, W3C
Proposed Recommendation, August 2001. See http://www.w3.org/TR/xsl
[8] IEC: International Engineering Consortium, ææIntelligent Network
(IN)ÆÆ. See http://www.iec.org/online/tutorials/in
[9] The Parlay Group. See http://www.parlay.org
[10] The 3rd Generation Partnership Project (3GPP) Open Services
Architecture (OSA). See http://www.3gpp.org.
[11] Sun Microsystems, ææJAIN Java Call Control (JCC) API Java
Specification Request (JSR) 21ÆÆ, 2001. See
http://jcp.org/jsr/detail/21.jsp
[12] Telcordia Technologies, Inc., ææJAIN @ TelcordiaÆÆ, JAIN
Reference Implementations download site, 2001. See
http://www.argreenhouse.com/JAINRefCode/
[13] Jain, R., J.-L. Bakker and F. Anjum, ææJava Call Control (JCC)
and Session Initiation Protocol (SIP),ÆÆ J. IEICE, to appear, 2001.
[14] Sun Microsystems, ææJAIN Java Coordination And Transaction
(JCAT) API Java Specification Request (JSR) 122ÆÆ, 2001. See
http://jcp.org/jsr/detail/122.jsp
[15] Lennox, J. and H. Schulzrinne, ææCall Processing Language
Framework and RequirementsÆÆ, May 2000, See
http://www.ietf.org/rfc/rfc2824.txt
[16] Lennox, J. and H. Schulzrinne, ææCPL: A Language for User
Control of Internet Telephony ServicesÆÆ, (work in progress) November
2000. See http://www.ietf.org/internet-drafts/draft-ietf-iptel-cpl-
04.txt
[17] Internet Engineering Task Force (IETF) Working Group Charters,
SPIRITS Working Group, 2001. See
http://www.ietf.org/html.charters/spirits-charter.html
Bakker, Jain Informational, May 2002 13
A Service Creation Markup Language November, 2001
for scripting Next Generation Network Services
C. Acronyms
3GPP Third Generation Partnership Project
API Application Programming Interface
OSA Open Service Access
DTD Document Type Definition
OMG Object Management Group
IDL Interface Definition Language
PSTN Public Switched Telephone Network
PLMN Public Land Mobile Network
CPL Call Processing Language
SPIRITS Services in the PSTN/IN Requesting InTernet Services
XML eXtensible Markup Language
XSD XML Schema Definition
XSL Extensible Stylesheet Language
XSLT Extensible Stylesheet Language Transformations
JAIN Java APIs for the Integrated Network
NGN Next Generation Network
SCML Service Creation Markup Language
SCE Service Creation Environment
D. Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into followed, or as
required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgements
Bakker, Jain Informational, May 2002 14
A Service Creation Markup Language November, 2001
for scripting Next Generation Network Services
This work was inspired by similar Telcordia work done Phil Ber. The
work assumes Capability Servers that information models that can
support the JAIN or 3GPP/Parlay/ETSI APIs. Additionally, when
writing the Internet Draft, a good deal of inspiration was drawn
from the CPL and SPIRITS work.
Bakker, Jain Informational, May 2002 15