Re: [Standards] XEP-0444 update: restrict reactions

[Nicolas Cedilnik]

Thanks for the feedback.
I suspect that in most instances, you're happy to accept any 
reactions, and forcing a poll of available ones before that would be 
unhelpful,
My earlier iteration of the PR did include a mechanism to fetch the 
available emojis (and rules, eg 1 emoji per reacter per message), but 
after discussion with Marvin (author), we decided that it's a bad idea, 
since, as you said, most instances are probably happy to accept any 
reactions.

blindly sending and seeing if they stick.


This is the current behavior described in this patch indeed. At the very 
least, this PR clarifies what clients should do when they receive an 
error after sending a reactions payload. I believe that the default 
behavior would be "revert to previous reactions state" but we made it 
"reset reactions to null" instead.


Would it work to advertise a disco feature of 'limited-reactions' so 
that e.g. a MUC that's going to filter such things could advertise the 
feature, and clients would know they need to fetch first, and 
otherwise wouldn't need to bother?


Outside of a gateway context, this is probably something that should be 
configurable by room admins, so wouldn't it be better as a muc#config 
field? Clients supporting it can adapt their UIs accordingly, and 
clients that don't can at least not display a bogus reaction state by 
taking into accounts the  they receive when trying to send a 
forbidden reaction payload.


-- Nicoco


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

Re: [Standards] NEW: XEP-0474 (SASL SCRAM Downgrade Protection)

[Thilo Molitor]

Yeah, that discussion in the summer was really long, but much appreciated by 
me!

The SSDP XEP mainly tries to fill the gap described in XEP-0440 Security 
Considerations [0]:
> If a client signals to the server that he does not support channel binding, 
because it found no mutual supported channel-binding types, another MITM 
attack vector is introduced. An active attacker could replace the  list with channel bindings unlikely (or impossible) to be 
supported by the client. If the client is configured to use non-channel-binding 
SASL mechanisms as a fallback, this could be used to downgrade the connection 
security. Note that this attack is a different one than the SASL-mechanism 
stripping one: Here the attacker tempers with the announced channel-binding 
types, i.e., the values within 

XEP-0440 suggests pinning the channel-binding. That could have negative side 
effects and prevent successful connections by clients, if the server operator 
decides to change the channel-binding mechanism (for example by downgrading 
from tls-exporter to tls-server-end-point because his server got big enough to 
need extra TLS termination/load balancing).

XEP-0474 tries to solve these problems without introducing the negative side 
effects of pinning. But it requires the server operator to disable SASL PLAIN.
(I'd argue most server operators not depending on an LDAP backend or somesuch 
could disable SASL PLAIN.)

> And if this isn't making things better, are we better off talking about
> clients latching on preferred mechanisms?
No, latching on some mechanisms does not make things better, see above.
It is some sort of last resort, if you can't come up with something better.
But XEP-0474 *is* better. It avoids all the problems with pinning, only 
introducing a dependency of not using/providing SASL PLAIN. But you already 
should not use/provide that if you can avoid it.
That's even suggested in § 13.8.3 of RFC 6120.

> Out of curiosity, if we were to say that the mechanisms and TLS channel
> bindings stream features were repeated after the authentication (perhaps as
> actual stream features, but more sensibly somewhere else -  and
>  possibly?) would this satisfy the requirements better?
> Differently? Not at all?
The goal of XEP-0474 is to cryptographically secure the XEP-0440 channel-
binding list even in the presence of a TLS-MITM.
When sending the list again after authentication, a TLS-MITM able to survive 
the authentication by advertising some fictional channel-binding types not 
supported by the client to force it to not use channel-binding (and otherwise 
only relaying the SCRAM authentication messages) will be able to intercept and 
change the channel-binding list sent after authentication, too.
You can send the channel-binding list as often as you want, you can't change 
that.
By using the SCRAM (and later on OPAQUE) cryptography we essentially can bind 
the tls channel-binding list offered by the server to the knowledge of the 
SCRAM password, efficiently detecting the TLS-MITM.

By the way: I already tried to explain some of the rationale behind this XEP 
in great detail on this list [1], too.

-tmolitor

[0] https://xmpp.org/extensions/xep-0440.html#security
[1] https://mail.jabber.org/pipermail/standards/2022-October/039025.html





Am Freitag, 30. Dezember 2022, 11:35:48 CET schrieb Dave Cridland:
> On Tue, 13 Dec 2022 at 18:04, Jonas Schäfer  wrote:
> > Version 0.1.0 of XEP-0474 (SASL SCRAM Downgrade Protection) has been
> > released.
> 
> I had a long discussion off-list with Thilo on this, and I broadly think it
> has very little utility - at best, you can tell if you've been downgraded
> *to* a SCRAM-family mechanism, but one that is still considered secure
> (since otherwise the attacker could trivially forge the ssdp SCRAM
> attribute). So this surely only detects a downgrade when the downgrade
> hasn't been successful. No?
> 
> Out of curiosity, if we were to say that the mechanisms and TLS channel
> bindings stream features were repeated after the authentication (perhaps as
> actual stream features, but more sensibly somewhere else -  and
>  possibly?) would this satisfy the requirements better?
> Differently? Not at all?
> 
> And if this isn't making things better, are we better off talking about
> clients latching on preferred mechanisms?


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

[Standards] Pending SASL2 PRs

[Thilo Molitor]

Since PR #1214 [0] (SASL2, XEP-0388) got finally approved by Dave, I want to 
bring some follow-up PRs to your attention:

1.) PR #1248 [1]: Overhaul SCRAM Upgrade ProtoXEP to include definition of 
SASL2 upgrade tasks.
This ProtoXEP defines SASL2 upgrade tasks.
I originally added these to SASL2 directly, but Dave convinced me that they 
belong in an extra XEP. This ProtoXEP defines a concrete upgrade task for 
SCRAM, too. If requested, I could split the concrete SCRAM upgrade tasks into 
a third ProtoXEP, if wanted, but given that the upgrade tasks XEP isn't that 
big, I'd rather don't split these.
If I recall correctly, this ProtoXEP hasn't been voted on by council.

2.) PR #1215 [2]: XEP-0198: Add section defining SASL2 and BIND2 interaction
This is an update to XEP-0198 to include some sections explaining interaction 
between XEP-0198 and SASL2/BIND2.
If I recall correctly, council already voted on this change under the 
precondition that PR #1214 is merged/published.

3.) PR #1217 [3]: XEP-0386: New revision v0.4.0
This is the BIND2 overhaul building upon the SASL2 changes in PR #1214.
As far as I know, authors already approved these changes, too. Therefore it 
should be merged/published once PR #1214 got published.

Sidenote: All of these PRs have been implemented in at least 3-4 FLOSS xmpp 
projects already.

-tmolitor

[0] https://github.com/xsf/xeps/pull/1214
[1] https://github.com/xsf/xeps/pull/1248
[2] https://github.com/xsf/xeps/pull/1215
[3] https://github.com/xsf/xeps/pull/1217



___
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] standardization process (was: Re: XEP-0353 propose id syntax)

[Florian Schmaus]

On 05/01/2023 16.31, Peter Saint-Andre wrote:

On 1/5/23 3:18 AM, Florian Schmaus wrote:

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.


You know, we could move all of our activities to an IETF Working Group...


I would not want to replace our document tooling with xml2rfc. I really 
like what we have to produce high quality publishable standards documents.



It is really just the process that needs to change. My idea is as follows:

Introduce an I-D-like incubating phase of ProtoXEPs. Everyone is able to 
create a new incubating ProtoXEP, no Council review required. The 
ProtoXEP is mutable at any time and there are no namespace bumps 
required for breaking protocol changes. But there are fixed revisions of 
incubating ProtoXEPs that can be referenced (akin to I-D revisions).


When the authors feel the ProtoXEP is ready for a council review they 
submit it. The council should check, amongst other things, if the 
specification is idiomatic XMPP (but ideally, such things are already 
taken core of in the incubating phase). Even if the council demands 
breaking changes to the specification it should be trivial to 
incorporate them, as specification was a moving target before anyway. If 
the authors oppose the changes, then they still have a document with a 
stable ID (and URL) to share, even if not blessed by the council and not 
a "real" XEP.


Once the council accepts a ProtoXEP and it becomes a XEP. And only the 
addition of editorial changes, clarifications, and implementation advice 
is allowed [1]. Namespace bumps are not allowed, but instead should be 
done via a new incubating XEP.


XEP states would cease to exists. But council may later elevate a XEP to 
become recommended and/or adds it to the compliance suite.



I've been thinking about such a change for a while (years). And I spoke 
with a few of you about it at various occasions. But this is the first 
time I wrote it on standards@ and I would appreciate any feedback.


- Flow

1: So it is different from an RFC, which is strictly immutable once 
published. The IETF has an errata process to pin information to an RFC 
after it was published.

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

Re: [Standards] XEP-0444 update: restrict reactions

[Kevin Smith]

-- Original Message --
From "Nicolas Cedilnik" 
To standards@xmpp.org
Date 30/12/2022 13:25:25
Subject [Standards] XEP-0444 update: restrict reactions


Hello all,

About https://github.com/xsf/xeps/pull/1249

My main reason for submitting a patch to this XEP is that most other walled garden IM 
networks are not as permissive when it comes to emoji reactions: most only allow 1 emoji 
per message per "reacter", some restrict the available emojis to a small subset 
of emojis. However, I think that it could also be useful in MUCs, where implementations 
may want to allow admins to use such restrictions.

My first draft had many issues, and after discussion on the github PR thread with marvin, I 
changed it to just mentioning that clients that send a reaction and then receive a  in return, should reflect that in their UI - removing all reactions 
from themselves to this message.

However, after further OOB discussion with marvin, we thought it might useful to add an 
additional "emoji correction" mechanism, in the form of a  element 
in the error payload.

With XMLove,


I suspect that in most instances, you're happy to accept any reactions, 
and forcing a poll of available ones before that would be unhelpful, as 
would blindly sending and seeing if they stick. Would it work to 
advertise a disco feature of 'limited-reactions' so that e.g. a MUC 
that's going to filter such things could advertise the feature, and 
clients would know they need to fetch first, and otherwise wouldn't need 
to bother?


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

[Standards] standardization process (was: Re: XEP-0353 propose id syntax)

[Peter Saint-Andre]

On 1/5/23 3:18 AM, Florian Schmaus wrote:

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.


You know, we could move all of our activities to an IETF Working Group...

Peter

___
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
___