rfc9237v2.txt   rfc9237.txt 
skipping to change at line 279 skipping to change at line 279
to a single number _REST-method-set_ by the following steps: to a single number _REST-method-set_ by the following steps:
* The entries in the table that specify the same URI-local-part are * The entries in the table that specify the same URI-local-part are
merged into a single entry that specifies the union of the merged into a single entry that specifies the union of the
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 that has been chosen as 32
the number for Dynamic-DELETE as the number for DELETE is 3). (e.g., 35 is 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 two to the power of each (decremented) method number set by taking two to the power of each (decremented) method number
and computing the inclusive OR of the binary representations of and computing the inclusive OR of the binary representations of
all the power 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]]
skipping to change at line 318 skipping to change at line 319
PATCH: 5 PATCH: 5
iPATCH: 6 iPATCH: 6
Dynamic-GET: 32; 0 .plus Dynamic-Offset Dynamic-GET: 32; 0 .plus Dynamic-Offset
Dynamic-POST: 33; 1 .plus Dynamic-Offset Dynamic-POST: 33; 1 .plus Dynamic-Offset
Dynamic-PUT: 34; 2 .plus Dynamic-Offset Dynamic-PUT: 34; 2 .plus Dynamic-Offset
Dynamic-DELETE: 35; 3 .plus Dynamic-Offset Dynamic-DELETE: 35; 3 .plus Dynamic-Offset
Dynamic-FETCH: 36; 4 .plus Dynamic-Offset Dynamic-FETCH: 36; 4 .plus Dynamic-Offset
Dynamic-PATCH: 37; 5 .plus Dynamic-Offset Dynamic-PATCH: 37; 5 .plus Dynamic-Offset
Dynamic-iPATCH: 38; 6 .plus Dynamic-Offset Dynamic-iPATCH: 38; 6 .plus Dynamic-Offset
) )
Dynamic-Offset = 32
Figure 4: AIF in CDDL Figure 4: AIF in CDDL
For the information shown in Table 1 and Figure 3, a representation For the information shown in Table 1 and Figure 3, a representation
in Concise Binary Object Representation (CBOR) [RFC8949] is given in in Concise Binary Object Representation (CBOR) [RFC8949] is given in
Figure 5; again, several optimizations and improvements are possible. Figure 5; again, several optimizations and improvements are possible.
83 # array(3) 83 # array(3)
82 # array(2) 82 # array(2)
67 # text(7) 67 # text(7)
skipping to change at line 511 skipping to change at line 513
* The specifications for Toid and Tperm need to realize the general * The specifications for Toid and Tperm need to realize the general
ideas of unambiguous object identifiers and permission lists in ideas of unambiguous object identifiers and permission lists in
the context where the AIF data item is intended to be used, and the context where the AIF data item is intended to be used, and
their structure needs to be usable with the intended media types their structure needs to be usable with the intended media types
(application/aif+cbor and application/aif+json) as identified in (application/aif+cbor and application/aif+json) as identified in
the specification. the specification.
* The parameter names need to conform to Section 4.3 of [RFC6838], * The parameter names need to conform to Section 4.3 of [RFC6838],
but preferably they are in [KebabCase] so they can be easily but preferably they are in [KebabCase] so they can be easily
translated into names used in APIs with popular programming translated into names used in APIs with popular programming
language. languages.
The designated experts will develop further criteria and guidelines The designated experts will develop further criteria and guidelines
as needed. as needed.
5.3. Content-Format 5.3. Content-Format
IANA has registered Content-Format numbers in the "CoAP Content- IANA has registered Content-Format numbers in the "CoAP Content-
Formats" subregistry, within the "Constrained RESTful Environments Formats" subregistry, within the "Constrained RESTful Environments
(CoRE) Parameters" registry [IANA.core-parameters], as follows: (CoRE) Parameters" registry [IANA.core-parameters], as follows:
skipping to change at line 544 skipping to change at line 546
combinations. combinations.
6. Security Considerations 6. Security Considerations
The security considerations of [RFC7252] apply when AIF is used with The security considerations of [RFC7252] apply when AIF is used with
CoAP; Section 11.1 of [RFC7252] specifically applies if complex CoAP; Section 11.1 of [RFC7252] specifically applies if complex
formats such as URIs are used for Toid or Tperm. Some wider issues formats such as URIs are used for Toid or Tperm. Some wider issues
are discussed in [RFC8576]. are discussed in [RFC8576].
When applying these formats, the referencing specification needs to When applying these formats, the referencing specification needs to
be careful to ensure that: be careful to ensure:
* the cryptographic armor employed around this format fulfills the * that the cryptographic armor employed around this format fulfills
referencing specification's security objectives and that the armor the referencing specification's security objectives and that the
or some additional information included in it with the AIF data armor or some additional information included in it with the AIF
item (1) unambiguously identifies the subject to which the data item (1) unambiguously identifies the subject to which the
authorizations shall apply and (2) provides any context 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
authorization is being granted from the object identifiers (such authorization is being granted from the object identifiers (such
as, for the data models defined in the present specification, the as, for the data models defined in the present specification, the
scheme and authority information that is used to construct the scheme and authority information that is used to construct the
full URI), and full URI), and
* the types used for Toid and Tperm provide the appropriate * that the types used for Toid and Tperm provide the appropriate
granularity and precision so that application requirements on the granularity and precision so that application requirements on the
precision of the authorization information are fulfilled and that precision of the authorization information are fulfilled and that
all parties have the same understanding of each Toid/Tperm pair in all parties have the same understanding of each Toid/Tperm pair in
terms of specified objects (resources) and operations on those. terms of specified objects (resources) and operations on those.
For the data formats, the security considerations of [RFC8259] and For the data formats, the security considerations of [RFC8259] and
[RFC8949] apply. [RFC8949] apply.
A plain implementation of AIF might implement just the basic REST A plain implementation of AIF might implement just the basic REST
model as per Section 2.1. If it receives authorizations that include model as per Section 2.1. If it receives authorizations that include
 End of changes. 6 change blocks. 
9 lines changed or deleted 11 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/