On Wed, 2013-06-19 at 20:42 +0100, Matthew Wild wrote:
> On 18 June 2013 11:51, Spencer MacDonald
> <spencer.macdonald.ot...@gmail.com> wrote:
> > Would it be possible to add "archive indicators" to XEP-0313 to solve my
> > "messages with no body are not archived issue"?.
> >
> > Maybe just adding <archive xmlns='urn:xmpp:mam:tmp'/> as a child of the
> > message?
>
> I've been thinking about this a bit. Since the issue first came up,
> I've been wondering if there are alternatives to the "no-body" rule.
> The problem is that the rule is 95% correct, but when it isn't it's
> not very helpful.
>
> I noted that XEP-0280 (Carbons) has a similar issue, but has an
> explicit flag (the <private/> element) rather than attempting to come
> up with any such rules.
>
> I've written a small proto-XEP that might be able to unify such flags:
> http://matthewwild.co.uk/uploads/message-processing-hints.html
>
> With this we could either remove the no-<body> rule, store by default
> and use no-store. Or we can keep it and add a 'store' hint (this one
> might be easier but feels backwards to me in the grand scheme of
> things).
>
> Thoughts?
>
Since xep-0079 Advanced Message Processing seems extensible and
discoverable, with well-defined "not implemented" cases, I'm just going
to use it like a hammer and treat everything like a nail. If
message-processing-hints ends up with a better syntax for these things,
awesome.
For your Example 1, could we use:
<amp per-hop="true">
<rule action='drop' condition='match-resource' value='other'/>
<rule action='drop' condition='deliver' value='stored'/>
</amp>
Your mod_carboncopy and mod_mam implementations could advertise support
for this by setting the following features (the client would need to
query both the local and remote servers before relying on its amp rules
applying though):
( <feature
var='http://jabber.org/protocol/amp?action=drop&condition=deliver&value=stored'/>
OR NOT
(<feature var='msgoffline'/> or <feature var='urn:xmpp:mam:tmp'/>))
AND (
<feature
var='http://jabber.org/protocol/amp?action=drop&condition=match-resource&value=other'/>
OR NOT <feature var='urn:xmpp:carbons:2'/> )
(not sure what clients should do if these conditions aren't met though)
For the "please store me even though I have no body" case, if a message
is tagged with <amp/> and there is no matching rule to cause 'drop', can
we infer that the client understands AMP and would have told us to drop
it if storing wasn't appropriate? If so, there's your "please store me"
tag.
Also, for the reliable message delivery case[1], when the remote user's
server supports <feature
var='http://jabber.org/protocol/amp?action=confirm&condition=deliver&value=stored'/>
and <feature var='urn:xmpp:mam:tmp'/>,
when you send:
<amp per-hop="true">
<rule action='confirm' condition='deliver' value='stored'/>
</amp>
and the *remote user's* server doesn't reply with:
<amp xmlns='http://jabber.org/protocol/amp' status='notify>
<rule action='notify' condition='deliver' value='stored'/>
</amp>
within a reasonable time, then the local user's client should alert the
user, and ask if a re-send is desired, or if the message should be
cancelled using something like xep-0308 [2].
This doesn't guarantee that the remote *client* supports MAM (Is that
turd worth polishing? Suggestions welcome.) but if we added a
client-side <feature var='urn:xmpp:reliable:tmp'/> to mean "I promise
that I have checked my message archive and notified my user about all
pending messages", then you can treat a presence with that feature as as
good as a XEP-0184: Message Delivery Receipt for all messages that you
already have a 'stored' notification about.
Similarly, if a "Chat Marker" message implied a promise of retrieval for
all stored messages before the id in question, we could use that to
remove the need for XEP-0184-style receipts per message [3].
We probably also need a way to deduplicate Chat
Markers/receipts/whatever that end up being stored in the archive (in
many cases, it's only the most recent one that we care about). What
about:
<rule action='drop' condition='deduplicate' value='most-recent'/>?
David.
[1] I will not sleep properly until we have addressed the "End to End
Acknowledgements" section of:
http://www.isode.com/whitepapers/reliable-xmpp.html for the "users never
online at the same time" case
[2] Pretty soon I'm going to end up with a SIP-like state machine (with
ACKs and PRACKS etc) aren't I?
[3] If all clients were using the same MAM archive, which also contained
read receipts, you could easily guarantee that clients doing state
recovery from the archive all had the same view. Failing that, I had
this crazy idea of using git/logd style ID chains for log
verification...
