Hi Flow, As it stands today, every message ideally has no more than two IDs: - The sender assigned id (origin-id or message's id-attribute) which is required so that senders can be assured that the message is the one they sent when they fetch them from the archive or get reflected from MUCs, receive errors about it and so on. - The archive assigned id (stanza-id with by-attribute set to the archive, that is the MUC in groupchat messages and the user's own bare JID for direct chat messages).
The only reason why we need the second ID is that archives can't be sure that all messages they will store have a globally unique id assigned by their senders, otherwise the archive could just have used the sender's id. As a client developer, these are the only two IDs I'll store about incoming (and outgoing, though I will only learn the archive id later) messages. Even if you add a ton of other stanza-id's I'll just ignore them. And that's exactly what we would want developers to do to ensure they do it right. So the question is not to infer the by-attribute (because there is no by-attribute in my local store). The question is only which of the two id's I use for what purpose. For MAM or reflection matching, it's obvious that the archive id or the sender id is to be used, respectively. And for message referencing, it depends on the message type (groupchats use archive id, direct chats use sender id). While having acknowledgment messages from the sender's server that tell the sender the assigned archive id would indeed be nice to have, adding that ID to the outgoing message means that now there is another ID at the recipient. If that ID is meant to be used for referencing later and clients need to handle it on top of the previous two, this only adds even more potential for confusion for client developers - and I don't see the benefit that would justify such additional potential of confusion and mistakes. The only usecase where I see fit and good reason for a by-attribute in a reference, is when one wants to reference a message from the archive of another conversation (e.g. when forwarding a message from one MUC to another). In that case though, one probably wants to make the fact that this reference is pointing outside the current context more explicit than just having a by-attribute that seems to be invalid in the current context. Marvin _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
