[Standards] XEP-0394: too weak to replace XEP-0071
jonas at wielicki.name
Mon Mar 19 07:49:03 UTC 2018
On Freitag, 16. März 2018 15:03:28 CET Tedd Sterr wrote:
> I like the idea and design of 0394, and look forward to seeing these
> extensions; the unholy hybrid attempting to shoehorn in 0393, not so much.
> Attempting to extend the inline text styling to support all of the
> additional formatting features is going to result in plain text messages
> that resemble Perl programs, which is really not good for readability. And
> essentially forcing clients to support 0393,
A client can use 394 without support 393 just fine. I don’t see where you got
this notion from, I guess my initial mail on this was unclear.
> while also including
> additional styling that 0393 does not support will do nothing to aid
The "unholy hybrid" is not about '393 compatibility in particular. It is about
gracefully falling back to plaintext in general. Making this compatible (to a
certain extent ) with '393 is just an added bonus.
> Regarding graceful degradation: there should be a service discovery string
> to indicate support for 0394; thus a sending client knows in advance
> whether to send 0394 formatting to another client.
This is the Feature Discovery fallacy (for the lack of a better term). Feature
Discovery does (currently) not really work. We have Carbons and MAM. You can’t
be sure whether the other side has clients which support or do not support a
feature and which are just currently not online. Not to mention MUCs and other
broadcast/multicast protocols. Is it reasonable to remove formatting options
just because one lurker in a MUC with 20 users does not have support? You also
generally won’t be able to see features of all clients in a Multi-Session Nick
situation. Relying on feature discovery is not going to solve anything.
> The sending client can still degrade gracefully - there are four
> possibilities: […]
: Full compatibility with '393 can’t be achieved anyways, because of
the intentional restrictions of '393. It would at most be an
approximation which---just like '393 itself and as designed---works
in *most* cases.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: This is a digitally signed message part.
More information about the Standards