idnits 2.17.1 draft-ietf-core-links-json-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 : ---------------------------------------------------------------------------- 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 (April 27, 2016) is 2920 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: 'RFCthis' is mentioned on line 265, but not defined ** Obsolete normative reference: RFC 5988 (Obsoleted by RFC 8288) ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) == Outdated reference: A later version (-11) exists of draft-greevenbosch-appsawg-cbor-cddl-08 == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-07 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group K. Li 3 Internet-Draft Alibaba Group 4 Intended status: Standards Track A. Rahman 5 Expires: October 29, 2016 InterDigital 6 C. Bormann, Ed. 7 Universitaet Bremen TZI 8 April 27, 2016 10 Representing CoRE Formats in JSON and CBOR 11 draft-ietf-core-links-json-05 13 Abstract 15 JavaScript Object Notation, JSON (RFC7159) is a text-based data 16 format which is popular for Web based data exchange. Concise Binary 17 Object Representation, CBOR (RFC7049) is a binary data format which 18 has been optimized for data exchange for the Internet of Things 19 (IoT). For many IoT scenarios, CBOR formats will be preferred since 20 it can help decrease transmission payload sizes as well as 21 implementation code sizes compared to other data formats. 23 Web Linking (RFC5988) provides a way to represent links between Web 24 resources as well as the relations expressed by them and attributes 25 of such a link. In constrained networks, a collection of Web links 26 can be exchanged in the CoRE link format (RFC6690). Outside of 27 constrained environments, it may be useful to represent these 28 collections of Web links in JSON, and similarly, inside constrained 29 environments, in CBOR. This specification defines a common format 30 for this. 32 Group Communication for the Constrained Application Protocol 33 (RFC7390) defines a number of JSON formats for controlling 34 communication between groups of nodes employing the Constrained 35 Application Protocol (CoAP). In a similar vein, this specification 36 defines CBOR variants of these formats. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at http://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on October 29, 2016. 55 Copyright Notice 57 Copyright (c) 2016 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 1.1. Objectives . . . . . . . . . . . . . . . . . . . . . . . 3 74 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 75 2. Web Links in JSON and CBOR . . . . . . . . . . . . . . . . . 4 76 2.1. Background . . . . . . . . . . . . . . . . . . . . . . . 4 77 2.2. Information Model . . . . . . . . . . . . . . . . . . . . 5 78 2.3. Additional Encoding Step for CBOR . . . . . . . . . . . . 6 79 2.4. Examples . . . . . . . . . . . . . . . . . . . . . . . . 7 80 2.4.1. Link Format to JSON Example . . . . . . . . . . . . . 7 81 2.4.2. Link Format to CBOR Example . . . . . . . . . . . . . 8 82 3. Group Communication Management Objects in CBOR . . . . . . . 10 83 3.1. Background . . . . . . . . . . . . . . . . . . . . . . . 10 84 3.2. Information Model . . . . . . . . . . . . . . . . . . . . 10 85 3.3. Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 11 86 3.4. Group Communication Example . . . . . . . . . . . . . . . 11 87 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 88 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 89 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 90 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 91 7.1. Normative References . . . . . . . . . . . . . . . . . . 15 92 7.2. Informative References . . . . . . . . . . . . . . . . . 15 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 95 1. Introduction 97 Web Linking [RFC5988] provides a way to represent links between Web 98 resources as well as the relations expressed by them and attributes 99 of such a link. In constrained networks, a collection of Web links 100 can be exchanged in the CoRE link format [RFC6690] to enable resource 101 discovery, for instance by using the CoAP protocol [RFC7252]. 103 The JavaScript Object Notation (JSON) [RFC7159] is a lightweight, 104 text-based, language-independent data interchange format. JSON is 105 popular in the Web development environment as it is easy for humans 106 to read and write. 108 The Concise Binary Object Representation (CBOR) [RFC7049] is a binary 109 data format which requires extremely small code size, allows very 110 compact message representation, and provides extensibility without 111 the need for version negotiation. CBOR is especially well suited for 112 IoT environments because of these efficiencies. 114 When converting between a bespoke syntax such as that defined by 115 [RFC6690] and JSON or CBOR, many small decisions have to be made. If 116 left without guidance, it is likely that a number of slightly 117 incompatible dialects will emerge. This specification defines a 118 common approach for translating between the CoRE-specific bespoke 119 formats, JSON and CBOR formats. Where applicable, mapping from other 120 formats (e.g. CoRE Link Format) into JSON or CBOR is also described. 122 This specification defines a common format for representing CoRE Web 123 Linking in JSON and CBOR, as well as the various JSON formats for 124 controlling CoRE group communication [RFC7390], in CBOR. 126 Note that there is a separate question on how to represent Web links 127 pointing out of JSON documents, as discussed e.g. in [MNOT11]. While 128 there are good reasons to stay as compatible as possible to 129 developments in this area, the present specification is solving a 130 different problem. 132 1.1. Objectives 134 This specification has been designed based on the following 135 objectives: 137 o Canonical mapping 139 * lossless round-tripping with [RFC6690] and between JSON and 140 CBOR 142 * but not trying for bit-preserving (DER-style) round-tripping 144 o The simplest thing that could possibly work 146 * Do not cater for RFC 5988 complications caused by HTTP header 147 character set issues [RFC2047] 149 o Consider other work that has links in JSON, e.g.: JSON-LD, JSON- 150 Reference [I-D.pbryan-zyp-json-ref] 152 * Do not introduce unmotivated differences 154 1.2. Terminology 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 158 "OPTIONAL" in this document are to be interpreted as described in 159 [RFC2119] when they appear in ALL CAPS. These words may also appear 160 in this document in lower case as plain English words, absent their 161 normative meanings. 163 The term "byte" is used in its now customary sense as a synonym for 164 "octet". 166 CoAP: Constrained Application Protocol [RFC7252] 168 CBOR: Concise Binary Object Representation [RFC7049] 170 CoRE: Constrained RESTful Environments, the field of work underlying 171 [RFC6690], [RFC7049], [RFC7252], and [RFC7390] 173 IoT: Internet of Things 175 JSON: JavaScript Object Notation [RFC7159] 177 The objective of the JSON and CBOR mappings defined in this document 178 is to contain information of the formats specified in [RFC5988] and 179 [RFC6690]. This specification therefore uses the names of the ABNF 180 productions used in those documents. 182 2. Web Links in JSON and CBOR 184 2.1. Background 186 Web Linking [RFC5988] provides a way to represent links between Web 187 resources as well as the relations expressed by them and attributes 188 of such a link. In constrained networks, a collection of Web links 189 can be exchanged in the CoRE link format [RFC6690] to enable resource 190 discovery, for instance by using the CoAP protocol [RFC7252] and in 191 conjunction with the CoRE resource directory 192 [I-D.ietf-core-resource-directory]. 194 2.2. Information Model 196 This section discusses the information model underlying the CORE Link 197 Format payload. 199 An application/link-format document is a collection of web links 200 ("link-value"), each of which is a collection of attributes ("link- 201 param") applied to a "URI-Reference". 203 We straightforwardly map: 205 o the outer collection to an array of links; 207 o each link to a JSON object or CBOR map, mapping attribute names to 208 attribute values. 210 In the object representing a "link-value", each target attribute or 211 other parameter ("link-param") is represented by a JSON name/value 212 pair (member). The name is a string representation of the parameter 213 or attribute name (as in "parmname"), the value is a string 214 representation of the parameter or attribute value ("ptoken" or 215 "quoted-string"). "quoted-string" productions are parsed (i.e, the 216 outer quotes removed and the backslash constructions evaluated) as 217 defined in [RFC6690] and its referenced documents, before placing 218 them in JSON strings (in the representation of which they may gain 219 back additional decorations such as backslashes as defined in 220 [RFC7159]). 222 If no attribute value ("ptoken" or "quoted-string") is present, the 223 presence of the attribute name is indicated by using the Boolean 224 value "true" as the value. 226 If a Link attribute ("parmname") is present more than once in a 227 "link-value", its values are then represented as a JSON array of JSON 228 string values; this array becomes the value of the JSON name/value 229 pair where the attribute name is the JSON name. Attributes occurring 230 just once MUST NOT be represented as JSON arrays but MUST be directly 231 represented as JSON strings. (Note that [RFC6690] has cut down on 232 the use of repeated parameter names; they are still allowed by 233 [RFC5988] though. No attempt has been made to decode the possibly 234 space-separated values for rt=, if=, and rel= into JSON arrays.) 236 The URI-Reference is represented as a name/value pair with the name 237 "href" and the URI-Reference as the value. (Rationale: This usage is 238 consistent with the use of "href" as a query parameter for link- 239 format query filtering and with link-format reserving the link 240 parameter "href" specifically for this use [RFC6690]). 242 The resulting structure can be represented in CDDL 243 [I-D.greevenbosch-appsawg-cbor-cddl] as: 245 links = [* link] 246 link = { 247 href: tstr ; resource URI 248 * tstr => tstr / true 249 } 251 Figure 1: CoRE Link Format Data Model 253 2.3. Additional Encoding Step for CBOR 255 The above specification for JSON could be used as is for the CBOR 256 encoding as well. However, to further reduce message sizes, an extra 257 encoding step is performed: "href" and some commonly occurring 258 attribute names are encoded as small integers. 260 The substitution is summarized below: 262 +----------+---------------+------------------------------------+ 263 | name | encoded value | reference | 264 +----------+---------------+------------------------------------+ 265 | href | 1 | [RFC6690], [RFCthis] | 266 | rel | 2 | [RFC5988] Section 5.3 | 267 | anchor | 3 | [RFC5988] Section 5.2 | 268 | rev | 4 | [RFC5988] Section 5.3 | 269 | hreflang | 5 | [RFC5988] Section 5.4 | 270 | media | 6 | [RFC5988] Section 5.4 | 271 | title | 7 | [RFC5988] Section 5.4 | 272 | type | 8 | [RFC5988] Section 5.4 | 273 | rt | 9 | [RFC6690] Section 3.1 | 274 | if | 10 | [RFC6690] Section 3.2 | 275 | sz | 11 | [RFC6690] Section 3.3 | 276 | ct | 12 | [RFC7252] Section 7.2.1 | 277 | obs | 13 | [RFC7641] Section 6 | 278 | ins | 14 | [I-D.ietf-core-resource-directory] | 279 | exp | 15 | [I-D.ietf-core-resource-directory] | 280 +----------+---------------+------------------------------------+ 282 Table 1: Integer Encoding of common attribute names 284 (Comment to be deleted before submitting this document to the IESG: 285 This list should, again, be checked against relevant references at 286 WGLC time.) 287 This list of substitutions is fixed by the present specification; no 288 future expansion of the list is foreseen. "href" as well as all 289 attribute names in this list MUST be represented by their integer 290 substitutions and MUST NOT use the attribute name in text form. 292 This leads to the following CDDL representation for the CBOR 293 encoding: 295 links = [* link] 296 link = { 297 href: tstr ; resource URI 298 * label => tstr / true 299 } 300 label = tstr / &( 301 href: 1, rel: 2, anchor: 3, 302 rev: 4, hreflang: 5, media: 6, 303 title: 7, type: 8, rt: 9, 304 if: 10, sz: 11, ct: 12, 305 obs: 13, 306 ) 308 Figure 2: CoRE Link Format Data Model (CBOR) 310 2.4. Examples 312 The examples in this section are based on an example on page 15 of 313 [RFC6690] (Figure 3). 315 ;ct=40;title="Sensor Index", 316 ;rt="temperature-c";if="sensor", 317 ;rt="light-lux";if="sensor", 318 ;anchor="/sensors/temp" 319 ;rel="describedby", 320 ;anchor="/sensors/temp";rel="alternate" 322 Figure 3: Example from page 15 of [RFC6690] 324 2.4.1. Link Format to JSON Example 326 The link-format document in Figure 3 becomes (321 bytes, line breaks 327 shown are not part of the minimally-sized JSON document): 329 "[{"href":"/sensors","ct":"40","title":"Sensor 330 Index"},{"href":"/sensors/temp","rt":"temperature- 331 c","if":"sensor"},{"href":"/sensors/light","rt":"light- 332 lux","if":"sensor"},{"href":"http://www.example.com/sensors/ 333 t123","anchor":"/sensors/ 334 temp","rel":"describedby"},{"href":"/t","anchor":"/sensors/ 335 temp","rel":"alternate"}] " 337 To demonstrate the handling of value-less and array-valued 338 attributes, we extend the link-format example by examples of these 339 (Figure 4; the "obs" attribute is defined in Section 6 of [RFC7641], 340 while the "foo" attribute is for exposition only): 342 ;ct=40;title="Sensor Index", 343 ;rt="temperature-c";if="sensor";obs, 344 ;rt="light-lux";if="sensor", 345 ;anchor="/sensors/temp" 346 ;rel="describedby";foo="bar";foo=3;ct=4711, 347 ;anchor="/sensors/temp";rel="alternate" 349 Figure 4: Example derived from page 15 of [RFC6690] 351 The link-format document in Figure 4 becomes the JSON document in 352 Figure 5 (some spacing and indentation added): 354 [{"href":"/sensors","ct":"40","title":"Sensor Index"}, 355 {"href":"/sensors/temp","rt":"temperature-c","if":"sensor", 356 "obs":true}, 357 {"href":"/sensors/light","rt":"light-lux","if":"sensor"}, 358 {"href":"http://www.example.com/sensors/t123", 359 "anchor":"/sensors/temp","rel":"describedby", 360 "foo":["bar","3"],"ct":"4711"}, 361 {"href":"/t","anchor":"/sensors/temp","rel":"alternate"}] 363 Figure 5: Example derived from page 15 of [RFC6690] 365 Note that the conversion is unable to convert the string-valued "ct" 366 attribute to a number, which would be the natural type for a Content- 367 Format value; similarly, both "foo" values are treated as strings 368 independently of whether they are quoted or numeric in syntax. 370 2.4.2. Link Format to CBOR Example 372 This examples shows conversion from link format to CBOR format. 374 The link-format document in Figure 3 becomes (in CBOR diagnostic 375 format): 377 [{1: "/sensors", 12: "40", 7: "Sensor Index"}, 378 {1: "/sensors/temp", 9: "temperature-c", 10: "sensor"}, 379 {1: "/sensors/light", 9: "light-lux", 10: "sensor"}, 380 {1: "http://www.example.com/sensors/t123", 3: "/sensors/temp", 381 2: "describedby"}, 382 {1: "/t", 3: "/sensors/temp", 2: "alternate"}] 384 or, in hexadecimal (203 bytes): 386 85 # array(number of data items:5) 387 a3 # map(# data item pairs:3) 388 01 # unsigned integer(value:1,"href") 389 68 # text string(8 bytes) 390 2f73656e736f7273 # "/sensors" 391 0c # unsigned integer(value:12,"ct") 392 62 # text(2) 393 3430 # "40" 394 07 # unsigned integer(value:7,"title") 395 6c # text string(12 bytes) 396 53656e736f7220496e646578 # "Sensor Index" 397 a3 # map(# data item pairs:3) 398 01 # unsigned integer(value:1,"href") 399 6d # text string(13 bytes) 400 2f73656e736f72732f74 401 656d70 # "/sensors/temp" 402 09 # unsigned integer(value:9,"rt") 403 6d # text string(13 bytes) 404 74656d70657261747572 405 652d63 # "temperature-c" 406 0a # unsigned integer(value:10,"if") 407 66 # text string(6 bytes) 408 73656e736f72 # "sensor" 409 a3 # map(# data item pairs:3) 410 01 # unsigned integer(value:1,"href") 411 6e # text string(14 bytes) 412 2f73656e736f72732f6c 413 69676874 # "/sensors/light" 414 09 # unsigned integer(value:9,"rt") 415 69 # text string(9 bytes) 416 6c696768742d6c7578 # "light-lux" 417 0a # unsigned integer(value:10,"if") 418 66 # text string(6 bytes) 419 73656e736f72 # "sensor" 420 a3 # map(# data item pairs:3) 421 01 # unsigned integer(value:1,"href") 422 78 23 # text string(35 bytes) 423 687474703a2f2f777777 424 2e6578616d706c652e63 425 6f6d2f73656e736f7273 426 2f74313233 # "http://www.example.com/sensors/t123" 427 03 # unsigned integer(value:3,"anchor") 428 6d # text string(13 bytes) 429 2f73656e736f72732f74 430 656d70 # "/sensors/temp" 431 02 # unsigned integer(value:2,"rel") 432 6b # text string(11 bytes) 433 6465736372696265646279 # "describedby" 434 a3 # map(# data item pairs:3) 435 01 # unsigned integer(value:1,"href") 436 62 # text string(12 bytes) 437 2f74 # "/t" 438 03 # unsigned integer(value:3,"anchor") 439 6d # text string(13 bytes) 440 2f73656e736f72732f74 441 656d70 # "/sensors/temp" 442 02 # unsigned integer(value:2,"rel") 443 69 # text string(9 bytes) 444 616c7465726e617465 # "alternate" 446 Figure 6: Web Links Encoded in CBOR 448 3. Group Communication Management Objects in CBOR 450 3.1. Background 452 The CoAP Group Communications specification [RFC7390] defines group 453 management objects in JSON format. These objects are used to 454 represent IP multicast group information for CoAP endpoints. See 455 [I-D.ietf-core-resource-directory] for more examples of using these 456 objects. 458 3.2. Information Model 460 This section discusses the information model underlying the CoAP 461 Group Communication management object payload. 463 A group membership JSON object contains one or more key/value pairs, 464 and represents a single IP multicast group membership for the CoAP 465 endpoint. Each key/value pair is encoded as a member of the JSON 466 object, where the key is the member name and the value is the 467 member's value. 469 The information model of the CoAP Group Communication management 470 object can be summarized below: 472 collection = { * index => membership } 473 index = tstr .regexp "[A-Za-z0-9]{1,2}" 474 membership = { 475 ? n: groupname, 476 ? a: groupaddress, 477 } 478 groupname = tstr ; host [":" port] 479 groupaddress = tstr ; IPv4address [ ":" port ] 480 ; / "[" IPv6address "]" [":" port ] 482 Figure 7: CoAP Group Communication Data Model 484 3.3. Mapping 486 The objective of the mapping defined in this section is to map 487 information from the JSON formats specified in [RFC7390] into CBOR 488 format, using the rules of Section 4.2 of [RFC7049]. 490 3.4. Group Communication Example 492 { "8" :{ "a": "[ff15::4200:f7fe:ed37:14ca]" }, 493 "11":{ "n": "sensors.floor1.west.bldg6.example.com", 494 "a": "[ff15::4200:f7fe:ed37:25cb]" }, 495 "12":{ "n": "All-Devices.floor1.west.bldg6.example.com", 496 "a": "[ff15::4200:f7fe:ed37:abcd]:4567" } 497 } 499 Figure 8: Example from section 2.6.2.4 of [RFC7390] 501 becomes: 503 a3 # map(3) 504 61 # text(1) 505 38 # "8" 506 a1 # map(1) 507 61 # text(1) 508 61 # "a" 509 78 1b # text(27) 510 5b666631353a3a343230 511 303a663766653a656433 512 373a313463615d # "[ff15::4200:f7fe:ed37:14ca]" 513 62 # text(2) 514 3131 # "11" 515 a2 # map(2) 516 61 # text(1) 517 6e # "n" 518 78 25 # text(37) 519 73656e736f72732e666c 520 6f6f72312e776573742e 521 626c6467362e6578616d 522 706c652e636f6d # "sensors.floor1.west.bldg6.example.com" 523 61 # text(1) 524 61 # "a" 525 78 1b # text(27) 526 5b666631353a3a343230 527 303a663766653a656433 528 373a323563625d # "[ff15::4200:f7fe:ed37:25cb]" 529 62 # text(2) 530 3132 # "12" 531 a2 # map(2) 532 61 # text(1) 533 6e # "n" 534 78 29 # text(41) 535 416c6c2d446576696365 536 732e666c6f6f72312e77 537 6573742e626c6467362e 538 6578616d706c652e636f 539 6d # "All-Devices.floor1.west.bldg6.example.com" 540 61 # text(1) 541 61 # "a" 542 78 20 # text(32) 543 5b666631353a3a343230 544 303a663766653a656433 545 373a616263645d3a34353637 # "[ff15::4200:f7fe:ed37:abcd]:4567" 547 Figure 9: Group Communication Management Object Encoded in CBOR 549 4. IANA Considerations 551 This specification registers the following additional Internet Media 552 Types: 554 Type name: application 556 Subtype name: link-format+json 558 Required parameters: None 560 Optional parameters: None 562 Encoding considerations: Resources that use the "application/ 563 link-format+json" media type are required to conform to the 564 "application/json" Media Type and are therefore subject to the 565 same encoding considerations specified in [RFC7159], Section 11. 567 Security considerations: As defined in this specification 569 Published specification: This specification. 571 Applications that use this media type: None currently known. 573 Additional information: 575 Magic number(s): N/A 577 File extension(s): N/A 579 Macintosh file type code(s): TEXT 581 Person & email address to contact for further information: 582 Carsten Bormann 584 Intended usage: COMMON 586 Change controller: IESG 588 and 589 Type name: application 591 Subtype name: link-format+cbor 593 Required parameters: None 595 Optional parameters: None 597 Encoding considerations: Resources that use the "application/ 598 link-format+cbor" media type are required to conform to the 599 "application/cbor" Media Type and are therefore subject to the 600 same encoding considerations specified in [RFC7049], Section 7. 602 Security considerations: As defined in this specification 604 Published specification: This specification. 606 Applications that use this media type: None currently known. 608 Additional information: 610 Magic number(s): N/A 612 File extension(s): N/A 614 Macintosh file type code(s): CBOR 616 Person & email address to contact for further information: 617 Kepeng Li <kepeng.lkp@alibaba-inc.com> 619 Intended usage: COMMON 621 Change controller: IESG 623 5. Security Considerations 625 The security considerations relevant to the data models of [RFC6690] 626 and [RFC7390], as well as those of [RFC7049] and [RFC7159] apply. 628 6. Acknowledgements 630 Special thanks to Bert Greevenbosch who was an author on the initial 631 version of a contributing document as well as the original author on 632 the CDDL notation. 634 Hannes Tschofenig made many helpful suggestions for improving this 635 document. 637 7. References 639 7.1. Normative References 641 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 642 Requirement Levels", BCP 14, RFC 2119, 643 DOI 10.17487/RFC2119, March 1997, 644 . 646 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, 647 DOI 10.17487/RFC5988, October 2010, 648 . 650 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 651 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 652 . 654 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 655 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 656 October 2013, . 658 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 659 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 660 2014, . 662 7.2. Informative References 664 [I-D.greevenbosch-appsawg-cbor-cddl] 665 Vigano, C. and H. Birkholz, "CBOR data definition language 666 (CDDL): a notational convention to express CBOR data 667 structures", draft-greevenbosch-appsawg-cbor-cddl-08 (work 668 in progress), March 2016. 670 [I-D.ietf-core-resource-directory] 671 Shelby, Z., Koster, M., Bormann, C., and P. Stok, "CoRE 672 Resource Directory", draft-ietf-core-resource-directory-07 673 (work in progress), March 2016. 675 [I-D.pbryan-zyp-json-ref] 676 Bryan, P. and K. Zyp, "JSON Reference", draft-pbryan-zyp- 677 json-ref-03 (work in progress), September 2012. 679 [MNOT11] Nottingham, M., "Linking in JSON", November 2011, 680 . 682 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 683 Part Three: Message Header Extensions for Non-ASCII Text", 684 RFC 2047, DOI 10.17487/RFC2047, November 1996, 685 . 687 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 688 Application Protocol (CoAP)", RFC 7252, 689 DOI 10.17487/RFC7252, June 2014, 690 . 692 [RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for 693 the Constrained Application Protocol (CoAP)", RFC 7390, 694 DOI 10.17487/RFC7390, October 2014, 695 . 697 [RFC7641] Hartke, K., "Observing Resources in the Constrained 698 Application Protocol (CoAP)", RFC 7641, 699 DOI 10.17487/RFC7641, September 2015, 700 . 702 Authors' Addresses 704 Kepeng LI 705 Alibaba Group 706 Wenyixi Road, Yuhang District 707 Hangzhou, Zhejiang 311121 708 China 710 Email: kepeng.lkp@alibaba-inc.com 712 Akbar Rahman 713 InterDigital Communications, LLC 714 1000 Sherbrooke Street West 715 Montreal, Quebec H3A 3G4 716 Canada 718 Phone: +1-514-585-0761 719 Email: akbar.rahman@interdigital.com 720 Carsten Bormann (editor) 721 Universitaet Bremen TZI 722 Postfach 330440 723 Bremen D-28359 724 Germany 726 Phone: +49-421-218-63921 727 Email: cabo@tzi.org