Subject: Re: [scim] Proposed Detail Errors

From: Erik Wahlström <[email-masked]>
Date: Tue, 1 Jul 2014 13:53:17 +0000

Limiting the error codes works for me. As scimType is optional should a general “400 bad request” just not add the scimType or should we also specify a “general” scimType to make it clear? Otherwise we should write it in bit more detail in the text "For HTTP Status 400 (Bad Request) responses, the following detail error types are defined and is optional to return for the Service Provider:”

/ Erik

On 01 Jul 2014, at 05:50, Phil Hunt <[email-masked]> wrote:

> My worry is that if service providers implement non-standard codes and than do not register them, then they can expect that clients shall ignore their proprietary custom codes.
> 
> Still, service providers should also expect that not every client will implement registered codes either.
> 
> Clients will need to keep in mind that many service providers will likely only return a general 400 bad request for *any* error as they may be cautious about proving attacks.
> 
> I recommend we limit error codes to protocol and schema issues only in order to get to a final draft in Toronto.
> 
> I understand the value of detailed error codes to coding smart UIs. But I would prefer to deal with these fine-grained errors in a future charter.
> 
> Phil
> 
> @independentid
> www.independentid.com
> [email-masked]
> 
> 
> 
> On Jun 30, 2014, at 4:13 PM, Kelly Grizzle <[email-masked]> wrote:
> 
>> I don't know that service providers should have to register codes that are specific to their implementation ... that kind of seems like overkill to me.  What benefit does that provide other than possibly preventing collisions?
>> 
>> As long as the SP can provide information to the client about what error occurred, it feels like that is enough.  The error code sent in the response could either be one of the SCIM-defined errors (mutability, etc...) or a provider-defined error (eg - an error code number, etc...).
>> 
>> 
>> -----Original Message-----
>> From: scim [mailto:[email-masked]] On Behalf Of Leif Johansson
>> Sent: Monday, June 30, 2014 5:54 PM
>> To: [email-masked]
>> Subject: Re: [scim] Proposed Detail Errors
>> 
>> On 2014-06-30 23:43, Anthony Nadalin wrote:
>>> Concern is that this can cause continuous code changes in different 
>>> codes being registered, ideally there would only be a couple and they 
>>> would be from the start but this could grow and cause interoperability 
>>> issues with folks registering error codes
>> 
>> Thats going to be true for any extension though, right? Errors are no worse in this respect.
>> 
>> _______________________________________________
>> scim mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/scim
>> 
>> _______________________________________________
>> scim mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/scim
> 
> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim

---

From: Anthony Nadalin <[email-masked]>
Date: Tue, 1 Jul 2014 16:27:27 +0000

+1

-----Original Message-----
From: scim [mailto:[email-masked]] On Behalf Of Erik Wahlström
Sent: Tuesday, July 1, 2014 6:53 AM
To: Phil Hunt
Cc: Leif Johansson; [email-masked]; Kelly Grizzle
Subject: Re: [scim] Proposed Detail Errors

Limiting the error codes works for me. As scimType is optional should a general "400 bad request" just not add the scimType or should we also specify a "general" scimType to make it clear? Otherwise we should write it in bit more detail in the text "For HTTP Status 400 (Bad Request) responses, the following detail error types are defined and is optional to return for the Service Provider:"

/ Erik

On 01 Jul 2014, at 05:50, Phil Hunt <[email-masked]> wrote:

>>> codes being registered, ideally there would only be a couple and 
>>> they would be from the start but this could grow and cause 
>>> interoperability issues with folks registering error codes
>>

---

From: Phil Hunt <[email-masked]>
Date: Tue, 1 Jul 2014 09:53:24 -0700

+1

I think scimType should be omitted if the server is not prepared to share the detail. 

We should keep in mind a request might be rejected by a non-scim provider such as a gateway. In these cases there may be no body either. This shouldn't he surprising--just normal http stuff. 

Phil

> On Jul 1, 2014, at 9:27, Anthony Nadalin <[email-masked]> wrote:
> 
> +1
>

---

From: Kelly Grizzle <[email-masked]>
Date: Tue, 1 Jul 2014 17:21:57 +0000

> My worry is that if service providers implement non-standard codes and than do not register
> them, then they can expect that clients shall ignore their proprietary custom codes.

I don't agree with this.  My thinking is not that the client needs to have a smart UI that can deal with these error codes, but that they need a way to know specifically what went wrong from a debugging perspective.  More than likely the error code will just get shoved into a log file, but it gives the sys admin of the client the ability to know why a request failed.

This type of information could be returned in the description of the error, but if clients want to be able to handle these smartly they will have to start parsing error messages.

This was one of the key things to be answered in ticket 46:

       3) If a service provider wants to transmit a more detailed error code, how would it do this?
       Does this have to fit into the formatted description or can another sub-attribute be added
       to the error reponse?

--Kelly

-----Original Message-----
From: Phil Hunt [mailto:[email-masked]] 
Sent: Monday, June 30, 2014 10:51 PM
To: Kelly Grizzle
Cc: Leif Johansson; [email-masked]
Subject: Re: [scim] Proposed Detail Errors

Phil

@independentid
www.independentid.com
[email-masked]

On Jun 30, 2014, at 4:13 PM, Kelly Grizzle <[email-masked]> wrote:

>> would be from the start but this could grow and cause

---

From: Phil Hunt <[email-masked]>
Date: Wed, 2 Jul 2014 10:12:21 -0700

Folks,

We’ve had quite a lot of discussion on this thread. It seems that the list of errors (below) is well accepted but the question of extensibility still needs to be resolved.

I propose to publish the errors (shown below) with an editorial comment that extensibility is being discussed and that these may change to URIs (depending on how we resolve).

The reason I would like to have this published is so that attendees can have all the information in context for the meeting and the deadline is Friday. 

Any objections?

Phil

@independentid
www.independentid.com
[email-masked]

On Jun 27, 2014, at 11:47 AM, Phil Hunt <[email-masked]> wrote:

> 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
> [email-masked]
> 
> 
>

---

From: Anthony Nadalin <[email-masked]>
Date: Wed, 2 Jul 2014 17:16:45 +0000

Fine, let's move this forward

From: scim [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Wednesday, July 2, 2014 10:12 AM
To: Scim WG
Subject: Re: [scim] Proposed Detail Errors

Folks,

We've had quite a lot of discussion on this thread. It seems that the list of errors (below) is well accepted but the question of extensibility still needs to be resolved.

Any objections?

Phil

@independentid
www.independentid.com<http://www.independentid.com>
[email-masked]<mailto:[email-masked]>

On Jun 27, 2014, at 11:47 AM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:

   error types are defined:

|              | supported.                   |                     |

|              |                              | PATCH (Section      |

|              |                              | 3.3.2)              |

|              | value).                      |                     |

|              |                              | 3.3.1)              |

|              | Figure 4).                   |                     |

|              | yields no match.             |                     |

|              |                              | 3.3.2)              |

|              |                              | 3.3.1), PATCH       |

|              |                              | (Section 3.3.2),    |

|              |                              | DELETE (Section     |

|              |                              | 3.4)                |

Phil

@independentid
www.independentid.com<http://www.independentid.com/>
[email-masked]<mailto:[email-masked]>

---

From: Kelly Grizzle <[email-masked]>
Date: Wed, 2 Jul 2014 17:43:42 +0000

Works for me.

From: scim [mailto:[email-masked]] On Behalf Of Anthony Nadalin
Sent: Wednesday, July 02, 2014 12:17 PM
To: Phil Hunt; Scim WG
Subject: Re: [scim] Proposed Detail Errors

Folks,

Any objections?

Phil

@independentid

   error types are defined:

|              | supported.                   |                     |

|              |                              | PATCH (Section      |

|              |                              | 3.3.2)              |

|              | value).                      |                     |

|              |                              | 3.3.1)              |

|              | Figure 4).                   |                     |

|              | yields no match.             |                     |

|              |                              | 3.3.2)              |

|              |                              | 3.3.1), PATCH       |

|              |                              | (Section 3.3.2),    |

|              |                              | DELETE (Section     |

|              |                              | 3.4)                |

Phil

@independentid

---

From: Phil Hunt <[email-masked]>
Date: Wed, 2 Jul 2014 11:12:24 -0700

One item missed.

Reviewing ticket 37, I see I missed the case where the filter specified yields too many matches.

I will add a code “tooMany” to describe this condition.

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Kelly Grizzle <[email-masked]>
Date: Wed, 2 Jul 2014 18:15:28 +0000

How about maxResultsExceeded so it will match up with the filter.maxResults attribute in ServiceProviderConfig?

From: scim [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Wednesday, July 02, 2014 1:12 PM
To: Scim WG
Subject: Re: [scim] Proposed Detail Errors

One item missed.

I will add a code "tooMany" to describe this condition.

Phil

@independentid

   error types are defined:

|              | supported.                   |                     |

|              |                              | PATCH (Section      |

|              |                              | 3.3.2)              |

|              | value).                      |                     |

|              |                              | 3.3.1)              |

|              | Figure 4).                   |                     |

|              | yields no match.             |                     |

|              |                              | 3.3.2)              |

|              |                              | 3.3.1), PATCH       |

|              |                              | (Section 3.3.2),    |

|              |                              | DELETE (Section     |

|              |                              | 3.4)                |

Phil

@independentid

_______________________________________________
scim mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/scim

---

From: Phil Hunt <[email-masked]>
Date: Wed, 2 Jul 2014 11:44:42 -0700

It could be tied to that number.

However, I didn’t want to assume that max number of matches was limited to maxResults.  You could have a 1000 matches but limit returns to 100 at a time.

In other cases, the server may return the error immediately without actually doing much calculation since it has determined the filter is just too small. For example, in a search-as-you-type scenario, having a couple of letters, may just be ignored.

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Kelly Grizzle <[email-masked]>
Date: Wed, 2 Jul 2014 21:42:18 +0000

I'm not sure that I understand what you're saying.  Are you saying that in some cases a server might return an exception and other times it might just not return any results or a limited result set?

From: Phil Hunt [mailto:[email-masked]]
Sent: Wednesday, July 02, 2014 1:45 PM
To: Kelly Grizzle
Cc: Scim WG
Subject: Re: [scim] Proposed Detail Errors

However, I didn't want to assume that max number of matches was limited to maxResults.  You could have a 1000 matches but limit returns to 100 at a time.

Phil

@independentid

On Jul 2, 2014, at 11:15 AM, Kelly Grizzle <[email-masked]<mailto:[email-masked]>> wrote:

One item missed.

Phil

@independentid

   error types are defined:

|              | supported.                   |                     |

|              |                              | PATCH (Section      |

|              |                              | 3.3.2)              |

|              | value).                      |                     |

|              |                              | 3.3.1)              |

|              | Figure 4).                   |                     |

|              | yields no match.             |                     |

|              |                              | 3.3.2)              |

|              |                              | 3.3.1), PATCH       |

|              |                              | (Section 3.3.2),    |

|              |                              | DELETE (Section     |

|              |                              | 3.4)                |

Phil

@independentid

---

From: Phil Hunt <[email-masked]>
Date: Wed, 2 Jul 2014 15:18:36 -0700

There server might decide not to process the request at all as it would return too many results (the amount undefined).   Example bad request:

GET /Users?filter=useName eq “*”&sortby=name

This would essentially cause the server to do an incredible amount of work only to dump 99.9% of it to return a relatively small maxResults set of results.

in this case, the filter syntax is valid, but the server is simply not willing to do the query.

Phil

@independentid
www.independentid.com
[email-masked]

On Jul 2, 2014, at 2:42 PM, Kelly Grizzle <[email-masked]> wrote:

> I’m not sure that I understand what you’re saying.  Are you saying that in some cases a server might return an exception and other times it might just not return any results or a limited result set?
>

---

From: David Möbius <[email-masked]>
Date: Thu, 03 Jul 2014 06:36:11 +0200

fine for me :)

Am 02.07.2014 19:12, schrieb Phil Hunt:
> Folks,
> 
> We’ve had quite a lot of discussion on this thread. It seems that the
> list of errors (below) is well accepted but the question of
> extensibility still needs to be resolved.
> 
> I propose to publish the errors (shown below) with an editorial comment
> that extensibility is being discussed and that these may change to URIs
> (depending on how we resolve).
> 
> The reason I would like to have this published is so that attendees can
> have all the information in context for the meeting and the deadline is
> Friday. 
> 
> *Any objections?*
> 
> Phil
> 
> @independentid
> www.independentid.com <http://www.independentid.com>
> [email-masked] <mailto:[email-masked]>
> 
> 
> 
>> www.independentid.com <http://www.independentid.com/>
>> [email-masked] <mailto:[email-masked]>
>>
>>
>>
> 
> 
>