Re: [Standards] Call for Experience: XEP-0085 (Chat State Notifications)
Am 20.11.2008 um 20:30 schrieb Peter Saint-Andre: RECOMMENDED means the same thing as SHOULD. :) So the following are equivalent: "It is RECOMMENDED for a client to do X" "A client SHOULD do X" To me, it sounds more necessary to implement a SHOULD than a RECOMMENDED :) Don't share presence in the first place. :P Well, we just talked about sharing it automatically, so there should be a way to revoke it. :) -- Jonathan -- Jonathan PGP.sig Description: This is a digitally signed message part
Re: [Standards] Call for Experience: XEP-0085 (Chat State Notifications)
Jonathan Schleifer wrote: > Am 20.11.2008 um 20:14 schrieb Peter Saint-Andre: > >> In rfc3921bis you will find the following text as a recommended best >> practice for chat sessions: >> >> If a user exchanges message stanzas with another entity >> but does not share presence with the entity based on a >> presence subscription, it is RECOMMENDED for the user's >> client to send directed presence to the other entity. > > Could we change RECOMMENDED to SHOULD? RECOMMENDED means the same thing as SHOULD. :) So the following are equivalent: "It is RECOMMENDED for a client to do X" "A client SHOULD do X" >> I don't agree with sending unavailable when you close the chat window. >> You might close it right before your contact sends you another reply and >> then what is their client supposed to do? That seems unnecessary. When >> you go offline your server will send unavailable, and that seems good >> enough to me. > > Well, but maybe have an easy way in the GUI to hide your presence from > that users again, so you don't need to relog to hide again :). Don't share presence in the first place. :P Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] Call for Experience: XEP-0085 (Chat State Notifications)
Am 20.11.2008 um 20:14 schrieb Peter Saint-Andre: In rfc3921bis you will find the following text as a recommended best practice for chat sessions: If a user exchanges message stanzas with another entity but does not share presence with the entity based on a presence subscription, it is RECOMMENDED for the user's client to send directed presence to the other entity. Could we change RECOMMENDED to SHOULD? I don't agree with sending unavailable when you close the chat window. You might close it right before your contact sends you another reply and then what is their client supposed to do? That seems unnecessary. When you go offline your server will send unavailable, and that seems good enough to me. Well, but maybe have an easy way in the GUI to hide your presence from that users again, so you don't need to relog to hide again :). -- Jonathan PGP.sig Description: This is a digitally signed message part
Re: [Standards] Call for Experience: XEP-0085 (Chat State Notifications)
Jonathan Schleifer wrote: > Am 20.11.2008 um 19:53 schrieb Peter Saint-Andre: > >> 1. What if you don't share presence with the other party and therefore >> can't receive caps data? I assume you'd need to send a service discovery >> request or share directed presence. > > That is some thing we need to rework anyway, I think. IMO, when we don't > share presence, we should send a directed presence directly after the > first message - this should be a seperate XEP or even part of XMPP > Messaging or Core. Oh for sure, it doesn't belong in XEP-0085, because it applies to all chat sessions in general. In rfc3921bis you will find the following text as a recommended best practice for chat sessions: If a user exchanges message stanzas with another entity but does not share presence with the entity based on a presence subscription, it is RECOMMENDED for the user's client to send directed presence to the other entity. > When we close the chat window (or manually using some button in the > client), we could send an unavailable presence again - and also when we > disconnect, of course. Same for invisibility. It is incredible annoying > when someone who's invisible messages you and lots of stuff doesn't work > therefore (like sending a file). I don't agree with sending unavailable when you close the chat window. You might close it right before your contact sends you another reply and then what is their client supposed to do? That seems unnecessary. When you go offline your server will send unavailable, and that seems good enough to me. >> 2. If you don't know (via disco/caps) that the other party supports >> XEP-0085, does the spec need to say that you (a) "MUST NOT" or (b) >> "SHOULD NOT" send chat state notifications? > > A "MUST NOT" would mean all old clients break it, so I think a "SHOULD > NOT" is better. I'm fine with SHOULD NOT. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] Call for Experience: XEP-0085 (Chat State Notifications)
Am 20.11.2008 um 19:53 schrieb Peter Saint-Andre: 1. What if you don't share presence with the other party and therefore can't receive caps data? I assume you'd need to send a service discovery request or share directed presence. That is some thing we need to rework anyway, I think. IMO, when we don't share presence, we should send a directed presence directly after the first message - this should be a seperate XEP or even part of XMPP Messaging or Core. When we close the chat window (or manually using some button in the client), we could send an unavailable presence again - and also when we disconnect, of course. Same for invisibility. It is incredible annoying when someone who's invisible messages you and lots of stuff doesn't work therefore (like sending a file). 2. If you don't know (via disco/caps) that the other party supports XEP-0085, does the spec need to say that you (a) "MUST NOT" or (b) "SHOULD NOT" send chat state notifications? A "MUST NOT" would mean all old clients break it, so I think a "SHOULD NOT" is better. -- Jonathan PGP.sig Description: This is a digitally signed message part
Re: [Standards] Call for Experience: XEP-0085 (Chat State Notifications)
Jonathan Schleifer wrote: > Am 20.11.2008 um 18:51 schrieb Peter Saint-Andre: > >> 1. Use disco/caps only (no implicit discovery) for chat state >> notifications and just wait for XEP-0022 clients to eventually disappear >> from the network. > > I vote for that one :) A few questions for the list: 1. What if you don't share presence with the other party and therefore can't receive caps data? I assume you'd need to send a service discovery request or share directed presence. 2. If you don't know (via disco/caps) that the other party supports XEP-0085, does the spec need to say that you (a) "MUST NOT" or (b) "SHOULD NOT" send chat state notifications? /psa
Re: [Standards] Call for Experience: XEP-0085 (Chat State Notifications)
Am 20.11.2008 um 18:51 schrieb Peter Saint-Andre: 1. Use disco/caps only (no implicit discovery) for chat state notifications and just wait for XEP-0022 clients to eventually disappear from the network. I vote for that one :) -- Jonathan PGP.sig Description: This is a digitally signed message part
Re: [Standards] Call for Experience: XEP-0085 (Chat State Notifications)
Pedro Melo wrote: > > On Oct 15, 2008, at 7:14 PM, Peter Saint-Andre wrote: > >> Peter Saint-Andre wrote: >>> Remko Tron�on wrote: >>> But I agree that caps should be preferred over the old method. >>> >>> +1 >> >> BTW, I think the old method was there for the transition from message >> events (XEP-0022) to chat state notifications. So perhaps it's time to >> rip that out and just talk about caps/disco. > > +1. I've been thinking about this more. Yes, service discovery and entity capabilities provide the right tools for the job here. The concern was caused by the use of XEP-0022 (Message Events) in older clients. Support for message events was not determined by service discovery because that protocol predated XEP-0030 by several years. Therefore your client could get in this strange state of wanting to use chat state notifications but ending up using message events. I see two paths forward: 1. Use disco/caps only (no implicit discovery) for chat state notifications and just wait for XEP-0022 clients to eventually disappear from the network. 2. Clean up the implicit discovery algorithm so that it reads something like this: *** In the absence of explicit discovery or negotiation, the User MAY implicitly request and discover the use of chat state notifications in a one-to-one chat session by adhering to the following business rules: 1. If the User desires chat state notifications, the message(s) that it sends to the Contact before receiving a reply MUST contain a chat state notification extension, which SHOULD be . 2. If the Contact replies but does not include a chat state notification extension, the User MUST NOT send subsequent chat state notifications to the Contact. 3. If the Contact replies and includes an notification (or sends a standalone notification to the User), the User and Contact SHOULD send subsequent notifications for supported chat states (as specified in the next subsection) by including an notification in each content message and sending standalone notifications for the chat states they support (at a minimum, the state). *** Notice that this gets rid of the idea of the "initial content message" and instead says that you send chat state notifications in all of the messages you send to the contact before receiving a reply. If the contact advertises support for XEP-0085 via disco/caps but never sends a chat state notification, the user would stop sending notifications. This saves some traffic, but I don't know how likely this scenario is. Thoughts? /psa
Re: [Standards] Call for Experience: XEP-0085 (Chat State Notifications)
On Oct 15, 2008, at 7:14 PM, Peter Saint-Andre wrote: Peter Saint-Andre wrote: Remko Tronçon wrote: But I agree that caps should be preferred over the old method. +1 BTW, I think the old method was there for the transition from message events (XEP-0022) to chat state notifications. So perhaps it's time to rip that out and just talk about caps/disco. +1. Best regards, -- Pedro Melo Blog: http://www.simplicidade.org/notes/ XMPP ID: [EMAIL PROTECTED] Use XMPP!
Re: [Standards] Call for Experience: XEP-0085 (Chat State Notifications)
Peter Saint-Andre wrote: > Remko Tronçon wrote: > >> But I agree that caps should be preferred over the old method. > > +1 BTW, I think the old method was there for the transition from message events (XEP-0022) to chat state notifications. So perhaps it's time to rip that out and just talk about caps/disco. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] Call for Experience: XEP-0085 (Chat State Notifications)
Remko Tronçon wrote: >> Now due to the offline message, they BOTH think the other end doesn't >> support XEP-85 and chat state notifications are never used. I already >> triggered that several times in Gajim. > > This particular problem is solved by *always* sending in our > messages. It's not 100% clear whether this is breaking the spec of > 'not sending chat state notifications when the initial message didn't > have ', but it's the easiest solution for this offline > message problem, for contacts changing resources, ... I don't think Dizzy and I thought much about the offline messaging case. What you suggest seems reasonable in that case. >> Solution: Caps, it's already in the XEP. But sadly, no client determines >> support via caps. > > Hmm, I always thought Psi did, but it seems I removed that. I think it > was because of a discussion on whether or not it was acceptable (from > the user's POV) to send composing events before the initial message. > Some found this scary, and I didn't have the time to implement > delaying sending composing events until the next message. > > Btw, what's the general opinion on sending 'composing' events before > the initial message? I know some other protocol clients like aMSN pop > up windows whenever a user starts typing, which some consider a > privacy problem. I think it's better not to send an empty composing event before you even send a message -- that would feel weird to me. But I don't know that the spec needs to forbid it (maybe it does now, though, eh?). > But I agree that caps should be preferred over the old method. +1 Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] Call for Experience: XEP-0085 (Chat State Notifications)
> Now due to the offline message, they BOTH think the other end doesn't > support XEP-85 and chat state notifications are never used. I already > triggered that several times in Gajim. This particular problem is solved by *always* sending in our messages. It's not 100% clear whether this is breaking the spec of 'not sending chat state notifications when the initial message didn't have ', but it's the easiest solution for this offline message problem, for contacts changing resources, ... > Solution: Caps, it's already in the XEP. But sadly, no client determines > support via caps. Hmm, I always thought Psi did, but it seems I removed that. I think it was because of a discussion on whether or not it was acceptable (from the user's POV) to send composing events before the initial message. Some found this scary, and I didn't have the time to implement delaying sending composing events until the next message. Btw, what's the general opinion on sending 'composing' events before the initial message? I know some other protocol clients like aMSN pop up windows whenever a user starts typing, which some consider a privacy problem. But I agree that caps should be preferred over the old method. cheers, Remko
Re: [Standards] Call for Experience: XEP-0085 (Chat State Notifications)
1. we implemented the MUSTs in TransVerse 2. nope 3. all-in-all the spec is pretty thorough and straightforward. On 10/13/08 4:45 PM, "Peter Saint-Andre" <[EMAIL PROTECTED]> wrote: > In its meeting last week, the XMPP Council agreed to issue a "Call for > Experience" regarding XEP-0085: Chat State Notifications, in preparation > for perhaps advancing this specification from Draft to Final in the > XSF's standards process. To help the Council decide whether this XEP is > ready to advance to a status of Final, the Council would like to gather > the following information: > > 1. Who has implemented XEP-0085? Please note that the protocol must > implemented in at least two separate codebases. > > 2. Have developers experienced any problems with the protocol as defined > in XEP-0085? If so, please describe the problems and, if possible, > suggested solutions. > > 3. Is the text of XEP-0085 clear and unambiguous? Are more examples > necessary? Is the conformance language (MAY/SHOULD/MUST) appropriate? > Have developers found the text confusing at all? Please describe any > suggestions you have for improving the text. > > If you have any comments on this XEP, please provide them by the close > of business on Friday, October 31, 2008. After the Call for Experience, > this XEP might undergo revisions to address feedback received, after > which it will be presented to the XMPP Council for voting to a status of > Final. > > You can review the XEP here: > > http://www.xmpp.org/extensions/xep-0085.html > > Please send all feedback to the list. > > Thanks! > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > >
Re: [Standards] Call for Experience: XEP-0085 (Chat State Notifications)
Jonathan Schleifer wrote: > Am 13.10.2008 um 22:45 schrieb Peter Saint-Andre: > >> 2. Have developers experienced any problems with the protocol as defined >> in XEP-0085? If so, please describe the problems and, if possible, >> suggested solutions. > > Yes, the behaviour of sending it at the first message and only replying > with it when we received a message with it often leads to a problem with > offline messages. When one receives an offline message without it and > the user answers, the client will answer without the. Both users are > online at that time. Now due to the offline message, they BOTH think the > other end doesn't support XEP-85 and chat state notifications are never > used. I already triggered that several times in Gajim. Aha, I've never seen that. > Solution: Caps, it's already in the XEP. But sadly, no client determines > support via caps. Plus the "try & error method" must be used for > compatibility reasons. > > Encouraging the use of caps in it would be nice, maybe even mark the try > & error method as deprecated. I'd be fine with that. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] Call for Experience: XEP-0085 (Chat State Notifications)
Am 13.10.2008 um 22:45 schrieb Peter Saint-Andre: 2. Have developers experienced any problems with the protocol as defined in XEP-0085? If so, please describe the problems and, if possible, suggested solutions. Yes, the behaviour of sending it at the first message and only replying with it when we received a message with it often leads to a problem with offline messages. When one receives an offline message without it and the user answers, the client will answer without the. Both users are online at that time. Now due to the offline message, they BOTH think the other end doesn't support XEP-85 and chat state notifications are never used. I already triggered that several times in Gajim. Solution: Caps, it's already in the XEP. But sadly, no client determines support via caps. Plus the "try & error method" must be used for compatibility reasons. Encouraging the use of caps in it would be nice, maybe even mark the try & error method as deprecated. -- Jonathan PGP.sig Description: This is a digitally signed message part
[Standards] Call for Experience: XEP-0085 (Chat State Notifications)
In its meeting last week, the XMPP Council agreed to issue a "Call for Experience" regarding XEP-0085: Chat State Notifications, in preparation for perhaps advancing this specification from Draft to Final in the XSF's standards process. To help the Council decide whether this XEP is ready to advance to a status of Final, the Council would like to gather the following information: 1. Who has implemented XEP-0085? Please note that the protocol must implemented in at least two separate codebases. 2. Have developers experienced any problems with the protocol as defined in XEP-0085? If so, please describe the problems and, if possible, suggested solutions. 3. Is the text of XEP-0085 clear and unambiguous? Are more examples necessary? Is the conformance language (MAY/SHOULD/MUST) appropriate? Have developers found the text confusing at all? Please describe any suggestions you have for improving the text. If you have any comments on this XEP, please provide them by the close of business on Friday, October 31, 2008. After the Call for Experience, this XEP might undergo revisions to address feedback received, after which it will be presented to the XMPP Council for voting to a status of Final. You can review the XEP here: http://www.xmpp.org/extensions/xep-0085.html Please send all feedback to the list. Thanks! Peter -- Peter Saint-Andre https://stpeter.im/
