Re: [Suit] [suit]: draft-moran-suit-manifest-02

[David Brown <[e-mail]>]

On Fri, Jul 06, 2018 at 01:50:38PM +0000, Rønningstad, Øyvind wrote:

>How about making more information severable (like with text)? Some information
>is short-lived, like the processing steps, while other information could be of
>interest after the update is complete, like the postConditions and sequence
>number. I'm wondering if we can make a split, so the relevant parts of the
>manifest can be stored for later reference. Something like the following:

I have another proposal for this.

Motivation: The manifest will be processed by different entities that
will differ in processing capability.  We want to make it easy to
include potentially complex information in the manifest, without
having to burden lower-resource entities that don't need to process
this information.  The goal is to make the manifest format more
generally processable.

Proposal: Assocate with each entity in the manifest additional
information describing the audience for that information.  

One way to do this would be to change the top-level of the manifest to
something like:

Manifest = [
  manifestVersion: 1,
  digestInfo:      DigestInfo,
  sequence:        SequenceNumber,
  info:            { * int => bstr }
]

This would be similar to how extensions are handled, except that all
of the existing instructions would be formatted in the same way.  A
given entity would know the fields that it is able to process, and any
other fields it can simply skip (as it is just a bstr).

This adds some complexity to the normal processing, and it would be
important to require, for example that the entries in 'info' are in
order by key in order to have a canonical representation.

David