On 04.06.2015 12:56, Kurt Zeilenga wrote: > It’s not clear to me that the problems that this extensions proposes to > address can be addressed through use an extension to XMPP. Extensions > ought to be truly optional. This ProtoXEP appears to be making mandates > which are more appropriate made, if the community were to support them > being made, in a revision of the XMPP base specification.
Possible, but a revision of the XMPP RFC changing the semantic and requirements of the 'id' attribute of stanzas in such a way won't ever happen I'd say. Yes, XEP-MID breaks if entities strip it out. But I can live with that. > I have a big problem with one ID to rule them all… and a bigger problem > with the last ID being that ID (the overrride requirement). To the > extent IDs are needed, they need to “stable”. This means they cannot be > overridden. As far as the use case is concerned where the ID attribute would get "overridden", it's not really overriding an existing ID. Maybe the XEP should use other terminology here. I full agree that stable IDs cannot be overridden. > For operational and security reasons, it unwise for one entity to rely > on IDs for services it provides (such as MAM) provide by some other > entity. MAM IDs are never provided by another entity then the MAM archive itself. At least that is my understanding of how MAM will/should work. > It’s not clear to me how this id provided by this extension would or > could be used in message type=error stanzas. That's simple: MIDs are not at all used for 'error' type messages. > It’s not clear to me why > this extension proposes a <message/> only solution, when it seems likely > that stanza id= problems are not necessarily specific to message stanzas. It was intentionally designed to be a solution for message stanzas only. I can't think why would want unique and stable messages IDs, like they are required to build an archive of stanza, for IQs and presences. IQ are simple request-response mechanisms and presence are ... Hmm, ok so maybe there is a reason one would archive presences in MAM (if we leave the privacy implications aside). That's actually a good point. What do the others think? I'm happy to s/message-id/stanza-id/. > It seems that there’s many security risks here associated with ID > forgery, replay, etc., but I’m not sure what, if any, mitigation is needed. Spoofing is actually a valid security concern. That is why XEP-MID states those strict business rules. > For the MUC use case, I rather we solve this as part of the MUC2 effort… I don't want to wait for MUC2, I want to solve cant-track-my-own-messages-in-muc issue right now, as it's pretty simple to solve. - Florian
signature.asc
Description: OpenPGP digital signature
