* 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
