[Standards] NEW: XEP-0224 (Attention)
sgolovan at nes.ru
Thu Aug 9 19:55:50 UTC 2007
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'
> <attention xmlns='http://www.xmpp.org/extensions/xep-0224.html#ns'/>
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.
> > 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. It seems to much for me. 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
> 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. Moreover, if a response to a disco#items
contains items it's necessary to put a correct JID to them (a real JID
for ordinary recipient, and the conference JID for a groupchat
More information about the Standards