[Standards] Decloaking and Temporary Subscriptions

Peter Saint-Andre stpeter at stpeter.im
Thu Jan 21 15:03:24 UTC 2010

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='bob at example.com'>
  <sesspres xmlns='urn:xmpp:sesspres:0'/>
  <status>Let's share presence for a while!</status>


2. Presence subscription

<presence to='bob at example.com' type='subscribe'>
  <sesspres xmlns='urn:xmpp:sesspres:0'/>
  <status>Let's share presence for a while!</status>

So let's look at the pros and cons...



- 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


- interim presence changes are not delivered (but we might be able to
change that behavior in rfc3921bis)



- 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


- 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 Saint-Andre

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6820 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20100121/baa69780/attachment.bin>

More information about the Standards mailing list