[Standards] presence priority -1 issues

Dave Cridland dave at cridland.net
Thu Jul 31 19:47:25 UTC 2008


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:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade



More information about the Standards mailing list