[Standards] request for reviews: XEP-0045 v1.25rc5

Waqas Hussain waqas20 at gmail.com
Tue Sep 27 13:29:22 UTC 2011


On Tue, Sep 27, 2011 at 2:36 AM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
> On 9/19/11 11:34 PM, Waqas Hussain wrote:
>
>> 3. Service changing room nick
>>
>> I'd like some text stating that a service can change the occupant's
>> nick at any time, including room join. An occupant MUST listen for
>> status code=100 in available presence for their current nick.
>
> I understand nick changes on join, but not after that. What is the use case?
>

Implementing policies such as lowercasing all nicks (these happen on
room join, or when user initiates a nick change). And there's also the
case of applying these when a user has not requested a nick change
(e.g., a user registers a nick with a room, the service may force a
nick on them when an admin accepts the registration).

I'd like the spec to be explicit on whether the server is allowed to
do this or not. I'm in favor of allowing it. I don't like it being
undefined.

>> 4. Presence from existing occupant to bare room JID
>>
>> The MUC's behavior is currently undefined. At least for the
>> type="unavailable" case (and perhaps also for the available case), the
>> MUC should handle and treat it as if it was sent to the occupant's
>> nick.
>
> I disagree. Sending presence to the Room JID <room at service> is different
> from sending it to the Occupant JID <room at service/nick> (e.g., the user
> might be sharing presence with the room itself, if the user and the room
> are subscribed to each other's presence).
>

Alright.

What I had in mind was one popular client (I can't remember which)
which sent unavailable to the bare room JID. I'm fine with it being
considered a client issue, and leaving the spec as it is.

I'll note that both ejabberd and Prosody do this. I haven't tested
other servers.

>> 5. Both <subject/> and <body/> in a single message
>>
>> "(A message with a <subject/> and a <body/> is a legitimate message,
>> but it SHALL NOT be interpreted as a subject change.)"
>>
>> I object to this. It complicates subject handling. I believe much
>> existing MUC software considers a message a subject change if it has a
>> <subject/> in it. How should software determine this? Assume it's a
>> subject change if there's no <body/>? What if there is not body, but
>> xHTML-IM is included? What if there's no body, but some
>> <unknown-element/>?
>
> IMHO a subject change should be a message with *only* a <subject/> child
> element and no other children.
>

Software which seems to follow my definition of a subject change, and
not your's: ejabberd, Tigase, Gajim, Miranda. And Prosody.

Pidgin is special, in that it displays the <body/> in the chat log,
and displays the <subject/> above the chatlog. M-Link on jabber.org
seems to return a <not-acceptable/> error on getting <subject/> with
any siblings. I didn't manage to find anything else which didn't
follow my definition.

Also, some servers add <delay/> elements to the subject message sent
to the client, with the time of when the subject was set, and could
add other things (crypto signatures, etc).

>> And I have mixed feelings about that MUST NOT.
>
> We had some discussion about that years ago, and decided that Occupant
> JIDs like "room at service/      " would be problematic. Do you have a use
> case for those?
>

What are these problems?

For one thing, most existing software doesn't enforce this.

For another, 'invisible' isn't defined. Does this mean nicks
consisting entirely of unicode whitespace characters? Does this fix
all the problems? Or do we have to take this further? e.g., does the
partially invisible nick "[space]stpeter[space]" have many of the
problems of all-whitespace nicks? That MUST NOT just seems like an
inadequate fix for a complex problem (assuming the problems are what I
think they are).

>> 9. In schema section 18.2 http://jabber.org/protocol/muc#user
>>
>> I'd like <xs:element ref='item' minOccurs='0'/> changed to <xs:element
>> ref='item' minOccurs='0' maxOccurs='unbounded'/>, to allow one <item/>
>> element for each session in a multi-session nick when including 'jid'.
>
> I have no deep objections to that, as long as we don't try to define
> mult-session nicks in this spec.
>

Agreed, I'm all for making XEP-0045 smaller, and moving most optional
stuff to separate specs.

>> 11. Full-to-bare JID rewriting to support vCards
>>
>> All(?) implementations are doing it, but it's not specified anywhere.
>> Should it be?
>
> Yes, it should. Proposed text would be appreciated.
>

Err... a quick attempt, probably not too good:

[Section 16.4: IQ]

6. If an occupant sends an IQ get to another occupant with the child
element <vCard xmlns='vcard-temp'/>, the room SHOULD route the stanza
to the target occupant's bare real JID. The room should also rewrite
the 'from' attribute of the IQ result response to the initial target
occupant's full in-room JID. The room can store any state required in
'id' or 'from' attributes of the IQ get stanza it sends.

--
Waqas Hussain



More information about the Standards mailing list