Re: [oiic-formation-discuss] Reason and example arguing for the use of an ODF (or XML) canonical form

[jose lorenzo <hozelda@yahoo.com>]

--- On Fri, 7/11/08, Peter Dolding <oiaohm@gmail.com> wrote:

> From: Peter Dolding <oiaohm@gmail.com>
> Subject: Re: [oiic-formation-discuss] Reason and example arguing for the use of an ODF (or XML) canonical form
> To: hozelda@yahoo.com
> Cc: oiic-formation-discuss@lists.oasis-open.org
> Date: Friday, July 11, 2008, 12:09 AM
> On Fri, Jul 11, 2008 at 1:30 PM, jose lorenzo
> <hozelda@yahoo.com> wrote:
> > --- On Thu, 7/10/08, Peter Dolding
> <oiaohm@gmail.com> wrote:
> >
> >> From: Peter Dolding <oiaohm@gmail.com>
> >> Subject: Re: [oiic-formation-discuss] Reason and
> example arguing for the use of an ODF (or XML) canonical
> form
> >> To: "Bart Hanssens"
> <bart.hanssens@skynet.be>
> >> Cc: "Stuart A. Yeates"
> <syeates@gmail.com>,
> oiic-formation-discuss@lists.oasis-open.org
> >> Date: Thursday, July 10, 2008, 9:52 PM
> >> On Thu, Jul 10, 2008 at 4:12 AM, Bart Hanssens
> >> <bart.hanssens@skynet.be> wrote:
> >>
> >> > ODF 1.1, section 1.5:
> >> >
> >> > "There are no rules regarding the
> elements and
> >> attributes that actually
> >> > have to be supported by conforming
> applications,
> >> except that
> >> > applications should not use foreign elements
> and
...
> The issue here is there two different ways to handle what
> foreign
> keys.   One is Wild West Method.  Current 1.5.  No one
> completely
> knows how many foreign keys are in use and who is using
> them.   This
> in time leads to problems.  Someone create a foreign key
> that matches
> someone else or worse redefines what a foreign key does but
> other
> parities are using it without there knowledge.  In
> compatibility
> problems.
> 
> Next is a non Wild West Method.  You can still create what
> ever
> foreign keys you like.  Only limit needed added to 1.5 you
> must
> register them with a central body with a complete
> description.
> Anyone using foreign keys not register with required
> description is in
> breach of standard.   Also who ever registers a key first
> it is theirs
> unless the standard takes it.  Also being able to register
> that you
> are using that foreign key so the creator of it knows.
> 
> Small change to ODF.  Large change to information,
> compatibility and
> test ablity.   Information is key if like 10 different
> programs are
> using the same foreign key for a feature that is missing
> ODF most
> likely need that feature.  This is the other feature of
> register of
> stuff like foreign keys if I look thew the list of all
> ready foreign
> keys and the one I need is already there compatibility is
> automatically gained.
> 
> Compared to current setup where there is no compatibility
> bar reversed
> created unless a party decides to be nice and document. 
> Central body
> wins every time.
> 
> Getting the non Wild West Method keys is not a long
> process.  Even a
> mailing list could be the central body as long as its a
> agreed to be.
> Rules about what parties could email for foreign keys would
> have to be
> written for it.  Other than that no major overheads.  Under
> 8 hours
> clearance should be more than possible.   There should be
> no
> application needing quicker than that.
> 
> Everyone keeps on thinking of this as either or.   Ie
> either
> flexibility or testability of standard.  It more than
> possible to have
> both.  Flexibility alone equals problems and lack of
> information where
> the standard can be improved for everyone's good.
> 
> Final thing how in the current system do you know if
> someone is using
> foreign keys for information other than what they should.  
> Usage of
> foreign keys is 100 percent not Audit able at moment. 
> Central body
> makes it a Audit able thing.  Companies creating foreign
> keys for
> stuff that exists would be pointing to either not wanting
> to follow
> standard or section of standard document needing revising.
> 
> We are hear about testing compatibility.  Little alteration
> of
> standard makes our job more 100 percent.

Not sure if I understand you. Here is what I am assuming. The central authority would register names and associated information (like public keys) for managing third party namespaces.

This may be an important way to help manage extensibility.

Some issues involve the same issues at stake with domain names: contention for names and serious disputes. Perhaps ODF can standardize on requiring some sort of Internet Domain Name System based basis for namespacing. This way we don't reinvent the wheel. Eg, (iirc) Java requires DNS-based names for naming of /scoping library extensions. Actually, if this is done, we'd possibly have the issue of maintaining consistency. I think the Java approach is specifically intended (to reduce effort/overhead and) so that no other central store be created and then need be maintained consistent. Thus maybe the use of DNS would serve as an alternative to an ODF specific central store.

Let's look closer at DNS. Unlike with DNS, extensions do not require the existence of consensus/cooperation in order to allow messages to spread widely. This suggests we may not be using the right tool for the job if we go with DNS.

It would be easy to violate or fake extension names based on DNS. To address forging, we would rely on a system which would in part use signatures. I heard ODF 1.2 is working in this area. Sig support would imply a need for an ODF central registry or for the use of an existing system that already manages secure identity.

There are many details to be resolved, for example, the wording of 1.5 and elsewhere, who/what/how/where/.. registration would be handled if at all, and possibly working this registration approach into a profiles approach where only some profiles require the registering and/or signature support.

If I understand correctly and if I am thinking clearly right now, it makes sense that standardizing the use of central registration of some sort would be a way to advance interop. 1.5 and/or maybe elsewhere would require some changes. The main idea being to standardize more constraints on the use of foreign elements/attribs, with suggested examples given: to require use of an ODF specific central registration or perhaps require use of some existing identifying framework like DNS or preferably something more secure.