W3C home > Mailing lists > Public > public-xmlsec@w3.org > August 2010

RE: Syntax for C14N2.0 profiles

From: Pratik Datta <pratik.datta@oracle.com>
Date: Fri, 13 Aug 2010 17:20:59 -0700 (PDT)
Message-ID: <97cf825c-2c0a-4530-83e1-bae65844add9@default>
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>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 14 August 2010 00:22:30 GMT