AW: Poll: Relative URIs and Strings in xmlns attributes

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 UTC