idnits 2.17.1 draft-groves-core-senml-options-00.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 ([I-D.ietf-core-senml]), 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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHALL not' in this paragraph: Note: Some content-formats contain media-type parameters as part of the content-format ID registrations. The AMTP option SHALL not be used with these CoAP content-formats. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHALL not' in this paragraph: Note: Some content-formats contain media-type parameters as part of the content-format ID registrations. The CFMTP option SHALL not be used with these CoAP content-formats. -- The document date (March 10, 2017) is 2597 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) == Unused Reference: 'RFC7252' is defined on line 533, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-core-coap-tcp-tls' is defined on line 544, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-groves-core-senml-bto-00 == Outdated reference: A later version (-16) exists of draft-ietf-core-senml-04 ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) == Outdated reference: A later version (-19) exists of draft-ietf-clue-protocol-13 == Outdated reference: A later version (-11) exists of draft-ietf-core-coap-tcp-tls-07 -- Obsolete informational reference (is this intentional?): RFC 3023 (Obsoleted by RFC 7303) Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group C. Groves 3 Internet-Draft W. Yang 4 Intended status: Standards Track Huawei 5 Expires: September 11, 2017 March 10, 2017 7 SenML Options 8 draft-groves-core-senml-options-00 10 Abstract 12 SenML [I-D.ietf-core-senml] defines an initial set of base and 13 regular attributes which are tied to a particular version of SenML. 14 SenML also allows the definition of additional attributes by 15 extending the syntax with a new label. Allowing the extension of 16 attributes brings the problem of how do endpoints negotiate whether 17 the new attribute can be used or not? This document discusses the 18 issue and proposes some potential solutions to this issue. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 11, 2017. 37 Copyright Notice 39 Copyright (c) 2017 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Solution space analysis . . . . . . . . . . . . . . . . . . . 3 57 3.1. Version Numbering . . . . . . . . . . . . . . . . . . . . 4 58 3.2. Mandatory / Optional Indication . . . . . . . . . . . . . 4 59 3.3. Options Mechanism . . . . . . . . . . . . . . . . . . . . 5 60 3.4. Media Type Definition and Parameters . . . . . . . . . . 6 61 4. Solution Proposal . . . . . . . . . . . . . . . . . . . . . . 7 62 4.1. Accept Media Type Parameter (AMTP) Option . . . . . . . . 9 63 4.2. Content-Format Media-Type Parameter Option . . . . . . . 10 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 66 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 67 8. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 70 9.2. Informative References . . . . . . . . . . . . . . . . . 12 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 73 1. Introduction 75 SenML [I-D.ietf-core-senml] defines an initial set of base and 76 regular attributes which are tied to a particular version of SenML. 77 SenML also allows the definition of additional attributes by 78 extending the defined syntax with a new label. Allowing the 79 extension of attributes brings the problem of how do endpoints 80 negotiate whether the new attribute can be used or not? 82 For example: A CoAP client issues a GET that indicates support of 83 SenML through the use of an CoAP Accept option. A CoAP server 84 supports the SenML attributes defined in [I-D.ietf-core-senml] and in 85 addition supports the Base Time Offset (BTO) 86 [I-D.groves-core-senml-bto] attribute. The server responds using the 87 BTO attribute. 89 [ {"bn": "urn:dev:ow:10e2073a01080063", 90 "bt": 1320067464, 91 "bto": 10, 92 "bu": "%RH", 93 "v": 21.2}, 94 { "v": 21.3}, 95 { "v": 21.4}, 96 { "v": 21.4}, 97 { "v": 21.5}, 98 { "v": 21.5}, 99 { "v": 21.5}, 100 { "v": 21.6}, 101 { "v": 21.7}, 102 { "v": 21.5}, 103 ... 105 Figure 1: Response with SenML using base time offset 107 As the CoAP client does not understand the "bto" attribute it will 108 ignore the attribute. This means that the time information is lost 109 for each of the SenML records. Whereas if the Server had not used 110 "bto" the client would have been able to understand the information. 112 This is mainly a problem when the server provides a response to a 113 message (i.e. GET) rather than when a client uses the SenML media 114 type in a message (i.e. PUT). In this later case the client can 115 modify its behaviour and not use an attribute based on an error 116 response from the server. 118 A solution is needed to prevent incompatible attributes from being 119 used. 121 2. Terminology 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 125 "OPTIONAL" in this document are to be interpreted as described in 126 [RFC2119]. 128 See [I-D.ietf-core-senml] for further definitions. 130 3. Solution space analysis 132 The extension of protocols in a compatible manner is not a new 133 problem. Some approaches to handle the are discussed below. The 134 discussion below is not meant to be treatise on protocol extension 135 but to highlight potential solutions. 137 3.1. Version Numbering 139 A version number is used to indicate when changes have been made to a 140 syntax. In some protocols a major version is used to indicate non- 141 backward compatible changes and a minor version is used to indicate 142 backwards compatible changes. SenML does use a version number 143 however it is an integer (no major and minor). It is used to 144 indicate the version number of the media type format. The version 145 does not appear in the media type format name. However presumably 146 the proposed registrations (e.g. senml+json) imply the use of version 147 number 10 (see sect.4.1/[I-D.ietf-core-senml]). If in the future 148 there is a new version how does the endpoint negotiate which SenML 149 version to use? A simple solution would be to create a new media 150 type name incorporating the new version e.g. "senml_v11+json". A 151 CoAP endpoint could then use an Accept option to indicate support for 152 "senml+json" and/or "senml_v11+json". 154 This method does generally mean that for each new attribute and 155 version the endpoints must at least understand all previously defined 156 attributes. Although major versions in some protocols do not 157 maintain backwards compatibility. 159 SenML does indicate that for certain representations i.e. EXI 160 representation (application/senml+exi) that the schemaID number must 161 be updated when the syntax is updated for a new attribute. This is 162 effectively a version mechanism but the other representation formats 163 do not follow this approach. 165 However the current SenML draft does allow the definition of 166 additional attributes without increasing the SenML version number. 167 Indeed there is a trend at the IETF that protocol versions change 168 very rarely. Instead updates are incorporated via option or 169 extension mechanisms. 171 Therefore it seems that an approach of utilising a version number for 172 each additional new attribute does not seem appropriate for SenML. 174 3.2. Mandatory / Optional Indication 176 Some protocols use a mechanism to indicate whether a parameter is 177 mandatory or optional to understand. This is based on the assumption 178 that a sending endpoint knows the functions that a parameter/s relate 179 to and can indicate whether the receiving endpoint must understand 180 the parameter/s to implement the function. A receiving endpoint will 181 anaylse the received parameters and if it does not understand the 182 parameter it will check the mandatory/option tag to see what it 183 should do. If the parameter is marked as mandatory then the 184 receiving endpoint will generate an error. If the parameter is 185 marked as optional then the receiving endpoint will continue 186 processing in knowledge that it doesn't need the parameter. 188 CoAP uses a mechanism similar to this for Options. By looking at the 189 option number an endpoint can determine whether it is critical or 190 not. 192 SenML does indicate that the version indicates the mandatory to 193 understand attributes (sect. 4.3/[I-D.ietf-core-senml]). SenML also 194 indicates that some attributes (i.e. base attributes) are optional 195 but this is in context of "optional to be used" rather than "optional 196 to be understood". 198 Whilst a method could be defined to indicate in SenML whether an 199 attribute is mandatory or optional, its not clear that it would be 200 useful. Given the number of use cases where CoAP can be used a 201 server may not know which information in a SenML pack is relevant for 202 a client. E.g. Whilst a server may return time information 203 associated with a record it doesn't actually know whether it is 204 useful to the client. The usefulness is application specific to the 205 client. 207 Therefore it seems this approach is also not appropriate for SenML. 209 3.3. Options Mechanism 211 Some protocols allow the optional parts of the protocol to be 212 negotiated during the initial protocol negotiation. For example the 213 SIP protocol has the OPTIONS method [RFC3261]. The CLUE protocol 214 [I-D.ietf-clue-protocol] also defines an extension method where an 215 OPTIONS message is used to negotiate the protocol extensions. The 216 benefits of such an approach is that two endpoints can negotiate 217 which extensions they will use in a session ensuring compatible 218 communications. 220 However these approaches assume an application level session where 221 there are establishment, communication and release phases. SenML is 222 a media type format primarly defined to be used with the HTTP and 223 CoAP protocols. These protocols don't follow a session based 224 approach. 226 HTTP/1.1 does have the OPTIONS method [RFC2616] however the use is 227 largely undocumented. CoAP does not have an equivalent method. 229 CoAP does have a method for negotiating signalling through "Signaling 230 Option Numbers" (sect.4.2/[I-D.ietf-core-coap-tcp-tls]). This 231 however is more used to negotiate the properties of the signalling 232 connection than any elements of the CoAP payload (not withstanding 233 the Blockwise transfer). 235 CoAP does have the OPTIONs mechanism allowing for the definition of 236 optionality functionality associated with a CoAP message. It also 237 defines the concept of critical and elective options. Two options 238 related to Content-type/Content-format are "Content-Format" and 239 "Accept". These options allow endpoints to indicate the media types 240 are using or wish to use. HTTP also uses these options. 242 CoAP also allows a per message exchange of what is supported for a 243 particular resource. This seems more appropriate than a protocol 244 level negotiation of the support of SenML attributes. 246 This functionality is very close to what needs to be acheived for 247 negotiating SenML attributes. 249 3.4. Media Type Definition and Parameters 251 Potentially the media type name could be used to indicate versions or 252 extensions. This may be appropriate where there are seldom changes 253 that affect the whole media type. However it may become unwieldy if 254 the media type name is used to define combinations of SenML 255 attributes, e.g. given 3 extensions a, b and c you could end up with 256 media names / content formats for a, b, c, a+b, a+c, b+c, a+b+c. The 257 problem gets worse each time an extension is added. It is made even 258 worse because Table 7/[I-D.ietf-core-senml] defines 8 different 259 content formats for SenML that would need to be updated. To allow 260 combinations of these parameters on the media types defined in SenML 261 it would need 56 Content-format code points. The content format 262 range 0..255 for IETF specifications isn't particularly large. 264 [RFC6838] allows for the registration of media type parameters. This 265 allows further companion information to be included along with the 266 media type. Charset is a common parameter (See [RFC3023]). This 267 information could be used to provide version or option information 268 associated with a media type. 270 This appears to be a good solution to indicate if additional SenML 271 attributes are supported in a media type. Whilst HTTP supports media 272 type parameters, CoAP does not support media type parameters or 273 extensions (i.e. see sect.10.2.2/[RFC7252]). Meaning that parameters 274 cannot be used as a common approach for HTTP and CoAP. However this 275 solution is used in section 16.9.1/[I-D.ietf-cose-msg] which takes 276 the approach of defining an optional parameter for the "application/ 277 cose". It then assigns multiple CoAP Content-Formats for the values 278 associated with the optional parameter (see 279 sect.16.10/[I-D.ietf-cose-msg]). 281 4. Solution Proposal 283 There doesn't appear to be one outstanding approach for negotiating 284 SenML attributes common to both HTTP and CoAP. The authors believe 285 that a hybrid approach as per [I-D.ietf-cose-msg] is needed in order 286 to be able to negotiate which SenML extension attributes are used. 288 The first part would be the definition of a optional media-type 289 parameter that allows an endpoint utilising HTTP to indicate the 290 SenML extension attributes that it is using or accepts. This could 291 be in the form of a comma separated string list of SenML labels from 292 those registered in the SenML label registry. Only attributes NOT 293 defined in [I-D.ietf-core-senml] would be allowed. 295 e.g. Content-type: application/senml+json; ext=abc,xyz 297 In order to allow this functionality in the base version of SenML an 298 optional parameter would be needed in the media type registrations in 299 sect.11.3/[I-D.ietf-core-senml]. 301 i.e. o Optional parameter: SenML extensions 303 This parameter indicates which SenML extensions are associated with 304 the media type. The parameter is defined by the following ABNF: 306 SenML-ext = "ext" "=" <"> senml-label *("," senml-label) <"> 307 ; Note: this follows the {{RFC2616}} quoted-string form. 308 ; senml-label is the label string from the list of IANA 309 ; registered SenML labels. 310 ; Only non-{{I-D.ietf-core-senml}} labels are allowed. 312 For example: ext="a,b,c"; 314 If the group decides that there will only ever be a small number of 315 SenML extensions then the simplest approach would be to follow 316 [I-D.ietf-cose-msg] and define multiple CoAP content formats 317 associated with potential extensions. This would be done in which 318 ever document defines the SenML extension. For example 319 [I-D.groves-core-senml-bto] would add the following to the IANA 320 considerations section: 322 +------------------------------------+----------+-----+-----------+ 323 | Media Type | Encoding | ID | Reference | 324 +------------------------------------+----------+-----+-----------+ 325 | application/senml+json; ext="bto" | | TBD | TBD | 326 | | | | | 327 | application/sensml+json; ext="bto" | | TBD | TBD | 328 | | | | | 329 | application/senml+cbor; ext="bto" | | TBD | TBD | 330 | | | | | 331 | application/sensml+cbor; ext="bto" | | TBD | TBD | 332 | | | | | 333 | application/senml+xml; ext="bto" | | TBD | TBD | 334 | | | | | 335 | application/sensml+xml; ext="bto" | | TBD | TBD | 336 | | | | | 337 | application/senml+exi; ext="bto" | | TBD | TBD | 338 | | | | | 339 | application/sensml+exi; ext="bto" | | TBD | TBD | 340 +------------------------------------+----------+-----+-----------+ 342 Table 1: New CoAP content formats 344 Text would also need to be added to [I-D.ietf-core-senml] to describe 345 the procedure for support of the media type parameter in CoAP. 347 If issuing potentially a large number of content-format numbers is 348 problematic a separate approach could be taken. A new CoAP option 349 could be defined to allow media-type parameters to be carried in CoAP 350 messages when then Content-Format or Accept options are used. As the 351 Content-Format and Accept options may be used in the same request 352 (with two different media types) two new options would be required, 353 one for the media-type parameters associated with the Content-Format 354 Option and one for the media-type parameters associated with the 355 Accept option. 357 *Editor's note: Alternatives could include defining the option for 358 both CoAP and HTTP. However this would likely mean that the option 359 would become specific to SenML extensions rather than a general 360 mechanism for carrying media type parameters.* 362 As CoAP only allows a single Content-Format to be carried in the 363 Content-Format and Accept options it would be straight forward to 364 define an option that allows media-type parameters to be carried. 365 One complication is that the encoding and syntax of the media-type 366 parameters is up to the media-type definition. It could be a string, 367 integer, binary, etc. Therefore the option value would need to be an 368 opaque sequence of bytes. If the scope was limited to SenML then the 369 option format would be a narrowed to a string of labels. 371 As multiple parameters could be defined for a media-type the 372 mechanism must allow multiple media type parameter to be signalled in 373 a CLUE message. One possible method is to define the option value 374 syntax to allow multiple parameter to be specified as a single 375 parameter value. Alternatively multiple instances of the option 376 could be used in the CoAP message. This method is indicated in the 377 IANA registration by allowing the option multiple times. 379 If a new generic option is defined it's not clear that 380 [I-D.ietf-core-senml] would be the best place to define the option. 381 If the scope is limited then [I-D.ietf-core-senml] would be 382 appropriate. Whichever draft defines the options it would need to 383 define them for registration with IANA along the lines of: 385 +--------+-------+-----------+ 386 | Number | Name | Reference | 387 +--------+-------+-----------+ 388 | TBD | AMTP | TBD | 389 | | | | 390 | TBD | CFMTP | TBD | 391 +--------+-------+-----------+ 393 Table 2: New CoAP Option Numbers 395 4.1. Accept Media Type Parameter (AMTP) Option 397 o The meaning of the option in a request: It indicates the media-type 398 parameters associated with the content-format (media-type) specified 399 in the Accept option. 401 Note: Some content-formats contain media-type parameters as part of 402 the content-format ID registrations. The AMTP option SHALL not be 403 used with these CoAP content-formats. 405 o The meaning of the option in a response: Not used. 407 o Whether the option is critical or elective: Critical as per the 408 Accept option. 410 o Whether the option is Safe-to-Forward: Safe as per the Accept 411 option. 413 Note: Potentially it could be unsafe to forward an opaque byte 414 sequence that the proxy does not understand. However processing this 415 option should only be done within the context of the media-type 416 specified by the Accept option. 418 o The format and length of the option's value: A variable length 419 opaque sequence of bytes. The encoding of the bytes is defined as 420 per the syntax for the parameters in the media-type definition 421 document. 423 o Whether the option must occur at most once or whether it can occur 424 multiple times: Multiple times. Each instance containing a seperate 425 media-type parameter. Whether the option can be included multiple 426 times for the one media type parameter is dependent on whether the 427 media-type definition allows for multiple instances of the one media 428 type parameter. 430 o Default value: None unless the media-type indicated in the accept 431 option defines a default parameter/s value. 433 4.2. Content-Format Media-Type Parameter Option 435 o The meaning of the option in a request: When used together with the 436 Content-Format option it indicates the media-type parameters 437 associated with the content-format (media-type) specified in the 438 content-format option. 440 Note: Some content-formats contain media-type parameters as part of 441 the content-format ID registrations. The CFMTP option SHALL not be 442 used with these CoAP content-formats. 444 o The meaning of the option in a response: When used together with 445 the Content-Format option it indicates the media-type parameters 446 associated with the content-format (media-type) specified in the 447 content-format option. 449 o Whether the option is critical or elective: As per the Content- 450 Format option it is elective. 452 o Whether the option is Safe-to-Forward: Safe as per the Content- 453 format option. 455 Note: Potentially it could be unsafe to forward an opaque byte 456 sequence that the proxy does not understand. However processing this 457 option should only be done within the context of the media-type 458 specified by the Content-Format options. 460 o The format and length of the option's value: A variable length 461 opaque sequence of bytes. The encoding of the bytes is defined as 462 per the syntax for the parameters in the media-type definition 463 document. 465 o Whether the option must occur at most once or whether it can occur 466 multiple times: Multiple times. Each instance containing a seperate 467 media-type parameter. Whether the option can be included multiple 468 times for the one media type parameter is dependent on whether the 469 media-type definition allows for multiple instances of the one media 470 type parameter. 472 o Default value: None unless the media-type indicated in the content- 473 format option defines a default parameter/s value. 475 5. Security Considerations 477 SenML security issues are described in [I-D.ietf-core-senml]. Some 478 extra considerations are indicated above. 480 6. IANA Considerations 482 Section 4 discusses potential IANA registrations. 484 7. Acknowledgements 486 TBD 488 8. Changelog 490 TBD 492 9. References 494 9.1. Normative References 496 [I-D.groves-core-senml-bto] 497 Groves, C. and W. Yang, "SenML Base Time Offset 498 Attribute", draft-groves-core-senml-bto-00 (work in 499 progress), October 2016. 501 [I-D.ietf-core-senml] 502 Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C. 503 Bormann, "Media Types for Sensor Measurement Lists 504 (SenML)", draft-ietf-core-senml-04 (work in progress), 505 October 2016. 507 [I-D.ietf-cose-msg] 508 Schaad, J., "CBOR Object Signing and Encryption (COSE)", 509 draft-ietf-cose-msg-24 (work in progress), November 2016. 511 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 512 Requirement Levels", BCP 14, RFC 2119, 513 DOI 10.17487/RFC2119, March 1997, 514 . 516 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 517 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 518 Transfer Protocol -- HTTP/1.1", RFC 2616, 519 DOI 10.17487/RFC2616, June 1999, 520 . 522 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 523 A., Peterson, J., Sparks, R., Handley, M., and E. 524 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 525 DOI 10.17487/RFC3261, June 2002, 526 . 528 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 529 Specifications and Registration Procedures", BCP 13, 530 RFC 6838, DOI 10.17487/RFC6838, January 2013, 531 . 533 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 534 Application Protocol (CoAP)", RFC 7252, 535 DOI 10.17487/RFC7252, June 2014, 536 . 538 9.2. Informative References 540 [I-D.ietf-clue-protocol] 541 Presta, R. and S. Romano, "CLUE protocol", draft-ietf- 542 clue-protocol-13 (work in progress), February 2017. 544 [I-D.ietf-core-coap-tcp-tls] 545 Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 546 Silverajan, B., and B. Raymor, "CoAP (Constrained 547 Application Protocol) over TCP, TLS, and WebSockets", 548 draft-ietf-core-coap-tcp-tls-07 (work in progress), March 549 2017. 551 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 552 Types", RFC 3023, DOI 10.17487/RFC3023, January 2001, 553 . 555 Authors' Addresses 557 Christian Groves 558 Huawei 559 Australia 561 Email: Christian.Groves@mail01.huawei.com 563 Weiwei Yang 564 Huawei 565 P.R.China 567 Email: tommy@huawei.com