[Standards] Decloaking and Temporary Subscriptions

Dave Cridland dave at cridland.net
Thu Jan 21 16:38:43 UTC 2010


On Thu Jan 21 15:03:24 2010, Peter Saint-Andre wrote:
> 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?

Well, except... If I want to call you via Jingle, and you come online  
10 minutes later, I think I'd like that (offer of a) call to still be  
active. (Again, see the council logs - the concept of telephone tag).

> DIRECTED PRESENCE
> 
> PRO
> 
> - it's what we use today for one-to-one chats, groupchat, etc.

In practise, one-to-one chats tend to have a presence subscription  
surrounding them. We may know it's possible, but in practise?



> - adding the <sesspres/> child makes the sharing request explicit  
> but
> those semantics are already implicit
> 
> 
The only person who did used to contact me without a subscription  
from time to time also never sent his presence. So those semantics  
aren't what happens for ad-hoc one-to-one chat. (We are now  
subscribed to each other, incidentally).


> CON
> 
> - interim presence changes are not delivered (but we might be able  
> to
> change that behavior in rfc3921bis)
> 
> 
Okay, so:


> 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
> 
> 
What, you have to squint hard to see an explicit agreement to share  
presence being like a presence subscription? You need an optician...  
;-)


> CON
> 
> - it will always get through (aren't we routing around legitimate
> communication blocking?)
> 
> 
No, I think this is a non-issue. GTalk block contact without consent,  
and I can sympathize with their viewpoint. I might even agree that  
it's a sane default for users - about the only thing I don't agree  
with is enforcing it on users.

This doesn't change that - we're not routing around, we're ensuring  
we have permission, which seems to be the point.


> - 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
> 
> 
Presence sharing *is* a presence subscription. (A mutual one no less,  
although using subscriptions no longer enforces that).

The only additional semantic we're adding is that both parties agree  
and accept this isn't going to be a long term one.


> - 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
> 
> 
Right, but the intent of the sender was "I'd like to share presence  
for a bit". If that's agreed to be shared naïvely as a long-term  
subscription, I don't see this as a failure, this is with the consent  
of the recipient *and* it exceeds the sender's requirements.


> - 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.
> 
> 
No, I'm not depending on it. I'm expecting it be used, and expecting  
it may help provide a human-to-human intent.


> - 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.
> 
> 
I was actually thinking in terms of expiring the request with a  
timestamp, not the subscription. The subscription gets removed when  
the parties are "finished", whatever that may mean. (And I see no  
reason why it needs to get removed if the parties are happy).

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade



More information about the Standards mailing list