Tracking issue: securing CBOR tag registry entry for dag-cbor

[rvagg]

Sorry for opening a new issue just as we're closing a ton but this really can't get lost and should be fairly high priority since so much is invested in dag-cbor already and it would be incredibly traumatic to have to switch from 42.

Brief history: dag-cbor has been using CBOR tag 42 for Link encoding. This wasn't registered with the CBOR tag registry @ https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml and was recently assigned to the YANG data modelling language for storing their Secure Item iDentifiers (SID) as per https://tools.ietf.org/html/draft-ietf-core-yang-cbor-10#section-4.2.1

An issue has been opened to discuss it with them @ core-wg/yang-cbor#13 and they seem amenable to changing as this is an early stage CBOR migration process for them.

This issue is to: (1) publicly note that this is an ongoing concern, (2) a reminder that we need to monitor and continue to make progress with YANG and (3) get dag-cbor onto the IANA CBOR tag registry.

[Stebalien]

Sorry for opening a new issue just as we're closing a ton but this really can't get lost and should be fairly high priority since so much is invested in dag-cbor already and it would be incredibly traumatic to have to switch from 42.

To be honest, we'd probably just accept the situation and not switch. The nice thing about clearly distinguishing between the cbor codec and the dag-cbor codec is that this is unlikely to be an issue in practice (although it still kind of sucks).

[vmx]

I feel responsible for this issue and I'll make sure it moves forward.

[rvagg]

The cost of letting an issue tracker collect cobwebs, check this out: #40 & the linked ipfs/specs#75 that was never merged.

[vmx]

Current state: tag 42 is unassigned, I've created a spec which hopefully get us that tag assigned: https://github.com/ipld/cid-cbor/

[vmx]

Done:

• CBOR tag conflict :( core-wg/yang-cbor#13 (comment)
• https://www.iana.org/assignments/cbor-tags