Subject: [scim] Errors vs Error

From: Phil Hunt <[email-masked]>
Date: Fri, 9 May 2014 10:15:06 -0700

At IIW this week, Erik, Morteza and I noticed that Section 3.9 (response codes) has an example detail response supporting multiple error messages.
> HTTP/1.1 404 NOT FOUND
> 
> {
>   "schemas": ["urn:scim:schemas:core:2.0:Error"],
>   "Errors":[
>     {
>       "description":"Resource 2819c223-7f76-453a-919d-413861904646 not found",
>       "code":"404"
>     }
>   ]
> }

We looked through the spec and could not find any cases where the “Errors” object is needed to support multiple errors. Even in the case of BULK requests, each request object gets its own response.

I also can’t find a reason to return the “schemas” attribute.  Any reasoning here? 

Does the following work?

HTTP/1.1 404 NOT FOUND

{
  "Error":[
    {
      "description":"Resource /Users/2819c223-7f76-453a-919d-413861904646 not found",
      "code":"404"
    }
  ]
}

Phil

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

---

From: Ian Glazer <[email-masked]>
Date: Fri, 9 May 2014 13:18:46 -0400

Yes

On Fri, May 9, 2014 at 1:15 PM, Phil Hunt <[email-masked]> wrote:

> At IIW this week, Erik, Morteza and I noticed that Section 3.9 (response
> codes) has an example detail response supporting multiple error messages.
>
> HTTP/1.1 404 NOT FOUND
>
> {
> We looked through the spec and could not find any cases where the “Errors”
> object is needed to support multiple errors. Even in the case of BULK
> requests, each request object gets its own response.
>
> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim
>
>

-- 
Ian Glazer
Senior Director, Identity
+1 202 255 3166
@iglazer <https://twitter.com/iglazer>

---

From: Phil Hunt <[email-masked]>
Date: Fri, 9 May 2014 10:49:00 -0700

I’m thinking we should be consistent with the status structure shown in Bulk.  See page 36/37 of draft 04.

IOW. We return the same block whether in an “operations” array in Bulk or in response to a regular SCIM operation (which has only one operation).

For example, for a bulk error response:
HTTP/1.1 200 OK
Content-Type: application/json

{
  "schemas": ["urn:scim:schemas:core:2.0:BulkResponse"],
  "Operations": [
    {
      "method": "POST",
      "bulkId": "qwerty",
      "status": {
        "code": "400",
        "description": "Request is unparseable, syntactically incorrect, or violates schema."
      }
    },
...
    {
      "location": "https://example.com/v2/Users/e9025315-6bea-44e1-899c-1e07454e468b",
      "method": "DELETE",
      "status": {
        "code": "404",
        "description": "Specified resource; e.g., User, does not exist."
      }
    }
  ]
}

And a single operation fail response:

HTTP/1.1 400 BAD
Content-Type: application/json

{
  "status": {
      "code": "400",
      "description": "Request is unparseable, syntactically incorrect, or violates schema."
  }
}

Phil

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

On May 9, 2014, at 10:23 AM, Melvin Laguren <[email-masked]> wrote:

> I agree.  I have not been able to find a use case where multiple errors would be returned.
> 
> As for the schemas, would we need it to identify the error object if we change from the current object to the following:
> 
> {
> 
> "problemType": "​http://example.com/errors/insufficient-access",
> "title": "You do not have the required permissions to create a new user.",
> "detail": "Creating a user requires RIGHT_CREATE_USER."
> 
> }
> 
> As proposed in ticket 46?
> 
> 
> 
> On Fri, May 9, 2014 at 10:18 AM, Ian Glazer <[email-masked]> wrote:
> Yes
> 
> 
> @iglazer
> Melvin Laguren
> Twitter:  @mlaguren
> Blog:  www.sqaessentials.com
> Meetups:  http://www.meetup.com/test-armory & http://www.meetup.com/The-Mobile-Testing-Gurus

---

From: Kelly Grizzle <[email-masked]>
Date: Fri, 9 May 2014 17:53:02 +0000

I looked into this a bit when researching for issue 46 (http://trac.tools.ietf.org/wg/scim/trac/ticket/46).

Regarding the fact that SCIM uses an "Errors" array, I was not able to find any documented reason for this in the old google mailing list or on the IETF mailing list. Based on the above links, it looks like multiple errors are most often used to return error information specific to data fields that are POSTed (eg - missing required field 'username', field value is in the incorrect format 'email'). I'm not sure how valuable this would be for SCIM request.

From: scim [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Friday, May 09, 2014 12:15 PM
To: Scim WG
Cc: Melvin Laguren
Subject: [scim] Errors vs Error

HTTP/1.1 404 NOT FOUND

{

  "Errors":[

    {

      "code":"404"

    }

  ]

}

We looked through the spec and could not find any cases where the "Errors" object is needed to support multiple errors. Even in the case of BULK requests, each request object gets its own response.

I also can't find a reason to return the "schemas" attribute.  Any reasoning here?

Does the following work?

HTTP/1.1 404 NOT FOUND

{

  "Error":[

    {

      "code":"404"

    }

  ]

}

Phil

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

---

From: Phil Hunt <[email-masked]>
Date: Fri, 9 May 2014 10:53:42 -0700

I would also suggest we add a detailed error type.  E.g. error_type.  The PATCH operation indicates sub-errors like: 
* malformed_operation
* mutability (attempt to modify an immutable or readOnly attribute)
* invalid_path
* no_target (e.g when a complex filter fails to find a value)
* invalid_value  (value was missing or incompatible with the attribute type)

Phil

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

---

From: Shelley <[email-masked]>
Date: Mon, 12 May 2014 11:57:43 -0500

Our SCIM 1.1 SP implementation currently returns multiple error
descriptions representing validation errors when creating/modifying
individual resources:

{
    "Errors": [
        {
            "description": "Invalid attribute 'username': may not be null
or empty",
            "code": "400"
        },
        {
            "description": "Invalid attribute 'locale': must be composed of
a 2-letter language code (ISO 639-1), an underscore and a 2-letter country
code (ISO 3166-1)",
            "code": "400"
        },
        {
            "description": "Invalid attribute 'emails[0].value': not a
well-formed email address",
            "code": "400"
        }
    ]
}

Having multiple errors in such a scenario is quite beneficial to consumers.
I'd propose continuing to allow multiple errors to be returned to
accommodate such scenarios.

That said, relaying the http status code within the errors response body
seems redundant and unnecessary. The "code" in its current form provides no
value other than perhaps for BULK, which seems to use a slight variation on
the Errors representation anyway.

On Fri, May 9, 2014 at 12:53 PM, Kelly Grizzle
<[email-masked]>wrote:

>  I looked into this a bit when researching for issue 46 (
> http://trac.tools.ietf.org/wg/scim/trac/ticket/46).
>
>
>
> Regarding the fact that SCIM uses an "Errors" array, I was not able to
> find any documented reason for this in the old google mailing list or on
> the IETF mailing list. Based on the above links, it looks like multiple
> errors are most often used to return error information specific to data
> fields that are POSTed (eg - missing required field 'username', field value
> is in the incorrect format 'email'). I'm not sure how valuable this would
> be for SCIM request.
>
>
>
> *From:* scim [mailto:[email-masked]] *On Behalf Of *Phil Hunt
> *Sent:* Friday, May 09, 2014 12:15 PM
> *To:* Scim WG
> *Cc:* Melvin Laguren
> *Subject:* [scim] Errors vs Error
>
>
>

---

From: Melvin Laguren <[email-masked]>
Date: Mon, 12 May 2014 10:58:21 -0700

That's a good example for the need for multiple errors.  Most of the
companies I work with at the the implementation primarily fail for one
reason.

Additionally, I think code should be optional and reference more to
internal codes that provide additional information.  Twitter and Facebook
use code in this way.

-- 
Melvin Laguren
Twitter:  @mlaguren
Blog:  www.sqaessentials.com
Meetups:  http://www.meetup.com/test-armory &
http://www.meetup.com/The-Mobile-Testing-Gurus

On Mon, May 12, 2014 at 9:57 AM, Shelley <[email-masked]> wrote:

>             "description": "Invalid attribute 'locale': must be composed
> of a 2-letter language code (ISO 639-1), an underscore and a 2-letter
> country code (ISO 3166-1)",
>             "code": "400"
>         },
>         {
> Having multiple errors in such a scenario is quite beneficial to
> consumers. I'd propose continuing to allow multiple errors to be returned
> to accommodate such scenarios.
>
> On Fri, May 9, 2014 at 12:53 PM, Kelly Grizzle <
> [email-masked]> wrote:
>
>> We looked through the spec and could not find any cases where the
>> “Errors” object is needed to support multiple errors. Even in the case of
>> BULK requests, each request object gets its own response.
>>
>>
>>

---

From: Phil Hunt <[email-masked]>
Date: Mon, 12 May 2014 11:04:01 -0700

I think there needs to be a code word (IANA registered?) like “invalid_syntax”.  Descriptive text can be provided and that would be optional.

In the detailed error JSON, the HTTP Response code appears redundant.

Phil

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

On May 12, 2014, at 10:58 AM, Melvin Laguren <[email-masked]> wrote:

> That's a good example for the need for multiple errors.  Most of the companies I work with at the the implementation primarily fail for one reason.
> 
> Additionally, I think code should be optional and reference more to internal codes that provide additional information.  Twitter and Facebook use code in this way.
> 
> -- 
> Melvin Laguren
> Twitter:  @mlaguren
> Our SCIM 1.1 SP implementation currently returns multiple error descriptions representing validation errors when creating/modifying individual resources:
> 
> {
>     "Errors": [
>         {
>             "description": "Invalid attribute 'username': may not be null or empty",
>             "code": "400"
>         },
>         {
>             "description": "Invalid attribute 'locale': must be composed of a 2-letter language code (ISO 639-1), an underscore and a 2-letter country code (ISO 3166-1)",
>             "code": "400"
>         },
>         {
>             "description": "Invalid attribute 'emails[0].value': not a well-formed email address",
>             "code": "400"
>         }
>     ]
> }
> 
> Having multiple errors in such a scenario is quite beneficial to consumers. I'd propose continuing to allow multiple errors to be returned to accommodate such scenarios.
> 
> That said, relaying the http status code within the errors response body seems redundant and unnecessary. The "code" in its current form provides no value other than perhaps for BULK, which seems to use a slight variation on the Errors representation anyway.
> 
> 
> 
> On Fri, May 9, 2014 at 12:53 PM, Kelly Grizzle <[email-masked]> wrote:

---

From: Kelly Grizzle <[email-masked]>
Date: Mon, 12 May 2014 18:23:15 +0000

I believe that the code was initially included in the error response for cases where the client may not easily be able to read the status code (similar to the way that location and version are included in the meta attribute in addition to the response headers).  I don't know how many clients are other there that would have difficulty with this, but that was the original thought process.

From: Phil Hunt [mailto:[email-masked]]
Sent: Monday, May 12, 2014 1:04 PM
To: Melvin Laguren
Cc: Shelley; Kelly Grizzle; Scim WG
Subject: Re: [scim] Errors vs Error

I think there needs to be a code word (IANA registered?) like "invalid_syntax".  Descriptive text can be provided and that would be optional.

Phil

@independentid

On May 12, 2014, at 10:58 AM, Melvin Laguren <[email-masked]<mailto:[email-masked]>> wrote:

--
Melvin Laguren
Twitter:  @mlaguren
Blog:  www.sqaessentials.com<http://www.sqaessentials.com/>
Meetups:  http://www.meetup.com/test-armory & http://www.meetup.com/The-Mobile-Testing-Gurus

On Mon, May 12, 2014 at 9:57 AM, Shelley <[email-masked]<mailto:[email-masked]>> wrote:

On Fri, May 9, 2014 at 12:53 PM, Kelly Grizzle <[email-masked]<mailto:[email-masked]>> wrote:
I looked into this a bit when researching for issue 46 (http://trac.tools.ietf.org/wg/scim/trac/ticket/46).

From: scim [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Phil Hunt
Sent: Friday, May 09, 2014 12:15 PM
To: Scim WG
Cc: Melvin Laguren
Subject: [scim] Errors vs Error

HTTP/1.1 404 NOT FOUND

{

  "Errors":[

    {

      "code":"404"

    }

  ]

}

Does the following work?

HTTP/1.1 404 NOT FOUND

{

  "Error":[

    {

      "code":"404"

    }

  ]

}

Phil

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

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

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