[Cbor] Re: Private tag numbers / 1010

[Vadim Goncharov <[e-mail]>]

On Sun, 15 Dec 2024 06:18:10 +0100
Anders Rundgren <[e-mail]> wrote:

> 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" :)

Are there discussions? In list of allocated tags I haven't found
anything like this (like 1010).

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

Well, I am not fan of meaningless duplication of tags - we already had
that duplication mistake with IPv4/IPv6 tags. It would have just the
same format - reference to to a type description and value itself. Just
reference could be not a text URL but something more machine-friendly
and more compact. If antoher tag would be taken, it should have another
meaning, IDK, may be like "@context" in JSON-LD... though that's still
pretty much close meaning.

It probably won't even change your implementation - just continue to
throw error on non-URLs in your specs/implementations, so that's other
values are for another software. So I don't understand why artificially
limit scope - exept URI, there are XRI generalizing it, there are DIDs,
etc.

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