Re: [Standards] rfc3920bis -06

[Peter Saint-Andre]

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.

11.2.3.3.  Full JID
-------------------

  If the JID contained in the 'to' attribute is of the form
  <[EMAIL PROTECTED]/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 <[EMAIL PROTECTED]>.

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

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.

/psa

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.

smime.p7s
Description: S/MIME Cryptographic Signature