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
* 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
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
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
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
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
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
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
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
>
>
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
>
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
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
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,
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
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
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
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:
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.
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
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
>> >
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
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
>
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
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
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
[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.
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
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
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,
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
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?
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,
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
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
34 matches
Mail list logo