Am 24.09.2011 11:57, schrieb Kevin Smith:
On Sat, Sep 24, 2011 at 9:48 AM, Alexander Holler<[email protected]> wrote:
Hello,
Am 23.09.2011 23:19, schrieb Peter Saint-Andre:
On 9/23/11 3:17 PM, EcliptuX wrote:
Le 23/09/2011 23:05, Peter Saint-Andre a écrit :
On 9/21/11 12:01 PM, EcliptuX wrote:
Hi,
On my jabber server, I'm running a MUC on the address
conference.domain.tld
I want to be able to create an alias like muc.domain.tld, but the
XEP-0045 don't permit it.
Is possible to add this specification in the next release ?
The specification doesn't restrict the addresses -- I have seen
conference.jabber.org, muc.xmpp.org, rooms.swift.im, etc.
I think I was not clear :)
I have an active room named [email protected]
I regret the choice of the term "conference"
I regret the choice of "conference.jabber.org" many years ago, too, but
it's the best that Peter Millard and I could come up with at the time.
and I want to change it to
a shorter one as "muc"
I want to have my room on [email protected], but I want to
keep the old one working ! I don't want to disturb my guests !
So, I really want an alias of @conference.onnouscachetout.com to
@muc.onnouscachetout.com
And it's look like the XEP-0045 don't support this fonctionnality yet :)
In general we don't have JID aliasing. However, this is probably
something that your MUC implementation could do for you -- I don't think
it's a spec issue but a deployment issue.
How should a server handle that? What should be used as 'from' for messages
without confusing clients?
If such should work servers and clients have to changed to be able to handle
JID-aliases. And that isn't something which is done with changing a few
lines and isn't (imho) worth the time needed.
MUC aliasing is actually one of the very few cases in XMPP where
aliasing could work without protocol extensions. The server would know
which alias each client has joined and can route messages from that
JID. I don't know any server implementation that does this, but if one
did it wouldn't require client changes or deviation from XEP-0045.
I think confusion on the client side would start if a client connects to
both aliases without knowing they are aliases. A server would have to
forbid that with a meaningful message.
And handling room-aliases on the server side would have many pitfalls
(e.g.the delay elements in the history). I'm not sure where else
room-JIDs are used (besides in 'from'), that would require checking the
whole XEP for appearances of room-JIDs (which currently isn't that easy) ;)
Regards,
Alexander
