Re: [Rats] [Cbor] I-D: draft-rundgren-cote-00

[Anders Rundgren <[e-mail]>]

On 2022-07-20 21:32, Michael Richardson wrote:
> 
>> The primary purpose is to enable developers defining community- or
>> application-specific type identifiers without having to go through an IANA
>> registration process. Although the scheme imposes no restrictions on type
>> identifiers (beyond being valid CBOR data items), using URLs should due to
>> their ubiquity be a candidate for CBOR based standards.
> 
> I'm not sure I understand why RATS is on the CC.

Well, the RATS WG is just about to adopt an entirely different CBOR object typing scheme :)
https://mailarchive.ietf.org/arch/msg/rats/D4JNumpn_Le80M1tlCjr8g347aU/


> A URL is rather bulky for some uses, but if the CBOR is encoding thousands of
> items in a compact form, then the amortization of the tag makes sense.

COTE represents an alternative, not a "competitor".  For the type of work I do with CBOR (taking it to the financial industry), the overhead is insignificant compared to the associated payloads.  That the predecessors that mostly are based on XML come with URL- or URI-based identifiers is another motive.

The core idea behind URL-based identifiers is making identifiers point to their actual definition.  Some recent standards like https://www.w3.org/TR/payment-request/ even require URL-based payment method identifiers to be pointing to machine-readable data which is used by browsers for invoking associated (but locally installed) applications!

COTE outlaws such uses but supports "browsable" identifiers.


> draft-ietf-cbor-file-magic provides a similiar mechanism with the
> recommendation that one go for a 4-byte tag from the FCFS space.
> yes, that involves a trip through IANA... an email and a delay of perhaps a
> week.

> I agree with Carsten that the document is a bit underspecified.

You are welcome with additional input.  I hope to do a real 00-submission next week that will include an appendix dealing with "URL Identifier Management".

As Carsten also pointed out, the CBOR WG has a bit of homework to do in order to create a robust repository of tags and associated (URL-based) definitions.

Cheers,
Anders