Re: [scim] Proposed Detail Errors

[Phil Hunt <[e-mail]>]

How so?

Phil

> On Jun 30, 2014, at 12:24, Anthony Nadalin <[e-mail]> wrote:
> 
> Isn’t this going to be a continued problems with IANA updates ?
>  
> From: scim [mailto:[e-mail]] On Behalf Of Phil Hunt
> Sent: Monday, June 30, 2014 11:14 AM
> To: Kelly Grizzle
> Cc: Scim WG
> Subject: Re: [scim] Proposed Detail Errors
>  
> After thinking about this a bit, I think URIs for scimType is the best way to go. While having a URI means a new IANA registry, it is probably simpler to implement and allows for the capability for SPs to extend errors as Kelly and David have requested.  It is also in line with: http://tools.ietf.org/html/draft-nottingham-http-problem-06
>  
> As many are off-line much of the week due to Canadian and US holidays, and the window for submissions for IETF90 closes Friday, I will start work amending the API draft to include the error codes listed at the start of this thread but with URIs and will add the IANA registry for errors.
>  
> Phil
>  
> @independentid
> www.independentid.com
> [e-mail]
>  
>  
>  
> On Jun 30, 2014, at 8:56 AM, Phil Hunt <[e-mail]> wrote:
> 
> 
> David had a similar comment. 
>  
> What if there was a separate attribute: spCode that allows the service provider to indicate non-protocol errors?
> 
> Phil
> 
> On Jun 30, 2014, at 7:46, Kelly Grizzle <[e-mail]> wrote:
> 
> I remember that one of the initial drivers for this ticket was the ability for service providers to send back error codes that are specific to the service provider.
>  
> An example on a user creation might be “error 28738” … “client has exceeded the maximum number of users in their organization”.  Ideally the SP would be able to communicate back the general HTTP error code, a provider-specific error code, and a human readable description.
>  
> I think that scimType would allow for this if the list were extensible.
>  
> --Kelly
>  
> From: Phil Hunt [mailto:[e-mail]] 
> Sent: Sunday, June 29, 2014 3:27 PM
> To: Kelly Grizzle
> Cc: Scim WG
> Subject: Re: [scim] Proposed Detail Errors
>  
> Could be if we use URIs for codes 
> 
> Phil
> 
> On Jun 29, 2014, at 13:09, Kelly Grizzle <[e-mail]> wrote:
> 
> I like these, Phil.  Should this list of error codes be extensible?
>  
>  
> From: scim [mailto:[e-mail]] On Behalf Of Phil Hunt
> Sent: Friday, June 27, 2014 1:47 PM
> To: Scim WG
> Subject: [scim] Proposed Detail Errors
>  
> After reviewing the API and Schema docs, here is a first cut of the detailed error codes.
>  
> For HTTP Status 400 (Bad Request) responses, the following detail
>    error types are defined:
>  
> +--------------+------------------------------+---------------------+
> | scimType     | Description                  | Applicability       |
> +--------------+------------------------------+---------------------+
> | invalidFilte | The specified filter syntax  | GET(Section 3.2.2), |
> | r            | was invalid (does not comply | POST (Search -      |
> |              | with Figure 1) or the        | Section 3.2.3),     |
> |              | specified attribute and      | PATCH (Path Filter  |
> |              | filter comparison            | - Section 3.3.2)    |
> |              | combination is not           |                     |
> |              | supported.                   |                     |
> | uniqueness   | One or more of attribute     | POST (Create -      |
> |              | values is already in use or  | Section 3.1), PUT   |
> |              | is reserved.                 | (Section 3.3.1),    |
> |              |                              | PATCH (Section      |
> |              |                              | 3.3.2)              |
> | mutability   | The attempted modification   | PUT (Section        |
> |              | is not compatible with the   | 3.3.1), PATCH       |
> |              | target attributes mutability | (Section 3.3.2)     |
> |              | or current state (e.g.       |                     |
> |              | modification of an immutable |                     |
> |              | attribute with an existing   |                     |
> |              | value).                      |                     |
> | invalidSynta | The request body message     | POST (Search -      |
> | x            | structure was invalid or did | Section 3.2.2,      |
> |              | not conform to the request   | Create - Section    |
> |              | schema.                      | 3.1, Bulk - Section |
> |              |                              | 3.5), PUT (Section  |
> |              |                              | 3.3.1)              |
> | invalidPath  | The path attribute was       | PATCH (Section      |
> |              | invalid or malformed (see    | 3.3.2)              |
> |              | Figure 4).                   |                     |
> | noTarget     | The specified "path" did not | PATCH (Section      |
> |              | yield an attribute or        | 3.3.2)              |
> |              | attribute value that could   |                     |
> |              | be operated on. This occurs  |                     |
> |              | when the specified "path"    |                     |
> |              | value contains a filter that |                     |
> |              | yields no match.             |                     |
> | invalidValue | A required value was         | GET (Section        |
> |              | missing, or the value        | 3.2.2), POST        |
> |              | specified was not compatible | (Create - Section   |
> |              | with the operation or        | 3.1, Search -       |
> |              | attribute type (see Section  | Section 3.2.2), PUT |
> |              | 2.1 [I-D.ietf-scim-core-sche | (Section 3.3.1),    |
> |              | ma]).                        | PATCH (Section      |
> |              |                              | 3.3.2)              |
> | invalidVers  | The specified API version is | GET (Section        |
> |              | not supported (see Section   | 3.2.2), POST (ALL), |
> |              | 3.11).                       | PUT (Section        |
> |              |                              | 3.3.1), PATCH       |
> |              |                              | (Section 3.3.2),    |
> |              |                              | DELETE (Section     |
> |              |                              | 3.4)                |
> +--------------+------------------------------+---------------------+
> I plan to put these into draft 07 of the API and will publish over the weekend.
>  
> As always, feedback welcome!
>  
> Phil
>  
> @independentid
> www.independentid.com
> [e-mail]
>  
>  
>  
> _______________________________________________
> scim mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/scim
> _______________________________________________
> scim mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/scim
> _______________________________________________
> scim mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/scim
>