idnits 2.17.1 draft-ietf-core-links-json-03.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 (July 06, 2015) is 3217 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) ** 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-06 == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-03 Summary: 3 errors (**), 0 flaws (~~), 3 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: January 7, 2016 InterDigital 6 C. Bormann, Ed. 7 Universitaet Bremen TZI 8 July 06, 2015 10 Representing CoRE Formats in JSON and CBOR 11 draft-ietf-core-links-json-03 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 January 7, 2016. 55 Copyright Notice 57 Copyright (c) 2015 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 CBOR Example . . . . . . . . . . . . . 8 81 2.4.2. Link Format in JSON to CBOR Example . . . . . . . . . 9 82 3. Group Communication Management Objects in CBOR . . . . . . . 11 83 3.1. Background . . . . . . . . . . . . . . . . . . . . . . . 11 84 3.2. Information Model . . . . . . . . . . . . . . . . . . . . 11 85 3.3. Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 11 86 3.4. Group Communication Example . . . . . . . . . . . . . . . 12 87 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 88 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 89 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 90 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 91 7.1. Normative References . . . . . . . . . . . . . . . . . . 16 92 7.2. Informative References . . . . . . . . . . . . . . . . . 16 93 Appendix A. Implementation . . . . . . . . . . . . . . . . . . . 17 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 96 1. Introduction 98 Web Linking [RFC5988] provides a way to represent links between Web 99 resources as well as the relations expressed by them and attributes 100 of such a link. In constrained networks, a collection of Web links 101 can be exchanged in the CoRE link format [RFC6690] to enable resource 102 discovery, for instance by using the CoAP protocol [RFC7252]. 104 The JavaScript Object Notation (JSON) [RFC7159] is a lightweight, 105 text-based, language-independent data interchange format. JSON is 106 popular in the Web development environment as it is easy for humans 107 to read and write. 109 The Concise Binary Object Representation (CBOR) [RFC7049] is a binary 110 data format which requires extremely small code size, allows very 111 compact message representation, and provides extensibility without 112 the need for version negotiation. CBOR is especially well suited for 113 IoT environments because of these efficiencies. 115 When converting between a bespoke syntax such as that defined by 116 [RFC6690] and JSON or CBOR, many small decisions have to be made. If 117 left without guidance, it is likely that a number of slightly 118 incompatible dialects will emerge. This specification defines a 119 common approach for translating between the CoRE-specific bespoke 120 formats, JSON and CBOR formats. Where applicable, mapping from other 121 formats (e.g. CoRE Link Format) into JSON or CBOR is also described. 123 This specification defines a common format for representing CoRE Web 124 Linking in JSON and CBOR, as well as the various JSON formats for 125 controlling CoRE group communication [RFC7390], in CBOR. 127 Note that there is a separate question on how to represent Web links 128 pointing out of JSON documents, as discussed e.g. in [MNOT11]. While 129 there are good reasons to stay as compatible as possible to 130 developments in this area, the present specification is solving a 131 different problem. 133 1.1. Objectives 135 This specification has been designed based on the following 136 objectives: 138 o Canonical mapping 140 * lossless round-tripping with [RFC6690] and between JSON and 141 CBOR 143 * but not trying for bit-preserving (DER-style) round-tripping 145 o The simplest thing that could possibly work 147 * Do not cater for RFC 5988 complications caused by HTTP header 148 character set issues [RFC2047] 150 o Consider other work that has links in JSON, e.g.: JSON-LD, JSON- 151 Reference [I-D.pbryan-zyp-json-ref] 153 * Do not introduce unmotivated differences 155 1.2. Terminology 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 159 "OPTIONAL" in this document are to be interpreted as described in 160 [RFC2119] when they appear in ALL CAPS. These words may also appear 161 in this document in lower case as plain English words, absent their 162 normative meanings. 164 The term "byte" is used in its now customary sense as a synonym for 165 "octet". 167 CoAP: Constrained Application Protocol [RFC7252] 169 CBOR: Concise Binary Object Representation [RFC7049] 171 CoRE: Constrained RESTful Environments, the field of work underlying 172 [RFC6690], [RFC7049], [RFC7252], and [RFC7390] 174 IoT: Internet of Things 176 JSON: JavaScript Object Notation [RFC7159] 178 The objective of the JSON and CBOR mappings defined in this document 179 is to contain information of the formats specified in [RFC5988] and 180 [RFC6690]. This specification therefore uses the names of the ABNF 181 productions used in those documents. 183 2. Web Links in JSON and CBOR 185 2.1. Background 187 Web Linking [RFC5988] provides a way to represent links between Web 188 resources as well as the relations expressed by them and attributes 189 of such a link. In constrained networks, a collection of Web links 190 can be exchanged in the CoRE link format [RFC6690] to enable resource 191 discovery, for instance by using the CoAP protocol [RFC7252] and in 192 conjunction with the CoRE resource directory 193 [I-D.ietf-core-resource-directory]. 195 2.2. Information Model 197 This section discusses the information model underlying the CORE Link 198 Format payload. 200 An application/link-format document is a collection of web links 201 ("link-value"), each of which is a collection of attributes ("link- 202 param") applied to a "URI-Reference". 204 We straightforwardly map: 206 o the outer collection to an array of links; 208 o each link to a JSON object or CBOR map, mapping attribute names to 209 attribute values. 211 In the object representing a "link-value", each target attribute or 212 other parameter ("link-param") is represented by a JSON name/value 213 pair (member). The name is a string representation of the parameter 214 or attribute name (as in "parmname"), the value is a string 215 representation of the parameter or attribute value ("ptoken" or 216 "quoted-string"). "quoted-string" productions are parsed (i.e, the 217 outer quotes removed and the backslash constructions evaluated) as 218 defined in [RFC6690] and its referenced documents, before placing 219 them in JSON strings (where they may gain back additional decorations 220 such as backslashes as defined in [RFC7159]). 222 If no attribute value ("ptoken" or "quoted-string") is present, the 223 presence of the attribute name is indicated by using "true" as the 224 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, it is 257 beneficial to perform an extra encoding step, and encode "href" and 258 some commonly occurring attribute names as small integers. 260 The substitution is summarized below: 262 +----------+---------------+ 263 | name | encoded value | 264 +----------+---------------+ 265 | href | 1 | 266 | rel | 2 | 267 | anchor | 3 | 268 | rev | 4 | 269 | hreflang | 5 | 270 | media | 6 | 271 | title | 7 | 272 | type | 8 | 273 | rt | 9 | 274 | if | 10 | 275 | sz | 11 | 276 | ct | 12 | 277 | obs | 13 | 278 +----------+---------------+ 280 Table 1: Integer Encoding of common attribute names 282 _** TO DO: Is this the right list of attribute names? **_ 284 This list of substitutions is fixed by the present specification; no 285 future expansion of the list is foreseen. "href" as well as all 286 attribute names in this list MUST be represented by their integer 287 substitutions and MUST NOT use the attribute name in text form. 289 This leads to the following CDDL representation for the CBOR 290 encoding: 292 links = [* link] 293 link = { 294 href: tstr ; resource URI 295 * label => tstr / true 296 } 297 label = tstr / &( 298 href: 1, rel: 2, anchor: 3, 299 rev: 4, hreflang: 5, media: 6, 300 title: 7, type: 8, rt: 9, 301 if: 10, sz: 11, ct: 12, 302 obs: 13, 303 ) 305 Figure 2: CoRE Link Format Data Model (CBOR) 307 2.4. Examples 309 ;ct=40;title="Sensor Index", 310 ;rt="temperature-c";if="sensor", 311 ;rt="light-lux";if="sensor", 312 ;anchor="/sensors/temp" 313 ;rel="describedby", 314 ;anchor="/sensors/temp";rel="alternate" 316 Figure 3: Example from page 15 of [RFC6690] 318 The link-format document in Figure 3 becomes (321 bytes): 320 "[{"href":"/sensors","ct":"40","title":"Sensor 321 Index"},{"href":"/sensors/temp","rt":"temperature- 322 c","if":"sensor"},{"href":"/sensors/light","rt":"light- 323 lux","if":"sensor"},{"href":"http://www.example.com/sensors/ 324 t123","anchor":"/sensors/ 325 temp","rel":"describedby"},{"href":"/t","anchor":"/sensors/ 326 temp","rel":"alternate"}] " 328 (More examples to be added.) 330 2.4.1. Link Format to CBOR Example 332 This examples shows conversion from link format to CBOR format. 334 The link-format document in Figure 3 becomes (in CBOR diagnostic 335 format): 337 [{1: "/sensors", 12: "40", 7: "Sensor Index"}, 338 {1: "/sensors/temp", 9: "temperature-c", 10: "sensor"}, 339 {1: "/sensors/light", 9: "light-lux", 10: "sensor"}, 340 {1: "http://www.example.com/sensors/t123", 3: "/sensors/temp", 341 2: "describedby"}, 342 {1: "/t", 3: "/sensors/temp", 2: "alternate"}] 344 or, in hexadecimal (203 bytes): 346 85 # array(number of data items:5) 347 a3 # map(# data item pairs:3) 348 01 # unsigned integer(value:1,"href") 349 68 # text string(8 bytes) 350 2f73656e736f7273 # "/sensors" 351 0c # unsigned integer(value:12,"ct") 352 62 # text(2) 353 3430 # "40" 354 07 # unsigned integer(value:7,"title") 355 6c # text string(12 bytes) 356 53656e736f7220496e646578 # "Sensor Index" 357 a3 # map(# data item pairs:3) 358 01 # unsigned integer(value:1,"href") 359 6d # text string(13 bytes) 360 2f73656e736f72732f74 361 656d70 # "/sensors/temp" 362 09 # unsigned integer(value:9,"rt") 363 6d # text string(13 bytes) 364 74656d70657261747572 365 652d63 # "temperature-c" 366 0a # unsigned integer(value:10,"if") 367 66 # text string(6 bytes) 368 73656e736f72 # "sensor" 369 a3 # map(# data item pairs:3) 370 01 # unsigned integer(value:1,"href") 371 6e # text string(14 bytes) 372 2f73656e736f72732f6c 373 69676874 # "/sensors/light" 374 09 # unsigned integer(value:9,"rt") 375 69 # text string(9 bytes) 376 6c696768742d6c7578 # "light-lux" 377 0a # unsigned integer(value:10,"if") 378 66 # text string(6 bytes) 379 73656e736f72 # "sensor" 380 a3 # map(# data item pairs:3) 381 01 # unsigned integer(value:1,"href") 382 78 23 # text string(35 bytes) 383 687474703a2f2f777777 384 2e6578616d706c652e63 385 6f6d2f73656e736f7273 386 2f74313233 # "http://www.example.com/sensors/t123" 387 03 # unsigned integer(value:3,"anchor") 388 6d # text string(13 bytes) 389 2f73656e736f72732f74 390 656d70 # "/sensors/temp" 391 02 # unsigned integer(value:2,"rel") 392 6b # text string(11 bytes) 393 6465736372696265646279 # "describedby" 394 a3 # map(# data item pairs:3) 395 01 # unsigned integer(value:1,"href") 396 62 # text string(12 bytes) 397 2f74 # "/t" 398 03 # unsigned integer(value:3,"anchor") 399 6d # text string(13 bytes) 400 2f73656e736f72732f74 401 656d70 # "/sensors/temp" 402 02 # unsigned integer(value:2,"rel") 403 69 # text string(9 bytes) 404 616c7465726e617465 # "alternate" 406 Figure 4: Web Links Encoded in CBOR 408 2.4.2. Link Format in JSON to CBOR Example 410 This examples shows conversion from link format JSON to CBOR format. 412 The JSON example from Section 2.4 becomes: 414 85 # array(number of data items:5) 415 a3 # map(# data item pairs:3) 416 01 # unsigned integer(value:1, "href") 417 68 # text string(8 bytes) 418 2f73656e736f7273 # "/sensors" 419 0c # unsigned integer(value:12,"ct") 420 18 28 # unsigned integer(value:40) 421 07 # unsigned integer(value:7,"title") 422 6c # text string(12 bytes) 423 53656e736f7220496e646578 # "Sensor Index" 424 a3 # map(# data item pairs:3) 425 01 # unsigned integer(value:1,"href") 426 6d # text string(13 bytes) 427 2f73656e736f72732f74 428 656d70 # "/sensors/temp" 429 09 # unsigned integer(value:9,"rt") 430 6d # text string(13 bytes) 431 74656d70657261747572 432 652d63 # "temperature-c" 433 0a # unsigned integer(value:10,"if") 434 66 # text string(6 bytes) 435 73656e736f72 # "sensor" 436 a3 # map(# data item pairs:3) 437 01 # unsigned integer(value:1,"href") 438 6e # text string(14 bytes) 439 2f73656e736f72732f6c 440 69676874 # "/sensors/light" 441 09 # unsigned integer(value:9,"rt") 442 69 # text string(9 bytes) 443 6c696768742d6c7578 # "light-lux" 444 0a # unsigned integer(value:10,"if") 445 66 # text string(6 bytes) 446 73656e736f72 # "sensor" 447 a3 # map(# data item pairs:3) 448 01 # unsigned integer(value:1,"href") 449 78 23 # text string(35 bytes) 450 687474703a2f2f777777 451 2e6578616d706c652e63 452 6f6d2f73656e736f7273 453 2f74313233 # "http://www.example.com/sensors/t123" 454 03 # unsigned integer(value:3,"anchor") 455 6d # text string(13 bytes) 456 2f73656e736f72732f74 457 656d70 # "/sensors/temp" 458 02 # unsigned integer(value:2,"rel") 459 6b # text string(11 bytes) 460 6465736372696265646279 # "describedby" 461 a3 # map(# data item pairs:3) 462 01 # unsigned integer(value:1,"href") 463 62 # text string(12 bytes) 464 2f74 # "/t" 465 03 # unsigned integer(value:3,"anchor") 466 6d # text string(13 bytes) 467 2f73656e736f72732f74 468 656d70 # "/sensors/temp" 469 02 # unsigned integer(value:2,"rel") 470 69 # text string(9 bytes) 471 616c7465726e617465 # "alternate" 472 Figure 5: Web Links Encoded in CBOR 474 3. Group Communication Management Objects in CBOR 476 3.1. Background 478 The CoAP Group Communications specification [RFC7390] defines group 479 management objects in JSON format. These objects are used to 480 represent IP multicast group information for CoAP endpoints. See 481 [I-D.ietf-core-resource-directory] for more examples of using these 482 objects. 484 3.2. Information Model 486 This section discusses the information model underlying the CoAP 487 Group Communication management object payload. 489 A group membership JSON object contains one or more key/value pairs, 490 and represents a single IP multicast group membership for the CoAP 491 endpoint. Each key/value pair is encoded as a member of the JSON 492 object, where the key is the member name and the value is the 493 member's value. 495 The information model of the CoAP Group Communication management 496 object can be summarized below: 498 collection = { * index => membership } 499 index = tstr .regexp "[A-Za-z0-9]{1,2}" 500 membership = { 501 ? n: groupname, 502 ? a: groupaddress, 503 } 504 groupname = tstr ; host [":" port] 505 groupaddress = tstr ; IPv4address [ ":" port ] 506 ; / "[" IPv6address "]" [":" port ] 508 Figure 6: CoAP Group Communication Data Model 510 3.3. Mapping 512 The objective of the mapping defined in this section is to map 513 information from the JSON formats specified in [RFC7390] into CBOR 514 format, using the rules of Section 4.2 of [RFC7049]. 516 3.4. Group Communication Example 518 { "8" :{ "a": "[ff15::4200:f7fe:ed37:14ca]" }, 519 "11":{ "n": "sensors.floor1.west.bldg6.example.com", 520 "a": "[ff15::4200:f7fe:ed37:25cb]" }, 521 "12":{ "n": "All-Devices.floor1.west.bldg6.example.com", 522 "a": "[ff15::4200:f7fe:ed37:abcd]:4567" } 523 } 525 Figure 7: Example from section 2.6.2.4 of [RFC7390] 527 becomes: 529 a3 # map(3) 530 61 # text(1) 531 38 # "8" 532 a1 # map(1) 533 61 # text(1) 534 61 # "a" 535 78 1b # text(27) 536 5b666631353a3a343230 537 303a663766653a656433 538 373a313463615d # "[ff15::4200:f7fe:ed37:14ca]" 539 62 # text(2) 540 3131 # "11" 541 a2 # map(2) 542 61 # text(1) 543 6e # "n" 544 78 25 # text(37) 545 73656e736f72732e666c 546 6f6f72312e776573742e 547 626c6467362e6578616d 548 706c652e636f6d # "sensors.floor1.west.bldg6.example.com" 549 61 # text(1) 550 61 # "a" 551 78 1b # text(27) 552 5b666631353a3a343230 553 303a663766653a656433 554 373a323563625d # "[ff15::4200:f7fe:ed37:25cb]" 555 62 # text(2) 556 3132 # "12" 557 a2 # map(2) 558 61 # text(1) 559 6e # "n" 560 78 29 # text(41) 561 416c6c2d446576696365 562 732e666c6f6f72312e77 563 6573742e626c6467362e 564 6578616d706c652e636f 565 6d # "All-Devices.floor1.west.bldg6.example.com" 566 61 # text(1) 567 61 # "a" 568 78 20 # text(32) 569 5b666631353a3a343230 570 303a663766653a656433 571 373a616263645d3a34353637 # "[ff15::4200:f7fe:ed37:abcd]:4567" 573 Figure 8: Group Communication Management Object Encoded in CBOR 575 TO DO: Should the IP address/port number information be represented 576 in a more compact way? 578 4. IANA Considerations 580 This specification registers the following additional Internet Media 581 Types: 583 Type name: application 585 Subtype name: link-format+json 587 Required parameters: None 589 Optional parameters: None 591 Encoding considerations: Resources that use the "application/ 592 link-format+json" media type are required to conform to the 593 "application/json" Media Type and are therefore subject to the 594 same encoding considerations specified in [RFC7159], Section 11. 596 Security considerations: As defined in this specification 598 Published specification: This specification. 600 Applications that use this media type: None currently known. 602 Additional information: 604 Magic number(s): N/A 606 File extension(s): N/A 608 Macintosh file type code(s): TEXT 610 Person & email address to contact for further information: 611 Carsten Bormann 613 Intended usage: COMMON 615 Change controller: IESG 617 and 618 Type name: application 620 Subtype name: link-format+cbor 622 Required parameters: None 624 Optional parameters: None 626 Encoding considerations: Resources that use the "application/ 627 link-format+cbor" media type are required to conform to the 628 "application/cbor" Media Type and are therefore subject to the 629 same encoding considerations specified in [RFC7049], Section 7. 631 Security considerations: As defined in this specification 633 Published specification: This specification. 635 Applications that use this media type: None currently known. 637 Additional information: 639 Magic number(s): N/A 641 File extension(s): N/A 643 Macintosh file type code(s): CBOR 645 Person & email address to contact for further information: 646 Kepeng Li <kepeng.lkp@alibaba-inc.com> 648 Intended usage: COMMON 650 Change controller: IESG 652 5. Security Considerations 654 The security considerations of [RFC6690], [RFC7049] and [RFC7159] 655 apply. 657 (TBD.) 659 6. Acknowledgements 661 (TBD.) 663 Special thanks to Bert Greevenbosch who was an author on the initial 664 version of a contributing document, as well as the original author on 665 the CDDL notation. 667 7. References 669 7.1. Normative References 671 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 672 Requirement Levels", BCP 14, RFC 2119, March 1997. 674 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. 676 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 677 Format", RFC 6690, August 2012. 679 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 680 Representation (CBOR)", RFC 7049, October 2013. 682 [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data 683 Interchange Format", RFC 7159, March 2014. 685 7.2. Informative References 687 [I-D.greevenbosch-appsawg-cbor-cddl] 688 Vigano, C. and H. Birkholz, "CBOR data definition 689 language: a notational convention to express CBOR data 690 structures.", draft-greevenbosch-appsawg-cbor-cddl-06 691 (work in progress), July 2015. 693 [I-D.ietf-core-resource-directory] 694 Shelby, Z., Koster, M., Bormann, C., and P. Stok, "CoRE 695 Resource Directory", draft-ietf-core-resource-directory-03 696 (work in progress), June 2015. 698 [I-D.pbryan-zyp-json-ref] 699 Bryan, P. and K. Zyp, "JSON Reference", draft-pbryan-zyp- 700 json-ref-03 (work in progress), September 2012. 702 [MNOT11] Nottingham, M., "Linking in JSON", November 2011, 703 . 705 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 706 Part Three: Message Header Extensions for Non-ASCII Text", 707 RFC 2047, November 1996. 709 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 710 Application Protocol (CoAP)", RFC 7252, June 2014. 712 [RFC7390] Rahman, A. and E. Dijk, "Group Communication for the 713 Constrained Application Protocol (CoAP)", RFC 7390, 714 October 2014. 716 Appendix A. Implementation 718 This appendix provides a simple reference implementation of the 719 mapping between CoRE link format and Links-in-JSON. 721 (TBD - the reference implementation was used to create the above 722 examples, but I still have to clean it up for readability and paste 723 it in at 69 columns max.) 725 Authors' Addresses 727 Kepeng LI 728 Alibaba Group 729 Wenyixi Road, Yuhang District 730 Hangzhou, Zhejiang 311121 731 China 733 Email: kepeng.lkp@alibaba-inc.com 735 Akbar Rahman 736 InterDigital Communications, LLC 737 1000 Sherbrooke Street West 738 Montreal, Quebec H3A 3G4 739 Canada 741 Phone: +1-514-585-0761 742 Email: akbar.rahman@interdigital.com 744 Carsten Bormann (editor) 745 Universitaet Bremen TZI 746 Postfach 330440 747 Bremen D-28359 748 Germany 750 Phone: +49-421-218-63921 751 Email: cabo@tzi.org