Re: [Standards] XEP-0353 propose id syntax

[Marvin W]

I guess it wasn't obvious what I was referring to here. Of course it's
totally fine to ask initiators to create an identifier that they
consder globally unique, but recipients can never rely on that. And as
such a MUST statement doesn't make sense. The reason is that as soon as
a "globally unique" identifier is generated and shared, someone might
take it and use it for something else, making it no longer globally
unique. 

All I want to say is: if you put something like globally unique in
there, at the same time you'd need to add a disclaimer, telling
developers that they can't rely on the global uniqueness and should
only assume id+initiator-jid as something that might be globally unique
(meaning: if it happens to be not globally unique, it's acceptable that
something breaks). Alternatively the globally unique could be just a
SHOULD, showing that it may actually be not globally unique.

And in any case, I would want to understand why we're adding such a
requirement, because I don't see why it would be needed (or even the
advantage, given that I can't rely on it as a recipient anyway).

Marvin

On Fri, 2023-01-06 at 19:25 -0500, Sam Whited wrote:
> > 1. It is impossible to guarantee that an identifier is "globally
> >    unique", thus this requirement should not end up in any
> >    specification.
> 
> The term "globally unique" is a widely understood term of art that is
> perfectly acceptable to use. We don't need to worry about the fact
> that
> it's technically possible that sometime before the eventual heat
> death
> of the universe it may be possible for two IDs generated in such a
> way
> that they could be called "globally unique" to not be unique. The
> probability is close enough to zero to be negligible.
> 
> We can always point to the definition in the glossary section of the
> spec if you're worried about this.
> 
> —Sam
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0353 propose id syntax

[Thilo Molitor]

To bring this from the Github PR [1] to the list, too
> @fippo @stpeter Is this ok to be merged in its current state?

[1] https://github.com/xsf/xeps/pull/1262


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0353 propose id syntax

[Sam Whited]

> 1. It is impossible to guarantee that an identifier is "globally
>unique", thus this requirement should not end up in any
>specification.

The term "globally unique" is a widely understood term of art that is
perfectly acceptable to use. We don't need to worry about the fact that
it's technically possible that sometime before the eventual heat death
of the universe it may be possible for two IDs generated in such a way
that they could be called "globally unique" to not be unique. The
probability is close enough to zero to be negligible.

We can always point to the definition in the glossary section of the
spec if you're worried about this.

—Sam
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0353 propose id syntax

[Marvin W]

Hi,

1. It is impossible to guarantee that an identifier is "globally
unique", thus this requirement should not end up in any specification.
2. The session ID is already required to be random as per XEP-0166.

What is the problem that you want to solve here? Looking at the
protocol, the only thing where it is relevant that ids are collision
free is the tie breaking. But that's far away from global uniqueness.
Further more, the tie breaking could just be modified to include the
initiators full jid as a second ordering criteria, which is guaranteed
to be collision free.

Marvin

On Fri, 2023-01-06 at 04:31 +0100, Thilo Molitor wrote:
> Well, thanks for all your explanations and recommendations.
> I'll go with "This identifier MUST be globally unique, and therefore
> it is 
> RECOMMENDED to use UUIDv4."
> I updated the PR accordingly: https://github.com/xsf/xeps/pull/1262
> 
> -tmolitor
> 
> 
> Am Donnerstag, 5. Januar 2023, 14:27:22 CET schrieb Dave Cridland:
> > On Thu, 5 Jan 2023 at 10:19, Florian Schmaus 
> > wrote:
> > > On 05/01/2023 10.51, Dave Cridland wrote:
> > > > * The argument that this doesn't need a namespace bump is wrong
> > > > because
> > > > "experimental" has no effect here. The entire point of those
> > > > 'versioned'
> > > > namespaces was to ensure that we could freely implement
> > > > Experimental
> > > > XEPs without worrying about causing compatibility nightmares.
> > > > The
> > > > argument that there's no implementation is counter-productive -
> > > > if
> > > > there's nobody implementing, then by definition it doesn't
> > > > matter if you
> > > > bump the namespace.
> > > 
> > > +1
> > > 
> > > I see a recent trend in the community that it is acceptable to
> > > introduce
> > > backwards incompatible changes in 'experimental' XEPs. I think we
> > > are
> > > moving along a dangerous path if this trend continues.
> > 
> > For a long time, it tended to be the opposite problem - people
> > would add an
> > optional attribute or child element, and then bump the namespace.
> > That's
> > irritating (and harms interoperability in a safe manner), but not
> > as bad as
> > introducing incompatible changes and *not* bumping the namespace.
> > 
> > > However, I believe that this trend is part a symptom of a larger
> > > problem. Namely that we e are missing a workflow where people can
> > > work
> > > together on a standards document, while implementing what is
> > > described
> > > in that document and still be able to react agile regarding
> > > protocol
> > > changes. The latter means, amongst other things, being able to
> > > introduce
> > > backwards incompatible changes without a namespace bump.
> > 
> > I think we have that, modulo that if we introduce an incompatible
> > change,
> > we bump the namespace. And in many cases, you can handle both
> > namespaces
> > easily with one or two conditionals, so if you're closely tracking
> > a XEP in
> > your implementation, it's usually OK.
> > 
> > The advantage of our model is that if people are not working
> > closely
> > together, it's still safe.
> > 
> > > I become more and more convinced that we may be better with an
> > > IETF I-D
> > > / RFC style standardization process. Where an I-D is a mutable,
> > > living
> > > document on the road to become an immutable RFC.
> > 
> > Well... An Experimental XEP maps to an I-D, except we've made ours
> > safe to
> > implement in the wild (fairly) safely.
> > 
> > RFCs map to DraftStable/Final XEPs. These still might change, but
> > this
> > really ought to be pretty rare, especially with Final. The fact
> > they're not
> > immutable is, I agree, not ideal - but the static nature of RFCs
> > brings its
> > own set of problems and I'm not really sure which is the better
> > option.
> > 
> > I think the thing I'm missing is that I sometimes want to be able
> > to find
> > the latest XEP version covering a particular namespace, but that
> > requires
> > tooling changes etc and I don't care enough to fix it myself, so...
> > 
> > Dave.
> 
> 
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0353 propose id syntax

[Thilo Molitor]

Well, thanks for all your explanations and recommendations.
I'll go with "This identifier MUST be globally unique, and therefore it is 
RECOMMENDED to use UUIDv4."
I updated the PR accordingly: https://github.com/xsf/xeps/pull/1262

-tmolitor


Am Donnerstag, 5. Januar 2023, 14:27:22 CET schrieb Dave Cridland:
> On Thu, 5 Jan 2023 at 10:19, Florian Schmaus  wrote:
> > On 05/01/2023 10.51, Dave Cridland wrote:
> > > * The argument that this doesn't need a namespace bump is wrong because
> > > "experimental" has no effect here. The entire point of those 'versioned'
> > > namespaces was to ensure that we could freely implement Experimental
> > > XEPs without worrying about causing compatibility nightmares. The
> > > argument that there's no implementation is counter-productive - if
> > > there's nobody implementing, then by definition it doesn't matter if you
> > > bump the namespace.
> > 
> > +1
> > 
> > I see a recent trend in the community that it is acceptable to introduce
> > backwards incompatible changes in 'experimental' XEPs. I think we are
> > moving along a dangerous path if this trend continues.
> 
> For a long time, it tended to be the opposite problem - people would add an
> optional attribute or child element, and then bump the namespace. That's
> irritating (and harms interoperability in a safe manner), but not as bad as
> introducing incompatible changes and *not* bumping the namespace.
> 
> > However, I believe that this trend is part a symptom of a larger
> > problem. Namely that we e are missing a workflow where people can work
> > together on a standards document, while implementing what is described
> > in that document and still be able to react agile regarding protocol
> > changes. The latter means, amongst other things, being able to introduce
> > backwards incompatible changes without a namespace bump.
> 
> I think we have that, modulo that if we introduce an incompatible change,
> we bump the namespace. And in many cases, you can handle both namespaces
> easily with one or two conditionals, so if you're closely tracking a XEP in
> your implementation, it's usually OK.
> 
> The advantage of our model is that if people are not working closely
> together, it's still safe.
> 
> > I become more and more convinced that we may be better with an IETF I-D
> > / RFC style standardization process. Where an I-D is a mutable, living
> > document on the road to become an immutable RFC.
> 
> Well... An Experimental XEP maps to an I-D, except we've made ours safe to
> implement in the wild (fairly) safely.
> 
> RFCs map to DraftStable/Final XEPs. These still might change, but this
> really ought to be pretty rare, especially with Final. The fact they're not
> immutable is, I agree, not ideal - but the static nature of RFCs brings its
> own set of problems and I'm not really sure which is the better option.
> 
> I think the thing I'm missing is that I sometimes want to be able to find
> the latest XEP version covering a particular namespace, but that requires
> tooling changes etc and I don't care enough to fix it myself, so...
> 
> Dave.


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0353 propose id syntax

[Dave Cridland]

On Thu, 5 Jan 2023 at 10:19, Florian Schmaus  wrote:

>
> On 05/01/2023 10.51, Dave Cridland wrote:
> > * The argument that this doesn't need a namespace bump is wrong because
> > "experimental" has no effect here. The entire point of those 'versioned'
> > namespaces was to ensure that we could freely implement Experimental
> > XEPs without worrying about causing compatibility nightmares. The
> > argument that there's no implementation is counter-productive - if
> > there's nobody implementing, then by definition it doesn't matter if you
> > bump the namespace.
>
> +1
>
> I see a recent trend in the community that it is acceptable to introduce
> backwards incompatible changes in 'experimental' XEPs. I think we are
> moving along a dangerous path if this trend continues.
>
>
For a long time, it tended to be the opposite problem - people would add an
optional attribute or child element, and then bump the namespace. That's
irritating (and harms interoperability in a safe manner), but not as bad as
introducing incompatible changes and *not* bumping the namespace.


> However, I believe that this trend is part a symptom of a larger
> problem. Namely that we e are missing a workflow where people can work
> together on a standards document, while implementing what is described
> in that document and still be able to react agile regarding protocol
> changes. The latter means, amongst other things, being able to introduce
> backwards incompatible changes without a namespace bump.
>
>
I think we have that, modulo that if we introduce an incompatible change,
we bump the namespace. And in many cases, you can handle both namespaces
easily with one or two conditionals, so if you're closely tracking a XEP in
your implementation, it's usually OK.

The advantage of our model is that if people are not working closely
together, it's still safe.


> I become more and more convinced that we may be better with an IETF I-D
> / RFC style standardization process. Where an I-D is a mutable, living
> document on the road to become an immutable RFC.


Well... An Experimental XEP maps to an I-D, except we've made ours safe to
implement in the wild (fairly) safely.

RFCs map to DraftStable/Final XEPs. These still might change, but this
really ought to be pretty rare, especially with Final. The fact they're not
immutable is, I agree, not ideal - but the static nature of RFCs brings its
own set of problems and I'm not really sure which is the better option.

I think the thing I'm missing is that I sometimes want to be able to find
the latest XEP version covering a particular namespace, but that requires
tooling changes etc and I don't care enough to fix it myself, so...

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0353 propose id syntax

[Dave Cridland]

On Thu, 5 Jan 2023 at 12:35, Marvin W  wrote:

> Which brings me to the conclusion: If we want to gauarantee a certain
> amount of randomness in any id field, we should just state exactly
> that, e.g. "the id SHOULD include at least 120 bits of randomness, for
> example by using an UUIDv4" (and then we might see people in the wild
> just encode 15 random bytes using base64, saving 16 bytes on the wire
> with every id).


For the "SHOULD" case, yes. For the MUST case, if we're basically encoding
a 128-bit number with a well-known syntax supported by external tooling
like databases, then UUIDv4 is pretty much perfect.

(I'd phrase the "SHOULD" case as "This identifier MUST be globally unique,
and therefore it is RECOMMENDED to use UUIDv4", rather than specifying bits
of randomness - the RECOMMENDED here is in the sense of "If you don't do
this you'd better know what you're doing").
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0353 propose id syntax

[Marvin W]

I also agree that a recommendation to use UUID is totally sufficient
here (call it RECOMMENDED or SHOULD, I don't care). There is no need to
require a UUID. Adding a recommendation for UUID is also inherently
backwards compatible and therefor does not require a namespace bump.

I also doubt the necessity for a 122 bits of randomness for this
specific usecase, that is the id of a jingle session, which by
definition is both short-lived and only between two entities. These two
parameters make an accidental collision highly unlikely while
intentional collisions should only harm the communication of the two
parties.

Finally, the obsession with use of UUID as "unique strings" in XMPP
seems a bit weird to me. The hex-encoding with dashes and version
information is far away from an efficient encoding of 122 bits of
randomness. The only reason we started with UUIDs was that previously,
clients did not use actual randomness to generate message ids, thereby
causing collisions. Using a UUIDv4 became a way for a client to signal
to other clients "my ids are actually random and collision free". This
probably will remain relevant for message/iq ids in the future, but it
is not for any other ids.

Which brings me to the conclusion: If we want to gauarantee a certain
amount of randomness in any id field, we should just state exactly
that, e.g. "the id SHOULD include at least 120 bits of randomness, for
example by using an UUIDv4" (and then we might see people in the wild
just encode 15 random bytes using base64, saving 16 bytes on the wire
with every id).

Marvin


On Thu, 2023-01-05 at 11:18 +0100, Florian Schmaus wrote:
> 
> On 05/01/2023 10.51, Dave Cridland wrote:
> > * The argument that this doesn't need a namespace bump is wrong
> > because 
> > "experimental" has no effect here. The entire point of those
> > 'versioned' 
> > namespaces was to ensure that we could freely implement
> > Experimental 
> > XEPs without worrying about causing compatibility nightmares. The 
> > argument that there's no implementation is counter-productive - if 
> > there's nobody implementing, then by definition it doesn't matter
> > if you 
> > bump the namespace.
> 
> +1
> 
> I see a recent trend in the community that it is acceptable to
> introduce 
> backwards incompatible changes in 'experimental' XEPs. I think we are
> moving along a dangerous path if this trend continues.
> 
> However, I believe that this trend is part a symptom of a larger 
> problem. Namely that we e are missing a workflow where people can
> work 
> together on a standards document, while implementing what is
> described 
> in that document and still be able to react agile regarding protocol 
> changes. The latter means, amongst other things, being able to
> introduce 
> backwards incompatible changes without a namespace bump.
> 
> I become more and more convinced that we may be better with an IETF
> I-D 
> / RFC style standardization process. Where an I-D is a mutable,
> living 
> document on the road to become an immutable RFC.
> 
> 
> > * In general, I think ids expected to be reasonably unique ought to
> > be 
> > UUIDv4. I mean, why not? But I'm hesitant to mandate this
> > absolutely, 
> > such as in this change, because although I'd like *senders* to
> > always 
> > use a UUIDv4, I'm a bit concerned about *receivers* making that 
> > assumption, and trying to parse out a UUIDv4 and storing it in a
> > 128-bit 
> > number or something. In some cases, that'd be a handy thing (I've
> > done 
> > this internally with MAM identifiers, for example), but I think we 
> > should be very careful about when this is the right choice.
> > 
> > So, I'd suggest "SHOULD" here at most, and I might choose to phrase
> > it 
> > as "RECOMMENDED", which has the same RFC 2119 meaning, but somewhat
> > different implicit meaning in English.
> 
> I also would prefer this approach. Simply because I believe that MUST
> should only be used when it is strictly necessary. In this case, it 
> appears to be enough to just say the requirements of the ID value and
> recommend (as in suggest) implementations to use UUIDv4. Unless I am 
> missing a a reason the protocol absolutely requires UUIDv4 and would 
> break otherwise?
> 
> - Flow
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0353 propose id syntax

[Florian Schmaus]

On 05/01/2023 10.51, Dave Cridland wrote:
* The argument that this doesn't need a namespace bump is wrong because 
"experimental" has no effect here. The entire point of those 'versioned' 
namespaces was to ensure that we could freely implement Experimental 
XEPs without worrying about causing compatibility nightmares. The 
argument that there's no implementation is counter-productive - if 
there's nobody implementing, then by definition it doesn't matter if you 
bump the namespace.


+1

I see a recent trend in the community that it is acceptable to introduce 
backwards incompatible changes in 'experimental' XEPs. I think we are 
moving along a dangerous path if this trend continues.


However, I believe that this trend is part a symptom of a larger 
problem. Namely that we e are missing a workflow where people can work 
together on a standards document, while implementing what is described 
in that document and still be able to react agile regarding protocol 
changes. The latter means, amongst other things, being able to introduce 
backwards incompatible changes without a namespace bump.


I become more and more convinced that we may be better with an IETF I-D 
/ RFC style standardization process. Where an I-D is a mutable, living 
document on the road to become an immutable RFC.



* In general, I think ids expected to be reasonably unique ought to be 
UUIDv4. I mean, why not? But I'm hesitant to mandate this absolutely, 
such as in this change, because although I'd like *senders* to always 
use a UUIDv4, I'm a bit concerned about *receivers* making that 
assumption, and trying to parse out a UUIDv4 and storing it in a 128-bit 
number or something. In some cases, that'd be a handy thing (I've done 
this internally with MAM identifiers, for example), but I think we 
should be very careful about when this is the right choice.


So, I'd suggest "SHOULD" here at most, and I might choose to phrase it 
as "RECOMMENDED", which has the same RFC 2119 meaning, but somewhat 
different implicit meaning in English.


I also would prefer this approach. Simply because I believe that MUST 
should only be used when it is strictly necessary. In this case, it 
appears to be enough to just say the requirements of the ID value and 
recommend (as in suggest) implementations to use UUIDv4. Unless I am 
missing a a reason the protocol absolutely requires UUIDv4 and would 
break otherwise?


- Flow
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] XEP-0353 propose id syntax

[Dave Cridland]

On a Github PR XEP-0353: Add requirement for UUID v4 for id attributes by
tmolitor-stud-tu · Pull Request #1262 · xsf/xeps · GitHub
, Thilo wrote:

> I think explicit is better than implicit, hence this PR.

> Since v0.4 of this XEP isn't implemented by any client yet (to my
knowledge) and because the XEP is still experimental, I think we can do
this update without bumping the namespace.
What do you thing @fippo  @stpeter
 ?


[Aside: Having been bitten by conversations happening off the list, and
therefore with less visibility than I (at least) would like, I'm dragging
this conversation back to the list]

The suggestion here is that the `id` field should be defined as being a
UUIDv4, mandatorily.

Also, that this doesn't need a namespace bump.

I think both of these are wrong:

* The argument that this doesn't need a namespace bump is wrong because
"experimental" has no effect here. The entire point of those 'versioned'
namespaces was to ensure that we could freely implement Experimental XEPs
without worrying about causing compatibility nightmares. The argument that
there's no implementation is counter-productive - if there's nobody
implementing, then by definition it doesn't matter if you bump the
namespace.

* In general, I think ids expected to be reasonably unique ought to be
UUIDv4. I mean, why not? But I'm hesitant to mandate this absolutely, such
as in this change, because although I'd like *senders* to always use a
UUIDv4, I'm a bit concerned about *receivers* making that assumption, and
trying to parse out a UUIDv4 and storing it in a 128-bit number or
something. In some cases, that'd be a handy thing (I've done this
internally with MAM identifiers, for example), but I think we should be
very careful about when this is the right choice.

So, I'd suggest "SHOULD" here at most, and I might choose to phrase it as
"RECOMMENDED", which has the same RFC 2119 meaning, but somewhat different
implicit meaning in English.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___