[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: FW: FW: [dss] OASIS DSS - SignatureObject on Input
At 10:39 AM 9/17/2004 -0400, Edward Shallow wrote: >Good stuff Trevor I think we're getting there, [...] > I think our little "transport element" debate is interesting, but my >larger unaddressed concern is the text across these 4 documents as they >pertain to timestamping. > > Forget about the mechanics of SignaturePlacement, DocumentWithSignature, >SignatureObject, (Document, DocumentBaseType, InputDocuments), Poperties (as >they might apply to timestamps as Gregor suggests), ReturnUpdatedSignature, >UpdateSignatureOnly, AddTimestamp, DocumentWithTemplate, SignatureForm, >DocsToBeTimeStamped, GenerateAsCounterSignature, and the list goes on ... > > Can this "text improvement" issue, across all documents, be officially >addressed as an Action ? We had talked about sometime producing a "roadmap" or "overview" document describing the profiles and how they relate to each other. I'm not sure it makes sense for the Core to talk about which profiles you should use, for example. >***************** >Now I'd like to get back to the DocumentWithSignature discussion and the >larger "transport element" issue. > >Collapsing DocumentWithSignature "in content but not in name" is simply >confusing, especially when one is allowed to qualify documents as signatures >through attributing. Okay, then why don't we wrap a <Document> within a <DocumentWithSignature> output, in the same way we've wrapped a <ds:KeyInfo> within an <AdditionalKeyInfo>? Preserving the <Document> addresses your concern, and wrapping it in a special element addresses my concern that we want the semantics of the returned element to be clear. Trevor
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]