On Tue, Sep 27, 2011 at 2:36 AM, Peter Saint-Andre <[email protected]> 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@service> is different > from sending it to the Occupant JID <room@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@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
