idnits 2.17.1 draft-becker-core-coap-sms-gprs-04.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 8, 2013) is 3913 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 423, but not defined ** Obsolete undefined reference: RFC 4395 (Obsoleted by RFC 7595) == Outdated reference: A later version (-27) exists of draft-bormann-coap-misc-25 ** 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-12 == Outdated reference: A later version (-11) exists of draft-silverajan-core-coap-alternative-transports-02 ** Downref: Normative reference to an Informational draft: draft-silverajan-core-coap-alternative-transports (ref. 'I-D.silverajan-core-coap-alternative-transports') Summary: 3 errors (**), 0 flaws (~~), 5 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, 2014 Huawei Technologies 6 T. Poetsch 7 K. Kuladinithi 8 ComNets, TZI, University Bremen 9 August 8, 2013 11 Transport of CoAP over SMS 12 draft-becker-core-coap-sms-gprs-04 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), that took the limitations of LLNs into account, is thus also 22 applicable to other transports. The adaptation of CoAP to SMS 23 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, 2014. 42 Copyright Notice 44 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 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 for mixed IP operation . . . . . . . . . . . . . . . . 8 74 10. URI Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 11. Transmission Parameters . . . . . . . . . . . . . . . . . . . 9 76 12. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 13. Security Considerations . . . . . . . . . . . . . . . . . . . 9 78 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 79 14.1. CoAP Option Number . . . . . . . . . . . . . . . . . . . . 10 80 14.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 10 81 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 82 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 83 16.1. Normative References . . . . . . . . . . . . . . . . . . . 10 84 16.2. Informative References . . . . . . . . . . . . . . . . . . 11 85 Appendix A. Changelog . . . . . . . . . . . . . . . . . . . . . . 12 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 88 1. Introduction 90 This specification details the usage of the Constrained Application 91 Protocol on the Short Message Service (SMS) of mobile cellular 92 networks. 94 1.1. Motivation 96 In some M2M environments, internet connectivity is not supported by 97 the constrained end-points, but a cellular network connection is 98 supported instead. Internet connectivity might also be switched off 99 for power saving reasons or the cellular coverage does not allow for 100 Internet connectivity. In these situations, SMS will be supported, 101 instead of UDP/IP over General Packet Radio Service (GPRS), High 102 Speed Packet Access (HSPA) or Long Term Evolution (LTE) networks. 104 In 3GPP, SMS is identified as the transport protocol for small data 105 transmissions (See [3gpp_ts23_888] for Key Issue on Machine Type 106 Communication (MTC) Device Trigger and the proposed solutions in 107 Sections 6.2, 6.42, 6.44, 6.48, 6.52, 6.60, and 6.61). In 108 [3gpp_ts23_682] 'Architecture Enhancements to facilitate 109 communications with Packet Data Networks and Applications' SMS is at 110 the moment the only Trigger Delivery (Trigger Delivery using T4). 112 M2M protocols using SMS, e.g. for telematics, are using mostly 113 various diverse proprietary and closed binary protocols with limited 114 publicly available documentation at the moment. 116 In Open Mobile Alliance (OMA) LightweightM2M technical specification 117 [oma_lightweightm2m_ts], SMS is identified as an alternative 118 transport for CoAP messages. 120 2. Terminology 122 This document uses the following terminology: 124 CoAP Server and Client 125 The terms CoAP Server and CoAP Client are used synonymously to 126 Server and Client as specified in the terminology section of 127 [I-D.ietf-core-coap]. 129 Mobile Station (MS) 130 A Mobile Station includes all required user equipment and software 131 that is needed for communication with a mobile network. As 132 defined in [etsi_ts101_748]. 134 3. Requirements Language 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in RFC 2119 [RFC2119]. 140 4. Scenarios 142 Several scenarios are presented first for M2M communications with 143 CoAP over SMS. First Mobile-Originating Mobile-Terminating (MO-MT) 144 scenarios are presented, where both CoAP endpoints are in devices in 145 a cellular network. Next, Mobile-Terminating (MT) scenarios are 146 detailed, where only the CoAP server is in a cellular network. 147 Finally, Mobile-Originating (MO) scenarios where the CoAP client is 148 in the cellular network. 150 4.1. MO-MT Scenarios 152 Two mobile cellular terminals communicate by exchanging a CoAP 153 Request and Response embedded into short message protocol data units 154 (PDUs) (depicted in Figure 1). Both terminals are connected via a 155 Short Message Service Centre (SMS-C). 157 CoAP-REQ CoAP-REQ 158 +------+ (SMS) +-------+ (SMS) +------+ 159 | A | --------> | SMS-C | -------> | B | 160 |(cell)| <-------- | | <------- |(cell)| 161 +------+ CoAP-RES +-------+ CoAP-RES +------+ 162 (SMS) (SMS) 164 Figure 1: Cellular and Cellular Communication (only SMS-based) 166 4.2. MT Scenarios 168 An IP host and a mobile cellular terminal communicate by exchanging 169 CoAP Request and Response. The IP host uses protocols offered by the 170 SMS-C (e.g. Short Message Peer-to-Peer (SMPP [smpp]), Computer 171 Interface to Message Distribution (CIMD [cimd]), Universal Computer 172 Protocol/External Machine Interface (UCP/EMI [ucp])) to submit a 173 short message for delivery, which contains the CoAP Request (depicted 174 in Figure 2). 176 CIMD CoAP-REQ 177 +------+ SMPP +-------+ (SMS) +------+ 178 | A | --------> | SMS-C | ---------> | B | 179 | (IP) | <-------- | | <--------- |(cell)| 180 +------+ +-------+ CoAP-RES +------+ 181 (SMS) 183 Figure 2: IP and Cellular Communication 185 There are service providers that offer SMS delivery and notification 186 using an HTTP/REST interface (depicted in Figure 3). 188 HTTP-REQ CIMD CoAP-REQ 189 +------+ (CoAP-DATA) +----------+ SMPP +-----+ (SMS) +------+ 190 | | | SMS | SS7 |SMS-C| | | 191 | A | ----------> | Service | ------> | / | ---------> | B | 192 | (IP) | <---------- | Provider | <------ | HLR | <--------- |(cell)| 193 +------+ HTTP-RES +----------+ +-----+ CoAP-RES +------+ 194 (CoAP-DATA) (SMS) 196 Figure 3: IP and Cellular Communication (using an SMS Service 197 Provider) 199 4.3. MO Scenarios 201 A mobile cellular terminal and an IP host communicate by exchanging 202 CoAP Request and Response. The mobile cellular terminal sends a CoAP 203 Request in a short message, which is in turn forwarded by the SMS-C 204 (e.g. with Short Message Peer-to-Peer (SMPP [smpp]), Computer 205 Interface to Message Distribution (CIMD [cimd]), Universal Computer 206 Protocol/External Machine Interface (UCP/EMI [ucp])) as depicted in 207 Figure 4). This scenario can be a fall-back for mobile-originating 208 communication, when IP connectivity cannot be setup (e.g. due to 209 missing coverage). 211 CoAP-REQ CIMD 212 +------+ (SMS) +-------+ SMPP +------+ 213 | A | --------> | SMS-C | ---------> | B | 214 |(cell)| <-------- | | <--------- | (IP) | 215 +------+ CoAP-RES +-------+ +------+ 216 (SMS) 218 Figure 4: Cellular and IP Communication 220 There are service providers offering SMS delivery and notification 221 using an HTTP/REST interface (depicted in Figure 5). 223 CoAP-REQ CIMD HTTP-REQ 224 +------+ (SMS) +-------+ SMPP +----------+ (CoAP-DATA) +----+ 225 | | | SMS-C | SS7 | SMS | | | 226 | A | ---------> | / | -----> | Service | ----------> | B | 227 |(cell)| <--------- | HLR | <----- | Provider | <---------- |(IP)| 228 +------+ CoAP-RES +-------+ +----------+ HTTP-RES +----+ 229 (SMS) (CoAP-DATA) 231 Figure 5: IP and Cellular Communication (using an SMS Service 232 Provider) 234 5. Message Exchanges 236 5.1. Message Exchange for SMS in a Cellular-To-Cellular Mobile- 237 Originated and Mobile-Terminated Scenario 239 The CoAP Client works as a Mobile Station to send the short message, 240 and the CoAP Server works as another Mobile Station to receive the 241 short message. All short messages are stored and forwarded by the 242 Service Center. The message exchange between the CoAP Client and the 243 CoAP Server is depicted in the figure below: 245 MS/CoAP CLIENT Service Center MS/CoAP SERVER 246 | | | 247 | ---SMS-SUBMIT---> | | 248 | <-SMS-SUBMIT-REPORT-- | | 249 | | | 250 | | --SMS-DELIVER---> | 251 | | <-SMS-DELIVER-REPORT-- | 252 | | | 253 | <-SMS-STATUS-REPORT-- | | 254 | | | 256 Figure 6: CoAP Messages over SMS 258 Note that the message exchange is just for one request message from 259 CoAP Client and CoAP Server. It includes the following steps: 261 Step 1: The CoAP Client sends a CoAP request in a SMS-SUBMIT message 262 to the Service Center. The CoAP Server address is specified as TP- 263 Destination-Address (see [3gpp_ts_23_040]). 265 Step 2: The Service Center returns a SMS-SUBMIT-REPORT message to the 266 CoAP Client. 268 Step 3: The Service Center stores the received SMS message and 269 forwards it to the CoAP Server, using an SMS-DELIVER message. The 270 CoAP Client address is specified as a TP Originating Address (see 271 [3gpp_ts_23_040]). 273 Step 4: The CoAP Server returns an SMS-DELIVER-REPORT message to the 274 Service Center. 276 Step 5: The Service Center returns the SMS-STATUS-REPORT message to 277 the CoAP Client to indicate the SMS delivery status, if required by 278 the CoAP Client. 280 Note that the SMS-STATUS-REPORT message just indicates the transport 281 layer SMS delivery status and has no relationship with the 282 confirmable message or non-confirmable message. If the CoAP Client 283 has sent a confirmable message, the CoAP Server MUST use a separate 284 SMS message to transmit the ACK. 286 6. Encoding Schemes of CoAP for SMS transport 288 Short messages can be encoded by using various alphabets: GSM 7 bit 289 default alphabet ([3gpp_ts23_038]), 8 bit data alphabet, and 16 bit 290 USC2 data alphabet ([iso_ucs2]). These encodings lead to message 291 sizes of 160, 140, and 70 characters, respectively. The support of 7 292 bit encoding is mandatory on a MS. The 7 bit and 16 bit encodings 293 are dependent on the language that needs to be encoded, e.g. USC2 294 for Arabic, Chinese, Japanese, etc. 8 bit encoding can be used for 295 user specific encoding. Furthermore, the supported encoding scheme 296 highly depends on the implementations of the MS itself. 298 According to [3gpp_ts23_038], GSM 7 bit encoding shall be supported 299 by all MSs offering SMS services. Since not all MSs support 8 bit 300 short message encoding, the prefered encoding scheme for CoAP 301 messages over SMS is therefore 7 bit, e.g. together with Base64 302 ([RFC4648]) or SMS encoding in [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 [3gpp_ts23_038]. Consequently, the 311 maximum length for a CoAP message results in 140 bytes. 160 312 characters = (140 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 for mixed IP operation 346 In case a CoAP Server has more than one network interface, e.g. SMS 347 and IP, the CoAP Client might want the server to send the response 348 via an alternative transport, i.e. to it's alternative address. 349 However, that implies that the initiating CoAP Client is aware of the 350 presence of the alternative interface. For this reason the new 351 options Response-To-Uri-Host and Response-To-Uri-Port are proposed. 353 +----+---+---+---+---+-------------------+-------+--------+---------+ 354 | No | C | U | N | R | Name | Forma | Length | Default | 355 | . | | | | | | t | | | 356 +----+---+---+---+---+-------------------+-------+--------+---------+ 357 | 34 | | | | | Response-To-Uri-H | strin | 1-270 | (none) | 358 | | | | | | ost | g | B | | 359 | 38 | | | | | Response-To-Uri-P | uint | 0-2 B | 5683 | 360 | | | | | | ort | | | | 361 +----+---+---+---+---+-------------------+-------+--------+---------+ 362 Table 1: New CoAP Option Numbers 364 If the Response-To-Uri-Host is present in the request, server MUST 365 send the response to the indicated URI address, instead of the 366 client's original request URI. 368 The options SHOULD NOT be used in the response. 370 The options MUST NOT occur more than once. 372 10. URI Scheme 374 The coap:// scheme defines that a CoAP server is reachable over 375 UDP/IP. Hence, a new URI scheme is needed for CoAP servers which are 376 reachable over SMS. 378 TODO: Update whenever it has been clarified in 379 [I-D.silverajan-core-coap-alternative-transports] 381 11. Transmission Parameters 383 It is RECOMMENDED to configure the RESPONSE_TIMEOUT variable for a 384 higher duration than specified in [I-D.ietf-core-coap] for the 385 applications described here. The actual value SHOULD be chosen based 386 on experience with SMS . 388 12. Multicast 390 Multicast is not possible with SMS transports. 392 13. Security Considerations 394 It is possible that a malicious CoAP Client sends repeated requests, 395 and it may cost money for the CoAP Server to use SMS to send back 396 associated responses. To avoid this situation, the CoAP Server 397 implementation can authenticate the CoAP Client before responding to 398 the requests. For example, the CoAP Server can maintain an MSISDN 399 white list. Only the MSISDN specified in the white list will be 400 allowed to send requests. The requests from others will be ignored 401 or rejected. 403 14. IANA Considerations 405 14.1. CoAP Option Number 407 The IANA is requested to add the following option number entries to 408 the CoAP Option Number Registry: 410 +--------+----------------------+----------------------------+ 411 | Number | Name | Reference | 412 +--------+----------------------+----------------------------+ 413 | 34 | Response-To-Uri-Host | Section 9 of this document | 414 +--------+----------------------+----------------------------+ 415 | 38 | Response-To-Uri-Port | Section 9 of this document | 416 +--------+----------------------+----------------------------+ 418 14.2. URI Scheme Registration 420 According to [I-D.silverajan-core-coap-alternative-transports] this 421 document requests the registration of the Uniform Resource Identifier 422 (URI) scheme "coap+alt". The registration request complies with 423 [RFC4395]. 425 15. Acknowledgements 427 This document is partly based on research for the research project 428 'The Intelligent Container' which is supported by the Federal 429 Ministry of Education and Research, Germany, under reference number 430 01IA10001. 432 The authors of this draft would like to thank Bert Greevenbosch, 433 Marcus Goetting, Nils Schulte and Klaus Hartke for the discussions on 434 the topic and the reviews of this document. 436 16. References 438 16.1. Normative References 440 [3gpp_ts23_038] 441 ETSI 3GPP, "Technical Specification: Alphabets and 442 language-specific information (3GPP TS 23.038 version 443 11.0.0 Release 11)", 2012. 445 [I-D.bormann-coap-misc] 446 Bormann, C. and K. Hartke, "Miscellaneous additions to 447 CoAP", draft-bormann-coap-misc-25 (work in progress), 448 May 2013. 450 [I-D.ietf-core-block] 451 Bormann, C. and Z. Shelby, "Blockwise transfers in CoAP", 452 draft-ietf-core-block-12 (work in progress), June 2013. 454 [I-D.ietf-core-coap] 455 Shelby, Z., Hartke, K., and C. Bormann, "Constrained 456 Application Protocol (CoAP)", draft-ietf-core-coap-18 457 (work in progress), June 2013. 459 [I-D.silverajan-core-coap-alternative-transports] 460 Silverajan, B. and T. Savolainen, "CoAP Communication with 461 Alternative Transports", 462 draft-silverajan-core-coap-alternative-transports-02 (work 463 in progress), July 2013. 465 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 466 Requirement Levels", BCP 14, RFC 2119, March 1997. 468 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 469 Encodings", RFC 4648, October 2006. 471 [etsi_ts101_748] 472 ETSI, "Technical Report: Digital cellular 473 telecommunications system; Abbreviations and acronyms (GSM 474 01.04 version 8.0.0 release 1999)", 2000. 476 [iso_ucs2] 477 ISO, "ISO/IEC10646: "Universal Multiple-Octet Coded 478 Character Set (UCS)"; UCS2, 16 bit coding.", 2000. 480 16.2. Informative References 482 [3gpp_ts23_682] 483 ETSI 3GPP, "Technical Specification Group Services and 484 System Aspects; Architecture Enhancements to facilitate 485 communications with Packet Data Networks and Applications; 486 (Release 11)", 2012. 488 [3gpp_ts23_888] 489 ETSI 3GPP, "Technical Specification Group Services and 490 System Aspects; System Improvements for Machine-Type 491 Communications; (3GPP TR 23.888 version 1.6.0, Release 492 11)", 2011. 494 [3gpp_ts_23_040] 495 3GPP, "Technical realization of the Short Message Service 496 (SMS)", 3GPP-23.040 a00, Mar 2011. 498 [cimd] Nokia, "CIMD Interface Specification (SMSCDOC8000.00, 499 Nokia SMS Center 8.0)", 2005. 501 [oma_lightweightm2m_ts] 502 OMA, "Lightweight Machine to Machine Technical 503 Specification", 2013. 505 [smpp] SMPP Developers Forum, "Short Message Peer to Peer 506 Protocol Specification v3.4 Issue 1.2", 1999. 508 [ucp] Vodafone, "Short Message Service Centre (SMSC) External 509 Machine Interface (EMI) Description Version 4.3d", 2011. 511 Appendix A. Changelog 513 Changed from draft-03 to draft-04: 515 o Various editorial changes. 517 o Removed USSD and GPRS related parts. 519 o Removed section 5: Examples 521 o Removed section 14: Proxying Considerations 523 o Added more block size considerations. 525 o Added more concatenated SMS considerations. 527 o Rewrote encoding scheme section; 7 bit encoding only. 529 Changed from draft-02 to draft-03: 531 o Added reference to OMA LightweightM2M Technical Specification in 532 "Motivation" section. 534 o Chose CoAP option numbers and updated the option number table to 535 meet draft-ietf-core-coap-13. 537 Changed from draft-01 to draft-02: 539 o Added security considerations: Transport and Object Security. 540 Section 13 542 o Reply-To-* changed to Response-To-*. Section 14 543 o Added URI scheme. 545 o Added possible CON/NON/ACK interactions. 547 o Added possible M2M proxy scenarios. 549 o Added reference to bormann-coap-misc for other SMS encoding. 550 Section 6 552 o Updated requirements on Uri-Host and Uri-Port for coap+tel://. 554 o Chose CoAP option numbers and updated the option number table to 555 meet draft-ietf-core-coap-10. /> 557 o Added an IANA registration for the URI scheme. Section 14.2 559 Authors' Addresses 561 Markus Becker (editor) 562 ComNets, TZI, University Bremen 563 Bibliothekstrasse 1 564 Bremen 28359 565 Germany 567 Phone: +49 421 218 62379 568 Email: mab@comnets.uni-bremen.de 570 Kepeng Li 571 Huawei Technologies 572 Huawei Base, Bantian, Longgang District 573 Shenzhen, Guangdong 518129 574 P. R. China 576 Phone: +86-755-28974289 577 Email: likepeng@huawei.com 579 Thomas Poetsch 580 ComNets, TZI, University Bremen 581 Bibliothekstrasse 1 582 Bremen 28359 583 Germany 585 Phone: +49 421 218 62379 586 Email: thp@comnets.uni-bremen.de 587 Koojana Kuladinithi 588 ComNets, TZI, University Bremen 589 Bibliothekstrasse 1 590 Bremen 28359 591 Germany 593 Phone: +49 421 218 62382 594 Email: koo@comnets.uni-bremen.de