- From: merlin <merlin@baltimore.ie>
- Date: Wed, 17 Jan 2001 15:30:15 +0000
- To: "Joseph M. Reagle Jr." <reagle@w3.org>
- Cc: "IETF/W3C XML-DSig WG" <w3c-ietf-xmldsig@w3.org>, muraw3c@attglobal.net, Brian LaMacchia <bal@microsoft.com>, "Donald Eastlake" <dee3@torque.pothole.com>, lde008@dma.isg.mot.com
I vote for minimality. In my opinion, and it is hard for me to clarify where this falls within the arguments of the assembled assailants, or if it is a valid and supportable argument, or even relevant, it is better to limit, where possible, the scope for arbitrary extensions within _elements_ under the dsig namespace. Wherever there is scope for extensions, within my basic dsig implementation I have to allow support for handler registration and I have to add logic that allows these extensions to be processed and I have to decide how to proceed if I don't understand such extensions. This makes sense in a broad scope -- SignatureMethod, KeyValue, ... - but at a certain point I become mired in the multiplicity of options. If we cannot define a concrete PGPData element (for example) that I can either support completely or ignore completely, then it seems to me that we should at the most define an extensible (schema) type, but no corresponding element. This allows an external entity to define a KeyInfo element that provides a full definition of PGPData in their own namespace, but I don't have to provide support for these extensions within my implementation of a PGPData element from the basic spec. I think I'm trying to say, why define a primitive element at all if we cannot define it sufficiently? Based on what I think are the arguments, I disagree with both Brian and Joseph! I don't want to be able to mess with the content of the most primitive XMLDSIG elements at all; doing so adds what are (in my opinion) unnecessary option to the elements. However, if it is mandatory that we support extension of these primitive elements by either complement or replacement, then I would fall on Brian's side (support replacement in addition to complement) because the (unnecessary, to belabour my opinion) complexity is equal for either case. I've already written too many words, so I'll end how I begin. I vote for minimality. Merlin r/reagle@w3.org/2001.01.16/18:23:25 > >Brian and I have been working on clarifying the use of the <ANY> within the >KeyInfo children (PGPData, SPKIData, etc.) for extensibility purposes. At >first, I thought it was an editorial issue of trying to harmonize the >inconsistent use of ANY in the different KeyTypes. Part of these >inconsistencies arose from a disconnect between myself and Brian in that >Brian intended the ANY to be used to extend elements from our namespace. I >expected ANY to be only be present to permit our types to be replaced. Both >of these view points are reflected in different KeyTypes and I'm agreeable >to ANY being used in KeyInfo for replacement, and in the KeyTypes as >complements (but not replacements). Consequently, we've been trying to >identify schema/DTD constructs that prohibit empty content: > > [a] <PGPData></PGPData> <!-- not a biggie, but silly --> > >or prohibit content that is only from an external namespace (I think it >should be under KeyInfo then): > > [b] <PGPData><foo:MyPGPData>bar</foo:MyPGPData></PGPData> > >However, at this point, Brian asked with good cause why not permit [b]? We >don't yet agree why it should or should not, so we're bouncing it back to >the list for discussion. You can see the areas of the spec affected by this >issue in [1], underlined in red. I'll bounce our last two messages to the >list as well for wider comment/review. > >I'll ask Don to bring this issue to a close. <smile> > >[1] http://www.w3.org/Signature/Drafts/xmldsig-core/Overview.html#sec-KeyInfo > >__ >Joseph Reagle Jr. >W3C Policy Analyst mailto:reagle@w3.org >IETF/W3C XML-Signature Co-Chair http://www.w3.org/People/Reagle/ >
Received on Wednesday, 17 January 2001 10:30:57 UTC