Re: FW: client capabilities

[Dave Cridland <dave@xxxxxxxxxxxx>]

On Thu Sep 14 17:28:53 2006, Arnt Gulbrandsen wrote:
> Dave Cridland writes:
> > On Thu Sep 14 16:51:06 2006, Peter Coates wrote:
> > > Is it really that hard to emit an ENABLE command if a server 
> > > advertises ENABLE
> > > and MODSEQ?  Clients are supposed to be able to modify their 
> > > behaviour depending
> > > on the CAPABILITIES vector
> >
> > Yes, and mine does modify its behaviour according to all 28 
> > capability names it supports, but it has no idea what ENABLE might 
> > mean, nor MODSEQ, and nor would any other client built to conform 
> > to the Lemonade Profile.
>
> 28? That's twelve more than 
> http://www.iana.org/assignments/imap4-capabilities lists. Sounds 
> like you hold the world record of draft implementation, have some 
> updates for the IANA, or both. Perhaps you could compare your list 
> with the IANA's and send them an update if appropriate?

You sound skeptical. :-)

Polymer supports: 1) IMAP4, 2) IMAP4REV1, 3) NAMESPACE, 4) ACL, 5) 
RIGHTS, 6) CHILDREN, 7) LITERAL+,  8) UIDPLUS, 9) BINARY, 10) IDLE, 
11) ID, 12) MULTIAPPEND, 13) UNSELECT, 14) SORT, 15) LIST-EXTENDED, 
16) LOGINDISABLED, 17) AUTH, 18) STARTTLS, 19) ACL2, 20) SASL-IR, 21) 
ESEARCH, 22) MAILBOX-REFERRALS, 23) POSTADDRESS, 24) CATENATE, 25) 
URLAUTH, 26) LIST-SUBSCRIBED, 27) LISTEXT, 28) CONDSTORE, 29) 
COMPRESS.

Hmmm. Miscounted.

The IPL, the library it sits on, actually supports THREAD and 
ANNOTATE, although I'm not entirely sure if the latter works. The 
THREAD support does, I've used it to build various test scripts 
looking at compression behaviour across replies, and suchlike, but 
Polymer doesn't use it.

I don't think there's anything there that IANA needs to include. Some 
of these are expired drafts, some even abandoned in favour of 
different approaches. Polymer doesn't, for instance, care whether a 
server supports LISTEXT and LIST-SUBSCRIBED if it supports 
LIST-EXTENDED.

One good thing about an ENABLE command would be for client authors to 
be able to brag more openly about these things, and pretend it's part 
of the protocol. We could disguise it as being intended for server 
administrators to gather useful statistics. But I'd rather define a 
field in ID for that.

Dave.
--
Dave Cridland - mailto:dave@xxxxxxxxxxxx - xmpp:dwd@xxxxxxxxxx
 - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
 - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade