On Aug 27, 2007, at 4:08 PM, Peter Saint-Andre wrote:
If there is not one highest-priority available resource but
instead the highest priority is asserted by two or more
available resources, the server SHOULD deliver the message
to all of those resources.
To be clear, I'm not against the messages going to more than one
resource on priority ties. I'm opposed to the receiving client not
knowing if they can stop showing them, because they've been handled
by another client for that user. To that end, here's an example of a
PEP node that would address my issue:
<iq type='set' id='pub1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='urn:xmpp:handled'>
<item>
<handled xmlns='urn:xmpp:handled'>
<handler>[EMAIL PROTECTED]/balcony</handler>
<from>[EMAIL PROTECTED]/orchard</from>
<id>msg_1</id>
<type>chat</type>
<body algo='sha1'>raSaTuhicMYKGLpOzi926pZFyks=</body>
<thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread>
</handled>
</item>
</publish>
</pubsub>
</iq>
The hash is base64(sha1(body)). If there was no message id, type,
body, or thread, the corresponding element won't be in the publish.
Handler and from are required.
This is to say this message has been handled:
<message
to='[EMAIL PROTECTED]'
from='[EMAIL PROTECTED]/orchard'
type='chat'
id='msg_1'
xml:lang='en'>
<body>Neither, fair saint, if either thee dislike.</body>
<thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread>
</message>
This goes to Juliet's "urn:xmpp:handled" node, which SHOULD keep
track of the last several messages handled (another good use case for
multiple items in a PEP node...). Juliet's other clients SHOULD
implicitly subscribe to this node. When a user starts to process a
message (begins a reply, closes the window, etc.) that was addressed
to a [EMAIL PROTECTED] (bare) JID, that client MUST publish a handled
notification via PEP for each previously-unhandled message that can
now be acknowledged. When a client has a message that has been
received, but not yet acknowledged, and receives a PEP publish that
the message has been handled by another resource, the client SHOULD
remove that message from display, and SHOULD remove the message from
whatever message logs into which it has been placed.
--
Joe Hildebrand
