RE: New proposed fix for here()

I have a somewhat similar feeling than Kevin, but on a
slightly higher level. Transforms in many cases are
defined by an input octet stream as a parameter, but
I think it's impossible to work with a model that limits
parameters to transforms to a fixed list. As an example,
many transforms need a character encoding ('charset')
as an input parameter, others may need other parameters.

If the model is written in a way that gives the impression
that the list of parameters is closed, and implementations
are built on that assumption, these implementations will
run into problems sooner or later.

So I would advise to: 1) Make clear that there can be
more parameters, depending on the transform. 2) For
the enveloped signature transform, make clear that
there is an additional parameter that identifies where
the signature is. It may not be necessary to define
a representation for this parameter, that may be left
to implementations.

In other words, tell people that something close to
a hack may be needed, but don't try to tell them how
to hack :-).

Regards,  Martin.

At 00/08/15 14:15 -0700, Kevin Regan wrote:

>I did like the fact that XPath was not required in order to implement
>canonicalization or the enveloped signature transform.  If I remember
>correctly, XPath was introduced for canonicalization and the enveloped
>signature transform as a convenient way of expressing those transforms.
>It seems regrettable that a syntax introduced to express those
>transforms
>is now "taking over" the transforms and becoming "required" in the sense
>that if XPath is not implemented, then enveloped signatures will not
>be possible (this would seem to suggest that XPath was not an adequate
>means of describing the enveloped signature transform).

Received on Tuesday, 15 August 2000 20:56:32 UTC