Subject: [Cbor] Typed CBOR Objects

From: Anders Rundgren <[email-masked]>
Date: Thu, 10 Feb 2022 07:02:42 +0100

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

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 10 Feb 2022 07:20:53 +0100

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 <[email-masked]> wrote:
> 
> Hi List,
> 
> _______________________________________________
> CBOR mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cbor

---

From: Joe Hildebrand <[email-masked]>
Date: Wed, 9 Feb 2022 23:43:11 -0700

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 <[email-masked]> wrote:
>

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 10 Feb 2022 08:25:45 +0100

> Of course, you can add an indirection, but the most direct way to indicate a new specific data model is a tag.

I certainly do not disagree with that!

What is not equally clear is what to do if you want to address the space currently occupied by JSON which is pretty much what this proposal is about. Deprecating URLs as type identifiers?

In addition, it is (as seen by the EAT discussions), often insufficient to just define a tag, you must typically define an associated media type as well.

However, media types are of little value when objects are embedded in other objects which is another sub-goal of this design.

Joe Hildebrand: the URL is not pointing to a machine-readable schema [*], it points to a specification to achieve decentralization.  Using non-resolving URIs is a deployment option.

For EAT, the alternative seems to be parameterized media types to achieve the *desired indirection*.  Is this the future for CBOR?

BTW, the following is rather much the same thing, only in a less universal way:
https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat-11#section-3.18
It was this and the parameterized media types that got me going :)

Cheers,
Anders

*] If someone want to create such a system they can do that; it not a part of THIS specification.

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 10 Feb 2022 10:45:37 +0100

+1++

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 10 Feb 2022 11:05:29 +0100

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

---

From: Joe Hildebrand <[email-masked]>
Date: Thu, 10 Feb 2022 03:59:31 -0700

> On Feb 10, 2022, at 12:25 AM, Anders Rundgren <[email-masked]> wrote:
> 

They weren't in XML either, but that didn't stop a bunch of XML tooling from dereferencing the URL *every time* a document was parsed.  Some of those tools even had caches, but they didn't cache negative results, if I recall correctly.

If you say "URL", then URNs and tag: URIs probably aren't valid.  If you say "URI", put in a bunch of words that say "these are for humans, tools MUST NOT dereference these", then someone will still write bad tools, but at least you'll be able to feel like it wasn't as much your fault.

-- 
Joe Hildebrand

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 10 Feb 2022 12:15:44 +0100

> What is not equally clear is what to do if you want to address the space currently occupied by JSON which is pretty much what this proposal is about. Deprecating URLs as type identifiers?

I think you are talking about JSON-LD here.
It is indeed a worthwhile undertaking to create a CBOR-LD (no, not the existing draft with that name, that does almost nothing), but this will go way beyond specifying a specific data model for a whole interchanged data item.

Grüße, Carsten

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 10 Feb 2022 12:21:24 +0100

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.

On 10.02.22 11:05, Anders Rundgren wrote:
> 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
> 
>>
>>> 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.
>>>
>>>> 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…).
>>>>
>>>>> 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.
>>>>>

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 10 Feb 2022 13:42:21 +0100

> 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