Re: [Cbor] Private tag numbers

[Vadim Goncharov <[e-mail]>]

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



-- 
WBR, @nuclight