On 9/27/11 7:29 AM, Waqas Hussain wrote: > 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).
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@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. 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@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@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@service/ " "room@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 problems. >>> 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 -- Peter Saint-Andre https://stpeter.im/
