Re: [Cbor] Private tag numbers

[Anders Rundgren <[e-mail]>]

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
> 
> 
>