[Standards] NEW: XEP-0224 (Attention)

Peter Saint-Andre stpeter at jabber.org
Thu Aug 9 19:40:48 UTC 2007

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'
  <attention xmlns='http://www.xmpp.org/extensions/xep-0224.html#ns'/>

The usage with a <body/> seems odd to me for the reason you point to:
the headline breaks the context of the chat session.

> 2) Since advertising of attention feature is supposed to depend on a
> recipient (and even on time since it can be turned on/off) it looks
> like any compliant client should make a disco#info query before ANY
> attention message sent. Isn't it an overkill?
> 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.

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.


Peter Saint-Andre

-------------- 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/2502620d/attachment.bin>

More information about the Standards mailing list