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. The flow of your protocol is good, though. > 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. > > > 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. -Justin
