XSF Discussion - 2022-09-21

What is the recommended way to update an experimental XEP? Like changing something REQUIRED to OPTIONAL and stuff like that? Can it just be updated? Should it be discussed on the mailing list?

are you the author?

yes

most people would probably just update it

alright :)

If it's one of those widely implemented but still experimental ones, I definitely recommend at least notifying the list about the planned changes

If it's just something that has sat idle with no implementations and you're trying to revive it, just go for it

i don't know of any SIMS implementation

Well, doesn't hurt to post to the list and find out :)

true will do that ✏

Tobias, I wrote one for Dino once, but they left it bitrot for e2ee reasons IIRC.

Tobias, are you aware of XEP-0447?

yes

Link Mauve, it's mostly about dropping the REQUIREMENT for description in the info and making it OPTIONAL, as UX wise it seems horrible to require a description for each attachment

Tobias, what are your thought about SIMS vs. XEP-0447?

fwiw, I don't like breaking changes of experimental xeps without namespace bumps. Tobias: do you plan to bump?

flow, this sounds minor enough tbh, I doubt any existing implementation will break on the description not being filled.

Tobias, OTOH, it’s quite useful to ask senders to provide basically an @alt text for accessibility reasons.

i think the main differences are 1. ( using Out-of-Band Data (XEP-0066) instead of References for referring to URLs and passing the jingle ID via XML instead of URI) and 2. not using references and mixed content. The instruction make it appear there are more significant differences but I think it boils down to not using references (which I can understand). Having File Info in a dedicated XEP is certainly useful. But if that's only used by a single XEP there is little value to have it distinct.

Link Mauve, well if something was previously required and now suddenly is not, then implementations could be expected that enforce the existing of the (previously) required data

yeah..i was wondering whether to bump the namespace or not...if there were others implementing it i'd say sure...but if not and it's just experimental anyway ✏

Tobias, a future version of XEP-0234 should certainly use 0446 as well.

yup

it's just experimental is rarely a good justification, it has been out there for a long time

flow, while you are here. After having implemented XEP-0440: SASL Channel-Binding Type Capability I think the <sasl-channel-binding/> element should become a direct stream feature instead of a child of sasl2 mechanisms. sasl 2 and sasl 1 will co-exist for quite a while and this removes the overhead of having to announce it twice

Tobias, I think Movim was another implementation.

in any case, we should agree on some rules (even if those are rules I personally do not agree with) and explicitly spell them out

probably makes sense to write to the ML to see if there are other implementations and ask if there are other things people feel that need updating in the XEP

Daniel, ahh I remember MattJ contacting me with the same: personally I wouldn't design it that way, I wonder if we couldn't do something like: if both sasl1 and sasl2 are there, then the channel binding information may appear only in one element

lol that's worse

that way, if we ever reach a state of sasl2 only, it will be a part of sasl2 element

Daniel, personally I think it is worse to not bundle an element which is absolutely related to sasl, not to sasl

that is, you will never have a channel-binding element without a sasl element

It's not *necessarily* strictly related to SASL

and it's definitely shared between all SASL versions

MattJ, could you elaborate how channel binding is not related to sasl?

But if we (for some weird reason) came up with some non-SASL authentication protocol that could also take advantage of channel binding, it could easily apply to that too

that appears to be a far fetched argument

Supported channel binding methods are properties of something that is actually not the SASL implementation in reality

At least today they are mostly properties of the TLS layer

So it seems perfectly natural to me to say "this is what the server supports" outside of any specific SASL protocol

sasl1 going away is simply not very realistic. and I much prefer the bandwidth saving over any perceived syntactical cleanliness ✏

SASL1 is definitely not going anywhere any time soon, but there will be SASL2-only servers (I plan this for Snikket, for example)

It's unnecessarily complex for clients to have to check multiple places for the same info

and it's an unnecessary waste of bytes to duplicate the exact same info for no reason

that last one is easily agreeable :)

I don't have a super strong opinion on that. it doesn't appear to be super complex to lookup the sasl-channel-binding information in two places, but if this is to much to ask from client developers then we can put it into the stream:features root ✏

This is how I implemented it in Prosody as soon as I added SASL2 support, and multiple client developers independently arrived at the same conclusion. I definitely think it's the best option, and doesn't have any downsides.

> This is how I implemented it in Prosody as soon as I added SASL2 support, and multiple client developers independently arrived at the same conclusion. I definitely think it's the best option, and doesn't have any downsides. 👍

flow, do you want me to create a PR with those changes?

sure, go ahead

flow, your own xeps calls them stream-features https://xmpp.org/extensions/xep-0440.html

:-)

but I can change all of them if you want?

i don’t know the difference but I've applied your suggested changes

Daniel, the existing ones are multiple-word adjectives that are hyphenated ✏

thanks

What is an appropriate way to provide feedback of a certain proprietary characteristic of a newly established stream in S2S? I was thinking of broadcasting a customer stream feature, but that's mostly aimed at negotiating things, which isn't really the case here. Service Discovery?

Stream features can be used for things that aren't negotiation, for example servers can provide caps hashes there

So if what you want to advertise is a feature of the stream, I think that's fine

If it's a feature of the server or the account, disco#info is also fine

it specifically relates to a stream

Thanks

Then it sounds like a stream feature is the way

Re caps hashes, XEP-0390 has a way to advertise those directly on the stream, see example 4.

Yeah, that's what I was referring to

Did it have a way to advertise caps hashes of e.g. components etc?

jcbrand, MattJ, arc around?

o/

On a call atm

MattJ: no matter. Are there any topic we need to discuss soonish?

s

ralphm, I don't think there is anything urgent on my radar. I did want to raise something: there is an IETF meeting coming up in London, and it is looking likely that there will be a BoF for the new messaging interoperability working group that folk are trying to get started. I was wondering if the XSF would be able to support my attendance expenses. I don't *think* this has been done traditionally, but I'm self-employed and don't work for $<big corp>, and yet I think my attendance would be valuable to the XSF.

When is it?

November

Ok, so 1) yes, I think the XSF should support that, 2) I might also go

Double yay :)

I would support such expense refunds, even I cannot decide on this. I think it worth to show we are interested and present

IIRC the XSF covered me when I went to IETF in London

👍👍👍

I would also suggets to call for input/questions from the community

I haven't really read up on this WG, yet, but that seems reasonable. That said, everyone can participate in IETF meetings remotely, too.

The BoF request is still pending, here: https://datatracker.ietf.org/doc/bofreq-cooper-more-instant-messaging-interoperability/

I participated in the IETF 114 session remotely. It was... terrible.

That was mostly because it was in a room not set up for remote participation, and hopefully that won't be the case this time around if it gets approved

Hi

Sounds like a good idea 👍

I guess that settles it

> https://datatracker.ietf.org/doc/bofreq-cooper-more-instant-messaging-interoperability/ it's quite amusing, although probably not surprising, that the only occurance of the word 'matrix' on that page is not a proper noun, but refers to the same concept that gave Matrix its proper noun :)