XSF Discussion - 2018-08-22

RFC6120, 7.6.1 > Once the server has generated an XMPP resourcepart for the client, it MUST return an IQ stanza of type "result" to the client, which MUST include a <jid/> child element that specifies the full JID for the connected resource as determined by the server. From what I understand, we generally assume that the resource can be forcibly assigned by the server. Does this sentence also mean any other part of the JID can be rewritten? (localpart, domain)

New messenger, LAN only, https://github.com/dakhnod/Meshenger

pep.: I *don't think so*. Host at least has to honour the stream to attribute.

pep., yes, it can

pep., before binding, there’s not really a JID anyway

there’s just the SASL identity, and that doesn’t have to match the JID

everything else (like stream @to) is just informational

pep., there was a prosody module which would integrate with some forum software, and it would create a JID which didn’t match the SASL identity (based on the forum username) if the SASL identity contained stuff which wasn’t allowde in the JID

I'd like to actually see a server that dishes out a different host in the jid than the one you opened a stream to c2s wise

the host will probably stay what the client expects it to be, indeed

not that it really matters

(I also confused stream @to and @from)

(@to isn’t quite that informational given that it’s used for TLS already)

Aaaand I need cooooffeeee ☕

Maranda: The hosted GTalk thing would assign you a different host IIRC

Zash: Huhu, I recall it opening s2s streams with no to or from and expecting those to be set from dialback. But that one sounds more hilarious

On c2s tho

Yeah but me think clients would tell it where they're opening a stream to in that case 😆

Could that mechanism be used for JID aliases?

As a neat upgrade mechanism when for instance a provider upgrades from example.com to example.org?

Wasn't there some 301 xmpp version proposal as opposed to that?

Link Mauve, the main issue with changing domains isn’t the local, but the remote side

Or rather make that "a xmpp version of status code 301"

jonasw, sure, but when you did migrate your domain (I remember pep. having to do that), it makes it transparent for your users.

Link Mauve, how is it going to be transparent when all the remote roster entries are borked?

Yeah, at least you don't have to have a flag day

In a company, where you are already using shared groups and mostly communicating locally, it does make sense.

right

Link Mauve, rewriting the bare JID could be a helper, but I think there’s a stream error for it

You will indeed still need that flag day when actually switching the actual account

Than tellin' someone his jid magically changed when he/she binds a resource...

What I meant above would have been the opposite really. "you can use your new _credentials_, but for now it'll still bind to the same old jid"

I'm pretty sure at least 95% of the clients out there would start coughing blood if there's a change to either the node or the host portion of a jid they don't expect anyways

When I was working on XMPP (PubSub) based federation for social networking sites, we had full movability of objects. Something would move to a different site and we'd send a node deletion notification with <redirect/> element pointing to the new place.

It's not like it was explicitely forbidden, nor really specified by the RFC either. Send an errata?

You can do something similar with the "gone" stanza error. It also has a way to specify the new location by putting a URI in the element.

If somebody retrieves his roster, the server will send out presence probes. If the remote server responds with "gone" it could rewrite the roster item.

also <moved/>

There's no <moved/> stanza error

Conversations will happily change the jid and use that for subsequent logins. Which in turn can be a problem some times. For example OpenFire will let you specify a jid like username@ip and on bind it gets changed to username@domain but domain won't resolve properly

-xep moved

bunneh!!

ralphm: that's for far better than what mentioned by others ☺️

https://xmpp.org/extensions/xep-0283.html

That's for sure*

But I don't like the bits in the security considerations, that defeats the point of the XEP

Damn auto correction

Or they are other weird and broken servers that use something like email@domain to login and then change the jid on bind to username@domain. And then subsequent logins don't work

And I don't think it's much of an issue

Maranda: thanks, there's a reason this stuff is there to begin with :-D

pep.: ah yeah, I forgot about that one. I don't think (now) that this XEP is needed. What does it do better than "gone"?

🤷‍♂️

ralphm, with <gone/> you need to keep track of what's gone where. With moved it's a client thing, the account can be tombstoned or deleted

Only works for roster though

yeah