Re: [scim] [INPUT REQUESTED] Re: Detailed error and status codes
Erik Wahlström <erik.wahlstrom@nexusgroup.com> Wed, 25 June 2014 07:25 UTC
Return-Path: <erik.wahlstrom@nexusgroup.com>
X-Original-To: scim@ietfa.amsl.com
Delivered-To: scim@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39A941B2B06 for <scim@ietfa.amsl.com>; Wed, 25 Jun 2014 00:25:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.051
X-Spam-Level:
X-Spam-Status: No, score=-1.051 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, J_CHICKENPOX_64=0.6, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zjo2Go5cYfs2 for <scim@ietfa.amsl.com>; Wed, 25 Jun 2014 00:25:25 -0700 (PDT)
Received: from smtp.nexusgroup.com (smtp.nexusgroup.com [83.241.133.121]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4340F1B2B05 for <scim@ietf.org>; Wed, 25 Jun 2014 00:25:23 -0700 (PDT)
Received: from NG-EX04.ad.nexusgroup.com (10.75.28.9) by NG-EX02.ad.nexusgroup.com (10.75.28.43) with Microsoft SMTP Server (TLS) id 15.0.847.32; Wed, 25 Jun 2014 09:25:20 +0200
Received: from NG-EX01.ad.nexusgroup.com (10.75.28.40) by NG-EX04.ad.nexusgroup.com (10.75.28.9) with Microsoft SMTP Server (TLS) id 15.0.847.32; Wed, 25 Jun 2014 09:25:19 +0200
Received: from NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab]) by NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab%12]) with mapi id 15.00.0847.030; Wed, 25 Jun 2014 09:25:19 +0200
From: Erik Wahlström <erik.wahlstrom@nexusgroup.com>
To: Phil Hunt <phil.hunt@oracle.com>
Thread-Topic: [scim] [INPUT REQUESTED] Re: Detailed error and status codes
Thread-Index: AQHPkARU/kJO3uaFVEmXGlkVn798fZuBS6sA
Date: Wed, 25 Jun 2014 07:25:19 +0000
Message-ID: <BE66EB70-40F3-4FC3-87DA-F828DDB300AD@nexusgroup.com>
References: <65922FF3-8637-4116-B336-C5424BF9BAAB@oracle.com> <53A9D021.2060906@gmx.de> <71B45AEC-9B79-4F3F-A933-23B0C2AF868E@oracle.com>
In-Reply-To: <71B45AEC-9B79-4F3F-A933-23B0C2AF868E@oracle.com>
Accept-Language: en-US, sv-SE
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.75.28.88]
Content-Type: multipart/alternative; boundary="_000_BE66EB7040F34FC387DAF828DDB300ADnexusgroupcom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/scim/aq08wnYsTwChwD6MpCDcFTYQHCQ
Cc: Julian Reschke <julian.reschke@gmx.de>, Scim WG <scim@ietf.org>
Subject: Re: [scim] [INPUT REQUESTED] Re: Detailed error and status codes
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Simple Cloud Identity Management BOF <scim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/scim>, <mailto:scim-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/scim/>
List-Post: <mailto:scim@ietf.org>
List-Help: <mailto:scim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/scim>, <mailto:scim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Jun 2014 07:25:28 -0000
So that would make it look like the following right? { "schemas": ["urn:scim:api:messages:2.0:Error"], "Error": { "type": "urn:scim:api:error:2.0:mutability", "title": “Attribute is readOnly.", "detail": “Attribute 'id' is readOnly and can’t be changed in a PATCH request.", “status": 400 } } I replaced Errors with Error. Also replaced urn:scim:error:api:2.0:mutability with urn:scim:api:error:2.0:mutability That works for me. / Erik On 25 Jun 2014, at 01:30, Phil Hunt <phil.hunt@oracle.com<mailto:phil.hunt@oracle.com>> wrote: Note: July 04 is the LAST day for us to potentially submit updates for the IETF90 meeting. This gives us about 1.5 weeks to close off the error issues and update the drafts. If you have a moment please take a look and comment as soon as possible... Julian thanks for the suggestion. For the rest of the group’s benefit, the draft Julian referenced suggests the following attributes be returned in a standardized detailed error JSON body… A problem details object MAY have the following members: o "type" (string) - An absolute URI [RFC3986<http://tools.ietf.org/html/rfc3986>] that identifies the problem type. When dereferenced, it SHOULD provide human-readable documentation for the problem type (e.g., using HTML [W3C.REC-html401-19991224<http://tools.ietf.org/html/draft-nottingham-http-problem-06#ref-W3C.REC-html401-19991224>]). When this member is not present, its value is assumed to be "about:blank". o "title" (string) - A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localisation. o "status" (number) - The HTTP status code ([RFC2616], Section 6<http://tools.ietf.org/html/rfc2616#section-6>) generated by the origin server for this occurrence of the problem. o "detail" (string) - An human readable explanation specific to this occurrence of the problem. o "instance" (string) - An absolute URI that identifies the specific occurrence of the problem. It may or may not yield further information if dereferenced. Here is the corresponding example error response: HTTP/1.1 403 Forbidden Content-Type: application/problem+json Content-Language: en { "type": "http://example.com/probs/out-of-credit", "title": "You do not have enough credit.", "detail": "Your current balance is 30, but that costs 50.", "instance": "http://example.net/account/12345/msgs/abc", "balance": 30, "accounts": ["http://example.net/account/12345", "http://example.net/account/67890"] } Julian, what is the value of having “type” be a URI? Why not just have a SCIM specific attribute (scimType) and use simple keywords? (asking mainly for the WG’s benefit). I guess the strong case is that by standardizing HTTP responses, client code gets simplified. However, using standard attributes creates the namespace conflict issue. So we need URI based error codes. The SCIM specs could adopt the “type”, “detail”, and “status”. We would register a namespace of urn:scim:error:apil:2.0 in the SCIM IANA section in addition to api:messages, schema:core, etc. This would give detail error types of: urn:scim:error:api:2.0:mutability, urnscim:error:api:2.0:filter, etc. The other items, like title, instance, etc could be optional or just omitted from SCIM spec. —> we would just indicate that clients should expect attributes within the JSON message other than those defined by the SCIM drafts. IMPORTANT NOTE: the format suggested by Julian allows for only one error at a time. Erik had commented he prefers to return only one. I tend to agree. In the case of BULK requests, this is not really an issue since each BULK operation gets its own response block. In the interests of time, any objections to using type (with URI based error codes), detail, status, per above and limiting to ONE per response? I know these are normative changes….however I’m pretty sure we can’t avoid changes in the final document clean up whether or not we adopt the proposed standardized error response. Cheers, Phil @independentid www.independentid.com<http://www.independentid.com/> phil.hunt@oracle.com<mailto:phil.hunt@oracle.com> On Jun 24, 2014, at 12:23 PM, Julian Reschke <julian.reschke@gmx.de<mailto:julian.reschke@gmx.de>> wrote: On 2014-06-24 21:01, Phil Hunt wrote: With regards to tickets 37, 46, 67, it looks like we will have some normative changes required. I am also expecting new SCIM error codes as we look at the possible reasons a server might return Bad Request or other HTTP status codes. Currently, the example response from PATCH, we use “error” to indicate a detailed error. * "error":"mutability"* >From Response Codes Section, no detail error is defined: *HTTP/1.1 404 NOT FOUND* { "schemas": ["urn:scim:api:messages:2.0:Error"], "Errors":[ { *"description":"Resource 2819c223-7f76-453a-919d-413861904646 not found", "code":"404"* } ] } Doing a search around Twitter, AWS, and many others, I see that “code” is often used to indicate a detailed error message (“mutability”) and status is used to indicate HTTP status. In an attempt to bring consistency across the API document, I am proposing we use http_status and scim_code. This will help make clear what we are referring to and allow existing implementations to co-exist for a while (by having different names). _Are there any objections to normalizing the spec around following format and attributes?_ Proposed example: *HTTP/1.1 400 Bad Request* Content-Type: application/scim+json;charset=UTF-8 Cache-Control: no-store Pragma: no-cache { "schemas": ["urn:scim:api:messages:2.0:Error"], "Errors":[ { *“scim_code":"mutability”,* * “http_status”:400,* "error_description":"Attribute 'id' is readOnly." }, . . . ] } ... You may want to read <http://tools.ietf.org/html/draft-nottingham-http-problem-06>... Best regards, Julian _______________________________________________ scim mailing list scim@ietf.org<mailto:scim@ietf.org> https://www.ietf.org/mailman/listinfo/scim _______________________________________________ scim mailing list scim@ietf.org<mailto:scim@ietf.org> https://www.ietf.org/mailman/listinfo/scim
- [scim] Detailed error and status codes Phil Hunt
- Re: [scim] Detailed error and status codes Julian Reschke
- Re: [scim] Detailed error and status codes Erik Wahlström
- [scim] [INPUT REQUESTED] Re: Detailed error and s… Phil Hunt
- Re: [scim] [INPUT REQUESTED] Re: Detailed error a… Erik Wahlström
- Re: [scim] [INPUT REQUESTED] Re: Detailed error a… Phil Hunt
- Re: [scim] [INPUT REQUESTED] Re: Detailed error a… Phil Hunt
- Re: [scim] [INPUT REQUESTED] Re: Detailed error a… David Möbius
- Re: [scim] [INPUT REQUESTED] Re: Detailed error a… Phil Hunt
- Re: [scim] [INPUT REQUESTED] Re: Detailed error a… David Möbius
- Re: [scim] [INPUT REQUESTED] Re: Detailed error a… Phil Hunt