XSF Discussion - 2017-10-16

RFCs like 7564 make me cry

instead of providing a simple pseudo-code there are 40 pages of stupid definitions

feel free to submit a draft doing so.

lskdjf no, please no, it's like saying that you don't need proper validation in HTML/JS because the database can handle that

SamWhited that would be nice yes :)

pep., XEP-0392 offers a way to adapt the colors to a given background.

or overall theme tint

Is "Remko" here, the dude that wrote a mail about OMEMO key agreement recently?

Syndace, sometimes

yesterday or on saturday he was

why are you asking?

I read a lot about OMEMO recently and I want to discuss his question a little while not spamming the mailing list with probably unqualified comments :D

is his nick in here remko aswell?

yupp

Syndace, there’s always the option of replying only to him

jonasw: re color generation, nice

jonasw, I decided to risk it and answered the list ^^

Syndace, good question you posted :)

edhelas: the little tool I use isn't actually on this machine, but here's a quick one that just checks if the first argument is a valid JID: https://gist.github.com/SamWhited/faaa24d72e06903122152a5a17984fe7

Note that by default that will be using the newer version of PRECIS from RFC 8264 and Unicode 10, but there shouldn't be any major differences.

https://xmpp.org/extensions/inbox/bmh.html Is that Flow? What happens if a client doesn't announce any supported markup? will the other client send non-formatted plaintext? Or the same but untagged?

MattJ, lovetox is having issues joining the channel, possibly the stalled s2s bug. he’s in jdev. Care to debug?

pep.,: what do you think would be best?

Is there a need for the XEP?

pep I obviously think so, as otherwhise I wouldn't have go through the effort writting it

Well the example I showed above kind of defeats the point

pep., your question?

yes

pep., I don't see how it defates the point

The markup is going to make it _as is_ to the other side in any case

With MAM, carbons and whatever, you have no way of knowing if all the clients that receive it supports it.

Ok, so maybe it's time to provide some motivation for BMH

I was going to wait until the offical editor annoucement, but it looks like people get into the wrong direction about what it's about

It would let those who understand it know for sure that it is what the sender intended.

Zash, that!

And why not xhtml-im?

You're assuming it's already out, right?

So BMH does not try to be a successor of XHTML-IM

It's not even meant as intermediate solution

The case for BMH is bridges which take Markup formated text, and send it via XMPP to an XMPP client

For example a Stackoverflow bot, which sends you an question and a answer

Or a discourse interface

Thing could in theory have serverside translation into XHTML-IM or XEP-future-markup-thing

Or a Bot which sends you status information with headings and sections and stuff

well the gateway/bridge would know markups the other side sends, and could translate it into XHTML-IM

I'm not sure more is needed

If you client doesn't know the markup language, fine, it will still display the text more or less nicely

If it does understand the markup hinted markup language, it can throw it into a converter and show it in a richful way

So it's equivalent to the Content-Type header in email

pep., Not every client supports XHTML-IM

Which is fine.

Flow, the more reasons to implement it

Not every client supports $MARKUP

Flow: pep.s point of the discovery section being fairly pointless stands tho

OTOH it is mandatory in XEPs

Zash, yep, the discovery was just a goodie I wanted to take along

I'm still not sure I see the point. This can be totally covered with xhtml-im

Flow, please do add some more details on the XEP so we can comment on it before it's accepted

:)

pep: I've responded on the editor announcement

Also the latest snapshot of the xep may contains more backstory: http://geekplace.eu/xeps/xep-bmh/xep-bmh.html

Meh, a 2 week last call for so important cornerstones like MAM feels a little bit to short

thanks

I'd like to make motivation the first requirement of a protoXEP :x

Isn't that usually supposed to be covered in the first section?

Well apparently not enough

Like, a problem statement or somesuch

"Why is this needed", "Are there existing XEPs trying to solve the same issue or similar/related ones", "How does that compare to these XEPs", etc.

please direct blame to the lazy me :)

Flow, I can see a point for your XEP here, just that it doesn't really come at a good time, with the latest events around XHTML-IM and people trying to kill it

Also I fear people are going to abuse it

And give up on xhtml-im for this

Was there an easy way to get schemas out of XEPs?

Zash: Ctrl+C, Ctrl+V.

Zash: You can probably use one of the xpath CLI tools to grab this: https://github.com/xsf/xeps/blob/master/xep-0016.xml#L856

No idea if this stuff is consistent across XEPs

In this specific instance I'm interested in getting schemas out of XEP60

And I seem to have repressed^W forgotten how XPath works

https://github.com/xsf/xeps/blob/master/xep-0060.xml#L6522

Copy paste, and split on the CDATA sections

Oh, it uses <xs:import /> to reference an external 'http://xmpp.org/schemas/x-data.xsd' too

Hm, I have this strange memory of fighting xpath or xml search tools in order to get them to spit out bare text, and giving up beacuse it's impossible.

Why is {pubsub#errors}unsupported a MUST?

Why does the implementation need to know all the things it doesn't do?

And isn't this the job of disco#info?