Signature Syntax & Processing draft questions:

Telecon: Not very
strong opinion: people not strongly opposed (but concerned about potential bloating) nor
strongly in favor (though should provide cleaner in exposition). RESULT: Change to
Solo's suggested "References".

When Object is used for data (as specified in the Type attribute), do not include
start/end tages in hash and auto-decode per any Encoding attribute. (If 5 and 6 below are
adopted it might be possible to drop the Type attribute on Object and use it only for
data, or change to a MimeType
attribute or the data, which is what it was earlier. Currently the Type attribute is used
up to distinguish between data/manifest/package/signatureproperties.)

Eastlake: this
would make the type reference in manifests mandatory.

Simon: would like an attribute that says whether you want the container tags or not.

Reagle: what happens if you have a ::child() and a reference with a strip=""
attribute? Telecon: The application would strip the object, then find the child (basically
take the granchildren of Object).

Reagle: If our concern is referring to manifests, just use an ID in the Manifest
element and refer to that! Concerns about moving an encoded object from within an object
to elsewhere would be more tricky. Boyer: wrote an email to Himes on how to do this, will
send to list.

RESULT: no change, but clarify text that references can ref to Manifest directly.

Permits Object(s) inside SignedInfo.

Might make the signature more compact, but might
complicates things with respect to understanding how to process (flexibility =
complexity). RESULT: no change.

Pull Manifest/Package up to the level of Object.

Pull SignatureProperties up to the level of Object.

Eastlake: removes extra level of
nesting.

Reagle: likes to keep an Object as the bucket to place non-core syntax and semantics.

Fox: wants a strong reason for us to make a change.

RESULT: no change, but add some text that manifests and signature properties can appear
anywhere the paren'ts content model permits; the signature content model only permits them
in Object.

Accomplish 2 and 4 by using the existing Mainfest element.

RESULT: no change (given
above).

Proposed Comments text.

Eastlake and Simon talked on list. If text is agreed to, will
be sent to editors.