rfc9090.original   rfc9090.txt 
Network Working Group C. Bormann Internet Engineering Task Force (IETF) C. Bormann
Internet-Draft Universität Bremen TZI Request for Comments: 9090 Universität Bremen TZI
Intended status: Standards Track 21 May 2021 Category: Standards Track July 2021
Expires: 22 November 2021 ISSN: 2070-1721
Concise Binary Object Representation (CBOR) Tags for Object Identifiers Concise Binary Object Representation (CBOR) Tags for Object Identifiers
draft-ietf-cbor-tags-oid-08
Abstract Abstract
The Concise Binary Object Representation (CBOR, RFC 8949) is a data The Concise Binary Object Representation (CBOR), defined in RFC 8949,
format whose design goals include the possibility of extremely small is a data format whose design goals include the possibility of
code size, fairly small message size, and extensibility without the extremely small code size, fairly small message size, and
need for version negotiation. extensibility without the need for version negotiation.
The present document defines CBOR tags for object identifiers (OIDs). This document defines CBOR tags for object identifiers (OIDs) and is
It is intended as the reference document for the IANA registration of the reference document for the IANA registration of the CBOR tags so
the CBOR tags so defined. defined.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 22 November 2021. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9090.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Simplified BSD License text to this document. Code Components extracted from this document must
as described in Section 4.e of the Trust Legal Provisions and are include Simplified BSD License text as described in Section 4.e of
provided without warranty as described in the Simplified BSD License. the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology
2. Object Identifiers . . . . . . . . . . . . . . . . . . . . . 4 2. Object Identifiers
2.1. Requirements on the byte string being tagged . . . . . . 5 2.1. Requirements on the Byte String Being Tagged
2.2. Preferred Serialization Considerations . . . . . . . . . 6 2.2. Preferred Serialization Considerations
2.3. Discussion . . . . . . . . . . . . . . . . . . . . . . . 6 2.3. Discussion
3. Basic Examples . . . . . . . . . . . . . . . . . . . . . . . 7 3. Basic Examples
3.1. Encoding of the SHA-256 OID . . . . . . . . . . . . . . . 7 3.1. Encoding of the SHA-256 OID
3.2. Encoding of a MIB Relative OID . . . . . . . . . . . . . 7 3.2. Encoding of a MIB Relative OID
4. Tag Factoring with Arrays and Maps . . . . . . . . . . . . . 8 4. Tag Factoring with Arrays and Maps
4.1. Preferred Serialization Considerations . . . . . . . . . 8 4.1. Preferred Serialization Considerations
4.2. Tag Factoring Example: X.500 Distinguished Name . . . . . 9 4.2. Tag Factoring Example: X.500 Distinguished Name
5. CDDL Control Operators . . . . . . . . . . . . . . . . . . . 10 5. CDDL Control Operators
6. CDDL typenames . . . . . . . . . . . . . . . . . . . . . . . 11 6. CDDL Type Names
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations
7.1. CBOR Tags . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. CBOR Tags
7.2. CDDL Control Operators . . . . . . . . . . . . . . . . . 12 7.2. CDDL Control Operators
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. References
9.1. Normative References . . . . . . . . . . . . . . . . . . 13 9.1. Normative References
9.2. Informative References . . . . . . . . . . . . . . . . . 14 9.2. Informative References
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 15 Acknowledgments
A.1. Changes from -06 to -07 . . . . . . . . . . . . . . . . . 15 Contributors
A.2. Changes from -05 to -06 . . . . . . . . . . . . . . . . . 15 Author's Address
A.3. Changes from -04 to -05 . . . . . . . . . . . . . . . . . 15
A.4. Changes from -03 to -04 . . . . . . . . . . . . . . . . . 15
A.5. Changes from -02 to -03 . . . . . . . . . . . . . . . . . 15
A.6. Changes from -01 to -02 . . . . . . . . . . . . . . . . . 15
A.7. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 15
A.8. Changes from -07 (bormann) to -00 (ietf) . . . . . . . . 16
A.9. Changes from -06 to -07 . . . . . . . . . . . . . . . . . 16
A.10. Changes from -05 to -06 . . . . . . . . . . . . . . . . . 16
A.11. Changes from -04 to -05 . . . . . . . . . . . . . . . . . 16
A.12. Changes from -03 to -04 . . . . . . . . . . . . . . . . . 16
A.13. Changes from -02 to -03 . . . . . . . . . . . . . . . . . 16
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
The Concise Binary Object Representation (CBOR, [RFC8949]) provides The Concise Binary Object Representation (CBOR) [RFC8949] provides
for the interchange of structured data without a requirement for a for the interchange of structured data without a requirement for a
pre-agreed schema. [RFC8949] defines a basic set of data types, as pre-agreed schema. [RFC8949] defines a basic set of data types, as
well as a tagging mechanism that enables extending the set of data well as a tagging mechanism that enables extending the set of data
types supported via an IANA registry. types supported via an IANA registry.
The present document defines CBOR tags for object identifiers (OIDs, This document defines CBOR tags for object identifiers (OIDs)
[X.660]), which many IETF protocols carry. The ASN.1 Basic Encoding [X.660], which many IETF protocols carry. The ASN.1 Basic Encoding
Rules (BER, [X.690]) specify binary encodings of both (absolute) Rules (BER) [X.690] specify binary encodings of both (absolute)
object identifiers and relative object identifiers. The contents of object identifiers and relative object identifiers. The contents of
these encodings (the "value" part of BER's type-length-value these encodings (the "value" part of BER's type-length-value
structure) can be carried in a CBOR byte string. This document structure) can be carried in a CBOR byte string. This document
defines two CBOR tags that cover the two kinds of ASN.1 object defines two CBOR tags that cover the two kinds of ASN.1 object
identifiers encoded in this way, and a third one to enable a common identifiers encoded in this way and a third one to enable a common
optimization. The tags can also be applied to arrays and maps to optimization. The tags can also be applied to arrays and maps to
efficiently tag all elements of an array or all keys of a map. It is efficiently tag all elements of an array or all keys of a map. This
intended as the reference document for the IANA registration of the document is the reference document for the IANA registration of the
tags so defined. tags so defined.
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
The terminology of [RFC8949] applies; in particular the term "byte" The terminology of [RFC8949] applies; in particular, the term "byte"
is used in its now customary sense as a synonym for "octet". The is used in its now-customary sense as a synonym for "octet". The
verb "to tag (something)" is used to express the construction of a verb "to tag (something)" is used to express the construction of a
CBOR tag with the object (something) as the tag content and a tag CBOR tag, with the object (something) as the tag content and a tag
number indicated elsewhere in the sentence (for instance in a "with" number indicated elsewhere in the sentence (for instance, in a "with"
clause, or by the shorthand "an NNN tag" for "a tag with tag number clause or by the shorthand "an NNN tag" for "a tag with tag number
NNN"). The term "SDNV" (Self-Delimiting Numeric Value) is used as NNN"). The term "SDNV" (Self-Delimiting Numeric Value) is used as
defined in [RFC6256], with the additional restriction detailed in defined in [RFC6256], with the additional restriction detailed in
Section 2.1 (no leading zeros). Section 2.1 (no leading zeros).
2. Object Identifiers 2. Object Identifiers
The International Object Identifier tree [X.660] is a hierarchically The International Object Identifier tree [X.660] is a hierarchically
managed space of identifiers, each of which is uniquely represented managed space of identifiers, each of which is uniquely represented
as a sequence of unsigned integer values [X.680]. (These integer as a sequence of unsigned integer values [X.680]. (These integer
values are called "primary integer values" in X.660 because they can values are called "primary integer values" in [X.660] because they
be accompanied by (not necessarily unambiguous) secondary can be accompanied by (not necessarily unambiguous) secondary
identifiers. We ignore the latter and simply use the term "integer identifiers. We ignore the latter and simply use the term "integer
values" here, occasionally calling out their unsignedness. We also values" here, occasionally calling out their unsignedness. We also
use the term "arc" when the focus is on the edge of the tree labeled use the term "arc" when the focus is on the edge of the tree labeled
by such an integer value, as well as in the sense of a "long arc", by such an integer value, as well as in the sense of a "long arc",
i.e., a (sub)sequence of such integer values.) i.e., a (sub)sequence of such integer values.)
While these sequences can easily be represented in CBOR arrays of While these sequences can easily be represented in CBOR arrays of
unsigned integers, a more compact representation can often be unsigned integers, a more compact representation can often be
achieved by adopting the widely used representation of object achieved by adopting the widely used representation of object
identifiers defined in BER; this representation may also be more identifiers defined in BER; this representation may also be more
amenable to processing by other software that makes use of object amenable to processing by other software that makes use of object
identifiers. identifiers.
BER represents the sequence of unsigned integers by concatenating BER represents the sequence of unsigned integers by concatenating
self-delimiting [RFC6256] representations of each of the integer self-delimiting representations [RFC6256] of each of the integer
values in sequence. values in sequence.
ASN.1 distinguishes absolute object identifiers (ASN.1 Type "OBJECT ASN.1 distinguishes absolute object identifiers (ASN.1 type "OBJECT
IDENTIFIER"), which begin at a root arc ([X.660] Clause 3.5.21), from IDENTIFIER"), which begin at a root arc ([X.660], Clause 3.5.21),
relative object identifiers (ASN.1 Type "RELATIVE-OID"), which begin from relative object identifiers (ASN.1 type "RELATIVE-OID"), which
relative to some object identifier known from context ([X.680] Clause begin relative to some object identifier known from context ([X.680],
3.8.63). As a special optimization, BER combines the first two Clause 3.8.63). As a special optimization, BER combines the first
integers in an absolute object identifier into one numeric identifier two integers in an absolute object identifier into one numeric
by making use of the property of the hierarchy that the first arc has identifier by making use of the property of the hierarchy that the
only three integer values (0, 1, and 2), and the second arcs under 0 first arc has only three integer values (0, 1, and 2) and the second
and 1 are limited to the integer values between 0 and 39. (The root arcs under 0 and 1 are limited to the integer values between 0 and
arc "joint-iso-itu-t(2)" has no such limitations on its second arc.) 39. (The root arc "joint-iso-itu-t(2)" has no such limitations on
If X and Y are the first two integer values, the single integer value its second arc.) If X and Y are the first two integer values, the
actually encoded is computed as: single integer value actually encoded is computed as:
X * 40 + Y X * 40 + Y
The inverse transformation (again making use of the known ranges of X The inverse transformation (again making use of the known ranges of X
and Y) is applied when decoding the object identifier. and Y) is applied when decoding the object identifier.
Since the semantics of absolute and relative object identifiers Since the semantics of absolute and relative object identifiers
differ, and it is very common for companies to use self-assigned differ and since it is very common for companies to use self-assigned
numbers under the arc "1.3.6.1.4.1" (IANA Private Enterprise Number numbers under the arc "1.3.6.1.4.1" (IANA Private Enterprise Number
OID, [IANA.enterprise-numbers]) that adds 5 fixed bytes to an encoded OID [IANA.enterprise-numbers]) that adds 5 fixed bytes to an encoded
OID value, this specification defines three tags, collectively called OID value, this specification defines three tags, collectively called
the "OID tags" here: the "OID tags" here:
Tag number TBD111: used to tag a byte string as the [X.690] encoding Tag number 111: Used to tag a byte string as the BER encoding
of an absolute object identifier (simply "object identifier" or [X.690] of an absolute object identifier (simply "object
"OID"). identifier" or "OID").
Tag number TBD110: used to tag a byte string as the [X.690] encoding Tag number 110: Used to tag a byte string as the BER encoding
of a relative object identifier (also "relative OID"). Since the [X.690] of a relative object identifier (also called "relative
encoding of each number is the same as for [RFC6256] Self-Delimiting OID"). Since the encoding of each number is the same as for Self-
Numeric Values (SDNVs), this tag can also be used for tagging a byte Delimiting Numeric Values (SDNVs) [RFC6256], this tag can also be
string that contains a sequence of zero or more SDNVs (or a more used for tagging a byte string that contains a sequence of zero or
application-specific tag can be created for such an application). more SDNVs (or a more application-specific tag can be created for
such an application).
Tag TBD112: structurally like TBD110, but understood to be relative Tag number 112: Structurally like tag 110 but understood to be
to "1.3.6.1.4.1" (IANA Private Enterprise Number OID, relative to "1.3.6.1.4.1" (IANA Private Enterprise Number OID
[IANA.enterprise-numbers]). Hence, the semantics of the result are [IANA.enterprise-numbers]). Hence, the semantics of the result
that of an absolute object identifier. are that of an absolute object identifier.
2.1. Requirements on the byte string being tagged 2.1. Requirements on the Byte String Being Tagged
To form a valid tag, a byte string tagged with TBD111, TBD110, or To form a valid tag, a byte string tagged with 111, 110, or 112 MUST
TBD112 MUST be syntactically valid contents (the value part) for a be syntactically valid contents (the value part) for a BER
BER representation of an object identifier (Sections 8.19, 8.20, and representation of an object identifier (see Table 1):
8.20 of [X.690], respectively): A concatenation of zero or more SDNV
values, where each SDNV value is a sequence of one or more bytes that +============+====================+
all have their most significant bit set, except for the last byte, | Tag number | Section of [X.690] |
where it is unset. Also, the first byte of each SDNV cannot be a +============+====================+
leading zero in SDNV's base-128 arithmetic, so it cannot take the | 111 | 8.19 |
value 0x80 (bullet (c) in Section 8.1.2.4.2 of [X.690]). +------------+--------------------+
| 110 | 8.20 |
+------------+--------------------+
| 112 | 8.20 |
+------------+--------------------+
Table 1: Tag Number and
Section of X.690 Governing Tag
Content
This is a concatenation of zero or more SDNV values, where each SDNV
value is a sequence of one or more bytes that all have their most
significant bit set, except for the last byte, where it is unset.
Also, the first byte of each SDNV cannot be a leading zero in SDNV's
base-128 arithmetic, so it cannot take the value 0x80 (bullet (c) in
Section 8.1.2.4.2 of [X.690]).
In other words: In other words:
* the byte string's first byte, and any byte that follows a byte * The byte string's first byte, and any byte that follows a byte
that has the most significant bit unset, MUST NOT be 0x80 (this that has the most significant bit unset, MUST NOT be 0x80 (this
requirement requires expressing the integer values in their requirement requires expressing the integer values in their
shortest form, with no leading zeroes) shortest form, with no leading zeroes).
* the byte string's last byte MUST NOT have the most significant bit * The byte string's last byte MUST NOT have the most significant bit
set (this requirement excludes an incomplete final integer value) set (this requirement excludes an incomplete final integer value).
If either of these invalid conditions are encountered, the tag is If either of these invalid conditions are encountered, the tag is
invalid. invalid.
[X.680] restricts RELATIVE-OID values to have at least one arc, i.e., [X.680] restricts RELATIVE-OID values to having at least one arc,
their encoding would have at least one SDNV. This specification i.e., their encoding would have at least one SDNV. This
permits empty relative object identifiers; they may still be excluded specification permits empty relative object identifiers; they may
by application semantics. still be excluded by application semantics.
To facilitate the search for specific object ID values, it is To facilitate the search for specific object ID values, it is
RECOMMENDED that definite length encoding (see Section 3.2.3 of RECOMMENDED that definite length encoding (see Section 3.2.3 of
[RFC8949]) is used for the byte strings used as tag content for these [RFC8949]) be used for the byte strings that are used as tag content
tags. for these tags.
The valid set of byte strings can also be expressed using regular The valid set of byte strings can also be expressed using regular
expressions on bytes, using no specific notation but resembling expressions on bytes, using no specific notation but resembling Perl
[PCRE]. Unlike typical regular expressions that operate on character Compatible Regular Expressions [PCRE]. Unlike typical regular
sequences, the following regular expressions take bytes as their expressions that operate on character sequences, the following
domain, so they can be applied directly to CBOR byte strings. regular expressions take bytes as their domain, so they can be
applied directly to CBOR byte strings.
For byte strings with tag TBD111: For byte strings with tag 111:
"/^(([\x81-\xFF][\x80-\xFF]*)?[\x00-\x7F])+$/" "/^(([\x81-\xFF][\x80-\xFF]*)?[\x00-\x7F])+$/"
For byte strings with tag TBD110 or TBD112: For byte strings with tags 110 or 112:
"/^(([\x81-\xFF][\x80-\xFF]*)?[\x00-\x7F])*$/" "/^(([\x81-\xFF][\x80-\xFF]*)?[\x00-\x7F])*$/"
A tag with tagged content that does not conform to the applicable A tag with tagged content that does not conform to the applicable
regular expression is invalid. regular expression is invalid.
2.2. Preferred Serialization Considerations 2.2. Preferred Serialization Considerations
For an absolute OID with a prefix of "1.3.6.1.4.1", representations For an absolute OID with a prefix of "1.3.6.1.4.1", representations
with both the TBD111 and TBD112 tags are applicable, where the with both the 111 and 112 tags are applicable, where the
representation with TBD112 will be five bytes shorter (by leaving out representation with 112 will be five bytes shorter (by leaving out
the prefix h'2b06010401' from the enclosed byte string). This the prefix h'2b06010401' from the enclosed byte string). This
specification makes that shorter representation the preferred specification makes that shorter representation the preferred
serialization (see Sections 3.4 and 4.1 of [RFC8949]). Note that serialization (see Sections 3.4 and 4.1 of [RFC8949]). Note that
this also implies that the Core Deterministic Encoding Requirements this also implies that the Core Deterministic Encoding Requirements
(Section 4.2.1 of [RFC8949]) require the use of TBD112 tags instead (Section 4.2.1 of [RFC8949]) require the use of 112 tags instead of
of TBD111 wherever that is possible. 111 tags wherever that is possible.
2.3. Discussion 2.3. Discussion
Staying close to the way object identifiers are encoded in ASN.1 BER Staying close to the way object identifiers are encoded in ASN.1 BER
makes back-and-forth translation easy; otherwise we would choose a makes back-and-forth translation easy; otherwise, we would choose a
more efficient encoding. Object identifiers in IETF protocols are more efficient encoding. Object identifiers in IETF protocols are
serialized in dotted decimal form or BER form, so there is an serialized in dotted decimal form or BER form, so there is an
advantage in not inventing a third form. Also, expectations of the advantage in not inventing a third form. Also, expectations of the
cost of encoding object identifiers are based on BER; using a cost of encoding object identifiers are based on BER; using a
different encoding might not be aligned with these expectations. If different encoding might not be aligned with these expectations. If
additional information about an OID is desired, lookup services such additional information about an OID is desired, lookup services such
as the OID Resolution Service (ORS) [X.672] and the OID Repository as the OID Resolution Service (ORS) [X.672] and the OID Repository
[OID-INFO] are available. [OID-INFO] are available.
3. Basic Examples 3. Basic Examples
This section gives simple examples of an absolute and a relative This section gives simple examples of an absolute and a relative
object identifier, represented via tag number TBD111 and TBD110, object identifier, represented via tag numbers 111 and 110,
respectively. respectively.
RFC editor: These and other examples assume the allocation of 111 for
TBD111 and 110 for TBD110 and need to be changed if that isn't the
actual allocation. Please remove this paragraph.
3.1. Encoding of the SHA-256 OID 3.1. Encoding of the SHA-256 OID
ASN.1 Value Notation: { joint-iso-itu-t(2) country(16) us(840) ASN.1 Value Notation:
organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
sha256(1) } csor(3) nistalgorithm(4) hashalgs(2) sha256(1) }
Dotted Decimal Notation: 2.16.840.1.101.3.4.2.1 Dotted Decimal Notation: 2.16.840.1.101.3.4.2.1
06 # UNIVERSAL TAG 6 06 # UNIVERSAL TAG 6
09 # 9 bytes, primitive 09 # 9 bytes, primitive
60 86 48 01 65 03 04 02 01 # X.690 Clause 8.19 60 86 48 01 65 03 04 02 01 # X.690 Clause 8.19
# | 840 1 | 3 4 2 1 show component encoding # | 840 1 | 3 4 2 1 show component encoding
# 2.16 101 # 2.16 101
Figure 1: SHA-256 OID in BER Figure 1: SHA-256 OID in BER
skipping to change at page 7, line 42 skipping to change at line 307
49 # 0b010_01001: mt 2, 9 bytes 49 # 0b010_01001: mt 2, 9 bytes
60 86 48 01 65 03 04 02 01 # X.690 Clause 8.19 60 86 48 01 65 03 04 02 01 # X.690 Clause 8.19
Figure 2: SHA-256 OID in CBOR Figure 2: SHA-256 OID in CBOR
3.2. Encoding of a MIB Relative OID 3.2. Encoding of a MIB Relative OID
Given some OID (e.g., "lowpanMib", assumed to be "1.3.6.1.2.1.226" Given some OID (e.g., "lowpanMib", assumed to be "1.3.6.1.2.1.226"
[RFC7388]), to which the following is added: [RFC7388]), to which the following is added:
ASN.1 Value Notation: { lowpanObjects(1) lowpanStats(1) ASN.1 Value Notation:
lowpanOutTransmits(29) } { lowpanObjects(1) lowpanStats(1) lowpanOutTransmits(29) }
Dotted Decimal Notation: .1.1.29 Dotted Decimal Notation: .1.1.29
0D # UNIVERSAL TAG 13 0D # UNIVERSAL TAG 13
03 # 3 bytes, primitive 03 # 3 bytes, primitive
01 01 1D # X.690 Clause 8.20 01 01 1D # X.690 Clause 8.20
# 1 1 29 show component encoding # 1 1 29 show component encoding
Figure 3: MIB relative object identifier, in BER Figure 3: MIB Relative Object Identifier in BER
D8 6E # tag(110) D8 6E # tag(110)
43 # 0b010_00011: mt 2 (bstr), 3 bytes 43 # 0b010_00011: mt 2 (bstr), 3 bytes
01 01 1D # X.690 Clause 8.20 01 01 1D # X.690 Clause 8.20
Figure 4: MIB relative object identifier, in CBOR Figure 4: MIB Relative Object Identifier in CBOR
This relative OID saves seven bytes compared to the full OID This relative OID saves seven bytes compared to the full OID
encoding. encoding.
4. Tag Factoring with Arrays and Maps 4. Tag Factoring with Arrays and Maps
The tag content of OID tags can be byte strings (as discussed above), The tag content of OID tags can be byte strings (as discussed above)
but also CBOR arrays and maps. The idea in the latter case is that but also CBOR arrays and maps. The idea in the latter case is that
the tag construct is factored out from each individual item in the the tag construct is factored out from each individual item in the
container; the tag is placed on the array or map instead. container; the tag is placed on the array or map instead.
When the tag content of an OID tag is an array, this means that the When the tag content of an OID tag is an array, this means that the
respective tag is imputed to all elements of the array that are byte respective tag is imputed to all elements of the array that are byte
strings, arrays, or maps. (There is no effect on other elements, strings, arrays, or maps. (There is no effect on other elements,
including text strings or tags.) For example, when the tag content including text strings or tags.) For example, when the tag content
of a TBD111 tag is an array, every array element that is a byte of a 111 tag is an array, every array element that is a byte string
string is an OID, and every element that is an array or map is in is an OID, and every element that is an array or map is, in turn,
turn treated as discussed here. treated as discussed here.
When the tag content of an OID tag is a map, this means that a tag When the tag content of an OID tag is a map, this means that a tag
with the same tag number is imputed to all keys in the map that are with the same tag number is imputed to all keys in the map that are
byte strings, arrays, or maps; again, there is no effect on keys of byte strings, arrays, or maps; again, there is no effect on keys of
other major types. Note that there is also no effect on the values other major types. Note that there is also no effect on the values
in the map. in the map.
As a result of these rules, tag factoring in nested arrays and maps As a result of these rules, tag factoring in nested arrays and maps
is supported. For example, a 3-dimensional array of OIDs can be is supported. For example, a 3-dimensional array of OIDs can be
composed by using a single TBD111 tag containing an array of arrays composed by using a single 111 tag containing an array of arrays of
of arrays of byte strings. All such byte strings are then considered arrays of byte strings. All such byte strings are then considered
OIDs. OIDs.
4.1. Preferred Serialization Considerations 4.1. Preferred Serialization Considerations
Where tag factoring with tag number TBD111 is used, some OIDs Where tag factoring with tag number 111 is used, some OIDs enclosed
enclosed in the tag may be encoded in a shorter way by using tag in the tag may be encoded in a shorter way by using tag number 112
number TBD112 instead of encoding an unadorned byte string. This instead of encoding an unadorned byte string. This remains the
remains the preferred serialization (see also Section 2.2). However, preferred serialization (see also Section 2.2). However, this
this specification does not make the presence or absence of tag specification does not make the presence or absence of tag factoring
factoring a preferred serialization; application protocols can define a preferred serialization; application protocols can define where tag
where tag factoring is to be used or not (and will need to do so if factoring is to be used or not (and will need to do so if they have
they have deterministic encoding requirements). deterministic encoding requirements).
4.2. Tag Factoring Example: X.500 Distinguished Name 4.2. Tag Factoring Example: X.500 Distinguished Name
Consider the X.500 distinguished name: Consider the X.500 distinguished name:
+==============================+=============+ +==============================+=============+
| Attribute Types | Attribute | | Attribute Types | Attribute |
| | Values | | | Values |
+==============================+=============+ +==============================+=============+
| c (2.5.4.6) | US | | c (2.5.4.6) | US |
skipping to change at page 9, line 27 skipping to change at line 388
| postalCode (2.5.4.17) | 90013 | | postalCode (2.5.4.17) | 90013 |
+------------------------------+-------------+ +------------------------------+-------------+
| street (2.5.4.9) | 532 S Olive | | street (2.5.4.9) | 532 S Olive |
| | St | | | St |
+------------------------------+-------------+ +------------------------------+-------------+
| businessCategory (2.5.4.15) | Public Park | | businessCategory (2.5.4.15) | Public Park |
| buildingName | Pershing | | buildingName | Pershing |
| (0.9.2342.19200300.100.1.48) | Square | | (0.9.2342.19200300.100.1.48) | Square |
+------------------------------+-------------+ +------------------------------+-------------+
Table 1: Example X.500 Distinguished Name Table 2: Example X.500 Distinguished Name
Table 1 has four "relative distinguished names" (RDNs). The country Table 2 has four "relative distinguished names" (RDNs). The country
(first) and street (third) RDNs are single-valued. The second and (first) and street (third) RDNs are single valued. The second and
fourth RDNs are multi-valued. fourth RDNs are multivalued.
The equivalent representations in CBOR diagnostic notation (Section 8 The equivalent representations in CBOR diagnostic notation (Section 8
of [RFC8949]) and CBOR are: of [RFC8949]) and CBOR are:
111([{ h'550406': "US" }, 111([{ h'550406': "US" },
{ h'550407': "Los Angeles", { h'550407': "Los Angeles",
h'550408': "CA", h'550408': "CA",
h'550411': "90013" }, h'550411': "90013" },
{ h'550409': "532 S Olive St" }, { h'550409': "532 S Olive St" },
{ h'55040f': "Public Park", { h'55040f': "Public Park",
h'0992268993f22c640130': "Pershing Square" }]) h'0992268993f22c640130': "Pershing Square" }])
Figure 5: Distinguished Name, in CBOR Diagnostic Notation Figure 5: Distinguished Name in CBOR Diagnostic Notation
d8 6f # tag(111) d8 6f # tag(111)
84 # array(4) 84 # array(4)
a1 # map(1) a1 # map(1)
43 550406 # 2.5.4.6 (4) 43 550406 # 2.5.4.6 (4)
62 # text(2) 62 # text(2)
5553 # "US" 5553 # "US"
a3 # map(3) a3 # map(3)
43 550407 # 2.5.4.7 (4) 43 550407 # 2.5.4.7 (4)
6b # text(11) 6b # text(11)
skipping to change at page 10, line 33 skipping to change at line 435
6e # text(14) 6e # text(14)
3533322053204f6c697665205374 # "532 S Olive St" 3533322053204f6c697665205374 # "532 S Olive St"
a2 # map(2) a2 # map(2)
43 55040f # 2.5.4.15 (4) 43 55040f # 2.5.4.15 (4)
6b # text(11) 6b # text(11)
5075626c6963205061726b # "Public Park" 5075626c6963205061726b # "Public Park"
4a 0992268993f22c640130 # 0.9.2342.19200300.100.1.48 (11) 4a 0992268993f22c640130 # 0.9.2342.19200300.100.1.48 (11)
6f # text(15) 6f # text(15)
5065727368696e6720537175617265 # "Pershing Square" 5065727368696e6720537175617265 # "Pershing Square"
Figure 6: Distinguished Name, in CBOR (109 bytes) Figure 6: Distinguished Name in CBOR (109 Bytes)
(This example encoding assumes that all attribute values are UTF-8 (This example encoding assumes that all attribute values are UTF-8
strings, or can be represented as UTF-8 strings with no loss of strings or can be represented as UTF-8 strings with no loss of
information.) information.)
5. CDDL Control Operators 5. CDDL Control Operators
Concise Data Definition Language (CDDL [RFC8610]) specifications may Concise Data Definition Language (CDDL) specifications [RFC8610] may
want to specify the use of SDNVs or SDNV sequences (as defined for want to specify the use of SDNVs or SDNV sequences (as defined for
the tag content for TBD110). This document introduces two new the tag content for tag 110). This document introduces two new
control operators that can be applied to a target value that is a control operators that can be applied to a target value that is a
byte string: byte string:
* ".sdnv", with a control type that contains unsigned integers. The * ".sdnv", with a control type that contains unsigned integers. The
byte string is specified to be encoded as an [RFC6256] SDNV (BER byte string is specified to be encoded as an SDNV (BER encoding)
encoding) for the matching values of the control type. [RFC6256] for the matching values of the control type.
* ".sdnvseq", with a control type that contains arrays of unsigned * ".sdnvseq", with a control type that contains arrays of unsigned
integers. The byte string is specified to be encoded as a integers. The byte string is specified to be encoded as a
sequence of [RFC6256] SDNVs (BER encoding) that decodes to an sequence of SDNVs (BER encoding) [RFC6256] that decodes to an
array of unsigned integers matching the control type. array of unsigned integers matching the control type.
* ".oid", like ".sdnvseq", except that the X*40+Y translation for * ".oid", like ".sdnvseq", except that the X*40+Y translation for
absolute OIDs is included (see Figure 8). absolute OIDs is included (see Figure 8).
Figure 7 shows an example for the use of ".sdnvseq" for a part of a Figure 7 shows an example for the use of ".sdnvseq" for a part of a
structure using OIDs that could be used in Figure 6; Figure 8 shows structure using OIDs that could be used in Figure 6; Figure 8 shows
the same with the ".oid" operator. the same with the ".oid" operator.
country-rdn = {country-oid => country-value} country-rdn = {country-oid => country-value}
skipping to change at page 11, line 29 skipping to change at line 477
country-value = text .size 2 country-value = text .size 2
Figure 7: Using .sdnvseq Figure 7: Using .sdnvseq
country-rdn = {country-oid => country-value} country-rdn = {country-oid => country-value}
country-oid = bytes .oid [2, 5, 4, 6] country-oid = bytes .oid [2, 5, 4, 6]
country-value = text .size 2 country-value = text .size 2
Figure 8: Using .oid Figure 8: Using .oid
Note that the control type need not be a literal; e.g., "bytes .oid Note that the control type need not be a literal; for example, "bytes
[2, 5, 4, *uint]" matches all OIDs inside OID arc 2.5.4, .oid [2, 5, 4, *uint]" matches all OIDs inside OID arc "2.5.4",
"attributeType". "attributeType".
6. CDDL typenames 6. CDDL Type Names
For the use with CDDL, the typenames defined in Figure 9 are For the use with CDDL, the type names defined in Figure 9 are
recommended: recommended:
oid = #6.111(bstr) oid = #6.111(bstr)
roid = #6.110(bstr) roid = #6.110(bstr)
pen = #6.112(bstr) pen = #6.112(bstr)
Figure 9: Recommended typenames for CDDL Figure 9: Recommended Type Names for CDDL
7. IANA Considerations 7. IANA Considerations
7.1. CBOR Tags 7.1. CBOR Tags
IANA is requested to assign in the 1+1 byte space (24..255) of the IANA has assigned the CBOR tag numbers in Table 3 in the 1+1 byte
CBOR tags registry [IANA.cbor-tags] the CBOR tag numbers in Table 2, space (24..255) of the "CBOR Tags" registry [IANA.cbor-tags], with
with the present document as the specification reference. this document as the specification reference.
+========+================+============================+============+ +=====+===============+============================+===========+
| Tag | Data Item | Semantics | Reference | | Tag | Data Item | Semantics | Reference |
+========+================+============================+============+ +=====+===============+============================+===========+
| TBD111 | byte string | object identifier (BER | [this | | 111 | byte string, | object identifier (BER | RFC 9090 |
| | or array or | encoding) | document, | | | array, or map | encoding) | |
| | map | | Section 2] | +-----+---------------+----------------------------+-----------+
+--------+----------------+----------------------------+------------+ | 110 | byte string, | relative object identifier | RFC 9090 |
| TBD110 | byte string | relative object identifier | [this | | | array, or map | (BER encoding); SDNV | |
| | or array or | (BER encoding); | document, | | | | [RFC6256] sequence | |
| | map | SDNV [RFC6256] sequence | Section 2] | +-----+---------------+----------------------------+-----------+
+--------+----------------+----------------------------+------------+ | 112 | byte string, | object identifier (BER | RFC 9090 |
| TBD112 | byte string | object identifier (BER | [this | | | array, or map | encoding), relative to | |
| | or array or | encoding), relative to | document, | | | | 1.3.6.1.4.1 | |
| | map | 1.3.6.1.4.1 | Section 2] | +-----+---------------+----------------------------+-----------+
+--------+----------------+----------------------------+------------+
Table 2: New Tag Numbers Table 3: New Tag Numbers
7.2. CDDL Control Operators 7.2. CDDL Control Operators
IANA is requested to assign in the CDDL Control Operators registry IANA has assigned the CDDL control operators in Table 4 in the "CDDL
[IANA.cddl] the CDDL Control Operators in Table 3, with the present Control Operators" registry [IANA.cddl], with this document as the
document as the specification reference. specification reference.
+==========+============================+ +==========+===========+
| Name | Reference | | Name | Reference |
+==========+============================+ +==========+===========+
| .sdnv | [this document, Section 5] | | .sdnv | RFC 9090 |
+----------+----------------------------+ +----------+-----------+
| .sdnvseq | [this document, Section 5] | | .sdnvseq | RFC 9090 |
+----------+----------------------------+ +----------+-----------+
| .oid | [this document, Section 5] | | .oid | RFC 9090 |
+----------+----------------------------+ +----------+-----------+
Table 3: New CDDL Operators Table 4: New CDDL
Control Operators
8. Security Considerations 8. Security Considerations
The security considerations of [RFC8949] apply. The security considerations of [RFC8949] apply.
The encodings in Clauses 8.19 and 8.20 of [X.690] are quite compact The encodings in Clauses 8.19 and 8.20 of [X.690] are quite compact
and unambiguous, but MUST be followed precisely to avoid security and unambiguous but MUST be followed precisely to avoid security
pitfalls. In particular, the requirements set out in Section 2.1 of pitfalls. In particular, the requirements set out in Section 2.1 of
this document need to be followed; otherwise, an attacker may be able this document need to be followed; otherwise, an attacker may be able
to subvert a checking process by submitting alternative to subvert a checking process by submitting alternative
representations that are later taken as the original (or even representations that are later taken as the original (or even
something else entirely) by another decoder supposed to be protected something else entirely) by another decoder that is intended to be
by the checking process. protected by the checking process.
OIDs and relative OIDs can always be treated as opaque byte strings. OIDs and relative OIDs can always be treated as opaque byte strings.
Actually understanding the structure that was used for generating Actually understanding the structure that was used for generating
them is not necessary, and, except for checking the structure them is not necessary, and, except for checking the structure
requirements, it is strongly NOT RECOMMENDED to perform any requirements, it is strongly NOT RECOMMENDED to perform any
processing of this kind (e.g., converting into dotted notation and processing of this kind (e.g., converting into dotted notation and
back) unless absolutely necessary. If the OIDs are translated into back) unless absolutely necessary. If the OIDs are translated into
other representations, the usual security considerations for non- other representations, the usual security considerations for non-
trivial representation conversions apply; the integer values are trivial representation conversions apply; the integer values are
unlimited in range. unlimited in range.
skipping to change at page 13, line 28 skipping to change at line 572
may cause the application to emit data with semantics different from may cause the application to emit data with semantics different from
what was intended. Applications therefore need to be restrictive what was intended. Applications therefore need to be restrictive
with respect to what data items they apply tag factoring to. with respect to what data items they apply tag factoring to.
9. References 9. References
9.1. Normative References 9.1. Normative References
[IANA.cbor-tags] [IANA.cbor-tags]
IANA, "Concise Binary Object Representation (CBOR) Tags", IANA, "Concise Binary Object Representation (CBOR) Tags",
<http://www.iana.org/assignments/cbor-tags>. <https://www.iana.org/assignments/cbor-tags>.
[IANA.cddl] [IANA.cddl]
IANA, "Concise Data Definition Language (CDDL)", IANA, "Concise Data Definition Language (CDDL)",
<http://www.iana.org/assignments/cddl>. <https://www.iana.org/assignments/cddl>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC6256] Eddy, W. and E. Davies, "Using Self-Delimiting Numeric [RFC6256] Eddy, W. and E. Davies, "Using Self-Delimiting Numeric
Values in Protocols", RFC 6256, DOI 10.17487/RFC6256, May Values in Protocols", RFC 6256, DOI 10.17487/RFC6256, May
2011, <https://www.rfc-editor.org/info/rfc6256>. 2011, <https://www.rfc-editor.org/info/rfc6256>.
skipping to change at page 14, line 10 skipping to change at line 602
Definition Language (CDDL): A Notational Convention to Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/info/rfc8610>. June 2019, <https://www.rfc-editor.org/info/rfc8610>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949, Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020, DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>. <https://www.rfc-editor.org/info/rfc8949>.
[X.660] International Telecommunications Union, "Information [X.660] ITU-T, "Information technology - Procedures for the
technology — Procedures for the operation of object operation of object identifier registration authorities:
identifier registration authorities: General procedures General procedures and top arcs of the international
and top arcs of the international object identifier tree", object identifier tree", ITU-T Recommendation X.660, July
ITU-T Recommendation X.660, July 2011, 2011, <https://www.itu.int/rec/T-REC-X.660>.
<https://www.itu.int/rec/T-REC-X.660>.
[X.680] International Telecommunications Union, "Information [X.680] ITU-T, "Information technology - Abstract Syntax Notation
technology — Abstract Syntax Notation One (ASN.1): One (ASN.1): Specification of basic notation", ITU-T
Specification of basic notation", ITU-T Recommendation Recommendation X.680, August 2015,
X.680, August 2015, <https://www.itu.int/rec/T-REC-X.680>. <https://www.itu.int/rec/T-REC-X.680>.
[X.690] International Telecommunications Union, "Information [X.690] ITU-T, "Information technology - ASN.1 encoding rules:
technology — ASN.1 encoding rules: Specification of Basic Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (BER), Canonical Encoding Rules (CER) and Encoding Rules (CER) and Distinguished Encoding Rules
Distinguished Encoding Rules (DER)", ITU-T Recommendation (DER)", ITU-T Recommendation X.690, August 2015,
X.690, August 2015, <https://www.itu.int/rec/T-REC-X.690>. <https://www.itu.int/rec/T-REC-X.690>.
9.2. Informative References 9.2. Informative References
[IANA.enterprise-numbers] [IANA.enterprise-numbers]
IANA, "Enterprise Numbers", IANA, "Private Enterprise Numbers",
<http://www.iana.org/assignments/enterprise-numbers>. <https://www.iana.org/assignments/enterprise-numbers>.
[OID-INFO] Orange SA, "OID Repository", 2016, [OID-INFO] Orange SA, "Object Identifier (OID) Repository",
<http://www.oid-info.com/>. <http://www.oid-info.com/>.
[PCRE] Ho, A., "PCRE - Perl Compatible Regular Expressions", [PCRE] "PCRE - Perl Compatible Regular Expressions",
2018, <http://www.pcre.org/>. <http://www.pcre.org/>.
[RFC7388] Schoenwaelder, J., Sehgal, A., Tsou, T., and C. Zhou, [RFC7388] Schoenwaelder, J., Sehgal, A., Tsou, T., and C. Zhou,
"Definition of Managed Objects for IPv6 over Low-Power "Definition of Managed Objects for IPv6 over Low-Power
Wireless Personal Area Networks (6LoWPANs)", RFC 7388, Wireless Personal Area Networks (6LoWPANs)", RFC 7388,
DOI 10.17487/RFC7388, October 2014, DOI 10.17487/RFC7388, October 2014,
<https://www.rfc-editor.org/info/rfc7388>. <https://www.rfc-editor.org/info/rfc7388>.
[X.672] International Telecommunications Union, "Information [X.672] ITU-T, "Information technology - Open systems
technology — Open systems interconnection — Object interconnection - Object identifier resolution system
identifier resolution system", ITU-T Recommendation X.672, (ORS)", ITU-T Recommendation X.672, August 2010,
August 2010, <https://www.itu.int/rec/T-REC-X.672>. <https://www.itu.int/rec/T-REC-X.672>.
Appendix A. Change Log
This section is to be removed before publishing as an RFC.
A.1. Changes from -06 to -07
* Various editorial changes prompted by IESG feedback; clarify the
usage of "SDNV" in this document (no leading zeros).
* Add security consideration about tag-factoring.
* Make TBD112, where applicable, the preferred serialization (and
thus the required deterministic encoding) over TBD111.
A.2. Changes from -05 to -06
Add references to specific section numbers of [X.690] to better
explain validity of enclosed byte string.
A.3. Changes from -04 to -05
* Update acknowledgements, contributor list, and author list
A.4. Changes from -03 to -04
Process WGLC and shepherd comments:
* Update references (RFC 8949, URIs for ITU-T)
* Define arc for this document, reference SDN definition
* Restructure, small editorial clarifications
A.5. Changes from -02 to -03
* Add tag TBD112 for PEN-relative OIDs
* Add suggested CDDL typenames; reference RFC8610
A.6. Changes from -01 to -02
Minor editorial changes, remove some remnants, ready for WGLC.
A.7. Changes from -00 to -01
Clean up OID tag factoring.
A.8. Changes from -07 (bormann) to -00 (ietf)
Resubmitted as WG draft after adoption.
A.9. Changes from -06 to -07
Reduce the draft back to its basic mandate: Describe CBOR tags for
what is colloquially know as ASN.1 Object IDs.
A.10. Changes from -05 to -06
Refreshed the draft to the current date ("keep-alive").
A.11. Changes from -04 to -05
Discussed UUID usage in CBOR, and incorporated fixes proposed by
Olivier Dubuisson, including fixes regarding OID nomenclature.
A.12. Changes from -03 to -04
Changes occurred based on limited feedback, mainly centered around
the abstract and introduction, rather than substantive technical
changes. These changes include:
* Changed the title so that it is about tags and techniques.
* Rewrote the abstract to describe the content more accurately, and
to point out that no changes to the wire protocol are being
proposed.
* Removed "ASN.1" from "object identifiers", as OIDs are independent
of ASN.1.
* Rewrote the introduction to be more about the present text.
* Proposed a concise OID arc.
* Provided binary regular expression forms for OID validation.
* Updated IANA registration tables.
A.13. Changes from -02 to -03
Many significant changes occurred in this version. These changes
include:
* Expanded the draft scope to be a comprehensive CBOR update.
* Added OID-related sections: OID Enumerations, OID Maps and Arrays,
and Applications and Examples of OIDs.
* Added Tag 36 update (binary MIME, better definitions).
* Added stub/experimental sections for X.690 Series Tags (tag <<X>>)
and Regular Expressions (tag 35).
* Added technique for representing sets and multisets.
* Added references and fixed typos.
Acknowledgments Acknowledgments
Sean Leonard started the work on this document in 2014 with an Sean Leonard started the work on this document in 2014 with an
elaborate proposal. Jim Schaad provided a significant review of this elaborate proposal. Jim Schaad provided a significant review of this
document. Rob Wilton's IESG review prompted us to provide preferred document. Rob Wilton's IESG review prompted us to provide preferred
serialization considerations. serialization considerations.
Contributors Contributors
Sean Leonard Sean Leonard
Penango, Inc. Penango, Inc.
5900 Wilshire Boulevard 5900 Wilshire Boulevard
21st Floor 21st Floor
Los Angeles, CA, 90036 Los Angeles, CA 90036
United States of America United States of America
Email: dev+ietf@seantek.com Email: dev+ietf@seantek.com
Author's Address Author's Address
Carsten Bormann Carsten Bormann
Universität Bremen TZI Universität Bremen TZI
Postfach 330440 Postfach 330440
D-28359 Bremen D-28359 Bremen
 End of changes. 77 change blocks. 
354 lines changed or deleted 242 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/