How to identity full SID vs. delta in CBOR encoding

[abierman]

The procedures for encoding SIDs as keys could be more precise. How does a decoder tell if a SID as a key is a full SID or a delta from the parent? They are encoding exactly the same so a large delta could be a full SID.

Apparent procedure:

1) first node must be a full SID (there is no parent yet) 2) each nested map or array must be encoded as a delta to the parent and this starts a new parent for delta calculation 3) the decoder never looks above the current map or array for the delta in the event a name is used instead of a SID for the current map or array 4) if a name is used for the key to start a map or array then none of descendants of this map or array can be identified with SID keys

There are no examples of mixing names and SIDs as keys. The text as written seems to support the interpretation above.

[abierman]

The forced delta SID encoding does not support the use-case of data injection by tools. Our customers do this all the time with XML. An interior portion of an XML instance document is pre-made (e.g. edit-config payload). Since XML was designed by people who understand why stateless is good, the entire XML instance document is still valid. The XML file snippet can be unaware of the ancestor nodes.

If the entire subtree must always be encoded top-down, then this canned data implementation approach will not be possible. It is therefore useful to allow a full SID within a subtree so a valid subtree can be injected into a CBOR message.. Note that this property is maintained if names as keys are used throughout

[mcr]

I thought that there was a CBOR Tag that indicated that the value was not delta encoded.

[abierman]

A CBOR tag for a full SID would fix the problem. The examples show both full and delta as plain integers.

[abierman]

There is 1 sentence that says a tag may be used

  To minimize their size, SIDs used as keys in inner CBOR maps are
   typically encoded using deltas.  Conversion from SIDs to deltas and
   back to SIDs are stateless processes solely based on the data
   serialized or deserialized.  These SIDs may also be encoded as
   absolute number when enclosed by CBOR tag 47.

I do not see any examples of this usage. It should be definitive. "typically encoded" and "may also" should be changed to a specific normative procedure.

I get it that many details are left to the protocol definition but this detail is specific to the CBOR encoding, not the protocol. It should be simple and efficient to implement a decoder.

[cabo]

An integer as a map key is always a delta SID, relative to the current SID value inherited to the map. A tag 47 is always an absolute SID.

Of course, the tree needs to start, and the inherited value starts at zero (so the first level of SIDs is indistinguishable from an absolute SID, but not because they are, but because adding the delta to zero makes it look that way).

No open issues, no freedom for implementation variance.

If the text needs to be fixed to reflect this design, we should do that.

[cabo]

I can't find what should be assumed as »the SID of the parent 'container'« for a name-referenced node.¶

If we know the SID, this could be:

{
  "ietf-system:system-state" : {                              / system-state (SID 1720) /
    1 : {                               / clock  (SID 1721) /
      2 : "2015-10-02T14:47:24Z-05:00", / current-datetime(SID 1723)/
      1 : "2015-09-15T09:12:58Z-05:00"  / boot-datetime (SID 1722) /
    }
  }
}

But we don't always know the SID for a name, so more robust would be starting from zero again:

{
  "ietf-system:system-state" : {                              / system-state (we don't have to know a SID here) /
    1721 : {                               / clock  (SID 1721) /
      2 : "2015-10-02T14:47:24Z-05:00", / current-datetime(SID 1723)/
      1 : "2015-09-15T09:12:58Z-05:00"  / boot-datetime (SID 1722) /
    }
  }
}

[mcr]

An integer as a map key is always a delta SID, relative to the current SID value inherited to the map. A tag 47 is always an absolute SID.

Of course, the tree needs to start, and the inherited value starts at zero (so the first level of SIDs is indistinguishable from an absolute SID, but not because they are, but because adding the delta to zero makes it look that way).

If I have a mixed SID/name encoding:

{
  "ietf-system:system-state" : {                             
    1721 : {                               / clock  (SID 1721) /
      "attestation-details": { 
            4 : "2015-10-02T14:47:24Z-05:00",  / epoch handle time
            5: "abce8234", / handle value
      }
      1 : "2015-09-15T09:12:58Z-05:00"  / boot-datetime (SID 1722) /
    }
  }
}

Are 4 and 5 relative to 1721?

[abierman]

This is good text an should be in the draft

An integer as a map key is always a delta SID, relative to the current SID value inherited to the map.
A tag 47 is always an absolute SID.

So the examples that all show a full SID as an Unsigned need to be changed to use tag 47/

[cabo]

This is good text an should be in the draft

An integer as a map key is always a delta SID, relative to the current SID value inherited to the map.
A tag 47 is always an absolute SID.

So the examples that all show a full SID as an Unsigned need to be changed to use tag 47/

I don't think we have examples that show an absolute SID in a position where there is a non-zero reference SID. An absolute SID value is the right delta value in the examples we do have with reference value zero (except for the one at the end of 4.5.1 where we do show tag 47).

[cabo]

This should now be addressed by #82.