Network Working Group J.P.T. Koponen Internet-Draft T. Ikonen Expires: October 14, 2002 L. Ziegler First Hop Ltd. April 15, 2002 XML encoding for SMS messages draft-koponen-sms-xml-03.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 October 14, 2002. Abstract Short Message Service (SMS) messages have become very popular among mobile phone users. However, the service providing is still relatively awkward. This draft presents an encoding and a simple protocol for describing and submitting SMS messages over the Internet. The protocol is aimed to be used between service providers and SMS gateways. The SMS messages are encoded in XML and the corresponding Document Type Definition (DTD) for the message structure is described. Koponen, et. al. Expires October 14, 2002 [Page 1] Internet-Draft XML encoding for SMS messages April 2002 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Glossary of Terms . . . . . . . . . . . . . . . . . . . . 5 1.2 Scope of this Document . . . . . . . . . . . . . . . . . . 6 1.2.1 Issues not considered in the protocol . . . . . . . . . . 6 1.3 Benefits of XML as the SMS message format . . . . . . . . 7 1.4 Service Provisioning Architecture . . . . . . . . . . . . 8 1.5 International Character Sets . . . . . . . . . . . . . . . 9 2. The Protocol . . . . . . . . . . . . . . . . . . . . . . . 10 2.1 SP sends a submit message to SMSG . . . . . . . . . . . . 10 2.2 SMSG sends deliver message to SP . . . . . . . . . . . . . 11 2.3 SP sends statusreportrequest message to SMSG . . . . . . . 11 2.4 SP sends delete message to SMSG . . . . . . . . . . . . . 12 3. DTD Specification of the messages . . . . . . . . . . . . 13 3.1 The message root . . . . . . . . . . . . . . . . . . . . . 13 3.2 submit . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.2.1 da - Destination Address . . . . . . . . . . . . . . . . . 14 3.2.1.1 number - Address Number . . . . . . . . . . . . . . . . . 15 3.2.1.2 group . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.2.1.3 email . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.2.1.4 atype - Address Type . . . . . . . . . . . . . . . . . . . 16 3.2.1.5 shadow . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.2.2 oa - Originating Address . . . . . . . . . . . . . . . . . 17 3.2.3 ud - User Data . . . . . . . . . . . . . . . . . . . . . . 17 3.2.4 udh - User Data Header . . . . . . . . . . . . . . . . . . 18 3.2.5 dcs - Data Coding Scheme . . . . . . . . . . . . . . . . . 18 3.2.6 pid - Protocol Identifier . . . . . . . . . . . . . . . . 18 3.2.7 vp - Validity Period . . . . . . . . . . . . . . . . . . . 19 3.2.8 timing . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.2.8.1 at . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.2.8.2 delay . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.2.9 qos - Quality of Service . . . . . . . . . . . . . . . . . 21 3.2.10 cost . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.2.11 rsr - Request status Report . . . . . . . . . . . . . . . 21 3.3 deliver . . . . . . . . . . . . . . . . . . . . . . . . . 22 3.3.1 scts - Service Center Time Stamp . . . . . . . . . . . . . 23 3.3.2 location . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.4 deliverystatus . . . . . . . . . . . . . . . . . . . . . . 23 3.4.1 said . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.5 statusreportrequest . . . . . . . . . . . . . . . . . . . 24 3.6 delete . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.7 deletereport . . . . . . . . . . . . . . . . . . . . . . . 25 3.8 ack - Acknowledgement . . . . . . . . . . . . . . . . . . 25 3.9 to . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.10 from . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 4. Security Considerations . . . . . . . . . . . . . . . . . 28 References . . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 29 Koponen, et. al. Expires October 14, 2002 [Page 2] Internet-Draft XML encoding for SMS messages April 2002 A. Examples of XML encoded messages . . . . . . . . . . . . . 31 A.1 submit message . . . . . . . . . . . . . . . . . . . . . . 31 A.2 ack message . . . . . . . . . . . . . . . . . . . . . . . 31 A.3 deliverystatus message . . . . . . . . . . . . . . . . . . 32 B. Full DTD of the messages . . . . . . . . . . . . . . . . . 33 C. Draft Modifications . . . . . . . . . . . . . . . . . . . 35 C.1 Difference of version (03) to earlier version (02) . . . . 35 C.2 Difference version of (02) to version (01) . . . . . . . . 35 C.3 Difference of version (01) to version (00) . . . . . . . . 35 D. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 37 Koponen, et. al. Expires October 14, 2002 [Page 3] Internet-Draft XML encoding for SMS messages April 2002 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 probably replace SMS messages as the most popular media for wireless applications, there will still be a very large user base for a long time. The great market interest related to WAP and the so-called mCommerce (mobile commerce) has also made 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) lists five SMSC protocols, SMPP (by Logica), CIMD (by Nokia), UCP/EMI (by CMG), SMS2000 (by SEMA) and a protocol by Ericsson [1]. 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. Therefore, there are several SMS gateways able to interact with some or all of the SMS protocols. SMS gateways are proxies between the SMS Centers and service providers which transform the complex telecommunications protocol interfaces to more simple interfaces used by the content providers. 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 gateways for service providers. A common interface would strongly enhance the interplay among the industry if all the possible SMS services could be connected to which ever SMS gateways. Customers are actually paying for the services delivered in the SMS messages. Therefore, quality of service and security measures are very important. The service providers are willing to become international. This Koponen, et. al. Expires October 14, 2002 [Page 4] Internet-Draft XML encoding for SMS messages April 2002 means that they have to connect their services to various SMS centers in many countries, and even to many SMS centers in one country, if the users of several operators are to be served. As the number of supported centers increases, one SMS gateway cannot handle all the SMS centers. There has to be several SMS gateways distributed throughout the world. These gateways need to interact if global services are to be developed. The other messaging systems (wireless, or Internet-based) in use parallel to SMS are the common email, pager messaging, instant messaging and presence [2]. Coupling all these systems is very attractive and would enhance the experience and reachability of end users in partly mobile communities, for example, with presence services. This draft provides an open interface for other messaging systems to interconnect with SMS messaging. The connection can be implemented with, e.g., a proxy able to convert XML-encoded SMS messages to instant messages and vice versa. 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 [3] for through definitions. 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 hand-held 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. SMSC devices support binary protocols which have been standardized and published by several companies and organizations. Five of these are listed by ETSI. A software module called an SMS gateway is used to give instructions to the SMSC. SMSG (Short Message Service Gateway): the proxy between the SP and SMSC. Since there are many SMSC protocols and the structure of these protocols is relatively cryptic, SMSGs are used by SPs to connect to SMSCs. Also, if the SP transacts with several SMSCs, the logic is Koponen, et. al. Expires October 14, 2002 [Page 5] Internet-Draft XML encoding for SMS messages April 2002 embedded into the SMSG. SP (Service Provider): an entity that 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 XML-encoded packets described later in this document. The service provider could also be a proxy transforming messages from other messaging systems. 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 [3]. WASP: Wireless Application Service Providing is the wireless version of the ASP (Application Service Providing) concept. The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to interpreted as described in RFC 2119. 1.2 Scope of this Document This draft describes an interface between an SMSG and an SP. The SMSG and SP may reside at different physical locations and may be 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 their SMS centers via standard SMS gateway interfaces, 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 databases hosted by the SP. 1.2.1 Issues not considered in the protocol This document presents a simple protocol for messaging between a service provider and an SMS gateway. 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. Koponen, et. al. Expires October 14, 2002 [Page 6] Internet-Draft XML encoding for SMS messages April 2002 The order of the submitted packets should be conserved. There are service applications in which the order of the packets coming from the 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 a 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 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 SMS gateway 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) [8] 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 [3] for providing a unified way to present documents and messages in the Internet. XML provides a standard way of describing 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 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 an 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 Koponen, et. al. Expires October 14, 2002 [Page 7] Internet-Draft XML encoding for SMS messages April 2002 layer of the protocol stack, and therefore binary encoding schemes would make application development for the protocol awkward and slow. XML speeds up application programming. The drawback is the increased bandwidth usage compared to binary encodings. We think that the benefits due to accelerated application programming are larger than the costs due to the larger bandwidth 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) [4] 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 bandwidth 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. Other option is to encode XML in ASN.1 format as described in [5]. 1.4 Service Provisioning Architecture The service provider submits the XML encoded SMS message to the SMSG. If the SMSG resides in other physical location, the connection is done over the Internet. The SMSG 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 SMSG and the service provider, i.e, the connection 3 in Figure 1. The protocol defines the messaging between one Service Provider and one SMS gateway. In real cases, there may be many service providers connected to the SMSG. Also, one service provider may also use many SMSGs. On the other hand, the SP can actually be another SMSG resulting in a network of SMS gateways. -------- ---------- ---------- -------- | | 1. | | 2. | | 3. | | | MT | <-----> | SMSC | <-----> | SMSG | <-----> | SP | | | | | | | | | -------- ---------- ---------- -------- Figure 1: The chain connecting the mobile terminal (MT) to the service provider (SP). The general SMS messaging environment contains several service providers, and several operators who have several SMS centers in many countries. In addition, there could be connections to other messaging systems, such as the Instant Messaging systems. The general environment is illustrated in Figure 2. Koponen, et. al. Expires October 14, 2002 [Page 8] Internet-Draft XML encoding for SMS messages April 2002 ... | OMS1 | SMSC1 ---- SMSG1 ----- SP1 / | \ / | \ SMSC2 -- | ----- SP2 | | SMSC3 ---- SMSG2 ----- SP3 | / | / OMS2 --- | ... Figure 2: An example of a generic environment which contains many service providers (SP), SMS centers, SMS gateways and other messaging systems (OMS). All the players are connected to each other in unpredictable ways. The services are hosted by different organizations and therefore we cannot assume that the overall configuration is optimized. 1.5 International Character Sets The implementer of an SMSG can choose the supported character sets. The 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 must define the character set with the encoding attribute: ... Koponen, et. al. Expires October 14, 2002 [Page 9] Internet-Draft XML encoding for SMS messages April 2002 2. The Protocol The protocol described in this document consists of four different message exchange cases. The messages are named according to normal GSM parlance: SMS messages sent from an SP to the mobile terminal (MT) 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 a 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: submit, deliver, ack, deliverstatus, statusreportrequest, delete, and deletereport. Both the positive acknowledgment and negative acknowledgments are carried in ack messages. The rest of the messages are described in the next sections. 2.1 SP sends a submit message to SMSG The SP wants to send one or more SMS messages to one or more MTs. The SP requests SMSG to submit the SMS messages by sending a submit message. The actual messages are encoded in one submit message. There may be instructions for sending several SMS messages at different times. The SMSG sends back an acknowledgment immediately. The acknowledgment contains a unique ID number for the submit. After receiving the initial submit from the SP, SMSG processes the message and sends it to an SMSC which forwards it to the MT. When SMSG receives acknowledgments from the SMSC, it sends another acknowledgment to the SP to indicate a successful or unsuccessful sending. After receiving a successful acknowledgment, the SP can be sure that the message has been sent to the SMSC. Finally, after SMSG has received deliverystatuses from SMSC, it sends a deliverystatus message to the original submitting SP ensuring that the message has been successfully received by the MT. If EMG has not received the acknowledgments or deliverystatus from SMSC within a certain time, it will mark the message as failed and will send a negative deliverystatus message to the SP. The second acknowledgment and the deliverystatus message are optional and must be requested in the submit message. Koponen, et. al. Expires October 14, 2002 [Page 10] Internet-Draft XML encoding for SMS messages April 2002 SMSG Service Provider submit <------------------------------------------------- ack -------------------------------------------------> ack (originating from SMSC if wished) -------------------------------------------------> deliverystatus -------------------------------------------------> 2.2 SMSG sends deliver message to SP In normal GSM parlance, the case in which SMS messages are transferred from the SMSC to an SP is called deliver and the opposite case discussed in the previous section is called submit. After an MT submits an SMS message to the SMSG, SMSG sends a corresponding deliver message to the SP . The deliver message describes the message originating from the MT. SMSG Service Provider deliver -------------------------------------------------> 2.3 SP sends statusreportrequest message to SMSG This message transaction functionality is OPTIONAL. The implementation of the status report request is not straightforward in the SMS gateway and all the SMSCs might not support such a feature. However, it is needed if the SP requires time critical information about the status of the SMS submits. The SP has earlier sent submit message to the SMSG, in which it has requested submission of scheduled messages. It can query the submission status of the messages by sending a statusreportrequest to the SMSG. If the request is not adequate, the SMSG responds with a negative acknowledgment. If the request is adequate, the SMSG answers with a deliverystatus message. Koponen, et. al. Expires October 14, 2002 [Page 11] Internet-Draft XML encoding for SMS messages April 2002 SMSG Service Provider statusreportrequest <------------------------------------------------- deliverystatus OR ack (negative) -------------------------------------------------> 2.4 SP sends delete message to SMSG This message transaction functionality is OPTIONAL. The implementation of the delete functionality to the existing SMSGs might be impractical and therefore it is not required. The SP has submitted a submit message earlier, 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 SMSG. If the request is not adequate, the SMSG responds with a negative acknowledgment. If the request is adequate, the SMSC sends a deletereport in which the messages which could not be canceled are listed. SMSG Service Provider delete <------------------------------------------------- deletereport or ack (negative) -------------------------------------------------> Koponen, et. al. Expires October 14, 2002 [Page 12] Internet-Draft XML encoding for SMS messages April 2002 3. DTD Specification of the messages 3.1 The message root The root element of this XML specification is a message element: The submit, deliver, ack and deliverstatus messages are REQUIRED and statusreportrequest, delete and deletereport are OPTIONAL. The to element designs the destination node where SMSG should send the message. This may be used, if the SMSG can choose from several SMSCs. Similarly the from element denotes the source node (e.g. a SMSC or another SMSG) of the message. The to (Section 3.9) and from (Section 3.10) elements are OPTIONAL. The attribute cid is an identifier provided by the SP to the SMSG in submit messages so that the SP can correlate the acknowledgments in response to the original messages. The attribute id is the unique identifier used by the SMSG to identify the messages. Therefore, if an SP wants to refer to a submit message with a statusreportrequest message, it must specify the id attribute in the message. The attributes id and cid are REQUIRED. One message element can contain many messages of a same type, but not messages of different types. Here ack is the acknowledgment, positive or negative. The message usage in the protocol is described in Section 2. The structures of the messages are described in the following sections. The elements are always REQUIRED later in this draft unless otherwise defined. 3.2 submit The submit message discussed in Section 2.1 has the following structure: There can be eleven elements nine of which are REQUIRED: da, oa, ud, udh, dcs, pid, vp and timing. Elements qos and cost are Koponen, et. al. Expires October 14, 2002 [Page 13] Internet-Draft XML encoding for SMS messages April 2002 OPTIONAL. The meaning of each element is described in the following list: o The da element contains the destination address which describes the telephone numbers to which the SMS messages will be sent. o The oa element contains the originating address, i.e., the address from which the SMS message comes to a mobile terminal. o The ud element contains user data, i.e., the actual payload in the delivered SMS message. o The udh element contains user data header, which is a payload header as described in GSM specifications. o The dcs element is data coding scheme as described in GSM specifications. o The pid element contains protocol identifier, as described in GSM specifications. o The vp element describes the validity period of the message submission request. o The timing element defines the scheduling of the messages. o qos defines parameters for quality of service. o The cost element defines the price of the message. If the service provisioned by the SP has a non-default price, the price can be specified in the cost element. The structure of the above mentioned 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 consist of just da, oa, udh elements. 3.2.1 da - Destination Address Destination address is carried by the da element: Koponen, et. al. Expires October 14, 2002 [Page 14] Internet-Draft XML encoding for SMS messages April 2002 Here the number 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 number element. The type of the number is specified in the atype element. In some appliances, there are large number lists which occur frequently. In such cases, it is favorable to use the group element, in which a unique identifier specifying the group is submitted. The third possible address is the email address given in the email element. The email element is OPTIONAL. 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 number - Address Number The actual address of the destination MT is given in the number 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 group The group element can be used to avoid submissions of large number lists frequently. The group identifier is given in the group element: The argument is given in string format. The string should be a unique identifier for a predefined group of valid addresses. It is out of the scope of this draft to define how to create new group identifiers between the SP and the SMSG. The type attribute of the group element can have two values, number or email. If the value of the type attribute is number, all the addresses defined in the group Koponen, et. al. Expires October 14, 2002 [Page 15] Internet-Draft XML encoding for SMS messages April 2002 element are telephone numbers, and if email, all the addresses are email addresses. 3.2.1.3 email In order to be able to submit the messages also in email format, the email element can be used: The address is given in string format (e.g. "juha.koponen@firsthop.com"). This instructs the SMSG to treat the message as email. This requires that an SMTP server is attached to the SMSG and therefore the email element is OPTIONAL. 3.2.1.4 atype - Address Type The type of the address given in the number element is given in the atype element: The type identifier is given as a hexadecimal number in string format. The possible types are defined by the GSM specification [5]. 3.2.1.5 shadow If the MT wants to stay anonymous to an 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 used for customer identification. The 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. Koponen, et. al. Expires October 14, 2002 [Page 16] Internet-Draft XML encoding for SMS messages April 2002 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 number child element is described in Section 3.2.1.1, the email child element in Section 3.2.1.3 and the atype child element is described in Section 3.2.1.4. 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: 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 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 [6]. Koponen, et. al. Expires October 14, 2002 [Page 17] Internet-Draft XML encoding for SMS messages April 2002 3.2.4 udh - User Data Header User data header is given in the udh element: The 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 hexadecimal number encoded in string format. For further information, see GSM specification [6]. Note that handling of udh information in GSM, TDMA and CDMA networks is not identical and therefore the use of udh element may cause interoperability problems between these networks. Also, older ANSI-41 based SMS standards have features which are not described in this draft: third acknowledgement and origination and destination subaddresses, and privacy, urgency and language indicators. Third acknowledgement is given by the end user (this draft specifies two acknowledgements: acknowledgement that the SMSC has received the message and the acknowledgement that the hand-set has received the message). Privacy, urgency and lanfuage indicators can partly be encoded in the udh, dcs and pid elements. Since these functionalities do represent only small minority of the SMS protocols, full support is not included in this version of the proposal. 3.2.5 dcs - Data Coding Scheme Data coding scheme is described in the dcs element: The data coding scheme is given as a one byte long hexadecimal number encoded as a string. For further information on data coding scheme, see GSM specification [7]. Note that handling of dcs information in GSM, TDMA and CDMA networks is not identical and therefore the use of dcs element may cause interoperability problems between these networks. 3.2.6 pid - Protocol Identifier Protocol identifier is given in the pid element: Koponen, et. al. Expires October 14, 2002 [Page 18] Internet-Draft XML encoding for SMS messages April 2002 The protocol identifier is given as a one byte long hexadecimal number encoded as a string. For further information on protocol identifier, see GSM specification [6]. Note that handling of pid information in GSM, TDMA and CDMA networks is not identical and therefore the use of pid element may cause interoperability problems between these networks. 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 the SMSC can dispand the messages that could not be successfully submitted. The validity period requested by the SP is given in the delay data element described in Section 3.2.8.2. The validity period can be given in two ways. The relative validity period requested by the SP is given in hexadecimal format as described in the GSM specification [6]. The meaning and format of the absolute validity period refers to ISO 8601 date format. 3.2.8 timing Schedule plan for future message submission is given in the timing element The timing element has two child elements: at and delay. The at 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 immediately. Only one time point can be specified, either by defining the exact time point or the delay. The reason for this is that this way all the SMS messages defined in one submit message can be tracked, based on their message identifier and destination address. Koponen, et. al. Expires October 14, 2002 [Page 19] Internet-Draft XML encoding for SMS messages April 2002 3.2.8.1 at The at element describes a point of time for a certain event. It is used in time stamps and also when scheduling message submissions from the SMSC to MTs at certain future time points. The at element has the following structure: The child elements are defined as: The at 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 defined by UMT (Universal Metric Time). 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 Koponen, et. al. Expires October 14, 2002 [Page 20] Internet-Draft XML encoding for SMS messages April 2002 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 . 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 a 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 response. Implementation of the qos element is OPTIONAL. 3.2.10 cost If the SP delivers a service of non-default 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. 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. Implementation of the cost element is OPTIONAL. 3.2.11 rsr - Request status Report If the SP wants to get a deliverystatus message from the SMSC as a Koponen, et. al. Expires October 14, 2002 [Page 21] Internet-Draft XML encoding for SMS messages April 2002 response to the submit message, the rsr element should be added: If the rsr element is present in the submit message, the deliverystatus 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 cid. 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. 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 SMSG 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 SMSG may signal it to give different levels to Koponen, et. al. Expires October 14, 2002 [Page 22] Internet-Draft XML encoding for SMS messages April 2002 different customers. For example, high end business customers can always be granted the best possible quality of service. The qos element is OPTIONAL. 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 or SMSG wants to notify the SP that a certain MT is at certain location. The location element is OPTIONAL. 3.3.1 scts - Service Center Time Stamp Service center time stamp is given in the scts element: The 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 to scts element is in ISO 8601 format but always in UTC, for example: 2000-11-16T20:00:05Z 3.3.2 location The location element can be used to carry position information of the MT: The actual format of the location data is not specified here, since not all SMSCs support delivery of the location data. The GSM specification would allow the delivery of the location information based on the home location register data. The system always knows in which cell the MT is. The development of mobile location systems is going on rapidly. Location element is OPTIONAL. 3.4 deliverystatus If the SP has requested the delivery status report in a submit message, the SMSC submits a deliverstatus as described in Section 2.1. Also, if the SP sends the SMSG a separate statusreportrequest Koponen, et. al. Expires October 14, 2002 [Page 23] Internet-Draft XML encoding for SMS messages April 2002 message, the SMSG answers with the deliverystatus message. The structure of the message is the following: The said (submit address identifier) element as described in Section 3.4.1 lists the addresses to which the messages were initially submitted. The from element (see section Section 3.10) contains the name of the source node of the deliverystatus message. 3.4.1 said The submit address identifier, said element is defined by: The said element may have ds (deliverystatus) attribute, or acks (acknowledgment status) attribute. The ds attribute is intended to be used when the said element is inside a deliverystatus element. On the other hand, if the said element is inside the ack element, the acks attribute should be used. The delivered and delivery failed fields in the ds attribute are REQUIRED and the expired, delayed and canceled fields are OPTIONAL. The reason for this is that some of the SMSCs support only two deliverystatus options (i.e., delivered or delivery failed) and some of them support richer vocabulary to describe the status of the delivery. 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 follows: The statusreportrequest is an empty element. The original submit message, the status of which is queried, is defined in the id attribute of the parent element message Figure 8. The statusreportrequest functionality is OPTIONAL. Koponen, et. al. Expires October 14, 2002 [Page 24] Internet-Draft XML encoding for SMS messages April 2002 3.6 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 delete message element is: The original submit message to which the delete operation should be applied is defined in the id attribute of the message father element, as described in Section 3.2.1. The da element (see Section 3.2.1) is used to define the destination addresses to which message submissions have been scheduled and the scheduled submissions should be canceled. If the da element is not specified, i.e., the amount of the da elements is zero, all the SMS messages pointed by the message reference (the id attribute of the message father element) should be deleted in the initial submit message. The delete functionality is OPTIONAL. 3.7 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: The deleteok element defines the messages referred to with their destination addresses for which the delete operation was successful. Similarly, the deletenotok element defines the messages referred to with their destination addresses for which the delete operation was not successful. The deleteok and deletenotok elements are specified as follows: The deletereport functionality is OPTIONAL. Although, if the delete message is implemented, also the deletereport messages should be implemented. 3.8 ack - Acknowledgement After submission of a submit or a deliver message, the receiver must submit an acknowledgment. The acknowledgment is defined by the ack Koponen, et. al. Expires October 14, 2002 [Page 25] Internet-Draft XML encoding for SMS messages April 2002 element: The child elements in the ack element are the said element, as described in Section 3.4.1, and the from element, as described in Section 3.10. The from element is OPTIONAL. The acknowledgment is used for two reasons. It makes it possible for the SMSC to see that the deliver message has reached the 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 to The to element is defined as follows: The value in the to element describes the destination node of the message. The to element is can be used if the SMSG is connected to several SPs or an SP is connected to several gateways. The identifier carried in the to element should be unique for the participants. For example, if the service provider is connected to several telephone operators SMSCs, the to element can be used to define the name of the operator. On the other hand, if there are several service providers, the to element may carry the name of the destination service provider. 3.10 from The from element is defined as follows: The value in the from element describes the source node of the message. The from element is used if the gateway is connected to several SPs, or the SP is connected to several gateways. If the to and from functionality is implemented, the SMSG acts effectively as a router for the SMS messages. The identifiers in the Koponen, et. al. Expires October 14, 2002 [Page 26] Internet-Draft XML encoding for SMS messages April 2002 to and from elements could point to SMS centers, SMS gateways, service providers or access gateways to other messaging systems (e.g. Instant Messaging). Koponen, et. al. Expires October 14, 2002 [Page 27] Internet-Draft XML encoding for SMS messages April 2002 4. Security Considerations SMS messages may carry sensitive information or information which has 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 an SP or an 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) [8]. Since the SMS messages carried by a submit message might have considerable value for the SP, it must have the possibility to be sure that the messages were actually sent. Currently, this protocol provides only the acknowledgment message and the two report messages to ensure the delivery. Koponen, et. al. Expires October 14, 2002 [Page 28] Internet-Draft XML encoding for SMS messages April 2002 References [1] "Digital cellular telecommunications system (Phase 2+) (GSM); Universal Mobile Telecommunications System (UMTS); Interface protocols for the connection of Short Message Service Centres (SMSCs) to Short Message Entities (SMEs) (3GPP TR 23.039 version 4.0.0 Release 4)", ETSI TR 123 039 V4.0.0 (2001-03), European Telecommunications Standards Institute. [2] Day, M., Aggarwal, S., Mohr, G. and J. Vincent, "Instant Messaging / Presence Protocol Requirements", RFC 2779, February 2000, . [3] Bray, T., Paoli, J. and M. Sperberg-McQueen, "Extensible Markup Language (XML) 1.0", W3C Recommendation , February 1998, . [4] Martin, B. and B. Jano, "WAP Binary XML Content Format", W3C Note , June 1999, . [5] "ASN.1 encoding rules; Encoding XML-Defined Data Using ASN.1", ITU-T Rec. X.694 (2002) ISO/IEC 8825-5:2002, International Telecommunications Union. [6] "Digital cellular telecommunications system (Phase 2+); Technical realization of the Short Message Service (SMS); (GSM 03.40 version 7.4.0 Release 1998)", ETSI TS 100 901, V7.4.0 (1999-12), European Telecommunications Standards Institute. [7] "Digital cellular telecommunications system (Phase 2+); Alphabets and language-specific information (GSM 03.38 version 7.2.0 Release 1998)", ETSI TS 100 900, V7.2.0 (1999-07), European Telecommunications Standards Institute. [8] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999, . Koponen, et. al. Expires October 14, 2002 [Page 29] Internet-Draft XML encoding for SMS messages April 2002 Authors' Addresses Juha P. T. Koponen First Hop Ltd. Porkkalankatu 20 c A Helsinki, FIN-00180 Finland Phone: +358 10 2866 440 EMail: Juha.Koponen@firsthop.com URI: http://www.firsthop.com/ Teemu Ikonen First Hop Ltd. Lasse Ziegler First Hop Ltd. Koponen, et. al. Expires October 14, 2002 [Page 30] Internet-Draft XML encoding for SMS messages April 2002 Appendix A. Examples of XML encoded messages A.1 submit message +358991234567 +358997654321 Merry Christmas ! 2000 12 24 18 0 0 -2 A.2 ack message Koponen, et. al. Expires October 14, 2002 [Page 31] Internet-Draft XML encoding for SMS messages April 2002 A.3 deliverystatus message +358991234567 +358997654321 Koponen, et. al. Expires October 14, 2002 [Page 32] Internet-Draft XML encoding for SMS messages April 2002 Appendix B. Full DTD of the messages Koponen, et. al. Expires October 14, 2002 [Page 33] Internet-Draft XML encoding for SMS messages April 2002 Koponen, et. al. Expires October 14, 2002 [Page 34] Internet-Draft XML encoding for SMS messages April 2002 Appendix C. Draft Modifications C.1 Difference of version (03) to earlier version (02) This version does not contain changes to the version (02). C.2 Difference version of (02) to version (01) This version makes only small changes to the earlier version (01). Few bugs in the DTD are corrected, and now the DTD is well formed. In order to gain well formedness, slight changes were made to the following elements and attributes: o The cid attribute of the message element. o The id attribute of the message element. o The submit element. o The ds attribute of said element. o The acks attribute of the said element. o The status attribute of the ack element. In addition, GSM specification references were updated to newer versions, and comments related to ASN.1 encoding of XML messages as well as ANSI-41 SMS format were added. C.3 Difference of version (01) to version (00) The draft (01) evolved rather much from the first version (00). There are two major refinements. Firstly, the concept of SMSC in previous version (00) covered both the actual SMS center and the SMS gateway. In this version (01), the difference is underlined and more traditional GSM parlance is used. Secondly, the XML specification is altered to a certain extent in order to correlate more with the GSM specifications. The experience with an SMS gateway in production use led the authors to simplify the messaging protocol a lot. o Abstract: SMS centers is changed to SMS gateways since the actual use of the protocol is to transact with the gateway as the SMS center protocols have already matured. o Introduction: paragraphs discussing connecting SMS gateways to each others and to other messaging systems were added. o Both the deliverystatusreport message in response to a submit message and the statusreport message in response to a Koponen, et. al. Expires October 14, 2002 [Page 35] Internet-Draft XML encoding for SMS messages April 2002 statusreportrequest message are replaced with a deliverystatus message. Now, there is only one type of statusreport messages. o The ack message in response to the deliver message is removed. The reason for this is that now the SMSG or the SMSC do not have to remember the deliver messages they have sent. The actual business transactions are managed by the SP and if there are some related problems, the SP should react, for example, by resubmitting the initial submit message. o The to and from elements were added in order to enable the routing of the SMS messages between several service providers and several SMS centers. o The messageID and mref elements used extensively in the version 00 were replaced with id and cid attributes in the message element. The cid attribute corresponds to the messageID and the id attribute to the mref element. Also, the said element was added in order to simplify the identifier handling. Koponen, et. al. Expires October 14, 2002 [Page 36] Internet-Draft XML encoding for SMS messages April 2002 Appendix D. Acknowledgements Olivier Dubuisson, Kevin Holley, Gwenael Le Bodic, Friedheld Rodermund, Jan Soegaard-Hansen and James Yu are thanked for their useful comments and suggestions. The authors gratefully acknowledge the contributions of Jaakko Tiistola and Harri Jaalinoja. Koponen, et. al. Expires October 14, 2002 [Page 37]