[Standards-JIG] proto-JEP: Smart Presence Distribution
sgunta at miraclesoft.com
Tue May 30 13:51:59 UTC 2006
Please stop sending this mails to me. Remove me from ur list
----- Original Message -----
From: "Richard Dobson" <richard at dobson-i.net>
To: "Jabber protocol discussion list" <standards-jig at jabber.org>
Sent: Tuesday, May 30, 2006 9:48 AM
Subject: Re: [Standards-JIG] proto-JEP: Smart Presence Distribution
> > | Incorrect, if you apply a privacy list or add someone to one the
> > | does not automatically send an unavailable presence stanza, so the
> > | servers will very quickly get out of sync if people are using privacy
> > | lists and you are relying on presence stanzas as you currently are.
> > The JEP specifies that corrections to the recipient list must be made
> > according to the change in privacy lists. Where's the problem?
> That is something which is not currently part of how privacy lists work,
> if you apply an outgoing block of presence it does just that, it doesn't
> send out an unavailable presence, are you suggesting we change how
> privacy lists work so that when you block someone from receiving your
> presence you send out an unavailable presence to them?, that could
> possibly work, but does kind of go against the spirit of how it works,
> does anyone else have any problem doing this? It is making you appear
> off-line automatically whereas it wouldn't have previously is anyone
> taking advantage of this fact in the wild?
> > | Nothing I have suggested is against the specs or requires any
> > You are using JEP-0033 for presence, which conflicts with the way
> > XMPP defines presence distribution. Also the recipient list storage
> > idea is not part of JEP-0033, we came up with that.
> Sorry but I fail to see how it conflicts with the RFC any more than your
> suggestion does, the only difference between what we are both suggesting
> is how the list of recipients is determined, other than that there is no
> difference, so if what I suggest conflicts with the RFCs then so does
> what you suggest.
> > | mechanism that would require re-writing the specs as it is not
> > | compatible with directed presence as outlined in XMPP IM 5.1.4, if you
> > Bring up a precise example that breaks our proto-JEP, then please
> > help come up with a solution, too. I'm still presuming you are trying
> > to be constructive. I said that we need a way to distinguish directed
> > presence, and it would be a shame if XMPP had no way to do this.
> A precise example is if you send directed presence to a particular JID
> that is not in your roster (i.e. would not normally receive your
> presence broadcasts) that is at the same server as someone who is in
> your roster the person you sent directed presence to would start
> receiving your broadcasted presence whenever you updated it, whereas in
> section 18.104.22.168 it says "it MUST NOT include the entity's JID in any
> subsequent broadcasts of available presence initiated by the user".
> That's the problem I cant see any clean way around the problem with
> directed presence without having explicit lists of recipients being
> set-up between servers as there is no visible difference between a
> presence broadcast and directed presence once it reaches the destination
> > We have a disco negotiation that ensures that both sides know what they
> > are doing. Now we only need a way to ensure that a directed presence
> > can be distinguished and treated seperately as it always has been.
> > At worst we can always add a parameter and a namespace, but it would
> > be nicer not having to do that.
> Yes not a very nice solution (feels like a bit of a hack), but im not
> sure if there is any other way, it also means the server altering the
> presense stanzas when they are received from the user, not the end of
> the world but best avoided, how does anyone else feel about this?
> > | No it is not against the current RFCs any more than JEP-0033 is
> > | the current RFCs, as already noted it is in fact your suggestion that
> > Yeah sure, JEP-0033 for presence is in accordance to all RFCs.
> > You're dreaming.
> It is in accordance as far as I can see, can you please explain exactly
> what is making you think that using JEP-0033 is against the RFCs? which
> bit of text says you cant do it that way? I fail to see how it is
> against the specs, and if it truly is then so is your proposal as far as
> I can tell, as when it is broadcasting the presence stanzas to be fanned
> out by the remote server it is work in exactly the same way as I
> suggest, it is just using a list of recipients generated in a slightly
> different way.
> > | against the RFCs, so again please get you facts right in future and
> > | don't just spout baseless accusations without anything to back them
> > You started the accusations, and you are the one with the distorted
> > Stop accusing and start being helpful.
> Sorry but no, you started the accusations stating that JEP-0033 and my
> suggestions cannot be used because they are against the specs and would
> to be able to be used without the specs being re-written which is simply
> not the case as far as I can see. I am perfectly willing to be helpful
> and have been, if you explained yourself properly and why you think why
> you do rather than stating your opinions as facts without explaining
> them we would be better able to help, what I have been saying are hardly
> "distorted facts", the problem with directed presence and delivery
> unreliability are very real.
> > | especially when your own suggestions is clearly against the very RFCs
> > | that you are accusing others of being in breach of.
> > Not clear at all. Come up with facts, until then this is just babble.
> > Why do you keep this aggressive tone? Is this proposal affecting your
> > financial prospects? I obviously can't be aware of all the side effects
> > a technological improvement can have.
> I have come up with facts above, im sorry but you started the aggressive
> tone from looking at my email box in a reply to a message from Mridul.
> Its not affecting my financial prospects, I simply object to people who
> aggressively defend their position using arguments or assumptions that
> have been shown to be incorrect, saying things without backing them up
> (that JEP0033 is against the RFC) and not listening to facts that people
> try to point out (the potential unreliability of xmpp stanza delivery)
> and then responding with a tirade of "how it should be". Please re-read
> your messages and consider how aggressive they appear to be with little
> to back up your position, please take what people are saying on board
> and rather than saying "you are wrong" (which is a rather aggressive
> statement) actually explain how you came to this conclusion so that they
> can understand your decision making process and if necessary correct any
> incorrect assumptions or misunderstandings on your part, or come to
> agreement with you, but if you don't explain we can't understand why you
> think how you do and especially if when we think about it we come to a
> different conclusion.
More information about the Standards