<div dir="ltr"><div><div><div><div><div><div>On an abstract level I feel like using the by attribute for the Message-ID-XEP will make the XEP more general purpose. Even though we might not necessarily see a benefit for multiple instances adding their own IDs now we might have a use case for them in the future.<br><br></div>As for letting the client choose the MAM id vs agreeing on some kind of schema I'm all for the schema since it does not require for elaborate business rules on how to handle duplicate ids an unknowing or malicious clients might inject.<br></div>Matthew is right in arguing that a remote entity might not know our stream id however those messages (let's face it we are talking about MUC here) will get reflected back to us anyway and thus allowing the remote entity to add their own message id.<br><br></div>MUC is also a great example where the by attribute might come in handy. It allows for both the MUC component and the users server to both add their own message-id without requiring complicated business rules such as 'if its a normal message strip all message ids and add your own but don't do this when its a group chat message'. It also allows for MAM implementations to optionally save group messages on behalf of the server (current XEP says optionally)<br><br></div>cheers<br></div>Daniel<br><br></div>P.S.: I don't have a strong opinion on the MAM id generation schema (And this doesn't belong to the message-id-discussion but should be in a separate MAM discussion since it has nothing to do with the actual message-id XEP besides the fact that it will be using this XEP when broadcasting messages via the MR2-XEP) but using something like SHA256(streamId+stanzaId) will have the benefit of not requiring and extra id and would also make all ids in the archive of the same length which might make it easier when looking at the database or an xml stream in a debugging context.<br></div><div class="gmail_extra"><br><div class="gmail_quote">2015-06-07 23:14 GMT+02:00 Matthew Wild <span dir="ltr"><<a href="mailto:mwild1@gmail.com" target="_blank">mwild1@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 7 June 2015 at 21:39, Florian Schmaus <<a href="mailto:flo@geekplace.eu">flo@geekplace.eu</a>> wrote:<br>
> On 07.06.2015 20:42, Georg Lukas wrote:<br>
>> 3) Create a MID generation scheme that can be independently followed by<br>
>> client and server, i.e. full-jid + stream-id + packet-id.<br>
><br>
> I'd don't think we'll need the full-jid. The properties of the stream-id<br>
> are sufficient to generate a unique, collision free MID by concatenating<br>
> it with the stanza-id.<br>
><br>
> We may not be able to use the stream-id though, because of the RFC<br>
> requirement that it has to be kept secret. Thus requiring us to<br>
> introduce a new public-stream-id which has the same properties as the<br>
> stream-id, but without the 'secret' requirement.<br>
><br>
>> This scheme is<br>
>> very similar to #2, but the client has less options to game it, and I<br>
>> don't see significant benefits over #2.<br>
><br>
> "Less options to game it" is not a significant benefit? Also not<br>
> requiring UUIDs as stanza-id is also a big plus: A dump client can still<br>
> generate stanza-ids using a simple counter and still participate.<br>
><br>
><br>
>> I think these options need to be weighted and one of them chosen before<br>
>> we can proceed with the MID XEP.<br>
><br>
> I'm all for 3. It solves the "how can a client know the MAM archive ID<br>
> in advance" problem in an elegant and efficient way.<br>
<br>
</div></div>I like it too, and I hope Dave can throw together the proposal he's<br>
been promising for it :)<br>
<br>
I feel it still has some shortcomings though:<br>
<br>
  - It only works for server-local archives (as remote entities won't<br>
know your stream id)<br>
<br>
  - It removes the ability for the server to use its own ids for<br>
messages, which may be more efficient<br>
<br>
  - If it's based on stanza ids, we have to verify uniqueness somehow<br>
(and gracefully fail on non-uniqueness)<br>
<br>
  - If it's based on counters then uniqueness is not a problem, but<br>
XEP-0198 implementation experience has demonstrated that simple<br>
counters apparently aren't so simple after all<br>
<br>
  - It removes the need for reflection of all sent messages, but there<br>
is potentially benefit in that practice (people generally like it in<br>
MUC)<br>
<br>
Regards,<br>
Matthew<br>
</blockquote></div><br></div>