Re: [Standards] Council Minutes 2020-05-27

[Georg Lukas]

* 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
___

Re: [Standards] Council Minutes 2020-05-27

[Sam Whited]

I have submitted another revision removing this workaround since no
control character or special whitespace character can be found with
appropriate semantics.

Let's take this opportunity for a clean break and take any further
discussion of this particular topic to a new thread, if necessary
since this is getting rather long. Sorry I didn't change the subject
line soon.

—Sam

On Thu, Jun 4, 2020, at 10:03, Jonas Schäfer wrote:
> On Dienstag, 2. Juni 2020 17:36:32 CEST Sam Whited wrote:
> > > Then it has a non-obvious disadvantage (apparently) even to
> > > technical users, in that it inserts invisible unicode codepoints.
> > > This will cause hard-to- troubleshoot issues when (parts of) the
> > > message are copied into a thing which cares about it, such as a C
> > > compiler.
> >
> > I don't think this is a problem we should worry about. If this is a
> > problem for you, you already have this problem all over the web and
> > everywhere else and the answer is not "pretend Unicode doesn't exist
> > and don't use it".
>
> I have yet to see a widely used thing in the web which injects hidden
> Unicode codepoints in user-submitted content.
>
> Note that I’m not complaining about the use of Unicode. I’m
> complaining about the non-obvious injection of invisible codepoints in
> user content messages.
>
> kind regards, Jonas
> ___
> Standards mailing list Info:
> https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: Standards-
> unsubscr...@xmpp.org
> ___
>
> Attachments:
> * signature.asc

-- 
Sam Whited
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Council Minutes 2020-05-27

[Jonas Schäfer]

On Dienstag, 2. Juni 2020 17:36:32 CEST Sam Whited wrote:
> > Then it has a non-obvious disadvantage (apparently) even to technical
> > users, in that it inserts invisible unicode codepoints. This will
> > cause hard-to- troubleshoot issues when (parts of) the message are
> > copied into a thing which cares about it, such as a C compiler.
> 
> I don't think this is a problem we should worry about. If this is a
> problem for you, you already have this problem all over the web and
> everywhere else and the answer is not "pretend Unicode doesn't exist and
> don't use it".

I have yet to see a widely used thing in the web which injects hidden Unicode 
codepoints in user-submitted content.

Note that I’m not complaining about the use of Unicode. I’m complaining about 
the non-obvious injection of invisible codepoints in user content messages.

kind regards,
Jonas

signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Council Minutes 2020-05-27

[Sam Whited]

For now I'm going to remove the documentation of using invisible Unicode
characters to break up the text. It's a neat idea, but I can't find a
control character or space that actually has semantics that would allow
it to be used for something like this, and I don't want it to just be a
hack. If anyone knows a character, probably in C0 or C1 somewhere, that
would work and is defined for application level usage maybe we can
document that if you're going to do this you should probably use it,
otherwise let's just remove this text and if implementations want to do
this with a random space they still can.

—Sam
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Council Minutes 2020-05-27

[Sam Whited]

But presumably this doesn't happen in XMPP clients and the like, which
do UTF-8 correctly? If this is just Windows being stupid and using UTF-
16, I don't think it's something we should bother with.

Then again, this isn't something that needs to be specified and since
we're not sure maybe it's worth just not mentioning it. If people
want to develop toolbars that use this technique or something, they
still can.

—Sam

On Tue, Jun 2, 2020, at 18:46, Tedd Sterr wrote:
>  On Windows, the ZWSP is handled correctly in many places, but badly
>  or not at all in others.
>
>  Depending on version and options, the RichEdit control may display no
>  space (good), a '?' (as unknown character), a full space, or a full
>  space *after* the following character. It also displays as a full
>  space in the console.
>
>
> *From:* Standards  on behalf of Tedd Sterr
>  *Sent:* 02 June 2020 21:20 *To:* XMPP
> Standards  *Subject:* Re: [Standards] Council
> Minutes 2020-05-27
>  > You don't need special handling, …
>  True; of course I realised my mistake immediately after sending.
>
>  Once, I had the great idea of using ZWSP to demarcate sections of
>  text that would be omitting during copying, but ended up having to
>  use something less fancy because it caused problems (it might have
>  been a display issue, possibly something else - I'll have to do some
>  testing.)
___
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]

On Windows, the ZWSP is handled correctly in many places, but badly or not at 
all in others.

Depending on version and options, the RichEdit control may display no space 
(good), a '?' (as unknown character), a full space, or a full space after the 
following character.
It also displays as a full space in the console.



From: Standards  on behalf of Tedd Sterr 

Sent: 02 June 2020 21:20
To: XMPP Standards 
Subject: Re: [Standards] Council Minutes 2020-05-27

> You don't need special handling, …
True; of course I realised my mistake immediately after sending.

Once, I had the great idea of using ZWSP to demarcate sections of text that 
would be omitting during copying, but ended up having to use something less 
fancy because it caused problems (it might have been a display issue, possibly 
something else - I'll have to do some testing.)

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Council Minutes 2020-05-27

[Sam Whited]

On Tue, Jun 2, 2020, at 16:48, Marvin W wrote:
> On 02.06.20 22:34, Sam Whited wrote:
> > This does not add new rules, [...] I was hoping to avoid adding
> > extra rules anyways, and making category C another thing that's
> > disallowed counts.
>
> You are contradicting yourself, but I guess we were thinking the same
> nonetheless ;)

I keep re-reading this, and I don't see a contradiction, but given your
next reply I think I must be misunderstanding something about what you
said in your previous email.

> I guess you misunderstood: I am talking about prefixing, that is
> putting the non-whitespace character (both U+200B and U+2060 are)
> where a whitespace would've been needed under current rules. Thus this
> does not require any changes to existing implementations to support
> it. The additional complexity is to correctly handle the breaking vs
> non-breaking nature of the preceding character. It also wasn't exactly
> correct as I didn't handle non-breaking spaces, so here is an updated
> version:

Ah yes, I see, that makes sense. I don't love this, but I'd be okay with
it if we found a character that had better semantics than U+2060. I'm
still looking into how its used and what Unicode says it's okay for, but
if it is strictly for joining words and preventing a break I agree it's
a hack and should be avoided.

Maybe U+E007F CANCEL TAG would be okay, right now it's only used for the
various combinations of flag emojis, but the Wikipedia article suggests
it's for general use as a "cancel" control character. I'll keep reading,
it may just be that this isn't a good idea after all and doesn't work.
We'll see.

—Sam

-- 
Sam Whited
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Council Minutes 2020-05-27

[Marvin W]

On 02.06.20 22:34, Sam Whited wrote:
> This does not add new rules, [...] I was hoping to avoid
> adding extra rules anyways, and making category C another thing that's
> disallowed counts.

You are contradicting yourself, but I guess we were thinking the same
nonetheless ;)
>> Solution could be:
>> - If a space, the start of the string or a newline precedes the
>>   opening directive, it can be disabled by prefixing it with U+200B
>> - If another opening directive precedes the opening directive, it can
>>   be disabled by prefixing it with U+2060
>>
>> Both are not sane solutions and I wasn't actually very serious when
>> mentioning it. So maybe it's not a good idea to mention it in the XEP
>> even though it technically works.
> 
> This would be adding a new rule like disallowing category C would, by
> making the ZWS or whatever we ended up using a special case, which I was
> hoping to avoid, but it may be worth considering. I'll keep thinking
> about it. Thanks for the ideas!

I guess you misunderstood: I am talking about prefixing, that is putting
the non-whitespace character (both U+200B and U+2060 are) where a
whitespace would've been needed under current rules. Thus this does not
require any changes to existing implementations to support it. The
additional complexity is to correctly handle the breaking vs
non-breaking nature of the preceding character. It also wasn't exactly
correct as I didn't handle non-breaking spaces, so here is an updated
version:

- If a breaking space, the start of the string or a newline precedes the
opening directive, it can be disabled by prefixing it with U+200B
- If a non-breaking space or another opening directive precedes the
opening directive, it can be disabled by prefixing it with U+2060

I'd say it might be worth documenting that in the XEP, but I'd refrain
from in any way suggesting developers to do that outside of controlled
environments as this is very likely to have negative impact on clients
that use Unicode older than 3.2 (when U+2060 was defined as WJ) or don't
have proper Unicode support.

Marvin
___
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]

> You don't need special handling, …
True; of course I realised my mistake immediately after sending.

Once, I had the great idea of using ZWSP to demarcate sections of text that 
would be omitting during copying, but ended up having to use something less 
fancy because it caused problems (it might have been a display issue, possibly 
something else - I'll have to do some testing.)

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Council Minutes 2020-05-27

[Marvin W]

Hi,

1. I don't think we should add new rules, especially none that are hard
to implement - and most people (and also many programming languages)
have trouble with unicode, so I'd qualify this as hard to implement.
2. I also disagree that category C characters should not be allowed to
appear after the opening directive. An example where I think there is
valid use to put it after the opening directive are LRO/RLO.
3. After checking again the definition, I disagree that WORD JOINER is a
good way to indicate no formatting should happen: "The function of
character is to indicate that line breaks are not allowed between the
adjoining characters, except next to hard line breaks." Thus, if this
character is put behind a space, it stops line breaks from happening at
that space which would normally happen, and I don't think that's what
people wanted.

Solution could be:
- If a space, the start of the string or a newline precedes the opening
directive, it can be disabled by prefixing it with U+200B
- If another opening directive precedes the opening directive, it can be
disabled by prefixing it with U+2060

Both are not sane solutions and I wasn't actually very serious when
mentioning it. So maybe it's not a good idea to mention it in the XEP
even though it technically works.

Marvin

On 02.06.20 19:45, Sam Whited wrote:
> Drat, you're right, I thought it was in category Z but it doesn't look
> like it is.
> 
> Sticking it before the directive would work as well. Alternatively we
> could expand the definition of what's not allowed immediately after a
> thing that might be a styling directive to include category C as well as
> category Z. It would make sense to me that they're not allowed either,
> and it means word joiner can be used as written.
> 
> I have no particular preference either way, but if anyone else sees a
> flaw with either solution that I'm missing let me know.
> 
> Thanks,
> Sam
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Council Minutes 2020-05-27

[Sam Whited]

On Tue, Jun 2, 2020, at 16:03, Sam Whited wrote:
> *this* is strong, but*this* is not bold

Amusingly in Fastmail's web interface those both render as bold, but I
meant "in this spec" of course :)

—Sam
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Council Minutes 2020-05-27

[Sam Whited]

On Tue, Jun 2, 2020, at 15:52, Tedd Sterr wrote:
>  First you realise joiners aren't classified as whitespace, so then
>  you have to prepend it instead, but that would need special handling,

You don't need special handling, the styling directives must start after
whitespace, so *this* is strong, but*this* is not bold. The joiner
breaks the whitespace and the styling directive in the same way it would
have broken the directive and the text if it came afterwards and was a
space (which is disallowed). The point is that the joiner fits within
the existing rules, it can already be used as the spec stands right now,
we're just documenting it as something you can do.

> then they're not always rendered correctly because some text renderers
> handle unicode badly (I have had similar issues with these kinds of
> things in the past, specifically ZWSP), then you find …

If this is true it could be a problem, can you point out a system that
renders ZWSP badly that we could test on? If it's a wide spread problem,
that would definitely make this less useful.

—Sam
___
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]

It probably is the best unicode charater to use for this purpose; I have doubts 
over whether this is a good thing to enable in the first place.

First you realise joiners aren't classified as whitespace, so then you have to 
prepend it instead, but that would need special handling, and then they're not 
always rendered correctly because some text renderers handle unicode badly (I 
have had similar issues with these kinds of things in the past, specifically 
ZWSP), then you find …

It just feels dirtier by the minute.



From: Standards  on behalf of Sam Whited 

Sent: 02 June 2020 20:29
To: standards@xmpp.org 
Subject: Re: [Standards] Council Minutes 2020-05-27

On Tue, Jun 2, 2020, at 15:14, Tedd Sterr wrote:
>  At first glance this looks like a cute solution, but it starts to
>  resemble a dirty hack the longer you look at it.

How so? Semantically this seems like the sort of thing joiners are for.
Eg. this is similar to the mechanism for breaking up combining emojis,
similar to breaking up letters in joined texts, etc. we're just breaking
up the styling directive from the text it would otherwise style.

>  You're hoping to add a neat little feature for little cost, but it's
>  going to be additional unnecessary complexity in almost all cases. If
>  you're aiming to keep 0393 small, neat, and clean then maybe this
>  isn't a good way to go. I don't even see much realistic use for
>  styling *this* but not *this* - messages are either fully styled or
>  fully unstyled - don't over-complicate things.

In general I feel the same way, but others said the all or nothing
approach was confusing and I do see the appeal of wanting a bold button
on a toolbar to work without breaking the rest of the text too. I could
go either way, but if we do want to unstyle individual blocks and spans,
this seems like a simple convenient way to do it.

—Sam
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Council Minutes 2020-05-27

[Sam Whited]

On Tue, Jun 2, 2020, at 15:14, Tedd Sterr wrote:
>  At first glance this looks like a cute solution, but it starts to
>  resemble a dirty hack the longer you look at it.

How so? Semantically this seems like the sort of thing joiners are for.
Eg. this is similar to the mechanism for breaking up combining emojis,
similar to breaking up letters in joined texts, etc. we're just breaking
up the styling directive from the text it would otherwise style.

>  You're hoping to add a neat little feature for little cost, but it's
>  going to be additional unnecessary complexity in almost all cases. If
>  you're aiming to keep 0393 small, neat, and clean then maybe this
>  isn't a good way to go. I don't even see much realistic use for
>  styling *this* but not *this* - messages are either fully styled or
>  fully unstyled - don't over-complicate things.

In general I feel the same way, but others said the all or nothing
approach was confusing and I do see the appeal of wanting a bold button
on a toolbar to work without breaking the rest of the text too. I could
go either way, but if we do want to unstyle individual blocks and spans,
this seems like a simple convenient way to do it.

—Sam

-- 
Sam Whited
___
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]

At first glance this looks like a cute solution, but it starts to resemble a 
dirty hack the longer you look at it.

You're hoping to add a neat little feature for little cost, but it's going to 
be additional unnecessary complexity in almost all cases. If you're aiming to 
keep 0393 small, neat, and clean then maybe this isn't a good way to go. I 
don't even see much realistic use for styling *this* but not *this* - messages 
are either fully styled or fully unstyled - don't over-complicate things.




From: Standards  on behalf of Sam Whited 

Sent: 02 June 2020 18:45
To: standards@xmpp.org 
Subject: Re: [Standards] Council Minutes 2020-05-27

Drat, you're right, I thought it was in category Z but it doesn't look
like it is.

Sticking it before the directive would work as well. Alternatively we
could expand the definition of what's not allowed immediately after a
thing that might be a styling directive to include category C as well as
category Z. It would make sense to me that they're not allowed either,
and it means word joiner can be used as written.

I have no particular preference either way, but if anyone else sees a
flaw with either solution that I'm missing let me know.

Thanks,
Sam
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Council Minutes 2020-05-27

[Sam Whited]

Drat, you're right, I thought it was in category Z but it doesn't look
like it is.

Sticking it before the directive would work as well. Alternatively we
could expand the definition of what's not allowed immediately after a
thing that might be a styling directive to include category C as well as
category Z. It would make sense to me that they're not allowed either,
and it means word joiner can be used as written.

I have no particular preference either way, but if anyone else sees a
flaw with either solution that I'm missing let me know.

Thanks,
Sam

On Tue, Jun 2, 2020, at 13:04, Marvin W wrote:
> Unfortunately your updated §7.1 is broken.
>
> - U+2060 WORD JOINER is not a whitespace character under Unicode
>   definition, therefor your proposed way to remove styling will not
>   work with any client correctly implementing the XEP.
> - U+200B ZERO WIDTH SPACE is also not a whitespace character (even
>   though it totally sounds as if), that's why I suggested to put it
>   *before* the styling directive, like "In ​*this* example". As
>   styling directives must be located at the beginning of the line,
>   after a whitespace or after a different styling directive and U+200B
>   is none of those.
> - When I suggested U+200B I indeed didn't have the third case in mind,
>   but only the other two and in both of these cases the fact that this
>   character is breaking wasn't an issue. U+2060 also acts as a
>   replacement for the deprecated U+FEFF ZERO WIDTH NON-BREAKING SPACE
>   so I'd say U+2060 is the right choice here, but it must still be
>   changes such that it is to be inserted before the opening directive
>   and not after.
> - Regarding the closing directive: Thinking more about it, the only
>   case where it is needed to also "escape" the closing directive is
>   the preformatted text block. Valid span closing directives must not
>   be after a space so can't be misunderstood as an opening.
>
> Marvin
> ___
> Standards mailing list Info:
> https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: Standards-
> unsubscr...@xmpp.org
> ___
>

-- 
Sam Whited
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Council Minutes 2020-05-27

[Marvin W]

Hi Sam,

Unfortunately your updated §7.1 is broken.

- U+2060 WORD JOINER is not a whitespace character under Unicode
definition, therefor your proposed way to remove styling will not work
with any client correctly implementing the XEP.
- U+200B ZERO WIDTH SPACE is also not a whitespace character (even
though it totally sounds as if), that's why I suggested to put it
*before* the styling directive, like "In ​*this* example". As styling
directives must be located at the beginning of the line, after a
whitespace or after a different styling directive and U+200B is none of
those.
- When I suggested U+200B I indeed didn't have the third case in mind,
but only the other two and in both of these cases the fact that this
character is breaking wasn't an issue. U+2060 also acts as a replacement
for the deprecated U+FEFF ZERO WIDTH NON-BREAKING SPACE so I'd say
U+2060 is the right choice here, but it must still be changes such that
it is to be inserted before the opening directive and not after.
- Regarding the closing directive: Thinking more about it, the only case
where it is needed to also "escape" the closing directive is the
preformatted text block. Valid span closing directives must not be after
a space so can't be misunderstood as an opening.

Marvin
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Council Minutes 2020-05-27

[Marvin W]

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.

Marvin
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Council Minutes 2020-05-27

[Sam Whited]

On Tue, Jun 2, 2020, at 10:26, Jonas Schäfer wrote:
> I think this is missing one disadvantage without an explicit opt-
> in flag:
>
> - 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.

I added a disco feature in the latest draft (merged earlier, should be
live later today if it's not already), this should also solve some of
these issues. A client can detect support which includes a versioned
namespace so that they can see what version of styling is supported if
we make changes later.


> I think this is fundamentally problematic.
>
> - Either the user inserts those characters themselves, which makes for
>   extremely terrible UX.
> - Or the sending client has to do it (-> requires client support) and
>   I wonder what the UI would look like for that.

The user probably doesn't want to insert those characters themselves,
and the space thing doesn't help much there. However, in the case where
the client does have a UI, this is fairly easy to do using normal UI
patterns. The user types *this* and it gets styled as strong, or they
highlight the text "this" and press the strong button and it wraps it in
*'s. Now they press the strong button again and it inserts the space if
one doesn't exist, thereby breaking the styling and the message goes
back to looking like "*this*" but without the formatting. Alternatively,
the user types "*this*" and it becomes strong, but they don't like that
so they press backspace. Instead of removing the last * the client could
first insert the spaces (then the user can continue to backspace if they
actually meant to remove the *). Of course, exactly what your UI
supports and how it does it is up to you, these are all just examples
based on other messengers that would work just fine with the space being
inserted to convey the no-break-but-not-part-of-the-same-span semantics.

> Then it has a non-obvious disadvantage (apparently) even to technical
> users, in that it inserts invisible unicode codepoints. This will
> cause hard-to- troubleshoot issues when (parts of) the message are
> copied into a thing which cares about it, such as a C compiler.

I don't think this is a problem we should worry about. If this is a
problem for you, you already have this problem all over the web and
everywhere else and the answer is not "pretend Unicode doesn't exist and
don't use it".

—Sam
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Council Minutes 2020-05-27

[Jonas Schäfer]

Hi Marvin,

This is the worst day for such an email after being paged twice this night, 
but since tomorrow is council day, I still tried to catch up. Apologies if I 
missed something or misunderstood something.

On Montag, 1. Juni 2020 17:58:38 CEST Marvin W wrote:
> I'd like to express that I am very much unhappy where this is leading.
> While I am personally not a big friend of inline message styling, I kind
> of feel that the party of non-likers (or parts thereof) is trying to
> make the XEP to something that is mostly useless instead of improving it.
> 
> In several discussions, I've been trying to maintain a more neutral
> position, even though I personally do not like 0393. So I'm putting up
> my thoughts here now (and a conclusion).

Thank you for the summary, it is very well written in my opinion, and covers 
nearly all issues.

> There are some advantages of using the inline styling directives as
> described in 0393 for users:
> - No sender support required: Even if your sending client is not aware
> of XEP-0393, you can use it to do styling that is understood by other
> clients that are XEP-0393 capable.

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.


> - Transport agnostic: Inline tyling works through gateways. It works
> through body-only encryption. As long as there is no widespread
> deployment of OMEMO 0.4+ or PGP-OX, there is no better way to send
> encrypted messages with styling other than inline.

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

(also note that there was a terrible hack which conveyed XHTML-IM over OTR, 
which is even more transport agnostic than body-only OMEMO is.)

> Some advantages are not exclusive to 0393 as they can be implemented
> purely on the sending side with other kinds of markup XEP, however they
> are implied by 0393.
> - No recipient support required: Even if your client does not make
> "*bold*" bold, it's clearly visible that this is emphasized. Support for
> XEP-0393 will improve user experience, but is not required to transfer
> the information of emphasizing a part of the message. Not being required
> on the receiving end is listed as a requirement in the XEP itself.

+1.

> - Prior art: Some people are/have been used to doing it before,
> including outside of XMPP. Using what is already done in practice for
> emphasizing improves user experience as people don't have to change
> anything but still get new features. For example Thunderbird actually
> renders "*bold*" in bold when reading a mail (not during writing it and
> not for HTML mails).

Also +1.

> Some disadvantages for users are:
> - False positives: No matter how strict you do the rules, there is
> always a little chance of having a false positive, resulting in wrong
> styling being applied.
>   This is mitigated partially by requiring clients to display styling
> directives. While there is still wrong styling, the intended message is
> still fully readable, it "just" looks a bit more ugly compared to when
> no styling was applied.

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.

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

>   Clients can also reduce the likeliness of this to happen by adding the
> styling directly inline in the text entry field where users type, so
> they will visually see when their input would cause wrong styling.

+1.

> - Aesthetics: Users of clients not supporting XEP-0393 will e.g. see
> asterisks around emphasized words, but users may not like to see them
> and would rather prefer to not have any emphasizing displayed at all.
>   This is mitigated partially by requiring clients to display styling
> directives, thus this disadvantage applies to all users, not only those
> of non-supporting clients. Sending users are thus well aware that those
> characters are displayed. The requirement to display "ugly" styling
> directives also increases the need for an additional standard that does
> not use inline styling directives.

+1, though see above about how well that requirement works in practice.


I think this is missing one disadvantage without an explicit opt-in flag:

- 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 

Re: [Standards] Council Minutes 2020-05-27

[Kevin Smith]

On 1 Jun 2020, at 19:52, Kevin Smith  wrote:
> 
> I think all the discussed ideas have merit, although possibly not for the 
> obvious reasons:
> 
> I think there is merit in being able to mark some bits of a message as 
> skipping styling. This is conceptually a hack (IMO), but it’s a hack that has 
> mileage and we should follow this train of thought through.
> 
> I think there is merit in “This message does not contain styling, don’t 
> bother parsing for it” for multiple reasons, performance being as obvious 
> one, but possibly more usefully it’s very simple for an entity that will 
> never send styling (e.g. a bot) to shove this on all messages and not have to 
> (implement support to) parse the outgoing message, work out where the 
> style-breaking-character-hack needs to be applied, and apply them.
> 
> I think there is merit in “This message *does* contain styling, and you can 
> skip the markups, because I’ll have hacked them away from where they 
> shouldn’t be applied”. This is opt-in where the opt-in is actually providing 
> value, I think.

And that can be applied to screenreaders, or whatever accessibility services, 
so it can try to avoid reading out the markup. It doesn’t make the world 
perfect, but it means that for that part of the world that does implement 393 
including the (currently hypothetical) opt-in, at least screen reader-aware 
clients can have a better time of it when incoming messages are marked with the 
opt-in annotation.

So I’m not pretending that clients won’t send without such an opt-in, or that a 
receiver should assume it’s not marked up because it doesn’t see the opt-in, 
but I don’t think it’s worthless to have it.

/K

> 
> /K
> 
>> On 1 Jun 2020, at 18:05, Sam Whited > > wrote:
>> 
>> Sorry, last rapid reply to my own email, I promise:
>> 
>> Apparently there is U+2060: word joiner which is the exact same thing as
>> a ZWSP except that it implies no line breaks. This has just about
>> exactly the semantics we want, and seems like it would be a good
>> candidate for how you disable styling on a specific piece of text.
>> 
>> I think I would prefer to have this over something that has to be
>> namespaced and registered. It's more flexible, would make it easier to
>> implement eg. a toolbar with bold and italic buttons (things get styled
>> by default if you type them, if you highlight the whole thing and remove
>> the styling it could cycle through just removing the styling but leaving
>> the *'s, or removing the *'s etc.
>> 
>> What do others think?
>> 
>> —Sam
>> 
>> On Mon, Jun 1, 2020, at 12:59, Sam Whited wrote:
>>> On Mon, Jun 1, 2020, at 11:58, Marvin W wrote:
 PS: As a sending client you can already opt-out using a hack: By
prepending the opening (and, if needed, closing) styling
directive with zero-width space (U+200B)
>>> 
>>> I hadn't actually thought of this. I'll need to think about it more,
>>> but we might recommend this in the spec since this is the exact use
>>> case zero width spaces are for (things that are word boundaries but
>>> where spaces don't necessarily go, between characters that shouldn't
>>> be put together in connected scripts, etc. My only concern would be
>>> that they also have the meaning "you can add a soft break here" which
>>> is probably *not* what you want in this case.
>>> 
>>> I'll think about it more, but this is definitely at least close to the
>>> point of a zero-width space and might be worth documenting.
>>> 
>>> —Sam
>>> 
>>> 
>>> --
>>> Sam Whited
>> 
>> -- 
>> Sam Whited
>> ___
>> Standards mailing list
>> Info: https://mail.jabber.org/mailman/listinfo/standards 
>> 
>> Unsubscribe: standards-unsubscr...@xmpp.org 
>> 
>> ___
> 
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Council Minutes 2020-05-27

[Dave Cridland]

On Mon, 1 Jun 2020 at 17:20, Marvin W  wrote:

> Hi,
>
> Sorry, long mail ahead.
>
> I'd like to express that I am very much unhappy where this is leading.
>

Thanks for writing this; it's an excellent summary of where we are, and
seems to have sparked some more constructive debate. (In other words, it's
what I attempted and failed to do!)


> So my conclusion:
> - We can add the opt-out flag to 0393. Supporting it is SHOULD on the
> recipient side and support for adding it is a MAY on the sender side.
> Making support a MUST both on sending and receiving side is unrealistic
> due to it just not being possible through transports and currently
> deployed encryption.
> - We put our energy into building a replacement (being it 0394 or
> something completely different) instead of using it to make 0393 less
> useful to harm its adoption.
>

I think the latter is correct, but I'm interested in exploring Kev's
proposal around the former.

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Council Minutes 2020-05-27

[Kevin Smith]

I think all the discussed ideas have merit, although possibly not for the 
obvious reasons:

I think there is merit in being able to mark some bits of a message as skipping 
styling. This is conceptually a hack (IMO), but it’s a hack that has mileage 
and we should follow this train of thought through.

I think there is merit in “This message does not contain styling, don’t bother 
parsing for it” for multiple reasons, performance being as obvious one, but 
possibly more usefully it’s very simple for an entity that will never send 
styling (e.g. a bot) to shove this on all messages and not have to (implement 
support to) parse the outgoing message, work out where the 
style-breaking-character-hack needs to be applied, and apply them.

I think there is merit in “This message *does* contain styling, and you can 
skip the markups, because I’ll have hacked them away from where they shouldn’t 
be applied”. This is opt-in where the opt-in is actually providing value, I 
think.

/K

> On 1 Jun 2020, at 18:05, Sam Whited  wrote:
> 
> Sorry, last rapid reply to my own email, I promise:
> 
> Apparently there is U+2060: word joiner which is the exact same thing as
> a ZWSP except that it implies no line breaks. This has just about
> exactly the semantics we want, and seems like it would be a good
> candidate for how you disable styling on a specific piece of text.
> 
> I think I would prefer to have this over something that has to be
> namespaced and registered. It's more flexible, would make it easier to
> implement eg. a toolbar with bold and italic buttons (things get styled
> by default if you type them, if you highlight the whole thing and remove
> the styling it could cycle through just removing the styling but leaving
> the *'s, or removing the *'s etc.
> 
> What do others think?
> 
> —Sam
> 
> On Mon, Jun 1, 2020, at 12:59, Sam Whited wrote:
>> On Mon, Jun 1, 2020, at 11:58, Marvin W wrote:
>>> PS: As a sending client you can already opt-out using a hack: By
>>>prepending the opening (and, if needed, closing) styling
>>>directive with zero-width space (U+200B)
>> 
>> I hadn't actually thought of this. I'll need to think about it more,
>> but we might recommend this in the spec since this is the exact use
>> case zero width spaces are for (things that are word boundaries but
>> where spaces don't necessarily go, between characters that shouldn't
>> be put together in connected scripts, etc. My only concern would be
>> that they also have the meaning "you can add a soft break here" which
>> is probably *not* what you want in this case.
>> 
>> I'll think about it more, but this is definitely at least close to the
>> point of a zero-width space and might be worth documenting.
>> 
>> —Sam
>> 
>> 
>> --
>> Sam Whited
> 
> -- 
> Sam Whited
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards 
> 
> Unsubscribe: standards-unsubscr...@xmpp.org 
> 
> ___

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Council Minutes 2020-05-27

[Sam Whited]

On Mon, Jun 1, 2020, at 12:51, Tedd Sterr wrote:
>  Your view is that some clients may default to not styling, and other
>  clients may default to doing styling, and so the same message viewed
>  on two different clients will render differently. This is also going
>  to happen where some clients support styling and others don't - you
>  can't really fix that.

That's correct, not all clients will implement this, and we can't fix
that. However we can fix problems among clients that choose to implement
this spec. By not allowing remote clients that may or may not support
styling to have an option that may default to different things on
different receiving clients, we at least ensure that on a specific
receiving client messages are displayed the same way regardless of
weather the remote client supports this spec or not.

>  What you're doing is implicitly demanding that all supporting clients
>  MUST default to adding styling, and thus if no hint is provided they
>  will render with styling; if an opt-out is provided then there is no
>  styling; and if an opt-in is provided then they also apply styling -
>  which obviously makes the opt-in somewhat redundant. The opt-in,
>  then, doesn't add complexity, doesn't make it harder to implement,
>  and doesn't make it less consistent, it's just unnecessary.

That's correct.

>  I suppose the only remaining question is whether you can make such
>  demands on all clients. (There is a related question of whether
>  there's any point implementing this if you're not even going to use
>  it by default, but I think that should be a user preference.)

Not on all clients, just on clients that choose to support this spec.
Everyone else can continue to do whatever they want with messages where
users wrote things like *this*. Of course, naturally I hope more
implement this spec so that the ecosystem becomes more consistent :)

—Sam

-- 
Sam Whited
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Council Minutes 2020-05-27

[Sam Whited]

Sorry, last rapid reply to my own email, I promise:

Apparently there is U+2060: word joiner which is the exact same thing as
a ZWSP except that it implies no line breaks. This has just about
exactly the semantics we want, and seems like it would be a good
candidate for how you disable styling on a specific piece of text.

I think I would prefer to have this over something that has to be
namespaced and registered. It's more flexible, would make it easier to
implement eg. a toolbar with bold and italic buttons (things get styled
by default if you type them, if you highlight the whole thing and remove
the styling it could cycle through just removing the styling but leaving
the *'s, or removing the *'s etc.

What do others think?

—Sam

On Mon, Jun 1, 2020, at 12:59, Sam Whited wrote:
> On Mon, Jun 1, 2020, at 11:58, Marvin W wrote:
> > PS: As a sending client you can already opt-out using a hack: By
> > prepending the opening (and, if needed, closing) styling
> > directive with zero-width space (U+200B)
>
> I hadn't actually thought of this. I'll need to think about it more,
> but we might recommend this in the spec since this is the exact use
> case zero width spaces are for (things that are word boundaries but
> where spaces don't necessarily go, between characters that shouldn't
> be put together in connected scripts, etc. My only concern would be
> that they also have the meaning "you can add a soft break here" which
> is probably *not* what you want in this case.
>
> I'll think about it more, but this is definitely at least close to the
> point of a zero-width space and might be worth documenting.
>
> —Sam
>
>
> --
> Sam Whited

-- 
Sam Whited
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Council Minutes 2020-05-27

[Sam Whited]

On Mon, Jun 1, 2020, at 11:58, Marvin W wrote:
> PS: As a sending client you can already opt-out using a hack: By
> prepending the opening (and, if needed, closing) styling directive
> with zero-width space (U+200B)

I hadn't actually thought of this. I'll need to think about it more, but
we might recommend this in the spec since this is the exact use case
zero width spaces are for (things that are word boundaries but where
spaces don't necessarily go, between characters that shouldn't be put
together in connected scripts, etc. My only concern would be that they
also have the meaning "you can add a soft break here" which is probably
*not* what you want in this case.

I'll think about it more, but this is definitely at least close to the
point of a zero-width space and might be worth documenting.

—Sam


-- 
Sam Whited
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Council Minutes 2020-05-27

[Sam Whited]

Not that it really matters, but to be pedantic and correct my own
mistake: I mentioned connected scripts, this is not correct. That is a
Zero width joiner, of course. ZWS is used in languages that don't put
spaces between words to indicate word boundaries, which is of course a
different thing. I had a brain fart.

—Sam

On Mon, Jun 1, 2020, at 12:59, Sam Whited wrote:
> On Mon, Jun 1, 2020, at 11:58, Marvin W wrote:
> > PS: As a sending client you can already opt-out using a hack: By
> > prepending the opening (and, if needed, closing) styling
> > directive with zero-width space (U+200B)
>
> I hadn't actually thought of this. I'll need to think about it more,
> but we might recommend this in the spec since this is the exact use
> case zero width spaces are for (things that are word boundaries but
> where spaces don't necessarily go, between characters that shouldn't
> be put together in connected scripts, etc. My only concern would be
> that they also have the meaning "you can add a soft break here" which
> is probably *not* what you want in this case.
>
> I'll think about it more, but this is definitely at least close to the
> point of a zero-width space and might be worth documenting.
>
> —Sam
>
>
> --
> Sam Whited

-- 
Sam Whited
___
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]

As I understand your argument, it seems the disagreement is actually over what 
happens when no hint is provided, rather than whether an opt-in hint should be 
provided.

Your view is that some clients may default to not styling, and other clients 
may default to doing styling, and so the same message viewed on two different 
clients will render differently. This is also going to happen where some 
clients support styling and others don't - you can't really fix that.

What you're doing is implicitly demanding that all supporting clients MUST 
default to adding styling, and thus if no hint is provided they will render 
with styling; if an opt-out is provided then there is no styling; and if an 
opt-in is provided then they also apply styling - which obviously makes the 
opt-in somewhat redundant. The opt-in, then, doesn't add complexity, doesn't 
make it harder to implement, and doesn't make it less consistent, it's just 
unnecessary.

I suppose the only remaining question is whether you can make such demands on 
all clients. (There is a related question of whether there's any point 
implementing this if you're not even going to use it by default, but I think 
that should be a user preference.)

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Council Minutes 2020-05-27

[Marvin W]

Hi,

Sorry, long mail ahead.

I'd like to express that I am very much unhappy where this is leading.
While I am personally not a big friend of inline message styling, I kind
of feel that the party of non-likers (or parts thereof) is trying to
make the XEP to something that is mostly useless instead of improving it.

In several discussions, I've been trying to maintain a more neutral
position, even though I personally do not like 0393. So I'm putting up
my thoughts here now (and a conclusion).

There are some advantages of using the inline styling directives as
described in 0393 for users:
- No sender support required: Even if your sending client is not aware
of XEP-0393, you can use it to do styling that is understood by other
clients that are XEP-0393 capable.
- Transport agnostic: Inline tyling works through gateways. It works
through body-only encryption. As long as there is no widespread
deployment of OMEMO 0.4+ or PGP-OX, there is no better way to send
encrypted messages with styling other than inline.

Some advantages are not exclusive to 0393 as they can be implemented
purely on the sending side with other kinds of markup XEP, however they
are implied by 0393.
- No recipient support required: Even if your client does not make
"*bold*" bold, it's clearly visible that this is emphasized. Support for
XEP-0393 will improve user experience, but is not required to transfer
the information of emphasizing a part of the message. Not being required
on the receiving end is listed as a requirement in the XEP itself.
- Prior art: Some people are/have been used to doing it before,
including outside of XMPP. Using what is already done in practice for
emphasizing improves user experience as people don't have to change
anything but still get new features. For example Thunderbird actually
renders "*bold*" in bold when reading a mail (not during writing it and
not for HTML mails).

Some disadvantages for users are:
- False positives: No matter how strict you do the rules, there is
always a little chance of having a false positive, resulting in wrong
styling being applied.
  This is mitigated partially by requiring clients to display styling
directives. While there is still wrong styling, the intended message is
still fully readable, it "just" looks a bit more ugly compared to when
no styling was applied.
  Clients can also reduce the likeliness of this to happen by adding the
styling directly inline in the text entry field where users type, so
they will visually see when their input would cause wrong styling.
- Aesthetics: Users of clients not supporting XEP-0393 will e.g. see
asterisks around emphasized words, but users may not like to see them
and would rather prefer to not have any emphasizing displayed at all.
  This is mitigated partially by requiring clients to display styling
directives, thus this disadvantage applies to all users, not only those
of non-supporting clients. Sending users are thus well aware that those
characters are displayed. The requirement to display "ugly" styling
directives also increases the need for an additional standard that does
not use inline styling directives.

Another kind of disadvantage:
- Ideological: Styling and content shouldn't be mixed. While I do agree
to this from protocol design, I don't think it's a disadvantage for
users on its own. I am still putting it as it comes up a lot. The actual
disadvantages are those like I described above which are inevitable when
mixing styling and content.

As it is the pure nature of 0393 to have styling and content mixed, this
is not up for discussion. Thus any change we do should try to (further)
mitigate or completely get rid of the disadvantages, ideally without
having to give up on the advantages.

Now the suggestion is to add both opt-in and opt-out flag and leaving it
open what happens when no flag is present, apparently hoping for it
eventually meaning the same as opt-out, while it currently means same as
opt-in.

So how does this change affect aforementioned advantages and disadvantages:
- False positives can still happen as long as no opt-out flag is used.
So I'd say that opt-out improves around that disadvantage, but does not
completely mitigate it.
- Styling directives will still be displayed by non-supporting clients
and should also continue be displayed for supporting clients (as a
mitigation to false positives), so there is no improvement around
aesthetics.
- Both opt-in and opt-out are no longer transport agnostic, which means
at least partially getting rid of advantage 2. If opt-in flag remains
optional, this only means that opt-out flag can be lost and even if
opt-out flag is applied, styling may occur (making the opt-out flag less
useful).
- Having a required opt-in flag means getting rid of advantage of no
sender support and transport-agnostic completely.

What I meant in the introduction with "making it mostly useless": A
required opt-in means the two distinct advantages of inline styling will
be lost. If opt-in is 

Re: [Standards] Council Minutes 2020-05-27

[Sam Whited]

Based on the feedback provided, and partially based on the text Dave
suggested, I've submitted some updates to add an "unstyled" hint among
other more minor changes.

https://github.com/xsf/xeps/pull/955

I want to give my reasoning for not adding the opposite, a "styled"
hint, on list:

Part of the point of Message Styling is that we are trying to make
various things that users are already doing more consistent. This means
that if two users in a MUC write "This has _emphasis_", I should see the
same thing. Similarly, if one user writes the previous message, and the
next user quotes them, the quoted message should look the same in both
places (with the exception that it's in whatever style you use for a
blockquote, of course). If we add a "styled" hint, and leave what
happens when no hint is specified up to the individual clients, this is
no longer guaranteed. Instead one user may send a styled hint, another
user quotes them but does not set a styled hint (because they don't
support it, or just copy pasted and added a ">" before the quote, as
users often do), my various clients might display the quoted message
differently from the original message even if they all support message
styling (one client may default to unstyled, and another may default to
styled, or applying some heuristics).

If instead we always default to styled, and only provide an "unstyled"
hint, messages will be styled or unstyled (if the hint is present) on
any clients that support this spec, and there is less ambiguity. This
does leave the possibility of false positives sent from clients that
don't support styling, but this is likely very rare, and my clients
could add a "view plaintext" button or similar like some email clients
have if they thought it was important enough to do so.


—Sam


On Sun, May 31, 2020, at 18:27, Tedd Sterr wrote:
> *4c) Advance XEP-0393 (Message Styling)* -
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Council Minutes 2020-05-27

[Jonas Schäfer]

On Montag, 1. Juni 2020 15:28:40 CEST Maxime Buquet wrote:
> On 2020/06/01, Jonas Schäfer wrote:
> > [..]
> > 
> > First off, as Dave mentioned already (and as "everyone" will already
> > know),
> > arguably this is deployed very widely. And not because of '393,
> > specifically, but because people have been using these types of
> > metamarkers for so long already that nobody could possibly trace it down
> > to a single source. In a way, they are similar to quotation marks;
> > they’ve become part of an additional grammar used by many people
> > throughout the internet.
> > 
> > There are "cultural dialects" (e.g. the various markdown flavors), but
> > there is basic compatibility. Pinning down the XMPP dialect of this is a
> > good` thing™.
> 
> I disagree. I think this is a bad idea and that we shouldn't endorse
> this as the XSF. XMPP is not a product line, it's a protocol. What
> specific sigils are being used (as input format) shouldn't be enforced
> at the protocol level.

I expect us to Deprecate / Obsolete the spec once we have a replacement with a 
proper wire format for conveying markup. If you feel strongly about this 
situation, the best way to fix it is to make a proposal which replaces the 
versatility of XHTML-IM (with some accessibility (colours) fixes). You’ll find 
lots of inspiration in the threads from the Eternal October 2017 where the 
Styling discussion first came up [1]. I expect this task to be about as fun as 
trying to get a Compliance Suite to Draft.

Then we can Deprecate or Obsolete '393 and move the input format 
recommendations to a UX-centric location (either as "Implementation Note" in 
XHTML-IM-NG or a third-party resource).

With the proposed additions, the document does indeed define a (albeit ugly) 
wire format to be used within XMPP. The  element clearly signals 
that a specific (albeit ugly) wire format (inside ) for marking up text 
is used, which has a rather clearly defined effect. This is useful for non-IM 
and non-human-operated entities, too.

> > However, we need a way forward which will not have to rely on transmitting
> > these markers on the wire. And we also need to be able to deal with
> > entities which send text which is strongly not intended to be formatted
> > based on those markers.
> > 
> > With the proposed mandatory opt-in and opt-out solution, we get both of
> > that. I *hope* that clients which unambiguously support '393 will start
> > to add the opt-in so that the default behaviour (in absence of any
> > marker) can move back from "styled" to "unstyled". In addition, should we
> > ever have to iterate on this document (either in a new XEP or in this
> > thing while it’s in draft), we now have a wire format element of which
> > the namespace can be bumped.> 
> > On Montag, 1. Juni 2020 10:23:37 CEST Dave Cridland wrote:
> > > [..]
> > > If we have a hint and (approximately) the text above in the
> > > specification,
> > > is this enough to make people... if not actually happy, at least willing
> > > to
> > > grudgingly accept the document?
> 
> The proposed changes are indeed better than 393 as is for reasons jonas
> mentioned.
> 
> These changes de facto make the XEP an opt-out XEP though, as long as
> the default is to interpret  for markup.

The default in *current* implementations of the (un-namespace-versioned) '393 
is indeed. With the wording proposed by Dave, implementations "MAY" choose 
styling as default, but they don’t have to. Implementations can very well 
choose to offer this optionally and/or have unstyled by default if the 
coverage of the  tag is widespread enough.

kind regards,
Jonas

   [1]: Some links:

- Original thread by Sam: 
  https://mail.jabber.org/pipermail/standards/2017-October/033546.html
- Rich text thread by Dave:
  https://mail.jabber.org/pipermail/standards/2017-October/033596.html
- Formatting Use Cases thread by Sam:
  https://mail.jabber.org/pipermail/standards/2017-October/033702.html

signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Council Minutes 2020-05-27

[Maxime Buquet]

On 2020/06/01, Jonas Schäfer wrote:
> [..]
> 
> First off, as Dave mentioned already (and as "everyone" will already know), 
> arguably this is deployed very widely. And not because of '393, specifically, 
> but because people have been using these types of metamarkers for so long 
> already that nobody could possibly trace it down to a single source. In a 
> way, 
> they are similar to quotation marks; they’ve become part of an additional 
> grammar used by many people throughout the internet.
> 
> There are "cultural dialects" (e.g. the various markdown flavors), but there 
> is basic compatibility. Pinning down the XMPP dialect of this is a good` 
> thing™.

I disagree. I think this is a bad idea and that we shouldn't endorse
this as the XSF. XMPP is not a product line, it's a protocol. What
specific sigils are being used (as input format) shouldn't be enforced
at the protocol level.

> However, we need a way forward which will not have to rely on transmitting 
> these markers on the wire. And we also need to be able to deal with entities 
> which send text which is strongly not intended to be formatted based on those 
> markers.
> 
> With the proposed mandatory opt-in and opt-out solution, we get both of that. 
> I *hope* that clients which unambiguously support '393 will start to add the 
> opt-in so that the default behaviour (in absence of any marker) can move back 
> from "styled" to "unstyled". In addition, should we ever have to iterate on 
> this document (either in a new XEP or in this thing while it’s in draft), we 
> now have a wire format element of which the namespace can be bumped.

> On Montag, 1. Juni 2020 10:23:37 CEST Dave Cridland wrote:
> > [..]
> > If we have a hint and (approximately) the text above in the specification,
> > is this enough to make people... if not actually happy, at least willing to
> > grudgingly accept the document?

The proposed changes are indeed better than 393 as is for reasons jonas
mentioned.

These changes de facto make the XEP an opt-out XEP though, as long as
the default is to interpret  for markup.

-- 
Maxime “pep” Buquet


signature.asc
Description: PGP signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Council Minutes 2020-05-27

[Jonas Schäfer]

On Montag, 1. Juni 2020 10:23:37 CEST Dave Cridland wrote:
> On Mon, 1 Jun 2020 at 09:19, Dave Cridland  wrote:
> > On Sun, 31 May 2020 at 23:50, Tedd Sterr  wrote:
> >> *4c) Advance XEP-0393 (Message Styling)* -
> >> https://xmpp.org/extensions/xep-0393.html
> >> Dave quite likes this, but is aware that many people don't.
> >> Jonas has a multitude of concerns: community recommendations for an
> >> explicit opt-in switch; no way to replace this with an updated or new
> >> variant, due to a lack of explicit signalling; putting 'markup' in the
> >> body
> >> is not the way to go in XMPP (more a weak, purity argument); it should
> >> mention security concerns about using existing markdown parsers, even if
> >> they're not necessarily 100% compatible; lack of an explicit grammar for
> >> writing a compliant parser.
> >> Dave sees the problem of there being many conflicting demands around
> >> styled text in messages, and doesn't think are yet any clean solutions;
> >> and
> >> this isn't one, either.
> >> Despite his concerns, Jonas acknowledges that this stimulated a great
> >> deal of improvement in UX by adding rich text to clients; but it was
> >> useful
> >> as an intermediate step, and we should now find a way to do it properly.
> >> Jonas would also prefer if this were on Informational-Active, rather than
> >> Standards Track.
> >> Daniel notes that this is only standardising something which clients
> >> already do in one form or another, and have done for years; it's not
> >> really
> >> in-body markdown because the formatting isn't removed, it's a suggestion
> >> on
> >> how to display emphasis that users are giving the text regardless -
> >> therefore it doesn't require opt-in/out. Dave knows it doesn't need
> >> signalling or negotiation, but thinks it would be nicer if it did -
> >> Daniel
> >> wouldn't be against adding a hint in the body to indicate use of message
> >> styling.
> >> Jonas replies to Daniel that, in that case, it doesn't really belong on
> >> the Standards Track; quoting XEP-0001, §3.1, "A Standards Track XEP
> >> defines
> >> … A wire protocol intended to be used as a standard part of XMPP
> >> technologies.", Jonas doesn't feel comfortable approving this for
> >> Standards
> >> Track, and even Informational would be stretching it, but is acceptable
> >> as
> >> a middle-ground; a non-XSF resource, such as ModernXMPP or similar, would
> >> be more fitting for UI things (which this is, according to Daniel's
> >> argument.)
> >> 
> >> Jonas: -1 (concerns mentioned above)
> >> Zash: -1 (agree with Jonas)
> >> Dave: +0
> >> Daniel: +1
> >> Georg: [pending]
> >> 
> >> The author, Sam, views the use of a "styling hint" as unnecessary bloat;
> >> Sam also took care to make sure the grammar was well-defined so a
> >> compliant
> >> parser can be written; also feels strongly that it belongs on the
> >> Standards
> >> Track.
> >> Zash thinks that overloading the body without negotiation is problematic
> >> - Dave queries whether negotiation or hinting would be preferable - Zash
> >> thinks either would be better than nothing.
> >> Jonas could be persuaded to accept overloading the body in this specific
> >> way if and only if an opt-in is given; and if an opt-in is present then
> >> it's more clearly wire protocol and belongs on the Standards Track; the
> >> lack of formal grammar isn't blocking, as long as implementers agree that
> >> it's doable without one (which is more an issue for Final.)
> >> Sam says it will never be opt-in, as that defeats the point - the very
> >> reason it got wide adoption is because it wasn't opt-in, it simply
> >> documents how to apply styling to what users already do; it could be
> >> opt-out per message, but that's all he would be comfortable with - opt-in
> >> is the only thing Jonas would be comfortable with.
> >> Dave says the inclusion of a styling hint for opt-in would move his vote
> >> to +1, and opt-out would be great too. Zash is also fine with this. Jonas
> >> concludes this is a clear way forward for the author.
> >> Sam intends to add the opt-out hint, but is absolutely against adding
> >> opt-in as it would completely break the point of this - it makes this
> >> much
> >> harder to implement and much less consistent.
> >> Jonas tries to get things back on-track, and directs further discussion
> >> on this elsewhere.
> > 
> > I'll try to summarise this as best I can, and then look for a consensus to
> > advance the document.
> > 
> > The status quo is that a considerable number of clients by deployment
> > already look for things like *this* and apply styling. A considerable
> > number of users will type things like *this* irrespective of client
> > support, and have done for literally decades.
> > 
> > So from that perspective, *at least* an informational document seems
> > useful. (I will avoid the meta-argument over whether this is a wire
> > protocol or a UX hint; I maintain this is a distinction without much
> > merit).
> > 
> > Sam's 

Re: [Standards] Council Minutes 2020-05-27

[Kozlov Konstantin]

01.06.2020, 14:31, "Andrew Nenakhov" :пн, 1 июн. 2020 г. в 16:02, Kozlov Konstantin : That's nice, that this XEP wasn't advanced yet. This encourages me to fore work on XEP-0394: Message Markup, which I beleive is much better and has more potential, than this one. I'll do my best to post updates to it soon and start implementing it in eyeCU, once I finish implementation of OMEMO. I hope it will encourage other developers to implement it in their client software instead of this one.yeah, and we've strengthened our resolve to work on our (yet another)reference-based markup extension, because it is very consistent, worksgreat with group chats, makes it easy to process markup, mentions,filter attached media, stickers, etc. ¯\_(ツ)_/¯That's nice. I hope, once I publish a new revision of XEP-0394, you'll send your suggestions to make your solution compatible with it.___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Council Minutes 2020-05-27

[Paul Schaub]

01.06.2020 13:31:39 Andrew Nenakhov :
> yeah, and we've strengthened our resolve to work on our (yet another)
> reference-based markup extension, because it is very consistent, works
> great with group chats, makes it easy to process markup, mentions,
> filter attached media, stickers, etc.  ¯\_(ツ)_/¯

ProtoXEP or didn't happen ;)

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Council Minutes 2020-05-27

[Andrew Nenakhov]

пн, 1 июн. 2020 г. в 16:02, Kozlov Konstantin :
> That's nice, that this XEP wasn't advanced yet. This encourages me to fore 
> work on XEP-0394: Message Markup, which I beleive is much better and has more 
> potential, than this one. I'll do my best to post updates to it soon and 
> start implementing it in eyeCU, once I finish implementation of OMEMO.
> I hope it will encourage other developers to implement it in their client 
> software instead of this one.

yeah, and we've strengthened our resolve to work on our (yet another)
reference-based markup extension, because it is very consistent, works
great with group chats, makes it easy to process markup, mentions,
filter attached media, stickers, etc.  ¯\_(ツ)_/¯



-- 
Andrew Nenakhov
CEO, redsolution, OÜ
https://redsolution.com
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Council Minutes 2020-05-27

[Kozlov Konstantin]

Hello! 01.06.2020, 01:53, "Tedd Sterr" : 4c) Advance XEP-0393 (Message Styling) -  https://xmpp.org/extensions/xep-0393.htmlDave quite likes this, but is aware that many people don't.Jonas has a multitude of concerns: community recommendations for an explicit opt-in switch; no way to replace this with an updated or new variant, due to a lack of explicit signalling; putting 'markup' in the body is not the way to go in XMPP (more a weak, purity argument); it should mention security concerns about using existing markdown parsers, even if they're not necessarily 100% compatible; lack of an explicit grammar for writing a compliant parser.Dave sees the problem of there being many conflicting demands around styled text in messages, and doesn't think are yet any clean solutions; and this isn't one, either.Despite his concerns, Jonas acknowledges that this stimulated a great deal of improvement in UX by adding rich text to clients; but it was useful as an intermediate step, and we should now find a way to do it properly. Jonas would also prefer if this were on Informational-Active, rather than Standards Track.Daniel notes that this is only standardising something which clients already do in one form or another, and have done for years; it's not really in-body markdown because the formatting isn't removed, it's a suggestion on how to display emphasis that users are giving the text regardless - therefore it doesn't require opt-in/out. Dave knows it doesn't need signalling or negotiation, but thinks it would be nicer if it did - Daniel wouldn't be against adding a hint in the body to indicate use of message styling.Jonas replies to Daniel that, in that case, it doesn't really belong on the Standards Track; quoting XEP-0001, §3.1, "A Standards Track XEP defines … A wire protocol intended to be used as a standard part of XMPP technologies.", Jonas doesn't feel comfortable approving this for Standards Track, and even Informational would be stretching it, but is acceptable as a middle-ground; a non-XSF resource, such as ModernXMPP or similar, would be more fitting for UI things (which this is, according to Daniel's argument.) Jonas: -1 (concerns mentioned above)Zash: -1 (agree with Jonas)Dave: +0Daniel: +1Georg: [pending] The author, Sam, views the use of a "styling hint" as unnecessary bloat; Sam also took care to make sure the grammar was well-defined so a compliant parser can be written; also feels strongly that it belongs on the Standards Track.Zash thinks that overloading the body without negotiation is problematic - Dave queries whether negotiation or hinting would be preferable - Zash thinks either would be better than nothing.Jonas could be persuaded to accept overloading the body in this specific way if and only if an opt-in is given; and if an opt-in is present then it's more clearly wire protocol and belongs on the Standards Track; the lack of formal grammar isn't blocking, as long as implementers agree that it's doable without one (which is more an issue for Final.)Sam says it will never be opt-in, as that defeats the point - the very reason it got wide adoption is because it wasn't opt-in, it simply documents how to apply styling to what users already do; it could be opt-out per message, but that's all he would be comfortable with - opt-in is the only thing Jonas would be comfortable with.Dave says the inclusion of a styling hint for opt-in would move his vote to +1, and opt-out would be great too. Zash is also fine with this. Jonas concludes this is a clear way forward for the author.Sam intends to add the opt-out hint, but is absolutely against adding opt-in as it would completely break the point of this - it makes this much harder to implement and much less consistent.Jonas tries to get things back on-track, and directs further discussion on this elsewhere.That's nice, that this XEP wasn't advanced yet. This encourages me to fore work on XEP-0394: Message Markup, which I beleive is much better and has more potential, than this one. I'll do my best to post updates to it soon and start implementing it in eyeCU, once I finish implementation of OMEMO.I hope it will encourage other developers to implement it in their client software instead of this one.___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Council Minutes 2020-05-27

[Dave Cridland]

On Mon, 1 Jun 2020 at 09:19, Dave Cridland  wrote:

>
>
> On Sun, 31 May 2020 at 23:50, Tedd Sterr  wrote:
>
>> *4c) Advance XEP-0393 (Message Styling)* -
>> https://xmpp.org/extensions/xep-0393.html
>> Dave quite likes this, but is aware that many people don't.
>> Jonas has a multitude of concerns: community recommendations for an
>> explicit opt-in switch; no way to replace this with an updated or new
>> variant, due to a lack of explicit signalling; putting 'markup' in the body
>> is not the way to go in XMPP (more a weak, purity argument); it should
>> mention security concerns about using existing markdown parsers, even if
>> they're not necessarily 100% compatible; lack of an explicit grammar for
>> writing a compliant parser.
>> Dave sees the problem of there being many conflicting demands around
>> styled text in messages, and doesn't think are yet any clean solutions; and
>> this isn't one, either.
>> Despite his concerns, Jonas acknowledges that this stimulated a great
>> deal of improvement in UX by adding rich text to clients; but it was useful
>> as an intermediate step, and we should now find a way to do it properly.
>> Jonas would also prefer if this were on Informational-Active, rather than
>> Standards Track.
>> Daniel notes that this is only standardising something which clients
>> already do in one form or another, and have done for years; it's not really
>> in-body markdown because the formatting isn't removed, it's a suggestion on
>> how to display emphasis that users are giving the text regardless -
>> therefore it doesn't require opt-in/out. Dave knows it doesn't need
>> signalling or negotiation, but thinks it would be nicer if it did - Daniel
>> wouldn't be against adding a hint in the body to indicate use of message
>> styling.
>> Jonas replies to Daniel that, in that case, it doesn't really belong on
>> the Standards Track; quoting XEP-0001, §3.1, "A Standards Track XEP defines
>> … A wire protocol intended to be used as a standard part of XMPP
>> technologies.", Jonas doesn't feel comfortable approving this for Standards
>> Track, and even Informational would be stretching it, but is acceptable as
>> a middle-ground; a non-XSF resource, such as ModernXMPP or similar, would
>> be more fitting for UI things (which this is, according to Daniel's
>> argument.)
>>
>> Jonas: -1 (concerns mentioned above)
>> Zash: -1 (agree with Jonas)
>> Dave: +0
>> Daniel: +1
>> Georg: [pending]
>>
>> The author, Sam, views the use of a "styling hint" as unnecessary bloat;
>> Sam also took care to make sure the grammar was well-defined so a compliant
>> parser can be written; also feels strongly that it belongs on the Standards
>> Track.
>> Zash thinks that overloading the body without negotiation is problematic
>> - Dave queries whether negotiation or hinting would be preferable - Zash
>> thinks either would be better than nothing.
>> Jonas could be persuaded to accept overloading the body in this specific
>> way if and only if an opt-in is given; and if an opt-in is present then
>> it's more clearly wire protocol and belongs on the Standards Track; the
>> lack of formal grammar isn't blocking, as long as implementers agree that
>> it's doable without one (which is more an issue for Final.)
>> Sam says it will never be opt-in, as that defeats the point - the very
>> reason it got wide adoption is because it wasn't opt-in, it simply
>> documents how to apply styling to what users already do; it could be
>> opt-out per message, but that's all he would be comfortable with - opt-in
>> is the only thing Jonas would be comfortable with.
>> Dave says the inclusion of a styling hint for opt-in would move his vote
>> to +1, and opt-out would be great too. Zash is also fine with this. Jonas
>> concludes this is a clear way forward for the author.
>> Sam intends to add the opt-out hint, but is absolutely against adding
>> opt-in as it would completely break the point of this - it makes this much
>> harder to implement and much less consistent.
>> Jonas tries to get things back on-track, and directs further discussion
>> on this elsewhere.
>>
>
> I'll try to summarise this as best I can, and then look for a consensus to
> advance the document.
>
> The status quo is that a considerable number of clients by deployment
> already look for things like *this* and apply styling. A considerable
> number of users will type things like *this* irrespective of client
> support, and have done for literally decades.
>
> So from that perspective, *at least* an informational document seems
> useful. (I will avoid the meta-argument over whether this is a wire
> protocol or a UX hint; I maintain this is a distinction without much merit).
>
> Sam's position is, as I understand it, that this status quo should simply
> be recognised.
>
> Others (Jonas for example) feel that it presents sufficient problems that
> it ought not to be presented as a recommended standard.
>
> The suggestion offered is to add one of two hints - in the 

Re: [Standards] Council Minutes 2020-05-27

[Dave Cridland]

On Sun, 31 May 2020 at 23:50, Tedd Sterr  wrote:

> *4c) Advance XEP-0393 (Message Styling)* -
> https://xmpp.org/extensions/xep-0393.html
> Dave quite likes this, but is aware that many people don't.
> Jonas has a multitude of concerns: community recommendations for an
> explicit opt-in switch; no way to replace this with an updated or new
> variant, due to a lack of explicit signalling; putting 'markup' in the body
> is not the way to go in XMPP (more a weak, purity argument); it should
> mention security concerns about using existing markdown parsers, even if
> they're not necessarily 100% compatible; lack of an explicit grammar for
> writing a compliant parser.
> Dave sees the problem of there being many conflicting demands around
> styled text in messages, and doesn't think are yet any clean solutions; and
> this isn't one, either.
> Despite his concerns, Jonas acknowledges that this stimulated a great deal
> of improvement in UX by adding rich text to clients; but it was useful as
> an intermediate step, and we should now find a way to do it properly. Jonas
> would also prefer if this were on Informational-Active, rather than
> Standards Track.
> Daniel notes that this is only standardising something which clients
> already do in one form or another, and have done for years; it's not really
> in-body markdown because the formatting isn't removed, it's a suggestion on
> how to display emphasis that users are giving the text regardless -
> therefore it doesn't require opt-in/out. Dave knows it doesn't need
> signalling or negotiation, but thinks it would be nicer if it did - Daniel
> wouldn't be against adding a hint in the body to indicate use of message
> styling.
> Jonas replies to Daniel that, in that case, it doesn't really belong on
> the Standards Track; quoting XEP-0001, §3.1, "A Standards Track XEP defines
> … A wire protocol intended to be used as a standard part of XMPP
> technologies.", Jonas doesn't feel comfortable approving this for Standards
> Track, and even Informational would be stretching it, but is acceptable as
> a middle-ground; a non-XSF resource, such as ModernXMPP or similar, would
> be more fitting for UI things (which this is, according to Daniel's
> argument.)
>
> Jonas: -1 (concerns mentioned above)
> Zash: -1 (agree with Jonas)
> Dave: +0
> Daniel: +1
> Georg: [pending]
>
> The author, Sam, views the use of a "styling hint" as unnecessary bloat;
> Sam also took care to make sure the grammar was well-defined so a compliant
> parser can be written; also feels strongly that it belongs on the Standards
> Track.
> Zash thinks that overloading the body without negotiation is problematic -
> Dave queries whether negotiation or hinting would be preferable - Zash
> thinks either would be better than nothing.
> Jonas could be persuaded to accept overloading the body in this specific
> way if and only if an opt-in is given; and if an opt-in is present then
> it's more clearly wire protocol and belongs on the Standards Track; the
> lack of formal grammar isn't blocking, as long as implementers agree that
> it's doable without one (which is more an issue for Final.)
> Sam says it will never be opt-in, as that defeats the point - the very
> reason it got wide adoption is because it wasn't opt-in, it simply
> documents how to apply styling to what users already do; it could be
> opt-out per message, but that's all he would be comfortable with - opt-in
> is the only thing Jonas would be comfortable with.
> Dave says the inclusion of a styling hint for opt-in would move his vote
> to +1, and opt-out would be great too. Zash is also fine with this. Jonas
> concludes this is a clear way forward for the author.
> Sam intends to add the opt-out hint, but is absolutely against adding
> opt-in as it would completely break the point of this - it makes this much
> harder to implement and much less consistent.
> Jonas tries to get things back on-track, and directs further discussion on
> this elsewhere.
>

I'll try to summarise this as best I can, and then look for a consensus to
advance the document.

The status quo is that a considerable number of clients by deployment
already look for things like *this* and apply styling. A considerable
number of users will type things like *this* irrespective of client
support, and have done for literally decades.

So from that perspective, *at least* an informational document seems
useful. (I will avoid the meta-argument over whether this is a wire
protocol or a UX hint; I maintain this is a distinction without much merit).

Sam's position is, as I understand it, that this status quo should simply
be recognised.

Others (Jonas for example) feel that it presents sufficient problems that
it ought not to be presented as a recommended standard.

The suggestion offered is to add one of two hints - in the interest of
finding a consensus here, I'll suggest some concrete text as a starter:

Implementations of this specification MUST add one of two hints:

 - This