[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] Namespace inheritance, other approach
Yes Trevor I agree. I assumed that more than one approach could be legitimized and it would be up to profiles to specify which opaqueness techniques they support. However for the core, I think we will need at least one that MUST be supported for the sake of inter-op. I would vote for the simplest out-of-the-box approach for the default. Perhaps separate transmission of DTD or Schema. -----Original Message----- From: Trevor Perrin [mailto:trevp@trevp.net] Sent: May 27, 2005 1:49 AM To: Martin Centner Cc: dss@lists.oasis-open.org Subject: Re: [dss] Namespace inheritance, other approach Martin Centner wrote: > Hi! > > AFAIK, PIs may appear anywhere in the document. Only the XML > declaration (<?XML ... ) and the document type declaration may only > appear in the prolog. However, those two types do not appear in the > XPath data model so, they cannot be sigend anyway. Thus, they could > simply be omitted when transmitting the whole document withing the <dss:XMLData> element. > When the document type declaration has to be evaluated (ex. for proper > recognition of xsd:Id-attributes) the document has to be re-parsed > anyway. So, why not transmitting it using base64 encoding in this case? At one point we were transmitting the DTD separately, in base64-encoded form. I suppose that's still an option (as is transmitting the DTD within the input document and encoding everything, as is transmitting Schemas, as is eliminating server de-referencing of ds:References, etc.: http://lists.oasis-open.org/archives/dss/200505/msg00019.html ) Is there anything about processing instructions that causes problems, or necessitates base64 encoding? Trevor > > martin > > Edward Shallow wrote: > >> Sorry I did not explain myself, but similar to the "binding the >> content to >> the rendering technique and artifacts" example provided by Rich, >> posting PI >> lines also explicitly declares the rendering engine being used which a >> DSS >> service can log and even bind cryptograhically, as part of the transport >> binding, or better as is illustrated in a vendor-neutral way in Rich's >> excellent example. >> -----Original Message----- >> From: Edward Shallow [mailto:ed.shallow@rogers.com] Sent: May 19, 2005 >> 10:44 AM >> To: 'Rich Salz'; 'Trevor Perrin' >> Cc: dss@lists.oasis-open.org >> Subject: RE: [dss] Namespace inheritance, other approach >> >> Here is a snip of sample PI with the vendor obscured. >> >> <?xml version="1.0" encoding="UTF-8"?> >> <?acme-AcmeSignerSolution PIVersion="1.0.0.0" solutionVersion="1.0.0.1" >> name="urn:schemas-Acme-com:office:AcmeSigner:oob:TravelRequest:1033" >> productVersion="11.0.6357" ?> <?acme-application >> progid="AcmeSigner.Document"?> >> >> >> Ed >> -----Original Message----- >> From: Rich Salz [mailto:rsalz@datapower.com] >> Sent: May 19, 2005 10:24 AM >> To: 'Trevor Perrin' >> Cc: dss@lists.oasis-open.org >> Subject: Re: [dss] Namespace inheritance, other approach >> >> >>> Could you give examples of why we need to put Processing instructions >>> and <?XML ...> lines in <dss:XMLData>? >> >> >> >> My document might have a reference to the XSL stylesheet that renders it, >> and I might want to have the source and the stylesheet signed, and proof >> that I intended them to be linked >> <? xml-stylesheet type="text/xml" >> href="http://www.example.com/foo.xsl"; ?> >> >> >> >> -- >> Rich Salz, Chief Security Architect >> DataPower Technology http://www.datapower.com >> XS40 XML Security Gateway http://www.datapower.com/products/xs40.html >> >> --------------------------------------------------------------------- >> To unsubscribe from this mail list, you must leave the OASIS TC that >> generates this mail. You may a link to this group and all your TCs in >> OASIS >> at: >> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this mail list, you must leave the OASIS TC that >> generates this mail. You may a link to this group and all your TCs in >> OASIS >> at: >> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this mail list, you must leave the OASIS TC that >> generates this mail. You may a link to this group and all your TCs in >> OASIS >> at: >> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. You may a link to this group and all your TCs in > OASIS > at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]