Re: ACTION-740: Proposal on Selection algorithms/syntax

Scott

You raise an important point. If in 2.0 we change items that were REQUIRED in 1.1 to OPTIONAL in 2.0 then that is an argument not to separate the material since it would be horrifically confusing to reference the 1.1 specification but with changed normative requirements. 

We should discuss whether legacy material support should be  optional - an important point.

I think the approach you suggest of using Algorithm would offer clarity and consistency and be desirable.

regards, Frederick

Frederick Hirsch
Nokia



On Dec 10, 2010, at 1:51 PM, ext Cantor, Scott E. wrote:

> Before getting into the proposal, please take a look at section 6.1, which is a broad overview of the use of "Algorithms" in the specification. Some of this text needs to be updated for 2.0, and before we do that, we need to make final decisions about how we combine the new and old material, since we're still debating that.
> 
> My proposal is essentially based on the assumption that we want to present both the old and new material in one document, but try and emphasize the new more. In that vein, I'm arguing that we use syntax for the new material that's more consistent with the old material, and use the approach of a generic element with a wildcard, and an Algorithm or Type attribute to identify the actual "plugin".
> 
> With respect to section 6.1, we have yet to discuss the MTI requirements for the legacy material. I guess I've been assuming that the intent was to make backward compatibility OPTIONAL. If that's true, we need to rework those lists in I assume an obvious way, and add the new algorithms we're going to REQUIRE or Recommend.
> 
> I'm also suggesting in this email that we add Selection to section 6.1 as an additional algorithm type, with the obvious text changes.
> 
> I suggest we do use Algorithm as the attribute that identifies the selection approach, processing rules, and output format. So the schema is changed to replace Type and Subtype with Algorithm. We could also use Type instead, and just drop Subtype, but I think Algorithm is better if it's appropriate, and I think it is. My suggested Algorithms (suggestions welcome) would be:
> 
> http://www.w3.org/2010/xmldsig2#xml
> http://www.w3.org/2010/xmldsig2#binaryExternal
> http://www.w3.org/2010/xmldsig2#binaryfromBase64
> 
> Then, I suggest we add a new section between 6.7 and 6.8 for "Selection Algorithms", and move the appropriate subsections (6.7.1.2-6.7.1.7) to that new section. Basically treating them like we treated Transform algorithms before.
> 
> I'm sure there's some text cleanup that will be needed in addition, but basically the idea would be to use section 6.7 to explain the overall set of elements that are involved (currently Selection, CanonicalizationMethod, and Verification) and how they fit together. But the actual definitions of the algorithms/types of those things would be their own sections.
> 
> I can of course make these changes if they're accepted.
> 
> -- Scott
> 
>

Received on Tuesday, 14 December 2010 14:34:15 UTC