Re: Canonical XML 2.0 Conformance Profiles

Frederick.Hirsch@nokia.com schrieb:
> To repeat what I think you said, Does this mean there are really two conformance levels?
>
> 1. Support C14N2 with defaults as listed for all parameters. All other parameters not at default settings are optional.
>
> 2. Also support ExclusiveMode, InclusiveNamespace, IgnoreComments and XmlAncestors parameters with values other then defaults.
>   
I'm saying that, yes, you could read the spec document both ways. By
now, the spec says (in 2.2.1) "Implementations may not support all of
these parameters. We have identified the following profiles.", but it
does not explicitly say how these profiles relate to conformance (i.e.
whether all of these profiles have to be supported, at least one of
them, or none of them...). I also remember Pratik saying that
implementers were allowed to decide upon which profiles they support,
meaning them to be optional.

Besides that I'd also like to point to the fact that both definitions of
conformance imply that all our new parameters (such as TrimTextNodes,
prefixRewriting etc.) are optional to implement. Hence, the difference
between C14N1.X and C14N2.0 turns out to merely be suggesting a list of
optional-to-implement, optional-to-use new params, and to require
backward compatibility. I have to admit that I'm not really satisfied
with this, since---to me---those new parameters are very useful in
practice, but if they remain optional, this means that you can never
rely on that your signature peer (i.e. in most cases the verifier)
supports the same set of XML Signatures as you do. We're fuzzying the
feature list of the XML Signature spec bundle here, and frankly, I'm not
sure this is a good approach for a soon-to-be standard document.

just my $.02

cheers

Meiko
>
>
> regards, Frederick
>
> Frederick Hirsch
> Nokia
>
>
>
> On Sep 2, 2010, at 8:24 AM, ext Meiko Jensen wrote:
>
>   
>> I've taken a look at the conformance profiles of canonical XML 2.0 as
>> published on August 31st.
>>
>> By now it seems that this specification---as it is now---implicitly
>> supports three different levels of "REQUIRED/OPTIONAL" for conformance.
>>
>> The first level is shaped by the default values for all parameters:
>> since this is the default, *every* conforming implementation must
>> support this configuration.
>>
>> The second level is shaped by the three "conformance profiles"
>> explicitly listed in section 2.2.1:
>> -ExclusiveMode="true" must be supported for the "1.x features" and "1.x
>> Simple Exclusive" profile (and I'd recommend it as well for streaming),
>> but since its default value is "false", a conforming implementation must
>> support this one in full.
>> -InclusiveNamespace must be supported as well, though default being an
>> empty list
>> -IgnoreComments="false" must be supported for "1.x features"
>> conformance, though default is "true"
>> -XmlAncestors="none" must be supported for "1.x features", though
>> default is "inherit"
>> Hence, these 4 parameters (and all of their combinations) are REQUIRED
>> to implement for conformance with the spec.
>>
>> The third level is shaped by all parameters listed in the spec, but
>> which are not deviating from their default values for any of the given
>> profiles. Hence---as I read it now---these are  OPTIONAL to implement.
>> -SortAttributes: though being listed explicitly in all the profiles, its
>> value is always set to "true", hence it is not required to support the
>> "false" case for any of the profiles nor the default.
>> -TrimTextNodes: always set to "false" => OPTIONAL
>> -Serialization: always set to XML => OPTIONAL (btw: the spec says
>> "serializeXML" as default, "Xml" as value in the profiles, and "XML" as
>> enum value in the XML Schema. Should be unified)
>> -PrefixRewrite: always set to "none", rendering "sequential" and
>> "derived" OPTIONAL
>> -QNameAware="": listed explicitly, but for conformance it is only
>> REQUIRED to support the empty version of this parameter (which means
>> doing nothing about this). => OPTIONAL
>>
>> The implicit 4th level is that people might start creating their own
>> parameters and switches here, but I think that's out of scope for the
>> specification.
>>
>>
>> To resume, we require only the conformance to the backward-compatibility
>> profiles. Everything "new" is rendered OPTIONAL, hence will not affect
>> conformance nor interops, right?
>>
>> This should close my Action-625 for now.
>>
>> best regards
>>
>> Meiko
>>
>> -- 
>> Dipl.-Inf. Meiko Jensen
>> Chair for Network and Data Security 
>> Horst Görtz Institute for IT-Security 
>> Ruhr University Bochum, Germany
>> _____________________________
>> Universitätsstr. 150, Geb. ID 2/411
>> D-44801 Bochum, Germany
>> Phone: +49 (0) 234 / 32-26796
>> Telefax: +49 (0) 234 / 32-14347
>> http:// www.nds.rub.de
>>
>>
>>     
>
>   

-- 
Dipl.-Inf. Meiko Jensen
Chair for Network and Data Security 
Horst Görtz Institute for IT-Security 
Ruhr University Bochum, Germany
_____________________________
Universitätsstr. 150, Geb. ID 2/411
D-44801 Bochum, Germany
Phone: +49 (0) 234 / 32-26796
Telefax: +49 (0) 234 / 32-14347
http:// www.nds.rub.de