Re: Some errors and typos in the latest XML-Signature draft, Part 1

Hi,

From:  "John Boyer" <jboyer@uwi.com>
To:  "Donald E. Eastlake 3rd" <dee3@torque.pothole.com>,
            "Joseph M. Reagle Jr." <reagle@w3.org>
Cc:  <Gregor.Karlinger@iaik.at>, "David Solo" <dsolo@alum.mit.edu>,
            "XML-Signature" <w3c-ietf-xmldsig@w3.org>
Date:  Thu, 13 Jan 2000 09:02:18 -0800
Message-ID:  <NDBBLAOMJKOFPMBCHJOIKEABCDAA.jboyer@uwi.com>

>Hi Donald,
>
>I do recall a quite lengthy discussion about whether type and charset were
>required, and I do recall a lengthy discussion about whether things which
>were, at the time, named <parameter> should be given explicit names.  I do
>not recall a resolution requiring transforms to wrap a parameter tag around
>its content, and the transform sections as currently written do not require
>it.

I don't see what the MimeType and Charset attributes have to do with it.
They are optional.

>The last I recall was that transforms had an open model.  From an
>implementation standpoint, the choice is trivial.  However, the parameter
>tag given below adds characters but no information value.  Furthermore, this
>would bring up the question of why aren't the charset and type parameters?

Parameter syntax was an item of discussion both days at the IETF
meeting in Washington.  As far as I can recall, the consensus at the
meeting was in favor of having parameters always appear as elements
with no special case for algorithms that take only one explicit
parameter, and in favor of those elements names being meaningful, and
in favor of those elements being qualified by an algorithm specific
namespace to assit parsers.  In other words, of the possibilities
considered on the second day at
<http://www.w3.org/Signature/Minutes/DC-Minutes/open-questions2.html>,
the Algorthm Specific option was favored.

For that reason, shortly after the
meeting, I changed section 5.1 to say

"Explicit additional parameters to an algorithm appear as content
elements within the algorithm role element. Such parameter elements
have a descriptive element name, which is frequently algorithm
specific, and MUST be in an algorithm specific namespace. "

and added references to 5.1 in various algorithms sections, like
DigestMethod and no one has objected to that text.  However, the
minutes don't reflect very clearly what the consensus was at the
meeting and arguably it has not been confirmed on the mailing list.

Charset and MimeType are special partly because they have a unifrom
meaning across all transforms and partly because, historically, they
came out of the design decision to suppress the actual type
information that might come from a URI de-reference and to not pass
along such information between transform stages.  There is just never
anything algorithm specific about the meaning of the MimeType
parameter.

>Finally, it makes a bit of a mess out of the Algorithm attribute.  I look at
>that attribute as modifying the content of the element.  Now it would be a
>modifier of the content of one of the subelements of the transform element.

I don't understand your comment above...  The Algorithm attribute
appears only at the Transform level.  It specifies what the Transform
is.  If it "modifies" anything, it primarily modified, by more detail
sepecification, the Transform element.

>For these reasons, the current specification of the transforms does not
>indicate that a parameter tag is required around the xpath expression.

There is no more Parameter tag, the decision was to go with algorithm
specific parameter element names.  If we change to allow mixed content
then we are making a special case for single parameter algorithms and
losing the namespace labeling of parameter elements.

>If you were going to change it, then it might make more sense to have the
>parameter tag indicate the algorithm type.  This would eliminate our
>reliance on algorithm identifiers given by URI.  The tag names could

?? Only if the indiation of the algorithm in the parameter tag were by
some unspecified non-URI mechanism.  What do you do if multiple
parameters indicate different algorithms?

>directly be XPath, XPointer and XSLT.  For canonicalization, we could then
>use the CanonicalizationMethod element as the transform.  The only one that
>is slightly clumsy is base64, yet still replacing <Transform
>Algorithm="&base64;"/> with <Transform><base64/></Transform> is not the end
>of the world.

So how do you specify a user defined algorithm?  How do you specify which
canoncialziation method you are using? 

>In this way, at least the parameter tags would have some information value
>(and they would always shorten the number of characters needed to express
>the transform).

Having distinct parameter elements allows you to extend algorithsm by
adding parameters and the like, to specify different encodings for the
different parameters, and the names are supposed to be descriptive
which helps a person looking at the XML.

>John Boyer
>Software Development Manager
>UWI.Com -- The Internet Forms Company

Donald

>-----Original Message-----
>From: w3c-ietf-xmldsig-request@w3.org
>[mailto:w3c-ietf-xmldsig-request@w3.org]On Behalf Of Donald E. Eastlake
>3rd
>Sent: Thursday, January 13, 2000 7:51 AM
>To: Joseph M. Reagle Jr.
>Cc: Gregor.Karlinger@iaik.at; David Solo; XML-Signature
>Subject: Re: Some errors and typos in the latest XML-Signature draft,
>Part 1
>
>
>
>The example seems like an artifact of an earlier design where the
>content of a Transfrom was normally a single opaque possibly encoded
>blob that only the Transform need understand.  But after that we moved
>towards explicit parameters to Transforms being Parameter elements and
>then decided that they should always be algorithm specific named
>elements.
>
>So it should really be
>
><Transforms>
>    <Transform Algorithm="&XPath;" xmlns:xp="&XPath;">
>        <xp:Path>descendant-or-self::node()[not(self::Id)]</xp:Path>
>    </Transform>
></Transforms>
>
>Donald
>From:  "Joseph M. Reagle Jr." <reagle@w3.org>
>Message-Id:  <3.0.5.32.20000112154640.00b37880@localhost>
>X-Sender:  reagle@localhost
>Date:  Wed, 12 Jan 2000 15:46:40 -0500
>To:  Gregor.Karlinger@iaik.at
>Cc:  David Solo <dsolo@alum.mit.edu>, Donald Eastlake
><dee3@torque.pothole.com>,
>            XML-Signature <w3c-ietf-xmldsig@w3.org>
>In-Reply-To:  <385E32AB.AFDEFBA1@iaik.at>
>
>>Gregor,
>>
>>Good catch. But why did you exclude the option of letting the content be
>>mixed? In Boyer's examples of Transforms, the content model of the
>Transform
>>document is obviously not an element.
>>
>>        <Transform Algorithm="&XPath;">
>>        descendant-or-self::node()[not(self::Id)]</Transform>
>>        </Transforms>
>>
>>Consequently, I've changed the content model to mixed for the time being.
>>
>>
>>At 14:44 99/12/20 +0100, Gregor Karlinger wrote:
>> >Section "3.3.3.1 The Transforms Element":
>> >-----------------------------------------
>> >
>> >In this section there is no hint (neither in the textual description nor
>>in the
>> >Schema definition) that the "Transform" element could have mixed content.
>>But
>> >in section 5.6 the specification defines some character content for the
>>"Transform"
>> >element.
>> >
>> >To solve this contradiction, I suggest the following:
>> >
>> >* Keep the content model as-is (content='elementOnly')
>> >
>> >* Put the stuff defined in section 5.6 into a parameter element (for
>>example the
>> >  XPath language expression).
>>
>>
>>_________________________________________________________
>>Joseph Reagle Jr.
>>Policy Analyst           mailto:reagle@w3.org
>>XML-Signature Co-Chair   http://www.w3.org/People/Reagle/
>>
>

Received on Thursday, 13 January 2000 13:48:48 UTC