[Standards] XEP-0394: too weak to replace XEP-0071

Jonas Wielicki 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
> compatibility.

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 [1]) 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: […]

See above.


kind regards,
Jonas

   [1]: 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...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.jabber.org/pipermail/standards/attachments/20180319/8896ed2e/attachment.sig>


More information about the Standards mailing list