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
