idnits 2.17.1 draft-ietf-core-links-json-06.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 08, 2016) is 2846 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 254, 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-08 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). 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 9, 2017 InterDigital 6 C. Bormann, Ed. 7 Universitaet Bremen TZI 8 July 08, 2016 10 Representing CoRE Formats in JSON and CBOR 11 draft-ietf-core-links-json-06 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 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on January 9, 2017. 49 Copyright Notice 51 Copyright (c) 2016 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 1.1. Objectives . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Web Links in JSON and CBOR . . . . . . . . . . . . . . . . . 4 70 2.1. Background . . . . . . . . . . . . . . . . . . . . . . . 4 71 2.2. Information Model . . . . . . . . . . . . . . . . . . . . 4 72 2.3. Additional Encoding Step for CBOR . . . . . . . . . . . . 6 73 2.4. Examples . . . . . . . . . . . . . . . . . . . . . . . . 7 74 2.4.1. Link Format to JSON Example . . . . . . . . . . . . . 7 75 2.4.2. Link Format to CBOR Example . . . . . . . . . . . . . 8 76 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 77 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 78 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 79 5.1. Normative References . . . . . . . . . . . . . . . . . . 12 80 5.2. Informative References . . . . . . . . . . . . . . . . . 13 81 Appendix A. Reference implementation . . . . . . . . . . . . . . 14 82 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 16 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 85 1. Introduction 87 Web Linking [RFC5988] provides a way to represent links between Web 88 resources as well as the relations expressed by them and attributes 89 of such a link. In constrained networks, a collection of Web links 90 can be exchanged in the CoRE link format [RFC6690] to enable resource 91 discovery, for instance by using the CoAP protocol [RFC7252]. 93 The JavaScript Object Notation (JSON) [RFC7159] is a lightweight, 94 text-based, language-independent data interchange format. JSON is 95 popular in the Web development environment as it is easy for humans 96 to read and write. 98 The Concise Binary Object Representation (CBOR) [RFC7049] is a binary 99 data format which requires extremely small code size, allows very 100 compact message representation, and provides extensibility without 101 the need for version negotiation. CBOR is especially well suited for 102 IoT environments because of these efficiencies. 104 When converting between a bespoke syntax such as that defined by 105 [RFC6690] and JSON or CBOR, many small decisions have to be made. If 106 left without guidance, it is likely that a number of slightly 107 incompatible dialects will emerge. This specification defines a 108 common approach for translating between the CoRE-specific bespoke 109 formats, JSON and CBOR formats. Where applicable, mapping from other 110 formats (e.g. CoRE Link Format) into JSON or CBOR is also described. 112 This specification defines a common format for representing CoRE Web 113 Linking in JSON and CBOR. 115 Note that there is a separate question on how to represent Web links 116 pointing out of JSON documents, as discussed e.g. in [MNOT11]. While 117 there are good reasons to stay as compatible as possible to 118 developments in this area, the present specification is solving a 119 different problem. 121 1.1. Objectives 123 This specification has been designed based on the following 124 objectives: 126 o Canonical mapping 128 * lossless round-tripping with [RFC6690] and between JSON and 129 CBOR 131 * but not trying for bit-preserving (DER-style) round-tripping 133 o The simplest thing that could possibly work 135 * Do not cater for RFC 5988 complications caused by HTTP header 136 character set issues [RFC2047] 138 o Consider other work that has links in JSON, e.g.: JSON-LD, JSON- 139 Reference [I-D.pbryan-zyp-json-ref] 141 * Do not introduce unmotivated differences 143 1.2. Terminology 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 147 "OPTIONAL" in this document are to be interpreted as described in 148 [RFC2119] when they appear in ALL CAPS. These words may also appear 149 in this document in lower case as plain English words, absent their 150 normative meanings. 152 The term "byte" is used in its now customary sense as a synonym for 153 "octet". 155 CoAP: Constrained Application Protocol [RFC7252] 157 CBOR: Concise Binary Object Representation [RFC7049] 159 CoRE: Constrained RESTful Environments, the field of work underlying 160 [RFC6690], [RFC7049], [RFC7252], and [RFC7641] 162 IoT: Internet of Things 164 JSON: JavaScript Object Notation [RFC7159] 166 The objective of the JSON and CBOR mappings defined in this document 167 is to contain information of the formats specified in [RFC5988] and 168 [RFC6690]. This specification therefore uses the names of the ABNF 169 productions used in those documents. 171 2. Web Links in JSON and CBOR 173 2.1. Background 175 Web Linking [RFC5988] provides a way to represent links between Web 176 resources as well as the relations expressed by them and attributes 177 of such a link. In constrained networks, a collection of Web links 178 can be exchanged in the CoRE link format [RFC6690] to enable resource 179 discovery, for instance by using the CoAP protocol [RFC7252] and in 180 conjunction with the CoRE resource directory 181 [I-D.ietf-core-resource-directory]. 183 2.2. Information Model 185 This section discusses the information model underlying the CORE Link 186 Format payload. 188 An application/link-format document is a collection of web links 189 ("link-value"), each of which is a collection of attributes ("link- 190 param") applied to a "URI-Reference". 192 We straightforwardly map: 194 o the outer collection to an array of links; 196 o each link to a JSON object or CBOR map, mapping attribute names to 197 attribute values. 199 In the object representing a "link-value", each target attribute or 200 other parameter ("link-param") is represented by a JSON name/value 201 pair (member). The name is a string representation of the parameter 202 or attribute name (as in "parmname"), the value is a string 203 representation of the parameter or attribute value ("ptoken" or 204 "quoted-string"). "quoted-string" productions are parsed (i.e, the 205 outer quotes removed and the backslash constructions evaluated) as 206 defined in [RFC6690] and its referenced documents, before placing 207 them in JSON strings (in the representation of which they may gain 208 back additional decorations such as backslashes as defined in 209 [RFC7159]). 211 If no attribute value ("ptoken" or "quoted-string") is present, the 212 presence of the attribute name is indicated by using the Boolean 213 value "true" as the value. 215 If a Link attribute ("parmname") is present more than once in a 216 "link-value", its values are then represented as a JSON array of JSON 217 string values; this array becomes the value of the JSON name/value 218 pair where the attribute name is the JSON name. Attributes occurring 219 just once MUST NOT be represented as JSON arrays but MUST be directly 220 represented as JSON strings. (Note that [RFC6690] has cut down on 221 the use of repeated parameter names; they are still allowed by 222 [RFC5988] though. No attempt has been made to decode the possibly 223 space-separated values for rt=, if=, and rel= into JSON arrays.) 225 The URI-Reference is represented as a name/value pair with the name 226 "href" and the URI-Reference as the value. (Rationale: This usage is 227 consistent with the use of "href" as a query parameter for link- 228 format query filtering and with link-format reserving the link 229 parameter "href" specifically for this use [RFC6690]). 231 The resulting structure can be represented in CDDL 232 [I-D.greevenbosch-appsawg-cbor-cddl] as: 234 links = [* link] 235 link = { 236 href: tstr ; resource URI 237 * tstr => tstr / true 238 } 240 Figure 1: CoRE Link Format Data Model 242 2.3. Additional Encoding Step for CBOR 244 The above specification for JSON could be used as is for the CBOR 245 encoding as well. However, to further reduce message sizes, an extra 246 encoding step is performed: "href" and some commonly occurring 247 attribute names are encoded as small integers. 249 The substitution is summarized below: 251 +----------+---------------+------------------------------------+ 252 | name | encoded value | reference | 253 +----------+---------------+------------------------------------+ 254 | href | 1 | [RFC6690], [RFCthis] | 255 | rel | 2 | [RFC5988] Section 5.3 | 256 | anchor | 3 | [RFC5988] Section 5.2 | 257 | rev | 4 | [RFC5988] Section 5.3 | 258 | hreflang | 5 | [RFC5988] Section 5.4 | 259 | media | 6 | [RFC5988] Section 5.4 | 260 | title | 7 | [RFC5988] Section 5.4 | 261 | type | 8 | [RFC5988] Section 5.4 | 262 | rt | 9 | [RFC6690] Section 3.1 | 263 | if | 10 | [RFC6690] Section 3.2 | 264 | sz | 11 | [RFC6690] Section 3.3 | 265 | ct | 12 | [RFC7252] Section 7.2.1 | 266 | obs | 13 | [RFC7641] Section 6 | 267 | ins | 14 | [I-D.ietf-core-resource-directory] | 268 | exp | 15 | [I-D.ietf-core-resource-directory] | 269 +----------+---------------+------------------------------------+ 271 Table 1: Integer Encoding of common attribute names 273 (Comment to be deleted before submitting this document to the IESG: 274 This list should, again, be checked against relevant references at 275 WGLC time.) 277 This list of substitutions is fixed by the present specification; no 278 future expansion of the list is foreseen. "href" as well as all 279 attribute names in this list MUST be represented by their integer 280 substitutions and MUST NOT use the attribute name in text form. 282 This leads to the following CDDL representation for the CBOR 283 encoding: 285 links = [* link] 286 link = { 287 href: tstr ; resource URI 288 * label => tstr / true 289 } 290 label = tstr / &( 291 href: 1, rel: 2, anchor: 3, 292 rev: 4, hreflang: 5, media: 6, 293 title: 7, type: 8, rt: 9, 294 if: 10, sz: 11, ct: 12, 295 obs: 13, 296 ) 298 Figure 2: CoRE Link Format Data Model (CBOR) 300 2.4. Examples 302 The examples in this section are based on an example on page 15 of 303 [RFC6690] (Figure 3). 305 ;ct=40;title="Sensor Index", 306 ;rt="temperature-c";if="sensor", 307 ;rt="light-lux";if="sensor", 308 ;anchor="/sensors/temp" 309 ;rel="describedby", 310 ;anchor="/sensors/temp";rel="alternate" 312 Figure 3: Example from page 15 of [RFC6690] 314 2.4.1. Link Format to JSON Example 316 The link-format document in Figure 3 becomes (321 bytes, line breaks 317 shown are not part of the minimally-sized JSON document): 319 "[{"href":"/sensors","ct":"40","title":"Sensor 320 Index"},{"href":"/sensors/temp","rt":"temperature- 321 c","if":"sensor"},{"href":"/sensors/light","rt":"light- 322 lux","if":"sensor"},{"href":"http://www.example.com/sensors/ 323 t123","anchor":"/sensors/ 324 temp","rel":"describedby"},{"href":"/t","anchor":"/sensors/ 325 temp","rel":"alternate"}] " 327 To demonstrate the handling of value-less and array-valued 328 attributes, we extend the link-format example by examples of these 329 (Figure 4; the "obs" attribute is defined in Section 6 of [RFC7641], 330 while the "foo" attribute is for exposition only): 332 ;ct=40;title="Sensor Index", 333 ;rt="temperature-c";if="sensor";obs, 334 ;rt="light-lux";if="sensor", 335 ;anchor="/sensors/temp" 336 ;rel="describedby";foo="bar";foo=3;ct=4711, 337 ;anchor="/sensors/temp";rel="alternate" 339 Figure 4: Example derived from page 15 of [RFC6690] 341 The link-format document in Figure 4 becomes the JSON document in 342 Figure 5 (some spacing and indentation added): 344 [{"href":"/sensors","ct":"40","title":"Sensor Index"}, 345 {"href":"/sensors/temp","rt":"temperature-c","if":"sensor", 346 "obs":true}, 347 {"href":"/sensors/light","rt":"light-lux","if":"sensor"}, 348 {"href":"http://www.example.com/sensors/t123", 349 "anchor":"/sensors/temp","rel":"describedby", 350 "foo":["bar","3"],"ct":"4711"}, 351 {"href":"/t","anchor":"/sensors/temp","rel":"alternate"}] 353 Figure 5: Example derived from page 15 of [RFC6690] 355 Note that the conversion is unable to convert the string-valued "ct" 356 attribute to a number, which would be the natural type for a Content- 357 Format value; similarly, both "foo" values are treated as strings 358 independently of whether they are quoted or numeric in syntax. 360 2.4.2. Link Format to CBOR Example 362 This examples shows conversion from link format to CBOR format. 364 The link-format document in Figure 3 becomes (in CBOR diagnostic 365 format): 367 [{1: "/sensors", 12: "40", 7: "Sensor Index"}, 368 {1: "/sensors/temp", 9: "temperature-c", 10: "sensor"}, 369 {1: "/sensors/light", 9: "light-lux", 10: "sensor"}, 370 {1: "http://www.example.com/sensors/t123", 3: "/sensors/temp", 371 2: "describedby"}, 372 {1: "/t", 3: "/sensors/temp", 2: "alternate"}] 374 or, in hexadecimal (203 bytes): 376 85 # array(number of data items:5) 377 a3 # map(# data item pairs:3) 378 01 # unsigned integer(value:1,"href") 379 68 # text string(8 bytes) 380 2f73656e736f7273 # "/sensors" 381 0c # unsigned integer(value:12,"ct") 382 62 # text(2) 383 3430 # "40" 384 07 # unsigned integer(value:7,"title") 385 6c # text string(12 bytes) 386 53656e736f7220496e646578 # "Sensor Index" 387 a3 # map(# data item pairs:3) 388 01 # unsigned integer(value:1,"href") 389 6d # text string(13 bytes) 390 2f73656e736f72732f74 391 656d70 # "/sensors/temp" 392 09 # unsigned integer(value:9,"rt") 393 6d # text string(13 bytes) 394 74656d70657261747572 395 652d63 # "temperature-c" 396 0a # unsigned integer(value:10,"if") 397 66 # text string(6 bytes) 398 73656e736f72 # "sensor" 399 a3 # map(# data item pairs:3) 400 01 # unsigned integer(value:1,"href") 401 6e # text string(14 bytes) 402 2f73656e736f72732f6c 403 69676874 # "/sensors/light" 404 09 # unsigned integer(value:9,"rt") 405 69 # text string(9 bytes) 406 6c696768742d6c7578 # "light-lux" 407 0a # unsigned integer(value:10,"if") 408 66 # text string(6 bytes) 409 73656e736f72 # "sensor" 410 a3 # map(# data item pairs:3) 411 01 # unsigned integer(value:1,"href") 412 78 23 # text string(35 bytes) 413 687474703a2f2f777777 414 2e6578616d706c652e63 415 6f6d2f73656e736f7273 416 2f74313233 # "http://www.example.com/sensors/t123" 417 03 # unsigned integer(value:3,"anchor") 418 6d # text string(13 bytes) 419 2f73656e736f72732f74 420 656d70 # "/sensors/temp" 421 02 # unsigned integer(value:2,"rel") 422 6b # text string(11 bytes) 423 6465736372696265646279 # "describedby" 424 a3 # map(# data item pairs:3) 425 01 # unsigned integer(value:1,"href") 426 62 # text string(12 bytes) 427 2f74 # "/t" 428 03 # unsigned integer(value:3,"anchor") 429 6d # text string(13 bytes) 430 2f73656e736f72732f74 431 656d70 # "/sensors/temp" 432 02 # unsigned integer(value:2,"rel") 433 69 # text string(9 bytes) 434 616c7465726e617465 # "alternate" 436 Figure 6: Web Links Encoded in CBOR 438 3. IANA Considerations 440 This specification registers the following additional Internet Media 441 Types: 443 Type name: application 445 Subtype name: link-format+json 447 Required parameters: None 449 Optional parameters: None 451 Encoding considerations: Resources that use the "application/ 452 link-format+json" media type are required to conform to the 453 "application/json" Media Type and are therefore subject to the 454 same encoding considerations specified in [RFC7159], Section 11. 456 Security considerations: As defined in this specification 458 Published specification: This specification. 460 Applications that use this media type: None currently known. 462 Additional information: 464 Magic number(s): N/A 466 File extension(s): N/A 468 Macintosh file type code(s): TEXT 470 Person & email address to contact for further information: 471 Carsten Bormann 473 Intended usage: COMMON 475 Change controller: IESG 477 and 478 Type name: application 480 Subtype name: link-format+cbor 482 Required parameters: None 484 Optional parameters: None 486 Encoding considerations: Resources that use the "application/ 487 link-format+cbor" media type are required to conform to the 488 "application/cbor" Media Type and are therefore subject to the 489 same encoding considerations specified in [RFC7049], Section 7. 491 Security considerations: As defined in this specification 493 Published specification: This specification. 495 Applications that use this media type: None currently known. 497 Additional information: 499 Magic number(s): N/A 501 File extension(s): N/A 503 Macintosh file type code(s): CBOR 505 Person & email address to contact for further information: 506 Kepeng Li 508 Intended usage: COMMON 510 Change controller: IESG 512 4. Security Considerations 514 The security considerations relevant to the data model of [RFC6690], 515 as well as those of [RFC7049] and [RFC7159] apply. 517 5. References 519 5.1. Normative References 521 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 522 Requirement Levels", BCP 14, RFC 2119, 523 DOI 10.17487/RFC2119, March 1997, 524 . 526 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, 527 DOI 10.17487/RFC5988, October 2010, 528 . 530 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 531 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 532 . 534 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 535 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 536 October 2013, . 538 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 539 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 540 2014, . 542 5.2. Informative References 544 [I-D.greevenbosch-appsawg-cbor-cddl] 545 Vigano, C. and H. Birkholz, "CBOR data definition language 546 (CDDL): a notational convention to express CBOR data 547 structures", draft-greevenbosch-appsawg-cbor-cddl-08 (work 548 in progress), March 2016. 550 [I-D.ietf-core-resource-directory] 551 Shelby, Z., Koster, M., Bormann, D., and P. Stok, "CoRE 552 Resource Directory", draft-ietf-core-resource-directory-08 553 (work in progress), July 2016. 555 [I-D.pbryan-zyp-json-ref] 556 Bryan, P. and K. Zyp, "JSON Reference", draft-pbryan-zyp- 557 json-ref-03 (work in progress), September 2012. 559 [MNOT11] Nottingham, M., "Linking in JSON", November 2011, 560 . 562 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 563 Part Three: Message Header Extensions for Non-ASCII Text", 564 RFC 2047, DOI 10.17487/RFC2047, November 1996, 565 . 567 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 568 Application Protocol (CoAP)", RFC 7252, 569 DOI 10.17487/RFC7252, June 2014, 570 . 572 [RFC7641] Hartke, K., "Observing Resources in the Constrained 573 Application Protocol (CoAP)", RFC 7641, 574 DOI 10.17487/RFC7641, September 2015, 575 . 577 [RUBY] "Information technology -- Programming languages -- Ruby", 578 ISO/IEC 30170:2012, April 2012. 580 Appendix A. Reference implementation 582 A reference implementation of a converter from [RFC6690] link-format 583 to JSON and CBOR (and back to link-format) in the programming 584 language Ruby [RUBY] is reproduced below. 586 # 587 require 'strscan' 588 require 'json' 589 require 'cbor-pretty' 591 class String 592 def as_utf8 593 force_encoding(Encoding::UTF_8) 594 end 595 end 597 module CoRE 598 module Links 599 def self.map_to_true(a) 600 Hash[a.map{ |t| [t, true]}] 601 end 603 PTOKENCHAR = %r"[\[\]\w!#-+\--/:<-?^-`{-~@]" 604 QUOSTRCHAR = %r{(?:[^"\\]|\\.)} # to be used inside " 605 ATTRCHAR = %r"[\w!#$&+.^`|~-]" 606 MUSTBEQUOTED = map_to_true(%w{anchor title rt if}) 607 ANCHORNAME = "href" 608 SCANATTR = 609 %r{(#{ATTRCHAR}+)(?:=(?:(#{PTOKENCHAR}+)|"(#{QUOSTRCHAR}*)"))?} # " 611 RAWMAPPINGS = <<-DATA 612 href: 1, rel: 2, anchor: 3, 613 rev: 4, hreflang: 5, media: 6, 614 title: 7, type: 8, rt: 9, 615 if: 10, sz: 11, ct: 12, 616 obs: 13, 617 DATA 619 MAPPINGS = Hash.new {|h, k| k} 620 RAWMAPPINGS.scan(/([-\w]+)\s*:\s*([-\w]+),/) do |n, v| 621 MAPPINGS[n] = Integer(v) 622 end 624 def self.parse(*args) 625 WLNK.parse(*args) 626 end 628 class WLNK 629 attr_accessor :resources 630 def initialize(r = []) # make sure the keys are strings 631 @resources = r.to_ary # make sure it's an Array 632 end 633 def self.parse(s, robust = true) 634 wl = WLNK.new 635 ss = StringScanner.new(s.as_utf8) 636 ss.skip(/\s+/) if robust 637 while ss.scan(%r{<([^>]+)>}) 638 res = { ANCHORNAME => ss[1].as_utf8 } 639 ss.skip(/\s*/) if robust 640 while ss.skip(/;/) 641 ss.skip(/\s*/) if robust 642 unless ss.scan(SCANATTR) 643 raise ArgumentError, "must have attribute behind ';' 644 at: #{ss.peek(20).inspect} (byte #{ss.pos})" 645 end 646 key = ss[1].as_utf8 647 value = ss[2] || 648 (ss[3] ? ss[3].gsub(/\\(.)/) { $1 } : true) 649 if res[key] 650 res[key] = Array(res[key]) << value 651 else 652 res[key] = value 653 end 654 ss.skip(/\s*/) if robust 655 end 656 wl.resources << res 657 break unless ss.skip(/,/) 658 ss.skip(/\s*/) if robust 659 end 660 ss.skip(/\s*/) if robust 661 raise ArgumentError, "link-format unparseable at: 662 #{ss.peek(20).inspect} (byte #{ss.pos})" unless ss.eos? 663 wl 664 end 665 def to_json 666 JSON.pretty_generate(@resources) 667 end 668 def to_cbor 669 CBOR.encode(@resources.map {|r| 670 Hash[r.map { |k, v| [MAPPINGS[k], v] }]}) 671 end 672 def to_wlnk 673 resources.map do |res| 674 res = res.dup 675 u = res.delete(ANCHORNAME) 676 ["<#{u}>", *res.map do |k, v| 677 if String === v 678 if MUSTBEQUOTED[k] || v !~ /\A#{PTOKENCHAR}+\z/ 679 "#{k}=\"#{v.gsub(/[\\"]/) { |x| "\\#{x}"}}\"" 680 else 681 "#{k}=#{v}" 682 end 683 else 684 "#{k}" 685 end 686 end].join(';') 687 end.join(",") 688 end 689 end 690 end 691 end 693 lf = CoRE::Links.parse(ARGF.read) 695 puts lf.to_json # JSON 696 puts CBOR.pretty(lf.to_cbor) # CBOR "pretty" binary form 697 puts lf.to_wlnk # RFC 6690 link-format 698 # 700 Acknowledgements 702 Special thanks to Bert Greevenbosch who was an author on the initial 703 version of a contributing document as well as the original author on 704 the CDDL notation. 706 Hannes Tschofenig made many helpful suggestions for improving this 707 document. 709 Authors' Addresses 711 Kepeng LI 712 Alibaba Group 713 Wenyixi Road, Yuhang District 714 Hangzhou, Zhejiang 311121 715 China 717 Email: kepeng.lkp@alibaba-inc.com 719 Akbar Rahman 720 InterDigital Communications, LLC 721 1000 Sherbrooke Street West 722 Montreal, Quebec H3A 3G4 723 Canada 725 Phone: +1-514-585-0761 726 Email: akbar.rahman@interdigital.com 728 Carsten Bormann (editor) 729 Universitaet Bremen TZI 730 Postfach 330440 731 Bremen D-28359 732 Germany 734 Phone: +49-421-218-63921 735 Email: cabo@tzi.org