XSF Discussion - 2021-06-02

`<xs:choice minOccurs='0'><xs:element ref='a'/><xs:element ref='b'/></xs:choice>`

Does this only allow <a/><a/> or also <a/><b/>?

I believe it's the latter, but would like a second opinion :)

I also think its the latter

Great

XMPP <3

I just opened this draft PR for XEP-0227: https://github.com/xsf/xeps/pull/1064

I'll post to the list, some reviewers would be nice

MattJ: for SCRAM storage, I'd recommend looking at https://datatracker.ietf.org/doc/html/rfc5803

I did

I used it as a reference, but I defined an XML mapping which I think simplifies it somewhat

How should we implement message reflection? #1: In XEP-0045: The service SHOULD reflect the message with the same 'id' that was generated by the client, to allow clients to track their outbound messages. If the client did not provide an 'id', the server MAY generate an 'id' and use it for all reflections of the same message. #2: On the Wiki page: 1) you recently sent a message to the MUC, AND 2) the received message is from your participant JID, AND I) the XEP-0359 origin ID matches (probably not a transport) OR II )the message ID matches (a nice MUC, but not required by the XEP) OR #3: In XEP-0359 They are also useful in the context of Multi-User Chat (XEP-0045) [2] conferences, as they allow to identify a message reflected by a MUC service back to the originating entity. When I understood well, we should use message-id (muc#stable_id) instead of XEP-0359. If we assume that the implementation follows #1, it will be possible to build message reflection based on message-id, only. The text in the wiki #2 should change the order of I) and II) or drop I) at all. ( I just talk about basic XMPP via MUC - without the idea to have stanzas forwarded my different servers etc. - where XEP-0359 may helpful.) Is this correct or did I misunderstood something?

You're right, practically all services take the muc#stable_id approach (jabber.org/M-Link used to be, and may currently still be, an exception)

This happened because originally XEP-0045 did not specify the behaviour, so that text about reflecting with the same id was added later on

Yes, I saw. But we should fix XEP-0359 and wiki as well?

In my opinion yes, and origin-id should be removed from the XEP

But last I knew the author disagreed :)

Maybe there are other use cases where it can be helpful.

But at least for MUC it will not

Maybe in IoT where messages get routed by lot of "things", each can att a origin-id ID.

s/att/add

I think having a mechanism allowing an originating entity to signal that it has assigned the given unique and stable ID to one an outgoing stanza could become handy. That said, the use origin-id use case for MUC is now gone and the XEP should reflect that.

DebXWoody, in that case you would use probably <stanza-id/>

test

MattJ, there are decent arguments against using the client ID

the client-supplied ID is not always unique

oh wait, but I guess that's what XEP-0359 is for

To be unique is an agreement which can be defined in origin-id and also in message-id. At the end of the day the client has to generated the id and as to make sure it's unique. Should be a problem - for both concepts.

Shouldn't be a problem

Until you have to trust hostile clients :)

DebXWoody, sure, you *could* have also a marker extension telling that the rfc id is globally unique (as opposed to unique within the scope of a single stream)