W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > October to December 1999

Re: Parameterization of Transforms

From: Donald E. Eastlake 3rd <dee3@torque.pothole.com>
Date: Fri, 29 Oct 1999 10:18:11 -0400
Message-Id: <199910291418.KAA00712@torque.pothole.com>
To: "DSig Group" <w3c-ietf-xmldsig@w3.org>
Hi,

Putting parameters to algorithms in a Parameter element certainly
makes no difference for zero parameter algorithms and does add
seemingly unnecessary characters for one parameter algorithms.  But
for multiple parameter algorithms, it provides a standard means of
marshalling the parameters, giving them individual types, and
providing different encodings for them.

Some people want algorithm specific human understandable parameter
types, such as the

<Parameter type="urn:ietf-org:hmac-truncation-length>128</Parameter>

mentioned in
<http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/1999OctDec/0063.html>.
To do that for multiple parameters is pretty hard unless they are
separate elements.  For example, you might have a digest function with
two parameters, one a number of output bits and one a number of
"rounds" or other work/strength control.  You might have an algorithm
with one parameter that needs base64 encoding but another simple
integer parameter that you would like readers to be able to
understand.

It seems to me that the cost in additional characters for the case of
one and only one parameter isn't much to pay for the cleaner
organization, ability to have different encodings, and ability to have
different types, when there are more than one parameter to an
algorithm.

Thanks,
Donald

From:  "John Boyer" <jboyer@uwi.com>
Resent-Date:  Thu, 28 Oct 1999 18:06:23 -0400 (EDT)
Resent-Message-Id:  <199910282206.SAA16375@www19.w3.org>
To:  "DSig Group" <w3c-ietf-xmldsig@w3.org>
Date:  Thu, 28 Oct 1999 15:06:14 -0700
Message-ID:  <NDBBLAOMJKOFPMBCHJOIIEODCBAA.jboyer@uwi.com>

>Joseph asked for a brief description of the difference between parameterized
>and unparameterized transforms.
>
>The easiest example is a simple barename xpointer.  Suppose I want to
>address an element named foo in some document.  It can be by one of the two
>methods below.
>
><ObjectReference Location="http://.../somedocument">
><Transforms>
><Transform
>Algorithm="http://www.w3.org/1999/07/WD-xptr-19990709">foo</Transform>
></Transforms>
></ObjectReference>
>
>or
>
><ObjectReference Location="http://.../somedocument">
><Transforms>
><Transform Algorithm="http://www.w3.org/1999/07/WD-xptr-19990709">
><Parameter>foo</Parameter>
></Transform>
></Transforms>
></ObjectReference>
>
>The parameter is unnecessary to xpointer.  I'd be amenable to it for the
>sake of consistency except that no other defined transform seemed to need it
>either. Finally, anyone defining an application specific transform can put
>whatever internal structure they'd like inside the tranform element content.
>For example, if you want to do a canonicalization algorithm, you can put the
>CanonicalizationAlgorithm element into the Transform directly (as opposed to
>putting the Canonicalization element into a Parameter that you then put into
>the Transform).
>
>John Boyer
>Software Development Manager
>UWI.Com -- The Internet Forms Company
Received on Friday, 29 October 1999 10:18:15 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.29 : Thursday, 13 January 2005 12:10:08 GMT