Hi Florian, thanks for chiming in! On 13.02.2018 17:57, Simon Friedberger wrote: >> C2. According to Daniel it is not clear which ID should be used when >> referencing things. In other words if he gets a delivery receipt >> for an >> ID the client might have based that on the origin-ID or the >> message-ID. > Delivery receipts predate xep359 so it is safe to say that the intention > is that delivery receipts use rfc6120-ids. While it is IMHO obvious from > reading xep184 that it is based on rfc6120-ids, it can't hurt to specify > this more explicitly. But looking at https://xmpp.org/extensions/xep-0045.html#message the message-ID seems to be rewritten to different values for different recipients. How can a client who gets a delivery receipt with such an ID figure out which message it is for?
>> E) Suggested solutions, including partial solutions: >> E1. message-ID and origin-ID should always be the same, >> According to Daniel and Georg things currently break down anyway >> if this does not hold. > I don't now why things should break down if this does not hold. I think because it is difficult to match IDs to messages due to the reasons mentioned above. >> C3. Using origin-ID to detect MUC reflection doesn't always work >> because MUCs >> may not reflect it. > A short note: If a MUC service announces support for 'urn:xmpp:sid:0' > then the service is required to reflect the xep359 IDs. So clients are > at least able to determine if the MUC will reflect the xep359 extension > elements (but not if the MUC won't). And client developers should probably refuse to join MUCs that don't. Mandating it in the standard might still be good motivation for transport implementers. >> C5. Some MUCs rewrite the message-id >> Why is this allowed? It is even suggested here: >> https://xmpp.org/extensions/xep-0045.html#message > Hehe, that's an old discussion. Some people argue that the reflected > message is not the initial message and thus, could get a new ID. I also > think that the MUC way wants to enforce unique IDs for reflected > messages, which may not be guaranteed if the MUC service would need to > use the client provided ID. > > No matter what, I doubt that this will change in the future. Although I > have currently a neutral stance, XEP-0045 is to some degree set in > stone, it it unlikely to get such a fundamental change. This is an interesting point. I overlooked that it is exacerbated by the fact that some MUCs split messages so an ID for some messages is simply not available. Hm... What is the correct behavior here? Clearly, having messages with the same ID does not work for referencing, corrections, whatever.. On the other hand if a new ID is generated the client needs to be told that the server just made it say something and it can now expect delivery receipts for that. When hashing the message this is forced. It will change the ID and the client has to know. I don't see how this can be solved without a "bounce" since the bounce isn't one because the server generated the message. >> ... > Sounds like an interesting approach which we should explore. But apparently it doesn't work. xD >> ... > You are mixing multiple problems with multiple solutions, which was > probably in an effort to get the whole picture, but also leads to > confusion. I personally would like to concentrate on solving C4, where > you pointed out a promising candidate for a solution: E2 Indeed. Mostly because I still don't think that I understand the complete picture. For example, if we are only trying to solve C4, is that really worth the effort? Does it do anything more than save a round-trip? _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________