[Standards] Decloaking and Temporary Subscriptions
stpeter at stpeter.im
Thu Jan 21 05:40:07 UTC 2010
On 1/20/10 1:23 PM, Dave Cridland wrote:
> Simon McVittie has made a proposal he's called decloaking,
In fact, decloaking is something that Rob McQueen and I came up with at
XMPP Summit #5 back in 2007. Simon finally took the initiative to write
it up in a proper document.
> effectively puts a bit of structure around the directed presence used to
> "back up" various client-client interactions, including Jingle calls and
> file transfers.
Something like this is needed if you want to contact someone with whom
you don't share presence. Whether we think that's really an important
scenario is another story. Perhaps the fact that I never wrote up a
document about this indicates my feelings in the matter.
> As part of the discussion, a brief mention was made of an alternate
> approach, which I'll call Temporary Subscriptions - that is, actual
> roster subscriptions which are by intent expected to be later removed.
Can you say SIP? ;-)
> 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 worthy
> 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 materialize?
(The same thing happened with message mine-ing last year -- at the time,
some people said they would work on an alternative proposal but it's
never been written.) Let someone write up a document about temp-subs so
that we can compare the two ideas in a constructive fashion. If no one
ever writes up temp-subs then that, too, might be an indication -- that
the idea is void for vagueness or not worth pursuing.
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).
Furthermore, subscription requests are cached if the target is offline
when received by the server. If the receiving server doesn't support
temp-subs, then it will send along the subscription request long after
it is valid.
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. :)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 6820 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards