On 8/9/07, Peter Saint-Andre <[EMAIL PROTECTED]> wrote: > 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>
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 on". > > 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 recipients). -- Sergei Golovan
