idnits 2.17.1 draft-becker-core-coap-sms-gprs-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC7252]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 8, 2014) is 3547 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC4395' is mentioned on line 436, but not defined ** Obsolete undefined reference: RFC 4395 (Obsoleted by RFC 7595) == Unused Reference: 'RFC3966' is defined on line 470, but no explicit reference was found in the text == Unused Reference: 'RFC3986' is defined on line 473, but no explicit reference was found in the text == Unused Reference: 'RFC5234' is defined on line 480, but no explicit reference was found in the text == Outdated reference: A later version (-27) exists of draft-bormann-coap-misc-26 ** Downref: Normative reference to an Informational draft: draft-bormann-coap-misc (ref. 'I-D.bormann-coap-misc') == Outdated reference: A later version (-21) exists of draft-ietf-core-block-15 == Outdated reference: A later version (-11) exists of draft-silverajan-core-coap-alternative-transports-06 ** Downref: Normative reference to an Informational draft: draft-silverajan-core-coap-alternative-transports (ref. 'I-D.silverajan-core-coap-alternative-transports') Summary: 4 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE M. Becker, Ed. 3 Internet-Draft ComNets, TZI, University Bremen 4 Intended status: Standards Track K. Li 5 Expires: February 9, 2015 Huawei Technologies 6 K. Kuladinithi 7 T. Poetsch 8 ComNets, TZI, University Bremen 9 August 8, 2014 11 Transport of CoAP over SMS 12 draft-becker-core-coap-sms-gprs-05 14 Abstract 16 Short Message Service (SMS) of mobile cellular networks is frequently 17 used in Machine-To-Machine (M2M) communications, such as for 18 telematic devices. The service offers small packet sizes and high 19 delays just as other typical low-power and lossy networks (LLNs), 20 i.e. 6LoWPANs. The design of the Constrained Application Protocol 21 (CoAP) [RFC7252], that took the limitations of LLNs into account, is 22 thus also applicable to other transports. The adaptation of CoAP to 23 SMS transport mechanisms is described in this document. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on February 9, 2015. 42 Copyright Notice 44 Copyright (c) 2014 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 63 4. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4.1. MO-MT Scenarios . . . . . . . . . . . . . . . . . . . . . 4 65 4.2. MT Scenarios . . . . . . . . . . . . . . . . . . . . . . 4 66 4.3. MO Scenarios . . . . . . . . . . . . . . . . . . . . . . 5 67 5. Message Exchanges . . . . . . . . . . . . . . . . . . . . . . 6 68 5.1. Message Exchange for SMS in a Cellular-To-Cellular 69 Mobile-Originated and Mobile-Terminated Scenario . . . . 6 70 6. Encoding Schemes of CoAP for SMS transport . . . . . . . . . 7 71 7. Message Size Implementation Considerations . . . . . . . . . 7 72 8. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 9. Options . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 9.1. New Options for mixed IP operation. . . . . . . . . . . . 8 75 10. URI Scheme . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 11. Transmission Parameters . . . . . . . . . . . . . . . . . . . 9 77 12. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 9 78 13. Security Considerations . . . . . . . . . . . . . . . . . . . 9 79 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 80 14.1. CoAP Option Number . . . . . . . . . . . . . . . . . . . 10 81 14.2. URI Scheme Registration . . . . . . . . . . . . . . . . 10 82 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 83 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 84 16.1. Normative References . . . . . . . . . . . . . . . . . . 10 85 16.2. Informative References . . . . . . . . . . . . . . . . . 11 86 Appendix A. Changelog . . . . . . . . . . . . . . . . . . . . . 12 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 89 1. Introduction 91 This specification details the usage of the Constrained Application 92 Protocol on the Short Message Service (SMS) of mobile cellular 93 networks. 95 1.1. Motivation 97 In some M2M environments, internet connectivity is not supported by 98 the constrained end-points, but a cellular network connection is 99 supported instead. Internet connectivity might also be switched off 100 for power saving reasons or the cellular coverage does not allow for 101 Internet connectivity. In these situations, SMS will be supported, 102 instead of UDP/IP over General Packet Radio Service (GPRS), High 103 Speed Packet Access (HSPA) or Long Term Evolution (LTE) networks. 105 In 3GPP, SMS is identified as the transport protocol for small data 106 transmissions (See [ts23_888] for Key Issue on Machine Type 107 Communication (MTC) Device Trigger and the proposed solutions in 108 Sections 6.2, 6.42, 6.44, 6.48, 6.52, 6.60, and 6.61). In [ts23_682] 109 'Architecture Enhancements to facilitate communications with Packet 110 Data Networks and Applications' SMS is at the moment the only Trigger 111 Delivery (Trigger Delivery using T4). 113 M2M protocols using SMS, e.g. for telematics, are using mostly 114 various diverse proprietary and closed binary protocols with limited 115 publicly available documentation at the moment. 117 In Open Mobile Alliance (OMA) LightweightM2M technical specification 118 [oma_lightweightm2m_ts], SMS is identified as an alternative 119 transport for CoAP messages. 121 2. Terminology 123 This document uses the following terminology: 125 CoAP Server and Client 126 The terms CoAP Server and CoAP Client are used synonymously to 127 Server and Client as specified in the terminology section of 128 [RFC7252]. 130 Mobile Station (MS) 131 A Mobile Station includes all required user equipment and software 132 that is needed for communication with a mobile network. As 133 defined in [etsi_ts101_748]. 135 3. Requirements Language 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in RFC 2119 [RFC2119]. 141 4. Scenarios 143 Several scenarios are presented first for M2M communications with 144 CoAP over SMS. First Mobile-Originating Mobile-Terminating (MO-MT) 145 scenarios are presented, where both CoAP endpoints are in devices in 146 a cellular network. Next, Mobile-Terminating (MT) scenarios are 147 detailed, where only the CoAP server is in a cellular network. 148 Finally, Mobile-Originating (MO) scenarios where the CoAP client is 149 in the cellular network. 151 4.1. MO-MT Scenarios 153 Two mobile cellular terminals communicate by exchanging a CoAP 154 Request and Response embedded into short message protocol data units 155 (PDUs) (depicted in Figure 1). Both terminals are connected via a 156 Short Message Service Centre (SMS-C). 158 CoAP-REQ CoAP-REQ 159 +------+ (SMS) +-------+ (SMS) +------+ 160 | A | --------> | SMS-C | -------> | B | 161 |(cell)| <-------- | | <------- |(cell)| 162 +------+ CoAP-RES +-------+ CoAP-RES +------+ 163 (SMS) (SMS) 165 Figure 1: Cellular and Cellular Communication (only SMS-based) 167 4.2. MT Scenarios 169 An IP host and a mobile cellular terminal communicate by exchanging 170 CoAP Request and Response. The IP host uses protocols offered by the 171 SMS-C (e.g. Short Message Peer-to-Peer (SMPP [smpp]), Computer 172 Interface to Message Distribution (CIMD [cimd]), Universal Computer 173 Protocol/External Machine Interface (UCP/EMI [ucp])) to submit a 174 short message for delivery, which contains the CoAP Request (depicted 175 in Figure 2). 177 CIMD CoAP-REQ 178 +------+ SMPP +-------+ (SMS) +------+ 179 | A | --------> | SMS-C | ---------> | B | 180 | (IP) | <-------- | | <--------- |(cell)| 181 +------+ +-------+ CoAP-RES +------+ 182 (SMS) 184 Figure 2: IP and Cellular Communication 186 There are service providers that offer SMS delivery and notification 187 using an HTTP/REST interface (depicted in Figure 3). 189 HTTP-REQ CIMD CoAP-REQ 190 +------+ (CoAP-DATA) +----------+ SMPP +-----+ (SMS) +------+ 191 | | | SMS | SS7 |SMS-C| | | 192 | A | ----------> | Service | ------> | / | ---------> | B | 193 | (IP) | <---------- | Provider | <------ | HLR | <--------- |(cell)| 194 +------+ HTTP-RES +----------+ +-----+ CoAP-RES +------+ 195 (CoAP-DATA) (SMS) 197 Figure 3: IP and Cellular Communication (using an SMS Service 198 Provider) 200 4.3. MO Scenarios 202 A mobile cellular terminal and an IP host communicate by exchanging 203 CoAP Request and Response. The mobile cellular terminal sends a CoAP 204 Request in a short message, which is in turn forwarded by the SMS-C 205 (e.g. with Short Message Peer-to-Peer (SMPP [smpp]), Computer 206 Interface to Message Distribution (CIMD [cimd]), Universal Computer 207 Protocol/External Machine Interface (UCP/EMI [ucp])) as depicted in 208 Figure 4). This scenario can be a fall-back for mobile-originating 209 communication, when IP connectivity cannot be setup (e.g. due to 210 missing coverage). 212 CoAP-REQ CIMD 213 +------+ (SMS) +-------+ SMPP +------+ 214 | A | --------> | SMS-C | ---------> | B | 215 |(cell)| <-------- | | <--------- | (IP) | 216 +------+ CoAP-RES +-------+ +------+ 217 (SMS) 219 Figure 4: Cellular and IP Communication 221 There are service providers offering SMS delivery and notification 222 using an HTTP/REST interface (depicted in Figure 5). 224 CoAP-REQ CIMD HTTP-REQ 225 +------+ (SMS) +-------+ SMPP +----------+ (CoAP-DATA) +----+ 226 | | | SMS-C | SS7 | SMS | | | 227 | A | ---------> | / | -----> | Service | ----------> | B | 228 |(cell)| <--------- | HLR | <----- | Provider | <---------- |(IP)| 229 +------+ CoAP-RES +-------+ +----------+ HTTP-RES +----+ 230 (SMS) (CoAP-DATA) 232 Figure 5: IP and Cellular Communication (using an SMS Service 233 Provider) 235 5. Message Exchanges 237 5.1. Message Exchange for SMS in a Cellular-To-Cellular Mobile- 238 Originated and Mobile-Terminated Scenario 240 The CoAP Client works as a Mobile Station to send the short message, 241 and the CoAP Server works as another Mobile Station to receive the 242 short message. All short messages are stored and forwarded by the 243 Service Center. The message exchange between the CoAP Client and the 244 CoAP Server is depicted in the figure below: 246 MS/CoAP CLIENT Service Center MS/CoAP SERVER 247 | | | 248 | ---SMS-SUBMIT---> | | 249 | <-SMS-SUBMIT-REPORT-- | | 250 | | | 251 | | --SMS-DELIVER---> | 252 | | <-SMS-DELIVER-REPORT-- | 253 | | | 254 | <-SMS-STATUS-REPORT-- | | 255 | | | 257 Figure 6: CoAP Messages over SMS 259 Note that the message exchange is just for one request message from 260 CoAP Client and CoAP Server. It includes the following steps: 262 Step 1: The CoAP Client sends a CoAP request in a SMS-SUBMIT message 263 to the Service Center. The CoAP Server address is specified as TP- 264 Destination-Address (see [ts23_040]). 266 Step 2: The Service Center returns a SMS-SUBMIT-REPORT message to the 267 CoAP Client. 269 Step 3: The Service Center stores the received SMS message and 270 forwards it to the CoAP Server, using an SMS-DELIVER message. The 271 CoAP Client address is specified as a TP Originating Address (see 272 [ts23_040]). 274 Step 4: The CoAP Server returns an SMS-DELIVER-REPORT message to the 275 Service Center. 277 Step 5: The Service Center returns the SMS-STATUS-REPORT message to 278 the CoAP Client to indicate the SMS delivery status, if required by 279 the CoAP Client. 281 Note that the SMS-STATUS-REPORT message just indicates the transport 282 layer SMS delivery status and has no relationship with the 283 confirmable message or non-confirmable message. If the CoAP Client 284 has sent a confirmable message, the CoAP Server MUST use a separate 285 SMS message to transmit the ACK. 287 6. Encoding Schemes of CoAP for SMS transport 289 Short messages can be encoded by using various alphabets: GSM 7 bit 290 default alphabet ([ts23_038]), 8 bit data alphabet, and 16 bit USC2 291 data alphabet ([iso_ucs2]). These encodings lead to message sizes of 292 160, 140, and 70 characters, respectively. Whereas the support of 7 293 bit encoding is mandatory on a MS, the two other encodings are 294 dependent on the language that needs to be encoded, e.g. USC2 for 295 Arabic, Chinese, Japanese, etc. Furthermore, the supported encoding 296 highly depends on the implementations of the MS itself. 298 According to [ts23_038], GSM 7 bit encoding shall be supported by all 299 MSs offering SMS services. Since not all MSs support 8 bit short 300 message encoding, the prefered encoding scheme for CoAP messages over 301 SMS is therefore 7 bit, e.g. Base64 ([RFC4648]) or SMS encoding in 302 [I-D.bormann-coap-misc]. 304 More considerations about SMS encoding can be found in 305 [I-D.bormann-coap-misc]. 307 7. Message Size Implementation Considerations 309 By using 7 bit encoding, a maximum length of 160 characters is 310 allowed in one short message [ts23_038]. Consequently, the maximum 311 length for a CoAP message results in 140 bytes. 160 characters = (140 312 bytes * 8)/7. 314 Possible options for larger CoAP messages are: 316 Concatenated short messages 317 Most MSs are able to send concatenation short messages in order to 318 tranmsit longer messages. The total length of a concatenated 319 short message can consist of up to 255 single messages and result 320 in total length of 39015 7 bit characters or 34170 bytes. 321 Resulting from this, the maximum length of each individual message 322 reduces to 153 (160 - 7) characters (133 bytes). 324 CoAP blockwise transfer 325 According to [I-D.ietf-core-block], the Block Size (SZX) of 326 blockwise transfer in CoAP is represented as a three-bit unsigned 327 integer. Thus, the possible block sizes are to the power of two. 328 (Block size = 2**(SZX + 4)). Due to the limitations of 160 329 characters (140 bytes) for one short message, the maximum value of 330 SZX is 3 (Block size = 128 byte). 332 However, it is RECOMMENDED that SMS is not used to transfer very 333 large resource data using blockwise transfer. 335 8. Addressing 337 For SMS in cellular networks, the CoAP endpoints have to work with a 338 SIM (Subscriber Identity Module) card and have to be addressed by the 339 MSISDN (Mobile Station ISDN (MSISDN) number). 341 To allow the CoAP client to detect that the short message contains a 342 CoAP message, the TP-DATA-Coding-Scheme SHOULD be included. 344 9. Options 346 9.1. New Options for mixed IP operation. 348 In case a CoAP Server has more than one network interface, e.g. SMS 349 and IP, the CoAP Client might want the server to send the response 350 via an alternative transport, i.e. to it's alternative address. 351 However, that implies that the initiating CoAP Client is aware of the 352 presence of the alternative interface. For this reason the new 353 options Response-To-Uri-Host and Response-To-Uri-Port are proposed. 355 +----+---+---+---+---+-------------------+-------+--------+---------+ 356 | No | C | U | N | R | Name | Forma | Length | Default | 357 | . | | | | | | t | | | 358 +----+---+---+---+---+-------------------+-------+--------+---------+ 359 | TB | | | | | Response-To-Uri- | strin | 1-270 | (none) | 360 | D | | | | | Host | g | B | | 361 | TB | | | | | Response-To-Uri- | uint | 0-2 B | 5683 | 362 | D | | | | | Port | | | | 363 +----+---+---+---+---+-------------------+-------+--------+---------+ 365 Table 1: New CoAP Option Numbers 367 If the Response-To-Uri-Host is present in the request, server MUST 368 send the response to the indicated URI address, instead of the 369 client's original request URI. 371 The options SHOULD NOT be used in the response. 373 The options MUST NOT occur more than once. 375 10. URI Scheme 377 The coap:// scheme defines that a CoAP server is reachable over UDP/ 378 IP. Hence, a new URI scheme is needed for CoAP servers which are 379 reachable over SMS. 381 As specified in [I-D.silverajan-core-coap-alternative-transports], 382 the transport information is expressed as part of the URI scheme 383 component. This is performed by minting new schemes for SMS 384 transport using the form "coap+sms", where the name of the transport 385 is clearly and unambiguously described. The endpoint identifier, 386 path and query components together with each scheme name would be 387 used to uniquely identify each resource. 389 Example of such URI : 391 o coap+sms://0015105550101/sensors/temperature 393 In the URI, 0015105550101 is a telephone subscriber number. 395 11. Transmission Parameters 397 It is RECOMMENDED to configure the RESPONSE_TIMEOUT variable for a 398 higher duration than specified in [RFC7252] for the applications 399 described here. The actual value SHOULD be chosen based on 400 experience with SMS . 402 12. Multicast 404 Multicast is not possible with SMS transports. 406 13. Security Considerations 408 It is possible that a malicious CoAP Client sends repeated requests, 409 and it may cost money for the CoAP Server to use SMS to send back 410 associated responses. To avoid this situation, the CoAP Server 411 implementation can authenticate the CoAP Client before responding to 412 the requests. For example, the CoAP Server can maintain an MSISDN 413 white list. Only the MSISDN specified in the white list will be 414 allowed to send requests. The requests from others will be ignored 415 or rejected. 417 14. IANA Considerations 418 14.1. CoAP Option Number 420 The IANA is requested to add the following option number entries to 421 the CoAP Option Number Registry: 423 +--------+----------------------+----------------------------+ 424 | Number | Name | Reference | 425 +--------+----------------------+----------------------------+ 426 | TBD | Response-To-Uri-Host | Section 2 of this document | 427 +--------+----------------------+----------------------------+ 428 | TBD | Response-To-Uri-Port | Section 2 of this document | 429 +--------+----------------------+----------------------------+ 431 14.2. URI Scheme Registration 433 According to [I-D.silverajan-core-coap-alternative-transports] this 434 document requests the registration of the Uniform Resource Identifier 435 (URI) scheme "coap+alt". The registration request complies with 436 [RFC4395]. 438 15. Acknowledgements 440 This document is partly based on research for the research project 441 'The Intelligent Container' which is supported by the Federal 442 Ministry of Education and Research, Germany, under reference number 443 01IA10001. 445 The authors of this draft would like to thank Bert Greevenbosch, 446 Marcus Goetting, Nils Schulte and Klaus Hartke for the discussions on 447 the topic and the reviews of this document. 449 16. References 451 16.1. Normative References 453 [I-D.bormann-coap-misc] 454 Bormann, C. and K. Hartke, "Miscellaneous additions to 455 CoAP", draft-bormann-coap-misc-26 (work in progress), 456 December 2013. 458 [I-D.ietf-core-block] 459 Bormann, C. and Z. Shelby, "Blockwise transfers in CoAP", 460 draft-ietf-core-block-15 (work in progress), July 2014. 462 [I-D.silverajan-core-coap-alternative-transports] 463 Silverajan, B. and T. Savolainen, "CoAP Communication with 464 Alternative Transports", draft-silverajan-core-coap- 465 alternative-transports-06 (work in progress), July 2014. 467 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 468 Requirement Levels", BCP 14, RFC 2119, March 1997. 470 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 471 3966, December 2004. 473 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 474 Resource Identifier (URI): Generic Syntax", STD 66, RFC 475 3986, January 2005. 477 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 478 Encodings", RFC 4648, October 2006. 480 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 481 Specifications: ABNF", STD 68, RFC 5234, January 2008. 483 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 484 Application Protocol (CoAP)", RFC 7252, June 2014. 486 [etsi_ts101_748] 487 ETSI, "Technical Report: Digital cellular 488 telecommunications system; Abbreviations and acronyms (GSM 489 01.04 version 8.0.0 release 1999)", 2000. 491 [iso_ucs2] 492 ISO, "ISO/IEC10646: "Universal Multiple-Octet Coded 493 Character Set (UCS)"; UCS2, 16 bit coding.", 2000. 495 [ts23_038] 496 ETSI 3GPP, "Technical Specification: Alphabets and 497 language-specific information (3GPP TS 23.038 version 498 11.0.0 Release 11)", 2012. 500 16.2. Informative References 502 [cimd] Nokia, "CIMD Interface Specification (SMSCDOC8000.00, 503 Nokia SMS Center 8.0)", 2005. 505 [oma_lightweightm2m_ts] 506 OMA, "Lightweight Machine to Machine Technical 507 Specification", 2013. 509 [smpp] SMPP Developers Forum, "Short Message Peer to Peer 510 Protocol Specification v3.4 Issue 1.2", 1999. 512 [ts23_040] 513 3GPP, "Technical realization of the Short Message Service 514 (SMS)", 3GPP-23.040 a00, Mar 2011. 516 [ts23_682] 517 ETSI 3GPP, "Technical Specification Group Services and 518 System Aspects; Architecture Enhancements to facilitate 519 communications with Packet Data Networks and Applications; 520 (Release 11)", 2012. 522 [ts23_888] 523 ETSI 3GPP, "Technical Specification Group Services and 524 System Aspects; System Improvements for Machine-Type 525 Communications; (3GPP TR 23.888 version 1.6.0, Release 526 11)", 2011. 528 [ucp] Vodafone, "Short Message Service Centre (SMSC) External 529 Machine Interface (EMI) Description Version 4.3d", 2011. 531 Appendix A. Changelog 533 Changed from draft-04 to draft-05: 535 o Removed reference to USSD. 537 o Updated reference to RFC7252 and 3GPP specs. 539 o Updated Options. 541 o Adapted URI scheme. 543 Changed from draft-03 to draft-04: 545 o Removed USSD and GPRS related parts. 547 o Removed section 5: Examples 549 o Removed section 14: Proxying Considerations 551 o Added more block size considerations. 553 o Added more concatenated SMS considerations. 555 o Rewrote encoding scheme section; 7 bit encoding only. 557 Changed from draft-02 to draft-03: 559 o Added reference to OMA LightweightM2M Technical Specification in 560 "Motivation" section. 562 o Chose CoAP option numbers and updated the option number table to 563 meet draft-ietf-core-coap-13. 565 Changed from draft-01 to draft-02: 567 o Added security considerations: Transport and Object Security. 568 Section 13 570 o Reply-To-* changed to Response-To-*. Section 14 572 o Added URI scheme. 574 o Added possible CON/NON/ACK interactions. 576 o Added possible M2M proxy scenarios. 578 o Added reference to bormann-coap-misc for other SMS encoding. 579 Section 6 581 o Updated requirements on Uri-Host and Uri-Port for coap+tel://. 583 o Chose CoAP option numbers and updated the option number table to 584 meet draft-ietf-core-coap-10. /> 586 o Added an IANA registration for the URI scheme. Section 14.2 588 Authors' Addresses 590 Markus Becker (editor) 591 ComNets, TZI, University Bremen 592 Bibliothekstrasse 1 593 Bremen 28359 594 Germany 596 Phone: +49 421 218 62379 597 Email: mab@comnets.uni-bremen.de 599 Kepeng Li 600 Huawei Technologies 601 Huawei Base, Bantian, Longgang District 602 Shenzhen, Guangdong 518129 603 P. R. China 605 Phone: +86-755-28974289 606 Email: likepeng@huawei.com 607 Koojana Kuladinithi 608 ComNets, TZI, University Bremen 609 Bibliothekstrasse 1 610 Bremen 28359 611 Germany 613 Phone: +49 421 218 62382 614 Email: koo@comnets.uni-bremen.de 616 Thomas Poetsch 617 ComNets, TZI, University Bremen 618 Bibliothekstrasse 1 619 Bremen 28359 620 Germany 622 Phone: +49 421 218 62379 623 Email: thp@comnets.uni-bremen.de