Explicitly state that "combination" is a valid form of "reconstitution." (i.e. after storage)

[GoogleCodeExporter]

The draft states that it defines "messages that may be transformed, 
converted, stored, and reconstituted in arbitrary ways". However, there 
isn't much said about what kinds of transformation or reconstitution are 
expressly permitted. I'd like to suggest at least one example that should 
be mentioned -- at the same time that I wish to confirm that this example 
is meant to be supported.

Given two Magic Envelopes that have a common payload but different sets of 
signatures, it seems to me that it should be possible to transform the two 
Magic Envelopes into a single Magic Envelope that contains the common 
payload as well as the union of all signatures contained in each of the 
original Magic Envelopes. This property would be very useful in 
applications that store data since it means that, in some cases, it would 
be possible to compress multiple Magic Envelopes into a single, more space 
or bandwidth efficient representation without any loss of semantics. An 
ability to "compress" multiple similar MEs into one record would also make 
it possible to simplify or optimize some database schemas that might be 
used for storage.

This "combination" property seems to be supported in the current draft 
since while the content of signatures is dependent on the payload, there is 
no dependency between the payload and the signatures. This independence of 
the payload from anything in the surrounding envelope is an important 
property of the Magic Signature method and stating it either explicitly or 
implicitly (in the form of an example that requires it -- such as 
combination) would make it more likely that any attempt to modify the spec 
in the future will maintain this property.

Original issue reported on code.google.com by bobwyman on 21 Apr 2010 at 3:53

[GoogleCodeExporter]

I agree, it seems useful to have something in the spec which makes this 
constraint more visible -- basically the "data" content does not depend on and 
does not need to know about any signatures that might be orbiting it.  But we 
also want to keep the spec simple.  Perhaps now that we support multiple 
signatures, it would be a good idea to have an example that shows a second 
signature being added to an existing one-signature example?  Bob, do you have 
some sample spec text diffs that we could add in, based on the latest June 
draft for Magic Signatures?

Original comment by jpanzer@google.com on 28 Jun 2010 at 8:13