So here is my list of notes: 1) Are we going to finally replace those creepy status codes?
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? 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). 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? 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. 6) Then, there is also the problem with the client not knowing whether it has all the history until a live message comes. 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. That's all for now. Perhaps I'll remember something else later. :)
signature.asc
Description: Toto je digitálně podepsaná část zprávy
