Subject: Re: CAPABILITIES, again...

From: Doug Royer <[email-masked]>
Date: Mon, 2 Aug 1999 14:36:08 -0700 (PDT)

> Date: Mon, 02 Aug 1999 13:43:57 -0700
> From: [email-masked] (Steve Mansour)
> 
> 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..

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?

> 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 'extra' data are you talking about?

I don't recall anyone adding any data this way.

> What do people think?

-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] (Steve Mansour)
Date: Mon, 02 Aug 1999 15:31:03 -0700

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

Wireless folks, now is the time to speak up.

-Steve