Internet DRAFT - draft-adwankar-netconf-symple

draft-adwankar-netconf-symple






Network Working Group                                Sandeep Adwankar
Internet-Draft                                           Motorola, Inc.
Expires: April 20, 2004                              Venu Vasudevan
                                                         Motorola, Inc.
						     Sangita Mohan
                                      University Of Illinois at Chicago                                                         
                                                     October 20, 2003

	SYMPLE Scripting Protocol and architecture for seamless
	management of XML based mobile devices and SNMP based devices
		draft-adwankar-netconf-symple-00.txt
                
Status of this Memo

   This document is an Internet-Draft and is subject to 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.

   This Internet-Draft will expire on April 20, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2003). All Rights Reserved.

Abstract

   
   There is a need for XML based scripting mechanism that allows
   ease of script construction and delegation with standardized
   mechanism. A management script composed of a set of instructions
   will allow periodic, coordinated and policy based management action.
   This memo describes a method of expressing management script and
   architecture for seamless management of XML based mobile devices
   along with SNMP based devices. 
   






 adwankar et al          Expires April 20, 2004             [Page 1]

 Internet Draft        SYMPLE Scripting Protocol     October 20, 2003






Table of Contents


   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . .   3
   2.    Architecture . . . . . . . . . . . . . . . . . . . . . . .   4
   3.    SYMPLE Protocol . . . . . . .  . . . . . . . . . . . . . .   6
   3.1   SyncML Introduction .. . . . . . . . .  . . . . . . . . .    6
   3.2   Synclet . . . . . . . . . . . . . . . . . . . .  . . . . .   7
   3.3   Synclet Engine. . . . . . . . . .  . . . . . . . . . . . .   9
   4     SYMPLE Commands. . . . . . . . . .  . . . . . . . . . . .   10
   4.1   Policy Commands. . . . . . . . . .  . . . . . . . . . . .   10
   4.1.1 Guard Policy Element. . . . . . . . . .  . . . . . . . . .  10
   4.2   Action Commands. . . . . . . . . .  . . . . . . . . . . .   12
   4.2.1 Schedule Element. . . . . . . . . .  . . . . . . . . . . .  12
   4.2.2 Diagnostics Element. . . . . . . . . .  . . . . . . . . . . 14
   4.2.3 Log Element. . . . . . . . . .  . . . . . . . . . . . . .   15
   5.    Seamless Management. . . . . . . . . .  . . . . . . . . .   16
   5.1   Multi-Protocol Gateway . . . . . . . . . . . . . . . . . .  17
   5.2   Seamless Management Flow. . . . . . . . . .  . . . . . . .  19
   6.    Conclusion. . . . . . . . . .  . . . . . . . . . . . . . .  21
   7.    Security Considerations . . . . . . . . . .  . . . . . . .  21
         References . . . . . . . . . . . . . . . . . . . . . . . .  22
   A.    SYMPLE DTD. . . . . . . . . .  . . . . . . . . . . . . . .  22
   B.    Management tree to MIB Mapping. . . . . . . . . .  . . . .  23




























 adwankar et al          Expires April 20, 2004             [Page 2]

 Internet Draft        SYMPLE Scripting Protocol     October 20, 2003








1. Introduction


   The SYMPLE (SYncML Programming LanguagE) is a SyncML-derived
   scripting language that extends SyncML semantics [1][2] in a
   lightweight manner suitable for resource-constrained devices. The
   SYMPLE provides support for the scheduling, evaluation and lifecycle
   management of scripts called as Synclets. To strike a balance
   between capabilities and deployment costs, SYMPLE is designed
   according to the following principles:
   
   1. Embeddable within SyncML. SYMPLE scripts can be embedded within
   standard SyncML packages, allowing reuse of SyncML as a script
   distribution protocol. 
   2. Lightweight. SYMPLE is easy-to-learn, requiring only a small
   amount of code to define complex requirements that can be
   interpreted by a lightweight extension of SyncML platform.
   3. Extensible. Devices can support different variants of Symple in
   accordance with their resources and computing capabilities,
   with Synclets being discarded without error by SYMPLE-unaware
   (but SyncML-aware) devices.  
   
   There is a need to manage SYMPLE based mobile devices from widely
   used management protocol such as SNMP[3][4]. This allows problem
   diagnostics involving combination of mobile and non-mobile devices.
   The manager can initiate software upgrade that spans mobile and 
   non-mobile devices. It allows manager to install and configure 
   enterprise applications simultaneously.
   
   The architecture allows use of conventional enterprise management
   protocol such as SNMP as the unified management platform, while at
   the same time supporting a diversity of management protocols. This
   allows a unified view of the enterprise without expecting enterprise
   management agents to be supported on mobile devices. The method
   uses a multi-protocol gateway that translates between the management
   operations dispatched from a management station, and the specific 
   management protocol that enacts it. 

   The rest of the document is organized as follows. Section 2 
   introduces the architecture of the SYMPLE for management scripting
   and seamless management of devices that support different protocols.
   Section 3 introduces synclet that extends SyncML DM. Section 4 
   describes various Symple commands with examples. Section 5 details 
   multi-protocol gateway and seamless management flow.






 adwankar et al          Expires April 20, 2004             [Page 3]

 Internet Draft        SYMPLE Scripting Protocol     October 20, 2003




2. Architecture



   +------------------------------------------------------------+
   | +--------------+                                           |
   | | SNMP         |                                           |
   | | MIB          |                                           |
   | +--------------+                                           | 
   |       ^                                                    |
   |       |                                                    |
   |       v                                                    |
   | +-------------+    +----------------+     +-------------+  |
   | | SNMP        |    | Multi-Protocol |     | SYMPLE      |  |
   | | Manager     |<-->| Gateway        |<--> | Manager     |  |                       
   | +-------------+    +----------------+     +-------------+  |
   |       ^                                         ^          |
   |       |                                         |          |
   |       v                                         v          |
   | +----------------+                      +----------------+ |
   | |                |                      |                | |
   | | +------------+ |                      | +------------+ | |
   | | | SNMP       | |                      | | SYMPLE     | | |
   | | | Management | |                      | | Management | | |
   | | | Agent      | |                      | | Agent      | | |
   | | +------------+ |                      | +------------+ | |
   | |----------------|                      |----------------| |
   | |                |                      |                | |
   | |                |                      |                | |
   | |  Non-mobile    |                      |    Mobile      | |
   | |  Device        |                      |    Device      | |
   | |                |                      |                | |
   | +----------------+                      +----------------+ |
   +------------------------------------------------------------+

   As shown in figure above, the universal manager spans the network
   controlled by the enterprise and a core communications network such
   as the Internet to manage devices connected to each of these 
   networks. A user controlled PAN in this case is considered part of
   the enterprise network. Enterprises maintain Management Information
   Base (MIB) [6] that consists of collection of managed objects for
   each type of enterprise device. The enterprise management system
   (EMS) provides a complete view of entire enterprise including all
   devices, hosts and routers in the enterprise. 










 adwankar et al          Expires April 20, 2004             [Page 4]

 Internet Draft        SYMPLE Scripting Protocol     October 20, 2003

   SNMP based devices are located through discovery mechanisms and the
   SNMP Manager directly executes the requested management action.
   Mobile devices advertise their presence with their capabilities data
   to the multi-protocol gateway. The multi-protocol gateway acts as a
   proxy and represents mobile device to the SNMP manager. The 
   management action on a mobile device will be routed through 
   the multi-protocol gateway. 

   A mobile device has a SYMPLE terminal management (TM) agent that is
   customized for its capabilities. The TM agent has access to firmware
   specific details and can perform management operations such as
   getting or setting configuration data, software image installation,
   and fault and security management. The TM agent talks with a SYMPLE
   Manager using a protocol that the device can support. For example a
   mobile device that supports only Short Message Service (SMS), 
   management actions and results/responses are sent over SMS between
   TM agent and TM server.

   The multi-protocol gateway maps the destination of a management
   action to a particular mobile device. For example the multi-protocol
   gateway advertises a GSM terminal with International Mobile
   Equipment Identity (IMEI) "000000011234564" as IP address 
   10.1.100.212 in the enterprise network. For management action of
   mass software upgrade for all devices in 10.1.100 subnet, the 
   management action destined for 10.1.100.212 is routed to the 
   multi-protocol gateway. The multi-protocol gateway then maps it
   to the corresponding IMEI and from the capabilities data of the
   device, it converts management action Protocol Data Unit (PDU) to
   terminal management protocol specific PDU. The multi-protocol
   gateway then schedules the management action on the corresponding
   SYMPLE manager. The SYMPLE manager participates in management
   protocol exchanges with terminal management agent to perform
   management action such as software upgrade. The multi-protocol
   gateway converts management atomicity requirements to individual
   device protocol levels as shown table below.


   +-----------------------------------------------------------------+
   |   Entity       |          Atomic Operation                      | 
   +----------------+------------------------------------------------+
   |   Device       | Device software upgrade with change in         | 
   |                | corresponding configuration.                   |
   +----------------+------------------------------------------------+
   |   Group        | Changes in group protocol such as multicast.   |
   +----------------+------------------------------------------------+
   |   Enterprise   | Business process change.                       |
   +----------------+------------------------------------------------+










 adwankar et al          Expires April 20, 2004             [Page 5]

 Internet Draft        SYMPLE Scripting Protocol     October 20, 2003




   The following characteristics make this architecture scalable: 
      o    Support for diverse terminal management protocols
      o    Distributed terminal management servers based on protocols          
           supported
      o    Scheduling management actions on SYMPLE Manager based on 
           availability of resources
      o    Terminal management agent specific to a device based on
           hardware, software capabilities
      o    Using layer 2 routing to advertise presence of  
           intermittently connected devices


3   SYMPLE Protocol

   The SYMPLE provide the ability to postpone management operations, 
   to allow effective completion of operations. It allows
   schedule coordinated terminal management operations across 
   collections of terminals. It adds a powerful computing abstraction
   to SyncML-DM to facilitate comprehensive, automated, scalable
   systems management.  For growing number of sophisticated mobile
   devices scripting allows optimized local management actions. 


3.1 SyncML Protocol Introduction

   The SyncML standard was developed as an XML-based information 
   synchronization standard designed specifically for the needs of the 
   wireless industry. Thus, the SyncML protocol is lightweight to cater 
   to device limitations, language-neutral and protocol-neutral.  To 
   suit device limitations, SyncML language constructs are kept fairly 
   minimal, with the protocol not using some features (e.g., server 
   sockets) that are yet to become pervasive on mobile devices. Because 
   SyncML is XML-based, it is inherently language-neutral, and supports 
   OEM-specific extensibility. In addition, the SyncML protocol can 
   run over a number of underlying transport protocols including HTTP, 
   WSP, and OBEX.

   SyncML's popularity in information synchronization led to its scope 
   being expanded via SyncML-DM to include device management. SyncML-DM 
   allows management actions to be performed on management objects, 
   where a management object might represent a device configuration or 
   the run-time software application environment. Actions taken against 
   the former might include reading and setting parameter keys and 
   values, while actions taken against the latter might include
   installing, upgrading, or uninstalling software elements. The 
   signatures of the Get and Set methods on a management object are 
   type-specific and may vary substantially in complexity.  For 
   instance, a management action for setting the device clock accepts a 
   simple textual MIME type (text/plain) while an action to change the 
   WAP browser settings requires new WAP provisioning blobs to be 
   transmitted as part of the Set operation. Software upgrades present 
   another example of a management action with significant payload 


 adwankar et al          Expires April 20, 2004             [Page 6]

 Internet Draft        SYMPLE Scripting Protocol     October 20, 2003

   complexity.



   As shown in Figure below, SyncML-DM is a 2-phase protocol consisting of 
   a setup phase for authentication and device information exchange, 
   followed by a management phase that can be repeated multiple times
   to support complex manager-to-mobile sessions. A management session 
   may also start with Packet 0 (the trigger), where the trigger may be 
   out-of-band depending on the environment.


   Mobile Device                                   Management Server

        |                                                  |
        |                                                  |
        |<-------------------------------------------------|
        |    Package 0: Alert from server                  |
        |                                                  |
        |------------------------------------------------->|
        |    Client initialization with client             | Setup
        |    credentials and device information            | Phase
        |<-------------------------------------------------|
        |    Server initialization with server             |
        |    credentials and management operations         |
        |------------------------------------------------->|
        |    Client response to management operations      | Mgmt
        |                                                  | Phase
        |<-------------------------------------------------|
        |    Server response to client management          |
        |    operation, and more management operations     |
        |    if session is to be continued                 |
        |                                                  |
        


 
   
3.2 Synclet

   A Synclet is an executable script consisting of Symple commands. 
   A Synclet specification comprises of two parts: a policy and an
   action routine. The Synclet policy specifies non-functional aspects
   of the Synclet such as if, when and how often it should be executed.
   The action routine is the management script that makes up the Synclet. 
   The policy, action routine separation allows the same functional
   Synclet to be reused in different circumstances. 
  









 adwankar et al          Expires April 20, 2004             [Page 7]

 Internet Draft        SYMPLE Scripting Protocol     October 20, 2003





 
   The figure below shows the architecture of Symple management agent.
   As shown in the figure the policy engine enforces policy that can
   act as trigger condition for synclet. The Symple parser along with
   XML parser parses the SyncML package (that encapsulates synclets)
   received by the device. The result of parsing is a set of synclets
   that are interpreted and executed by the Synclet Engine. 
   

                      +---------------------+
                      |  Synclet Engine     |
                      |                     |                   
                      +---------------------+
                      |  Policy Engine      |
                      |                     |
                      +---------------------+
                      |  Sync Engine         |
                      |                     |     
                      +---------------------+     
                      |  Symple Parser      |     
                      |                     |     
                      +---------------------+     
                      |  XML Parser         |  
                      |                     |  
                      +---------------------+
                      |  Firmware           |
                      |                     |
                      +---------------------+   
      
   Synclets are transported over the SyncML protocol, which in turn is
   bearer-agnostic. Thus Synclets may be transported over HTTP, SMTP or
   other IP-based protocols. To be compatible with Synclet unaware
   clients, Synclets are carried as the payload i.e., as nested tags 
   in a Synclet XML element within the SyncML body. Standard SyncML
   engines that are not Synclet-enabled will simply ignore the Synclet
   scripts within the enclosing Synclet tags. As Synclet upload and
   execution are decoupled, multiple Synclets with differing execution
   policies may be carried in a single SyncML session, i.e. nested
   within the same Synclet tag.

   Synclet bundles are a convenience mechanism that allows a group of
   Synclets to be loaded in a single SyncML session, and be henceforth
   accessed by the remote operator using a single bundle name. The
   bundle notion facilitates packaging, distribution and policy
   management of Synclets.








 adwankar et al          Expires April 20, 2004             [Page 8]

 Internet Draft        SYMPLE Scripting Protocol     October 20, 2003


3.3 Synclet Engine

   Synclet Engine is terminal resident container layered over the
   standard client-side Sync Engine. They host and manage Synclets that
   are dispatched to the terminal. Synclet Engine perform functions
   relating to Synclet lifecycle management, and serve as secure
   sandboxes for Synclet execution. Lifecycle functions include 
   (de) activation, multitasking between concurrently executing
   Synclets, and the suspension and the revival of Synclets that were
   stopped due to adverse terminal conditions (e.g. deteriorating 
   battery level). To avoid race conditions on the device, Synclet
   Engine support virtual multitasking where multiple terminal-resident
   Synclets might have partially executed at any point in time, but
   only one Synclet is actually executing at any instant.
   
   The SYMPLE specifications include a model of conditional,
   policy-based execution. The policy engine determines the subset of
   Activatable Synclets based on evaluating individual Synclet
   policies. Policies could be based on absolute time, invocation
   cardinality (number of times a Synclet should be run), and device
   state. More sophisticated Synclet Engine could support the
   interleaved execution of multiple synclets. These could include
   allowing a certain maximum number of concurrent synclets, deadlock
   avoidance or resolution between concurrent synclets, and fairness
   policies for Synclet swap-out whereby idle synclets are swapped out
   for other waiting synclets.
   
   Synclet Engine provide a constrained environment to executing synclets,
   bounding and monitoring their access to the underlying terminal.
   Synclets are privileged applications have limited access to
   retrieving and modifying the device state via a special set of
   closed classes in Java. Two factors simplify sandboxing in Synclet.
   First, the Synclet dispatching capability is accessible only to a 
   small number of trusted parties (namely service operators). So 
   authentication solutions such as digital signatures can check the 
   signature against a very small universe of trusted sources.  
   Secondly, the use of a scripting language allows for language safety
   verifiers to be developed, and for sandboxes to suspend (and resume)
   the script at arbitrary points in the program.
   
   Synclets face the unique situation in executing on mobile 
   devices, namely that the device may be powered off at any time
   without operator control. Synclet Engine lifecycle management
   techniques need to allow for script re-entrancy in such adverse
   situations. Script re-entrancy might involve re-prioritizing
   Synclets when they are restarted, to reflect the new environment
   (analogous to adjusting the nice value of processes in Unix).
   This is handled by re-evaluating Synclet policies of awakening
   Synclets in the changed environment.



  



 adwankar et al          Expires April 20, 2004             [Page 9]

 Internet Draft        SYMPLE Scripting Protocol     October 20, 2003


4  SYMPLE Commands

   This section elaborates on the kinds of policies supported in 
   Symple, and the SyncML extensions supported in an action routine.
   SyncML is extended in two ways in the action routine language: the
   addition of a few new commands, and support for conditional command
   execution (guarded commands) environment.
   

4.1 Policy Commands

   Policies are specifiable at three levels of granularity: device,
   synclet bundle, and synclet. Device level policies apply to all
   scripts that will execute on the device from the time the policy
   is installed. For instance, a device policy may dictate that only
   one Synclet shall be active at a time. Synclet bundle policies apply
   to a collection of synclets that were loaded as an aggregate,
   perhaps because they collectively perform a single cohesive task.
   Synclet policies govern the execution of the Synclet's action
   routine, and may include the maximum time a Synclet is allowed to
   run, resources that should be allocated before the Synclet should be
   activated, or recovery actions when Synclet execution is
   interrupted. Device policies tend to be more static and persistent
   than Synclet bundle and Synclet level policies.

4.1.1 Guard Policy Element

   The semantics of guard policy element is as below:
   Element: <Guard>

   Description:
         Conditionally executes a management action based on result 
         of guard route execution
  
   Parameters:
      Attribute: Management Tree Node URI
      Condition: (greaterThan | lessThan | equals)            
      Threshold: trigger threshold.

   Example1:

   The following synclet is an example of guard policy in which the
   security code is changed only if the device has sufficient energy
   level to satisfy the management action of changing the security
   code.











 adwankar et al          Expires April 20, 2004             [Page 10]

 Internet Draft        SYMPLE Scripting Protocol     October 20, 2003


   +------------------------------------------------------------------+
   |<Synclet>                                                         |   
   |   <Guard>                                                        |
   |      <Attribute> ./DevDetail/EnergyLevel </Attribute>            |
   |	  <Condition> greaterThan </Condition>                        |
   |      <Threshold> 5 </Threshold>                                  |
   |   </Guard>                                                       |
   |   <Replace>                                                      |
   |     <CmdID>1</CmdID>                                             |
   |     <Meta>                                                       |
   |        <Format xmlns="syncml:metinf"> text/plain </Format>       |
   |     </Meta>                                                      |
   |     <Item>                                                       |
   |        <Target><LocURI>./Ext/Settings/Security</LocURI></Target> |
   |        <Data> SECURITY CODE </Data>                              |   
   |     </Item>                                                      |
   |   </Replace>                                                     |
   |<Synclet>                                                         |   
   +------------------------------------------------------------------+


   Example2:

   The following synclet is an example of guard policy in which if the
   App1 execution count is less than 2 then the assetMgmt script is
   downloaded and executed.

   +------------------------------------------------------------------+
   |<Synclet>                                                         |   
   |   <Guard>                                                        |
   |      <Attribute>                                                 |
   |   		./Ext/Applications/App1/ExecutionCount                |
   |      </Attribute>                                                |
   |	  <Condition> lessThan </Condition>                           |
   |      <Threshold> 2 </Threshold>                                  |
   |   </Guard>                                                       |
   |   <Exec>                                                         |
   |     <CmdID>1</CmdID>                                             |
   |     <Meta>                                                       |
   |        <Format xmlns="syncml:metinf"> text/plain </Format>       |
   |     </Meta>                                                      |
   |     <Item>                                                       |
   |        <Target>                                                  |
   |            <LocURI>                                              |
   |               http://www.symple.org/scripts/assetMgmt            |
   |            </LocURI>                                             |
   |        </Target>                                                 |
   |     </Item>                                                      |
   |   </Exec>                                                        |
   |<Synclet>                                                         |   
   +------------------------------------------------------------------+

 



 adwankar et al          Expires April 20, 2004             [Page 11]

 Internet Draft        SYMPLE Scripting Protocol     October 20, 2003



    The above example shows policy based asset management where assets
    on a terminal are managed based on operator defined sets of rules.
    The assets on a device include user data, applications, and user
    purchased applications and games. The operator-defined rules will
    result in managing assets in such a way as that extends the 
    capabilities of the resource constrained devices. The assetMgmt
    script in such a case will transparently back up the asset
    information on the server. The assets are restored to the device
    when they are needed. The backup and restore of assets from
    terminal to server is achieved using extension of SyncML protocol.
    The user and assets are transparent to the asset management
    process. Thus the policy will make the device memory bigger than
    the actual physical memory. With extended memory, device is able to
    hold more assets than that can be possible physically.
 


4.2 Action Commands 
 

4.2.1 Schedule Element

   The semantics of schedule management command is as below:
   Element: <Schedule>

   Description:
      Schedules the management commands specified as per the parameters
  
   Parameters:
      CmdID: Id for the command
      Meta: Meta Information parameters
      Date: Date and Time to schedule the management action
      Period: Interval between schedule operations
      Repeat: Number of times the schedule operation will be repeated
      (Get|Replace|Add|Delete|Exec): Management actions

   Example:

   The following synclet (policy element not shown) is an example of
   management action of periodically scheduling performance management
   operation of gathering network latency information.











   


 adwankar et al          Expires April 20, 2004             [Page 12]

 Internet Draft        SYMPLE Scripting Protocol     October 20, 2003

   +------------------------------------------------------------------+   
   |<Synclet>                                                         |
   |   <CmdID>1</CmdID>                                               |
   |   <Schedule>                                                     |
   |      <CmdID>2</CmdID>                                            |
   |      <Meta>                                                      |
   |         <URI>http://www.symple.org</URI>                         |   
   |      </Meta>                                                     |
   |      <Date>1032795720000</Date>                                  |
   |      <Period>1</Period>                                          |
   |      <Repeat>1</Repeat>                                          |
   |      <Get>                                                       |
   |         <Item>                                                   |
   |            <Target>                                              |
   |               <LocURI>                                           |
   |                  ./Sync/DM/Performance/Network/Latency           |
   |               </LocURI>                                          |  
   |            </Target>                                             |
   |            <Meta>                                                |
   |               <Type xmlns='syncml:metinf'>                       |
   |               application/vnd.syncml-devinf-devicemanagement+xml |
   |               </Type>                                            | 
   |            </Meta>                                               |   
   |        </Item>                                                   |
   |     </Get>                                                       |  
   |  </Schedule>                                                     |
   |</Synclet>                                                        | 
   +------------------------------------------------------------------+

   

   The service performance measurement involves measurement of various
   performance metrics over period of time. The typical measurements
   taken from the device include 
   1.Success Rate in terms of user logons
   2.Delays: Initial access, Round Trip, Server Response Time
   3.Availability: Is Server responding?
   4.Quality: Latency (average), Bandwidth (average)
   5.Report application "performance", e.g. browser/MP3 player reports
     download speed

   In this scenario, the operator sends Synclet to the device that is 
   configured to take measurements, i.e. to monitor local conditions 
   such as local storage usage, application performance, network 
   performance, authentication failures, etc.  At an appropriate time,
   the synclet may initiate a management session in which it would 
   relay such information up to the management server for further 
   processing.

   An example of an application performance measurement is that of web
   page availability.  If the availability of a web page to a mobile
   terminal is guaranteed to be a certain rate, such as 99%, it might
   be desirable to measure the availability of the page from the 
   terminal directly, so as to ensure that an end-to-end measurement 
   is taken.  This is the only way, in fact, to guarantee that that are


 adwankar et al          Expires April 20, 2004             [Page 13]

 Internet Draft        SYMPLE Scripting Protocol     October 20, 2003

   no broken links in the chain of applications, middleware, and 
   network elements between the web server and the terminal.   The 
   terminal could be configured to test the availability of a 
   particular URL periodically.  An exceptional condition, such as that
   network connectivity is available but the particular URL cannot be 
   fetched, might trigger a local event that ultimately causes a 
   management server to be informed of the situation.  Presumably, the
   management server would, upon receipt of this data, present it to an
   administrator who could take action to prevent the service level 
   agreement from being broken, and the service provider losing 
   revenue.

   Such a measurement taken along with GPS coordinates will provide
   operator with "rough" spots in the network. Before any active 
   measurements are taken, the management system may be used to 
   configure the device regarding which measurements to record, as well
   as under which circumstances a management session should be 
   initiated.  In other words, the device may store local measurements
   that are not considered important enough to warrant a 
   client-initiated session with a management server.

   Sometimes the recording of local measurements is equated with the
   generation of local events.  An event might be, for example, that a
   particular measurement exceeds a particular value.  Such an event 
   might be stored locally, possibly for later retrieval by a 
   management server during an explicit diagnostic session in which 
   the administrator wishes to see these events.  Or, a particular 
   event may be important enough (determined by some configuration 
   parameters or a policy) to warrant the client initiating a session
   with a management server.



4.2.2 Diagnostics Element

   The semantics of diagnostics management command is as below:
   Element: <Diagnostics>

   Description:
      Performs multiple checks for various configuration nodes
  
   Parameters:
      Assert: A single check for a configuration node
         Parameters:
            Item: Container with management node URI and desired data	
         
      Exception: Fix for failed check
         Parameters:
            (Replace|Add|Delete|Exec) Management actions
      CatchAll:  Fix for all failed checks      
         Parameters:
            (Replace|Add|Delete|Exec) Management actions
   




 adwankar et al          Expires April 20, 2004             [Page 14]

 Internet Draft        SYMPLE Scripting Protocol     October 20, 2003


   Example:            

   The following synclet (policy element not shown) is an example of
   management action of diagnosing reported problem with browser.
   The diagnostics synclet will perform series of checks with series
   of asserts and will determine cause of problem. For example, if
   there is problem with GPRS settings, it will download web_settings
   and replace existing default web session.

   +------------------------------------------------------------------+
   |<Synclet>                                                         |
   |   <CmdID>1</CmdID>                                               |   
   |   <Diagnostics>                                                  |
   |      <CmdID>2</CmdID>                                            |   
   |      <Assert>                                                    |
   |         <Item>                                                   | 
   |            <Target>                                              |
   |               <LocURI>./Sync/DM/WAP/WAPSTNG1/GPRS_APN</LocURI>   |
   |            </Target>                                             |
   |            <Data>internet.operator.com</Data>                    |
   |         </Item>                                                  |
   |      </Assert>                                                   |
   |      <Exception>                                                 |
   |         <Replace>                                                |
   |		<Item>	                                              |
   |               <Target>                                           |
   |                  <LocURI>./Sync/DM/WAP/DEFAULTWEBSESSION</LocURI>|
   |               </Target>                                          |
   |               <Data>www.symple.org/web_settings</Data>           |
   |            </Item>                                               |
   |         </Replace>                                               |
   |      <Exception>                                                 |
   |   </Diagnostics>                                                 |
   |</Synclet>                                                        |
   +------------------------------------------------------------------+
 


   The diagnostics scenario demonstrates the ability for the customer
   representative to download a diagnostic Synclet into a suspected
   faulty device.  The diagnostics Synclet once downloaded will
   automatically execute and perform perfunctory or sophisticated
   diagnostic checks of the device.  The results of the diagnostic
   checks can be relayed to the customer representative as part of 
   catchall handling who can then better assist the user with their
   problems.
 
 4.2.3 Log Element
 
   The semantics of log management command is as below:
   Element: <Log>

   Description:
      Start or stops logging


 adwankar et al          Expires April 20, 2004             [Page 15]

 Internet Draft        SYMPLE Scripting Protocol     October 20, 2003

  
   Parameters:          
      Attribute: Management Tree Node URI
      Action: (start | stop)
      Duration: Time to log (Optional parameter, valid for start)            
            
   Example:            
 
   The following synclet (policy element not shown) is an example of
   management action of logging security lock state of the device.
   The log duration is for 24 hours and will help in finding out any
   possible security violations. The event log can consists of call
   processing events, application execution events, signal strength
   readings, location readings, local conditions like battery charge
   state, output power level etc. 

   +------------------------------------------------------------------+
   |<Synclet>                                                         |
   |   <CmdID>1</CmdID>                                               |
   |   <Log>                                                          |
   |      <CmdID>2</CmdID>                                            |
   |      <Attribute>                                                 |
   |         ./Ext/Settings/LockState                                 |
   |      </Attribute>                                                |
   |      <Command>                                                   |
   |         start                                                    |
   |      </Command>                                                  |
   |      <Duration>                                                  |
   |         86400                                                    |
   |      </Duration>                                                 |
   |   </Log>                                                         |
   |</Synclet>                                                        |  
   +------------------------------------------------------------------+

   Appendix A presents the SYMPLE DTD.

   
   



5. Seamless Management

   The management protocols like SNMP and SyncML differ in a number of
   attributes such as

     o    Security Mechanism
     o    Access Control Lists
     o    Addressing Mechanism
     o    MIB
     o    Protocol Representation Format
     o    Protocol layers
     o    Notifications




 adwankar et al          Expires April 20, 2004             [Page 16]

 Internet Draft        SYMPLE Scripting Protocol     October 20, 2003



5.1 Multi-Protocol Gateway



   The multi-protocol gateway is a software entity that represents a 
   terminal (having its own terminal specific management protocol) in 
   the enterprise management system. The multi-protocol gateway makes 
   the enterprise management system believe that the terminal is like 
   any other manageable entity in the enterprise. At the same time it 
   uses terminal specific management protocols for management of 
   terminals.

   Following are the main components of the Multi-protocol gateway as 
   shown in Figure below.



             +-----------------------------+
             |                             |
             |     Notifier                |
             |                             |
             +-----------------------------+
             |                             |
             |     Address Mapper          |
             |                             |
             +-----------------------------+
             |                             |
             |     MIB Mapper              |
             |                             |
             +-----------------------------+
             |                             |
             |     Job Scheduler           |
             |                             |
             +-----------------------------+
             |                             |
             |     Protocol Converter      |
             |                             |
             +-----------------------------+         





   Protocol Converter:
   This component is responsible for the conversion of the SNMP
   protocol to the Symple-SyncML protocol. This includes mapping 
   atomicity requirements on to the terminal specific protocol.
   This component transforms SNMP PDU's to SyncML packages. In this
   transformation process, SNMP security credentials are converted to
   SyncML based security credentials required by Symple Manager.





 adwankar et al          Expires April 20, 2004             [Page 17]

 Internet Draft        SYMPLE Scripting Protocol     October 20, 2003



   Address Mapper: 
   The Multi-protocol gateway maintains a list of the mobile devices     
   that can be reached. This list is populated by a handshake or a 
   discovery mechanism that is exchanged between the Multi-Protocol 
   Gateway and the device. The Mapper maps the address of the device on 
   the enterprise address space. For example, in the case of a GSM 
   terminal, it allows the mapping of a terminal IMEI to the enterprise 
   local private IP address space. The Mapper advertises reach-ability 
   to this local private IP address space from the enterprise address 
   space. It then provides translation from the local private IP   
   address space to the terminal IMEI. 

   MIB Mapper
   Appendix B presents the mapping of management tree of a mobile
   device to SNMP MIB.	

   Job Scheduler:
   This component is responsible for the load balancing of terminal 
   management activities. It schedules TM operations depending on the 
   Symple manager availability and availability of scarce wireless 
   resources in case of wireless devices.

   Notifier:
   Since the time taken for Symple protocol over wireless bearer will
   be more than that expected in the SNMP management, the Notifier allows
   notifying the SNMP manager after the terminal management task 
   is complete. 

  


























 adwankar et al          Expires April 20, 2004             [Page 18]

 Internet Draft        SYMPLE Scripting Protocol     October 20, 2003




5.2 Seamless Management Flow

   Figure below shows a sequence of exchanges between various components of 
   the Universal Manager. These sequences of steps are explained below.


   +------------+       +-----------+   +------------+     +----------+
   | SNMP       |       | Multi     |   | SYMPLE     |     | Mobile   |
   | Manager    |       | Protocol  |   | Manager    |     | Terminal |
   |            |       | Gateway   |   |            |     |          |
   +------------+       +-----------+   +------------+     +----------+
        | (1)Terminal        | Resolve to     |                 |
        |  Management        | terminal       |                 |
        |------------------->|---  address.   |                 |
        |   Operation        |   | credentials|                 |
        |                    |<--  check      |                 |
        |                    |                | Trigger message |
        | (3)Notify status   | (2)Schedule new| to activate agent
        |<-------------------|--------------->|---------------> |
        |                    |   TM           |                 |
        |                    |                | Credentials,    |     
        |                    |                |<--------------->|(4)
        |                    |                | Capabilities    |Execute
        |                    |                | exchange        | TM
        |                    |                |                 |operation
        |                    |                | Send TM task    |
        |                    |                |---------------->|---
        |                    |                | Send Results    |   |   
        |                    |                |<----------------|<-- 
        |                    |                |                 |
        |                    |                | Send Status     |
        |                    |(5)Send Results |---------------->| 
        | (6)Results to      |<---------------|                 |
        |<-------------------|                |                 |
        | Enterprise         |                |                 |
        | Manager            |                |                 |
                     

   1. Terminal Management Operation

   For a terminal management action, such as the querying of the 
   manufacturer name of a GSM terminal, the SNMP manager is unaware
   of the presence of such a terminal and either of the following
   operations take place.

   a] The enterprise management system based on additional information 
   such IMEI decides to route management action to multi-protocol 
   gateway, or 
   b] Multi-protocol gateway advertises addressability to that IMEI as 
   a certain IP address and terminal management actions take place on 
   this proxy IP address.



 adwankar et al          Expires April 20, 2004             [Page 19]

 Internet Draft        SYMPLE Scripting Protocol     October 20, 2003





   In either case the enterprise management system routes the SNMP PDU 
   for the corresponding management action to the Multi-Protocol 
   Gateway instead of sending the SNMP PDU directly to the mobile 
   device. The SNMP PDU's host and port are set to the host and port 
   that the Multi-Protocol Gateway is listening on as opposed to the
   host and port of the mobile device. The SNMP PDU thus sent
   contains the Operation Name (e.g. Get, Get Next, Set), the OID to be
   queried, (optionally IMEI of the GSM terminal and the value of the
   OID if it is a Set Operation), SNMP credentials and a request ID of
   the SNMP PDU.
   
   2. Protocol Conversion

   On receiving a SNMP Packet, the Multi-Protocol Gateway extracts the 
   required information from the SNMP PDU. The Multi-Protocol gateway 
   performs a credentials check and maps the SNMP OID to the 
   corresponding Symple management tree node. In case the IMEI is not 
   sent, it maps the destination IP address to the IMEI of the device. 
   The Protocol Converter after fetching the corresponding SyncML 
   parameter hands the same over to the Scheduler that schedules the 
   task on the Symple manager. The parameters sent as part of the 
   request to the Symple Manager include the Operation Name 
   i.e. (Get, Get Next, Set), SyncML management tree node, the value of 
   the SyncML parameter if it is a Set Operation, Unique Id for the
   device (e.g. IMEI in case of GSM terminal) and the Request ID 
   (associated with each SNMP PDU) of the operation. 

   Figure below shows a part of the SyncML command actually sent to the 
   mobile device to retrieve the manufacturer name from the management 
   tree of the device.

   +------------------------------------------------------------------+  
   |   <Get>                                                          |
   |     <CmdID>2</CmdID>                                             |
   |     <Meta>                                                       |
   |           <Format xmlns="syncml:metinf"> text/plain </Format>    |
   |     </Meta>                                                      |
   |     <Item>                                                       |
   |     <Target><LocURI>./DevInfo/Man</LocURI></Target>              |
   |     </Item>                                                      |
   |   </Get>                                                         |
   +------------------------------------------------------------------+

   3. Status Notification

   The Notifier component of the Multi-Protocol Gateway now sends back 
   a status to the SNMP manager informing it that the task has been
   added to the Symple Manager and hence prevents time outs and 
   retransmission of SNMP PDUs. The status information is sent 
   to the port where the SNMP manager is listening for information from
   the Multi-Protocol Gateway.


 adwankar et al          Expires April 20, 2004             [Page 20]

 Internet Draft        SYMPLE Scripting Protocol     October 20, 2003





   4. SyncML Protocol exchanges

   The Symple manager exchanges credentials and capabilities (after 
   sending optional trigger message ) with the TM agent. The Symple
   manager then sends a management action to the TM agent as part of
   the SyncML package. The TM agent at the mobile terminal executes
   the requested operation and sends back the results and status to the
   Symple manager. 


   5. Notification of results

   The Protocol Converter at the Multi-Protocol Gateway converts 
   results from the Symple manager to SNMP PDUs and sends the SNMP 
   packet to the SNMP manager listening on a different port for
   response SNMP PDUs. The response PDU also contains information 
   on the requested Command either Get/Get Next/Set, the request ID 
   associated with the request SNMP Packet, SNMP OID, value associated 
   with the OID and the status if the operation executed on the phone 
   was successful or not. On receiving the response SNMP Packet from 
   the Multi-Protocol Gateway the packet information is extracted for 
   the results. The performance results of dispatch of Symple scripts
   and seamless management is presented in [5][6].


5.  Conclusion

   The Symple aims to provide XML based complex scripting mechanism to 
   device management. It allows sophisticated set of management
   capabilities to be supported in resource-constrained devices. It
   allows easy authoring of coordinated operations involving
   performance management and diagnostics.
   
   A uniform protocol across all mobile and non-mobile devices is
   infeasible as management protocols are optimized for a certain
   family of devices. The architecture for seamless management enables
   atomic transactions that are executed across diverse devices. It
   allows distributed diagnostics across heterogeneous hosts and
   protocols. 

Security Considerations

   The Symple scripting protocol relies on SyncML DM Security
   specification [7].









 adwankar et al          Expires April 20, 2004             [Page 21]

 Internet Draft        SYMPLE Scripting Protocol     October 20, 2003







References

   1. The SyncML Device Management Protocol, version 1.1.2, 
      Open Mobile Alliance Ltd. June 2003 
   2. The SyncML Representation Protocol Device Management Usage, 
      version 1.1.2, Open Mobile Alliance Ltd. June 2003    
   3. J. Case, M. Fedor, M. Schoffstall, J. Davin. A Simple Network 
      Management Protocol. RFC 1157, Internet Engineering Task Force, 
      May 1990.
   4. K. McCloghrie, M. Rose. Management Information Base for Network 
      Management of TCP/IP-based internets:MIB-II. RFC 1213, Internet 
      Engineering Task Force, March 1991.      
   5. MobiMan: Bringing Scripted Agents to Wireless Terminal Management,
      V. Vasudevan, S. Adwankar, N. Narsimhan, DSOM 2003
   6. Universal Manager: Seamless Management of enterprise mobile and
      non-mobile devices, S. Adwankar, S. Mohan, V. Vasudevan, MDM 2004
   7. The SyncML Device Management Security, version 1.1.2, 
      Open Mobile Alliance Ltd. June 2003 


Appendix A.SYMPLE DTD

   +------------------------------------------------------------------+
   |<!-- Attribute  -->                                               |
   |<!ELEMENT Attribute (#PCDATA)>                                    |
   |<!-- Condition -->                                                |
   |<!ELEMENT Condition (#PCDATA)>                                    |
   |<!-- Threshold  -->                                               |  
   |<!ELEMENT Threshold (#PCDATA)>                                    |
   |<!-- Command  -->                                                 |  
   |<!ELEMENT Command (#PCDATA)>                                      |
   |<!-- Duration  -->                                                |  
   |<!ELEMENT Duration (#PCDATA)>                                     |
   |<!-- Guard operation -->                                          |   
   |<!ELEMENT Guard (CmdID, NoResp?, Cred?, Meta?, Attribute,         |
   |                 Condition, Threshold )>                          |
   |<!-- start time and date to schedule operation -->                |
   |<!ELEMENT Date (#PCDATA)>                                         |
   |<!-- repeat interval with periodic execution -->                  |
   |<!ELEMENT Period (#PCDATA)>                                       |
   |<!-- repeat count with periodic execution -->                     | 
   |<!ELEMENT Repeat (#PCDATA)>                                       | 
   |<!-- Schedule operation  -->                                      |
   |<!ELEMENT Schedule (CmdID, NoResp?, Cred?, Meta?, Date?, Period?, |
   |                    Repeat?, URI?,                                |
   |                    (Get|Replace|Add|Delete|Exec))>               | 
   |<!ELEMENT Assert (CmdID, Target?, NoResp?, Cred?, Meta?, Item+)>  |
   |<!ELEMENT Exception (CmdID, NoResp?, Cred?, Meta?,                |
   |                    (Get|Replace|Add|Delete|Exec))>               | 


 adwankar et al          Expires April 20, 2004             [Page 22]

 Internet Draft        SYMPLE Scripting Protocol     October 20, 2003

   |<!ELEMENT CatchAll (CmdID, NoResp?, Cred?, Meta?,                 |
   |                    (Get|Replace|Add|Delete|Exec))>               |
   |<!-- Diagnostics operation  -->                                   |     
   |<!ELEMENT Diagnostics (CmdID, Assert+, Exception+, CatchAll?)>    |   
   |<!-- Log operation -->                                            |   
   |<!ELEMENT Log (CmdID, NoResp?, Cred?, Meta?, Attribute,           |
   |                 Command, Duration )>                             |   
   |<!-- Synclet -->                                                  |
   |<!ELEMENT Synclet (CmdID, NoResp?, Meta?, (Schedule | Assert |    |
   |       Postpone | Alert | Guard | Get | Replace | Add | Delete    |
   |       Exception | Diagnostics | Exec | Seqeunce | Atomic )+)>    |
   |<!-- End of DTD Definition -->                                    |  
   +------------------------------------------------------------------+ 


Appendix B. Management tree to MIB Mapping

       MOBILE-MIB DEFINITIONS ::= BEGIN

          IMPORTS
                  mgmt, NetworkAddress, IpAddress, Counter, Gauge,
                          TimeTicks
                      FROM RFC1155-SMI
                  OBJECT-TYPE
                          FROM RFC-1212;

          mgmt         OBJECT IDENTIFIER ::= { iso org(3) dod(6) internet(1) 
                                               mgmt(2) }
          directory    OBJECT IDENTIFIER ::= { internet 1 }
          experimental OBJECT IDENTIFIER ::= { internet 3 }
          private      OBJECT IDENTIFIER ::= { internet 4 }
          enterprises  OBJECT IDENTIFIER ::= { private 1 }
          Company      OBJECT IDENTIFIER ::= { enterprises xxx }

          -- textual conventions

           DisplayString ::=
               OCTET STRING
          -- This data type is used to model textual information taken
          -- from the NVT ASCII character set.  By convention, objects
          -- with this syntax are declared as having
          --
                (SIZE (0..255))

           PhysAddress ::=
               OCTET STRING
          -- This data type is used to model media addresses.  For many
          -- types of media, this will be in a binary representation.
          -- For example, an ethernet address would be represented as
          -- a string of 6 octets.


          -- groups in MOBILE-MIB

          DevInfo          OBJECT IDENTIFIER ::= { Company 1 }


 adwankar et al          Expires April 20, 2004             [Page 23]

 Internet Draft        SYMPLE Scripting Protocol     October 20, 2003

          
          DevDetail        OBJECT IDENTIFIER ::= { Company 2 }
          
          Ext              OBJECT IDENTIFIER ::= { DevDetail 1 }
          
          Settings         OBJECT IDENTIFIER ::= { Ext 1 }
          
          WAP              OBJECT IDENTIFIER ::= { Ext 2 }          
          
          Log              OBJECT IDENTIFIER ::= { Ext 3 }                    

          Applications     OBJECT IDENTIFIER ::= { Ext 4 }          
          
          App1             OBJECT IDENTIFIER ::= { Applications 1 }                    

          -- the DevInfo group

	  -- Directory which holds device info

          Man         OBJECT-TYPE
              SYNTAX  DisplayString (SIZE (0..255))
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "Manufacture name."
              ::= { DevInfo 1 }

          Mod         OBJECT-TYPE
              SYNTAX  DisplayString (SIZE (0..255))
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "Model name."
              ::= { DevInfo 2 }

          DevID       OBJECT-TYPE
              SYNTAX  DisplayString (SIZE (0..255))
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "Device serial number."
              ::= { DevInfo 3 }

          Lang        OBJECT-TYPE
              SYNTAX  DisplayString (SIZE (0..255))
              ACCESS  read-write
              STATUS  mandatory
              DESCRIPTION
                      "Device language."
              ::= { DevInfo 4 }

          DmV         OBJECT-TYPE
              SYNTAX  DisplayString (SIZE (0..255))
              ACCESS  read-only
              STATUS  mandatory


 adwankar et al          Expires April 20, 2004             [Page 24]

 Internet Draft        SYMPLE Scripting Protocol     October 20, 2003

            DESCRIPTION
                      "Device version."
              ::= { DevInfo 5 }
              
          -- the DevDetail group
          
          OEM         OBJECT-TYPE
              SYNTAX  DisplayString (SIZE (0..255))
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "Specify OEM of the device (ex, Motorola)."
              ::= { DevDetail 1 }

          FwV         OBJECT-TYPE
              SYNTAX  DisplayString (SIZE (0..255))
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "Firmware version."
              ::= { DevDetail 2 }

          SwV         OBJECT-TYPE
              SYNTAX  DisplayString (SIZE (0..255))
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "Software version."
              ::= { DevDetail 3 }

          HwV         OBJECT-TYPE
              SYNTAX  DisplayString (SIZE (0..255))
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "Hardware version."
              ::= { DevDetail 4 }

          DevTyp      OBJECT-TYPE
              SYNTAX  DisplayString (SIZE (0..255))
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "Device type."
              ::= { DevDetail 5 }

          Bearer      OBJECT-TYPE
              SYNTAX  DisplayString (SIZE (0..255))
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "Bearer."
              ::= { DevDetail 6 }

          EnergyLevel OBJECT-TYPE


 adwankar et al          Expires April 20, 2004             [Page 25]

 Internet Draft        SYMPLE Scripting Protocol     October 20, 2003

              SYNTAX  INTEGER
              ACCESS  read-only
              STATUS  mandatory
              DESCRIPTION
                      "Energy Level. e.g Battery level"
              ::= { DevDetail 7 }
              
          -- the Settings group

          -- Parent Settings directory

          clock       OBJECT-TYPE
              SYNTAX  DisplayString (SIZE (0..255))
              ACCESS  read-write
              STATUS  mandatory
              DESCRIPTION
                      "Set date and time."
              ::= { Settings 1 }

          ActiveRing  OBJECT-TYPE
              SYNTAX  INTEGER
              ACCESS  read-write
              STATUS  mandatory
              DESCRIPTION
                      "Replace active ring tone type setting."
              ::= { Settings 2 }

          ActiveAlert OBJECT-TYPE
              SYNTAX  INTEGER
              ACCESS  read-write
              STATUS  mandatory
              DESCRIPTION
                      "Replace active alert type setting (Silent, Vibrate, 
                                                          Loud, etc)."
              ::= { Settings 3 }

          AlertLevel  OBJECT-TYPE
              SYNTAX  INTEGER
              ACCESS  read-write
              STATUS  mandatory
              DESCRIPTION
                      "Replace alert level setting."
              ::= { Settings 4 }

          DTMF  OBJECT-TYPE
              SYNTAX  INTEGER
              ACCESS  read-write
              STATUS  mandatory
              DESCRIPTION
                      "Replace DTMF settings (Short, Long, Off)."
              ::= { Settings 5 }

          SecurityCode  OBJECT-TYPE
              SYNTAX  DisplayString (SIZE (0..255))
              ACCESS  read-write


 adwankar et al          Expires April 20, 2004             [Page 26]

 Internet Draft        SYMPLE Scripting Protocol     October 20, 2003

              STATUS  mandatory
              DESCRIPTION
                      "Replace the security code."
              ::= { Settings 6 }

          LockState  OBJECT-TYPE
              SYNTAX  INTEGER
              ACCESS  read-write
              STATUS  mandatory
              DESCRIPTION
                      "Security lock state (Locked, Unlocked)."
              ::= { Settings 7 }

               
          -- the WAP group

          -- WAP folder settings

          Defaultwebsession OBJECT-TYPE         
              SYNTAX        DisplayString (SIZE (0..255))
              ACCESS        read-write
              STATUS        optional
              DESCRIPTION
                      "Set default web session on phone."
              ::= { WAP 1 }

          -- the Log group

          -- Directory which holds Log Mgmt Node

          CallProcessing OBJECT-TYPE         
              SYNTAX        DisplayString (SIZE (0..255))
              ACCESS        read-write
              STATUS        optional
              DESCRIPTION
                      "Call Processing Log."
              ::= { Log 1 }

          Location OBJECT-TYPE         
              SYNTAX        DisplayString (SIZE (0..255))
              ACCESS        read-write
              STATUS        optional
              DESCRIPTION
                      "Location Log."
              ::= { Log 2 }

          -- the Applications group

          -- Directory which holds Applications Info

          ExecutionCount OBJECT-TYPE         
              SYNTAX        INTEGER
              ACCESS        read-write
              STATUS        optional
              DESCRIPTION


 adwankar et al          Expires April 20, 2004             [Page 27]

 Internet Draft        SYMPLE Scripting Protocol     October 20, 2003

                      "App1 Execution Count."
              ::= { App1 1 }

          END



Author's Address

   Sandeep Adwankar
   Motorola
   1301 East Algonquin Rd,
   MS IL02-2240, Schaumburg,
   IL 60196 USA   
   EMail: sandeep.adwankar@motorola.com










































 adwankar et al          Expires April 20, 2004             [Page 28]