OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss-dev message

[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


Dear Juan Carlos,

> 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.

Kind regards,
Daniel M. Lambea



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]