Re: SIMPLE chat: Status codes

Hi Saul,

see inline.

On 09/02/2012 9:54, Saul Ibarra Corretge wrote:
> Hi,
>
> On Feb 8, 2012, at 9:10 AM, Miguel A. Garcia wrote:
>
>> The SIMPLE chat draft, draft-ietf-simple-chat-13t.txt, went through the Apps review. The reviewer had a comment that requires a bit of discussion in the working group before we take an action. Here is the issue.
>>
>> ---
>> In Section 7.1:
>>
>>      The reservation of a nickname can fail, e.g. if the NICKNAME request
>>      contains a malformed or non-existent Use-Nickname header field, or
>>      if the same nickname has already been reserved by another
>>      participant (i.e., by another URI) in the chat room.  The
>>      validation can also fail where the sender of the message is not
>>      entitled to reserve the nickname.  In any of these cases the MSRP
>>      switch MUST answer the NICKNAME request with a 423 response.  The
>>      semantics of the 423 response are: "Nickname usage failed; the
>>      nickname is not allocated to this user".
>>
>> It would be better to use different response codes for different error
>> conditions.
>> ---
>>
>> So, here is the discussion I would like to have. Do we need different response code for each of these issues? We can do:
>>
>
> I agree, some more fine grained error reporting would help applications give better feedback.
>
>> a) Do nothing and motivate why a single response code is sufficient
>>
>> b) Create a response code for each error situation. This could be, e.g.:
>>
>>    424 Malformed nickname
>>    425 Nickname already in use
>>    507 Not allowed to reserve a nickname
>>
>> Notice that the "Not allowed to reserve nickname" should have a 500-class response to indicate a permanent failure, as opposed to the other two error codes, where a new request fixing the problem may succed.
>
> These look just fine, user may just change the nickname and try again (in the 4xx cases), which I think it'll be helpful.
>
> What about nickname policy? Lets say a focus doesn't allow "admin", "root" and "god" as nicknames, should we consider that a malformed nickname? It's not really malformed, it's explicitly forbidden. What about this?
>    426 Forbidden nickname

I think these special nicknames are permanently reserved, so, they are in 
use (by the system).

I don't care much of the textual representation of the status code, since 
this is for us human to  understand. The important think is that the 
semantics are clear.

/Miguel
>
>>
>> Note: i just noticed that the 423 status code is already allocated (see http://www.iana.org/assignments/msrp-parameters/msrp-parameters.xml ) so I have chosen the next available status code.
>>
>>
>> And while composing this e-mail, I revised the rest of the status codes that we are requesting, and we have requested a status code 428 for indicating "Private messages not supported". I think this should be a 500-class status code as well, since it is a permanent failure. Can we also move this one to 508?
>>
>
> Agreed.
>
>
> Regards,
>

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain