Subject: [Simple] SIMPLE chat: Status codes

From: "Miguel A. Garcia" <[email-masked]>
Date: Wed, 8 Feb 2012 09:10:49 +0100

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:

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.

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?

Please comment.

/Miguel

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

---

From: Saul Ibarra Corretge <[email-masked]>
Date: Thu, 9 Feb 2012 09:54:59 +0100

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:
> 
> 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.

> 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

> 
> 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,

-- 
Saúl Ibarra Corretgé
AG Projects

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Thu, 9 Feb 2012 10:26:30 +0100

Hi Saul,

see inline.

> 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…

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

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

---

From: Saul Ibarra Corretge <[email-masked]>
Date: Thu, 9 Feb 2012 11:00:24 +0100

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

---

From: Ben Campbell <[email-masked]>
Date: Thu, 9 Feb 2012 16:30:13 -0600

(as individual)

> 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 m…

Keep in mind the MSRP error codes don't formally map to local and global failures. But I'm happy to stick to the informal convention of picking numbers similar to those for SIP or HTTP :-)

---

From: Ben Campbell <[email-masked]>
Date: Thu, 9 Feb 2012 16:33:47 -0600

(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:

> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/simple

---

From: Ben Campbell <[email-masked]>
Date: Mon, 13 Feb 2012 08:46:54 -0600

(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.

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Mon, 13 Feb 2012 15:59:11 +0100

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

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

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

---

From: Ben Campbell <[email-masked]>
Date: Mon, 13 Feb 2012 09:03:41 -0600

On Feb 13, 2012, at 8:59 AM, Miguel A. Garcia wrote:

> - I believe there is a sentiment of providing as detailed as possible error codes.
> 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.
> 

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
>

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Tue, 14 Feb 2012 07:33:03 +0100

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

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

---

From: Ben Campbell <[email-masked]>
Date: Tue, 14 Feb 2012 00:57:38 -0600

>     428 Private messages not supported

wfm

Thanks!

Ben.

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Tue, 14 Feb 2012 10:10:13 +0100

>     428 Private messages not supported

+1, the new semantics for 425 covers the case I mentioned before and using 403 instead of 507 also seems fine.

Regards,

--
Saúl Ibarra Corretgé
AG Projects