On Wed, Jan 30, 2019, at 22:42, Dave Cridland wrote:
> Well, I was thinking it would be reversible. So if a server receives a
> "response" type - error, or result - it can reverse the mapping and
> give the client the id it used.
>
> Externally, it'd look like the client used unique ids everywhe
On Tue, 29 Jan 2019, 18:01 Sam Whited On Tue, Jan 29, 2019, at 17:41, Dave Cridland wrote:
> > a) Clients can make some assertion that they will generate a
> > globally-unique @id on stanzas.
>
> I like that, but would servers now have to remember which messages were
> sent by clients that adverti
On Tue, Jan 29, 2019, at 17:41, Dave Cridland wrote:
> a) Clients can make some assertion that they will generate a
> globally-unique @id on stanzas.
I like that, but would servers now have to remember which messages were sent by
clients that advertised this feature and which weren't? I'm not su
Let's assume, for a moment, that we do not wish to attempt to solve
deliberate duplication of ids, and instead assume that any duplication is a
bug.
Let's further assume that "if only" the @id attribute of a stanza were both
always present, and globally unique, it'd work.
What if:
a) Clients can
On Tue, Jan 29, 2019, at 15:31, Georg Lukas wrote:
> However, there are multiple issues I see with [XEP-0367's] rules:
>
> - they are rather complex
I tend to agree; having to do any sort of logic just to get an ID isn't ideal,
nor is having different IDs being used between group chats and regul
Hi together,
I've added a "Message IDs and References" agendum to the Summit
discussion agenda. As I probably won't be able to attend, I wanted to
elaborate what exactly the problems I'd like to see solved are, and
maybe even ignite a bit of on-list discussion pre-Summit.
We currently have three
