Re: SIMPLE chat: Status codes

hmmm... I agree with you Ben, the existing 403 code has the same semantics.

So, let's revise the proposal. List of new codes used by the draft:

      404 Failure to resolve recipient's URI
      424 Malformed nickname
      425 Nickname reserved or already in use
      428 Private messages not supported

Usage of existing codes:

      403 Not allowed


/Miguel


On 13/02/2012 16:03, Ben Campbell wrote:
>
> On Feb 13, 2012, at 8:59 AM, Miguel A. Garcia wrote:
>
>> I will try to give my perception, and propose something:
>>
>> - I believe there is a sentiment of providing as detailed as possible error codes.
>> - However, we don't want an explosion of MSRP error codes for chat.
>>
>> My interpretation: perhaps we can take something in between. Where it is expected that the endpoint will do different things based on the received error code, we should differentiate them. Where it is not possible to justify the difference, we should try to use a single one.
>>
>> Based on that, I still think we should go with my earlier proposal:
>>
>>     424 Malformed nickname
>>     425 Nickname reserved or already in use
>>     507 Not allowed to reserve a nickname
>
> I agree with the first two. How is the 507 different than 403? The requestor knows the context. Otherwise we could argue for a separate version of "forbidden" for every possible action.
>
>>
>>
>> Saul wanted one more error code to indicate "Nickname not allowed by the policy". But I argued that this can be modeled as a permanently reserved nickname and a 425 response (the nickname is syntactically correct, but you cannot reserve it). So, the endpoint will take the same action: display to the user that it is not possible to reserve that nickname, and give the user the possibility to select another one.
>>
>> Can we go for this?
>>
>> /Miguel
>>
>> On 13/02/2012 15:46, Ben Campbell wrote:
>>> (as chair)
>>>
>>> Does anyone else have thoughts on this question? The draft just finished IETF last call. We'd like to get an "approval candidate" back to the IESG as soon as possible.
>>>
>>> Thanks!
>>>
>>> Ben.
>>>
>>> On Feb 9, 2012, at 4:33 PM, Ben Campbell wrote:
>>>
>>>> (as individual)
>>>>
>>>> I have mixed emotions on the need for more granular nickname errors. I see the point, but I'm also hesitant to start a response code explosion.
>>>>
>>>> In this case, I guess it depends on what we expect a client implementation to do different with the different conditions. If the answer is "display the error to the end-user along with the comment text" for all cases, I don't find that very convincing.
>>>>
>>>> On Feb 9, 2012, at 4:00 AM, Saul Ibarra Corretge wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>
>>>>> Ok, bad example :-) I was thinking about some nicknames that could perhaps be disabled by the administrator, like bad words or some special names. This case is semantically different than a malformed nickname (it's not malformed) and it's also not "not in use" (nobody can use it, actually) so IMHO a new code could be appropriate.
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>> --
>>>>> Saúl Ibarra Corretgé
>>>>> AG Projects
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Simple mailing list
>>>>> [email protected]
>>>>> https://www.ietf.org/mailman/listinfo/simple
>>>>
>>>> _______________________________________________
>>>> Simple mailing list
>>>> [email protected]
>>>> https://www.ietf.org/mailman/listinfo/simple
>>>
>>
>> --
>> Miguel A. Garcia
>> +34-91-339-3608
>> Ericsson Spain
>> _______________________________________________
>> Simple mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/simple
>

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