Subject: Re: Access Control deferred?

From: Doug Royer <[email-masked]>
Date: Wed, 20 Jan 1999 16:07:49 -0800 (PST)

> Date: Wed, 20 Jan 1999 17:07:41 -0500
> From: "Paul B. Hill" <[email-masked]>
> 
> >Creating a 'delegate' means different things to different implementations.
> >That's why I think the only way this will work is if we allow for
> >a grammar that will allow for finer control over access (attribute
> >hiding from the 3rd user).
> >
> 
> So are you saying that existing vendor implemenations are being used to
> determine what can and cannot be addressed by the CAP requirements draft?

No - I am saying that we do not seem to be able to form a consensus.

-Doug
-------------------------------------------------------------------
[email-masked]		http://www.royer.com/People/Doug
801 W. El Camino #131		Work:   (650)786-7599
Mountain View, CA 94040		Ham Radio: N6AAW, Aviation: PP-ASEL

---

From: "Paul B. Hill" <[email-masked]>
Date: Wed, 20 Jan 1999 19:32:03 -0500

>No - I am saying that we do not seem to be able to form a consensus.

OK. I don't mean to be picking on Doug, it's just that he is actually
willing to use the list :) In private conversations I've formed an
impression that several of the editors have tended to agree with some of my
views. But when working on the requirements document the discussions
quickly delve into a "yeah, here's how I would implement it." Followed by a
comment like, "no, to do that right you need to change the architecture so
that it works like this..." And a few hours later everyone concludes that
the requirement should be deferred because they couldn't agree on an
implementation. 

Before anyone gets mad, please note that I said that this was _my_
_impression_, it does not necessarily reflect reality.

I haven't actually noticed this list being used to effectively determine
what the consensus is for CAP requirements. Many are assuming that silence
means consensus. At this time I do not believe that we have a consensus
because of conversations that I have had external to the list.

---

From: [email-masked] (Steve Mansour)
Date: Wed, 20 Jan 1999 18:11:39 -0800

> the requirement should be deferred because they couldn't agree on an

As I recall, it wasn't that people couldn't agree on implementations. We've been
pretty good about staying clear of implementation discussions at the editors
meetings. One big concern was that the granularity of access control being
discussed made a pretty high barrier to entry. There was concern that we might
place too high a bar and preclude certain devices (palm tops, etc.) from
providing implementations. Feedback on this from anyone involved in such work
would be great.

-Steve

---

From: "Mark Poepping" <[email-masked]>
Date: Thu, 21 Jan 1999 00:03:51 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Steve Mansour
> Sent: Wednesday, January 20, 1999 9:12 PM
> To: Paul B. Hill
> Subject: Re: Access Control deferred?
>
>

I'm not a vendor of handheld products, but...

I don't understand the high barrier..  It strikes me that the
implementor of a handheld client needn't necessarily implement
a full ACL management interface, and that the client (or perhaps
the server by some later revision of the protocol) could simply
default to some chosen ACL, like 'me:rw, else:free-busy'.  This
complies with an ACL-inclusive CAP, and is very lightweight.

I think that every [serious] calendar 'server' product will have
ACLs, so we should specify a standard to enable interoperability.
Not specifying a standard will ensure incompatibility.

mark.

---

From: Pat Egen <[email-masked]>
Date: Fri, 22 Jan 1999 18:11:17 -0500

I agree with Mark.  Handhelds tend to work with a server anyway (either to
upload or download) and the server should be able to handle the ACL.  I also
agree that if we don't specify some sort of standard there will be
incompatibility.  History will repeat itself yet again.