XML encoding for SMS messages J.P.T. Koponen Internet-Draft T. Ikonen Expires: May 17, 2001 L. Ziegler First Hop Ltd. November 16, 2000 XML encoding for SMS messages draft-koponen-sms-xml-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 except that the right to produce derivative works is not granted. 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 May 17, 2001. Abstract The Short Message Service (SMS) messages have become very popular. However, the service provisioning is still relatively awkward. This draft presents an encoding and a simple protocol for describing and submitting Short Message Service (SMS) messages over the Internet. The protocol is aimed to be used between SMS Centers and service providers. The SMS messages are encoded in XML and the corresponding Document Type Definition (DTD) for the message structure is described. Koponen, et. al. Expires May 17, 2001 [Page 1] Internet-Draft XML encoding for SMS messages November 2000 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Glossary of Terms . . . . . . . . . . . . . . . . . . . . 4 1.2 Scope of this Document . . . . . . . . . . . . . . . . . . 5 1.2.1 Issues not considered in the protocol . . . . . . . . . . 6 1.3 Benefits of XML as the SMS message format . . . . . . . . 6 1.4 Service Provisioning Architecture . . . . . . . . . . . . 7 1.5 International Character Sets . . . . . . . . . . . . . . . 8 2. The Protocol . . . . . . . . . . . . . . . . . . . . . . . 9 2.1 SP sends a submit message to SMSC . . . . . . . . . . . . 9 2.2 SMSC sends deliver message to SP . . . . . . . . . . . . . 9 2.3 SP sends statusreportrequest message to SMSC . . . . . . . 10 2.4 SP sends delete message to SMSC . . . . . . . . . . . . . 10 3. DTD Specification of the messages . . . . . . . . . . . . 12 3.1 The message root . . . . . . . . . . . . . . . . . . . . . 12 3.2 submit . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.2.1 da - Destination Address . . . . . . . . . . . . . . . . . 13 3.2.1.1 anumber - Address Number . . . . . . . . . . . . . . . . . 13 3.2.1.2 atype - Address Type . . . . . . . . . . . . . . . . . . . 13 3.2.1.3 shadow . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.2.2 oa - Originating Address . . . . . . . . . . . . . . . . . 14 3.2.3 ud - User Data . . . . . . . . . . . . . . . . . . . . . . 14 3.2.4 udh - User Data Header . . . . . . . . . . . . . . . . . . 15 3.2.5 dcs - Data Coding Scheme . . . . . . . . . . . . . . . . . 15 3.2.6 pid - Protocol Identifier . . . . . . . . . . . . . . . . 15 3.2.7 vp - Validity Period . . . . . . . . . . . . . . . . . . . 16 3.2.8 timing . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.2.8.1 time . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.2.8.2 delay . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.2.9 QoS - Quality of Service . . . . . . . . . . . . . . . . . 18 3.2.10 messageID - Message Identifier . . . . . . . . . . . . . . 18 3.2.11 cost . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.2.12 rsr - Request status Report . . . . . . . . . . . . . . . 19 3.3 deliver . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.3.1 scts - Service Center Time Stamp . . . . . . . . . . . . . 20 3.3.2 location . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.4 deliverstatusreport . . . . . . . . . . . . . . . . . . . 21 3.4.1 statuslist . . . . . . . . . . . . . . . . . . . . . . . . 21 3.5 statusreportrequest . . . . . . . . . . . . . . . . . . . 22 3.6 statusreport . . . . . . . . . . . . . . . . . . . . . . . 22 3.7 delete . . . . . . . . . . . . . . . . . . . . . . . . . . 22 3.8 deletereport . . . . . . . . . . . . . . . . . . . . . . . 23 3.9 ack - Acknowledgement . . . . . . . . . . . . . . . . . . 23 3.9.1 mref - Message Reference . . . . . . . . . . . . . . . . . 24 3.10 nack - Negative Acknowledgement . . . . . . . . . . . . . 24 4. Security Considerations . . . . . . . . . . . . . . . . . 26 References . . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 27 Koponen, et. al. Expires May 17, 2001 [Page 2] Internet-Draft XML encoding for SMS messages November 2000 A. Examples of XML encoded messages . . . . . . . . . . . . . 28 A.1 submit message . . . . . . . . . . . . . . . . . . . . . . 28 A.2 ack message . . . . . . . . . . . . . . . . . . . . . . . 28 A.3 deliverstatusreport message . . . . . . . . . . . . . . . 29 B. Full DTD of the messages . . . . . . . . . . . . . . . . . 30 C. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 32 Koponen, et. al. Expires May 17, 2001 [Page 3] Internet-Draft XML encoding for SMS messages November 2000 1. Introduction SMS (Short Message Service) is a relatively simple messaging system provided by the mobile phone networks. SMS messages are supported by GSM, TDMA and CDMA based mobile phone networks currently in use. Although services based on SMS have been feasible for many years, the recent mobile phone penetration and large scale user adoption of the existing services have made the SMS based services even more attractive to service providers. Although services enabled by WAP (Wireless Application Protocol) and UMTS (Universal Mobile Telecommunications System) will most propably replace SMS messages as the most popular media for wireless aplications, there will still be a very large user base still for a long time. The great market interest related to WAP and the so-called mCommerce (mobile commerce) has made also SMS more interesting as a service delivery channel. Operators and service providers are creating many new services. Wireless Application Service Provision (WASP) is a recent, interesting service architecture for providing SMS based services. The basic principle is that there is only one SMSC (SMS Center) which encodes the messages to be submitted through the GSM network. The basic difficulty in developing SMS based services is the variety of protocols used in SMS Centers. European Telecommunication Standards Institute (ETSI) has approved four SMSC protocols, SMPP (by Logica), CIMD (by Nokia), UCP/EMI (by CMG) and SMS2000 (by SEMA). All these protocols have a slightly different functionality and quite different character conversions. Supporting all these protocols is a demanding task for a service provider. There are several SMS gateways able to interact with some or all of the SMS protocols. However, there is no standard way for service providers to interact with the SMS gateways. Also, only few of the SMS gateways support all the SMSC protocols. This draft proposes a solution by introducing an easily adoptable interface to SMS Centers or SMS gateways for service providers. Customers are actually paying for the services delivered in the SMS messages. Therefore, quality of service and security measures are very important. 1.1 Glossary of Terms DTD (Document Type Definition): an XML document which defines a grammar for a class of documents. Most importantly, a DTD declares the elements (sometimes called tags) that encode the structure of a document. A validating XML software can verify the validity of a document by comparing the document to its DTD. See [1] for through definitions. Koponen, et. al. Expires May 17, 2001 [Page 4] Internet-Draft XML encoding for SMS messages November 2000 GSM (Global System for Mobile communications): the mobile phone technology currently in extensive use throughout the world. MT (Mobile Terminal): mostly a mobile phone but may also be a handheld computer or a laptop. The only requirement in this draft is that the MT is SMS enabled. SMS (Short Message Service): messaging system according to GSM specification. Alphanumeric and binary messages can be submitted via SMS. SMS messages can transport short alphanumeric notes or binary encoded figures, operator logos and ringing tones. SMSC (Short Message Service Center): the hardware device submitting the messages. Currently, SMSC devices support binary formats. A software module called SMS gateway is used to give instructions to the SMSC. The protocol described in this draft is proposed to provide a standard for service providers to interact with SMS gateways or SMS centers. SP (Service Provider): an entity who hosts an SMS service. The service provider creates the content for the service (SP could actually use an external content provider) and creates the business logic. The service provider should have a web server capable of sending and receiving the XML encoded packets described later in this document. XML (eXtensible Markup Language): a meta language defined by W3C that can be used to describe structured documents. XML can be used to define languages that in turn can be used to write structured documents. XML is a subset of SGML, the Standard Generalized Markup Language. The current version of XML is defined in [1]. WASP: Wireless Application Service Providing is the wireless version of the ASP (Application Service Providing) concept. 1.2 Scope of this Document This draft describes an interface between SMSC and SP. The SMSC and SP reside at different physical locations and are connected over the Internet. In other words, the interface proposed here is a straightforward way to connect SMS messages to the Internet. The purpose is to make becoming a service provider as easy as possible. If the mobile operators would provide a standard way to connect to the SMS Centers, the only thing required for becoming a wireless service provider would be a server capable of delivering and transmitting XML encoded SMS messages. As the wireless services are maintained at the SPs servers, it is easy to connect the wireless services to the Internet based services and data bases Koponen, et. al. Expires May 17, 2001 [Page 5] Internet-Draft XML encoding for SMS messages November 2000 hosted by the SP. 1.2.1 Issues not considered in the protocol This document presents a simple protocol for messaging between service provider and an SMSC. If it is kept simple, there are many important tasks the protocol does not solve. It is assumed here that the underlying XML packet carrier protocol takes care of the of the following tasks: o No packet losses. All the packets should reach the destination. The order of the submitted packets should be conserved. There are service applications in which the order of the packets coming from SMSC to the service provider has some significance, for example, in online gaming where the first one wins. o Error free payload transmission. There are already enough protocols in Internet capable for error free transmission, and therefore this protocol can use better suited protocols as carriers. o Connection creation. The SMS transmission protocol described is point-to-point protocol, but does not provide any means for opening or closing the connection. Additionally, it does not provide means for casting to multiple service providers. If the mobile end user willing to get some service would like to request for offers from many service providers, the multicast for service providers would be attractive. o Security is important for SMS services since the messages may carry confidential information or monetary value. There should be no means for intruders to read or change the messages. Also non-authorized message creation and submission must be impossible. The service provider most likely pays for the submitted messages to the SMSC and therefore, it should be clear that the service provider pays only for messages it has send. The above mentioned services must be ensured by the underlying carrier protocol. Transport Layer Security (TLS) [5] is a good example candidate. The messages could also be transmitted by a commercial middleware software or by email. 1.3 Benefits of XML as the SMS message format XML is a widely adopted W3C standard [1] for providing a unified way to present documents and messages in the Internet. XML provides a standard way to describe message structures, standard high quality charge free software for creating and parsing XML documents. Therefore, XML is one of the most attractive alternatives to be used Koponen, et. al. Expires May 17, 2001 [Page 6] Internet-Draft XML encoding for SMS messages November 2000 as the message encoding format in new protocols. This document does not provide tutorial to XML since there is a large number of good text books and tutorials available. The objective of this draft is to provide a maximally easy access to the Short Message Service provisioning. SMS Centers are complicated entities, but this complexity can be hidden behind a unified interface. The protocol described in this draft operates in the application layer of the protocol stack, and therefore binary encoding schemes would make application development for the protocol awkward and slowly. XML speeds up the application programming. The drawback is the increased bandwidth usage compared to binary encodings. We think that the savings due to accelerated application programming are larger than the costs due to the larger band width usage. However, if the bandwidth usage would be a problem, there are also possibilities to reduce the document size in a transparent way. WBXML (WAP Binary XML) [2] is a W3C specification for converting XML documents to binary format: document tags are recoded reducing significantly the size of the document. In this way, the bandwith usage can be reduced to a minimum and the overhead compared to other binary encoding formats is small. WBXML is designed for XML submission over wireless media, and thus, it should also be compact enough for the Internet. 1.4 Service Provisioning Architecture The service provider submits the XML encoded SMS message through the Internet to the SMS gateway. The SMS gateway transforms the SMS message to a form understandable by the SMSC. After that the SMSC submits the SMS to the target phone. This architecture is illustrated in figure 1. The protocol and messages described in this draft are used only between the SMSC and the service provider. The protocol defines the messaging between one Service Provider and one SMSCenter. In real cases, there might be many service providers connected to the SMSC. Theoretically, one service provider might use also many SMSCs. -------- ---------- -------- | | 1. | | 2. | | | MT | <-------> | SMSC | <-------> | SP | | | | | | | -------- ---------- -------- figure 1. Koponen, et. al. Expires May 17, 2001 [Page 7] Internet-Draft XML encoding for SMS messages November 2000 1.5 International Character Sets The implementor of an SMSC can choose the supported character sets. SP must know, which character sets it can use. The used character set is defined in the xml file. For example, if the SP would like to use ISO-latin-1 character set, the XML file declaration should define the character set with the encoding atribute: ... Koponen, et. al. Expires May 17, 2001 [Page 8] Internet-Draft XML encoding for SMS messages November 2000 2. The Protocol The protocol described in this document has four different message exchange cases. The messages are named according to normal GSM parlance: SMS messages sent from SP to the mobile terminal are called submit messages and the messages from the MT to the SP are called deliver messages. In addition, the SP can query the status of the messages defined in earlier submit messages with statusreportrequest message, and also cancel the requested message submissions with delete messages. The submitted report messages can be used by the billing mechanisms. The messages in the protocol are: ack, nack, submit, deliverystatusreport, deliver, delete, deletereport, statusreportrequest, statusreport. The positive acknowledgement is ack, and the negative acknowledgement is nack. The rest of the messages are described in the next sections. 2.1 SP sends a submit message to SMSC The SP wants to send one or more SMS messages to one or more MTs. SP requests SMSC to submit the SMS messages by sending submit a message. The actual messages are encoded in one submit message. There may be instructions for sending several SMS messages at different times. The SMSC sends back an acknowledgement immediately. After the SMSC has processed the messages and submitted them, or passed them to the scheduler, it sends a deliverystatusreport message to SP. The deliverystatusreport is optional and must be requested in the submit message. SMSC Service Provider submit <------------------------------------------------- ack OR nack -------------------------------------------------> deliverystatusreport (OPTIONAL) -------------------------------------------------> 2.2 SMSC sends deliver message to SP In normal GSM parlance, the case in which SMS messages are transferred from the SMSC to a SP is called deliver and the opposite case discussed in the previous section is called submit. Koponen, et. al. Expires May 17, 2001 [Page 9] Internet-Draft XML encoding for SMS messages November 2000 After an MT submits an SMS message to the SMSC, SMSC sends a corresponding deliver message to the SP . The deliver message describes the message originating from the MT. After that, the SP sends immediately an acknowledgement back to the SMSC. SMSC Service Provider deliver -------------------------------------------------> ack OR nack <------------------------------------------------- 2.3 SP sends statusreportrequest message to SMSC The SP has earlier sent submit message to the SMSC, in which it has requested submission of scheduled messages. It can query the submission status of the messages by sending a statusreportrequest to the SMSC. If the request is not adequate, the SMSC responds with a negative acknowledgement. If the request is adequate, the SMSC answers with a statusreport. SMSC Service Provider statusreportrequest <------------------------------------------------- statusreport OR nack -------------------------------------------------> 2.4 SP sends delete message to SMSC SP has earlier submitted a submit message, in which it has requested submission of scheduled messages. It wants to cancel message submissions. To do this, the SP sends a delete message to the SMSC. If the request is not adequate, the SMSC responds with a negative acknowledgement. If the request is adequate, the SMSC sends a deletereport in which the messages which could not be cancelled are listed. Koponen, et. al. Expires May 17, 2001 [Page 10] Internet-Draft XML encoding for SMS messages November 2000 SMSC Service Provider delete <------------------------------------------------- deletereport or nack -------------------------------------------------> Koponen, et. al. Expires May 17, 2001 [Page 11] Internet-Draft XML encoding for SMS messages November 2000 3. DTD Specification of the messages 3.1 The message root The root element of this XML specification is a message element: One message element can contain many messages of a same type, but not messages of different types. Here ack is the positive acknowledgement and nack is the negative acknowledgement. The message usage in the protocol is described in Section 2. The structures of the messages are described in the following sections. 3.2 submit The submit message discussed in Section 2.1 has the following structure: There can be twelve elements and two of them are mandatory (at least one da element and a messageID element). Here da is the destination address which describes the telephone numbers to which the SMS messages will be sent, and oa is the originating address, i.e., the address from which the SMS message comes to mobile terminals. ud is user data, i.e., the actual payload in the delivered SMS message, udh is user data header, which is a payload header as described in GSM specifications, dcs is data coding scheme as described in GSM specifications, pid is protocol identier, as described in GSM specifications, vp is the validity period of the message submission request, timing defines the scheduling of the messages. QoS defines parameters for quality of service, and messageID is message identifier. The structure of these elements is defined in following subsections. Multicast to mobile terminals can be implemented by specifying more than one destination address with more than one da element. There are GSM specific elements such as udh, dcs, and pid which can be used by those familiar with GSM specifications. However, if just plain SMS message submission is requested, a submit message can Koponen, et. al. Expires May 17, 2001 [Page 12] Internet-Draft XML encoding for SMS messages November 2000 consist of just da, oa, udh and messageID elements. 3.2.1 da - Destination Address Destination address is carried by the da element: Here the anumber element describes the actual GSM compatible address. The address is normally the telephone number of the receiving mobile terminal. The phone number, or other GSM compatible address, is given in the anumber element. The type of the number is specified in the atype element. However, if the SMSC wants to provide anonymity for the mobile customers it can give the SP only an alphanumeric identifier not related to any phone numbers. In this case, the shadow element should be used instead of the atype element. If the atype element is missing, the default is International Telecommunication Numbering Plan ITU-T E.164 standard, for example, "+358991234567", where "+" means that the number is international, "358" is the country code for Finland, "99" denotes a teleoperator and "1234567" is a subscriber number. The teleoperator and subscriber numbers presented here are dummy numbers. 3.2.1.1 anumber - Address Number The actual address of the destination MT is given in the anumber element: The address is given in string format. Parsing the address depends on its type which is defined by the atype element. 3.2.1.2 atype - Address Type The type of the address is given in the anumber element: The type identifier is given as a hexadesimal number in string format. The possible types are defined by the GSM specification TODO:reference. Koponen, et. al. Expires May 17, 2001 [Page 13] Internet-Draft XML encoding for SMS messages November 2000 3.2.1.3 shadow If the MT wants to stay anonymous to a SP and the SMSC supports this feature, shadow addresses can be used: If the shadow element is present, the address should be a unique string identifier which can be for customer identification. SMSC and SP decide, whether a certain phone number always relates to a certain shadow address or whether shadow addresses are created for each session. The use of shadow addresses, instead of the physical service provision number, is attractive, if there are many service provision numbers, for example, in different countries. It is possible for an SMSC to hide the actual service number from the SP. This would be beneficial if the actual service phone number would be changed every now and then or there are many service numbers for the same service. 3.2.2 oa - Originating Address The oa element defines the Originating Address defined by the GSM specification: The arguments in the oa element describe the address of the MT, from which the message originates. There is always only one originating address. The oa element is defined in the same way as the da element describing the destination address in Section 3.2.1 is defined. The anumber child element is described in Section 3.2.1.1 and the atype child element is described in Section 3.2.1.2. If the atype element is not specified, the default address type is used as defined in Section 3.2.1. In submit message, if the originating address is not specified, the SMSC should use its default address. In deliver messages, the originating address of the MT is required. 3.2.3 ud - User Data The actual payload of the SMS message is carried in the ud (user data) element: Koponen, et. al. Expires May 17, 2001 [Page 14] Internet-Draft XML encoding for SMS messages November 2000 The user data can be either in text or binary format. Text is the default format and given as a string, as defined in the XML specifications. The purpose is to hide the complexities related to string conversions in different SMSC protocols. To support various character sets, the encoding attribute in the message XML file header should be used, as described in Section 1.5. Ringing tones, pictures, and over the air applications can be submitted in binary format. The binary data should be presented as a hexadecimal string. Although the SMS messages have a maximum length, the length of the ud element data field is not limited. The SMSC should then split the messages and submit them in pieces. Some mobile phones support this feature and are able to concatenate the pieces automatically. The fragmentation data is carried in the udh element, for details, see [3]. 3.2.4 udh - User Data Header User data header is given in the udh element: User Data Header is an additional data field which can be used for carrying additional information, such as information about the user data fragmentation. The argument of the udh element must be given as a hexadesimal number encoded in string format. For further information, see GSM specification [3]. 3.2.5 dcs - Data Coding Scheme Data Coding Scheme is described in the dcs element: Data coding scheme is given as a one byte long hexadesimal number encoded as a string. For further information on data coding scheme, see GSM specification [4]. 3.2.6 pid - Protocol Identifier Protocol identifier is given in the pid element: Koponen, et. al. Expires May 17, 2001 [Page 15] Internet-Draft XML encoding for SMS messages November 2000 Protocol Identifier is given as a one byte long hexadesimal number encoded as a string. For further information on protocol identifier, see GSM specification [3]. 3.2.7 vp - Validity Period The validity period of the message submission is given in the vp element: The validity period is the time after which SMSC can dispand the messages that could not be succesfully submitted yet. The validity period requested by SP is given in the delay data element described in Section 3.2.8.2. 3.2.8 timing Schedule plan for future message submission is given in the timing element The timing element has two child elements: time and delay. The time element specifies the actual point in time when the SMSC should send the messages. The delay element specifies how long the SMSC should wait before sending the messages. The timing element is optional. If the timing element is not given, the messages should be sent immidiately. Only one time point can be specified, either by defining the exact time point or the delay. The reason for this is that so all the SMS messages defined in one submit message can be tracked, based on their message identifier and destination address. 3.2.8.1 time Time element describes a point of time for a certain event. It is used in time stamps and also when scheduling message submissions from SMSC to MTs at certain future time points. The time element has the following structure: Koponen, et. al. Expires May 17, 2001 [Page 16] Internet-Draft XML encoding for SMS messages November 2000 The child elements are defined as: The time is given with seven parameters: year, month, day, hour, minute, second and the timezone. The elements are given as follows: o Year as an integer, e.g. 2000. o Month as an integer from 1 to 12. o Day as an integer from 1 to 31. o Hour as an integer from 0 to 23. o Minute as an integer from 0 to 59. o Second as an integer from 0 to 59. o The time zone is given as an integer from -11 to 12, as described by UMT (TODO: reference). 3.2.8.2 delay The time the SMSC should wait before submitting the SMS messages after it has received the submit request is defined with the delay element: The child elements year, month, day,hour, minute and second are defined in the previous Section 3.2.8.1. SMSC policy defines whether very long delay periods are supported. All child elements are optional. In this way, a one minute delay, for example, can be given as 1 . Koponen, et. al. Expires May 17, 2001 [Page 17] Internet-Draft XML encoding for SMS messages November 2000 3.2.9 QoS - Quality of Service The quality of service information is given in the QoS element: The format of the content of the QoS element depends on the SMSC implementation. If the SMSC supports some quality of service mechanism, the corresponding data can be defined in the QoS element. For example, a news message is sent to 10000 MTs at a certain time and simultaneously few customers are having a service transaction with the SP. Clearly, bulk messages should have low quality of service, and those having online transaction should have high quality of service to ensure fast responce. 3.2.10 messageID - Message Identifier The message Identifier is given in the messageID element: The message identifier is used by the SP to track the delivery of its messages. The submitter, that is, the SP, chooses the actual format. If the SP sends a submit message, it receives back a deliverystatus message. In the deliverystatus message, the messageID element defines the original submit message to which the deliverystatusreport refers. Since the SMSC can not trust that SP uses unique message identifiers, it has to support also an inherent message reference identifier specified by the mref element discussed in Section 3.9.1. If the SP wants to query the status of messages or delete submitted messages, it has to refer to them with the mref element. 3.2.11 cost If the SP delivers a service of nondefault price, it can inform the SMSC that the service should be charged more (or less) than the default price. The pricing information is delivered by the cost element: The content of the cost element is not specified, but it could contain the price class or determine how much the service actually costs. Koponen, et. al. Expires May 17, 2001 [Page 18] Internet-Draft XML encoding for SMS messages November 2000 The cost element is needed when the MT user requests a premium priced service. The MT originated deliver message has a standard price, or it may even be free for the MT user, but as the SP creates the submit message and sends it to the SMSC, the SP signals to the SMSC that the MT user should be billed for a certain price. In this way, the service user is billed for the actual service and not for the service request. Would the SP, for some reason, fail in providing the service, the MT is not billed - at least not the whole price. 3.2.12 rsr - Request status Report If the SP wants to get a deliverstatusreport message from the SMSC as a response to the submit message, the rsr element should be added: If the rsr element is present in the submit message, the deliverstatusreport message is sent. If rsr is not present, no reports are sent. 3.3 deliver The deliver message discussed in Section 2.2 has the following structure: The submit element contains ten child elements. The child elements are oa, originating address, da, destination address, ud user data, ud, user data header, pid, protocol identifier, timing, location and messageID. Only the oa element and the deliverID element are compulsory. Most of the elements were already defined in Section 3.2: o The oa (originating address) element contains the address of the MT from which the message originates. The originating address must always be specified. The oa element is described in Section 3.2.2. o The da (destination address) element contains the service address to which the SMS message was sent. If there is a default service address, the destination address can be left out. The da element is described in Section 3.2.1. Koponen, et. al. Expires May 17, 2001 [Page 19] Internet-Draft XML encoding for SMS messages November 2000 o The ud (user data) element contains the actual payload of the message, as described in Section 3.2.3. If the ud data element does not exist, the MT has not submitted any messages, but the SMSC wants to provide the SP with some information about the MT (e.g., its location). o The udh (user data header) is described in Section 3.2.4. o The dcs (data coding scheme) is described in Section 3.2.5. o The pid (protocol identifier) is described in Section 3.2.6. o The QoS (Quality of Service) is described in Section 3.2.9. If the service provider is able to provide various qualities of service, the SMSC may signal it to give different levels to different customers. For example, high end business customers can always be granted the best possible quality of service. o The mref (message reference) is described in Section 3.9.1. When the SMSC sends a deliver message, it expects to receive an acknowledgement in response. The acknowledgement contains the same mref element and SMSC can associate the acknowledgement to the correct deliver message. The deliver message introduces two new elements: scts and location. The scts (Service Center Time Stamp) determines the time at which the SMSC received the SMS message from an MT. The location element can be used to transmit information on the location of an MT. The structure of these elements are defined in the following subsections. Note, that a deliver element may lack the ud element, i.e., the actual SMS message. This makes sense, for example if the SMSC wants to notify the SP that a certain MT is at certain location. 3.3.1 scts - Service Center Time Stamp Service center time stamp is given in the scts element: Service center time stamp is the time stamp given by the SMSC. The time stamp defines the exact point in time at which the SMSC received the message from an MT. The argument of the scts element is the time element defined in Section 3.2.8.1. 3.3.2 location The location element can be used to carry position information of Koponen, et. al. Expires May 17, 2001 [Page 20] Internet-Draft XML encoding for SMS messages November 2000 the MT: The actual format of the location data is not specified here, since not all SMSC:s support delivery of the location data. The GSM specification would allow the delivery of the location based on the home location register data. The system knows always in which cell the MT is. The development of mobile location systems is going on rapidly. 3.4 deliverstatusreport If the SP has requested the delivery status report in a submit message, the SMSC submits a deliverstatusreport as described in Section 2.1. The structure of the message is the following: The mref element as described in Section 3.9.1 refers to the initial submit message (the mref identifier is given in the acknowledgement in response to the initial submit message). The second child element is a statuslist element providing the status of each message. The statuslist element is described in the next subsection. 3.4.1 statuslist The statuslist element carries the status information. It connects destination addresses to the status information. Not all of the mobile terminals can be reached at the same time, so the status varies from message to message. The status of a requested SMS message submission is given in the status element defined as: The da element is the destination address to which the message will be submitted. The structure of the da element is described in Section 3.2.1. The message status can have four different states which are defined according to the GSM standard. The states have the following meanings: Koponen, et. al. Expires May 17, 2001 [Page 21] Internet-Draft XML encoding for SMS messages November 2000 o ok, the message has been succesfully delivered to the destination MT. o expired, the messages validity period has been ended before the message has been delivered to the MT. o delayed, the destination MT has not been reached. Its power may be switched of, or it mey be outside the mobile network. o cancelled, the message submission has been cancelled for some reason. 3.5 statusreportrequest The service provider can query the status of messages submitted to the SMSC in a submit message as described in Section 2.3. To query the status of a message, the SP must send a statusreportrequest message. The structure of the message is defined as: The mref element as defined in Section 3.9.1 defines the original submit message. The messageID element is a handle to the statusreport so that the SP can associate a received statusreport or nack message to the correct statusreportrequest message. Now the SP has to use the message reference created by SMSC given in the acknowledgement in response to the original submit message. The structure of the mref element is defined in Section 3.9.1. 3.6 statusreport The SMSC responds to a statusreportrequest message with a statusreport defined as: The first element is the mref element which refers to the initial submit message sent by the SP. The messageID element contains the reference to the earlier statusreportrequest sent by the SP. The third child element is a list of the statuslist elements (see Section 3.4.1, in which the actual information on message status is stored. 3.7 delete If the SP wants to delete messages submitted earlier, it can send a delete message as described in Section 2.4. The structure of the Koponen, et. al. Expires May 17, 2001 [Page 22] Internet-Draft XML encoding for SMS messages November 2000 delete message element is: Here, the first mandatory child element is the mref element (defined in Section 3.9.1), which defines the submit message that should be deleted either completely or partially. The second element (messageID, Section 3.2.10) is a handle for the deletereport so that the SP can associate a received deletereport or nack message to the correct delete message. The SMSC should give the messageID element value unchanged in the responding deleterequest message. The third element (da, Section 3.2.1) is optional and can be used to define the destination addresses to which message submissions have been scheduled and the scheduled submissions should be cancelled. If the da element is not specified, all the SMS messages pointed by the message reference, i.e., all the messages specified should be canceled in the initial submit message to which the mref element points. 3.8 deletereport After the SP has submitted a delete message to the SMSC, the SMSC deletes messages and responds then with a deletereport message. The deletereport message is defined as follows: Here the mref element refers to the initial submit element which has requested for submission of the messages now deleted. The messageID element refers to the delete message for which the deletereport message is a response. The deleteOK element defines the messages referred to with their destination addresses for which the delete operation was succesful. Similarly, The deleteNOTOK element defines the messages refereed with their destination addresses for which the delete operation was not succesful. The deleteOK and deleteNOTOK elements are specified as follows: 3.9 ack - Acknowledgement After submission of submit or deliver message, the receiver must submit an acknowldgement. The acknowledgement is defined by the ack element: Koponen, et. al. Expires May 17, 2001 [Page 23] Internet-Draft XML encoding for SMS messages November 2000 The child elements in the ack element are the messageID (message identifier) element, as described in Section 3.2.10, and the mref (the message reference) element, as described in the next subsection. The acknowledgement is used for two reasons. It gives a possibility for the SMSC to see that the deliver message has reached SP so that it does not have to resend it. The second reason is that when the SP sends a submit message, it receives a message reference in return which can be used for requesting status information or deleting messages. 3.9.1 mref - Message Reference The message reference is a pointer used by the SMSC to refer to a submit message sent by the SP. The SMSC uses also identifiers for the deliver messages it submits to the SP. Since the SMSC cannot trust that the SP would always use unique identifiers in the submit messages (the messageID element described in Section 3.2.10), it must use its own reference identifiers. These identifiers, called message references, are defined as: The content of the mref element is given as a alphanumeric string. 3.10 nack - Negative Acknowledgement If a message can not be processed, the message receiver responds with a negative acknowledgement. The structure of the The nack element contains first the message identifier (messageID) if the negative acknowledgement is a response to a message sent by the SP. If the negative acknowldgemenet is a responce to a message sent by the SMSC, then the first element is the message reference (mref) element. The last child element is the errormessage element, which is defined as: Koponen, et. al. Expires May 17, 2001 [Page 24] Internet-Draft XML encoding for SMS messages November 2000 Here, only two error situations are specified. The xmlparsingerror element describes a case in which the initial message was not well-formed, and the XML parsing was not succesful. The outofstorage element is sent if the initial message can not be processed due to ending memory or other storage space. The third possibility is to the othererror element in which a customized error message can be delivered. Koponen, et. al. Expires May 17, 2001 [Page 25] Internet-Draft XML encoding for SMS messages November 2000 4. Security Considerations The SMS messages may carry sensitite information or information which has of monetary value. Also, the MT user pays for the service, and also the SP might pay to the SMSC for the usage of the gateway. If the protocol described is used over the Internet, all traffic should be hidden. It must not be possible for any unauthorized third party to act as SP or SMSC either. Therefore, strong encryption of the messages and authentication are required. However, the purpose of the protocol described in this draft is not to provide a solution for these security problems. The underlying message passing protocol should provide the required security services. There are relatively many message passing protocols ensuring data security, for example, the Transport Layer Security (TLS) [5]. Since the SMS messages carried by a submit message might have considerable value for the SP, it must have a possibility to be sure that the messages were actually sent. Currently, this protocol provides only the acknowledgement message and the two report messages to ensure the delivery. Koponen, et. al. Expires May 17, 2001 [Page 26] Internet-Draft XML encoding for SMS messages November 2000 References [1] Bray, T., Paoli, J. and M. Sperberg-McQueen, "Extensible Markup Language (XML) 1.0", W3C Recommendation , February 1998, . [2] Martin, B. and B. Jano, "WAP Binary XML Content Format", W3C Note , June 1999, . [3] "Digital cellular telecommunications system (Phase 2+); Technical realization of the Short Message Service (SMS) Point-to-Point (PP)", ETSI GSM 03.40, version 5.3.0, July 1996. [4] "Digital cellular telecommunications system (Phase 2+); Alphabets and language-specific infromation", ETSI GSM 03.38, version 5.3.0, July 1996. [5] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999, . Authors' Addresses Juha P. T. Koponen First Hop Ltd. Tekniikantie 12 Espoo, FIN-02150 Finland Phone: +358 9 2517 2325 EMail: Juha.Koponen@firsthop.com URI: http://www.firsthop.com/ Teemu Ikonen First Hop Ltd. Lasse Ziegler First Hop Ltd. Koponen, et. al. Expires May 17, 2001 [Page 27] Internet-Draft XML encoding for SMS messages November 2000 Appendix A. Examples of XML encoded messages A.1 submit message +358991234567 +358997654321 Merry Christmas ! 1 A.2 ack message 0000001 1 Koponen, et. al. Expires May 17, 2001 [Page 28] Internet-Draft XML encoding for SMS messages November 2000 A.3 deliverstatusreport message 0000001 +358991234567 +358997654321 Koponen, et. al. Expires May 17, 2001 [Page 29] Internet-Draft XML encoding for SMS messages November 2000 Appendix B. Full DTD of the messages Koponen, et. al. Expires May 17, 2001 [Page 30] Internet-Draft XML encoding for SMS messages November 2000 Koponen, et. al. Expires May 17, 2001 [Page 31] Internet-Draft XML encoding for SMS messages November 2000 Appendix C. Acknowledgements The authors gratefully acknowledge the contributions of Jaakko Tiistola and Harri J„„linoja. Thanks to Juhana R„s„nen and Olli Auvinen for important comments and suggestions for the draft and thanks to Heli Harri for proof reading the draft. Juha P„„j„rvi is thanked for his advice related to the IETF process. Koponen, et. al. Expires May 17, 2001 [Page 32]