RE: C14N: Non-absolutized URIs

Hi Jonathan,

<john>
> It is essential that a single behavior be defined for C14N,
> and the fact
> that XPath permits application-dependent behavior means that
> applications
> (such as C14N) are permitted to define the most appropriate behavior.
> Retaining the 'raw value' is most appropriate for C14N, esp. for the
> purposes of DSig.
</john>

<jonathan>
No, the fact that XPath permits application-dependent behavior means only
that the plenary has forced it (along with all other groups) to accept
application-depedent behavior.
</jonathan>

<john>Right, and as an application of XPath, we are choosing the behavior
that is most appropriate to our application.  No matter how much the plenary
wants to force things on dsig, there is nothing they can do to change the
behavior of a sha-1 hash.  We MUST have a single behavior, therefore we MUST
</john>

<jonathan>
I'm concerned.  It looks like you are defining it a certain way - to be
"literal".  If W3C groups are free to do this, then why don't we just drop
the plan for the XPath erratum and kill two birds with one stone?
<snip/>
</jonathan>

<john>Yes, we are choosing the literal value.  The reason that Xpath must
have the erratum is that some applications may need URI absolutization.  In
those cases

<jonathan>
I agree that you are in a tough spot.  I think a clever solution might be
found to work around (not change) XPath's undefined behavior (like retaining
the "literal" value and using this in the serialization algorithm), but I
can only imagine how to do this for c14n.
</jonathan>

<john>I do not think this is a tough spot for C14N since retaining the
literal value is *precisely* what we are saying should be done.
Furthermore, the XPath data model is really dependent on the application to
do, or not to do, the absolutizing.  Since it is also not part of core XML
1.0 processing, it should be a trivial task to omit the absolutizing
behavior.</john>

<jonathan>
I don't think you'll be so lucky
with DSig as a whole, as the erratum also affects XPath filtering, and XSLT
transformations.
<snip/>
</jonathan>

<john>
Actually, I think that DSig will have to follow suit with C14N and REQUIRE
the maintenance  of the string literals.  As an application, DSig is
critically dependent on C14N for generating the message to be digested.  To
the extent that C14N is, conceptually at least, an application of XPath, so
is DSig.  If the C14N application requires the literals, then the
requirement to maintain them flows into DSig conformant applications.

Frankly, I don't see the big deal; in all the software I've tried so far, I
haven't found one that can't give me this string, so the inconvenience is
likely to be low.  Further, I believe that this approach eliminates the
problems you describe for both the C14N transform and the XPath transform.

I agree that this will be a problem for the XSLT transform.  I haven't
considered it before now, which is OK I think considering I just got word
today that XPath was going to change (it's won't even be on the public
errata yet).

The answer could be as simple as dropping XSLT as a transform, though I do
love XSLT and would hate to see that happen.  No matter what though, we
should probably address future concerns in this regard as concerns over the
impact of this erratum on the XSLT transform, not on C14N or the Xpath
transform.

Thanks,
John Boyer
Development Team Leader,
Distributed Processing and XML
PureEdge Solutions Inc.
Creating Binding E-Commerce
v: 250-479-8334, ext. 143  f: 250-479-3772
1-888-517-2675   http://www.PureEdge.com <http://www.pureedge.com/>

</john>

Received on Monday, 11 September 2000 20:03:43 UTC