On 25/02/2023 12.38, Marvin W wrote:
On Sat, 2023-02-25 at 11:35 +0100, Florian Schmaus wrote:
What I tried to express is that changing the semantics of the RFC
'id'
attribute in a new RFC is not a viable solution. Simply because you
still need to operate with older implementations that do not
On Sat, 2023-02-25 at 11:35 +0100, Florian Schmaus wrote:
> What I tried to express is that changing the semantics of the RFC
> 'id'
> attribute in a new RFC is not a viable solution. Simply because you
> still need to operate with older implementations that do not follow
> the
> newer RFC. Henc
On 25.02.23 11:05, Marvin W wrote:
On Sat, 2023-02-25 at 10:50 +0100, Florian Schmaus wrote:
However, it is still unclear to me how changing the RFC 'id'
attribute
specification from "must be unique within the scope of the stream id"
to
"must be globally unique, for example by using UUID" solves
On Sat, 2023-02-25 at 10:50 +0100, Florian Schmaus wrote:
> However, it is still unclear to me how changing the RFC 'id'
> attribute
> specification from "must be unique within the scope of the stream id"
> to
> "must be globally unique, for example by using UUID" solves much we
> discussed in t
On 25.02.23 00:56, Peter Saint-Andre wrote:
On 2/24/23 8:47 AM, Tedd Sterr wrote:
The original sender of a message stanza SHOULD give it id=UUID.
Unfortunately, this wasn't a requirement in the RFCs, so now we have
various hacks to try to deal with that because we can't just fix the
problem w
On 2/24/23 8:47 AM, Tedd Sterr wrote:
The original sender of a message stanza SHOULD give it id=UUID.
Unfortunately, this wasn't a requirement in the RFCs, so now we have
various hacks to try to deal with that because we can't just fix the
problem while maintaining compatibility.
At some poi
