[Standards] Council Minutes 2020-05-27

Marvin W xmpp at larma.de
Tue Jun 2 16:39:27 UTC 2020

Hi Jonas,

On 02.06.20 16:26, Jonas Schäfer wrote:
> I think we disagree fundamentally, though, on whether this is an advantage, or 
> at least as a necessary advantage. It necessarily implies that if a client 
> does not have support for it, I have no way to opt out if I know that my 
> message will "style" badly.

I was using this feature of message styling for long time (when
Conversations had support and most desktop clients didn't), so I'd say
it's an advantage. The disadvantage you are mixing in here is false
positives, which is a disadvantage on its own, not directly related to
this advantage.

> Yes, body-only encryption breaks a lot of richer use-cases. That’s 
> nothing new, and I refuse to cater for it at the expense of other concerns.

As I myself am not a fan of 0393, I'd say catering to this was one of
the ideas of 0393 (correct me if I'm wrong). If you don't want to cater
to this, that's up to you, but shouldn't be relevant for 0393.
> Partial +1. First, note that not many clients actually show the quotation 
> markers, which can lead to fun confusion with things which happen to start a 
> line with `> ` for whatever reason. So this rule isn’t quite working out in 
> practice.

You can't blame the XEP (or its author) for devs not implementing it
correctly. Adding new rules to the XEP won't change that, so any
proposed changes might as well be ignored by some devs.

> Then note that the added styling plus potentially deemphasising of the 
> metacharacters can still make a message unnecessarily visually harder to read.

I agree, if that wasn't the case, false positives wouldn't be an issue
anymore (that why it's only partially mitigated and not completely).
However note that deemphasising styling directives is also against the
recommendation in 0393 §8.
> - We cannot upgrade or fundamentally change the syntax in a non-breaking 
> fashion, without:
>   - forcing everyone using a newer version to send opt-out flags for all 
> eternity, or 
>   - adding explicit support for detecting other non-Styling markup and 
> disabling the Styling parser in those cases (which introduces a weird 
> coupling; you might call that ideological, too), or
>   - have inconsistent displaying of styling, which is the one of the primary 
> things this XEP is intended to solve.

Assuming you mean change syntax for inline styling:
- I feel we all agree that we shouldn't want to fundamentally change the
syntax of inline styling in the future, but instead want to get away
from using inline styling.
- If any changes happen at all, they should be made with backwards
compatibility in mind. Which probably means that new styling (don't know
let's say links) can be added, but existing rules can't be changed.
- If we stick with my assumption that it is by design that you can both
read and write styling without support of the client, an opt-in with a
version will a) not allow to upgrade without client support and/or b)
raise the question how to render a message that has a higher version
than the client: add no styling or still try to parse with older rules?

If you were not talking about syntax for inline styling, but all kinds
of styling/markup:
- There can't be two different ways of styling/markup active at the same
time for a single message, as those could be in conflict. Therefor it's
obvious that if a client receives and understands a message with e.g.
both 0393 and 0394 styling it must give precedence to one or completely
ignore both. However if a client does not understand 0394, I don't think
it's an issue if it still tries to do 0393 (as long as there is no
opt-out for it on the message itself). This also allows for 0394 or
similar XEPs to be designed in a backwards compatible fashion (as in
backwards compatible to 0393), even though some probably are going to
argue that this should not be a design goal.

> I don’t see that as a reason to not make it a MUST.
I'd be OK with making it a MUST, however dictating a MUST for a feature
that wasn't present in earlier versions kind of defeats its purpose
because sending clients cannot rely on that feature being actually
implemented by recipient clients.


More information about the Standards mailing list