Subject: W-5 CAP Should CAPABILITY reply ...

From: Doug Royer <[email-masked]>
Date: Tue, 17 Aug 1999 15:18:08 -0700 (PDT)

W-5 CAP Should CAPABILITY reply be sent        U
     as result of successful AUTHENTICATE
     and IDENTITY

I think the status of this is "'Y' - optional" ?
And that CAPABILITY is also a CAP command.

And I think that Steve is looking for a proposal for the ABNF/or 
syntax information.

Is all/any of the above correct?

-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, 18 Aug 1999 15:37:53 GMT

Hhhhhhhmmmmmmmmmmmm.
How about these change instructions:
1. Add to section 2.3:
CAPABILITIES    Request a list of the CS capabilities.

2. Add a new subsection to 7.1 with:
1.1.1   CAPABILITIES Command

Arguments:   None

Data:        None

Result:      2.0 Success
             x.x Not valid state for this command.
            10.2 Server shutting down.

The "CAPABILITIES" command allows the CUA to query the CS for it's list of 
capabilities. This command may be called in the Connected and 
Authenticated states. The results may differ based on the state.

The CS returns a list of its capabilities.

Examples: The following examples shows the response to 

        C: CAPABILITIES
        S: 2.0 ICAPv1, CCS, SCS, VCAR-POL, VCAR-GRA

I did not see any place in the existing specification where "ABNF" is 
specified for the commands. Maybe it should be? In addition, there needs 
to be examples for this command. The ones specified may not be complete.
-- Frank

---

From: [email-masked]
Date: Thu, 19 Aug 1999 09:55:53 -0400

>And that CAPABILITY is also a CAP command.

This is slippery slope that I think we should avoid.  If you take the 
approach of having an optional capability response to any command that 
changes what it possibly could be (ie: AUTHENTICATE, STARTTLS, IDENTITY, 
etc) then your set a dangerous precedence for future commands that also 
affect the users capabilities by making it semi-necessary to have them 
also return it (even if optionally).  IF they have to return other info in 
response to the command then it could become very confusing in parsing it 
all out; perhaps even nearly impossible.

KISS approach: Put CAPABILITY in 1 command and the CUA can querry it when 
it wants/needs to!  That way we do not bog down the state machine or ABNF 
w/extra optional stuff that just designs us down a slippery slope to very 
bad places.  (Having 3+ commands that return the same data begs for a 
single way to retrieve that data instead of 3+ separate ones!)

>And I think that Steve is looking for a proposal for the ABNF/or 

This KISS approach also has the benefit of keeping the ABNF simple.  No 
need to extend or change the existing syntax (maybe refine it a bit, maybe 
not).

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: Thu, 19 Aug 1999 15:11:08 GMT

Bruce:
Good idea. We had these other commands returning the capabilities string 
because we had removed the CAPABILITIES command. Now that it is back in, 
we should remove the string from being appended to the responses to these 
other disjoint commands.
This keeps the functionality of our commands more orthogonal. A good 
thing, in my mind.
-- Frank