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. :)
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
smime.p7s
Description: S/MIME Cryptographic Signature
