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

From: [email-masked]
Date: Fri, 1 Oct 1999 11:27:28 -0400

Richard Schusterman wrote, in part:
>This action item was not a question. It was a placeholder for someone (I
>suppose it should have been me) to propose a way for a CUA to retrieve
>user properties from a CS using CAP. Examples of user properties that
>would be useful to a CUA:
>
>   * First and last name of this user.
>   * A default calendar to fetch for this user.
>   * The URI's that are described by the draft-ietf-calsch-locating
>     document.

The assumption then is that the "user profile" is a server function. Okay. 
That answers my earlier question.
However, I don't believe that this was a user requirement in the 
requirements document. Right? If not, then this should be deferred to a 
future version as it appears that we have a full plate of functions, as it 
is.
Even if this is a current requirement, I question the merits of it. In 
current practice, "user profiles" for applications can be kept in the CUA, 
the CS or even in a common directory. I prefer the former, but can also 
see rationale for the latter. However, to stuff this kind of 
meta-information about a CUA in the CS doesn't seem to me to be the 
direction that the rest of the world is taking. What if the server is down 
and the CUA wants to access a backup server? How does it get to this 
information? By going to the backup server's copy of the "user profile"? 
That is data redundancy and also leaves open the opportunity for data 
integrity discrepancies due to delays or errors in synchronization between 
the two profile's settings. In addition, this approach wouldn't seem to 
scale very well.
I suggest, mark this as closed or defer it.
-- Frank

---

From: [email-masked] (Richard Shusterman)
Date: Fri, 01 Oct 1999 11:33:23 -0700

Let's not mix implementation details (like where the user profile is
stored and whether it has to be sync'ed between two servers) with CUA
and CS requirements for CAP. Although the original CAP requirements (for
example, access control used to be a deferred requirement) did not list
a CUA requirement to get/set user profiles, it did state that CAP must
support "How to allow for CUAs without local store and with minimal
memory."

So, what I'm arguing for here is a optional capability that, if
implemented by the CS, allows a CUA to get/set basic user profile
information. Where this user profile is stored should not be part of
CAP. We just need to define the commands/responses that allows the CUA
to get/set this information thru a CS. At a minimum, we should at least
define the "get" command/response so that a CUA does not have to store
or prompt for the user's first/last name and calid - all it needs from
the user is a login name/password.

As for the "direction that the rest of the world is taking", I actually
think there is a movement towards smaller (thin) clients vs larger (fat)
clients. This argues for making sure that a small, thin CUA can be a
reasonable calendar application without keeping local storage or having
to implement multiple protocols.

[email-masked] wrote:

>
> Richard Shusterman wrote, in part:
>
> The assumption then is that the "user profile" is a server function.
> Okay. That answers my earlier question.
>
> requirements document. Right? If not, then this should be deferred to
> a future version as it appears that we have a full plate of functions,
> as it is.
>
> current practice, "user profiles" for applications can be kept in the
> CUA, the CS or even in a common directory. I prefer the former, but
> can also see rationale for the latter. However, to stuff this kind of
> direction that the rest of the world is taking. What if the server is
> down and the CUA wants to access a backup server? How does it get to
> this information? By going to the backup server's copy of the "user
> profile"? That is data redundancy and also leaves open the opportunity
> for data integrity discrepancies due to delays or errors in
> synchronization between the two profile's settings. In addition, this
> approach wouldn't seem to scale very well.
>

---

From: John Stracke <[email-masked]>
Date: Fri, 01 Oct 1999 15:26:39 -0400

Richard Shusterman wrote:

> information.

This sounds like it'd be redundant with ACAP (Application Configuration
Access Protocol, RFC-2244).  I think a monolayer client should probably use
ACAP directly rather than shoehorning identical functionality into CAP.

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |Life is like a metaphor.                     |
[email-masked]|                                             |
\==============================================================/

---

From: [email-masked] (Richard Shusterman)
Date: Fri, 01 Oct 1999 14:45:35 -0700

Oops, forgot to CC the working group.

Richard Shusterman wrote:

> Uh, what's ACAP got to do with this discussion? Why not suggest LDAP instead
> (it's more widespread)?
>
> What I'm trying to say is that small (thin) CUAs do not want to talk to
> multiple servers and use multiple protocols. For example, such a CUA might
> simply want to connect to a CS, authenticate as user X, fetch user X's default
> calid Y, and then disconnect.
>
> X does not necessarily equal Y, that Y is required as a target for all CAP
> application commands, and that Y may be a long string of characters (to
> guarantee unique of calid's) that user X has not memorized.
>
> Hmmm, one way to avoid having this CUA request user X's default calid Y would
> be for Y to be returned as part of the AUTHENTICATE command response. If we can
> at least add this response to CAP, that may be sufficient for this first
> version of CAP. It would be real nice to have a way to "pass thru" simple
> directory queries/responses thru CAP (to what is probably an external user
> directory) ...
>
> John Stracke wrote:
>

---

From: John Stracke <[email-masked]>
Date: Sun, 03 Oct 1999 21:12:55 -0400

Richard Shusterman wrote:

> > Uh, what's ACAP got to do with this discussion?

Everything.  You're talking about application configuration information, after all.

> > multiple servers and use multiple protocols.

How exactly is it worse for a thin client to speak CAP and ACAP than to speak
CAP-with-ACAP-like-features-thrown-in? I can think of a few ways separate protocols
are better for a thin client, actually:

   * Separate protocols means you can deploy separate servers if you want, which
     means better scalability.  Since the server is the bottleneck for all your thin
     clients, scalability is essential.
   * Smaller protocols means simpler servers, which, again, means better
     scalability.
   * Simpler servers can mean better security, since it's easier to do a security
     analysis.
   * Simpler servers are cheaper.

> > It would be real nice to have a way to "pass thru" simple

How simple? Wherever you draw the line, sooner or later you'll find a use case that
says you need something more complicated; before you know it, you've got the whole
camel in the tent with you.  Just use the existing protocols.

--
/================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.  |
|Chief Scientist |===============================================|
|eCal Corp.      |Beware of wizards, for you are crunchy and good|
[email-masked]|with ketchup.                                  |
\================================================================/

---

From: Doug Royer <[email-masked]>
Date: Mon, 04 Oct 1999 07:39:41 -0700

> a future version as it appears that we have a full plate of functions,

I also don't think it was in cap requirements.
 
> I suggest, mark this as closed or defer it.

ACAP is where user prefs go. I am willing to see Richard's proposal
before we close it in case there is something we missed.

-Doug

---

From: Doug Royer <[email-masked]>
Date: Mon, 04 Oct 1999 07:58:46 -0700

> > Uh, what's ACAP got to do with this discussion?

I agree with John. It looks like what you want is ACAP.

> Why not suggest LDAP instead (it's more widespread)?

Different issue. LDAP is a phone book and a protocol
to that phone book. ACAP is a protocol that describes how
to Get/Set user properties.

> > simply want to connect to a CS, authenticate as user X, fetch user X's\
> > default calid Y, and then disconnect.

I agree. However a lot of time was spent on ACAP on those issues.

> > Hmmm, one way to avoid having this CUA request user X's default calid Y
> > would be for Y to be returned as part of the AUTHENTICATE command
> > response. If we can at least add this response to CAP, that may be 
> > sufficient for this first version of CAP. It would be real nice to
> > have a way to "pass thru" simple directory queries/responses thru
> > CAP (to what is probably an external user directory) ...

I understand the issues now that you have explained them - thanks.

But Frank is right in that maybe this needs to be a separate task.
Lets design CAP so that something like this could be added in the
future. However I don't see it as a MUST at this time.

-- 
Doug
--------------------------------------------------------------------------
Work: [email-masked]      Home    801 Woodside Rd #14-244
      530 E. Montecito St.         Office: Redwood City, CA 94061
      Santa Barbara, CA 93103
      805-957-1790 x541            Personal Email: [email-masked]