[Standards] NEW: XEP-0359 (Unique and Stable Stanza IDs)

rakoo matthieu.rakotojaona at gmail.com
Tue Jul 14 22:12:05 UTC 2015


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="room at muc.example.org" id="aaa"/>
    <stanza-id by="archive at myserver.com" 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="me at myserver.com"
           to="you at yourserver.com">
    <body>Hello there!</body>
    <stanza-id by="router at router1.com" id="1111"/> # No more client-id here
    <stanza-id by="router at router2.com" id="2222"/>
    <stanza-id by="router at routern.com" 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"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 343 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20150715/c8f6e7fe/attachment.sig>


More information about the Standards mailing list