dotgnu-general
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [DotGNU]More standards to look at


From: Norbert Bollow
Subject: Re: [DotGNU]More standards to look at
Date: Tue, 23 Oct 2001 10:44:13 +0200

Dan Kuykendall <address@hidden> wrote:

> Right now we have our own preferences system, as many others seem to do.
> I think this will be a critcal piece that we should get standardized on
> and fast.

Yes, this is important.

Given that there's a standards-track RFC out already, we should
strive to be as compatible with it as possible, within the
contraints that are given by our objectives.

> http://www.imc.org/rfc2244

I don't like this protocol at all.  There are no precautions for
protecting the user's privacy.  It is implied that ACAP is
supposed to be normally used over unencrypted connections.  When
this is done over an untrusted network, there is the risk that
someone can determine who uses what program when on which
computer.  I consider this a huge privacy violation.  Running
the protocol over an unencrypted connection does not necessarily
solve the problem, unless generous padding is applied to each
line that is sent by client or server.

A line-oriented protocol is a very bad way to carry out a
privacy-sensitive computer-to-computer communication.

For DotGNU, I think that this protocol is not useful, because we
want DotGNU to have strong privacy protection _and_ good speed.

> I did a search and found an xml-ized version (DTD) of that
> http://www.oasis-open.org/cover/draft-melnikov-acap-xml-00.txt

That is much more reasonable.  Now all we need is a reasonable,
XML-based way through which an application can request such
XML-ized configuration information.

> Some more good info about ACAP can be found in its white paper.
> http://asg.web.cmu.edu/acap/white-papers/acap-white-paper.html
> 
> This looks like a decent standard for storing preferences in a format
> that can be shared between apps and services.
> The main problem is that the standard is focused on solving mail
> preference solutions, but there is no reason why this couldnt be used or
> adapted to other solutions.

Yes.  ACAP is designed to be extensible.  I think it may be a
good strategy for us to define extensions and try to get them
turned into standards-track RFCs.

Greetings, Norbert.

-- 
A member of FreeDevelopers and the DotGNU Steering Committee: dotgnu.org
Norbert Bollow, Weidlistr.18, CH-8624 Gruet   (near Zurich, Switzerland)
Tel +41 1 972 20 59       Fax +41 1 972 20 69      http://thinkcoach.com
Your own domain with all your Mailman lists: $15/month  http://cisto.com


reply via email to

[Prev in Thread] Current Thread [Next in Thread]