Re: [Standards] Proposed XMPP Extension: Styling

[Sam Whited]

On Wed, Nov 15, 2017, at 04:06, Mathieu Pasquet wrote:
> One thing that bugs me is that this XEP is supposed to specify the
> existing behavior of several clients regarding various pieces of markup
> (Gajim, Psi, etc…), but on the other hand it does not exactly match with
> either (from what I remember of gajim inline markup, at least). Even
> then, Conversations implemented it while it previously only had support
> for the blockquote feature. The other clients will probably need to be
> updated to match the featureset and the rules defined in the XEP, so it
> will not be compatible with the already existing deployments.

Unfortunately there was no single formatting in use across clients that
I tried, so I went with the one that seemed most widely spread (or at
least, something similar to it). This wasn't really meant to be a
historical XEP that documents existing functionality, it was supposed to
be a new styling system and I just took cues from what people were
already doing when writing it up. The ideas was to make it a standards
track XEP (not historical or informational). I'm not against changing
that, but I do have a feeling standards track makes the most sense.

Right now there is fragmentation among clients, hopefully this standard
can reduce that fragmentation (eventually, it's not likely to happen
overnight).

> - Section 4 is somewhat insufficient, it does not make a case for
>   styling being both an input and a wire format at the same time

Users don't really care what the wire format is, and the use cases are
mostly about users. I agree this could use some expanding though, and
I'd love suggestions.

> - In 5.7, I don't understand example 5, why is there an "ignored", is it
>   ignored by the rendering? why?

Oops, that looks like a mistake. We'd talked about making all text on
the same line as the opening ``` ignored but I appear to have added it
to an example but not to the text. Thanks!

> - In 5.8, I think having blockquotes start with "> " (spaced) and not ">" 
>   would be better, as we can already see conversations quoting "><"
>   smileys.

This seems sensible; it does mean that nested block quotes would have to
be special cased, or the definition of block quote changed to include
the "level" of the quote. I'll think about how best to reword this.

> - In section 7, accessibility, there is no way to make this kind of
>   thing accessible to existing clients, because they have to support the
>   XEP to exclude formatting characters from being read.

I do not think this is an accessibility concern, maybe a UI issue
though. However, the plain text version of formatting sent using this
specification is probably readable enough. People are used to quotes
from email and type *emphasis* all the time. The others are easy enough
to understand (or at least don't hinder readability).


> - On section 9, there should be a grammar, or a reference implementation
>   developers can use or check against

I will try to add something later on in the process; that does seem
reasonable to have.

> otherwise I don't see how that
>   will solve any of the security issues we had in XHTML-IM. (this is
>   close enough to a subset of markdown that some people will be tempted
>   to use on of the existing parsers, most of which allow inline HTML)

This is not compatible with markdown, many of the symbols are different
so using a markdown library is probably not an option.

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

Re: [Standards] Proposed XMPP Extension: Styling

[Sam Whited]

Hi all,

There seems to have been some heated discussion last night and I'd like
to address a few things where there seems to be some confusion:

The act of accepting an XEP does not instantly make it the one-true-way
to do things. Experimental XEPs are exactly that, experimental. They
might catch on, be expanded, and eventually become XSF recommendations,
or they might not. ProtoXEPs are not accepted as XEPs because someone on
the council wants them to be, in fact a number of protoxeps have been
accepted that I or others think are actually pretty bad. They're
accepted because they are worth exploring or and most ideas, even if we
don't especially like them, aren't worthy of being rejected out of hand
(there are of course exceptions to every rule, but if there's generally
disagreement about a topic that's probably a sign that it's not an
exception and we should see the discussion through to the end). Most of
the discussion happening here is the sort of discussion that should
happen *after* a proposal has already become an XEP.

Also, please refrain from ad hominem attacks against other people, or
the council. It is not helpful.

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

Re: [Standards] Proposed XMPP Extension: Styling

[Jonas Wielicki]

On Mittwoch, 15. November 2017 11:06:16 CET Mathieu Pasquet wrote:
> - In 5.8, I think having blockquotes start with "> " (spaced) and not ">" 
>   would be better, as we can already see conversations quoting "><" smileys.

A huge plus one for that, even though it requires additional rules for nested 
blockquotes, if that’s a thing.

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] Proposed XMPP Extension: Styling

[Kozlov Konstantin]

Sounds reassuring. I guess I'll try to join the Council next time.15.11.2017, 10:49, "Jonas Wielicki" :On Mittwoch, 15. November 2017 10:32:29 CET Evgeny Khramtsov wrote: 1) no matter what arguments you bring if a Council member wants it, it will be merged making all XSF discussions pointlessThat is in fact incorrect. The whole council needs to be convinced, since voting is veto-based. A single "-1" counters a proposal.(This doesn’t touch your point on trend-making apps and de-facto standards though.),___Standards mailing listInfo: https://mail.jabber.org/mailman/listinfo/standardsUnsubscribe: standards-unsubscr...@xmpp.org__
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Styling

[Mathieu Pasquet]

On Mon, Nov 06, 2017 at 11:58:15AM -0600, Sam Whited wrote:
> The XMPP Extensions Editor has received a proposal for a new XEP.
> 
> Title: Styling
> 
> Abstract:
> 
> > This specification defines a plain-text formatting syntax for use in
> > exchanging instant messages with simple text styling.
> 
> URL: https://xmpp.org/extensions/inbox/styling.html
> 
> The Council will decide in the next two weeks whether to accept this
> proposal as an official XEP.
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___


Hi,

Thanks for taking the time to write this. I do like that it strictly
defines a few ways to format text and blocks, without leaving too much
leeway to implementors.

I still think putting markup in the  is a terrible idea that
is not detectable or extensible, and proprietary clients get away
with it only because they are in control of the client and server
infrastructure.

One thing that bugs me is that this XEP is supposed to specify the
existing behavior of several clients regarding various pieces of markup
(Gajim, Psi, etc…), but on the other hand it does not exactly match with
either (from what I remember of gajim inline markup, at least). Even
then, Conversations implemented it while it previously only had support
for the blockquote feature. The other clients will probably need to be
updated to match the featureset and the rules defined in the XEP, so it
will not be compatible with the already existing deployments.

If it's supposed to be informational (or historical), then it should not
require additional development time or client updates; if it is something
clients should implement in the future, then I don’t see how the
existing, inconsistent behavior of current clients regarding inline
markup is supposed to help this XEP.

I’m in favor of the BMH-not-BMH suggested by Jonas, but I think it’s an
awful solution to a problem we should not have (interpreting the body as
something it is not). And it won't do a thing for clients that don't
support this rendering.

On the technical content of the XEP:

- Section 4 is somewhat insufficient, it does not make a case for
  styling being both an input and a wire format at the same time

- In 5.7, I don't understand example 5, why is there an "ignored", is it
  ignored by the rendering? why?

- In 5.8, I think having blockquotes start with "> " (spaced) and not ">" 
  would be better, as we can already see conversations quoting "><" smileys.

- In section 7, accessibility, there is no way to make this kind of
  thing accessible to existing clients, because they have to support the
  XEP to exclude formatting characters from being read.

- On section 9, there should be a grammar, or a reference implementation
  developers can use or check against, otherwise I don't see how that
  will solve any of the security issues we had in XHTML-IM. (this is
  close enough to a subset of markdown that some people will be tempted
  to use on of the existing parsers, most of which allow inline HTML)


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

Re: [Standards] Proposed XMPP Extension: Styling

[Dave Cridland]

On 15 November 2017 at 09:15, Goffi  wrote:
> Good morning/evening/day eveybody
>
> Le mercredi 15 novembre 2017, 09:54:07 CET Dave Cridland a écrit :
>> Conversations is following an existing trend. Sam has merely documented it,
>> and we're trying to ensure that the downsides of this approach - and I
>> don't think anyone pretends there aren't any - are mitigated.
>>
>> This is not ideal, it is not perfect, but I think we're well into von
>> Clausevitz territory[1], and the question should be whether we can control
>> the inevitable damage.
>
> So shouldn't the type of the XEP (if it becomes one) be "informational"
> instead? At least this show this is not a good practice supported by the
> community.
>

I don't care hugely what type it is, though to suggest its entirely
unsupported by the community suggests that Spark, Gajim, Psi and
Conversations are not part of this community, which I would hold to be
demonstrably incorrect.

> And please if it really do through the official number, add on "opt-in"
> mechanism as previously discussed (this is still not in the protoXEP).

As an aside, I really hate working on XEPs before we accept them.
However, this might fall closely enough under the "wrong approach"
criteria that I can be persuaded.

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

Re: [Standards] Proposed XMPP Extension: Styling

[Goffi]

Good morning/evening/day eveybody

Le mercredi 15 novembre 2017, 09:54:07 CET Dave Cridland a écrit :
> Conversations is following an existing trend. Sam has merely documented it,
> and we're trying to ensure that the downsides of this approach - and I
> don't think anyone pretends there aren't any - are mitigated.
> 
> This is not ideal, it is not perfect, but I think we're well into von
> Clausevitz territory[1], and the question should be whether we can control
> the inevitable damage.

So shouldn't the type of the XEP (if it becomes one) be "informational" 
instead? At least this show this is not a good practice supported by the 
community.

And please if it really do through the official number, add on "opt-in" 
mechanism as previously discussed (this is still not in the protoXEP).

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

Re: [Standards] Proposed XMPP Extension: Styling

[Evgeny Khramtsov]

Wed, 15 Nov 2017 08:54:07 +
Dave Cridland  wrote:

> Conversations is following an existing trend. Sam has merely
> documented it, and we're trying to ensure that the downsides of this
> approach - and I don't think anyone pretends there aren't any - are
> mitigated.

Fine. Then, according to XSF policy, you should mark this XEP as
"Historical".
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Styling

[Dave Cridland]

On 15 Nov 2017 07:44, "Evgeny Khramtsov"  wrote:

Wed, 15 Nov 2017 09:21:22 +0300
Kozlov Konstantin  wrote:

> I hope the Council will never accept such inconsistent thing as an
> official XEP.

Too late, it's already implemented in Conversations and, since it's
kinda a trend maker, this stuff will stick around. Which is sad,
because:
1) no matter what arguments you bring if a Council member wants
it, it will be merged making all XSF discussions pointless
2) a trend making app is a bad thing: all IT is suffering because of
this and the consequence is hyped adopted technologies (like
Markdown and the whole HTML5 pile of shit) which sucks in technical
sense.


I agree with your second point, although not with both your examples.

While I dislike much of HTML 5, for example, it's demonstrably a de facto
standard, and this is better than fragmentation.

Finally, Conversations might have implemented this, yes, but both Gajim and
Psi have implemented something similar for years. Over a decade, I believe.
Guus implemented it in Spark in very short time, too. Conversations is not
setting a trend here, but following one.

Conversations is following an existing trend. Sam has merely documented it,
and we're trying to ensure that the downsides of this approach - and I
don't think anyone pretends there aren't any - are mitigated.

This is not ideal, it is not perfect, but I think we're well into von
Clausevitz territory[1], and the question should be whether we can control
the inevitable damage.

Dave.

1 - "The enemy of the good plan is the dream of the perfect one".

___
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] Proposed XMPP Extension: Styling

[Guus der Kinderen]

On a side-note: please try to keep discussions positive. Not only does that
make for a friendlier conversation, arguments are much more likely to be
taken into consideration if you don't start off by putting people off.


On 15 November 2017 at 08:45, Evgeny Khramtsov  wrote:

> Wed, 15 Nov 2017 08:48:42 +0100
> Jonas Wielicki  wrote:
>
> > That is in fact incorrect. The whole council needs to be convinced,
> > since voting is veto-based. A single "-1" counters a proposal.
>
> Oh, we have a hope
> ___
> 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] Proposed XMPP Extension: Styling

[Evgeny Khramtsov]

Wed, 15 Nov 2017 08:48:42 +0100
Jonas Wielicki  wrote:

> That is in fact incorrect. The whole council needs to be convinced,
> since voting is veto-based. A single "-1" counters a proposal.

Oh, we have a hope
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Styling

[Jonas Wielicki]

On Mittwoch, 15. November 2017 10:32:29 CET Evgeny Khramtsov wrote:
> 1) no matter what arguments you bring if a Council member wants
> it, it will be merged making all XSF discussions pointless

That is in fact incorrect. The whole council needs to be convinced, since 
voting is veto-based. A single "-1" counters a proposal.

(This doesn’t touch your point on trend-making apps and de-facto standards 
though.)


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] Proposed XMPP Extension: Styling

[Evgeny Khramtsov]

Wed, 15 Nov 2017 09:21:22 +0300
Kozlov Konstantin  wrote:

> I hope the Council will never accept such inconsistent thing as an
> official XEP.

Too late, it's already implemented in Conversations and, since it's
kinda a trend maker, this stuff will stick around. Which is sad,
because:
1) no matter what arguments you bring if a Council member wants
it, it will be merged making all XSF discussions pointless
2) a trend making app is a bad thing: all IT is suffering because of
this and the consequence is hyped adopted technologies (like
Markdown and the whole HTML5 pile of shit) which sucks in technical
sense.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Styling

[Kozlov Konstantin]

  06.11.2017, 22:19, "Emmanuel Gil Peyrot" :On Mon, Nov 06, 2017 at 11:58:15AM -0600, Sam Whited wrote:People have been telling you countless times on standards@ thatembedding raw markup in the body is an extremely bad idea, with manyexamples.Markdown(-like) is NOT a plain text format, having the receiving clientchoose between rendering all formatting characters or stripping them isstupid, and requiring humans to mentally strip them out in olderclients is stupid; have you not seen the mess that OTR is for example?There is exactly no extensibility in this proposal, if tomorrow thetrend changes you will end up with all users of clients implementing itnot understanding what’s going on.Formatting really should be in a separate payload, so that clientswhich don’t understand it can use the plain text version and safelyignore the formatted one.And again, this XEP does not address any of the issues with XHTML-IM,web people will just pipe this through the first Markdown library andget rendering wrong, get more elements than listed here, and get a nicepassthrough of escaped HTML.   URL: https://xmpp.org/extensions/inbox/styling.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP.Sorry for the rant, --Emmanuel Gil PeyroAbsolutely agree with each statement.The whole idea sounds awful. I hope the Council will never accept such inconsistent thing as an official XEP. With my best regards,Konstantin___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Styling

[Sam Whited]

I'd like to specifically request feedback on the (currently empty)
internationalization and security considerations sections. Are there any
specific internationalization or security concerns that need to be
addressed in this spec?

I couldn't think of anything, but I'd like to hear from others.

Thanks!

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

Re: [Standards] Proposed XMPP Extension: Styling

[Sam Whited]

On November 10, 2017 7:32:24 AM CST, Daniel Gultsch  wrote:
>I think we can eliminate some false positives by requiring that a
>closing keyword is not preceded by a white space character.

That sounds sensible, I'll push an update later today.

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

Re: [Standards] Proposed XMPP Extension: Styling

[Daniel Gultsch]

Hi,


since this is now implemented in Conversations first rounds of
feedback are rolling in.

I think we can eliminate some false positives by requiring that a
closing keyword is not preceded by a white space character. I don't
think this will introduce any unwanted side effects however it makes
the XEP a tiny bit more complicated in that we have to define if a
'false close', meaning an unexpected close (whitespace+keyword) should
invalidate the block or should be ignored.

Let me give an example to make this clear. The question is whether
"*foo *bar*" should be interpreted as "foo *bar" or "foo bar"

Both slack and whatsapp interpret this as "foo *bar" which I
can get on board with.

Interestingly WhatsApp interprets "*foo *" as "*foo *" and Slack
interprets this as "foo ". However I think that WhatsApp has
the easier parser here because it will simply ignore all closing
keywords that are preceded by a whitespace. Meaning "*foo *bar*" and
"*foo *" can be handled by the same rule. While slack does something
strange here imho.

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

Re: [Standards] Proposed XMPP Extension: Styling

[Goffi]

Le mercredi 8 novembre 2017, 11:18:51 CET Jonas Wielicki a écrit :
> I think we also have to acknowledge that there are use-cases for much richer
> text, for example within the Social Network and Blog Federation interest
> groups (sorry if that name doesn’t quite fit). Those use-cases were covered
> by XHTML-IM before, and fail to be covered by BMH and Styling. Message
> Markup can cover those use-cases, if it gets extended into that direction,
> while helping to prevent the security issues of XHTML-IM. Please see the
> other thread for considerations about plaintext fallback.

I forgot to mention here: XHTML-IM is not sufficient for blogging, SàT and 
Movim use XHTML that we clean. I think in addition to current markup debate, 
we need a XEP for full XHTML implementation with security consideration, but 
that's a different story.

++
Goffi

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

Re: [Standards] Proposed XMPP Extension: Styling

[Jonas Wielicki]

On Mittwoch, 8. November 2017 11:58:57 CET Goffi wrote:
> Le mercredi 8 novembre 2017, 11:18:51 CET Jonas Wielicki a écrit :
> > On Mittwoch, 8. November 2017 10:58:06 CET Goffi wrote:
> > 
> > We’re having a nice, civil discussion in xsf@ right now about this, let me
> > summarize my current viewpoint on this (as author of the Message Markup
> > proposal):[SNIP]
> 
> Hi Jonas,
> 
> unfortunately I'm too busy now to follow that. The reason why I think style
> is not needed anymore is:
> 
> - if a client want to do styling, he knows it, and it just have to:
>   * use markup element as specified in https://xmpp.org/extensions/inbox/
> markup.html
>   * remove, or eventually keep the markup at its discretion

Styling is very useful as it essentially specifies a markup language. Thus we 
get consistent parsing across clients -- at least as long as Styling isn’t 
modified. As a bonus, this markup language codifies what is being typed into 
(presumably) millions of text boxes right now. Which is good (efficiency is a 
product of familiarity).


> - we can have an extension to markup to specify style-like syntax for markup
> characteres we can safely remove, as mentionned in other thread. The syntax
> can be exactly the one of style, this would not be an issue.

Exactly. I suggest we do that.


> - at the end, using markup with a style-like syntax is exactly like style at
> the only difference that a client doing that must add  element to
> specify were the styling is. 

This is what is going to happen, plus a hint that the body is also Styling 
markup. Which is good for entities which only support that for whatever 
reason.


> I would rather not have "*" and other "`" in
> the , but if it makes everybody happy it may be OK.

I think those are needed to have a proper plain-text fallback in any case. I 
am contemplating adding very precise rules for adding those characters to 
 when creating a  message. In addition, I plan to make those 
rulse compatible to Styling (i.e. so that Styling + markup messages are 
valid). This has the advantage that human users of clients not supporting 
Markup can better interpret received messages (Plain-text fallback).


> If we keep style with an attribute in addition to markup (and XHTML-IM at
> least for a while), we are just multiplying ways to do markup, and make the
> message parsing more complicated (and bug prone).

I don’t see any bug prone-ity here. In my client, I’ll choose whatever format 
I can support best (which would be something like markup > XHTML-IM > Styling) 
on the receiving side. On the sending side, I’d default to Styling (unless 
turned off by the user *or* if explicit markup has been used) + Markup. If a 
user wants to remove Styling-based markup from the message, they can do so 
with last message correction with a simple "Remove markup" button.


> The only reason I would see to keep style is for e2e encryption because
> OMEMO doesn't handle anything else that , and this is a bad reason :
> OMEMO needs to be fixed, and markup doesn't prevent using it.

We agree that OMEMO needs fixing in that regard. It isn’t a blocker for 
 in non-OMEMO conversations though.


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] Proposed XMPP Extension: Styling

[Goffi]

Le mercredi 8 novembre 2017, 11:18:51 CET Jonas Wielicki a écrit :
> On Mittwoch, 8. November 2017 10:58:06 CET Goffi wrote:

> We’re having a nice, civil discussion in xsf@ right now about this, let me
> summarize my current viewpoint on this (as author of the Message Markup
> proposal):[SNIP]

Hi Jonas,

unfortunately I'm too busy now to follow that. The reason why I think style is 
not needed anymore is:

- if a client want to do styling, he knows it, and it just have to:
* use markup element as specified in https://xmpp.org/extensions/inbox/
markup.html
* remove, or eventually keep the markup at its discretion

- we can have an extension to markup to specify style-like syntax for markup 
characteres we can safely remove, as mentionned in other thread. The syntax 
can be exactly the one of style, this would not be an issue.

- at the end, using markup with a style-like syntax is exactly like style at 
the only difference that a client doing that must add  element to 
specify were the styling is. I would rather not have "*" and other "`" in the 
, but if it makes everybody happy it may be OK.

If we keep style with an attribute in addition to markup (and XHTML-IM at 
least for a while), we are just multiplying ways to do markup, and make the 
message parsing more complicated (and bug prone).

The only reason I would see to keep style is for e2e encryption because OMEMO 
doesn't handle anything else that , and this is a bad reason : OMEMO 
needs to be fixed, and markup doesn't prevent using it.

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

Re: [Standards] Proposed XMPP Extension: Styling

[Daniel Gultsch]

2017-11-08 11:04 GMT+01:00 Georg Lukas :
> * Daniel Gultsch  [2017-11-08 10:40]:
>> I mild annoyance is that the sending client needs to support this. So
>> if i'm using mcabber which doesn't support styling I can never trigger
>> styling on the receiving side even if I, as a knowing user, know about
>> the syntax and the consequences of styling.
>
> What about the following compatibility proposal:
> - messages with a BMH(*) of "styling" get styled according to the
>   Styling XEP, and the markup characters are removed on display (but not
>   on copy)
> - messages without a BMH get rendered as markup with the markup
>   charachters in place (compatibility)
> - messages with a BMH of "plain" get rendered verbatim with no styling
>   applied (opt-out)

I'm afraid it will not be clear to the average user why styled
messages sometimes show the keywords and sometimes they don't.

I'd prefer one unified way to handle the keywords. And I think the
current consensus was to keep the keywords. (You can make them a bit
opaque which looks quite nice imho)

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

Re: [Standards] Proposed XMPP Extension: Styling

[Jonas Wielicki]

On Mittwoch, 8. November 2017 10:58:06 CET Goffi wrote:
> Le mercredi 8 novembre 2017, 10:39:49 CET Daniel Gultsch a écrit :
> > Reading this the first time I wasn't sure what you mean by opt-in.
> > 
> > But essentially you want each 'styled' message annotated by an  > xmlns="styling..."/> tag or something like that. And you want clients
> > to render those messages styled only if a message contains that tag.
> > 
> > I can get on board with this.
> > I mild annoyance is that the sending client needs to support this. So
> > if i'm using mcabber which doesn't support styling I can never trigger
> > styling on the receiving side even if I, as a knowing user, know about
> > the syntax and the consequences of styling.
> > 
> > But if this is required to get everyone happy I can accept this as a
> > compromise.
> 
> Hi Daniel,
> 
> regarding the new "Message Markup" proposal from Jonas I think there is
> little sense to keep pushing this styling one, the use case is covered and
> in a far better way (no markup in the body).

We’re having a nice, civil discussion in xsf@ right now about this, let me 
summarize my current viewpoint on this (as author of the Message Markup 
proposal):

- Styling fills a gap in the sense that it documents currently used input 
formats *and* provides a nice fallback for plain-text clients at the same 
time.

- It should be viewed as a docmuentation of the current status instead of a 
new markup format everyone is supposed to use from now on.

- Daniel agreed to an opt-in mechanism so that clients which did not intend to 
send Styling-ed messages don’t get their messages interpreted that way 
inadvertently.

- People pointed out rightfully so that Message Markup indeed contains 
something like markup in the body -- this is contradictory to the mission 
statement that it should not. I have a hard time to resolve this 
contradiction, but it boils down to "we need a plaintext fallback" and 
"plaintext fallback is hard to distinguish from markup language in many 
cases".

- I think that there’s merit in having something like the rejected Body Markup 
Hints as a more general mechanism and have Styling define the current use of 
intuitive ascii-based markup. This provides us with an opt-in mechanism and a 
common switch.

- I think we have to acknowledge that there are sources which emit a markup of 
a certain class (like what is documented in Styling, or even Markdown like the 
sources Florian quoted when proposing Body Markup Hints) which falls back to 
plaintext gracefully. We can make use of this property (which Message Markup 
does not necessarily have, and which XHTML-IM certainly does not) by leaving 
the markup in the  as plain-text fallback and at the same time 
conveying a hint how it can be formatted nicely.

  Examples of markup which falls back to plaintext gracefully: Markdown, 
  CommonMark, Styling.

  Counter-examples: XHTML, reStructuredText (sometimes), Markdown containing 
  HTML.

- I think we at the same time also have to acknowldege that there are sources 
which emit text which is really just plaintext (automated systems), and their 
messages must not be interpreted incorrectly as marked up.

- I think we also have to acknowledge that there are use-cases for much richer 
text, for example within the Social Network and Blog Federation interest 
groups (sorry if that name doesn’t quite fit). Those use-cases were covered by 
XHTML-IM before, and fail to be covered by BMH and Styling. Message Markup can 
cover those use-cases, if it gets extended into that direction, while helping 
to prevent the security issues of XHTML-IM. Please see the other thread for 
considerations about plaintext fallback.


I think that this discussion has helped me to better understand where I want 
to go with Message Markup, and I also think that both specifications plus 
possibly BMH should co-exist.


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] Proposed XMPP Extension: Styling

[Georg Lukas]

* Daniel Gultsch  [2017-11-08 10:40]:
> I mild annoyance is that the sending client needs to support this. So
> if i'm using mcabber which doesn't support styling I can never trigger
> styling on the receiving side even if I, as a knowing user, know about
> the syntax and the consequences of styling.

What about the following compatibility proposal:
- messages with a BMH(*) of "styling" get styled according to the
  Styling XEP, and the markup characters are removed on display (but not
  on copy)
- messages without a BMH get rendered as markup with the markup
  charachters in place (compatibility)
- messages with a BMH of "plain" get rendered verbatim with no styling
  applied (opt-out)

(*) BMH or an updated version that provides at least "plaintext" and
"styling" values.

A sending client could implement that by sending BMH="styling" by
default, and offering a "remove styling" button on the sent message,
which would send an LMC message with BMH="plain".

Georg
-- 
|| http://op-co.de ++  GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N  ++
|| gpg: 0x962FD2DE ||  o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+  ||
|| Ge0rG: euIRCnet ||  X(+++) tv+ b+(++) DI+++ D- G e h- r++ y?   ||
++ IRCnet OFTC OPN ||_||


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

Re: [Standards] Proposed XMPP Extension: Styling

[Goffi]

Le mercredi 8 novembre 2017, 10:39:49 CET Daniel Gultsch a écrit :

> Reading this the first time I wasn't sure what you mean by opt-in.
> 
> But essentially you want each 'styled' message annotated by an  xmlns="styling..."/> tag or something like that. And you want clients
> to render those messages styled only if a message contains that tag.
> 
> I can get on board with this.
> I mild annoyance is that the sending client needs to support this. So
> if i'm using mcabber which doesn't support styling I can never trigger
> styling on the receiving side even if I, as a knowing user, know about
> the syntax and the consequences of styling.
> 
> But if this is required to get everyone happy I can accept this as a
> compromise.

Hi Daniel,

regarding the new "Message Markup" proposal from Jonas I think there is little 
sense to keep pushing this styling one, the use case is covered and in a far 
better way (no markup in the body).

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

Re: [Standards] Proposed XMPP Extension: Styling

[Daniel Gultsch]

2017-11-07 19:29 GMT+01:00 Jonas Wielicki :
> This XEP is incompatible with *sending* clients (be they human or automated)
> which are not aware of it. I strongly advocate for an opt-in mechanism (at
> which point this is the rejected Body Markup Hints ProtoXEP, but with a custom
> markup) on each message; if that’s not gonna find consensus, I think an opt-
> out mechanism is the least which must be done.

Reading this the first time I wasn't sure what you mean by opt-in.

But essentially you want each 'styled' message annotated by an  tag or something like that. And you want clients
to render those messages styled only if a message contains that tag.

I can get on board with this.
I mild annoyance is that the sending client needs to support this. So
if i'm using mcabber which doesn't support styling I can never trigger
styling on the receiving side even if I, as a knowing user, know about
the syntax and the consequences of styling.

But if this is required to get everyone happy I can accept this as a compromise.

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

Re: [Standards] Proposed XMPP Extension: Styling

[Evgeny Khramtsov]

Tue, 7 Nov 2017 20:10:19 +
Dave Cridland  wrote:

> * The format is quite small, so a parser - while still a parser, with
> all that that entails - is about as simple as one could imagine.

Really? Can I use LALR parser for this? If yes, there should be a
YACC-like grammar I can use in my language, I don't want to spend time
on this.
Otherwise I will just take existing implementation and patch it.
Not everybody likes writing parsers.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Styling

[Goffi]

Le mardi 7 novembre 2017, 21:20:07 CET Dave Cridland a écrit :

> Well, no. XHTML-IM sends two message texts in the same message.
> Hopefully they might even have the same content.
> 
> In email, there's a method for sending "multipart/alternative" which
> is used for this, and both spammers and marketeers alike insert
> *different* content into each fork, to bypass or confuse
> content-checking or to take advantage of rendering quirks of clients.
> We've yet to deal with the security implications of that.
> 
> I'm thinking more like BMH (but probably constrained to a single format).
> 
> Dave.

It's not the first time I read this, but multi-content is not a specifity of 
XHTML-IM, the RFCs specifically allow multiple body (with different 
languages), so nothing new here.

There is also accessibility to take into account (plain text version is useful 
for screen readers).

That said, having a single message would not necessarily be a bad idea (I'm 
quite in favor of that actually), if it is correctly marked (which is not the 
case with current proposal).


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

Re: [Standards] Proposed XMPP Extension: Styling

[Jonas Wielicki]

On Dienstag, 7. November 2017 20:26:54 CET Dave Cridland wrote:
> On 7 November 2017 at 18:29, Jonas Wielicki  wrote:
> > On Montag, 6. November 2017 11:58:15 CET Sam Whited wrote:
> >> URL: https://xmpp.org/extensions/inbox/styling.html
> > 
> > This XEP is incompatible with *sending* clients (be they human or
> > automated) which are not aware of it. I strongly advocate for an opt-in
> > mechanism (at which point this is the rejected Body Markup Hints
> > ProtoXEP, but with a custom markup) on each message; if that’s not gonna
> > find consensus, I think an opt- out mechanism is the least which must be
> > done.
> 
> I agree that a simplified BMH is the right path here.
> 
> > I also still think that this XEP mixes input conventions with wire format
> > in a very unfortunate way. In the spirit of "complaining about things
> > this XEP is not trying to be is not going to help anyone", I am currently
> > preparing a another ProtoXEP.
> 
> And I look forward to it. But I think we may then end up with
> multipart/alternative, and I'm not wholly sure I want that.
> 
> * The content fork concept has proven a bit of a pain in email,
> whereas "subtle" formatting, like format-flowed, has worked very well.
> * We double the size of messages, by writing everything twice.
> * Such a design more or less requires content negotiation, which is a
> fine thing, but basically fails in MUC and similar cases.
> * By writing everything twice, we double the size of messages.

Lucky for you, it’s not multipart/alternative :-) (which we both agree is a 
terrible idea).

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] Proposed XMPP Extension: Styling

[Dave Cridland]

On 7 November 2017 at 18:29, Jonas Wielicki  wrote:
> On Montag, 6. November 2017 11:58:15 CET Sam Whited wrote:
>> URL: https://xmpp.org/extensions/inbox/styling.html
>
> This XEP is incompatible with *sending* clients (be they human or automated)
> which are not aware of it. I strongly advocate for an opt-in mechanism (at
> which point this is the rejected Body Markup Hints ProtoXEP, but with a custom
> markup) on each message; if that’s not gonna find consensus, I think an opt-
> out mechanism is the least which must be done.
>

I agree that a simplified BMH is the right path here.

> I also still think that this XEP mixes input conventions with wire format in a
> very unfortunate way. In the spirit of "complaining about things this XEP is
> not trying to be is not going to help anyone", I am currently preparing a
> another ProtoXEP.

And I look forward to it. But I think we may then end up with
multipart/alternative, and I'm not wholly sure I want that.

* The content fork concept has proven a bit of a pain in email,
whereas "subtle" formatting, like format-flowed, has worked very well.
* We double the size of messages, by writing everything twice.
* Such a design more or less requires content negotiation, which is a
fine thing, but basically fails in MUC and similar cases.
* By writing everything twice, we double the size of messages.

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

Re: [Standards] Proposed XMPP Extension: Styling

[Dave Cridland]

On 7 November 2017 at 18:15, Goffi  wrote:
> Le mardi 7 novembre 2017, 13:02:40 CET Dave Cridland a écrit :
>> On 6 November 2017 at 22:58, Goffi  wrote:
>> > As an exemple which could lead to big trouble, imagine a shell@ MUC room
>> > with>
>> > somebody pasting this code to explain something:
>> > ls `date +%Y-%m-%d`-*.xml
>>
>> We could include an indicator of how to interpret text - basically,
>> Florian Schmaus's recent suggestion tailored to this.
>>
>> Then you end up with:
>>
>> 1) Sender is plaintext -> Receiver does not style.
>> 2) Sender is styled, Receiver cannot style -> Receiver does not style.
>> 3) Sender is styled, Receiver can style -> Receiver styles.
>>
>> (Note in case (1), whether the Receiver can style or not is irrelevant).
>
> Note that an indicator is exactly what is done with XHTML-IM.
>

Well, no. XHTML-IM sends two message texts in the same message.
Hopefully they might even have the same content.

In email, there's a method for sending "multipart/alternative" which
is used for this, and both spammers and marketeers alike insert
*different* content into each fork, to bypass or confuse
content-checking or to take advantage of rendering quirks of clients.
We've yet to deal with the security implications of that.

I'm thinking more like BMH (but probably constrained to a single format).

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

Re: [Standards] Proposed XMPP Extension: Styling

[Dave Cridland]

On 7 November 2017 at 15:16, Marvin Gülker  wrote:
> Am 06. November 2017 um 15:29 Uhr -0600 schrieb Sam Whited 
> :
>> > Not using something XML-based in a XEP's format
>> > also creates a precedence case from which we don't know where else it
>> > will come back at us when other XEPs are made.
>>
>> I didn't understand this, sorry, could you please rephrase it or attempt
>> to clarify?
>
> Until now, XMPP is based on XML throughout all XEPs (that I'm aware
> of). This now introduces markup that's not XML for the first time,
> requiring a specific parser for it. What I'm saying is just that in
> future XEPs, it will be much easier to refer to this one and say "hey,
> we already have a XEP that's not based on XML, so what's wrong with
> this?". Consequently, XMPP clients are going to accumulate a plethora of
> parsers for different formats over time then.
>

An XMPP client typically has an ASN.1 DER parser, as well as XML, and
countless other parsers for microformats you've forgotten we use
because they're buried deeply. DNS, perhaps, or various SASL
mechanisms. I'm pretty sure that a JSON parser is probably quite
common, too (POSH, for example, needs a JSON parser). You might even
count base64.

The difference here isn't that it's another parser, it's that its a
new "home grown" syntax to parse. We don't do those often - XEP-0115's
hash input format is one, but we generate that and don't parse it, and
XEP-0245 is pretty trivial.

However, I think that the benefits here outweigh the costs:

* The format is quite small, so a parser - while still a parser, with
all that that entails - is about as simple as one could imagine.
* The format is the same as plenty of other IM systems, so we know
it's proven useful.

That all said, I do not consider this a precedent for future XEPs to
specify a zillion different syntaxes. Our options for styling IM
messages are XHTML-IM, which has (in my experience and opinion) proven
a complex and dangerous thing to implement, this, or plaintext. I'm
happy to keep it at that. I'm not sure what other new syntaxes we're
likely to ever need.

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

Re: [Standards] Proposed XMPP Extension: Styling

[Sam Whited]

On Tue, Nov 7, 2017, at 12:29, Jonas Wielicki wrote:
> We have to appreciate that sometimes content is sent from sources which
> are or 
> are not human, outside of the control of the client itself or otherwise 
> unpredictable and unreasonable. For example, I have an application which 
> essentially bridges command line utilities to XMPP. Having e.g.
> blockquote 
> styling applied to lines beginning with "> " would be unfortunate and
> make the 
> output much less readable.

This seems very niche to me, I am not relaly concerned with the
occasional code paste being broken. I have never heard of this being a
problem in Slack (for example), so I don't see why it would be a problem
here either. The people who are pasting code are probably also the
people who will figure out what's going on with the least amount of
trouble. A 100% solution with no false positives would be great, but I
can't think of a way to do it without significantly more complexity or a
formal markup language (which is against the requirements I drew up
based on previous discussions).

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

Re: [Standards] Proposed XMPP Extension: Styling

[Jonas Wielicki]

On Montag, 6. November 2017 11:58:15 CET Sam Whited wrote:
> URL: https://xmpp.org/extensions/inbox/styling.html

This XEP is incompatible with *sending* clients (be they human or automated) 
which are not aware of it. I strongly advocate for an opt-in mechanism (at 
which point this is the rejected Body Markup Hints ProtoXEP, but with a custom 
markup) on each message; if that’s not gonna find consensus, I think an opt-
out mechanism is the least which must be done.

We have to appreciate that sometimes content is sent from sources which are or 
are not human, outside of the control of the client itself or otherwise 
unpredictable and unreasonable. For example, I have an application which 
essentially bridges command line utilities to XMPP. Having e.g. blockquote 
styling applied to lines beginning with "> " would be unfortunate and make the 
output much less readable.

I also still think that this XEP mixes input conventions with wire format in a 
very unfortunate way. In the spirit of "complaining about things this XEP is 
not trying to be is not going to help anyone", I am currently preparing a 
another ProtoXEP.

Note that I’m not against writing down rules for ad-hoc text-input formatting 
(I think the rules in the XEP are, except for the escaping, very reasonable to 
implement in a normal user-facing client for converting input to actual markup 
which is then sent with a proper wire format), but I am strongly against 
simply pouring text with inline pseudo-markup into a .

(Other concerns I have have already been discussed elsewhere in this thread or 
in the XHTML-IM discussion, and I’m not going to repeat those here for better 
signal/noise.)

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] Proposed XMPP Extension: Styling

[Goffi]

Le mardi 7 novembre 2017, 13:02:40 CET Dave Cridland a écrit :
> On 6 November 2017 at 22:58, Goffi  wrote:
> > As an exemple which could lead to big trouble, imagine a shell@ MUC room
> > with> 
> > somebody pasting this code to explain something:
> > ls `date +%Y-%m-%d`-*.xml
> 
> We could include an indicator of how to interpret text - basically,
> Florian Schmaus's recent suggestion tailored to this.
> 
> Then you end up with:
> 
> 1) Sender is plaintext -> Receiver does not style.
> 2) Sender is styled, Receiver cannot style -> Receiver does not style.
> 3) Sender is styled, Receiver can style -> Receiver styles.
> 
> (Note in case (1), whether the Receiver can style or not is irrelevant).

Note that an indicator is exactly what is done with XHTML-IM.

And by the way, our client can use Mardown, Dotclear wiki, or actually any 
syntax (including the one specified in this XEP) without problem and wihtout 
polluting the plain text content.

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

Re: [Standards] Proposed XMPP Extension: Styling

[Goffi]

Le mardi 7 novembre 2017, 12:57:32 CET Dave Cridland a écrit :
> On 6 November 2017 at 22:58, Goffi  wrote:
> > I still really dislike the fact that rendering of text body could be
> > different accross clients.
> 
> I don't follow why this is a problem, which makes me suspect I'm
> misunderstanding what you mean here.
> 
> Text bodies are already rendered differently across clients, whether
> that's a choice like Gajim made to use *bold* etc, or whether it's
> just font and other issues. Clients already combine multiple
> sequential messages into a single message where they feel like, and
> numerous other choices. Some choose to render ":-)" as a small
> graphical smiling face, others choose not to.
> 
> As as for fonts, etc...
> 
> So I'm assuming you cannot mean visual style - in which case, I'm
> somewhat lost as to what you do actually mean?
> 
> Dave.
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___

Hi Dave,

my main concern about different rendering are the formatting characteres which 
can or cannot be removed depending on the client, and in this case the content 
changes which is a big problem (cf. my code pasting example).

This is better if we force to display characters, as I mentionned in my last 
email.


If the content is the same, things are better, but still putting different 
formatting is an issue: having the command line I've show before (ls `date +
%Y-%m-%d`-*.xml) half in monospace, partly in bold is an issue, for 
readability, understanding and even accessibility.

Yes some clients are doing that, but that's not because some client have a bad 
behaviour that we need to standardise - and then legitimate - it.

Your smiling  ":-)" rendered as graphic is a good example as I often rant 
against client changing that when I want to paste code.


Combining messages without changing content, fonts etc is not an issue. 
Changing the content is an issue. Changing the style of part of the content 
may also be an issue in many case, even if it's alright in 80% of case.


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

Re: [Standards] Proposed XMPP Extension: Styling

[Peter Saint-Andre]

On 11/7/17 8:16 AM, Marvin Gülker wrote:
> Am 06. November 2017 um 15:29 Uhr -0600 schrieb Sam Whited 
> :
>>> Not using something XML-based in a XEP's format
>>> also creates a precedence case from which we don't know where else it
>>> will come back at us when other XEPs are made.
>>
>> I didn't understand this, sorry, could you please rephrase it or attempt
>> to clarify?
> 
> Until now, XMPP is based on XML throughout all XEPs (that I'm aware
> of). >

We do have the "/me" markup in plaintext messages:

https://xmpp.org/extensions/xep-0245.html

> This now introduces markup that's not XML for the first time,
> requiring a specific parser for it. What I'm saying is just that in
> future XEPs, it will be much easier to refer to this one and say "hey,
> we already have a XEP that's not based on XML, so what's wrong with
> this?". Consequently, XMPP clients are going to accumulate a plethora of
> parsers for different formats over time then.

I see your point. In fact, I have seen many private uses of XMPP that
"extend" it in just this way...

Peter





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

Re: [Standards] Proposed XMPP Extension: Styling

[Marvin Gülker]

Am 06. November 2017 um 21:19 Uhr +0100 schrieb Daniel Gultsch 
:
> It's probably more helpful if people comment on the actual XEP in
> regards to specific rules or wording in the XEP.

Read my message again. I have done that (commenting on wording with
regard to terminal clients), and additionally provided some conceptual
criticism.

> Just complaining about it and wanting something completely different
> is not going to help anyone.
> If you want semantic information in there or if you prefer something
> XHTML based go ahead and write that XEP.

I've never written a XEP before, but if you insist, I will see if I can
try. But don't expect me to submit a suggestion within a few days. I've
some important stuff coming up in about two weeks, and before that I
can't get into something that complex.

Marvin

-- 
Blog: https://www.guelkerdev.de
PGP/GPG ID: F1D8799FBCC8BC4F
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Styling

[Marvin Gülker]

Am 06. November 2017 um 15:29 Uhr -0600 schrieb Sam Whited :
> > Not using something XML-based in a XEP's format
> > also creates a precedence case from which we don't know where else it
> > will come back at us when other XEPs are made.
> 
> I didn't understand this, sorry, could you please rephrase it or attempt
> to clarify?

Until now, XMPP is based on XML throughout all XEPs (that I'm aware
of). This now introduces markup that's not XML for the first time,
requiring a specific parser for it. What I'm saying is just that in
future XEPs, it will be much easier to refer to this one and say "hey,
we already have a XEP that's not based on XML, so what's wrong with
this?". Consequently, XMPP clients are going to accumulate a plethora of
parsers for different formats over time then.

This is a fear, not a fact. It might or might not come true.

Marvin

-- 
Blog: https://www.guelkerdev.de
PGP/GPG ID: F1D8799FBCC8BC4F
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Styling

[Sam Whited]

On November 7, 2017 6:02:54 AM CST, Jonas Wielicki  wrote:
>When I put "foo" into a message, it will be sent as:
>
>bfoo/b
>
>Which every sane XML library will hand to the receiving application as
>a 
>string containing "foo". At which point, if you pour that into a

This is what I was talking about. You may be right though if XML libraries 
automatically unescape entities. It was just a remark off the top of my head 
which should have been left out though, it's not as much of a problem since 
this spec isn't using a markdown compatible format.

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

Re: [Standards] Proposed XMPP Extension: Styling

[Jonas Wielicki]

On Montag, 6. November 2017 15:25:00 CET Sam Whited wrote:
> Although, in retrospect the body is escaped so this isn't as
> likely as XHTML-IM to be a problem unless you unescape and them dump it
> into the DOM (which is a problem regardless of what formatting spec you
> use).

Could you clarify? I can’t see anything in the XEP which mandates escaping 
(which wouldn’t help either with malicious senders).

When I put "foo" into a message, it will be sent as:

bfoo/b

Which every sane XML library will hand to the receiving application as a 
string containing "foo". At which point, if you pour that into a 
default markdown thing, you get HTML in the output.

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] Proposed XMPP Extension: Styling

[Dave Cridland]

On 6 November 2017 at 22:58, Goffi  wrote:
> As an exemple which could lead to big trouble, imagine a shell@ MUC room with
> somebody pasting this code to explain something:
>
> ls `date +%Y-%m-%d`-*.xml

We could include an indicator of how to interpret text - basically,
Florian Schmaus's recent suggestion tailored to this.

Then you end up with:

1) Sender is plaintext -> Receiver does not style.
2) Sender is styled, Receiver cannot style -> Receiver does not style.
3) Sender is styled, Receiver can style -> Receiver styles.

(Note in case (1), whether the Receiver can style or not is irrelevant).

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

Re: [Standards] Proposed XMPP Extension: Styling

[Dave Cridland]

On 6 November 2017 at 22:58, Goffi  wrote:
> I still really dislike the fact that rendering of text body could be different
> accross clients.

I don't follow why this is a problem, which makes me suspect I'm
misunderstanding what you mean here.

Text bodies are already rendered differently across clients, whether
that's a choice like Gajim made to use *bold* etc, or whether it's
just font and other issues. Clients already combine multiple
sequential messages into a single message where they feel like, and
numerous other choices. Some choose to render ":-)" as a small
graphical smiling face, others choose not to.

As as for fonts, etc...

So I'm assuming you cannot mean visual style - in which case, I'm
somewhat lost as to what you do actually mean?

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

Re: [Standards] Proposed XMPP Extension: Styling

[Dave Cridland]

I really enjoyed the irony of catching up on the xsf@ discussion on why
this is so unworkable:

​

On 6 November 2017 at 17:58, Sam Whited  wrote:

> The XMPP Extensions Editor has received a proposal for a new XEP.
>
> Title: Styling
>
> Abstract:
>
> > This specification defines a plain-text formatting syntax for use in
> > exchanging instant messages with simple text styling.
>
> URL: https://xmpp.org/extensions/inbox/styling.html
>
> The Council will decide in the next two weeks whether to accept this
> proposal as an official XEP.
> ___
> 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] Proposed XMPP Extension: Styling

[Goffi]

Le lundi 6 novembre 2017, 18:58:15 CET Sam Whited a écrit :
> The XMPP Extensions Editor has received a proposal for a new XEP.
> 
> Title: Styling
> 
> Abstract:
> > This specification defines a plain-text formatting syntax for use in
> > exchanging instant messages with simple text styling.
> 
> URL: https://xmpp.org/extensions/inbox/styling.html
> 
> The Council will decide in the next two weeks whether to accept this
> proposal as an official XEP.
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___

After a flamewa^W talk on xsf@, we have evocated the fact the formatting 
characteres could be always displayed (with a "MUST" not a "SHOULD"). That 
would make the thing a bit more acceptable to my eyes as we could then safely 
ignore the XEP.

The issue then is escaping characteres, they should be removed.

As an exemple which could lead to big trouble, imagine a shell@ MUC room with 
somebody pasting this code to explain something:

ls `date +%Y-%m-%d`-*.xml

If some clients remove formating characteres, this would lead to some people 
not seeing the correct command (except if we force to keep formatting 
characters, then it will just be ugly :D ).

I still really dislike the fact that rendering of text body could be different 
accross clients.

On other important point mentionned by jnanar, is that formatting data in text 
could be a really bad thing for accessibility (thing about page readers).


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

Re: [Standards] Proposed XMPP Extension: Styling

[Sam Whited]

On Mon, Nov 6, 2017, at 14:08, Marvin Gülker wrote:
> The XEP defines requirements like "MUST be displayed in italics" (§6.5)
> or "MUST be displayed with a horizontal line through the middle (strike
> through)" (§6.6) that immediately map to the user interface and are not
> possible to implement in a terminal client on most terminal emulators. I
> don't see why a terminal client should be excluded from supporting this
> XEP -- it might be able to show elements by other means than the XEP
> author imagined (e.g., using colour instead of italics; check how man(1)
> copes with italics). The wording should be changed to reflect the
> semantical meaning and not the visual outcome.

Good point! Assuming this is accepted (we'll see), I will rephrase and
make the specific stylings (bold, italic, etc.) a recommendation instead
of a MUST. Thanks for the feedback!

> Another point of critique we already heard earlier on this mailinglist:
> anything that's not based on XML requires the application developer to
> either implement a new parser for the format himself or add a dependency
> on an external parser. It looks like this XEP is Markdown for the sake
> of using Markdown, whereas a more efficient solution would rely on the
> tools already available.

I do think that using a custom language is a bit of an annoyance since
everyone has to implement it, but this is a fairly easy parser to write.
I'm not sure what existing tools would be a good fit though (note that
this isn't Markdown and existing Markdown implementations have already
been discounted for reasons discussed in other threads), but I would
welcome suggestions if there's something nice out there already that I
don't know of which meets the same use cases and requirements.

> Not using something XML-based in a XEP's format
> also creates a precedence case from which we don't know where else it
> will come back at us when other XEPs are made.

I didn't understand this, sorry, could you please rephrase it or attempt
to clarify?

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

Re: [Standards] Proposed XMPP Extension: Styling

[Peter Saint-Andre]

On 11/6/17 2:25 PM, Sam Whited wrote:
> On Mon, Nov 6, 2017, at 14:07, Peter Saint-Andre wrote:
>> Why not just use Markdown (or a subset thereof)?
> 
> There were two main reasons why I decided not to use actual Markdown:
> 
> The first is that, as Link Mauve pointed out, this has most of the same
> drawbacks as XHTML-IM (the markdown libraries pass through arbitrary
> HTML). Although, in retrospect the body is escaped so this isn't as
> likely as XHTML-IM to be a problem unless you unescape and them dump it
> into the DOM (which is a problem regardless of what formatting spec you
> use).
> 
> The main reason though is that this is effectively what Whatsapp and
> Slack do (they use more or less the same formatting), and I suspect that
> between the two enough people are used to the styling to make it worth
> immitating.

Thanks for the explanation! :-)

Peter




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

Re: [Standards] Proposed XMPP Extension: Styling

[Sam Whited]

On Mon, Nov 6, 2017, at 14:07, Peter Saint-Andre wrote:
> Why not just use Markdown (or a subset thereof)?

There were two main reasons why I decided not to use actual Markdown:

The first is that, as Link Mauve pointed out, this has most of the same
drawbacks as XHTML-IM (the markdown libraries pass through arbitrary
HTML). Although, in retrospect the body is escaped so this isn't as
likely as XHTML-IM to be a problem unless you unescape and them dump it
into the DOM (which is a problem regardless of what formatting spec you
use).

The main reason though is that this is effectively what Whatsapp and
Slack do (they use more or less the same formatting), and I suspect that
between the two enough people are used to the styling to make it worth
immitating.

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

Re: [Standards] Proposed XMPP Extension: Styling

[Goffi]

Le lundi 6 novembre 2017, 22:14:21 CET Daniel Gultsch a écrit :
> 2017-11-06 22:06 GMT+01:00 Goffi :
> > Le lundi 6 novembre 2017, 22:04:29 CET Daniel Gultsch a écrit :
> >> 2017-11-06 21:58 GMT+01:00 Goffi :
> >> > Le lundi 6 novembre 2017, 21:53:48 CET Daniel Gultsch a écrit :
> >> >> 2017-11-06 21:46 GMT+01:00 Goffi :
> >> >> > And you have no indication of markup, so if I copy/paste some code
> >> >> > for
> >> >> > instance, some client will render it with markup,
> >> >> 
> >> >> I think it is possible to avoid those 'false positives' to some
> >> >> degree. The limited amount of keywords and other rules (has to start
> >> >> with whitespace, not interupted by newline) already work quite well.
> >> >> If you come up with an example of a piece of code that will end up
> >> >> being styled even though it is not supposed to we can maybe fix this
> >> >> be slightly changing the rules.
> >> > 
> >> > Are you suggesting to do heuristic to detect if if a text use a markup
> >> > or
> >> > not?
> >> 
> >> No I'm implying that the current syntax already has very few false
> >> positives and we might be able to bring down the rate of false
> >> positives even more by changing the syntax slightly. But for that to
> >> work I need an example of a false positive.
> > 
> > "Wow, I can write in `monospace`, even a literal ``backtick
> > (`)``!"
> 
> I'm not really sure how you want this to be rendered or what this
> actually means but if you send me the text in between the " it will
> render like this: https://gultsch.de/files/monospace.png which seems
> fine?!
> 
> But I meant more like provide an example of (valid) code you would
> actually paste in real life not some constructed example to 'break'
> the parser.

I took this example because it is in the XEP, so obviously not made to break 
the parser. The point is if you want to paste this simple example to explain 
how to use the syntax, it will render differently depending on the client 
supporting (and using) the XEP or not. In your screenshot it would be bad as 
the monospace backquotes are not displayed.

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

Re: [Standards] Proposed XMPP Extension: Styling

[Daniel Gultsch]

2017-11-06 22:06 GMT+01:00 Goffi :
> Le lundi 6 novembre 2017, 22:04:29 CET Daniel Gultsch a écrit :
>> 2017-11-06 21:58 GMT+01:00 Goffi :
>> > Le lundi 6 novembre 2017, 21:53:48 CET Daniel Gultsch a écrit :
>> >> 2017-11-06 21:46 GMT+01:00 Goffi :
>> >> > And you have no indication of markup, so if I copy/paste some code for
>> >> > instance, some client will render it with markup,
>> >>
>> >> I think it is possible to avoid those 'false positives' to some
>> >> degree. The limited amount of keywords and other rules (has to start
>> >> with whitespace, not interupted by newline) already work quite well.
>> >> If you come up with an example of a piece of code that will end up
>> >> being styled even though it is not supposed to we can maybe fix this
>> >> be slightly changing the rules.
>> >
>> > Are you suggesting to do heuristic to detect if if a text use a markup or
>> > not?
>> No I'm implying that the current syntax already has very few false
>> positives and we might be able to bring down the rate of false
>> positives even more by changing the syntax slightly. But for that to
>> work I need an example of a false positive.
>
> "Wow, I can write in `monospace`, even a literal ``backtick
> (`)``!"

I'm not really sure how you want this to be rendered or what this
actually means but if you send me the text in between the " it will
render like this: https://gultsch.de/files/monospace.png which seems
fine?!

But I meant more like provide an example of (valid) code you would
actually paste in real life not some constructed example to 'break'
the parser.

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

Re: [Standards] Proposed XMPP Extension: Styling

[Goffi]

Le lundi 6 novembre 2017, 22:04:29 CET Daniel Gultsch a écrit :
> 2017-11-06 21:58 GMT+01:00 Goffi :
> > Le lundi 6 novembre 2017, 21:53:48 CET Daniel Gultsch a écrit :
> >> 2017-11-06 21:46 GMT+01:00 Goffi :
> >> > And you have no indication of markup, so if I copy/paste some code for
> >> > instance, some client will render it with markup,
> >> 
> >> I think it is possible to avoid those 'false positives' to some
> >> degree. The limited amount of keywords and other rules (has to start
> >> with whitespace, not interupted by newline) already work quite well.
> >> If you come up with an example of a piece of code that will end up
> >> being styled even though it is not supposed to we can maybe fix this
> >> be slightly changing the rules.
> > 
> > Are you suggesting to do heuristic to detect if if a text use a markup or
> > not?
> No I'm implying that the current syntax already has very few false
> positives and we might be able to bring down the rate of false
> positives even more by changing the syntax slightly. But for that to
> work I need an example of a false positive.

"Wow, I can write in `monospace`, even a literal ``backtick 
(`)``!"


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

Re: [Standards] Proposed XMPP Extension: Styling

[Daniel Gultsch]

2017-11-06 21:58 GMT+01:00 Goffi :
> Le lundi 6 novembre 2017, 21:53:48 CET Daniel Gultsch a écrit :
>> 2017-11-06 21:46 GMT+01:00 Goffi :
>> > And you have no indication of markup, so if I copy/paste some code for
>> > instance, some client will render it with markup,
>>
>> I think it is possible to avoid those 'false positives' to some
>> degree. The limited amount of keywords and other rules (has to start
>> with whitespace, not interupted by newline) already work quite well.
>> If you come up with an example of a piece of code that will end up
>> being styled even though it is not supposed to we can maybe fix this
>> be slightly changing the rules.
>
> Are you suggesting to do heuristic to detect if if a text use a markup or not?

No I'm implying that the current syntax already has very few false
positives and we might be able to bring down the rate of false
positives even more by changing the syntax slightly. But for that to
work I need an example of a false positive.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Styling

[Goffi]

Le lundi 6 novembre 2017, 21:53:48 CET Daniel Gultsch a écrit :
> 2017-11-06 21:46 GMT+01:00 Goffi :
> > And you have no indication of markup, so if I copy/paste some code for
> > instance, some client will render it with markup,
> 
> I think it is possible to avoid those 'false positives' to some
> degree. The limited amount of keywords and other rules (has to start
> with whitespace, not interupted by newline) already work quite well.
> If you come up with an example of a piece of code that will end up
> being styled even though it is not supposed to we can maybe fix this
> be slightly changing the rules.

Are you suggesting to do heuristic to detect if if a text use a markup or not?

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

Re: [Standards] Proposed XMPP Extension: Styling

[Daniel Gultsch]

2017-11-06 21:46 GMT+01:00 Goffi :
> And you have no indication of markup, so if I copy/paste some code for
> instance, some client will render it with markup,


I think it is possible to avoid those 'false positives' to some
degree. The limited amount of keywords and other rules (has to start
with whitespace, not interupted by newline) already work quite well.
If you come up with an example of a piece of code that will end up
being styled even though it is not supposed to we can maybe fix this
be slightly changing the rules.

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

Re: [Standards] Proposed XMPP Extension: Styling

[Jonas Wielicki]

On Montag, 6. November 2017 21:19:47 CET Daniel Gultsch wrote:
> It's probably more helpful if people comment on the actual XEP in
> regards to specific rules or wording in the XEP.
> Just complaining about it and wanting something completely different
> is not going to help anyone.
> If you want semantic information in there or if you prefer something
> XHTML based go ahead and write that XEP.
> But this particular XEP is not magically going to turn into something
> completely different.
> 
> 

While I agree with your statement in general (that XEPs should be commented on 
based on what they are), I think this situation is different from the general 
case.

We have the situation that one group is pushing for abandoning XHTML-IM (for 
good reasons!) and any XEP remotely touching the area of markup *will* be held 
against XHTML-IM standards (we’ve seen that with Body Markup Hints) and the 
use-cases people discussed on the list in the last weeks. 

Now we find that one of the proponents of obsoleting XHTML-IM is proposing a 
XEP which solves some of the use-cases in ways for which we’ve heard arguments 
against which only partially have been refuted properly. I personally find 
this frustrating because it feels like those offering criticism are being 
ignored for no good reason.

And I think those raising their voices on those matters are in the right here.

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] Proposed XMPP Extension: Styling

[Goffi]

Le lundi 6 novembre 2017, 20:31:32 CET Sam Whited a écrit :
> On Mon, Nov 6, 2017, at 13:17, Emmanuel Gil Peyrot wrote:
> > Markdown(-like) is NOT a plain text format, having the receiving client
> > choose between rendering all formatting characters or stripping them is
> > stupid, and requiring humans to mentally strip them out in older
> > clients is stupid; have you not seen the mess that OTR is for example?
> 
> It seems to work just fine for everyone else (Whatsapp, Slack, etc.).

Whatsapp and Slack are particularly bad examples: centralised apps with a 
single implementation, they is not need for clean standard in this use case.

> I do not see how this is comparable to OTR or why it would cause any of
> the same problems since the format is perfectly readable and ordinary
> human beings use Whatsapp and appear to be happy with it.

I don't think that "Wow, I can write in `monospace`, even a literal ``backtick 
(`)``!" is easily readable.

And you have no indication of markup, so if I copy/paste some code for 
instance, some client will render it with markup, some other will correctly 
render it without markup. If I escape the code, the markup aware client will 
render it correctly, but it will be wrong for all other clients.


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

Re: [Standards] Proposed XMPP Extension: Styling

[Daniel Gultsch]

It's probably more helpful if people comment on the actual XEP in
regards to specific rules or wording in the XEP.
Just complaining about it and wanting something completely different
is not going to help anyone.
If you want semantic information in there or if you prefer something
XHTML based go ahead and write that XEP.
But this particular XEP is not magically going to turn into something
completely different.


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

Re: [Standards] Proposed XMPP Extension: Styling

[Marvin Gülker]

The XEP defines requirements like "MUST be displayed in italics" (§6.5)
or "MUST be displayed with a horizontal line through the middle (strike
through)" (§6.6) that immediately map to the user interface and are not
possible to implement in a terminal client on most terminal emulators. I
don't see why a terminal client should be excluded from supporting this
XEP -- it might be able to show elements by other means than the XEP
author imagined (e.g., using colour instead of italics; check how man(1)
copes with italics). The wording should be changed to reflect the
semantical meaning and not the visual outcome.

In that regard, the Markdown-inspired approach is bad at conveying the
semantical meaning anyway. It just comes from the wrong end -- it says
"make this bold" or "strike this through", but it does not allow me as
author to say "emphasize this", "this is a person's name", or "this is
outdated". It forces a visual output where it should rather leave the
means by which a semantical meaning is conveyed to the client developer.
Take an extreme example: a client that does not output messages
visually, but auditive by reading them out, which may well be a useful
feature for visually impaired people. Since we cannot know all possible
kinds of client UIs in advance, we should try to not interfer with the
developer's UI as far as possible.

Another point of critique we already heard earlier on this mailinglist:
anything that's not based on XML requires the application developer to
either implement a new parser for the format himself or add a dependency
on an external parser. It looks like this XEP is Markdown for the sake
of using Markdown, whereas a more efficient solution would rely on the
tools already available. Not using something XML-based in a XEP's format
also creates a precedence case from which we don't know where else it
will come back at us when other XEPs are made.

Marvin

-- 
Blog: https://www.guelkerdev.de
PGP/GPG ID: F1D8799FBCC8BC4F
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Styling

[Peter Saint-Andre]

On 11/6/17 1:02 PM, Evgeny Khramtsov wrote:
> Mon, 06 Nov 2017 13:31:32 -0600
> Sam Whited  wrote:
> 
>> This spec does not use Markdown, nor is it compatible with markdown,
>> so if people use a Markdown library they won't get the same formatting
>> described in this spec.
> 
> But they can easily fork existing md-to-js engines like [1] and patch
> it. So we still need to rely on reliability of those engines.

Why not just use Markdown (or a subset thereof)?

Peter




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

Re: [Standards] Proposed XMPP Extension: Styling

[Evgeny Khramtsov]

Mon, 06 Nov 2017 13:31:32 -0600
Sam Whited  wrote:

> This spec does not use Markdown, nor is it compatible with markdown,
> so if people use a Markdown library they won't get the same formatting
> described in this spec.

But they can easily fork existing md-to-js engines like [1] and patch
it. So we still need to rely on reliability of those engines.

[1] https://github.com/showdownjs/showdown
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Styling

[Daniel Gultsch]

2017-11-06 20:31 GMT+01:00 Sam Whited :
> the same problems since the format is perfectly readable

This is the important part here. (And why I suggested to get rid of
the escaping mechanism)

>> There is exactly no extensibility in this proposal, if tomorrow the
>> trend changes you will end up with all users of clients implementing it
>> not understanding what’s going on.
>
> I do not think this is a problem. I also have no problem adding
> formatting characters similar to the ones already in this spec and
> changing the formatting of older messages.

I actually don't want to have a lot of extensibility in there. I want
all of this human readable (and not in a way that Latex is human
readable) which kind of limits the amount of stuff we can put in
there. But that's a good thing imho.

That being said if for some reasoning blinking text or something like
that becomes a thing we can rather easily add »blink« or something
like that. Because older clients will just render that as »blink«
which is totally fine.

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

Re: [Standards] Proposed XMPP Extension: Styling

[Sam Whited]

On Mon, Nov 6, 2017, at 13:17, Emmanuel Gil Peyrot wrote:
> Markdown(-like) is NOT a plain text format, having the receiving client
> choose between rendering all formatting characters or stripping them is
> stupid, and requiring humans to mentally strip them out in older
> clients is stupid; have you not seen the mess that OTR is for example?

It seems to work just fine for everyone else (Whatsapp, Slack, etc.).
I do not see how this is comparable to OTR or why it would cause any of
the same problems since the format is perfectly readable and ordinary
human beings use Whatsapp and appear to be happy with it.

> There is exactly no extensibility in this proposal, if tomorrow the
> trend changes you will end up with all users of clients implementing it
> not understanding what’s going on.

I do not think this is a problem. I also have no problem adding
formatting characters similar to the ones already in this spec and
changing the formatting of older messages.

> Formatting really should be in a separate payload, so that clients
> which don’t understand it can use the plain text version and safely
> ignore the formatted one.

This message *is* plaintext. It works fine. Meanwhile, when it is a
separate payload I have to worry about whether the messages are actually
the same (which is an interesting attack vector I'd like to explore in
XHTML-IM at some point), whether they're both encrypted, etc.

> And again, this XEP does not address any of the issues with XHTML-IM,
> web people will just pipe this through the first Markdown library and
> get rendering wrong, get more elements than listed here, and get a nice
> passthrough of escaped HTML.

This spec does not use Markdown, nor is it compatible with markdown, so
if people use a Markdown library they won't get the same formatting
described in this spec.

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

Re: [Standards] Proposed XMPP Extension: Styling

[Emmanuel Gil Peyrot]

On Mon, Nov 06, 2017 at 11:58:15AM -0600, Sam Whited wrote:
> The XMPP Extensions Editor has received a proposal for a new XEP.
> 
> Title: Styling
> 
> Abstract:
> 
> > This specification defines a plain-text formatting syntax for use in
> > exchanging instant messages with simple text styling.

Please no…

People have been telling you countless times on standards@ that
embedding raw markup in the body is an extremely bad idea, with many
examples.

Markdown(-like) is NOT a plain text format, having the receiving client
choose between rendering all formatting characters or stripping them is
stupid, and requiring humans to mentally strip them out in older
clients is stupid; have you not seen the mess that OTR is for example?

There is exactly no extensibility in this proposal, if tomorrow the
trend changes you will end up with all users of clients implementing it
not understanding what’s going on.

Formatting really should be in a separate payload, so that clients
which don’t understand it can use the plain text version and safely
ignore the formatted one.

And again, this XEP does not address any of the issues with XHTML-IM,
web people will just pipe this through the first Markdown library and
get rendering wrong, get more elements than listed here, and get a nice
passthrough of escaped HTML.

> 
> URL: https://xmpp.org/extensions/inbox/styling.html
> 
> The Council will decide in the next two weeks whether to accept this
> proposal as an official XEP.

Sorry for the rant,

-- 
Emmanuel Gil Peyrot


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