[Standards] NEW: XEP-0224 (Attention)

Peter Saint-Andre stpeter at jabber.org
Thu Aug 9 20:07:38 UTC 2007


Sergei Golovan wrote:
> On 8/9/07, Peter Saint-Andre <stpeter at jabber.org> wrote:
>> Sergei Golovan wrote:
>>> On 8/9/07, XMPP Extensions Editor <editor at xmpp.org> wrote:
>>>> Version 0.1 of XEP-0224 (Attention) has been released.
>>> I'd like to comment this version little bit:
>>>
>>> 1) Headline messages are not "normal messages which aren't to be
>>> stored offline". They serve another goal (see section 2.1.1 of RFC
>>> 3921) and cannot (or shouldn't?) be a part of any conversation. So, I
>>> think that it's inappropriate to use headline messages for attention
>>> purpose. If the message shouldn't be stored offline then it should use
>>> AMP (XEP-0079) for example.
>> I think that attention messages should not be sent with a <body/>, but
>> should be a standalone message of type='headline', like so:
>>
>> <message from='calvin at usrobots.lit/lab'
>>          to='herbie at usrobots.lit/home'
>>          type='headline'>
>>   <attention xmlns='http://www.xmpp.org/extensions/xep-0224.html#ns'/>
>> </message>
> 
> This message looks like <iq/> but <iq/> is better because the
> recipient may receive result in case of accepted attention or error in
> case of ignored one. The ability of getting a response even makes
> disco#info queries unnecessary.

Yes this seems like an acceptable use of IQ to me, though I don't know
if you really need a response to an attention request.

>>> 3) (Theoretical question) If we look at client capabilities XEP (115)
>>> we may see that it reaches it's purpose if a features list isn't
>>> changed (since the last sent presence at least) and is the same for
>>> all members in the user's roster. Is this "floating feature" (which
>>> can be switched on/off) really compatible with XEP-0115?
>> If a feature is switched on or off then the sender should send updated
>> caps information.
> 
> I see. But it looks like the client should resend presence on any
> change in features list. 

Exactly right.

> It seems to much for me. 

So don't implement caps.

> I'd like not to
> change features list at all. And the presence of a feature in the list
> should mean "the feature is supported" and not "the feature is turned
> on".

You misunderstand one of the main reasons for entity capabilities. If I
plug in a video camera and can now do Jingle video chat, people may want
to know about that.

>> If a feature is enabled or disabled on a per-recipient basis, then I
>> agree that it may not make sense to include it in the caps data.
>> However, I think it is better in this case and maybe in other (or most)
>> cases to include the attention namespace in the caps data and simply
>> ignore the attention request on the client side if the sender is not
>> allowed to poke the user in this way. Changing the disco#info results on
>> a per-recipient basis seems like overkill.
> 
> I'd not call a responding on disco#info and disco#items query per
> recipient an overkill.

In this case it seems like overkill to me -- the client needs to keep
track of who can even know that my client supports the attention
protocol. Why bother? Just filter it out on the client side. After all,
another client could send you attention requests even if your client
says that it doesn't support the protocol.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7354 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070809/7b8a2c83/attachment.bin>


More information about the Standards mailing list