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 reme
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 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 nest
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 i
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.
>
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 - a
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
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 X
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
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
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://mai
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 sing
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
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 r
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.
Th
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
___
S
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
t
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
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 viewp
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
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 abo
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
* 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 stylin
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 messa
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
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 langu
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 ma
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
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 f
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:
>>
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.
>>
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
> essential
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 rejecte
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 coul
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
> misunderstandin
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
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
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 rephra
On November 7, 2017 6:02:54 AM CST, Jonas Wielicki wrote:
>When I put "foo" into a message, it will be sent as:
>
>foo
>
>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
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
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
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
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 form
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.
>
>
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 i
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
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 pa
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
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 i
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
> >> > insta
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
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
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
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 s
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 h
Le lundi 6 novembre 2017, 21:07:02 CET Peter Saint-Andre a écrit :
> 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 wo
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 ah
Mon, 6 Nov 2017 13:07:02 -0700
Peter Saint-Andre wrote:
> Why not just use Markdown (or a subset thereof)?
By whom? By Sam? From what I understand the intention to be
markdown incompatible is a fool protection. But I think this will not
work for the reason I just described.
_
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
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
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
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 wi
Hi,
2017-11-06 18:58 GMT+01:00 Sam Whited :
> 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.
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
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.
P
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
66 matches
Mail list logo
