Hello!
Apologies in advance; I've just subscribed to the mailing list (so I can't
reply to the thread), and I'm also a pretty new XMPP developer (I've
definitely missed the Last Call).
> 1. Is this specification needed to fill gaps in the XMPP protocol
> stack or to clarify an existing protocol?
Yes!
> 2. Does the specification solve the problem stated in the introduction
> and requirements?
Mostly. I have a specific concern for retraction in 1:1 chats,
where retractions target the @id.
RFC 6120 states the @id can be unqiue to the stream, or across all streams
(aka "global"), where this is up to the sender.
For an XEP that uses @id to refer to *any* previously sent message,
even requiring supporters to use a global @id is not enough,
as the RFC also makes no mention of what happens to the @id outside of
that stream (only that entities use it to know some response was
a direct result of a stanza they sent within that stream).
Because of this, it seems to me that an entirely valid client implementation
is to count up from 0 for each stanza sent in that stream
(maybe due to lightweight requirements where there is no CSPRNG?),
and their server can route that stanza along with an entirely different @id,
as long as it remembers the link between that @id and the one the client used
for when a response is sent back to that client.
(I would also like to submit that, while such an implementation would be
expensive, and I cannot prove that implementations like this currently exist,
we should still take them into account as they are fully compliant, and
not doing so is how we make specifications that can be unreliable.)
Requiring entities to also not modify the @id when sending into
different streams would have considerations for entities that don't
support the specification (thus the @id can be different for others).
And if supporting entities don't modify an @id from an unsupporting entity,
that could also possibly break stream-uniqueness guarantees.
I am sure there are many similar issues.
An XEP which successfully uses @id in 1:1 is LMC, as it is explicitly limited
to the last message. Thus, if there are multiple messages from that entity
with that @id, the message to be corrected is the most recent one from them
at that time, with that @id.
If we want to target *any* previous message, this cannot be done.
> 3. Do you plan to implement this specification in your code? If not,
> why not?
As it is currently written, no. I believe 0359's <origin-id/> would be one
possible solution for the above, as that element (and even the name of 0359)
seems to have been written specifically for this problem.
Looking at the commit history for 0424, this used to be the case until
~2 years ago! I would love to hear why it stopped being used.
> 4. Do you have any security concerns related to this specification?
Maybe not necessarily security-related, but it seems entirely possible to
write fully-compliant implementations which can break in 1:1 chats,
due to the instability of @ids.
> 5. Is the specification accurate and clearly written?
I have two nitpicks with its wording:
> Supporting clients MUST set a unique 'id' on the <message> element in
> outgoing stanzas (as per Unique and Stable Stanza IDs (XEP-0359) [9]),
> [...]
"unique" here could be interpreted, using the RFC, as unique to one stream
or across all streams.
Additionally, 0359 makes zero mentions of requiring supporters to handle
@ids any differently (it only introduces <stanza-id/> and <origin-id/>),
while this passage states it does. This could cause problems where
entities may check for 0359 support, and then incorrectly assume a behavior
entirely unspecified by 0359. This mistake is actually made later in 0424:
> Clients that don't support Unique and Stable Stanza IDs (XEP-0359) [9]
> (and therefore don't support Message Retraction (XEP-0424) [14]),
> are not guaranteed to have a unique 'id' attribute on their <message>
> elements.
> [...]
> To mitigate this, clients can do a Service Discovery (XEP-0030) [1] request
> to check if the other client supports XEP-0359, and if not, [...]
I am sure this XEP will eventually see a lot of adoption in the future
(and it definitely serves a very important purpose in my eyes),
but as it currently stands for 1:1, I see some edge cases that I would
prefer not to have to debug, whenever they become an issue.
Thank you all for your efforts to maintain the XMPP ecosystem.
— Violet
