[Cbor] Re: Private tag numbers / 1010

[Vadim Goncharov <[e-mail]>]

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.

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



-- 
WBR, @nuclight