Subject: Re: CAPABILITIES, again...

From: Doug Royer <[email-masked]>
Date: Mon, 2 Aug 1999 16:50:41 -0700 (PDT)

> Date: Mon, 02 Aug 1999 19:36:49 -0400
> From: Alexander Taler <[email-masked]>
> > 
> > I don't have a problem with a separate CAPABILITIES command.
> > 
> > I thought the question Steve asked was; Should connect, authenticate
> > and identity commands return the results of a CAPABILITIES command?
> > 
> > 1) The 1st thing a CUA MUST do after connecting is a CAPABILITIES command
> >    in order to determine which AUTH mechanism to use, correct?
> > 
> > 2) For security reasons a CS may wish NOT to broadcast non-AUTH
> >    CAPABILITIES at connect time, or connect + CAPABILITIES time.  So a
> >    CUA MUST re-send the CAPABILITIES command after authentication.
> > 
> > 3) Because one or more users may have additional permissions, these can
> >    not be determined any other way - other than issuing a CAPABILITIES
> >    command after a successful AUTH and IDENTITY commands.
> > 
> > For those reasons, I suggested:
> > 
> >         1) That AUTH only CAPABILITIES be sent as a result of
> >            a connect. As 100% of the time a CUA MUST ask after
> >            a connect. So why not send it as a result of connect?
> > 
> >         2) Then after a successful AUTH has completed. A CUA
> >            MUST then get the CAPABILITIES for that authenticated
> >            user. So why not send it as a result of a successful
> >            authentication?
> > 
> >         3) If the user changes identity (Via the IDENTITY command).
> >            Then a CUA MUST re-issues a CAPABILITIES command.
> >            So why not send it as a result of a successful IDENTIFY?
> > 
> > -Doug
> 
> A CUA which is regularly polling a CS, but not maintaining a 
> connection, will store authentication information and will 
> not need the capabilities after every logon.

A CUA implementation MIGHT cache the information. Are you adding such
a requirement to the CUA?

> However, if we are not talking about a significant amount of 
> data then sending it after AUTHENTICATE shouldn't be a problem.

If the results of a CAPABILITY were to change, how would the
CUA know? If it did not ask each time?

> How about we make it optional to return them after AUTHENTICATE
> and provide a CAPABILITIES command?  Then administrators could
> tailor the server to their needs.

I could live with that.

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

---

From: Alexander Taler <[email-masked]>
Date: Mon, 02 Aug 1999 20:00:27 -0400

> a requirement to the CUA?

Yes, a CUA _might_ store that information.

> CUA know? If it did not ask each time?
 
The issue is how the capabilities should be sent to the CUA,
as a result of AUTHENTICATE, or from a CAPABILITY command.  
The issue is _not_ whether they should be sent at all, everyone
agrees (I hope) that capabilities need to be resent after 
authentication.

> > tailor the server to their needs.

Let me rephrase that:

"The transport-level capabilities MAY be returned as a result of
a successful AUTHENTICATE command."

We still have a "CAPABILITY" command.

Can everyone else live with that?

Alex (Always trying to have his cake and eat it too.)