Sergei Golovan wrote: > On 8/9/07, XMPP Extensions Editor <[EMAIL PROTECTED]> 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='[EMAIL PROTECTED]/lab'
to='[EMAIL PROTECTED]/home'
type='headline'>
<attention xmlns='http://www.xmpp.org/extensions/xep-0224.html#ns'/>
</message>
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
--
Peter Saint-Andre
https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
