| < draft-ietf-ace-aif-06.txt | draft-ietf-ace-aif-07.txt > | |||
|---|---|---|---|---|
| ACE Working Group C. Bormann | ACE Working Group C. Bormann | |||
| Internet-Draft Universität Bremen TZI | Internet-Draft Universität Bremen TZI | |||
| Intended status: Standards Track 5 March 2022 | Intended status: Standards Track 15 March 2022 | |||
| Expires: 6 September 2022 | Expires: 16 September 2022 | |||
| An Authorization Information Format (AIF) for ACE | An Authorization Information Format (AIF) for ACE | |||
| draft-ietf-ace-aif-06 | draft-ietf-ace-aif-07 | |||
| Abstract | Abstract | |||
| Information about which entities are authorized to perform what | Information about which entities are authorized to perform what | |||
| operations on which constituents of other entities is a crucial | operations on which constituents of other entities is a crucial | |||
| component of producing an overall system that is secure. Conveying | component of producing an overall system that is secure. Conveying | |||
| precise authorization information is especially critical in highly | precise authorization information is especially critical in highly | |||
| automated systems with large numbers of entities, such as the | automated systems with large numbers of entities, such as the | |||
| "Internet of Things". | "Internet of Things". | |||
| skipping to change at page 2, line 10 ¶ | skipping to change at page 2, line 10 ¶ | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on 6 September 2022. | This Internet-Draft will expire on 16 September 2022. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2022 IETF Trust and the persons identified as the | Copyright (c) 2022 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 (https://trustee.ietf.org/ | |||
| license-info) in effect on the date of publication of this document. | license-info) in effect on the date of publication of this document. | |||
| Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
| skipping to change at page 2, line 35 ¶ | skipping to change at page 2, line 35 ¶ | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 | 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 2. Information Model . . . . . . . . . . . . . . . . . . . . . . 3 | 2. Information Model . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 2.1. REST-specific Model . . . . . . . . . . . . . . . . . . . 4 | 2.1. REST-specific Model . . . . . . . . . . . . . . . . . . . 4 | |||
| 2.2. Limitations . . . . . . . . . . . . . . . . . . . . . . . 5 | 2.2. Limitations . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 2.3. REST-specific Model With Dynamic Resource Creation . . . 6 | 2.3. REST-specific Model With Dynamic Resource Creation . . . 6 | |||
| 3. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 6 | 3. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
| 4. Media Types . . . . . . . . . . . . . . . . . . . . . . . . . 8 | 4. Media Types . . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
| 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 | |||
| 5.1. Media Types . . . . . . . . . . . . . . . . . . . . . . . 9 | 5.1. Media Types . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
| 5.2. Registries . . . . . . . . . . . . . . . . . . . . . . . 10 | 5.2. Registries . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
| 5.3. Content-Format . . . . . . . . . . . . . . . . . . . . . 11 | 5.3. Content-Format . . . . . . . . . . . . . . . . . . . . . 12 | |||
| 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 | |||
| 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 | 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
| 7.1. Normative References . . . . . . . . . . . . . . . . . . 12 | 7.1. Normative References . . . . . . . . . . . . . . . . . . 13 | |||
| 7.2. Informative References . . . . . . . . . . . . . . . . . 13 | 7.2. Informative References . . . . . . . . . . . . . . . . . 14 | |||
| Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15 | Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
| Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 | Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
| 1. Introduction | 1. Introduction | |||
| Constrained Devices as they are used in the "Internet of Things" need | Constrained Devices as they are used in the "Internet of Things" need | |||
| security in order to operate correctly and prevent misuse. One | security in order to operate correctly and prevent misuse. One | |||
| important element of this security is that devices in the Internet of | important element of this security is that devices in the Internet of | |||
| Things need to be able to decide which operations requested of them | Things need to be able to decide which operations requested of them | |||
| should be considered authorized, need to ascertain that the | should be considered authorized, need to ascertain that the | |||
| authorization to request the operation does apply to the actual | authorization to request the operation does apply to the actual | |||
| requester as authenticated, and need to ascertain that other devices | requester as authenticated, and need to ascertain that other devices | |||
| skipping to change at page 4, line 5 ¶ | skipping to change at page 4, line 5 ¶ | |||
| The term "byte", abbreviated by "B", is used in its now customary | The term "byte", abbreviated by "B", is used in its now customary | |||
| sense as a synonym for "octet". | sense as a synonym for "octet". | |||
| 2. Information Model | 2. Information Model | |||
| Authorizations are generally expressed through some data structures | Authorizations are generally expressed through some data structures | |||
| that are cryptographically secured (or transmitted in a secure way). | that are cryptographically secured (or transmitted in a secure way). | |||
| This section discusses the information model underlying the payload | This section discusses the information model underlying the payload | |||
| of that data (as opposed to the cryptographic armor around it). | of that data (as opposed to the cryptographic armor around it). | |||
| The semantics of the authorization information defined in this | ||||
| document are that of an _allow-list_: everything is denied until it | ||||
| is explicitly allowed. | ||||
| For the purposes of this specification, the underlying access control | For the purposes of this specification, the underlying access control | |||
| model will be that of an access matrix, which gives a set of | model will be that of an access matrix, which gives a set of | |||
| permissions for each possible combination of a subject and an object. | permissions for each possible combination of a subject and an object. | |||
| We are focusing the AIF data item on a single row in the access | We are focusing the AIF data item on a single row in the access | |||
| matrix (such a row traditionally is also called a capability list), | matrix (such a row has often been called a capability list), without | |||
| without concern to the subject for which the data item is issued. As | concern to the subject for which the data item is issued. As a | |||
| a consequence, AIF MUST be used in a way that the subject of the | consequence, AIF MUST be used in a way that the subject of the | |||
| authorizations is unambiguously identified (e.g., as part of the | authorizations is unambiguously identified (e.g., as part of the | |||
| armor around it). | armor around it). | |||
| The generic model of such a capability list is a list of pairs of | The generic model of such a capability list is a list of pairs of | |||
| object identifiers and the permissions the subject has on the | object identifiers (of type Toid) and the permissions (of type Tperm) | |||
| object(s) identified. | the subject has on the object(s) identified. | |||
| AIF-Generic<Toid, Tperm> = [* [Toid, Tperm]] | AIF-Generic<Toid, Tperm> = [* [Toid, Tperm]] | |||
| Figure 1: Definition of Generic AIF | Figure 1: Definition of Generic AIF | |||
| In a specific data model (such as the one also specified in this | In a specific data model (such as the one also specified in this | |||
| document), the object identifier (Toid) will often be a text string, | document), the object identifier (Toid) will often be a text string, | |||
| and the set of permissions (Tperm) will be represented by a bitset in | and the set of permissions (Tperm) will be represented by a bitset in | |||
| turn represented as a number (see Section 3). | turn represented as a number (see Section 3). | |||
| skipping to change at page 6, line 26 ¶ | skipping to change at page 6, line 26 ¶ | |||
| access.) In other words, it addresses an important subset of the | access.) In other words, it addresses an important subset of the | |||
| third limitation mentioned in Section 2.2. | third limitation mentioned in Section 2.2. | |||
| +================+===================================+ | +================+===================================+ | |||
| | URI-local-part | Permission Set | | | URI-local-part | Permission Set | | |||
| +================+===================================+ | +================+===================================+ | |||
| | /a/make-coffee | POST, Dynamic-GET, Dynamic-DELETE | | | /a/make-coffee | POST, Dynamic-GET, Dynamic-DELETE | | |||
| +----------------+-----------------------------------+ | +----------------+-----------------------------------+ | |||
| Table 2: An authorization instance in the AIF | Table 2: An authorization instance in the AIF | |||
| Information Model | Information Model With Dynamic Resource Creation | |||
| For a method X, the presence of a Dynamic-X permission means that the | For a method X, the presence of a Dynamic-X permission means that the | |||
| subject holds permission to exercise the method X on resources that | subject holds permission to exercise the method X on resources that | |||
| have been returned in a 2.01 (201) response by a Location-indicating | have been returned in a 2.01 (201 Created) response by a Location- | |||
| mechanism to a request that the subject made to the resource listed | indicating mechanism to a request that the subject made to the | |||
| (/a/make-coffee in the example shown in Table 2, which might return | resource listed. In the example shown in Table 2, POST operations on | |||
| the location of a resource that allows GET to find out about the | /a/make-coffee might return the location of a resource dynamically | |||
| status and DELETE to cancel the coffee-making operation). | created on the coffee machine that allows GET to find out about the | |||
| status of, and DELETE to cancel, the coffee-making operation. | ||||
| Since the use of the extension defined in this section can be | Since the use of the extension defined in this section can be | |||
| detected by the mentioning of the Dynamic-X permissions, there is no | detected by the mentioning of the Dynamic-X permissions, there is no | |||
| need for another explicit switch between the basic and the model | need for another explicit switch between the basic and the model | |||
| extended by dynamic resource creation; the extended model is always | extended by dynamic resource creation; the extended model is always | |||
| presumed once a Dynamic-X permission is present. | presumed once a Dynamic-X permission is present. | |||
| 3. Data Model | 3. Data Model | |||
| Different data model specializations can be defined for the generic | Different data model specializations can be defined for the generic | |||
| skipping to change at page 7, line 17 ¶ | skipping to change at page 7, line 24 ¶ | |||
| permission sets. | permission sets. | |||
| * The (non-dynamic) methods in the permission sets are converted | * The (non-dynamic) methods in the permission sets are converted | |||
| into their CoAP method numbers, minus 1. | into their CoAP method numbers, minus 1. | |||
| * Dynamic-X permissions are converted into what the number would | * Dynamic-X permissions are converted into what the number would | |||
| have been for X, plus a Dynamic-Offset chosen as 32 (e.g., 35 is | have been for X, plus a Dynamic-Offset chosen as 32 (e.g., 35 is | |||
| the number for Dynamic-DELETE as the number for DELETE is 3). | the number for Dynamic-DELETE as the number for DELETE is 3). | |||
| * The set of numbers is converted into a single number REST-method- | * The set of numbers is converted into a single number REST-method- | |||
| set by taking each number to the power of two and computing the | set by taking two to the power of each (decremented) method number | |||
| inclusive OR of the binary representations of all the power | and computing the inclusive OR of the binary representations of | |||
| values. | all the power values. | |||
| This data model could be interchanged in the JSON [RFC8259] | This data model could be interchanged in the JSON [RFC8259] | |||
| representation given in Figure 3. | representation given in Figure 3. | |||
| [["/s/temp",1],["/a/led",5],["/dtls",2]] | [["/s/temp",1],["/a/led",5],["/dtls",2]] | |||
| Figure 3: An authorization instance encoded in JSON (40 bytes) | Figure 3: An authorization instance encoded in JSON (40 bytes) | |||
| In Figure 4, a straightforward specification of the data model | In Figure 4, a straightforward specification of the data model | |||
| (including both the methods from [RFC7252] and the new ones from | (including both the methods from [RFC7252] and the new ones from | |||
| skipping to change at page 9, line 18 ¶ | skipping to change at page 9, line 37 ¶ | |||
| Types" registry. | Types" registry. | |||
| +==========+======================+=====================+ | +==========+======================+=====================+ | |||
| | Name | Template | Reference | | | Name | Template | Reference | | |||
| +==========+======================+=====================+ | +==========+======================+=====================+ | |||
| | aif+cbor | application/aif+cbor | RFC XXXX, Section 4 | | | aif+cbor | application/aif+cbor | RFC XXXX, Section 4 | | |||
| +----------+----------------------+---------------------+ | +----------+----------------------+---------------------+ | |||
| | aif+json | application/aif+json | RFC XXXX, Section 4 | | | aif+json | application/aif+json | RFC XXXX, Section 4 | | |||
| +----------+----------------------+---------------------+ | +----------+----------------------+---------------------+ | |||
| Table 3 | Table 3: New Media Types | |||
| For application/aif+cbor: | For application/aif+cbor: | |||
| Type name: application | Type name: application | |||
| Subtype name: aif+cbor | Subtype name: aif+cbor | |||
| Required parameters: none | Required parameters: N/A | |||
| Optional parameters: | Optional parameters: | |||
| * Toid: the identifier for the object for which permissions are | * Toid: the identifier for the object for which permissions are | |||
| supplied. A value from the media-type parameter sub-registry | supplied. A value from the media-type parameter sub-registry | |||
| for Toid. Default value: "URI-local-part" (RFC XXXX). | for Toid. Default value: "URI-local-part" (RFC XXXX). | |||
| * Tperm: the data type of a permission set for the object | * Tperm: the data type of a permission set for the object | |||
| identified via a Toid. A value from the media-type parameter | identified via a Toid. A value from the media-type parameter | |||
| sub-registry for Tperm. Default value: "REST-method-set" (RFC | sub-registry for Tperm. Default value: "REST-method-set" (RFC | |||
| XXXX). | XXXX). | |||
| Encoding considerations: binary (CBOR) | Encoding considerations: binary (CBOR) | |||
| skipping to change at page 10, line 4 ¶ | skipping to change at page 10, line 27 ¶ | |||
| fragment identifiers is as specified for "application/cbor". (At | fragment identifiers is as specified for "application/cbor". (At | |||
| publication of RFC XXXX, there is no fragment identification | publication of RFC XXXX, there is no fragment identification | |||
| syntax defined for "application/cbor".) | syntax defined for "application/cbor".) | |||
| Person & email address to contact for further information: ACE WG | Person & email address to contact for further information: ACE WG | |||
| mailing list (ace@ietf.org), or IETF Applications and Real-Time | mailing list (ace@ietf.org), or IETF Applications and Real-Time | |||
| Area (art@ietf.org) | Area (art@ietf.org) | |||
| Intended usage: COMMON | Intended usage: COMMON | |||
| Restrictions on usage: none | Restrictions on usage: none | |||
| Author/Change controller: IETF | Author/Change controller: IETF | |||
| Provisional registration: no | Provisional registration: no | |||
| For application/aif+json: | For application/aif+json: | |||
| Type name: application | Type name: application | |||
| Subtype name: aif+json | Subtype name: aif+json | |||
| Required parameters: none | Required parameters: N/A | |||
| Optional parameters: | Optional parameters: | |||
| * Toid: the identifier for the object for which permissions are | * Toid: the identifier for the object for which permissions are | |||
| supplied. A value from the media-type parameter sub-registry | supplied. A value from the media-type parameter sub-registry | |||
| for Toid. Default value: "URI-local-part" (RFC XXXX). | for Toid. Default value: "URI-local-part" (RFC XXXX). | |||
| * Tperm: the data type of a permission set for the object | * Tperm: the data type of a permission set for the object | |||
| identified via a Toid. A value from the media-type parameter | identified via a Toid. A value from the media-type parameter | |||
| sub-registry for Tperm. Default value: "REST-method-set" (RFC | sub-registry for Tperm. Default value: "REST-method-set" (RFC | |||
| XXXX). | XXXX). | |||
| Encoding considerations: binary (JSON is UTF-8-encoded text) | Encoding considerations: binary (JSON is UTF-8-encoded text) | |||
| skipping to change at page 11, line 15 ¶ | skipping to change at page 11, line 30 ¶ | |||
| +===========+=================+=====================+===========+ | +===========+=================+=====================+===========+ | |||
| | Parameter | name | Description/ | Reference | | | Parameter | name | Description/ | Reference | | |||
| | | | Specification | | | | | | Specification | | | |||
| +===========+=================+=====================+===========+ | +===========+=================+=====================+===========+ | |||
| | Toid | URI-local-part | local-part of URI | RFC XXXX | | | Toid | URI-local-part | local-part of URI | RFC XXXX | | |||
| +-----------+-----------------+---------------------+-----------+ | +-----------+-----------------+---------------------+-----------+ | |||
| | Tperm | REST-method-set | set of REST methods | RFC XXXX | | | Tperm | REST-method-set | set of REST methods | RFC XXXX | | |||
| | | | represented | | | | | | represented | | | |||
| +-----------+-----------------+---------------------+-----------+ | +-----------+-----------------+---------------------+-----------+ | |||
| Table 4 | Table 4: New Media Type Parameters | |||
| The registration policy is Specification required [RFC8126]. The | The registration policy is Specification required [RFC8126]. The | |||
| designated expert will engage with the submitter to ascertain the | designated expert will engage with the submitter to ascertain the | |||
| requirements of this document are addressed. | requirements of this document are addressed: | |||
| * The specifications for Toid and Tperm need to realize the general | ||||
| ideas of unambiguous object identifiers and permission lists in | ||||
| the context where the AIF data item is intended to be used, and | ||||
| their structure needs to be usable with the intended media types | ||||
| (application/aif+cbor and application/aif+json) as identified in | ||||
| the specification. | ||||
| * The parameter names need to conform to Section 4.3 of [RFC6838], | ||||
| but preferably are in [KebabCase] so they can easily be translated | ||||
| into names used in popular programming language APIs. | ||||
| The designated experts will develop further criteria and guidelines | ||||
| as needed. | ||||
| 5.3. Content-Format | 5.3. Content-Format | |||
| IANA is requested to register Content-Format numbers in the "CoAP | IANA is requested to register Content-Format numbers in the "CoAP | |||
| Content-Formats" sub-registry, within the "Constrained RESTful | Content-Formats" sub-registry, within the "Constrained RESTful | |||
| Environments (CoRE) Parameters" Registry [IANA.core-parameters], as | Environments (CoRE) Parameters" Registry [IANA.core-parameters], as | |||
| follows: | follows: | |||
| +======================+================+======+===========+ | +======================+================+======+===========+ | |||
| | Content-Type | Content Coding | ID | Reference | | | Content-Type | Content Coding | ID | Reference | | |||
| +======================+================+======+===========+ | +======================+================+======+===========+ | |||
| | application/aif+cbor | - | TBD1 | RFC XXXX | | | application/aif+cbor | - | TBD1 | RFC XXXX | | |||
| +----------------------+----------------+------+-----------+ | +----------------------+----------------+------+-----------+ | |||
| | application/aif+json | - | TBD2 | RFC XXXX | | | application/aif+json | - | TBD2 | RFC XXXX | | |||
| +----------------------+----------------+------+-----------+ | +----------------------+----------------+------+-----------+ | |||
| Table 5 | Table 5: New Content-Formats | |||
| // RFC Ed.: please replace TBD1 and TBD2 with assigned IDs and remove | // RFC Ed.: please replace TBD1 and TBD2 with assigned IDs and remove | |||
| this note. | this note. | |||
| In the registry as defined by Section 12.3 of [RFC7252] at the time | In the registry as defined by Section 12.3 of [RFC7252] at the time | |||
| of writing, the column "Content-Type" is called "Media type" and the | of writing, the column "Content-Type" is called "Media type" and the | |||
| column "Content Coding" is called "Encoding". | column "Content Coding" is called "Encoding". | |||
| Note that applications that register Toid and Tperm values are | Note that applications that register Toid and Tperm values are | |||
| encouraged to also register Content-Formats for the relevant | encouraged to also register Content-Formats for the relevant | |||
| combinations. | combinations. | |||
| 6. Security Considerations | 6. Security Considerations | |||
| The security considerations of [RFC7252] apply. Some wider issues | The security considerations of [RFC7252] apply when AIF is used with | |||
| are discussed in [RFC8576]. | CoAP, and, if complex formats such as URIs are used for Toid or | |||
| Tperm, specifically Section 11.1 of [RFC7252]. Some wider issues are | ||||
| The semantics of the authorization information defined in this | discussed in [RFC8576]. | |||
| document are that of an _allow-list_: everything is denied until it | ||||
| is explicitly allowed. | ||||
| When applying these formats, the referencing specification needs to | When applying these formats, the referencing specification needs to | |||
| be careful to: | be careful to: | |||
| * ensure that the cryptographic armor employed around this format | * ensure that the cryptographic armor employed around this format | |||
| fulfills the referencing specification's security objectives, and | fulfills the referencing specification's security objectives, and | |||
| that the armor or some additional information included in it with | that the armor or some additional information included in it with | |||
| the AIF data item (1) unambiguously identifies the subject to | the AIF data item (1) unambiguously identifies the subject to | |||
| which the authorizations shall apply and (2) provides any context | which the authorizations shall apply and (2) provides any context | |||
| information needed to derive the identity of the object to which | information needed to derive the identity of the object to which | |||
| skipping to change at page 13, line 22 ¶ | skipping to change at page 14, line 5 ¶ | |||
| [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>. | |||
| [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform | [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform | |||
| Resource Identifier (URI): Generic Syntax", STD 66, | Resource Identifier (URI): Generic Syntax", STD 66, | |||
| RFC 3986, DOI 10.17487/RFC3986, January 2005, | RFC 3986, DOI 10.17487/RFC3986, January 2005, | |||
| <https://www.rfc-editor.org/info/rfc3986>. | <https://www.rfc-editor.org/info/rfc3986>. | |||
| [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type | ||||
| Specifications and Registration Procedures", BCP 13, | ||||
| RFC 6838, DOI 10.17487/RFC6838, January 2013, | ||||
| <https://www.rfc-editor.org/info/rfc6838>. | ||||
| [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained | [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained | |||
| Application Protocol (CoAP)", RFC 7252, | Application Protocol (CoAP)", RFC 7252, | |||
| DOI 10.17487/RFC7252, June 2014, | DOI 10.17487/RFC7252, June 2014, | |||
| <https://www.rfc-editor.org/info/rfc7252>. | <https://www.rfc-editor.org/info/rfc7252>. | |||
| [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for | [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for | |||
| Writing an IANA Considerations Section in RFCs", BCP 26, | Writing an IANA Considerations Section in RFCs", BCP 26, | |||
| RFC 8126, DOI 10.17487/RFC8126, June 2017, | RFC 8126, DOI 10.17487/RFC8126, June 2017, | |||
| <https://www.rfc-editor.org/info/rfc8126>. | <https://www.rfc-editor.org/info/rfc8126>. | |||
| skipping to change at page 14, line 19 ¶ | skipping to change at page 15, line 10 ¶ | |||
| [IANA.core-parameters] | [IANA.core-parameters] | |||
| IANA, "Constrained RESTful Environments (CoRE) | IANA, "Constrained RESTful Environments (CoRE) | |||
| Parameters", | Parameters", | |||
| <https://www.iana.org/assignments/core-parameters>. | <https://www.iana.org/assignments/core-parameters>. | |||
| [IANA.media-type-sub-parameters] | [IANA.media-type-sub-parameters] | |||
| IANA, "MIME Media Type Sub-Parameter Registries", | IANA, "MIME Media Type Sub-Parameter Registries", | |||
| <https://www.iana.org/assignments/media-type-sub- | <https://www.iana.org/assignments/media-type-sub- | |||
| parameters>. | parameters>. | |||
| [KebabCase] | ||||
| "KebabCase", 29 August 2014, | ||||
| <http://wiki.c2.com/?KebabCase>. | ||||
| [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", | [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", | |||
| FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, | FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, | |||
| <https://www.rfc-editor.org/info/rfc4949>. | <https://www.rfc-editor.org/info/rfc4949>. | |||
| [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., | [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., | |||
| and D. Orchard, "URI Template", RFC 6570, | and D. Orchard, "URI Template", RFC 6570, | |||
| DOI 10.17487/RFC6570, March 2012, | DOI 10.17487/RFC6570, March 2012, | |||
| <https://www.rfc-editor.org/info/rfc6570>. | <https://www.rfc-editor.org/info/rfc6570>. | |||
| [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for | [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for | |||
| skipping to change at page 15, line 21 ¶ | skipping to change at page 16, line 16 ¶ | |||
| 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>. | |||
| Acknowledgements | Acknowledgements | |||
| Jim Schaad, Francesca Palombini, Olaf Bergmann, Marco Tiloca, and | Jim Schaad, Francesca Palombini, Olaf Bergmann, Marco Tiloca, and | |||
| Christian Amsüss provided comments that shaped the direction of this | Christian Amsüss provided comments that shaped the direction of this | |||
| document. Alexey Melnikov pointed out that there were gaps in the | document. Alexey Melnikov pointed out that there were gaps in the | |||
| media type specifications, and Loganaden Velvindron provided a | media type specifications, and Loganaden Velvindron provided a | |||
| shepherd review with further comments. Benjamin Kaduk provided an | shepherd review with further comments. Many thanks also to the IESG | |||
| extensive review as responsible Area Director, and indeed is | reviewers, which provided several small but significant observations. | |||
| responsible for much improvement in the document. | Benjamin Kaduk provided an extensive review as responsible Area | |||
| Director, and indeed is responsible for much improvement in the | ||||
| document. | ||||
| 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 | |||
| Germany | Germany | |||
| Phone: +49-421-218-63921 | Phone: +49-421-218-63921 | |||
| Email: cabo@tzi.org | Email: cabo@tzi.org | |||
| End of changes. 22 change blocks. | ||||
| 43 lines changed or deleted | 72 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/ | ||||