[Standards] Decloaking and Temporary Subscriptions
stpeter at stpeter.im
Fri Jan 22 23:23:17 UTC 2010
On 1/21/10 9:38 AM, Dave Cridland wrote:
> 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).
Maybe. What if it's 30 minutes? 2 hours? 2 weeks? What if I go offline
and the request I sent you can't be acted upon?
>> DIRECTED PRESENCE
>> - 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?
For years, I've been recommending presence sharing between contacts who
don't have presence subscriptions (casual chatting, if you will). People
always say it's a good idea. Whether they have implemented it or not in
their clients, I don't know.
>> - 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.
That's an awfully small sample size.
> So those semantics aren't
> what happens for ad-hoc one-to-one chat.
Given the prevalence of the presence subscription model, I think ad-hoc
chats are relatively rare. Again, small sample sizes. However, I'd like
to have presence sharing in those situations. Not that I can claim to be
a typical user. But, in general people have presence subscriptions,
which is why I have not cared deeply about session-based presence
despite the conversations at Summit 5 back in 2007. The Jingle use cases
might well be quite different from ad-hoc chats.
>> - interim presence changes are not delivered (but we might be able to
>> change that behavior in rfc3921bis)
> Okay, so:
>> PRESENCE SUBSCRIPTION
>> - 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... ;-)
Subscriptions in XMPP have *always* been long-lived. Changing them to
also be temporary seems problematic to me.
>> - 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.
I'd be curious to see what the Google folks think about that.
>> - 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.
That is precisely the aspect I dislike, because *all* XMPP clients and
servers currently make assumptions about the meaning of a presence
subscription, and those assumptions are violated here.
That might not be a big deal, given how promiscuous people are with
presence already. But it is a difference. In particular, the roster
implications need to be thought through carefully.
>> - 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.
How long is "a bit"? The length of our current communications session?
Some guess at an expiration time? Forever?
>> - 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).
OK, thanks for the clarifications.
I think some experimenation and further testing are in order here.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 6820 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards