[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dss-dev] Data format guessing of data within Base64Data tag
...Maybe the reason for this behaviour could be found in clause 2.4.2,where these two elements are specified. I copy their specifications below: " <Base64XML> [Optional] [Default] This contains a base64 string obtained after base64 encoding of a XML data. The server MUST decode it to obtain the XML data." "<Base64Data> [Optional] This contains a base64 encoding of data that are not XML. The type of data is specified by its MimeType attribute, that may be required when using DSS with other signature types." The first sentence specifying the contents of <Base64Data> seems to me the reason for this behaviour: as the standard seems to mandate NOT XML here, I would say that the application is checking that this requirement is actually satisfied, which I personally feel it is reasonable.....I am aware that my understanding is not built on any "MUST" or "MUST NOT", in which case it would be unarguable...Then the ambiguity lies in 2.4.2. For what I understand, the <Base64Data> tag is defined for everything that is not _necessarily_ XML. <Base64XML> seems specially designed for XML while <Base64Data> is just for plain data. I don't see the rule that enforces mutual exclusion between both tags. IMHO, if there is not "MUST NOT" in the definition and also there is no checking step defined in the processing, the simplest thing is not to parse the octet stream. ...
first of all it should be clear, that no direct violation of conformance is notable.
But, the reason for inventing Base64Data was not, to certify, that the content is no XML. The motivation was: How can we tunnel/embed something not being XML inside an xml container for signing purposes? Just imagine an intermediate version of an xml document neither wel-formed not valid. How would you sign this as "your version of thursday, say 1300 CEST :-?
As a server "programmer" I am still curious what might motivate a service to parse something, the spec sees only as data ... ?
All the best, Stefan.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]