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