[Standards] Messages to unsubscribed contacts and resources

Tue Dec 11 11:28:55 CST 2007

Robin Redeker wrote:
> Hi!
> 
> Some days ago I had a mail discussion on the jdev@ mailing list
> about messages to unsubscribed contacts and contacts in general.
> Tomasz said that messages should generally go to the bare JID instead of
> the full JID, and that the local routing is up to the server.
> 
> He meant, chat sessions should be kept track of with the <thread>
> element, which completly makes sense to me.
> 
> On the other side RFC3921bis says:
> 
>    Section 5.1.1:
> 
>    If the message is being sent in reply to a message previously
>    received from an address of the form <user at domain/resource> (e.g.,
>    within the context of a chat session), the value of the 'to' address
>    SHOULD be of the form <user at domain/resource> rather than of the form
>    <user at domain> unless the sender has knowledge (via presence) that the
>    intended recipient's resource is no longer available.
> 
> That of course also makes sense, but my problem was: What if the sending
> contact does not know about the presence of that resource? When should
> he stop sending to user at domain/resource? Should he, if he has no
> knowledge about the presence, send to user at domain generally?

IMHO it is a best practice for users who do not normally share presence
to send directed presence during a chat session.

> Please also note that the term 'chat session' in that paragraph is quite
> undefined, or at least it's meaning is a bit fuzzy to me.

At its simplest, I think this is a chat session:

<message from='A/res' to='B'>
  <body>hi!</body>
</message>

<message from='B/res' to='A/res' type='chat'>
  <body>hi back!</body>
</message>

<message from='A/res' to='B/res' type='chat'>
  <body>wow, a chat session!</body>
</message>

<message from='B/res' to='A/res' type='chat'>
  <body>yeah, but I gotta run!</body>
</message>

<message from='A/res' to='B/res' type='chat'>
  <body>OK, bye!</body>
</message>

However, I would recommend the following kind of flow, with sharing of
directed presence:

<message from='A/res' to='B'>
  <body>hi!</body>
</message>

<message from='B/res' to='A/res' type='chat'>
  <body>hi back!</body>
</message>

[ ... some optional client prompt for presence sharing here ... ]

<presence from='B/res' to='A/res'/>

<presence from='A/res' to='B/res'/>

<message from='A/res' to='B/res' type='chat'>
  <body>wow, a chat session!</body>
</message>

<message from='B/res' to='A/res' type='chat'>
  <body>yeah, but I gotta run!</body>
</message>

<message from='A/res' to='B/res' type='chat'>
  <body>OK, bye!</body>
</message>

<presence from='B/res' to='A/res' type='unavailable'/>

<presence from='A/res' to='B/res' type='unavailable'/>

The sharing of directed presence gives both parties more knowledge about
availability, but I think it should be initiated by the recipient (and
subject to client prompt on a per-session basis, or configuration in the
client to auto-share directed presence).

> And is somewhere described how full JIDs and <thread> play together? If at all?

http://www.xmpp.org/extensions/xep-0201.html

> If routing is up to the local server side, makes it sense to reveal
> resources at all? Wasn't there a progress towards randomized resources?

http://www.xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-04.html#bind-servergen

> Sorry for so many questions, but I'm a little bit confused. I try to get
> the conversation aspect in my client right, and one problem I stumbled
> accross was the fact that my client has no 'windows' or 'tabs' which
> could control the extend of a 'chat session'. In my client there is
> always a 'tab' to a contact, and the extends of a 'chat session' are
> very fuzzy and undefined.
> If the term 'chat session' in XMPP means I have to keep track of the
> session via some special hacks with resources and <thread>, I would have
> to complicate the whole thing a bit. That is of course maybe only an issue
> with my special client.

IMHO, threads are *not* required to have a chat session.

> But before I can implement anything resembling 'chat sessions' that
> term must be more explictly defined.

See above for an example. I can easily write a formal definition too.

> Of course, If I don't have to keep track of the resources, that would
> _greatly_ simplify everything for me. Just sending to the bare JID and
> leaving the rest up to <thread> and the contacts routing settings
> would make enormous sense to me.

Sending every message to the bare JID is not the custom.

> Back to section 5.1.1, the sections somehow contradicts the section
> 8.3.1.1 (Message):
> 
>    For a message stanza of type "chat", "error", "groupchat", or
>    "normal", the server SHOULD deliver the stanza to the
>    highest-priority available resource.
> 
> That 'feature' only makes sense if at least the initial message goes to
> a bare JID. But if it is routed to a resource by the server and I have
> no knowledge about the presence of that resource (eg. if I'm not
> subscribed), where should the next message go to, to the full JID I
> received a reply from? 

You should keep sending to the bare JID until you receive a reply from a
full JID, then start sending to the full JID.

> Will my messages, if that contacts resource goes
> offline, be dropped without my knowledge?

No, they will probably go to offline storage, because of this:

http://www.xmpp.org/internet-drafts/draft-saintandre-rfc3921bis-04.html#rules-fulljid-availnomatch

I agree that these customary practices are not spelled out very well, so
I will fix that in the next version of rfc3921bis.

Thanks for the questions!

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- 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/20071211/c41e4e06/attachment-0001.bin 