XMPP Council - 2020-04-22

1) Roll Call

Hi

SYN

ACK

FIN

also, no TCP in multicast

2) Agenda Bashing

RST RST RST

this one’s a long one, anything to modify?

TL;DR, sorry :(

3) Editor’s Update - Expired calls: None - Calls in progress: None - New ProtoXEP: Quick Response - New ProtoXEP: Best practices for password hashing and storage

4) Items for voting

looks good, but I haven't even catched up with previous on-lists

s/catched/caught/ scnr

4a) Proposed XMPP Extension: Best practices for password hashing and storage URL: https://xmpp.org/extensions/inbox/password-storage.html Abstract: This document outlines best practices for handling user passwords on the public Jabber network for both clients and servers.

do you folks think this is a matter the XSF should handle?

that’s my primary question with this one

As Dave says, it would fit with IETF / Kitten

someone said on list (was it the author?) that we can start this of with the xsf and if it gets replaced by something else that's fine

and i agree

it doesn’t concern wire protocol, it concerns interop to some extent (but not beyond things applying to all things SASL)

so +1

daniel, very good point, I like it

I think that the XSF is not the right place for recommendations for "the public Jabber network", but other than that it's probably a good place for public-server recommendations

I follow daniel with the +1

+1

+1

Thanks

4b) Proposed XMPP Extension: Quick Response URL: https://xmpp.org/extensions/inbox/quick-response.html Abstract: Quickly respond to automated messages.

let’s make this a quick response: I’m +1 on that ✏

That looks vaguely familiar.

it does

+1

+1

though I’d like to note (cc @ MattJ ) that I agree that actions and responses should maybe be merged on the wire layer, and a flag should indicate a switch between the "virtual keyboard" or "persistent actions" mode

Can it be fixed in Experimental?

(spoiler: I don't think so, but I'd like to discuss details if/when it is accepted)

anything is possible in Experimental

Syndace, I’m not hard-sold on either way, if there’s a good rationale in the document which explains why a split is sensible, I’m fine with that

FWIW I got hooked by Daniel's mention of spinners for actions, so... we'll see

Yeah, I think the reasons will be a little clearer after I've incorporated the feedback I got in the past days.

(this could be another optional flag for response type)

Ge0rG, are you staying with your intent to vote on-list on this one?

Is there any merit in considering 'forms2' here?

a quick +1 in the hope to catch up with the thread before it expires or bad things happen

hi Kev

Kev, I don’t think so

If people don't want to use forms because they're terrible, rather than solving a subproblem, using to to start work on a thing that isn't terrible?

Kev: after the protoxep has been accepted then :)

not blocking this one to reproduce what happened with reactions

I think we need to stop over-engineering the simple things

Kev, I've no objection to people working on forms2, but I have objection to delaying otherwise fine protocols because there is a dream of something better that might be finished in a couple of years

The XEP might just end up specifying how to conveniently use forms to achieve what is done with different elements now.

The use case doesn't call for forms at all

the discussion about a potential '4 replacement should be taken to xsf@ please, we have a tight agenda today

(note that I'm not particularly in favour of quick response, I don't mind, I'm just bitter re reactions)

4c) PR#935: XEP-0004: clarify that the submitting entity may omit optional fields URL: https://github.com/xsf/xeps/pull/935 Description: It is not really spelled out that the submitting entity may omit fields not mark as required by the processing entity. Even though the existence of the flag on form fields is a strong hint towards this, it is worth to explicitly state that.

+1

I don’t see how this could do harm. +1

+1

Observation: nobody really knows what omitting a field does in different contexts

wait. what will be the value of those fields if you leave them out?

daniel, up to the processing thing?

and thats good?

daniel, the "default"?

MUC doesn't define this, for example

the same as if you don't have the clarification in the XEP, I suppose

the default or the previous value?

defaults or previosu values depneding on if you're creating somethin new, or editing

daniel, it doesn’t change the logic of the document.

it was implicitly there already that fields which aren’t marked as <required/> can be omitted

mhh ok. +1

Tho I believe at least one implementation will reject forms if they're missing <fields>

<required/> This element, which MUST be empty, flags the field as required in order for the form to be considered valid.

taking the reverse of that, a field without <required/> does not need to be present

I don't think you can fix 4 without a certain amount of discomfort. It's underspecified in both the core and its uses, and trying to deal with it is a mess. This seems like low hanging fruit with relatively little pain, to me.

Kev, is this about 4c, or still about Quick Responses / forms2?

jonas’: The PR.

if the latter, please save it for after the meeting in xsf@. if the former, I don’t quite see how it’s connected.

MattJ observed that no-one knows what optional fields mean.

the PR is just a clarification of something which is defined elsewhere, but not spelt out clearly; I don’t see how your comment is relevant, but I’m tired, so maybe that’s that.

I said that any improvement to '4 is going to have uncomfortable questions, but this one seems to be fairly painless, and helps.

ah, yeah, that

I agree

thanks for clarifying

I'm not council, but I'm in favour of the change under discussion. I just don't think it resolves anything in practice.

MattJ, I agree with that, too.

but I’m not going to stand in the way of making our documents more accessible by spelling things out in clear statements instead of having to reverse-logic something

and with that, moving on

4d) PR#926: XEP-0045: Clarify that the 307 status code should not be used alongside 333 for user disconnects URL: https://github.com/xsf/xeps/pull/926 Description: Per discussion in xsf@ about the UX implications of showing user disconnects as kicks.

+1

+1

+1

+1

4e) Start Last Call on XEP-0320: Use of DTLS-SRTP in Jingle Sessions URL: https://xmpp.org/extensions/xep-0320.html Abstract: This specification defines how to use DTLS-SRTP (RFC 5763) in the Jingle application type for the Real-time Transport Protocol (RTP) as a way to negotiate media path key agreement for secure RTP in one-to-one media sessions.

4d) is 'recommended' the right word here, given confusion with SHOULD?

+1

re 4e: +1, due to the recent influx of jingle things, I expect some feedback there actually

Kev, thanks, I’ll let the editors know

+1

+1

4f) Start Last Call on XEP-0339: Source-Specific Media Attributes in Jingle URL: https://xmpp.org/extensions/xep-0339.html Abstract: This specification provides an XML mapping for translating the RFC 5766 Source-Specific Media Attributes from SDP to Jingle

again, +1

+1

+1

+1

Secret hidden agendum: 4g) PR#934: XEP-0167: add rtcp-mux element URL: https://github.com/xsf/xeps/pull/934 Description: RTCP-muxing is used in WebRTC. This element is actually used in the wild by clients like Siskin and Movim (and soon Conversations)

on-list

+1

+1

nevermind, +1

doesn't that affect backward compat?

it's an optional element

so probably not?

in the same namespace though

some ~people~ parsers are picky about that

MAY and addition should be mostly fine?

Unless you're doing ultra strict schema validation

well we can introduce the feature for it

see the comment

if that makes people feel better

but in practice i wouldn’t be worried about it

most implementations i saw send this

that's how i even learned about that field

by sending it you tell the other party that you support it?

hm, writing down that a feature is to be announced -- even if in practice noone cares -- would be good for clarity ✏

apparently down to the original google jingle

Seems fine then

but yeah, not going to insist on this

+1 with the PR as-is

I wonder if we have a Jingle SIG we could solicit reviews from

we have a few people involved with jingle, but I think at least one of them already commented on the PR

Yeah

daniel: does the responder need to somehow acknowledge use of <rtcp-mux/> or is it implied by how the connection is established?

Ge0rG, they can or can’t put that into their counter offer

that’ll negotiate nicely without any additional feature flags then

if they don’t know it, they can simply ignore it

yeah

5) Pending Votes

everyone is pending on Room Activity Indicators according to my notes (but I haven’t checked the ML yet)

anyone want to cast votes now?

not me

we’re over time anyways

and nothing expires

so moving on

6) Date of Next

+1w wfm

+1w wfm

+1w wfm

7) AOB Unless someone speaks up with an urgent AOB in the next 30s, I’m going to cut this.

+1W WFM

8) Ite Meeting Est

Thanks all

Thanks everyone for managing this long agenda without any on-list vote.

Thanks Tedd :)