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

parameters (was RE: latest edits )

From: Mark Bartel <mbartel@thistle.ca>
Date: Tue, 12 Oct 1999 12:20:11 -0400
Message-ID: <91F20911A6C0D2118DF80040056D77A2032A09@arren.cpu1634.adsl.bellglobal.com>
To: "'w3c-ietf-xmldsig@w3.org'" <w3c-ietf-xmldsig@w3.org>
Donald E. Eastlake 3rd wrote:
>
>I'm not sure we need a syntax for algorithm parameters.  And if we do,
>this seems awfully bulky.  I mean, if an algorithm takes one integer
>parameter, I'd kind of prefer A below.  I can see B.  But C seems like
>overkill to me.
>
>A.		1
>B.		<Integer>1</Integer>
>C.		<Parameter type="http://dsig.reg.int/integer">1</Parameter>

I'm not keen on B either.  What I was thinking for C was (as in the HMAC
example) that the type would be specific to the algorithm.  So I would
rewrite C as

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

The idea being to provide a standard mechanism for sticking in
parameter-name/value pairs.  Clearly more important for the
multiple-parameter case.  But for multiple parameters we could always allow
something like

E.  128,52

which is just the example A with another parameter.  I don't like E because
it creates a new, non-XML syntax to distinguish separate parameters.  Going
with D lets the XML parser do almost all of the work (with the exception of
the string to integer conversion).

Summary:  I prefer D, but I like A/E better than B or C.

And perhaps we don't need to define a general syntax, but we do need to
provide syntax for the parameters of those algorithms that we define.  Doing
so sets the precedent for future algorithm parameter definitions, and so in
a way does "define" the parameter syntax.

-Mark Bartel
JetForm
Received on Tuesday, 12 October 1999 12:20:14 GMT

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