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.) Pavel > -Justin -- Web: http://www.pavlix.net/ Jabber & Mail: pavlix(at)pavlix.net OpenID: pavlix.net
