On Fri, Jan 23, 2026 at 3:34 AM Rob Wilton (rwilton)
<[email protected]> wrote:
>
> Hi,
>
> I know that I have been involved in some discussions on this topic in the
> past, but I'm not sure that I ever tracked to conclusion, and it feels like
> the RFC has potentially ended up in a slight strange, and perhaps
> underspecified place.
>
> Section 6.12 makes it clear that the union encoding in CBOR:
>
> is different from how the regular type is encoded (e.g., enums and bits are
> encoded as strings when within a union)
> the reason that this is done is for consistency of parsing with XML (which
> seems like a reasonable reason).
>
>
> However, it also defines CBOR tags to allow different values encoded as
> strings to be discriminated against (for bits, enum, ident-ref and
> instance-identifier).
>
> The YANG encoding in JSON RFC (RFC 7951), section 6.10, makes it clear that
> type information is used when validating a value of a union type, which means
> that the JSON parsing of the values of nodes that are data type union already
> potentially differs from XML (e.g., consider the simple case that the first
> union type was an unrestricted string, along with an integer).
>
> The CBOR YANG encoding includes CBOR tags to identify the type but does not
> indicate whether those tags should be used during parsing (e.g., as JSON
> decoding would). I presume that they should be used, otherwise the tags seem
> to serve no useful purpose.
>
> But if we are using the CBOR type tags to discriminate when validating then
> it isn't clear to me what the benefit is of then using strings for bits and
> enums when parsing union values using those types.
>
I think the decision to use strings for enum and bits here is to
maintain the same error patterns as XML or JSON for these types.
Both can depend on the member type order. e.g:
typedef enum1 {
enum one { value 1; }
enum foo;
}
typedef enum2 {
enum one;
enum bar;
}
typedef uniontyp {
type enum1;
type enum2;
}
If the server sends enum2::one the receiver will match enum1::one.
If the value is sent instead, the receiver would match enum2:one.
> Can anyone clarify what the expected behaviour is when parsing please? Is an
> erratum needed/helpful here?
>
I think it is implementation-specific how the tag values would be used.
I was looking at my code to see what it does and the tags are used:
/* check if tagged value received. If so then force
* the parsing to find that type in the union member types
* This can produce a different decode than XML or JSON!
* CBOR sends more metadata than XML or JSON and does it
* with a tiny number of bytes!
*/
switch (tagval) {
case 0:
break; // no tag received
case TAG_YANG_DEC_FRACTION:
/* got a decimal64 */
return parse_yang_decimal64(pcb, obj, retval);
case TAG_YANG_BITS:
case TAG_YANG_ENUM:
/* expecting string form of bits or enum */
expect_string = TRUE;
break;
case TAG_YANG_IDREF:
return parse_yang_idref(pcb, obj, retval);
case TAG_YANG_INSTANCE_ID:
expect_instid = TRUE;
break;
default:
return wrong_token_error(pcb, "known tag");
}
> Kind regards,
> Rob
Andy
>
>
>
> _______________________________________________
> core mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
_______________________________________________
netmod mailing list -- [email protected]
To unsubscribe send an email to [email protected]
