On 1/29/10 2:13 PM, Jonathan Schleifer wrote: > Am 29.01.2010 um 15:58 schrieb Peter Saint-Andre: > >> On 1/29/10 5:41 AM, Jonathan Schleifer wrote: >>> Am 28.01.2010 um 22:40 schrieb Dave Cridland: >>> >>>> So a note's needed at minimum to explain that this didn't used to be a >>>> requirement, and clients (and servers) SHOULD cope with no response as >>>> meaning unavailable. >> >> The default is always unavailable. If you receive positive <presence/> >> then you have some clue that the contact is online. If not, not. If you >> receive a definitive answer that the contact is offline, that's even >> better, but you can never assume that the contact is online. >> >>> The problem with that is: How do you figure out if you don't get a >>> response or if you are just still waiting for it? We should define a >>> sane timeout here, I guess, to prevent incompatibilities. This also >>> means we need to figure out a sane value that even works with bad >>> connections. >> >> I don't see a good reason to go down that path, which introduces more >> complexity into clients. > > So you suggest to assume all presences you already received as invalid > when you send a presence probe and only take those into account that you > got after the probe? Sounds like a solution, but a dirty one, IMO. > > I think that sending back an unavailable a MUST is a good idea, as then > you have a definite answer whether the user is online or not, whereas > without, it could just be a laggy connection etc. I suggested making it a MUST to return unavailable. Peter -- Peter Saint-Andre https://stpeter.im/
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.