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

For canonicalization, I meant to say 'in' instead of 'as', i.e.

CanonicalizationMethod could be used *in* the transform, with the type of
c14n given as content (or an attribute).

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


-----Original Message-----
From: w3c-ietf-xmldsig-request@w3.org
[mailto:w3c-ietf-xmldsig-request@w3.org]On Behalf Of John Boyer
Sent: Thursday, January 13, 2000 9:02 AM
To: Donald E. Eastlake 3rd; 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


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.

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?
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.

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

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
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.

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).

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



-----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 12:28:56 UTC