- From: Pratik Datta <pratik.datta@oracle.com>
- Date: Fri, 13 Aug 2010 17:20:59 -0700 (PDT)
- To: Pratik Datta <pratik.datta@oracle.com>, Meiko Jensen <Meiko.Jensen@ruhr-uni-bochum.de>, Scott Cantor <cantor.2@osu.edu>
- Cc: XMLSec WG Public List <public-xmlsec@w3.org>
- Message-ID: <97cf825c-2c0a-4530-83e1-bae65844add9@default>
Added a new section 2.2.1 Conformance profiles with this information. http://www.w3.org/2008/xmlsec/Drafts/c14n-20/Overview.html#sec-Conformance-Profiles version - August 13, 2010 Pratik From: Pratik Datta Sent: Saturday, August 07, 2010 6:22 PM To: Meiko Jensen; Scott Cantor Cc: XMLSec WG Public List Subject: RE: Syntax for C14N2.0 profiles Proposal for implementation conformation profiles. (My ACTION-576) Profile 1: "1.x features" Needs to support: ExclusiveMode=true/false , InclusiveNamespace, IgnoreComments=true/false, SortAttributes=true and XMLAncestors=inherit/none (Default for others i.e: TrimTextNodes=false, Serialization=Xml, PrefixRewrite=none, No QNameAware) Profile 2: "1.x Simple Exclusive" Subset of 1.x features. Only for ExclusiveMode=true. XMLAncestors=none Only for complete subtrees identified by ID. No XPath, no comments, no visible utilization of XPath (Defaults for other options, i.e. No InclusiveNamespace, IgnoreComments=true, SortAttributes=true, TrimTextNodes=false, Serialization=Xml, PrefixRewrite=none, No QNameAware) Profile 3: "Streaming" Need to support: streaming XPath, and all 1.x features. (However Meiko said that "SortAttributes" and "XML Ancestors" are difficult to support http://lists.w3.org/Archives/Public/public-xmlsec/2010Apr/0071.html ) Pratik From: Meiko Jensen [mailto:Meiko.Jensen@ruhr-uni-bochum.de] Sent: Tuesday, June 29, 2010 3:19 AM To: Scott Cantor Cc: Pratik Datta; XMLSec WG Public List Subject: Re: Syntax for C14N2.0 profiles Or should we just define profiles as a combination of parameters that need to be supported by implementation, but there would be no indication in the syntax that a particular profile is being used. That would be my preference. I think this is a conformance issue, not an implementation issue. I agree, however, this implies that we might not even need the named parameter sets at all. It should be sufficient to just mark every parameter whether it is mandatory to be supported or not. However, this also reduces the "favorite" configuration---in the sense of being recommended by the WG---to the parameter's default values, hence this might result in all other configurations not being used very much. I prefer the later. The problem with the first approach is that profiles also need parameters - i.e. a exclusive-canonical-xml-1.0-nocomments" would need the InclusiveNamespacePrefixList as parameters. This would get very confusing. It would be a mess. Agreed. 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. IC 4/150 D-44780 Bochum, Germany Phone: +49 (0) 234 / 32-26796 Telefax: +49 (0) 234 / 32-14347 http:// HYPERLINK "http://www.nds.rub.de"www.nds.rub.de
Received on Saturday, 14 August 2010 00:22:29 UTC