search

ietf-rats / ietf-corim-cddl

This repository is abandoned. The adopted I-D can be found at:
https://github.com/ietf-rats-wg/draft-ietf-rats-corim/
2 stars 0 forks source link

raw-value type should be extensible #115

Closed nedmsmith closed 3 years ago

nedmsmith commented 3 years ago

Somewhat related to PR #75 in https://github.com/ietf-rats/draft-birkholz-rats-corim/pull/75/files on extensibility points.

The raw-value-group should have better extensibility. This is most easily achieved by making raw-value-type extensible (e.g. $raw-value-type-choice). It would be beneficial for the raw value to be a tagged-type-choice as well. e.g.:

raw-value-group = (
  comid.raw-value => $raw-value-type-choice
  ? comid.raw-value-mask => raw-value-mask-type
)
$raw-value-type-choice /= tagged-raw-value-type
$raw-value-type-choice /= raw-value-type
raw-value-type = bstr / tstr
; $6.XXX to be allocated from the first-come-first-served range
tagged-raw-value-type = #6.XXX(raw-value-type)

From an extensibility point perspective, can the CDDL be complete if tagged-raw-value-type doesn't define any #6.4711 values initially?

nedmsmith commented 3 years ago

If there are #6. code points for tstr and bstr then it would be possible to simplify the definition to always be a tagged-raw-value-type. #6.(tstr) and #6.(bstr) could be the only two types defined in the spec, but others could extend using different #6.XXX code points.

thomas-fossati commented 3 years ago

hi Ned, IIUC, what we'd need -- to start with -- is just something like:

raw-value-group = (
  comid.raw-value => $raw-value-type-choice
  ? comid.raw-value-mask => raw-value-mask-type
)

$raw-value-type-choice /= bytes
$raw-value-type-choice /= tstr

raw-value-mask-type = byte

with the requirement with regards to extending $raw-value-type-choice that if the underlying type happens to be the same as one of the existing ones, one needs to wrap it in a tag.

This way we wouldn't need to define any tag now, and let it be a future problem of the "extensor".

nedmsmith commented 3 years ago

A subsequent definition could be:

$raw-value-type-choice /= tagged-raw-value-type
tagged-raw-value-type = <some-tag><some-value>
thomas-fossati commented 3 years ago

A subsequent definition could be:

$raw-value-type-choice /= tagged-raw-value-type
tagged-raw-value-type = <some-tag><some-value>

yes, and the tag would be defined only at the time that definition is introduced. lazy registration :-)

nedmsmith commented 3 years ago

Based on PR #125 the tag #6.560 means the following byte string would contain the same information that was in bytes pre PR#125. Anyone can use the 560 tag for any purpose which seems to address any backward compatibility issues. If an entity wanted to create a more sophisticated raw value structure, that could be achieved.

One possible consideration is whether or not the bitmask would also need to be tagged in order to allow the mask to be defined with the similar level of sophistication.

However, given the tag on the type, that might be enough context to know how to interpret the mask bits also.