XSF Discussion - 2018-07-11

Do you guys know if is there any MUC for Monal?

AFAIK no

Does Monal support MUC?

Yes it does, MattJ

One thought about XEP-0177: Jingle Raw UDP Transport Method...

Section 4.4 says, that upon sending/receiving session-accept action, entity should start immediately send media.

So, application level XEP's will start doing job before they even sure the connection succeed. Is it a good idea?

Maybe it's better for transport XEP start sending something meaningless, independent from application level XEP, like 1 datagram of '\0' byte 10 times per second.

And once it receives a datagram, stop sending it and notify application, that connection succeed, to let it send real media.

How do you know for sure that a single null byte is meaningless?

And to answer your first question: I don't see a problem doing what the XEP demands, but maybe I miss something?

Yagiza, it doesn’t matter

Yagiza, UDP is lossy anyways, and the media layer needs to be able to cope with loss

flow, I'm not sure. But at least it consumes less traffic and we may be sure that application won't start sending anything useful before connection succeed. And it will make transport level XEP really independent from application level XEPs.

jonasw, I think Yagiza possibly had error cases like "could not connect to remote host" in mind

But even those could be dedected after sending the data over the UDP stream

flow, yupp, exactly

and if everything is fine, it speeds up sending of media

Yagiza, I still don't see the problem

Yagiza, also UDP is stateless, there is no connection succeeded in TCP style

and inventing your own handshake on top of UDP is...meh

your network stack will eventually notify you if it became aware that the UDP packets don't arrive at the destination

but they could also simply go down into a black hole

Yes. Receiving data is the sign, that connection succeed. So, I just want to separate application level XEP from transport level.

wouldn't it only notice that if they get bounced?

Transport establishes connection and application utilizes it.

UDP is connection-less tho

Zash, yes

Zash, but transport level implies some kind of connection, and it doesn't matter what on lower level goes on.

Yagiza, no, it doesn’t

UDP is transport level, UDP does not imply any type of connection

if the application requires reliability of any sort, it needs to either use TCP or do something by itself on top of UDP

jonasw, UDP is not a fully transport level. It's somewhat between transport and network level.

ISO/OSI or IETF levels? 😁

Ge0rG, at least OSI (^_^)

Gosh, I wish OSI levels would finally die.

Didn't they? :)

Sometime in the '80's, everywhere other than Isode, I thought.

And at all universities

True. The concept of layers is quite useful, but the notion of trying to peg UDP's "layer" as something other than "UDP" isn't helpful.

What about the concept of 0198 being the Session layer and 6120 the Presentation layer? Those who don't understand history are bound to repeat it?

6121 is the Application Layer? What's TLS?

I thought the Session layer included authentication, so I'm not sure 198 counts there. But I never paid much attention to it really.

I'm not saying it's a perfect match. Actually, it's a set of horrible hacks created to mimic those layers, rather imperfectly

TLS doesn't fit into the OSI model at all. You can't have Lawful Interception on top of it.

And I'd count 6121 into Presentation as well.

I think our layers are now 1*(Physical, IP, Transport) [TLS] Application [SASL / 1*XEP]

Hmmm. Maybe the optional TLS layer is in the low-level repeating stack (for VPNs).

I'm not sure about your notation.

Ge0rG, ABNF just 'cos.

Or maybe it's just too late to do meaningful work today.

In Gajim we have issues with Cisco Servers, it seems Gajim gets often disconnected with resource conflict error

after that Gajim changes resource, but gets disconnected soon again

does anyone know whats up with this?

Is there a Cisco support channel for the xmpp server stuff?

has anyone connections to some devs that working on this thing?

I can't imagine that. Unless you are a paying customer.

ok in theory what are reasons by the standard for resource conflict

i know the rfc describes that its allowed to not let a resource connect 2 times

when another client is logged in (or just logs in) with the same resource.

then they have to issue that error

typically, when a second client connects with that resource, one of them gets killed.

ok defince second client

sane servers kill the old one, because they assume that it's the same client, coming back from a network change

if i disconnect because of wlan

and reconnect without smacks

am i considerd a second client?

the server can't know if it's the same client or not, except *maybe* based on the resource you want to bind

some developers say the server should just assign you a new random resource and have the zombie stay online

ok so its definitly about the resource

there is no other reason where this would be issued

if it's a resource conflict, I'd assume that

Hand out new resource, ping the old, ???, profit!

Is it https://xmpp.org/rfcs/rfc6120.html#streams-error-conditions-conflict

dwd said somesuch at some point iirc

User says: "The dialog starts to appear within a minute to a few minutes after connection is established. "

Zash: in theory I might agree, but in practice we haven't sorted out the MAM/Carbons mess and messages will get lost and/or bounced. Maybe with a significant delay.

which makes no sense

there is no second client involved

why would it let me connect and issue that after a minute

Great question.

lovetox, does Gajim still support the RFC 3921 session iq?

Old ejabberds used to have a similar behaviour if you didn't use that

Random shot in the dark

hm no thats not it, user just confirmed it was the same with gajim 0.16, so this was like this forever, just that gajim would automatically switch resource without user telling, so they might not noticed it

so i might solve this again like that

and just switch resource

Zash: will your tombstoning in prosody support the alternate jid?

i think so daniel, the stanzas i saw included a alternate jid

daniel: yes, it saves the alternate jid from the destruction command and now includes it with the <gone> error

wait there is a gone error now?

i thought you wanted to do unavailable with destroy

Zash, can you give me an example of the stanza you want to implement?

Hm?

daniel: I changed it to a normal error reply

Clients didn't like the unavailable, and flow pointed out on the list that error made more sense (which I agree with)

can you give me an example of that presence?

and jonasw

<presence from='room@muc.host/nick' type='error' id='1'><error type='cancel'><gone xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>xmpp:long-long-time-ago@far-far-away.galaxy.invalid?join</gone><text xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>Nuke it from orbit, it&apos;s the only way to be sure!</text></error></presence>

daniel: that ^ in reply to a join stanza

ok. thanks

MattJ: Our error reply code doesn't make it easy to attach text in <gone> :/

lovetox, Holger: looks like that change was not publicly discussed as far as I can see

So we'll probably never know

*THE* change

Seems it was applied by Ian Paterson who's long gone I guess ...

then its time we bring it back :)

At least he probably won't stop you from doing that :-)

Yeah, pretty sure he just disappeared

He was quite active and authored a number of XEPs

Context?

Oh!

Wrong MUC

jdev@

We really need more mucs

MORE

With the same 20 people in all of them :)

Hah, I didn't notice either.

plus the double amount of popcron chewing spectators

Until one day, The Great Merge

Yeah. One big discussion venue. Twitter?

With hash tags instead of rooms

Tags are the new groups. Even multi groups

does "THE change" have a commit id?

flow, no, I don't think anything from the CVS days is in git

what a pity

Is there somewhere a backup of the CVS? We could re-root the whole history onto reposurgeon

How many VCSes have we gone through?

Gosh. Zoofy. There's a blast from the past - he was on the first Council I got "elected" to. (uncontested of course).