Re: [Standards] request for reviews: XEP-0045 v1.25rc5
On Wed, Sep 28, 2011 at 6:44 PM, Peter Saint-Andre stpe...@stpeter.im wrote: What I was implying was, most deployed software is not following the 'message-with-subject-but-no-body' rule, and is following the 'message-with-subject-is-a-subject' rule. Making the latter wrong and the former right is going to make most deployed software non-compliant. I think we might need to have a longer discussion about this, or a call for consensus. On the other hand, making message-with-body an acceptable way of changing the subject is going to make existing compliant software non-compliant. I'd have thought that was bad (this doesn't just apply to servers - clients also need to know what a subject change is). /K
Re: [Standards] request for reviews: XEP-0045 v1.25rc5
On 9/29/11 1:59 AM, Kevin Smith wrote: On Wed, Sep 28, 2011 at 6:44 PM, Peter Saint-Andrestpe...@stpeter.im wrote: What I was implying was, most deployed software is not following the 'message-with-subject-but-no-body' rule, and is following the 'message-with-subject-is-a-subject' rule. Making the latter wrong and the former right is going to make most deployed software non-compliant. I think we might need to have a longer discussion about this, or a call for consensus. On the other hand, making message-with-body an acceptable way of changing the subject is going to make existing compliant software non-compliant. I'd have thought that was bad (this doesn't just apply to servers - clients also need to know what a subject change is). I really don't want to change this, given that it's been this way for ages. However, a while ago someone asked about whether it's OK to send non-subject-change messages that contain a body and a subject, thus the current text in the spec. Another option would be to forbid the latter. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] request for reviews: XEP-0045 v1.25rc5
On 9/29/11 10:50 AM, Alexander Holler wrote: Am 28.09.2011 19:25, schrieb Peter Saint-Andre: On 9/28/11 2:04 AM, Dave Cridland wrote: On Tue Sep 27 22:28:49 2011, Alexander Holler wrote: Hmm, doesn't forwarding IQs be a problem for semianonymous rooms? Especially for things like vcard? Indeed; M-Link actually turns these off by defaultfor users who are anonymous (but has a configurable to turn them back on). Some clients request the vCard directly from the real jid if they see one, which effectively means that forwarding vCard requests to non-anonymous particpants rarely happens. In general, this is worth recommending, I think (and poses no new protocol, which is nicer). Isn't that handled by the existing text in Section 16.4? If an occupant wants to send an IQ stanza to another user in a non-anonymous room, the sender SHOULD send the request directly to the recipient's bare JID or full JID, rather than attempting to send the request through the room (i.e., via the recipient's room JID). Question is why forwading IQs should be needed. I don't see any reason for that. If a client knows the real JID of another occupant, he can use that. If he doesn't know the real JID, it has reason and forwarding might be dangerous without using a whitelist which defines what's ok to forward. And such a whitelist is doomed to be incomplete. Alexander, now that I think about it some more, I realize you might be right about this. I'm sure the main reason for the current IQ forwarding behavior in many MUC implementations is the desire to pull in vCard-based avatars, but by forwarding the full vCard someone can discover your real JID in a semi-anonymous room, which on the face of it sure sounds like a security hole to me... Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] request for reviews: XEP-0045 v1.25rc5
On Tue Sep 27 22:28:49 2011, Alexander Holler wrote: Hmm, doesn't forwarding IQs be a problem for semianonymous rooms? Especially for things like vcard? Indeed; M-Link actually turns these off by defaultfor users who are anonymous (but has a configurable to turn them back on). Some clients request the vCard directly from the real jid if they see one, which effectively means that forwarding vCard requests to non-anonymous particpants rarely happens. In general, this is worth recommending, I think (and poses no new protocol, which is nicer). Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] request for reviews: XEP-0045 v1.25rc5
On Wed, Sep 28, 2011 at 1:44 AM, Peter Saint-Andre stpe...@stpeter.im wrote: On 9/27/11 7:29 AM, Waqas Hussain wrote: On Tue, Sep 27, 2011 at 2:36 AM, Peter Saint-Andre stpe...@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? Example: User's current nick is 'psa', and sends a registration form with nick 'stpeter', then on registration acceptance server switches their nick to 'stpeter' for them. Example 2: Room owner selects the lowercase nicks only option in the room config. Room updates nicks of those present. What I want is text saying either this is allowed, or that this is not allowed. My vote is for allowing the server to do this. 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. :) What I was implying was, most deployed software is not following the 'message-with-subject-but-no-body' rule, and is following the 'message-with-subject-is-a-subject' rule. Making the latter wrong and the former right is going to make most deployed software non-compliant. 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... I was mostly thinking of documenting historical practice. There's a case for vcard4 as well, but perhaps that could be solved along with the PEP in MUC problem. At that point we may even have the option of deprecating the whole vcard-temp thing. I'm not too concerned about documenting this, and we could leave the whole thing for later. Aside: There has also some discussion in the jdev room and elsewhere about the room itself querying and caching vCards (and other data) of occupants, and serving occupants' vCard queries from that cache. vCards account for most of the traffic on new room join. -- Waqas Hussain
Re: [Standards] request for reviews: XEP-0045 v1.25rc5
On 9/28/11 2:04 AM, Dave Cridland wrote: On Tue Sep 27 22:28:49 2011, Alexander Holler wrote: Hmm, doesn't forwarding IQs be a problem for semianonymous rooms? Especially for things like vcard? Indeed; M-Link actually turns these off by defaultfor users who are anonymous (but has a configurable to turn them back on). Some clients request the vCard directly from the real jid if they see one, which effectively means that forwarding vCard requests to non-anonymous particpants rarely happens. In general, this is worth recommending, I think (and poses no new protocol, which is nicer). Isn't that handled by the existing text in Section 16.4? If an occupant wants to send an IQ stanza to another user in a non-anonymous room, the sender SHOULD send the request directly to the recipient's bare JID or full JID, rather than attempting to send the request through the room (i.e., via the recipient's room JID). /psa
Re: [Standards] request for reviews: XEP-0045 v1.25rc5
On 9/28/11 8:40 AM, Waqas Hussain wrote: On Wed, Sep 28, 2011 at 1:44 AM, Peter Saint-Andrestpe...@stpeter.im wrote: On 9/27/11 7:29 AM, Waqas Hussain wrote: On Tue, Sep 27, 2011 at 2:36 AM, Peter Saint-Andrestpe...@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? Example: User's current nick is 'psa', and sends a registration form with nick 'stpeter', then on registration acceptance server switches their nick to 'stpeter' for them. I've added some text about that possibility. Example 2: Room owner selects the lowercase nicks only option in the room config. Room updates nicks of those present. The spec does not define the lowercase nicks only option (or any other, more advanced mapping option) so I don't see a good place to add appropriate text. What I want is text saying either this is allowed, or that this is not allowed. My vote is for allowing the server to do this. I think it's allowed, for sure. 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 thebody/ in the chat log, and displays thesubject/ above the chatlog. M-Link on jabber.org seems to return anot-acceptable/ error on gettingsubject/ with any siblings. I didn't manage to find anything else which didn't follow my definition. Also, some servers adddelay/ 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. :) What I was implying was, most deployed software is not following the 'message-with-subject-but-no-body' rule, and is following the 'message-with-subject-is-a-subject' rule. Making the latter wrong and the former right is going to make most deployed software non-compliant. I think we might need to have a longer discussion about this, or a call for consensus. 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 elementvCard 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... I was mostly thinking of documenting historical practice. There's a case for vcard4 as well, but perhaps that could be solved along with the PEP in MUC problem. At that point we may even have the option of deprecating the whole vcard-temp thing. I'm not too concerned about documenting this, and we could leave the whole thing for later. Aside: There has also some discussion in the jdev room and elsewhere about the room itself querying and caching vCards (and other data) of occupants, and serving occupants' vCard queries from that cache. vCards account for most of the traffic on new room join. I like that idea. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] request for reviews: XEP-0045 v1.25rc5
On Mon, Sep 26, 2011 at 10:55 PM, Kurt Zeilenga kurt.zeile...@isode.com wrote: On Sep 26, 2011, at 2:36 PM, Peter Saint-Andre wrote: 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. I think one ought to allow for extension elements in the subject change message. For instance, say the subject change message is delayed at an occupant's server, which hence adds a delay/ element. Hence, I think it should be a subject/ child with a body/. I don't mind if it has other children than subject/, but existing implementations require there to be no body/ on a subject change, and I see no reason to break them at this stage. /K
Re: [Standards] request for reviews: XEP-0045 v1.25rc5
On Sep 26, 2011, at 11:09 PM, Kevin Smith wrote: I think one ought to allow for extension elements in the subject change message. For instance, say the subject change message is delayed at an occupant's server, which hence adds a delay/ element. Hence, I think it should be a subject/ child with a body/. whoops. s/with/without/ here. I don't mind if it has other children than subject/, but existing implementations require there to be no body/ on a subject change, and I see no reason to break them at this stage. yes. -- Kurt
Re: [Standards] request for reviews: XEP-0045 v1.25rc5
On Tue, Sep 27, 2011 at 2:36 AM, Peter Saint-Andre stpe...@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@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
Re: [Standards] request for reviews: XEP-0045 v1.25rc5
On Tue, Sep 27, 2011 at 2:13 AM, Peter Saint-Andre stpe...@stpeter.im wrote: On 9/24/11 1:53 PM, Waqas Hussain wrote: I note that this feature has no disco feature defined. MUC does not have the plethora of disco features that PubSub has. You decide whether that's a good thing or a bad thing. Given that no-one seems to have deployed this yet, we need a way to discover support. Do we want or need to define fine-grained disco features for XEP-0045? And if so, why limit the new features to just this one? Many clients enable/disable/hide UI elements based on what is allowed/supported. The argument for having these particular features discoverable and not all others is that most other non-discoverable features are available in pretty much all server implementations. These features however are not present on existing servers. Clients should therefore only be showing UI elements when the features are known to be available. Doing otherwise is going to annoy users when it fails after they've put in the effort of filling in a form and submitting it, with no previous indication that it wasn't supported. -- Waqas Hussain
Re: [Standards] request for reviews: XEP-0045 v1.25rc5
On 9/27/11 7:38 AM, Waqas Hussain wrote: On Tue, Sep 27, 2011 at 2:13 AM, Peter Saint-Andre stpe...@stpeter.im wrote: On 9/24/11 1:53 PM, Waqas Hussain wrote: I note that this feature has no disco feature defined. MUC does not have the plethora of disco features that PubSub has. You decide whether that's a good thing or a bad thing. Given that no-one seems to have deployed this yet, we need a way to discover support. Do we want or need to define fine-grained disco features for XEP-0045? And if so, why limit the new features to just this one? Many clients enable/disable/hide UI elements based on what is allowed/supported. The argument for having these particular features discoverable and not all others is that most other non-discoverable features are available in pretty much all server implementations. These features however are not present on existing servers. Clients should therefore only be showing UI elements when the features are known to be available. Doing otherwise is going to annoy users when it fails after they've put in the effort of filling in a form and submitting it, with no previous indication that it wasn't supported. But then we're making a connection between MUC features for which we need to define service discovery features and the current state of the art in MUC implementations. I think that's not a good idea because how do we know exactly which features are currently supported? If we're going to define service discovery features, then I think we need to be consistent about it. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] request for reviews: XEP-0045 v1.25rc5
On 9/27/11 7:29 AM, Waqas Hussain wrote: On Tue, Sep 27, 2011 at 2:36 AM, Peter Saint-Andre stpe...@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@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
Re: [Standards] request for reviews: XEP-0045 v1.25rc5
On 9/27/11 3:28 PM, Alexander Holler wrote: Am 27.09.2011 15:29, schrieb Waqas Hussain: 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 elementvCard 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. Hmm, doesn't forwarding IQs be a problem for semianonymous rooms? That's already covered by the third bullet point in Section 16.4: If an occupant wants to send an IQ stanza to another user in a semi-anonymous room, the sender can direct the stanza to the recipient's room JID and the service SHOULD forward the stanza to the recipient's real JID. However, the MUC service MUST NOT reveal the sender's real JID to the recipient at any time, nor reveal the recipient's real JID to the sender. Especially for things like vcard? Why are vCards special in this regard? Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] request for reviews: XEP-0045 v1.25rc5
On 9/24/11 1:53 PM, Waqas Hussain wrote: On Sat, Sep 24, 2011 at 2:08 AM, Peter Saint-Andre stpe...@stpeter.im wrote: On 9/20/11 6:00 PM, Evgeniy Khramtsov wrote: On 20.09.2011 08:46, Peter Saint-Andre wrote: On 9/19/11 4:40 PM, Alexander Holler wrote: No, but maybe adding some muc-features which are making it obvious what is supported by the server is an option. I don't know if there is an implemention which supports e.g. those voice-requests as described, those I've tested seem not to have it implemented. If you test more implementations and find that none of them support the feature (and the developers say they have no plans to implement the feature), then it might make sense to remove the feature from the spec. Peter We have a patch and we are going to include it in the new ejabberd version. Please don't remove the feature from the spec. Cool, thanks for letting us know. I won't touch that part of the spec. :) I note that this feature has no disco feature defined. MUC does not have the plethora of disco features that PubSub has. You decide whether that's a good thing or a bad thing. Given that no-one seems to have deployed this yet, we need a way to discover support. Do we want or need to define fine-grained disco features for XEP-0045? And if so, why limit the new features to just this one? I propose the features http://jabber.org/protocol/muc#request and http://jabber.org/protocol/muc#register Also, it's worth considering moving this (nick register, registration approval, voice request) out of XEP-0045, and into an XEP of its own. As far as I see, MUC implementations have up until now treated this is an optional secondary part of the main MUC spec. The new XEP could also include text about service-level nick registrations, which is what it currently implemented and deployed, and can have interesting interactions with room-level registration. I like the idea of slimming down XEP-0045 to the extent possible. I do intend to implement these in Prosody. Thanks for letting us know. P.S. An important thing in this is the room requesting additional information. One obvious example is captcha support. How should that flow? The room should send a captcha form IQ-set or message to the requester? Those are good questions. I don't have the answers, but it might be easier to work out the answers if we put this feature into a separate spec. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] request for reviews: XEP-0045 v1.25rc5
Waqas, thanks for the review. Comments inline. I will push out an updated version sometime this week, once we settle a few of these issues. On 9/19/11 11:34 PM, Waqas Hussain wrote: On Thu, Aug 18, 2011 at 6:43 PM, Peter Saint-Andre stpe...@stpeter.im wrote: I've completed a round of revisions to XEP-0045 (Multi-User Chat) in an effort to incorporate developer feedback I've received since the last version 3 years ago. The XMPP Council would like to vote on these revisions before the end of September or possibly early October, so it would be great if folks could check the diff in the next few weeks: http://xmpp.org/extensions/diff/api/xep/0045/diff/1.24/vs/1.25rc5 1. Using GC instead of groupchat 1.0 in various places This doesn't affect me, but new readers of the document might find it confusing. Fixed in my working copy. 2. Room subject The current text suggests the room should send a subject if it's set. I'd like it to send subject/subject in the case when it's not set. The subject will then act as a clear end marker for room history. That seems reasonable. Added to my working copy. 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? 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). 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. 6. action nick and jid for kicks and bans Examples 85 and 108 have been updated from actor jid='...'/ to actor nick='...'/, but the text immediately before them still says the bare JID of the user who initiated [...]. What I'd like here is to allow the room to include a nick and/or a bare/full JID. A nick is useful for general consumption, but a service should be allowed to turn this off. And a service should be allowed to include JID in the stanzas going to occupants who are allowed to see JIDs (moderators). And I don't see any particular reason to not make them full JIDs. Fine with me. I've changed bare JID to roomnick or bare JID but I've left the examples the same. 7. Section 16.1 restates what RFC6122 already specifies (and calls it RFC6120 instead). Reference fixed. I see no harm in repeating the rules here. 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? 8. Presence subscriptions I've been wanting to add this in Prosody, but have worried about client behavior on receiving both MUC-specific, and normal presence from the same JID. I'm +1 to it though. Many users do add rooms as contacts. Agreed. 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. 10. MUC child element in presence errors Note: If an error occurs in relation to joining a room, the service SHOULD include the MUC child element (i.e., x xmlns='http://jabber.org/protocol/muc'/) in the presence/ stanza of type error. What is the rationale behind this SHOULD? 'id' attributes are the canonical XMPP way for matching stanzas to error replies; RFC6120#8.1.3 is quite clear that 'id' attributes can be depended on to work fine with presence. IIRC, in Prosody, we added this specifically because Gajim was having issues with nick changes (I note that you didn't specify the above quoted text for this and other error cases). But should this really be a SHOULD? Probably not. Note that I have
Re: [Standards] request for reviews: XEP-0045 v1.25rc5
On Sep 26, 2011, at 2:36 PM, Peter Saint-Andre wrote: 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. I think one ought to allow for extension elements in the subject change message. For instance, say the subject change message is delayed at an occupant's server, which hence adds a delay/ element. Hence, I think it should be a subject/ child with a body/. -- Kurt
Re: [Standards] request for reviews: XEP-0045 v1.25rc5
On Sat, Sep 24, 2011 at 2:08 AM, Peter Saint-Andre stpe...@stpeter.im wrote: On 9/20/11 6:00 PM, Evgeniy Khramtsov wrote: On 20.09.2011 08:46, Peter Saint-Andre wrote: On 9/19/11 4:40 PM, Alexander Holler wrote: No, but maybe adding some muc-features which are making it obvious what is supported by the server is an option. I don't know if there is an implemention which supports e.g. those voice-requests as described, those I've tested seem not to have it implemented. If you test more implementations and find that none of them support the feature (and the developers say they have no plans to implement the feature), then it might make sense to remove the feature from the spec. Peter We have a patch and we are going to include it in the new ejabberd version. Please don't remove the feature from the spec. Cool, thanks for letting us know. I won't touch that part of the spec. :) I note that this feature has no disco feature defined. Given that no-one seems to have deployed this yet, we need a way to discover support. I propose the features http://jabber.org/protocol/muc#request and http://jabber.org/protocol/muc#register Also, it's worth considering moving this (nick register, registration approval, voice request) out of XEP-0045, and into an XEP of its own. As far as I see, MUC implementations have up until now treated this is an optional secondary part of the main MUC spec. The new XEP could also include text about service-level nick registrations, which is what it currently implemented and deployed, and can have interesting interactions with room-level registration. I do intend to implement these in Prosody. P.S. An important thing in this is the room requesting additional information. One obvious example is captcha support. How should that flow? The room should send a captcha form IQ-set or message to the requester? -- Waqas Hussain
Re: [Standards] request for reviews: XEP-0045 v1.25rc5
On 9/20/11 6:00 PM, Evgeniy Khramtsov wrote: On 20.09.2011 08:46, Peter Saint-Andre wrote: On 9/19/11 4:40 PM, Alexander Holler wrote: No, but maybe adding some muc-features which are making it obvious what is supported by the server is an option. I don't know if there is an implemention which supports e.g. those voice-requests as described, those I've tested seem not to have it implemented. If you test more implementations and find that none of them support the feature (and the developers say they have no plans to implement the feature), then it might make sense to remove the feature from the spec. Peter We have a patch and we are going to include it in the new ejabberd version. Please don't remove the feature from the spec. Cool, thanks for letting us know. I won't touch that part of the spec. :) /psa
Re: [Standards] request for reviews: XEP-0045 v1.25rc5
Am 20.09.2011 22:06, schrieb Waqas Hussain: On Tue, Sep 20, 2011 at 3:50 PM, Alexander Hollerhol...@ahsoftware.de wrote: Since sending a private messages to administrators is always possible (even without voice), I think there isn't really a need for this feature. That's not true. PMs to room admins are not always possible. For example, jab...@conference.jabber.org has PMs disabled for non-moderators, and sending to admins doesn't work. True, there is e.g. that muc#roomconfig_allowpm. I believed I've read somewhere that messages to moderators, admins or owners should be allowed, but it looks like I just confused that with something else. ;) Regards, Alexander
Re: [Standards] request for reviews: XEP-0045 v1.25rc5
Am 20.09.2011 00:46, schrieb Peter Saint-Andre: On 9/19/11 4:40 PM, Alexander Holler wrote: Am 19.09.2011 20:23, schrieb Peter Saint-Andre: On 9/6/11 10:38 AM, Alexander Holler wrote: Looking again at XEP-0045, I don't see a reason why a request for voice should be handled in another way than a request for membership. ;) In fact I would suggest to replace both with an unified request for affiliation which should work like the request for membership in 7.10 (with an attribute 'affiliation' and maybe a xmlns something other than 'jabber:iq:register'). Is there a strong reason to change this now, other than protocol hygiene? No, but maybe adding some muc-features which are making it obvious what is supported by the server is an option. I don't know if there is an implemention which supports e.g. those voice-requests as described, those I've tested seem not to have it implemented. If you test more implementations and find that none of them support the feature (and the developers say they have no plans to implement the feature), then it might make sense to remove the feature from the spec. Since sending a private messages to administrators is always possible (even without voice), I think there isn't really a need for this feature. Regards, Alexander
Re: [Standards] request for reviews: XEP-0045 v1.25rc5
On Tue, Sep 20, 2011 at 3:50 PM, Alexander Holler hol...@ahsoftware.de wrote: Am 20.09.2011 00:46, schrieb Peter Saint-Andre: On 9/19/11 4:40 PM, Alexander Holler wrote: Am 19.09.2011 20:23, schrieb Peter Saint-Andre: On 9/6/11 10:38 AM, Alexander Holler wrote: Looking again at XEP-0045, I don't see a reason why a request for voice should be handled in another way than a request for membership. ;) In fact I would suggest to replace both with an unified request for affiliation which should work like the request for membership in 7.10 (with an attribute 'affiliation' and maybe a xmlns something other than 'jabber:iq:register'). Is there a strong reason to change this now, other than protocol hygiene? No, but maybe adding some muc-features which are making it obvious what is supported by the server is an option. I don't know if there is an implemention which supports e.g. those voice-requests as described, those I've tested seem not to have it implemented. If you test more implementations and find that none of them support the feature (and the developers say they have no plans to implement the feature), then it might make sense to remove the feature from the spec. Since sending a private messages to administrators is always possible (even without voice), I think there isn't really a need for this feature. That's not true. PMs to room admins are not always possible. For example, jab...@conference.jabber.org has PMs disabled for non-moderators, and sending to admins doesn't work. -- Waqas Hussain
Re: [Standards] request for reviews: XEP-0045 v1.25rc5
On 20.09.2011 08:46, Peter Saint-Andre wrote: On 9/19/11 4:40 PM, Alexander Holler wrote: No, but maybe adding some muc-features which are making it obvious what is supported by the server is an option. I don't know if there is an implemention which supports e.g. those voice-requests as described, those I've tested seem not to have it implemented. If you test more implementations and find that none of them support the feature (and the developers say they have no plans to implement the feature), then it might make sense to remove the feature from the spec. Peter We have a patch and we are going to include it in the new ejabberd version. Please don't remove the feature from the spec. -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:x...@jabber.ru.
Re: [Standards] request for reviews: XEP-0045 v1.25rc5
On 9/6/11 8:17 AM, Ralph Meijer wrote: On Tue, 2011-09-06 at 15:37 +0200, Alexander Holler wrote: Am 06.09.2011 11:09, schrieb Ralph Meijer: On Tue, 2011-09-06 at 09:24 +0200, Alexander Holler wrote: [..] I don't see any reason why the user should send a form to the server. If using a form is wanted, the correct way would be that the user requests a form for the request from the server, and sends back the result, which is then processed by the server (resulting in a form for the moderator). The described way where the user generates a form only makes sense, if that form is forwarded to the moderator. But that would result in the possible problems I've described (e.g. hidden fields and wrong labels). I don't see how requesting a form from the service first somehow makes this better. An attacker could simply ignore that form and submit its own bad one. Whats the point that the user sends labels? Where do the user gets the list of required fields from? Ah, these are valid concerns. Looking into it in more detail, of course the form for requesting voice, as shown in example 74 of XEP-0045 v1.25rc5, is of type 'submit'. The form sent to the moderator for approval, as shown in example 103 is of type 'form', as at should be. The latter is thus an entirely different one, with additional fields muc#jid, muc#roomnick and muc#request_allow, constructed by the MUC service. You are taking the associated prose, that suggests to 'forward the request', too literal. The form sent by the user's client can be entirely constructed by the client, without displaying it as such to the user. As it is of type 'submit', no labels are required. The required field is 'muc#role' and the value is 'participant'. The type and label attributes should probably be removed from the example. Even thought this is currently not specified, future extensions could define how an interaction might be, with additional fields required of the user. Your suggestion of first requesting a form to get these fields (as with registering a nick or configuring a room) seems the obvious solution to that. If there is no immediate need for this, I suggest we leave things as is, though. I've reworded those sections to remove the ambiguity. Section 7.13 The service then proceeds as described in the Approving Voice Requests section of this document. Section 8.6 As noted in the Requesting Voice section of this document, an occupant requests voice by sending a voice request data form to the service. The service then SHOULD use that voice request data form as the basis for a voice approval data form that it generates and sends to the room moderator(s). The voice approval data form is contained in a message/ stanza, as shown below. /psa
Re: [Standards] request for reviews: XEP-0045 v1.25rc5
On 9/6/11 10:38 AM, Alexander Holler wrote: Looking again at XEP-0045, I don't see a reason why a request for voice should be handled in another way than a request for membership. ;) In fact I would suggest to replace both with an unified request for affiliation which should work like the request for membership in 7.10 (with an attribute 'affiliation' and maybe a xmlns something other than 'jabber:iq:register'). Is there a strong reason to change this now, other than protocol hygiene? Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] request for reviews: XEP-0045 v1.25rc5
On 8/31/11 11:41 AM, Alexander Holler wrote: Just to summarize the problems I see with those requests (to change affiliation): 1. I haven't found out how the user has to build such an request. E.g. the request for voice as described in the XEP doesn't work with either ejabberd or M-Link ( or I did something wrong during my short tests ;) ). 2. The service has to parse and translate every request into a form which is then presented to moderators. The service has to replace all labels and has to check every type. And because I think there should be standardized way for those requests I don't see why using a form for such a request offers any benefit over something like this: - message from='us...@example.com/box' to='ro...@chat.example.com' x xmlns='http://jabber.org/protocol/muc#request' type='submit' item affiliation='member' nick='someone'/ /x /message - In both cases the service has to generate a form which is then send/presented to moderators, but parsing _and_ verifying something like the above message is much easier than parsing _and_ verifying a form. I see no compelling reason to change this. I might see a reason to remove the feature entirely, if no one supports it. At this point in the life cycle of XEP-0045, we're trying to clean up some minor problems and clarify some issues for implementers, not make any changes of significance, and certainly not merely for the sake of consistency or elegance. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] request for reviews: XEP-0045 v1.25rc5
On 8/19/11 1:02 PM, Alexander Holler wrote: Am 18.08.2011 23:00, schrieb Alexander Holler: Am 18.08.2011 15:43, schrieb Peter Saint-Andre: I've completed a round of revisions to XEP-0045 (Multi-User Chat) in an effort to incorporate developer feedback I've received since the last version 3 years ago. The XMPP Council would like to vote on these revisions before the end of September or possibly early October, so it would be great if folks could check the diff in the next few weeks: http://xmpp.org/extensions/diff/api/xep/0045/diff/1.24/vs/1.25rc5 A rendered version is here: http://xmpp.org/extensions/tmp/xep-0045-1.25.html Thanks for the update. I will try to read (again) as much as I can. Here is my current list of open questions: - Which nicks are reserved? (owner, admins, members) - Owners, admins ormembers without reserved nicks? Nicks are reserved based on registering with the room. Nicks of owners and admins are not reserved automatically, unless an implementation decides that is a nice feature. - What happens with reserved nicks when someone changes his nick? Does the reserved nick changes too? Implementation specific. I don't know why fully-anonymous rooms got removed, according tothe history this was done 2002. But I think there are good reasons for rooms where even moderators or owners shouldn't be able to see real JIDs. E.g. thinking about countries where people have to fear speaking freely without beeing anonymous. There might be possibilities to discover real JIDs when access to the machine running the service is available, but if someone (a owner or moderator) doesn't have such, he can't be get under pressure to reveal real JIDs because he just can't see them. So here are my 2¢ for in regard to fully-anonymous rooms: - muc_fullyanonymous in service discovery is missing, - make a note about problems with fully-anonymous rooms, e.g how to ban someone without revealing his jid in the list of outcasts, how to remove an outcast if the outcast was done based on the nick only, possible solution: outcasts with a timeout). Besides removing outcasts, I think anything else could be handled through the use of nicks only. To not having the need to define how fully-anonymous rooms are handled, maybe the xep could just list the value 'none' for whois (no change needed), add muc_fullyanonymous to service discovery and say everything else in regard to how fully-anonymous rooms are handled (if supported) is implementation specific. Feel free to write and submit a proposal for fully anonymous rooms. IMHO this is out of scope for XEP-0045, and has been since 2002. We are trying to *not* add new features to XEP-0045 at this point, and in fact to remove features if they are not used. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] request for reviews: XEP-0045 v1.25rc5
On 8/18/11 3:00 PM, Alexander Holler wrote: Am 18.08.2011 15:43, schrieb Peter Saint-Andre: I've completed a round of revisions to XEP-0045 (Multi-User Chat) in an effort to incorporate developer feedback I've received since the last version 3 years ago. The XMPP Council would like to vote on these revisions before the end of September or possibly early October, so it would be great if folks could check the diff in the next few weeks: http://xmpp.org/extensions/diff/api/xep/0045/diff/1.24/vs/1.25rc5 A rendered version is here: http://xmpp.org/extensions/tmp/xep-0045-1.25.html Thanks for the update. I will try to read (again) as much as I can. At first I would strongly suggest to replace at least that 'oldhag' which is e.g. used for a new nick with something else. I've wondered some minutes when I first read that example in 7.6 until I have read further. For other people like me, who like stupid looking but easy to read docs, here is something I've done to my copy of XEP-0045 (.example and .test are reserved by RFC 2606): - sed \ -e 's/chat.shakespeare.lit/chat.example/g' \ -e 's/shakespeare.lit/home.test/g' \ -e 's/firstwitch/occupant1owner/g' \ -e 's/secondwitch/occupant2admin/g' \ -e 's/thirdwitch/occupant3none/g' \ -e 's/crone1/user1owner/g' \ -e 's/wiccarocks/user2admin/g' \ -e 's/hag66/user3none/g' \ -e 's/oldhag/newnick/g' \ -e 's/coven/room1/g' \ -i xep-0045.html - ;=) Fun Shakespeare examples have kept me motivated in writing all this documentation for the last 10+ years. I won't be changing them now. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] request for reviews: XEP-0045 v1.25rc5
Am 19.09.2011 20:49, schrieb Peter Saint-Andre: On 8/18/11 3:00 PM, Alexander Holler wrote: Am 18.08.2011 15:43, schrieb Peter Saint-Andre: I've completed a round of revisions to XEP-0045 (Multi-User Chat) in an effort to incorporate developer feedback I've received since the last version 3 years ago. The XMPP Council would like to vote on these revisions before the end of September or possibly early October, so it would be great if folks could check the diff in the next few weeks: http://xmpp.org/extensions/diff/api/xep/0045/diff/1.24/vs/1.25rc5 A rendered version is here: http://xmpp.org/extensions/tmp/xep-0045-1.25.html Thanks for the update. I will try to read (again) as much as I can. At first I would strongly suggest to replace at least that 'oldhag' which is e.g. used for a new nick with something else. I've wondered some minutes when I first read that example in 7.6 until I have read further. For other people like me, who like stupid looking but easy to read docs, here is something I've done to my copy of XEP-0045 (.example and .test are reserved by RFC 2606): - sed \ -e 's/chat.shakespeare.lit/chat.example/g' \ -e 's/shakespeare.lit/home.test/g' \ -e 's/firstwitch/occupant1owner/g' \ -e 's/secondwitch/occupant2admin/g' \ -e 's/thirdwitch/occupant3none/g' \ -e 's/crone1/user1owner/g' \ -e 's/wiccarocks/user2admin/g' \ -e 's/hag66/user3none/g' \ -e 's/oldhag/newnick/g' \ -e 's/coven/room1/g' \ -i xep-0045.html - ;=) Fun Shakespeare examples have kept me motivated in writing all this documentation for the last 10+ years. I won't be changing them now. Than, maybe, just bringing the examples in section 9 in line with the rest of the documentation is an option. Using the above sed is a good way to see the problematic examples. E.g. the example in 9.1 will change from --- iq from='kinghen...@shakespeare.lit/throne' id='ban1' to='southamp...@henryv.shakespeare.lit' type='set' query xmlns='http://jabber.org/protocol/muc#admin' item affiliation='outcast' jid='earlofcambri...@shakespeare.lit'/ /query /iq --- to --- iq from='kinghen...@home.test/throne' id='ban1' to='southamp...@henryv.home.test' type='set' query xmlns='http://jabber.org/protocol/muc#admin' item affiliation='outcast' jid='earlofcambri...@home.test'/ /query /iq --- I don't remember which examples really confused me most during my first reading, but that one is surely one of those candidates because it isn't obvious what is room, service, occupant or real JID. The problem will become obvious (through the sed) because all JIDs are at home.test. ;) Regards, Alexander
Re: [Standards] request for reviews: XEP-0045 v1.25rc5
Am 19.09.2011 20:47, schrieb Peter Saint-Andre: - Which nicks are reserved? (owner, admins, members) - Owners, admins ormembers without reserved nicks? Nicks are reserved based on registering with the room. Nicks of owners and admins are not reserved automatically, unless an implementation decides that is a nice feature. Registering with a room is getting the affiliation member. So how does an owner or admin reserves a (his) nick? I think especially those want to have their nick registered. - What happens with reserved nicks when someone changes his nick? Does the reserved nick changes too? Implementation specific. Hmm, that means clients never can implement reserved-nick-handling because they just don't know how the server behaves. Regards, Alexander
Re: [Standards] request for reviews: XEP-0045 v1.25rc5
Am 19.09.2011 20:23, schrieb Peter Saint-Andre: On 9/6/11 10:38 AM, Alexander Holler wrote: Looking again at XEP-0045, I don't see a reason why a request for voice should be handled in another way than a request for membership. ;) In fact I would suggest to replace both with an unified request for affiliation which should work like the request for membership in 7.10 (with an attribute 'affiliation' and maybe a xmlns something other than 'jabber:iq:register'). Is there a strong reason to change this now, other than protocol hygiene? No, but maybe adding some muc-features which are making it obvious what is supported by the server is an option. I don't know if there is an implemention which supports e.g. those voice-requests as described, those I've tested seem not to have it implemented. Regards, Alexander
Re: [Standards] request for reviews: XEP-0045 v1.25rc5
On 9/19/11 4:33 PM, Alexander Holler wrote: Am 19.09.2011 20:47, schrieb Peter Saint-Andre: - Which nicks are reserved? (owner, admins, members) - Owners, admins ormembers without reserved nicks? Nicks are reserved based on registering with the room. Nicks of owners and admins are not reserved automatically, unless an implementation decides that is a nice feature. Registering with a room is getting the affiliation member. So how does an owner or admin reserves a (his) nick? I think especially those want to have their nick registered. Nick are reserved by registering with the room. - What happens with reserved nicks when someone changes his nick? Does the reserved nick changes too? Implementation specific. Hmm, that means clients never can implement reserved-nick-handling because they just don't know how the server behaves. Changing your in-room nick is temporary. If you want to reserve a different nick, you can register it in the usual way. I have no idea if current implementations let you reserve more than one nick (probably not). We might want to define that behavior a bit more carefully. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] request for reviews: XEP-0045 v1.25rc5
On 9/19/11 4:40 PM, Alexander Holler wrote: Am 19.09.2011 20:23, schrieb Peter Saint-Andre: On 9/6/11 10:38 AM, Alexander Holler wrote: Looking again at XEP-0045, I don't see a reason why a request for voice should be handled in another way than a request for membership. ;) In fact I would suggest to replace both with an unified request for affiliation which should work like the request for membership in 7.10 (with an attribute 'affiliation' and maybe a xmlns something other than 'jabber:iq:register'). Is there a strong reason to change this now, other than protocol hygiene? No, but maybe adding some muc-features which are making it obvious what is supported by the server is an option. I don't know if there is an implemention which supports e.g. those voice-requests as described, those I've tested seem not to have it implemented. If you test more implementations and find that none of them support the feature (and the developers say they have no plans to implement the feature), then it might make sense to remove the feature from the spec. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] request for reviews: XEP-0045 v1.25rc5
Am 20.09.2011 00:44, schrieb Peter Saint-Andre: On 9/19/11 4:33 PM, Alexander Holler wrote: Am 19.09.2011 20:47, schrieb Peter Saint-Andre: - Which nicks are reserved? (owner, admins, members) - Owners, admins ormembers without reserved nicks? Nicks are reserved based on registering with the room. Nicks of owners and admins are not reserved automatically, unless an implementation decides that is a nice feature. Registering with a room is getting the affiliation member. So how does an owner or admin reserves a (his) nick? I think especially those want to have their nick registered. Nick are reserved by registering with the room. Are, now I'm getting it. registering with a room does mean at first getting the nick reserved. Becoming a member (if not already) is just a minor matter. I've read it the other way, that registering with a does mean at first becoming a member. Regards, Alexander
Re: [Standards] request for reviews: XEP-0045 v1.25rc5
On Thu, Aug 18, 2011 at 6:43 PM, Peter Saint-Andre stpe...@stpeter.im wrote: I've completed a round of revisions to XEP-0045 (Multi-User Chat) in an effort to incorporate developer feedback I've received since the last version 3 years ago. The XMPP Council would like to vote on these revisions before the end of September or possibly early October, so it would be great if folks could check the diff in the next few weeks: http://xmpp.org/extensions/diff/api/xep/0045/diff/1.24/vs/1.25rc5 1. Using GC instead of groupchat 1.0 in various places This doesn't affect me, but new readers of the document might find it confusing. 2. Room subject The current text suggests the room should send a subject if it's set. I'd like it to send subject/subject in the case when it's not set. The subject will then act as a clear end marker for room history. 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. 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. 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/? 6. action nick and jid for kicks and bans Examples 85 and 108 have been updated from actor jid='...'/ to actor nick='...'/, but the text immediately before them still says the bare JID of the user who initiated [...]. What I'd like here is to allow the room to include a nick and/or a bare/full JID. A nick is useful for general consumption, but a service should be allowed to turn this off. And a service should be allowed to include JID in the stanzas going to occupants who are allowed to see JIDs (moderators). And I don't see any particular reason to not make them full JIDs. 7. Section 16.1 restates what RFC6122 already specifies (and calls it RFC6120 instead). And I have mixed feelings about that MUST NOT. 8. Presence subscriptions I've been wanting to add this in Prosody, but have worried about client behavior on receiving both MUC-specific, and normal presence from the same JID. I'm +1 to it though. Many users do add rooms as contacts. 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'. 10. MUC child element in presence errors Note: If an error occurs in relation to joining a room, the service SHOULD include the MUC child element (i.e., x xmlns='http://jabber.org/protocol/muc'/) in the presence/ stanza of type error. What is the rationale behind this SHOULD? 'id' attributes are the canonical XMPP way for matching stanzas to error replies; RFC6120#8.1.3 is quite clear that 'id' attributes can be depended on to work fine with presence. IIRC, in Prosody, we added this specifically because Gajim was having issues with nick changes (I note that you didn't specify the above quoted text for this and other error cases). But should this really be a SHOULD? 11. Full-to-bare JID rewriting to support vCards All(?) implementations are doing it, but it's not specified anywhere. Should it be? 12. History management Should it perhaps be noted that clients shouldn't depend on getting only what they asked for? I don't think all MUC implementations support history management. And 'maxchars' is particularly troublesome, as anything between the MUC history code and the client could modify the stanza. Misc: s/non/none/ Nicknames can contain virtually any Unicode character introduces the possibility of nick spoofing - grammar fail. s/hte/the/ All this came from skimming the diff. I'll probably have more feedback when I manage to review the entire spec in detail while looking at Prosody's code. -- Waqas Hussain
Re: [Standards] request for reviews: XEP-0045 v1.25rc5
Am 05.09.2011 13:00, schrieb Dave Cridland: On Wed Aug 31 18:41:15 2011, Alexander Holler wrote: Just to summarize the problems I see with those requests (to change affiliation): ... 2. The service has to parse and translate every request into a form which is then presented to moderators. The service has to replace all labels and has to check every type. And because I think there should be standardized way for those requests I don't see why using a form for such a request offers any benefit over something like this: - message from='us...@example.com/box' to='ro...@chat.example.com' x xmlns='http://jabber.org/protocol/muc#request' type='submit' item affiliation='member' nick='someone'/ /x /message - A form would allow the addition of a CAPTCHA, for instance. In both cases the service has to generate a form which is then send/presented to moderators, but parsing _and_ verifying something like the above message is much easier than parsing _and_ verifying a form. Not especially, actually. There is an issue with hidden fields, possibly, but those are pretty trivial to deal with. I don't see any reason why the user should send a form to the server. If using a form is wanted, the correct way would be that the user requests a form for the request from the server, and sends back the result, which is then processed by the server (resulting in a form for the moderator). The described way where the user generates a form only makes sense, if that form is forwarded to the moderator. But that would result in the possible problems I've described (e.g. hidden fields and wrong labels). Regards, Alexander
Re: [Standards] request for reviews: XEP-0045 v1.25rc5
On Tue, 2011-09-06 at 09:24 +0200, Alexander Holler wrote: [..] I don't see any reason why the user should send a form to the server. If using a form is wanted, the correct way would be that the user requests a form for the request from the server, and sends back the result, which is then processed by the server (resulting in a form for the moderator). The described way where the user generates a form only makes sense, if that form is forwarded to the moderator. But that would result in the possible problems I've described (e.g. hidden fields and wrong labels). I don't see how requesting a form from the service first somehow makes this better. An attacker could simply ignore that form and submit its own bad one. A service implementation simply needs to always check foreign inputs against its internal definitions of allowed fields with their types and ignore the rest. Whether you are using plain XML or our Data Forms does not really matter. Given solid library support, handling forms correctly is quite easy. In Wokkel I first parse incoming forms into an internal representation, and as a second step I can type-check the values against a set of field definitions for that form type. This will interpret the incoming form according to those definitions, *not* against whatever the peer happens to pass along (i.e. type attributes that do not match the type in the field definition will raise an error). Let's look at your example: - message from='user3n...@home.test/pda' id='yd53c486' to='room1@chat.example' x xmlns='jabber:x:data' type='submit' field var='FORM_TYPE' valuehttp://jabber.org/protocol/muc#request/value /field field var='muc#role' type='text-single' label='Requested role' valueparticipant/value /field field var='muc#role' type='hidden' label='Requested role' valuemoderator/value /field /x /message - In Wokkel, the form would be rejected in the first step because it has more than one 'muc#role' field. If the submitted form would only have the second field, with type hidden, it would be rejected in the second step because the field type didn't match. For plain XML you would need to do similar things. Your example: - message from='us...@example.com/box' to='ro...@chat.example.com' x xmlns='http://jabber.org/protocol/muc#request' type='submit' item affiliation='member' nick='someone'/ /x /message - Several possible attacks for libraries that aren't too careful checking their inputs: 1) There could be more than one item element: x xmlns='http://jabber.org/protocol/muc#request' type='submit' item role='participant' nick='someone'/ item role='moderator' nick='someone'/ /x 2) The namespace of the second item/ element could be different from its parent. Example: x xmlns='http://jabber.org/protocol/muc#request' type='submit' item role='participant' nick='someone'/ item xmlns='http://www.jabber.org/protocol/muc#request' role='moderator' nick='someone'/ /x 3) The namespace of the attributes could be different, or their could be one in the empty namespace and one in another: x xmlns='http://jabber.org/protocol/muc#request' type='submit' item xmlns:muc='http://jabber.org/protocol/muc#request' role='participant' muc:role='moderator' nick='someone'/ /x In short, I don't think that passing along the form as-is, is much of an issue. The client receiving the request can do several checks (like duplicate fields) and when the form comes back, the MUC service needs to check its inputs anyway. Also, this particular example tries to obtain the moderator role (even though your XML examples use 'affiliation'). A service should not honour requests other than 'participant', because requesting voice is just that. That said, having the service vetting the form before passing it along wouldn't hurt, of course. A slight rewording of the text could achieve that. I just don't see enough reason to change the actual protocol at this stage of development of this specification. -- ralphm
Re: [Standards] request for reviews: XEP-0045 v1.25rc5
Am 06.09.2011 11:09, schrieb Ralph Meijer: On Tue, 2011-09-06 at 09:24 +0200, Alexander Holler wrote: [..] I don't see any reason why the user should send a form to the server. If using a form is wanted, the correct way would be that the user requests a form for the request from the server, and sends back the result, which is then processed by the server (resulting in a form for the moderator). The described way where the user generates a form only makes sense, if that form is forwarded to the moderator. But that would result in the possible problems I've described (e.g. hidden fields and wrong labels). I don't see how requesting a form from the service first somehow makes this better. An attacker could simply ignore that form and submit its own bad one. Whats the point that the user sends labels? Where do the user gets the list of required fields from? Regards, Alexander
Re: [Standards] request for reviews: XEP-0045 v1.25rc5
On Tue, 2011-09-06 at 15:37 +0200, Alexander Holler wrote: Am 06.09.2011 11:09, schrieb Ralph Meijer: On Tue, 2011-09-06 at 09:24 +0200, Alexander Holler wrote: [..] I don't see any reason why the user should send a form to the server. If using a form is wanted, the correct way would be that the user requests a form for the request from the server, and sends back the result, which is then processed by the server (resulting in a form for the moderator). The described way where the user generates a form only makes sense, if that form is forwarded to the moderator. But that would result in the possible problems I've described (e.g. hidden fields and wrong labels). I don't see how requesting a form from the service first somehow makes this better. An attacker could simply ignore that form and submit its own bad one. Whats the point that the user sends labels? Where do the user gets the list of required fields from? Ah, these are valid concerns. Looking into it in more detail, of course the form for requesting voice, as shown in example 74 of XEP-0045 v1.25rc5, is of type 'submit'. The form sent to the moderator for approval, as shown in example 103 is of type 'form', as at should be. The latter is thus an entirely different one, with additional fields muc#jid, muc#roomnick and muc#request_allow, constructed by the MUC service. You are taking the associated prose, that suggests to 'forward the request', too literal. The form sent by the user's client can be entirely constructed by the client, without displaying it as such to the user. As it is of type 'submit', no labels are required. The required field is 'muc#role' and the value is 'participant'. The type and label attributes should probably be removed from the example. Even thought this is currently not specified, future extensions could define how an interaction might be, with additional fields required of the user. Your suggestion of first requesting a form to get these fields (as with registering a nick or configuring a room) seems the obvious solution to that. If there is no immediate need for this, I suggest we leave things as is, though. -- ralphm
Re: [Standards] request for reviews: XEP-0045 v1.25rc5
On Wed Aug 31 18:41:15 2011, Alexander Holler wrote: Just to summarize the problems I see with those requests (to change affiliation): 1. I haven't found out how the user has to build such an request. E.g. the request for voice as described in the XEP doesn't work with either ejabberd or M-Link ( or I did something wrong during my short tests ;) ). M-Link doesn't do voice requests (or room registration, either). Maybe we should. 2. The service has to parse and translate every request into a form which is then presented to moderators. The service has to replace all labels and has to check every type. And because I think there should be standardized way for those requests I don't see why using a form for such a request offers any benefit over something like this: - message from='us...@example.com/box' to='ro...@chat.example.com' x xmlns='http://jabber.org/protocol/muc#request' type='submit' item affiliation='member' nick='someone'/ /x /message - A form would allow the addition of a CAPTCHA, for instance. In both cases the service has to generate a form which is then send/presented to moderators, but parsing _and_ verifying something like the above message is much easier than parsing _and_ verifying a form. Not especially, actually. There is an issue with hidden fields, possibly, but those are pretty trivial to deal with. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] request for reviews: XEP-0045 v1.25rc5
Just to summarize the problems I see with those requests (to change affiliation): 1. I haven't found out how the user has to build such an request. E.g. the request for voice as described in the XEP doesn't work with either ejabberd or M-Link ( or I did something wrong during my short tests ;) ). 2. The service has to parse and translate every request into a form which is then presented to moderators. The service has to replace all labels and has to check every type. And because I think there should be standardized way for those requests I don't see why using a form for such a request offers any benefit over something like this: - message from='us...@example.com/box' to='ro...@chat.example.com' x xmlns='http://jabber.org/protocol/muc#request' type='submit' item affiliation='member' nick='someone'/ /x /message - In both cases the service has to generate a form which is then send/presented to moderators, but parsing _and_ verifying something like the above message is much easier than parsing _and_ verifying a form. Regards, Alexander
Re: [Standards] request for reviews: XEP-0045 v1.25rc5
On 8/23/11 6:34 AM, Alexander Holler wrote: Am 23.08.2011 11:23, schrieb Ralph Meijer: On Mon, 2011-08-22 at 20:30 +0200, Alexander Holler wrote: Hello, [..] And in my list before, I've forgotten to mention the problem that for requests a form is send by the user to room, which the room then forwards to moderators, and the moderators will see the form with the room as sender. I see it as a problem if the MUC-service really forwards such a request without checking every content. And if the service has to check everything of the form, there is no reason why a form must be send by the user, the service could build the form too and something more simple could be used for requests (e.g. something likex xmlns='...muc#request) I assume this is about 'Registering with a Room'. There are two parts to this: I meant the wording e.g. in 8.6: As noted in the Requesting Voice section of this document, when a service receives a request for voice from an occupant it SHOULD forward that request to the room moderator(s). That 'forward' is what makes me nervous. You appear to want to check the values sent to the room admin/owner, but why? What attack vector do you believe needs to be addressed? One of the first things I first thought about is what happens with fields of type 'hidden' in the request. I haven't checked any implementation, but I could imagine implementations which really would just forward such fields which then might end in the approval form send to and back from the moderator. Playing with UTF-stuff in (forwarded) labels could allow some funny things too. OK, but what is the attack? Are you concerned about an attack against the room admins or an attack against the MUC service? The room will translate the user's request into the kind of form shown at http://xmpp.org/extensions/xep-0045.html#voiceapprove and the admin will click a few buttons (e.g., approve or deny) before returning that form to the service. So there's no real attack here against the room admin, or on the room as far as I can see. But I think it would be better to say that the request is translated by the service into the kind of form shown in Section 8.6. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] request for reviews: XEP-0045 v1.25rc5
Le 18/08/2011 15:43, Peter Saint-Andre a écrit : I've completed a round of revisions to XEP-0045 (Multi-User Chat) in an effort to incorporate developer feedback I've received since the last version 3 years ago. The XMPP Council would like to vote on these revisions before the end of September or possibly early October, so it would be great if folks could check the diff in the next few weeks: http://xmpp.org/extensions/diff/api/xep/0045/diff/1.24/vs/1.25rc5 A rendered version is here: http://xmpp.org/extensions/tmp/xep-0045-1.25.html Thanks! Peter In part 9.5 Modifying the Member List In the context of an open room, the member list is simply a list of users (bare JID and reserved nick) who are registered with the room. Such users cacan appear in a room roster, have their room nickname reserved, be returned in search results or FAQ queries, and the like. cacan - can Regards, BOCQUET Ludovic
Re: [Standards] request for reviews: XEP-0045 v1.25rc5
On Mon, 2011-08-22 at 20:30 +0200, Alexander Holler wrote: Hello, [..] And in my list before, I've forgotten to mention the problem that for requests a form is send by the user to room, which the room then forwards to moderators, and the moderators will see the form with the room as sender. I see it as a problem if the MUC-service really forwards such a request without checking every content. And if the service has to check everything of the form, there is no reason why a form must be send by the user, the service could build the form too and something more simple could be used for requests (e.g. something like x xmlns='...muc#request) I assume this is about 'Registering with a Room'. There are two parts to this: 1) The interaction between the occupant and the room to submit the request 2) The interaction between the admin/owner and the room to approve the request. The reason step 1 is done using Data Forms, is that allows a lot of flexibility in what information is requested from the occupant to complete the registration. Having a namespace with some predefined fields limits this tremendously. We had this for in-band account registration in the very early Jabber days, and is one of the reasons why Data Forms were invented. On top of that Field Data Standardization for Data Forms (XEP-0068) allows for providing a namespace for the the field names. In this case, the form sent to the admin doesn't have an encapsulating element in a MUC namespace, and any Jabber client that can handle data forms is able to provide a UI for this, without any knowledge of the underlying semantics. XEP-0068 also provides a way to have fields with names that are entirely application specific. They MUST start with 'x-'. This is great for asking for information from the occupant that is not covered by the predefined fields in XEP-0045 or registered with the XMPP Registrar. Step 2 is entirely optional and up to the implementation and/or configuration of the MUC service: 9.9 Approving Registration Requests If a service does not automatically accept requests to register with a room, it MAY provide a way for room admins to approve or deny registration requests over XMPP (alternatively, it could provide a web interface or some other admin tool). [..] You appear to want to check the values sent to the room admin/owner, but why? What attack vector do you believe needs to be addressed? -- ralphm
Re: [Standards] request for reviews: XEP-0045 v1.25rc5
Am 23.08.2011 11:23, schrieb Ralph Meijer: On Mon, 2011-08-22 at 20:30 +0200, Alexander Holler wrote: Hello, [..] And in my list before, I've forgotten to mention the problem that for requests a form is send by the user to room, which the room then forwards to moderators, and the moderators will see the form with the room as sender. I see it as a problem if the MUC-service really forwards such a request without checking every content. And if the service has to check everything of the form, there is no reason why a form must be send by the user, the service could build the form too and something more simple could be used for requests (e.g. something likex xmlns='...muc#request) I assume this is about 'Registering with a Room'. There are two parts to this: I meant the wording e.g. in 8.6: As noted in the Requesting Voice section of this document, when a service receives a request for voice from an occupant it SHOULD forward that request to the room moderator(s). That 'forward' is what makes me nervous. You appear to want to check the values sent to the room admin/owner, but why? What attack vector do you believe needs to be addressed? One of the first things I first thought about is what happens with fields of type 'hidden' in the request. I haven't checked any implementation, but I could imagine implementations which really would just forward such fields which then might end in the approval form send to and back from the moderator. Playing with UTF-stuff in (forwarded) labels could allow some funny things too. Maybe I just take that 'forward' to literal, but I don't like it. Regards, Alexander
Re: [Standards] request for reviews: XEP-0045 v1.25rc5
Hello, I've just seen another glitch in XEP-0045 which contributes to the confusion of readers. In 8.2 (Kicking an occupant) 'harfl...@henryv.shakespeare.lit' is used as name for the room. I suggest to change this at least to 'harfl...@chat.shakespeare.lit' to express that 'harfleur' is the name of a room. And in my list before, I've forgotten to mention the problem that for requests a form is send by the user to room, which the room then forwards to moderators, and the moderators will see the form with the room as sender. I see it as a problem if the MUC-service really forwards such a request without checking every content. And if the service has to check everything of the form, there is no reason why a form must be send by the user, the service could build the form too and something more simple could be used for requests (e.g. something like x xmlns='...muc#request) Regards, Alexander
