Re: [Standards] RFC: XEP-0045 MUC should not rewrite message IDs
On 26 July 2014 12:30, Georg Lukas ge...@op-co.de wrote: 3) In practice, nobody is relying on the uniqueness of 'id's anyway, because there are so many broken implementations out there. Two small points on this. Firstly, many of your other comments rely on the uniqueness and stability of ids. An example is your (7) - this relies on all messages sent from the same occupant jid having unique ids. You'll probably realise some problems with this approach fairly quickly if you stop and think about it. Secondly, RFC 6120, §8.1.3, says: It is up to the originating entity whether the value of the 'id' attribute is unique only within its current stream or unique globally. Now, the real question is this: What is the originating entity in the case of MUC? We do not, generally, consider that the originating entity of a pubsub event is the publisher, although semantically this is the case. But for MUC, we seem to consider the originating entity to be the originating client - at least when it suits us. This would make sense if the MUC was a simple stanza relay service, but it's not. None of M-Link, Openfire, or Prosody implement a 1:1 mapping of occupant jid to client anymore. In addition, things like history, or archival access, generate stanzas spontaneously. In any case, the thing effectively mandating unique id generation for outgoing messages is NOT XEP-0045, but RFC 6120. This doesn't invalidate your arguments entirely, but it may well suggest that RFC 6120 has a technical flaw that needs addressing. Dave.
Re: [Standards] RFC: XEP-0045 MUC should not rewrite message IDs
On Jul 26, 2014, at 7:43 AM, Dave Cridland d...@cridland.net wrote: On 26 July 2014 12:30, Georg Lukas ge...@op-co.de wrote: 3) In practice, nobody is relying on the uniqueness of 'id's anyway, because there are so many broken implementations out there. Two small points on this. Firstly, many of your other comments rely on the uniqueness and stability of ids. An example is your (7) - this relies on all messages sent from the same occupant jid having unique ids. You'll probably realise some problems with this approach fairly quickly if you stop and think about it. Secondly, RFC 6120, §8.1.3, says: It is up to the originating entity whether the value of the 'id' attribute is unique only within its current stream or unique globally. Now, the real question is this: What is the originating entity in the case of MUC? We do not, generally, consider that the originating entity of a pubsub event is the publisher, although semantically this is the case. But for MUC, we seem to consider the originating entity to be the originating client - at least when it suits us. This would make sense if the MUC was a simple stanza relay service, but it's not. None of M-Link, Openfire, or Prosody implement a 1:1 mapping of occupant jid to client anymore. In addition, things like history, or archival access, generate stanzas spontaneously. In any case, the thing effectively mandating unique id generation for outgoing messages is NOT XEP-0045, but RFC 6120. This doesn't invalidate your arguments entirely, but it may well suggest that RFC 6120 has a technical flaw that needs addressing. Dave. That RFC 6120 text is misleading if not outright bogus. It implies that ids have some uniqueness when in fact they may not, even in one particular stream. But worse, it's wrong. An entity originating an error or result stanza is obligated to use the id the error or result is in response to. So the value is not always up to the originating entity of the error or result stanza. I have no objection to Georg's most recent revision to XEP 45. -- Kurt
Re: [Standards] RFC: XEP-0045 MUC should not rewrite message IDs
* Dave Cridland d...@cridland.net [2014-07-26 17:09]: Firstly, many of your other comments rely on the uniqueness and stability of ids. An example is your (7) - this relies on all messages sent from the same occupant jid having unique ids. You'll probably realise some problems with this approach fairly quickly if you stop and think about it. Now that you mention it, XEP-0308 does not make any assumptions about the uniqueness of 'id's, it merely adds them as a reference so a client can check if the message-to-be-corrected actually arrived at the same client. Of course, not having 'id' stability here will force the receiver to handle the correction as a new message. The assumption _I_ do make about 'id' uniqueness is that my outgoing messages to the MUC have 'id's unique within my session, so I can track if they actually were reflected or not. Secondly, RFC 6120, §8.1.3, says: It is up to the originating entity whether the value of the 'id' attribute is unique only within its current stream or unique globally. This does not read like a REQUIREMENT of uniqueness, merely a recommendation. Please let me quote the paragraph prior to that: The 'id' attribute is used by the originating entity to track any response or error stanza that it might receive in relation to the generated stanza from another entity (such as an intermediate server or the intended recipient). If we see the MUC client as the 'originating entity' of the groupchat message it sends, it is perfectly reasonable for it to use the 'id' attribute to track whether its message arrived at the MUC. Now we might construct a world where the reflected message to the original sender is re-using the sender's 'id', whereas the relfection of the message to all other participants has rewritten 'id's. However I am still not sure what we actually do gain by rewriting the 'id's in the first place. If we see the MUC service as the 'originating entity', please elaborate how the creation of new 'id's for reflected messages helps the service with response/error tracking in a way that is not possible with re-used 'id's. This would make sense if the MUC was a simple stanza relay service, but it's not. None of M-Link, Openfire, or Prosody implement a 1:1 mapping of occupant jid to client anymore. In addition, things like history, or archival access, generate stanzas spontaneously. History and archive access are different things with even stronger requirements on uniqueness. I don't see how the current wording of the XEP-0045 (which I would like changed) provides guarantees strong enough for these purposes. In any case, the thing effectively mandating unique id generation for outgoing messages is NOT XEP-0045, but RFC 6120. Outgoing messages are merely RECOMMENDED to have an 'id', and that 'id' is meant to allow the sender to track responses and errors. Together with Kurt's point, I don't see how the RFC is mandating unique 'id's at all. Georg -- || http://op-co.de ++ GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N ++ || gpg: 0x962FD2DE || o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+ || || Ge0rG: euIRCnet || X(+++) tv+ b+(++) DI+++ D- G e h- r++ y? || ++ IRCnet OFTC OPN ||_|| signature.asc Description: Digital signature
Re: [Standards] RFC: XEP-0045 MUC should not rewrite message IDs
On 26 July 2014 16:53, Kurt Zeilenga kurt.zeile...@isode.com wrote: On Jul 26, 2014, at 7:43 AM, Dave Cridland d...@cridland.net wrote: This doesn't invalidate your arguments entirely, but it may well suggest that RFC 6120 has a technical flaw that needs addressing. That RFC 6120 text is misleading if not outright bogus. It implies that ids have some uniqueness when in fact they may not, even in one particular stream. I agree it's probably leaning very heavily on the idealistic side. But worse, it's wrong. An entity originating an error or result stanza is obligated to use the id the error or result is in response to. So the value is not always up to the originating entity of the error or result stanza. This, too. I have no objection to Georg's most recent revision to XEP 45. I think it's probably the right choice for message stanzas which are immediately retransmitted. IQs almost certainly need special handling, and I'm not sure that presence ought to have the same id, since those stanzas are repeated. I suspect that history messages ought to be allowed to have ids allocated by the server. I suspect that applications requiring such behaviour may need this advertised as a disco feature on the room and/or service. I also note that intermediaries may be changing ids; such intermediaries probably ought to be handling MUC especially and might need a note. Dave.
[Standards] RFC: XEP-0045 MUC should not rewrite message IDs
Hi, XEP-0045, section 7.4 http://xmpp.org/extensions/xep-0045.html#message states: Note well that for tracking purposes this service assigns a new 'id' to each message it generates (here using a UUID as defined in RFC 4122 [18]). I suggest changing that line to: The service SHOULD reflect the message with the same 'id' that was generated by the client. If the client did not provide an 'id', the server SHOULD generate one 'id' and use it for all reflections of the same message (e.g. using a UUID as defined in RFC 4122 [18]). (The example XML above should be changed accordingly; we might even replace SHOULD with MUST after the major implementations have changed) Rationale: A client needs some way to track if a sent message was succesfully processed and reflected. This is required to indicate success of transmission, to allow for message correction (XEP-0308), and it helps in displaying message errors in the context of the outgoing message. To determine if a newly received MUC message was indeed the reflection of the last outgoing MUC message, in theory three elements can be used: from, id, and body. * from: the message 'from' attribute must be the participant's nickname, however this will also be the case if the participant is connected with two clients sharing the same nickname, and the other client sends a MUC message. * id: the message 'id' attribute can only be relied upon if the server does not rewrite it * body: the message body could be used to check if an incoming message is the reflection of the just-sent message. However, some services rewrite the body, i.e. to replace a large message with a pastebin link. Therefore, none of the three elements can be reliably used to identify if an incoming MUC message is the reflection of the last outgoing message. To improve the situation, I suggest changing the XEP in a way that MUC message reflections keep the original message 'id'. Implications: This change might violate the uniqueness guarantee of message 'id's, however as the current behavior is not a MUST, service implementations exist that do not touch the message 'id', and the world is not falling apart. Kind regards, Georg -- || http://op-co.de ++ GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N ++ || gpg: 0x962FD2DE || o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+ || || Ge0rG: euIRCnet || X(+++) tv+ b+(++) DI+++ D- G e h- r++ y? || ++ IRCnet OFTC OPN ||_|| signature.asc Description: Digital signature
Re: [Standards] RFC: XEP-0045 MUC should not rewrite message IDs
On Fri, Jul 25, 2014 at 3:06 PM, Georg Lukas ge...@op-co.de wrote: XEP-0045, section 7.4 http://xmpp.org/extensions/xep-0045.html#message states: Note well that for tracking purposes this service assigns a new 'id' to each message it generates (here using a UUID as defined in RFC 4122 [18]). I suggest changing that line to: The service SHOULD reflect the message with the same 'id' that was generated by the client. If the client did not provide an 'id', the server SHOULD generate one 'id' and use it for all reflections of the same message (e.g. using a UUID as defined in RFC 4122 [18]). I agree with the intention, but I think making a breaking change to xep45 at this point wouldn't be appropriate. /K
Re: [Standards] RFC: XEP-0045 MUC should not rewrite message IDs
On Fri, Jul 25, 2014 at 10:06 AM, Georg Lukas ge...@op-co.de wrote: Hi, XEP-0045, section 7.4 http://xmpp.org/extensions/xep-0045.html#message states: Note well that for tracking purposes this service assigns a new 'id' to each message it generates (here using a UUID as defined in RFC 4122 [18]). Prosody's MUC service doesn't do that. Broadcasted messages have the same 'id' as the original (including a missing 'id' attribute). I suggest changing that line to: The service SHOULD reflect the message with the same 'id' that was generated by the client. If the client did not provide an 'id', the server SHOULD generate one 'id' and use it for all reflections of the same message (e.g. using a UUID as defined in RFC 4122 [18]). I object to the second SHOULD. Comments on the rest of the message follow. (The example XML above should be changed accordingly; we might even replace SHOULD with MUST after the major implementations have changed) Rationale: A client needs some way to track if a sent message was succesfully processed and reflected. This is required to indicate success of transmission, to allow for message correction (XEP-0308), and it helps in displaying message errors in the context of the outgoing message. To determine if a newly received MUC message was indeed the reflection of the last outgoing MUC message, in theory three elements can be used: from, id, and body. * from: the message 'from' attribute must be the participant's nickname, however this will also be the case if the participant is connected with two clients sharing the same nickname, and the other client sends a MUC message. * id: the message 'id' attribute can only be relied upon if the server does not rewrite it * body: the message body could be used to check if an incoming message is the reflection of the just-sent message. However, some services rewrite the body, i.e. to replace a large message with a pastebin link. Therefore, none of the three elements can be reliably used to identify if an incoming MUC message is the reflection of the last outgoing message. To improve the situation, I suggest changing the XEP in a way that MUC message reflections keep the original message 'id'. Implications: This change might violate the uniqueness guarantee of message 'id's, however as the current behavior is not a MUST, service implementations exist that do not touch the message 'id', and the world is not falling apart. I'll note that there is no uniqueness guarantee in message 'id's. It's entirely up to the sender. I can happily make my client send id=waqas for all messages forever, and that does not violate the spec. Given a lack of uniqueness guarantees, a server should either be generating IDs for all messages, or it should be generating them for none. Mixed-mode ID generation doesn't make a lot of sense. Using 'id' to match messages doesn't work well. Security issue: I can notice the 'id' on your messages, and can happily send messages with that 'id' to confuse your client. You don't own the value of the 'id'. If you are using this to sync history on reconnect, I can even temporarily take over your nick while you are disconnected, leaving your client with nothing to detect the sync marker being invalid. Given the current text of the XEP, even if this change is accepted, you may not be compatible with existing servers out there, and there's no way to reliably check for compatibility until after you've sent some messages. History sync is one area of XMPP that's terribly broken. All the popular XMPP protocols involving history (MUC, offline messages, PubSub, etc) have large gaps and race conditions, making reliable sync impossible. Heck many of the specs only work on the assumption of synchronised clocks. This is a separate email though. -- Waqas Hussain
Re: [Standards] RFC: XEP-0045 MUC should not rewrite message IDs
Am 25.07.2014 um 09:22 schrieb Kevin Smith: On Fri, Jul 25, 2014 at 3:06 PM, Georg Lukas ge...@op-co.de wrote: XEP-0045, section 7.4 http://xmpp.org/extensions/xep-0045.html#message states: Note well that for tracking purposes this service assigns a new 'id' to each message it generates (here using a UUID as defined in RFC 4122 [18]). I suggest changing that line to: The service SHOULD reflect the message with the same 'id' that was generated by the client. If the client did not provide an 'id', the server SHOULD generate one 'id' and use it for all reflections of the same message (e.g. using a UUID as defined in RFC 4122 [18]). I agree with the intention, but I think making a breaking change to xep45 at this point wouldn't be appropriate. Well, this is not using normative language, just giving a rationale (which is better than any SHOULD without a rationale at least). However, I don't understand what the service gains by tracking ids here. It can never forget the generated id unless there is an error which seems prohibitive. If a service does track (somehow) and needs to avoid id collisions between clients, it should probably take the id supplied by the client into account, so it generates the same id for two messages with the same id from the same client.
Re: [Standards] RFC: XEP-0045 MUC should not rewrite message IDs
While I understand your rationale, I think it's counter to the rationale of why XEP 45 allows MUC services to generate their own id= attributes on stanzas they forward. As Waqas noted, the id= produced by the subscriber's client may simply not meet the services need for tracking. A service may require all stanzas it produces or forwards to have universally unique ids. I concur with Kev that it seems far too late to change the spec in this manner. IMO, message correction should only be used in the context of MUC when the MUC service says it supports XEP 308. That might indicate, for instance, that the service is willing to forward subscriber produced ids. -- Kurt On Jul 25, 2014, at 7:06 AM, Georg Lukas ge...@op-co.de wrote: Hi, XEP-0045, section 7.4 http://xmpp.org/extensions/xep-0045.html#message states: Note well that for tracking purposes this service assigns a new 'id' to each message it generates (here using a UUID as defined in RFC 4122 [18]). I suggest changing that line to: The service SHOULD reflect the message with the same 'id' that was generated by the client. If the client did not provide an 'id', the server SHOULD generate one 'id' and use it for all reflections of the same message (e.g. using a UUID as defined in RFC 4122 [18]). (The example XML above should be changed accordingly; we might even replace SHOULD with MUST after the major implementations have changed) Rationale: A client needs some way to track if a sent message was succesfully processed and reflected. This is required to indicate success of transmission, to allow for message correction (XEP-0308), and it helps in displaying message errors in the context of the outgoing message. To determine if a newly received MUC message was indeed the reflection of the last outgoing MUC message, in theory three elements can be used: from, id, and body. * from: the message 'from' attribute must be the participant's nickname, however this will also be the case if the participant is connected with two clients sharing the same nickname, and the other client sends a MUC message. * id: the message 'id' attribute can only be relied upon if the server does not rewrite it * body: the message body could be used to check if an incoming message is the reflection of the just-sent message. However, some services rewrite the body, i.e. to replace a large message with a pastebin link. Therefore, none of the three elements can be reliably used to identify if an incoming MUC message is the reflection of the last outgoing message. To improve the situation, I suggest changing the XEP in a way that MUC message reflections keep the original message 'id'. Implications: This change might violate the uniqueness guarantee of message 'id's, however as the current behavior is not a MUST, service implementations exist that do not touch the message 'id', and the world is not falling apart. Kind regards, Georg -- || http://op-co.de ++ GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N ++ || gpg: 0x962FD2DE || o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+ || || Ge0rG: euIRCnet || X(+++) tv+ b+(++) DI+++ D- G e h- r++ y? || ++ IRCnet OFTC OPN ||_||
Re: [Standards] RFC: XEP-0045 MUC should not rewrite message IDs
On Fri, Jul 25, 2014 at 6:08 PM, Philipp Hancke fi...@goodadvice.pages.de wrote: Am 25.07.2014 um 09:22 schrieb Kevin Smith: On Fri, Jul 25, 2014 at 3:06 PM, Georg Lukas ge...@op-co.de wrote: XEP-0045, section 7.4 http://xmpp.org/extensions/xep-0045.html#message states: Note well that for tracking purposes this service assigns a new 'id' to each message it generates (here using a UUID as defined in RFC 4122 [18]). I suggest changing that line to: The service SHOULD reflect the message with the same 'id' that was generated by the client. If the client did not provide an 'id', the server SHOULD generate one 'id' and use it for all reflections of the same message (e.g. using a UUID as defined in RFC 4122 [18]). I agree with the intention, but I think making a breaking change to xep45 at this point wouldn't be appropriate. Well, this is not using normative language, just giving a rationale (which is better than any SHOULD without a rationale at least). However, I don't understand what the service gains by tracking ids here. No, me neither. As I said earlier, I think (at the moment) 45 would have been better to have required stable ids across reflection from the start. But as it doesn't, and I don't think requiring them at this stage is appropriate. /K
Re: [Standards] RFC: XEP-0045 MUC should not rewrite message IDs
On 25 July 2014 18:24, Kevin Smith ke...@kismith.co.uk wrote: On Fri, Jul 25, 2014 at 6:08 PM, Philipp Hancke fi...@goodadvice.pages.de wrote: Am 25.07.2014 um 09:22 schrieb Kevin Smith: On Fri, Jul 25, 2014 at 3:06 PM, Georg Lukas ge...@op-co.de wrote: XEP-0045, section 7.4 http://xmpp.org/extensions/xep-0045.html#message states: Note well that for tracking purposes this service assigns a new 'id' to each message it generates (here using a UUID as defined in RFC 4122 [18]). I suggest changing that line to: The service SHOULD reflect the message with the same 'id' that was generated by the client. If the client did not provide an 'id', the server SHOULD generate one 'id' and use it for all reflections of the same message (e.g. using a UUID as defined in RFC 4122 [18]). I agree with the intention, but I think making a breaking change to xep45 at this point wouldn't be appropriate. Well, this is not using normative language, just giving a rationale (which is better than any SHOULD without a rationale at least). However, I don't understand what the service gains by tracking ids here. No, me neither. As I said earlier, I think (at the moment) 45 would have been better to have required stable ids across reflection from the start. But as it doesn't, and I don't think requiring them at this stage is appropriate. Even if it's the behaviour of almost every MUC implementation out there? And there are people not so far away who have influence over the one implementation that I know does rewrite ids, I believe :) The current text and examples about servers rewriting id attributes was only added in the last revision of the document after a push by some people who back then thought it was the right approach. As far as I can tell nobody now thinks it is the right approach, and the vast majority of implementations haven't changed from their original (non-rewriting) behaviour. In my view rewriting ids completely breaks the protocol and various extensions, and we have certainly not yet passed the point-of-no-return, we should fix it while we can. Regards, Matthew
