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] XMPP Council Agenda 2020-06-03

[Jonas Schäfer]

Addition:

On Dienstag, 2. Juni 2020 16:29:30 CEST you wrote:
> 7) AOB

7a) XEP-0050: The 'execute' problem

We should, before the CFE concludes (and potentially re-issuing it 
afterwards), think about what to do about that. Tedd Sterr helpfully compiled 
a summary here: 

https://mail.jabber.org/pipermail/standards/2020-May/037489.html

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
___

[Standards] XMPP Council Agenda 2020-06-03

[Jonas Schäfer]

Hi everyone,

The next XMPP Council Meeting will take place on 2020-06-03 at 15:00Z in 
xmpp:coun...@muc.xmpp.org?join. Everyone is welcome to join and add to the 
discussions.

This agenda is composed from:

- Editor notifications to standards@
- xsf/xeps GitHub PRs marked as Needs Council
- Suggestions directly sent to me (see below)

Agenda as follows:

1) Roll Call

2) Agenda Bashing

* Feel free to pre-bash on-list or directly to me if you think something is 
missing.

3) Editor’s Update

- Calls in Progress

  - CFE for XEP-0050 (ends at 2020-06-09)


4) Items for voting

None.

5) Outstanding Votes

Georg has some.

6) Date of Next

7) AOB

8) Close

End of Agenda.

Note that I am aiming for 30 minutes, but meetings may be extended as 
necessary if all council members agree.

Meetings are normally held every Wednesday at 15:00 UTC in the 
xmpp:coun...@muc.xmpp.org?join chatroom.
Meetings are open, and anyone (XSF Member or not) may attend, though only XMPP 
Council members may vote. Relevant comments from the floor are welcomed.

Using your web browser, you can join anonymously via
https://xmpp.org/chat?council

Note that conversations in the room are logged publicly at
https://logs.xmpp.org/council/

If you have suggestions for an agenda item, you can message me via XMPP or 
email at this address or at jo...@zombofant.net.

I aim to publish the Agenda on the day before the Council meeting before 
19:00Z.


Thanks everyone,
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
___

[Standards] UPDATED: XEP-0393 (Message Styling)

[XSF Editor]

Version 0.3.0 of XEP-0393 (Message Styling) has been released.

Abstract:
This specification defines a formatted text syntax for use in instant
messages with simple text styling.

Changelog:

Add ability to disable styling, further clarify accessibility
considerations, and mention that Styling is not Markdown in
the security
considerations section.
   (ssw)

URL: https://xmpp.org/extensions/xep-0393.html

Note: The information in the XEP list at https://xmpp.org/extensions/
is updated by a separate automated process and may be stale at the
time this email is sent. The XEP documents linked herein are up-to-
date.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] UPDATED: XEP-0424 (Message Retraction)

[XSF Editor]

Version 0.3.0 of XEP-0424 (Message Retraction) has been released.

Abstract:
This specification defines a method for indicating that a message
should be retracted.

Changelog:
* Clarify when a service must advertise support via disco.
* Add another service discovery URN for tombstones. (jcb)

URL: https://xmpp.org/extensions/xep-0424.html

Note: The information in the XEP list at https://xmpp.org/extensions/
is updated by a separate automated process and may be stale at the
time this email is sent. The XEP documents linked herein are up-to-
date.
___
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
___