Re: [Standards] RFC: XEP-0045 MUC should not rewrite message IDs

[Dave Cridland]

On 26 July 2014 16:53, Kurt Zeilenga  wrote:

>
> On Jul 26, 2014, at 7:43 AM, Dave Cridland  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.

Re: [Standards] RFC: XEP-0045 MUC should not rewrite message IDs

[Georg Lukas]

* Dave Cridland  [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

[Kurt Zeilenga]

On Jul 26, 2014, at 7:43 AM, Dave Cridland  wrote:

> On 26 July 2014 12:30, Georg Lukas  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]

On 26 July 2014 12:30, Georg Lukas  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

[Georg Lukas]

Hello,

* Kevin Smith  [2014-07-25 18:53]:
> I agree with the intention, but I think making a breaking change to
> xep45 at this point wouldn't be appropriate.

Existing protocols need to be changed occasionally, and I am pretty sure
no point in time is appropriate for that.

However, the change I suggest is not a breaking change, it merely
documents how most implementations do it anyway.

The XEP currently only makes a note that "*this* service" rewrites the
'id'. It does NOT state that every service MUST rewrite it. This is also
why I suggested "SHOULD" for the change: this would allow for
currently-rewriting implementations to go on rewriting or get fixed
eventually, while new implementations will provide the suggested
behaviour.

So please restrain from rejecting my proposal purely on formal grounds.

Regarding the technical grounds, I have re-read the 2010 discussion
about this matter [1], as well as this thread and I found the following
points:

pro rewriting:
 1. the client message and the reflected message are not the same
message, they only have similar content
 2. server-side error tracking
 3. 'id' uniqueness guarantees can be given by the service
 4. tracking of message 'id's is generally not worthwhile
 5. unique 'id's allow for threading

contra rewriting:
 6. it allows a client to track if its message was successfully reflected
 7. Last Message Correction (XEP-0308) works even without explicit
 support from the MUC

I'd like to address the points in detail:

1) From a purely technical PoV, #1 is surely true, however as a client
developer (or a MUC user, for that matter), I consider what I sent and
what is reflected as the same message, and having the same 'id' value
tremendously helps with tracking this message.

2) Prosody and ejabberd demonstrate that error tracking is possible even
without rewriting the 'id', and it doesn't look like vast server-side
resources are required for that

3) In practice, nobody is relying on the uniqueness of 'id's anyway,
because there are so many broken implementations out there.

4) It actually is worthwhile for a client implementation to track the
'id's it generated itself. Here it does know very well about their
uniqueness, and it can use the JID+id combination to identify message
reflections, message ACKs (XEP-0184) or deploy message correction.

5) The Threading XEP (0201) provides its own unique thread id, which
should be used instead of the message 'id' if a client opts to implement
threading.

6) While it is possible to create a new XEP for adding some unique
client-generated message id to each stanza for reflection tracking
purposes, or use another XEP like 0201, using the message 'id' is
straightforward and the least surprising method. This would also make it
consistent with the notion that a message error will carry the same
'id'.

7) To allow message correction in an id-rewriting MUC, the MUC service
needs to keep track of the mapping between a client's last 'id' and all
the reflection 'id's it created for that client's last message, for each
receiver. This means at least O(N²) storage for a MUC with N
participants and per-receiver unique 'id's.


To summarize: so far I have not seen any convincing technical arguments
in favor of rewriting the message 'id' on reflected messages. If anybody
has such arguments, I would love to hear them. However, keeping the
client-originated 'id' makes (at least) client implementations easier
and less error prone, and allows for better state synchronization (what
you sent vs. what the MUC received).

The formal argument that changing the XEP is bad is true, however this
change would only reflect what major MUC implementations (I tested
Prosody and ejabberd, probably there are more) are doing anyway, while
not explicitly disallowing the id-rewriting implementations.

To comply with Waqas' objection, I would change the second SHOULD into a
MAY, though:

| "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 MAY generate one 'id' and use it for all reflections of the
| same message (e.g. using a UUID as defined in RFC 4122 [18])."


Kind regards,

Georg

[1] http://mail.jabber.org/pipermail/standards/2010-November/023949.html
-- 
|| 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

[Matthew Wild]

On 25 July 2014 18:24, Kevin Smith  wrote:
> On Fri, Jul 25, 2014 at 6:08 PM, Philipp Hancke
>  wrote:
>> Am 25.07.2014 um 09:22 schrieb Kevin Smith:
>>
>>> On Fri, Jul 25, 2014 at 3:06 PM, Georg Lukas  wrote:

 XEP-0045, section 7.4 
 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

Re: [Standards] RFC: XEP-0045 MUC should not rewrite message IDs

[Kevin Smith]

On Fri, Jul 25, 2014 at 6:08 PM, Philipp Hancke
 wrote:
> Am 25.07.2014 um 09:22 schrieb Kevin Smith:
>
>> On Fri, Jul 25, 2014 at 3:06 PM, Georg Lukas  wrote:
>>>
>>> XEP-0045, section 7.4 
>>> 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

[Kurt Zeilenga]

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  wrote:

> Hi,
> 
> XEP-0045, section 7.4 
> 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

[Philipp Hancke]

Am 25.07.2014 um 09:22 schrieb Kevin Smith:

On Fri, Jul 25, 2014 at 3:06 PM, Georg Lukas  wrote:

XEP-0045, section 7.4 
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

[Waqas Hussain]

On Fri, Jul 25, 2014 at 10:06 AM, Georg Lukas  wrote:

> Hi,
>
> XEP-0045, section 7.4 
> 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

[Kevin Smith]

On Fri, Jul 25, 2014 at 3:06 PM, Georg Lukas  wrote:
> XEP-0045, section 7.4 
> 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

[Standards] RFC: XEP-0045 MUC should not rewrite message IDs

[Georg Lukas]

Hi,

XEP-0045, section 7.4 
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