Subject: Re: BEEP and CAP - one-to-many

From: "John Stracke" <[email-masked]>
Date: Fri, 15 Mar 2002 12:27:47 -0500

>> But, Doug, that doesn't solve the thin-client problem you were talking 
>> about, because the MAY leaves it entirely up to the CS.  A thin client 
>> that can't handle a monolithic reply can't tell whether the CS will 
send 
>> one or not.  Right?
>
>Thin clients pick their provider.

Calendaring thin clients do today, because they have no choice.  In the 
email world, this is not the case; there are PDA and Web-based MUAs that 
can work with any IMAP server.  The same should be true for CAP.

/========================================================\
|John Stracke                    |Principal Engineer     |
[email-masked]   |Incentive Systems, Inc.|
|http://www.incentivesystems.com |My opinions are my own.|
|========================================================|
|Linux: the Unix defragmentation tool.                   |
\========================================================/

---

From: Doug Royer <[email-masked]>
Date: Fri, 15 Mar 2002 11:18:15 -0700

> can work with any IMAP server.  The same should be true for CAP.

How about we add a capability 'can-multipart' ?
For both the CS and the CUA. This would also solve the large
vendor problem where they seem to refuse to do multipart.

If one end of the connection does not advertise it, then the
other end MUST "do one to many"?