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

Peter Saint-Andre stpeter at stpeter.im
Tue Sep 27 20:44:20 UTC 2011

On 9/27/11 7:29 AM, Waqas Hussain wrote:
> 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). 

Right, the nick change use case makes sense. Sorry I missed that.

> 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).

Maybe. But why wouldn't the service enforce the nick rules on 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.

I agree that the server should be allowed to enforce its nick rules
whenever necessary. We can argue over when it's necessary to do so. :)

>>> 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.

Well, XEP-0045 says:

   In order to exit a multi-user chat room, an occupant sends a
   presence stanza of type "unavailable" to the <room at service/nick>
   it is currently using in the room.

That's pretty clear, I think. If a client violates that rule, then it
has a bug. :)

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

"Be liberal in what you accept", sure.

>>> 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).

Yes, that's possible. But we've defined a subject change request as
message-with-subject-but-no-body for a long time now.

Naturally, if we were designing this all from scratch we'd probably use
an ad-hoc command for subject changes. :)

>>> 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?

How in a client do you show the difference between the following two nicks?

"room at service/      "
"room at service/     "

> 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).

I think there are problems. I agree that there are even more complex

>>> 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.

Not bad. But do we really want to special-case this for "vcard-temp"? At
the very least, why not "urn:ietf:params:xml:ns:vcard-4.0"? And at most,
the same logic might apply to extensions other than vCard...


Peter Saint-Andre

More information about the Standards mailing list