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*].   
         
           <scml> 
            <terminating> 
             <address-switch field=ÆÆterminatingÆÆ> 
              <address is=ÆÆsip:smith@phone.example.comÆÆ> 
               <disconnected causeCode="CAUSE_BUSY"> 
                <routeCall connectionPtr="conC"> 
                 <arguments> 
                  
           <targetAddress>sip:smith@voicemail.example.com</targetAddress> 
                 </arguments> 
                </routeCall> 
               </disconnected> 
              </address> 
             </address-switch> 
            </terminating> 
           </scml> 
            
                     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. 
         
           <scml> 
            <invocation> 
             <time-switch> 
              <time freq="weekly" byday="MO,TU,WE,TH,FR" 
           dtstart="20010101T060000"> 
               <createCall callPtr="wakeupCall"/> 
               <routeCall callPtr="wakeupCall" 
           connectionPtr="wakeupMusicConnection"> 
                <arguments> 
                 
           <targetAddress>sip:jones@bedroom.phone.home.com</targetAddress> 
                 
           <originatingAddress>sip:jones@music.wakeup.com</originatingAddres
           s> 
                 <originalCalledAddress xsi:nil="true"/> 
                 <redirectingAddress xsi:nil="true"/> 
                </arguments> 
                <failed> 
      
     Bakker, Jain               Informational, May 2002                        8 
                         A Service Creation Markup Language      November, 2001 
                 for scripting Next Generation Network Services 
      
                 <mail 
           url="mailto:jones@home.com?subject=wake%20up%20failed"/> 
                </failed> 
               </routeCall> 
              </time> 
             </time-switch> 
            </invocation> 
           </scml> 
            
                        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 <createCall> 
        creates a call resource identified as ææwakeupCallÆÆ and the node 
        <routeCall> 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