jdev - 2020-01-21

rfc says https://tools.ietf.org/html/rfc6120#section-4.4 when closing a stream the side that closes has to wait for a closing in return

but does that make sense in the case of a stream error?

i get if i close the stream normally i want to give the other side the oppurtunity to send everything out it was going to send

but in the case of a stream error, i will ignore anything anyway

lovetox: if you'll ignore then yes. But does the RFC even allow clients to send stream errors?

yes MattJ why not

lovetox, why do you have to ignroe any inbound stanzas on stream errors?

if i receive not well formed xml from the server

and end the stream with a stream error

why or how would it make sense to wait for more xml from the server?

stream errors are not recoverable, means to me, all xml parsing ends right there

ok, but thinking about the generic case, not the specific case where you can't recover from an ill formed xml stream

nothing forces you to not wait for the other side to close the stream and continue processing inbound stanzas

nothing forces me, but then i would ignore the "unrecoverable" rule for stream errors

as i would still wait and parse inbound stanzas even after an stream error

I think the rule leaves room for interpretation

that was not my question, if i *could* do it

may question was does it make sense

is there a case where i want data from the server even after he violated basic rules of a stream

If you can process the data, then I don't see and advantage by not doing it

*an advantage

If you can process the data, then I don't see an advantage by not doing it

but there is no stream error other than malformed xml ones

that client could send

most stream errors are related to server actions

like conflict, host-gone, not-authorized

etc

but yeah from the examples, i think its expected to send a close stream back even on error

maybe malformed-xml is the exception where it really makes no sense

What about errors on the layer above xml, like using XML mixed content, which is allowed by XML but disallowed in XMPP

flow, /correct

pep., and then I have to type the whole message again? Or is the idea that I select the message from the history, prefix it with '/correct', then correct it and hit enter?

/correct <tab>

Then you can edit and resend

But you can also /correct anothermessageinstead

ui ✏

And poezio doesn't yet implement the LMC "clarification"

the "strike the last" from LMC?

no, the "always use the first id"

Otherwise yes in reading we do "Message Correction", not Last Message Correction.

We only send the last via /correct, but you can do /rawxml :x

another problem, say i send close stream

and the server answers with more stanzas because i let him like the XEP suggests

i cant ack these messages anmore via streammanagement

so the server will think i didnt get those messages

..

You can if you resume

does close stream not mean i cant resume?

Oh, right :)

Yeah

i think it causes more complexity and problems if after stream close, i wait for a stream close in return or any other stanza

i dont see any benefit for client or server

lovetox, the stanzas could still have been in flight

if your link has latency

you need some way to deal with this, even though "drop everything and log errors" may be a valid way

Resource-*un*-binding before /stream?

you still have to deal with stanzas which are in-flight when you send your unbind

same difference

send un-bind, maybe receive stanzas, receive unbind-ack, send /stream, receive /stream

how’s that different from send /stream, maybe receive stanzas, receive /stream?

you can maybe send sm:a?

ah, that

yeah

more roundtrips!

gotta add some after removing from the start

probably not

Zash, I thought about that too, sure adds complexitly, which always opens up the discussion if it's worth it ✏

can get Close Enough ™ with unavailable presence I guess

yeah, but nice to think about it

Hi all, when an user join a private room, I don't want him to have access to previous messages, only new messages. Is there a way I can accomplish that?

Yes, this can be implemented

Not aware of any publicly available such implementations tho

Thank you, Zash. So I would have to write a module for this? I'm new to XMPP and currently I'm using ejabberd. Could you give me some references on how to get started on that?

links with docs or tutorials, besides ejabberd website itself, if any.

I can't do better than your favorite search engine I'm afraid

no problem, thanks anyway

leosbrf, you may also want to ask this in the official ejabberd muc

hi, is there some XEP or part of Core that defines capabilities for registered accounts? something like userA cannot make use of the MAM or Carbons, for instance? Something like different kind of accounts with different sets of permissions

marc0s: that sounds like a policy configuration, not a protocol. What would you write down in the xep?

Ge0rG, that sounds right, indeed. Maybe I'd like to have a way to query that policy. We've been asked for some weird (IMHO) requirement where some kind of accounts would only be allowed to receive messages, not sending them, but at the same time, senders should be aware of the recipient will not be able to answer because of that policy. I was just wondering if something already existed for that before inventing our own (basically doing that check out of band)

marc0s: you might be able to appropriate https://xmpp.org/extensions/xep-0317.html (Hats) or https://xmpp.org/extensions/xep-0310.html Presence State Annotations

but I'm sure there is no in-the-wild client support for either

thanks Ge0rG. Client support is not an issue, we're rolling our own, based on stanzajs. Will have a look at that XEPs

em, disco info comes to mind?

but instead of routing it to the users, let the server answer with the caps for this account

so a little server addon :)

A: "can you send messages" B: "no but since I can't send messages I can't reply" A: *still waiting for response*

lovetox, yes, disco can be another way of solving this. Actually the XEP states than when querying a bare jid, it's the server who should answer, if I didn't misread it... so maybe yes, that's something a module can solve

moparisthebest, :D