[Standards] Council Minutes 2020-01-02

Georg Lukas georg at op-co.de
Wed Jan 15 15:52:18 UTC 2020

* Tedd Sterr <teddsterr at outlook.com> [2020-01-07 17:07]:
> http://logs.xmpp.org/council/2020-01-02?p=h#2020-01-02-a37a199502a4581c
> 3a) Proposed XMPP Extension: MAM Fastening Collation - https://xmpp.org/extensions/inbox/mamfc.html


The general functionality is something that we really need, but I think
we need some representative examples in the XEP and an explanation of
the required server-side logic for implementing them. Right now I fail
to understand whether this proposal will work or not (and I haven't yet
catched up with the respective mail thread, sorry).

> 3b) Proposed XMPP Extension: User-defined Data Transfer - https://xmpp.org/extensions/inbox/udt.html


I think this addresses a valid problem with the XMPP ecosystem, but for
God's sake don't call anything in the API "udt", because this is even
more obscure than the standard means of custom stanza elements that XMPP
provides. With the acronym introduced and consequently used in this XEP,
I'd rather have expected this submission in 77 days from now, under a
different track, because no application developer looking for how to
embed JSON into XMPP would ever find this.

I'll gladly change to +1 if you do an s/udt/json/g on the document,

I think there is no need to split the API description into its own XEP,
but there might be value in moving the datatype attribute into XEP-0335
and to keep this XEP as API-description only.

> 3c) Proposed XMPP Extension: Fallback Indication - https://xmpp.org/extensions/inbox/fallback.html


I'm not strongly convinced by this, as stated in the respective thread,
but I think it doesn't actually do harm. Also please add an attribute
for the namespace that caused the fallback to be added.

Also we need more discussion around the more sophisticated use cases
with partial fallback content, as outlined by Marvin. However, we should
be able to figure out those during Experimental.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200115/b4d6596a/attachment.sig>

More information about the Standards mailing list