[Standards] XEP-0313: pending 0.7 update review

Philipp Hörist philipp at hoerist.com
Sat Apr 4 09:47:17 UTC 2020


Hi,

Am Sa., 4. Apr. 2020 um 11:33 Uhr schrieb Ruslan N. Marchenko <me at ruff.mobi
>:

>
> Thanks, that makes perfect sense to me as in my limited _mere p2p
> conversation_ use case all those bells and whistles are rather confusing.
> I don't understand though the need of _flip-page_ element - the reverse
> _page_ order is achieved by <before> element (as specified here [1]). Is it
> to reverse _message_ order (contradicting to section Querying an archive)?
>
>
<before/> gives you the last page in chronological order, there comes no
use case to mind where this is useful.

- Either i want to sync up, then i want them in chronological order, so i
dont use <before/>
- Or i want to "backscroll" through history, then i want them in reversed
order which <before/> and <flip-page> now make possible


> * Communicating the archive ID: not sure how to formulate it but something
> along the lines: if client expects message synchronisation for outgoing
> messages it MUST add origin-ID to the sent message and store the ID locally
> for future synchronisation.
> * Business Rules -> Storage and Retrieval Rules -> User Archives : At a
> minimum, the server MUST store the <body> elements of a stanza. The
> server also MUST store origin-id element if that was supplied in outgoing
> message by archive owner.
>
>
Its not strictly needed that the archive preserves the origin-id, its not
even needed for deduplication that you use origin-id at all.
Whatever you put now in origin-id, just put into the standard message-id
attribute. message-id attribute is already preserved by servers.

I think the use for origin-id was historically because not all MUC
implementations did preserve the message-id or were allowed to rewrite it.
But this has been fixed in 0045 since then if im not wrong

Regards
Philipp
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200404/1c5273b5/attachment.html>


More information about the Standards mailing list