On 29.09.20 12:23, Dave Cridland wrote: > * UUIDv4 becomes an "advised to use"; the requirement is uniqueness. I > think UUIDv4 is a good thing, and people are unlikely to get anything > wrong if they use this method, but I don't think there's any > interoperability issue with using something different. > * Unconvinced we want to (or even can) rely on global uniqueness from > foreign entities; so I'm keen on the first bullet-point in (b) but less > sold on the second - having servers allocate a MAM id for inbound > foreign messages seems uncomplicated and safer.
The reason to enforce UUIDv4 is that this can be verified server-side. While it can't be verified that something that looks like a UUIDv4 is created from actual randomness, it's probably the easiest in any programming language to actually generate a random UUIDv4 instead of generating a non-random string that the server-side verification considers a valid UUIDv4. If the string can just be anything, implementations may reside to things like random-connection-id + counter or timestamp. We've seen those in the past. To get new developers to do things right, we should make sure that doing the right thing is easier than doing wrong things that work "good enough" - even if we reach this by artificially increasing the complexity of doing wrong things. I am not aiming for global uniqueness, just uniqueness within each "conversation" (a groupchat or a direct chat) and within each entity. Also I am aiming for reducing the IDs a message has, given how much confusion we already had because of "which ID to take for this XEP". On 29.09.20 13:34, Holger Weiß wrote:> BTW, I see how we designed things this way so I do understand how this > might break existing API layers, but I don't see how this is the wrong > layer per se. Stream management is about acknowledging stanza delivery, > and referring to the delivered stanza by ID rather than count seems fine > to me. It's done similarly in other protocols. I agree with this but from here would conclude that stream management *is* the wrong layer to announce the MAM server's stanza-id: Stream management works on the stanzas (iq, message, presence) which comfortably all have an id attribute on the top element, which is the real "stanza id". Thus acking a stanza with an ID instead of the count is perfectly fine, but then IMO it should be the id attribute of such stanza and not different things for different kinds of stanzas. Marvin _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
