RE: Fwd: Moving exc-c14n forward: your response is needed!

> ... the question is whether
> xml:base="" means 'the current document is the base' or it means
> 'don't change the base you have', or it is undefined.

xml:base="" means don't change the base you have.  An empty string is
treated as any other relative URI.

> -----Original Message-----
> From: Martin Duerst [mailto:[email protected]]
> Sent: Sunday, April 21, 2002 5:30 PM
> To: [email protected]; [email protected]; Philippe Le Hegaret;
Jonathan
> Marsh
> Cc: [email protected]; [email protected]; [email protected]
> Subject: Re: Fwd: Moving exc-c14n forward: your response is needed!
> 
> Hello Joseph,
> 
> Many thanks for your excellent summary. Just a few comments below:
> 
> [Jonathan, there is some question about XML Base where maybe you
> can help.]
> 
> At 18:12 02/04/19 -0400, Joseph Reagle wrote:
> >On Friday 19 April 2002 15:07, [email protected] wrote:
> > >    Martin: Ask for a health warning re problem with Exclusive
> > >    Canonicalization, where xml:lang and perhaps namespaces get
> > >    ignored when signing a payload.
> >
> >Thank you for raising this issue. It gives me an opportunity to be
clear
> >about our present state on this issue.
> >
> >Martin and I did talk about this issue a few months ago when he was
in
> >Boston.  Also, Philippe raised this question with respect to xml:base
> when
> >we were entering CR. However, I don't recall any specific action or
text
> >resulting from that conversation with Martin beyond what the present
text
> >states (see below).
> >
> >However, I do remember the salient point of conversation. Take the
> >following example of a soap envelope contain an svg element and
signature
> >over it:
> >
> ><env:Envelope xml:lang="english"  xml:space="preserve"
> 
> Should be xml:lang="en", just for the record.
> 
> 
> >      xmlns:env="...soap..."/>
> >    <env:Header>...</env:Header>
> >    <env:body>
> >        <svg>...<svg>
> >        <Signature>
> >    </env:body>
> ></env:Envelope>
> >
> >
> >Do namespace nodes and xml:* attributes pose the same sort of
problems?
> >
> >For namespace nodes, they are nuisance and a problem. Under c14n the
env:
> >declarations aren't even needed (nuisance) in the svg element, yet
they
> are
> >there and contaminate the SVG such that if it is signed in context
and
> then
> >removed from the SOAP header and the signature is recalculated (and
> >canonicalized outside of the envelope) it won't be able to validate.
> >exc-c14n removes this problem.
> >
> >For the xml:{lang, space, and base} one can argue that they are less
of a
> >nuisance,
> 
> Yes, there is only one of each, and they don't have prefixes hidden
> in attributes and text content.
> 
> 
> >but still pose a problem. While the env: namspace nodes in the
> >canonical form of the svg are completely un-needed, one can argue
that
> the
> >SVG element should be also be considered to be in English
> 
> Or some other language.
> 
> >and have
> >important white space. Or that a relative URI in the SVG is dependent
on
> >the xml:base in the soap Envelope. However, if an application removes
the
> >SVG and acts on it as such, it wouldn't be useful anyway. (I don't
know
> if
> >or how SOAP defines the detachment of a payload for processing...?)
> >Regardless, I'd expect that if the detachable SVG is to be useful
when
> >detached, it will already have its own xml:* attributes. And if it
does,
> >the canonical form in or out of the soap envelope will be the same.
> 
> There is one specific problem with xml:lang, which is the following:
> 
> If the SVG document to be included has no language information, it
> is impossible to note that in the top SVG element or just outside.
> We had some preliminary discussion on how to fix this problem; the
> proposal that has received most support in the I18N WG/IG is to use
> xml:lang="".
> 
> In some specific cases, there is a similar problem with namespaces.
> For xml:space, there should not be any such problem, because there
> is a default, which can be made explicit. For xml:base, I don't know
> if there is such a problem or not. I.e. the question is whether
> xml:base="" means 'the current document is the base' or it means
> 'don't change the base you have', or it is undefined.
> 
> 
> >It's definitely a tricky issue and we explicitly solicited feedback
on
> >these points in our CR [1], but haven't had any push-back, so I hope
> >folks are largely satisfied and the text is clear [2].
> >
> >[1] http://www.w3.org/TR/2002/CR-xml-exc-c14n-20020212
> >    Specific areas where we would appreciate further
> >    implementation experience are:
> >     1. Speed of canonicalziation relative to Canonical XML; it
should be
> >        no slower, is it faster?
> >     2. Use in application contexts. Does the specified behaviour
meet
> >        application requirements for flexibly canonicalizing document
> >        subsets if they are moved out of their context? For example,
does
> >        your application scenario lead to any difficulties in which a
> >        subset (e.g., payload) require the use of an ancestor base
that
> is
> >        not easily remedied by including xml:base in the apex of the
> >        subset?
> >
> >[2] http://www.w3.org/Signature/Drafts/xml-exc-c14n#sec-Limitations
> >
> >   1.3 Limitations
> >
> >    Exclusive XML Canonicalization has the limitations of Canonical
XML
> >    [XML-C14N] plus two additional limitations as follows:
> >     1. The XML being canonicalized may depend on the effect of xml
> >        namespace attributes, such as xml:lang, xml:space, and
xml:base
> >        appearing in ancestor nodes. To avoid problems due to the
> >        non-importation of such attributes into an enveloped document
> >        subset, either they must be explicitly given in the apex
nodes of
> >        the XML document subset being canonicalized or they must
always
> be
> >        declared with an equivalent value in every context in which
the
> >        XML document subset will be interpreted.
> 
> I think this covers my action from the I18N WG minutes:
> 
> Martin: Ask for a health warning re problem with Exclusive
> Canonicalization, where xml:lang and perhaps namespaces get ignored
when
> signing a payload.
> 
> If somebody disagrees, please tell me.
> 
> 
> >     2. Applications that use the XML being canonicalized may depend
on
> >        the effect of XML namespace declarations where the namespace
> >        prefix being bound is not visibly utilized. An example would
be
> an
> >        attribute whose value is an XPath expression and whose
evaluation
> >        therefore depends upon namespace prefixes referenced in the
> >        expression. Or, an attribute value might be considered a
QName
> >        [XML-Schema]
> 
> I don't think you should cite XML-Schema, but XML-Namespaces
> (http://www.w3.org/TR/REC-xml-names/#NT-QName). In the example
> below, XML-Schema is only one example of an application using
> QNames, nothing special. But with the reference above, it can
> easily be read differently.
> 
> 
> >by some applications, but it is only a string-value
> >        to XPath:
> >        <number xsi:type="xsd:decimal">10.09</number>.
> >        To avoid problems with such namespace declarations,
> >           + the XML must be modified so that use of the namespace
prefix
> >             involved is visible or
> >           + the namespace declarations must appear and be bound to
the
> >             same values in every context in which the XML will be
> >             interpreted or
> >           + the prefixes for such namespaces must appear in the
> >             InclusiveNamespaces PrefixList.
> >
> >http://www.w3.org/Signature/Drafts/xml-exc-c14n#sec-Considerations
> >
> >5. Security Considerations
> >
> >    This specification is used to serialize an XPath nodeset under
> certain
> >    assumptions given in [XML-C14N] and this specification. For
example,
> >    implementations of [XML-C14N] do not render a document XML
> >    declaration; when implementations of this specification serialize
a
> >    subset they do not render ancestor attributes from the "xml:"
> >    namespace (e.g., xml:lang, xml:space, and xml:base). Nor do
> >    implementations of this specification consider the appearence of
a
> >    namespace prefix within an attribute value to be visibly
utilized.
> >    While we feel such choices are consistent with other XML
> >    specifications and satisfy our application requirements it is
> 
> I'm not very happy here; this can be read as "it's okay to remove
> xml:lang". I think the explanation that XML-C14N and exclusive
> canonicalization provide two extremes, and the application
> designer has to chose the right mix, would be better.
> 
> 
> >    important that an XML application carefully construct its
transforms
> >    such that the result is meaningful and unambigous in its
application
> >    context. The Limitations of this specification, the Resolutions
of
> >    [XML-C14N], and the Security Considerations of [XML-DSig] should
be
> >    carefully attended to.
> >
> >   5.1 "Esoteric" Nodesets
> >
> >    Consider an application that might use this specification or
> >    [XML-C14N] to serialize a single attribute node. Neither
> specification
> >    will automatically emit a namespace declaration for that single
> >    attribute node. Consequently, a "carefully constructed" transform
> >    should create a nodeset containing the attribute and the relevant
> >    namespace declaration for serialization.
> >
> >    We provide this example to caution that as one moves beyond
> >    well-formed [XML] and then well-balanced XML [XML-Fragment], it
> >    becomes increasingly difficult to create a result that "is
meaningful
> >    and unambiguous in its application context."
> 
> 
> Regards,   Martin.