[Standards] Suggestion for XEP-0045 : permit alias for the MUC address

Alexander Holler holler at ahsoftware.de
Sun Sep 25 09:54:55 UTC 2011

Am 25.09.2011 11:39, schrieb Kevin Smith:
> On Sun, Sep 25, 2011 at 10:34 AM, Alexander Holler<holler at ahsoftware.de>  wrote:
>> Am 24.09.2011 23:51, schrieb Waqas Hussain:
>>>> 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) ;)
>>> Kev is correct. MUC aliasing can work fine without any protocol or
>>> client changes. A server doesn't need to forbid letting a client enter
>>> a room in two ways. It would work fine. And I can't think of any
>>> pitfalls regarding the delay element.
>> The pitfall is that you can't stamp the delayed stanza when the delaying
>> actually occurs, which means you have to do that somehow else. If you do,
>> you will have to change that afterwards (when sending out). Stuff like this
>> is what I call pitfalls.
> I don't see why aliasing would affect the way delay elements are
> inserted into room history. Please explain.

The from in the delay element has to be the domain (alias) the receiving 
occupant connected to. And the server doesn't know that when the stanza 
will be stored. Anyway, implementing it somehow else is no problem.

But I don't want to continue this discussion.
I agree that it is possible without changing the XEP, so the original 
request to change the XEP is fulfilled because it isn't needed. So 
everyone can go on and implement it.



More information about the Standards mailing list