Subject: Re: W-21 Get/Set user properties.

From: [email-masked]
Date: Mon, 4 Oct 1999 10:45:52 -0400

Richard:
It appears that your suggestion regards CAP as some "uber protocol". I 
don't hold that opinion. We should recognize that CAP needs to keep within 
well defined boundaries or we will find ourselves feature-creaping and not 
have the bandwidth/resources to complete our basic set of work.
The definition of server based user-profiles is a considerable amount of 
work and is a new work item. For example, we will need to study what kinds 
of properties define a CUA setup. This could go on for some time. In 
addition, we will have to have some work on the server side too. For 
example, will these properties need to be specified at the server-level, 
calendar-level or both? Should the profile be a new calendar component or 
just individual properties.
This is not something that can just be arbitrarily added to our scope of 
work. Do you have a formal proposal prepared for this work?
-- Frank

---

From: [email-masked] (Richard Shusterman)
Date: Mon, 04 Oct 1999 14:21:26 -0700

[email-masked] wrote:

> don't hold that opinion. We should recognize that CAP needs to keep
> within well defined boundaries or we will find ourselves
> feature-creaping and not have the bandwidth/resources to complete our
> basic set of work.
>
> The definition of server based user-profiles is a considerable amount
> of work and is a new work item. For example, we will need to study
> what kinds of properties define a CUA setup. This could go on for some
> time. In addition, we will have to have some work on the server side
> too. For example, will these properties need to be specified at the
> server-level, calendar-level or both? Should the profile be a new
> calendar component or just individual properties.
>
> This is not something that can just be arbitrarily added to our scope
> of work. Do you have a formal proposal prepared for this work?

Nope and I think we've beat this topic to death for now. Doug, please
close this work item.

My intention was/is not to overload CAP. What I was trying to do was
bring up one of the issues that has come up in offline CAP discussions.
Now that we've discussed this on the mailing list, I'm satisfied.

BTW, anyone have a good client and server implementation of ACAP to
offer :)

From the CAP draft:

"... There is no implied structure in a Relative CALID. It is an
arbitrary string of 7 bit ASCII characters. It may refer to the calendar
of a user or of a  resource such as a conference room. It MUST be unique
within the calendar store. It is recommended that the Relative CALID be
globally unique."

In a large population of calendars, these Relative CALID's will not be
very user friendly. As such, a CAP CUA will have to retrieve a user's
Relative CALID from somewhere, probably a ACAP server or perhaps, a LDAP
server. Since I've never heard of a commercial implementation of ACAP,
I'm guessing it'll be LDAP.

---

From: Doug Royer <[email-masked]>
Date: Mon, 04 Oct 1999 15:10:47 -0700

> Nope and I think we've beat this topic to death for now. Doug, please

Thanks - I have marked it 'N'

---

From: Doug Royer <[email-masked]>
Date: Mon, 04 Oct 1999 15:06:34 -0700

> I'm guessing it'll be LDAP.

Maybe this is an issue for the locate draft?

-Doug