Re: CAPABILITIES, again...

[Bruce_Kahn@xxxxxxxx]

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
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...