- From: Joseph M. Reagle Jr. <reagle@w3.org>
- Date: Mon, 29 Jan 2001 16:26:38 -0500
- To: Brian LaMacchia <bal@microsoft.com>
- Cc: "'merlin'" <merlin@baltimore.ie>, "'Donald E. Eastlake 3rd'" <lde008@dma.isg.mot.com>, "'w3c-ietf-xmldsig@w3.org'" <w3c-ietf-xmldsig@w3.org>
At 10:55 1/25/2001 -0800, Brian LaMacchia wrote: >Since all of KeyInfo is optional, by definition if you don't understand a >clause you come across you drop it on the floor. Agreed, and the bit we're trying to understand is if some folks want to be able to say: 1. "I understand "http://www.w3.org/2000/09/xmldsig#PGPData" and its children element types and only those element types; I might understand other namespaces under KeyInfo" 2. "I understand "http://www.w3.org/2000/09/xmldsig#PGPData" and its children element types from the dsig namespace and maybe some other children of a similar sort of meaning from other namespaces" There's a tradeoff between the clarity of the namespace in option 1, and the small bit of metadata "typing" implied in option 2. When it comes to parsing, these lead to the following models: 1. I find foo:bar under KeyInfo, I don't even have a clue if I care about it, but I can dereference the namespace, grab the schema, and understand its type from that. 2. I find foo:bar under PGPData, I can infer whether I care or not immediately because I know if I care about PGPData. So you're approach does give a hint as to whether one should even bother to dereference and chase down a schema, but it also encourages folks to extend our elements (in a potentially confusing way) where I'd like to encourage them to make a clean replacement and use schema typing to explicitly define the relationship. >One of my main objections with option 1, which I raised previously during >the flap over the exact structure of X509Data, is that the XMLDSIG WG should >not be in the position of specifying a fixed, non-extensible Scheme for data >types that are "owned" by another WG. We own our namespace; they own there's. >If this WG is not willing to support extensibility within the "best-guess" >structures we have created to foster use of the output of the other WGs, I >humbly suggest that our best, safest course of action would be to remove the >X509Data, SPKIData and PGPData sections in their entirety from the draft and >let each of the other WGs issue RFCs that specify sub-elements of KeyInfo >that best represent their own work product. The nice thing is that they can do exactly this without dropping out "best-guess" approximations because other WGs will do their work in their own namespace. Actually, my interest in not having extensibility at the type level (PGP, X509, SPKI) is to encourage other WGs to do a better job at the schema class level, instead of hacking on extensions to ours at the instance level. __ 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, 29 January 2001 16:26:56 UTC