jonas’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
Ge0rGlooks good, but I haven't even catched up with previous on-lists
jonas’4a) Proposed XMPP Extension: Best practices for password hashing and storage
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
ZashAs Dave says, it would fit with IETF / Kitten
danielsomeone 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
danieland i agree
jonas’it doesn’t concern wire protocol, it concerns interop to some extent (but not beyond things applying to all things SASL)
jonas’daniel, very good point, I like it
Ge0rGI 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
jonas’let’s make this a quick response: I’m +1 on that
Ge0rGThat looks vaguely familiar.
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
ZashCan it be fixed in Experimental?
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
MattJFWIW I got hooked by Daniel's mention of spinners for actions, so... we'll see
SyndaceYeah, 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?
KevIs there any merit in considering 'forms2' here?
Ge0rGa quick +1 in the hope to catch up with the thread before it expires or bad things happen
jonas’Kev, I don’t think so
KevIf 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
MattJKev, 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
SyndaceThe XEP might just end up specifying how to conveniently use forms to achieve what is done with different elements now.
MattJThe 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
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.
jonas’I don’t see how this could do harm. +1
MattJObservation: nobody really knows what omitting a field does in different contexts
danielwait. what will be the value of those fields if you leave them out?
Zashdaniel, up to the processing thing?
danieland thats good?
jonas’daniel, the "default"?
MattJMUC doesn't define this, for example
Ge0rGthe same as if you don't have the clarification in the XEP, I suppose
danielthe default or the previous value?
Zashdefaults 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
danielmhh ok. +1
ZashTho I believe at least one implementation will reject forms if they're missing <fields>
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
KevI 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?
Kevjonas’: 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.
KevMattJ 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.
KevI 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’thanks for clarifying
MattJI'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
Per discussion in xsf@ about the UX implications of showing user disconnects as kicks.
jonas’4e) Start Last Call on XEP-0320: Use of DTLS-SRTP in Jingle Sessions
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.
Kev4d) is 'recommended' the right word here, given confusion with SHOULD?
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
jonas’4f) Start Last Call on XEP-0339: Source-Specific Media Attributes in Jingle
Abstract: This specification provides an XML mapping for translating the RFC 5766 Source-Specific Media Attributes from SDP to Jingle
jonas’Secret hidden agendum:
4g) PR#934: XEP-0167: add rtcp-mux element
Description: RTCP-muxing is used in WebRTC. This element is actually used in the wild by clients like Siskin and Movim (and soon Conversations)