Subject: [scim] URI suffixes in SCIM

From: Alex Redston <[email-masked]>
Date: Wed, 12 Jun 2013 15:55:00 +0100

Hello SCIM list

My team are currently implementing SCIM on our platform and have found a 
curious anomaly which seems to not make any sense. Please accept my 
apologies if this mater has previously been raised or is part of an old 
draft.

  * The SCIM API Draft specification states that "Consumers ... MAY
    specify the desired response data format via an HTTP Accept Header;
    e.g.,"Accept: application/json" *or via URI suffix; e.g., GET
    /Users/2819c223-7f76-453a-919d-413861904646.json*" (section 3.6 of
    draft-ietf-scim-api-01)
  * Although the same section does not state that Service Providers MUST
    support URI suffixes as an alternative indication of the Consumer's
    desired response, it is implied
  * Since the URI suffix appears as part of the resource identifier,
    before the ? (see RFC3986 section 3.3, "Path"), appending different
    suffixes effectively implies a different resource, so that
    *2819c223-7f76-453a-919d-413861904646*,
    *2819c223-7f76-453a-919d-413861904646.xml* and
    *2819c223-7f76-453a-919d-413861904646.json* are canonically
    different. /Representation/ should not be confused with /Resource
    Identification/
  * Use of URI suffixes to indicate content-type is a throwback to
    filesystem-based web servers which use filename extensions to deduce
    content-type, which are unlikely to be used to build SCIM
    implementations, and is thus not relevant to this spec
  * We would like to motion to have the requirement that "Consumers ...
    MAY specify the desired response data format ... via URI suffix" be
    removed from the daft spec.

Thanks

Alex

-- 
Alex Redston

Technical Architect, Managing Director
Switch Research Limited

+44 1328 838821
+44 7973 320795

---

From: Kelly Grizzle <[email-masked]>
Date: Wed, 12 Jun 2013 20:07:53 +0000

URI suffixes were initially supported because they are fairly commonly used in REST APIs to denote the response type and are especially useful if a client can't easily set the "Accept" request header.  However, since the -01 draft has dropped support for the XML data format, I would be in favor of dropping this.  Alex, could you please open an issue for this and propose some text changes?  http://tools.ietf.org/wg/scim/

Thanks for the feedback.

--Kelly

From: [email-masked] [mailto:[email-masked]] On Behalf Of Alex Redston
Sent: Wednesday, June 12, 2013 9:55 AM
To: [email-masked]
Subject: [scim] URI suffixes in SCIM

Hello SCIM list

My team are currently implementing SCIM on our platform and have found a curious anomaly which seems to not make any sense. Please accept my apologies if this mater has previously been raised or is part of an old draft.

  *   The SCIM API Draft specification states that "Consumers ... MAY specify the desired response data format via an HTTP Accept Header; e.g.,"Accept: application/json" or via URI suffix; e.g., GET /Users/2819c223-7f76-453a-919d-413861904646.json" (section 3.6 of draft-ietf-scim-api-01)
  *   Although the same section does not state that Service Providers MUST support URI suffixes as an alternative indication of the Consumer's desired response, it is implied
  *   Since the URI suffix appears as part of the resource identifier, before the ? (see RFC3986 section 3.3, "Path"), appending different suffixes effectively implies a different resource, so that 2819c223-7f76-453a-919d-413861904646, 2819c223-7f76-453a-919d-413861904646.xml and 2819c223-7f76-453a-919d-413861904646.json are canonically different. Representation should not be confused with Resource Identification
  *   Use of URI suffixes to indicate content-type is a throwback to filesystem-based web servers which use filename extensions to deduce content-type, which are unlikely to be used to build SCIM implementations, and is thus not relevant to this spec
  *   We would like to motion to have the requirement that "Consumers ... MAY specify the desired response data format ... via URI suffix" be removed from the daft spec.

Thanks

Alex

--

Alex Redston

Switch Research Limited

+44 1328 838821

+44 7973 320795

---

From: Samuel Erdtman <[email-masked]>
Date: Mon, 17 Jun 2013 19:15:33 +0200

+1 to remove it

After Kelly's comment we could remove all text on accept header.

Sent from my iPhone

On 12 jun 2013, at 22:08, Kelly Grizzle <[email-masked]> wrote:

  URI suffixes were initially supported because they are fairly commonly
used in REST APIs to denote the response type and are especially useful if
a client can’t easily set the “Accept” request header.  However, since the
-01 draft has dropped support for the XML data format, I would be in favor
of dropping this.  Alex, could you please open an issue for this and
propose some text changes?  http://tools.ietf.org/wg/scim/

Thanks for the feedback.

--Kelly

*From:* [email-masked]
[mailto:[email-masked]<[email-masked]>]
*On Behalf Of *Alex Redston
*Sent:* Wednesday, June 12, 2013 9:55 AM
*To:* [email-masked]
*Subject:* [scim] URI suffixes in SCIM

Hello SCIM list

   - The SCIM API Draft specification states that "Consumers … MAY specify
   the desired response data format via an HTTP Accept Header; e.g.,"Accept:
   application/json" *or via URI suffix; e.g., GET
   /Users/2819c223-7f76-453a-919d-413861904646.json*" (section 3.6 of
   draft-ietf-scim-api-01)
   - Although the same section does not state that Service Providers MUST
   support URI suffixes as an alternative indication of the Consumer's desired
   response, it is implied
   - Since the URI suffix appears as part of the resource identifier,
   before the ? (see RFC3986 section 3.3, "Path"), appending different
   suffixes effectively implies a different resource, so that *
   2819c223-7f76-453a-919d-413861904646*, *
   2819c223-7f76-453a-919d-413861904646.xml* and *
   2819c223-7f76-453a-919d-413861904646.json* are canonically different. *
   Representation* should not be confused with *Resource Identification*
   - Use of URI suffixes to indicate content-type is a throwback to
   filesystem-based web servers which use filename extensions to deduce
   content-type, which are unlikely to be used to build SCIM implementations,
   and is thus not relevant to this spec
   - We would like to motion to have the requirement that "Consumers … MAY
   specify the desired response data format … via URI suffix" be removed from
   the daft spec.

Thanks

Alex

-- 

Alex Redston

Switch Research Limited

+44 1328 838821

+44 7973 320795

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