From prvs=3049F95DBC=erik.wahlstrom@nexusgroup.com Tue Dec 3 05:19:04 2013 Return-Path: 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 9FB9A1ADEB7 for ; Tue, 3 Dec 2013 05:19:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 fFx-lGitBhjr for ; Tue, 3 Dec 2013 05:19:00 -0800 (PST) Received: from mailedge.nexussafe.com (mailedge.nexussafe.com [83.241.133.98]) by ietfa.amsl.com (Postfix) with ESMTP id 1F2571AE127 for ; Tue, 3 Dec 2013 05:18:59 -0800 (PST) Received: from MARVMAILCAS.technxs.com (10.75.28.37) by MailEdge.nexussafe.com (83.241.133.98) with Microsoft SMTP Server (TLS) id 14.0.722.0; Tue, 3 Dec 2013 14:18:55 +0100 Received: from MARVMAILDB.technxs.com ([fe80::2481:7a28:782a:7fc7]) by MarvMailCAS.technxs.com ([fe80::cd7:3e15:4b14:c076%14]) with mapi id 14.03.0158.001; Tue, 3 Dec 2013 14:18:52 +0100 From: =?Windows-1252?Q?Erik_Wahlstr=F6m?= To: "" Thread-Topic: Some comments after a review of the 02 specs Thread-Index: AQHOv0N57+jTwpU2dkakYMmynuEiCppCxSAA Date: Tue, 3 Dec 2013 13:18:51 +0000 Message-ID: <1E973309-99AA-4ABC-B63B-3B6174E06479@nexussafe.com> References: In-Reply-To: Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.75.28.135] Content-Type: multipart/alternative; boundary="_000_1E97330999AA4ABCB63B3B6174E06479nexussafecom_" MIME-Version: 1.0 Subject: Re: [scim] Some comments after a review of the 02 specs X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 13:19:04 -0000 --_000_1E97330999AA4ABCB63B3B6174E06479nexussafecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I created a ticket regarding "Spec defines "Consumer" but uses the word "cl= ient" through out the spec.=94 http://tools.ietf.org/wg/scim/trac/ticket/5= 3 So, should we call it client instead of Consumer? And Server instead of Ser= vice Provider? I prefer client/server instead of Consumer/Service Provider due to the fact= that we use it all through the code, it feels a bit forced to use Consumer= . And it also conflicts a bit with SAML Service Provider. Any thoughts? / Erik On 02 Oct 2013, at 09:46, Erik Wahlstr=F6m > wrote: After a review of the -02 specs I found a couple of issues that I guess we = need to discuss. I propose adding them all as new issues in the issue track= er of no one objects. ---------------------- In general I think we should add a couple of more examples in our definitio= ns when we talk about example Resources. We always mention User and Group. = That's fine but when we start talking about ServiceProviderConifig and Reso= urceType they come as a surprise and you wonder if they are treated as any = Resource or not. Example: Resource: The Service Provider managed artifact containing one or more attributes; e.g., User or Group Resource: The Service Provider managed artifact containing one or more attributes; e.g., User, Group, ServiceProviderConfig or ResourceT= ype. ---------------------- In the API documentation we never mension the new URIs like urn:scim:schema= s:core:2.0:ListResponse, SearchRequest, Error, BulkRequest, BulkResponse. W= e also mention urn:scim:schemas:core:2.0:name.givenName and that's real att= ributes defined in the core schema for a specific User. ---------------------- In the "3.8 Attribute Notation" section shouln't we also define the core re= source type like User and Group when we refrence name.givenName. Instead of: urn:scim:schemas:core:2.0:name.givenName Have: urn:scim:schemas:core:2.0:User:name.givenName ---------------------- We have some language confusion on a lot of places in the specification. In= our defintions we define that there exists Consumers and Service Providers= . But most of the specification talks about clients and servers. I personal= ly use client and server when I talk about SCIM. Here is a list of where we= say client instead of Consumer. The server equivalent is longer. From: "It is RECOMMENDED that clients be implemented in such a way that new authentication schemes can be deployed. Implementers SHOULD support existing authentication" To: "It is RECOMMENDED that Service Providers and Consumers is implemented in such a way that new aut= hentication schemes can be deployed. Implementers SHOULD support existing authentication" -- From: "To create new Resources, clients send POST requests to the Resource endpoint; i.e., /Users or /Groups." To: "To create new Resources, Consumers send POST requests to the Resource endpoint; i.e., /Users or /Groups." -- From: "Since the server is free to alter and/or ignore POSTed content, returning the full representation can be useful to the client, enabling it to correlate the client and server views of the new Resource. When a Resource is created, its URI must be returned in the response Location header." To: "Since the server is free to alter and/or ignore POSTed content, returning the full representation can be useful to the Consumer, enabling it to correlate the Consumer and Service Provider views of the new Resource. When a Resource is created, = its URI must be returned in the response Location header." -- From: "Below, the client sends a POST request containing a User" To: "Below, the Consumer sends a POST request containing a User." -- From: "To retrieve a known Resource, clients send GET requests to the Resource endpoint; e.g., /Users/{id} or /Groups/{id}." To: "To retrieve a known Resource, Consumers send GET requests to the Resource endpoint; e.g., /Users/{id} or /Groups/{id}." -- From: "Clients MAY execute queries without passing parameters on the URL by using the HTTP POST verb combined with the '/.search' path extension." To: "Consumers MAY execute queries without passing parameters on the URL by using the HTTP POST verb combined with the '/.search' path extension." -- From: "To create a new search result set, a SCIM client sends an HTTP POST request to the desired SCIM resource endpoint (ending in '/.search')." To: "To create a new search result set, a SCIM Consumer sends an HTTP POST request to the desired SCIM resource endpoint (ending in '/.search')." -- From: "In addition to returning a HTTP response code implementers MUST return the errors in the body of the response in the client requested format containing the error response and, per the HTTP specification, human-readable explanations." To: "In addition to returning a HTTP response code implementers MUST return the errors in the body of the response containing the error response and, per the HTTP specificatio= n, human-readable explanations." -- From: "In recognition that some clients, servers and firewalls prevent PUT, PATCH and DELETE operations a client MAY override the POST operation by specifying the custom header "X-HTTP-Method-Override" with the desired PUT, PATCH, DELETE operation." To: "In recognition that some clients, servers and firewalls prevent PUT, PATCH and DELETE operations a Consumer MAY override the POST operation by specifying the custom header "X-HTTP-Method-Override" with the desired PUT, PATCH, DELETE operation." ---------------------- And finaly I agree with Steves earlier comment on the mail list, at least t= he first two suggestions :), regarding section 3.1.5 not beeing up to date.= Steve stated: "Section 3.1.5. (Headed: DateTime) of the SCIM v2 Schema refers to section = 3.2.7 which no longer exists and to the (XML Schema Datatypes Specification= ) which is no longer supported. I'd suggest we refer to the relevant stand= ards in this paragraph and link to RFC3339 - section 5.6 (http://tools.ietf= .org/html/rfc3339#section-5.6), ISO-8601 (http://www.iso.org/iso/catalogue_= detail?csnumber=3D40874) and if humor is tolerated, to Randall Munroe's opi= nion (https://xkcd.com/1179/)." / Erik --_000_1E97330999AA4ABCB63B3B6174E06479nexussafecom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <14DB74F64E37554DA6F124B3C20455C5@nexussafe.com> Content-Transfer-Encoding: quoted-printable
I created a ticket regarding "Spec defines "Consumer" b= ut uses the word "client" through out the spec.=94  http://tools.ietf.org/wg/= scim/trac/ticket/53

So, should we call it client instead of Consumer? And Server instead o= f Service Provider? 

I prefer client/server instead of Consumer/Service Provider due to the= fact that we use it all through the code, it feels a bit forced to use Con= sumer. And it also conflicts a bit with SAML Service Provider.

Any thoughts?

/ Erik


On 02 Oct 2013, at 09:46, Erik Wahlstr=F6m <erik.wahlstrom@nexussafe.com> wrote:

After a review of the -02 specs I found a couple = of issues that I guess we need to discuss. I propose adding them all as new= issues in the issue tracker of no one objects.



----------------------

In general I think we should add a couple of more examples in our definitio= ns when we talk about example Resources. We always mention User and Group. = That's fine but when we start talking about ServiceProviderConifig and Reso= urceType they come as a surprise and you wonder if they are treated as any Resource or not.

Example:

  Resource:  The Service Provider managed artifact containin= g one or
     more attributes; e.g., User or Group

  Resource:  The Service Provider managed artifact containin= g one or
     more attributes; e.g., User, Group, ServicePr= oviderConfig or ResourceType.

----------------------

In the API documentation we never mension the new URIs like urn:scim:schema= s:core:2.0:ListResponse, SearchRequest, Error, BulkRequest, BulkResponse. W= e also mention urn:scim:schemas:core:2.0:name.givenName and that's real att= ributes defined in the core schema for a specific User.


----------------------
In the "3.8 Attribute Notation" section shouln't we also define t= he core resource type like User and Group when we refrence name.givenName.<= br>
Instead of:
urn:scim:schemas:core:2.0:name.givenName
Have:
urn:scim:schemas:core:2.0:User:name.givenName

----------------------

We have some language confusion on a lot of places in the specification. In= our defintions we define that there exists Consumers and Service Providers= . But most of the specification talks about clients and servers. I personal= ly use client and server when I talk about SCIM. Here is a list of where we say client instead of Consumer= . The server equivalent is longer.

From:
  "It is RECOMMENDED that
  clients be implemented in such a way that new authentication sc= hemes
  can be deployed.  Implementers SHOULD support existing aut= hentication"
To:
  "It is RECOMMENDED that
  Service Providers and Consumers is implemented in such a way th= at new authentication schemes
  can be deployed.  Implementers SHOULD support existing aut= hentication"

--   

From:
  "To create new Resources, clients send POST requests to th= e Resource
  endpoint; i.e., /Users or /Groups."

To:
  "To create new Resources, Consumers send POST requests to = the Resource
  endpoint; i.e., /Users or /Groups."

--   

From:
  "Since the server is free to
  alter and/or ignore POSTed content, returning the full represen= tation
  can be useful to the client, enabling it to correlate the clien= t and
  server views of the new Resource.  When a Resource is crea= ted, its
  URI must be returned in the response Location header."
To:
  "Since the server is free to
  alter and/or ignore POSTed content, returning the full represen= tation
  can be useful to the Consumer, enabling it to correlate the Con= sumer and
  Service Provider views of the new Resource.  When a Resour= ce is created, its
  URI must be returned in the response Location header."

--

From:
  "Below, the client sends a POST request containing a User&= quot;
To:
  "Below, the Consumer sends a POST request containing a Use= r."

--

From:
  "To retrieve a known Resource, clients send GET requests t= o the
  Resource endpoint; e.g., /Users/{id} or /Groups/{id}."

To:   
  "To retrieve a known Resource, Consumers send GET requests= to the
  Resource endpoint; e.g., /Users/{id} or /Groups/{id}."

--

From:
  "Clients MAY execute queries without passing parameters on= the URL by
  using the HTTP POST verb combined with the '/.search' path exte= nsion."

To:
  "Consumers MAY execute queries without passing parameters = on the URL by
  using the HTTP POST verb combined with the '/.search' path exte= nsion."

--

From:
  "To create a new search result set, a SCIM client sends an= HTTP POST
  request to the desired SCIM resource endpoint (ending in '/.sea= rch')."
To:
  "To create a new search result set, a SCIM Consumer sends = an HTTP POST
  request to the desired SCIM resource endpoint (ending in '/.sea= rch')."

--

From:
  "In addition to returning a
  HTTP response code implementers MUST return the errors in the b= ody of
  the response in the client requested format containing the erro= r
  response and, per the HTTP specification, human-readable
  explanations."
To:
  "In addition to returning a
  HTTP response code implementers MUST return the errors in the b= ody of
  the response containing the error response and, per the HTTP sp= ecification, human-readable
  explanations."

--

From:
  "In recognition that some clients, servers and firewalls p= revent PUT,
  PATCH and DELETE operations a client MAY override the POST oper= ation
  by specifying the custom header "X-HTTP-Method-Override&qu= ot; with the
  desired PUT, PATCH, DELETE operation."
To:
  "In recognition that some clients, servers and firewalls p= revent PUT,
  PATCH and DELETE operations a Consumer MAY override the POST op= eration
  by specifying the custom header "X-HTTP-Method-Override&qu= ot; with the
  desired PUT, PATCH, DELETE operation."

----------------------

And finaly I agree with Steves earlier comment on the mail list, at least t= he first two suggestions :), regarding section 3.1.5 not beeing up to date.= Steve stated:

"Section 3.1.5. (Headed: DateTime) of the SCIM v2 Schema refers to sec= tion 3.2.7 which no longer exists and to the (XML Schema Datatypes Specific= ation) which is no longer supported.  I'd suggest we refer to the rele= vant standards in this paragraph and link to RFC3339 - section 5.6 (http://tools.ietf.org/html/rfc3339#section-5.6), ISO-8601 (<= a href=3D"http://www.iso.org/iso/catalogue_detail?csnumber=3D40874">http://= www.iso.org/iso/catalogue_detail?csnumber=3D40874) and if humor is tolerated, to Randall Munroe's opinion (https://xkcd.com/1179/)."


/ Erik

--_000_1E97330999AA4ABCB63B3B6174E06479nexussafecom_-- From prvs=6049AE931B=erik.wahlstrom@nexusgroup.com Tue Dec 3 05:32:06 2013 Return-Path: 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 8F7321AE114 for ; Tue, 3 Dec 2013 05:32:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 mmlNuF_vkuN8 for ; Tue, 3 Dec 2013 05:32:04 -0800 (PST) Received: from mailedge.nexussafe.com (mailedge.nexussafe.com [83.241.133.98]) by ietfa.amsl.com (Postfix) with ESMTP id C3D501AE107 for ; Tue, 3 Dec 2013 05:32:03 -0800 (PST) Received: from MARVMAILCAS.technxs.com (10.75.28.37) by MailEdge.nexussafe.com (83.241.133.98) with Microsoft SMTP Server (TLS) id 14.0.722.0; Tue, 3 Dec 2013 14:32:02 +0100 Received: from MARVMAILDB.technxs.com ([fe80::2481:7a28:782a:7fc7]) by MarvMailCAS.technxs.com ([fe80::cd7:3e15:4b14:c076%14]) with mapi id 14.03.0158.001; Tue, 3 Dec 2013 14:32:00 +0100 From: =?Windows-1252?Q?Erik_Wahlstr=F6m?= To: Shelley Thread-Topic: [scim] Clarification on body request for DELETE Thread-Index: AQHORrBXpd/Pk14cuUODIxLJUT71pppDufOA Date: Tue, 3 Dec 2013 13:31:59 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.75.28.135] Content-Type: multipart/alternative; boundary="_000_FC869C5C8D77457689A0A10C42811D0Anexussafecom_" MIME-Version: 1.0 Cc: "scim@ietf.org" Subject: Re: [scim] Clarification on body request for DELETE X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 13:32:06 -0000 --_000_FC869C5C8D77457689A0A10C42811D0Anexussafecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Well, it=92s thing compared to my late reply :) http://trac.tools.ietf.org/wg/scim/trac/ticket/39 The ticket #39 talks about this. I=92ve had a small chat with Alexandre who= registered that ticket. He said that both 200 with a text saying body shou= ld be empty and 204 worked, but he preferred 200. I kinda prefer a 204. It=92s more in line with HTTP spec, but it is a break= ing change so we should really think it through. Any thoughts? 200 och 204. / Erik On 01 May 2013, at 23:10, Shelley > wrote: Apologies for the delayed reply to this thread regarding the DELETE respons= e [1], but +1 to returning a 204. [1] http://www.ietf.org/mail-archive/web/scim/current/msg00980.html On Wed, Mar 27, 2013 at 1:10 PM, > wrote: ---------- Forwarded message ---------- From: Kelly Grizzle > To: Alexandre Santos >, "scim@ietf.org" > Cc: Date: Wed, 27 Mar 2013 18:10:28 +0000 Subject: Re: [scim] Clarification on body request for DELETE The SCIM API spec is not entirely clear here. According to RFC 2616, the D= ELETE operation should work like this: A successful response SHOULD be 200 (OK) if the response includes an entity describing the status, 202 (Accepted) if the action has not yet been enacted, or 204 (No Content) if the action has been enacted but the response does not include an entity. I can=92t think of anything interesting for SCIM to return in a response bo= dy, so my vote would either be a 200 with an empty response (or just a mess= age) or a 204 with no response body. Perhaps we should open an issue to cl= arify this. Thoughts? --Kelly _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim --_000_FC869C5C8D77457689A0A10C42811D0Anexussafecom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Well, it=92s thing compared to my late reply :)

The ticket #39 talks about this. I=92ve had a small chat with Ale= xandre who registered that ticket. He said that both 200 with a text saying= body should be empty and 204 worked, but he preferred 200.

I kinda prefer a 204. It=92s more in line with HTTP spec, but it is a = breaking change so we should really think it through.

Any thoughts? 200 och 204.

/ Erik


On 01 May 2013, at 23:10, Shelley <randomshelley@gmail.com> wrote:

Apologies for the delayed reply to this thread regarding t= he DELETE response [1], but +1 to returning a 204.

[1] http://www.ietf.org/mail-archive/web/scim/current/msg00980.html


On Wed, Mar 27, 2013 at 1:10 PM, <scim-requ= est@ietf.org> wrote:
---------- Forwarded message ----------
From: Kelly Grizzle <kelly.grizzle@sailpoint.com>
To: Alexandre Santos <a= santos@pingidentity.com>, "sci= m@ietf.org" <scim@ietf.org= >
Cc: 
Date: Wed, 27 Mar 2013 18:10:28 +0000
Subject: Re: [scim] Clarification on body request for DELETE

The SCIM API spec is not = entirely clear here.  According to RFC 2616, the DELETE operation shou= ld work like this:

 

   A successful response SHOULD be 200 (OK) if t= he response includes an

   entity describing the status, 202 (Accepted) = if the action has not

   yet been enacted, or 204 (No Content) if the = action has been enacted

   but the response does not include an entity.<= u>

 

I can=92t think of anythi= ng interesting for SCIM to return in a response body, so my vote would eith= er be a 200 with an empty response (or just a message) or a 204 with no response body.  Perhaps we should open an issue to clar= ify this.  Thoughts?

 

--Kelly



_______________________________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim

--_000_FC869C5C8D77457689A0A10C42811D0Anexussafecom_-- From michael.hammer@yaanatech.com Tue Dec 3 06:17:09 2013 Return-Path: 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 E331B1AD7C0 for ; Tue, 3 Dec 2013 06:17:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 E4-SECj8yLpX for ; Tue, 3 Dec 2013 06:17:03 -0800 (PST) Received: from email1.corp.yaanatech.com (webmail10.yaanatech.com [63.128.177.10]) by ietfa.amsl.com (Postfix) with ESMTP id A34E11ADF0F for ; Tue, 3 Dec 2013 06:17:03 -0800 (PST) Received: from SC9-EX2K10MB1.corp.yaanatech.com ([fe80::149d:c2e1:8065:2a47]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Tue, 3 Dec 2013 06:17:00 -0800 From: Michael Hammer To: "erik.wahlstrom@nexusgroup.com" , "scim@ietf.org" Thread-Topic: Some comments after a review of the 02 specs Thread-Index: AQHOv0N57+jTwpU2dkakYMmynuEiCppCxSAAgAAgKKA= Date: Tue, 3 Dec 2013 14:16:59 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBF00765@sc9-ex2k10mb1.corp.yaanatech.com> References: <1E973309-99AA-4ABC-B63B-3B6174E06479@nexussafe.com> In-Reply-To: <1E973309-99AA-4ABC-B63B-3B6174E06479@nexussafe.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.14] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0009_01CEF008.6A904F10" MIME-Version: 1.0 Subject: Re: [scim] Some comments after a review of the 02 specs X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 14:17:10 -0000 ------=_NextPart_000_0009_01CEF008.6A904F10 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000A_01CEF008.6A904F10" ------=_NextPart_001_000A_01CEF008.6A904F10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If we are talking about a protocol and not some vague business process, = I agree. =20 Mike =20 =20 From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Erik Wahlstr=F6m Sent: Tuesday, December 03, 2013 8:19 AM To: Subject: Re: [scim] Some comments after a review of the 02 specs =20 I created a ticket regarding "Spec defines "Consumer" but uses the word "client" through out the spec.=94 http://tools.ietf.org/wg/scim/trac/ticket/53 =20 So, should we call it client instead of Consumer? And Server instead of Service Provider?=20 =20 I prefer client/server instead of Consumer/Service Provider due to the = fact that we use it all through the code, it feels a bit forced to use = Consumer. And it also conflicts a bit with SAML Service Provider. =20 Any thoughts? =20 / Erik =20 =20 On 02 Oct 2013, at 09:46, Erik Wahlstr=F6m = wrote: After a review of the -02 specs I found a couple of issues that I guess = we need to discuss. I propose adding them all as new issues in the issue tracker of no one objects. ---------------------- In general I think we should add a couple of more examples in our definitions when we talk about example Resources. We always mention User = and Group. That's fine but when we start talking about = ServiceProviderConifig and ResourceType they come as a surprise and you wonder if they are = treated as any Resource or not. Example: Resource: The Service Provider managed artifact containing one or more attributes; e.g., User or Group Resource: The Service Provider managed artifact containing one or more attributes; e.g., User, Group, ServiceProviderConfig or ResourceType. ---------------------- In the API documentation we never mension the new URIs like urn:scim:schemas:core:2.0:ListResponse, SearchRequest, Error, = BulkRequest, BulkResponse. We also mention urn:scim:schemas:core:2.0:name.givenName = and that's real attributes defined in the core schema for a specific User.=20 ---------------------- In the "3.8 Attribute Notation" section shouln't we also define the core resource type like User and Group when we refrence name.givenName. Instead of: urn:scim:schemas:core:2.0:name.givenName Have: urn:scim:schemas:core:2.0:User:name.givenName ---------------------- We have some language confusion on a lot of places in the specification. = In our defintions we define that there exists Consumers and Service = Providers. But most of the specification talks about clients and servers. I = personally use client and server when I talk about SCIM. Here is a list of where we = say client instead of Consumer. The server equivalent is longer. From: "It is RECOMMENDED that clients be implemented in such a way that new authentication schemes can be deployed. Implementers SHOULD support existing authentication" To: "It is RECOMMENDED that Service Providers and Consumers is implemented in such a way that new authentication schemes can be deployed. Implementers SHOULD support existing authentication" -- =20 From: "To create new Resources, clients send POST requests to the Resource endpoint; i.e., /Users or /Groups." To: "To create new Resources, Consumers send POST requests to the Resource endpoint; i.e., /Users or /Groups." -- =20 From: "Since the server is free to alter and/or ignore POSTed content, returning the full representation can be useful to the client, enabling it to correlate the client and server views of the new Resource. When a Resource is created, its URI must be returned in the response Location header." To: "Since the server is free to alter and/or ignore POSTed content, returning the full representation can be useful to the Consumer, enabling it to correlate the Consumer = and Service Provider views of the new Resource. When a Resource is = created, its URI must be returned in the response Location header." -- From: "Below, the client sends a POST request containing a User" To: "Below, the Consumer sends a POST request containing a User." -- From: "To retrieve a known Resource, clients send GET requests to the Resource endpoint; e.g., /Users/{id} or /Groups/{id}." To: =20 "To retrieve a known Resource, Consumers send GET requests to the Resource endpoint; e.g., /Users/{id} or /Groups/{id}." -- From: "Clients MAY execute queries without passing parameters on the URL by using the HTTP POST verb combined with the '/.search' path extension." To: "Consumers MAY execute queries without passing parameters on the URL = by using the HTTP POST verb combined with the '/.search' path extension." --=20 From: "To create a new search result set, a SCIM client sends an HTTP POST request to the desired SCIM resource endpoint (ending in '/.search')." To: "To create a new search result set, a SCIM Consumer sends an HTTP POST request to the desired SCIM resource endpoint (ending in '/.search')." --=20 From: "In addition to returning a HTTP response code implementers MUST return the errors in the body of the response in the client requested format containing the error response and, per the HTTP specification, human-readable explanations." To: "In addition to returning a HTTP response code implementers MUST return the errors in the body of the response containing the error response and, per the HTTP specification, human-readable explanations." -- From: "In recognition that some clients, servers and firewalls prevent PUT, PATCH and DELETE operations a client MAY override the POST operation by specifying the custom header "X-HTTP-Method-Override" with the desired PUT, PATCH, DELETE operation." To: "In recognition that some clients, servers and firewalls prevent PUT, PATCH and DELETE operations a Consumer MAY override the POST operation by specifying the custom header "X-HTTP-Method-Override" with the desired PUT, PATCH, DELETE operation." ---------------------- And finaly I agree with Steves earlier comment on the mail list, at = least the first two suggestions :), regarding section 3.1.5 not beeing up to = date. Steve stated: "Section 3.1.5. (Headed: DateTime) of the SCIM v2 Schema refers to = section 3.2.7 which no longer exists and to the (XML Schema Datatypes = Specification) which is no longer supported. I'd suggest we refer to the relevant standards in this paragraph and link to RFC3339 - section 5.6 (http://tools.ietf.org/html/rfc3339#section-5.6), ISO-8601 (http://www.iso.org/iso/catalogue_detail?csnumber=3D40874) and if humor = is tolerated, to Randall Munroe's opinion (https://xkcd.com/1179/)." / Erik =20 ------=_NextPart_001_000A_01CEF008.6A904F10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

If we are talking about a protocol and not some vague business = process, I agree.

 

Mike

 

 

From:= = scim [mailto:scim-bounces@ietf.org] On Behalf Of Erik = Wahlstr=F6m
Sent: Tuesday, December 03, 2013 8:19 = AM
To: <scim@ietf.org>
Subject: Re: [scim] = Some comments after a review of the 02 = specs

 

I = created a ticket regarding "Spec defines "Consumer" but = uses the word "client" through out the spec.”  http://tools.ietf.o= rg/wg/scim/trac/ticket/53

 

So, should we call it client instead of Consumer? And = Server instead of Service Provider? 

 

I = prefer client/server instead of Consumer/Service Provider due to the = fact that we use it all through the code, it feels a bit forced to use = Consumer. And it also conflicts a bit with SAML Service = Provider.

 

Any thoughts?

 

/ = Erik

 

 

On = 02 Oct 2013, at 09:46, Erik Wahlstr=F6m <erik.wahlstrom@nexussafe.com= > wrote:



After a = review of the -02 specs I found a couple of issues that I guess we need = to discuss. I propose adding them all as new issues in the issue tracker = of no one objects.



----------------------

In = general I think we should add a couple of more examples in our = definitions when we talk about example Resources. We always mention User = and Group. That's fine but when we start talking about = ServiceProviderConifig and ResourceType they come as a surprise and you = wonder if they are treated as any Resource or = not.

Example:

  Resource:  The Service = Provider managed artifact containing one = or
     more attributes; e.g., User or = Group

  Resource:  The Service Provider managed = artifact containing one or
     more = attributes; e.g., User, Group, ServiceProviderConfig or = ResourceType.

----------------------

In the API = documentation we never mension the new URIs like = urn:scim:schemas:core:2.0:ListResponse, SearchRequest, Error, = BulkRequest, BulkResponse. We also mention = urn:scim:schemas:core:2.0:name.givenName and that's real attributes = defined in the core schema for a specific User. =


----------------------
In the "3.8 Attribute = Notation" section shouln't we also define the core resource type = like User and Group when we refrence name.givenName.

Instead = of:
urn:scim:schemas:core:2.0:name.givenName
Have:
urn:scim:sche= mas:core:2.0:User:name.givenName

----------------------

We = have some language confusion on a lot of places in the specification. In = our defintions we define that there exists Consumers and Service = Providers. But most of the specification talks about clients and = servers. I personally use client and server when I talk about SCIM. Here = is a list of where we say client instead of Consumer. The server = equivalent is longer.

From:
  "It is = RECOMMENDED that
  clients be implemented in such a way = that new authentication schemes
  can be deployed. =  Implementers SHOULD support existing = authentication"
To:
  "It is RECOMMENDED = that
  Service Providers and Consumers is implemented in = such a way that new authentication schemes
  can be = deployed.  Implementers SHOULD support existing = authentication"

-- =   

From:
  "To create new Resources, = clients send POST requests to the Resource
  endpoint; = i.e., /Users or /Groups."

To:
  "To create = new Resources, Consumers send POST requests to the = Resource
  endpoint; i.e., /Users or = /Groups."

-- =   

From:
  "Since the server is free = to
  alter and/or ignore POSTed content, returning the full = representation
  can be useful to the client, enabling it = to correlate the client and
  server views of the new = Resource.  When a Resource is created, its
  URI must = be returned in the response Location = header."
To:
  "Since the server is free = to
  alter and/or ignore POSTed content, returning the full = representation
  can be useful to the Consumer, enabling it = to correlate the Consumer and
  Service Provider views of = the new Resource.  When a Resource is created, = its
  URI must be returned in the response Location = header."

--

From:
  "Below, the = client sends a POST request containing a = User"
To:
  "Below, the Consumer sends a POST = request containing a = User."

--

From:
  "To retrieve a = known Resource, clients send GET requests to the
  Resource = endpoint; e.g., /Users/{id} or /Groups/{id}."

To: =   
  "To retrieve a known Resource, = Consumers send GET requests to the
  Resource endpoint; = e.g., /Users/{id} or = /Groups/{id}."

--

From:
  "Clients = MAY execute queries without passing parameters on the URL = by
  using the HTTP POST verb combined with the '/.search' = path extension."

To:
  "Consumers MAY = execute queries without passing parameters on the URL = by
  using the HTTP POST verb combined with the '/.search' = path extension."

--

From:
  "To = create a new search result set, a SCIM client sends an HTTP = POST
  request to the desired SCIM resource endpoint = (ending in '/.search')."
To:
  "To create a = new search result set, a SCIM Consumer sends an HTTP = POST
  request to the desired SCIM resource endpoint = (ending in '/.search')."

-- =

From:
  "In addition to returning = a
  HTTP response code implementers MUST return the errors = in the body of
  the response in the client requested = format containing the error
  response and, per the HTTP = specification, = human-readable
  explanations."
To:
  &= quot;In addition to returning a
  HTTP response code = implementers MUST return the errors in the body of
  the = response containing the error response and, per the HTTP specification, = human-readable
  explanations."

--

From:<= br>  "In recognition that some clients, servers and = firewalls prevent PUT,
  PATCH and DELETE operations a = client MAY override the POST operation
  by specifying the = custom header "X-HTTP-Method-Override" with = the
  desired PUT, PATCH, DELETE = operation."
To:
  "In recognition that some = clients, servers and firewalls prevent PUT,
  PATCH and = DELETE operations a Consumer MAY override the POST = operation
  by specifying the custom header = "X-HTTP-Method-Override" with the
  desired PUT, = PATCH, DELETE operation."

----------------------

And = finaly I agree with Steves earlier comment on the mail list, at least = the first two suggestions :), regarding section 3.1.5 not beeing up to = date. Steve stated:

"Section 3.1.5. (Headed: DateTime) of = the SCIM v2 Schema refers to section 3.2.7 which no longer exists and to = the (XML Schema Datatypes Specification) which is no longer supported. =  I'd suggest we refer to the relevant standards in this paragraph = and link to RFC3339 - section 5.6 (http://tools.ietf= .org/html/rfc3339#section-5.6), ISO-8601 (http://= www.iso.org/iso/catalogue_detail?csnumber=3D40874) and if humor is = tolerated, to Randall Munroe's opinion (https://xkcd.com/1179/)."

/ Erik

 

------=_NextPart_001_000A_01CEF008.6A904F10-- ------=_NextPart_000_0009_01CEF008.6A904F10 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMTIw MzE0MTY1N1owIwYJKoZIhvcNAQkEMRYEFEIRKDSdgyAYWJic4qEI0XWrTNVjMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAPCITBXhmWqe4nBqmJDq5t11d4L8y4A4KPDIH+wXJ HkW65kmZnC6a/RTZqO/unc1NtuQ5Yfd/k9Ywd+Qn8K3WZeIX6DfJLk3iTggvOTRiizglF1RWPHBV xyoWDlXLaxAJNKG54qnQO82v3fWB1JlV2zorSraW0Q4stPtM65BGXmBMXy3oiEJW6IikRsdwb0uR 64yYIfqqHn6LxKBPTkoSAfKP8/0pNe4XimPi8UEn3yVlZByBh28SNB/MtZeSURjAu35f3DHjtxKs Ou5DmK7fbleEohAlu/wulWMZSIZkhRzZhy+FniRTrKkc+i6l4bphGV1x2+VXZ3dcY2mQCD1ECwAA AAAAAA== ------=_NextPart_000_0009_01CEF008.6A904F10-- From randomshelley@gmail.com Tue Dec 3 06:31:23 2013 Return-Path: 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 4A1021ADFB4 for ; Tue, 3 Dec 2013 06:31:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 Lx0GETh7ZKd0 for ; Tue, 3 Dec 2013 06:31:21 -0800 (PST) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE1F1AD9AB for ; Tue, 3 Dec 2013 06:31:21 -0800 (PST) Received: by mail-ie0-f176.google.com with SMTP id at1so22899794iec.7 for ; Tue, 03 Dec 2013 06:31:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rvLd3Z507lRPXfKurgKaB7U6rQpnCjQeF121cfKPdDc=; b=vUSfxRcCDhhks9XTFlqx3W7KwO4ubr0J+a0jgrXou77H5NOqcSK0ov5vx9Dj+N3CPg +A8tyrkIDrwVwH877fcB145+Z/VfB3pZs1nePfc5hzZJJsYicC8GHWNC467Nm+wPqoc7 EuH0ak/jicoAqAgOkEPOcdrLYo9kbrQBYsGoTPxTt7dY8gPvrsPIiGdL4w+fqRXRqnrW KRXbwsMEsul+YdaMJmKpcZGLg/txn/scDnqIvCKQJ4bDHMhqQoECVqEny169z9Ebzgfx WO7xy23syznZyL36BurKJKp6P2YAu/5IQEwmeYfssdpKoeqjblnRl6dGo/XSs5xayEMX sicw== MIME-Version: 1.0 X-Received: by 10.43.93.5 with SMTP id bs5mr747985icc.78.1386081078474; Tue, 03 Dec 2013 06:31:18 -0800 (PST) Received: by 10.64.61.170 with HTTP; Tue, 3 Dec 2013 06:31:18 -0800 (PST) In-Reply-To: References: Date: Tue, 3 Dec 2013 08:31:18 -0600 Message-ID: From: Shelley To: =?ISO-8859-1?Q?Erik_Wahlstr=F6m?= Content-Type: multipart/alternative; boundary=bcaec519691d4ffc2204eca2263f Cc: "scim@ietf.org" Subject: Re: [scim] Clarification on body request for DELETE X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 14:31:23 -0000 --bcaec519691d4ffc2204eca2263f Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 204 does seem more inline with the HTTP spec. What value would a message body provide in this scenario? Either way may be a breaking change since the SCIM spec isn't entirely prescriptive about the DELETE response. For what it's worth, we are currently returning 204 in our 1.1 SP implementation. On Tue, Dec 3, 2013 at 7:31 AM, Erik Wahlstr=F6m < erik.wahlstrom@nexusgroup.com> wrote: > Well, it=92s thing compared to my late reply :) > > http://trac.tools.ietf.org/wg/scim/trac/ticket/39 > The ticket #39 talks about this. I=92ve had a small chat with Alexandre w= ho > registered that ticket. He said that both 200 with a text saying body > should be empty and 204 worked, but he preferred 200. > > I kinda prefer a 204. It=92s more in line with HTTP spec, but it is a > breaking change so we should really think it through. > > Any thoughts? 200 och 204. > > / Erik > > > On 01 May 2013, at 23:10, Shelley wrote: > > Apologies for the delayed reply to this thread regarding the DELETE > response [1], but +1 to returning a 204. > > [1] http://www.ietf.org/mail-archive/web/scim/current/msg00980.html > > > On Wed, Mar 27, 2013 at 1:10 PM, wrote: > >> ---------- Forwarded message ---------- >> From: Kelly Grizzle >> To: Alexandre Santos , "scim@ietf.org" < >> scim@ietf.org> >> Cc: >> Date: Wed, 27 Mar 2013 18:10:28 +0000 >> Subject: Re: [scim] Clarification on body request for DELETE >> >> The SCIM API spec is not entirely clear here. According to RFC 2616, th= e >> DELETE operation should work like this: >> >> >> >> A successful response SHOULD be 200 (OK) if the response includes an >> >> entity describing the status, 202 (Accepted) if the action has not >> >> yet been enacted, or 204 (No Content) if the action has been enacted >> >> but the response does not include an entity. >> >> >> >> I can=92t think of anything interesting for SCIM to return in a response >> body, so my vote would either be a 200 with an empty response (or just a >> message) or a 204 with no response body. Perhaps we should open an issu= e >> to clarify this. Thoughts? >> >> >> >> --Kelly >> >> > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > > --bcaec519691d4ffc2204eca2263f Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
204 does seem more inline with the HTTP spec. What va= lue would a message body provide in this scenario? Either way may be a brea= king change since the SCIM spec isn't entirely prescriptive about the D= ELETE response. For what it's worth, we are currently returning 204 in = our 1.1 SP implementation.



On Tue, Dec 3, 2013 at 7:31 AM, Erik Wahlstr=F6m <<= a href=3D"mailto:erik.wahlstrom@nexusgroup.com" target=3D"_blank">erik.wahl= strom@nexusgroup.com> wrote:
Well, it=92s thing compared to my late reply :)

The ticket #39 talks about this. I=92ve had a small chat with=A0Alexan= dre who registered that ticket. He said that both 200 with a text saying bo= dy should be empty and 204 worked, but he preferred 200.

I kinda prefer a 204. It=92s more in line with HTTP spec, but it is a = breaking change so we should really think it through.

Any thoughts? 200 och 204.

/ Erik


On 01 May 2013, at 23:10, Shelley <randomshelley@gmail.com> wrote:

Apologies for the delayed reply to this thread regarding t= he DELETE response [1], but +1 to returning a 204.

[1] http://www.ietf.org/mail-archive/web/scim/current/ms= g00980.html


On Wed, Mar 27, 2013 at 1:10 PM, <scim-requ= est@ietf.org> wrote:
---------- Forwarded message ----------
From:=A0Kelly Grizzle <kelly.grizzle@sailpoint.com>
To:=A0Alexandre Santos <asantos@pingidentity.com>, "scim@ietf.org" <scim@ietf.org>
Cc:=A0
Date:=A0Wed, 27 Mar 2013 18:10:28 +0000
Subject:=A0Re: [scim] Clarification on body request for DELETE

The SCIM API spec is not = entirely clear here.=A0 According to RFC 2616, the DELETE operation should = work like this:

=A0<= /p>

=A0=A0 A successful response SHOULD be 200 (OK) if the res= ponse includes an

=A0=A0 entity describing the status, 202 (Accepted) if the= action has not

=A0=A0 yet been enacted, or 204 (No Content) if the action= has been enacted

=A0=A0 but the response does not include an entity.=

=A0<= /p>

I can=92t think of anythi= ng interesting for SCIM to return in a response body, so my vote would eith= er be a 200 with an empty response (or just a message) or a 204 with no response body.=A0 Perhaps we should open an issue to clarify= this.=A0 Thoughts?

=A0<= /p>

--Kelly



_______________________________________________
scim mailing list
scim@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/scim


--bcaec519691d4ffc2204eca2263f-- From d.moebius@tarent.de Tue Dec 3 06:51:16 2013 Return-Path: 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 A65311AE15B for ; Tue, 3 Dec 2013 06:51:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 enkscP_7grxG for ; Tue, 3 Dec 2013 06:51:14 -0800 (PST) Received: from mail-pb0-f72.google.com (mail-pb0-f72.google.com [209.85.160.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1703B1AE157 for ; Tue, 3 Dec 2013 06:51:07 -0800 (PST) Received: by mail-pb0-f72.google.com with SMTP id jt11so38646747pbb.3 for ; Tue, 03 Dec 2013 06:51:05 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=IctYj1T7dIF4q+eDe95hG0Y6ZSMp4SjD+niwB5hqReA=; b=mxeqlwf+g8nEoxdzbd2oCAZxHLppglrKDPqLVxLZMB6qPLYazNZPsWnLOOs/yWhx4/ aPNvHnUg38ylnsvm65SmHybgoFE7DyxKGz+ilinfFQCPlsA8CGThXMPok7R1eMF6cI+e VgvH0e4o5n2UHbaMC80NJBW+v7HQj8zfvCF6G+mqGthqq2Yi2HO8yVBY8nKwoBSw0KO/ bXtng82Z629xtQPM5JAIVcZj0H0O+VTC7kT0b5nN/UfTS79Fckrw+eqAsBWp/yllMXYa 4TBvWV+d1kS7FDiS2jMgrqPWeX5wYcyhZj+kUbAPeldXogs9/m8UYAvNLu1PxCmLr3G8 b5VA== X-Gm-Message-State: ALoCoQmNeGV2Irm83SU1HT/jTPojh79RAVopgJpmm+Uu0Gq8AHk++CYGeSqhRADh9YDGHO/6i4yN MIME-Version: 1.0 X-Received: by 10.66.140.40 with SMTP id rd8mr55946219pab.119.1386082265111; Tue, 03 Dec 2013 06:51:05 -0800 (PST) Received: by 10.66.67.41 with HTTP; Tue, 3 Dec 2013 06:51:05 -0800 (PST) Date: Tue, 3 Dec 2013 15:51:05 +0100 Message-ID: From: David Moebius To: scim@ietf.org Content-Type: multipart/alternative; boundary=001a11331cb20ab12004eca26d13 Subject: [scim] can a User address be primary X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 14:52:40 -0000 --001a11331cb20ab12004eca26d13 Content-Type: text/plain; charset=ISO-8859-1 Hello, in the document http://tools.ietf.org/html/draft-ietf-scim-core-schema-02 at point *http://tools.ietf.org/html/draft-ietf-scim-core-schema-02#section-12.2 * *you can find an example that a address can be primary* addresses": [ { "type": "work", "streetAddress": "100 Universal City Plaza", "locality": "Hollywood", "region": "CA", "postalCode": "91608", "country": "USA", "formatted": "100 Universal City Plaza\nHollywood, CA 91608 USA", "primary": true }, at the point http://tools.ietf.org/html/draft-ietf-scim-core-schema-02#section-12.7 "name":"addresses", "type":"complex", "multiValued":true, "description":"A physical mailing address for this User, as described in (address Element). Canonical Type Values of work, home, and other. The value attribute is a complex type with the following sub-attributes.", Mortimore, et al. Expires March 03, 2014 [Page 31] Internet-Draft draft-scim-core-schema-02 August 2013 "readOnly":false, "required":false, "caseExact":false, "subAttributes":[ { "name":"formatted" ... it looks like that address should not have the field primary. Since it makes sence for me I would think that it is ok if a address is primary. Can you conform this? by David --001a11331cb20ab12004eca26d13 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello,

at point=A0
http://tools.ietf.o=
rg/html/draft-ietf-scim-core-schema-02#section-12.2
=



you can find an example that a address can be primary
=


a=
ddresses": [
       {
         "type": "work",
         "streetAddress": "100 Universal City Plaza",
         "locality": "Hollywood",
         "region": "CA",
         "postalCode": "91608",
         "country": "USA",
         "formatted": "100 Universal City Plaza\nHollywood, =
CA 91608 USA",
         "primary": true
       },

at the point http://tools.ietf.org/html/draft-ietf-scim-core-schema-02#section-12.7


"name":"addresses",
          "type":"complex",
          "multiValued":true,
          "description":"A physical mailing address for this=
 User, as described in (address Element). Canonical Type Values of work, ho=
me, and other. The value attribute is a complex type with the following sub=
-attributes.",



Mortimore, et al.        Expires March 03, 2014           =
     [Page 31]

 
Internet-Draft          draft-scim-core-schema-02            Aug=
ust 2013


          "readOnly":false,
          "required":false,
          "caseExact":false,
          "subAttributes":[
            {
              "name":"formatted"
.=
..
it looks like that address should not have th=
e field primary.
Since it makes sence for me I would t=
hink that it is ok if a address is primary. 



Can you conform this?

by David
--001a11331cb20ab12004eca26d13-- From prvs=50495BD681=erik.wahlstrom@nexusgroup.com Tue Dec 3 08:42:51 2013 Return-Path: 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 81AA51AE018 for ; Tue, 3 Dec 2013 08:42:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 MDQRKtvlz92m for ; Tue, 3 Dec 2013 08:42:49 -0800 (PST) Received: from mailedge.nexussafe.com (mailedge.nexussafe.com [83.241.133.98]) by ietfa.amsl.com (Postfix) with ESMTP id EE70C1ABD2A for ; Tue, 3 Dec 2013 08:42:48 -0800 (PST) Received: from MARVMAILCAS.technxs.com (10.75.28.37) by MailEdge.nexussafe.com (83.241.133.98) with Microsoft SMTP Server (TLS) id 14.0.722.0; Tue, 3 Dec 2013 17:42:46 +0100 Received: from MARVMAILDB.technxs.com ([fe80::2481:7a28:782a:7fc7]) by MarvMailCAS.technxs.com ([fe80::cd7:3e15:4b14:c076%14]) with mapi id 14.03.0158.001; Tue, 3 Dec 2013 17:42:44 +0100 From: =?iso-8859-1?Q?Erik_Wahlstr=F6m?= To: David Moebius , "scim@ietf.org" Thread-Topic: [scim] can a User address be primary Thread-Index: AQHO8DdR1Hj03obm3Eu7Cvh3FvUuQZpCqxHl Date: Tue, 3 Dec 2013 16:42:43 +0000 Message-ID: <50748E7D83B48349962C98013ACEC1690116800FDC@MarvMailDB.technxs.com> References: In-Reply-To: Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.75.28.12] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [scim] can a User address be primary X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 16:42:51 -0000 Hi, Yes, it can be primary. Its a multivalue attribute and one of the upsides = of that is that you get an primary attribute automatically. / Erik ________________________________________ From: scim [scim-bounces@ietf.org] on behalf of David Moebius [d.moebius@ta= rent.de] Sent: Tuesday, December 03, 2013 3:51 PM To: scim@ietf.org Subject: [scim] can a User address be primary Hello, in the document http://tools.ietf.org/html/draft-ietf-scim-core-schema-02 at point http://tools.ietf.org/html/draft-ietf-scim-core-schema-02#section-12.2 you can find an example that a address can be primary addresses": [ { "type": "work", "streetAddress": "100 Universal City Plaza", "locality": "Hollywood", "region": "CA", "postalCode": "91608", "country": "USA", "formatted": "100 Universal City Plaza\nHollywood, CA 91608 USA", "primary": true }, at the point http://tools.ietf.org/html/draft-ietf-scim-core-schema-02#sect= ion-12.7 "name":"addresses", "type":"complex", "multiValued":true, "description":"A physical mailing address for this User, as descr= ibed in (address Element). Canonical Type Values of work, home, and other. = The value attribute is a complex type with the following sub-attributes.", Mortimore, et al. Expires March 03, 2014 [Page 31] Internet-Draft draft-scim-core-schema-02 August 2013 "readOnly":false, "required":false, "caseExact":false, "subAttributes":[ { "name":"formatted" ... it looks like that address should not have the field primary. Since it makes sence for me I would think that it is ok if a address is pri= mary. Can you conform this? by David From phil.hunt@oracle.com Tue Dec 3 09:31:45 2013 Return-Path: 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 4E49E1AD8F7 for ; Tue, 3 Dec 2013 09:31:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 XQ2hfkMN8zwA for ; Tue, 3 Dec 2013 09:31:41 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 953C91AD8F4 for ; Tue, 3 Dec 2013 09:31:41 -0800 (PST) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id rB3HVbiT014362 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 3 Dec 2013 17:31:38 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rB3HVaTD023450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Dec 2013 17:31:36 GMT Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rB3HVZjC017148; Tue, 3 Dec 2013 17:31:35 GMT Received: from [192.168.1.12] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 03 Dec 2013 09:31:35 -0800 Content-Type: multipart/alternative; boundary="Apple-Mail=_969E424D-F396-42BB-9B8F-D2E24C87CCE3" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Phil Hunt In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBF00765@sc9-ex2k10mb1.corp.yaanatech.com> Date: Tue, 3 Dec 2013 09:31:33 -0800 Message-Id: <7D79810B-D426-4E9B-BBC3-934E09FA41B5@oracle.com> References: <1E973309-99AA-4ABC-B63B-3B6174E06479@nexussafe.com> <00C069FD01E0324C9FFCADF539701DB3BBF00765@sc9-ex2k10mb1.corp.yaanatech.com> To: Michael Hammer X-Mailer: Apple Mail (2.1510) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "scim@ietf.org" , "erik.wahlstrom@nexusgroup.com" Subject: Re: [scim] Some comments after a review of the 02 specs X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 17:31:45 -0000 --Apple-Mail=_969E424D-F396-42BB-9B8F-D2E24C87CCE3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Agreed. The word "consumer" can be ambiguous. Eg. a Client is sending = updates to a service provider vs a client retrieving resources from the = service provider. Which is the consumer depends on the action too much. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-12-03, at 6:16 AM, Michael Hammer = wrote: > If we are talking about a protocol and not some vague business = process, I agree. > =20 > Mike > =20 > =20 > From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Erik Wahlstr=F6m > Sent: Tuesday, December 03, 2013 8:19 AM > To: > Subject: Re: [scim] Some comments after a review of the 02 specs > =20 > I created a ticket regarding "Spec defines "Consumer" but uses the = word "client" through out the spec.=94 = http://tools.ietf.org/wg/scim/trac/ticket/53 > =20 > So, should we call it client instead of Consumer? And Server instead = of Service Provider?=20 > =20 > I prefer client/server instead of Consumer/Service Provider due to the = fact that we use it all through the code, it feels a bit forced to use = Consumer. And it also conflicts a bit with SAML Service Provider. > =20 > Any thoughts? > =20 > / Erik > =20 > =20 > On 02 Oct 2013, at 09:46, Erik Wahlstr=F6m = wrote: >=20 >=20 > After a review of the -02 specs I found a couple of issues that I = guess we need to discuss. I propose adding them all as new issues in the = issue tracker of no one objects. >=20 >=20 >=20 > ---------------------- >=20 > In general I think we should add a couple of more examples in our = definitions when we talk about example Resources. We always mention User = and Group. That's fine but when we start talking about = ServiceProviderConifig and ResourceType they come as a surprise and you = wonder if they are treated as any Resource or not. >=20 > Example: >=20 > Resource: The Service Provider managed artifact containing one or > more attributes; e.g., User or Group >=20 > Resource: The Service Provider managed artifact containing one or > more attributes; e.g., User, Group, ServiceProviderConfig or = ResourceType. >=20 > ---------------------- >=20 > In the API documentation we never mension the new URIs like = urn:scim:schemas:core:2.0:ListResponse, SearchRequest, Error, = BulkRequest, BulkResponse. We also mention = urn:scim:schemas:core:2.0:name.givenName and that's real attributes = defined in the core schema for a specific User.=20 >=20 >=20 > ---------------------- > In the "3.8 Attribute Notation" section shouln't we also define the = core resource type like User and Group when we refrence name.givenName. >=20 > Instead of: > urn:scim:schemas:core:2.0:name.givenName > Have: > urn:scim:schemas:core:2.0:User:name.givenName >=20 > ---------------------- >=20 > We have some language confusion on a lot of places in the = specification. In our defintions we define that there exists Consumers = and Service Providers. But most of the specification talks about clients = and servers. I personally use client and server when I talk about SCIM. = Here is a list of where we say client instead of Consumer. The server = equivalent is longer. >=20 > From: > "It is RECOMMENDED that > clients be implemented in such a way that new authentication schemes > can be deployed. Implementers SHOULD support existing = authentication" > To: > "It is RECOMMENDED that > Service Providers and Consumers is implemented in such a way that = new authentication schemes > can be deployed. Implementers SHOULD support existing = authentication" >=20 > -- =20 >=20 > From: > "To create new Resources, clients send POST requests to the Resource > endpoint; i.e., /Users or /Groups." >=20 > To: > "To create new Resources, Consumers send POST requests to the = Resource > endpoint; i.e., /Users or /Groups." >=20 > -- =20 >=20 > From: > "Since the server is free to > alter and/or ignore POSTed content, returning the full = representation > can be useful to the client, enabling it to correlate the client and > server views of the new Resource. When a Resource is created, its > URI must be returned in the response Location header." > To: > "Since the server is free to > alter and/or ignore POSTed content, returning the full = representation > can be useful to the Consumer, enabling it to correlate the Consumer = and > Service Provider views of the new Resource. When a Resource is = created, its > URI must be returned in the response Location header." >=20 > -- >=20 > From: > "Below, the client sends a POST request containing a User" > To: > "Below, the Consumer sends a POST request containing a User." >=20 > -- >=20 > From: > "To retrieve a known Resource, clients send GET requests to the > Resource endpoint; e.g., /Users/{id} or /Groups/{id}." >=20 > To: =20 > "To retrieve a known Resource, Consumers send GET requests to the > Resource endpoint; e.g., /Users/{id} or /Groups/{id}." >=20 > -- >=20 > From: > "Clients MAY execute queries without passing parameters on the URL = by > using the HTTP POST verb combined with the '/.search' path = extension." >=20 > To: > "Consumers MAY execute queries without passing parameters on the URL = by > using the HTTP POST verb combined with the '/.search' path = extension." >=20 > --=20 >=20 > From: > "To create a new search result set, a SCIM client sends an HTTP POST > request to the desired SCIM resource endpoint (ending in = '/.search')." > To: > "To create a new search result set, a SCIM Consumer sends an HTTP = POST > request to the desired SCIM resource endpoint (ending in = '/.search')." >=20 > --=20 >=20 > From: > "In addition to returning a > HTTP response code implementers MUST return the errors in the body = of > the response in the client requested format containing the error > response and, per the HTTP specification, human-readable > explanations." > To: > "In addition to returning a > HTTP response code implementers MUST return the errors in the body = of > the response containing the error response and, per the HTTP = specification, human-readable > explanations." >=20 > -- >=20 > From: > "In recognition that some clients, servers and firewalls prevent = PUT, > PATCH and DELETE operations a client MAY override the POST operation > by specifying the custom header "X-HTTP-Method-Override" with the > desired PUT, PATCH, DELETE operation." > To: > "In recognition that some clients, servers and firewalls prevent = PUT, > PATCH and DELETE operations a Consumer MAY override the POST = operation > by specifying the custom header "X-HTTP-Method-Override" with the > desired PUT, PATCH, DELETE operation." >=20 > ---------------------- >=20 > And finaly I agree with Steves earlier comment on the mail list, at = least the first two suggestions :), regarding section 3.1.5 not beeing = up to date. Steve stated: >=20 > "Section 3.1.5. (Headed: DateTime) of the SCIM v2 Schema refers to = section 3.2.7 which no longer exists and to the (XML Schema Datatypes = Specification) which is no longer supported. I'd suggest we refer to = the relevant standards in this paragraph and link to RFC3339 - section = 5.6 (http://tools.ietf.org/html/rfc3339#section-5.6), ISO-8601 = (http://www.iso.org/iso/catalogue_detail?csnumber=3D40874) and if humor = is tolerated, to Randall Munroe's opinion (https://xkcd.com/1179/)." >=20 >=20 > / Erik > =20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail=_969E424D-F396-42BB-9B8F-D2E24C87CCE3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

On 2013-12-03, at 6:16 AM, Michael Hammer <michael.hammer@yaanatech.com<= /a>> wrote:

If we are talking about = a protocol and not some vague business process, I = agree.
 
Mike
 
From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Erik = Wahlstr=F6m
Sent: Tuesday, December 03, 2013 = 8:19 AM
To: <scim@ietf.org>
Subject: Re: [scim] Some comments = after a review of the 02 specs
 
I created a ticket regarding "Spec defines "Consumer" but uses = the word "client" through out the spec.=94  So, = should we call it client instead of Consumer? And Server instead of = Service Provider? 
After a review = of the -02 specs I found a couple of issues that I guess we need to = discuss. I propose adding them all as new issues in the issue tracker of = no one objects.



----------------------

In general = I think we should add a couple of more examples in our definitions when = we talk about example Resources. We always mention User and Group. = That's fine but when we start talking about ServiceProviderConifig and = ResourceType they come as a surprise and you wonder if they are treated = as any Resource or not.

Example:

  Resource: =  The Service Provider managed artifact containing one = or
     more attributes; e.g., User or = Group

  Resource:  The Service Provider managed = artifact containing one or
     more = attributes; e.g., User, Group, ServiceProviderConfig or = ResourceType.

----------------------

In the API = documentation we never mension the new URIs like = urn:scim:schemas:core:2.0:ListResponse, SearchRequest, Error, = BulkRequest, BulkResponse. We also mention = urn:scim:schemas:core:2.0:name.givenName and that's real attributes = defined in the core schema for a specific User. 


-----------------= -----
In the "3.8 Attribute Notation" section shouln't we also define = the core resource type like User and Group when we refrence = name.givenName.

Instead = of:
urn:scim:schemas:core:2.0:name.givenName
Have:
urn:scim:schem= as:core:2.0:User:name.givenName

----------------------

We = have some language confusion on a lot of places in the specification. In = our defintions we define that there exists Consumers and Service = Providers. But most of the specification talks about clients and = servers. I personally use client and server when I talk about SCIM. Here = is a list of where we say client instead of Consumer. The server = equivalent is longer.

From:
  "It is RECOMMENDED = that
  clients be implemented in such a way that new = authentication schemes
  can be deployed. =  Implementers SHOULD support existing = authentication"
To:
  "It is RECOMMENDED = that
  Service Providers and Consumers is implemented in = such a way that new authentication schemes
  can be = deployed.  Implementers SHOULD support existing = authentication"

--   

From:
  "To = create new Resources, clients send POST requests to the = Resource
  endpoint; i.e., /Users or = /Groups."

To:
  "To create new Resources, Consumers = send POST requests to the Resource
  endpoint; i.e., /Users = or /Groups."

--   

From:
  "Since = the server is free to
  alter and/or ignore POSTed content, = returning the full representation
  can be useful to the = client, enabling it to correlate the client and
  server = views of the new Resource.  When a Resource is created, = its
  URI must be returned in the response Location = header."
To:
  "Since the server is free = to
  alter and/or ignore POSTed content, returning the full = representation
  can be useful to the Consumer, enabling it = to correlate the Consumer and
  Service Provider views of = the new Resource.  When a Resource is created, = its
  URI must be returned in the response Location = header."

--

From:
  "Below, the client sends = a POST request containing a User"
To:
  "Below, the = Consumer sends a POST request containing a = User."

--

From:
  "To retrieve a known = Resource, clients send GET requests to the
  Resource = endpoint; e.g., /Users/{id} or /Groups/{id}."

To: =   
  "To retrieve a known Resource, Consumers = send GET requests to the
  Resource endpoint; e.g., = /Users/{id} or = /Groups/{id}."

--

From:
  "Clients MAY = execute queries without passing parameters on the URL = by
  using the HTTP POST verb combined with the '/.search' = path extension."

To:
  "Consumers MAY execute = queries without passing parameters on the URL by
  using = the HTTP POST verb combined with the '/.search' path = extension."

-- 

From:
  = "To create a new search result set, a SCIM client sends an HTTP = POST
  request to the desired SCIM resource endpoint = (ending in '/.search')."
To:
  "To create a new search = result set, a SCIM Consumer sends an HTTP POST
  request to = the desired SCIM resource endpoint (ending in = '/.search')."

-- 

From:
  = "In addition to returning a
  HTTP response code = implementers MUST return the errors in the body of
  the = response in the client requested format containing the = error
  response and, per the HTTP specification, = human-readable
  explanations."
To:
  "In = addition to returning a
  HTTP response code implementers = MUST return the errors in the body of
  the response = containing the error response and, per the HTTP specification, = human-readable
  explanations."

--

From:
&nb= sp; "In recognition that some clients, servers and firewalls = prevent PUT,
  PATCH and DELETE operations a client MAY = override the POST operation
  by specifying the custom = header "X-HTTP-Method-Override" with the
  desired PUT, = PATCH, DELETE operation."
To:
  "In recognition that = some clients, servers and firewalls prevent PUT,
  PATCH = and DELETE operations a Consumer MAY override the POST = operation
  by specifying the custom header = "X-HTTP-Method-Override" with the
  desired PUT, PATCH, = DELETE operation."

----------------------

And finaly I = agree with Steves earlier comment on the mail list, at least the first = two suggestions :), regarding section 3.1.5 not beeing up to date. Steve = stated:

"Section 3.1.5. (Headed: DateTime) of the SCIM v2 Schema = refers to section 3.2.7 which no longer exists and to the (XML Schema = Datatypes Specification) which is no longer supported.  I'd suggest = we refer to the relevant standards in this paragraph and link to RFC3339 = - section 5.6 (https://xkcd.com/1179/)."


/ = Erik
scim@ietf.org
https://www.ietf.org/ma= ilman/listinfo/scim

= --Apple-Mail=_969E424D-F396-42BB-9B8F-D2E24C87CCE3-- From moransar@cisco.com Wed Dec 4 00:46:27 2013 Return-Path: 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 2EA4A1AE0B9 for ; Wed, 4 Dec 2013 00:46:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.202 X-Spam-Level: X-Spam-Status: No, score=-9.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 G9zrhT-115Ne for ; Wed, 4 Dec 2013 00:46:25 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 79F8C1AE06F for ; Wed, 4 Dec 2013 00:46:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2941; q=dns/txt; s=iport; t=1386146782; x=1387356382; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=X2CON+dVVjEuI8px5cx15s34ma2VN0AY674v09IHV9o=; b=LYXCimZep7pn1Wv2tBN8dAyxrIdR9/HQ37FP0Qdkf91cRZQEbUbm1qGr uT6pi0kUwEnW7iselvJc6lw+C9KTsb1TZJLu8KWhtxrhPMzQPPxSH3YLR VNLqgG2xHkHzFhjHPVmoRN3ZEIZMwS4c7fyHKulY3Nkkl8qrubKWMWhVt Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0FAJnrnlKtJV2c/2dsb2JhbABagwc4U7hogR8WdIIlAQEBBAEBAWsbAgEIEQQBAS8nCx0IAgQBEogCDbMGjhcXjks6hDMDiQqPCoEwkGODKYIq X-IronPort-AV: E=Sophos;i="4.93,823,1378857600"; d="scan'208";a="4200090" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-8.cisco.com with ESMTP; 04 Dec 2013 08:46:22 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id rB48kM3Q017261 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Dec 2013 08:46:22 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.25]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Wed, 4 Dec 2013 02:46:21 -0600 From: "Morteza Ansari (moransar)" To: =?iso-8859-1?Q?Erik_Wahlstr=F6m?= , "David Moebius" , "scim@ietf.org" Thread-Topic: [scim] can a User address be primary Thread-Index: AQHO8DdQuTGl9BTPZk+dqbgvmYf0oJpDEYaAgACHHwA= Date: Wed, 4 Dec 2013 08:46:21 +0000 Message-ID: References: <50748E7D83B48349962C98013ACEC1690116800FDC@MarvMailDB.technxs.com> In-Reply-To: <50748E7D83B48349962C98013ACEC1690116800FDC@MarvMailDB.technxs.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.21.89.52] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [scim] can a User address be primary X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 08:46:27 -0000 Interesting, I had not read that text that way, but I agree that currently that seem to be the correct interpretation. But the question is whether that is correct or we should fix it. Speaking as one of the implementers, I don't think it is the right assumption that all multi-valued attributes will have "type", "primary", and "display" sub attributes. I certainly agree it makes sense for "addresses" to have those, but not as a general statement for all multi-valued attributes. For example in case of "photos" (or entitlements, roles, etc.) we may not need/want such sub-attributes. Cheers, Morteza On 12/3/13 8:42 AM, "Erik Wahlstr=F6m" wrot= e: >Hi, >Yes, it can be primary. Its a multivalue attribute and one of the >upsides of that is that you get an primary attribute automatically. >/ Erik >________________________________________ >From: scim [scim-bounces@ietf.org] on behalf of David Moebius >[d.moebius@tarent.de] >Sent: Tuesday, December 03, 2013 3:51 PM >To: scim@ietf.org >Subject: [scim] can a User address be primary > >Hello, > >in the document http://tools.ietf.org/html/draft-ietf-scim-core-schema-02 >at point > > > >http://tools.ietf.org/html/draft-ietf-scim-core-schema-02#section-12.2 > > >you can find an example that a address can be primary > > >addresses": [ > { > "type": "work", > "streetAddress": "100 Universal City Plaza", > "locality": "Hollywood", > "region": "CA", > "postalCode": "91608", > "country": "USA", > "formatted": "100 Universal City Plaza\nHollywood, CA 91608 USA", > "primary": true > }, > > >at the point=20 >http://tools.ietf.org/html/draft-ietf-scim-core-schema-02#section-12.7 > >"name":"addresses", > "type":"complex", > "multiValued":true, > "description":"A physical mailing address for this User, as >described in (address Element). Canonical Type Values of work, home, and >other. The value attribute is a complex type with the following >sub-attributes.", > > > >Mortimore, et al. Expires March 03, 2014 [Page 31] > > > >Internet-Draft =20 >draft-scim-core-schema-02a-02> August 2013 > > > "readOnly":false, > "required":false, > "caseExact":false, > "subAttributes":[ > { > "name":"formatted" > >... > >it looks like that address should not have the field primary. > >Since it makes sence for me I would think that it is ok if a address is >primary. > > >Can you conform this? > > >by David > >_______________________________________________ >scim mailing list >scim@ietf.org >https://www.ietf.org/mailman/listinfo/scim From prvs=1050B9073B=erik.wahlstrom@nexusgroup.com Wed Dec 4 06:04:26 2013 Return-Path: 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 00FD11AE26E for ; Wed, 4 Dec 2013 06:04:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 6ZPbuODVYsBS for ; Wed, 4 Dec 2013 06:04:23 -0800 (PST) Received: from mailedge.nexussafe.com (mailedge.nexussafe.com [83.241.133.98]) by ietfa.amsl.com (Postfix) with ESMTP id 23AB51AE260 for ; Wed, 4 Dec 2013 06:04:20 -0800 (PST) Received: from MARVMAILCAS.technxs.com (10.75.28.37) by MailEdge.nexussafe.com (83.241.133.98) with Microsoft SMTP Server (TLS) id 14.0.722.0; Wed, 4 Dec 2013 15:04:19 +0100 Received: from MARVMAILDB.technxs.com ([fe80::2481:7a28:782a:7fc7]) by MarvMailCAS.technxs.com ([fe80::cd7:3e15:4b14:c076%14]) with mapi id 14.03.0158.001; Wed, 4 Dec 2013 15:04:16 +0100 From: =?Windows-1252?Q?Erik_Wahlstr=F6m?= To: "Morteza Ansari (moransar)" Thread-Topic: [scim] can a User address be primary Thread-Index: AQHO8DdR1Hj03obm3Eu7Cvh3FvUuQZpCqxHlgAD+WYCAAFjSgA== Date: Wed, 4 Dec 2013 14:04:15 +0000 Message-ID: <65B6C68D-0C8C-4E94-822F-A4079147080C@nexussafe.com> References: <50748E7D83B48349962C98013ACEC1690116800FDC@MarvMailDB.technxs.com> In-Reply-To: Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.75.28.65] Content-Type: text/plain; charset="Windows-1252" Content-ID: <34A86F2664718C4DB1C695839584BFE8@nexussafe.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: David Moebius , "scim@ietf.org" , =?Windows-1252?Q?Erik_Wahlstr=F6m?= Subject: Re: [scim] can a User address be primary X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 14:04:26 -0000 All attributes are "unless otherwise specified are optional=94 so I guess i= t=92s up to each implementation if they would like to use the attributes pr= imary, type and so on on each multi-valued attribute. Maybe some implemento= rs would like to have a primary picture, like facebooks profile picture, so= I don=92t think we should define if it=92s possible to have it or not on e= ach multi-valued attribute. / Erik On 04 Dec 2013, at 09:46, Morteza Ansari (moransar) wr= ote: > Interesting, I had not read that text that way, but I agree that currentl= y > that seem to be the correct interpretation. But the question is whether > that is correct or we should fix it. >=20 > Speaking as one of the implementers, I don't think it is the right > assumption that all multi-valued attributes will have "type", "primary", > and "display" sub attributes. I certainly agree it makes sense for > "addresses" to have those, but not as a general statement for all > multi-valued attributes. For example in case of "photos" (or > entitlements, roles, etc.) we may not need/want such sub-attributes. >=20 >=20 >=20 > Cheers, > Morteza >=20 > On 12/3/13 8:42 AM, "Erik Wahlstr=F6m" wr= ote: >=20 >> Hi, >> Yes, it can be primary. Its a multivalue attribute and one of the >> upsides of that is that you get an primary attribute automatically. >> / Erik >> ________________________________________ >> From: scim [scim-bounces@ietf.org] on behalf of David Moebius >> [d.moebius@tarent.de] >> Sent: Tuesday, December 03, 2013 3:51 PM >> To: scim@ietf.org >> Subject: [scim] can a User address be primary >>=20 >> Hello, >>=20 >> in the document http://tools.ietf.org/html/draft-ietf-scim-core-schema-0= 2 >> at point >>=20 >>=20 >>=20 >> http://tools.ietf.org/html/draft-ietf-scim-core-schema-02#section-12.2 >>=20 >>=20 >> you can find an example that a address can be primary >>=20 >>=20 >> addresses": [ >> { >> "type": "work", >> "streetAddress": "100 Universal City Plaza", >> "locality": "Hollywood", >> "region": "CA", >> "postalCode": "91608", >> "country": "USA", >> "formatted": "100 Universal City Plaza\nHollywood, CA 91608 USA", >> "primary": true >> }, >>=20 >>=20 >> at the point=20 >> http://tools.ietf.org/html/draft-ietf-scim-core-schema-02#section-12.7 >>=20 >> "name":"addresses", >> "type":"complex", >> "multiValued":true, >> "description":"A physical mailing address for this User, as >> described in (address Element). Canonical Type Values of work, home, and >> other. The value attribute is a complex type with the following >> sub-attributes.", >>=20 >>=20 >>=20 >> Mortimore, et al. Expires March 03, 2014 [Page 31] >>=20 >>=20 >> >> Internet-Draft =20 >> draft-scim-core-schema-02> a-02> August 2013 >>=20 >>=20 >> "readOnly":false, >> "required":false, >> "caseExact":false, >> "subAttributes":[ >> { >> "name":"formatted" >>=20 >> ... >>=20 >> it looks like that address should not have the field primary. >>=20 >> Since it makes sence for me I would think that it is ok if a address is >> primary. >>=20 >>=20 >> Can you conform this? >>=20 >>=20 >> by David >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >=20 From michael.hammer@yaanatech.com Wed Dec 4 06:44:48 2013 Return-Path: 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 534061AE26F for ; Wed, 4 Dec 2013 06:44:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 8kPEw1tyuDYG for ; Wed, 4 Dec 2013 06:44:44 -0800 (PST) Received: from email1.corp.yaanatech.com (webmail10.yaanatech.com [63.128.177.10]) by ietfa.amsl.com (Postfix) with ESMTP id 3D9DC1AE268 for ; Wed, 4 Dec 2013 06:44:43 -0800 (PST) Received: from SC9-EX2K10MB1.corp.yaanatech.com ([fe80::149d:c2e1:8065:2a47]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Wed, 4 Dec 2013 06:44:40 -0800 From: Michael Hammer To: "moransar@cisco.com" , "erik.wahlstrom@nexusgroup.com" , "d.moebius@tarent.de" , "scim@ietf.org" Thread-Topic: [scim] can a User address be primary Thread-Index: AQHO8DdQWH11pcPwh0CIEgHCneVB4ZpDMw2AgAENPID//92PYA== Date: Wed, 4 Dec 2013 14:44:39 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBF0110E@sc9-ex2k10mb1.corp.yaanatech.com> References: <50748E7D83B48349962C98013ACEC1690116800FDC@MarvMailDB.technxs.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.43] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0048_01CEF0D5.72B5F230" MIME-Version: 1.0 Subject: Re: [scim] can a User address be primary X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 14:44:48 -0000 ------=_NextPart_000_0048_01CEF0D5.72B5F230 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ummm... Ambiguity is not good in a standard. Having multiple interpretations will affect interoperability. Mike -----Original Message----- From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Morteza Ansari (moransar) Sent: Wednesday, December 04, 2013 3:46 AM To: Erik Wahlstr=F6m; David Moebius; scim@ietf.org Subject: Re: [scim] can a User address be primary Interesting, I had not read that text that way, but I agree that = currently that seem to be the correct interpretation. But the question is whether = that is correct or we should fix it. Speaking as one of the implementers, I don't think it is the right assumption that all multi-valued attributes will have "type", "primary", = and "display" sub attributes. I certainly agree it makes sense for = "addresses" to have those, but not as a general statement for all multi-valued attributes. For example in case of "photos" (or entitlements, roles, = etc.) we may not need/want such sub-attributes. Cheers, Morteza On 12/3/13 8:42 AM, "Erik Wahlstr=F6m" = wrote: >Hi, >Yes, it can be primary. Its a multivalue attribute and one of the=20 >upsides of that is that you get an primary attribute automatically. >/ Erik >________________________________________ >From: scim [scim-bounces@ietf.org] on behalf of David Moebius=20 >[d.moebius@tarent.de] >Sent: Tuesday, December 03, 2013 3:51 PM >To: scim@ietf.org >Subject: [scim] can a User address be primary > >Hello, > >in the document=20 >http://tools.ietf.org/html/draft-ietf-scim-core-schema-02 >at point > > > >http://tools.ietf.org/html/draft-ietf-scim-core-schema-02#section-12.2 > > >you can find an example that a address can be primary > > >addresses": [ > { > "type": "work", > "streetAddress": "100 Universal City Plaza", > "locality": "Hollywood", > "region": "CA", > "postalCode": "91608", > "country": "USA", > "formatted": "100 Universal City Plaza\nHollywood, CA 91608 = USA", > "primary": true > }, > > >at the point >http://tools.ietf.org/html/draft-ietf-scim-core-schema-02#section-12.7 > >"name":"addresses", > "type":"complex", > "multiValued":true, > "description":"A physical mailing address for this User, as=20 >described in (address Element). Canonical Type Values of work, home,=20 >and other. The value attribute is a complex type with the following=20 >sub-attributes.", > > > >Mortimore, et al. Expires March 03, 2014 [Page = 31] > > > >Internet-Draft =20 >draft-scim-core-schema-02hem >a-02> August 2013 > > > "readOnly":false, > "required":false, > "caseExact":false, > "subAttributes":[ > { > "name":"formatted" > >... > >it looks like that address should not have the field primary. > >Since it makes sence for me I would think that it is ok if a address is = >primary. > > >Can you conform this? > > >by David > >_______________________________________________ >scim mailing list >scim@ietf.org >https://www.ietf.org/mailman/listinfo/scim _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim ------=_NextPart_000_0048_01CEF0D5.72B5F230 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMTIw NDE0NDQzOFowIwYJKoZIhvcNAQkEMRYEFFa0SQDlmBqkjycAzJBd0TS9rxS9MIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAaxzLtv62KRHFwySKIWxgS7rg1gjNta5AYC+mxpyo IfuZ2N9GKy+tfskICk2EBrOq+vIlbieafrtqbVwH43sg85kgx1krp3ktd0MupeJrjn28bZnR5kzI 3ted+IR3tSDGuuRJ+iVQ+Ng8j3StN/4vIvrO27gQ+Bh5NYo9UsfhPlyv5M5rDzqKoAE5X++LZXE3 XiUoOjDz9Pm8skO1pfiU5csJIP0CCu0Y3p28uKIUnhmcTt0RC8lNsBT7i58dEexc9A0c5cNfmeFw hS4ZVxPjYJqxZmxHZ+KCm3C6ggxCIK2ouX7uvuXHhLyKGxqm+uN5IgXs00KrUVmsShtLo8UyzQAA AAAAAA== ------=_NextPart_000_0048_01CEF0D5.72B5F230-- From phil.hunt@oracle.com Wed Dec 4 09:01:21 2013 Return-Path: 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 02EC91AE157 for ; Wed, 4 Dec 2013 09:01:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 bTOKOn8a_Hwv for ; Wed, 4 Dec 2013 09:01:18 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 85FEE1AE08C for ; Wed, 4 Dec 2013 09:01:18 -0800 (PST) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id rB4H1CZc014316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 4 Dec 2013 17:01:13 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rB4H1AXi025361 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Dec 2013 17:01:11 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rB4H1A6H025350; Wed, 4 Dec 2013 17:01:10 GMT Received: from [192.168.1.12] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 04 Dec 2013 09:01:10 -0800 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Phil Hunt In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBF0110E@sc9-ex2k10mb1.corp.yaanatech.com> Date: Wed, 4 Dec 2013 09:01:08 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <8BA025F4-6E53-46E3-9DB2-E081F7986982@oracle.com> References: <50748E7D83B48349962C98013ACEC1690116800FDC@MarvMailDB.technxs.com> <00C069FD01E0324C9FFCADF539701DB3BBF0110E@sc9-ex2k10mb1.corp.yaanatech.com> To: Michael Hammer X-Mailer: Apple Mail (2.1510) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "d.moebius@tarent.de" , "scim@ietf.org" , "erik.wahlstrom@nexusgroup.com" , "moransar@cisco.com" Subject: Re: [scim] can a User address be primary X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 17:01:21 -0000 I don't think the spec is ambiguous. But the fact that "primary" is an = inherited feature of a multi-value type does make it somewhat hidden. It would be good to include an example of a "primary" address in the = draft. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-12-04, at 6:44 AM, Michael Hammer = wrote: > Ummm... Ambiguity is not good in a standard. > Having multiple interpretations will affect interoperability. >=20 > Mike >=20 > -----Original Message----- > From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Morteza Ansari > (moransar) > Sent: Wednesday, December 04, 2013 3:46 AM > To: Erik Wahlstr=F6m; David Moebius; scim@ietf.org > Subject: Re: [scim] can a User address be primary >=20 > Interesting, I had not read that text that way, but I agree that = currently > that seem to be the correct interpretation. But the question is = whether that > is correct or we should fix it. >=20 > Speaking as one of the implementers, I don't think it is the right > assumption that all multi-valued attributes will have "type", = "primary", and > "display" sub attributes. I certainly agree it makes sense for = "addresses" > to have those, but not as a general statement for all multi-valued > attributes. For example in case of "photos" (or entitlements, roles, = etc.) > we may not need/want such sub-attributes. >=20 >=20 >=20 > Cheers, > Morteza >=20 > On 12/3/13 8:42 AM, "Erik Wahlstr=F6m" = wrote: >=20 >> Hi, >> Yes, it can be primary. Its a multivalue attribute and one of the=20 >> upsides of that is that you get an primary attribute automatically. >> / Erik >> ________________________________________ >> From: scim [scim-bounces@ietf.org] on behalf of David Moebius=20 >> [d.moebius@tarent.de] >> Sent: Tuesday, December 03, 2013 3:51 PM >> To: scim@ietf.org >> Subject: [scim] can a User address be primary >>=20 >> Hello, >>=20 >> in the document=20 >> http://tools.ietf.org/html/draft-ietf-scim-core-schema-02 >> at point >>=20 >>=20 >>=20 >> = http://tools.ietf.org/html/draft-ietf-scim-core-schema-02#section-12.2 >>=20 >>=20 >> you can find an example that a address can be primary >>=20 >>=20 >> addresses": [ >> { >> "type": "work", >> "streetAddress": "100 Universal City Plaza", >> "locality": "Hollywood", >> "region": "CA", >> "postalCode": "91608", >> "country": "USA", >> "formatted": "100 Universal City Plaza\nHollywood, CA 91608 = USA", >> "primary": true >> }, >>=20 >>=20 >> at the point >> = http://tools.ietf.org/html/draft-ietf-scim-core-schema-02#section-12.7 >>=20 >> "name":"addresses", >> "type":"complex", >> "multiValued":true, >> "description":"A physical mailing address for this User, as=20= >> described in (address Element). Canonical Type Values of work, home,=20= >> and other. The value attribute is a complex type with the following=20= >> sub-attributes.", >>=20 >>=20 >>=20 >> Mortimore, et al. Expires March 03, 2014 [Page = 31] >>=20 >>=20 >> >> Internet-Draft =20 >> = draft-scim-core-schema-02> hem >> a-02> August 2013 >>=20 >>=20 >> "readOnly":false, >> "required":false, >> "caseExact":false, >> "subAttributes":[ >> { >> "name":"formatted" >>=20 >> ... >>=20 >> it looks like that address should not have the field primary. >>=20 >> Since it makes sence for me I would think that it is ok if a address = is=20 >> primary. >>=20 >>=20 >> Can you conform this? >>=20 >>=20 >> by David >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From michael.hammer@yaanatech.com Wed Dec 4 09:35:21 2013 Return-Path: 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 01A9C1AE332 for ; Wed, 4 Dec 2013 09:35:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 zL0mrsTdR3T9 for ; Wed, 4 Dec 2013 09:35:17 -0800 (PST) Received: from email1.corp.yaanatech.com (webmail10.yaanatech.com [63.128.177.10]) by ietfa.amsl.com (Postfix) with ESMTP id 30CA71AE31F for ; Wed, 4 Dec 2013 09:35:17 -0800 (PST) Received: from SC9-EX2K10MB1.corp.yaanatech.com ([fe80::149d:c2e1:8065:2a47]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Wed, 4 Dec 2013 09:35:14 -0800 From: Michael Hammer To: "phil.hunt@oracle.com" Thread-Topic: [scim] can a User address be primary Thread-Index: AQHO8DdQWH11pcPwh0CIEgHCneVB4ZpDMw2AgAENPID//92PYIAArK8A//99f2A= Date: Wed, 4 Dec 2013 17:35:13 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBF0132D@sc9-ex2k10mb1.corp.yaanatech.com> References: <50748E7D83B48349962C98013ACEC1690116800FDC@MarvMailDB.technxs.com> <00C069FD01E0324C9FFCADF539701DB3BBF0110E@sc9-ex2k10mb1.corp.yaanatech.com> <8BA025F4-6E53-46E3-9DB2-E081F7986982@oracle.com> In-Reply-To: <8BA025F4-6E53-46E3-9DB2-E081F7986982@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.43] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_010A_01CEF0ED.46562850" MIME-Version: 1.0 Cc: "d.moebius@tarent.de" , "scim@ietf.org" , "erik.wahlstrom@nexusgroup.com" , "moransar@cisco.com" Subject: Re: [scim] can a User address be primary X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 17:35:21 -0000 ------=_NextPart_000_010A_01CEF0ED.46562850 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable When someone says they didn't read it that way. When someone says there are multiple interpretations. There is ambiguity. I just scanned the text for the word "primary". You have the statement: =20 "The primary attribute value 'true' MUST appear no more than once." This appears to be a global statement. I have to assume that applies to = any complete description. Yet, you have examples showing "primary" used multiple times with value = =3D "true". I was looking to see where it specifies what values this may be applied = to. There was this restriction: "referenceTypes The names of the Resource Types that may be referenced; e.g., User. This is only applicable for attributes that are of the "reference" data type. The following multi-valued attributes are defined. There are no canonical type values defined and the primary value serves no useful purpose." But, that restriction seems scoped solely to referenceTypes. Absent any other restrictions, I would assume that any multi-valued attribute can include the "primary" attribute. If that is not true... Also, if you are referring to the "primary" attribute, you should = identify it as a formal attribute and not as casual text. I can't tell if all uses of the word "primary" in the document always = refer to the attribute or not. This is underspecified and ambiguous. Please don't be dismissive. Fix it. Mike -----Original Message----- From: Phil Hunt [mailto:phil.hunt@oracle.com]=20 Sent: Wednesday, December 04, 2013 12:01 PM To: Michael Hammer Cc: moransar@cisco.com; erik.wahlstrom@nexusgroup.com; = d.moebius@tarent.de; scim@ietf.org Subject: Re: [scim] can a User address be primary I don't think the spec is ambiguous. But the fact that "primary" is an inherited feature of a multi-value type does make it somewhat hidden. It would be good to include an example of a "primary" address in the = draft. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-12-04, at 6:44 AM, Michael Hammer wrote: > Ummm... Ambiguity is not good in a standard. > Having multiple interpretations will affect interoperability. >=20 > Mike >=20 > -----Original Message----- > From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Morteza Ansari > (moransar) > Sent: Wednesday, December 04, 2013 3:46 AM > To: Erik Wahlstr=F6m; David Moebius; scim@ietf.org > Subject: Re: [scim] can a User address be primary >=20 > Interesting, I had not read that text that way, but I agree that=20 > currently that seem to be the correct interpretation. But the question = > is whether that is correct or we should fix it. >=20 > Speaking as one of the implementers, I don't think it is the right=20 > assumption that all multi-valued attributes will have "type",=20 > "primary", and "display" sub attributes. I certainly agree it makes = sense for "addresses" > to have those, but not as a general statement for all multi-valued=20 > attributes. For example in case of "photos" (or entitlements, roles,=20 > etc.) we may not need/want such sub-attributes. >=20 >=20 >=20 > Cheers, > Morteza >=20 > On 12/3/13 8:42 AM, "Erik Wahlstr=F6m" wrote: >=20 >> Hi, >> Yes, it can be primary. Its a multivalue attribute and one of the=20 >> upsides of that is that you get an primary attribute automatically. >> / Erik >> ________________________________________ >> From: scim [scim-bounces@ietf.org] on behalf of David Moebius=20 >> [d.moebius@tarent.de] >> Sent: Tuesday, December 03, 2013 3:51 PM >> To: scim@ietf.org >> Subject: [scim] can a User address be primary >>=20 >> Hello, >>=20 >> in the document >> http://tools.ietf.org/html/draft-ietf-scim-core-schema-02 >> at point >>=20 >>=20 >>=20 >> http://tools.ietf.org/html/draft-ietf-scim-core-schema-02#section-12. >> 2 >>=20 >>=20 >> you can find an example that a address can be primary >>=20 >>=20 >> addresses": [ >> { >> "type": "work", >> "streetAddress": "100 Universal City Plaza", >> "locality": "Hollywood", >> "region": "CA", >> "postalCode": "91608", >> "country": "USA", >> "formatted": "100 Universal City Plaza\nHollywood, CA 91608 = USA", >> "primary": true >> }, >>=20 >>=20 >> at the point >> http://tools.ietf.org/html/draft-ietf-scim-core-schema-02#section-12. >> 7 >>=20 >> "name":"addresses", >> "type":"complex", >> "multiValued":true, >> "description":"A physical mailing address for this User, as=20 >> described in (address Element). Canonical Type Values of work, home,=20 >> and other. The value attribute is a complex type with the following=20 >> sub-attributes.", >>=20 >>=20 >>=20 >> Mortimore, et al. Expires March 03, 2014 [Page = 31] >>=20 >>=20 >> >> Internet-Draft =20 >> draft-scim-core-schema-02> sc >> hem >> a-02> August 2013 >>=20 >>=20 >> "readOnly":false, >> "required":false, >> "caseExact":false, >> "subAttributes":[ >> { >> "name":"formatted" >>=20 >> ... >>=20 >> it looks like that address should not have the field primary. >>=20 >> Since it makes sence for me I would think that it is ok if a address=20 >> is primary. >>=20 >>=20 >> Can you conform this? >>=20 >>=20 >> by David >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim ------=_NextPart_000_010A_01CEF0ED.46562850 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMTIw NDE3MzUxMVowIwYJKoZIhvcNAQkEMRYEFM2RA5JK/BaK4AxG+Sxfm59EWWGPMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAJohJCFBMyMNl1R7zm638NXOJKkQTyoDcAhSP4VSy eoyiuf46wbESItXlERS0oafBlioSdASyze+8aylyo4DtTpEce1VlRT4KXm5/r0qqn2HJ3I8PmCe0 JeMW/zng+J2CE9epcYT5dtBAcZhwHOWoA+41n8dOXDQweaiG6ytA6YXyEJFSh6aIVm6N9dh/eUO9 c3YbDhe4ugw3eHJAi8aFmFhRitY1J2KDT30sl6foG/H+p8PK6lNykTaoIGDzONHNiynXfln6Da4c 4EBCVvoFcqP/beucEHsPeJz1zrlEzg4l2Cwh2rsEDG97C5e0YrOEAMWC2GkZ8BqJkzGm6zOrKQAA AAAAAA== ------=_NextPart_000_010A_01CEF0ED.46562850-- From phil.hunt@oracle.com Thu Dec 5 11:43:21 2013 Return-Path: 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 2C3E21ACCDA for ; Thu, 5 Dec 2013 11:43:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 9xlffxDD-Iqj for ; Thu, 5 Dec 2013 11:43:13 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 21CE91AE05D for ; Thu, 5 Dec 2013 11:43:13 -0800 (PST) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id rB5Jh8Fu026857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 5 Dec 2013 19:43:09 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rB5Jh80I016927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 5 Dec 2013 19:43:08 GMT Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rB5Jh8dX006432 for ; Thu, 5 Dec 2013 19:43:08 GMT Received: from [192.168.1.12] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 05 Dec 2013 11:43:07 -0800 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_123C2244-3F59-401D-A8DD-88259361555F" Message-Id: <693755BB-BCB0-4B4C-8091-937FE3AD9B80@oracle.com> Date: Thu, 5 Dec 2013 11:43:06 -0800 To: "scim@ietf.org WG" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Subject: [scim] Aliases and perm resource URLs - is redirect a solution? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 19:43:21 -0000 --Apple-Mail=_123C2244-3F59-401D-A8DD-88259361555F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I had a casual conversation by email with Kelly and Erik, it seems = useful to have this discussion with the wider group. Issue: There is a desire by a lot of developers to support easy URLs, = supposedly to avoid lookups. These URLs can be of the form: 1. To reference the current "subject" in the current security context: GET https:////v2/Users/me 2. To reference a user by their user id (MS OData and Google Directory = do forms of this): GET https:////v2/Users/ Note that for item 2, it could *easily* be re-expressed as: GET https:////v2/Users?filter=3Dusername eq = The catch comes when you want to use those aliases for other operations. = Eg. update telephone number for the current user. PATCH https:////v2/Users/me The big concern is we want clients to be using the permenant URL which = is of the form: PATCH https:////v2/Users/ This is the form that must be used for group membership or any reference = to the item. A. Support Alias Using Redirects It occurs to me that we *might* be able to use redirects. This causes = another request response. But in practice it is not as costly as one = might think. In practice it is done within the same HTTP connection and = this is almost as fast (in the same way that browsers re-use connections = to load hundreds of graphic images etc). Reading 2616, and searching on stackoverflow, etc, it seems that a 301 = "permanent" redirect fits. This allows the "alias" to be used, but at = the same time, it always informs the client that the permanent URL is = the one that will not change. In contrast, 302, suggests that the = client should use the alias since the redirected URL may change in the = future. The catch is that RFC2616's 3xx introduction states: The action required MAY be carried out by the user agent without interaction with the user if and only if the method used in the second request is GET or HEAD. A client SHOULD detect infinite redirection loops, since such loops generate network traffic for each redirection. In our case we want to *preserve* the action as is. A PATCH should not = convert to GET, etc. Also, clients SHOULD NOT tolerate more than ONE = redirect (unless something else needs to be considered due to proxies = and gateways). The alternatives? B. Aliases Transparently Accepted Service Providers could simply accept the request as is and process = directly. When they return a record, the Location value should always be = the perm URL rather than the alias. The downside to this, is the = tendency to get lazy and use non-perm URLs that may change (particularly = those using a user-id). C. Aliases Not Supported All operations must be based on immutable perm URLs. This may often = require the clients to remember perm URLs (or obtain them through the = access token, etc). Or the client apps must do a query before modify = step. This isn't that unusual. This happened in LDAP all the time. = However, in LDAP this lead to a lot of desire to hard code predictive = DNs creating a lot of incompatibility (I made a lot of money fixing = these issues). For many it would mean pressure to use record = identifiers based on a login id rather than a guid. I don't really have a particular strong position on any of these. But I = do think we need to include in the api document a clarification on = "redirects" one way or the other. If we leave this unspecified, you = could see clients having to deal with a wide variety of interpretation = here. =20 I do see some positives in supporting aliases if only because major = providers like MS, Facebook, and Google are already doing it. It might = be useful for them to share the postives/negatives of their experience = if possible. Does this lead to problems with multiple ways to reference = objects? Everyone's input appreciated. I'll volunteer to assemble any comments = back into a ticket next week. Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_123C2244-3F59-401D-A8DD-88259361555F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I had = a casual conversation by email with Kelly and Erik, it seems useful to = have this discussion with the wider group.

Issue: =  There is a desire by a lot of developers to support easy URLs, = supposedly to avoid lookups.  These URLs can be of the = form:

1.  To reference the current = "subject" in the current security context:
GET = https://<some_domain>/<some_prefix>/v2/Users/me

=
2.  To reference a user by their user id (MS OData and = Google Directory do forms of this):
GET = https://<some_domain>/<some_prefix>/v2/Users/<user_id>

Note that for item 2, it could *easily* be = re-expressed as:
GET = https://<some_domain>/<some_prefix>/v2/Users?filter=3Dusername= eq <user_id>

The catch comes when you = want to use those aliases for other operations.  Eg. update = telephone number for the current = user.

PATCH https://<some_domain>/<= some_prefix>/v2/Users/me

The big concern is = we want clients to be using the permenant URL which is of the = form:
PATCH https://<some_domain>/<some_prefi= x>/v2/Users/<guid>
This is the form that must = be used for group membership or any reference to the = item.

A. Support Alias Using = Redirects
It occurs to me that we *might* be able to use = redirects.  This causes another request response.  But in = practice it is not as costly as one might think. In practice it is done = within the same HTTP connection and this is almost as fast (in the same = way that browsers re-use connections to load hundreds of graphic images = etc).

Reading 2616, and searching on = stackoverflow, etc, it seems that a 301 "permanent" redirect fits. =  This allows the "alias" to be used, but at the same time, it = always informs the client that the permanent URL is the one that will = not change.  In contrast, 302, suggests that the client should use = the alias since the redirected URL may change in the = future.

The catch is that RFC2616's 3xx = introduction states:

I do see =
some positives in supporting aliases if only because major providers =
like MS, Facebook, and Google are already doing it.  It might be =
useful for them to share the postives/negatives of their experience if =
possible. Does this lead to problems with multiple ways to reference =
objects?

Everyone's input appreciated. I'll =
volunteer to assemble any comments back into a ticket next =
week.

=

--Apple-Mail=_123C2244-3F59-401D-A8DD-88259361555F--

From pradtke@stanford.edu  Thu Dec  5 14:19:37 2013
Return-Path: 
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 4B6781AE168 for ; Thu,  5 Dec 2013 14:19:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level: 
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
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 qzyK223NG71W for ; Thu,  5 Dec 2013 14:19:34 -0800 (PST)
Received: from smtp.stanford.edu (smtp2.Stanford.EDU [171.67.219.82]) by ietfa.amsl.com (Postfix) with ESMTP id BDC031ADFB8 for ; Thu,  5 Dec 2013 14:19:34 -0800 (PST)
Received: from smtp.stanford.edu (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 658D1340AA3; Thu,  5 Dec 2013 14:19:31 -0800 (PST)
Received: from sr13-cc613b7de2.stanford.edu (sr13-cc613b7de2.Stanford.EDU [171.64.19.137]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: pradtke) by smtp.stanford.edu (Postfix) with ESMTPSA id A5439340E90; Thu,  5 Dec 2013 14:19:30 -0800 (PST)
Message-ID: <52A0FBF1.4080606@stanford.edu>
Date: Thu, 05 Dec 2013 14:19:29 -0800
From: Patrick Radtke 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Phil Hunt , "scim@ietf.org WG" 
References: <693755BB-BCB0-4B4C-8091-937FE3AD9B80@oracle.com>
In-Reply-To: <693755BB-BCB0-4B4C-8091-937FE3AD9B80@oracle.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [scim] Aliases and perm resource URLs - is redirect a solution?
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Simple Cloud Identity Management BOF 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 05 Dec 2013 22:19:37 -0000

I'm curious about the potential for naming conflicts for using

https:////v2/Users/

For example, we have a valid user with the username 'me', which would be 
problematic if 'me' is keyword to reference the current subject of the 
security context.
Similarly, we've had users choose names that looked like random 
gibberish, which would have a very unlikely chance of conflicting with 
the service provider generated id if we allowed this style of aliasing.

LinkedIn's style may be less prone to conflicts.

https:////v2/Users/~
would be used to get the current subject

and

https:////v2/Users/username=bob

would load a specific user (without the extra ListResponse data that 
comes with doing filtering.)


I think it would be desirable to have a way to determine the permanent 
URL for the subject of the current security context even if the group 
decides not to support aliases.

I don't have a preference amongst the proposed solutions.

-Patrick


On 12/5/13, 11:43 AM, Phil Hunt wrote:
> I had a casual conversation by email with Kelly and Erik, it seems
> useful to have this discussion with the wider group.
>
> Issue:  There is a desire by a lot of developers to support easy URLs,
> supposedly to avoid lookups.  These URLs can be of the form:
>
> 1.  To reference the current "subject" in the current security context:
> GET https:////v2/Users/me
>
> 2.  To reference a user by their user id (MS OData and Google Directory
> do forms of this):
> GET https:////v2/Users/
>
> Note that for item 2, it could *easily* be re-expressed as:
> GET https:////v2/Users?filter=username eq
> 
>
> The catch comes when you want to use those aliases for other operations.
>   Eg. update telephone number for the current user.
>
> PATCH https:////v2/Users/me
>
> The big concern is we want clients to be using the permenant URL which
> is of the form:
> PATCH https:////v2/Users/
> This is the form that must be used for group membership or any reference
> to the item.
>
> A. Support Alias Using Redirects
> It occurs to me that we *might* be able to use redirects.  This causes
> another request response.  But in practice it is not as costly as one
> might think. In practice it is done within the same HTTP connection and
> this is almost as fast (in the same way that browsers re-use connections
> to load hundreds of graphic images etc).
>
> Reading 2616, and searching on stackoverflow, etc, it seems that a 301
> "permanent" redirect fits.  This allows the "alias" to be used, but at
> the same time, it always informs the client that the permanent URL is
> the one that will not change.  In contrast, 302, suggests that the
> client should use the alias since the redirected URL may change in the
> future.
>
> The catch is that RFC2616's 3xx introduction states:
>
> The action
>     required MAY be carried out by the user agent without interaction
>     with the user if and only if the method used in the second request is
>     GET or HEAD. A client SHOULD detect infinite redirection loops, since
>     such loops generate network traffic for each redirection.
>
>
> In our case we want to *preserve* the action as is. A PATCH should not
> convert to GET, etc. Also, clients SHOULD NOT tolerate more than ONE
> redirect (unless something else needs to be considered due to proxies
> and gateways).
>
> The alternatives?
>
> B. Aliases Transparently Accepted
> Service Providers could simply accept the request as is and process
> directly. When they return a record, the Location value should always be
> the perm URL rather than the alias.   The downside to this, is the
> tendency to get lazy and use non-perm URLs that may change (particularly
> those using a user-id).
>
> C. Aliases Not Supported
> All operations must be based on immutable perm URLs.  This may often
> require the clients to remember perm URLs (or obtain them through the
> access token, etc).  Or the client apps must do a query before modify
> step.  This isn't that unusual.  This happened in LDAP all the time.
>   However, in LDAP this lead to a lot of desire to hard code predictive
> DNs creating a lot of incompatibility (I made a lot of money fixing
> these issues).   For many it would mean pressure to use record
> identifiers based on a login id rather than a guid.
>
> I don't really have a particular strong position on any of these. But I
> do think we need to include in the api document a clarification on
> "redirects" one way or the other. If we leave this unspecified, you
> could see clients having to deal with a wide variety of interpretation
> here.
>
> I do see some positives in supporting aliases if only because major
> providers like MS, Facebook, and Google are already doing it.  It might
> be useful for them to share the postives/negatives of their experience
> if possible. Does this lead to problems with multiple ways to reference
> objects?
>
> Everyone's input appreciated. I'll volunteer to assemble any comments
> back into a ticket next week.
>
> Phil
>
> @independentid
> www.independentid.com 
> phil.hunt@oracle.com 
>
>
>
> _______________________________________________
> scim mailing list
> scim@ietf.org
> https://www.ietf.org/mailman/listinfo/scim
>


From phil.hunt@oracle.com  Thu Dec  5 15:45:54 2013
Return-Path: 
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 F0AC91AE16D for ; Thu,  5 Dec 2013 15:45:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level: 
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
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 aJ28PJ_X7oAi for ; Thu,  5 Dec 2013 15:45:51 -0800 (PST)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 65D121AE1DD for ; Thu,  5 Dec 2013 15:45:51 -0800 (PST)
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id rB5NjluG007775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 5 Dec 2013 23:45:47 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rB5Njkvq002222 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Dec 2013 23:45:46 GMT
Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rB5NjjFC024806; Thu, 5 Dec 2013 23:45:45 GMT
Received: from [172.15.2.237] (/174.7.233.157) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 05 Dec 2013 15:45:45 -0800
References: <693755BB-BCB0-4B4C-8091-937FE3AD9B80@oracle.com> <52A0FBF1.4080606@stanford.edu>
Mime-Version: 1.0 (1.0)
In-Reply-To: <52A0FBF1.4080606@stanford.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <138198F8-285E-4ED1-957E-00C96E949605@oracle.com>
X-Mailer: iPhone Mail (11B554a)
From: Phil Hunt 
Date: Thu, 5 Dec 2013 15:45:44 -0800
To: Patrick Radtke 
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: "scim@ietf.org WG" 
Subject: Re: [scim] Aliases and perm resource URLs - is redirect a solution?
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Simple Cloud Identity Management BOF 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 05 Dec 2013 23:45:54 -0000

The stipulation would be the alias' must resolve uniquely - such as in the c=
ase of user id.=20

Phil

> On Dec 5, 2013, at 14:19, Patrick Radtke  wrote:
>=20
> I'm curious about the potential for naming conflicts for using
>=20
> https:////v2/Users/
>=20
> For example, we have a valid user with the username 'me', which would be p=
roblematic if 'me' is keyword to reference the current subject of the securi=
ty context.
> Similarly, we've had users choose names that looked like random gibberish,=
 which would have a very unlikely chance of conflicting with the service pro=
vider generated id if we allowed this style of aliasing.
>=20
> LinkedIn's style may be less prone to conflicts.
>=20
> https:////v2/Users/~
> would be used to get the current subject
>=20
> and
>=20
> https:////v2/Users/username=3Dbob
>=20
> would load a specific user (without the extra ListResponse data that comes=
 with doing filtering.)
>=20
>=20
> I think it would be desirable to have a way to determine the permanent URL=
 for the subject of the current security context even if the group decides n=
ot to support aliases.
>=20
> I don't have a preference amongst the proposed solutions.
>=20
> -Patrick
>=20
>=20
>> On 12/5/13, 11:43 AM, Phil Hunt wrote:
>> I had a casual conversation by email with Kelly and Erik, it seems
>> useful to have this discussion with the wider group.
>>=20
>> Issue:  There is a desire by a lot of developers to support easy URLs,
>> supposedly to avoid lookups.  These URLs can be of the form:
>>=20
>> 1.  To reference the current "subject" in the current security context:
>> GET https:////v2/Users/me
>>=20
>> 2.  To reference a user by their user id (MS OData and Google Directory
>> do forms of this):
>> GET https:////v2/Users/
>>=20
>> Note that for item 2, it could *easily* be re-expressed as:
>> GET https:////v2/Users?filter=3Dusername eq
>> 
>>=20
>> The catch comes when you want to use those aliases for other operations.
>>  Eg. update telephone number for the current user.
>>=20
>> PATCH https:////v2/Users/me
>>=20
>> The big concern is we want clients to be using the permenant URL which
>> is of the form:
>> PATCH https:////v2/Users/
>> This is the form that must be used for group membership or any reference
>> to the item.
>>=20
>> A. Support Alias Using Redirects
>> It occurs to me that we *might* be able to use redirects.  This causes
>> another request response.  But in practice it is not as costly as one
>> might think. In practice it is done within the same HTTP connection and
>> this is almost as fast (in the same way that browsers re-use connections
>> to load hundreds of graphic images etc).
>>=20
>> Reading 2616, and searching on stackoverflow, etc, it seems that a 301
>> "permanent" redirect fits.  This allows the "alias" to be used, but at
>> the same time, it always informs the client that the permanent URL is
>> the one that will not change.  In contrast, 302, suggests that the
>> client should use the alias since the redirected URL may change in the
>> future.
>>=20
>> The catch is that RFC2616's 3xx introduction states:
>>=20
>> The action
>>    required MAY be carried out by the user agent without interaction
>>    with the user if and only if the method used in the second request is
>>    GET or HEAD. A client SHOULD detect infinite redirection loops, since
>>    such loops generate network traffic for each redirection.
>>=20
>>=20
>> In our case we want to *preserve* the action as is. A PATCH should not
>> convert to GET, etc. Also, clients SHOULD NOT tolerate more than ONE
>> redirect (unless something else needs to be considered due to proxies
>> and gateways).
>>=20
>> The alternatives?
>>=20
>> B. Aliases Transparently Accepted
>> Service Providers could simply accept the request as is and process
>> directly. When they return a record, the Location value should always be
>> the perm URL rather than the alias.   The downside to this, is the
>> tendency to get lazy and use non-perm URLs that may change (particularly
>> those using a user-id).
>>=20
>> C. Aliases Not Supported
>> All operations must be based on immutable perm URLs.  This may often
>> require the clients to remember perm URLs (or obtain them through the
>> access token, etc).  Or the client apps must do a query before modify
>> step.  This isn't that unusual.  This happened in LDAP all the time.
>>  However, in LDAP this lead to a lot of desire to hard code predictive
>> DNs creating a lot of incompatibility (I made a lot of money fixing
>> these issues).   For many it would mean pressure to use record
>> identifiers based on a login id rather than a guid.
>>=20
>> I don't really have a particular strong position on any of these. But I
>> do think we need to include in the api document a clarification on
>> "redirects" one way or the other. If we leave this unspecified, you
>> could see clients having to deal with a wide variety of interpretation
>> here.
>>=20
>> I do see some positives in supporting aliases if only because major
>> providers like MS, Facebook, and Google are already doing it.  It might
>> be useful for them to share the postives/negatives of their experience
>> if possible. Does this lead to problems with multiple ways to reference
>> objects?
>>=20
>> Everyone's input appreciated. I'll volunteer to assemble any comments
>> back into a ticket next week.
>>=20
>> Phil
>>=20
>> @independentid
>> www.independentid.com 
>> phil.hunt@oracle.com 
>>=20
>>=20
>>=20
>> _______________________________________________
>> scim mailing list
>> scim@ietf.org
>> https://www.ietf.org/mailman/listinfo/scim
>=20
> _______________________________________________
> scim mailing list
> scim@ietf.org
> https://www.ietf.org/mailman/listinfo/scim

From moransar@cisco.com  Fri Dec  6 00:26:53 2013
Return-Path: 
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 6F80C1A1F76 for ; Fri,  6 Dec 2013 00:26:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.501
X-Spam-Level: 
X-Spam-Status: No, score=-9.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 wreKgIoi--2w for ; Fri,  6 Dec 2013 00:26:50 -0800 (PST)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 9B4E21A1F56 for ; Fri,  6 Dec 2013 00:26:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16792; q=dns/txt; s=iport; t=1386318407; x=1387528007; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=+9CDwtQrqr5mpGgbTH1noz3bzTKWovC/DLDmwlVJfIw=; b=adI+9Ve+F7/lZ8ah/6KBMhGbXj2FE8T45EnhoOt32huTCVoH0T0BDaD1 55vmsisji/q56dkt3SwhFE9kFNDEAv+yF+Bd0H9G+/Fzw4GDSXDvo+nVf l2aGBrEjnysw2ZjHWwOGHzzni4zqROe2Gs4US6e3MM705FGmsbNU4xE64 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ArUFAK+JoVKtJV2a/2dsb2JhbABTBoJDRDhTr0YBiTOBJBZ0giUBAQEESR4iAgEIEQMBAhcBEAcyFAkIAgQBEhuHZw3AdxeOHhEBCwIyGBIBC4QVA5FkhjCSE4MpgWoHFyI
X-IronPort-AV: E=Sophos;i="4.93,839,1378857600"; d="scan'208,217";a="4782037"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-4.cisco.com with ESMTP; 06 Dec 2013 08:26:47 +0000
Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rB68QkBH020971 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Dec 2013 08:26:46 GMT
Received: from xmb-rcd-x08.cisco.com ([169.254.8.25]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Fri, 6 Dec 2013 02:26:46 -0600
From: "Morteza Ansari (moransar)" 
To: Phil Hunt , "scim@ietf.org WG" 
Thread-Topic: [scim] Aliases and perm resource URLs - is redirect a solution?
Thread-Index: AQHO8fJGJzuBpSz8/UGxfEjKa/OAaJpGtF6A
Date: Fri, 6 Dec 2013 08:26:44 +0000
Message-ID: 
References: <693755BB-BCB0-4B4C-8091-937FE3AD9B80@oracle.com>
In-Reply-To: <693755BB-BCB0-4B4C-8091-937FE3AD9B80@oracle.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.9.131030
x-originating-ip: [10.21.144.185]
Content-Type: multipart/alternative; boundary="_000_CEC6BF67BB975moransarciscocom_"
MIME-Version: 1.0
Subject: Re: [scim] Aliases and perm resource URLs - is redirect a solution?
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Simple Cloud Identity Management BOF 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 06 Dec 2013 08:26:53 -0000

--_000_CEC6BF67BB975moransarciscocom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Speaking as an implementer not as chair:

In our implementation we have added the notion of "/users/me" and it seems =
pretty useful. It does not cause a conflict in our implementation as our "i=
d" namespace has a very specific format and it is not possible to have a "m=
e" as an id.

We do not support the second case and I would worry about supporting such a=
lias given consumer could start caching that and a change in userName could=
 result in invalid link or worse end up pointing to the wrong entry.  Using=
 301 redirect is an interesting notion but as Phil suggested it won't addre=
ss some of the cases.  I am also interested in hearing from other implement=
ers on their experience with implementing aliases.


Cheers,
Morteza

From: Phil Hunt >
Date: Thursday, December 5, 2013 11:43 AM
To: "scim@ietf.org" >
Subject: [scim] Aliases and perm resource URLs - is redirect a solution?

I had a casual conversation by email with Kelly and Erik, it seems useful t=
o have this discussion with the wider group.

Issue:  There is a desire by a lot of developers to support easy URLs, supp=
osedly to avoid lookups.  These URLs can be of the form:

1.  To reference the current "subject" in the current security context:
GET https:////v2/Users/me

2.  To reference a user by their user id (MS OData and Google Directory do =
forms of this):
GET https:////v2/Users/

Note that for item 2, it could *easily* be re-expressed as:
GET https:////v2/Users?filter=3Dusername eq 

The catch comes when you want to use those aliases for other operations.  E=
g. update telephone number for the current user.

PATCH https:////v2/Users/me

The big concern is we want clients to be using the permenant URL which is o=
f the form:
PATCH https:////v2/Users/
This is the form that must be used for group membership or any reference to=
 the item.

A. Support Alias Using Redirects
It occurs to me that we *might* be able to use redirects.  This causes anot=
her request response.  But in practice it is not as costly as one might thi=
nk. In practice it is done within the same HTTP connection and this is almo=
st as fast (in the same way that browsers re-use connections to load hundre=
ds of graphic images etc).

Reading 2616, and searching on stackoverflow, etc, it seems that a 301 "per=
manent" redirect fits.  This allows the "alias" to be used, but at the same=
 time, it always informs the client that the permanent URL is the one that =
will not change.  In contrast, 302, suggests that the client should use the=
 alias since the redirected URL may change in the future.

The catch is that RFC2616's 3xx introduction states:

The action
   required MAY be carried out by the user agent without interaction
   with the user if and only if the method used in the second request is
   GET or HEAD. A client SHOULD detect infinite redirection loops, since
   such loops generate network traffic for each redirection.

In our case we want to *preserve* the action as is. A PATCH should not conv=
ert to GET, etc. Also, clients SHOULD NOT tolerate more than ONE redirect (=
unless something else needs to be considered due to proxies and gateways).

The alternatives?

B. Aliases Transparently Accepted
Service Providers could simply accept the request as is and process directl=
y. When they return a record, the Location value should always be the perm =
URL rather than the alias.   The downside to this, is the tendency to get l=
azy and use non-perm URLs that may change (particularly those using a user-=
id).

C. Aliases Not Supported
All operations must be based on immutable perm URLs.  This may often requir=
e the clients to remember perm URLs (or obtain them through the access toke=
n, etc).  Or the client apps must do a query before modify step.  This isn'=
t that unusual.  This happened in LDAP all the time.  However, in LDAP this=
 lead to a lot of desire to hard code predictive DNs creating a lot of inco=
mpatibility (I made a lot of money fixing these issues).   For many it woul=
d mean pressure to use record identifiers based on a login id rather than a=
 guid.

I don't really have a particular strong position on any of these. But I do =
think we need to include in the api document a clarification on "redirects"=
 one way or the other. If we leave this unspecified, you could see clients =
having to deal with a wide variety of interpretation here.

I do see some positives in supporting aliases if only because major provide=
rs like MS, Facebook, and Google are already doing it.  It might be useful =
for them to share the postives/negatives of their experience if possible. D=
oes this lead to problems with multiple ways to reference objects?

Everyone's input appreciated. I'll volunteer to assemble any comments back =
into a ticket next week.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com


--_000_CEC6BF67BB975moransarciscocom_
Content-Type: text/html; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable







Speaking as an implementer not as chair:







In our implementation we have added the notion of "/users/me"=
; and it seems pretty useful. It does not cause a conflict in our implement=
ation as our "id" namespace has a very specific format and it is =
not possible to have a "me" as an id.







We do not support the second case and I would worry about supporting s=
uch alias given consumer could start caching that and a change in userName =
could result in invalid link or worse end up pointing to the wrong entry. &=
nbsp;Using 301 redirect is an interesting
 notion but as Phil suggested it won't address some of the cases.  I a=
m also interested in hearing from other implementers on their experience wi=
th implementing aliases.












Cheers,


Morteza









From: Phil Hunt <phil.hunt@oracle.com>

Date: Thursday, December 5, 2013 11=
:43 AM

To: "scim@ietf.org" <scim@i=
etf.org>

Subject: [scim] Aliases and perm re=
source URLs - is redirect a solution?












I had a casual conversation by email with Kelly and Erik, it seems useful t=
o have this discussion with the wider group.






Issue:  There is a desire by a lot of developers to support easy =
URLs, supposedly to avoid lookups.  These URLs can be of the form:






1.  To reference the current "subject" in the current s=
ecurity context:








2.  To reference a user by their user id (MS OData and Google Dir=
ectory do forms of this):








Note that for item 2, it could *easily* be re-expressed as:










The catch comes when you want to use those aliases for other operation=
s.  Eg. update telephone number for the current user.













The big concern is we want clients to be using the permenant URL which=
 is of the form:



This is the form that must be used for group membership or any referen=
ce to the item.







A. Support Alias Using Redirects


It occurs to me that we *might* be able to use redirects.  This c=
auses another request response.  But in practice it is not as costly a=
s one might think. In practice it is done within the same HTTP connection a=
nd this is almost as fast (in the same way
 that browsers re-use connections to load hundreds of graphic images etc).<=
/div>






Reading 2616, and searching on stackoverflow, etc, it seems that a 301=
 "permanent" redirect fits.  This allows the "alias&quo=
t; to be used, but at the same time, it always informs the client that the =
permanent URL is the one that will not change.  In contrast,
 302, suggests that the client should use the alias since the redirected UR=
L may change in the future.







The catch is that RFC2616's 3xx introduction states:




The action
   required MAY be carried out by the user agent without interaction
   with the user if and only if the method used in the second request is
   GET or HEAD. A client SHOULD detect infinite redirection loops, since
   such loops generate network traffic for each redirection.









In our case we want to *preserve* the action as is. A PATCH should not=
 convert to GET, etc. Also, clients SHOULD NOT tolerate more than ONE redir=
ect (unless something else needs to be considered due to proxies and gatewa=
ys).







The alternatives?







B. Aliases Transparently Accepted


Service Providers could simply accept the request as is and process di=
rectly. When they return a record, the Location value should always be the =
perm URL rather than the alias.   The downside to this, is the tendenc=
y to get lazy and use non-perm URLs that
 may change (particularly those using a user-id).







C. Aliases Not Supported


All operations must be based on immutable perm URLs.  This may of=
ten require the clients to remember perm URLs (or obtain them through the a=
ccess token, etc).  Or the client apps must do a query before modify s=
tep.  This isn't that unusual.  This happened
 in LDAP all the time.  However, in LDAP this lead to a lot of desire =
to hard code predictive DNs creating a lot of incompatibility (I made a lot=
 of money fixing these issues).   For many it would mean pressure to u=
se record identifiers based on a login id
 rather than a guid.







I don't really have a particular strong position on any of these. But =
I do think we need to include in the api document a clarification on "=
redirects" one way or the other. If we leave this unspecified, you cou=
ld see clients having to deal with a wide
 variety of interpretation here.  







I do see some positives in supporting aliases if only because major pr=
oviders like MS, Facebook, and Google are already doing it.  It might =
be useful for them to share the postives/negatives of their experience if p=
ossible. Does this lead to problems with
 multiple ways to reference objects?







Everyone's input appreciated. I'll volunteer to assemble any comments =
back into a ticket next week.













--_000_CEC6BF67BB975moransarciscocom_--

From moransar@cisco.com  Fri Dec  6 00:31:00 2013
Return-Path: 
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 32C201AE2E7 for ; Fri,  6 Dec 2013 00:31:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.491
X-Spam-Level: 
X-Spam-Status: No, score=-9.491 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 d7ZViAmbvYn5 for ; Fri,  6 Dec 2013 00:30:57 -0800 (PST)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id 0B0DB1AE1B7 for ; Fri,  6 Dec 2013 00:30:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25526; q=dns/txt; s=iport; t=1386318653; x=1387528253; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=ZUieg2AMjUnZELhfAubiSekqMUsAM1tuupFVBFIuwLQ=; b=YDbTjG3N/yQnSXPl12NW7JADO/Z19KKuR0xZyByd3v/ZQ+M97enI2+G8 xkxlD+gGakgKPbxRS8WKxbG6a0RGTXUtX97NeSmUXlpFcAl5kUsA2jZrx AT3OWl1pN/R5y13VYoRFjhUvZPCBwh6ROO0PJn7wAiv95Lq3SVQ1/ZG2n k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ArsFAPiKoVKtJV2b/2dsb2JhbAA/FwOCQ0Q4SAu3EIFqgSQWdIIlAQEBAgIdEjkGGwIBCAcKAwECFQQIBAMHMhQDAQUHAQIBAwESiAINNrRwi1IXhSiHN4E/EQEMHhUBDAsRB4QbA5gUkhOBPYEaUoFxOQ
X-IronPort-AV: E=Sophos;i="4.93,839,1378857600"; d="scan'208,217";a="4782268"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-7.cisco.com with ESMTP; 06 Dec 2013 08:30:52 +0000
Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rB68Uq3D026058 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 6 Dec 2013 08:30:52 GMT
Received: from xmb-rcd-x08.cisco.com ([169.254.8.25]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Fri, 6 Dec 2013 02:30:51 -0600
From: "Morteza Ansari (moransar)" 
To: "Morteza Ansari (moransar)" , "scim@ietf.org" 
Thread-Topic: [scim] Next SCIM WG call agenda - Dec. 4th @11AM Pacific
Thread-Index: AQHO6nThwLFSajoTBEOO5TvGsYymG5pGxH6A
Date: Fri, 6 Dec 2013 08:30:50 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.9.131030
x-originating-ip: [10.21.144.185]
Content-Type: multipart/alternative; boundary="_000_CEC6CA79BB9E5moransarciscocom_"
MIME-Version: 1.0
Subject: Re: [scim] Next SCIM WG call agenda - Dec. 4th @11AM Pacific
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Simple Cloud Identity Management BOF 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 06 Dec 2013 08:31:00 -0000

--_000_CEC6CA79BB9E5moransarciscocom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Not sure if there was a confusion on the date or other reasons at works but=
 only a few folks joined the call on the 4th.  We had some general discussi=
on of the open issues but given we didn't have quorum we did not go through=
 the agenda and review issues.

The next and last call for 2013 will be on Dec. 18th 11AM Pacific time.


Cheers,
Morteza

From: Morteza Ansari >
Date: Monday, November 25, 2013 10:58 PM
To: "scim@ietf.org" >
Subject: Re: [scim] Next SCIM WG call agenda - Dec. 4th @11AM Pacific

Given the US holidays this week (Ths/Fri), a number of folks can't make thi=
s call.  The biweekly WG call is pushed forward by one week and will start =
on Dec. 4th.

The agenda is not changed and we will go through all the open issues. Pleas=
e between now and then if have taken any issue and have a proposed text use=
 the mailing list so we can get the easy ones out of the way and use the ca=
ll time for more challenging issues requiring live discussion.

The WebEx meeting info is not change (other than the date), but included he=
re for reference.


Cheers,
Morteza

Topic: SCIM WG bi-weekly call
Date: Every 2 weeks on Wednesday, from Wednesday, December 4, 2013 to no en=
d date
Time: 11:00 am, Pacific Standard Time (San Francisco, GMT-08:00)
Meeting Number: 340 844 711
Meeting Password: (This meeting does not require a password.)


-------------------------------------------------------
To join the online meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to https://go.webex.com/go/j.php?ED=3D153193777&UID=3D0&RT=3DMiM0
2. If requested, enter your name and email address.
3. If a password is required, enter the meeting password: (This meeting doe=
s not require a password.)
4. Click "Join".

To view in other time zones or languages, please click the link:
https://go.webex.com/go/j.php?ED=3D153193777&UID=3D0&ORT=3DMiM0

-------------------------------------------------------
To join the audio conference only
-------------------------------------------------------
To receive a call back, provide your phone number when you join the meeting=
, or call the number below and enter the access code.
US Toll Free: +1-855-749-4751
US Toll: +1-415-655-0000
Global call-in numbers: https://go.webex.com/go/globalcallin.php?serviceTyp=
e=3DMC&ED=3D153193777&tollFree=3D1
Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restricti=
ons.pdf

Access code:340 844 711

-------------------------------------------------------
For assistance
-------------------------------------------------------
1. Go to https://go.webex.com/go/mc
2. On the left navigation bar, click "Support".

You can contact me at:
moransar@cisco.com
1-408 566-5647

To update this meeting to your calendar program (for example Microsoft Outl=
ook), click this link:
https://go.webex.com/go/j.php?ED=3D153193777&UID=3D0&ICS=3DMRS1&LD=3D1&RD=
=3D2&ST=3D1&SHA2=3DAAAAARBGrx6g-3G8Y56jVVHaPSruhMgm2a/qNpXPxgH8MS4f&RT=3DMi=
M0


WebEx will automatically setup Meeting Manager for Windows the first time y=
ou join a meeting. To save time, you can setup prior to the meeting by clic=
king this link:
https://go.webex.com/go/meetingcenter/mcsetup.php


The playback of UCF (Universal Communications Format) rich media files requ=
ires appropriate players. To view this type of rich media files in the meet=
ing, please check whether you have the players installed on your computer b=
y going to https://go.webex.com/go/systemdiagnosis.php.

Sign up for a free trial of WebEx
http://www.webex.com/go/mcemfreetrial

http://www.webex.com

CCP:+14156550000x340844711#

IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a=
nd any documents and other materials exchanged or viewed during the session=
 to be recorded. By joining this session, you automatically consent to such=
 recordings. If you do not consent to the recording, discuss your concerns =
with the meeting host prior to the start of the recording or do not join th=
e session. Please note that any such recordings may be subject to discovery=
 in the event of litigation.


From: Morteza Ansari >
Date: Tuesday, November 12, 2013 9:45 PM
To: "scim@ietf.org" >
Subject: [scim] Next SCIM WG call agenda - Nov. 27th @11AM Pacific

Hi folks,

Note that we don't have a call tomorrow and the next call is on Nov. 27th a=
t 11AM Pacific.  We will be going through all the open issues on tracker. P=
lease between now and then if have taken any issue and have a proposed text=
 use the mailing list so we can get the easy ones out of the way and use th=
e call time for more challenging issues requiring live discussion.


Cheers,
Morteza

--_000_CEC6CA79BB9E5moransarciscocom_
Content-Type: text/html; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable







Not sure if there was a confusion on the date or other reasons at work=
s but only a few folks joined the call on the 4th.  We had some genera=
l discussion of the open issues but given we didn't have quorum we did not =
go through the agenda and review issues.







The next and last call for 2013 will be on Dec. 18th 11AM Pacific time=
.












Cheers,


Morteza









From: Morteza Ansari <moransar@cisco.com>

Date: Monday, November 25, 2013 10:=
58 PM

To: "scim@ietf.org" <scim@i=
etf.org>

Subject: Re: [scim] Next SCIM WG ca=
ll agenda - Dec. 4th @11AM Pacific













Given the US holidays this week (Ths/Fri), a number of folks can't mak=
e this call.  The biweekly WG call is pushed forward by one week and w=
ill start on Dec. 4th.







The agenda is not changed and we will go through all the open issues.&=
nbsp;Please between now and then if have taken any issue and have a propose=
d text use the mailing list so we can get the easy ones out of the way and =
use the call time for more challenging
 issues requiring live discussion.







The WebEx meeting info is not change (other than the date), but includ=
ed here for reference.












Cheers,


Morteza









Topic: SCIM WG bi-weekly call 

Date: Every 2 weeks on Wednesday, from Wednesday, Decemb=
er 4, 2013 to no end date 

Time: 11:00 am, Pacific Standard Time (San Francisco, GM=
T-08:00) 

Meeting Number: 340 844 711 

Meeting Password: (This meeting does not require a passw=
ord.) 





-------------------------------------------------------&=
nbsp;

To join the online meeting (Now from mobile devices!)&nb=
sp;

-------------------------------------------------------&=
nbsp;

1. Go to https://go.webex.com/go/j.php?ED=3D153193777&UID=3D0&RT=3DMiM0<=
/a> 

2. If requested, enter your name and email address. =
;

3. If a password is required, enter the meeting password=
: (This meeting does not require a password.) 

4. Click "Join". 



To view in other time zones or languages, please click t=
he link: 

https://go.webex.com/go/j.php?ED=3D=
153193777&UID=3D0&ORT=3DMiM0 


-------------------------------------------------------&=
nbsp;

To join the audio conference only 

-------------------------------------------------------&=
nbsp;

To receive a call back, provide your phone number when y=
ou join the meeting, or call the number below and enter the access code.&nb=
sp;

US Toll Free: +1-855-749-4751 

US Toll: +1-415-655-0000 
Global call-in numbers: https://go.webex.com/go/globalcal=
lin.php?serviceType=3DMC&ED=3D153193777&tollFree=3D1 

Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf 



Access code:340 844 711 



-------------------------------------------------------&=
nbsp;

For assistance 

-------------------------------------------------------&=
nbsp;

1. Go to https://go.webex.com/go/mc 

2. On the left navigation bar, click "Support"=
. 



You can contact me at: 

moransar@cisco.com 

1-408 566-5647 



To update this meeting to your calendar program (for exa=
mple Microsoft Outlook), click this link: 

htt=
ps://go.webex.com/go/j.php?ED=3D153193777&UID=3D0&ICS=3DMRS1&LD=
=3D1&RD=3D2&ST=3D1&SHA2=3DAAAAARBGrx6g-3G8Y56jVVHaPSruhMgm2a/qN=
pXPxgH8MS4f&RT=3DMiM0 



WebEx will automatically setup Meeting Manager for Windo=
ws the first time you join a meeting. To save time, you can setup prior to =
the meeting by clicking this link: 

https://go.webex.com/go/meetingcenter/mcsetup.php 





The playback of UCF (Universal Communications Format) ri=
ch media files requires appropriate players. To view this type of rich medi=
a files in the meeting, please check
 whether you have the players installed on your computer by going to <=
/span>=
https://go.webex.com/go/systemdiagnosis.php. 



Sign up for a free trial of WebEx 

http://www.webex.com/go/mcemfreetrial <=
/span>



http://www=
.webex.com 



CCP:+14156550000x340844711# 



IMPORTANT NOTICE: This WebEx service includes a feature =
that allows audio and any documents and other materials exchanged or viewed=
 during the session to be recorded.
 By joining this session, you automatically consent to such recordings. If =
you do not consent to the recording, discuss your concerns with the meeting=
 host prior to the start of the recording or do not join the session. Pleas=
e note that any such recordings
 may be subject to discovery in the event of litigation. 
















From: Morteza Ansari <moransar@cisco.com>

Date: Tuesday, November 12, 2013 9:=
45 PM

To: "scim@ietf.org" <scim@i=
etf.org>

Subject: [scim] Next SCIM WG call a=
genda - Nov. 27th @11AM Pacific













Hi folks, 







Note that we don't have a call tomorrow and the next call is on Nov. 2=
7th at 11AM Pacific.  We will be going through all the open issues on =
tracker. Please between now and then if have taken any issue and have a pro=
posed text use the mailing list so we
 can get the easy ones out of the way and use the call time for more challe=
nging issues requiring live discussion.












Cheers,


Morteza













--_000_CEC6CA79BB9E5moransarciscocom_--

From moransar@cisco.com  Fri Dec  6 00:37:26 2013
Return-Path: 
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 BAA251AE2F6 for ; Fri,  6 Dec 2013 00:37:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.491
X-Spam-Level: 
X-Spam-Status: No, score=-14.491 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 EJQzKz8Ak4xS for ; Fri,  6 Dec 2013 00:37:23 -0800 (PST)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6380E1AE0F1 for ; Fri,  6 Dec 2013 00:37:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21326; q=dns/txt; s=iport; t=1386319040; x=1387528640; h=from:to:subject:date:message-id:mime-version; bh=d+1Y2SM/yYFr9zLBWf6h72ztC4B9JDYqPyRTg2E/UIQ=; b=ZN0BrzPI2D3+ommdtvPOqYv09EM7LJIeAwm/MMzoncuQ4T6H1JthkJUz 0FfW/1aastshHonpaEAPJ6olplJU1Z03N4Us2Gq916CDlBGW0rO49szyY UIIa23d0Jpnhg2hOSk8Csc7w/8QK+QmBLjhd74ChF5BgaQV9peRwza204 E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AtcGAOmLoVKtJV2a/2dsb2JhbAA/FwOCQ0Q4U7cQgWqBJBZtB4IqAi85Bh0BDw0YBAgEAzkUAwEMAwEDE4gCDTahQJMxi1MXhSiHN4E/EQEMHhUBDBwHhBsDmBSSE4E9gRpSgXE5
X-IronPort-AV: E=Sophos;i="4.93,839,1378857600";  d="scan'208,217";a="289796795"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 06 Dec 2013 08:37:19 +0000
Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rB68bJ9U000924 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 6 Dec 2013 08:37:19 GMT
Received: from xmb-rcd-x08.cisco.com ([169.254.8.25]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Fri, 6 Dec 2013 02:37:18 -0600
From: "Morteza Ansari (moransar)" 
To: "scim@ietf.org" 
Thread-Topic: Next SCIM WG call agenda - Dec. 18th @11AM Pacific
Thread-Index: AQHO8l5fOzzLMejJTEyrlokAt61AWA==
Date: Fri, 6 Dec 2013 08:37:18 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.9.131030
x-originating-ip: [10.21.144.185]
Content-Type: multipart/alternative; boundary="_000_CEC6CCBDBB9FBmoransarciscocom_"
MIME-Version: 1.0
Subject: [scim] Next SCIM WG call agenda - Dec. 18th @11AM Pacific
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Simple Cloud Identity Management BOF 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 06 Dec 2013 08:37:27 -0000

--_000_CEC6CCBDBB9FBmoransarciscocom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi folks,

Just a reminder that the next and last 2013 SCIM WG call is scheduled for D=
ec. 18th at 11AM Pacific time. The agenda is not changed and we will go thr=
ough all the open issues. Please between now and then if have taken any iss=
ue and have a proposed text use the mailing list so we can get the easy one=
s out of the way and use the call time for more challenging issues requirin=
g live discussion.

The WebEx meeting info is not changed, but included here for reference.

Also note that we will not have a call on Jan 1st and the next one after De=
c. 18th call will be on Jan. 15th.


Cheers,
Morteza

Topic: SCIM WG bi-weekly call
Date: Every 2 weeks on Wednesday, from Wednesday, December 4, 2013 to no en=
d date
Time: 11:00 am, Pacific Standard Time (San Francisco, GMT-08:00)
Meeting Number: 340 844 711
Meeting Password: (This meeting does not require a password.)


-------------------------------------------------------
To join the online meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to https://go.webex.com/go/j.php?ED=3D153193777&UID=3D0&RT=3DMiM0
2. If requested, enter your name and email address.
3. If a password is required, enter the meeting password: (This meeting doe=
s not require a password.)
4. Click "Join".

To view in other time zones or languages, please click the link:
https://go.webex.com/go/j.php?ED=3D153193777&UID=3D0&ORT=3DMiM0

-------------------------------------------------------
To join the audio conference only
-------------------------------------------------------
To receive a call back, provide your phone number when you join the meeting=
, or call the number below and enter the access code.
US Toll Free: +1-855-749-4751
US Toll: +1-415-655-0000
Global call-in numbers: https://go.webex.com/go/globalcallin.php?serviceTyp=
e=3DMC&ED=3D153193777&tollFree=3D1
Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restricti=
ons.pdf

Access code:340 844 711

-------------------------------------------------------
For assistance
-------------------------------------------------------
1. Go to https://go.webex.com/go/mc
2. On the left navigation bar, click "Support".

You can contact me at:
moransar@cisco.com
1-408 566-5647

To update this meeting to your calendar program (for example Microsoft Outl=
ook), click this link:
https://go.webex.com/go/j.php?ED=3D153193777&UID=3D0&ICS=3DMRS1&LD=3D1&RD=
=3D2&ST=3D1&SHA2=3DAAAAARBGrx6g-3G8Y56jVVHaPSruhMgm2a/qNpXPxgH8MS4f&RT=3DMi=
M0


WebEx will automatically setup Meeting Manager for Windows the first time y=
ou join a meeting. To save time, you can setup prior to the meeting by clic=
king this link:
https://go.webex.com/go/meetingcenter/mcsetup.php


The playback of UCF (Universal Communications Format) rich media files requ=
ires appropriate players. To view this type of rich media files in the meet=
ing, please check whether you have the players installed on your computer b=
y going to https://go.webex.com/go/systemdiagnosis.php.

Sign up for a free trial of WebEx
http://www.webex.com/go/mcemfreetrial

http://www.webex.com

CCP:+14156550000x340844711#

IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a=
nd any documents and other materials exchanged or viewed during the session=
 to be recorded. By joining this session, you automatically consent to such=
 recordings. If you do not consent to the recording, discuss your concerns =
with the meeting host prior to the start of the recording or do not join th=
e session. Please note that any such recordings may be subject to discovery=
 in the event of litigation.

--_000_CEC6CCBDBB9FBmoransarciscocom_
Content-Type: text/html; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable









Hi folks,







Just a reminder that the next and las=
t 2013 SCIM WG call is scheduled for Dec. 18th at 11AM Pacific time. <=
span style=3D"font-family: Calibri, sans-serif; ">The agenda is not changed=
 and we will go through all the open issues. Please
 between now and then if have taken any issue and have a proposed text use =
the mailing list so we can get the easy ones out of the way and use the cal=
l time for more challenging issues requiring live discussion.







The WebEx meeting info is not changed, but included here for =
reference.









Also note that we will not have a call on Jan 1st and the next one aft=
er Dec. 18th call will be on Jan. 15th.












Cheers,


Morteza







Topic: SCIM WG bi-weekly call 

Date: Every 2 weeks on Wednesday, from Wednesday, Decemb=
er 4, 2013 to no end date 

Time: 11:00 am, Pacific Standard Time (San Francisco, GM=
T-08:00) 

Meeting Number: 340 844 711 

Meeting Password: (This meeting does not require a passw=
ord.) 





-------------------------------------------------------&=
nbsp;

To join the online meeting (Now from mobile devices!)&nb=
sp;

-------------------------------------------------------&=
nbsp;

1. Go to https://go.webex.com/go/j.php?ED=3D153193777&UID=3D0&RT=3DMiM0<=
/a> 

2. If requested, enter your name and email address. =
;

3. If a password is required, enter the meeting password=
: (This meeting does not require a password.) 

4. Click "Join". 



To view in other time zones or languages, please click t=
he link: 

https://go.webex.com/go/j.php?ED=3D=
153193777&UID=3D0&ORT=3DMiM0 


-------------------------------------------------------&=
nbsp;

To join the audio conference only 

-------------------------------------------------------&=
nbsp;

To receive a call back, provide your phone number when y=
ou join the meeting, or call the number below and enter the access code.&nb=
sp;

US Toll Free: +1-855-749-4751 

US Toll: +1-415-655-0000 
Global call-in numbers: https://go.webex.com/go/globalcal=
lin.php?serviceType=3DMC&ED=3D153193777&tollFree=3D1 

Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf 



Access code:340 844 711 



-------------------------------------------------------&=
nbsp;

For assistance 

-------------------------------------------------------&=
nbsp;

1. Go to https://go.webex.com/go/mc 

2. On the left navigation bar, click "Support"=
. 



You can contact me at: 

moransar@cisco.com 

1-408 566-5647 



To update this meeting to your calendar program (for exa=
mple Microsoft Outlook), click this link: 

htt=
ps://go.webex.com/go/j.php?ED=3D153193777&UID=3D0&ICS=3DMRS1&LD=
=3D1&RD=3D2&ST=3D1&SHA2=3DAAAAARBGrx6g-3G8Y56jVVHaPSruhMgm2a/qN=
pXPxgH8MS4f&RT=3DMiM0 



WebEx will automatically setup Meeting Manager for Windo=
ws the first time you join a meeting. To save time, you can setup prior to =
the meeting by clicking this link: 

https://go.webex.com/go/meetingcenter/mcsetup.php 





The playback of UCF (Universal Communications Format) ri=
ch media files requires appropriate players. To view this type of rich medi=
a files in the meeting, please check
 whether you have the players installed on your computer by going to <=
/span>=
https://go.webex.com/go/systemdiagnosis.php. 



Sign up for a free trial of WebEx 

http://www.webex.com/go/mcemfreetrial <=
/span>



http://www=
.webex.com 



CCP:+14156550000x340844711# 



IMPORTANT NOTICE: This WebEx service includes a feature =
that allows audio and any documents and other materials exchanged or viewed=
 during the session to be recorded.
 By joining this session, you automatically consent to such recordings. If =
you do not consent to the recording, discuss your concerns with the meeting=
 host prior to the start of the recording or do not join the session. Pleas=
e note that any such recordings
 may be subject to discovery in the event of litigation. 




--_000_CEC6CCBDBB9FBmoransarciscocom_--

From phil.hunt@oracle.com  Tue Dec 10 09:28:05 2013
Return-Path: 
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 CC0BD1ADFAB for ; Tue, 10 Dec 2013 09:28:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
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 Bx4bODsMxwyV for ; Tue, 10 Dec 2013 09:28:02 -0800 (PST)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 99E001ADF74 for ; Tue, 10 Dec 2013 09:28:02 -0800 (PST)
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id rBAHRujG030994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 10 Dec 2013 17:27:56 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rBAHRtSU023297 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Dec 2013 17:27:55 GMT
Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rBAHRt87023280; Tue, 10 Dec 2013 17:27:55 GMT
Received: from [192.168.1.12] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 10 Dec 2013 09:27:54 -0800
Content-Type: multipart/alternative; boundary="Apple-Mail=_C69F2FB6-A740-4D43-8F75-B20DDF66A89B"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Phil Hunt 
In-Reply-To: 
Date: Tue, 10 Dec 2013 09:27:51 -0800
Message-Id: 
References: <693755BB-BCB0-4B4C-8091-937FE3AD9B80@oracle.com> 
To: Morteza Ansari (moransar) 
X-Mailer: Apple Mail (2.1510)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: "scim@ietf.org WG" 
Subject: Re: [scim] Aliases and perm resource URLs - is redirect a solution?
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Simple Cloud Identity Management BOF 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Dec 2013 17:28:06 -0000

--Apple-Mail=_C69F2FB6-A740-4D43-8F75-B20DDF66A89B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

FWIW, I just found the following draft which defines 307 (temporary =
redirect) and 308 (perm redirect).
http://tools.ietf.org/html/draft-reschke-http-status-308-07

These new HTTP 307 and 308 responses mirror 302 and 301 except that they =
require the operation to be preserved.  In contrast, 302 and 301 require =
that the HTTP verb be changed to GET or HEAD.

It occurs to me that in addition to support for aliases, the 307 =
temporary redirect may be useful for re-directign clients to a failover =
node or other proxy.

In terms of 308, when applied to "/me" or "/Users/" the 308 =
redirect to where the real operation should be performed.

A 308 might also be used against "/Users/" when a resource =
has moved, changed tenancies, or been assigned a new id (not sure why, =
but seems reasonable).

As for whether a service provider supports a particular alias, I think =
that will be quickly evident to clients since they will not get =
redirects but rather NOT FOUND responses.  It seems reasonable that SPs =
could choose to implement aliases based on almost any unique key they =
choose. It might be reasonable to expect that typically this is just a =
user-id as the issue seems to be one of coordination with other security =
components in the system (e.g. having to map the currently authenticated =
subject to a SCIM resource).

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com

On 2013-12-06, at 12:26 AM, Morteza Ansari (moransar) =
 wrote:

> Speaking as an implementer not as chair:
>=20
> In our implementation we have added the notion of "/users/me" and it =
seems pretty useful. It does not cause a conflict in our implementation =
as our "id" namespace has a very specific format and it is not possible =
to have a "me" as an id.
>=20
> We do not support the second case and I would worry about supporting =
such alias given consumer could start caching that and a change in =
userName could result in invalid link or worse end up pointing to the =
wrong entry.  Using 301 redirect is an interesting notion but as Phil =
suggested it won't address some of the cases.  I am also interested in =
hearing from other implementers on their experience with implementing =
aliases.
>=20
>=20
> Cheers,
> Morteza
>=20
> From: Phil Hunt 
> Date: Thursday, December 5, 2013 11:43 AM
> To: "scim@ietf.org" 
> Subject: [scim] Aliases and perm resource URLs - is redirect a =
solution?
>=20
> I had a casual conversation by email with Kelly and Erik, it seems =
useful to have this discussion with the wider group.
>=20
> Issue:  There is a desire by a lot of developers to support easy URLs, =
supposedly to avoid lookups.  These URLs can be of the form:
>=20
> 1.  To reference the current "subject" in the current security =
context:
> GET https:////v2/Users/me
>=20
> 2.  To reference a user by their user id (MS OData and Google =
Directory do forms of this):
> GET https:////v2/Users/
>=20
> Note that for item 2, it could *easily* be re-expressed as:
> GET https:////v2/Users?filter=3Dusername eq =

>=20
> The catch comes when you want to use those aliases for other =
operations.  Eg. update telephone number for the current user.
>=20
> PATCH https:////v2/Users/me
>=20
> The big concern is we want clients to be using the permenant URL which =
is of the form:
> PATCH https:////v2/Users/
> This is the form that must be used for group membership or any =
reference to the item.
>=20
> A. Support Alias Using Redirects
> It occurs to me that we *might* be able to use redirects.  This causes =
another request response.  But in practice it is not as costly as one =
might think. In practice it is done within the same HTTP connection and =
this is almost as fast (in the same way that browsers re-use connections =
to load hundreds of graphic images etc).
>=20
> Reading 2616, and searching on stackoverflow, etc, it seems that a 301 =
"permanent" redirect fits.  This allows the "alias" to be used, but at =
the same time, it always informs the client that the permanent URL is =
the one that will not change.  In contrast, 302, suggests that the =
client should use the alias since the redirected URL may change in the =
future.
>=20
> The catch is that RFC2616's 3xx introduction states:
> The action
>    required MAY be carried out by the user agent without interaction
>    with the user if and only if the method used in the second request =
is
>    GET or HEAD. A client SHOULD detect infinite redirection loops, =
since
>    such loops generate network traffic for each redirection.
>=20
> In our case we want to *preserve* the action as is. A PATCH should not =
convert to GET, etc. Also, clients SHOULD NOT tolerate more than ONE =
redirect (unless something else needs to be considered due to proxies =
and gateways).
>=20
> The alternatives?
>=20
> B. Aliases Transparently Accepted
> Service Providers could simply accept the request as is and process =
directly. When they return a record, the Location value should always be =
the perm URL rather than the alias.   The downside to this, is the =
tendency to get lazy and use non-perm URLs that may change (particularly =
those using a user-id).
>=20
> C. Aliases Not Supported
> All operations must be based on immutable perm URLs.  This may often =
require the clients to remember perm URLs (or obtain them through the =
access token, etc).  Or the client apps must do a query before modify =
step.  This isn't that unusual.  This happened in LDAP all the time.  =
However, in LDAP this lead to a lot of desire to hard code predictive =
DNs creating a lot of incompatibility (I made a lot of money fixing =
these issues).   For many it would mean pressure to use record =
identifiers based on a login id rather than a guid.
>=20
> I don't really have a particular strong position on any of these. But =
I do think we need to include in the api document a clarification on =
"redirects" one way or the other. If we leave this unspecified, you =
could see clients having to deal with a wide variety of interpretation =
here. =20
>=20
> I do see some positives in supporting aliases if only because major =
providers like MS, Facebook, and Google are already doing it.  It might =
be useful for them to share the postives/negatives of their experience =
if possible. Does this lead to problems with multiple ways to reference =
objects?
>=20
> Everyone's input appreciated. I'll volunteer to assemble any comments =
back into a ticket next week.
>=20
> Phil
>=20
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>=20


--Apple-Mail=_C69F2FB6-A740-4D43-8F75-B20DDF66A89B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

FWIW, =
I just found the following draft which defines 307 (temporary redirect) =
and 308 (perm redirect).

<=
/div>
These new HTTP 307 and 308 responses mirror 302 and 301 except =
that they require the operation to be preserved.  In contrast, 302 =
and 301 require that the HTTP verb be changed to GET or =
HEAD.

It occurs to me that in addition to =
support for aliases, the 307 temporary redirect may be useful for =
re-directign clients to a failover node or other =
proxy.

In terms of 308, when applied to "/me" =
or "/Users/<somealias>" the 308 redirect to where the real =
operation should be performed.

A 308 might also =
be used against "/Users/<resource-id>" when a resource has moved, =
changed tenancies, or been assigned a new id (not sure why, but seems =
reasonable).

As for whether a service provider =
supports a particular alias, I think that will be quickly evident to =
clients since they will not get redirects but rather NOT FOUND =
responses.  It seems reasonable that SPs could choose to implement =
aliases based on almost any unique key they choose. It might be =
reasonable to expect that typically this is just a user-id as the issue =
seems to be one of coordination with other security components in the =
system (e.g. having to map the currently authenticated subject to a SCIM =
resource).




On 2013-12-06, at 12:26 AM, Morteza Ansari (moransar) =
<moransar@cisco.com> =
wrote:








Speaking as an implementer not as chair:







In our implementation we have added the notion of "/users/me" and =
it seems pretty useful. It does not cause a conflict in our =
implementation as our "id" namespace has a very specific format and it =
is not possible to have a "me" as an id.







We do not support the second case and I would worry about =
supporting such alias given consumer could start caching that and a =
change in userName could result in invalid link or worse end up pointing =
to the wrong entry.  Using 301 redirect is an interesting
 notion but as Phil suggested it won't address some of the cases. =
 I am also interested in hearing from other implementers on their =
experience with implementing aliases.












Cheers,


Morteza









From: Phil Hunt <phil.hunt@oracle.com>

Date: Thursday, December 5, 2013 =
11:43 AM

To: "scim@ietf.org" <scim@ietf.org>

Subject: [scim] Aliases and perm =
resource URLs - is redirect a solution?












I had a casual conversation by email with Kelly and Erik, it seems =
useful to have this discussion with the wider group.






Issue:  There is a desire by a lot of developers to support =
easy URLs, supposedly to avoid lookups.  These URLs can be of the =
form:







1.  To reference the current "subject" in the current security =
context:








2.  To reference a user by their user id (MS OData and Google =
Directory do forms of this):








Note that for item 2, it could *easily* be re-expressed as:










The catch comes when you want to use those aliases for other =
operations.  Eg. update telephone number for the current =
user.













The big concern is we want clients to be using the permenant URL =
which is of the form:



This is the form that must be used for group membership or any =
reference to the item.







A. Support Alias Using Redirects


It occurs to me that we *might* be able to use redirects. =
 This causes another request response.  But in practice it is =
not as costly as one might think. In practice it is done within the same =
HTTP connection and this is almost as fast (in the same way
 that browsers re-use connections to load hundreds of graphic images =
etc).







Reading 2616, and searching on stackoverflow, etc, it seems that a =
301 "permanent" redirect fits.  This allows the "alias" to be used, =
but at the same time, it always informs the client that the permanent =
URL is the one that will not change.  In contrast,
 302, suggests that the client should use the alias since the redirected =
URL may change in the future.







The catch is that RFC2616's 3xx introduction states:




The action
   required MAY be carried out by the user agent without interaction
   with the user if and only if the method used in the second request is
   GET or HEAD. A client SHOULD detect infinite redirection loops, since
   such loops generate network traffic for each redirection.









In our case we want to *preserve* the action as is. A PATCH should =
not convert to GET, etc. Also, clients SHOULD NOT tolerate more than ONE =
redirect (unless something else needs to be considered due to proxies =
and gateways).







The alternatives?







B. Aliases Transparently Accepted


Service Providers could simply accept the request as is and process =
directly. When they return a record, the Location value should always be =
the perm URL rather than the alias.   The downside to this, is the =
tendency to get lazy and use non-perm URLs that
 may change (particularly those using a user-id).







C. Aliases Not Supported


All operations must be based on immutable perm URLs.  This may =
often require the clients to remember perm URLs (or obtain them through =
the access token, etc).  Or the client apps must do a query before =
modify step.  This isn't that unusual.  This happened
 in LDAP all the time.  However, in LDAP this lead to a lot of =
desire to hard code predictive DNs creating a lot of incompatibility (I =
made a lot of money fixing these issues).   For many it would mean =
pressure to use record identifiers based on a login id
 rather than a guid.







I don't really have a particular strong position on any of these. =
But I do think we need to include in the api document a clarification on =
"redirects" one way or the other. If we leave this unspecified, you =
could see clients having to deal with a wide
 variety of interpretation here.  







I do see some positives in supporting aliases if only because major =
providers like MS, Facebook, and Google are already doing it.  It =
might be useful for them to share the postives/negatives of their =
experience if possible. Does this lead to problems with
 multiple ways to reference objects?







Everyone's input appreciated. I'll volunteer to assemble any =
comments back into a ticket next week.





















=

--Apple-Mail=_C69F2FB6-A740-4D43-8F75-B20DDF66A89B--

From randomshelley@gmail.com  Tue Dec 10 15:25:56 2013
Return-Path: 
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 AD66A1AE2A1 for ; Tue, 10 Dec 2013 15:25:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
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 UALNjo66KZJq for ; Tue, 10 Dec 2013 15:25:54 -0800 (PST)
Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 23C261AE147 for ; Tue, 10 Dec 2013 15:25:54 -0800 (PST)
Received: by mail-ie0-f170.google.com with SMTP id qd12so9984943ieb.29 for ; Tue, 10 Dec 2013 15:25:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=C4RJOZS8WgJ4ZTHc1CQcUAdgdTM9+5zxdXsuTc8atIs=; b=UphMaxwBpY0pTQFTtCHCiy2WPW0aa+8+yjzN7qhPsU2ntKH2O2VcIKuRpNi8m+E7/r oNKTxTJmjzNMUKm0gSGAgWyvTWp0B+K4e/zWAhbtO1o2DozQTy4LiqgGhdRww+jbMo71 27kVzqDOpAqOtj7nC6pNizi286/dsC/dEIR8MVuN530a6AMkQS8jOgs/PBOSmyrQYVOZ mIzbeOOyL6SCJzHg3umKMJttHfxFZjHes+iHzkWojWlDfctn2/mrtXSlsMnWUpCcQxP7 izypq//CFl4AfSjO3V9isiZjvbigHnIGrY7B+Vhep//WqyNMshgS2iuswjPRMaDB5397 5z3g==
MIME-Version: 1.0
X-Received: by 10.42.214.202 with SMTP id hb10mr89036icb.76.1386717948259; Tue, 10 Dec 2013 15:25:48 -0800 (PST)
Received: by 10.64.61.170 with HTTP; Tue, 10 Dec 2013 15:25:48 -0800 (PST)
In-Reply-To: 
References: 
Date: Tue, 10 Dec 2013 17:25:48 -0600
Message-ID: 
From: Shelley 
To: "scim@ietf.org" 
Content-Type: multipart/alternative; boundary=20cf301cc3b2b5b26d04ed366e8f
Subject: Re: [scim] Group Display Name Uniqueness
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Simple Cloud Identity Management BOF 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Dec 2013 23:25:56 -0000

--20cf301cc3b2b5b26d04ed366e8f
Content-Type: text/plain; charset=ISO-8859-1

The lack of a unique attribute in the Group resource still seems to
represent a bit of a gap and inconsistency in the core schema and this
appears to be an outstanding concern as noted by this and other discussions
which remain open [1,2,3].

The SCIM id is an immutable, provider-generated ID and the externalId is
consumer-specific. As such, neither of these are appropriate candidates for
defining a semantic contract between multiple consumers and SPs without the
use of an extension or separate process. The lack of a required, unique
attribute can limit both systems and human abilities to differentiate
between groups and derive meaning from them.

Dale's proposal to introduce "groupName" [1] seems reasonable to help
mitigate this concern, although this will not help our 1.1 implementation.
As mentioned, our SCIM 1.1 SP implementation currently requires the group
displayName to be unique to help fill this gap, although we're considering
using custom extensions in addition to/instead of the unique displayName.
Admittedly, requiring a "display name" to be unique doesn't seem completely
appropriate; however, given that it is the only required attribute for
groups, it seems like a reasonable option and the least disruptive place to
put a unique constraint.

Any further thoughts on this topic or practical examples of how other SCIM
implementations handle groups -particularly, if/how groups with duplicate
displayNames are reconciled/differentiated and how semantic meaning is
derived- would be appreciated.

[1] http://www.ietf.org/mail-archive/web/scim/current/msg00698.html
[2] http://www.ietf.org/mail-archive/web/scim/current/msg01253.html
[3] http://storm.alert.sk/blog/2012/04/13/SCIMming-the-Surface #15



On Wed, Jul 24, 2013 at 9:51 AM, Shelley  wrote:

> Should the group "displayName" attribute be UNIQUE?
>
> This would be more inline with requiring the user "userName" attribute to
> be unique, and seems reasonable - what value is there in having multiple
> different groups with the same name without a guaranteed differentiation
> between them aside from a provider-generated ID?
>
> (For what it's worth, for these reasons our SCIM SP implementation already
> requires group displayNames to be UNIQUE such that they behave similarly to
> user userNames.)
>

--20cf301cc3b2b5b26d04ed366e8f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


The lack of a unique attribute in the Group resource still=
 seems to represent a bit of a gap and inconsistency in the core schema and=
 this appears to be an outstanding concern as noted by this and other discu=
ssions which remain open [1,2,3].



The SCIM id is an immutable, provider-generated ID=
=20
and the externalId is consumer-specific. As such, neither of these are appr=
opriate candidates for defining a semantic contract between multiple consum=
ers and SPs without the use of an extension or separate process. The lack o=
f a required, unique attribute can limit both systems and human abilities t=
o differentiate between groups and derive meaning from them.


Dale's proposal to introduce "groupName" [1] seems reason=
able to help mitigate this concern, although this will not help our 1.1 imp=
lementation. As mentioned, our SCIM 1.1 SP implementation currently require=
s the group displayName to be unique to help fill this gap, although we'=
;re considering using custom extensions in addition to/instead of the uniqu=
e displayName. Admittedly, requiring a "display name" to be uniqu=
e doesn't seem completely appropriate; however, given that it is the on=
ly required attribute for groups, it seems like a reasonable option and the=
 least disruptive place to put a unique constraint.


Any further thoughts on this topic or practical examples of how other S=
CIM implementations handle groups -particularly, if/how groups with duplica=
te displayNames are reconciled/differentiated and how semantic meaning is d=
erived- would be appreciated.





On Wed, Jul 24, 2013 at 9:51 AM, Shelley <randomshelley@gmail.com> wrote:


Should the group "displayName" attribute be=
 UNIQUE?

This would be more inline with requiring the user "use=
rName" attribute to be unique, and seems reasonable - what value is th=
ere in having multiple different groups with the same name without a guaran=
teed differentiation between them aside from a provider-generated ID?



(For what it's worth, for these reasons our SCIM SP impl=
ementation already requires group displayNames to be UNIQUE such that they =
behave similarly to user userNames.)





--20cf301cc3b2b5b26d04ed366e8f--

From shivang@totvslabs.com  Tue Dec 10 16:45:26 2013
Return-Path: 
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 A37C91AE2E8 for ; Tue, 10 Dec 2013 16:45:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 249kbswmtZne for ; Tue, 10 Dec 2013 16:45:24 -0800 (PST)
Received: from mail-vc0-f175.google.com (mail-vc0-f175.google.com [209.85.220.175]) by ietfa.amsl.com (Postfix) with ESMTP id 26A291ADFC0 for ; Tue, 10 Dec 2013 16:45:24 -0800 (PST)
Received: by mail-vc0-f175.google.com with SMTP id ld13so5162002vcb.34 for ; Tue, 10 Dec 2013 16:45:18 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=m3/cWjclLI2bUPbqUT2BWuolzQTrjYmdm8vDgoELMVU=; b=JgEbR9b9bmStKhtH2EtkRH4LoGfU2okqlJiVv9fgaV+/pgBqLMBBZgW2A7UcjaYADh y50gPD0v3hWbz72rSejskDf1VtTA6Ydv64w/x90QNw0ZZ2OsvOoNvJdRvbgDDHrKirfC a9yutkWbG28x8RivzUSZ178jX2IhBFRJ/n9mhZ/09Gr+p2tL50Xb+oRYcn0LJKRME1/k 4e+wKftl/kMTp/WBZdmn23ByiSTOZs9LjStVLXnB4tHDRGVhY8rdR46wIANU5NJH9QGi AFl90kus3gE0E4+qnaaqF96C7fHG3QwFKruCOhwsXlYCjsdQ8H+VGzIgRzoZqu2dgktj bBxQ==
X-Gm-Message-State: ALoCoQnHKjiPAxmQ0g+ExzmnmcJY+ghAZqgxSK0lLM32tFuPoROXIhVXmk5sUMgpgi2i698tmmns
MIME-Version: 1.0
X-Received: by 10.58.233.98 with SMTP id tv2mr15002610vec.11.1386722718506; Tue, 10 Dec 2013 16:45:18 -0800 (PST)
Received: by 10.58.246.33 with HTTP; Tue, 10 Dec 2013 16:45:18 -0800 (PST)
Date: Tue, 10 Dec 2013 16:45:18 -0800
Message-ID: 
From: Shivang Shah 
To: scim@ietf.org
Content-Type: multipart/alternative; boundary=089e0115ef9c09f5ab04ed378bca
Subject: [scim] Questions regarding SCIM endpoints and other extended Resources in SCIM
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Simple Cloud Identity Management BOF 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Dec 2013 00:45:26 -0000

--089e0115ef9c09f5ab04ed378bca
Content-Type: text/plain; charset=ISO-8859-1

Hi Everyone,

(Apologize if this is double posting ! I posted previously before I was
subscribed to the listing!)

I had couple of questions regarding the SCIM api endpoints discussed here :
http://www.simplecloud.info/specs/draft-scim-api-01.html and I thought this
might be a good place to start with.

In the specs I see the following :

"The SCIM protocol specifies well known endpoints and HTTP methods for
managing Resources defined in the core schema; i.e., User and Group
Resources correspond to /Users and /Groups respectively. Service Providers
that support extended Resources SHOULD define Resource endpoints using the
established convention; pluralize the Resource name defined in the extended
schema by appending an 's'. Given there are cases where Resource
pluralization is ambiguous; e.g., a Resource named 'person' is legitimately
'persons' and 'people' Consumers SHOULD discover Resource endpoints via the
Schema Sub-Attribute 'endpoint'. "

What I don't understand is the following:

1) I have never seen Capitalization of the Resource name before. Is this
something new for SCIM? Urls in browsers (urls anywhere for that matter)
are by default case insensitive and it doesn't matter if we capitalize it
or not. My real question would be is capitalizing the Resource name a part
of the spec or just an example?
2) (This might be bit more of a mesh up question between REST spec and
SCIM). We have a scenario where a user HAS "favorites". There are 2 ways we
can handle this:

/scim/v1/users/{userId}/favorites (we can call this an extended
sub-resource)

OR

/scim/favorites/users/{userId} (we can all this an extended resource
"favorites").

>From the url perspective both seem to be right but what I don't know is
which one is more suitable according to SCIM (and maybe REST? )
specifications. And a follow up question to that might be, do the extended
resources have to be capitalized as well?

All help is appreciated! I am new to implementing and understanding SCIM,
so please forgive me if I have missed some subtle pointers in the
specifications itself!

Cheers and looking forward to any answers that can help me understand this!

--089e0115ef9c09f5ab04ed378bca
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Hi Everyone,

(Apologize if this is doubl=
e posting ! I posted previously before I was subscribed to the listing!)
I had couple of questions regarding the SCIM api endpoints discus=
sed here : http://www.simplecloud.info/specs/draft-scim-api-01.=
html and I thought this might be a good place to start with.



In the specs I see the following : 

"The SCIM protocol spec=
ifies well known endpoints and HTTP methods for managing Resources defined =
in the
                core schema; i.e., User and Group Resources correspond to /=
Users and /Groups respectively.  Service Providers
                that support extended Resources SHOULD define Resource endp=
oints using the established convention; pluralize
                the Resource name defined in the extended schema by appendi=
ng an 's'.  Given there are cases where Resource
                pluralization is ambiguous; e.g., a Resource named 'per=
son' is legitimately 'persons' and 'people' Consumers
                SHOULD discover Resource endpoints via the Schema Sub-Attri=
bute 'endpoint'.
           =20
"

What I don't understand is the following:

1) I hav=
e=20
never seen Capitalization of the Resource name before. Is this something
 new for SCIM? Urls in browsers (urls anywhere for that matter) are by=20
default case insensitive and it doesn't matter if we capitalize it or=
=20
not. My real question would be is capitalizing the Resource name a part=20
of the spec or just an example?
2) (This might be bit more of a mesh=20
up question between REST spec and SCIM). We have a scenario where a user
 HAS "favorites". There are 2 ways we can handle this: 

/s=
cim/v1/users/{userId}/favorites (we can call this an extended sub-resource)=

=A0
OR

/scim/favorites/users/{userId} (we can all this an ext=
ended resource "favorites"). 



From
 the url perspective both seem to be right but what I don't know is=20
which one is more suitable according to SCIM (and maybe REST? )=20
specifications. And a follow up question to that might be, do the=20
extended resources have to be capitalized as well?

All help is=20
appreciated! I am new to implementing and understanding SCIM, so please=20
forgive me if I have missed some subtle pointers in the specifications=20
itself!

Cheers and looking forward to any answers that can help me u=
nderstand this!


--089e0115ef9c09f5ab04ed378bca--

From shivang@totvslabs.com  Tue Dec 10 17:15:37 2013
Return-Path: 
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 69A181AE09B for ; Tue, 10 Dec 2013 17:15:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 JIO1-B_WrQ0O for ; Tue, 10 Dec 2013 17:15:34 -0800 (PST)
Received: from mail-vc0-f178.google.com (mail-vc0-f178.google.com [209.85.220.178]) by ietfa.amsl.com (Postfix) with ESMTP id BC3FD1AE049 for ; Tue, 10 Dec 2013 17:15:34 -0800 (PST)
Received: by mail-vc0-f178.google.com with SMTP id lh4so5105973vcb.23 for ; Tue, 10 Dec 2013 17:15:29 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=+5emDAw3cvUQ83cvALb3Uta0Tb2tsIn8koSNY70ufdM=; b=HT4QIz3VbS4+pZYuync7Gn9/tjqhea0yeBo9vVLATiLoKKXv2N53qWa4DyxrmnFCTl cO90NTmvd84vE8+KK8NnIRArdJ7zb+BBRn6ZqL7xB53RRhTWWg/GadMPI2SWLWF2zzVw KJuSyC5dKpHeXEPKFq/2P8YgTUQq5Gmmq8dWADg4sVXvlmsiKKKFegMMRHcwxDQZGJ3s VrTthuBIbohuoDwe0oiBAEFxIiMEhb52r4kquUYmKwqzmTcHdBkE/DhR3leAWkbhUt9x aA28IAJGHlI2mJex20iJqCPfLNeavMsC8oaYdtTgmF4MF2xdpZoE+7GOqYogbiYGH9qk n86A==
X-Gm-Message-State: ALoCoQlYFes0jXzew5uhTpWZsbGFb2arTwTB7x9sEx2odqCdbqNaHQ+Ny4vEU5s4o8jBmytqpad+
MIME-Version: 1.0
X-Received: by 10.58.37.67 with SMTP id w3mr2296269vej.22.1386724529124; Tue, 10 Dec 2013 17:15:29 -0800 (PST)
Received: by 10.58.246.33 with HTTP; Tue, 10 Dec 2013 17:15:29 -0800 (PST)
In-Reply-To: 
References: 
Date: Tue, 10 Dec 2013 17:15:29 -0800
Message-ID: 
From: Shivang Shah 
To: scim@ietf.org
Content-Type: multipart/alternative; boundary=089e013a0d42f5d31a04ed37f626
Subject: Re: [scim] Questions regarding SCIM endpoints and other extended Resources in SCIM
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Simple Cloud Identity Management BOF 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Dec 2013 01:15:37 -0000

--089e013a0d42f5d31a04ed37f626
Content-Type: text/plain; charset=ISO-8859-1

I will probably reply back to the my question because I just came across
the URL standards and it does seem that I was mis-informed about urls not
being case sensitive.

http://www.w3.org/TR/WD-html40-970708/htmlweb.html

Now considering the fact that they indeed ARE case sensitive, I was
wondering if it would make more sense to clients and developers to always
use lower cases in standards (especially when the browsers themselves
convert everything to lower case). It's my suggestion as a developer who
plans to implement SCIM. It just makes more sense.


On Tue, Dec 10, 2013 at 4:45 PM, Shivang Shah  wrote:

> Hi Everyone,
>
> (Apologize if this is double posting ! I posted previously before I was
> subscribed to the listing!)
>
> I had couple of questions regarding the SCIM api endpoints discussed here
> : http://www.simplecloud.info/specs/draft-scim-api-01.html and I thought
> this might be a good place to start with.
>
> In the specs I see the following :
>
> "The SCIM protocol specifies well known endpoints and HTTP methods for
> managing Resources defined in the core schema; i.e., User and Group
> Resources correspond to /Users and /Groups respectively. Service Providers
> that support extended Resources SHOULD define Resource endpoints using the
> established convention; pluralize the Resource name defined in the extended
> schema by appending an 's'. Given there are cases where Resource
> pluralization is ambiguous; e.g., a Resource named 'person' is legitimately
> 'persons' and 'people' Consumers SHOULD discover Resource endpoints via the
> Schema Sub-Attribute 'endpoint'. "
>
> What I don't understand is the following:
>
> 1) I have never seen Capitalization of the Resource name before. Is this
> something new for SCIM? Urls in browsers (urls anywhere for that matter)
> are by default case insensitive and it doesn't matter if we capitalize it
> or not. My real question would be is capitalizing the Resource name a part
> of the spec or just an example?
> 2) (This might be bit more of a mesh up question between REST spec and
> SCIM). We have a scenario where a user HAS "favorites". There are 2 ways we
> can handle this:
>
> /scim/v1/users/{userId}/favorites (we can call this an extended
> sub-resource)
>
>
> OR
>
> /scim/favorites/users/{userId} (we can all this an extended resource
> "favorites").
>
> From the url perspective both seem to be right but what I don't know is
> which one is more suitable according to SCIM (and maybe REST? )
> specifications. And a follow up question to that might be, do the extended
> resources have to be capitalized as well?
>
> All help is appreciated! I am new to implementing and understanding SCIM,
> so please forgive me if I have missed some subtle pointers in the
> specifications itself!
>
> Cheers and looking forward to any answers that can help me understand this!
>

--089e013a0d42f5d31a04ed37f626
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


I will probably reply back to the my question because=
 I just came across the URL standards and it does seem that I was mis-infor=
med about urls not being case sensitive. 

http://www.w3.org/TR/WD-html40-970708/=
htmlweb.html


Now considering the fact that they indeed ARE case sensitive, I w=
as wondering if it would make more sense to clients and developers to alway=
s use lower cases in standards (especially when the browsers themselves con=
vert everything to lower case). It's my suggestion as a developer who p=
lans to implement SCIM. It just makes more sense. 




On Tue,=
 Dec 10, 2013 at 4:45 PM, Shivang Shah <shivang@totvslabs.com><=
/span> wrote:


Hi Everyone,

(Apologize if this is double posting ! I posted previously before I was=
 subscribed to the listing!)


I had couple of questions regarding the SCIM api=
 endpoints discussed here : http://www.simplecloud.info/specs/d=
raft-scim-api-01.html and I thought this might be a good place to start=
 with.




In the specs I see the following : 

"The SCIM protocol spec=
ifies well known endpoints and HTTP methods for managing Resources defined =
in the
                core schema; i.e., User and Group Resources correspond to /=
Users and /Groups respectively.  Service Providers
                that support extended Resources SHOULD define Resource endp=
oints using the established convention; pluralize
                the Resource name defined in the extended schema by appendi=
ng an 's'.  Given there are cases where Resource
                pluralization is ambiguous; e.g., a Resource named 'per=
son' is legitimately 'persons' and 'people' Consumers
                SHOULD discover Resource endpoints via the Schema Sub-Attri=
bute 'endpoint'.
           =20
"

What I don't understand is the following:

1) I hav=
e=20
never seen Capitalization of the Resource name before. Is this something
 new for SCIM? Urls in browsers (urls anywhere for that matter) are by=20
default case insensitive and it doesn't matter if we capitalize it or=
=20
not. My real question would be is capitalizing the Resource name a part=20
of the spec or just an example?
2) (This might be bit more of a mesh=20
up question between REST spec and SCIM). We have a scenario where a user
 HAS "favorites". There are 2 ways we can handle this: 

/scim/v1/users/{userId}/favorites (we can call this an extended sub-res=
ource)

=A0
OR

/scim/favorites/users/{userId}=
 (we can all this an extended resource "favorites"). 




From
 the url perspective both seem to be right but what I don't know is=20
which one is more suitable according to SCIM (and maybe REST? )=20
specifications. And a follow up question to that might be, do the=20
extended resources have to be capitalized as well?

All help is=20
appreciated! I am new to implementing and understanding SCIM, so please=20
forgive me if I have missed some subtle pointers in the specifications=20
itself!

Cheers and looking forward to any answers that can help me u=
nderstand this!





--089e013a0d42f5d31a04ed37f626--

From phil.hunt@oracle.com  Tue Dec 10 19:07:40 2013
Return-Path: 
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 B17C51AE108 for ; Tue, 10 Dec 2013 19:07:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
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 vcUgRb1Lh32q for ; Tue, 10 Dec 2013 19:07:37 -0800 (PST)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 8A3541AE10B for ; Tue, 10 Dec 2013 19:07:37 -0800 (PST)
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id rBB37UnS024576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 Dec 2013 03:07:31 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rBB37TGo023972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Dec 2013 03:07:30 GMT
Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rBB37Tv3017896; Wed, 11 Dec 2013 03:07:29 GMT
Received: from [192.168.1.125] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 10 Dec 2013 19:07:29 -0800
References:  
Mime-Version: 1.0 (1.0)
In-Reply-To: 
Content-Type: multipart/alternative; boundary=Apple-Mail-2101EEC6-B2E0-4538-8A16-A936716CB31A
Content-Transfer-Encoding: 7bit
Message-Id: <5BE47AC2-DAA1-4BE9-870B-CF5C94338630@oracle.com>
X-Mailer: iPhone Mail (11B554a)
From: Phil Hunt 
Date: Tue, 10 Dec 2013 19:07:27 -0800
To: Shivang Shah 
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "scim@ietf.org" 
Subject: Re: [scim] Questions regarding SCIM endpoints and other extended Resources in SCIM
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Simple Cloud Identity Management BOF 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Dec 2013 03:07:41 -0000

--Apple-Mail-2101EEC6-B2E0-4538-8A16-A936716CB31A
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

I am not sure what you have been looking at but most examples I have seen us=
e proper case names for object types in REST. I don't think it is a hard rul=
e-just what I have seen.=20

However the spec so far is clear on proper case usage for scim. If your serv=
er lowercases things it would cause it to have restore case on out output (e=
g location).=20

For me, I don't see a real reason to change case at this time.=20

Phil

> On Dec 10, 2013, at 17:15, Shivang Shah  wrote:
>=20
> I will probably reply back to the my question because I just came across t=
he URL standards and it does seem that I was mis-informed about urls not bei=
ng case sensitive.=20
>=20
> http://www.w3.org/TR/WD-html40-970708/htmlweb.html
>=20
> Now considering the fact that they indeed ARE case sensitive, I was wonder=
ing if it would make more sense to clients and developers to always use lowe=
r cases in standards (especially when the browsers themselves convert everyt=
hing to lower case). It's my suggestion as a developer who plans to implemen=
t SCIM. It just makes more sense.=20
>=20
>=20
>> On Tue, Dec 10, 2013 at 4:45 PM, Shivang Shah  wro=
te:
>> Hi Everyone,
>>=20
>> (Apologize if this is double posting ! I posted previously before I was s=
ubscribed to the listing!)
>>=20
>> I had couple of questions regarding the SCIM api endpoints discussed here=
 : http://www.simplecloud.info/specs/draft-scim-api-01.html and I thought th=
is might be a good place to start with.
>>=20
>> In the specs I see the following :=20
>>=20
>> "The SCIM protocol specifies well known endpoints and HTTP methods for ma=
naging Resources defined in the core schema; i.e., User and Group Resources c=
orrespond to /Users and /Groups respectively. Service Providers that support=
 extended Resources SHOULD define Resource endpoints using the established c=
onvention; pluralize the Resource name defined in the extended schema by app=
ending an 's'. Given there are cases where Resource pluralization is ambiguo=
us; e.g., a Resource named 'person' is legitimately 'persons' and 'people' C=
onsumers SHOULD discover Resource endpoints via the Schema Sub-Attribute 'en=
dpoint'. "
>>=20
>> What I don't understand is the following:
>>=20
>> 1) I have never seen Capitalization of the Resource name before. Is this s=
omething new for SCIM? Urls in browsers (urls anywhere for that matter) are b=
y default case insensitive and it doesn't matter if we capitalize it or not.=
 My real question would be is capitalizing the Resource name a part of the s=
pec or just an example?
>> 2) (This might be bit more of a mesh up question between REST spec and SC=
IM). We have a scenario where a user HAS "favorites". There are 2 ways we ca=
n handle this:=20
>>=20
>> /scim/v1/users/{userId}/favorites (we can call this an extended sub-resou=
rce)
>>=20
>> =20
>> OR
>>=20
>> /scim/favorites/users/{userId} (we can all this an extended resource "fav=
orites").=20
>>=20
>> =46rom the url perspective both seem to be right but what I don't know is=
 which one is more suitable according to SCIM (and maybe REST? ) specificati=
ons. And a follow up question to that might be, do the extended resources ha=
ve to be capitalized as well?
>>=20
>> All help is appreciated! I am new to implementing and understanding SCIM,=
 so please forgive me if I have missed some subtle pointers in the specifica=
tions itself!
>>=20
>> Cheers and looking forward to any answers that can help me understand thi=
s!
>=20
> _______________________________________________
> scim mailing list
> scim@ietf.org
> https://www.ietf.org/mailman/listinfo/scim

--Apple-Mail-2101EEC6-B2E0-4538-8A16-A936716CB31A
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


I am not sure what you have been looki=
ng at but most examples I have seen use proper case names for object types i=
n REST. I don't think it is a hard rule-just what I have seen. 

However the spec so far is clear on proper case usage for s=
cim. If your server lowercases things it would cause it to have restore case=
 on out output (eg location). 

For me, I don't=
 see a real reason to change case at this time. 

Phil

On Dec 10, 2013, at 17:15, Shivang Shah <shivang@totvslabs.com> wrote:

I will probably reply back to=
 the my question because I just came across the URL standards and it does se=
em that I was mis-informed about urls not being case sensitive. 

http://www.w3.org=
/TR/WD-html40-970708/htmlweb.html


Now considering the fact that they indeed ARE case sensitive, I wa=
s wondering if it would make more sense to clients and developers to always u=
se lower cases in standards (especially when the browsers themselves convert=
 everything to lower case). It's my suggestion as a developer who plans to i=
mplement SCIM. It just makes more sense. 




On Tue, D=
ec 10, 2013 at 4:45 PM, Shivang Shah <shivang@totvslabs.com> wrote:


Hi Everyone,

(Apologize if this is double posting ! I posted previously before I was su=
bscribed to the listing!)


I had couple of questions regarding the SCIM api e=
ndpoints discussed here : http://www.simplecloud.info/specs/draft=
-scim-api-01.html and I thought this might be a good place to start with=
.




In the specs I see the following : 

"The SCIM protocol specifies w=
ell known endpoints and HTTP methods for managing Resources defined in the
                core schema; i.e., User and Group Resources correspond to /U=
sers and /Groups respectively.  Service Providers
                that support extended Resources SHOULD define Resource endpo=
ints using the established convention; pluralize
                the Resource name defined in the extended schema by appendin=
g an 's'.  Given there are cases where Resource
                pluralization is ambiguous; e.g., a Resource named 'person' i=
s legitimately 'persons' and 'people' Consumers
                SHOULD discover Resource endpoints via the Schema Sub-Attrib=
ute 'endpoint'.
           =20
"

What I don't understand is the following:

1) I have=20
never seen Capitalization of the Resource name before. Is this something
 new for SCIM? Urls in browsers (urls anywhere for that matter) are by=20
default case insensitive and it doesn't matter if we capitalize it or=20
not. My real question would be is capitalizing the Resource name a part=20
of the spec or just an example?
2) (This might be bit more of a mesh=20
up question between REST spec and SCIM). We have a scenario where a user
 HAS "favorites". There are 2 ways we can handle this: 

/scim/v=
1/users/{userId}/favorites (we can call this an extended sub-resource)

 
OR

/scim/favorites/users/{userId} (we can a=
ll this an extended resource "favorites"). 




From
 the url perspective both seem to be right but what I don't know is=20
which one is more suitable according to SCIM (and maybe REST? )=20
specifications. And a follow up question to that might be, do the=20
extended resources have to be capitalized as well?

All help is=20
appreciated! I am new to implementing and understanding SCIM, so please=20
forgive me if I have missed some subtle pointers in the specifications=20
itself!

Cheers and looking forward to any answers that can help me un=
derstand this!





____________________=
___________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman=
/listinfo/scim
=

--Apple-Mail-2101EEC6-B2E0-4538-8A16-A936716CB31A--

From shivang@totvslabs.com  Tue Dec 10 20:09:26 2013
Return-Path: 
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 5D77B1AE0C5 for ; Tue, 10 Dec 2013 20:09:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.377
X-Spam-Level: 
X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-0.7] 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 ETjKoGoazsyG for ; Tue, 10 Dec 2013 20:09:23 -0800 (PST)
Received: from mail-vc0-f178.google.com (mail-vc0-f178.google.com [209.85.220.178]) by ietfa.amsl.com (Postfix) with ESMTP id DA7CA1ADF8A for ; Tue, 10 Dec 2013 20:09:22 -0800 (PST)
Received: by mail-vc0-f178.google.com with SMTP id lh4so5199985vcb.23 for ; Tue, 10 Dec 2013 20:09:17 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=aQO83gutIQvf8o4O+uqnwEG1qJ5qo96zFZ4AebYyeTo=; b=Eh4L8pHAi8ArSormI4trDvaX/tQS5HHtaUHs2WTykXWd2dF4sY9/f6q95lKv8Q5aSb 1XxZL6Exk9Gj4GDgzTaJlPKq909DicTXzTiMlckBpvnhxCJHoutTiX7YiFlWFdN1WR7f 6yfTVZQgmHItBvSLW/uzyAoyprMmC3v4D2AlkjskKeVtNJTbenjxLm8YMV5U9s1x0xPC dyGsMuBQCQCwYLVG893t5UqKLIprZnRLgPFQuXeOnli5x07swQywGkgytaydRZafCyNO Pu0hrNzjz9guFrkXrxNNDUfAfsLeimjT6ei7jmsN5zFOR3gJqaJiCJqIqIxX7N78/w8H GWGQ==
X-Gm-Message-State: ALoCoQlUgJhhAFTaf++ehn4KPGZpVNjv+0jTXahf/th77JfdSpIazO5qxlEzwZlhXcey7rs7nGdM
MIME-Version: 1.0
X-Received: by 10.58.118.84 with SMTP id kk20mr1856128veb.26.1386734957044; Tue, 10 Dec 2013 20:09:17 -0800 (PST)
Received: by 10.58.246.33 with HTTP; Tue, 10 Dec 2013 20:09:16 -0800 (PST)
In-Reply-To: <5BE47AC2-DAA1-4BE9-870B-CF5C94338630@oracle.com>
References:   <5BE47AC2-DAA1-4BE9-870B-CF5C94338630@oracle.com>
Date: Tue, 10 Dec 2013 20:09:16 -0800
Message-ID: 
From: Shivang Shah 
To: Phil Hunt 
Content-Type: multipart/alternative; boundary=089e0122a08683955804ed3a6492
Cc: "scim@ietf.org" 
Subject: Re: [scim] Questions regarding SCIM endpoints and other extended Resources in SCIM
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Simple Cloud Identity Management BOF 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Dec 2013 04:09:26 -0000

--089e0122a08683955804ed3a6492
Content-Type: text/plain; charset=ISO-8859-1

Phil,

Thanks for the reply back. And I respectfully beg to differ. 2 things:

1) on windows servers urls are case insensitive.
https://www.google.com/#q=windows+server+url+case+sensitive
How do we plan to handle that? Wouldn't it cause issues if someone migrates
from linux to windows servers if proper care is not taken by developers
while implementing their SCIM+REST platform that indeed they will have to
make their urls such that migration won't be a problem while keeping in
mind that they will have to adhere to specifications?

2)  I will quote some examples herewith as to what developers (and probably
SCIM implementers) like me will be expecting if I think of SCIM as REST
based implementation. As of now, all the 3rd party REST apis I have
integrated with, I have always seen them follow all lower cases for their
implementations. Here are some examples:

LINKEDIN:

http://api.linkedin.com/v1/people/~/connections
http://api.linkedin.com/v1/people/id=12345/connections

http://api.linkedin.com/v1/people/~/connections:(headline,first-name,last-name)
http://api.linkedin.com/v1/people/url=http%3A%2F%2Fwww.linkedin.com%2Fin%2Flbeebe/connections

GOOGLE:

GET https://www.googleapis.com/plus/v1/people/userId

SALESFORCE:


   - For authorization:
   https://login.salesforce.com/services/oauth2/authorize
   - For token requests: https://login.salesforce.com/services/oauth2/token
   - For revoking OAuth tokens:
   https://login.salesforce.com/services/oauth2/revoke


They could have used /OAuth2 or /Token or /People or /Connections, but from
my experience and knowledge, I have always seen them to be lowercase
(twitter as well btw)

And there will probably be some more examples that I can come up with. My
point being (and yes I don't think its set in stone), if something is
accepted widely in developer community, and if it makes their life easier,
it should be taken into consideration.

I will give another example. OAuth2.0 specs do not have any mention (or
alteast i didn't see any in the drafts) as to what authorization endpoints
or token request endpoints should be. But now it's widely accepted among
developers and implementers that /oauth2/authorize OR /oauth2/auth are
considered to be authorization endpoints. Here's an example from salesforce

http://www.salesforce.com/us/developer/docs/api_rest/Content/intro_understanding_oauth_endpoints.htm

But, when URLs are made a part of the specification, it will be set in
stone. Should a thought be given to somehow not force implementers to
follow a very specific set of urls (and url rules there-in) but instead let
the initial implementers decide on that and eventually gain developer
community support? And if we do want to force a very specific set of urls
as a part specifications, then we should get inputs and have discussions
with people out there who are actually going to use and implement these
specifications .. people who will be using scim as means to
provisioning/deprovisioning users in applications such as google,
salesforce (and many others)

Yes, people will follow whats going to be written in the specs. Upper or
Lowercases urls is not an issue once it's in the specs, that's what will be
implemented. But as leads of writing these specifications, thoughts should
be given as to how it will be really put to practice in real world. How
developers like me would be using it. How comfortable they will be
conforming to these specifications. TechGiants like google, linkedin
(probably salesforce?) etc might have all their REST urls lower cased, how
awkward would developers in these companies feel to introduce an
implementation which is different from their whole platform, only because
they are following specifications (and yes, vice versa case is true as well
where they MIGHT have all the urls properly Uppercased for objects, and if
we lowercase urls in scim specs then they will feel awkward. But as you can
see from the examples, the widely accepted norm is lowercasing)

PS: On a side note, I am very new to these kind of discussions and if I
ever step out of line, please do forgive my ignorance :).


On Tue, Dec 10, 2013 at 7:07 PM, Phil Hunt  wrote:

> I am not sure what you have been looking at but most examples I have seen
> use proper case names for object types in REST. I don't think it is a hard
> rule-just what I have seen.
>
> However the spec so far is clear on proper case usage for scim. If your
> server lowercases things it would cause it to have restore case on out
> output (eg location).
>
> For me, I don't see a real reason to change case at this time.
>
> Phil
>
> On Dec 10, 2013, at 17:15, Shivang Shah  wrote:
>
> I will probably reply back to the my question because I just came across
> the URL standards and it does seem that I was mis-informed about urls not
> being case sensitive.
>
> http://www.w3.org/TR/WD-html40-970708/htmlweb.html
>
> Now considering the fact that they indeed ARE case sensitive, I was
> wondering if it would make more sense to clients and developers to always
> use lower cases in standards (especially when the browsers themselves
> convert everything to lower case). It's my suggestion as a developer who
> plans to implement SCIM. It just makes more sense.
>
>
> On Tue, Dec 10, 2013 at 4:45 PM, Shivang Shah wrote:
>
>> Hi Everyone,
>>
>> (Apologize if this is double posting ! I posted previously before I was
>> subscribed to the listing!)
>>
>> I had couple of questions regarding the SCIM api endpoints discussed here
>> : http://www.simplecloud.info/specs/draft-scim-api-01.html and I thought
>> this might be a good place to start with.
>>
>> In the specs I see the following :
>>
>> "The SCIM protocol specifies well known endpoints and HTTP methods for
>> managing Resources defined in the core schema; i.e., User and Group
>> Resources correspond to /Users and /Groups respectively. Service Providers
>> that support extended Resources SHOULD define Resource endpoints using the
>> established convention; pluralize the Resource name defined in the extended
>> schema by appending an 's'. Given there are cases where Resource
>> pluralization is ambiguous; e.g., a Resource named 'person' is legitimately
>> 'persons' and 'people' Consumers SHOULD discover Resource endpoints via the
>> Schema Sub-Attribute 'endpoint'. "
>>
>> What I don't understand is the following:
>>
>> 1) I have never seen Capitalization of the Resource name before. Is this
>> something new for SCIM? Urls in browsers (urls anywhere for that matter)
>> are by default case insensitive and it doesn't matter if we capitalize it
>> or not. My real question would be is capitalizing the Resource name a part
>> of the spec or just an example?
>> 2) (This might be bit more of a mesh up question between REST spec and
>> SCIM). We have a scenario where a user HAS "favorites". There are 2 ways we
>> can handle this:
>>
>> /scim/v1/users/{userId}/favorites (we can call this an extended
>> sub-resource)
>>
>>
>> OR
>>
>> /scim/favorites/users/{userId} (we can all this an extended resource
>> "favorites").
>>
>> From the url perspective both seem to be right but what I don't know is
>> which one is more suitable according to SCIM (and maybe REST? )
>> specifications. And a follow up question to that might be, do the extended
>> resources have to be capitalized as well?
>>
>> All help is appreciated! I am new to implementing and understanding SCIM,
>> so please forgive me if I have missed some subtle pointers in the
>> specifications itself!
>>
>> Cheers and looking forward to any answers that can help me understand
>> this!
>>
>
> _______________________________________________
> scim mailing list
> scim@ietf.org
> https://www.ietf.org/mailman/listinfo/scim
>
>

--089e0122a08683955804ed3a6492
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Phil, 

Thanks for the reply back. And I respec=
tfully beg to differ. 2 things: 

1) on windows servers ur=
ls are case insensitive. https://www.google.com/#q=3Dwindo=
ws+server+url+case+sensitive



How do we plan to handle that? Wouldn't it cause issues if=
=20
someone migrates from linux to windows servers if proper care is not=20
taken by developers while implementing their SCIM+REST platform that=20
indeed they will have to make their urls such that migration won't be a=
=20
problem while keeping in mind that they will have to adhere to=20
specifications?



2)=A0 I will quote some examples herewith as to what=20
developers (and probably SCIM implementers) like me will be expecting if
 I think of SCIM as REST based implementation. As of now, all the 3rd=20
party REST apis I have integrated with, I have always seen them follow=20
all lower cases for their implementations. Here are some examples:


LINKEDIN:
SALESFORCE: 


They could have used /OAuth2 or /Token or /People or=20
/Connections, but from my experience and knowledge, I have always seen=20
them to be lowercase (twitter as well btw)

And there will=20
probably be some more examples that I can come up with. My point being=20
(and yes I don't think its set in stone), if something is accepted=20
widely in developer community, and if it makes their life easier, it=20
should be taken into consideration. 


I will give another example. OAuth2.0 specs do not have any mention=20
(or alteast i didn't see any in the drafts) as to what authorization=20
endpoints or token request endpoints should be. But now it's widely=20
accepted among developers and implementers that /oauth2/authorize OR=20
/oauth2/auth are considered to be authorization endpoints. Here's an=20
example from salesforce


http://www.sale=
sforce.com/us/developer/docs/api_rest/Content/intro_understanding_oauth_end=
points.htm



But, when URLs are made a part of the
 specification, it will be set in stone. Should a thought be given to=20
somehow not force implementers to follow a very specific set of urls=20
(and url rules there-in) but instead let the initial implementers decide
 on that and eventually gain developer community support? And if we do=20
want to force a very specific set of urls as a part specifications, then
 we should get inputs and have discussions with people out there who are
 actually going to use and implement these specifications .. people who=20
will be using scim as means to provisioning/deprovisioning users in=20
applications such as google, salesforce (and many others)


Yes, people will follow whats going=20
to be written in the specs. Upper or Lowercases urls is not an issue=20
once it's in the specs, that's what will be implemented. But as lea=
ds of
 writing these specifications, thoughts should be given as to how it=20
will be really put to practice in real world. How developers like me=20
would be using it. How comfortable they will be conforming to these=20
specifications. TechGiants like google, linkedin (probably salesforce?)=20
etc might have all their REST urls lower cased, how awkward would=20
developers in these companies feel to introduce an implementation which=20
is different from their whole platform, only because they are following=20
specifications (and yes, vice versa case is true as well where they=20
MIGHT have all the urls properly Uppercased for objects, and if we=20
lowercase urls in scim specs then they will feel awkward. But as you can
 see from the examples, the widely accepted norm is lowercasing)



PS: On
 a side note, I am very new to these kind of discussions and if I ever=20
step out of line, please do forgive my ignorance :). 


On Tue, Dec 10, 2013 at 7:07 =
PM, Phil Hunt <phil.hunt@oracle.com> wrote:


I am not sure what yo=
u have been looking at but most examples I have seen use proper case names =
for object types in REST. I don't think it is a hard rule-just what I h=
ave seen.=A0



However the spec so far is clear on proper case usage f=
or scim. If your server lowercases things it would cause it to have restore=
 case on out output (eg location).=A0

For me, I do=
n't see a real reason to change case at this time.=A0



Phil

On Dec 10, 2013, at 17:1=
5, Shivang Shah <shivang@totvslabs.com> wrote:



I will probably reply back to the my question be=
cause I just came across the URL standards and it does seem that I was mis-=
informed about urls not being case sensitive. 

http://www.w3.o=
rg/TR/WD-html40-970708/htmlweb.html



Now considering the fact that they indeed ARE case sensitive, I w=
as wondering if it would make more sense to clients and developers to alway=
s use lower cases in standards (especially when the browsers themselves con=
vert everything to lower case). It's my suggestion as a developer who p=
lans to implement SCIM. It just makes more sense. 





On Tue,=
 Dec 10, 2013 at 4:45 PM, Shivang Shah <shivang@totvslabs.com><=
/span> wrote:



Hi Everyone,

(Apologize if this is double posting ! I posted previously before I was=
 subscribed to the listing!)



I had couple of questions regarding the SCIM api endpoints di=
scussed here : http://www.simplecloud.info/specs/draft-scim-api=
-01.html and I thought this might be a good place to start with.





In the specs I see the following : 

"The SCIM protocol spec=
ifies well known endpoints and HTTP methods for managing Resources defined =
in the
                core schema; i.e., User and Group Resources correspond to /=
Users and /Groups respectively.  Service Providers
                that support extended Resources SHOULD define Resource endp=
oints using the established convention; pluralize
                the Resource name defined in the extended schema by appendi=
ng an 's'.  Given there are cases where Resource
                pluralization is ambiguous; e.g., a Resource named 'per=
son' is legitimately 'persons' and 'people' Consumers
                SHOULD discover Resource endpoints via the Schema Sub-Attri=
bute 'endpoint'.
           =20
"

What I don't understand is the following:

1) I hav=
e=20
never seen Capitalization of the Resource name before. Is this something
 new for SCIM? Urls in browsers (urls anywhere for that matter) are by=20
default case insensitive and it doesn't matter if we capitalize it or=
=20
not. My real question would be is capitalizing the Resource name a part=20
of the spec or just an example?
2) (This might be bit more of a mesh=20
up question between REST spec and SCIM). We have a scenario where a user
 HAS "favorites". There are 2 ways we can handle this: 

/scim/v1/users/{userId}/favorites (we can call this an extended sub-res=
ource)

=A0
OR

/scim/favorites/users/{userId} (we can all =
this an extended resource "favorites"). 





From
 the url perspective both seem to be right but what I don't know is=20
which one is more suitable according to SCIM (and maybe REST? )=20
specifications. And a follow up question to that might be, do the=20
extended resources have to be capitalized as well?

All help is=20
appreciated! I am new to implementing and understanding SCIM, so please=20
forgive me if I have missed some subtle pointers in the specifications=20
itself!

Cheers and looking forward to any answers that can help me u=
nderstand this!





_______=
________________________________________
scim mailing list<=
/span>
scim@iet=
f.org

https://www.ietf.org/mailman/listinfo/scim



--089e0122a08683955804ed3a6492--

From phil.hunt@oracle.com  Tue Dec 10 20:17:03 2013
Return-Path: 
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 1E1801AE166 for ; Tue, 10 Dec 2013 20:17:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.601
X-Spam-Level: 
X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
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 3tvdJ6cg6VLJ for ; Tue, 10 Dec 2013 20:16:59 -0800 (PST)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 770F01ADF8A for ; Tue, 10 Dec 2013 20:16:59 -0800 (PST)
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id rBB4Grtn007421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 Dec 2013 04:16:53 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rBB4GqZK012679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Dec 2013 04:16:53 GMT
Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rBB4GqZA012673; Wed, 11 Dec 2013 04:16:52 GMT
Received: from [192.168.1.125] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 10 Dec 2013 20:16:51 -0800
References:   <5BE47AC2-DAA1-4BE9-870B-CF5C94338630@oracle.com> 
Mime-Version: 1.0 (1.0)
In-Reply-To: 
Content-Type: multipart/alternative; boundary=Apple-Mail-B78465D6-E748-4F5F-84AA-4777D3D7479E
Content-Transfer-Encoding: 7bit
Message-Id: <5982C3B5-6058-430A-8940-5B1FDFE9FF0F@oracle.com>
X-Mailer: iPhone Mail (11B554a)
From: Phil Hunt 
Date: Tue, 10 Dec 2013 20:16:49 -0800
To: Shivang Shah 
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "scim@ietf.org" 
Subject: Re: [scim] Questions regarding SCIM endpoints and other extended Resources in SCIM
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Simple Cloud Identity Management BOF 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Dec 2013 04:17:03 -0000

--Apple-Mail-B78465D6-E748-4F5F-84AA-4777D3D7479E
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

I think you miss my point. Case is arbitrary and the precedence was set by s=
cim 1. There is a mandate not to make major breaking changes unless there is=
 a compelling reason.=20

Yes, windows servers support case insensitivity urls. But that doesn't mean t=
hey can't comply with case sensitive urls.=20

Phil

> On Dec 10, 2013, at 20:09, Shivang Shah  wrote:
>=20
> Phil,=20
>=20
> Thanks for the reply back. And I respectfully beg to differ. 2 things:=20
>=20
> 1) on windows servers urls are case insensitive. https://www.google.com/#q=
=3Dwindows+server+url+case+sensitive
> How do we plan to handle that? Wouldn't it cause issues if someone migrate=
s from linux to windows servers if proper care is not taken by developers wh=
ile implementing their SCIM+REST platform that indeed they will have to make=
 their urls such that migration won't be a problem while keeping in mind tha=
t they will have to adhere to specifications?
>=20
> 2)  I will quote some examples herewith as to what developers (and probabl=
y SCIM implementers) like me will be expecting if I think of SCIM as REST ba=
sed implementation. As of now, all the 3rd party REST apis I have integrated=
 with, I have always seen them follow all lower cases for their implementati=
ons. Here are some examples:
>=20
> LINKEDIN:
> http://api.linkedin.com/v1/people/~/connections
> http://api.linkedin.com/v1/people/id=3D12345/connections
>=20
> http://api.linkedin.com/v1/people/~/connections:(headline,first-name,last-=
name)
> http://api.linkedin.com/v1/people/url=3Dhttp%3A%2F%2Fwww.linkedin.com%2Fin=
%2Flbeebe/connections
>=20
> GOOGLE:
>=20
> GET https://www.googleapis.com/plus/v1/people/userId
>=20
> SALESFORCE:=20
>=20
> For authorization: https://login.salesforce.com/services/oauth2/authorize
> For token requests: https://login.salesforce.com/services/oauth2/token
> For revoking OAuth tokens: https://login.salesforce.com/services/oauth2/re=
voke
>=20
> They could have used /OAuth2 or /Token or /People or /Connections, but fro=
m my experience and knowledge, I have always seen them to be lowercase (twit=
ter as well btw)
>=20
> And there will probably be some more examples that I can come up with. My p=
oint being (and yes I don't think its set in stone), if something is accepte=
d widely in developer community, and if it makes their life easier, it shoul=
d be taken into consideration.=20
>=20
> I will give another example. OAuth2.0 specs do not have any mention (or al=
teast i didn't see any in the drafts) as to what authorization endpoints or t=
oken request endpoints should be. But now it's widely accepted among develop=
ers and implementers that /oauth2/authorize OR /oauth2/auth are considered t=
o be authorization endpoints. Here's an  example from salesforce
>=20
> http://www.salesforce.com/us/developer/docs/api_rest/Content/intro_underst=
anding_oauth_endpoints.htm
>=20
> But, when URLs are made a part of the specification, it will be set in sto=
ne. Should a thought be given to somehow not force implementers to follow a v=
ery specific set of urls (and url rules there-in) but instead let the initia=
l implementers decide on that and eventually gain developer community suppor=
t? And if we do  want to force a very specific set of urls as a part specifi=
cations, then we should get inputs and have discussions with people out ther=
e who are actually going to use and implement these specifications .. people=
 who will be using scim as means to provisioning/deprovisioning users in app=
lications such as google, salesforce (and many others)
>=20
> Yes, people will follow whats going to be written in the specs. Upper or L=
owercases urls is not an issue once it's in the specs, that's what will be i=
mplemented. But as leads of writing these specifications, thoughts should be=
 given as to how it will be really put to practice in real world. How develo=
pers like me would be using it. How comfortable they will be conforming to t=
hese specifications. TechGiants like google, linkedin (probably salesforce?)=
 etc might have all their REST urls lower cased, how awkward would developer=
s in these companies feel to introduce an implementation which is different f=
rom their whole platform, only because they are following specifications (an=
d yes, vice versa case is true as well where they MIGHT have all the urls pr=
operly Uppercased for objects, and if we lowercase urls in scim specs then t=
hey will feel awkward. But as you can see from the examples, the widely acce=
pted norm is lowercasing)
>=20
> PS: On a side note, I am very new to these kind of discussions and if I ev=
er step out of line, please do forgive my ignorance :).
>=20
>=20
>> On Tue, Dec 10, 2013 at 7:07 PM, Phil Hunt  wrote:
>> I am not sure what you have been looking at but most examples I have seen=
 use proper case names for object types in REST. I don't think it is a hard r=
ule-just what I have seen.=20
>>=20
>> However the spec so far is clear on proper case usage for scim. If your s=
erver lowercases things it would cause it to have restore case on out output=
 (eg location).=20
>>=20
>> For me, I don't see a real reason to change case at this time.=20
>>=20
>> Phil
>>=20
>>> On Dec 10, 2013, at 17:15, Shivang Shah  wrote:
>>>=20
>>> I will probably reply back to the my question because I just came across=
 the URL standards and it does seem that I was mis-informed about urls not b=
eing case sensitive.=20
>>>=20
>>> http://www.w3.org/TR/WD-html40-970708/htmlweb.html
>>>=20
>>> Now considering the fact that they indeed ARE case sensitive, I was wond=
ering if it would make more sense to clients and developers to always use lo=
wer cases in standards (especially when the browsers themselves convert ever=
ything to lower case). It's my suggestion as a developer who plans to implem=
ent SCIM. It just makes more sense.=20
>>>=20
>>>=20
>>>> On Tue, Dec 10, 2013 at 4:45 PM, Shivang Shah  w=
rote:
>>>> Hi Everyone,
>>>>=20
>>>> (Apologize if this is double posting ! I posted previously before I was=
 subscribed to the listing!)
>>>>=20
>>>> I had couple of questions regarding the SCIM api endpoints discussed he=
re : http://www.simplecloud.info/specs/draft-scim-api-01.html and I thought t=
his might be a good place to start with.
>>>>=20
>>>> In the specs I see the following :=20
>>>>=20
>>>> "The SCIM protocol specifies well known endpoints and HTTP methods for m=
anaging Resources defined in the core schema; i.e., User and Group Resources=
 correspond to /Users and /Groups respectively. Service Providers that suppo=
rt extended Resources SHOULD define Resource endpoints using the established=
 convention; pluralize the Resource name defined in the extended schema by a=
ppending an 's'. Given there are cases where Resource pluralization is ambig=
uous; e.g., a Resource named 'person' is legitimately 'persons' and 'people'=
 Consumers SHOULD discover Resource endpoints via the Schema Sub-Attribute '=
endpoint'. "
>>>>=20
>>>> What I don't understand is the following:
>>>>=20
>>>> 1) I have never seen Capitalization of the Resource name before. Is thi=
s something new for SCIM? Urls in browsers (urls anywhere for that matter) a=
re by default case insensitive and it doesn't matter if we capitalize it or n=
ot. My real question would be is capitalizing the Resource name a part of th=
e spec or just an example?
>>>> 2) (This might be bit more of a mesh up question between REST spec and S=
CIM). We have a scenario where a user HAS "favorites". There are 2 ways we c=
an handle this:=20
>>>>=20
>>>> /scim/v1/users/{userId}/favorites (we can call this an extended sub-res=
ource)
>>>>=20
>>>> =20
>>>> OR
>>>>=20
>>>> /scim/favorites/users/{userId} (we can all this an extended resource "f=
avorites").=20
>>>>=20
>>>> =46rom the url perspective both seem to be right but what I don't know i=
s which one is more suitable according to SCIM (and maybe REST? ) specificat=
ions. And a follow up question to that might be, do the extended resources h=
ave to be capitalized as well?
>>>>=20
>>>> All help is appreciated! I am new to implementing and understanding SCI=
M, so please forgive me if I have missed some subtle pointers in the specifi=
cations itself!
>>>>=20
>>>> Cheers and looking forward to any answers that can help me understand t=
his!
>>>=20
>>> _______________________________________________
>>> scim mailing list
>>> scim@ietf.org
>>> https://www.ietf.org/mailman/listinfo/scim
>=20
> _______________________________________________
> scim mailing list
> scim@ietf.org
> https://www.ietf.org/mailman/listinfo/scim

--Apple-Mail-B78465D6-E748-4F5F-84AA-4777D3D7479E
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: 7bit


I think you miss my point. Case is arbitrary and the precedence was set by scim 1. There is a mandate not to make major breaking changes unless there is a compelling reason. 

Yes, windows servers support case insensitivity urls. But that doesn't mean they can't comply with case sensitive urls. 

Phil

On Dec 10, 2013, at 20:09, Shivang Shah <shivang@totvslabs.com> wrote:

Phil, 

Thanks for the reply back. And I respectfully beg to differ. 2 things: 

1) on windows servers urls are case insensitive. https://www.google.com/#q=windows+server+url+case+sensitive



How do we plan to handle that? Wouldn't it cause issues if 
someone migrates from linux to windows servers if proper care is not 
taken by developers while implementing their SCIM+REST platform that 
indeed they will have to make their urls such that migration won't be a 
problem while keeping in mind that they will have to adhere to 
specifications?



2)  I will quote some examples herewith as to what 
developers (and probably SCIM implementers) like me will be expecting if
 I think of SCIM as REST based implementation. As of now, all the 3rd 
party REST apis I have integrated with, I have always seen them follow 
all lower cases for their implementations. Here are some examples:


LINKEDIN:
SALESFORCE: 



They could have used /OAuth2 or /Token or /People or 
/Connections, but from my experience and knowledge, I have always seen 
them to be lowercase (twitter as well btw)

And there will 
probably be some more examples that I can come up with. My point being 
(and yes I don't think its set in stone), if something is accepted 
widely in developer community, and if it makes their life easier, it 
should be taken into consideration. 


I will give another example. OAuth2.0 specs do not have any mention 
(or alteast i didn't see any in the drafts) as to what authorization 
endpoints or token request endpoints should be. But now it's widely 
accepted among developers and implementers that /oauth2/authorize OR 
/oauth2/auth are considered to be authorization endpoints. Here's an 
example from salesforce


http://www.salesforce.com/us/developer/docs/api_rest/Content/intro_understanding_oauth_endpoints.htm



But, when URLs are made a part of the
 specification, it will be set in stone. Should a thought be given to 
somehow not force implementers to follow a very specific set of urls 
(and url rules there-in) but instead let the initial implementers decide
 on that and eventually gain developer community support? And if we do 
want to force a very specific set of urls as a part specifications, then
 we should get inputs and have discussions with people out there who are
 actually going to use and implement these specifications .. people who 
will be using scim as means to provisioning/deprovisioning users in 
applications such as google, salesforce (and many others)


Yes, people will follow whats going 
to be written in the specs. Upper or Lowercases urls is not an issue 
once it's in the specs, that's what will be implemented. But as leads of
 writing these specifications, thoughts should be given as to how it 
will be really put to practice in real world. How developers like me 
would be using it. How comfortable they will be conforming to these 
specifications. TechGiants like google, linkedin (probably salesforce?) 
etc might have all their REST urls lower cased, how awkward would 
developers in these companies feel to introduce an implementation which 
is different from their whole platform, only because they are following 
specifications (and yes, vice versa case is true as well where they 
MIGHT have all the urls properly Uppercased for objects, and if we 
lowercase urls in scim specs then they will feel awkward. But as you can
 see from the examples, the widely accepted norm is lowercasing)



PS: On
 a side note, I am very new to these kind of discussions and if I ever 
step out of line, please do forgive my ignorance :). 


On Tue, Dec 10, 2013 at 7:07 PM, Phil Hunt <phil.hunt@oracle.com> wrote:


I am not sure what you have been looking at but most examples I have seen use proper case names for object types in REST. I don't think it is a hard rule-just what I have seen. 



However the spec so far is clear on proper case usage for scim. If your server lowercases things it would cause it to have restore case on out output (eg location). 

For me, I don't see a real reason to change case at this time. 



Phil

On Dec 10, 2013, at 17:15, Shivang Shah <shivang@totvslabs.com> wrote:



I will probably reply back to the my question because I just came across the URL standards and it does seem that I was mis-informed about urls not being case sensitive. 

http://www.w3.org/TR/WD-html40-970708/htmlweb.html



Now considering the fact that they indeed ARE case sensitive, I was wondering if it would make more sense to clients and developers to always use lower cases in standards (especially when the browsers themselves convert everything to lower case). It's my suggestion as a developer who plans to implement SCIM. It just makes more sense. 





On Tue, Dec 10, 2013 at 4:45 PM, Shivang Shah <shivang@totvslabs.com> wrote:



Hi Everyone,

(Apologize if this is double posting ! I posted previously before I was subscribed to the listing!)



I had couple of questions regarding the SCIM api endpoints discussed here : http://www.simplecloud.info/specs/draft-scim-api-01.html and I thought this might be a good place to start with.





In the specs I see the following : 

"The SCIM protocol specifies well known endpoints and HTTP methods for managing Resources defined in the
                core schema; i.e., User and Group Resources correspond to /Users and /Groups respectively.  Service Providers
                that support extended Resources SHOULD define Resource endpoints using the established convention; pluralize
                the Resource name defined in the extended schema by appending an 's'.  Given there are cases where Resource
                pluralization is ambiguous; e.g., a Resource named 'person' is legitimately 'persons' and 'people' Consumers
                SHOULD discover Resource endpoints via the Schema Sub-Attribute 'endpoint'.
            
"

What I don't understand is the following:

1) I have 
never seen Capitalization of the Resource name before. Is this something
 new for SCIM? Urls in browsers (urls anywhere for that matter) are by 
default case insensitive and it doesn't matter if we capitalize it or 
not. My real question would be is capitalizing the Resource name a part 
of the spec or just an example?
2) (This might be bit more of a mesh 
up question between REST spec and SCIM). We have a scenario where a user
 HAS "favorites". There are 2 ways we can handle this: 

/scim/v1/users/{userId}/favorites (we can call this an extended sub-resource)

 
OR

/scim/favorites/users/{userId} (we can all this an extended resource "favorites"). 





From
 the url perspective both seem to be right but what I don't know is 
which one is more suitable according to SCIM (and maybe REST? ) 
specifications. And a follow up question to that might be, do the 
extended resources have to be capitalized as well?

All help is 
appreciated! I am new to implementing and understanding SCIM, so please 
forgive me if I have missed some subtle pointers in the specifications 
itself!

Cheers and looking forward to any answers that can help me understand this!





_______________________________________________
scim mailing list
scim@ietf.org

https://www.ietf.org/mailman/listinfo/scim



_______________________________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim

--Apple-Mail-B78465D6-E748-4F5F-84AA-4777D3D7479E--

From shivang@totvslabs.com  Tue Dec 10 20:36:05 2013
Return-Path: 
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 6EA771AE35B for ; Tue, 10 Dec 2013 20:36:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.377
X-Spam-Level: 
X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-0.7] 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 eattssnML1LI for ; Tue, 10 Dec 2013 20:36:02 -0800 (PST)
Received: from mail-vb0-f45.google.com (mail-vb0-f45.google.com [209.85.212.45]) by ietfa.amsl.com (Postfix) with ESMTP id E0D931AE355 for ; Tue, 10 Dec 2013 20:36:01 -0800 (PST)
Received: by mail-vb0-f45.google.com with SMTP id i12so1264791vbh.18 for ; Tue, 10 Dec 2013 20:35:56 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ga0Vbogess0IGva03rTxEJrTmHzmUA3ICYB5Ei6+xI8=; b=RMO5VX3dolocRJctWLx6DmkrRGfFMSlKpz3NV1+WEp/UtNS1myokEpDyl89k0iTFim pcxLSSL8GFV4swBGbpJKj0MdircyNF4oCboLydd6KJJqmrgnJnAU99tMPThBWdWhlAot OCsD64VFkCeBCQxJtZmmDor3YOQITZhl4gpMUAbBztYGT3wjctgcZ3gQGLMubqujh7HI j+DvtYlidf2+kW1uV+ZfLodL+Jj1TBJf6N6sBAdPY1iM4lUtv5aD/1KZGMqxD+v0VtIy wu8sYgorLCyRwozrqtENSvh+0FeA3V74u3Y/S676aRjhXplbGshBi3dLFdZeyuXJk4AO kZQQ==
X-Gm-Message-State: ALoCoQmCwk6HQgWO5amDQkuthAbmbZbJsB/b62Yq3mquPI6KE9dL1pwEXDF7dPKX7Q2mb22id62w
MIME-Version: 1.0
X-Received: by 10.58.255.233 with SMTP id at9mr2670281ved.20.1386736556297; Tue, 10 Dec 2013 20:35:56 -0800 (PST)
Received: by 10.58.246.33 with HTTP; Tue, 10 Dec 2013 20:35:56 -0800 (PST)
In-Reply-To: <5982C3B5-6058-430A-8940-5B1FDFE9FF0F@oracle.com>
References:   <5BE47AC2-DAA1-4BE9-870B-CF5C94338630@oracle.com>  <5982C3B5-6058-430A-8940-5B1FDFE9FF0F@oracle.com>
Date: Tue, 10 Dec 2013 20:35:56 -0800
Message-ID: 
From: Shivang Shah 
To: Phil Hunt 
Content-Type: multipart/alternative; boundary=047d7bf15fc8d5e56e04ed3ac32f
Cc: "scim@ietf.org" 
Subject: Re: [scim] Questions regarding SCIM endpoints and other extended Resources in SCIM
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Simple Cloud Identity Management BOF 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Dec 2013 04:36:05 -0000

--047d7bf15fc8d5e56e04ed3ac32f
Content-Type: text/plain; charset=ISO-8859-1

oh I see .. I am sorry I was not aware of the mandate to not make major
breaking changes. But one could argue the same way that instead of making
implementers comply with case sensitive urls (which might be awkward for
them), it'd be probably ok to make a change in the spec, especially when
(and please do correct me if I am wrong here) the spec is moving one major
version up from 1.1 to 2.0 ? Urls do change when the API versions change,
especially when there are major version changes. I think I am failing to
understand as to how big of an impact would this change in the spec be?

Developers and Implementers comfort with the specifications should be (and
again, this is just my personal view, till the time we make this an open
discussion on forums to see what other developers think) a good enough
compelling reason to change the spec with a major version change. That
would be my 2 cents.


On Tue, Dec 10, 2013 at 8:16 PM, Phil Hunt  wrote:

> I think you miss my point. Case is arbitrary and the precedence was set by
> scim 1. There is a mandate not to make major breaking changes unless there
> is a compelling reason.
>
> Yes, windows servers support case insensitivity urls. But that doesn't
> mean they can't comply with case sensitive urls.
>
> Phil
>
> On Dec 10, 2013, at 20:09, Shivang Shah  wrote:
>
> Phil,
>
> Thanks for the reply back. And I respectfully beg to differ. 2 things:
>
> 1) on windows servers urls are case insensitive.
> https://www.google.com/#q=windows+server+url+case+sensitive
> How do we plan to handle that? Wouldn't it cause issues if someone
> migrates from linux to windows servers if proper care is not taken by
> developers while implementing their SCIM+REST platform that indeed they
> will have to make their urls such that migration won't be a problem while
> keeping in mind that they will have to adhere to specifications?
>
> 2)  I will quote some examples herewith as to what developers (and
> probably SCIM implementers) like me will be expecting if I think of SCIM as
> REST based implementation. As of now, all the 3rd party REST apis I have
> integrated with, I have always seen them follow all lower cases for their
> implementations. Here are some examples:
>
> LINKEDIN:
>
> http://api.linkedin.com/v1/people/~/connections
> http://api.linkedin.com/v1/people/id=12345/connections
>
>
> http://api.linkedin.com/v1/people/~/connections:(headline,first-name,last-name)
>
> http://api.linkedin.com/v1/people/url=http%3A%2F%2Fwww.linkedin.com%2Fin%2Flbeebe/connections
>
> GOOGLE:
>
> GET https://www.googleapis.com/plus/v1/people/userId
>
> SALESFORCE:
>
>
>    - For authorization:
>    https://login.salesforce.com/services/oauth2/authorize
>    - For token requests:
>    https://login.salesforce.com/services/oauth2/token
>    - For revoking OAuth tokens:
>    https://login.salesforce.com/services/oauth2/revoke
>
>
> They could have used /OAuth2 or /Token or /People or /Connections, but
> from my experience and knowledge, I have always seen them to be lowercase
> (twitter as well btw)
>
> And there will probably be some more examples that I can come up with. My
> point being (and yes I don't think its set in stone), if something is
> accepted widely in developer community, and if it makes their life easier,
> it should be taken into consideration.
>
> I will give another example. OAuth2.0 specs do not have any mention (or
> alteast i didn't see any in the drafts) as to what authorization endpoints
> or token request endpoints should be. But now it's widely accepted among
> developers and implementers that /oauth2/authorize OR /oauth2/auth are
> considered to be authorization endpoints. Here's an example from salesforce
>
>
> http://www.salesforce.com/us/developer/docs/api_rest/Content/intro_understanding_oauth_endpoints.htm
>
> But, when URLs are made a part of the specification, it will be set in
> stone. Should a thought be given to somehow not force implementers to
> follow a very specific set of urls (and url rules there-in) but instead let
> the initial implementers decide on that and eventually gain developer
> community support? And if we do want to force a very specific set of urls
> as a part specifications, then we should get inputs and have discussions
> with people out there who are actually going to use and implement these
> specifications .. people who will be using scim as means to
> provisioning/deprovisioning users in applications such as google,
> salesforce (and many others)
>
> Yes, people will follow whats going to be written in the specs. Upper or
> Lowercases urls is not an issue once it's in the specs, that's what will be
> implemented. But as leads of writing these specifications, thoughts should
> be given as to how it will be really put to practice in real world. How
> developers like me would be using it. How comfortable they will be
> conforming to these specifications. TechGiants like google, linkedin
> (probably salesforce?) etc might have all their REST urls lower cased, how
> awkward would developers in these companies feel to introduce an
> implementation which is different from their whole platform, only because
> they are following specifications (and yes, vice versa case is true as well
> where they MIGHT have all the urls properly Uppercased for objects, and if
> we lowercase urls in scim specs then they will feel awkward. But as you can
> see from the examples, the widely accepted norm is lowercasing)
>
> PS: On a side note, I am very new to these kind of discussions and if I
> ever step out of line, please do forgive my ignorance :).
>
>
> On Tue, Dec 10, 2013 at 7:07 PM, Phil Hunt  wrote:
>
>> I am not sure what you have been looking at but most examples I have seen
>> use proper case names for object types in REST. I don't think it is a hard
>> rule-just what I have seen.
>>
>> However the spec so far is clear on proper case usage for scim. If your
>> server lowercases things it would cause it to have restore case on out
>> output (eg location).
>>
>> For me, I don't see a real reason to change case at this time.
>>
>> Phil
>>
>> On Dec 10, 2013, at 17:15, Shivang Shah  wrote:
>>
>> I will probably reply back to the my question because I just came across
>> the URL standards and it does seem that I was mis-informed about urls not
>> being case sensitive.
>>
>> http://www.w3.org/TR/WD-html40-970708/htmlweb.html
>>
>> Now considering the fact that they indeed ARE case sensitive, I was
>> wondering if it would make more sense to clients and developers to always
>> use lower cases in standards (especially when the browsers themselves
>> convert everything to lower case). It's my suggestion as a developer who
>> plans to implement SCIM. It just makes more sense.
>>
>>
>> On Tue, Dec 10, 2013 at 4:45 PM, Shivang Shah wrote:
>>
>>> Hi Everyone,
>>>
>>> (Apologize if this is double posting ! I posted previously before I was
>>> subscribed to the listing!)
>>>
>>> I had couple of questions regarding the SCIM api endpoints discussed
>>> here : http://www.simplecloud.info/specs/draft-scim-api-01.html and I
>>> thought this might be a good place to start with.
>>>
>>> In the specs I see the following :
>>>
>>> "The SCIM protocol specifies well known endpoints and HTTP methods for
>>> managing Resources defined in the core schema; i.e., User and Group
>>> Resources correspond to /Users and /Groups respectively. Service Providers
>>> that support extended Resources SHOULD define Resource endpoints using the
>>> established convention; pluralize the Resource name defined in the extended
>>> schema by appending an 's'. Given there are cases where Resource
>>> pluralization is ambiguous; e.g., a Resource named 'person' is legitimately
>>> 'persons' and 'people' Consumers SHOULD discover Resource endpoints via the
>>> Schema Sub-Attribute 'endpoint'. "
>>>
>>> What I don't understand is the following:
>>>
>>> 1) I have never seen Capitalization of the Resource name before. Is this
>>> something new for SCIM? Urls in browsers (urls anywhere for that matter)
>>> are by default case insensitive and it doesn't matter if we capitalize it
>>> or not. My real question would be is capitalizing the Resource name a part
>>> of the spec or just an example?
>>> 2) (This might be bit more of a mesh up question between REST spec and
>>> SCIM). We have a scenario where a user HAS "favorites". There are 2 ways we
>>> can handle this:
>>>
>>> /scim/v1/users/{userId}/favorites (we can call this an extended
>>> sub-resource)
>>>
>>>
>>> OR
>>>
>>> /scim/favorites/users/{userId} (we can all this an extended resource
>>> "favorites").
>>>
>>> From the url perspective both seem to be right but what I don't know is
>>> which one is more suitable according to SCIM (and maybe REST? )
>>> specifications. And a follow up question to that might be, do the extended
>>> resources have to be capitalized as well?
>>>
>>> All help is appreciated! I am new to implementing and understanding
>>> SCIM, so please forgive me if I have missed some subtle pointers in the
>>> specifications itself!
>>>
>>> Cheers and looking forward to any answers that can help me understand
>>> this!
>>>
>>
>> _______________________________________________
>> scim mailing list
>> scim@ietf.org
>> https://www.ietf.org/mailman/listinfo/scim
>>
>>
> _______________________________________________
> scim mailing list
> scim@ietf.org
> https://www.ietf.org/mailman/listinfo/scim
>
>

--047d7bf15fc8d5e56e04ed3ac32f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


oh I see .. I am sorry I was not aware of the mandate=
 to not make major breaking changes. But one could argue the same way that =
instead of making implementers comply with case sensitive urls (which might=
 be awkward for them), it'd be probably ok to make a change in the spec=
, especially when (and please do correct me if I am wrong here) the spec is=
 moving one major version up from 1.1 to 2.0 ? Urls do change when the API =
versions change, especially when there are major version changes. I think I=
 am failing to understand as to how big of an impact would this change in t=
he spec be? 


Developers and Implementers comfort with the specifications shoul=
d be (and again, this is just my personal view, till the time we make this =
an open discussion on forums to see what other developers think) a good eno=
ugh compelling reason to change the spec with a major version change. That =
would be my 2 cents.




On Tue,=
 Dec 10, 2013 at 8:16 PM, Phil Hunt <phil.hunt@oracle.com> wrote:


I think you miss my p=
oint. Case is arbitrary and the precedence was set by scim 1. There is a ma=
ndate not to make major breaking changes unless there is a compelling reaso=
n.=A0



Yes, windows servers support case insensitivity urls. B=
ut that doesn't mean they can't comply with case sensitive urls.=A0=


Phil


On Dec 10, 2013, at 20:09, Shivang Shah <=
;shivang@totvsla=
bs.com> wrote:



Phil, 

Thanks for the reply back. And I respectfully beg to dif=
fer. 2 things: 

1) on windows servers urls are case insen=
sitive. https://www.google.com/#q=3Dwindows+server+url+cas=
e+sensitive




How do we plan to handle that? Wouldn't it cause issues if=
=20
someone migrates from linux to windows servers if proper care is not=20
taken by developers while implementing their SCIM+REST platform that=20
indeed they will have to make their urls such that migration won't be a=
=20
problem while keeping in mind that they will have to adhere to=20
specifications?



2)=A0 I will quote some examples herewith as to what=20
developers (and probably SCIM implementers) like me will be expecting if
 I think of SCIM as REST based implementation. As of now, all the 3rd=20
party REST apis I have integrated with, I have always seen them follow=20
all lower cases for their implementations. Here are some examples:


LINKEDIN:
SALESFORCE: 



They could have used /OAuth2 or /Token or /People or=20
/Connections, but from my experience and knowledge, I have always seen=20
them to be lowercase (twitter as well btw)

And there will=20
probably be some more examples that I can come up with. My point being=20
(and yes I don't think its set in stone), if something is accepted=20
widely in developer community, and if it makes their life easier, it=20
should be taken into consideration. 


I will give another example. OAuth2.0 specs do not have any mention=20
(or alteast i didn't see any in the drafts) as to what authorization=20
endpoints or token request endpoints should be. But now it's widely=20
accepted among developers and implementers that /oauth2/authorize OR=20
/oauth2/auth are considered to be authorization endpoints. Here's an=20
example from salesforce


http://www.sale=
sforce.com/us/developer/docs/api_rest/Content/intro_understanding_oauth_end=
points.htm




But, when URLs are made a part of the
 specification, it will be set in stone. Should a thought be given to=20
somehow not force implementers to follow a very specific set of urls=20
(and url rules there-in) but instead let the initial implementers decide
 on that and eventually gain developer community support? And if we do=20
want to force a very specific set of urls as a part specifications, then
 we should get inputs and have discussions with people out there who are
 actually going to use and implement these specifications .. people who=20
will be using scim as means to provisioning/deprovisioning users in=20
applications such as google, salesforce (and many others)


Yes, people will follow whats going=20
to be written in the specs. Upper or Lowercases urls is not an issue=20
once it's in the specs, that's what will be implemented. But as lea=
ds of
 writing these specifications, thoughts should be given as to how it=20
will be really put to practice in real world. How developers like me=20
would be using it. How comfortable they will be conforming to these=20
specifications. TechGiants like google, linkedin (probably salesforce?)=20
etc might have all their REST urls lower cased, how awkward would=20
developers in these companies feel to introduce an implementation which=20
is different from their whole platform, only because they are following=20
specifications (and yes, vice versa case is true as well where they=20
MIGHT have all the urls properly Uppercased for objects, and if we=20
lowercase urls in scim specs then they will feel awkward. But as you can
 see from the examples, the widely accepted norm is lowercasing)



PS: On
 a side note, I am very new to these kind of discussions and if I ever=20
step out of line, please do forgive my ignorance :). 


On Tue, Dec 10, 2013 at 7:07 =
PM, Phil Hunt <phil.hunt@oracle.com> wrote:



I am not sure what yo=
u have been looking at but most examples I have seen use proper case names =
for object types in REST. I don't think it is a hard rule-just what I h=
ave seen.=A0




However the spec so far is clear on proper case usage f=
or scim. If your server lowercases things it would cause it to have restore=
 case on out output (eg location).=A0

For me, I do=
n't see a real reason to change case at this time.=A0




Phil

On Dec 10, 2013, at 17:15, Shivang Sh=
ah <shivang@t=
otvslabs.com> wrote:



I will probably reply back to the my question be=
cause I just came across the URL standards and it does seem that I was mis-=
informed about urls not being case sensitive. 

http://www.w3.o=
rg/TR/WD-html40-970708/htmlweb.html




Now considering the fact that they indeed ARE case sensitive, I w=
as wondering if it would make more sense to clients and developers to alway=
s use lower cases in standards (especially when the browsers themselves con=
vert everything to lower case). It's my suggestion as a developer who p=
lans to implement SCIM. It just makes more sense. 






On Tue,=
 Dec 10, 2013 at 4:45 PM, Shivang Shah <shivang@totvslabs.com><=
/span> wrote:




Hi Everyone,

(Apologize if this is double posting ! I posted previously before I was=
 subscribed to the listing!)




I had couple of questions regarding the SCIM api endpoints di=
scussed here : http://www.simplecloud.info/specs/draft-scim-api=
-01.html and I thought this might be a good place to start with.






In the specs I see the following : 

"The SCIM protocol spec=
ifies well known endpoints and HTTP methods for managing Resources defined =
in the
                core schema; i.e., User and Group Resources correspond to /=
Users and /Groups respectively.  Service Providers
                that support extended Resources SHOULD define Resource endp=
oints using the established convention; pluralize
                the Resource name defined in the extended schema by appendi=
ng an 's'.  Given there are cases where Resource
                pluralization is ambiguous; e.g., a Resource named 'per=
son' is legitimately 'persons' and 'people' Consumers
                SHOULD discover Resource endpoints via the Schema Sub-Attri=
bute 'endpoint'.
           =20
"

What I don't understand is the following:

1) I hav=
e=20
never seen Capitalization of the Resource name before. Is this something
 new for SCIM? Urls in browsers (urls anywhere for that matter) are by=20
default case insensitive and it doesn't matter if we capitalize it or=
=20
not. My real question would be is capitalizing the Resource name a part=20
of the spec or just an example?
2) (This might be bit more of a mesh=20
up question between REST spec and SCIM). We have a scenario where a user
 HAS "favorites". There are 2 ways we can handle this: 

/scim/v1/users/{userId}/favorites (we can call this an extended sub-res=
ource)

=A0
OR

/scim/favorites/users/{userId} (we can all =
this an extended resource "favorites"). 






From
 the url perspective both seem to be right but what I don't know is=20
which one is more suitable according to SCIM (and maybe REST? )=20
specifications. And a follow up question to that might be, do the=20
extended resources have to be capitalized as well?

All help is=20
appreciated! I am new to implementing and understanding SCIM, so please=20
forgive me if I have missed some subtle pointers in the specifications=20
itself!

Cheers and looking forward to any answers that can help me u=
nderstand this!





_______=
________________________________________
scim mailing list<=
/span>
scim@iet=
f.org


https://www.ietf.org/mailman/listinfo/scim



___________________=
____________________________
scim mailing list
scim@ietf.org

https://www.ietf.org/mailman/listinfo/scim



--047d7bf15fc8d5e56e04ed3ac32f--

From shivang@totvslabs.com  Wed Dec 11 08:47:17 2013
Return-Path: 
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 CECA41AE07C for ; Wed, 11 Dec 2013 08:47:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.377
X-Spam-Level: 
X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-0.7] 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 HzDdsvFzZxVi for ; Wed, 11 Dec 2013 08:47:10 -0800 (PST)
Received: from mail-vb0-f53.google.com (mail-vb0-f53.google.com [209.85.212.53]) by ietfa.amsl.com (Postfix) with ESMTP id ED3681AE066 for ; Wed, 11 Dec 2013 08:47:09 -0800 (PST)
Received: by mail-vb0-f53.google.com with SMTP id o19so1779628vbm.40 for ; Wed, 11 Dec 2013 08:47:04 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=lTbWfFz1soRJWM/6vK89wFjrEwIJ8yt2fUyLEb2gUnQ=; b=FpvLDva4c0NMhgQTAiH4bjMX71kWPsaDK11VH3EWC38U33SPDD2tnYQg+Qu/crGYg3 ZTrL4DBD9Rwnq/HacLYDgFGfu/Z4U+WrTU0P+cDy1xqugMVqvoRcpOdsuHJLiX1u3Axa /Q40KniG0NjFsokvHy6azD+z3lBb2QU3k2+4rVSvvwbe9JuA/QBZU79vEVGWQB0booM3 krgE/njQlrD9ZBTAgFlpVPlDMCOpbQRZ1lM76j9qBBEfMeFfQgyi08YVbQnyDkY/tqoz 7xIZqsN5wUpT0+Ccxm+pGM70AFVAubTcvGvZSnDV9GfHwtZ59mlmFiU2/ECfPIuavc+2 hPiQ==
X-Gm-Message-State: ALoCoQk3gMpWfVjEgS6CiBrb6Yr49E1hwKCwPwAmcAH618CbiuCVaumC9ENt+6LnLmg76Ju+tgOM
MIME-Version: 1.0
X-Received: by 10.58.188.42 with SMTP id fx10mr218444vec.51.1386780423933; Wed, 11 Dec 2013 08:47:03 -0800 (PST)
Received: by 10.58.246.33 with HTTP; Wed, 11 Dec 2013 08:47:03 -0800 (PST)
In-Reply-To: 
References:   <5BE47AC2-DAA1-4BE9-870B-CF5C94338630@oracle.com>  <5982C3B5-6058-430A-8940-5B1FDFE9FF0F@oracle.com> 
Date: Wed, 11 Dec 2013 08:47:03 -0800
Message-ID: 
From: Shivang Shah 
To: Phil Hunt 
Content-Type: multipart/alternative; boundary=089e013a27a68ce80804ed44fad5
Cc: "scim@ietf.org" 
Subject: Re: [scim] Questions regarding SCIM endpoints and other extended Resources in SCIM
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Simple Cloud Identity Management BOF 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Dec 2013 16:47:18 -0000

--089e013a27a68ce80804ed44fad5
Content-Type: text/plain; charset=ISO-8859-1

All,

I had another follow up question to this thread. As per the spec here:

The SCIM protocol specifies well known endpoints and HTTP methods for
   managing Resources defined in the core schema; i.e., User and Group
   Resources correspond to /Users and /Groups respectively.  Service
   Providers that support extended Resources SHOULD define Resource
   endpoints using the established convention; pluralize the Resource
   name defined in the extended schema by appending an 's'.  Given there
   are cases where Resource pluralization is ambiguous; e.g., a Resource
   named 'person' is legitimately 'persons' and 'people' Consumers
   SHOULD discover Resource endpoints via the Resource Type attribute
   'endpoint'.

I see that there is not much information on the extended subresources of
the already defined well known endpoints. Here's an example.

Suppose an application has a User who HAS assigned Projects which inturn
HAS assigned Tasks per project. In this case, the REST urls would look
something like:

scim/v1/Users/{userId}/Projects/{projectId}/tasks.

My question is: does this still comply SCIM specs? Or resource handling
like these should be on a separate REST platform because it doesn't have
anything to do directly with Identity Management (although one might argue
that these could be entitlements assigned to the User)

Another question here would be, if I am someone trying to write a generic
SCIM-REST client based off of the specs, how would I take into
consideration and handle the above resources because from what it seems,
each scim service provider could have their own Object that a User gets in
their application (or gets assigned to), for eg: Projects in the above
case.

I guess it's more of a design question as to where a service provider
should draw the line and encapsulate their apis as SCIM apis or dedicated
REST apis.

Anyone has any suggestions for me? We have started implementing scim on our
platform and we would like to comply as much as we can with the specs.


On Tue, Dec 10, 2013 at 8:35 PM, Shivang Shah  wrote:

> oh I see .. I am sorry I was not aware of the mandate to not make major
> breaking changes. But one could argue the same way that instead of making
> implementers comply with case sensitive urls (which might be awkward for
> them), it'd be probably ok to make a change in the spec, especially when
> (and please do correct me if I am wrong here) the spec is moving one major
> version up from 1.1 to 2.0 ? Urls do change when the API versions change,
> especially when there are major version changes. I think I am failing to
> understand as to how big of an impact would this change in the spec be?
>
> Developers and Implementers comfort with the specifications should be (and
> again, this is just my personal view, till the time we make this an open
> discussion on forums to see what other developers think) a good enough
> compelling reason to change the spec with a major version change. That
> would be my 2 cents.
>
>
> On Tue, Dec 10, 2013 at 8:16 PM, Phil Hunt  wrote:
>
>> I think you miss my point. Case is arbitrary and the precedence was set
>> by scim 1. There is a mandate not to make major breaking changes unless
>> there is a compelling reason.
>>
>> Yes, windows servers support case insensitivity urls. But that doesn't
>> mean they can't comply with case sensitive urls.
>>
>> Phil
>>
>> On Dec 10, 2013, at 20:09, Shivang Shah  wrote:
>>
>> Phil,
>>
>> Thanks for the reply back. And I respectfully beg to differ. 2 things:
>>
>> 1) on windows servers urls are case insensitive.
>> https://www.google.com/#q=windows+server+url+case+sensitive
>> How do we plan to handle that? Wouldn't it cause issues if someone
>> migrates from linux to windows servers if proper care is not taken by
>> developers while implementing their SCIM+REST platform that indeed they
>> will have to make their urls such that migration won't be a problem while
>> keeping in mind that they will have to adhere to specifications?
>>
>> 2)  I will quote some examples herewith as to what developers (and
>> probably SCIM implementers) like me will be expecting if I think of SCIM as
>> REST based implementation. As of now, all the 3rd party REST apis I have
>> integrated with, I have always seen them follow all lower cases for their
>> implementations. Here are some examples:
>>
>> LINKEDIN:
>>
>> http://api.linkedin.com/v1/people/~/connections
>> http://api.linkedin.com/v1/people/id=12345/connections
>>
>>
>> http://api.linkedin.com/v1/people/~/connections:(headline,first-name,last-name)
>>
>> http://api.linkedin.com/v1/people/url=http%3A%2F%2Fwww.linkedin.com%2Fin%2Flbeebe/connections
>>
>> GOOGLE:
>>
>> GET https://www.googleapis.com/plus/v1/people/userId
>>
>> SALESFORCE:
>>
>>
>>    - For authorization:
>>    https://login.salesforce.com/services/oauth2/authorize
>>    - For token requests:
>>    https://login.salesforce.com/services/oauth2/token
>>    - For revoking OAuth tokens:
>>    https://login.salesforce.com/services/oauth2/revoke
>>
>>
>> They could have used /OAuth2 or /Token or /People or /Connections, but
>> from my experience and knowledge, I have always seen them to be lowercase
>> (twitter as well btw)
>>
>> And there will probably be some more examples that I can come up with. My
>> point being (and yes I don't think its set in stone), if something is
>> accepted widely in developer community, and if it makes their life easier,
>> it should be taken into consideration.
>>
>> I will give another example. OAuth2.0 specs do not have any mention (or
>> alteast i didn't see any in the drafts) as to what authorization endpoints
>> or token request endpoints should be. But now it's widely accepted among
>> developers and implementers that /oauth2/authorize OR /oauth2/auth are
>> considered to be authorization endpoints. Here's an example from salesforce
>>
>>
>> http://www.salesforce.com/us/developer/docs/api_rest/Content/intro_understanding_oauth_endpoints.htm
>>
>> But, when URLs are made a part of the specification, it will be set in
>> stone. Should a thought be given to somehow not force implementers to
>> follow a very specific set of urls (and url rules there-in) but instead let
>> the initial implementers decide on that and eventually gain developer
>> community support? And if we do want to force a very specific set of urls
>> as a part specifications, then we should get inputs and have discussions
>> with people out there who are actually going to use and implement these
>> specifications .. people who will be using scim as means to
>> provisioning/deprovisioning users in applications such as google,
>> salesforce (and many others)
>>
>> Yes, people will follow whats going to be written in the specs. Upper or
>> Lowercases urls is not an issue once it's in the specs, that's what will be
>> implemented. But as leads of writing these specifications, thoughts should
>> be given as to how it will be really put to practice in real world. How
>> developers like me would be using it. How comfortable they will be
>> conforming to these specifications. TechGiants like google, linkedin
>> (probably salesforce?) etc might have all their REST urls lower cased, how
>> awkward would developers in these companies feel to introduce an
>> implementation which is different from their whole platform, only because
>> they are following specifications (and yes, vice versa case is true as well
>> where they MIGHT have all the urls properly Uppercased for objects, and if
>> we lowercase urls in scim specs then they will feel awkward. But as you can
>> see from the examples, the widely accepted norm is lowercasing)
>>
>> PS: On a side note, I am very new to these kind of discussions and if I
>> ever step out of line, please do forgive my ignorance :).
>>
>>
>> On Tue, Dec 10, 2013 at 7:07 PM, Phil Hunt  wrote:
>>
>>> I am not sure what you have been looking at but most examples I have
>>> seen use proper case names for object types in REST. I don't think it is a
>>> hard rule-just what I have seen.
>>>
>>> However the spec so far is clear on proper case usage for scim. If your
>>> server lowercases things it would cause it to have restore case on out
>>> output (eg location).
>>>
>>> For me, I don't see a real reason to change case at this time.
>>>
>>> Phil
>>>
>>> On Dec 10, 2013, at 17:15, Shivang Shah  wrote:
>>>
>>> I will probably reply back to the my question because I just came across
>>> the URL standards and it does seem that I was mis-informed about urls not
>>> being case sensitive.
>>>
>>> http://www.w3.org/TR/WD-html40-970708/htmlweb.html
>>>
>>> Now considering the fact that they indeed ARE case sensitive, I was
>>> wondering if it would make more sense to clients and developers to always
>>> use lower cases in standards (especially when the browsers themselves
>>> convert everything to lower case). It's my suggestion as a developer who
>>> plans to implement SCIM. It just makes more sense.
>>>
>>>
>>> On Tue, Dec 10, 2013 at 4:45 PM, Shivang Shah wrote:
>>>
>>>> Hi Everyone,
>>>>
>>>> (Apologize if this is double posting ! I posted previously before I was
>>>> subscribed to the listing!)
>>>>
>>>> I had couple of questions regarding the SCIM api endpoints discussed
>>>> here : http://www.simplecloud.info/specs/draft-scim-api-01.html and I
>>>> thought this might be a good place to start with.
>>>>
>>>> In the specs I see the following :
>>>>
>>>> "The SCIM protocol specifies well known endpoints and HTTP methods for
>>>> managing Resources defined in the core schema; i.e., User and Group
>>>> Resources correspond to /Users and /Groups respectively. Service Providers
>>>> that support extended Resources SHOULD define Resource endpoints using the
>>>> established convention; pluralize the Resource name defined in the extended
>>>> schema by appending an 's'. Given there are cases where Resource
>>>> pluralization is ambiguous; e.g., a Resource named 'person' is legitimately
>>>> 'persons' and 'people' Consumers SHOULD discover Resource endpoints via the
>>>> Schema Sub-Attribute 'endpoint'. "
>>>>
>>>> What I don't understand is the following:
>>>>
>>>> 1) I have never seen Capitalization of the Resource name before. Is
>>>> this something new for SCIM? Urls in browsers (urls anywhere for that
>>>> matter) are by default case insensitive and it doesn't matter if we
>>>> capitalize it or not. My real question would be is capitalizing the
>>>> Resource name a part of the spec or just an example?
>>>> 2) (This might be bit more of a mesh up question between REST spec and
>>>> SCIM). We have a scenario where a user HAS "favorites". There are 2 ways we
>>>> can handle this:
>>>>
>>>> /scim/v1/users/{userId}/favorites (we can call this an extended
>>>> sub-resource)
>>>>
>>>>
>>>> OR
>>>>
>>>> /scim/favorites/users/{userId} (we can all this an extended resource
>>>> "favorites").
>>>>
>>>> From the url perspective both seem to be right but what I don't know is
>>>> which one is more suitable according to SCIM (and maybe REST? )
>>>> specifications. And a follow up question to that might be, do the extended
>>>> resources have to be capitalized as well?
>>>>
>>>> All help is appreciated! I am new to implementing and understanding
>>>> SCIM, so please forgive me if I have missed some subtle pointers in the
>>>> specifications itself!
>>>>
>>>> Cheers and looking forward to any answers that can help me understand
>>>> this!
>>>>
>>>
>>> _______________________________________________
>>> scim mailing list
>>> scim@ietf.org
>>> https://www.ietf.org/mailman/listinfo/scim
>>>
>>>
>> _______________________________________________
>> scim mailing list
>> scim@ietf.org
>> https://www.ietf.org/mailman/listinfo/scim
>>
>>
>

--089e013a27a68ce80804ed44fad5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


All,

I had another follow =
up question to this thread. As per the spec here: 

T=
he SCIM protocol specifies well known endpoints and HTTP methods for
   managing Resources defined in the core schema; i.e., User and Group
   Resources correspond to /Users and /Groups respectively.  Service
   Providers that support extended Resources SHOULD define Resource
   endpoints using the established convention; pluralize the Resource
   name defined in the extended schema by appending an 's'.  Given =
there
   are cases where Resource pluralization is ambiguous; e.g., a Resource
   named 'person' is legitimately 'persons' and 'people=
' Consumers
   SHOULD discover Resource endpoints via the Resource Type attribute
   'endpoint'.
I see that there is not much information on the=
 extended subresources of the already defined well known endpoints. Here=
9;s an example. 

Suppose an application has a User who HAS ass=
igned Projects which inturn HAS assigned Tasks per project. In this case, t=
he REST urls would look something like:


scim/v1/Users/{userId}/Projects/{projectId}/tasks.

M=
y question is: does this still comply SCIM specs? Or resource handling like=
 these should be on a separate REST platform because it doesn't have an=
ything to do directly with Identity Management (although one might argue th=
at these could be entitlements assigned to the User)


Another question here would be, if I am someone trying to write a=
 generic SCIM-REST client based off of the specs, how would I take into con=
sideration and handle the above resources because from what it seems, each =
scim service provider could have their own Object that a User gets in their=
 application (or gets assigned to), for eg: Projects in the above case. 

I guess it's more of a design question as to where a ser=
vice provider should draw the line and encapsulate their apis as SCIM apis =
or dedicated REST apis. 

Anyone has any suggestions for m=
e? We have started implementing scim on our platform and we would like to c=
omply as much as we can with the specs.




O=
n Tue, Dec 10, 2013 at 8:35 PM, Shivang Shah <shivang@totvslabs.com> wrote:


oh I see .. I am sorry=
 I was not aware of the mandate to not make major breaking changes. But one=
 could argue the same way that instead of making implementers comply with c=
ase sensitive urls (which might be awkward for them), it'd be probably =
ok to make a change in the spec, especially when (and please do correct me =
if I am wrong here) the spec is moving one major version up from 1.1 to 2.0=
 ? Urls do change when the API versions change, especially when there are m=
ajor version changes. I think I am failing to understand as to how big of a=
n impact would this change in the spec be? 



Developers and Implementers comfort with the specifications shoul=
d be (and again, this is just my personal view, till the time we make this =
an open discussion on forums to see what other developers think) a good eno=
ugh compelling reason to change the spec with a major version change. That =
would be my 2 cents.




On Tue, Dec 10, 2013 at 8:16 PM, Phil Hunt=
 <phil.hunt@oracle.com> wrote:



I think you miss my p=
oint. Case is arbitrary and the precedence was set by scim 1. There is a ma=
ndate not to make major breaking changes unless there is a compelling reaso=
n.=A0




Yes, windows servers support case insensitivity urls. B=
ut that doesn't mean they can't comply with case sensitive urls.=A0=


Phil



On Dec 10, 2013, at 20:09, Shivang Shah <shivang@totvslabs.com>=
; wrote:



Phil, 

Thanks for the reply back. And I respectfully beg to dif=
fer. 2 things: 

1) on windows servers urls are case insen=
sitive. https://www.google.com/#q=3Dwindows+server+url+cas=
e+sensitive





How do we plan to handle that? Wouldn't it cause issues if=
=20
someone migrates from linux to windows servers if proper care is not=20
taken by developers while implementing their SCIM+REST platform that=20
indeed they will have to make their urls such that migration won't be a=
=20
problem while keeping in mind that they will have to adhere to=20
specifications?



2)=A0 I will quote some examples herewith as to what=20
developers (and probably SCIM implementers) like me will be expecting if
 I think of SCIM as REST based implementation. As of now, all the 3rd=20
party REST apis I have integrated with, I have always seen them follow=20
all lower cases for their implementations. Here are some examples:


LINKEDIN:
SALESFORCE: 




They could have used /OAuth2 or /Token or /People or=20
/Connections, but from my experience and knowledge, I have always seen=20
them to be lowercase (twitter as well btw)

And there will=20
probably be some more examples that I can come up with. My point being=20
(and yes I don't think its set in stone), if something is accepted=20
widely in developer community, and if it makes their life easier, it=20
should be taken into consideration. 


I will give another example. OAuth2.0 specs do not have any mention=20
(or alteast i didn't see any in the drafts) as to what authorization=20
endpoints or token request endpoints should be. But now it's widely=20
accepted among developers and implementers that /oauth2/authorize OR=20
/oauth2/auth are considered to be authorization endpoints. Here's an=20
example from salesforce


http://www.sale=
sforce.com/us/developer/docs/api_rest/Content/intro_understanding_oauth_end=
points.htm





But, when URLs are made a part of the
 specification, it will be set in stone. Should a thought be given to=20
somehow not force implementers to follow a very specific set of urls=20
(and url rules there-in) but instead let the initial implementers decide
 on that and eventually gain developer community support? And if we do=20
want to force a very specific set of urls as a part specifications, then
 we should get inputs and have discussions with people out there who are
 actually going to use and implement these specifications .. people who=20
will be using scim as means to provisioning/deprovisioning users in=20
applications such as google, salesforce (and many others)


Yes, people will follow whats going=20
to be written in the specs. Upper or Lowercases urls is not an issue=20
once it's in the specs, that's what will be implemented. But as lea=
ds of
 writing these specifications, thoughts should be given as to how it=20
will be really put to practice in real world. How developers like me=20
would be using it. How comfortable they will be conforming to these=20
specifications. TechGiants like google, linkedin (probably salesforce?)=20
etc might have all their REST urls lower cased, how awkward would=20
developers in these companies feel to introduce an implementation which=20
is different from their whole platform, only because they are following=20
specifications (and yes, vice versa case is true as well where they=20
MIGHT have all the urls properly Uppercased for objects, and if we=20
lowercase urls in scim specs then they will feel awkward. But as you can
 see from the examples, the widely accepted norm is lowercasing)



PS: On
 a side note, I am very new to these kind of discussions and if I ever=20
step out of line, please do forgive my ignorance :). 


On Tue, Dec 10, 2013 at 7:07 =
PM, Phil Hunt <phil.hunt@oracle.com> wrote:




I am not sure what yo=
u have been looking at but most examples I have seen use proper case names =
for object types in REST. I don't think it is a hard rule-just what I h=
ave seen.=A0





However the spec so far is clear on proper case usage f=
or scim. If your server lowercases things it would cause it to have restore=
 case on out output (eg location).=A0

For me, I do=
n't see a real reason to change case at this time.=A0





Phil

On Dec 10, 2013, at 17:15, Shivang Sh=
ah <shivang@t=
otvslabs.com> wrote:



I will probably reply back to the my question be=
cause I just came across the URL standards and it does seem that I was mis-=
informed about urls not being case sensitive. 

http://www.w3.o=
rg/TR/WD-html40-970708/htmlweb.html





Now considering the fact that they indeed ARE case sensitive, I w=
as wondering if it would make more sense to clients and developers to alway=
s use lower cases in standards (especially when the browsers themselves con=
vert everything to lower case). It's my suggestion as a developer who p=
lans to implement SCIM. It just makes more sense. 







On Tue,=
 Dec 10, 2013 at 4:45 PM, Shivang Shah <shivang@totvslabs.com><=
/span> wrote:





Hi Everyone,

(Apologize if this is double posting ! I posted previously before I was=
 subscribed to the listing!)





I had couple of questions regarding the SCIM api endpoints di=
scussed here : http://www.simplecloud.info/specs/draft-scim-api=
-01.html and I thought this might be a good place to start with.







In the specs I see the following : 

"The SCIM protocol spec=
ifies well known endpoints and HTTP methods for managing Resources defined =
in the
                core schema; i.e., User and Group Resources correspond to /=
Users and /Groups respectively.  Service Providers
                that support extended Resources SHOULD define Resource endp=
oints using the established convention; pluralize
                the Resource name defined in the extended schema by appendi=
ng an 's'.  Given there are cases where Resource
                pluralization is ambiguous; e.g., a Resource named 'per=
son' is legitimately 'persons' and 'people' Consumers
                SHOULD discover Resource endpoints via the Schema Sub-Attri=
bute 'endpoint'.
           =20
"

What I don't understand is the following:

1) I hav=
e=20
never seen Capitalization of the Resource name before. Is this something
 new for SCIM? Urls in browsers (urls anywhere for that matter) are by=20
default case insensitive and it doesn't matter if we capitalize it or=
=20
not. My real question would be is capitalizing the Resource name a part=20
of the spec or just an example?
2) (This might be bit more of a mesh=20
up question between REST spec and SCIM). We have a scenario where a user
 HAS "favorites". There are 2 ways we can handle this: 

/scim/v1/users/{userId}/favorites (we can call this an extended sub-res=
ource)

=A0
OR

/scim/favorites/users/{userId} (we can all =
this an extended resource "favorites"). 







From
 the url perspective both seem to be right but what I don't know is=20
which one is more suitable according to SCIM (and maybe REST? )=20
specifications. And a follow up question to that might be, do the=20
extended resources have to be capitalized as well?

All help is=20
appreciated! I am new to implementing and understanding SCIM, so please=20
forgive me if I have missed some subtle pointers in the specifications=20
itself!

Cheers and looking forward to any answers that can help me u=
nderstand this!





_______=
________________________________________
scim mailing list<=
/span>
scim@iet=
f.org



https://www.ietf.org/mailman/listinfo/scim



___________________=
____________________________
scim mailing list
scim@ietf.org


https://www.ietf.org/mailman/listinfo/scim






--089e013a27a68ce80804ed44fad5--

From phil.hunt@oracle.com  Wed Dec 11 12:10:44 2013
Return-Path: 
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 C06481AE1CF for ; Wed, 11 Dec 2013 12:10:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
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 ZJLLId0TrGHs for ; Wed, 11 Dec 2013 12:10:41 -0800 (PST)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 2F4F01AE1BB for ; Wed, 11 Dec 2013 12:10:37 -0800 (PST)
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id rBBKAUjQ005425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 11 Dec 2013 20:10:31 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rBBKATka009619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 11 Dec 2013 20:10:30 GMT
Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rBBKATWv009883 for ; Wed, 11 Dec 2013 20:10:29 GMT
Received: from [192.168.1.12] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 11 Dec 2013 12:10:29 -0800
From: Phil Hunt 
Content-Type: multipart/alternative; boundary="Apple-Mail=_6659EEDF-586B-4B56-BD49-E07DB3409186"
Message-Id: 
Date: Wed, 11 Dec 2013 12:10:27 -0800
To: "scim@ietf.org WG" 
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
X-Mailer: Apple Mail (2.1510)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Subject: [scim] SCIM Redirect Support Clarification - Draft Proposal
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Simple Cloud Identity Management BOF 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Dec 2013 20:10:45 -0000

--Apple-Mail=_6659EEDF-586B-4B56-BD49-E07DB3409186
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

The following is a new section to be added to draft-ietf-scim-api.  This =
provides clarification as to what HTTP redirects clients must support. =20=


My thought is we need to support 5.0 through 5.2. =20

Section 5.2.1 (aliases) may be somewhat more controversial and thus has =
been written as an optional feature. I do agree strongly with the =
concern not to have multiple URIs for a resource. My thought here is =
that by using a redirect as a compromise, the redirect encourages the =
client to use the proper URL and thus might be seen as self-healing over =
time.  Yet at the same time, it does solve some scenarios where the =
client may be aware of a user-id but is not able to conveniently obtain =
the user's URI in advance.

In other cases, temporary and permanent redirection seem like a natural =
requirement for any REST service over time.  Though I must confess in =
many cases the issue is reduced since service providers would tend to =
coordinate with clients when data set URIs are changed as part of a =
service migration.

Proposed text:

5.0 Redirection Support

Section 10.3 of the HTTP specification [RFC2616] defines several =
redirect response codes normally used to redirect user-agents (browsers) =
in response to HTTP requests. As SCIM is not intended for user-agents, =
this section clarifies the use of HTTP redirection codes.

In order to preserve the integrity of SCIM operations, HTTP redirection =
codes 301-306 SHOULD NOT be used unless the service provider is aware =
the client is in fact a user-agent.  Redirection code 301-306 are =
require the clients to convert requests to HTTP GET or HEAD and are not =
normally suitable.
"The action required MAY be carried out by the user agent without =
interaction with the user if and only if the method used in the second =
request is GET or HEAD."

Because SCIM is a RESTful API and is normally performed without user =
interaction, HTTP redirection SHOULD preserve the integrity of requests =
after a redirect. This section clarifies the use of HTTP redirect code =
307, as defined in [RFC2616] and HTTP Redirect code 308 as defined in =
[draft-reschke-http-status-308]. In both cases, the processing rules for =
Redirect 307 and 308 are to be applied.

Upon receiving a redirect, SCIM clients SHOULD preserve the HTTP action =
and SCIM operation by applying it to the new resource location specified =
in the redirect.

SCIM servers MAY issue two types of HTTP redirects:  HTTP redirect 307 =
for temporary redirection and HTTP redirect 308 for permanent =
redirection.

5.1 Temporary Redirection

A service provider MAY temporarily redirect clients using HTTP 307 as =
specified in RFC2616. The original HTTP action MUST be preserved. =
Clients MUST ensure that the new location keeps the operation intent =
intact.

The SCIM client MUST use the original permanent URI when referencing the =
affected SCIM resource in any other SCIM operations or SCIM resource =
(e.g. such as a Group).

If there is no user-agent involved in the transaction, the SCIM client =
MAY proceed by automatically processing the redirect.

5.2 Permanent Redirection

In the event that a SCIM resource has been relocated or reassigned, a =
service provider MAY issue an HTTP 308 redirect as specified in =
[draft-reschke-http-status-308]. This redirect informs the SCIM client =
of the new permanent URI for the object.=20

SCIM clients MUST ensure that the new address keeps the operation intent =
intact and the same HTTP verb is used.

The SCIM client MUST use the new permanent URI when referencing the =
affected SCIM resource in any other SCIM operations or SCIM resource =
(e.g. such as a Group).

If there is no user-agent involved in the transaction, the SCIM client =
MAY proceed by automatically processing the redirect.

5.2.1 Alias Redirection

A SCIM service provider MAY support aliases by using HTTP 308 =
redirection [draft-reschke-http-status-308]. =20

Servers that DO NOT support aliases SHOULD respond with HTTP 404 (not =
found) if an aliased request is received or is not otherwise resolvable.

An aliases SHALL use HTTP 308 permanent redirects and follow the same =
processing rules in section [section 5.2].

5.2.1.1 Self-Referencing

In situations where the client wishes to refer to the current security =
context of the user, the server may translate a URI ending in "/me" to =
mean the resource represented by current authenticated subject.=20

If "/me" does not resolve to a resource within the service endpoint =
requested, the service provider MUST respond with HTTP 404 (not found). =
If subject is resolved to a local resource, the service provider MAY use =
HTTP 308 to redirect the SCIM client to the permanent URI of the =
authenticated subject.

5.2.1.2 Unique-Key Reference

A client may wish to reference a resource by a unique-key alias such as =
a username. A non-normative example request URI would be of the form:

PATCH http://example.com//v2/Users/

If the server is able to resolve the alias to the permanent resource =
URI, the service provider MAY redirect the SCIM client to the permanent =
URI using HTTP 308.=20

The service provider SHALL return HTTP 404 (not found) if the alias =
cannot be translated into a permanent URI.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com


--Apple-Mail=_6659EEDF-586B-4B56-BD49-E07DB3409186
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

5.0 =
Redirection Support

Section 10.3 of =
the HTTP specification [RFC2616] defines several redirect response codes =
normally used to redirect user-agents (browsers) in response to HTTP =
requests. As SCIM is not intended for user-agents, this section =
clarifies the use of HTTP redirection codes.

In =
order to preserve the integrity of SCIM operations, HTTP redirection =
codes 301-306 SHOULD NOT be used unless the service provider is aware =
the client is in fact a user-agent.  Redirection code 301-306 are =
require the clients to convert requests to HTTP GET or HEAD and are not =
normally suitable.
"The =
action required MAY be carried out by the user agent without =
interaction with the user if and only if the method used in the =
second request is GET or =
HEAD."

Because SCIM is a =
RESTful API and is normally performed without user interaction, HTTP =
redirection SHOULD preserve the integrity of requests after a redirect. =
This section clarifies the use of HTTP redirect code 307, as defined in =
[RFC2616] and HTTP Redirect code 308 as defined =
in [draft-reschke-http-status-308]. In both cases, the processing =
rules for Redirect 307 and 308 are to be applied.

Upon receiving a redirect, SCIM clients SHOULD preserve the HTTP =
action and SCIM operation by applying it to the new resource location =
specified in the redirect.

SCIM servers MAY =
issue two types of HTTP redirects:  HTTP redirect 307 for temporary =
redirection and HTTP redirect 308 for permanent =
redirection.

5.1 Temporary =
Redirection

A service provider =
MAY temporarily redirect clients using HTTP 307 as specified in RFC2616. =
The original HTTP action MUST be preserved. Clients MUST ensure that the =
new location keeps the operation intent intact.

The SCIM client MUST use the original permanent URI when =
referencing the affected SCIM resource in any other SCIM operations or =
SCIM resource (e.g. such as a Group).

If there is no user-agent involved in the =
transaction, the SCIM client MAY proceed by automatically processing the =
redirect.

5.2 Permanent =
Redirection

In the event that a =
SCIM resource has been relocated or reassigned, a service provider MAY =
issue an HTTP 308 redirect as specified =
in [draft-reschke-http-status-308]. This redirect informs the SCIM =
client of the new permanent URI for the =
object. 

SCIM clients MUST =
ensure that the new address keeps the operation intent intact and the =
same HTTP verb is used.

The SCIM =
client MUST use the new permanent URI when referencing the affected SCIM =
resource in any other SCIM operations or SCIM resource (e.g. such as a =
Group).

If =
there is no user-agent involved in the transaction, the SCIM client MAY =
proceed by automatically processing the =
redirect.

5.2.1 =
Alias Redirection

A SCIM service provider =
MAY support aliases by using HTTP 308 =
redirection [draft-reschke-http-status-308]. =
 

Servers that DO =
NOT support aliases SHOULD respond with HTTP 404 (not found) if an =
aliased request is received or is not otherwise =
resolvable.

An aliases SHALL =
use HTTP 308 permanent redirects and follow the same processing rules in =
section [section 5.2].

5.2.1.1 Self-Referencing

In situations where the =
client wishes to refer to the current security context of the user, the =
server may translate a URI ending in "/me" to mean the resource =
represented by current authenticated =
subject. 

If "/me" does not =
resolve to a resource within the service endpoint requested, the service =
provider MUST respond with HTTP 404 (not found). If subject is resolved =
to a local resource, the service provider MAY use HTTP 308 to redirect =
the SCIM client to the permanent URI of the authenticated =
subject.

5.2.1.2 =
Unique-Key Reference

A client may wish to =
reference a resource by a unique-key alias such as a username. A =
non-normative example request URI would be of the =
form:


If the server is =
able to resolve the alias to the permanent resource URI, the service =
provider MAY redirect the SCIM client to the permanent URI using HTTP =
308. 

The service =
provider SHALL return HTTP 404 (not found) if the alias cannot be =
translated into a permanent =
URI.

=

--Apple-Mail=_6659EEDF-586B-4B56-BD49-E07DB3409186--

From pradtke@stanford.edu  Wed Dec 11 12:56:42 2013
Return-Path: 
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 7F07B1ADF55 for ; Wed, 11 Dec 2013 12:56:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level: 
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
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 dpxGtqjjf5rU for ; Wed, 11 Dec 2013 12:56:40 -0800 (PST)
Received: from smtp.stanford.edu (smtp2.Stanford.EDU [171.67.219.82]) by ietfa.amsl.com (Postfix) with ESMTP id 47CE51ADF68 for ; Wed, 11 Dec 2013 12:56:40 -0800 (PST)
Received: from smtp.stanford.edu (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id DF2F5340D94; Wed, 11 Dec 2013 12:56:34 -0800 (PST)
Received: from radtke.local (c-50-131-40-145.hsd1.ca.comcast.net [50.131.40.145]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: pradtke) by smtp.stanford.edu (Postfix) with ESMTPSA id 463C4340C29; Wed, 11 Dec 2013 12:56:34 -0800 (PST)
Message-ID: <52A8D181.10908@stanford.edu>
Date: Wed, 11 Dec 2013 12:56:33 -0800
From: Patrick Radtke 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Phil Hunt , "scim@ietf.org WG" 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [scim] SCIM Redirect Support Clarification - Draft Proposal
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Simple Cloud Identity Management BOF 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Dec 2013 20:56:42 -0000

Thanks for the writeup Phil.

I know your example "Unique-Key Reference" is non-normative, but I 
suspect implementers will base their URL syntax on the example and it 
will become a defacto standard.

 From a client/service consumer perspective, that URL pattern is bad for 
our organization. We have a user with the username "me". If we integrate 
with a service provider that supports both 5.2.1.1 and 5.2.1.2 (with the 
example url syntax), one of those two features will break once we add 
our user "me".

 From an implementor's perspective, I would prefer to know the attribute 
key for the unique reference so I don't have to do multiple lookups 
internally. For example, if someone queried "Users/bob234ad", then 
internally I would lookup the resource by id, if not found then lookup 
by username, if not found then lookup by external_id). While the spec, 
as written, allows me to use whatever URL pattern I see fit, I would be 
worried that client implementations would only support the example 
syntax given.

I would highly prefer an example URL that contains they 'key' attribute 
name in the url to avoid usage of a URL pattern that will be problematic 
for us.

   PATCH http://example.com//v2/Users/userName=


-Patrick


On 12/11/13, 12:10 PM, Phil Hunt wrote:
> The following is a new section to be added to draft-ietf-scim-api.  This
> provides clarification as to what HTTP redirects clients must support.
>
> My thought is we need to support 5.0 through 5.2.
>
> Section 5.2.1 (aliases) may be somewhat more controversial and thus has
> been written as an optional feature. I do agree strongly with the
> concern not to have multiple URIs for a resource. My thought here is
> that by using a redirect as a compromise, the redirect encourages the
> client to use the proper URL and thus might be seen as self-healing over
> time.  Yet at the same time, it does solve some scenarios where the
> client may be aware of a user-id but is not able to conveniently obtain
> the user's URI in advance.
>
> In other cases, temporary and permanent redirection seem like a natural
> requirement for any REST service over time.  Though I must confess in
> many cases the issue is reduced since service providers would tend to
> coordinate with clients when data set URIs are changed as part of a
> service migration.
>
> Proposed text:
>
> 5.0 Redirection Support
>
> Section 10.3 of the HTTP specification [RFC2616] defines several
> redirect response codes normally used to redirect user-agents (browsers)
> in response to HTTP requests. As SCIM is not intended for user-agents,
> this section clarifies the use of HTTP redirection codes.
>
> In order to preserve the integrity of SCIM operations, HTTP redirection
> codes 301-306 SHOULD NOT be used unless the service provider is aware
> the client is in fact a user-agent.  Redirection code 301-306 are
> require the clients to convert requests to HTTP GET or HEAD and are not
> normally suitable.
>
>     "The action required MAY be carried out by the user agent without
>     interaction with the user if and only if the method used in the
>     second request is GET or HEAD."
>
>
> Because SCIM is a RESTful API and is normally performed without user
> interaction, HTTP redirection SHOULD preserve the integrity of requests
> after a redirect. This section clarifies the use of HTTP redirect code
> 307, as defined in [RFC2616] and HTTP Redirect code 308 as defined
> in [draft-reschke-http-status-308]. In both cases, the processing rules
> for Redirect 307 and 308 are to be applied.
>
> Upon receiving a redirect, SCIM clients SHOULD preserve the HTTP action
> and SCIM operation by applying it to the new resource location specified
> in the redirect.
>
> SCIM servers MAY issue two types of HTTP redirects:  HTTP redirect 307
> for temporary redirection and HTTP redirect 308 for permanent redirection.
>
> 5.1 Temporary Redirection
>
>     A service provider MAY temporarily redirect clients using HTTP 307
>     as specified in RFC2616. The original HTTP action MUST be preserved.
>     Clients MUST ensure that the new location keeps the operation intent
>     intact.
>
>     The SCIM client MUST use the original permanent URI when referencing
>     the affected SCIM resource in any other SCIM operations or SCIM
>     resource (e.g. such as a Group).
>
>     If there is no user-agent involved in the transaction, the SCIM
>     client MAY proceed by automatically processing the redirect.
>
>
> 5.2 Permanent Redirection
>
>     In the event that a SCIM resource has been relocated or reassigned,
>     a service provider MAY issue an HTTP 308 redirect as specified
>     in [draft-reschke-http-status-308]. This redirect informs the SCIM
>     client of the new permanent URI for the object.
>
>     SCIM clients MUST ensure that the new address keeps the operation
>     intent intact and the same HTTP verb is used.
>
>     The SCIM client MUST use the new permanent URI when referencing the
>     affected SCIM resource in any other SCIM operations or SCIM resource
>     (e.g. such as a Group).
>
>     If there is no user-agent involved in the transaction, the SCIM
>     client MAY proceed by automatically processing the redirect.
>
>
> 5.2.1 Alias Redirection
>
>     A SCIM service provider MAY support aliases by using HTTP 308
>     redirection [draft-reschke-http-status-308].
>
>     Servers that DO NOT support aliases SHOULD respond with HTTP 404
>     (not found) if an aliased request is received or is not otherwise
>     resolvable.
>
>     An aliases SHALL use HTTP 308 permanent redirects and follow the
>     same processing rules in section [section 5.2].
>
> 5.2.1.1 Self-Referencing
>
>     In situations where the client wishes to refer to the current
>     security context of the user, the server may translate a URI ending
>     in "/me" to mean the resource represented by current authenticated
>     subject.
>
>     If "/me" does not resolve to a resource within the service endpoint
>     requested, the service provider MUST respond with HTTP 404 (not
>     found). If subject is resolved to a local resource, the service
>     provider MAY use HTTP 308 to redirect the SCIM client to the
>     permanent URI of the authenticated subject.
>
>
> 5.2.1.2 Unique-Key Reference
>
>     A client may wish to reference a resource by a unique-key alias such
>     as a username. A non-normative example request URI would be of the form:
>
>         PATCH http://example.com//v2/Users/
>
>
>     If the server is able to resolve the alias to the permanent resource
>     URI, the service provider MAY redirect the SCIM client to the
>     permanent URI using HTTP 308.
>
>     The service provider SHALL return HTTP 404 (not found) if the alias
>     cannot be translated into a permanent URI.
>
>
> Phil
>
> @independentid
> www.independentid.com 
> phil.hunt@oracle.com 
>
>
>
> _______________________________________________
> scim mailing list
> scim@ietf.org
> https://www.ietf.org/mailman/listinfo/scim
>


From phil.hunt@oracle.com  Wed Dec 11 13:08:25 2013
Return-Path: 
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 5675C1ADF6C for ; Wed, 11 Dec 2013 13:08:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level: 
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
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 Cz2TgfYQ0H3C for ; Wed, 11 Dec 2013 13:08:22 -0800 (PST)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 9B5831ADFF3 for ; Wed, 11 Dec 2013 13:08:22 -0800 (PST)
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id rBBL8GFu014032 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 Dec 2013 21:08:16 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rBBL8Fta018356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Dec 2013 21:08:15 GMT
Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rBBL8Eog013493; Wed, 11 Dec 2013 21:08:14 GMT
Received: from [192.168.1.12] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 11 Dec 2013 13:08:14 -0800
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Phil Hunt 
In-Reply-To: <52A8D181.10908@stanford.edu>
Date: Wed, 11 Dec 2013 13:08:12 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <0CE10FA1-97A0-4451-A2D9-09C08F590965@oracle.com>
References:  <52A8D181.10908@stanford.edu>
To: Patrick Radtke 
X-Mailer: Apple Mail (2.1510)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "scim@ietf.org WG" 
Subject: Re: [scim] SCIM Redirect Support Clarification - Draft Proposal
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Simple Cloud Identity Management BOF 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Dec 2013 21:08:25 -0000

see below
Phil

@independentid
www.independentid.com
phil.hunt@oracle.com

On 2013-12-11, at 12:56 PM, Patrick Radtke  wrote:

> Thanks for the writeup Phil.
>=20
> I know your example "Unique-Key Reference" is non-normative, but I =
suspect implementers will base their URL syntax on the example and it =
will become a defacto standard.
>=20
> =46rom a client/service consumer perspective, that URL pattern is bad =
for our organization. We have a user with the username "me". If we =
integrate with a service provider that supports both 5.2.1.1 and 5.2.1.2 =
(with the example url syntax), one of those two features will break once =
we add our user "me".
That is unfortunate. Yet I suspect there is significant weight behind =
"me" thanks to Facebook. If we changed to "self" is someone else going =
to complain about that?  we have to choose something.  "self" then?
>=20
> =46rom an implementor's perspective, I would prefer to know the =
attribute key for the unique reference so I don't have to do multiple =
lookups internally. For example, if someone queried "Users/bob234ad", =
then internally I would lookup the resource by id, if not found then =
lookup by username, if not found then lookup by external_id). While the =
spec, as written, allows me to use whatever URL pattern I see fit, I =
would be worried that client implementations would only support the =
example syntax given.

I think this is something entirely for the SP to decide through some =
external negotiation. The format proposed was based on what MS is doing =
with OData and Google is doing with Google Directory. =20
>=20
> I would highly prefer an example URL that contains they 'key' =
attribute name in the url to avoid usage of a URL pattern that will be =
problematic for us.
>=20
>  PATCH http://example.com//v2/Users/userName=3D

The only concern here is that then clients will want to go to full =
filters with multiple terms.  E.g.

PATCH http://example.com//v2/Users?filter=3DuserName eq =


Aside from causing some invalid operation scenarios, I think we don't =
want to encourage this pattern too much. We want to keep it as limited =
as possible.

The real anti-pattern here is the desire by clients to "calculate" a URL =
rather than query for it in the first place. My gut feel is that in most =
cases this can be decided based on the context of the relationship =
between client and service provider.

The real debate will likely be that those who want aliases will not want =
redirects. They'll want that aliased URL to be handled as if it were the =
URL -- leading us to multi-URLs per object.

Curious to see what other people think.  I'd love to kill it, but I =
think even my employer won't agree.
>=20
>=20
> -Patrick
>=20
>=20
> On 12/11/13, 12:10 PM, Phil Hunt wrote:
>> The following is a new section to be added to draft-ietf-scim-api.  =
This
>> provides clarification as to what HTTP redirects clients must =
support.
>>=20
>> My thought is we need to support 5.0 through 5.2.
>>=20
>> Section 5.2.1 (aliases) may be somewhat more controversial and thus =
has
>> been written as an optional feature. I do agree strongly with the
>> concern not to have multiple URIs for a resource. My thought here is
>> that by using a redirect as a compromise, the redirect encourages the
>> client to use the proper URL and thus might be seen as self-healing =
over
>> time.  Yet at the same time, it does solve some scenarios where the
>> client may be aware of a user-id but is not able to conveniently =
obtain
>> the user's URI in advance.
>>=20
>> In other cases, temporary and permanent redirection seem like a =
natural
>> requirement for any REST service over time.  Though I must confess in
>> many cases the issue is reduced since service providers would tend to
>> coordinate with clients when data set URIs are changed as part of a
>> service migration.
>>=20
>> Proposed text:
>>=20
>> 5.0 Redirection Support
>>=20
>> Section 10.3 of the HTTP specification [RFC2616] defines several
>> redirect response codes normally used to redirect user-agents =
(browsers)
>> in response to HTTP requests. As SCIM is not intended for =
user-agents,
>> this section clarifies the use of HTTP redirection codes.
>>=20
>> In order to preserve the integrity of SCIM operations, HTTP =
redirection
>> codes 301-306 SHOULD NOT be used unless the service provider is aware
>> the client is in fact a user-agent.  Redirection code 301-306 are
>> require the clients to convert requests to HTTP GET or HEAD and are =
not
>> normally suitable.
>>=20
>>    "The action required MAY be carried out by the user agent without
>>    interaction with the user if and only if the method used in the
>>    second request is GET or HEAD."
>>=20
>>=20
>> Because SCIM is a RESTful API and is normally performed without user
>> interaction, HTTP redirection SHOULD preserve the integrity of =
requests
>> after a redirect. This section clarifies the use of HTTP redirect =
code
>> 307, as defined in [RFC2616] and HTTP Redirect code 308 as defined
>> in [draft-reschke-http-status-308]. In both cases, the processing =
rules
>> for Redirect 307 and 308 are to be applied.
>>=20
>> Upon receiving a redirect, SCIM clients SHOULD preserve the HTTP =
action
>> and SCIM operation by applying it to the new resource location =
specified
>> in the redirect.
>>=20
>> SCIM servers MAY issue two types of HTTP redirects:  HTTP redirect =
307
>> for temporary redirection and HTTP redirect 308 for permanent =
redirection.
>>=20
>> 5.1 Temporary Redirection
>>=20
>>    A service provider MAY temporarily redirect clients using HTTP 307
>>    as specified in RFC2616. The original HTTP action MUST be =
preserved.
>>    Clients MUST ensure that the new location keeps the operation =
intent
>>    intact.
>>=20
>>    The SCIM client MUST use the original permanent URI when =
referencing
>>    the affected SCIM resource in any other SCIM operations or SCIM
>>    resource (e.g. such as a Group).
>>=20
>>    If there is no user-agent involved in the transaction, the SCIM
>>    client MAY proceed by automatically processing the redirect.
>>=20
>>=20
>> 5.2 Permanent Redirection
>>=20
>>    In the event that a SCIM resource has been relocated or =
reassigned,
>>    a service provider MAY issue an HTTP 308 redirect as specified
>>    in [draft-reschke-http-status-308]. This redirect informs the SCIM
>>    client of the new permanent URI for the object.
>>=20
>>    SCIM clients MUST ensure that the new address keeps the operation
>>    intent intact and the same HTTP verb is used.
>>=20
>>    The SCIM client MUST use the new permanent URI when referencing =
the
>>    affected SCIM resource in any other SCIM operations or SCIM =
resource
>>    (e.g. such as a Group).
>>=20
>>    If there is no user-agent involved in the transaction, the SCIM
>>    client MAY proceed by automatically processing the redirect.
>>=20
>>=20
>> 5.2.1 Alias Redirection
>>=20
>>    A SCIM service provider MAY support aliases by using HTTP 308
>>    redirection [draft-reschke-http-status-308].
>>=20
>>    Servers that DO NOT support aliases SHOULD respond with HTTP 404
>>    (not found) if an aliased request is received or is not otherwise
>>    resolvable.
>>=20
>>    An aliases SHALL use HTTP 308 permanent redirects and follow the
>>    same processing rules in section [section 5.2].
>>=20
>> 5.2.1.1 Self-Referencing
>>=20
>>    In situations where the client wishes to refer to the current
>>    security context of the user, the server may translate a URI =
ending
>>    in "/me" to mean the resource represented by current authenticated
>>    subject.
>>=20
>>    If "/me" does not resolve to a resource within the service =
endpoint
>>    requested, the service provider MUST respond with HTTP 404 (not
>>    found). If subject is resolved to a local resource, the service
>>    provider MAY use HTTP 308 to redirect the SCIM client to the
>>    permanent URI of the authenticated subject.
>>=20
>>=20
>> 5.2.1.2 Unique-Key Reference
>>=20
>>    A client may wish to reference a resource by a unique-key alias =
such
>>    as a username. A non-normative example request URI would be of the =
form:
>>=20
>>        PATCH http://example.com//v2/Users/
>>=20
>>=20
>>    If the server is able to resolve the alias to the permanent =
resource
>>    URI, the service provider MAY redirect the SCIM client to the
>>    permanent URI using HTTP 308.
>>=20
>>    The service provider SHALL return HTTP 404 (not found) if the =
alias
>>    cannot be translated into a permanent URI.
>>=20
>>=20
>> Phil
>>=20
>> @independentid
>> www.independentid.com 
>> phil.hunt@oracle.com 
>>=20
>>=20
>>=20
>> _______________________________________________
>> scim mailing list
>> scim@ietf.org
>> https://www.ietf.org/mailman/listinfo/scim
>>=20
>=20
> _______________________________________________
> scim mailing list
> scim@ietf.org
> https://www.ietf.org/mailman/listinfo/scim


From phil.hunt@oracle.com  Wed Dec 11 13:14:57 2013
Return-Path: 
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 32DA41AD694 for ; Wed, 11 Dec 2013 13:14:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level: 
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
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 XURzqXd4WDRU for ; Wed, 11 Dec 2013 13:14:54 -0800 (PST)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 708B61A1F5D for ; Wed, 11 Dec 2013 13:14:54 -0800 (PST)
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id rBBLElQY020487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 Dec 2013 21:14:48 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rBBLElCf023844 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Dec 2013 21:14:47 GMT
Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rBBLEluA004961; Wed, 11 Dec 2013 21:14:47 GMT
Received: from [192.168.1.12] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 11 Dec 2013 13:14:47 -0800
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Phil Hunt 
In-Reply-To: <0CE10FA1-97A0-4451-A2D9-09C08F590965@oracle.com>
Date: Wed, 11 Dec 2013 13:14:45 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <83E3D2E7-C5EF-4D1D-B1C2-BB010E33E420@oracle.com>
References:  <52A8D181.10908@stanford.edu> <0CE10FA1-97A0-4451-A2D9-09C08F590965@oracle.com>
To: Patrick Radtke 
X-Mailer: Apple Mail (2.1510)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: "scim@ietf.org WG" 
Subject: Re: [scim] SCIM Redirect Support Clarification - Draft Proposal
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Simple Cloud Identity Management BOF 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Dec 2013 21:14:57 -0000

Patrick,

It occurs to me that if "/me" is performed at the root level then it =
won't conflict with /Users/me.  Would that work?  Using a root level =
match might actually work better for cases where the client security =
context is not a user, but rather a client "service" that has been =
issued its own credential.

Note: for cases like OAuth delegated tokens I would expect "me" or self =
to resolve to the resource owner.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com

On 2013-12-11, at 1:08 PM, Phil Hunt  wrote:

> see below
> Phil
>=20
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>=20
> On 2013-12-11, at 12:56 PM, Patrick Radtke  =
wrote:
>=20
>> Thanks for the writeup Phil.
>>=20
>> I know your example "Unique-Key Reference" is non-normative, but I =
suspect implementers will base their URL syntax on the example and it =
will become a defacto standard.
>>=20
>> =46rom a client/service consumer perspective, that URL pattern is bad =
for our organization. We have a user with the username "me". If we =
integrate with a service provider that supports both 5.2.1.1 and 5.2.1.2 =
(with the example url syntax), one of those two features will break once =
we add our user "me".
> That is unfortunate. Yet I suspect there is significant weight behind =
"me" thanks to Facebook. If we changed to "self" is someone else going =
to complain about that?  we have to choose something.  "self" then?
>>=20
>> =46rom an implementor's perspective, I would prefer to know the =
attribute key for the unique reference so I don't have to do multiple =
lookups internally. For example, if someone queried "Users/bob234ad", =
then internally I would lookup the resource by id, if not found then =
lookup by username, if not found then lookup by external_id). While the =
spec, as written, allows me to use whatever URL pattern I see fit, I =
would be worried that client implementations would only support the =
example syntax given.
>=20
> I think this is something entirely for the SP to decide through some =
external negotiation. The format proposed was based on what MS is doing =
with OData and Google is doing with Google Directory. =20
>>=20
>> I would highly prefer an example URL that contains they 'key' =
attribute name in the url to avoid usage of a URL pattern that will be =
problematic for us.
>>=20
>> PATCH http://example.com//v2/Users/userName=3D
>=20
> The only concern here is that then clients will want to go to full =
filters with multiple terms.  E.g.
>=20
> PATCH http://example.com//v2/Users?filter=3DuserName eq =

>=20
> Aside from causing some invalid operation scenarios, I think we don't =
want to encourage this pattern too much. We want to keep it as limited =
as possible.
>=20
> The real anti-pattern here is the desire by clients to "calculate" a =
URL rather than query for it in the first place. My gut feel is that in =
most cases this can be decided based on the context of the relationship =
between client and service provider.
>=20
> The real debate will likely be that those who want aliases will not =
want redirects. They'll want that aliased URL to be handled as if it =
were the URL -- leading us to multi-URLs per object.
>=20
> Curious to see what other people think.  I'd love to kill it, but I =
think even my employer won't agree.
>>=20
>>=20
>> -Patrick
>>=20
>>=20
>> On 12/11/13, 12:10 PM, Phil Hunt wrote:
>>> The following is a new section to be added to draft-ietf-scim-api.  =
This
>>> provides clarification as to what HTTP redirects clients must =
support.
>>>=20
>>> My thought is we need to support 5.0 through 5.2.
>>>=20
>>> Section 5.2.1 (aliases) may be somewhat more controversial and thus =
has
>>> been written as an optional feature. I do agree strongly with the
>>> concern not to have multiple URIs for a resource. My thought here is
>>> that by using a redirect as a compromise, the redirect encourages =
the
>>> client to use the proper URL and thus might be seen as self-healing =
over
>>> time.  Yet at the same time, it does solve some scenarios where the
>>> client may be aware of a user-id but is not able to conveniently =
obtain
>>> the user's URI in advance.
>>>=20
>>> In other cases, temporary and permanent redirection seem like a =
natural
>>> requirement for any REST service over time.  Though I must confess =
in
>>> many cases the issue is reduced since service providers would tend =
to
>>> coordinate with clients when data set URIs are changed as part of a
>>> service migration.
>>>=20
>>> Proposed text:
>>>=20
>>> 5.0 Redirection Support
>>>=20
>>> Section 10.3 of the HTTP specification [RFC2616] defines several
>>> redirect response codes normally used to redirect user-agents =
(browsers)
>>> in response to HTTP requests. As SCIM is not intended for =
user-agents,
>>> this section clarifies the use of HTTP redirection codes.
>>>=20
>>> In order to preserve the integrity of SCIM operations, HTTP =
redirection
>>> codes 301-306 SHOULD NOT be used unless the service provider is =
aware
>>> the client is in fact a user-agent.  Redirection code 301-306 are
>>> require the clients to convert requests to HTTP GET or HEAD and are =
not
>>> normally suitable.
>>>=20
>>>   "The action required MAY be carried out by the user agent without
>>>   interaction with the user if and only if the method used in the
>>>   second request is GET or HEAD."
>>>=20
>>>=20
>>> Because SCIM is a RESTful API and is normally performed without user
>>> interaction, HTTP redirection SHOULD preserve the integrity of =
requests
>>> after a redirect. This section clarifies the use of HTTP redirect =
code
>>> 307, as defined in [RFC2616] and HTTP Redirect code 308 as defined
>>> in [draft-reschke-http-status-308]. In both cases, the processing =
rules
>>> for Redirect 307 and 308 are to be applied.
>>>=20
>>> Upon receiving a redirect, SCIM clients SHOULD preserve the HTTP =
action
>>> and SCIM operation by applying it to the new resource location =
specified
>>> in the redirect.
>>>=20
>>> SCIM servers MAY issue two types of HTTP redirects:  HTTP redirect =
307
>>> for temporary redirection and HTTP redirect 308 for permanent =
redirection.
>>>=20
>>> 5.1 Temporary Redirection
>>>=20
>>>   A service provider MAY temporarily redirect clients using HTTP 307
>>>   as specified in RFC2616. The original HTTP action MUST be =
preserved.
>>>   Clients MUST ensure that the new location keeps the operation =
intent
>>>   intact.
>>>=20
>>>   The SCIM client MUST use the original permanent URI when =
referencing
>>>   the affected SCIM resource in any other SCIM operations or SCIM
>>>   resource (e.g. such as a Group).
>>>=20
>>>   If there is no user-agent involved in the transaction, the SCIM
>>>   client MAY proceed by automatically processing the redirect.
>>>=20
>>>=20
>>> 5.2 Permanent Redirection
>>>=20
>>>   In the event that a SCIM resource has been relocated or =
reassigned,
>>>   a service provider MAY issue an HTTP 308 redirect as specified
>>>   in [draft-reschke-http-status-308]. This redirect informs the SCIM
>>>   client of the new permanent URI for the object.
>>>=20
>>>   SCIM clients MUST ensure that the new address keeps the operation
>>>   intent intact and the same HTTP verb is used.
>>>=20
>>>   The SCIM client MUST use the new permanent URI when referencing =
the
>>>   affected SCIM resource in any other SCIM operations or SCIM =
resource
>>>   (e.g. such as a Group).
>>>=20
>>>   If there is no user-agent involved in the transaction, the SCIM
>>>   client MAY proceed by automatically processing the redirect.
>>>=20
>>>=20
>>> 5.2.1 Alias Redirection
>>>=20
>>>   A SCIM service provider MAY support aliases by using HTTP 308
>>>   redirection [draft-reschke-http-status-308].
>>>=20
>>>   Servers that DO NOT support aliases SHOULD respond with HTTP 404
>>>   (not found) if an aliased request is received or is not otherwise
>>>   resolvable.
>>>=20
>>>   An aliases SHALL use HTTP 308 permanent redirects and follow the
>>>   same processing rules in section [section 5.2].
>>>=20
>>> 5.2.1.1 Self-Referencing
>>>=20
>>>   In situations where the client wishes to refer to the current
>>>   security context of the user, the server may translate a URI =
ending
>>>   in "/me" to mean the resource represented by current authenticated
>>>   subject.
>>>=20
>>>   If "/me" does not resolve to a resource within the service =
endpoint
>>>   requested, the service provider MUST respond with HTTP 404 (not
>>>   found). If subject is resolved to a local resource, the service
>>>   provider MAY use HTTP 308 to redirect the SCIM client to the
>>>   permanent URI of the authenticated subject.
>>>=20
>>>=20
>>> 5.2.1.2 Unique-Key Reference
>>>=20
>>>   A client may wish to reference a resource by a unique-key alias =
such
>>>   as a username. A non-normative example request URI would be of the =
form:
>>>=20
>>>       PATCH http://example.com//v2/Users/
>>>=20
>>>=20
>>>   If the server is able to resolve the alias to the permanent =
resource
>>>   URI, the service provider MAY redirect the SCIM client to the
>>>   permanent URI using HTTP 308.
>>>=20
>>>   The service provider SHALL return HTTP 404 (not found) if the =
alias
>>>   cannot be translated into a permanent URI.
>>>=20
>>>=20
>>> Phil
>>>=20
>>> @independentid
>>> www.independentid.com 
>>> phil.hunt@oracle.com 
>>>=20
>>>=20
>>>=20
>>> _______________________________________________
>>> scim mailing list
>>> scim@ietf.org
>>> https://www.ietf.org/mailman/listinfo/scim
>>>=20
>>=20
>> _______________________________________________
>> scim mailing list
>> scim@ietf.org
>> https://www.ietf.org/mailman/listinfo/scim
>=20
> _______________________________________________
> scim mailing list
> scim@ietf.org
> https://www.ietf.org/mailman/listinfo/scim


From pradtke@stanford.edu  Wed Dec 11 13:26:40 2013
Return-Path: 
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 CE0491AE01F for ; Wed, 11 Dec 2013 13:26:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level: 
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
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 djWPb-WfZ_Ep for ; Wed, 11 Dec 2013 13:26:39 -0800 (PST)
Received: from smtp.stanford.edu (smtp2.Stanford.EDU [171.67.219.82]) by ietfa.amsl.com (Postfix) with ESMTP id CF3AA1AE01E for ; Wed, 11 Dec 2013 13:26:39 -0800 (PST)
Received: from smtp.stanford.edu (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 6DA30340E9F; Wed, 11 Dec 2013 13:26:34 -0800 (PST)
Received: from radtke.local (c-50-131-40-145.hsd1.ca.comcast.net [50.131.40.145]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: pradtke) by smtp.stanford.edu (Postfix) with ESMTPSA id 31433340D6D; Wed, 11 Dec 2013 13:26:34 -0800 (PST)
Message-ID: <52A8D889.4050207@stanford.edu>
Date: Wed, 11 Dec 2013 13:26:33 -0800
From: Patrick Radtke 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Phil Hunt 
References:  <52A8D181.10908@stanford.edu> <0CE10FA1-97A0-4451-A2D9-09C08F590965@oracle.com> <83E3D2E7-C5EF-4D1D-B1C2-BB010E33E420@oracle.com>
In-Reply-To: <83E3D2E7-C5EF-4D1D-B1C2-BB010E33E420@oracle.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "scim@ietf.org WG" 
Subject: Re: [scim] SCIM Redirect Support Clarification - Draft Proposal
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Simple Cloud Identity Management BOF 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Dec 2013 21:26:41 -0000

On 12/11/13, 1:14 PM, Phil Hunt wrote:
> Patrick,
>
> It occurs to me that if "/me" is performed at the root level then it won't conflict with /Users/me.  Would that work?  Using a root level match might actually work better for cases where the client security context is not a user, but rather a client "service" that has been issued its own credential.
>
> Note: for cases like OAuth delegated tokens I would expect "me" or self to resolve to the resource owner.

I like that idea.

Looking around at other alternatives, OpenSocial uses @me and LinkedIn 
uses ~.
If we need to go under the /Users/ then either of those would work for 
us. They contain special characters which makes them less likely to 
conflict with a userName.

thanks Phil,

Patrick


From leifj@sunet.se  Tue Dec 17 23:49:57 2013
Return-Path: 
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 79EDA1AE0CE for ; Tue, 17 Dec 2013 23:49:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.309
X-Spam-Level: 
X-Spam-Status: No, score=-1.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.538, SPF_NEUTRAL=0.779] 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 vf-sfbRHiCyl for ; Tue, 17 Dec 2013 23:49:55 -0800 (PST)
Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) by ietfa.amsl.com (Postfix) with ESMTP id AF5201ADFF6 for ; Tue, 17 Dec 2013 23:49:54 -0800 (PST)
Received: from smtp1.sunet.se (smtp1.sunet.se [IPv6:2001:6b0:8:2::214]) by e-mailfilter01.sunet.se (8.14.3/8.14.3/Debian-9.4) with ESMTP id rBI7npLc016109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 18 Dec 2013 08:49:52 +0100
Received: from kerio.sunet.se (kerio.sunet.se [192.36.171.210]) by smtp1.sunet.se (8.14.4/8.14.4) with ESMTP id rBI56DiP027555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 18 Dec 2013 06:06:16 +0100 (CET)
X-Footer: c3VuZXQuc2U=
Received: from [193.10.94.23] ([193.10.94.23]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 8.2.1) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256 bits)) for scim@ietf.org; Wed, 18 Dec 2013 08:49:48 +0100
Message-ID: <52B1539C.1030102@sunet.se>
Date: Wed, 18 Dec 2013 08:49:48 +0100
From: Leif Johansson 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: "scim@ietf.org" 
References: <20131218073754.8878.38942.idtracker@ietfa.amsl.com>
In-Reply-To: <20131218073754.8878.38942.idtracker@ietfa.amsl.com>
X-Enigmail-Version: 1.6
X-Forwarded-Message-Id: <20131218073754.8878.38942.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, sunet-se:default, base:default, @@RPTN)
X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=62.0000; longitude=15.0000; http://maps.google.com/maps?q=62.0000,15.0000&z=6
X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default)
X-Canit-Stats-ID: 09L2TNPeM - 06fdf4630962 - 20131218
X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw
X-Scanned-By: CanIt (www . roaringpenguin . com)
Subject: [scim] Fwd: scim - New Meeting Session Request for IETF 89
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Simple Cloud Identity Management BOF 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Dec 2013 07:49:57 -0000

Folks,

so as not to forget, I've requested a 2hr session for us in London.

Me and Morteza are hoping that those of you who are regular
contributors, document editors and reviewers turn up in person but if
you know you won't be able to make it to London, please tell us early so
we know how much remote participation tooling to plan for.

        Cheers Leif

A new meeting session request has just been submitted by Leif Johansson, a Chair of the scim working group.


---------------------------------------------------------
Working Group Name: System for Cross-domain Identity Management
Area Name: Applications Area
Session Requester: Leif Johansson

Number of Sessions: 1
Length of Session(s):  2 Hours
Number of Attendees: 30
Conflicts to Avoid: 
 First Priority: abfab apparea appsawg oauth tls jose uta
 Second Priority: kitten xmpp



Special Requests:
  avoid security & identity related bofs
---------------------------------------------------------





From moransar@cisco.com  Fri Dec 20 23:30:28 2013
Return-Path: 
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 C78DE1AE2D4 for ; Fri, 20 Dec 2013 23:30:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.028
X-Spam-Level: 
X-Spam-Status: No, score=-15.028 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 w2HBVlrHiK_j for ; Fri, 20 Dec 2013 23:30:26 -0800 (PST)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id D6D451AE2DD for ; Fri, 20 Dec 2013 23:30:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23749; q=dns/txt; s=iport; t=1387611023; x=1388820623; h=from:to:subject:date:message-id:mime-version; bh=hpmPjptNDnCBxBCitPRr45h56FaiCr7f/JMx2IhcCDI=; b=ESffc9r7n1CzCs/Gi7BepEG3GaRog9ML2cbdONylPn+NzPTGfs2VBnw0 gsYR0GVCg6sF9i5tuyJAr1yOhiSzNAptRBi0STXYsG8KW9RiokF61qZxA n5LVnn3cd0MR/sXkNOH4j90AIEEkTLfwqMWJDtEmzLSrKAe3/cEVszZzp o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AmMFAA5DtVKtJXG//2dsb2JhbAA+FwOCR0Q4Sgu5PYEQFnSCJQECAgIvOQYdAQgHCgMBAhUECAQDORQDAQUHAwEDARKIBA02tQOVPxeFPIdGgUERAQweFQEMHAeEHgSYF5IUgUCBG1KBcTk
X-IronPort-AV: E=Sophos;i="4.95,526,1384300800";  d="scan'208,217";a="290088938"
Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-9.cisco.com with ESMTP; 21 Dec 2013 07:30:20 +0000
Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id rBL7UKLR029056 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 21 Dec 2013 07:30:20 GMT
Received: from xmb-rcd-x08.cisco.com ([169.254.8.144]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Sat, 21 Dec 2013 01:30:20 -0600
From: "Morteza Ansari (moransar)" 
To: "Morteza Ansari (moransar)" , "scim@ietf.org" 
Thread-Topic: [scim] Next SCIM WG call agenda - Dec. 18th @11AM Pacific
Thread-Index: AQHO/h6AcaBVd+A3BU2IiCapWoR2TQ==
Date: Sat, 21 Dec 2013 07:30:19 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.9.131030
x-originating-ip: [10.21.119.241]
Content-Type: multipart/alternative; boundary="_000_CEDA82EBC07FAmoransarciscocom_"
MIME-Version: 1.0
Subject: Re: [scim] Next SCIM WG call agenda - Dec. 18th @11AM Pacific
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Simple Cloud Identity Management BOF 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 21 Dec 2013 07:30:29 -0000

--_000_CEDA82EBC07FAmoransarciscocom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

I guess we should have polled the WG to see who is going to be joining this=
 call given it is getting close to the holidays.  Only a few folks joined t=
he call, certainly not enough to consider it a WG call.  We talked about a =
few items for a bit and called it a day. No WG discussion took place =96 no=
 notes.

The next WG call will be Jan. 15th, I will send a separate reminder along w=
ith agenda when it gets closer to the meeting.


Cheers,
Morteza

From: Morteza Ansari >
Date: Friday, December 6, 2013 12:37 AM
To: "scim@ietf.org" >
Subject: [scim] Next SCIM WG call agenda - Dec. 18th @11AM Pacific

Hi folks,

Just a reminder that the next and last 2013 SCIM WG call is scheduled for D=
ec. 18th at 11AM Pacific time. The agenda is not changed and we will go thr=
ough all the open issues. Please between now and then if have taken any iss=
ue and have a proposed text use the mailing list so we can get the easy one=
s out of the way and use the call time for more challenging issues requirin=
g live discussion.

The WebEx meeting info is not changed, but included here for reference.

Also note that we will not have a call on Jan 1st and the next one after De=
c. 18th call will be on Jan. 15th.


Cheers,
Morteza

Topic: SCIM WG bi-weekly call
Date: Every 2 weeks on Wednesday, from Wednesday, December 4, 2013 to no en=
d date
Time: 11:00 am, Pacific Standard Time (San Francisco, GMT-08:00)
Meeting Number: 340 844 711
Meeting Password: (This meeting does not require a password.)


-------------------------------------------------------
To join the online meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to https://go.webex.com/go/j.php?ED=3D153193777&UID=3D0&RT=3DMiM0
2. If requested, enter your name and email address.
3. If a password is required, enter the meeting password: (This meeting doe=
s not require a password.)
4. Click "Join".

To view in other time zones or languages, please click the link:
https://go.webex.com/go/j.php?ED=3D153193777&UID=3D0&ORT=3DMiM0

-------------------------------------------------------
To join the audio conference only
-------------------------------------------------------
To receive a call back, provide your phone number when you join the meeting=
, or call the number below and enter the access code.
US Toll Free: +1-855-749-4751
US Toll: +1-415-655-0000
Global call-in numbers: https://go.webex.com/go/globalcallin.php?serviceTyp=
e=3DMC&ED=3D153193777&tollFree=3D1
Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restricti=
ons.pdf

Access code:340 844 711

-------------------------------------------------------
For assistance
-------------------------------------------------------
1. Go to https://go.webex.com/go/mc
2. On the left navigation bar, click "Support".

You can contact me at:
moransar@cisco.com
1-408 566-5647

To update this meeting to your calendar program (for example Microsoft Outl=
ook), click this link:
https://go.webex.com/go/j.php?ED=3D153193777&UID=3D0&ICS=3DMRS1&LD=3D1&RD=
=3D2&ST=3D1&SHA2=3DAAAAARBGrx6g-3G8Y56jVVHaPSruhMgm2a/qNpXPxgH8MS4f&RT=3DMi=
M0


WebEx will automatically setup Meeting Manager for Windows the first time y=
ou join a meeting. To save time, you can setup prior to the meeting by clic=
king this link:
https://go.webex.com/go/meetingcenter/mcsetup.php


The playback of UCF (Universal Communications Format) rich media files requ=
ires appropriate players. To view this type of rich media files in the meet=
ing, please check whether you have the players installed on your computer b=
y going to https://go.webex.com/go/systemdiagnosis.php.

Sign up for a free trial of WebEx
http://www.webex.com/go/mcemfreetrial

http://www.webex.com

CCP:+14156550000x340844711#

IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a=
nd any documents and other materials exchanged or viewed during the session=
 to be recorded. By joining this session, you automatically consent to such=
 recordings. If you do not consent to the recording, discuss your concerns =
with the meeting host prior to the start of the recording or do not join th=
e session. Please note that any such recordings may be subject to discovery=
 in the event of litigation.

--_000_CEDA82EBC07FAmoransarciscocom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <68F509F39223A64FBB5340C6D80BC1B6@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable







I guess we should have polled the WG to see who is going to be joining=
 this call given it is getting close to the holidays.  Only a few folk=
s joined the call, certainly not enough to consider it a WG call.  We =
talked about a few items for a bit and called
 it a day. No WG discussion took place =96 no notes.







The next WG call will be Jan. 15th, I will send a separate reminder al=
ong with agenda when it gets closer to the meeting.












Cheers,


Morteza









From: Morteza Ansari <moransar@cisco.com>

Date: Friday, December 6, 2013 12:3=
7 AM

To: "scim@ietf.org" <scim@i=
etf.org>

Subject: [scim] Next SCIM WG call a=
genda - Dec. 18th @11AM Pacific















Hi folks,







Just a reminder that the next and las=
t 2013 SCIM WG call is scheduled for Dec. 18th at 11AM Pacific time. <=
span style=3D"font-family: Calibri, sans-serif; ">The agenda is not changed=
 and we will go through all the open issues. Please
 between now and then if have taken any issue and have a proposed text use =
the mailing list so we can get the easy ones out of the way and use the cal=
l time for more challenging issues requiring live discussion.







The WebEx meeting info is not changed, but included here for =
reference.









Also note that we will not have a call on Jan 1st and the next one aft=
er Dec. 18th call will be on Jan. 15th.












Cheers,


Morteza







Topic: SCIM WG bi-weekly call 

Date: Every 2 weeks on Wednesday, from Wednesday, Decemb=
er 4, 2013 to no end date 

Time: 11:00 am, Pacific Standard Time (San Francisco, GM=
T-08:00) 

Meeting Number: 340 844 711 

Meeting Password: (This meeting does not require a passw=
ord.) 





-------------------------------------------------------&=
nbsp;

To join the online meeting (Now from mobile devices!)&nb=
sp;

-------------------------------------------------------&=
nbsp;

1. Go to https://go.webex.com/go/j.php?ED=3D153193777&UID=3D0&RT=3DMiM0<=
/a> 

2. If requested, enter your name and email address. =
;

3. If a password is required, enter the meeting password=
: (This meeting does not require a password.) 

4. Click "Join". 



To view in other time zones or languages, please click t=
he link: 

https://go.webex.com/go/j.php?ED=3D=
153193777&UID=3D0&ORT=3DMiM0 


-------------------------------------------------------&=
nbsp;

To join the audio conference only 

-------------------------------------------------------&=
nbsp;

To receive a call back, provide your phone number when y=
ou join the meeting, or call the number below and enter the access code.&nb=
sp;

US Toll Free: +1-855-749-4751 

US Toll: +1-415-655-0000 
Global call-in numbers: https://go.webex.com/go/globalcal=
lin.php?serviceType=3DMC&ED=3D153193777&tollFree=3D1 

Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf 



Access code:340 844 711 



-------------------------------------------------------&=
nbsp;

For assistance 

-------------------------------------------------------&=
nbsp;

1. Go to https://go.webex.com/go/mc 

2. On the left navigation bar, click "Support"=
. 



You can contact me at: 

moransar@cisco.com 

1-408 566-5647 



To update this meeting to your calendar program (for exa=
mple Microsoft Outlook), click this link: 

htt=
ps://go.webex.com/go/j.php?ED=3D153193777&UID=3D0&ICS=3DMRS1&LD=
=3D1&RD=3D2&ST=3D1&SHA2=3DAAAAARBGrx6g-3G8Y56jVVHaPSruhMgm2a/qN=
pXPxgH8MS4f&RT=3DMiM0 



WebEx will automatically setup Meeting Manager for Windo=
ws the first time you join a meeting. To save time, you can setup prior to =
the meeting by clicking this link: 

https://go.webex.com/go/meetingcenter/mcsetup.php 





The playback of UCF (Universal Communications Format) ri=
ch media files requires appropriate players. To view this type of rich medi=
a files in the meeting, please check
 whether you have the players installed on your computer by going to <=
/span>=
https://go.webex.com/go/systemdiagnosis.php. 



Sign up for a free trial of WebEx 

http://www.webex.com/go/mcemfreetrial <=
/span>



http://www=
.webex.com 



CCP:+14156550000x340844711# 



IMPORTANT NOTICE: This WebEx service includes a feature =
that allows audio and any documents and other materials exchanged or viewed=
 during the session to be recorded.
 By joining this session, you automatically consent to such recordings. If =
you do not consent to the recording, discuss your concerns with the meeting=
 host prior to the start of the recording or do not join the session. Pleas=
e note that any such recordings
 may be subject to discovery in the event of litigation. 









--_000_CEDA82EBC07FAmoransarciscocom_--

From phil.hunt@oracle.com  Mon Dec 30 10:23:14 2013
Return-Path: 
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 3654D1AE2D5 for ; Mon, 30 Dec 2013 10:23:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.038
X-Spam-Level: 
X-Spam-Status: No, score=-2.038 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham
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 evkLkDkbW0Hz for ; Mon, 30 Dec 2013 10:23:10 -0800 (PST)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 6BFB91AE2EA for ; Mon, 30 Dec 2013 10:23:10 -0800 (PST)
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id rBUIN2xO029129 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 30 Dec 2013 18:23:03 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rBUIN2st024790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 30 Dec 2013 18:23:02 GMT
Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rBUIN1CT024772 for ; Mon, 30 Dec 2013 18:23:01 GMT
Received: from [192.168.1.124] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 30 Dec 2013 10:23:01 -0800
From: Phil Hunt 
Content-Type: multipart/alternative; boundary="Apple-Mail=_740498C2-0AA2-429B-AEA1-8E6A05F621CE"
Message-Id: <831A94AD-A84F-412C-ACFD-8A1BD99ECDBF@oracle.com>
Date: Mon, 30 Dec 2013 10:22:59 -0800
To: "scim@ietf.org WG" 
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
X-Mailer: Apple Mail (2.1510)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Subject: [scim] Open Ticket Recommendations (Tickets 1 to 20)
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Simple Cloud Identity Management BOF 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Dec 2013 18:23:14 -0000

--Apple-Mail=_740498C2-0AA2-429B-AEA1-8E6A05F621CE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

On the last SCIM WG conference call (where we did not have quorum), one =
of the follow-up items proposed by was for members to personally review =
the open tickets and make some recommendations to assist the chairs on =
disposition of the current items.  Many of them have proposals and many =
of them are straight forward.  This should help Kelly move forward with =
the next revision of the draft in a quicker fashion:

These are my personal recommendations, please comment with your +1 or =
preferred alternative action.  Note:  Missing ticket numbers are already =
resolved/closed.

Ticket:  1  Roles within Groups
Recommendation:  Won't fix
Comment:  Replaced by ticket 11

Ticket: 2 Add pagination capability to plural Resource attributes
Recommendation:  Won't fix
Comment:  Solved/impact reduced by ticket 10

Ticket: 3  ExcludedAttributes Parameter
Recommendation:  Leave as new (continue discussion)
Comment:  Impact reduced by ticket 10 - is there still a need to exclude =
attributes from the default set?  What about using "!" on the attributes =
parameter?

Ticket: 4  Bring SAML Binding Up to Date
Recommendation:  Leave as new
Comment:  No apparent work.

Ticket: 6  Nickname part of Name attribute
Recommendation:  Won't fix
Comment: While there are some advantages, I don't see enough value that =
making a change makes sense.  Making name complex makes mapping for LDAP =
harder.

Ticket: 8 Targeting and Proxying
Recommendation: Won't fix
Comment:  This functionality has been covered by draft 02 (tenancy =
section) and can be also enhanced by ticket 55 (redirection).

Ticket: 9 Add ability to mark attributes as unique in schemas
Recommendation: Apply to draft
Comment:  See discussion added Dec 30, values for uniqueness recommended =
(note: more discussion may be needed)

Ticket: 10 Ability to mark attributes as sensitive in schemas
Recommendation:  Apply to draft
Comment:  Significant discussion and work occurred prior to and at =
IETF88 (vancouver) where informal consensus was obtained

Ticket: 11 Define Simple Language for Entitlements
Recommendation:  Defer
Comment:  Chris Phillips did some good starting work. But I don't see =
enough discussion yet.  Focus on for a following draft?

Ticket: 12 OpenID Connect and SCIM
Recommendation:  Won't fix
Comment: This seems to be an item for OIDF.  That said, I have suggested =
that SCIM be a valid endpoint in draft-hunt-oauth-v2-user-a4c
Never-the-less, this isn't an item which impacts SCIM itself.  Should we =
leave open as a liaison/ note taking item?

Ticket : 13  Add "required" flag in configuration to support etags
Recommendation:  Apply to draft
Comment:  Though no proposed text is available, this seems straight =
forward

Ticket: 14 Enhance password and login metadata
Recommendation:  Defer to future draft
Comment:  There is significant work being done in the area by more than =
one participant. There is a need to make a standardized, inter-operable =
recommendation. However, there is no significant proposal on the ticket =
at this time.

Ticket: 15 Soft Delete and Resurrection
Recommendation: Defer to future draft

Ticket:16 Attribute selection in query responses
Recommendation:  Won't fix (Duplicate)
Comment:  This item covered by Ticket 10 which determines what =
attributes are returned by default

Ticket: 18 Review Patch Function
Recommendation: Defer
Comment:  Still had complaints on my side. Yet no new proposal has been =
drafted

Ticket: 20  Insert a "person" resource into the model
Recommendation:  Won't fix
Comment:  This ticket has been around for a while. While it seems like a =
good thing, we seem to have avoided hierarchical structures.  The =
current draft provides more details on schema extension and I think the =
need for this is minimal.  (please comment if you disagree!!)

Tickets 21 and higher will follow in another message=85

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com


--Apple-Mail=_740498C2-0AA2-429B-AEA1-8E6A05F621CE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

On =
the last SCIM WG conference call (where we did not have quorum), one of =
the follow-up items proposed by was for members to personally review the =
open tickets and make some recommendations to assist the chairs on =
disposition of the current items.  Many of them have proposals and =
many of them are straight forward.  This should help Kelly move =
forward with the next revision of the draft in a quicker =
fashion:

These are my personal recommendations, =
please comment with your +1 or preferred alternative action.  Note: =
 Missing ticket numbers are already =
resolved/closed.

Ticket:  1  Roles =
within Groups
Recommendation:  Won't =
fix
Comment:  Replaced by ticket =
11

Ticket: 2 Add pagination capability to =
plural Resource attributes
Recommendation:  Won't =
fix
Comment:  Solved/impact reduced by ticket =
10

Ticket: 3  ExcludedAttributes =
Parameter
Recommendation:  Leave as new (continue =
discussion)
Comment:  Impact reduced by ticket 10 - is =
there still a need to exclude attributes from the default set? =
 What about using "!" on the attributes =
parameter?

Ticket: 4  Bring SAML Binding =
Up to Date
Recommendation:  Leave as =
new
Comment:  No apparent =
work.

Ticket: 6  Nickname part of Name =
attribute
Recommendation:  Won't fix
Comment: =
While there are some advantages, I don't see enough value that making a =
change makes sense.  Making name complex makes mapping for LDAP =
harder.

Ticket: 8 Targeting and =
Proxying
Recommendation: Won't fix
Comment: =
 This functionality has been covered by draft 02 (tenancy section) =
and can be also enhanced by ticket 55 =
(redirection).

Ticket: 9 Add ability to mark =
attributes as unique in schemas
Recommendation: Apply to =
draft
Comment:  See discussion added Dec 30, values for =
uniqueness recommended (note: more discussion may be =
needed)

Ticket: 10 Ability to mark attributes =
as sensitive in schemas
Recommendation:  Apply to =
draft
Comment:  Significant discussion and work occurred =
prior to and at IETF88 (vancouver) where informal consensus was =
obtained

Ticket: 11 Define Simple Language for =
Entitlements
Recommendation:  Defer
Comment: =
 Chris Phillips did some good starting work. But I don't see enough =
discussion yet.  Focus on for a following =
draft?

Ticket: 12 OpenID Connect and =
SCIM
Recommendation:  Won't fix
Comment: This =
seems to be an item for OIDF.  That said, I have suggested that =
SCIM be a valid endpoint in draf=
t-hunt-oauth-v2-user-a4c
Never-the-less, this isn't an =
item which impacts SCIM itself.  Should we leave open as a liaison/ =
note taking item?

Ticket : 13  Add =
"required" flag in configuration to support =
etags
Recommendation:  Apply to draft
Comment: =
 Though no proposed text is available, this seems straight =
forward

Ticket: 14 Enhance password and login =
metadata
Recommendation:  Defer to future =
draft
Comment:  There is significant work being done in =
the area by more than one participant. There is a need to make a =
standardized, inter-operable recommendation. However, there is no =
significant proposal on the ticket at this =
time.

Ticket: 15 Soft Delete and =
Resurrection
Recommendation: Defer to future =
draft

Ticket:16 Attribute selection in query =
responses
Recommendation:  Won't fix =
(Duplicate)
Comment:  This item covered by Ticket 10 =
which determines what attributes are returned by =
default

Ticket: 18 Review Patch =
Function
Recommendation: Defer
Comment:  Still =
had complaints on my side. Yet no new proposal has been =
drafted

Ticket: 20  Insert a "person" =
resource into the model
Recommendation:  Won't =
fix
Comment:  This ticket has been around for a while. =
While it seems like a good thing, we seem to have avoided hierarchical =
structures.  The current draft provides more details on schema =
extension and I think the need for this is minimal.  (please =
comment if you disagree!!)

Tickets 21 and =
higher will follow in another message=85

=

--Apple-Mail=_740498C2-0AA2-429B-AEA1-8E6A05F621CE--

From phil.hunt@oracle.com  Mon Dec 30 13:08:05 2013
Return-Path: 
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 801ED1AE55D for ; Mon, 30 Dec 2013 13:08:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.738
X-Spam-Level: 
X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham
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 wrMe_eMOhx8s for ; Mon, 30 Dec 2013 13:08:03 -0800 (PST)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD421AE29A for ; Mon, 30 Dec 2013 13:08:02 -0800 (PST)
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id rBUL7u43001201 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 30 Dec 2013 21:07:56 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rBUL7tQm021451 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 30 Dec 2013 21:07:55 GMT
Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rBUL7tM8021440 for ; Mon, 30 Dec 2013 21:07:55 GMT
Received: from [192.168.1.124] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 30 Dec 2013 13:07:54 -0800
From: Phil Hunt 
Content-Type: multipart/alternative; boundary="Apple-Mail=_A7FC31EC-7E44-4973-8CC0-827FE764C023"
Message-Id: 
Date: Mon, 30 Dec 2013 13:07:54 -0800
To: "scim@ietf.org WG" 
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
X-Mailer: Apple Mail (2.1510)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Subject: [scim] Open Ticket Recommendations (Tickets 21 - 40 )
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Simple Cloud Identity Management BOF 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Dec 2013 21:08:05 -0000

--Apple-Mail=_A7FC31EC-7E44-4973-8CC0-827FE764C023
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Continuing the open ticket review=85.

Ticket:  21Add "application" or "system" resource schema
Recommendation: Defer
Comment: This is of interest.  OAuth is defining client registration and =
this could be the basis for a new schema. This could easily be done in =
the oAuth client registration draft or a separate SCIM WG draft.  Defer =
for now.

Ticket:  22 Add metadata to attributes
Recommendation:  Defer
Comment: This would be difficult in some cases to implement at the =
attribute level in a general way. More discussion needed

Ticket:  23 Clarify requirements for preserving case in attribute values
Recommendation: Defer
Comment: More discussion needed.

Ticket:  24 Add negation operator for filters
Recommendation: Apply to draft
Comment: I think Kelly made a proposal that was accepted at IETF 88?  =
Note: ticket is not up-to-date

Ticket:  26 Allow search for groups with member foo, but only return =
member foo and not all members
Recommendation: Won't fix
Comment: This can be avoided by constructing a filter that confirms =
membership and then requesting only the group id and/or name to be =
returned.

Ticket:  30
Recommendation: Defer
Comment: No significant work done

Ticket:  31 Support for Consistent Paged Results
Recommendation: Won't Fix
Comment: While the ticket is not up-to-date, there has been a lot of =
discussion that there is not a strong desire for this feature compared =
with the possible costs.  At present, current implementers feel =
retaining search state necessary for consistent results could become a =
drain on resources and a possible DoS problem.

Ticket:  32 Async / Workflow Support
Recommendation: Defer
Comment: I think we need some practical implementation exploration =
before commenting on this issue. There is a general async REST issue =
here.

Ticket:  35 Define Mutability
Recommendation: Add to draft
Comment: This was discussed at IETF88 with recommendations put forward =
and agreed by the audience.

Ticket:  36  Address is a complex multi-valued attribute or list of =
sub-attributes
Recommendation: Defer
Comment: this item still needs some discussion

Ticket:  37 Error response when server is unwilling to perform query
Recommendation: Defer
Comment: Could be quickly resolved, however no specific proposal entered =
on ticket

Ticket: 39  Clarification for response body on DELETE
Recommendation: Defer
Comment: This could be resolved quickly.  Should follow common REST =
practices IMHO.

Ticket: 40 JSON format for defining a set of SCIM schema extensions
Recommendation: Defer
Comment:  More discussion needed. Could be done as a separate draft

Tickets 41 to 55 to follow=85

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com


--Apple-Mail=_A7FC31EC-7E44-4973-8CC0-827FE764C023
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252


Recommendation: Defer
Comment: This is of =
interest.  OAuth is defining client registration and this could be =
the basis for a new schema. This could easily be done in the oAuth =
client registration draft or a separate SCIM WG draft.  Defer for =
now.



Ticket:  22 Add metadata =
to attributes
Recommendation:  Defer
Comment: =
This would be difficult in some cases to implement at the attribute =
level in a general way. More discussion needed

Ticket:  23 Clarify requirements for preserving case =
in attribute values
Recommendation: Defer
Comment: =
More discussion needed.

Ticket:  31 Support for Consistent Paged =
Results
Recommendation: Won't Fix
Comment: While the =
ticket is not up-to-date, there has been a lot of discussion that there =
is not a strong desire for this feature compared with the possible =
costs.  At present, current implementers feel retaining search =
state necessary for consistent results could become a drain on resources =
and a possible DoS problem.

Ticket:  35 Define =
Mutability
Recommendation: Add to draft
Comment: =
This was discussed at IETF88 with recommendations put forward and agreed =
by the audience.

Ticket:  37 Error response when server is unwilling to =
perform query
Recommendation: Defer
Comment: Could =
be quickly resolved, however no specific proposal entered on =
ticket

Ticket: 39  Clarification for =
response body on DELETE
Recommendation: =
Defer
Comment: This could be resolved quickly.  Should =
follow common REST practices IMHO.

Ticket: 40 =
JSON format for defining a set of SCIM schema =
extensions
Recommendation: Defer
Comment:  More =
discussion needed. Could be done as a separate draft
=





=

--Apple-Mail=_A7FC31EC-7E44-4973-8CC0-827FE764C023--

From phil.hunt@oracle.com  Mon Dec 30 13:28:43 2013
Return-Path: 
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 057E21AE541 for ; Mon, 30 Dec 2013 13:28:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.738
X-Spam-Level: 
X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham
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 sw7HRx6SfXat for ; Mon, 30 Dec 2013 13:28:39 -0800 (PST)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id A40C81AE53D for ; Mon, 30 Dec 2013 13:28:39 -0800 (PST)
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id rBULSVeB028767 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 30 Dec 2013 21:28:32 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rBULSVYx023025 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 30 Dec 2013 21:28:31 GMT
Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rBULSUVB019352 for ; Mon, 30 Dec 2013 21:28:30 GMT
Received: from [192.168.1.124] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 30 Dec 2013 13:28:30 -0800
From: Phil Hunt 
Content-Type: multipart/alternative; boundary="Apple-Mail=_1EE67E86-E777-422A-A1FF-B66D8BD7919C"
Message-Id: 
Date: Mon, 30 Dec 2013 13:28:29 -0800
To: "scim@ietf.org WG" 
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
X-Mailer: Apple Mail (2.1510)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Subject: [scim] Open Ticket Recommendations (Tickets 41 +)
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Simple Cloud Identity Management BOF 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Dec 2013 21:28:43 -0000

--Apple-Mail=_1EE67E86-E777-422A-A1FF-B66D8BD7919C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Final open ticket recommendations:

Ticket: 41 Add IANA considerations
Recommendation: Defer
Comment: still a todo

Ticket: 42 Make server root searches optional
Recommendation: Apply to draft
Comment: This has been discussed on list and at IETF 87/88. Should =
proceed with proposed text

Ticket: 43 Consider dropping short-hand notation for complex =
multi-valued attributes
Recommendation: defer / merge with 36
Comment: Seems to be related to ticket 36?

Ticket: 44 Add JSON Schemas for Core Schema Resources
Recommendation: Apply to draft
Comment: Seems straight forward.  Note: seems related to Ticket 40 (JSON =
format for defining a set of scim schema extensions)

Ticket: 45 LDAP Mapping
Recommendation: Defer
Comment: LDAP is more of an endpoint (client) rather than SCIM SP =
capable item. Would an LDAP Profile of SCIM (e.g. no complex attributes =
Users) be more appropriate?

Ticket: 46 Clarify error responses and allow non-HTTP error codes
Recommendation: Defer
Comment: Need proposal text. Seems tied in with Ticket 37

Ticket: 47 Attribute Indexing
Recommendation: Apply to draft
Comment: Item proposal reviewed and discussed at IETF88

Ticket: 48 Operations with Extended Schema Attributes
Recommendation:  Apply to draft
Comment: Seems like a straight forward clarification

Ticket: 49 Ends With filter missing
Recommendation: Apply to draft
Comment: Apply missing filter to draft

Ticket: 50 Filter semantics do not allow filtering on complex plural =
attributes (aka inner join)
Recommendation: Apply to draft
Comment:  A reasonable set of proposals was given at IETF88 -- consensus =
was around adding [subattr clause] notation.

Ticket: 51 Formalize searching by schema
Recommendation: Apply to draft
Comment:  Seems like a reasonable clarification (?)

Ticket: 52 Minor textual changes
Recommendation: Apply to draft
Comment: editorial issues.

Ticket: 53 Consumer vs Client
Recommendation: Apply to draft
Comment: editorial issues.

Ticket: 54 Define core resource when referencing attributes
Recommendation: Apply to draft
Comment: editorial issue

Ticket: 55 Redirection
Recommendation: Apply to draft (for now)
Comment: some limited discussion on list. Is this an item that should be =
elevated to the WG working on REST?

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com


--Apple-Mail=_1EE67E86-E777-422A-A1FF-B66D8BD7919C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

Final =
open ticket recommendations:

Ticket: 41 Add IANA =
considerations
Recommendation: Defer
Comment: still =
a todo



Ticket: 42 Make =
server root searches optional
Ticket: 43 Consider dropping =
short-hand notation for complex multi-valued attributes
Recommendation: defer / merge with =
36
Comment: Seems to be related =
to ticket 36?

Ticket: 44 Add JSON Schemas for =
Core Schema Resources

Ticket: 45 LDAP Mapping
Recommendation: Defer
Comment: LDAP is more of an endpoint =
(client) rather than SCIM SP capable item. Would an LDAP Profile of SCIM =
(e.g. no complex attributes Users) be more appropriate?

Ticket: 46 Clarify error =
responses and allow non-HTTP error codes
Recommendation: Defer

Ticket: 47 Attribute =
Indexing
Recommendation: Apply =
to draft
Comment: Item proposal =
reviewed and discussed at IETF88
Ticket: 48 Operations with =
Extended Schema Attributes
Comment: Seems like a straight forward clarification

Ticket: 49 Ends With filter =
missing
Recommendation: Apply to =
draft
Comment: Apply missing =
filter to draft

Ticket: 50 Filter semantics do not allow =
filtering on complex plural attributes (aka inner join)
Recommendation: Apply to draft
Comment:  A reasonable set of =
proposals was given at IETF88 -- consensus was around adding [subattr =
clause] notation.

Ticket: 51 Formalize searching by =
schema
Recommendation: Apply to =
draft
Comment:  Seems like =
a reasonable clarification (?)
Ticket: 52 Minor textual =
changes
Recommendation: Apply to =
draft
Comment: editorial =
issues.

Ticket: 53 Consumer vs Client
Recommendation: Apply to draft
Comment: editorial issues.

Recommendation: Apply to draft
Comment: editorial issue

Comment: some limited discussion on list. Is this an item that =
should be elevated to the WG working on REST?

Phil

@independentid
phil.hunt@oracle.com
=





=

--Apple-Mail=_1EE67E86-E777-422A-A1FF-B66D8BD7919C--