[Standards] rfc3920bis -06

Peter Saint-Andre stpeter at stpeter.im
Tue Jul 29 14:23:18 UTC 2008

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.

>>>  Full JID
>>> -------------------
>>>   If the JID contained in the 'to' attribute is of the form
>>>   <node at domain/resource> and there is no connected resource that exactly
>>>   matches the full JID, the stanza shall be processed as if the JID were
>>>   of the form <node at domain>.
>>> Is this also true for IQ stanzas? That would be very confusing if I
>>> query one entity for services and send something to it, it is gone and
>>> some other entity gets it. What happens if I send a get-IQ and my
>>> application crashes. Does the result go to a different entity? 
>> No, it doesn't, because IQs to the bare JID are handled by the server
>> itself on behalf of the bare JID, not delivered to another resource.
> Right, my fault.
>>> If my application uses the full JID it has a reason to do so. I
>>> also would prefer the same for messages (which I can get with
>>> XEP-0079).
>> What is "the same" here?
> I mean when I send a message to the full JID it MUST send be routed to
> that JID, just like for IQ stanzas. When chatting I use the bare JID
> and talk to the client with the best priority. When something chooses
> a full JID it has a reason to do so and a server should hinor that.

Yes, directed presence works that way.

>>>   If the JID contained in the 'to' attribute is of the form
>>>   <node at domain/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.

> And
> about negative priorities, I think if someone uses a full JID it has a
> reason for this, no matter what the priority is. My basic problem is
> how to handle two non-chat applications? They must have a negative
> priority to prevent receiving user chat messages but they may want to
> "chat" between each other.

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.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20080729/bc7044a4/attachment.bin>

More information about the Standards mailing list