subject:"Re\: \[Standards\] NEW\: XEP\-0224 \(Attention\)"

On Sat, Aug 11, 2007 at 02:06:19AM +0200, Andreas Monitzer wrote:
> On Aug 11, 2007, at 01:57, Sergei Golovan wrote:
> 
> >On 8/11/07, Andreas Monitzer <[EMAIL PROTECTED]> wrote:
> >>Hmm would that be so bad? A headline window will surely draw more
> >>attention than a regular message.
> >
> >How this separate window would associate with a chat thread?
> >Especially if chat and headline messages are stored in different
> >histories.
> 
> The message of the headline is not part of the discussion, and so  
> shouldn't be stored along the rest. There is no association.

My suggestion is that you send a message of type chat to the full JID of
the person you've been chatting with to get their attention. If we do
that, your worries about headline messages are moot.

> >IQ has a fixed clear structure. Its parsing usually performed by one
> >routine,
> 
> I don't know many XMPP implementations, but in libpurple,   
> is handled by a single function, whereas -handling is spread  
> around the whole XMPP plugin (since nearly every feature uses an iq  
> stanza at some point).

It sounds as if the handling of IQ vs. message stanzas is different in
different implementations, so I don't think we can take that as an
argument one way or the other.

It seems to me that these attention requests will be sent in the 
context of an existing chat. In that case, sending a chat message to 
the full JID would make sense:

This is pretty much equivalent to IQ except that no ack is needed or
expected. Which seems reasonable to me in this context. You're just
saying "hey!"

> >But it's not a big deal to process a message instead of IQ. What I
> >want from any protocol detail is a feedback. XMPP would be much nicer
> >if any stanza required an acknowledgement. 

Feel free to implement XEP-0198. Or just use SIP, they ack everything!

> For now, messages and
> >presences are thrown without an acknowledgement (except for an ugly
> >presence usage in XEP-0045 AFAIK). So, I'd like to use them as seldom
> >as possible. Only if using message is unavoidable it may be used. (If
> >I could, I'd use IQ even for a regular messaging.)
> 
> This sounds more like you have a general issue with the XMPP protocol  
> as such. This is outside the scope of my XEP, please discuss this on  
> this list on the topic of rfc3921bis.
> 
> andy

What Andy said.

Peter

Re: [Standards] NEW: XEP-0224 (Attention)


On Aug 11, 2007, at 01:57, Sergei Golovan wrote:


On 8/11/07, Andreas Monitzer <[EMAIL PROTECTED]> wrote:

Hmm would that be so bad? A headline window will surely draw more
attention than a regular message.


How this separate window would associate with a chat thread?
Especially if chat and headline messages are stored in different
histories.


The message of the headline is not part of the discussion, and so  
shouldn't be stored along the rest. There is no association.



IQ has a fixed clear structure. Its parsing usually performed by one
routine,


I don't know many XMPP implementations, but in libpurple,   
is handled by a single function, whereas -handling is spread  
around the whole XMPP plugin (since nearly every feature uses an iq  
stanza at some point).



But it's not a big deal to process a message instead of IQ. What I
want from any protocol detail is a feedback. XMPP would be much nicer
if any stanza required an acknowledgement. For now, messages and
presences are thrown without an acknowledgement (except for an ugly
presence usage in XEP-0045 AFAIK). So, I'd like to use them as seldom
as possible. Only if using message is unavoidable it may be used. (If
I could, I'd use IQ even for a regular messaging.)


This sounds more like you have a general issue with the XMPP protocol  
as such. This is outside the scope of my XEP, please discuss this on  
this list on the topic of rfc3921bis.


andy

Re: [Standards] NEW: XEP-0224 (Attention)

On 8/11/07, Andreas Monitzer <[EMAIL PROTECTED]> wrote:
> > include  into this message, Tkabber will show it in a separate
> > headlines window.
>
> Hmm would that be so bad? A headline window will surely draw more
> attention than a regular message.

How this separate window would associate with a chat thread?
Especially if chat and headline messages are stored in different
histories.

>
> > IQ is simple. Message is complicated.
>
> uh, why? There's much more code involved in an IQ stanza than in a
> message.

IQ has a fixed clear structure. Its parsing usually performed by one
routine, and to add support for some IQ namespace one can do something
like the following (example from Tkabber):

iq::register_handler set query
http://www.xmpp.org/extensions/xep-0224.html#ns
::plugins::attention::react

Message is a much more complicated object.

But it's not a big deal to process a message instead of IQ. What I
want from any protocol detail is a feedback. XMPP would be much nicer
if any stanza required an acknowledgement. For now, messages and
presences are thrown without an acknowledgement (except for an ugly
presence usage in XEP-0045 AFAIK). So, I'd like to use them as seldom
as possible. Only if using message is unavoidable it may be used. (If
I could, I'd use IQ even for a regular messaging.)

Though, if XMPP is for information which worth nothing then everyone
may use anything he wants.

Cheers!
-- 
Sergei Golovan

Re: [Standards] NEW: XEP-0224 (Attention)


On Aug 11, 2007, at 00:40, Sergei Golovan wrote:


On 8/11/07, Peter Saint-Andre <[EMAIL PROTECTED]> wrote:

If your client shows a message even though it doesn't understand the
only child element in that message, then you should file a bug  
with the

developers, because that violates RFC 3920.


I know. And this bug will be fixed. Though I still think that headline
messages aren't acceptable for drawing attention. If someone will
include  into this message, Tkabber will show it in a separate
headlines window.


Hmm would that be so bad? A headline window will surely draw more  
attention than a regular message.



IQ is simple. Message is complicated.


uh, why? There's much more code involved in an IQ stanza than in a  
message.


andy

Re: [Standards] NEW: XEP-0224 (Attention)

On 8/11/07, Peter Saint-Andre <[EMAIL PROTECTED]> wrote:
> If your client shows a message even though it doesn't understand the
> only child element in that message, then you should file a bug with the
> developers, because that violates RFC 3920.

I know. And this bug will be fixed. Though I still think that headline
messages aren't acceptable for drawing attention. If someone will
include  into this message, Tkabber will show it in a separate
headlines window. Or you want to add something like "client SHOULD
ignore all information included into attention message"?

IQ is simple. Message is complicated.

Cheers!
-- 
Sergei Golovan

Re: [Standards] NEW: XEP-0224 (Attention)

Andreas Monitzer wrote:

> Specs shouldn't be designed around bugs of existing implementations...

+1!




smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Standards] NEW: XEP-0224 (Attention)

Sergei Golovan wrote:
> On 8/11/07, Peter Saint-Andre <[EMAIL PROTECTED]> wrote:
>> If it's a chat message then it won't be a strange headline message. If
>> the message is empty except for the attention request then a client must
>> ignore the message if it doesn't understand the attention namespace, so
>> that won't result in strange empty messages. And several people on the
>> list don't think that the attention request is something that we need to
>> ack. But if others think this needs to be an IQ then I'm open to argument.
> 
> I know at least one client which will show an empty headline message
> (it's Tkabber, it can't imagine such strange headlines). Can someone
> bet that it's the only one?

If your client shows a message even though it doesn't understand the
only child element in that message, then you should file a bug with the
developers, because that violates RFC 3920.

Peter

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



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Standards] NEW: XEP-0224 (Attention)


On Aug 11, 2007, at 00:13, Sergei Golovan wrote:


I know at least one client which will show an empty headline message
(it's Tkabber, it can't imagine such strange headlines). Can someone
bet that it's the only one?


libpurple also had this bug, but I fixed it this summer. Maybe  
someone can file a bug on Tkabber?

Specs shouldn't be designed around bugs of existing implementations...

andy

Re: [Standards] NEW: XEP-0224 (Attention)

On 8/11/07, Peter Saint-Andre <[EMAIL PROTECTED]> wrote:
> If it's a chat message then it won't be a strange headline message. If
> the message is empty except for the attention request then a client must
> ignore the message if it doesn't understand the attention namespace, so
> that won't result in strange empty messages. And several people on the
> list don't think that the attention request is something that we need to
> ack. But if others think this needs to be an IQ then I'm open to argument.

I know at least one client which will show an empty headline message
(it's Tkabber, it can't imagine such strange headlines). Can someone
bet that it's the only one?

-- 
Sergei Golovan

Re: [Standards] NEW: XEP-0224 (Attention)

Sergei Golovan wrote:
> On 8/11/07, Peter Saint-Andre <[EMAIL PROTECTED]> wrote:
>> IMHO you should send a chat message to the full JID of the person you're
>> chatting with. One message, delivered to one resource, not acked. A
>> simple throw-away that says "hey!"
> 
> Well, I feel tired little bit of this discussion. 

Great, we tired you out! ;-)

> You may do with this XEP what you want :)

It's not what I want, it's what makes the most sense -- or at least what
reflects the consensus of the list. ;-)

> But I still think that working with IQ in XMPP is easier than with
> messages. And if a client doesn't support "attention poking via IQ"
> then it's OK. But if a client doesn't support "attention poking via
> message" then it will result in strange empty messages, or strange
> headline messages or whatever.

If it's a chat message then it won't be a strange headline message. If
the message is empty except for the attention request then a client must
ignore the message if it doesn't understand the attention namespace, so
that won't result in strange empty messages. And several people on the
list don't think that the attention request is something that we need to
ack. But if others think this needs to be an IQ then I'm open to argument.

/psa

smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Standards] NEW: XEP-0224 (Attention)

On 8/11/07, Peter Saint-Andre <[EMAIL PROTECTED]> wrote:
> IMHO you should send a chat message to the full JID of the person you're
> chatting with. One message, delivered to one resource, not acked. A
> simple throw-away that says "hey!"

Well, I feel tired little bit of this discussion. You may do with this
XEP what you want :)

But I still think that working with IQ in XMPP is easier than with
messages. And if a client doesn't support "attention poking via IQ"
then it's OK. But if a client doesn't support "attention poking via
message" then it will result in strange empty messages, or strange
headline messages or whatever.

Cheers!
-- 
Sergei Golovan

Re: [Standards] NEW: XEP-0224 (Attention)

Sergei Golovan wrote:
> On 8/11/07, Andreas Monitzer <[EMAIL PROTECTED]> wrote:
>> I think he's talking about the network transfer waste, not the coding
>> waste. Since all clients need some kind of handling sending iqs and
>> receiving them, this is not really a concern.
> 
> 'message type=headline' looks more wasteful than 'iq type=set' :)

IMHO you should send a chat message to the full JID of the person you're
chatting with. One message, delivered to one resource, not acked. A
simple throw-away that says "hey!"

smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Standards] NEW: XEP-0224 (Attention)

On 8/11/07, Andreas Monitzer <[EMAIL PROTECTED]> wrote:
> I think he's talking about the network transfer waste, not the coding
> waste. Since all clients need some kind of handling sending iqs and
> receiving them, this is not really a concern.

'message type=headline' looks more wasteful than 'iq type=set' :)

-- 
Sergei Golovan

Re: [Standards] NEW: XEP-0224 (Attention)

Andreas Monitzer wrote:
> On Aug 10, 2007, at 23:05, Sergei Golovan wrote:
> 
>> On 8/11/07, Peter Saint-Andre <[EMAIL PROTECTED]> wrote:
>>> Sergei Golovan wrote:
>>> OK then:
>>>
>>> But the recipient's client must send a reply if we use IQ, which seems
>>> wasteful for a little toy like this.
>>
>> Well, the first working draft of this toy (IQ-based, with a mandatory
>> reply) consists of 67 lines of code. Is it too wasteful?
> 
> I think he's talking about the network transfer waste, not the coding
> waste. Since all clients need some kind of handling sending iqs and
> receiving them, this is not really a concern.

Right. As I said in the jdev room (and I quote):

[13:14:06]  OMG you want a reliable transport for your stupid
buzz messages?!?!




smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Standards] NEW: XEP-0224 (Attention)


On Aug 10, 2007, at 23:05, Sergei Golovan wrote:


On 8/11/07, Peter Saint-Andre <[EMAIL PROTECTED]> wrote:

Sergei Golovan wrote:
OK then:

But the recipient's client must send a reply if we use IQ, which  
seems

wasteful for a little toy like this.


Well, the first working draft of this toy (IQ-based, with a mandatory
reply) consists of 67 lines of code. Is it too wasteful?


I think he's talking about the network transfer waste, not the coding  
waste. Since all clients need some kind of handling sending iqs and  
receiving them, this is not really a concern.


andy

Re: [Standards] NEW: XEP-0224 (Attention)

On 8/11/07, Peter Saint-Andre <[EMAIL PROTECTED]> wrote:
> Sergei Golovan wrote:
> OK then:
>
> But the recipient's client must send a reply if we use IQ, which seems
> wasteful for a little toy like this.

Well, the first working draft of this toy (IQ-based, with a mandatory
reply) consists of 67 lines of code. Is it too wasteful?

-- 
Sergei Golovan

Re: [Standards] NEW: XEP-0224 (Attention)

Sergei Golovan wrote:
> On 8/11/07, Peter Saint-Andre <[EMAIL PROTECTED]> wrote:
>> But the recipient must send a reply if we use IQ, which seems wasteful
>> for a little toy like this.
> 
> Not a recipient, but her client. As for Tkabber it will waste about
> 3-5 lines of code.

OK then:

But the recipient's client must send a reply if we use IQ, which seems
wasteful for a little toy like this.

/psa



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Standards] NEW: XEP-0224 (Attention)

On 8/11/07, Peter Saint-Andre <[EMAIL PROTECTED]> wrote:
>
> But the recipient must send a reply if we use IQ, which seems wasteful
> for a little toy like this.

Not a recipient, but her client. As for Tkabber it will waste about
3-5 lines of code.

-- 
Sergei Golovan

Re: [Standards] NEW: XEP-0224 (Attention)

Sergei Golovan wrote:
> On 8/11/07, Peter Saint-Andre <[EMAIL PROTECTED]> wrote:
>> Peter Saint-Andre wrote:
>> The more I think about it, the more it seems to me that this kind of
>> feature is a "throwaway" -- do you really need to receive a reply? You
>> just want to poke the other person. There's no need for a reliable
>> transport with fancy error messages and all that.
> 
> I think that if we can make less uncertainty an no cost (almost no
> cost) we should always do that. If a client author doesn't want to
> process replies it's up to him to ignore them.

But the recipient must send a reply if we use IQ, which seems wasteful
for a little toy like this.

/psa



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Standards] NEW: XEP-0224 (Attention)

On 8/11/07, Peter Saint-Andre <[EMAIL PROTECTED]> wrote:
> Peter Saint-Andre wrote:
> The more I think about it, the more it seems to me that this kind of
> feature is a "throwaway" -- do you really need to receive a reply? You
> just want to poke the other person. There's no need for a reliable
> transport with fancy error messages and all that.

I think that if we can make less uncertainty an no cost (almost no
cost) we should always do that. If a client author doesn't want to
process replies it's up to him to ignore them.

Cheers!
-- 
Sergei Golovan

Re: [Standards] NEW: XEP-0224 (Attention)

Peter Saint-Andre wrote:
> Andreas Monitzer wrote:
>> On Aug 10, 2007, at 15:30, Sergei Golovan wrote:
>>
>>> I just want to get a result of attention query.
>> Hmmm well, I personally wouldn't care about it (since you can't know if
>> the user noticed it anyways), but I'm rather indifferent on it. What's
>> the opinion of others on this list about it?
> 
> IQ seems good to me.
> 
> There are all sorts of potentially complicating factors involved here
> (multiple resources) but I think they are relatively minor. Much depends
> on the use case. Your examples showed one user sending the attention
> request in the context of an existing chat session. In that context you
> know the other person's resource and you are sending to that one because
> you want to other person to pay attention to the chat session. If you
> want to shake/buzz/etc. all of the user's resources then a message
> headline would be better.

We discussed it a bit more in the jdev room:

http://www.jabber.org/muc-logs/[EMAIL PROTECTED]/2007-08-10.html#13:06:39

The more I think about it, the more it seems to me that this kind of
feature is a "throwaway" -- do you really need to receive a reply? You
just want to poke the other person. There's no need for a reliable
transport with fancy error messages and all that.

Peter

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



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Standards] NEW: XEP-0224 (Attention)

Andreas Monitzer wrote:
> On Aug 10, 2007, at 15:30, Sergei Golovan wrote:
> 
>> I just want to get a result of attention query.
> 
> Hmmm well, I personally wouldn't care about it (since you can't know if
> the user noticed it anyways), but I'm rather indifferent on it. What's
> the opinion of others on this list about it?

IQ seems good to me.

There are all sorts of potentially complicating factors involved here
(multiple resources) but I think they are relatively minor. Much depends
on the use case. Your examples showed one user sending the attention
request in the context of an existing chat session. In that context you
know the other person's resource and you are sending to that one because
you want to other person to pay attention to the chat session. If you
want to shake/buzz/etc. all of the user's resources then a message
headline would be better.

And of course the XEP is just defining a payload format. A client could
send it either by message or by IQ. If you want to buzz one resource,
use IQ. If you want to buzz all resources, use message headline.

Peter

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

smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Standards] NEW: XEP-0224 (Attention)

Tomasz Sterna wrote:
> Dnia 10-08-2007, pią o godzinie 16:11 +0100, Richard Dobson napisał(a):
>> In that case you would just ignore the attempted shake for people who 
>> you dont want to be able to do it (and probably return an error of
>> some sort), but you can still publish that you allow it in your caps
>> if you allow it for some people in your roster,
> 
> Maybe we should think of extending Caps to allow publishing different
> capabilities to different contacts.

Over complicated. We made some tradeoffs with caps (and indeed with
presence itself) by using a broadcast model. If you don't want to
advertise a feature to everyone in your roster, don't include it in the
hash.

Peter

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




smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Standards] NEW: XEP-0224 (Attention)

2007-08-10 Thread Richard Dobson




Maybe we should think of extending Caps to allow publishing different
capabilities to different contacts.
  


Yea maybe, but we need to find a reason for it first, certainly in this 
case its not needed as in normal real world use people are just going to 
have it globally on or off, they arnt going to be bothered with enabling 
and disabling this tiny little feature for individual contacts, are 
there any other more actually credible use cases for it that we can 
think of?


Richard

Re: [Standards] NEW: XEP-0224 (Attention)

2007-08-10 Thread Tomasz Sterna

Dnia 10-08-2007, pią o godzinie 16:11 +0100, Richard Dobson napisał(a):
> In that case you would just ignore the attempted shake for people who 
> you dont want to be able to do it (and probably return an error of
> some sort), but you can still publish that you allow it in your caps
> if you allow it for some people in your roster,

Maybe we should think of extending Caps to allow publishing different
capabilities to different contacts.


-- 
Tomasz Sterna
Xiaoka Grp.  http://www.xiaoka.com/

Re: [Standards] NEW: XEP-0224 (Attention)

2007-08-10 Thread Richard Dobson




Unfortunately, no. I wouldn't like everyone in my roster to be able to
shake my client window. Instead I would like to implement a sort of
white list for this. And it's hard to represent in XEP-0115 hash that
somone is allowed to ask an attention query and others aren't.
  


In that case you would just ignore the attempted shake for people who 
you dont want to be able to do it (and probably return an error of some 
sort), but you can still publish that you allow it in your caps if you 
allow it for some people in your roster, I think your "whitelist" 
implementation is going to be pretty much in a minority and people are 
likely to just implement it how it works in MSN messenger and the like 
with a global on and off, normal users (Aunt Tilly) arnt going to be 
bothered with individually whitelisting specific users to allow it... 
Things dont need to be made overcomplicated.




IQ is perfectly compatible with unsupported clients. They definitely
reply with an error (if the client isn't an outdated Psi, which was
known to swallow unsupported IQ stanzas).
  


I would defianately vote to use IQ rather than message too. Also regards 
to the memory leak issue mentioned im not sure what thats all about, we 
shouldnt be hampering the design of optimum protocol just because of the 
possiblity that someone might have bugs in their software...


Richard

Re: [Standards] NEW: XEP-0224 (Attention)

On 8/10/07, Andreas Monitzer <[EMAIL PROTECTED]> wrote:
> On Aug 10, 2007, at 15:30, Sergei Golovan wrote:
>
> > And I don't like to make many disco#info queries to determine
> > current state of the remote client.
>
> That's what XEP-0115 is about, this is outside the scope of XEP-0224.

Unfortunately, no. I wouldn't like everyone in my roster to be able to
shake my client window. Instead I would like to implement a sort of
white list for this. And it's hard to represent in XEP-0115 hash that
somone is allowed to ask an attention query and others aren't.

> Further, you can just send it to non-supporting clients, too. The XEP

IQ is perfectly compatible with unsupported clients. They definitely
reply with an error (if the client isn't an outdated Psi, which was
known to swallow unsupported IQ stanzas).

> just says that you have to check for support, not that you must not
> send one to a non-supporting client (wouldn't do anything, though). I
> guess the disco#info check should be changed to a SHOULD instead of a
> MUST (I already changed that in my local version here).

I think that without a feedback this XEP is only a toy, not more. (But
since Jabber is good only as a toy anyway then it shouldn't matter
much :)

Cheers!
-- 
Sergei Golovan

Re: [Standards] NEW: XEP-0224 (Attention)


On Aug 10, 2007, at 15:30, Sergei Golovan wrote:


I just want to get a result of attention query.


Hmmm well, I personally wouldn't care about it (since you can't know  
if the user noticed it anyways), but I'm rather indifferent on it.  
What's the opinion of others on this list about it?


And I don't like to make many disco#info queries to determine  
current state of the remote client.


That's what XEP-0115 is about, this is outside the scope of XEP-0224.  
Further, you can just send it to non-supporting clients, too. The XEP  
just says that you have to check for support, not that you must not  
send one to a non-supporting client (wouldn't do anything, though). I  
guess the disco#info check should be changed to a SHOULD instead of a  
MUST (I already changed that in my local version here).


andy

Re: [Standards] NEW: XEP-0224 (Attention)

On 8/10/07, Andreas Monitzer <[EMAIL PROTECTED]> wrote:
> On Aug 10, 2007, at 15:12, Sergei Golovan wrote:
>
> > You're already use  to determine XEP support. So, I think that
> > anyway the message should be sent to a full JID.
> >
> > As for potential memory leak I would say that it's better to leave
> > this problem to a client developer. There are always clients, which
> > behave incorrectly. Do you want to completely avoid using s?
>
> No, but I want a specific reason to use an iq instead of a message.

I just want to get a result of attention query. And I don't like to
make many disco#info queries to determine current state of the remote
client.

-- 
Sergei Golovan

Re: [Standards] NEW: XEP-0224 (Attention)


On Aug 10, 2007, at 15:12, Sergei Golovan wrote:


You're already use  to determine XEP support. So, I think that
anyway the message should be sent to a full JID.

As for potential memory leak I would say that it's better to leave
this problem to a client developer. There are always clients, which
behave incorrectly. Do you want to completely avoid using s?


No, but I want a specific reason to use an iq instead of a message.

andy

Re: [Standards] NEW: XEP-0224 (Attention)

On 8/10/07, Andreas Monitzer <[EMAIL PROTECTED]> wrote:
> On Aug 09, 2007, at 21:55, Sergei Golovan wrote:
>
> >> I think that attention messages should not be sent with a ,
> >> but
> >> should be a standalone message of type='headline', like so:
> >>
> >>  >>  to='[EMAIL PROTECTED]/home'
> >>  type='headline'>
> >>   
> >> 
> >
> > This message looks like  but  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.
>
> I chose to use  instead of  because you don't have to
> specify a resource to send the message, and you don't need a reply on
> this one (every -message is a potential memory leak, when the
> receiving client doesn't behave properly), because even when the
> client displays the attention grabbing event, you can't know if the
> user has seen/heard it. Is there a serious reason to go to ?

You're already use  to determine XEP support. So, I think that
anyway the message should be sent to a full JID.

As for potential memory leak I would say that it's better to leave
this problem to a client developer. There are always clients, which
behave incorrectly. Do you want to completely avoid using s?

Cheers!
-- 
Sergei Golovan

Re: [Standards] NEW: XEP-0224 (Attention)


On Aug 09, 2007, at 22:46, Olivier Goffart wrote:

I think the lower important level is related and should be include  
to this

XEP.


If you don't want immediate attention, why send the attention  
grabbing message in the first place? I could see a usecase for  
"normal" and "urgent", but then again, once you do send that  
attention message, it's always urgent anyways. I don't think you can  
ask the originating users to make that distinction. I'd guess the  
local client could make that differentiation based on the own  
presence (don't play the attention sound when DND, only flash the  
screen, for example).


andy

Re: [Standards] NEW: XEP-0224 (Attention)


On Aug 09, 2007, at 21:55, Sergei Golovan wrote:

I think that attention messages should not be sent with a ,  
but

should be a standalone message of type='headline', like so:


  




This message looks like  but  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.


I chose to use  instead of  because you don't have to  
specify a resource to send the message, and you don't need a reply on  
this one (every -message is a potential memory leak, when the  
receiving client doesn't behave properly), because even when the  
client displays the attention grabbing event, you can't know if the  
user has seen/heard it. Is there a serious reason to go to ?


The  element is not required in this spec, but I could change  
it to SHOULD NOT contain, would that be better?


andy

Re: [Standards] NEW: XEP-0224 (Attention)

Olivier Goffart wrote:
> Le jeudi 9 août 2007, Peter Saint-Andre a écrit :
>> Olivier Goffart wrote:
>>> Le mercredi 8 août 2007, XMPP Extensions Editor a écrit :
 Version 0.1 of XEP-0224 (Attention) has been released.

 Abstract: This document defines an XMPP protocol extension for getting
 the attention of another user.
> 
 URL: http://www.xmpp.org/extensions/xep-0224.html
>>> One year ago, i also wrote a JEP about that (but never published it)
>>>
>>> The concept is quite the same.  (but i also defined a lower important
>>> message level)
>>>
>>> I did not publish it because I was thinking it could be included in the
>>> SHIM (XEP-0131)
>> You mean like this?
>>
>> http://www.xmpp.org/extensions/xep-0131.html#headers-urgency
> 
> Exactly.
> 
> If we agree that urgent message demand a particular attention, we have two 
> different specification for the same thing.
> 
> The only difference is that you may demand attention for the previous message 
> you sent.  The message which demand the attention is not urgent itself, only 
> the whole discussion is.
> Bu i think it probably doesn't matter.
> 
> What I suggest is to modify the XEP-0224 into a kind of "Best Practices" 
> or "Buisness rules" regarding important messages.

I think the idea behind "attention" is different. The reference to
XEP-0132 in the introduction to XEP-0224 is not just a joke. The
protocol is not intended as a way to flag a message as more important,
but literally to poke or prod the contact, as in "hey, pay attention".
Personally I don't think I would ever use the feature, but it's one of
those things that lots of end users think is cool, so who am I to deny
them their fun?

/psa





smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Standards] NEW: XEP-0224 (Attention)

2007-08-09 Thread Olivier Goffart

Le jeudi 9 août 2007, Peter Saint-Andre a écrit :
> Olivier Goffart wrote:
> > Le mercredi 8 août 2007, XMPP Extensions Editor a écrit :
> >> Version 0.1 of XEP-0224 (Attention) has been released.
> >>
> >> Abstract: This document defines an XMPP protocol extension for getting
> >> the attention of another user.

> >> URL: http://www.xmpp.org/extensions/xep-0224.html
> >
> > One year ago, i also wrote a JEP about that (but never published it)
> >
> > The concept is quite the same.  (but i also defined a lower important
> > message level)
> >
> > I did not publish it because I was thinking it could be included in the
> > SHIM (XEP-0131)
>
> You mean like this?
>
> http://www.xmpp.org/extensions/xep-0131.html#headers-urgency

Exactly.

If we agree that urgent message demand a particular attention, we have two 
different specification for the same thing.

The only difference is that you may demand attention for the previous message 
you sent.  The message which demand the attention is not urgent itself, only 
the whole discussion is.
Bu i think it probably doesn't matter.

What I suggest is to modify the XEP-0224 into a kind of "Best Practices" 
or "Buisness rules" regarding important messages.

-- 
Olivier

(PS: I've uploaded my old XEP to a web server so it's easier to read it:
http://bepointbe.be/files/notification_level.html )

signature.asc
Description: This is a digitally signed message part.

Re: [Standards] NEW: XEP-0224 (Attention)

Olivier Goffart wrote:
> Le mercredi 8 août 2007, XMPP Extensions Editor a écrit :
>> Version 0.1 of XEP-0224 (Attention) has been released.
>>
>> Abstract: This document defines an XMPP protocol extension for getting the
>> attention of another user.
>>
>> Changelog: Initial published version. (psa)
>>
>> Diff: N/A
>>
>> URL: http://www.xmpp.org/extensions/xep-0224.html
> 
> One year ago, i also wrote a JEP about that (but never published it)
> 
> The concept is quite the same.  (but i also defined a lower important message 
> level)
> 
> I did not publish it because I was thinking it could be included in the SHIM 
> (XEP-0131)

You mean like this?

http://www.xmpp.org/extensions/xep-0131.html#headers-urgency

/psa




smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Standards] NEW: XEP-0224 (Attention)

2007-08-09 Thread Olivier Goffart

Le mercredi 8 août 2007, XMPP Extensions Editor a écrit :
> Version 0.1 of XEP-0224 (Attention) has been released.
>
> Abstract: This document defines an XMPP protocol extension for getting the
> attention of another user.
>
> Changelog: Initial published version. (psa)
>
> Diff: N/A
>
> URL: http://www.xmpp.org/extensions/xep-0224.html

One year ago, i also wrote a JEP about that (but never published it)

The concept is quite the same. (but i also defined a lower important message
level)

I did not publish it because I was thinking it could be included in the SHIM
(XEP-0131)

Anyway, I've attached it.
I think the lower important level is related and should be include to this
XEP.

--
Olivier
Title: JEP-: notification levels

JEP-: notification levels
This JEP provides documentation for the notification level.

WARNING: This document has not yet been accepted for consideration or approved in any official manner by the Jabber Software Foundation, and this document must not be referred to as a Jabber Enhancement Proposal (JEP). If this document is accepted as a JEP by the Jabber Council, it will be published at and announced on the <[EMAIL PROTECTED]> mailing list.

JEP Information

Status: ProtoJEP
Type: Standards Track
Number:
Version: 0.0.1
Last Updated: 2006-06-11
JIG: Standards JIG
Approving Body: Jabber CouncilDependencies: XMPP Core
Supersedes: None
Superseded By: None
Short Name: notification levels
Author Information

Olivier Goffart

Email:
[EMAIL PROTECTED]
JID:
[EMAIL PROTECTED]

Legal Notice
This Jabber Enhancement Proposal is copyright 1999 - 2006 by the Jabber Software Foundation (JSF) and is in full conformance with the JSF's Intellectual Property Rights Policy . This material may be distributed only subject to the terms and conditions set forth in the Creative Commons Attribution License ().
Discussion Venue
The preferred venue for discussion of this document is the Standards-JIG discussion list: .
Relation to XMPP
The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) specifications contributed by the Jabber Software Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this JEP has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.
Conformance Terms
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Table of Contents

1. Introduction

2. Notification level

3. Use Cases

3.1. Lower message

3.2. Urgent message

4. Discovery

5. Business Rules

6. Implementation Notes

7. Security Considerations

8. IANA Considerations

9. DTD

Notes
Revision History

1.
Introduction

This JEP let change the notification level of a message. A different notification may be executed on the user's client depending the level.
It allow to send message without disturbing a busy person, or at the opposite notify a busy person that the message is really urgent.
It also describe how to do the equivalent of a wizz or a nudge in others messaging systems
2.
Notification level

We define the several notification level
Table 1: Different notification level

Level
Meaning

normal
This is the default level of all message without additional notification indication

lower
This mark a message which is not important and doesn't require immediate reply.

urgent
This is a message that require an immediate reply or action in return.

3.
Use Cases

3.1 Lower message

Romeo know that Juliet is busy, and don't want to distrub her, but would like to let her a message she could read when she is has time.
Example 1. Send a lower priority message

I love you, Juliet

3.2 Urgent message

Juliet know that Romeo is busy, and is probably not paying attention to his massages, but has a very urgent message to
communicate.
Example 2. Send a urgent message

The reservation deadline for my father's ball ends in five minutes. Do you want to go there with me ?

4.
Discovery

It may be usefull to know if the client support that feature in order to let know the user that setting notification level will not have any effect
Example 3.

Re: [Standards] NEW: XEP-0224 (Attention)

Sergei Golovan wrote:
> On 8/10/07, Peter Saint-Andre <[EMAIL PROTECTED]> wrote:
>> Sergei Golovan wrote:
>>> This message looks like  but  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.
> 
> Yes, I'd like to know if my attention request wasn't ignored by a
> recipient's client.

Fair enough, I have no objections to an IQ approach.

>>> 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
> 
> You're right that in case of attention support it's an overkill. So,
> I'd remove several MUSTs from the XEP. Namely, I don't feel that
> disco#info querying is necessary before alerting and I don't think
> that the advertising must be switched off when it's disabled. 

Agreed. So now we'll wait for the spec author to make those changes if
he agrees, too.

/psa



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Standards] NEW: XEP-0224 (Attention)

On 8/10/07, Peter Saint-Andre <[EMAIL PROTECTED]> wrote:
> Sergei Golovan wrote:
> >
> > This message looks like  but  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.

Yes, I'd like to know if my attention request wasn't ignored by a
recipient's client.

> >
> > 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

You're right that in case of attention support it's an overkill. So,
I'd remove several MUSTs from the XEP. Namely, I don't feel that
disco#info querying is necessary before alerting and I don't think
that the advertising must be switched off when it's disabled. (There
are too many MUSTs in the XEP. I'd remove all of them, actually.)

-- 
Sergei Golovan

Re: [Standards] NEW: XEP-0224 (Attention)

Sergei Golovan wrote:
> 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 , but
>> should be a standalone message of type='headline', like so:
>>
>> >  to='[EMAIL PROTECTED]/home'
>>  type='headline'>
>>   
>> 
> 
> This message looks like  but  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/



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Standards] NEW: XEP-0224 (Attention)

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 , but
> should be a standalone message of type='headline', like so:
>
>   to='[EMAIL PROTECTED]/home'
>  type='headline'>
>   
> 

This message looks like  but  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

Re: [Standards] NEW: XEP-0224 (Attention)

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 , but
should be a standalone message of type='headline', like so:

The usage with a  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

Re: [Standards] NEW: XEP-0224 (Attention)

On 8/9/07, Jakob Schroeter <[EMAIL PROTECTED]> wrote:
> Hi,
>
> On Thursday August 9 2007, Sergei Golovan wrote:
> > 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?
>
> I'd say yes, the receiving client should re-disco or use a previously cached
> caps hash.

The problem is which hash to include into a presence packet. It should
be different for different recipients. But there's only one presence
packet (usually).

-- 
Sergei Golovan

Re: [Standards] NEW: XEP-0224 (Attention)

2007-08-09 Thread Jakob Schroeter

Hi,

On Thursday August 9 2007, Sergei Golovan wrote:
> 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?

I'd say yes, the receiving client should re-disco or use a previously cached 
caps hash.

Jakob


signature.asc
Description: This is a digitally signed message part.

Re: [Standards] NEW: XEP-0224 (Attention)