Peter Saint-Andre wrote: > Dirk Meyer wrote: >> Sorry for the late answer, I've been very busy the last weeks. >> >> Peter Saint-Andre wrote: >>> Dirk Meyer wrote: >>>> The same is true for presence (in RFC 39210. I found the presence >>>> handling much too complicate to implement. It took me longer than >>>> adding PubSub and XTLS support. >>> Yes, presence is complex. Sorry about that. Did you implement it in a >>> server or a client? >> >> Only client but IIRC adding a friend to the roster resulted in getting >> an iq result without sending a get or set. Very confusing. > > So you sent <presence type='subscribe'/> and you received an IQ result > from your server? That sounds like a server bug.
I'm not sure what it was, but something like that. I will have time to clean up my implementation next week and I will do some more testing with my server (I now use ejabberd 2 which I did not use before). >>>> If the JID contained in the 'to' attribute is of the form >>>> <[EMAIL PROTECTED]/resource> and there is a connected resource that >>>> exactly matches the full JID, the server SHOULD deliver the stanza >>>> to that connected resource. >>>> >>>> I would prefer MUST >>> It needs to be a conditional MUST, because the server MUST NOT deliver >>> a message stanza to you if: >>> >>> 1. According to XEP-0016 you are blocking messages from the sender. >>> >>> 2. According to RFC 3920 your resource has negative presence priority. >> >> So maybe not "MUST send to this resource" but "MUST NOT send the >> message to a different resource". This keeps XEP-0016 in place. > > So you are suggesting that a message addressed to a full JID would > never be delivered to another resource (or stored offline?) if that > resource does not exist. Correct? I hadn't considered that option. [...] > A message that is addressed to a resource with a negative priority is > delivered to that resource. The only thing that negative priority does > is prohibit delivery to that resource if the message was addressed to > the bare JID, not the full JID. Interessting question. What should happen if you send a message to the full JID of a resource that does not exist anymore. And to combine it with a negative priority: what happens if that resource had a negative priority before indicating non-chat. 1. Discard? Always a bad idea without letting the sender know. 2. Store? Possible, but may not make any sense. Depends on the context. 3. Send to someone else? Makes no sense in some contexts? If I have a message based IBB a different receiver can not handle it. Regards, Dirk -- "Either toss the Windows out of your computer, or toss your computer out the window!" -- Richard Stallman
