On 11 May 2015 at 19:21, XMPP Extensions Editor wrote:
> Title: REST with XMPP
>
How is this materially different to XEP-0050?
The reason I ask is because my initial reaction was that the specification
essentially reinvents XEP-0004, but when I considered how it looked once
that change had been
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: REST with XMPP
Abstract: This specification defines how the Representational State Transfer
(REST)
architectural style can be applied to an XMPP overlay network. It specifies
an XMPP protocol extension for accessing re
On 11.05.2015 17:46, Ben Langfeld wrote:
> The thinking is that it is a simple way to provide a baseline method of
> stanza disambiguation for all XEPs without reinventing solutions.
> Generating a UUID is cheap, and I don't see any reason for a client
> implementation to object to doing it.
IIRC
On 11.05.2015 17:25, Brian Cully wrote:
> In implementing MAM in clients there can be a case where MAM results
> contain duplicates of already seen messages. In order to prevent such
> duplication, the MAM ID for a stanza would need to appear on a newly
> generated non-MAM stanza.
>
>
On 11 May 2015 at 16:25, Brian Cully wrote:
> In implementing MAM in clients there can be a case where MAM results
> contain duplicates of already seen messages. In order to prevent such
> duplication, the MAM ID for a stanza would need to appear on a newly
> generated non-MAM stanza.
>
[I’m worried that my original message is getting derailed here, but
I’ll continue with this thread for a little longer]
Even were it simple, you cannot trust clients to generate UUIDs for
purposes such as MAM or any other “trusted” ID source. It becomes trivial for
ill-behaved o
The thinking is that it is a simple way to provide a baseline method of
stanza disambiguation for all XEPs without reinventing solutions.
Generating a UUID is cheap, and I don't see any reason for a client
implementation to object to doing it.
On 11 May 2015 at 12:36, Brian Cully wrote:
> I don’
I don’t think it makes sense to require clients to generate globally
unique IDs. In a closed environment you can do what you want, but it seems
onerous to require that for arbitrary clients (many of which don’t include any
ID on messages, let alone globally unique ones).
-bjc
> On 11-M
Leaving backward compatibility concerns aside, I'd like to see globally
unique message IDs made compulsory instead of optional and to use the
original message ID as the MAM ID. This is what we are doing in our
closed-client environment and it works well, but sacrifices compatibility
with other clie
In implementing MAM in clients there can be a case where MAM results
contain duplicates of already seen messages. In order to prevent such
duplication, the MAM ID for a stanza would need to appear on a newly generated
non-MAM stanza.
As background, imagine a client which, when i
10 matches
Mail list logo
