W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > July to September 2000

AW: Poll: Relative URIs and Strings in xmlns attributes

From: Gregor Karlinger <gregor.karlinger@iaik.at>
Date: Thu, 21 Sep 2000 10:35:26 +0200
To: "Mark Bartel" <mbartel@thistle.ca>, "IETF/W3C XML-DSig WG" <w3c-ietf-xmldsig@w3.org>, "Joseph M. Reagle Jr." <reagle@w3.org>
Message-ID: <NDBBIMACDKCOPBLEJCCDOEDCCLAA.gregor.karlinger@iaik.at>
Hi Mark,

The description of the first choice Joseph has given starts with:

>1. To state that the canonical form of a document containing a relative URI
>in a namespace is undefined, and consequently such a document can not be
>signed. [...]

My way of thinking is that an algorithm performing Canonical XML must return
an error if it dedects relative URIs in the input. Maybe I am wrong, Joseph?

Regards, Gregor
---------------------------------------------------------------
Gregor Karlinger
mailto://gregor.karlinger@iaik.at
http://www.iaik.at
Phone +43 316 873 5541
Institute for Applied Information Processing and Communications
Austria
---------------------------------------------------------------


> -----Ursprüngliche Nachricht-----
> Von: w3c-ietf-xmldsig-request@w3.org
> [mailto:w3c-ietf-xmldsig-request@w3.org]Im Auftrag von Mark Bartel
> Gesendet: Mittwoch, 20. September 2000 13:08
> An: IETF/W3C XML-DSig WG
> Betreff: Re: Poll: Relative URIs and Strings in xmlns attributes
>
>
> I think I'm missing something...
>
> merlin said:
> > I agree that #2 may be necessary; we are otherwise
> > mandating some degree of URI understanding within a
> > c14r.
>
> Gregor said:
> > Since neither Canonical XML nor XML-Signature interpret namespace
> > uri values in an other way as that they are strings, I don't see
> > a reason to forbid the generation of a canonical version for XML
> > docs using relative namespace uris.
>
> I don't understand how #1 mandates or forbids anything.  It merely says
> that we're not specifying what happens.  If it mandates anything I'm
> against it!  Perhaps we should change the wording to "can not be
> interoperably signed."
>
> Under #1, an implementation can choose to treat URIs as per #2... we're
> just not guaranteeing that it will interoperate.  But it seems to me that
> #2 doesn't guarantee interoperability in the grand scheme of things anyway
> since other specs don't define what happens in the case of relative URIs.
>
> I think odds are most implementations will behave as per #2... I just
> object to requiring them to behave that way.
>
> -Mark Bartel
> JetForm Corporation
>
>
>
Received on Thursday, 21 September 2000 04:34:50 GMT

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