On Wed, 13 Aug 2008 15:03:21 -0600 Peter Saint-Andre <[EMAIL PROTECTED]> wrote:
> Pavel Simerda wrote: > > On Tue, 12 Aug 2008 00:31:00 -0700 > > Justin Karneges <[EMAIL PROTECTED]> wrote: > > > >> On Monday 11 August 2008 14:04:22 Pavel Simerda wrote: > >>> On Mon, 11 Aug 2008 13:45:08 -0600 > >>> > >>> Peter Saint-Andre <[EMAIL PROTECTED]> wrote: > >>>> 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'/> > >> I'm pretty sure any server developer who doesn't want to process > >> the XML inside a presence stanza would also be against adding new > >> presence types. > >> > >> I think if any extending goes on, it would have to be through child > >> elements of the stanza. > > > > I believe if the type is really different from the usual > > availability (which the temporary availability is), we should not > > stick with the current set of presence types only because "it has > > been like that for a long time". > > > >> The flow of your protocol is good, though. > >> > > > > Thanks. > > > >>> Current implementations would send it to the client (if not > >>> instructed to block everything) or no? > >> It's hard to say what current servers would do. Presence stanzas > >> are treated specially in servers, much more than message/iq which > >> are usually just relayed as-is. It wouldn't surprise me if sending > >> new/invalid presence types would cause the receiving server to drop > >> the stanza. > > > > Still better than confusion with subscribe. > > > >>>>> 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. > >> Or maybe it is a fine backwards-compatible scheme? Clients/servers > >> unaware of temporary subscriptions would at least be able to set > >> up a normal subscription. > > > > Which is IMO bad and confusing when you only want temporary presence > > session. This might even lead to the situation that people are angry > > because you want subscription and you aren't supposted to. > > > > What more, clients can do nothing to prevent it. > > > > If you want to extend something, it would be better if it's not > > subscriptions. We have enough problems with subscriptions without > > that. > > > > (They sometimes don't work as expected and servers sometimes store > > different subscription states for the same user relation.) > > Look, we're trying to work around presence blocking. Some servers > will only let <presence type='subscribe'/> through because of privacy > lists (or what looks like a privacy list anyway, a la Google Talk), > and a new value for the 'type' attribute won't help here. So either > we use subscribe or it won't work anytime soon. Choose one. :) I don't like workarounds in the core specifications nor in the extensions. I personally would prefer waiting for fixed implementations over ugly workarounds. > Personally I don't mind having a big roster, and I don't mind having > people send me presence subscription requests, long-term or > short-tterm, whatever. In fact I'd love to have a flag for > short-tterm subscriptions when a presence subscription request comes > in -- I'd be more likely to approve it, and maybe the short-term > subscription turns into a long-lived subscription. I'm not sure how > you present these options to the users (both the subscriber and the > subscribee), but I think client developers can work on those issues > and we can share those insights. > > Peter -- Web: http://www.pavlix.net/ Jabber & Mail: pavlix(at)pavlix.net OpenID: pavlix.net
