Re: [Standards] Proposed XMPP Extension: Channel Binding Pseudomechanisms

On Thu, May 7, 2020, at 15:49, Florian Schmaus wrote: > I am sure we do not need an version bump for this. The information of > falls into the category "additional > information that is nice to have but not (strictly) required". We > extend existing elements by new elements or attributes without

Re: [Standards] Proposed XMPP Extension: Channel Binding Pseudomechanisms

On 5/7/20 9:09 PM, Sam Whited wrote: > On Thu, May 7, 2020, at 13:11, Florian Schmaus wrote: >> I did, at first. It is totally irrelevant if it is an extra stream >> feature or not. This just seemed a little bit more esthetic. > > I disagree, it's very relevant. We can discuss both, but how

Re: [Standards] Proposed XMPP Extension: Channel Binding Pseudomechanisms

On Thu, May 7, 2020, at 13:11, Florian Schmaus wrote: > I did, at first. It is totally irrelevant if it is an extra stream > feature or not. This just seemed a little bit more esthetic. I disagree, it's very relevant. We can discuss both, but how things work and are implemented may be entirely

Re: [Standards] Proposed XMPP Extension: Channel Binding Pseudomechanisms

On 5/7/20 6:34 PM, Sam Whited wrote: > On Thu, May 7, 2020, at 12:21, Florian Schmaus wrote: >> That the remote entity, the server in c2s, supports those particular >> channel binding types. > > Okay, I assumed you meant that this would be a separate stream feature, > but from the examples you

Re: [Standards] Proposed XMPP Extension: Channel Binding Pseudomechanisms

On Thu, May 7, 2020, at 12:21, Florian Schmaus wrote: > That the remote entity, the server in c2s, supports those particular > channel binding types. Okay, I assumed you meant that this would be a separate stream feature, but from the examples you gave it doesn't seem like that's what you're

Re: [Standards] Proposed XMPP Extension: Channel Binding Pseudomechanisms

On 5/6/20 7:05 PM, Sam Whited wrote: > I thought about something like this but it wasn't clear to me what > negotiating channel binding would even mean. That the remote entity, the server in c2s, supports those particular channel binding types. > It also means that we have > more state to keep

Re: [Standards] form field types: text-multi vs list-multi with

On 5/5/20 12:35 PM, Matthew Wild wrote: > On Sat, 2 May 2020 at 21:29, Florian Schmaus > wrote: > > So why go for the slightly more complicated semantic of > list-multi+, when we could just go with text-multi? > > > We covered this somewhat in the MUC since

Re: [Standards] XEP-0289 FMUC: Do joined nodes know what mode is configured?

I've had some one-on-one conversations which lead me to believe that expecting the joined FMUC node to echo a stanza back in master-slave mode, but not in master-master mode, is something that's not adequately covered in the XEP. Assuming that this indeed is an oversight, I'd like to work towards

Re: [Standards] Proposed XMPP Extension: Channel Binding Pseudomechanisms

On Wed May 6, 2020 at 8:19 PM CEST, Sam Whited wrote: > On Wed, May 6, 2020, at 18:03, Dave Cridland wrote: > > The TL;DR is "horrible syntax, but really useful idea". … So, I would > > love to see this problem tackled properly, but without a syntax that > > involves me wanting to stab myself in