[Cbor] Re: Private tag numbers / 1010

[Anders Rundgren <[e-mail]>]

On 2024-12-15 01:14, Vadim Goncharov wrote:
> Hi,
> 
> Regarding https://datatracker.ietf.org/doc/draft-rundgren-cotx/05/ of
> tag 1010, please provide ability for identifier to be a non-text string
> until this is not an RFC.

Well, for unknown reasons the CBOR WG have rejected the by other formats firmly established method using dereferenceable specification URLs as object identifiers, so it seems COTX will remain my private "invention" :)

Anyway, I'm not a fan of "polymorphic" tags so I would urge you to seek a new tag number (hopefully a bit more compact than 1010), for a version using a binary argument.

Regards,
Anders

> 
> E.g. for 1010([37(binary-UUID), ...]) or SHA256 of object or
> something other (like referring previous string in a table) - the goal
> here is to allow more *compact* representation, like that of "@context"
> in JSON-LD (of which CBOR-LD took wrong way of not using CBOR tags
> capabilities).
> 
> On Sun, 23 Jul 2023 09:15:50 +0200
> Anders Rundgren <[e-mail]> wrote:
> 
>> If you don't put the private tag in a tag construct (where it could
>> clash with other tags), you could start using the solution today.  I
>> would consider a construct like
>>
>>      Your Registered Tag([Private Number, Actual CBOR Object])
>>
>> which eliminates the need for a standard based on reserving a range
>> of tag values that I guess are associated with a specific tag
>> syntax/interpretation.
>>
>> Other ways ahead: the JSON and XML folks seem to be quite happy using
>> URLs/URIs.  Why couldn't CBOR users do that as well?
>> https://www.ietf.org/archive/id/draft-rundgren-cotx-04.html
>>
>> The potential waste of bytes is hardly an issue except for very
>> constrained systems.  If this indeed is an issue, OIDs represent a
>> since long establish method for getting your own global (and possibly
>> private) namespace.
>>
>> Anders
>>
>> On 2023-07-23 0:05, Vadim Goncharov wrote:
>>> Hi Carsten and Tony,
>>>
>>> I'd still argue it's better bring up the older idea of
>>> "per-enterpise tag spaces" - that is, where IANA register just one
>>> "container" tag per organization, and there is a range of tag space
>>> of actual "private" tags shared between all that enterprises.
>>>
>>> E.g. tag 1234560 for Microsoft and 1234561 for FreeBSD, and 234567
>>> for some data, which will have different meanings depending on which
>>> container it's inside:
>>>
>>>        1234560(["name", 234567({
>>>          "hi": "there"
>>>        })])
>>>
>>> and
>>>
>>>        1234561(["name", 234567({
>>>          "hello": [-122.5, 37.43]
>>>        })])
>>>
>>> And enterprise tag number contatiner will be close to top-level of
>>> CBOR document. This is in spirit of RFC 5424 which has enterprise
>>> numbers (iso.org.dod.internet.private.enterprise registered per RFC
>>> 2578) for interpreting keys within it's sections:
>>>
>>>         [exampleSDID@32473 iut="3" eventSource="Application"
>>>          eventID="1011"][FreebsdField@2238 priority="high"]
>>>
>>> (32473 registered as example enterprise for RFC/documentation)
>>>
>>> This way, if ever private tags need to be exposed to public (as in
>>> your analogy with 10.0.0/8), then organization may publish a spec
>>> for the tag pair - e.g. for 1234561's 234567.
>>>
>>> It's still to be thought about from which range to allocate blocks
>>> (may be several, for each byte-length range), and other questions,
>>> but I hope you get the main idea.
>>>
>>> On Sat, 22 Apr 2023 10:34:05 +0200
>>> Carsten Bormann <[e-mail]> wrote:
>>>    
>>>> Hi Tony,
>>>>
>>>> thank you for asking this question.
>>>> CBOR has a somewhat evolved view of the tag namespace (number
>>>> space), and it may not be obvious.
>>>>
>>>> On 21. Apr 2023, at 18:53, Tony Putman <[e-mail]>
>>>> wrote:
>>>>>
>>>>> Hi all,
>>>>>    I'm defining a data schema for purely internal use (no
>>>>> interoperability needed)
>>>>
>>>> This is known as “famous last words” :-)
>>>> A lot of organizations have learned that they do need to connect
>>>> their “private” net 10 IP addresses once they purchase or merge
>>>> with other organizations. I think the same applies to tag numbers,
>>>> even more so because sharing data is more loosely coupled than
>>>> sharing networks, and you may find a need to integrate your data
>>>> with data from other sources that have tags “for purely internal
>>>> use".
>>>>> and encoding it in CBOR. There are points where we may want to
>>>>> vary/extend the contents with new data, and I thought the natural
>>>>> way to do this would be to define different tags to hold the data.
>>>>> I expected to find a set of tag numbers defined in IANA for
>>>>> private use, but there don't appear to be any.
>>>>
>>>> Indeed, because “private use” may be an illusion for the above
>>>> reason.
>>>>
>>>> (Note that we have a different kind of tags, for contextual use
>>>> [1]. I’m not talking about those.)
>>>>
>>>> [1]:
>>>> https://www.ietf.org/archive/id/draft-bormann-cbor-notable-tags-07.html#name-enumerated-alternative-data
>>>>   
>>>>>    - Is this a misuse of tags?  And if so, what would be the more
>>>>> natural way to specify this?
>>>>
>>>> You didn’t say much, but what you said leads me to believe that
>>>> tags are a good way to address your requirement.
>>>>   
>>>>> - Is this a general problem that people face and would it be worth
>>>>> defining a set of private tags which are known to be
>>>>> context-sensitive and not interoperable?
>>>>
>>>> Why share a set of (then not so) “private” tags when you can have
>>>> your own, *actually* private ones?
>>>>
>>>> My recommendation would be:
>>>>
>>>> Make a good guess at how many tags you’ll need, and get a block of
>>>> tags registered from the FCFS space for your needs. (You don’t need
>>>> to be overly large with that number because you can always go back
>>>> for more.) Call them Dyson-0 to Dyson-4711 if you want.
>>>>
>>>> Run your own internal tag registry assigning your private meanings
>>>> to your IANA-assigned private tags. And, of course, once you are
>>>> surprised by noticing that your “private” use is no longer really
>>>> so private, update the IANA registry with some information about
>>>> some of the tags (e.g., specifications) at your leisure.
>>>>
>>>> We would like you to use the space from 65536 up (1+4 space) unless
>>>> you need a humungous number (for which we have the 1+8 space).
>>>> There also is a limited FCFS space from 32768 to 65535 (in 1+2
>>>> space), but you don’t want to take an out-of-proportion chunk of
>>>> those (and only if the size of the tag representation matters a
>>>> lot for your application).
>>>>
>>>> Today’s tag usage report:
>>>> range  used     %                 free                total
>>>> 0 1+0    13 54.17                   11                   24
>>>> 1 1+1    70 30.17                  162                  232
>>>> 2 1+2   438  0.67                64842                65280
>>>> 3 1+4 65284  0.00           4294836476           4294901760
>>>> 4 1+8     2  0.00 18446744069414584318 18446744069414584320
>>>>
>>>> (Remember that this reflects the first ~ 10 years of allocation,
>>>> which also might ramp up a bit over time — this space needs to hold
>>>> for many more decades.)
>>>>
>>>> Grüße, Carsten
>>>>
>>>> _______________________________________________
>>>> CBOR mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/cbor
>>>
>>>
>>>    
>>
> 
> 
>