[Standards] rfc3920bis -06

Dirk Meyer dmeyer at tzi.de
Mon Jul 28 17:59:13 UTC 2008


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.

>> 11.2.3.3.  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.

>>   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. 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.


Dirk

-- 
++?????++ Out of Cheese Error. Redo From Start.
        -- (Terry Pratchett, Interesting Times)



More information about the Standards mailing list