RE: Action-539: review C14N2.0

> OK, this makes way more sense to me. However, I wonder what this
> approach can achieve more than the inclusiveNamespacePrefixList that is
> already defined.

The prefix list does not tell you what nodes may contain the prefix. Knowing
that actually obviates the need for inclusive prefixes in many cases. The
prefix list is what you use when you can't tell where the prefixes will be
used.

> If one uses a Qname in a text node, one can either mark
> that node as "Qname-relevant content", hence have it parsed for prefixes
> and embed them, or one can put the prefixes used in the Qnames on the
> inclusiveNamespaces list, hence having them embedded despite any
> "visibly utilized". I'm not sure which approach is better or if one
> includes the other already.

The latter approach undermines the purpose of exclusive c14n. Once you mark
them inclusive, you're vulnerable to leakage from the context just as if you
used inclusive to begin with. Having tended to overuse the prefix list,
because of QName risks, I've seen the problems it causes.

The main reason for keeping the prefix list, apart from compatibility, would
be for cases in which the QNames can't be known in advance.
 
> I'm not sure I understood your point. I have no objections with that we
> have to support schema-unaware (or DTD-unaware) applications of XML
> Signature, however, does this imply that we are not allowed to propose
> solutions that do well with schema but are not applicable / not relevant
> without, as long as we propose general "fallback" solutions for the
> schema-inaware cases as well?

No, I'm not saying that, but the additions I'd be proposing would not be
assuming them and are in most cases acting as a replacement for them. I'm
just anticipating the obvious response. It's a logical one, I just don't
think it's a practical one.

-- Scott

Received on Monday, 19 April 2010 18:53:21 UTC