On Aug 5, 2008, at 12:01 AM, Peter Saint-Andre wrote:
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.
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.
Then do we need a feature for "IM" (as in, "sorry, this calendaring
resource doesn't do that instant messaging stuff")?
I've re-read this thread quickly.
I think dwd doesn't like negative features, and I tend to agree with
him (although guilty of implementing such a beast in the past). But
the need to mark resources as non-im is still there and it's real.
It seems that using an <identity> in the automation class could be
enough to signal non-IM interface. Or put it in another way, maybe we
should say that only clients/* should be interpreted as IM-capable
resources.
I like the part that only client/* should be interpreted as IM-
capable resources, but I don't know if that is too strict.
Best regards,
--
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: [EMAIL PROTECTED]
Use XMPP!
