[Standards-JIG] proto-JEP: Smart Presence Distribution

[Richard Dobson]

> | Incorrect, if you apply a privacy list or add someone to one the server 
> | 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 re-writing 
>
> 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 5.1.4.2 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 
server.
> 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 against 
> | the current RFCs, as already noted it is in fact your suggestion that is 
>
> 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 up, 
>
> You started the accusations, and you are the one with the distorted "facts."
> 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.

Richard