[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] Namespace inheritance, other approach
Folks, This wholw tree and sub-tree discussion is fine, and I believe we are getting closer to consensus. But please remember we still have occassions where some form of encoding/escaping will always be required (i.e. <?XML ...> declaration lines and PI lines which would precede the root). This is the "whole document" scenario which we have not outlawed and is a legitimate use-case. Hence the "encoding=" attribute that we are contemplating that we borrowed from "ATOM" would have to support, at a minimum 1) xml (the default perhaps), 2) escaped, and 3) base64. Cheers, Ed -----Original Message----- From: Martin Centner [mailto:martin.centner@labs.cio.gv.at] Sent: May 18, 2005 10:07 AM To: dss@lists.oasis-open.org Cc: Konrad Lanz Subject: Re: [dss] Namespace inheritance, other approach Hi Trevor, Hi everyone, maybe I can help to explain the issue my colleague Konrad is concerned about ... If some transforms are applied on the client side and some transforms are applied on the server side the intermediate result has to be transmitted from the client to the server. This is trivial if the intermediate results are octets. However, it gets tricky if the intermediate result is a node-set. The node-set to be transmitted is a set of nodes of an underlying parse tree A. To transmit the node-set it has to be serialized or canonicalized somehow. If the node-set does not include all nodes of the underlying parse tree, re-parsing the canonicalized node-set will result in a different parse tree B. This will likely effect any further transforms applied on the server side - including canonicalization. Thus, transmitting an arbitrary node-set from the client side to the server side is not more than an implicit C14N-transformation. Therefore, this transformation should be reflected in the list of <ds:Transforms> of the corresponding <ds:Reference> element. Whether exclusive or inclusive canonicalization is used does not matter in this case. However, there are cases where the difference in the two parse-trees A and B may not be relevant to the subsequent transforms. For example, if the node-set to be transmitted are the nodes of a complete subtree of A. In this case the octets to be transmitted may be obtained by serializing the corresponding subtree of A. Therefore, in some cases it may not be necessary for the client to implement C14N and the C14N-transformation may be omitted from the list of <ds:Transforms>. Thus, it could be left to the client to take appropriate measures in order to make the resulting signatures verifiable. However, it may be wise to make implementers aware of the issue mentioned above. Kind Regards, martin --------------------------------------------------------------------- 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]