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
[Standards] XEP-0096 (SI File Transfer): fallback method is not explained
G'day everybody, On the XEP-0096, several stream methods can be used, and it's said that In-Band Bytestreams must be implemented and can be used as a fallback method if everything else doens't work. But I don't see any explaination on how to do the fallback, so how are we supposed to do ? The only way I see is to propose the file a second time, but that mean that the user will have to confirm it again. I know there is the more modern jingle approch to transfer files (XEP-0234), but XEP-0096 is more widely deployed (and is standard while XEP-0234 is experimental at the moment), so I'm implementing this one first. Any suggestion welcome thanks Goffi
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/
