--- Scott Cantor <[EMAIL PROTECTED]> wrote: > > There is no spec in XML-land that says base64 > content uses any particular > line length. > So, for example, if the original base64 encoded data comes through SMTP, we will have to decode and encode it again if we have to put the same value in an XML? > > That's advisory only, and XML schema mostly deals > with what normalization > results in, not with the raw XML is. >
I guess I am failing to understand how 'advisory' can be construed as 'do not do it'. XML-schema spec says 'This line-length limitation is not mandated in the lexical forms of base64Binary data and must not be enforced by XML Schema processors.' - which I interpret as 'RFC2045 is NOT a must - so do not enforce it' - rather than as 'RFC2045 is wrong - make sure there are no new lines'. The same spec (XML-Schema) also explains that the whitespace facet of base64Binary is fixed to 'collapse' - so a schema validator will indeed convert new lines to spaces. But this is still OK - as all the new lines will be converted to spaces - the logic for using OpenSSL's flag I gave earlier will still work (spaces are neglected by base64 decoders). What I am driving at is that having new lines in base64 encoded data is not restricted by any spec - in fact it is deemed necessary by at least one spec. And also that you can make your decoder flexible by checking and setting the flag as I mentioned earlier. But normalization is a real problem for signature validation, as you mentioned earlier - looks like whitespace facet for signed content must always be preserve - particularly if you have schema validators before signature verification. -rams __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
