Closed thomas-fossati closed 9 months ago
Below are some suggestions/questions regarding the RATS Conceptual Messages Wrapper draft (draft-ftbs-rats-msg-wrap-00).
While the mechanism is generic -- at least in part, now that we added the CM indicator to the array serialisation -- we want to keep the scope limited to RATS messages.
This encap is intended for tunnelling RATS messages in protocols that don't use media types as first class type identifiers themselves. The relation of this spec with the EAT media type I-D is one of "consumer": if EAT MT has a type that is good for the message, we can use it.
In #22, I hope I have explained a bit better the basic reason for providing a single encap, and what registrations we are amortising.
.det
with indentation of the RFC6838 definition? I think that'd be easier to read.To improve readability this has now been separated into its own section.
Done in #23
cbor-bytes / base64-string
serialized per the tag number? If not, what would govern the type?This is stated in §3.2: "[...] encoded as a CBOR byte string, to which the tag is prepended."
8219753144ABCDABCD
and DA6374763244ABCDABCD
).Agreed; we have added the CBOR "pretty" output to the examples.
Done in #23
example_tag = #6.1668576818(bstr)
.We have now used a brand new CDDL feature ("non-literal CBOR tag numbers") in §3.2 to do that in a generic way.
hi Carl, we think we addressed all your points. See https://thomas-fossati.github.io/draft-ftbs-rats-msg-wrap/draft-ftbs-rats-msg-wrap.html
Could you please check when you have some spare time?
/cc @carl-wallace
Yep. Thanks. A few nits/comments:
In third sentence of first paragraph in section 1, “RATS conceptual message” should be plural.
In the cm-type definition, attestation-result should probably be plural.
In the first sentence of section 3.2, "may be derived from CoAP Content-Format numbers" may be more accurate given section 3.2.1's allowance for other registered tags.
I wonder if including
Should the lookahead for CBORTag be bounded on 0xdb instead of 0xdf? The jump table in RFC 8949 has 0xdb as highest value.
Yep. Thanks.
Cool, thanks for checking (and for the further comments).
A few nits/comments: [...]
done in https://github.com/thomas-fossati/draft-ftbs-rats-msg-wrap/pull/30
Carl's original review was addressed in #22 and #23.
The follow-up re-review (https://github.com/thomas-fossati/draft-ftbs-rats-msg-wrap/issues/15#issuecomment-1516870623) has been addressed in #30
See https://mailarchive.ietf.org/arch/msg/rats/Bmlxnu0GmnRMsP6WEq3CBjLVm0k/