Re: [Cbor] Typed CBOR Objects

[Anders Rundgren <[e-mail]>]

On 2022-02-10 12:21, Henk Birkholz wrote:
> I can see your point. I hesitated for a second, but posted anyways :-)
> And you are not being rude, you called me out and I am... kinda guilty
> as charged.
> Still, this reflects my opinion as a contributor.

Hi Henk,
No problems, all is good :)

If we take EAT which served as an "inspiration", EAT typing is currently
a mixed bag including:

- Specific CBOR tags

- Specific media types (TBD)

- Parameterized media types (TBD):
    https://github.com/ietf-rats-wg/eat/issues/157

- URL/OID based profile info(!):
    https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat-11#section-3.18

Although each developer with some self-esteem consider their applications as
unique and therefore motivate equally unique solutions, I see that as problem
even for my own designs which target Open Banking & payment systems.

The (apparently naîve idea...) was that there could be classes of
applications which could benefit from something along the lines of
https://datatracker.ietf.org/doc/draft-ietf-cbor-file-magic/
but using decentralized URLs instead of registered CBOR tags.

That's all. Well, not really, there is this nagging media type thing as well...

I'm not in any way proposing that consuming applications should download
specifications (even if expressed in a schema).  What I do think is reasonable
is declaring what kind of schema data is associated with and letting
consuming applications kindly report if they don't understand the particular
dialect.  This is an alternative to current Open Banking system which
typically return 500 server error when something is wrong. Armed with
discovery services you can combine robustness with agility which becomes
an issue when the numbers of consuming application entities exceed 100,000
and there is no centralized software certification in place, not to mention
the fact that these systems often are updated at least once a year.

Cheers,
Anders

> 
> On 10.02.22 11:05, Anders Rundgren wrote:
>> On 2022-02-10 10:45, Henk Birkholz wrote:
>>> +1++
>>
>> Henk, I don't want to rude, but maybe you should hold your dismissals
>> until EAT have resolved their typing issues?
>> We are still waiting :)
>>
>> Cheers,
>> Anders
>>
>>>
>>> On 10.02.22 07:43, Joe Hildebrand wrote:
>>>> Agree with Carsten.
>>>>
>>>> Additionally, if you insist on repeating XML's mistakes, can you at
>>>> least make sure that you don't repeat some of the worst consequences
>>>> of those mistakes?  URLs are an attractive nuisance for these
>>>> identifiers, since naively-written processors tend to retrieve those
>>>> URLs drastically more frequently than anyone imagined, thinking that
>>>> they might contain computer-parseable schema information -- which
>>>> turns out not to mostly never work.
>>>>
>>>> If you must have unique identifiers that are easy to mint without a
>>>> new central registry, ask for a non-resolving URI, and make all of
>>>> your examples use RFC 4151 tag: URIs or something that has similar
>>>> properties.
>>>>
>>>> (Note: RFC 4151 is Informational, but useful.  Careful use of a new
>>>> URN space might work, if you must.)
>>>>
>>>> —
>>>> Joe Hildebrand
>>>>
>>>>> On Feb 9, 2022, at 11:20 PM, Carsten Bormann <[e-mail]> wrote:
>>>>>
>>>>> Of course, you can add an indirection, but the most direct way to
>>>>> indicate a new specific data model is a tag.
>>>>> In essence, your TBD211 is exactly that; you have just chosen to add
>>>>> a parameter in the form of a URL or an OID (which is pretty much
>>>>> what you argue AGAINST in the last section…).
>>>>>
>>>>> I’d rather allocate a tag for each specific data model.
>>>>>
>>>>> Grüße, Carsten
>>>>>
>>>>>
>>>>>> On 10. Feb 2022, at 07:02, Anders Rundgren
>>>>>> <[e-mail]> wrote:
>>>>>>
>>>>>> Hi List,
>>>>>>
>>>>>> As a subscriber of the RATS list I noted that I'm not alone looking
>>>>>> for a flexible and extensible way of identifying a CBOR "schema"
>>>>>> (content specification).
>>>>>> Different solutions have been suggested including parameterized
>>>>>> media-types: https://github.com/ietf-rats-wg/eat/issues/157
>>>>>>
>>>>>> Having a background in XML Schema (including WS-*) and similar
>>>>>> concepts applied to JSON, I've sketched up a counterpart for CBOR
>>>>>> that currently only exists in the form of a GitHub issue:
>>>>>> https://github.com/ietf-rats-wg/eat/issues/165
>>>>>>
>>>>>> Using URLs as type identifiers may be regarded as breaking the
>>>>>> desire keeping things nimble.  However, there are lots of possible
>>>>>> applications where a 50-byte overhead would be a no-issue.  For
>>>>>> converting JSON-based designs to CBOR, URLs are a necessity.  For
>>>>>> highly constrained environments, OIDs seems like a useful alternative.
>>>>>>
>>>>>> Feedback would be appreciated.
>>>>>>
>>>>>> Thanx,
>>>>>> Anders
>>>>>>
>>>>>> _______________________________________________
>>>>>> CBOR mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/cbor
>>>>>
>>>>> _______________________________________________
>>>>> CBOR mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/cbor
>>>>
>>>> _______________________________________________
>>>> CBOR mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/cbor
>>>
>>> _______________________________________________
>>> CBOR mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/cbor
>>