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.
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.
Dave.
--
Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
