- From: Scott Cantor <cantor.2@osu.edu>
- Date: Sat, 23 Jan 2010 14:33:54 -0500
- To: "'MURATA Makoto \(FAMILY Given\)'" <eb2m-mrt@asahi-net.or.jp>, "'XMLSec WG Public List'" <public-xmlsec@w3.org>
MURATA Makoto (FAMILY Given) wrote on 2010-01-23: > Schemas are not the only. The combination of prose and the schema > provide the answer. Otherwise, absolutely everything should be allowed > even as contents of <CanonicalizationMethod > Algorithm="http://www.w3.org/2006/12/xml-c14n11#WithComments"> In the absence of a definition for an algorithm or extension URI, the schema is normative and permits anything, exactly what it says. Given a *particular* algorithm, the prose may constrain the actual content in any specific case. > In my understanding, the schema is somewhat loose and prose is expected > to impose tighter constraints. But the prose does not look clear enough > to me. Prose can always be clearer, but this is too late in the game to be raising this issue IMHO. Anything changed now would risk introducing errors into a spec whose text in these areas has been stable for years. >> That is the province of each of those algorithms to define. If the >> algorithm is inclusive, there's no content. > > Which sentence in the XML Signature spec says so? None. The normative language would be in the c14n specifications, which do not specify any such content. You can allow any content you want, I suppose, but it won't affect the algorithm. > So, can the <ec:InclusiveNamespaces> element have sibling > elements? No. > I think nothing in the exclusive c14n spec disallows this one. I am > aware of "This algorithm also takes an optional explicit parameter of an > empty InclusiveNamespaces element with a PrefixList attribute.", but > I do not think this sentence mentions sibling elements. I think it doesn't mention them and that's enough to me, but an errata could be opened against excl c14n 1.0. For that matter an errata could be opened against c14n 1.0 and 1.1 to specifically preclude any content, I suppose. I don't think either is needed, but neither would be an issue to address in the context of XMLSignature 1.1. -- Scott
Received on Saturday, 23 January 2010 19:34:25 UTC