On Mon, 11 Aug 2008 13:45:08 -0600
Peter Saint-Andre <[EMAIL PROTECTED]> wrote:
> Justin Karneges wrote:
> > On Tuesday 05 August 2008 08:54:22 Pavel Simerda wrote:
> >> On Mon, 04 Aug 2008 16:59:50 -0600
> >>
> >> Peter Saint-Andre <[EMAIL PROTECTED]> wrote:
> >>> Right. Or XEP-0191. Effectively Google Talk (and other similar
> >>> services) deploy a rule of "forbid communications with people not
> >>> on my roster" on the user's behalf -- no need for fancy privacy
> >>> rules managed by the user.
> >> But this also disallows chatting with people outside your roster,
> >> which is something I often do.
> >>
> >> I'm for any way that doesn't leak presence but allows chat
> >> sessions (or single messages)... without giving any presence info.
> >> It's nice to be able to decide about the non-roster people
> >> blocking separately.
> >>
> >> Some people would also like to use the "invisible" facility, that
> >> would also be orthogonal to the roster subscriptions. (I never used
> >> invisible personally.)
> >>
> >> Sorry if I'm just repeating the obvious.
> >
> > I've suggested using directed presence (which need not contain the
> > same information as broadcasted presence, if any) for this.
> >
> > A related discussion is that we wanted a way to trade caps and
> > resource information between unsubscribed/invisible contacts.
> > Robert suggested sending directed presence with caps and a special
> > field to indicate you want to trade capabilities and reveal each
> > others' resource name. E.g.:
> >
> > <presence from='contactA/Resource' to='contactB'>
> > <tradewithme/>
> > <c ...> // caps
> > </presence>
> >
> > I believe most clients drop unsolicited presence on the floor.
> > What we'd need is for clients to notice the <tradewithme> element
> > on these stanzas as a request to trade presence temporarily with
> > the sender, but not necessarily form a subscription. So your
> > client might say, "User 'contactA' wishes to engage in
> > communication with you. Is this okay? [Yes/No]" If the user
> > selects 'Yes', then your client would reply with the same kind of
> > presence packet. Now, each party may determine disco information
> > of the other, and they can chat, do file transfers, jingle, etc.
>
> Right.
Seems good.
> > Servers could then have a scheme where they block/bounce all
> > communication except from contacts that have your presence.
> > Presence is the key word here, not subscriptions, since if you
> > login invisible you'd still want the bouncing effect on subscribed
> > contacts that you've not revealed yourself to. I think presence is
> > the most natural privacy control mechanism.
>
> More natural than presence subscriptions or the roster?
>
I think so.
> > There's just one problem, and this was brought up at the summit: if
> > both parties forbid communication with people not in the roster
> > (or, more appropriately, forbid communication with people who don't
> > have their presence), then it would not be possible to trade
> > directed presence. Oops!
>
> If this were implemented using privacy lists, your client could
> automatically update the default "don't talk with strangers" privacy
> list when you do presence sharing. But we'd still need a way to
> bootstrap. Hmm.
Yep, you might use an external component for these 'rendez-vous'
situations in cases where the privacy is too strict to allow one-to-one
meeting bootstrap.
> > IMO, for this to work we need to define some server exceptions.
> > For example, GTalk will let <presence type='subscribe'> packets
> > through. We'd want to take this a step further and let through any
> > presence packet containing a <tradewithme> element.
>
> Server DOM grovelling to look for the right extension? That doesn't
> sound very appealing to server developers.
What about:
A: <presence type='meeting-request'/>
(A is waiting for B to join him, B may
respond quickly, after a long time or never)
B: <presence type='meeting'>
<show>...</show>
<status>...</status>
</presence>
<presence type='meeting-request'/>
(B now looks meeting/some_status to A)
A: <presence type='meeting'>
<show>...</show>
<status>...</status>
</presence>
(A and B look now meeting/some_status to each other)
A: <message/>
B: <message/>
A: <iq/>
...
...
(they did what they wanted)
A: <presence type='unavailable'/>
B: <presence type='unavailable'/>
(meeting is over)
Current implementations would send it to the client (if not instructed
to block everything) or no?
Future conforming implementations may choose to only allow only
<presence type="meeting-request"/>
or both
<presence type="meeting-request"/>
<presence type="subscribe"/>
Is it a problem to provide a new presence type in a XEP and
eventually sometime added to the RFC?
> > We need two new XEPs: "Temporary Presence Exchange" (for exchanging
> > caps/resource information with unknown/invisible entities),
>
> What more does that involve on top of directed presence containing
> caps?
>
> > and "Presence-based Privacy" (which is TPE-aware).
>
> I feel a lot of hoops here. How about a way to send a presence
> subscription request but indicate that it's intended to be only
> temporary?
>
> <presence type='subscribe'>
> <temporary/>
> </presence>
>
> That'll get through without all sorts of server upgrades etc.
That will, without a server upgrade be regarded as a subscription
request by the server, which is not a good backwards-compatible scheme
either.
> /psa
>
--
Web: http://www.pavlix.net/
Jabber & Mail: pavlix(at)pavlix.net
OpenID: pavlix.net
