W3C home > Mailing lists > Public > xmlschema-dev@w3.org > March 2001

What to do with CryptoBinary?

From: Joseph M. Reagle Jr. <reagle@w3.org>
Date: Mon, 26 Mar 2001 17:01:32 -0500
Message-Id: <4.3.2.7.2.20010326145542.02cb5008@rpcp.mit.edu>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 11 January 2011 00:14:20 GMT