Subject: CAPABILITIES, again...

From: [email-masked] (Steve Mansour)
Date: Mon, 02 Aug 1999 13:43:57 -0700

Our current proposal for CAP has been to have "capabilities" information
returned as part of a successful connection, authentication, or change
of identity. The reasoning (I think) was to remove the need to send a
special command to get the server capabilities --it also makes the
command set smaller by one command..

There have been a couple of objections to this design. In particular,
there is concern over using a wireless transport or a limited bandwidth
transport. Is it bad design to force the transmission of this extra
information in response to a connection, or an authentication, or an
identity change?

What do people think?

-Steve

---

From: [email-masked]
Date: Mon, 02 Aug 1999 22:33:58 GMT

Steve:
I think that I was one of the primary individuals objecting to having a 
separate command. I don't have such reservations anymore. 
Some one gave me the compelling argument FOR such an individual command by 
pointing out that the only way to rediscover what your capabilities were 
was to either change your identity or reauthenticate the connection. Seems 
rather rough a requirement.
So if folks agree, I don't see a reason why we shouldn't include a 
separate CAPABILITIES command.
-- Frank

---

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

> Date: Mon, 02 Aug 1999 15:31:03 -0700
> From: [email-masked] (Steve Mansour)
> 
> Doug Royer wrote:
> 
> > > Date: Mon, 02 Aug 1999 13:43:57 -0700
> > > From: [email-masked] (Steve Mansour)
> > >
> > And it reduces round trip time for low bandwidth connections.
> 
> > The first thing you have to do is to send a capability when connecting
> > to determine what AUTH method to use for authentication.
> >
> > 100 % of the time?
> >
> > What 'extra' data are you talking about?
> 
> The capabilities data. The concern was this: What if we don't want the
> capabilities sent to us after we authenticate? 

My point is that you MUST do that anyway!

> By making the capabilities
> information part of the response to a successful authentication, you force
> that data to be transmitted even if we don't want it.

Don't want it? You *MUST* have it, or you don't know what a user
is enabled to do as what a CAPABILITY command can send out may
vary depending on the ID of the authenticated user. (An admin
for example might get more capabilities than a non-admin).

> Wireless folks, now is the time to speak up.

I do not see this as a wireless issue. I think it is a MUST to
re-CAPABILITY after authenticate as WHAT you can do may not
be the same as WHAT another user can do, if you don't ask
or send the data - how will you find out?

-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: [email-masked]
Date: Wed, 25 Aug 1999 10:23:34 -0400

>My point is that you MUST do that anyway!

I dont see why.  Please explain the need to do this to me.  If my CUA is 
configured for accessing a CS anonymously, why does it care about the 15 
different AUTH abilities??  It doesn't.   If I configure my CUA to "Always 
use secure transport" then it would want to do this.  However, I dont see 
many wireless clients doing TLS for everything...

Bruce
===========================================================================
Bruce Kahn                                INet: [email-masked]
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: [email-masked]
Date: Wed, 25 Aug 1999 10:27:05 -0400

Frank wrote:
>Some one gave me the compelling argument FOR 
>such an individual command by pointing out that
>the only way to rediscover what your capabilities
>were was to either change your identity or 
>reauthenticate the connection.

Actually, enabling link level security/encryption is another case too. 
This involves no App level state changes, merely a transport level change. 
 In the future Im sure we will find more cases where this could also be 
true.

>So if folks agree, I don't see a reason why we 
>shouldn't include a separate CAPABILITIES command. 

So far I think we have general agreement that CAPABILITIES should be 
reinstated as a separate command. 

Bruce

---

From: [email-masked]
Date: Wed, 25 Aug 1999 12:32:13 -0400

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

  Besides the issue of the amount of data, its also a bad design to do 
this for every command that results in a potential change of what 
CAPABILITIES data is returned.  If we start to add other commands that do 
the same (ie: StartTLS, BeginWidget, etc) and each in effect changes what 
data could be sent back then we just bloat the return data stream and have 
made it an implicit requirement of all new additions that they potentially 
do this in addition to possibly returning data.  If a new BeginWidget 
results in some data that has to be sent back then how would we cleanly 
deliniate it from the "update" CAPABILITIES that may also be sent back?? 
This is just a slipperly slope to bad architecture!

  Now, how about adding another level of complexity and having several ops 
that are 'chained' by the CUA (ie: Connect, StartTLS, AUTH AWSEOME-1024 
bits, BeginWidget, ...)  If each modifies the capabilities but the CUA 
only cares about those between AUTH AWESOME-1024 and BeginWidget then why 
should the CS need to keep sending possibly different data?  Waste of 
bandwidth and CS cycles (not good for ISPs, etc).

  KISS: If > 1 command is going to return the same (even optionally) data 
then that begs for this to be centralized into 1 command that the CUA 
should use instead. 

>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.

  This is a slippery slope into expansion hell.  As before, this basically 
predicates that any CAP, CAPrev2, etc addition that also affects 
capabilities must (even optionally) return the same data.   This just 
makes the ABNF and state machines bigger and uglier w/o any benefit.

  Also what if the AUTHENTICATE failes between a whiz bang CUA that has 20 
AUTH mechanisms and the CS that only supports 5?  Unless the CUA gets 
lucky and hits 1 of those 5 it wouldnt be able to query the CS for its 
supported AUTH schemes when it initially connected. 

  A simpler and more robust design was already in the preliminiary CAP 
drafts (check out http://www.imc.org/draft-ietf-calsch-cap).  Provide the 
information on demand in 1 of 2 states.  It would look something like this 
on initial connect (paraphrasing RFCs 1869/2487 and 2595 a bit):

       S: <wait for connection>
       C: <open connection to server>
       S: 2.0;calendar.acmevendor.com here
       C: CAPABILITY
       S: 2.0;Here is what you can do
       S: CAPrev1
       S: MAXICALOBJECTSIZE=1000
       S: STARTTLS
       S: AUTH=KERBEROS_V4
       S: AUTH=EXTERNAL
       S: .
       C: STARTTLS
       S: 2.0;Let's dance...
       C: <starts TLS negotiation>
   C & S: <negotiate a TLS session>
   C & S: <check result of negotiation>
       C: CAPABILITY
       S: 2.0;Here is what you can do
       S: CAPrev1
       S: MAXICALOBJECTSIZE=1000
       S: STARTTLS
       S: AUTH=X-BIGWIDGET
       S: AUTH=KERBEROS_V4
       S: AUTH=EXTERNAL
       S: AUTH=PLAIN
       S: .

This allows the CUAs to check when they want to.  Isnt this what CUs and 
CUA really want?

Bruce

---

From: [email-masked]
Date: Wed, 25 Aug 1999 12:41:14 -0400

Alex asked:
>The issue is _not_ whether they should be sent at all, everyone
>agrees (I hope) that capabilities need to be resent after 
>authentication.

We all agree that the CUA needs a clear way to determine what they can or 
cannot do.  Bind probing is just not a good idea.  However I for one dont 
think it needs to be _automatic_ on an AUTHENTICATE.

If Im in Anonymously attempting to read the local concert calendar then 
what do I care what the MAXICALOBJECTSIZE, MINDATE, MAXDATE, etc are?  If 
I am only doing a simple 'read' of any upcoming events in the next 30 days 
then do I really care??  Probably not.

If I am using my CUA to access my personal calendar then my CUA would of 
course be interested in the info.   Having it optional on AUTHENTICATE is 
a smaller convenience for some CUAs but it is also a nasty prescedent for 
other future commands.  I have to ask if this optional feature is worth 
the extra UI, doc, and coding cycles compared to a KISS (and more modular) 
approach of centralizing it into a single command.  Im leaning (as you can 
guess by now) towards the "Put it into 1 command only and let the CUA deal 
w/it as it sees fit since it knows its reqs best" case.

Bruce

---

From: Doug Royer <[email-masked]>
Date: Wed, 25 Aug 1999 11:34:22 -0700 (PDT)

> From: [email-masked]
> Date: Wed, 25 Aug 1999 10:23:34 -0400
> 
> Doug replied with:

Because your ISP may change CS versions or vendors and what you can
do might change. If the CUA assumes that it is the same as the last
time it contacted the same site, things may break.

-Doug

---

From: Doug Royer <[email-masked]>
Date: Wed, 25 Aug 1999 12:51:55 -0700 (PDT)

> Date: Wed, 25 Aug 1999 12:41:14 -0400
>
> ...
>

I now agree.

I do however think that a CUA must be strongly encouraged to ask for
CAPABILITY in order to be inter operable across vendors.  If a CUA
were to never ask - and assume one vendors CS - interoperability goes
out the window.  As one CS might not support 'AUTH=FOO'.

I am not sure how to do this without mandating the CAPABILITY
command be issued at the appropriate points.

-Doug

---

From: Doug Royer <[email-masked]>
Date: Wed, 25 Aug 1999 12:45:10 -0700 (PDT)

> Date: Wed, 25 Aug 1999 12:32:13 -0400
> 
> Alex proposed:

You have convinced me :-)

I retract my proposal for the CAPABILITY reply to automatically
be part of the reply for connect and authenticate. ...

Anyone else still want it?

-Doug

---

From: [email-masked]
Date: Thu, 26 Aug 1999 09:46:27 -0400

Doug commented:
>CAPABILITY in order to be inter operable across vendors.

Definitely!  I love all this agreement; kinda makes me giddy before my 
caffine kicks in... :^]

Bruce