On Thu, 31 Jul 2008 20:47:25 +0100 Dave Cridland <[EMAIL PROTECTED]> wrote:
> On Thu Jul 31 17:54:32 2008, Pedro Melo wrote: > > > > On Jul 31, 2008, at 5:21 PM, Dave Cridland wrote: > > > >> On Thu Jul 31 17:17:40 2008, Pedro Melo wrote: > >>>> Moving forward, this would allow clever clients to observe > >>>> that it wasn't a IM client capable of handling calendaring > >>>> requests, but a dumb calendaring bot working on behalf of the > >>>> user. > >>> Not following. > >> > >> Clients could have an integrated calendaring app, allowing both > >> chat and calendaring traffic to happen to the same full jid. > >> > >> Alternately, it may only do one or the other. > > > > Yes, but then you would only need to publish the proper <feature>. > > > > What makes a automated system try a certain protocol is the > > feature, not the identity. The identity automation/calender (per > > Peter example) is only needed to mark a resource as a non-IM > > resource. > > > > > Right, except in the case of IM, features are advertised. But to > advertise a lack of IM, we need to change the identity, since we > don't have an IM feature. > > Of course, it'd really be automation/application, or > automation/daemon, since what kinds of protocols it's an automaton > for is, as you say, down to the features advertised. Protocols/features and the purpose of the application may be different. IMHO it depends on how much you want to distinguish. > > So a clever Calendar application that also allows chat would > > probably still announce itself with a client/pc but would also > > set <feature> to support cal-dav-over-xmpp, or whatever. > > Of course - but I'm somewhat against a negative feature, if there's > any alternative. +1 > Dave. Pavel -- Web: http://www.pavlix.net/ Jabber & Mail: pavlix(at)pavlix.net OpenID: pavlix.net
