[Standards] Council Minutes 2020-05-27

Tedd Sterr teddsterr at outlook.com
Sun May 31 22:27:24 UTC 2020


https://logs.xmpp.org/council/2020-05-27?p=h#2020-05-27-32eaadaabdda84f4

1) Roll Call
Present: Daniel, Jonas, Zash, Dave
Not in Denmark: Georg

2) Agenda Bashing
Jonas notes that Fippo would like to Last Call XEP-0338 (Jingle Grouping Framework) and sees no reason it can't be added to today's agenda.

3) Editor's Update
* Calls in Progress
  - CFE for XEP-0050 (ends at 2020-06-09)
* Expired/Expiring calls:
  - LC for XEP-0393 (ended yesterday)

4a) Proposed XMPP Extension: SASL Channel-Binding Type Capability - https://xmpp.org/extensions/inbox/xep-sasl-cb-types.html
Dave notes this is a write-up of Florian's suggestion.

Dave: +1 (this is exactly what we were all saying we were happy with last week)
Zash: +1
Daniel: +1
Jonas: +1
Georg: [pending]

4b) PR #949 - Add status-addresses registrar entry - https://github.com/xsf/xeps/pull/949
Jonas notes the on-list discussion around this [1].

Dave: +1
Daniel: +1
Jonas: +1 (not certain this is a good place for that typo of info, but it doesn't harm)
Zash: +1
Georg: [pending]

Dave adds that there were suggestions of putting this in a DNS record or '.well-known' URI, but putting it here feels like a necessary first step.

Flow wonders if the form-field's registry entry should include data-form validation information, in particular that this value's datatype is xs:anyURI; thinks this should be discussed before adding to the registry, as changing it afterwards could be considered a breaking change.

4c) Advance XEP-0393 (Message Styling) - https://xmpp.org/extensions/xep-0393.html
Dave quite likes this, but is aware that many people don't.
Jonas has a multitude of concerns: community recommendations for an explicit opt-in switch; no way to replace this with an updated or new variant, due to a lack of explicit signalling; putting 'markup' in the body is not the way to go in XMPP (more a weak, purity argument); it should mention security concerns about using existing markdown parsers, even if they're not necessarily 100% compatible; lack of an explicit grammar for writing a compliant parser.
Dave sees the problem of there being many conflicting demands around styled text in messages, and doesn't think are yet any clean solutions; and this isn't one, either.
Despite his concerns, Jonas acknowledges that this stimulated a great deal of improvement in UX by adding rich text to clients; but it was useful as an intermediate step, and we should now find a way to do it properly. Jonas would also prefer if this were on Informational-Active, rather than Standards Track.
Daniel notes that this is only standardising something which clients already do in one form or another, and have done for years; it's not really in-body markdown because the formatting isn't removed, it's a suggestion on how to display emphasis that users are giving the text regardless - therefore it doesn't require opt-in/out. Dave knows it doesn't need signalling or negotiation, but thinks it would be nicer if it did - Daniel wouldn't be against adding a hint in the body to indicate use of message styling.
Jonas replies to Daniel that, in that case, it doesn't really belong on the Standards Track; quoting XEP-0001, §3.1, "A Standards Track XEP defines … A wire protocol intended to be used as a standard part of XMPP technologies.", Jonas doesn't feel comfortable approving this for Standards Track, and even Informational would be stretching it, but is acceptable as a middle-ground; a non-XSF resource, such as ModernXMPP or similar, would be more fitting for UI things (which this is, according to Daniel's argument.)

Jonas: -1 (concerns mentioned above)
Zash: -1 (agree with Jonas)
Dave: +0
Daniel: +1
Georg: [pending]

The author, Sam, views the use of a "styling hint" as unnecessary bloat; Sam also took care to make sure the grammar was well-defined so a compliant parser can be written; also feels strongly that it belongs on the Standards Track.
Zash thinks that overloading the body without negotiation is problematic - Dave queries whether negotiation or hinting would be preferable - Zash thinks either would be better than nothing.
Jonas could be persuaded to accept overloading the body in this specific way if and only if an opt-in is given; and if an opt-in is present then it's more clearly wire protocol and belongs on the Standards Track; the lack of formal grammar isn't blocking, as long as implementers agree that it's doable without one (which is more an issue for Final.)
Sam says it will never be opt-in, as that defeats the point - the very reason it got wide adoption is because it wasn't opt-in, it simply documents how to apply styling to what users already do; it could be opt-out per message, but that's all he would be comfortable with - opt-in is the only thing Jonas would be comfortable with.
Dave says the inclusion of a styling hint for opt-in would move his vote to +1, and opt-out would be great too. Zash is also fine with this. Jonas concludes this is a clear way forward for the author.
Sam intends to add the opt-out hint, but is absolutely against adding opt-in as it would completely break the point of this - it makes this much harder to implement and much less consistent.
Jonas tries to get things back on-track, and directs further discussion on this elsewhere.

4d) Last Call: XEP-0338 (Jingle Grouping Framework) - https://xmpp.org/extensions/xep-0338.html
Daniel: +1 (expect a similar outcome as the other two Jingle specs: little, but positive, feedback)
Zash: +1
Jonas: +1
Dave: +1
Georg: [pending]

5) Pending votes
None.

6) Date of next
2020-06-03 1500 UTC

7) AOB
Jonas has sent a meeting-time scheduling thing for the routing stuff and things [2].

8) Close
Thanks all.

Discussion of the use of styling hints for XEP-0393 continues…


[1] https://mail.jabber.org/pipermail/standards/2020-May/037443.html
[2] https://mail.jabber.org/pipermail/standards/2020-May/037492.html

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200531/470a60b2/attachment.html>


More information about the Standards mailing list