Updated in the inbox: http://xmpp.org/extensions/inbox/chat-markers.html
On 6/24/13 1:39 PM, Spencer MacDonald wrote: > I have (slightly) updated my XEP based on feedback: > > I have changed the element name read to displayed. > I have removed the stamp attribute (in practise it was confusing). > I have added a thread attribute. > I have changed the namespace to urn:xmpp:chat-markers:0 to allow for > versioning. > > Regards > > Spencer > > > > On Fri, Jun 21, 2013 at 11:20 PM, David Laban <[email protected] > <mailto:[email protected]>> wrote: > > On Wed, 2013-06-19 at 20:42 +0100, Matthew Wild wrote: > > On 18 June 2013 11:51, Spencer MacDonald > > <[email protected] > <mailto:[email protected]>> 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... > > > -- Peter Saint-Andre https://stpeter.im/
