Excerpts from Lance Stout's message of 2015-07-14 10:33:23 -0700: > > > Version 0.1 of XEP-0359 (Unique and Stable Stanza IDs) has been released. > > > \o/ > > > Some feedback on this new version: > > > 1. Disco feature is needed to discover that an entity generates ids, and that > it therefore is able to assure that ids attributed to it are valid by > stripping & overwriting ids that it routes. > > 2. Security considerations needs to include that a given id should only be > accepted for use if the by attribute is for the JID that is expected and that > the JID is able to assert the id. (Don't trust ids from room messages unless > the by attribute is the room JID AND the room lists the stanza-id feature in > its disco features) > > > > - Lance
Hey everyone,
I have some questions regarding the business rules:
- Why enforce a single id at a time ? I think it can be useful to have
multiple ids in a message:
<message ...>
[...]
<stanza-id by="[email protected]" id="aaa"/>
<stanza-id by="[email protected]" id="bbb"/>
</message>
Here the id given by the room is not the same as the one used to store
it in my server's archive: I will more probably query my archive with
the archive-provided id, but when I'm going directly to the room I
will want to use the room-provided id
- Why put the client-id in the stanza-id ? Intuitively I would have put
it directly at the top-level:
<message id="12345"
from="[email protected]"
to="[email protected]">
<body>Hello there!</body>
<stanza-id by="[email protected]" id="1111"/> # No more client-id here
<stanza-id by="[email protected]" id="2222"/>
<stanza-id by="[email protected]" id="nnnn"/>
</message>
This makes it clearer that the message, as generated by me, has this
id, and all the others are added along the road.
(Note: this seems to "conflict" with XEP-0184 at least, however I
think the features actually overlap more than they conflict)
- Purely semantic: "client-id" implies it was generated by a client, but
there are cases where it's not: for instance pubsub notifications are
sent by the servers (although there already are item-level ids in this
case), bots can technically be clients but they can also be server,
...
The name should indicate that it is the id generated by the initiator.
Maybe something like "sender-id"
signature.asc
Description: PGP signature
