Internet Engineering Task Force SPIRITS WG Internet Draft draft-unmehopa-spirits-parameter-generation-00.txt November 14, 2001 Expires: May 2002 Authors: Musa Unmehopa (ed.) Lucent Technologies John-Luc Bakker Telcordia Technologies Bruno Chatras France Telecom Janusz Dobrowolski StateSoft Frans Haerens Alcatel Bell Generating the INAP and Parlay parameters for the SPIRITS protocol draft-unmehopa-spirits-parameter-generation-00.txt 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 The SPIRITS protocol is a protocol through which the PSTN can request actions (services) to be carried out in the IP network in response to events occurring within the PSTN/IN. Internet Draft "INAP parameters for the SPIRITS protocol" [1] presents XML encoded INAP CS-2 parameters and XML encoded Parlay parameters which the SPIRITS protocol can transport from the PSTN into the IP network. These XML encodings were constructed in a manual exercise from the ASN.1 sources in case of INAP and the IDL sources in case of Parlay. Unmehopa, et. al. [Page 1] Internet Draft SPIRITS parameter generation November 2001 This Internet-Draft reports of an exercise of generating and validating the XML encodings using publically available tools and scripts. Furthermore, this Internet-Draft reports of an exercise to generate XML Schema's rather than XML DTDs. This Internet-Draft presents the author's experiences in the above exercise and provides some recommendations for the specification of the parameters and data types of the SPIRITS protocol. The exercise is not completed yet, and hence this Internet-Draft presents intermediate results. It is the expectation of the authors that future iterations of the document will be produced. 1.0 Introduction The SPIRITS protocol is designed to carry service information from one domain to another. This information is already specified in the source domain, i.e. PSTN/IN, in the form of parameters and data types. These parameters and data types are then encoded in a format that is more convenient and suitable for the transport mechanism of choice for the SPIRITS protocol. Internet Draft "INAP parameters for the SPIRITS protocol" [1] presents XML encoded INAP CS-2 parameters and XML encoded Parlay parameters which the SPIRITS protocol can transport from the PSTN into the IP network. The transport mechanism for the SPIRITS protocol has been identified, in the SPIRITS Protocol Requirements [2], as the Session Initiation Protocol (SIP) [3]. This Internet-Draft promotes the need to define a solution for parameter encoding that can be applied to any flavor of INAP (any Capability Set, any regional variant, fixed and mobile, i.e. CAMEL), as well as to any flavor of Parlay (any Parlay version and any Parlay interface, including e.g Generic Call Control and Multi Party Call Control). In other words, there is a need for a solution which avoids to "manually" define an XML DTD for each INAP or Parlay variant that may be used by the SPIRITS architecture. This solution would provide the following benefits: - Avoid the "manual" exercise to define XML encodings, which is laborious and error prone. - Ensure full alignment between the ASN.1 definitions and the XML representation thereof, as well as between the IDL definitions and the XML representation thereof. - Applied to any flavour of INAP and any flavour and version of Parlay - Any change or modification to the ASN.1 or the IDL definitions can be easily carried over to the XML encodings - The XML encodings and the examples are validated Unmehopa, et. al. [Page 2] Internet Draft SPIRITS parameter generation November 2001 Throughout this Internet-Draft references are made to Parlay. It should be noted that regarding the API package of interest to the SPIRITS protocol, i.e. MultiParty Call Control, the API interface definitions are being specificied in a joint collaboration between Parlay and 3GPP OSA. Every instance in this Internet-Draft where Parlay is mentioned, OSA is equally applicable. 1.1 Table Of Contents: Subject Page No. Main Sections: Abstract............................................1 1.0 Introduction........................................2 1.1 Table of Contents...................................2 2.0 Use of XML Schema's.................................2 3.0 the Process.........................................3 3.1 IDL to XML..........................................3 3.2 ASN.1 to XML........................................4 4.0 Future Work.........................................4 5.0 Recommendations.....................................6 6.0 Acknowledgements....................................6 7.0 References..........................................6 8.0 Authors' Addresses.................................29 9.0 Acronyms...........................................30 10.0 Full Copyright Statement...........................31 Appendices: A XSD for Parlay Parameters and Data Types............7 B Examples for Parlay................................26 2.0 Use of XML Schema's The current XML encodings in [1] make use of XML DTDs (Document Type Definition). The DTDs specify the content and layout for the XML encodings of the SPIRITS protocol data types and parameters. XML definitions making use of XML DTDs can be validated using an XML parser. One drawback of DTDs is that they have their own particular syntax, they are not specified in XML syntax themselves. This implies that the XML DTDs themselves cannot be validated using the same XML parser used to validate the XML files that make use of those XML DTDs. Another drawback is the limited support for types and namespaces. These drawbacks are overcome by XML Schema's [4,5]. These XML schema's are defined using XSD (XML Schema Definition). An XSD schema defines the elements, attributes, and data types conform to XML syntax. This means that an XML XSD can be validated using an XML parser. XSD also offers support for namespaces. Additionally, as XSDs conform to XML syntax, protocol designers and implementers only need to be familiar with one language syntax, i.e. XML, in stead of two, i.e. XML and DTD. XML Schemas are type safe and Unmehopa, et. al. [Page 3] Internet Draft SPIRITS parameter generation November 2001 come with a set of predefined simple types, where DTD only accepts one type: string. More importantly, XML schemas allow the programmer to define data types as well as to restrict, redefine and extend them in a manner similar to inheritance in object oriented programming languages. This latter attribute of schemas enables modularity, extensibility and reuse of XML Schema's. Extensibility is useful in a manner similar to adding behavior by using inheritance in an object-oriented language. This Internet-Draft recommends the use of XSD rather than XML DTD for the specification of the SPIRITS protocol parameters and data types. 3.0 The Process This section describes the process that was used to construct the XML encodings. Section 3.1 describes the process for the Parlay IDL definitions, whereas section 3.2 describes the process for the INAP ASN.1 definitions. 3.1 IDL to XML This exercise was performed for the XML DTDs contained in appendix E of [1]. The Parlay methods, parameters and data types are specified in IDL (Interface Definition Language) [6]. The Object Management Group (OMG) has issued a Request For Proposal [7], which solicits proposals for the support of IDL to XML and IDL to WSDL mappings. The relevance to the SPIRITS Protocol work is that Parlay method invocations, as well as the parameters and data types, are defined in IDL for which the XML language mappings are requested. The initial submission to this RFP is dated from June 2001 [8], and describes a proposal for IDL to XML Schema mappings. Chapter 3 of [8] describes XML Schema constructs used to describe each IDL construct. Unfortunately, this work is still ongoing and not matured yet. Therefore the approach taken in this Internet-Draft is to take the 'hand-crafted' XML DTDs from [1] and work from those as a starting point. The following process was followed: Step 1 - Validate the XML DTDs and the XML Examples. Step 2 - Generate XSDs from the DTDs. Step 3 - Validate the XSD Examples. It is important to note that this step-wise process can be repeated as is for XML DTDs automatically generated from the IDL, once the OMG specifications [7,8] are completed and tool support is available. 3.1.1 Step 1 - Validate the XML DTDs and the XML Examples. We used Xerces [9] which is a publically available XML parser that supports the XML 1.0 recommendation. The hand-crafted XML DTDs from Appendix E of [1] served as input. Minor syntactic corrections were made to the XML DTDs, as a Unmehopa, et. al. [Page 4] Internet Draft SPIRITS parameter generation November 2001 result of the validation process. Furthermore, updates were made to reflect the latest approved version of the Parlay specification [10]. The latter are mainly concerned with Call Event Types that have been updated in the SPIRITS_CET.DTD file and the SPIRITS_ACI.DTD file. A drawback of this approach, as identified in section 2.0, is that the XML DTDs can only be validated using an XML parser through the validation of the XML examples that make use of those XML DTDs. One cannot validate the DTD directly using an XML parser. 3.1.2 Step 2 - Generate XSDs from the DTDs For Step 2 we used a publically available tool "dtd2xsd" [11] to translate the XML 1.0 DTDs into XML schema's (REC-xmlschema-1-20010502). The proposed namespace for the XML schema's is "http://www.csapi.org/spirits/", as "org.csapi" is the namespace for the Parlay IDL. The results of Step 2 are provided in Appendix A of this Internet-Draft. 3.1.3 Step 3 - Validate the XSD Examples Again, Xerces [10] was used to validate the examples. No modifications were required, corroborating the validation of the XML DTDs and the generation of the XSDs from these DTDs. The results of Step 3 are provided in Appendix B of this Internet-Draft. 3.2 ASN.1 to XML This exercise pertains to the XML DTDs contained in appendix B of [1]. The INAP parameters and data types are specified in ASN.1 (Abstract Syntax Notation One) [12]. ITU-T recommendation X.693 [13] specifies as set of basic XML Encoding Rules (XER) that may be used to convert a specification defined in ASN.1 to a specification defined in XML, and vice versa. Amendment 3 of ITU-T recommendation X.680 [14] specifies XML value notation for ASN.1 basic notation. Unfortunately, this work is in progress and not yet mature. ITU-T recommendation X.693 [13] is currently under ITU-T AAP (Alternative Approval Process). The automatic generation of XML from the ASN.1 specifications, using XER, is left to future iterations of the exercise presented in this Internet- Draft. It is expected that a step-wise process as proposed in section 3.1 can be applied to the INAP ASN.1 case as well. 4.0 Future Work This section identifies areas for further study, as well as areas of ongoing work. 4.1 IDL-to-XML generation IDL to XML generation and mapping rules are ongoing work in the OMG. No tool support is was identified at this time, although no extensive search Unmehopa, et. al. [Page 5] Internet Draft SPIRITS parameter generation November 2001 was performed. Once this work matures, the XML will be generated automatically from the IDL, making the parameter and data type definition for the SPIRITS protocol more transparent. 4.2 Typo's This exercise showed a number of typo's in the XML DTD's currently contained in [1]. These typo's are the result of the "manual" DTD construction. For the time being these are fixed in the XSDs. Eventually, these need to fixed in the XML DTDs as well. However, as soon as the DTDs or XSD can be generated from the IDL and ASN.1 respectively, this need is superseded. 4.3 Tagged Choice of Data Elements (IDL) Some of the Parlay definitions in IDL make use of the "tagged choice of data elements" language construct. During the manual construction of the XML DTDs from the IDL, no suitable conversion for this IDL language construct was identified. The example provided in [1] in section E.3.3.1 "Example of an Event Report Error" will therefore not correctly validate. However, as soon as the DTDs or XSDs can be generated from the IDL, this need is superseded. OMG will have defined a standard mapping for this IDL language construct. 4.4 Strong typing XSD support strong typing. The string type for date and time parameters, e.g "1998-12-04 10:30" can be strong typed. The XSD data type is "dateTime". The format of the example would then be "1998-12-04T10:30", which is slightly different than the Parlay TpString IDL type value. Although it is preferred to use strong typing, in this particular case this would yield a different parameter value. A potential solution would be to submit a change request to Parlay to change the string representation to "TpDateAndtime" for the date and time parameters to the same as the XSD type "dateTime". 4.5 Namespace This Internet-Draft proposes to use the following namespace for the XML schema's "http://www.csapi.org/spirits/". The naming convention attempts to align with "org.csapi" as the namespace for the Parlay IDL. The XSDs contained in appendix A do not yet include this namespace. 4.6 ASN.1-to-XML generation It is the intention of the authors to perform the INAP ASN.1 exercise, similar to the Parlay IDL exercise, in future iterations of this Internet-Draft. That work will be based on XER as defined in [13]. 4.7 Completeness of the protocol representation In order for the protocol to be complete not only all the data elements Unmehopa, et. al. [Page 6] Internet Draft SPIRITS parameter generation November 2001 have to be defined but also the sequencing of messages and events must be determined as well. Since the SPRITS protocol deals only with two entities PSTN and IP the functional partition is well determined. It should be noted that different INAP flavors have different call models. In order to validate a protocol a call model has to be defined as certain events must be for example ignored in the context of a call progression. The PARLAY has a call model however it is the toolkit level call model and not necessarily a network level call model. In order for the interoperation of service written by different software professionals a common call model must be assumed. The work on the multimedia call model is progressing well however no universally accepted model has emerged yet. 5.0 Recommendations The authors of this Internet-Draft recommend that:- - XML Schema's be used instead of XML DTDs, for the further definition of the SPIRITS protocol - the XML Schema's be generated, possibly via XML DTD as an intermediary step, from the IDL and ASN.1, as soon as the respective language mappings to XML are specified and tool support is available - the following namespace for the XML schema's be used "http://www.csapi.org/spirits/" 6.0 Acknowledgements The authors would like to extend their gratitude to Dirk-Jaap Plas, Alec Brusilovsky, Kumar Vemuri and Igor Faynberg for their valuable comments, suggestions for improvement and general support. 7.0 References [1] A.Brusilovsky, E.Dacloush, M.Unmehopa, K.Vemuri, A.Zaki, F.Haerens, "INAP parameters for the SPIRITS protocol", [2] I.Faynberg, J.Gato, H.Lu, L.Slutsman, "SPIRITS Protocol Requirements", [3] Handley, M., Schooler, E., Schulzrinne, H. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999. [4] XML Schema Part 1:Structures, W3C Recommendation REC-xmlschema-1-20010502, http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/ [5] XML Schema Part 2:Datatypes, W3C Recommendation REC-xmlschema-2-20010502, http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/ Unmehopa, et. al. [Page 7] Internet Draft SPIRITS parameter generation November 2001 [6] ISO/IEC 14750-1999, Information technology - Open distributed Processing - Interface Definition Language [7] CORBA/SOAP Interworking Request For Proposal, Object Management Group, orbos/00-09-07, http://cgi.omg.org/cgi-bin/doc?orbos/00-09-07 [8] CORBA Web Services, Initial Joint Submission, Object Management Group, orbos/01-06-07, ftp://ftp.omg.org/pub/docs/orbos/01-06-07.pdf [9] Apache Xerces XML Java Parser, http://xml.apache.org/xerces-j/index.html [10] 3G TS 29.198-04 version 4.1.0, "3rd Generation Partnership Project; Technical Specification Group Core Network; Open Service Access (OSA); Application Programming Interface (API); Part 4: Call Control" (Release 4) [11] dtd2xs v1.52, http://puvogel.informatik.med.uni-giessen.de/dtd2xs/ [12] ITU-T Recommendation X.680 (12/97) Information technology - Abstract Notation One (ASN.1): Specification of basic notation [13] ITU-T Recommendation X.693, Information Technology - ASN.1 Encoding Rules: XML Encoding Rules [14] ITU-T Recommendation X.680 (1997), Information Technology - ASN.1: Specification of Basic Notation - Amendment 3 - XML Value Notation Appendix A: XSD for Parlay Parameters and Data Types This appendix contains the generated XML XSDs for the Parlay Encoding of SPIRITS Data. These were generated from the XML DTDs that were originally described in [1]. The DTD file breakdown structure as in [1] is maintained for ease of reference. Similarly, conventions and terminology are preserved from [1]. A.1 Protocol Operations A.1.1 Event Report Request ************************* Unmehopa, et. al. [Page 8] Internet Draft SPIRITS parameter generation November 2001 *************************** A.1.2 Event Report Result ************************* *************************** A.1.3 Event Report Error ************************* Unmehopa, et. al. [Page 9] Internet Draft SPIRITS parameter generation November 2001 *************************** A.1.4 Report Notification ************************* *************************** A.2 Common Element Definitions A.2.1 CallEventType ************************* Unmehopa, et. al. [Page 10] Internet Draft SPIRITS parameter generation November 2001 Unmehopa, et. al. [Page 11] Internet Draft SPIRITS parameter generation November 2001 *************************** A.2.2 CallMonitorMode ************************* *************************** A.2.3 AdditionalCallEventInfo ************************* Unmehopa, et. al. [Page 12] Internet Draft SPIRITS parameter generation November 2001 Unmehopa, et. al. [Page 13] Internet Draft SPIRITS parameter generation November 2001 Unmehopa, et. al. [Page 14] Internet Draft SPIRITS parameter generation November 2001 Unmehopa, et. al. [Page 15] Internet Draft SPIRITS parameter generation November 2001 *************************** A.2.4 CallEventTime ************************* *************************** A.2.5 ErrorTime ************************* *************************** A.2.6 ErrorType ************************* Unmehopa, et. al. [Page 16] Internet Draft SPIRITS parameter generation November 2001 *************************** A.2.7 AdditionalErrorInfo ************************* Unmehopa, et. al. [Page 17] Internet Draft SPIRITS parameter generation November 2001 *************************** A.2.8 Notification Info ************************* Unmehopa, et. al. [Page 18] Internet Draft SPIRITS parameter generation November 2001 Unmehopa, et. al. [Page 19] Internet Draft SPIRITS parameter generation November 2001 Unmehopa, et. al. [Page 20] Internet Draft SPIRITS parameter generation November 2001 Unmehopa, et. al. [Page 21] Internet Draft SPIRITS parameter generation November 2001 Unmehopa, et. al. [Page 22] Internet Draft SPIRITS parameter generation November 2001 Unmehopa, et. al. [Page 23] Internet Draft SPIRITS parameter generation November 2001 Unmehopa, et. al. [Page 24] Internet Draft SPIRITS parameter generation November 2001 *************************** A.2.9 Address ************************* Unmehopa, et. al. [Page 25] Internet Draft SPIRITS parameter generation November 2001 Unmehopa, et. al. [Page 26] Internet Draft SPIRITS parameter generation November 2001 *************************** Appendix B: Examples for Parlay B.1 This is the validated example from Appendix E of [1], E.3.1.1 Example of an Event Report Request, using the XSDs described in Appendix B. B.2 This is the validated example from Appendix E of [1], E.3.2.1 Example of an Event Report Result, using the XSDs described in Appendix B. Unmehopa, et. al. [Page 27] Internet Draft SPIRITS parameter generation November 2001 1998-12-04 10:30 B.3 This is the validated example from Appendix E of [1], E.3.3.1 Example of an Event Report Error, using the XSDs described in Appendix B. As has been identified in section 4.3 there is still an error contained in this example. 1998-12-04 10:30 B.4 This is the validated example from Appendix E of [1], E.3.4.1 Example of a Report Notification, using the XSDs described in Appendix B.
Unmehopa, et. al. [Page 28] Internet Draft SPIRITS parameter generation November 2001 1800PIZZA
31356871684
Unmehopa, et. al. [Page 29] Internet Draft SPIRITS parameter generation November 2001 1998-12-04 10:30 B.5 SPIRITS.XSD Includes A convenience XSD file was created, which includes all the XSDs from Appendix B. elementFormDefault="qualified" attributeFormDefault="unqualified" > Some explanatory text goes here ... 8.0 Authors' Addresses Musa Unmehopa Lucent Technologies, Larenseweg 50, Postbus 1168 Hilversum, The Netherlands unmehopa@lucent.com Unmehopa, et. al. [Page 30] Internet Draft SPIRITS parameter generation November 2001 John-Luc Bakker Telcordia Technologies 445 South Street Morristown, 07960 NJ USA jlbakker@research.telcordia.com Bruno Chatras France Telecom R&D France bruno.chatras@rd.francetelecom.com Janusz Dobrowolski StateSoft 2351 Richmond Dr Wheaton, Il 60187 USA j_a_dobrowolski@hotmail.com Frans Haerens Alcatel Bell Francis Welles Plein, B-2080 Antwerp Belgium 1200 BD, frans.haerens@alcatel.be 9.0 Acronyms 3GPP Third Generation Partnership Project AAP Alternative Approval Process ASN.1 Abstract Syntax Notation One CAMEL Customized Applications for Mobile Network Enhanced Logic CS Capability Set DTD Document Type Definition IDL Interface Definition Language INAP Intelligent Network Application Protocol OMG Object Management Group OSA Open Service Access PSTN Public Switched Telephone Network SIP Session Initiation Protocol SPIRITS Services in the PSTN/IN Requesting InTernet Services Unmehopa, et. al. [Page 31] Internet Draft SPIRITS parameter generation November 2001 WSDL Web Services Definition Language XER XML Encoding Rules XML eXtensible Markup Language XSD XML Schema Definition 10.0 Full Copyright Statement "Copyright (C) The Internet Society (date). 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. Unmehopa, et. al. [Page 32]