Poll: Relative URIs and Strings in xmlns attributes

Before we request Candidate Rec status for Canonical XML there's one issue 
that I've been trying to understand and come to closure on, and that's the 
implications of the recent XML Plenary decision on Canonical XML: "to 
deprecate the use of relative URI references in namespace declarations." [1] 
What does that mean for the Canonical Form? We've had some discussion on 
this over this week in this WG [2], some discussion in the XML Coordination 
Group, and I also briefly discussed this with TimBL. I think the two options 
we now face are below. Please post your preference -- and optionally 
reason/rationale -- by end of day Wednesday September 30th. (Those cc:'d are 
invited to make their choice known in an advisory capacity than can convince 
others of their position, but in the end I'd like to say, "the XML Signature 
WG feels $this-way about the issue, while others (agree|disagree)."

CHOICES

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. (This includes namespaces like "../foo" as well as "bar"; only 
documents with namespace declaration using absolute URIs are in scope -- 
just as only well formed documents are in scope.)
2. To state that the canonical form is URI unaware. In section 3.1 [4], we 
already disclaim responsibility for resolving/normalizing other URIs, data 
types, application semantics, etc. (The reason we made this distinction in 
the first place is because XPath did. However, an errata of XPath might be 
issued that would make the resulting the string-value 
implementation-dependent, but we can't say till we see the errata.) 
Consequently, not only is the issue of the "relative-URI-in-namespace" out 
of scope, so is the plenary decision.

ARGUMENTS FOR CHOICE (1)

A. The XML Plenary decision recommends W3C specs say, "This specification 
does not define an information set [or whatever] for XML documents which use 
relative URIs in namespace declarations." [1]
B. In [3] DanC stated that, "if you specify how they work today, we won't be 
able to make a different specification later." I'm very glad the XML Plenary 
has come to a decision on this and I want to respect the spirit and intended 
effect of that decision.
C. (1) seems to be the common interpretation of the plenary decision to 
Canonical XML by the folks who were active in the Plenary discussion.

ARGUMENTS FOR CHOICE (2)

A. The XML Plenary decision, "Proposed: to deprecate the use of relative URI 
references in namespace declarations; that is: to say that while they 
conform to the Namespace Recommendation of January 1999, later 
specifications such as DOM, XPath, etc. will define no interpretation for 
them." However, I'm told that "no interpretation"  is not an argument in 
favor "literal interpretation" which was specifically opted against.
B. However, it might permit us to make an argument that we are all-together 
URI unaware.  (The only reason we know these might be URIs and not strings 
is because of the XPath namespace-node and because of the syntactic sugar of 
'xmlns:'.) Later, if consensus is reached on namespaces/URIs, someone can 
easily write a URI-canonicalization specification and apply it prior to 
Canonical XML.
C. Canonical XML is not in the set of specifications (DOM, XPath, etc.) 
covered by the Plenary decision, but an application of them which is allowed 
to do as it pleases. Canonical XML is an application of XPath that uses 
namespace nodes as we choose as a contribution to a generated hash-value. 
What we do today won't hinder others in the future.
D. There are documents out there that use relative URIs and need to be 
signed. (Is this the case for anyone in the WG?)






[1] http://www.w3.org/2000/09/xppa.html
>4.2 Proposal
>
>Proposed: to deprecate the use of relative URI references
>in namespace declarations; that is: to say that while they
>conform to the Namespace Recommendation of January
>1999, later specifications such as DOM, XPath, etc. will
>define no interpretation for them. "
[2] http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000JulSep/0467.html
[3] Forwarded Text ----
>Date: Thu, 14 Sep 2000 15:35:09 -0500
>From: Dan Connolly <connolly@w3.org>
>
> > 2. Our question is related to the question asked of by Clark [2], since 
> the
> > XPath errata attempts to [3] implement the plenary decision [4]. Under 
> XPath
> > errata [3] "XPath expressions can still be well-defined on a document
> > containing relative namespace URIs..." [2]  We also felt that there can 
> be a
> > Canonical form of such documents. And our interpretation of [3] led us to
> > believe it is up to xmldsig to decide how to represent it. We recently
> > decided to treat relative URIs in these instances as a non-absolutized
> > string in the Canonical form. However, this caused others to feel this
> > violated the plenary decision
>
>Hmm... yes... I might have told you differently in our
>earlier conversation, but I think that *any* specification
>of how a relative URI reference in an xml namespace
>declaration is to be interpreted is in conflict
>with the plenary decision; if you specify how they
>work today, we won't be able to make a different
>specification later. (Meanwhile, we're allowing
>implementations to do what they like, so the only
>chance we really have of specifying how they work
>later is if the market agrees on some way of
>interpreting them, and we adopt that way.)
[4] http://www.w3.org/TR/2000/WD-xml-c14n-20000907#Limitations
For example, in a digital signature application, a document is often 
retrieved and processed prior to signature generation. The processing SHOULD 
include the conversion of relative URIs to absolute URIs, thereby mitigating 
any security risk.


__
Joseph Reagle Jr.
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/People/Reagle/

Received on Friday, 15 September 2000 17:13:12 UTC