Re: [Standards] Proposed XMPP Extension: Message Markup

Hi, On 7 November 2017 at 21:34, Jonas Wielicki wrote: > The XMPP Extensions Editor has received a proposal for a new XEP. > Minor remark: the XEP says that spans MUST NOT overlap. Is there a reason for this? I'm asking, because the systems I have seen that use external

Re: [Standards] Proposed XMPP Extension: Message Markup

* Goffi [2017-11-08 08:17]: > about the stars in the list items, it's not really nice to keep them. > > It would be good to have an attribute to say which plain text characters can > be safely removed without changing the meaning. > For instance type="numeric" means than

Re: [Standards] Proposed XMPP Extension: Message Markup

Le mardi 7 novembre 2017, 21:34:04 CET Jonas Wielicki a écrit : > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title: Message Markup > Abstract: > This specification provides an alternative to XHTML-IM with rigid > separation of content and markup information, improving

Re: [Standards] Proposed XMPP Extension: Message Markup

Le mardi 7 novembre 2017, 22:41:21 CET Marvin Gülker a écrit : > §9 on security: one issue that comes to my mind is specifying > out-of-range values for the "start" and "end" attributes by a malicious > client. Or a start without end/end without start, if a client replace it by HTML tags

Re: [Standards] Proposed XMPP Extension: Styling

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

Re: [Standards] UPDATED: XEP-0385 (Stateless Inline Media Sharing (SIMS))

On Tue, Nov 7, 2017, at 16:35, Peter Saint-Andre wrote: > A XEP feels more appropriate to me, so that changes to it receive wider > review and so that it can be referenced more easily from other specs. Sounds good; I defer to your wisdom there (I'm never 100% sure when one is appropriate over the

Re: [Standards] UPDATED: XEP-0385 (Stateless Inline Media Sharing (SIMS))

On 11/7/17 3:33 PM, Sam Whited wrote: > On Tue, Nov 7, 2017, at 15:47, Arc Riley wrote: >> It may be best to have a single XEP cover codec support and reference it >> as appropriate. > > Or a registry. A XEP feels more appropriate to me, so that changes to it receive wider review and so that it

Re: [Standards] UPDATED: XEP-0385 (Stateless Inline Media Sharing (SIMS))

On Tue, Nov 7, 2017, at 15:47, Arc Riley wrote: > It may be best to have a single XEP cover codec support and reference it > as appropriate. Or a registry. —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards

Re: [Standards] UPDATED: XEP-0385 (Stateless Inline Media Sharing (SIMS))

It may be best to have a single XEP cover codec support and reference it as appropriate. On Tue, Nov 7, 2017 at 1:15 PM, Peter Saint-Andre wrote: > We might want to update XEP-0266, too: > > https://xmpp.org/extensions/xep-0266.html#codecs-opus > >

Re: [Standards] Proposed XMPP Extension: Message Markup

This is an interesting approach. Specifying the markup completely externally would not have occured to me, but is a really cool idea. Some notes: §4.1 has: > The start and end attributes define the range at which the span is > applied. They are in units of unicode code points in the character >

Re: [Standards] Proposed XMPP Extension: Message Markup

On 11/7/17 1:48 PM, Goffi wrote: > Le mardi 7 novembre 2017, 21:34:04 CET Jonas Wielicki a écrit : >> The XMPP Extensions Editor has received a proposal for a new XEP. >> >> Title: Message Markup >> Abstract: >> This specification provides an alternative to XHTML-IM with rigid >> separation of

Re: [Standards] UPDATED: XEP-0385 (Stateless Inline Media Sharing (SIMS))

We might want to update XEP-0266, too: https://xmpp.org/extensions/xep-0266.html#codecs-opus https://xmpp.org/extensions/xep-0266.html#mti On 11/7/17 2:11 PM, Arc Riley wrote: > https://xmpp.org/extensions/xep-0385.html#sect-idm139941991230272 > > Since the IETF has standardized the

Re: [Standards] UPDATED: XEP-0385 (Stateless Inline Media Sharing (SIMS))

https://xmpp.org/extensions/xep-0385.html#sect-idm139941991230272 Since the IETF has standardized the patent-clear Opus codec, this should be recommended. It is already used for WebRTC and broadly supported. https://tools.ietf.org/html/rfc6716 https://caniuse.com/#search=Opus On Wed, Oct 4,

Re: [Standards] Proposed XMPP Extension: Message Markup

Le mardi 7 novembre 2017, 21:34:04 CET Jonas Wielicki a écrit : > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title: Message Markup > Abstract: > This specification provides an alternative to XHTML-IM with rigid > separation of content and markup information, improving

Re: [Standards] Proposed XMPP Extension: Styling

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

Re: [Standards] Proposed XMPP Extension: Styling

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

[Standards] Proposed XMPP Extension: Message Markup

The XMPP Extensions Editor has received a proposal for a new XEP. Title: Message Markup Abstract: This specification provides an alternative to XHTML-IM with rigid separation of content and markup information, improving the resilience against spoofing and injection attacks. URL:

Re: [Standards] Proposed XMPP Extension: Styling

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.

Re: [Standards] Proposed XMPP Extension: Styling

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

Re: [Standards] Proposed XMPP Extension: Styling

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

Re: [Standards] LAST CALL: XEP-0387 (XMPP Compliance Suites 2017)

On Wed, Nov 1, 2017, at 11:50, Dave Cridland wrote: > On 1 November 2017 at 17:14, Sam Whited wrote: > > On Wed, Nov 1, 2017, at 11:47, Jonas Wielicki wrote: > >> On Montag, 16. Oktober 2017 18:38:46 CET Jonas Wielicki wrote: > >> > This message constitutes notice of a Last

Re: [Standards] Proposed XMPP Extension: Styling

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 >

Re: [Standards] Proposed XMPP Extension: Styling

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

Re: [Standards] Proposed XMPP Extension: Styling

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

Re: [Standards] Proposed XMPP Extension: Styling

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

Re: [Standards] LAST CALL: XEP-0313 (Message Archive Management)

[XEP-0313 for LC] I have three points to make. a) What to store: As already mentioned by Jonas and Kevin, the business rules in §5.1.1 are only a first approximation of what we want to persist, and we need to figure out better / more explicit ways to determine persistent / transient messages.

Re: [Standards] Proposed XMPP Extension: Styling

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

Re: [Standards] Proposed XMPP Extension: Styling

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

Re: [Standards] Proposed XMPP Extension: Styling

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,

Re: [Standards] Proposed XMPP Extension: Styling

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

Re: [Standards] Proposed XMPP Extension: Styling

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?

Re: [Standards] Proposed XMPP Extension: Styling

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,

Re: [Standards] Proposed XMPP Extension: Styling

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

Re: [Standards] Proposed XMPP Extension: Styling

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