[Standards] XEP-0313: pending 0.7 update review

Philipp Hörist philipp at hoerist.com
Tue May 12 16:05:17 UTC 2020


Hi,

I think you misunderstand the XEP, MAM does not care about what IDs a user
adds, it certainly does not care about origin-id, or the message-id.

The server itself generates a unique ID when receiving a message and this
ID is communicated via the stanza-id element for example in MUC Messages.

Or if you fetch messages via MAM, in the result element id attribute.

Regards
Philipp

Am Di., 12. Mai 2020 um 17:44 Uhr schrieb Michal Piotrowski <
michal.piotrowski at erlang-solutions.com>:

> One more question, probably more general. What would be the most desired
> server's behaviour when it observes that a user sent a message with a used
> UID? In my opinion, it be better to reject this new message with an
> existing UID, if so how to communicate that error back to the sender?
>
> Best regards
> Michal Piotrowski
> Software Architect at https://www.erlang-solutions.com/
> email: michal.piotrowski at erlang-solutions.com
> skype: twitter/github/medium: michalwski
>
>
>
> On Mon, 11 May 2020 at 10:22, Michal Piotrowski <
> michal.piotrowski at erlang-solutions.com> wrote:
>
>> Hi Matthew,
>>
>> Thanks for making the changes. I'm really in favour of them. I see there
>> was no update to the PRs nor here on the mailing list. What needs to happen
>> in order to proceed with these?
>>
>> Alos, I have a comment (or rather question) regarding the new way of
>> querying the archive based on message UIDs. I assume that by UID, you mean
>> the origin-id as set by the client sending the message. If so, it didn't
>> find it clearly stated in your proposed changes nor in the current
>> version of MAM XEP. If not origin-id is meant here, I'd like to know what
>> UID means in this context.
>>
>> Best regards
>> Michal Piotrowski
>> Software Architect at https://www.erlang-solutions.com/
>> email: michal.piotrowski at erlang-solutions.com
>> skype: twitter/github/medium: michalwski
>>
>>
>>
>> On Wed, 22 Apr 2020 at 13:17, Florian Schmaus <flo at geekplace.eu> wrote:
>>
>>> On 4/22/20 12:07 PM, Matthew Wild wrote:
>>> > On Tue, 21 Apr 2020 at 15:50, Florian Schmaus <flo at geekplace.eu
>>> > <mailto:flo at geekplace.eu>> wrote:
>>> >     On 4/21/20 2:32 PM, Dave Cridland wrote:> On Mon, 20 Apr 2020 at
>>> 16:20,
>>> >     > You're going to hate me, but one more thing...
>>> >     >
>>> >     > Current MAM says that servers SHOULD include a count. The
>>> problem with
>>> >     > this is that it's extremely slow on any system with more than
>>> trivial
>>> >     > retention periods, since this tends to degenerate into either a
>>> >     COUNT(*)
>>> >     > SQL query (table-scan-tastic) or a standalone counter (which then
>>> >     drifts
>>> >     > and is a contention point).
>>> >     >
>>> >     > The majority of client libraries appear to ignore the count
>>> values
>>> >     > anyway, as far as I can tell, so can we relax this to a MAY?
>>> (XEP-0059
>>> >     > is MAY-but-only-if, which is arguably really a SHOULD anyway).
>>> >
>>> >     I think such a relaxation would require a namespace bump.
>>> >
>>> > I'm not convinced. In any case, servers that already comply with the
>>> > SHOULD will probably continue to do so, new servers may be more likely
>>> > not to, but given that clients don't really use the (unreliable) info
>>> > today then I don't think we lose anything in practice.
>>>
>>> I could follow that argumentation in this case. It's probably just me,
>>> but I am very conservative when it comes to relaxations of keywords.
>>>
>>> - Florian
>>>
>>> _______________________________________________
>>> Standards mailing list
>>> Info: https://mail.jabber.org/mailman/listinfo/standards
>>> Unsubscribe: Standards-unsubscribe at xmpp.org
>>> _______________________________________________
>>>
>>
> Code Sync & Erlang Solutions Conferences
> <https://www2.codesync.global/l/23452/2019-11-13/6sypwx>
>
>
> Code BEAM Lite ITA - Bologna: Rescheduled
>
> Code BEAM STO - Stockholm: Rescheduled
>
> ElixirConf EU - Warsaw: 7-8 October 2020
>
> Code Mesh - London: 5-6 November 2020
>
>
> Erlang Solutions cares about your data and privacy; please find all
> details about the basis for communicating with you and the way we process
> your data in our Privacy Policy
> <https://www.erlang-solutions.com/privacy-policy.html>. You can update
> your email preferences or opt-out from receiving Marketing emails here
> <https://www2.erlang-solutions.com/email-preference?epc_hash=JtO6C7Q2rJwCdZxBx3Ad8jI2D4TJum7XcUWcgfjZ8YY>
> .
>
>
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200512/5b95e775/attachment-0001.html>


More information about the Standards mailing list