W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > April to June 2000

Re: XML Schema WG response to the DSig Last Call WD

From: Joseph M. Reagle Jr. <reagle@w3.org>
Date: Thu, 11 May 2000 16:37:51 -0400
Message-Id: <3.0.5.32.20000511163751.009cc640@localhost>
To: "Biron,Paul V" <Paul.V.Biron@kp.org>
Cc: <w3c-ietf-xmldsig@w3.org>, "'w3c-xml-schema-ig'" <w3c-xml-schema-ig@w3.org>
At 09:29 00/03/24 -0800, Biron,Paul V wrote:
 >The Schema WG believes that there are no major issues with the dsig last
 >call WD [1].  However, the draft schema specification(s) has undergone
 >considerable change since the 1999-12-17 draft [3] on which the schema
 >fragments in Section 4 "Core Signature Syntax" are based.  The Schema WG
 >therefore requests that the XML Sig WG rewrite all schema(s) used in
 >defining dsig in terms of the schema specification current when schemas
 >reaches CR.

Paul (and the schema IG),

Thanks again for your comments. The disposition of your comments that
includes more explicit references to appropriate emails/minutes are at:
        http://www.w3.org/Signature/20000228-last-call-issues.html#schema

To respond to your email more directly: We've updated our draft to comply
with the syntax of the Schema Last Call. The latest draft can be found at:
        http://www.w3.org/TR/2000/WD-xmldsig-core-20000510/
This draft reflects most of our responses to all the comments sent during
last call. Those issues not yet marked done, in combination with the
editorial to-do's (as stated in that STATUS of the spec) will be addressed
within the next few weeks (prior to going to CR).

 >Additionally, there are several cases in which more judicious use could be
 >made of Schema Datatypes.  For instance, Section 4.2 "The SignatureValue
 >Element" contains the actual signature octet sequence, base64 encoded--it
is
 >declared as a string, it should be a binary with the encoding facet equal
to
 >base64;  

Ok, we've done this:

   <simpleType name='CryptoBinary' base='binary'>
       <encoding value='base64'/>
   </simpleType>


 >Section 4.5 "The Object Element" has a MimeType attribute, declared
 >as a string that could be declared as a subtype of string, with a pattern
 >facet that matched all legal mime type variations.
 
There has not yet been a demand for this degree of constraint on that value.
If someone on the xmldsig list WG volunteers to specify that facet and
advocates it, the list can then decide if they wish to include it. (I
planned on giving it a go at some point but haven't yet.)

 >Lastly, the dsig WD should make clear whether the schema and DTD included
in
 >Section 9 are normative or informative.

In response to this point, the WG has decided that the schema is normative,
though the most recent spec does not make that clear enough, but we will in
the next version.

 >The Schema WG also suggests that the XML Sig WG consider using a mechanism
 >similar to that proposed in [4] for assigning schema datatypes to
 >element/attribute declarations in the dsig DTD.
 >[4] http://www.w3.org/TR/dt4dtd

I think that is an interesting approach. However, there hasn't been any call
for this sort of feature from others on the list. My own thoughts are:
1. The document is only a NOTE (not normative).
2. It relies upon non-registered URNs [1] (not something I'm keen on)
3. One could update that spec to a normative document that used URIs if the
schema specifications made the data types first class resources. (However,
that isn't up to us, but to you! <smile>)
4. And finally, while it would make the DTDs more expressive, I don't think
it would further the typing capabilities of a 'out of the box' DTD
processor; and as we are describing the syntax with schema in parallel, it
would probably be of limited utility for us to add this as a work item.

[1] http://www.faqs.org/rfcs/rfc2611.html

_________________________________________________________
Joseph Reagle Jr.   
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/People/Reagle/
Received on Thursday, 11 May 2000 16:37:57 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.29 : Thursday, 13 January 2005 12:10:09 GMT