idnits 2.17.1 draft-ietf-cbor-tags-oid-03.txt: -(3): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(531): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 6 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 6 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (17 November 2020) is 1255 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) -- Looks like a reference, but probably isn't: '85' on line 400 -- Looks like a reference, but probably isn't: '4' on line 406 -- Looks like a reference, but probably isn't: '6' on line 406 -- Looks like a reference, but probably isn't: '2' on line 406 -- Looks like a reference, but probably isn't: '5' on line 406 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-cbor-7049bis' ** Downref: Normative reference to an Informational RFC: RFC 6256 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Bormann 3 Internet-Draft Universität Bremen TZI 4 Intended status: Standards Track S. Leonard 5 Expires: 21 May 2021 Penango, Inc. 6 17 November 2020 8 Concise Binary Object Representation (CBOR) Tags for Object Identifiers 9 draft-ietf-cbor-tags-oid-03 11 Abstract 13 The Concise Binary Object Representation (CBOR, draft-ietf-cbor- 14 7049bis) is a data format whose design goals include the possibility 15 of extremely small code size, fairly small message size, and 16 extensibility without the need for version negotiation. 18 The present document defines CBOR tags for object identifiers (OIDs). 19 It is intended as the reference document for the IANA registration of 20 the CBOR tags so defined. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on 21 May 2021. 39 Copyright Notice 41 Copyright (c) 2020 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. Code Components 49 extracted from this document must include Simplified BSD License text 50 as described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Object Identifiers . . . . . . . . . . . . . . . . . . . . . 3 57 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 5. Tag Factoring with OID Arrays and Maps . . . . . . . . . . . 6 60 6. Applications and Examples of OIDs . . . . . . . . . . . . . . 7 61 7. CDDL Control Operators . . . . . . . . . . . . . . . . . . . 9 62 8. CDDL typenames . . . . . . . . . . . . . . . . . . . . . . . 9 63 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 64 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 65 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 66 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 67 11.2. Informative References . . . . . . . . . . . . . . . . . 12 68 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 12 69 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 72 1. Introduction 74 The Concise Binary Object Representation (CBOR, 75 [I-D.ietf-cbor-7049bis]) provides for the interchange of structured 76 data without a requirement for a pre-agreed schema. 77 [I-D.ietf-cbor-7049bis] defines a basic set of data types, as well as 78 a tagging mechanism that enables extending the set of data types 79 supported via an IANA registry. 81 The present document defines CBOR tags for object identifiers (OIDs, 82 [X.660]), which many IETF protocols carry. The ASN.1 Basic Encoding 83 Rules (BER, [X.690]) specify binary encodings of both (absolute) 84 object identifiers and relative object identifiers. The contents of 85 these encodings (the "value" part of BER's type-length-value 86 structure) can be carried in a CBOR byte string. This document 87 defines two CBOR tags that cover the two kinds of ASN.1 object 88 identifiers encoded in this way. The tags can also be applied to 89 arrays and maps to efficiently tag all elements of an array or all 90 keys of a map. It is intended as the reference document for the IANA 91 registration of the tags so defined. 93 1.1. Terminology 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 97 "OPTIONAL" in this document are to be interpreted as described in 98 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 99 capitals, as shown here. 101 The terminology of draft-ietf-cbor-7049bis applies; in particular the 102 term "byte" is used in its now customary sense as a synonym for 103 "octet". 105 2. Object Identifiers 107 The International Object Identifier tree [X.660] is a hierarchically 108 managed space of identifiers, each of which is uniquely represented 109 as a sequence of unsigned integer values [X.680]. (These integer 110 values are called "primary integer values" in X.660 because they can 111 be accompanied by (not necessarily unambiguous) secondary 112 identifiers. We ignore the latter and simply use the term "integer 113 values" here, occasionally calling out their unsignedness.) 115 While these sequences can easily be represented in CBOR arrays of 116 unsigned integers, a more compact representation can often be 117 achieved by adopting the widely used representation of object 118 identifiers defined in BER; this representation may also be more 119 amenable to processing by other software that makes use of object 120 identifiers. 122 BER represents the sequence of unsigned integers by concatenating 123 self-delimiting [RFC6256] representations of each of the integer 124 values in sequence. 126 ASN.1 distinguishes absolute object identifiers (ASN.1 Type "OBJECT 127 IDENTIFIER"), which begin at a root arc ([X.660] Clause 3.5.21), from 128 relative object identifiers (ASN.1 Type "RELATIVE-OID"), which begin 129 relative to some object identifier known from context ([X.680] Clause 130 3.8.63). As a special optimization, BER combines the first two 131 integers in an absolute object identifier into one numeric identifier 132 by making use of the property of the hierarchy that the first arc has 133 only three integer values (0, 1, and 2), and the second arcs under 0 134 and 1 are limited to the integer values between 0 and 39. (The root 135 arc "joint-iso-itu-t(2)" has no such limitations on its second arc.) 136 If X and Y are the first two integer values, the single integer value 137 actually encoded is computed as: 139 X * 40 + Y 141 The inverse transformation (again making use of the known ranges of X 142 and Y) is applied when decoding the object identifier. 144 Since the semantics of absolute and relative object identifiers 145 differ, this specification defines two tags, collectively called the 146 "OID tags" here: 148 Tag TBD111: tags a byte string as the [X.690] encoding of an absolute 149 object identifier (simply "object identifier" or "OID"). 151 Tag TBD110: tags a byte string as the [X.690] encoding of a relative 152 object identifier (also "relative OID"). Since the encoding of each 153 number is the same as for [RFC6256] Self-Delimiting Numeric Values 154 (SDNVs), this tag can also be used for tagging a byte string that 155 contains a sequence of zero or more SDNVs. 157 Tag TBD112: structurally like TBD110, but understood to be relative 158 to "1.3.6.1.4.1" (IANA Private Enterprise Number OID). Hence, the 159 semantics of the result are that of an absolute object identifier. 161 2.1. Requirements on the byte string being tagged 163 To form a valid tag, a byte string tagged by TBD111, TBD110, or 164 TBD112 MUST be a syntactically valid BER representation of an object 165 identifier: A concatenation of zero or more SDNV values, where each 166 SDNV value is a sequence of one or more bytes that all have their 167 most significant bit set, except for the last byte, where it must be 168 unset; the first byte of each SDNV cannot be 0x80 (which would be a 169 leading zero in SDNV's base-128 arithmetic). 171 In other words: 173 * its first byte, and any byte that follows a byte that has the most 174 significant bit unset, MUST NOT be 0x80 (this requirement requires 175 expressing the integer values in their shortest form, with no 176 leading zeroes) 178 * its last byte MUST NOT have the most significant bit set (this 179 requirement excludes an incomplete final integer value) 181 If either of these invalid conditions are encountered, the tag is 182 invalid. 184 [X.680] restricts RELATIVE-OID values to have at least one arc, i.e., 185 their encoding would have at least one SDNV. This specification 186 permits empty relative object identifiers; they may still be excluded 187 by application semantics. 189 To facilitate the search for specific object ID values, it is 190 RECOMMENDED that definite length encoding (see Section 3.2.3 of 191 [I-D.ietf-cbor-7049bis]) is used for the byte strings used as tag 192 content for these tags. 194 The valid set of byte strings can also be expressed using regular 195 expressions on bytes, using no specific notation but resembling 196 [PCRE]. Unlike typical regular expressions that operate on character 197 sequences, the following regular expressions take bytes as their 198 domain, so they can be applied directly to CBOR byte strings. 200 For byte strings with tag TBD111: 202 "/^(([\x81-\xFF][\x80-\xFF]*)?[\x00-\x7F])+$/" 204 For byte strings with tag TBD110 or TBD112: 206 "/^(([\x81-\xFF][\x80-\xFF]*)?[\x00-\x7F])*$/" 208 A tag with tagged content that does not conform to the applicable 209 regexp is invalid. 211 3. Examples 213 3.1. Encoding of the SHA-256 OID 215 ASN.1 Value Notation: { joint-iso-itu-t(2) country(16) us(840) 216 organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 217 sha256(1) } 219 Dotted Decimal Notation: 2.16.840.1.101.3.4.2.1 221 06 # UNIVERSAL TAG 6 222 09 # 9 bytes, primitive 223 60 86 48 01 65 03 04 02 01 # X.690 Clause 8.19 224 # | 840 1 | 3 4 2 1 show component encoding 225 # 2.16 101 227 Figure 1: SHA-256 OID in BER 229 D8 6F # tag(111) 230 49 # 0b010_01001: mt 2, 9 bytes 231 60 86 48 01 65 03 04 02 01 # X.690 Clause 8.19 233 Figure 2: SHA-256 OID in CBOR 235 3.2. Encoding of a MIB Relative OID 237 Given some OID (e.g., "lowpanMib", assumed to be "1.3.6.1.2.1.226" 238 [RFC7388]), to which the following is added: 240 ASN.1 Value Notation: { lowpanObjects(1) lowpanStats(1) 241 lowpanOutTransmits(29) } 243 Dotted Decimal Notation: .1.1.29 245 0D # UNIVERSAL TAG 13 246 03 # 3 bytes, primitive 247 01 01 1D # X.690 Clause 8.20 248 # 1 1 29 show component encoding 250 Figure 3: MIB relative object identifier, in BER 252 D8 6E # tag(110) 253 43 # 0b010_01001: mt 2 (bstr), 3 bytes 254 01 01 1D # X.690 Clause 8.20 256 Figure 4: MIB relative object identifier, in CBOR 258 This relative OID saves seven bytes compared to the full OID 259 encoding. 261 4. Discussion 263 Staying close to the way object identifiers are encoded in ASN.1 BER 264 makes back-and-forth translation easy; otherwise we would choose a 265 more efficient encoding. Object identifiers in IETF protocols are 266 serialized in dotted decimal form or BER form, so there is an 267 advantage in not inventing a third form. Also, expectations of the 268 cost of encoding object identifiers are based on BER; using a 269 different encoding might not be aligned with these expectations. If 270 additional information about an OID is desired, lookup services such 271 as the OID Resolution Service (ORS) [X.672] and the OID Repository 272 [OID-INFO] are available. 274 5. Tag Factoring with OID Arrays and Maps 276 OID tags can tag byte strings (as discussed above), but also CBOR 277 arrays and maps. The idea in the latter case is that the tag is 278 factored out from each individual item in the container; the tag is 279 placed on the array or map instead. 281 When an OID tag is applied to an array, it means that the respective 282 tag is imputed to all elements of the array that are byte strings, 283 arrays, or maps. (There is no effect on other elements, including 284 text strings or tags.) For example, when an array is tagged with 285 TBD111, every array element that is a byte string is an OID, and 286 every element that is an array or map is in turn treated as discussed 287 here. 289 When an OID tag is applied to a map, it means that the respective tag 290 is imputed to all keys in the map that are byte strings, arrays, or 291 maps; again, there is no effect on keys of other major types. Note 292 that there is also no effect on the values in the map. 294 As a result of these rules, tag factoring in nested arrays and maps 295 is supported. For example, a 3-dimensional array of OIDs can be 296 composed by using a single TBD111 tag containing an array of arrays 297 of arrays of byte strings. All such byte strings are then considered 298 OIDs. 300 6. Applications and Examples of OIDs 302 6.1. X.500 Distinguished Name 304 Consider the X.500 distinguished name: 306 +==============================+=============+ 307 | Attribute Types | Attribute | 308 | | Values | 309 +==============================+=============+ 310 | c (2.5.4.6) | US | 311 +------------------------------+-------------+ 312 | l (2.5.4.7) | Los Angeles | 313 | s (2.5.4.8) | CA | 314 | postalCode (2.5.4.17) | 90013 | 315 +------------------------------+-------------+ 316 | street (2.5.4.9) | 532 S Olive | 317 | | St | 318 +------------------------------+-------------+ 319 | businessCategory (2.5.4.15) | Public Park | 320 | buildingName | Pershing | 321 | (0.9.2342.19200300.100.1.48) | Square | 322 +------------------------------+-------------+ 324 Table 1: Example X.500 Distinguished Name 326 Table 1 has four "relative distinguished names" (RDNs). The country 327 and street RDNs are single-valued. The second and fourth RDNs are 328 multi-valued. 330 The equivalent representations in CBOR diagnostic notation and CBOR 331 are: 333 111([{ h'550406': "US" }, 334 { h'550407': "Los Angeles", h'550408': "CA", 335 h'550411': "90013" }, 336 { h'550409': "532 S Olive St" }, 337 { h'55040f': "Public Park", 338 h'0992268993f22c640130': "Pershing Square" }]) 340 Figure 5: Distinguished Name, in CBOR Diagnostic Notation 342 d8 6f # tag(111) 343 84 # array(4) 344 a1 # map(1) 345 43 550406 # 2.5.4.6 (4) 346 62 # text(2) 347 5553 # "US" 348 a3 # map(3) 349 43 550407 # 2.5.4.7 (4) 350 6b # text(11) 351 4c6f7320416e67656c6573 # "Los Angeles" 352 43 550408 # 2.5.4.8 (4) 353 62 # text(2) 354 4341 # "CA" 355 43 550411 # 2.5.4.17 (4) 356 65 # text(5) 357 3930303133 # "90013" 358 a1 # map(1) 359 43 550409 # 2.5.4.9 (4) 360 6e # text(14) 361 3533322053204f6c697665205374 # "532 S Olive St" 362 a2 # map(2) 363 43 55040f # 2.5.4.15 (4) 364 6b # text(11) 365 5075626c6963205061726b # "Public Park" 366 4a 0992268993f22c640130 # 0.9.2342.19200300.100.1.48 (11) 367 6f # text(15) 368 5065727368696e6720537175617265 # "Pershing Square" 370 Figure 6: Distinguished Name, in CBOR (109 bytes) 372 (This example encoding assumes that all attribute values are UTF-8 373 strings, or can be represented as UTF-8 strings with no loss of 374 information.) 376 7. CDDL Control Operators 378 CDDL specifications may want to specify the use of SDNVs or SDNV 379 sequences (as defined for the tag content for TBD110). This document 380 introduces two new control operators that can be applied to a target 381 value that is a byte string: 383 * ".sdnv", with a control type that contains unsigned integers. The 384 byte string is specified to be encoded as an [RFC6256] SDNV (BER 385 encoding) for the matching values of the control type. 387 * ".sdnvseq", with a control type that contains arrays of unsigned 388 integers. The byte string is specified to be encoded as a 389 sequence of [RFC6256] SDNVs (BER encoding) that decodes to an 390 array of unsigned integers matching the control type. 392 * ".oid", like ".sdnvseq", except that the X*40+Y translation for 393 absolute OIDs is included (see Figure 8). 395 Figure 7 shows an example for the use of ".sdnvseq" for a part of a 396 structure using OIDs that could be used in Figure 6; Figure 8 shows 397 the same with the ".oid" operator. 399 country-rdn = {country-oid => country-value} 400 country-oid = bytes .sdnvseq [85, 4, 6] 401 country-value = text .size 2 403 Figure 7: Using .sdnvseq 405 country-rdn = {country-oid => country-value} 406 country-oid = bytes .oid [2, 5, 4, 6] 407 country-value = text .size 2 409 Figure 8: Using .oid 411 Note that the control type need not be a literal; e.g., "bytes .oid 412 [2, 5, 4, *uint]" matches all OIDs inside OID arc 2.5.4, 413 "attributeType". 415 8. CDDL typenames 417 For the use with CDDL [RFC8610], the typenames defined in Figure 9 418 are recommended: 420 oid = #6.111(bstr) 421 roid = #6.110(bstr) 422 pen = #6.112(bstr) 423 Figure 9: Recommended typenames for CDDL 425 9. IANA Considerations 427 9.1. CBOR Tags 429 IANA is requested to assign the CBOR tags in Table 2, with the 430 present document as the specification reference. 432 +========+================+============================+ 433 | Tag | Data Item | Semantics | 434 +========+================+============================+ 435 | TBD111 | byte string or | object identifier (BER | 436 | | array or map | encoding) | 437 +--------+----------------+----------------------------+ 438 | TBD110 | byte string or | relative object identifier | 439 | | array or map | (BER encoding); | 440 | | | SDNV [RFC6256] sequence | 441 +--------+----------------+----------------------------+ 442 | TBD112 | byte string or | object identifier (BER | 443 | | array or map | encoding), relative to | 444 | | | 1.3.6.1.4.1 | 445 +--------+----------------+----------------------------+ 447 Table 2: Values for New Tags 449 9.2. CDDL Control Operators 451 IANA is requested to assign the CDDL Control Operators in Table 3, 452 with the present document as the specification reference. 454 +==========+============================+ 455 | Name | Reference | 456 +==========+============================+ 457 | .sdnv | [this document, Section 7] | 458 +----------+----------------------------+ 459 | .sdnvseq | [this document, Section 7] | 460 +----------+----------------------------+ 461 | .oid | [this document, Section 7] | 462 +----------+----------------------------+ 464 Table 3: New CDDL Operators 466 10. Security Considerations 468 The security considerations of [I-D.ietf-cbor-7049bis] apply. 470 The encodings in Clauses 8.19 and 8.20 of [X.690] are quite compact 471 and unambiguous, but MUST be followed precisely to avoid security 472 pitfalls. In particular, the requirements set out in Section 2.1 of 473 this document need to be followed; otherwise, an attacker may be able 474 to subvert a checking process by submitting alternative 475 representations that are later taken as the original (or even 476 something else entirely) by another decoder supposed to be protected 477 by the checking process. 479 OIDs and relative OIDs can always be treated as opaque byte strings. 480 Actually understanding the structure that was used for generating 481 them is not necessary, and, except for checking the structure 482 requirements, it is strongly NOT RECOMMENDED to perform any 483 processing of this kind (e.g., converting into dotted notation and 484 back) unless absolutely necessary. If the OIDs are translated into 485 other representations, the usual security considerations for non- 486 trivial representation conversions apply; the integer values are 487 unlimited in range. 489 11. References 491 11.1. Normative References 493 [I-D.ietf-cbor-7049bis] 494 Bormann, C. and P. Hoffman, "Concise Binary Object 495 Representation (CBOR)", Work in Progress, Internet-Draft, 496 draft-ietf-cbor-7049bis-16, 30 September 2020, 497 . 500 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 501 Requirement Levels", BCP 14, RFC 2119, 502 DOI 10.17487/RFC2119, March 1997, 503 . 505 [RFC6256] Eddy, W. and E. Davies, "Using Self-Delimiting Numeric 506 Values in Protocols", RFC 6256, DOI 10.17487/RFC6256, May 507 2011, . 509 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 510 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 511 May 2017, . 513 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 514 Definition Language (CDDL): A Notational Convention to 515 Express Concise Binary Object Representation (CBOR) and 516 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 517 June 2019, . 519 [X.660] International Telecommunications Union, "Information 520 technology — Procedures for the operation of object 521 identifier registration authorities: General procedures 522 and top arcs of the international object identifier tree", 523 ITU-T Recommendation X.660, July 2011. 525 [X.680] International Telecommunications Union, "Information 526 technology — Abstract Syntax Notation One (ASN.1): 527 Specification of basic notation", ITU-T Recommendation 528 X.680, August 2015. 530 [X.690] International Telecommunications Union, "Information 531 technology — ASN.1 encoding rules: Specification of Basic 532 Encoding Rules (BER), Canonical Encoding Rules (CER) and 533 Distinguished Encoding Rules (DER)", ITU-T Recommendation 534 X.690, August 2015. 536 11.2. Informative References 538 [OID-INFO] Orange SA, "OID Repository", 2016, 539 . 541 [PCRE] Ho, A., "PCRE - Perl Compatible Regular Expressions", 542 2018, . 544 [RFC7388] Schoenwaelder, J., Sehgal, A., Tsou, T., and C. Zhou, 545 "Definition of Managed Objects for IPv6 over Low-Power 546 Wireless Personal Area Networks (6LoWPANs)", RFC 7388, 547 DOI 10.17487/RFC7388, October 2014, 548 . 550 [X.672] International Telecommunications Union, "Information 551 technology — Open systems interconnection — Object 552 identifier resolution system", ITU-T Recommendation X.672, 553 August 2010. 555 Appendix A. Change Log 557 This section is to be removed before publishing as an RFC. 559 A.1. Changes from -01 to -02 561 Minor editorial changes, remove some remnants, ready for WGLC. 563 A.2. Changes from -00 to -01 565 Clean up OID tag factoring. 567 A.3. Changes from -07 (bormann) to -00 (ietf) 569 Resubmitted as WG draft after adoption. 571 A.4. Changes from -06 to -07 573 Reduce the draft back to its basic mandate: Describe CBOR tags for 574 what is colloquially know as ASN.1 Object IDs. 576 A.5. Changes from -05 to -06 578 Refreshed the draft to the current date ("keep-alive"). 580 A.6. Changes from -04 to -05 582 Discussed UUID usage in CBOR, and incorporated fixes proposed by 583 Olivier Dubuisson, including fixes regarding OID nomenclature. 585 A.7. Changes from -03 to -04 587 Changes occurred based on limited feedback, mainly centered around 588 the abstract and introduction, rather than substantive technical 589 changes. These changes include: 591 * Changed the title so that it is about tags and techniques. 593 * Rewrote the abstract to describe the content more accurately, and 594 to point out that no changes to the wire protocol are being 595 proposed. 597 * Removed "ASN.1" from "object identifiers", as OIDs are independent 598 of ASN.1. 600 * Rewrote the introduction to be more about the present text. 602 * Proposed a concise OID arc. 604 * Provided binary regular expression forms for OID validation. 606 * Updated IANA registration tables. 608 A.8. Changes from -02 to -03 610 Many significant changes occurred in this version. These changes 611 include: 613 * Expanded the draft scope to be a comprehensive CBOR update. 615 * Added OID-related sections: OID Enumerations, OID Maps and Arrays, 616 and Applications and Examples of OIDs. 618 * Added Tag 36 update (binary MIME, better definitions). 620 * Added stub/experimental sections for X.690 Series Tags (tag <>) 621 and Regular Expressions (tag 35). 623 * Added technique for representing sets and multisets. 625 * Added references and fixed typos. 627 Acknowledgments 629 Jim Schaad provided a review of this document. 631 Authors' Addresses 633 Carsten Bormann 634 Universität Bremen TZI 635 Postfach 330440 636 D-28359 Bremen 637 Germany 639 Phone: +49-421-218-63921 640 Email: cabo@tzi.org 642 Sean Leonard 643 Penango, Inc. 644 5900 Wilshire Boulevard 645 21st Floor 646 Los Angeles, CA, 90036 647 United States of America 649 Email: dev+ietf@seantek.com 650 URI: http://www.penango.com/