On 10/5/11 2:11 PM, Mike Wacker wrote:
> On 10/4/2011 10:14 AM, Peter Saint-Andre wrote:
>> 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.
> Yes, a feature, for example, to request a unique nick would not create
> an incompatibility since old clients wouldn't use the feature. If you
> still let the client use any nick, it's backwards-compatible.
>
> But if you locked down nicks and required the client to use the nick
> returned by the feature, you would impact a pre-existing scenario,
> entering a room.
>>> 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).
> Or an easy way to avoid dealing with nick conflicts. If you locked down
> nicks, you could also have a predetermined 1:1 mapping between nicks and
> bare jids that can be calculated either way with O(1) space. While there
> always expected use cases, I find it's generally not good to assume a
> feature would only be used in a certain way :)
>
> But since the server can rewrite nicks, is it safe to say the client
> MUST gracefully handle this scenario? The one area where that causes
> concern for me is existing groupchat 1.0 clients, I obviously do not
> know how they would handle a nick rewrite.
>
>>> 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.
Thinking about this further, it strikes me that old groupchat 1.0
clients will not know anything about the 210 status code, so in that
case it would be better for the service to return an error. Note that
the service knows which clients support groupchat 1.0 and which clients
support MUC, so it can send an error to the former and a nick change to
the latter.
/psa
