- From: Joseph M. Reagle Jr. <reagle@w3.org>
- Date: Mon, 26 Mar 2001 17:01:32 -0500
- To: "IETF/W3C XML-DSig WG" <w3c-ietf-xmldsig@w3.org>
- Cc: xmlschema-dev@w3.org
xmldsig defined (and other security applications have adopted) the following useful type: <simpleType name="CryptoBinary"> <restriction base="binary"> <encoding value="base64"/> </restriction> </simpleType> However, the recent Schema Proposed REC [1] eliminated the "binary" type and creates "base64Binary" and "hexBinary" types. I think this is a good thing in general as we did the same ourselves, but now we have to make a decision. Signature can 1. persist with its CryptoBinary, which is now redundant and encourages the use of another type needlessly. The definition is now: <simpleType name="CryptoBinary"> <restriction base="base64Binary"> </restriction> </simpleType> 2. Remove the CryptoBinary type. On the namespace issue, my rule of thumb has been that if I'm not breaking processors or instances from one version of the spec to the next, then there's no need to change the namespace. This doesn't break any instances nor processors, but seems to be in a gray zone... So we could: A. Continue with #1 for legacy purposes but warn others to use xsd:base64Binary when appropriate. B. Remove CryptoBinary and change the dsig namespace. C. Remove CryptoBinary and not change the dsig namespace. Thoughts? [1] http://www.w3.org/TR/xmlschema-2/#base64Binary __ Joseph Reagle Jr. http://www.w3.org/People/Reagle/ W3C Policy Analyst mailto:reagle@w3.org IETF/W3C XML-Signature Co-Chair http://www.w3.org/Signature W3C XML Encryption Chair http://www.w3.org/Encryption/2001/
Received on Monday, 26 March 2001 17:01:34 UTC