On 1/21/10 3:44 AM, Dave Cridland wrote: > On Thu Jan 21 05:40:07 2010, Peter Saint-Andre wrote: > >> As to the temp-sub idea itself, sending something like the following >> seems that it simply won't work unless you know that the destination >> server and client support the tempsub extension (otherwise they will >> treat the subscription as permanent). >> >> <presence type='subscribe'> >> <temp xmlns='urn:xmpp:temp:0'/> >> </presence> >> >> > Right, so it depends on what you want the failure case to be. If the > failure case is that well, hey, you wanted to get in touch with the guy > anyway, then this is great. > > Note that I'd expect something more like: > > <presence type='subscribe'> > <temp xmlns='urn:xmlns:temp:0' expires='20100122T000000'/> > <status>Just wanted a quick call about Foo</status> > </presence>
I don't see a need for expires. What people really seem to want here is session-specific presence sharing, and when I send the request how do I know when the session will end? There is no real difference between <temp/> and <decloak/> here, what we really mean is <session-presence/> (I think). So we have a choice between: 1. Directed presence <presence to='[email protected]'> <sesspres xmlns='urn:xmpp:sesspres:0'/> <status>Let's share presence for a while!</status> </presence> and: 2. Presence subscription <presence to='[email protected]' type='subscribe'> <sesspres xmlns='urn:xmpp:sesspres:0'/> <status>Let's share presence for a while!</status> </presence> So let's look at the pros and cons... DIRECTED PRESENCE PRO - it's what we use today for one-to-one chats, groupchat, etc. - adding the <sesspres/> child makes the sharing request explicit but those semantics are already implicit CON - interim presence changes are not delivered (but we might be able to change that behavior in rfc3921bis) PRESENCE SUBSCRIPTION PRO - it will always get through (no GTalk blocking etc.) - if you squint really hard, session-specific presence sharing looks like a presence subscription of temporary duration CON - it will always get through (aren't we routing around legitimate communication blocking?) - session-specific presence sharing isn't really a presence subscription, which in XMPP is and has always been a long-lived trust relationship between two entities; overloading that trust relationship seems like a bad idea - the fall-through case is establishment of a long-lived subscription, which was not the intent of sending a request for session-specific presence sharing - depending on the text in the <status/> element to indicate the real intent is problematic -- many servers and clients might not handle that properly for subscription requests (certainly not for subscription requests that are cached if the recipient is offline), there are i18n issues, etc. - expirations (if included) further muddy the waters because then we'll need to specify a way to refresh the temporary subscription along with associated error flows (you've seen my presence long enough!), to specify recommended defaults (ten minutes, one hour, one day?), etc. Overall I see more problems with overloading 'subscribe' than not, but I might be missing something. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
