Re: [Standards] Adding namespaced content to Registry entries
On 6/3/20 10:50 PM, Dave Cridland wrote:> That said, I think there's two useful things we can do here: > > 1) Validation information is clearly useful in this case; we should add > that to the XEP-0068 registry by an update to XEP-0068 I would like to avoid steering us in a world where we are required to explicitly mark registry entries as extensible. Instead, registry entries should simply assumed to be extensible. Just like we assume that XML elements are extensible in XMPP, and for that reason also do not explicitly declare that extensibility in your XML schemas (minus a few exceptions). Otherwise, we would need to perform this over and over again for every add-on XEP that deals with elements that are part of a registry, for no reason. There is *no* advantage in explicit stating it: Just as on the protocol level, either the extended additional information was negotiated, and you are prepared for it, or you are not required to understand it, and can simply ignore it while processing the registry entry. - Florian signature.asc Description: OpenPGP digital signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Council Minutes 2020-05-27
* Tedd Sterr [2020-06-01 00:53]: > 4a) Proposed XMPP Extension: SASL Channel-Binding Type Capability - > https://xmpp.org/extensions/inbox/xep-sasl-cb-types.html +1 > 4b) PR #949 - Add status-addresses registrar entry - > https://github.com/xsf/xeps/pull/949 > Jonas notes the on-list discussion around this [1]. +1 (and even +2 if we add the .well-known mapping into it and somebody implements the right magic in the server software) > 4c) Advance XEP-0393 (Message Styling) - > https://xmpp.org/extensions/xep-0393.html +1 It was a nice heated discussion, this time and last time. The principal feature now exists on IM systems for roughly twenty years [0] and it is good to have it formalized. It wouldn't make sense to have a disco feature for supporting this, because MAM and Carbons will end up delivering a message do different clients. I'm not opposed to a boolean tri-state per-message flag to opt-in, opt-out, or use the recipient's default setting for Styling on that message: Opt-out: Opt-in: Default / fallback: no additional element [0] https://irssi.org/NEWS/#v0-7-97 > > 4d) Last Call: XEP-0338 (Jingle Grouping Framework) - > https://xmpp.org/extensions/xep-0338.html +1 Georg signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
