OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

oiic-formation-discuss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


--- On Fri, 7/11/08, Dave Pawson <dave.pawson@gmail.com> wrote:

> From: Dave Pawson <dave.pawson@gmail.com>
> Subject: Re: [oiic-formation-discuss] Reason and example arguing for the use of an ODF (or XML) canonical form
> To: oiic-formation-discuss@lists.oasis-open.org
> Date: Friday, July 11, 2008, 2:12 AM
> 2008/7/11 jose lorenzo <hozelda@yahoo.com>:
> 
> > 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.
> 
> 
> > 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.
> 
> 
> The logic is solid, just that prior experience says that
> central
> registries don't work,
> don't get used, do get abused and have, in the past,
> failed to fulfill
> their promise.

I am considering such centralization as might happen through a third party CA (or more than one) and even name registries. I don't know what will work best, but to manage signatures beyond self-signing, you need some sort of trusted system which tends to mean in practice today (I think) that you have a small number of more trusted entities vouching for the rest.

The trick is to find something that allows the system to remain fluid (so that it be used) while providing non-negligible value.

Really, how many useful extensions are we likely to see? If there would be many, interop would get clobbered. A registry(-ies) of some sort allows the more useful extensions to be gathered and graded perhaps (eg, documentation provided and opinions of various users recorded). This smaller set should be enough to allow users to have fun while keeping "virus" and other subterfuge attacks in check (default drop). The registry(-ies) might also be set to handle implementations (eg, plugin signing.. eg, maybe Mozilla would handle this for browser plugins related to its browsers and ODF).

Even firewalls tend to work this way. Allow the few *known* (IANA or otherwise) and desired/expected conversations to occur while blocking/dropping the rest.

The theory sure sounds good to me. It works in some case, not in others.



      


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]