Thanks, guys. I will complete my review of Section 7 this weekend. It was a busy week...
On 1/29/10 5:57 PM, Jiří Zárevúcky wrote: > So here is my list of notes: > > 1) > Are we going to finally replace those creepy status codes? Yes, I will work on that soon. > 2) > Just bellow example 22, there is this text: > > "If the user is entering a room that is non-anonymous (i.e., which > informs all occupants of each occupant's full JID as shown above), the > service SHOULD allow the user to enter the room ..." > > What is the alternative here? Deny entry based on some undefined security policy, I think. > 3) > In the same place, the inclusion of status code for non-anonymous room > is just recommended, and the service can instead choose to send a > message with the status code. > > While that second possibility is perhaps more suited for very restricted > clients, it's just "MAY" and thus not wise to rely on. In effect, the > client still needs to expect both possibilities, filter the server-sent > message if necessary and provide it's own to be consistent. > > Thus, I'd really like to see the presence-based notification promoted to > MUST and the message dropped entirely. The same goes of every other > place where this choice is provided (e.g. logging notification). I *think* that's probably a good idea but I'm not 100% sure yet. Do you mean that we'd never use the message notifications and always use presence instead? I don't see a good reason to generate presence if there's no underlying presence change (other than a room config change). > 4) > Section 7.1.14 > "If the user is entering a room in which the discussions are logged to a > public archive (often accessible via HTTP), the service SHOULD allow the > user to enter the room" > > The same question as with point 1. What's the alternative? See above. > 5) > "The service SHOULD send all discussion history messages before > delivering any "live" messages sent after the user enters the room." > > IMO, this should be a MUST. Agreed. > 6) > Then, there is also the problem with the client not knowing whether it > has all the history until a live message comes. Yes, that is a long-standing problem. I think it's fixed if we say that history MUST be sent before live messages, because history messages MUST have a delay tag from the service. Correct? > 7) > Spec is not specific about how the current discussion topic is to be > communicated when occupant enters a room. My vote is for subject changes > being part of the history, since they are important context for the > messages. If no change was made as far as history goes, it would be the > first message in history. Yes, that is currently unspecified or underspecified, and I know that (for instance) Openfire and ejabberd interpret the spec differently. I don't think that the subject message is really part of the history, in the sense that the subject could have been set before the last X messages were generated (where "X" is the size of the history). However, the subject might also have been changed in the middle of those X messages. :) So I see a few options: 1. Send history, send subject, send live messages. 2. Send subject, send history, send live messages. 3. Send subject at time when history started, send history including any subject changes, send live messages. #3 requires the MUC service to keep more state. In general I see the subject as the *current* room topic and I don't think it is the responsibility of the service to maintain historical information about the prior subjects, so I think #1 is best (plus it provides a nice demarcation between historical messages and live messages, if there is a subject). > That's all for now. Perhaps I'll remember something else later. :) Thanks! Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
