On Tue, Jan 29, 2019, at 17:41, Dave Cridland wrote: > a) Clients can make some assertion that they will generate a > globally-unique @id on stanzas.
I like that, but would servers now have to remember which messages were sent by clients that advertised this feature and which weren't? I'm not sure that's the end of the world, but it can't be applied retroactively (whereas origin-id is on each message, so a server that adds support later can know which messages in an archive should already have globally unique IDs). > b) Servers can also advertise assertions that they, too, deal with > globally unique stanzas identifiers. If a connected client fails to > make the assertion, the server either: > > i) Injects a stanza-id of its own, or: If we're going to have to fall back to this, maybe we should just always use stanza-id so that we don't have to determine if the id attribute or the stanza-id should be used. > ii) Changing the @id and encodes the original @id within it, somehow. > (They could use any scheme for that, and might want to consider > something that's difficult or impossible to emulate). What does encoding the original ID in it get us? Does the server need to know the original ID later for some reason? Clients presumably wouldn't be able to use this value if a message is reflected; if they added support for this presumably they'd just add support for globally unique IDs. > c) MUC services (and similar broadcasters) advertise a "stable > identifier" thing. Since @id's are now globally unique, they can be > passed through - but a MUC service faced with a server that isn't > asserting the Thing can choose to override the @id. Same as above. Does this make it harder (impossible?) for clients to associate reflections with the original message? > d) If a server is doing the id thing, and a client asserts same, and > fails to include an @id on any stanza, that stanza is bounced. This seems sane. —Sam _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
