[Standards] Decloaking and Temporary Subscriptions
dave at cridland.net
Thu Jan 21 10:44:29 UTC 2010
On Thu Jan 21 05:40:07 2010, Peter Saint-Andre wrote:
> Something like this is needed if you want to contact someone with
> you don't share presence. Whether we think that's really an
> scenario is another story. Perhaps the fact that I never wrote up a
> document about this indicates my feelings in the matter.
Something like this is certainly useful, yes.
> > As part of the discussion, a brief mention was made of an
> > approach, which I'll call Temporary Subscriptions - that is,
> > roster subscriptions which are by intent expected to be later
> Can you say SIP? ;-)
Indeed - to clarify, SIP's subscriptions all have a specific expiry,
and need constant refreshing.
> > In the Council meeting, I opined that I was uneasy with the
> concept of
> > decloaking essentially because this Temporary Subscription concept
> > seemed to have been only very sparsely discussed - I think (and
> the rest
> > of the council largely agreed) that it's an interesting idea, and
> > of careful consideration.
> Feel free to write up a proposal.
> > We all entirely disagreed in precisely what it meant - more in the
> > Council logs.
> > So - what does the list think? Decloak? Temp-Sub? Or both?
> Why does the Council refuse to publish proposals that are worthy of
> further discussion, pending promised proposals that never
> (The same thing happened with message mine-ing last year -- at the
> some people said they would work on an alternative proposal but it's
> never been written.)
Well, there's absolutely no guidance for why a protoXEP should be
rejected by the Council - it's left to the Council's discretion.
Every year, the XSF Members get to decide whether the Council's used
such discretion wisely or not. (And if readers are not members, now's
a good time to change that).
In this case, there's no proposal offered at all, merely that one
potential counter-proposal - raised in fact by the author - has been
shot down without a fair hearing.
> 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'/>
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:
<temp xmlns='urn:xmlns:temp:0' expires='20100122T000000'/>
<status>Just wanted a quick call about Foo</status>
> Furthermore, subscription requests are cached if the target is
> when received by the server. If the receiving server doesn't support
> temp-subs, then it will send along the subscription request long
> it is valid.
Right, so a clever client knows that the moment has passed, and a
clever user with a dumb client and a dumb server can read the text,
The trickier bit is that in an ideal world, we'd have some way of
marking the subscription as temporary in the roster - and that really
needs roster metadata.
> I see many problems here, which might be addressed in a proposal if
> someone volunteers to write one (either in XEP format or on the list
> here). Do feel free to get to work, folks. :)
Well, I see many advantages, which might outweigh the problems - and
it seems that discussion on the list might give us some idea.
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
More information about the Standards