On 10/3/11 5:11 PM, Mike Wacker wrote: > Hello, > > One of the tenets of XEP-0045 is backwards-compatibility with groupchat > 1.0.
Additional features do not necessarily introduce incompatibility. The old "Groupchat 1.0" protocol had very few features. > I was wondering if reserved nicks break this tenet. XEP-0045 says > clients SHOULD first try to discover a reserved nick, if any, before > entering a room. However, the server MAY lock down nicks and return an > error if the reserved nick is not used. If it does lock down nicks, then > the client actually MUST (not SHOULD) check for a reserved nick before > entering the room, since using any other nick would cause an error. Rooms with nick lockdown are typically deployed in very controlled environments (e.g., military systems where each person must be identified exactly as they are registered or authenticated). > I used the Wayback Machine to look at the old page about the groupchat > 1.0 protocol and early versions of JEP-0045, and none of them indicate > support for discovering reserved nicks, meaning the client has to set > the nick instead. Correct. > Thus, it seems like older clients, including > groupchat, would actually break if the server locked down nicks and > returned an error if the reserved nick was not used to enter a room. So you couldn't join the room. Again, such rooms will be deployed in very controlled environments. > (Though I don't know the history of groupchat other than what old docs > said, so someone can correct me if there's some missing piece here not > mentioned in the docs.) > > RC7 for XEP-0045 1.25 allows servers to rewrite nicks. If a nick rewrite > does not break old groupchat clients, perhaps we should say the server > MUST rewrite the nick instead of returning an error if the nicks are > locked down and a nick other than the reserved one is used to enter the > room. I do think that such an approach is more consistent with Postel's Law, so I'll adjust the text accordingly. Peter -- Peter Saint-Andre https://stpeter.im/
