-
Syndace
Can a client respond with an internal-server-error if something internal goes wrong when handling a request? The "server" part makes me unsure.
-
MattJ
Heh
-
MattJ
Do you have a specific case in mind?
-
MattJ
or is this just a "is it possible"?
-
Syndace
Im currently coding a client for fun and I have a situation where something internal may fail and I'm wondering what to respond in that case. To make it more specific: Before I send a stanza as response I validate it using the XML schema files and some additional logic. What do I do if the validation fails? I have to anwser something to iq request..
-
Syndace
Now that I think about it, maybe I should only validate incoming stanzas and not outgoing ones. The receiving entity can't expect valid stanzas anyway and has to validate itself.
-
Syndace
I just thought it would be cool to make sure what I'm sending is valid.
-
MattJ
Isn't that bad-request?
-
MattJ
Oh, sorry, I see what you're saying
-
MattJ
Maybe undefined-condition with a custom error would be appropriate here
-
MattJ
There's not much the remote party can do about it in any case
-
Syndace
Hmm the undefined-condition should be used in application-specific cases
-
Syndace
I mean, should is not must but it does not feel clean either
-
Syndace
I think I'll use my internal validation to display warnings/errors and send the invalid stanza anyway. At least this way finding and debugging invalid stanzas is easy.
-
Flow
Syndace, whatever you do, it's often a good idea to include a human readable english text into the error response which provides more information about what whent wrong. But only if that information does not cause some sort of security leak
-
Syndace
Flow, most of the errors are self explanatory, aren't they? Often the XEPs define semantics for error conditions. I like to avoid decisions that might cause security leaks.
-
Flow
Syndace, In my experience it's quite the opposite. For example internal-server-error: It's often usefull to know the cause of the error
-
Syndace
Why does the client have to know which internal server error occured?
-
Syndace
Nevermind, there are probably cases where additional info makes a lot of sense. I'll overthink which of my generated errors could benifit from additional info.
-
Flow
Syndace, so that it can report the error condition back to the server operator
-
Syndace
The server operator should really log internal errors himself..
-
Flow
and he will very likely do that
-
zinid
Syndace: sometimes a user sees an error and don't bother support, because the error is temporary, for example, database failure
-
pep.
jonasw, in your last email to the XHTML-IM thread, I fail to see how having a protocol break from xml to xml would fix OP's issue. I'd like to keep XML as well but if you do that you're still open to the same vulnerabilities
-
jonasw
pep., yes, I’m not convinced that XML helps, which is what I wrote I think?
-
pep.
let me reread
-
jonasw
actually I’m even posting an example of how this might be exploited
-
jonasw
yeah, I probably should’ve added something like "I *think* that […], but I’m not convinced that clients will do the right thing by default, which is why we’re trying to get rid ofXHTML-IM in the first place." will clarify on-list
-
pep.
:)
-
pep.
But,
-
pep.
hmm, yes
-
pep.
yeah, saying "We are now using this NS instead" won'T fix the problem of people not validating
-
pep.
So if people want a change, XML is a no-no
-
pep.
And so is markdown because some implementation (most?) accept html
-
jonasw
markdown is out even if only because it’s not extensible
-
pep.
Right
-
pep.
But I would go further and say, for XML, it's a no-no for web clients at all.
-
pep.
Because people are putting stuff everywhere without validating and that creates vulnerabilities :)
-
pep.
Not just in <body>
-
pep.
Even if it's the most obvious
-
goffi
pep.: that is issue with client dev, validating untrusted input is the first thing to learn when you do web dev (even not web actually)
-
goffi
pep.: (disclaimer: I'm not claming that my web software are failproof, security issue can and will happen to most software)
-
pep.
goffi, yeah, look at my last email on the list
-
Zash
Can't have nice things!
-
pep.
I should have put something like "unlike OP suggests" at the end of that sentence
-
goffi
jonasw: thanks for your last message, I kind of feel alone when I don't even understand while people are still talking about markdown after the debate we had.
-
goffi
s/while/why/
-
jonasw
I’m assuming some good faith (i.e. too long other thread and people didn’t read)
-
goffi
it's possible, I've had the same thing during OMEMO flamewar, hard to follow when you arrive after the battle.
-
Zash
I kinda wanna pin the entire xhtml-im problem on whoever invented .innerHTML
-
jonasw
Zash, .innerHTML isn’t the issue with XHTML-IM
-
jonasw
XHTML-IM breaks not only if you use .innerHTML, it also breaks if you use appendChild
-
Zash
Blame the web!
-
edhelas
Mardown in XMPP, seriously ?!
-
edhelas
i'm not against Markdown, but looks like we are trying to solve a problem by changing it
-
Zash
No, Markdown being defined as a superset of HTML rules it out
-
jonasw
dwd gave a proper definition of what he thinks should be markdown for IM.
-
jonasw
more or less proper.
-
jonasw
I’m tired of asking how to emphasize "Trainer*Innen" with that though.
-
Zash
\bold{Trainer*Innen}
-
jonasw
uhhh
-
jonasw
TeX in IM
-
goffi
one of the problem is that people always thing about their own use case
-
jonasw
that’s execellent
-
jonasw
it’s even turing complete!
-
Zash
(I don't actually know TeX, wild guess)
-
jonasw
it’d be \emph{} or \textbf{}, depending on whether you want emphasis (italics) or actual boldface
-
Zash
Is this Creole? http://www.wikicreole.org/wiki/Creole1.0
-
goffi
XMPP message can also be "normal" with a subject and potentially long, not necessarily a line in a MUC/MIX, and embedded images can be useful there (think about email gateway)
-
jonasw
goffi, agreed
-
jonasw
Zash, yes
-
goffi
I'll take a break on standard@ for tonight, I have written enough there today :)
-
Zash
Ok, me, a naive web developer does a simple string replace and puts the result as .innerHTML
-
waqas
You are doing a simple string replace? That's naive web developer lvl3
-
edhelas
I append my HTML like I append my variables in my SQL requests, using concatenation
-
goffi
why we don't use mirc colors in <body>? Looks like a good idea (as good as using markdown)
-
jonasw
goffi, those use control codes in the 0x00..0x1f range right? you can’t send those over XML
-
goffi
jonasw: easy, we just have to add \uxxxx
-
goffi
we can even use ANSI escape code like this, will be great
-
dwd
goffi, Note that I'm explicitly suggesting we *keep* XHTML embedding, but just avoid it being the go-to way of adding bold and italics in IM messages.
-
jonasw
dwd, I’m not convinced that this is a good thing.
-
jonasw
this just introduces fragmentation we can avoid.
-
Zash
Is it bold and italics and other *styling* people want?
-
dwd
jonasw, I don't really want to specify a whole new document definition.
-
Zash
If so, bringing back <font> could work
-
jonasw
dwd, why not?
-
dwd
Zash, For IM, you mean? I think people want emphasis (mostly just *bold*) and preformat is handy, mostly because code-like stuff is about the only time you use * and / in IMs.
-
Zash
XFONT-IM, you get <font> with a bunch of attributes that map roughtyl to CSS properties
-
jonasw
dwd, as I said. Trainer*Innen is a legit german word
-
goffi
dwd: for <message> ? I didn't got that, I though you were suggesting the separate XHTML XEP (which is a good idea) only for blogging
-
Zash
~$ pandoc <<< '*Trainer*Innen*' <p><em>Trainer</em>Innen*</p>
-
Zash
Palm -> face
-
goffi
but sorry, movie time, will read updates later
-
Zash
jonasw: You type ^B Trainer*Innen ^B in your client. The client translates the input into protocol and sends it.
-
Zash
Or click the [B] button
-
jonasw
Zash, sure, but if the protocol doesn’t support it, because it’s mardown?
-
Zash
~$ pandoc -f html -t markdown <<< '<b>Trainer*Innen</b>' **Trainer\*Innen**
-
jonasw
nice
-
jonasw
at this point we can simply use a proper format, because nobody will learn that syntax for themselves.
-
dwd
jonasw: Either (a) you can't. (b) We define bold toggle as being on a word break. (c) We use doubled asterisks as an escape.
-
jonasw
dwd, see above
-
jonasw
"you can’t" is a terrible answer
-
Zash
dwd: Should we really demand end-users learn some syntax?
-
jonasw
"bold toggle on word breaks" moves the "you can’t" answer to other cases
-
jonasw
"doubled asterisks as an escape", see what Zash says
-
dwd
No, it's not. You also cannot embed images. This is OK. There are lots of edge cases. Imagine how many there's going to be on a complete document markup language.
-
Zash
~$ pandoc <<< '**Trainer*Innen**' <p>**Trainer*Innen**</p>
- Zash scratches head
-
jonasw
dwd, of course. which is why I suggest to have a language we can easily extend instead of some markdown-ish markup.
-
jonasw
that easily allows us to take care of edge-cases and new use-cases later
-
jonasw
without breaking everything again
-
uc
Don't forget S̶t̶r̶i̶k̶e̶ t̶h̶r̶o̶u̶g̶h̶
-
zinid
lol, guys, you will never come to agreement :)
- zinid is reading another round of xhtml-im ranting
-
Zash
I see. Then there can only ever be conflict between us.
-
remko
i shall refrain from suggesting to use docbook markup
-
jonasw
remko, how about groff?
-
Zash
I actually went to look through a bunch of existing XML formats yesterday
-
Zash
There's a bunch
-
remko
for the subset that i think we want (bold, italic, code), i don't think it matters really.
-
jonasw
remko, depends on who "we" includes, "bold, italic, code" doesn’t cut it.
-
remko
'we' => '99% of the use cases' ;-)
-
Zash
But I'm not sure any XML format will make it difficult enough to do the wrong thing
-
jonasw
Zash, I can see people not sanitising attributes and simply changing local names, unfortunately.
-
Zash
Yup
-
remko
jonasw: looking at all the IM clients out there, bold, italic, and underline are the only thing they seem to support. I haven't heard people complaining about this limitation.
-
Zash
Don't forget iChat users with colors
-
remko
it'll boil down to whether we want a structured format or a non-structured format. Personally, I'm torn. I used to lean one way, but am now leaning the other.
-
jonasw
remko, you haven’t heard me then ;-)
-
jonasw
remko, at least there’s also blockquote
-
remko
jonasw: I like blockquote. But there is a case to be made that this should be replaced by a snippet payload.
-
Zash
remko: semantics vs style, xml vs not xml, structured vs not
-
Zash
Any more considerations?
-
remko
Zash: Messages doesn't even support markup i just noticed.
-
jonasw
remko, and how’d you encode those in snippets?
-
jonasw
do we want full-blown HTML snippets, with all the vulnerabilities that has?
-
remko
nope. Just <pre>.
-
jonasw
do you confuse blockquote with code?
-
remko
i.e. a snippet is just rendered as a <pre>, no markup.
-
jonasw
https://d2k1ftgv7pobq7.cloudfront.net/meta/u/res/images/db8a72d486e14d6fe249b6a80962b69b/slack-webdesign-cropped.jpg
-
remko
jonasw: i did confuse both
-
jonasw
here’s one example of inline images, links, something like headings in an IM client
-
Zash
jonasw: Isn't that more like a referece?
-
remko
jonasw: for blockquote, the question is whether this is really a part of the message or not. Could be a reference to something that you happen to render this way.
-
jonasw
Zash, sure, it should be a reference in addition, and ideally the markup should reference the reference to make things super-clear
-
jonasw
but having every client support every type of reference isn’t a good idea I think
-
Zash
jonasw: {xep attaching} maybe?
-
Bunneh
jonasw: XEP-0367: Message Attaching (Standards Track, Deferred, 2017-09-11) See: https://xmpp.org/extensions/xep-0367.html
-
jonasw
wouldn’t it make more sense to have references in addition rather than instead of content?
-
remko
i don't think the bulk of 'modern' (non-XMPP) IM clients out there put images and links in their messages. They use autolinking and unicode replacement object, and attach the immage as an external object.
-
edhelas
the issue with XHTML-IM are also things like images
-
jonasw
remko, sure, you need to mark up where the image goes though
-
Zash
Do modern messagers even do actual in-line images?
-
remko
jonasw: hence the unicode replacement object
-
jonasw
which is again some kind of markup
-
Zash
As opposed to messages that consist only of an image
-
remko
Zash: i wonder about that. I have seen them use the unicode replacement object, but am not sure if they actually use it for placement.
-
remko
(talking about Messages concretely)
-
remko
if you look in the Messages DB, i see messages that came with an image as { "text": "\uFFFC Hi there", "attachments": [ { "image": "..."}]} (or some sorts)
-
remko
but as i said, i'm not sure if they actually use this, or just always render the image at the front/back of the message.
-
jonasw
remko, that looks like something which grew historically because they don’t have proper markup.
-
remko
might be
-
remko
in any case, i would rather not have any markup for images than <img> tags.
-
jonasw
what’s wrong wtih <img/> tags or their equivalent in any other markup?
-
remko
it's a slippery slope to too complex document. It's also ambiguous how text should flow around this stuff etc. If you don't allow it, it's less ambiguous
-
remko
just render is at a separate image. That's also how people feel IM should work i think.
-
Zash
remko: Like a separate type of message box?
-
remko
yes
-
jonasw
I think there’s a lot of value for that type of rich messages.
-
Zash
Yeah I think most things I've seen do that
-
jonasw
possibly not images, but other semantic markup
-
remko
jonasw: i'm not saying there's no use case in XMPP for rich messages with full document markup. IM is just not one IMO.
-
jonasw
talking about IM.
-
jonasw
not necessarily human-generated messages though
-
remko
those should perhaps be a different thing then.
-
jonasw
why make it a different thing?
-
remko
slack also distinguishes between bot messages and human-written messages.
-
remko
you can't do anything beyond bold, italic, and underline as a person.
-
jonasw
but why does the transport need to be different?
-
jonasw
sharing the transport format for whatever markup we’re doing leads to better interoperability
-
Zash
https://xmpp.org/extensions/inbox/content-types.html
-
jonasw
oh god
-
jonasw
type='text/xml'
-
jonasw
I’m in pain now.
-
remko
haven't read the XEP, but saw that pass the mailing list. That sounded like pandora's box to me :)
-
jonasw
that specific implementation feels bad
-
jonasw
and I’m still not convinced that it’s a good thing to have in any case. This will fragment implementations.
-
Zash
I think someone (could be me) suggested <body>markdown markup here</body><body-content type='markdown'/>
-
zinid
Zash: that's exactly Example 1 from the ProtoXEP
-
zinid
<message from='person1@example.org/34892374' to='person2@example.org/938089023' type='chat'> <body>**Note:** This message is very important.</body> <content type='text/markdown' xmlns='urn:xmpp:content'/> </message>
-
Zash
zinid: ah, must have scrolled past that
-
jonasw
zinid, yes, but an empty <content/> has a different meaning than a <content> with text content, which is super awkward.
-
zinid
jonasw: yep, I don't think we need this crap
-
Zash
I actually think it's awkward with <body/><xhtml-im/>
-
zinid
still, it's unclear what should a client render if it doesn't support the content type?
-
zinid
in the case of markdown it's obvious, but with another formats/
-
zinid
?
-
Zash
zinid: if you do this only with formats that are still readable when treated as plain text, it's probably fine
-
zinid
Zash: yes
-
Zash
You probably also wanna have explicit features for formats you understand
-
jonasw
feature discovery doesn’t work in modern IM though.
-
Zash
As in, disco#info features and the whole caps dance
-
Zash
Oh right, we're moving away from the end-to-end thing :/
-
jonasw
let the server handle translation to the different markup types understood by the client!
-
Zash
Ohgod
-
zinid
jonasw: OMEMO guys will not approve :D
-
jonasw
zinid, right
-
zinid
feature discovery won't help in MUCs
-
jonasw
that, too
-
jonasw
or MIXes
-
Zash
or when you switch client and fetch stuff from MAM
-
Zash
or if you use carbons
-
Zash
or ...
-
jonasw
yes, so, that’s not really gonna work.
-
Zash
Can we even do things at all then?
-
jonasw
sure
-
jonasw
like we’ve been doing it with <xhtml-im/>
-
Zash
multipart/alternative basically
-
jonasw
yupp
-
Zash
Do everything at once and let the recipient do what they want :)
-
zinid
do I understand correctly: the only concern about xhtml-im is security issues?
-
jonasw
zinid, the "only", yes
-
jonasw
for me at least.
-
remko
no, i don't think that's true
-
Zash
That's why SamWhited wants it dead, no?
-
remko
that's what initially triggered the discussion, yes. And it's important, because xhtml-im is very hard to sanitize.
-
Zash
It's too easy to just stick the incoming XML tree into a browser DOM
-
remko
but i think other people don't want XHTML-IM, because it's very unpredictable to render in a chat log.
-
zinid
can we provide testing vectors?
-
Zash
User studies needed
-
SamWhited
I hadn't actually considered the difference between text style and layout before, it was just security for me at first, but now I agree that we need something that's purely style, not layout.
-
jonasw
SamWhited, I think we need something for semantics, not for style.
-
jonasw
(neither for layout by the way)
-
Zash
I actually think normal people will want style rather than semantics
-
remko
semantics for things that don't need layout :)
-
jonasw
emphasis, blockquote, strong emphasis, lists and enumerations, and code at the very least.
-
remko
yes, zash is right
-
SamWhited
jonasw: yes, that's fair, I think I agree with that. I can imagine certain clients render "emphasis" as italics and other bold or something similar.
-
jonasw
SamWhited, that, and also accessibility tools
-
jonasw
like screen readers
-
jonasw
they benefit a lot from semantics.
-
remko
i actually agree with Zash, people don't care about semantics in IM, they care about style.
-
SamWhited
Yes, I think for the most part you'll find they're the same for anything simple though.
-
jonasw
Zash, they think they want style, but they actually want semantics.
-
remko
they want something to be bold, not 'emphasized'
-
Zash
jonasw: That's probably true.
-
jonasw
remko, they want something to be bold to emphasize it
-
jonasw
they don’t think in terms of semantics, but that’s what they want
-
remko
different people have different interpretations of emphasis.
-
remko
if i want something emphasized, i don't want it in italic (even though that's the standard way to emphasize things)
-
jonasw
remko, you’re free to chose strong emphasis then, people make that kind of mistakes all the time.
-
jonasw
it’s still emphasis, and that’s the meaning which is wanted to be conveyed and which is conveyed
-
SamWhited
Although, if I'm a client author I'm going to put a "Bold" button, not an "Emphasis" button and it would be confusing if on one of my other clients the "Bold" button turns out to be italics.
-
jonasw
SamWhited, when you’re saying "purely style", I’m afraid that use-cases like enumerations are excluded though.
-
remko
SamWhited: exactly
-
jonasw
SamWhited, yes of course you wouldn’t label it emphasis ;-). and it should be made clear which defaults apply for the two kinds of emphasis people have (render weak -> italic, strong -> bold; people will choose strong in 99.9% of the cases, that doesn’t matter)
-
SamWhited
yah, nevermind, I juts changed my mind again. Conveying semantics might be nice in some cases, but all I want is the most dead simple thing we can do.
-
jonasw
will all due respect, I wonder whether you might maybe want to consider not only what you want ;-)
-
remko
jonasw: so you're saying that you're offering a bold and italic button, but insist they're using semantics? It has to render the same way on the other side, so i don't think it's semantics anymore.
-
SamWhited
I just gave you the reason why client developers want it.
-
SamWhited
(probably)
-
jonasw
SamWhited, as a client developer, I want to have one markup which covers all things my users are likely to encounter. This includes more complex messages (possibly generated by automated systems, similar to slack integrations or something). And I don’t want to have to support three different tiers of markdown dialects to achieve that.
-
jonasw
I may not offer my users the tools to create, e.g., a three-level nested enumerated list in the interface, because this ain’t a word processor.
-
Zash
People can't use a comma?
-
SamWhited
Wait, what? Who said anything about multiple tiers of markdown dialects?
-
jonasw
Zash, context?
-
Zash
jonasw: lists
-
jonasw
SamWhited, that’s what happens if we go down the route of "we’ll start with some simple text-based markup and oops, then we’ll find out two years later that we also need something to do lists or whatever, so let’s bump the namespace"
-
jonasw
Zash, bullet points, if you will
-
zinid
Zash: lists are easier to read I guess
-
jonasw
much easier
-
Zash
Do peopel use this when talking?
-
zinid
I do sometimes
-
jonasw
Zash, I do ;-). but also, "possibly generated by automated systems"
-
SamWhited
I think that: 1. That's probably not a problem 2. It already works fine
-
zinid
Zash: for example to tell my wife what to buy in a shop ;)
-
Zash
I have found a 𝐁𝐎𝐋𝐃 solution!
-
jonasw
it works fine until you have multiple lines in a bullet (e.g. due to word-wrap) and then it is unreadable, SamWhited,✎ -
jonasw
it works fine until you have multiple lines in a bullet (e.g. due to word-wrap) and then it is unreadable, SamWhited. ✏
-
jonasw
I would like to quote a few things from the Zen of Python which have been in my mind during this whole "the new markup for XMPP" discussion: Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. […] In the face of ambiguity, refuse the temptation to guess.
-
jonasw
and also, especially since people are now suggesting that they’re creating precedents by implementing things in a wide-spread client: Now is better than never. Although never is often better than *right* now.
-
Zash
dwd: btw, *bold* in markdown isn't bold, but italics :P
-
jonasw
(that, too)
-
jonasw
SamWhited, I really, really don’t understand what the issue is with creating an extensible, very simple markup or re-using one instead of restricting us to a very small set of things.
-
SamWhited
I never said there was a problem with it
-
jonasw
fair.
-
jonasw
I somehow felt you did, but that wasn’t true.
-
jonasw
maybe I mixed up an email somewhere and had that lingering thought somewhere, I apologize.
-
Zash
SamWhited: Do you think any XML based format will be too easy to do the wrong thing with?
-
SamWhited
Zash: I'm not sure, I suspect so, but I have no idea.
-
zinid
Zash: only when you put unescaped cdata into DOM?
-
SamWhited
XMPP doesn't allow CDATA, no?
-
Zash
Question is, where's the cutoff where people will prefer the right thing?
-
jonasw
SamWhited, cdata is any text, actually
-
zinid
SamWhited: well I mean the content of <body/> for example
-
SamWhited
*unescaped CDATA
-
Zash
SamWhited: You are thinking of <![CDATA[ ]]>?
-
Zash
Whatever that's called
-
SamWhited
yah, that
-
Zash
Do we disallow it tho?
-
zinid
no, I meant a text within tags in general
-
zinid
I see no other way how to screw up
-
jonasw
zinid, I have one: let’s say we have a tag <emph/> for emphasis
-
zinid
we can assume that you can screw up during transforming layout element into DOM, but you can screw up this way with any formats
-
jonasw
a client may simply do a translation mapping the emph local name to em for XHTML.
-
Zash
Also wtf unicode has all sorts of 𝗯𝗼𝗹𝗱 𝘁𝗲𝘅𝘁
-
jonasw
and then fail to remove attributes such as onclick="alert('fnord')"
-
zinid
jonasw: yes, but you can do the same with other formats, no?
-
jonasw
not with non-XML formats
-
jonasw
you’d have to actively put attributes in the result
-
Zash
I think non-XML formats may be to easy to just run trough a regex and allow HTML trough
-
jonasw
Zash, depends
-
jonasw
think: [{"text": "some text", "emphasis": "strong"}, {"text": " and now without emphasis"}] -> '<strong>some text</strong> and now without emphasis'
-
jonasw
you can’t regex that in any reasonable way.
-
jonasw
anything in ["text"] will have to be htmlescaped, but otherwise it should be safe.
-
zinid
jonasw: other formats can also posses kinda "attributes" and you can also copy their contents into so evil DOM element blindly, no?
-
jonasw
(now I officially did it. I proposed a JSON-transport for things.)
-
jonasw
zinid, not if none of those attributes reasonably map to any DOM element which is evil
-
jonasw
we shouldn’t be needing any attributes at all, I think
-
jonasw
except maybe class if we do that palette thing
-
jonasw
(okay, href too)
-
Zash
[{"c":[{"c":"bold","t":"Str"}],"t":"Strong"},{"t":"Space"},{"c":"text","t":"Str"}]
-
jonasw
but attributes should be rather rare
-
Zash
^ actual JSON "markup" format.
-
jonasw
Zash, not sure if that’s some serious markup you found somewhere or if you’re trolli... oh dear
-
jonasw
I don’t know what that does
-
Zash
jonasw: pandoc -t json
-
jonasw
but does it work?
-
jonasw
ah, t is type.
-
Zash
jonasw: It's a JSON dump of the internal parse tree
-
jonasw
right
-
jonasw
probably not a good choice since probably underspecified
-
jonasw
but yeah, that’s the idea
-
Zash
<Strong><Str>bold</Str></Strong><Space/><Str>text</Str>
-
Zash
~$ pandoc -t native <<< '**bold** text' [Para [Strong [Str "bold"],Space,Str "text"]]
-
zinid
jonasw: if we can map attributes reasonably, can't we do the same for xhtml-im? and then forbid unknown attributes/elements
-
jonasw
zinid, the difference is that one requires action to fail, the other requires inaction.
-
zinid
I don't understand
-
jonasw
of course, XHTML-IM already defines that some attributes are evil and you need to remove them.
-
jonasw
that doesn’t magically make developers do that.
-
SamWhited
Even if they do it, any trivial mistake in the white list logic results in a vulnerability.
-
zinid
XML schema?
- zinid hides
-
jonasw
zinid, sure, nobody does that.
-
jonasw
it requires action to do that
-
jonasw
getting developers to take action is what’s tricky
-
zinid
yeah, I know
-
jonasw
(if it was only about trivial mistakes, we could provide an audited reference implementation)
-
jonasw
(either based on XML schemas or whatever works in JavaScript)
-
zinid
ok, we refuse xhtml-im, then what?
-
zinid
there are 100500 formats and we can invent others
-
zinid
how to choose?
-
zinid
ah, and we need to make sure there are no potential vulnerabilities, hell yeah
-
zinid
regarding markdown: if we don't choose it, then developers will blame us even harder that we don't use "modern" technologies like json or markdown, or rest :)
-
jonasw
zinid, I’m all in for a JSON-based markup
-
zinid
for example, I heard "xmpp is dead if they don't switch to json" and seems like people tend to agree with that
-
Zash
I note that PEP examples doesn't include the 'http://jabber.org/protocol/pubsub' feature. Is that supposed to be implied by <identity category='pubsub' type='pep'/>?
-
Zash
And the last version of PEP changed that section from being to=host to to=account and /some/ unnamed implementations still advertise stuff on the host
-
moparisthebest
Why hasn't anyone taken my bbcode suggestion seriously?
-
moparisthebest
On an actual serious note, there are markdown standards, we could just pick one
-
moparisthebest
http://commonmark.org/ is the best I know of