From randomshelley@gmail.com Wed May 1 14:10:38 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2151421F9B19 for ; Wed, 1 May 2013 14:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v-nzG3YB8SDm for ; Wed, 1 May 2013 14:10:37 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 319BA21F9ACB for ; Wed, 1 May 2013 14:10:34 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id bn7so2418952ieb.13 for ; Wed, 01 May 2013 14:10:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=05PK95ARMfxqgJQY70Tm5OOXsTtFa9wgyK3PJB3VmJc=; b=0ttdSC0f9hFEbj1OH6dR0o/WvM+0AOt1y9PEyS98fmdmI75mwlWce2dGCr7Ym6s3s3 kZ0RtLkrB5AAQang0oFvG0KnRUkdxEIQoqR+8h3UHUDv48u4cJzTjXIb8kaQQ/ocVf+Q /1UbB+6nn69jI++7F/kpestlCvWZLS2937cgtMESrjCGBiFdfwhS6NyoLp4pFQ4W8zA+ SElHgzfTNHZe6UHHU8VFRBOqtUw9vfCJBog8lMtuqtOp95BaBsWvWf8CSY8n1EOuM41R jEstBkxlcX8WOskyKHR42U5B4D7uvYGyAmiPAaBiy1lROxGyiCzZq9U7HISyvmRdx4AJ VEmA== MIME-Version: 1.0 X-Received: by 10.50.78.232 with SMTP id e8mr2472744igx.72.1367442633823; Wed, 01 May 2013 14:10:33 -0700 (PDT) Received: by 10.64.18.233 with HTTP; Wed, 1 May 2013 14:10:33 -0700 (PDT) Date: Wed, 1 May 2013 16:10:33 -0500 Message-ID: From: Shelley To: "scim@ietf.org" Content-Type: multipart/alternative; boundary=089e013c6a2070e5d604dbae8cd1 Subject: Re: [scim] Clarification on body request for DELETE X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 21:10:38 -0000 --089e013c6a2070e5d604dbae8cd1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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, the > 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 issue > to clarify this. Thoughts?**** > > ** ** > > --Kelly > > --089e013c6a2070e5d604dbae8cd1 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Apologies for the delayed reply to this thread regarding t= he DELETE response [1], but +1 to returning a 204.

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


On Wed, Mar 27, 2013 at 1:10 PM, <= scim-request@ietf.org> wrote:
---------- Forwarded message ----------
From:=A0Kelly Grizzle <kelly.grizzle@sailpoint.com>= ;
To:=A0Alexandre Santos <asantos@pingidentity.com>, "s= cim@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

<= /div>

--089e013c6a2070e5d604dbae8cd1-- From t.rossner@tarent.de Tue May 7 01:22:46 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 644B521F8ECB for ; Tue, 7 May 2013 01:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P3heeqtrse-x for ; Tue, 7 May 2013 01:22:09 -0700 (PDT) Received: from dovecot.stylite.de (dovecot.stylite.de [213.183.76.200]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF5C21F8EAC for ; Tue, 7 May 2013 01:22:08 -0700 (PDT) Received: from [172.26.4.225] (fb-n15-11.unbelievable-machine.net [94.198.62.204]) (Authenticated sender: t.rossner@osiam.de) by dovecot.stylite.de (Postfix) with ESMTPSA id 8695611E for ; Tue, 7 May 2013 10:22:03 +0200 (CEST) Message-ID: <5188B9AA.5090700@tarent.de> Date: Tue, 07 May 2013 10:22:02 +0200 From: =?ISO-8859-15?Q?Thorsten_Ro=DFner?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: scim@ietf.org References: <51657C1E.8060700@tarent.de> In-Reply-To: <51657C1E.8060700@tarent.de> X-Forwarded-Message-Id: <51657C1E.8060700@tarent.de> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-MServer-Mail-Id: 4859648 Subject: [scim] externalId - How to distinguish between client's tenants X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 08:22:47 -0000 Hi All, can someone please help me understanding the Common Schema's "externalId"? My current understanding: - The externalId for a resource can be stored - if provided - for each Service Consumer's tenant (or if a SC doesn't support tenants, the externalId is stored for each SC's instance). A single SCIM resource thereby can have multiple externalIds (depending on the number of consumer tenants or instances). The question that derives from my understanding: - How can the SP differentiate between tenants of an SC in order to respect the following quote from the specification: "The Service Provider MUST always interpret the externalId as scoped to the Service Consumer's tenant."? Or is the differentiation outside the scope of the SCIM spec? Thanks & cheers Thorsten From leifj@mnt.se Thu May 9 11:09:58 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D63D21F92FC for ; Thu, 9 May 2013 11:09:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nw3v5DZFU3as for ; Thu, 9 May 2013 11:09:58 -0700 (PDT) Received: from mail-pb0-x230.google.com (mail-pb0-x230.google.com [IPv6:2607:f8b0:400e:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 0ECA621F9227 for ; Thu, 9 May 2013 11:09:57 -0700 (PDT) Received: by mail-pb0-f48.google.com with SMTP id ma3so2147840pbc.7 for ; Thu, 09 May 2013 11:09:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:content-type:content-transfer-encoding:x-gm-message-state; bh=dlMMzcEoPxmjBoWBFoOAtsOv6em7CLqipRMpH3Pdr78=; b=JdK/UxGidYmkfmA3oHgQ2+0gNfe7sZOsvjaZJDu/j8lraPfI4WxH4QLGKm7wDxbtul f5D/fMZJUpj2Wc92563tKWESWdAuaOEyw80KNj1TFzH4u664UimYSrr8KICNce14Pq6d 1QPy+Iahvyl9LvYuxqKVX6sXWQY8WEVXFyWDwSlUnlGzgnRKhMZ8PhhmwmVrXMPHCIxG 64KZuUyfQ8gXGQO6kZU3t2PZ1fdPt0drbbJj8s/xoJ9Rldqi0DbvAyiu0HMBhXPvMa4o 1sCluZASgCI0V3nKLtB2MpO/X8AyKwtXsZ2zJ/RsY9Wvs7sc+RWRv6wAA3/CIpHshhjk jl1g== X-Received: by 10.68.78.37 with SMTP id y5mr13615866pbw.28.1368122997736; Thu, 09 May 2013 11:09:57 -0700 (PDT) Received: from [64.9.239.200] (user-64-9-239-200.googlewifi.com [64.9.239.200]) by mx.google.com with ESMTPSA id cp1sm3847814pbc.42.2013.05.09.11.09.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 09 May 2013 11:09:56 -0700 (PDT) Message-ID: <518BE672.1030907@mnt.se> Date: Thu, 09 May 2013 20:09:54 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: scim WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkOCAqr77zSzizg5fvRKJ+Wz8ff4nlSMHNQukCo6xb+em/i1ooHU4XMp6iwWQFz9+nlvWAl Cc: Barry Leiba , iesg-secretary@ietf.org Subject: [scim] Closing the design team and scheduling regular confcalls X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 18:09:58 -0000 Folks, The goal of the SCIM design team was to set the WG on a path towards "scim 2.0" by identifying and proposing solutions to the major issues. The time has now come to close the design team and thank the contributors for all their hard work. In order to preserve the momentum and make sure the SCIM WG will complete in a timely manner we will start a schedule of bi-weekly conference calls [1] open to all. Before each call, an agenda will be posted to the list and after each call notes will be posted to the list and the WG wiki. The time of the call will be 10 AM PST every other Wednesday. The first call will be 2 weeks from next Wednesday (29/5) and this email serves as notification for this and all future calls until further notice. A separate email with the meeting details will be sent to the list shortly. Leif & Morteza [1] http://www.ietf.org/iesg/statement/interim-meetings.html From phil.hunt@oracle.com Tue May 14 08:34:23 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A637A21F915C for ; Tue, 14 May 2013 08:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KAp2YFunjydK for ; Tue, 14 May 2013 08:34:17 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 2DBC421F8F2C for ; Tue, 14 May 2013 08:34:17 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4EFYFeg004715 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 14 May 2013 15:34:16 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4EFYFRX019307 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 14 May 2013 15:34:15 GMT Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4EFYFSI019299 for ; Tue, 14 May 2013 15:34:15 GMT Received: from [192.168.1.89] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 14 May 2013 08:34:14 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_D99E1BB9-F140-4415-A509-65CFF3D169A5" Date: Tue, 14 May 2013 08:34:15 -0700 Message-Id: <3399B348-F87B-465B-A796-28B764AB292B@oracle.com> To: scim WG Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Subject: [scim] Use of value for complex multi-valued attributes X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2013 15:34:24 -0000 --Apple-Mail=_D99E1BB9-F140-4415-A509-65CFF3D169A5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The current draft implies that value should be used for the significant = attribute in a multi-valued attribute. It also says you can have = multi-valued complex attributes. > 3.2. Multi-valued Attributes >=20 > Multi-valued attributes are unordered lists of attributes. Each > attribute MAY contain Sub-Attributes and therefore multi-valued > attributes may contain Complex Attributes. The below = Sub-Attributes > are considered normative and when specified SHOULD be used as > defined. >=20 > type A label indicating the attribute's function; e.g., "work" or > "home". >=20 > primary A Boolean value indicating the 'primary' or preferred > attribute value for this attribute, e.g. the preferred mailing > address or primary e-mail address. The primary attribute value > 'true' MUST appear no more than once. >=20 > display A human readable name, primarily used for display = purposes. > READ-ONLY. >=20 >=20 >=20 >=20 >=20 >=20 > Mortimore, et al. Expires October 17, 2013 [Page = 7] > =20 > Internet-Draft draft-scim-core-schema-01 April = 2013 >=20 >=20 > operation The operation to perform on the multi-valued attribute > during a PATCH request. The only valid value is "delete", which > signifies that this instance should be removed from the = Resource. >=20 > value The attribute's significant value; e.g., the e-mail address, > phone number, etc. Attributes that define a "value" = sub-attribute > MAY be alternately represented as a collection of primitive = types. > For example: What is the intent of value for example with the addresses attribute? I = can think of three representations that are valid according to the = current draft: =46rom example (no value used): "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 }, { "type": "home", "streetAddress": "456 Hollywood Blvd", "locality": "Hollywood", "region": "CA", "postalCode": "91608", "country": "USA", "formatted": "456 Hollywood Blvd\nHollywood, CA 91608 USA" } ] What is probably the wrong approach: "addresses": [ { "type": "work", "primary": true, "value": { "streetAddress": "100 Universal City Plaza", "locality": "Hollywood", "region": "CA", "postalCode": "91608", "country": "USA", "formatted": "100 Universal City Plaza\nHollywood, CA 91608 = USA" } }, { "type": "home", "value": { "streetAddress": "456 Hollywood Blvd", "locality": "Hollywood", "region": "CA", "postalCode": "91608", "country": "USA", "formatted": "456 Hollywood Blvd\nHollywood, CA 91608 USA" } } ] Another approach would be to turn most significant sub-attribute into = value: "addresses": [ { "type": "work", "streetAddress": "100 Universal City Plaza", "locality": "Hollywood", "region": "CA", "postalCode": "91608", "country": "USA", "value": "100 Universal City Plaza\nHollywood, CA 91608 USA", "primary": true }, { "type": "home", "streetAddress": "456 Hollywood Blvd", "locality": "Hollywood", "region": "CA", "postalCode": "91608", "country": "USA", "value": "456 Hollywood Blvd\nHollywood, CA 91608 USA" } ] Maybe we should indicate that "value" is NOT to be used with complex = attributes? Otherwise, I could see a lot of inter-op issues as people = decide whih combinations or specific attribute is the significant = attribute when it comes to complex attributes. Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_D99E1BB9-F140-4415-A509-65CFF3D169A5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii The = current draft implies that value should be used for the significant = attribute in a multi-valued attribute. It also says you can have = multi-valued complex attributes.

3.2.  =
Multi-valued Attributes


   Multi-valued attributes are unordered lists of attributes.  Each
   attribute MAY contain Sub-Attributes and therefore multi-valued
   attributes may contain Complex Attributes.  The below Sub-Attributes
   are considered normative and when specified SHOULD be used as
   defined.

   type  A label indicating the attribute's function; e.g., "work" or
      "home".

   primary  A Boolean value indicating the 'primary' or preferred
      attribute value for this attribute, e.g. the preferred mailing
      address or primary e-mail address.  The primary attribute value
      'true' MUST appear no more than once.

   display  A human readable name, primarily used for display purposes.
      READ-ONLY.






Mortimore, et =
al.       Expires October 17, 2013                [Page 7]

 =

draft-scim-core-schema-01      =
       April 2013


   operation  The operation to perform on the multi-valued attribute
      during a PATCH request.  The only valid value is "delete", which
      signifies that this instance should be removed from the Resource.

   value  The attribute's significant value; e.g., the e-mail address,
      phone number, etc.  Attributes that define a "value" sub-attribute
      MAY be alternately represented as a collection of primitive types.
      For example:

What is = the intent of value for example with the addresses attribute?  I = can think of three representations that are valid according to the = current draft:

=46rom example (no value = used):
"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
  },
  {
    "type":= "home",
    "streetAddress": "456 Hollywood = Blvd",
    "locality": = "Hollywood",
    "region": = "CA",
    "postalCode": = "91608",
    "country": = "USA",
    "formatted": "456 Hollywood = Blvd\nHollywood, CA 91608 = USA"
  }
]

What is probably = the wrong approach:
"addresses": = [
  {
     "type": = "work",
     "primary": = true,
     "value": = {
         "streetAddr= ess": "100 Universal City = Plaza",
         "locality= ": = "Hollywood",
         "reg= ion": = "CA",
         "postalCode= ": = "91608",
         "country= ": = "USA",
         "formatted= ": "100 Universal City Plaza\nHollywood, CA 91608 = USA"
     }
   },
 &= nbsp; {
     "type": = "home",
     "value": = {
         "streetAddress"= : "456 Hollywood = Blvd",
         "locality"= : = "Hollywood",
         "reg= ion": = "CA",
         "postalCode= ": = "91608",
         "country= ": = "USA",
         "formatted= ": "456 Hollywood Blvd\nHollywood, CA 91608 = USA"
     }
  }
]

Another approach would = be to turn most significant sub-attribute into = value:
"addresses": = [
  {
    "type": = "work",
    "streetAddress": "100 Universal City = Plaza",
    "locality": = "Hollywood",
    "region": = "CA",
    "postalCode": = "91608",
    "country": = "USA",
    "value": "100 Universal City = Plaza\nHollywood, CA 91608 USA",
    "primary": = true
  },
  {
    "type":= "home",
    "streetAddress": "456 Hollywood = Blvd",
    "locality": = "Hollywood",
    "region": = "CA",
    "postalCode": = "91608",
    "country": = "USA",
    "value": "456 Hollywood = Blvd\nHollywood, CA 91608 = USA"
  }
]

Maybe we should = indicate that "value" is NOT to be used with complex attributes? =  Otherwise, I could see a lot of inter-op issues as people decide = whih combinations or specific attribute is the significant attribute = when it comes to complex attributes.

Phil

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





= --Apple-Mail=_D99E1BB9-F140-4415-A509-65CFF3D169A5-- From randomshelley@gmail.com Tue May 14 12:41:26 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A62C421F8EDA for ; Tue, 14 May 2013 12:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hteszPhZazjw for ; Tue, 14 May 2013 12:41:25 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id A5D1B21F8F24 for ; Tue, 14 May 2013 12:41:22 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id s9so1952008iec.34 for ; Tue, 14 May 2013 12:41:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=ngty6p/Wv4ec2jdGpfPclLZ7tLza7YJMcI/7dPJVnPY=; b=YgNZs+MtRku6mSE6yw9ZfwH9kyPX8uGgENBXEP9MF/nML8LfWfsYy50JpoWziztlYK MEFgEiecJqhJzkeu0YGK5YHnXFO87YNiHN9fTrSqNJ/CsRhUsYiUP+TU9vCo6ovgWfKo NUp9v390+oHJdTv4mABcPMDie05LrS/F4Vv2G/g45Pmk/EHjrCwR5sBkxVsPaBVkbfWj hLmYcENcf5Gcba6ELhyyDrPnT53rq68nG3xMw2nwXV9507jrXddoW5sOcToX1tq7nk4A pzBOFbVsNf6roZx3gc+c1SsWhw1alS8cUaQe6jYYRWycq2uwSVB/Ds1HHsFCx4Pjx5am 6AaA== MIME-Version: 1.0 X-Received: by 10.50.78.232 with SMTP id e8mr3112834igx.72.1368560482106; Tue, 14 May 2013 12:41:22 -0700 (PDT) Received: by 10.64.226.17 with HTTP; Tue, 14 May 2013 12:41:21 -0700 (PDT) Date: Tue, 14 May 2013 14:41:21 -0500 Message-ID: From: Shelley To: "scim@ietf.org" Content-Type: multipart/alternative; boundary=089e013c6a2063c05904dcb2d1fe Subject: Re: [scim] Use of value for complex multi-valued attributes X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2013 19:41:27 -0000 --089e013c6a2063c05904dcb2d1fe Content-Type: text/plain; charset=ISO-8859-1 > Maybe we should indicate that "value" is NOT to be used with complex > attributes? +1. Also note that there was some initial discussion on this topic [1] and a corresponding ticket [2]. [1] http://www.ietf.org/mail-archive/web/scim/current/msg00928.html [2] http://trac.tools.ietf.org/wg/scim/trac/ticket/36 On Tue, May 14, 2013 at 2:01 PM, wrote: > ---------- Forwarded message ---------- > From: Phil Hunt > To: scim WG > Cc: > Date: Tue, 14 May 2013 08:34:15 -0700 > Subject: [scim] Use of value for complex multi-valued attributes > The current draft implies that value should be used for the significant > attribute in a multi-valued attribute. It also says you can have > multi-valued complex attributes. > > 3.2 . Multi-valued Attributes > > Multi-valued attributes are unordered lists of attributes. Each > attribute MAY contain Sub-Attributes and therefore multi-valued > attributes may contain Complex Attributes. The below Sub-Attributes > are considered normative and when specified SHOULD be used as > defined. > > type A label indicating the attribute's function; e.g., "work" or > "home". > > primary A Boolean value indicating the 'primary' or preferred > attribute value for this attribute, e.g. the preferred mailing > address or primary e-mail address. The primary attribute value > 'true' MUST appear no more than once. > > display A human readable name, primarily used for display purposes. > READ-ONLY. > > > > > > Mortimore, et al. Expires October 17, 2013 [Page 7] > > Internet-Draft draft-scim-core-schema-01 April 2013 > > > operation The operation to perform on the multi-valued attribute > during a PATCH request. The only valid value is "delete", which > signifies that this instance should be removed from the Resource. > > value The attribute's significant value; e.g., the e-mail address, > phone number, etc. Attributes that define a "value" sub-attribute > MAY be alternately represented as a collection of primitive types. > For example: > > > What is the intent of value for example with the addresses attribute? I > can think of three representations that are valid according to the current > draft: > > *From example (no value used):* > "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 > }, > { > "type": "home", > "streetAddress": "456 Hollywood Blvd", > "locality": "Hollywood", > "region": "CA", > "postalCode": "91608", > "country": "USA", > "formatted": "456 Hollywood Blvd\nHollywood, CA 91608 USA" > } > ] > > *What is probably the wrong approach:* > "addresses": [ > { > "type": "work", > "primary": true, > *"value": {* > "streetAddress": "100 Universal City Plaza", > "locality": "Hollywood", > "region": "CA", > "postalCode": "91608", > "country": "USA", > "formatted": "100 Universal City Plaza\nHollywood, CA 91608 USA" > } > }, > { > "type": "home", > "value": { > "streetAddress": "456 Hollywood Blvd", > "locality": "Hollywood", > "region": "CA", > "postalCode": "91608", > "country": "USA", > "formatted": "456 Hollywood Blvd\nHollywood, CA 91608 USA" > } > } > ] > > *Another approach would be to turn most significant sub-attribute into > value:* > "addresses": [ > { > "type": "work", > "streetAddress": "100 Universal City Plaza", > "locality": "Hollywood", > "region": "CA", > "postalCode": "91608", > "country": "USA", > "value": "100 Universal City Plaza\nHollywood, CA 91608 USA", > "primary": true > }, > { > "type": "home", > "streetAddress": "456 Hollywood Blvd", > "locality": "Hollywood", > "region": "CA", > "postalCode": "91608", > "country": "USA", > "value": "456 Hollywood Blvd\nHollywood, CA 91608 USA" > } > ] > > Maybe we should indicate that "value" is NOT to be used with complex > attributes? Otherwise, I could see a lot of inter-op issues as people > decide whih combinations or specific attribute is the significant attribute > when it comes to complex attributes. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > --089e013c6a2063c05904dcb2d1fe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Maybe we should indicate that "value" is NOT to be used wit= h complex attributes?

+1.

Also note that there was some initial discussion= on this topic [1] and a corresponding ticket [2].

[1] http://www.i= etf.org/mail-archive/web/scim/current/msg00928.html
[2] http://tr= ac.tools.ietf.org/wg/scim/trac/ticket/36


On Tue, May 14, 2013 at 2:01 P= M, <scim-request@ietf.org> wrote:
---------- Forwarded mess= age ----------
From:=A0Phil Hunt <phil.hunt@oracle.com>
To:=A0scim WG <scim@ietf.org>Cc:=A0
Date:=A0Tue, 14 May 2013 08:34:15 -0700
Subject:=A0[scim] Use= of value for complex multi-valued attributes
The current draft implies that value should be used for the significant att= ribute in a multi-valued attribute. It also says you can have multi-valued = complex attributes.


3.2.  Multi-valued Attributes


   Multi-valued attributes are unordered lists of attributes.  Each
   attribute MAY contain Sub-Attributes and therefore multi-valued
   attributes may contain Complex Attributes.  The below Sub-Attributes
   are considered normative and when specified SHOULD be used as
   defined.

   type  A label indicating the attribute's function; e.g., "work&=
quot; or
      "home".

   primary  A Boolean value indicating the 'primary' or preferred
      attribute value for this attribute, e.g. the preferred mailing
      address or primary e-mail address.  The primary attribute value
      'true' MUST appear no more than once.

   display  A human readable name, primarily used for display purposes.
      READ-ONLY.






Mortimore, et al.       Expires Octo=
ber 17, 2013                [Page 7]

 
Internet-Draft          draft-scim-core-schema-01             Apri=
l 2013


   operation  The operation to perform on the multi-valued attribute
      during a PATCH request.  The only valid value is "delete", =
which
      signifies that this instance should be removed from the Resource.

   value  The attribute's significant value; e.g., the e-mail address,
      phone number, etc.  Attributes that define a "value" sub-at=
tribute
      MAY be alternately represented as a collection of primitive types.
      For example:

What is the = intent of value for example with the addresses attribute? =A0I can think of= three representations that are valid according to the current draft:

From example (no value used):
"ad= dresses": [
=A0=A0{
=A0=A0=A0=A0"type": "work&quo= t;,
=A0=A0=A0=A0"streetAddress": "100 Universal City Plaz= a",
=A0=A0=A0=A0"locality": "Hollywood",
=A0=A0=A0=A0"region": "CA",
=A0=A0=A0=A0"postal= Code": "91608",
=A0=A0=A0=A0"country": "US= A",
=A0=A0=A0=A0"formatted": "100 Universal City Pla= za\nHollywood, CA 91608 USA",
=A0=A0=A0=A0"primary": true
=A0=A0},
=A0=A0{
=A0=A0=A0= =A0"type": "home",
=A0=A0=A0=A0"streetAddress&q= uot;: "456 Hollywood Blvd",
=A0=A0=A0=A0"locality": = "Hollywood",
=A0=A0=A0=A0"region": "CA", =A0=A0=A0=A0"postalCode": "91608",
=A0=A0=A0=A0"= ;country": "USA",
=A0=A0=A0=A0"formatted": &quo= t;456 Hollywood Blvd\nHollywood, CA 91608 USA"
=A0=A0}
]

What is probably the wrong approach:
"addresses": [
=A0=A0{
=A0=A0=A0=A0=A0"typ= e": "work",
=A0=A0=A0=A0=A0"primary": true,
= =A0=A0=A0=A0=A0"value": {
=A0=A0=A0=A0=A0=A0=A0=A0=A0&q= uot;streetAddress": "100 Universal City Plaza",
=A0=A0=A0=A0=A0=A0=A0=A0=A0"locality": "Hollywood",
= =A0=A0=A0=A0=A0=A0=A0=A0=A0"region": "CA",
=A0=A0=A0= =A0=A0=A0=A0=A0=A0"postalCode": "91608",
=A0=A0=A0= =A0=A0=A0=A0=A0=A0"country": "USA",
=A0=A0=A0=A0=A0= =A0=A0=A0=A0"formatted": "100 Universal City Plaza\nHollywoo= d, CA 91608 USA"
=A0=A0=A0=A0=A0}
=A0=A0=A0},
=A0=A0=A0{
=A0=A0=A0=A0=A0"type&= quot;: "home",
=A0=A0=A0=A0=A0"value": {
=A0=A0= =A0=A0=A0=A0=A0=A0=A0"streetAddress": "456 Hollywood Blvd&qu= ot;,
=A0=A0=A0=A0=A0=A0=A0=A0=A0"locality": "Hollywood&qu= ot;,
=A0=A0=A0=A0=A0=A0=A0=A0=A0"region": "CA",
=A0=A0=A0= =A0=A0=A0=A0=A0=A0"postalCode": "91608",
=A0=A0=A0= =A0=A0=A0=A0=A0=A0"country": "USA",
=A0=A0=A0=A0=A0= =A0=A0=A0=A0"formatted": "456 Hollywood Blvd\nHollywood, CA = 91608 USA"
=A0=A0=A0=A0=A0}
=A0=A0}
]

Another approach= would be to turn most significant sub-attribute into value:
= "addresses": [
=A0=A0{
=A0=A0=A0=A0"type": "= work",
=A0=A0=A0=A0"streetAddress": "100 Universal C= ity Plaza",
=A0=A0=A0=A0"locality": "Hollywood",
=A0=A0=A0=A0&qu= ot;region": "CA",
=A0=A0=A0=A0"postalCode": &qu= ot;91608",
=A0=A0=A0=A0"country": "USA",
=A0= =A0=A0=A0"value": "100 Universal City Plaza\nHollywood, CA 9= 1608 USA",
=A0=A0=A0=A0"primary": true
=A0=A0},
=A0=A0{
=A0=A0=A0= =A0"type": "home",
=A0=A0=A0=A0"streetAddress&q= uot;: "456 Hollywood Blvd",
=A0=A0=A0=A0"locality": = "Hollywood",
=A0=A0=A0=A0"region": "CA", =A0=A0=A0=A0"postalCode": "91608",
=A0=A0=A0=A0"= ;country": "USA",
=A0=A0=A0=A0"value": "45= 6 Hollywood Blvd\nHollywood, CA 91608 USA"
=A0=A0}
]
<= br>
Maybe we should indicate that "value" is NOT to be = used with complex attributes? =A0Otherwise, I could see a lot of inter-op i= ssues as people decide whih combinations or specific attribute is the signi= ficant attribute when it comes to complex attributes.



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


--089e013c6a2063c05904dcb2d1fe-- From phil.hunt@oracle.com Tue May 14 13:00:52 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 360F421F90EE for ; Tue, 14 May 2013 13:00:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ihOjKOFiwKgo for ; Tue, 14 May 2013 13:00:46 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 0A6A121F901A for ; Tue, 14 May 2013 13:00:45 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4EK0hLh016740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 14 May 2013 20:00:44 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4EK0gxw001131 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 14 May 2013 20:00:42 GMT Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4EK0gvt010140; Tue, 14 May 2013 20:00:42 GMT Received: from [192.168.1.89] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 14 May 2013 13:00:41 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_202AEA3E-2824-4A7A-91AC-412A2707D9B2" From: Phil Hunt In-Reply-To: Date: Tue, 14 May 2013 13:00:43 -0700 Message-Id: <2AD07E83-5DF9-4859-943D-A7BC6F5A5FAA@oracle.com> References: To: Shelley X-Mailer: Apple Mail (2.1283) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "scim@ietf.org" Subject: Re: [scim] Use of value for complex multi-valued attributes X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2013 20:00:52 -0000 --Apple-Mail=_202AEA3E-2824-4A7A-91AC-412A2707D9B2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Shelly, Thanks for pointing that out. The ticket already captures the issue. =20 We should try to work to close it for the 02 draft as this seems like an = easy issue. :-) Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-05-14, at 12:41 PM, Shelley wrote: >=20 > Maybe we should indicate that "value" is NOT to be used with complex = attributes? >=20 > +1. >=20 > Also note that there was some initial discussion on this topic [1] and = a corresponding ticket [2]. >=20 > [1] http://www.ietf.org/mail-archive/web/scim/current/msg00928.html > [2] http://trac.tools.ietf.org/wg/scim/trac/ticket/36 >=20 >=20 > On Tue, May 14, 2013 at 2:01 PM, wrote: > ---------- Forwarded message ---------- > From: Phil Hunt > To: scim WG > Cc:=20 > Date: Tue, 14 May 2013 08:34:15 -0700 > Subject: [scim] Use of value for complex multi-valued attributes > The current draft implies that value should be used for the = significant attribute in a multi-valued attribute. It also says you can = have multi-valued complex attributes. >=20 >>=20 >> 3.2. Multi-valued Attributes >>=20 >> Multi-valued attributes are unordered lists of attributes. Each >> attribute MAY contain Sub-Attributes and therefore multi-valued >> attributes may contain Complex Attributes. The below = Sub-Attributes >> are considered normative and when specified SHOULD be used as >> defined. >>=20 >> type A label indicating the attribute's function; e.g., "work" or >> "home". >>=20 >> primary A Boolean value indicating the 'primary' or preferred >> attribute value for this attribute, e.g. the preferred mailing >> address or primary e-mail address. The primary attribute value >> 'true' MUST appear no more than once. >>=20 >> display A human readable name, primarily used for display = purposes. >> READ-ONLY. >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Mortimore, et al. Expires October 17, 2013 [Page = 7] >> =20 >> Internet-Draft draft-scim-core-schema-01 April = 2013 >>=20 >>=20 >> operation The operation to perform on the multi-valued attribute >> during a PATCH request. The only valid value is "delete", = which >> signifies that this instance should be removed from the = Resource. >>=20 >> value The attribute's significant value; e.g., the e-mail = address, >> phone number, etc. Attributes that define a "value" = sub-attribute >> MAY be alternately represented as a collection of primitive = types. >> For example: >=20 > What is the intent of value for example with the addresses attribute? = I can think of three representations that are valid according to the = current draft: >=20 > =46rom example (no value used): > "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 > }, > { > "type": "home", > "streetAddress": "456 Hollywood Blvd", > "locality": "Hollywood", > "region": "CA", > "postalCode": "91608", > "country": "USA", > "formatted": "456 Hollywood Blvd\nHollywood, CA 91608 USA" > } > ] >=20 > What is probably the wrong approach: > "addresses": [ > { > "type": "work", > "primary": true, > "value": { > "streetAddress": "100 Universal City Plaza", > "locality": "Hollywood", > "region": "CA", > "postalCode": "91608", > "country": "USA", > "formatted": "100 Universal City Plaza\nHollywood, CA 91608 = USA" > } > }, > { > "type": "home", > "value": { > "streetAddress": "456 Hollywood Blvd", > "locality": "Hollywood", > "region": "CA", > "postalCode": "91608", > "country": "USA", > "formatted": "456 Hollywood Blvd\nHollywood, CA 91608 USA" > } > } > ] >=20 > Another approach would be to turn most significant sub-attribute into = value: > "addresses": [ > { > "type": "work", > "streetAddress": "100 Universal City Plaza", > "locality": "Hollywood", > "region": "CA", > "postalCode": "91608", > "country": "USA", > "value": "100 Universal City Plaza\nHollywood, CA 91608 USA", > "primary": true > }, > { > "type": "home", > "streetAddress": "456 Hollywood Blvd", > "locality": "Hollywood", > "region": "CA", > "postalCode": "91608", > "country": "USA", > "value": "456 Hollywood Blvd\nHollywood, CA 91608 USA" > } > ] >=20 > Maybe we should indicate that "value" is NOT to be used with complex = attributes? Otherwise, I could see a lot of inter-op issues as people = decide whih combinations or specific attribute is the significant = attribute when it comes to complex attributes. >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=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 --Apple-Mail=_202AEA3E-2824-4A7A-91AC-412A2707D9B2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
Phil

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





On 2013-05-14, at 12:41 PM, Shelley wrote:


Maybe we should indicate that "value" is NOT to be = used with complex attributes?

+1.

Also note that there was some initial = discussion on this topic [1] and a corresponding ticket [2].

[1] = h= ttp://www.ietf.org/mail-archive/web/scim/current/msg00928.html
[2] http://trac.too= ls.ietf.org/wg/scim/trac/ticket/36


On Tue, May 14, = 2013 at 2:01 PM, <scim-request@ietf.org> wrote:
---------- Forwarded message = ----------
From: Phil Hunt <phil.hunt@oracle.com>
To: scim WG <scim@ietf.org>
Cc: 
Date:&= nbsp;Tue, 14 May 2013 08:34:15 -0700
Subject: [scim] Use of = value for complex multi-valued attributes
The current draft implies that value should be used for the significant = attribute in a multi-valued attribute. It also says you can have = multi-valued complex attributes.


3.2.  =
Multi-valued Attributes


   Multi-valued attributes are unordered lists of attributes.  Each
   attribute MAY contain Sub-Attributes and therefore multi-valued
   attributes may contain Complex Attributes.  The below Sub-Attributes
   are considered normative and when specified SHOULD be used as
   defined.

   type  A label indicating the attribute's function; e.g., "work" or
      "home".

   primary  A Boolean value indicating the 'primary' or preferred
      attribute value for this attribute, e.g. the preferred mailing
      address or primary e-mail address.  The primary attribute value
      'true' MUST appear no more than once.

   display  A human readable name, primarily used for display purposes.
      READ-ONLY.






Mortimore, et al.       Expires =
October 17, 2013                [Page 7]

 
Internet-Draft          draft-scim-core-schema-01             April =
2013


   operation  The operation to perform on the multi-valued attribute
      during a PATCH request.  The only valid value is "delete", which
      signifies that this instance should be removed from the Resource.

   value  The attribute's significant value; e.g., the e-mail address,
      phone number, etc.  Attributes that define a "value" sub-attribute
      MAY be alternately represented as a collection of primitive types.
      For example:

What is = the intent of value for example with the addresses attribute?  I = can think of three representations that are valid according to the = current draft:

=46rom example (no value = used):
"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
  },
  {
    "type":= "home",
    "streetAddress": "456 Hollywood = Blvd",
    "locality": = "Hollywood",
    "region": "CA",
    "postalCode": = "91608",
    "country": = "USA",
    "formatted": "456 Hollywood = Blvd\nHollywood, CA 91608 = USA"
  }
]

What is probably = the wrong approach:
"addresses": = [
  {
     "type": = "work",
     "primary": = true,
     "value": = {
         "streetAddr= ess": "100 Universal City Plaza",
         "locality": = "Hollywood",
         "reg= ion": = "CA",
         "postalCode= ": = "91608",
         "country= ": = "USA",
         "formatted= ": "100 Universal City Plaza\nHollywood, CA 91608 USA"
=      }
   },
  &nb= sp;{
     "type": = "home",
     "value": = {
         "streetAddress"= : "456 Hollywood = Blvd",
         "locality"= : "Hollywood",
         "region": = "CA",
         "postalCode= ": = "91608",
         "country= ": = "USA",
         "formatted= ": "456 Hollywood Blvd\nHollywood, CA 91608 USA"
=      }
  }
]

Another approach would be to turn most significant sub-attribute = into value:
"addresses": = [
  {
    "type": = "work",
    "streetAddress": "100 Universal City = Plaza",
    "locality": = "Hollywood",
    "region": = "CA",
    "postalCode": = "91608",
    "country": = "USA",
    "value": "100 Universal City = Plaza\nHollywood, CA 91608 USA",
    "primary": = true
  },
  {
    "type":= "home",
    "streetAddress": "456 Hollywood = Blvd",
    "locality": = "Hollywood",
    "region": "CA",
    "postalCode": = "91608",
    "country": = "USA",
    "value": "456 Hollywood = Blvd\nHollywood, CA 91608 = USA"
  }
]

Maybe we should = indicate that "value" is NOT to be used with complex attributes? =  Otherwise, I could see a lot of inter-op issues as people decide = whih combinations or specific attribute is the significant attribute = when it comes to complex attributes.



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


_______________________________________________
scim mailing = list
scim@ietf.org
https://www.ietf.org/ma= ilman/listinfo/scim

= --Apple-Mail=_202AEA3E-2824-4A7A-91AC-412A2707D9B2-- From sfehrman@me.com Tue May 14 19:44:35 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE41921F8AF4 for ; Tue, 14 May 2013 19:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rikuogrquelq for ; Tue, 14 May 2013 19:44:30 -0700 (PDT) Received: from st11p02mm-asmtp005.mac.com (st11p02mm-asmtpout005.mac.com [17.172.220.240]) by ietfa.amsl.com (Postfix) with ESMTP id 8C55121F8ADF for ; Tue, 14 May 2013 19:44:30 -0700 (PDT) Received: from [192.168.1.200] (99-22-84-177.lightspeed.cicril.sbcglobal.net [99.22.84.177]) by st11p02mm-asmtp005.mac.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Jan 3 2012)) with ESMTPSA id <0MMT00DCZJLO2LB0@st11p02mm-asmtp005.mac.com> for scim@ietf.org; Wed, 15 May 2013 02:44:13 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626,1.0.431,0.0.0000 definitions=2013-05-14_16:2013-05-14, 2013-05-14, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=1 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1305010000 definitions=main-1305140271 From: Scott Fehrman MIME-version: 1.0 (Apple Message framework v1283) Content-type: multipart/alternative; boundary="Apple-Mail=_D86214FA-3DA9-449D-8A82-D1EE7D2978E5" Date: Tue, 14 May 2013 21:44:11 -0500 In-reply-to: To: scim@ietf.org References: Message-id: <30042F6B-A126-4B11-BAE9-5E288E274BEE@me.com> X-Mailer: Apple Mail (2.1283) Subject: Re: [scim] Use of value for complex multi-valued attributes X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 02:44:36 -0000 --Apple-Mail=_D86214FA-3DA9-449D-8A82-D1EE7D2978E5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii +1 On May 14, 2013, at 2:01 PM, scim-request@ietf.org wrote: >=20 > Maybe we should indicate that "value" is NOT to be used with complex = attributes? Otherwise, I could see a lot of inter-op issues as people = decide whih combinations or specific attribute is the significant = attribute when it comes to complex attributes. >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 Scott Fehrman, sfehrman@me.com= --Apple-Mail=_D86214FA-3DA9-449D-8A82-D1EE7D2978E5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii scim-request@ietf.org = wrote:

Phil

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


Scott = Fehrman, sfehrman@me.com
= --Apple-Mail=_D86214FA-3DA9-449D-8A82-D1EE7D2978E5-- From aredston@switchresearch.com Wed May 15 01:28:25 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A4A821F8599 for ; Wed, 15 May 2013 01:28:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.733 X-Spam-Level: X-Spam-Status: No, score=-1.733 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f21eTGFZbgnf for ; Wed, 15 May 2013 01:28:21 -0700 (PDT) Received: from appa.redston.com (host217-37-178-214.in-addr.btopenworld.com [217.37.178.214]) by ietfa.amsl.com (Postfix) with ESMTP id 6E11021F8F17 for ; Wed, 15 May 2013 01:28:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by appa.redston.com (Postfix) with ESMTP id 22F7B44894 for ; Wed, 15 May 2013 09:22:17 +0100 (BST) X-Virus-Scanned: amavisd-new at redston.com Received: from appa.redston.com ([127.0.0.1]) by localhost (appa.redston.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HihR2brie8AU for ; Wed, 15 May 2013 09:22:08 +0100 (BST) Received: from [192.168.148.25] (unknown [192.168.148.25]) by appa.redston.com (Postfix) with ESMTPSA id 5D0FF4485F for ; Wed, 15 May 2013 09:22:08 +0100 (BST) Message-ID: <51934718.3020500@switchresearch.com> Date: Wed, 15 May 2013 09:28:08 +0100 From: Alex Redston User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: scim@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------030404020809090604080000" Subject: Re: [scim] scim Digest, Vol 17, Issue 4 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 08:28:25 -0000 This is a multi-part message in MIME format. --------------030404020809090604080000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Phil, I would have to agree with your analysis, this is a little too open to interpretation The type and primary attributes both seem to be just pieces of arbitrary metadata, if we are going to have metadata like primary and type then why not simply have a structure for generic metadata: Then you could have whatever metadata was useful to provide context, like "type", "order", "primary", "depreciated". By all means be prescriptive on the most common metadata like "type" and "primary" to aid interoperability but make the model more extensible - what do you think? "addresses": [ { *"metadata": {* "type": "work", "primary": true } *"value": {* "streetAddress": "100 Universal City Plaza", "locality": "Hollywood", "region": "CA", "postalCode": "91608", "country": "USA", } }, { *"metadata": {* "type": "home" } "value": { "streetAddress": "1 Western Drive", "locality": "Hollywood", "region": "CA", "postalCode": "91608", "country": "USA", } } { *"metadata": {* "type": "home", "depreciated": "true" } "value": { "streetAddress": "2 Beverly Drive", "locality": "Hollywood", "region": "CA", "postalCode": "91608", "country": "USA", } } ] Alex Alex Redston Technical Architect Switch Research On 14/05/2013 20:01, scim-request@ietf.org wrote: > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. To do so, go to > > https://www.ietf.org/mailman/listinfo/scim > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > MIME or Plain Text Digests?" to MIME. You can set this option > globally for all the list digests you receive at this point. > > > > Send scim mailing list submissions to > scim@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/scim > or, via email, send a message with subject or body 'help' to > scim-request@ietf.org > > You can reach the person managing the list at > scim-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of scim digest..." > > > Today's Topics: > > 1. Use of value for complex multi-valued attributes (Phil Hunt) > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim -- Alex Redston Technical Architect, Managing Director Switch Research Limited +44 1328 838821 +44 7973 320795 --------------030404020809090604080000 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Phil,

I would have to agree with your analysis, this is a little too open to interpretation

The type and primary attributes both seem to be just pieces of arbitrary metadata, if we are going to have metadata like primary and type then why not simply have a structure for generic metadata:

Then you could have whatever metadata was useful to provide context, like "type", "order", "primary", "depreciated". By all means be prescriptive on the most common metadata like "type" and "primary" to aid interoperability but make the model more extensible - what do you think?

"addresses": [
  {
     "metadata": {
         "type": "work",
         "primary": true
     }
     "value": {
         "streetAddress": "100 Universal City Plaza",
         "locality": "Hollywood",
         "region": "CA",
         "postalCode": "91608",
         "country": "USA",       
     }
   },
   {
     "metadata": {
         "type": "home"
     }
     "value": {
         "streetAddress": "1 Western Drive",
         "locality": "Hollywood",
         "region": "CA",
         "postalCode": "91608",
         "country": "USA",
     }
  }
   {
     "metadata": {
         "type": "home",
        "depreciated": "true"
     }
     "value": {
         "streetAddress": "2 Beverly Drive",
         "locality": "Hollywood",
         "region": "CA",
         "postalCode": "91608",
         "country": "USA",
     }
  }

]


Alex



Alex Redston
Technical Architect
Switch Research

On 14/05/2013 20:01, scim-request@ietf.org wrote:
If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription.  To do so, go to 

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

Click the 'Unsubscribe or edit options' button, log in, and set "Get
MIME or Plain Text Digests?" to MIME.  You can set this option
globally for all the list digests you receive at this point.



Send scim mailing list submissions to
	scim@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.ietf.org/mailman/listinfo/scim
or, via email, send a message with subject or body 'help' to
	scim-request@ietf.org

You can reach the person managing the list at
	scim-owner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of scim digest..."



Today's Topics:

   1. Use of value for complex multi-valued attributes (Phil Hunt)



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


-- 
Alex Redston

Technical Architect, Managing Director
Switch Research Limited

+44 1328 838821
+44 7973 320795
--------------030404020809090604080000-- From phil.hunt@oracle.com Wed May 15 09:12:23 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A08A21F87C5 for ; Wed, 15 May 2013 09:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dh42ZLpOARpK for ; Wed, 15 May 2013 09:12:17 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 5EDF721F87D2 for ; Wed, 15 May 2013 09:12:16 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4FGCEHB023302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 15 May 2013 16:12:15 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4FGCD66009425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 15 May 2013 16:12:13 GMT Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4FGCChH014190; Wed, 15 May 2013 16:12:12 GMT Received: from [192.168.1.89] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 15 May 2013 09:12:11 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_83749031-DA89-40D6-BB7C-7EE2C61E63C3" From: Phil Hunt In-Reply-To: <51934718.3020500@switchresearch.com> Date: Wed, 15 May 2013 09:12:16 -0700 Message-Id: <769A6FDD-4261-4736-9B26-DD0D55440157@oracle.com> References: <51934718.3020500@switchresearch.com> To: Alex Redston X-Mailer: Apple Mail (2.1283) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: scim@ietf.org Subject: Re: [scim] scim Digest, Vol 17, Issue 4 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 16:12:23 -0000 --Apple-Mail=_83749031-DA89-40D6-BB7C-7EE2C61E63C3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Alex, I guess the issue is avoiding too many normative changes. Also, I would = prefer getting too "wordy" or having too much structure. Also, so far = "meta" is used for things unrelated to the data values (e.g. modified = date) and usually not modifiable by clients. I admit, "type" and = "primary" has a meta feel, but clearly still client-controlled. Having value contain sub-attributes makes some sense from a truly = consistent view of defining multi-valued attributes. However, I believe = the original intent is that "value" always contain a string value. Others may be able to give the original 1.0 perspective on this. There's = often good reason for these things. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-05-15, at 1:28 AM, Alex Redston wrote: > Phil, >=20 > I would have to agree with your analysis, this is a little too open to = interpretation >=20 > The type and primary attributes both seem to be just pieces of = arbitrary metadata, if we are going to have metadata like primary and = type then why not simply have a structure for generic metadata: >=20 > Then you could have whatever metadata was useful to provide context, = like "type", "order", "primary", "depreciated". By all means be = prescriptive on the most common metadata like "type" and "primary" to = aid interoperability but make the model more extensible - what do you = think? >=20 > "addresses": [ > { > "metadata": { > "type": "work", > "primary": true > } > "value": { > "streetAddress": "100 Universal City Plaza", > "locality": "Hollywood", > "region": "CA", > "postalCode": "91608", > "country": "USA", =20 > } > }, > { > "metadata": { > "type": "home" > } > "value": { > "streetAddress": "1 Western Drive", > "locality": "Hollywood", > "region": "CA", > "postalCode": "91608", > "country": "USA", > } > } > { > "metadata": { > "type": "home", > "depreciated": "true" > } > "value": { > "streetAddress": "2 Beverly Drive", > "locality": "Hollywood", > "region": "CA", > "postalCode": "91608", > "country": "USA", > } > } >=20 > ] >=20 >=20 > Alex >=20 >=20 >=20 > Alex Redston > Technical Architect > Switch Research=20 >=20 > On 14/05/2013 20:01, scim-request@ietf.org wrote: >> If you have received this digest without all the individual message >> attachments you will need to update your digest options in your list >> subscription. To do so, go to=20 >>=20 >> https://www.ietf.org/mailman/listinfo/scim >>=20 >> Click the 'Unsubscribe or edit options' button, log in, and set "Get >> MIME or Plain Text Digests?" to MIME. You can set this option >> globally for all the list digests you receive at this point. >>=20 >>=20 >>=20 >> Send scim mailing list submissions to >> scim@ietf.org >>=20 >> To subscribe or unsubscribe via the World Wide Web, visit >> https://www.ietf.org/mailman/listinfo/scim >> or, via email, send a message with subject or body 'help' to >> scim-request@ietf.org >>=20 >> You can reach the person managing the list at >> scim-owner@ietf.org >>=20 >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of scim digest..." >>=20 >>=20 >> Today's Topics: >>=20 >> 1. Use of value for complex multi-valued attributes (Phil Hunt) >>=20 >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >=20 > --=20 > Alex Redston >=20 > Technical Architect, Managing Director > Switch Research Limited >=20 > +44 1328 838821 > +44 7973 320795 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail=_83749031-DA89-40D6-BB7C-7EE2C61E63C3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
Having = value contain sub-attributes makes some sense from a truly consistent = view of defining multi-valued attributes. However, I believe the = original intent is that "value" always contain a string = value.

Others may be able to give the original = 1.0 perspective on this. There's often good reason for these = things.

Phil

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





On 2013-05-15, at 1:28 AM, Alex Redston wrote:

=20 =20
Phil,

I would have to agree with your analysis, this is a little too open to interpretation

The type and primary attributes both seem to be just pieces of arbitrary metadata, if we are going to have metadata like primary and type then why not simply have a structure for generic = metadata:

Then you could have whatever metadata was useful to provide context, like "type", "order", "primary", "depreciated". By all means be prescriptive on the most common metadata like "type" and "primary" to aid interoperability but make the model more extensible - what do you think?

"addresses": [
  {
     "metadata": {
         "type": "work",
         "primary": true
     }
     "value": {
=          "streetAddress": = "100 Universal City Plaza",
         "locality": = "Hollywood",
         "region": = "CA",
         "postalCode": = "91608",
         "country": = "USA",       
     }
   },
   {
     "metadata": {
         "type": "home"
     }
     "value": {
=          "streetAddress": = "1 Western Drive",
         "locality": = "Hollywood",
         "region": = "CA",
         "postalCode": = "91608",
         "country": = "USA",
     }
  }
   {
     "metadata": {
         "type": "home",
        "depreciated": "true"
     }
     "value": {
=          "streetAddress": = "2 Beverly Drive",
         "locality": = "Hollywood",
         "region": = "CA",
         "postalCode": = "91608",
         "country": = "USA",
     }
  }

]


Alex



Alex Redston
Technical Architect
Switch Research

On 14/05/2013 20:01, scim-request@ietf.org = wrote:
If you have received this digest without all the =
individual message
attachments you will need to update your digest options in your list
subscription.  To do so, go to=20

https://www.ietf.org/m=
ailman/listinfo/scim

Click the 'Unsubscribe or edit options' button, log in, and set "Get
MIME or Plain Text Digests?" to MIME.  You can set this option
globally for all the list digests you receive at this point.



Send scim mailing list submissions to
	scim@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.ietf.org/m=
ailman/listinfo/scim
or, via email, send a message with subject or body 'help' to
	scim-request@ietf.org

You can reach the person managing the list at
	scim-owner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of scim digest..."



Today's Topics:

   1. Use of value for complex multi-valued attributes (Phil Hunt)



_______________________________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/m=
ailman/listinfo/scim


--=20
Alex Redston

Technical Architect, Managing Director
Switch Research Limited

+44 1328 838821
+44 7973 320795
_______________________________________________
scim mailing = list
scim@ietf.org
https://www.ietf.org/ma= ilman/listinfo/scim

= --Apple-Mail=_83749031-DA89-40D6-BB7C-7EE2C61E63C3-- From iesg-secretary@ietf.org Wed May 15 09:50:30 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79E8A21F9080; Wed, 15 May 2013 09:50:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-sCjmIa1oRL; Wed, 15 May 2013 09:50:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C41221F8ECB; Wed, 15 May 2013 09:50:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IESG Secretary To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 4.45 Message-ID: <20130515165029.7586.56475.idtracker@ietfa.amsl.com> Date: Wed, 15 May 2013 09:50:29 -0700 Cc: scim@ietf.org Subject: [scim] SCIM Working Group to Close Design Team and Schedule Regular Conference Calls X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 16:50:30 -0000 Folks, The goal of the SCIM design team was to set the WG on a path towards "scim 2.0" by identifying and proposing solutions to the major issues. The time has now come to close the design team and thank the contributors for all their hard work. In order to preserve the momentum and make sure the SCIM WG will complete in a timely manner we will start a schedule of bi-weekly conference calls [1] open to all. Before each call, an agenda will be posted to the list and after each call notes will be posted to the list and the WG wiki. The time of the call will be 10 AM PST every other Wednesday. The first call will be 2 weeks from next Wednesday (29/5) and this email serves as notification for this and all future calls until further notice. A separate email with the meeting details will be sent to the list shortly. Leif & Morteza [1] http://www.ietf.org/iesg/statement/interim-meetings.html From t.rossner@tarent.de Thu May 16 00:19:29 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4046021F9113 for ; Thu, 16 May 2013 00:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LsPI-sR4VQew for ; Thu, 16 May 2013 00:19:24 -0700 (PDT) Received: from dovecot.stylite.de (dovecot.stylite.de [213.183.76.200]) by ietfa.amsl.com (Postfix) with ESMTP id 80C4921F86CA for ; Thu, 16 May 2013 00:19:23 -0700 (PDT) Received: from [172.26.4.225] (fb-n15-11.unbelievable-machine.net [94.198.62.204]) (Authenticated sender: t.rossner@osiam.de) by dovecot.stylite.de (Postfix) with ESMTPSA id D0E0D103 for ; Thu, 16 May 2013 09:19:22 +0200 (CEST) Message-ID: <51948879.6050200@tarent.de> Date: Thu, 16 May 2013 09:19:21 +0200 From: =?windows-1252?Q?Thorsten_Ro=DFner?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: scim@ietf.org References: <51948828.1000106@osiam.de> In-Reply-To: <51948828.1000106@osiam.de> X-Forwarded-Message-Id: <51948828.1000106@osiam.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-MServer-Mail-Id: 4965929 Subject: Re: [scim] externalId - How to distinguish between client's tenants X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 07:19:29 -0000 Hi again, as there was no response to my question below I would like to know if the question itself was unclear or if it is just outside the SCIM scope? Thanks and best regards Thorsten Am 07.05.2013 10:22, schrieb Thorsten Roßner: > Hi All, > > can someone please help me understanding the Common Schema's "externalId"? > > My current understanding: > > - The externalId for a resource can be stored - if provided - for each > Service Consumer's tenant (or if a SC doesn't support tenants, the > externalId is stored for each SC's instance). A single SCIM resource > thereby can have multiple externalIds (depending on the number of > consumer tenants or instances). > > The question that derives from my understanding: > > - How can the SP differentiate between tenants of an SC in order to > respect the following quote from the specification: "The Service > Provider MUST always interpret the externalId as scoped to the Service > Consumer's tenant."? > > Or is the differentiation outside the scope of the SCIM spec? > > Thanks & cheers > Thorsten > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From prvs=18557f5dd9=julian.builes@cerner.com Thu May 23 08:04:34 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83FED21F9746 for ; Thu, 23 May 2013 08:04:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1EgUw0Rb+97 for ; Thu, 23 May 2013 08:04:28 -0700 (PDT) Received: from PPKC2MAIL4.cernercloud.com (ppkc2mail4.cernercloud.com [159.140.195.94]) by ietfa.amsl.com (Postfix) with ESMTP id 07E6E21F9742 for ; Thu, 23 May 2013 08:04:20 -0700 (PDT) Received: from CERNMSGLS5HUB1.cerner.net ([170.71.96.36]) by PPKC2MAIL4.CERNERCLOUD.COM (8.14.5/8.14.5) with ESMTP id r4NF4JT4019806 for ; Thu, 23 May 2013 10:04:19 -0500 Received: from CERNMSGLS5MB3A.cerner.net ([169.254.1.23]) by CERNMSGLS5HUB1.cerner.net ([170.71.96.36]) with mapi id 14.02.0318.004; Thu, 23 May 2013 10:04:19 -0500 From: "builes,julian" To: "scim@ietf.org" Thread-Topic: Schemas Attribute Thread-Index: AQHOV8bMGE5KLv6Th0yuacXyxRoQ1Q== Date: Thu, 23 May 2013 15:04: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.2.4.120824 x-originating-ip: [39.250.140.23] Content-Type: multipart/alternative; boundary="_000_D8EED9610A191B46B7F9165BA9F390D913B9EDCACERNMSGLS5MB3Ac_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626, 1.0.431, 0.0.0000 definitions=2013-05-23_04:2013-05-23, 2013-05-23, 1970-01-01 signatures=0 Subject: [scim] Schemas Attribute X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 15:06:01 -0000 --_000_D8EED9610A191B46B7F9165BA9F390D913B9EDCACERNMSGLS5MB3Ac_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, After reading the core schema document, I find that I am a little confused = about the intended usage of the schemas attribute. According to section 5.1 (Common Schema Attributes) the 'schemas' attribute= is optional: "It is not necessary to specify the schemas attribute if the = Resource is fully defined in this document as the core schema is implicitly= included." But after reading further, section 5.2 ("schemas" attribute) states that th= is attribute is required: "Each String value must be a unique URI. This spe= cification defines URIs for User, Group, and a standard "enterprise" extens= ion. All representations of SCIM schema MUST include a non-zero value array= with value(s) of the URIs supported by that representation. Duplicate valu= es MUST NOT be included. Value order is not specified and MUST not impact b= ehavior. REQUIRED." So is schemas a required attribute? -- Best Regards, Julian Builes Software Engineer julian.builes@cerner.com CONFIDENTIALITY NOTICE This message and any included attachments are from C= erner Corporation and are intended only for the addressee. The information = contained in this message is confidential and may constitute inside or non-= public information under international, federal, or state securities laws. = Unauthorized forwarding, printing, copying, distribution, or use of such in= formation is strictly prohibited and may be unlawful. If you are not the ad= dressee, please promptly delete this message and notify the sender of the d= elivery error by e-mail or you may call Cerner's corporate offices in Kansa= s City, Missouri, U.S.A at (+1) (816)221-1024. --_000_D8EED9610A191B46B7F9165BA9F390D913B9EDCACERNMSGLS5MB3Ac_ Content-Type: text/html; charset="us-ascii" Content-ID: <9AB98E820274F24A98D7C640D27072FC@cerner.com> Content-Transfer-Encoding: quoted-printable
Hi all,

After reading the core schema document, I find that I am a little conf= used about the intended usage of the schemas attribute.

According to section 5.1 (Common Schema Attributes) the 'schemas' attr= ibute is optional: "= It is not necessary to specify the schemas attribute if the Resource is fully= defined in this document as the core schema is implicitly included."<= /span>

But after reading further, section 5.2 ("schemas" attribute)= states that this attribute is required: "Each String value must be a unique URI. This specification defines URIs for User, Group, and= a standard "enterprise" extension. All representations of SCIM s= chema MUST include a non-zero value array with value(s) of the URIs support= ed by that representation. Duplicate values MUST NOT be included. Value order is not specified and MUST not impact beh= avior. REQUIRED."

So is sche= mas a required attribute?

-- 
Best Regards,
Julian Builes
Software Engineer
julian.builes@cerner.com
CONFIDENTIALITY NOTICE This message and any included attachments are from C= erner Corporation and are intended only for the addressee. The information = contained in this message is confidential and may constitute inside or non-= public information under international, federal, or state securities laws. = Unauthorized forwarding, printing, copying, distribution, or use of such in= formation is strictly prohibited and may be unlawful. If you are not the ad= dressee, please promptly delete this message and notify the sender of the d= elivery error by e-mail or you may call Cerner's corporate offices in K= ansas City, Missouri, U.S.A at (+1) (816)221-1024.
--_000_D8EED9610A191B46B7F9165BA9F390D913B9EDCACERNMSGLS5MB3Ac_-- From leifj@mnt.se Thu May 23 09:43:48 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3128821F9609 for ; Thu, 23 May 2013 09:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mOzjdq3dQDku for ; Thu, 23 May 2013 09:43:29 -0700 (PDT) Received: from mail-ee0-f47.google.com (mail-ee0-f47.google.com [74.125.83.47]) by ietfa.amsl.com (Postfix) with ESMTP id 4C13A21F977B for ; Thu, 23 May 2013 09:40:34 -0700 (PDT) Received: by mail-ee0-f47.google.com with SMTP id t10so1997742eei.6 for ; Thu, 23 May 2013 09:40:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding:x-gm-message-state; bh=Oqio+Pk5VDRYXqYDwhi7VbfeZ/iuX+4C5WU+J7ntsoA=; b=YK27T7e0/eCb4P8IoPy/oYokDsP8qW0QiW1SAftYhl2wtmaSM1vrV4AEUN9+/RV9WX VZ5Sa0l10jURV4lod5wZ4f0eJQlnikCSbUqD1KoqLNe211PpymIzuoJhNWrWZM2Cb+bt bXgsqwEKcemaDdrfD9DdonjF+8+RNLkWZXGVg9fhYuDTBcuknQYkiNMBzjpsxqGlXFh0 VMtnAHyEoRn0T3RJAV5AF+pensbmRq5bENOfeUH9Z6LFGmioY5bd9Q7lo+mCrdIiQO0r EJwd5NTL+eaosFNmRi3a74b7fSowQMEX7PCr9QBFmmC+4Ik7+ra+HmPkg+A5ceD5aHhg vxoQ== X-Received: by 10.14.5.5 with SMTP id 5mr33154388eek.21.1369327233347; Thu, 23 May 2013 09:40:33 -0700 (PDT) Received: from [10.59.1.63] (host178-210-static.36-85-b.business.telecomitalia.it. [85.36.210.178]) by mx.google.com with ESMTPSA id bo9sm4148166eeb.9.2013.05.23.09.40.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 23 May 2013 09:40:32 -0700 (PDT) Message-ID: <519E467E.6010703@mnt.se> Date: Thu, 23 May 2013 18:40:30 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: scim WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlg7TGXtudy5Q6r8u7ug4dubcyTWTScWMfswcC7tV+zV1JZOQoBm0wd2GWn5rSiOr2BQR6o Subject: [scim] scheduling in Berlin X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 16:43:48 -0000 Folks, Who are planning to come to Berlin for the next IETF meeting? What topics should we put on the agenda? WG scheduling ends in about a week and I'd like to know that we have enough attendance to ask for a slot. Best R. Leif From phil.hunt@oracle.com Thu May 23 10:07:20 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ACB921F95FD for ; Thu, 23 May 2013 10:07:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.418 X-Spam-Level: X-Spam-Status: No, score=-5.418 tagged_above=-999 required=5 tests=[AWL=-0.215, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mK99s9G8ZgRl for ; Thu, 23 May 2013 10:07:05 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 4E73F21F961B for ; Thu, 23 May 2013 10:00:06 -0700 (PDT) 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 r4NH04j9004073 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 23 May 2013 17:00:05 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 r4NH03C7004563 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 23 May 2013 17:00:04 GMT Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4NH03GN003296; Thu, 23 May 2013 17:00:03 GMT Received: from [192.168.1.125] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 23 May 2013 10:00:03 -0700 References: <519E467E.6010703@mnt.se> Mime-Version: 1.0 (1.0) In-Reply-To: <519E467E.6010703@mnt.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <6F23FAAD-E13B-4091-B1FB-67633BC29249@oracle.com> X-Mailer: iPhone Mail (10B329) From: Phil Hunt Date: Thu, 23 May 2013 10:00:03 -0700 To: Leif Johansson X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: scim WG Subject: Re: [scim] scheduling in Berlin X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 17:07:20 -0000 I am planning to be there. Would prefer not to meet on friday. :-) Would like to have a final proposal for schema/schema extensions. I think ke= lly is working on that.=20 Any other items for draft 03? Phil On 2013-05-23, at 9:40, Leif Johansson wrote: >=20 > Folks, >=20 > Who are planning to come to Berlin for the next IETF meeting? >=20 > What topics should we put on the agenda? >=20 > WG scheduling ends in about a week and I'd like to know that we > have enough attendance to ask for a slot. >=20 > Best R. > Leif > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From tonynad@microsoft.com Thu May 23 10:51:36 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94C7721F8EEC for ; Thu, 23 May 2013 10:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.533 X-Spam-Level: X-Spam-Status: No, score=0.533 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ImKpr4ngpYMl for ; Thu, 23 May 2013 10:51:20 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0237.outbound.protection.outlook.com [207.46.163.237]) by ietfa.amsl.com (Postfix) with ESMTP id CF2BF21F8D31 for ; Thu, 23 May 2013 10:38:46 -0700 (PDT) Received: from BY2FFO11FD014.protection.gbl (10.1.15.201) by BY2FFO11HUB017.protection.gbl (10.1.14.91) with Microsoft SMTP Server (TLS) id 15.0.698.0; Thu, 23 May 2013 17:38:45 +0000 Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD014.mail.protection.outlook.com (10.1.14.76) with Microsoft SMTP Server (TLS) id 15.0.698.0 via Frontend Transport; Thu, 23 May 2013 17:38:45 +0000 Received: from CO9EHSOBE017.bigfish.com (157.54.51.80) by mail.microsoft.com (157.54.80.48) with Microsoft SMTP Server (TLS) id 14.3.136.1; Thu, 23 May 2013 17:38:42 +0000 Received: from mail74-co9-R.bigfish.com (10.236.132.234) by CO9EHSOBE017.bigfish.com (10.236.130.80) with Microsoft SMTP Server id 14.1.225.23; Thu, 23 May 2013 17:37:30 +0000 Received: from mail74-co9 (localhost [127.0.0.1]) by mail74-co9-R.bigfish.com (Postfix) with ESMTP id D570326023A for ; Thu, 23 May 2013 17:37:30 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT004.namprd03.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -17 X-BigFish: PS-17(zz9371I542Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6h1082kzz1033IL8275dhz31h2a8h668h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh9a9j1155h) Received-SPF: softfail (mail74-co9: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=tonynad@microsoft.com; helo=BL2PRD0310HT004.namprd03.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BY2PR03MB043; H:BY2PR03MB041.namprd03.prod.outlook.com; LANG:en; Received: from mail74-co9 (localhost.localdomain [127.0.0.1]) by mail74-co9 (MessageSwitch) id 1369330649534139_28194; Thu, 23 May 2013 17:37:29 +0000 (UTC) Received: from CO9EHSMHS029.bigfish.com (unknown [10.236.132.253]) by mail74-co9.bigfish.com (Postfix) with ESMTP id 75E624E006B; Thu, 23 May 2013 17:37:29 +0000 (UTC) Received: from BL2PRD0310HT004.namprd03.prod.outlook.com (157.56.240.21) by CO9EHSMHS029.bigfish.com (10.236.130.39) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 23 May 2013 17:37:28 +0000 Received: from BY2PR03MB043.namprd03.prod.outlook.com (10.255.241.147) by BL2PRD0310HT004.namprd03.prod.outlook.com (10.255.97.39) with Microsoft SMTP Server (TLS) id 14.16.311.1; Thu, 23 May 2013 17:37:27 +0000 Received: from BY2PR03MB041.namprd03.prod.outlook.com (10.255.241.145) by BY2PR03MB043.namprd03.prod.outlook.com (10.255.241.147) with Microsoft SMTP Server (TLS) id 15.0.698.13; Thu, 23 May 2013 17:37:24 +0000 Received: from BY2PR03MB041.namprd03.prod.outlook.com ([169.254.8.74]) by BY2PR03MB041.namprd03.prod.outlook.com ([169.254.8.74]) with mapi id 15.00.0698.010; Thu, 23 May 2013 17:37:24 +0000 From: Anthony Nadalin To: Leif Johansson , scim WG Thread-Topic: [scim] scheduling in Berlin Thread-Index: AQHOV9TYiVuiFmoMYk++lStlMj/fNJkTCKRw Date: Thu, 23 May 2013 17:37:24 +0000 Message-ID: <4bb2f8a9efaf405e91e65359fa7ba9d0@BY2PR03MB041.namprd03.prod.outlook.com> References: <519E467E.6010703@mnt.se> In-Reply-To: <519E467E.6010703@mnt.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.46.126.7] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BY2PR03MB043.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%MNT.SE$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC105.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC105.redmond.corp.microsoft.com X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(377454002)(189002)(13464003)(74366001)(47446002)(23726002)(51856001)(54356001)(74502001)(81542001)(53806001)(6806003)(50986001)(81342001)(46102001)(33646001)(46406003)(44976003)(59766001)(4396001)(69226001)(79102001)(47736001)(74876001)(16676001)(80022001)(54316002)(76482001)(56816002)(20776003)(66066001)(50466002)(74316001)(74662001)(47776003)(63696002)(31966008)(56776001)(77982001)(65816001)(49866001)(47976001)(74706001)(42262001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB017; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 085551F5A8 Subject: Re: [scim] scheduling in Berlin X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 17:51:37 -0000 I will be there -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Lei= f Johansson Sent: Thursday, May 23, 2013 9:41 AM To: scim WG Subject: [scim] scheduling in Berlin Folks, Who are planning to come to Berlin for the next IETF meeting? What topics should we put on the agenda? WG scheduling ends in about a week and I'd like to know that we have enough= attendance to ask for a slot. Best R. Leif _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim From kelly.grizzle@sailpoint.com Thu May 23 10:57:39 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66E7A21F9579 for ; Thu, 23 May 2013 10:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5fOJW7M39fFI for ; Thu, 23 May 2013 10:57:22 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe002.messaging.microsoft.com [213.199.154.205]) by ietfa.amsl.com (Postfix) with ESMTP id 2B74621F87D2 for ; Thu, 23 May 2013 10:43:20 -0700 (PDT) Received: from mail90-am1-R.bigfish.com (10.3.201.247) by AM1EHSOBE019.bigfish.com (10.3.207.141) with Microsoft SMTP Server id 14.1.225.23; Thu, 23 May 2013 17:43:19 +0000 Received: from mail90-am1 (localhost [127.0.0.1]) by mail90-am1-R.bigfish.com (Postfix) with ESMTP id C7E04C03D5; Thu, 23 May 2013 17:43:19 +0000 (UTC) X-Forefront-Antispam-Report: CIP:132.245.1.133; KIP:(null); UIP:(null); IPV:NLI; H:BLUPRD0412HT002.namprd04.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: PS-22(zz9371I542Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL8275dhz31h2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1155h) Received-SPF: softfail (mail90-am1: transitioning domain of sailpoint.com does not designate 132.245.1.133 as permitted sender) client-ip=132.245.1.133; envelope-from=kelly.grizzle@sailpoint.com; helo=BLUPRD0412HT002.namprd04.prod.outlook.com ; .outlook.com ; Received: from mail90-am1 (localhost.localdomain [127.0.0.1]) by mail90-am1 (MessageSwitch) id 1369330998217555_12105; Thu, 23 May 2013 17:43:18 +0000 (UTC) Received: from AM1EHSMHS016.bigfish.com (unknown [10.3.201.227]) by mail90-am1.bigfish.com (Postfix) with ESMTP id 2CC6C2E0068; Thu, 23 May 2013 17:43:18 +0000 (UTC) Received: from BLUPRD0412HT002.namprd04.prod.outlook.com (132.245.1.133) by AM1EHSMHS016.bigfish.com (10.3.207.154) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 23 May 2013 17:43:18 +0000 Received: from BLUPRD0412MB643.namprd04.prod.outlook.com ([169.254.4.9]) by BLUPRD0412HT002.namprd04.prod.outlook.com ([10.255.214.163]) with mapi id 14.16.0311.000; Thu, 23 May 2013 17:43:17 +0000 From: Kelly Grizzle To: Leif Johansson , scim WG Thread-Topic: [scim] scheduling in Berlin Thread-Index: AQHOV9S4KlRWw0PNFk+pPCFTF4qtCpkTCc0g Date: Thu, 23 May 2013 17:43:16 +0000 Message-ID: <56C3C758F9D6534CA3778EAA1E0C34375C436542@BLUPRD0412MB643.namprd04.prod.outlook.com> References: <519E467E.6010703@mnt.se> In-Reply-To: <519E467E.6010703@mnt.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 3402FAD30046703402FC20 x-originating-ip: [173.226.147.242] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Subject: Re: [scim] scheduling in Berlin X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 17:57:39 -0000 I have a conflict, so will not be able to make the meeting in person. I wi= ll try to participate remotely if possible. --Kelly -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Lei= f Johansson Sent: Thursday, May 23, 2013 11:41 AM To: scim WG Subject: [scim] scheduling in Berlin Folks, Who are planning to come to Berlin for the next IETF meeting? What topics should we put on the agenda? WG scheduling ends in about a week and I'd like to know that we have enough= attendance to ask for a slot. Best R. Leif _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim From samuel@erdtman.se Sun May 26 22:13:18 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3FA521F9234 for ; Sun, 26 May 2013 22:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZft3YxY6-k1 for ; Sun, 26 May 2013 22:13:13 -0700 (PDT) Received: from mail-ee0-f52.google.com (mail-ee0-f52.google.com [74.125.83.52]) by ietfa.amsl.com (Postfix) with ESMTP id 89E5621F920B for ; Sun, 26 May 2013 22:13:09 -0700 (PDT) Received: by mail-ee0-f52.google.com with SMTP id c13so3478700eek.25 for ; Sun, 26 May 2013 22:13:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:from:mime-version:in-reply-to:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=AvTRnDz3i+T+MBBIzQ0L+D0uBeFEZGjGRnpa7vCijcI=; b=WOmiYaFAZ1My1LiDolNmO9QY2bvbBVa1vXhUNlfKy6CS4DxuyctKO/SR67K/xMtgFM SCz0EsAS/ZLA6bgw80Kb6E3byb2XcLG+zzOJSh2Cgor7WXpwVn6k/8CxzZILkHqxNcjB SH6dSi+PgvTsJDWA05D8jPhczlUjoRlkOr/7dtI4YSl1Rjt5WUt0QSkT5fgLJla50afG UH/g0qHEWM2mE+1Dk1U5LIBcpxsDFlue6DDKpiTbcEfWYBvNVyUks58L3gplAdST29yH 1StaJ/NXgWCKnH0e6DHg1bK9olbR5tVAkWBUIm2r5A3MvemEjhWZv64VlMd8fFNUzOFn Os/A== X-Received: by 10.14.103.200 with SMTP id f48mr8447581eeg.150.1369631588228; Sun, 26 May 2013 22:13:08 -0700 (PDT) References: From: Samuel Erdtman Mime-Version: 1.0 (1.0) In-Reply-To: Date: Mon, 27 May 2013 07:13:04 +0200 Message-ID: <-1114418971685601798@unknownmsgid> To: "builes,julian" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmeDX3+mGotAzsGbIFO/H/Peveeojq0wlyflT4t3hwtc0+7T51CqCVL++bzyj0S2uZX6pyC Cc: "scim@ietf.org" Subject: Re: [scim] Schemas Attribute X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 05:13:18 -0000 When I have worked with implementing this I have interpreter schemas a require attribute. Other comments? Best Regards Samuel Erdtman Sent from my iPhone On 23 maj 2013, at 17:06, "builes,julian" wrote: > schemas a require From leifj@mnt.se Mon May 27 07:27:55 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26C0821F95EC for ; Mon, 27 May 2013 07:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vtgsqygxTc82 for ; Mon, 27 May 2013 07:27:51 -0700 (PDT) Received: from mail-ee0-f43.google.com (mail-ee0-f43.google.com [74.125.83.43]) by ietfa.amsl.com (Postfix) with ESMTP id C0CED21F901A for ; Mon, 27 May 2013 07:27:50 -0700 (PDT) Received: by mail-ee0-f43.google.com with SMTP id d41so4126786eek.16 for ; Mon, 27 May 2013 07:27:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding:x-gm-message-state; bh=w3//sH27vK0aTzqyOMxYAg7CLY6RAiXyx+DmBgz2K4k=; b=psqy76FSOgpYXLLE1BPdjQRJaPQpqiEzC4gyUcQWZUxJr9DnBTgPB433nwbh8BgJa+ xtGcp3dYdAgSGiDOp4WcHEVWw0QGkKYNOI/r+F4O1bfvHhu7Ef8rYNtBbzMw+ofxOgpK 6ok8DjZjd4F8algCSw1uMeezJ8qHVhlqI9nICqTSL0QEcAelcRAEyMKySDEP/ypT5dCb FnYzynNmbISQdT4stm7K2VRPjwTeYacwwqBPNUxlJ0x5KvnyO7/AiE1oWTB7690nfMuN axwex2ZYO60po+fqUIdoMqsYcb7mb5NiVOU743JZsbuGihvSmKMcl1/xGCzeXDqosCnZ qoSw== X-Received: by 10.15.81.197 with SMTP id x45mr54323511eey.9.1369664869849; Mon, 27 May 2013 07:27:49 -0700 (PDT) Received: from ?IPv6:2001:948:6:2:6511:df4a:b588:a819? ([2001:948:6:2:6511:df4a:b588:a819]) by mx.google.com with ESMTPSA id f1sm13581879eem.17.2013.05.27.07.27.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 27 May 2013 07:27:48 -0700 (PDT) Message-ID: <51A36D63.8050805@mnt.se> Date: Mon, 27 May 2013 16:27:47 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: scim WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnqcP0ApOwbLGuw0XBgTJrzZgCpRE8G7udL8tl42XTV1g7vTP8ECAst2caqHY65oj4DhB6j Subject: [scim] Berlin X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 14:27:55 -0000 Folks, I've requested a 2hr session for Berlin and asked for Friday avoidance (not sure we'll get that though) Lets make sure we have lots of progress to fill the session! Please review and comment on the documents listed on our datatracker page: http://datatracker.ietf.org/wg/scim/ -> Documents Some of those are documents hoping for WG adoption and they need more review. In particular we need to look at Mark Wahls document on the JIT profile which potentially covers part of our deliverables. Leif From phil.hunt@oracle.com Wed May 29 10:02:39 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4592921F96E7 for ; Wed, 29 May 2013 10:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.25 X-Spam-Level: X-Spam-Status: No, score=-6.25 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7mIGEZ3JbQH5 for ; Wed, 29 May 2013 10:02:34 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 2E5EE21F9385 for ; Wed, 29 May 2013 10:02:34 -0700 (PDT) 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 r4TH2VS1027000 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 29 May 2013 17:02: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 r4TH2Wun014269 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 29 May 2013 17:02:32 GMT Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4TH2WBg018768 for ; Wed, 29 May 2013 17:02:32 GMT Received: from [192.168.1.89] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 29 May 2013 10:02:31 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) From: Phil Hunt In-Reply-To: <20130515165029.7586.56475.idtracker@ietfa.amsl.com> Date: Wed, 29 May 2013 10:02:30 -0700 Content-Transfer-Encoding: 7bit Message-Id: <0474EDCC-8480-4B2F-AF21-597B699883EF@oracle.com> References: <20130515165029.7586.56475.idtracker@ietfa.amsl.com> To: "scim@ietf.org WG" X-Mailer: Apple Mail (2.1283) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Subject: Re: [scim] SCIM Working Group to Close Design Team and Schedule Regular Conference Calls X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 17:02:39 -0000 Are we having the meeting today? Any info on the call? Phil @independentid www.independentid.com phil.hunt@oracle.com On 2013-05-15, at 9:50 AM, IESG Secretary wrote: > Folks, > > The goal of the SCIM design team was to set the WG on a path > towards "scim 2.0" by identifying and proposing solutions to the > major issues. The time has now come to close the design team > and thank the contributors for all their hard work. > > In order to preserve the momentum and make sure the SCIM > WG will complete in a timely manner we will start a schedule > of bi-weekly conference calls [1] open to all. > > Before each call, an agenda will be posted to the list and after > each call notes will be posted to the list and the WG wiki. > > The time of the call will be 10 AM PST every other Wednesday. > > The first call will be 2 weeks from next Wednesday (29/5) and > this email serves as notification for this and all future calls > until further notice. > > A separate email with the meeting details will be sent to the > list shortly. > > Leif & Morteza > > [1] http://www.ietf.org/iesg/statement/interim-meetings.html > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From kelly.grizzle@sailpoint.com Thu May 30 12:43:00 2013 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1E121F9371 for ; Thu, 30 May 2013 12:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ROjL7rg2n8M2 for ; Thu, 30 May 2013 12:42:55 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id BD3F021F8F3E for ; Thu, 30 May 2013 12:42:46 -0700 (PDT) Received: from mail213-tx2-R.bigfish.com (10.9.14.237) by TX2EHSOBE013.bigfish.com (10.9.40.33) with Microsoft SMTP Server id 14.1.225.23; Thu, 30 May 2013 19:42:46 +0000 Received: from mail213-tx2 (localhost [127.0.0.1]) by mail213-tx2-R.bigfish.com (Postfix) with ESMTP id C8687C80111; Thu, 30 May 2013 19:42:45 +0000 (UTC) X-Forefront-Antispam-Report: CIP:132.245.1.133; KIP:(null); UIP:(null); IPV:NLI; H:BLUPRD0412HT001.namprd04.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -29 X-BigFish: PS-29(zz9371Ic89bh542I1432I14e3M14ffIzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275dhz31h2a8h668h839h947hd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1155h) Received-SPF: softfail (mail213-tx2: transitioning domain of sailpoint.com does not designate 132.245.1.133 as permitted sender) client-ip=132.245.1.133; envelope-from=kelly.grizzle@sailpoint.com; helo=BLUPRD0412HT001.namprd04.prod.outlook.com ; .outlook.com ; Received: from mail213-tx2 (localhost.localdomain [127.0.0.1]) by mail213-tx2 (MessageSwitch) id 1369942963631389_7168; Thu, 30 May 2013 19:42:43 +0000 (UTC) Received: from TX2EHSMHS009.bigfish.com (unknown [10.9.14.235]) by mail213-tx2.bigfish.com (Postfix) with ESMTP id 97D3C140063; Thu, 30 May 2013 19:42:43 +0000 (UTC) Received: from BLUPRD0412HT001.namprd04.prod.outlook.com (132.245.1.133) by TX2EHSMHS009.bigfish.com (10.9.99.109) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 30 May 2013 19:42:43 +0000 Received: from BLUPRD0412MB643.namprd04.prod.outlook.com ([169.254.4.37]) by BLUPRD0412HT001.namprd04.prod.outlook.com ([10.255.214.162]) with mapi id 14.16.0311.000; Thu, 30 May 2013 19:42:39 +0000 From: Kelly Grizzle To: =?iso-8859-1?Q?Thorsten_Ro=DFner?= , "scim@ietf.org" Thread-Topic: [scim] externalId - How to distinguish between client's tenants Thread-Index: AQHOUgW4h/wtAYQfC0ieyP1B/aLvQpkeMB9g Date: Thu, 30 May 2013 19:42:39 +0000 Message-ID: <56C3C758F9D6534CA3778EAA1E0C34375C4488D6@BLUPRD0412MB643.namprd04.prod.outlook.com> References: <51948828.1000106@osiam.de> <51948879.6050200@tarent.de> In-Reply-To: <51948879.6050200@tarent.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 587CDF57004756587CE0A4 x-originating-ip: [173.226.147.242] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Subject: Re: [scim] externalId - How to distinguish between client's tenants X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 19:43:00 -0000 Sorry for the delay, Thorsten. The -01 revision of the api document discus= ses options for multi-tenancy in section 4, but does not require any partic= ular mechanism - http://tools.ietf.org/html/draft-ietf-scim-api-01#section-= 4. --Kelly -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Tho= rsten Ro=DFner Sent: Thursday, May 16, 2013 2:19 AM To: scim@ietf.org Subject: Re: [scim] externalId - How to distinguish between client's tenant= s Hi again, as there was no response to my question below I would like to know if the q= uestion itself was unclear or if it is just outside the SCIM scope? Thanks and best regards Thorsten Am 07.05.2013 10:22, schrieb Thorsten Ro=DFner: > Hi All, > > can someone please help me understanding the Common Schema's "externalId"= ? > > My current understanding: > > - The externalId for a resource can be stored - if provided - for each=20 > Service Consumer's tenant (or if a SC doesn't support tenants, the=20 > externalId is stored for each SC's instance). A single SCIM resource=20 > thereby can have multiple externalIds (depending on the number of=20 > consumer tenants or instances). > > The question that derives from my understanding: > > - How can the SP differentiate between tenants of an SC in order to=20 > respect the following quote from the specification: "The Service=20 > Provider MUST always interpret the externalId as scoped to the Service=20 > Consumer's tenant."? > > Or is the differentiation outside the scope of the SCIM spec? > > Thanks & cheers > Thorsten > > _______________________________________________ > 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