Canonicalizations galore

[jose lorenzo <hozelda@yahoo.com>]

--- On Tue, 6/24/08, Dave Pawson <dave.pawson@gmail.com> wrote:

> From: Dave Pawson <dave.pawson@gmail.com>
> Subject: Re: [oiic-formation-discuss] Deliverable: odf-diff?
> To: oiic-formation-discuss@lists.oasis-open.org
> Date: Tuesday, June 24, 2008, 3:08 AM
> 2008/6/24 jose lorenzo <hozelda@yahoo.com>:
> 
> > One more note:
> >
> > You had mentioned the use of canonical forms for
> signatures. In that case, we would need precision encoded
> somewhere (maybe outside ODF proper). Applications like
> this would likely require very strict rules.
> 
> http://www.w3.org/TR/xmldsig-core/
> 
> That is precise, and the signature can be internal to the
> C18N document.

Some related links and references:
http://www.w3.org/TR/xmldsig-core/
4.3.1 The CanonicalizationMethod Element
6.0 Algorithms

http://www.w3.org/TR/2001/REC-xml-c14n-20010315
http://www.w3.org/TR/2007/CR-xml-c14n11-20070621/

OK, skimming over these pages, I would guess that a sig would be defined automatically (1-1 ?) for any ODF canonicalization algorithm (plus parameter set) that is defined.

I really like the idea of various canonicalizations to fit the use case/ diff requirements. The canonicalization (alg) effectively defines what the diff user/tool considers distinct or not (eg, Sanders' hypothetical tool applied to solve problem P).

I see many possibilities, and this can lead to very interesting development. There would be a mapping to match the occasion. In fact, a tool may actually come about allowing the user to dynamically determine what they view as important/distinct and then generate the map (alg). From the meta info to this map (ie, from the actual canonicalization algorithm or from a set of parameters to some well known alg), other tools would be able to recognize the implied diff and adopt it in order to further add value in tune with the user's needs. In fact, the alg generator might be a config util incorporated into the desktop or at the highest levels of an office suite. The generated algs can be named to allow various custom algs be used based on context (eg, when editing from a certain account or desktop or on a certain day or when emailing a certain person, etc, a specifc alg would be in scope) or directly upon request.

I suppose it would be useful to some to also have a specific sig (see links at top and in parent) too so that a sig exists for every partition of XML that would correspond/map to a specific canonicalization.

The canonicalization algorithms are something that I suppose third parties would (also) create based on needs. They might then be required (or not depending on profile.. eg, if profile makes sig support optional or not) to support various other items.

This is getting very varied. There can be many combinations of profiles+canonical forms+cert orgs (and never mind when you throw in apps and that they may apply different profiles under different scenarios).

Since canonicalization of XML is not something unique to ODF, it will exist regardless. Two questions might be, "to what extent will ODF standardize a canonicalization algorithm, say, on a per profile basis; and how much support will the standard provide for those that want to adapt their own canonical mappings for ODF processing? There are probably many little details that should be standardized. These details would probably also vary on a per profile basis.

Interop is an issue to some extent always. I'll echo and reinterpret Dave's recent comment http://lists.oasis-open.org/archives/oiic-formation-discuss/200806/msg00710.html  that the OIIC TC may become a fixture of ODF in the sense of maintaining an ongoing close working relationship with the ODF TC as ODF evolves (I know, that's not exactly what you said). What then, if any, might be the OIIC's initial set of deliverables/scope/etc in this area of canonicalizations/diffs/etc?

Perhaps based on demand for some of these things (a specific profile, a specific diff need, etc), work will be undertaken by outside groups in parallel to OIIC TC work and issues will be reported to the TC as they crop up. The TC can then consider how to add lubrication/order/etc to the process and submit requests of some sort to the main TC.