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:[email protected] - xmpp:[email protected]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
