On Tue, 29 Jan 2019, 18:01 Sam Whited <s...@samwhited.com wrote: > 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). >
Ah, I was thinking that we'd do this on a hop-by-hop basis. So clients advertise only to their servers, and the servers advertise to each other. But I think message archiving might remain a case where we need to use stanza-ids - I know I said we'd ignore the case of a malicious attacker, but we definitely don't want an attacker to overwrite or simply corrupt an archive. Of course, we could use a mandated format for ids which includes the jid, but that doesn't work with MUC etc. And interesting alternative is if the MAM service uses a derived id tuple of (from,id) - in that case I *think* it's safe to use stanza ids, as long as the servers and clients are all advertising our new feature *or* there's some kind of workaround. Sorry, I'm thinking aloud and being *very* unclear. That's why I had the servers handle non-conforming clients: > > 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. > Yeah. It's a bit rubbish, and I don't like this option. > > 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. > Well, I was thinking it would be reversible. So if a server receives a "response" type - error, or result - it can reverse the mapping and give the client the id it used. Externally, it'd look like the client used unique ids everywhere and consistently - but the client's view of its own stanzas would be unchanged. > > 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? > I think - and I may be wrong - that it'd be fairly easy to use the same id on the reflection itself. > > 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: standards-unsubscr...@xmpp.org > _______________________________________________ >
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
