TALLY and New POLL: Fwd: Proposal RE: Poll: Relative URIs and Strings in xmlns attributes

So the results of recent discussion on this topic were rather muddled/mixed 
which is not surprising given the state of the issue <smile>. Our own 
discussion was split [2] with some confusion regarding the meaning of 
"unspecified". Additionally, the brief discussion at the XML Plenary meeting 
didn't give us an inescapable argument either [1].

However, I think John's recently analysis [2,c] is delightfully unmuddled 
(just two variables and their enumeration). I'm not of a strong technical 
opinion either way (I've flip-flopped a few times), and my interest in this 
is much more at the meta-level that the following two requirements be met:

1. That the conformance requirements and expectations regarding Canonical 
XML and its applications be straightforward. Even if this means being 
aggressive with considering things in or out of scope we need to ensure a 
developer can understand and implement the spec in an interoperable way as 
easily as possible.
2. The way in which we should respect the Plenary Decision is by not 
requiring XML processors to do things counter to the Plenary Decision.

Consequently, from a procedural point of view, in order to bring this issue 
to a close, we need to opt for one of these options and ask for opposition. 
So given the previous discussion and John's proposal of:

         go with Choice #1 as it is specified above, i.e. REQUIRE
         implementers to A) not use Type 1 processors, B) generate
         errors if Type 2 processor used and non-absolute namespace
         URI found, or C) use a Type 3 processor.
         [2,c]

please express your acceptance of this proposal or opposition (and reason 
why) by Wednesday October 27th.

[1] http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000JulSep/0517.html
[2] Tally
Option 1 Undefined (does that mean not signed or not interop)
a. Martin Duerst (adhere to plenary decision and motivation)
    http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000JulSep/0503.html
b. Mark Bartel (2 adds extra requirements)
    http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000JulSep/0504.html
    However, also states that this doesn't require a fail, just that it
    won't interoperate.
    http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000JulSep/0509.html
c. Boyer (Easiest on implementation/conformance front)
    http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000JulSep/0521.html

Option 2 Interpret as String.
a. Petteri Stenius (Meaning we don't try to interprate the values)
    http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000JulSep/0505.html
b. Gregor Karlinger (We don't bother with URIs beyond treating
    them as string)
    http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000JulSep/0506.html
c. Merlin Hughes (1 requires us to understand what a URI is)
    http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000JulSep/0507.html
d. Donald Eastlake (give "suitable warnings that realtive URI
     namespaces are flakey"
     http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000JulSep/0520.html

__
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, 22 September 2000 16:29:05 UTC