3) Editor’s Update
- Expired calls: None
- Calls in progress: None
- New ProtoXEP: Quick Response
- New ProtoXEP: Best practices for password hashing and storage
jonas’
4) Items for voting
Ge0rG
looks good, but I haven't even catched up with previous on-lists
jonas’
s/catched/caught/ scnr
jonas’
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.
jonas’
do you folks think this is a matter the XSF should handle?
jonas’
that’s my primary question with this one
Zash
As Dave says, it would fit with IETF / Kitten
daniel
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
daniel
and i agree
jonas’
it doesn’t concern wire protocol, it concerns interop to some extent (but not beyond things applying to all things SASL)
daniel
so +1
jonas’
daniel, very good point, I like it
Ge0rG
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
let’s make this a quick response: I’m +1 on that ✏
Ge0rG
That looks vaguely familiar.
jonas’
it does
daniel
+1
Zash
+1
jonas’
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
Zash
Can it be fixed in Experimental?
susmit88has left
Syndace
(spoiler: I don't think so, but I'd like to discuss details if/when it is accepted)
jonas’
anything is possible in Experimental
jonas’
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
MattJ
FWIW I got hooked by Daniel's mention of spinners for actions, so... we'll see
Syndace
Yeah, I think the reasons will be a little clearer after I've incorporated the feedback I got in the past days.
MattJ
(this could be another optional flag for response type)
jonas’
Ge0rG, are you staying with your intent to vote on-list on this one?
Kev
Is there any merit in considering 'forms2' here?
Ge0rG
a quick +1 in the hope to catch up with the thread before it expires or bad things happen
Ge0rG
hi Kev
jonas’
Kev, I don’t think so
Kev
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?
pep.
Kev: after the protoxep has been accepted then :)
pep.
not blocking this one to reproduce what happened with reactions
jonas’
I think we need to stop over-engineering the simple things
MattJ
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
Syndace
The XEP might just end up specifying how to conveniently use forms to achieve what is done with different elements now.
MattJ
The use case doesn't call for forms at all
jonas’
the discussion about a potential '4 replacement should be taken to xsf@ please, we have a tight agenda today
pep.
(note that I'm not particularly in favour of quick response, I don't mind, I'm just bitter re reactions)
jonas’
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.
bearhas left
Ge0rG
+1
jonas’
I don’t see how this could do harm. +1
Zash
+1
MattJ
Observation: nobody really knows what omitting a field does in different contexts
daniel
wait. what will be the value of those fields if you leave them out?
Zash
daniel, up to the processing thing?
daniel
and thats good?
jonas’
daniel, the "default"?
MattJ
MUC doesn't define this, for example
Ge0rG
the same as if you don't have the clarification in the XEP, I suppose
daniel
the default or the previous value?
Zash
defaults or previosu values depneding on if you're creating somethin new, or editing
jonas’
daniel, it doesn’t change the logic of the document.
jonas’
it was implicitly there already that fields which aren’t marked as <required/> can be omitted
daniel
mhh ok. +1
Zash
Tho I believe at least one implementation will reject forms if they're missing <fields>
jonas’
<required/>
This element, which MUST be empty, flags the field as required in order for the form to be considered valid.
jonas’
taking the reverse of that, a field without <required/> does not need to be present
Kev
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.
jonas’
Kev, is this about 4c, or still about Quick Responses / forms2?
Kev
jonas’: The PR.
jonas’
if the latter, please save it for after the meeting in xsf@. if the former, I don’t quite see how it’s connected.
Kev
MattJ observed that no-one knows what optional fields mean.
jonas’
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.
Kev
I said that any improvement to '4 is going to have uncomfortable questions, but this one seems to be fairly painless, and helps.
jonas’
ah, yeah, that
jonas’
I agree
jonas’
thanks for clarifying
MattJ
I'm not council, but I'm in favour of the change under discussion. I just don't think it resolves anything in practice.
jonas’
MattJ, I agree with that, too.
jonas’
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
jonas’
and with that, moving on
jonas’
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.
jonas’
+1
Zash
+1
daniel
+1
Ge0rG
+1
jonas’
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.
Kev
4d) is 'recommended' the right word here, given confusion with SHOULD?
daniel
+1
jonas’
re 4e: +1, due to the recent influx of jingle things, I expect some feedback there actually
jonas’
Kev, thanks, I’ll let the editors know
Ge0rG
+1
Zash
+1
jonas’
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
jonas’
again, +1
Ge0rG
+1
Zash
+1
daniel
+1
jonas’
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)