Re: [Cbor] Review draft-bormann-cbor-tags-oid-07

[Jim Schaad <[e-mail]>]

> -----Original Message-----
> From: Carsten Bormann <[e-mail]>
> Sent: Friday, July 3, 2020 3:48 PM
> To: Jim Schaad <[e-mail]>
> Cc: [e-mail]; [e-mail]
> Subject: Re: Review draft-bormann-cbor-tags-oid-07
> 
> Hi Jim,
> 
> thank you for this flash override review :-)
> 
> > On 2020-07-03, at 20:39, Jim Schaad <[e-mail]> wrote:
> >
> > * Section 1 - There has been a recent argument on one of the mailing
> > lists about the question between the value of an encoding and the
> > contents of the value of the encoding.  I think that it needs to be
> > highlighted that this is referring to the V portion of TLV for BER.
> > "The contents of these encodings..." is mostly likely going to cause
> > somebody to have the same problem.
> 
> I added »(the "value" part of BER's
> type-length-value structure)«.
> 
> > * Section 1 - last sentence - What it is being referred to here?
> 
> Last sentence:
> 
> It is intended as the reference document for the IANA registration of the tags so
> defined.
> 
> It = this document?
> 
> Or did you mean the penultimate sentence?  That needed to be fixed; done.

I thought that this was true, but given the distance between "This document" and "It" it was not a sure thing.

> 
> > * Section 2 - What is a "primary integer"?  Is this one that has not
> > yet gone to high school?
> 
> I have no idea.  ASN.1 term?  Ah right, X.660.  Since arcs can be identified both
> by its actual integer value and (not necessarily unambiguous) secondary
> identifiers, the integer value is called “primary” integer value.  Fixed this by
> adding explanation and getting rid of the “primary” elsewhere.

Ah yes - this would have been from 
{ joint-iso-itu-t country us      organization gov csor nistalgorithm hashalgs     sha256(1) }

Which is legal as long as the strings have been defined elsewhere.

> 
> > * Section 2.1 - I don't think it is the tag that is invalid, but
> > rather the value in the tag that is invalid.
> 
> Well, the value (tag content) is a byte string, and there are no validity
> requirements on byte strings.  It is that tag formed out of tag number and tag
> content that is invalid.
> 
> > The "tagged value"?
> 
> We now call that “tag content” in 7049bis.

I really need to try and memorize the new terminology.

> 
> > (Is this a
> > well-formed error?)
> 
> No, a validity error.
> 
> > * You need to update references and text to the CBOR bis document.
> 
> Eventually…  But yes, using the terms from 7049bis helps. Fixed.
> 
> > * Section 5 - Does it make any sense to allow the tags to be specified
> > in a nested manner?  TBD110(X) [TBD111(Y)] ?
> 
> Not sure how that would work.
> Can you give an example?
> 
> I was thinking about stacking tags to deepen their effect into arrays and maps,
> but haven’t quite figured that out either.

I managed to get my numbers backwards above - so that would probably make it harder to understand.   For short things it probably does not matter, but for longer things it might be useful.

tag(111) h'608680165030402' [  / 2.16.840.1.101.3.4.2
  tag(110) h'01',       / .1     sha256
 tag(110) h'02'         / .2     sha???  I would have to look it up, but it is one of the sha-2 hash functions.
]

An array of two hash functions which could be parsed into the two rooted OID values

> 
> > * Section 5 - One way to handle the problem would be to define a new
> > tag which cancels any tag inheritance as a general purpose thing.
> > This might also be useful for other tags which might be defined in
> > this way in the future.
> 
> Yes, but if you generate an example, that becomes unwieldy as well (the
> neutralizer needs to be inserted in awkward places; the CDDL will be
> horrendous).
> So instead of starting out with an infinitely deep effect that then needs to be
> stopped, I was thinking about one-deep plus a way to extend that.
> But first we need a few good examples.

Yeah, the CDDL would be just terrible to write.

> 
> > * Section 7 - I would agree that having an operator that parses string
> > dotted format does not make any sense.  It might be useful to include
> > the .oid operator however which has the property of doing the magic.
> 
> Done.
> 
> > * Section 7 - I need an example of .sdnv because I am having a problem
> > figuring out how it would be used.
> 
> If there is a .fooseq, there should be a .foo for exactly one foo.
> 
> RFC5050blockflags-encoded = bytes .sdnv block-flags block-flags = uint .bits &(
> Block-must-be-replicated-in-every-fragment:       0
> Transmit-status-report-if-block-cant-be-processed:       1
> Delete-bundle-if-block-cant-be-processed:       2
> Last-block:       3
> Discard-block-if-it-cant-be-processed:       4
> Block-was-forwarded-without-being-processed:       5
> Block-contains-an-EID-reference-field:       6
> )
> 
> Well, yeah, any reasonable spec would just carry the uint.

Ok - I thought that I what you meant.  I just could not believe that was true.

> 
> > * Section 7 - If we do nesting behavior on these tags, then a control
> > operator to make A relative to B would be useful as well.
> 
> Again, if you have an example for that, I’m all ears.

root-sha2 = bytes .sdnvseq [ 60 840 1 101 3 4 2 ]
root-sha256 = byte .sdnvseq [ 60 840 1 101 3 4 2 1 ]
rel-sha25 = root-sha256 .oidrel root-sha2

> 
> I pushed an update to https://github.com/cabo/cbor-oid/tree/cleanup; view
> formatted at https://raw.githack.com/cabo/cbor-oid/cleanup/draft-bormann-
> cbor-tags-oid.html — plaintext diff at
> 
> https://tools.ietf.org/rfcdiff?url1=draft-bormann-cbor-tags-oid-
> 07.txt&url2=https://raw.githubusercontent.com/cabo/cbor-oid/cleanup/draft-
> bormann-cbor-tags-oid.txt
> 
> Grüße, Carsten