XSF Discussion - 2016-01-19

Right, voted!

(Y)

it's awesome to see how diverse our crowd is

hi, I have submitted a protoxep last week-end, can I have a confirmation that it was well received by somebody subscribed on editor@ please ? Thanks :)

goffi: which protoxep?

thorsten: jid mention

Cool

thorsten: there is a rendered version there: http://www.goffi.org/public/xmpp/xep/xep-proto-jid-mention.html

goffi: let me check

And it has been acknowledged by xmpp.org?

Interesting

thorsten: I have sent id last week-end, but no response and didn't see it proposed on standard@, that's why I'm asking here

it*

that's a shame! it sounds fine so far for me :)

editor@ are probably busy, it's not a big deal if it takes a couple of days, I just want to be sure is was received...

Did you send in the appropriate way? Email to editor@ with 'XEP' in the subject?

goffi: it was received.

Kev: yes

SamWhited: oki perfect, thanks

hello everyone, I'm having a look at https://xmpp.org/extensions/xep-0369.html it's quite interesting but I'm wondering how all theses subscriptions will be listed for the clients

to display the "subscribed rooms"

edhelas: You'd combine it with the pubsub-account stuff that dwd's working on.

Kev, you have a link for it ?

Dave wrote a mail to standards@ with an outline, but there's no XEP yet.

The 'how do you tell what you're subscribed to' is a generic pubsub problem without the pubsub-account stuff, but MIX combined with pubsub-account is going to be rather nice.

What should one use for an namespace not related to an XEP? xmlns='http://projectname.org'? xmlns='projectname.org'?

You can do, yes

You might want to use "http://projectname.org/something"

so you can have different values for different protocols

MattJ: I do wonder how important the scheme is

especially in times of https everywhere

Flow: It's an opaque string

Zash: i wonder how opaque it is, there is http://www.iana.org/assignments/xml-registry/xml-registry.xhtml

but I can't find any rules or an registration for "urn:xmpp" which is used by todays XEPs

nor any saying that all strings with the "urn:xmpp:" belong to the XSF

That seems to be the IETFs namespaces

so I assume it's just convention and a requirement

*and not a requirement

Aha

-rfc 4854 ✏

Zash: A Uniform Resource Name (URN) Namespace for Extensions to the Extensible Messaging and Presence Protocol (XMPP). P. Saint-Andre. April 2007. (Status: INFORMATIONAL) (DOI: 10.17487/RFC4854) https://tools.ietf.org/html/rfc4854

http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml#urn-namespaces-1

aaahhh

Zash: ta :)

What's the implementation status of the latest MAM?

in clients

Zash: Why do you ask?

I've had a patch for a version bump laying around since forever and wonder when would be a good time to update

I personally wait for https://github.com/xsf/xeps/pull/82 to get merged until I continue Smack's MAM impl

Server-side?

Yes

It was fairly easy to support both, I found.

Our Carbons and 198 impl already do that

Still don't really like it ✏

are there any news regarding the planned group booking for the summit hotel?

Tobias: I believe everyone's just been booking it themselves.

ok...would be nice if it would have been communicated

Yeah.

but still the same hotel, right?

Yes.

seems to be sold out for wendsday to sunday..then i'll look for something else

:/

re: https://xmpp.org/extensions/inbox/content-types.html I don’t like it much, but if this is required for something, it would be nice to have a disco that actually tells which content-types are supported

instead of sending useless data that will be discarded by the other party

+1

Eg <feature var="urn:xmpp:content#text/plain"/> etc?

intosi: The change to update is small but the change needed to do both would be large and ugly :(

Zash, yeah

I really don't like it

'it' suddenly became ambiguos

I don't like it neither, it will bring more fragmentation

we use markdown and we convert to XHTML, but what should I do if somebody use markdown as text? Use XHTML version or text?

and probably other formats will come, other flavour of markdown

Indeed

MattJ: What about the JSON container XEP?

Machine-to-machine, not IM

Humans are good at interpreting the same data, in different formats, in the same way

i.e. XHTML-IM vs Markdown vs plain text with no markdown, are all going to be slightly different but still readable

The user's client does not need to know the difference

I kinda thougt they wanted XHTML-IM without XHTML-IM, by having the receiving client render it from Markdown

I think so

Which implies having multiple formats for conveying formatted text on the wire

> 17:38:33 MattJ> I really don't like it

Same could be said about XHTML-IM :)

Or well, sorta

We have plain, and we have formatted

Weirdness happens if they have different actual content

Markdown can be both, but it's not a third category

> Every XMPP Extension Protocol specification must contain a section entitled "Security Considerations"

add to that no 2 clients would use the same parser and would end up with wildly different displayed representations

There can be only Pandoc!

(Zash is currently in love with pandoc)

that'd be my preference but someone would complain that it's not a standard and has a license they don't like :)

personally I don't want instant messages long enough to require formatting, but I understand there are different use cases

msnmessenger.jpg

Booked for Brussels (Aloft)

Note I won't be arriving until late on Thursday, so will miss summit day 1

mathieui: I do believe that would be against the idea of conent hints: <body> content is always human readable, the hint is just to indicate a particular encoding

so I would simply remove § 2.2 and § 2.3 from the content-types xep

Memberbot really needs an "Aprove all" button

yes yes | xmppsend memberbot

"yes " * 17

Memberbot really does not need an "approve all" button :)

*shrug* If people care enough to take the time to apply for membership that's pretty much all I'm looking for

You are entitled to your own acceptance criteria, but I'm not comfortable with accepting without reading the application they submitted

That's fair

Particularly that there was one ineligible application this year ;)

So, if the Aloft doesn't have any rooms left for XSF people, should we be thinking of being elsewhere?

What makes someone ineligible?

I don't even understand the point of membership except to prevent someone from skewing a vote by having all their friends vote

SamWhited: Dave didn't include email address/JID. Presumably deliberately because the XEP didn't get advanced, or such.

According to the wiki, almost no-one has booked the Aloft, which suggests, given there were no rooms when Tobi just tried to book, that the majority of people won't be able to be there.

Or, the majority of people haven't updated that page

Or that.

Kev, if the wiki page represents the reality, that is :)

Wed - Thu isn't available, but Thu - Sun is.

intosi, yup..thu - sun is...but who knows how many :) but at the current time it'll probably be the same everywhere

Brussels in that weekend can be a bit of a challenge this late.