On 2026-07-14, at 14:46, Sipos, Brian J. <[email protected]> wrote: > > The root of the problem is the question “is the decoder-processor supposed to > treat null value any differently?
For those interested in the history, here is what Jim Schaad said in <http://mailarchive.ietf.org/arch/msg/cose/vfJ6mfHXq7bu6fw_sLD7f6XSiks> about a similar case: >> "For body_protected and sign_protected, if the fields are not present in >> their >> corresponding maps, an bstr of length zero should be used." >> >> Should? The encoding of this is interop-critical. Also, why not use NULL for >> absent field here? > > This is a lower case should and does have the same 2119 language meaning (see > the text in 1.1 about natural language). However 'is' will work just as well. > > I could just as easily use NULL, but there is no size or conception > difference. The change from NULL to an empty bstr came about from the idea > at one point during using arrays that it might be easier to do the parsing if > the empty binary string was used instead. It might also make checking of > types easier. This change got copied down into the structure to be signed as > it made the code easier (just copy the item). As I said, I am not wedded to > either way. I don’t know how that discussion continued, but it shows that Jim viewed null and the empty byte string in that case as interchangeable and the choice to be subject to minutiae such as ease of parsing. Now in that case, a choice was apparently made: empty_or_serialized_map = bstr .cbor header_map / bstr .size 0 Maybe the discrepancy in the case here, ciphertext (text explicitly says “nil" [null] and examples show empty byte string) is an incompletely executed change, or maybe the examples are just showing an incorrect transfer of the …_protected decision to ciphertext. At this point, I’d like to hear from more implementers… Grüße, Carsten _______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
