The media type application/yang-data+cbor (RFC 9254) is designed for
exactly this: it supports an optional "id" parameter (id=name or id=sid)
for unambiguous signaling. However, RFC 9254 also specifies that this media
type is intended only for YANG-modeled data, which introduces a constraint
described below.
Option 1 — Use application/yang-data+cbor with the id parameter
Provides standardized, unambiguous signaling aligned with RFC 9254.
The constraint is that applying it to the capability exchange requires
a corresponding YANG module — which the current https-notif draft does
not define. However, draft-ietf-netconf-notif-envelope
(https://datatracker.ietf.org/doc/draft-ietf-netconf-notif-envelope/)
is already introducing an extensible YANG model for notification
envelopes in this space, which suggests that defining a YANG module
for the capability exchange may be a natural and reasonable step.
If taken, it may also be worth updating the parent https-notif draft
to use application/yang-data+json and application/yang-data+xml for
consistency, though that would be a separate and non-trivial change.
Option 2 — Keep application/cbor; signal encoding via capability URIs
Retain application/cbor for both capability exchange and notifications.
Signal the SID vs. name distinction through dedicated capability URIs
in the capability exchange response, e.g.:
urn:ietf:capability:https-notif-receiver:encoding:cbor:sid
urn:ietf:capability:https-notif-receiver:encoding:cbor:named_identifier
The draft already permits custom capability URIs, and publishers are
required to ignore unrecognised ones, so this requires no structural
changes to either draft. The tradeoff is relying on URI convention
rather than the standardized media-type mechanism — though it fully
resolves the ambiguity. Given that the capability exchange is a
one-time event per session, the performance difference between the
two options is negligible.
The media type application/yang-data+cbor (RFC 9254) is designed for
exactly this: it supports an optional "id" parameter (id=name or id=sid)
for unambiguous signaling. However, RFC 9254 also specifies that this media
type is intended only for YANG-modeled data, which introduces a constraint
described below.
Option 1 — Use application/yang-data+cbor with the id parameter
Provides standardized, unambiguous signaling aligned with RFC 9254.
The constraint is that applying it to the capability exchange requires
a corresponding YANG module — which the current https-notif draft does
not define. However, draft-ietf-netconf-notif-envelope
(https://datatracker.ietf.org/doc/draft-ietf-netconf-notif-envelope/)
is already introducing an extensible YANG model for notification
envelopes in this space, which suggests that defining a YANG module
for the capability exchange may be a natural and reasonable step.
If taken, it may also be worth updating the parent https-notif draft
to use application/yang-data+json and application/yang-data+xml for
consistency, though that would be a separate and non-trivial change.
Option 2 — Keep application/cbor; signal encoding via capability URIs
Retain application/cbor for both capability exchange and notifications.
Signal the SID vs. name distinction through dedicated capability URIs
in the capability exchange response, e.g.:
urn:ietf:capability:https-notif-receiver:encoding:cbor:sid
urn:ietf:capability:https-notif-receiver:encoding:cbor:named_identifier
The draft already permits custom capability URIs, and publishers are
required to ignore unrecognised ones, so this requires no structural
changes to either draft. The tradeoff is relying on URI convention
rather than the standardized media-type mechanism — though it fully
resolves the ambiguity. Given that the capability exchange is a
one-time event per session, the performance difference between the
two options is negligible.