Subject: Re: [scim] scim Digest, Vol 8, Issue 70

From: Ganesh and Sashi Prasad <[email-masked]>
Date: Fri, 17 Aug 2012 07:19:42 +1000

> While I appreciate the thought and time Ganesh has put into the concepts,
I am not convinced the approach would be net better and less complex and so
do not support it and welcome moving on to other topics.

I agree. Perhaps it would be best for the spec committee to move on to
tackling other issues. The approach I'm proposing has been well-understood
already, so I don't think anything would be gained by me putting it into an
Internet Draft at this stage.

Just out of interest, my current employer (a major telco with about 10
million subscribers) adopts the approach of using a relational database as
the "source of truth" to which all updates are applied, and then writes out
the "de-normalised" subscriber records to a geographically-dispersed LDAP
cluster. I was speaking to one of the technical leads in charge of that
area (since I am the architect for Identity and Access Management) and he
believed that this two-phase approach was operationally simpler and more
robust, not more complex!

Personally, I'm gratified that my proposal has been taken seriously and
evaluated on its merits, so here's a heartfelt "thank you" from me to all
of you who have taken the time to examine it. I believe this approach of
being able to address individual elements of a multi-valued attribute has
application even beyond SCIM, so I will be pursuing it as a generic set of
patterns ("resource" defined as a Nested Dictionary, "NDAP directory" as a
resource datastore, "NDAP" as a RESTful API with well-defined
sub-operations, etc.) Who knows, some day that set of patterns may be
re-applied to user provisioning because "that's how it's done elsewhere"
:-).

Thanks and regards,
Ganesh

On 17 August 2012 05:23, <[email-masked]> 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
>         [email-masked]
>
> 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
>         [email-masked]
>
> You can reach the person managing the list at
>         [email-masked]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of scim digest..."
>
> Today's Topics:
>
>    1. Re: scim Digest, Vol 8, Issue 24 (Chris Phillips)
>
>
> ---------- Forwarded message ----------
> From: Chris Phillips <[email-masked]>
> To: "[email-masked]" <[email-masked]>
> Cc:
> Date: Thu, 16 Aug 2012 15:23:29 -0400
> Subject: Re: [scim] scim Digest, Vol 8, Issue 24
> +1 to Phil's comments.
>
> As well, adding a ghost directory to [de|en]code things is just too much
> overhead to build into the protocol.  If someone wants to build that on TOP
> of SCIM, that's up to them.
>
> While I appreciate the thought and time Ganesh has put into the concepts,
> I am not convinced the approach would be net better and less complex and so
> do not support it and welcome moving on to other topics.
>
> C.
>
> From: Phil Hunt <[email-masked]>
> Date: Thursday, 16 August, 2012 1:42 PM
> To: Kelly Grizzle <[email-masked]>
> Cc: Emmanuel Dreux <[email-masked]>, Anthony Nadalin <
> [email-masked]>, Ganesh and Sashi Prasad <[email-masked]>,
> Melinda Shore <[email-masked]>, "[email-masked]" <[email-masked]>
> Subject: Re: [scim] scim Digest, Vol 8, Issue 24
>
> I do think we need to arrive at some consensus on this now because
> Ganesh's proposal is a major "fork-in-the-road" decision. If we table it,
> it will be hard to come back to. This is why I have engaged on the subject
> with Ganesh so thoroughly.  Never-the-less, I would like to arrive at some
> conclusions here.
>
> My apologies, but I thought it was worth re-stating the problem for those
> late to the discussion would be useful.
>
> Background:
> At present, the current spec does not allow you to change a specific
> sub-attribute in a multi-valued complex attribute structure (e.g. changing
> street name in a specific address value instance such as "home").  The
> proposal is that each sub attribute in a multi-valued structure gets its
> own unique identifier.  Then you can directly reference the specific
> complex attribute component in a complex value.
>
> The current draft proposal requires that complex-value (e.g. an address
> value which is made up of number, street, city, etc) be changed if you want
> to change any of the sub-attributes. The current approach seems a
> reasonable compromise since it is likely the collection of attributes in a
> complex "value" are often manipulated together. IOW. You tend to set them
> all at once.  Ganesh's proposal allows specific sub-attributes to be
> directly addressable by giving each value instance a unique identifier.
>
> Another example of this is the group "member" attribute.  In the current
> draft, a member can have a value and a display name. In this case you would
> usually change the value (object identifier) and the name as well.
>  Ganesh's proposal would allow "Display Name" to be changed or value to be
> changed.  Something, IMV, that doesn't occur nearly as often.  IOW members
> change group membership, but members rarely change names.
>
> My conclusion:
> If the client must first query (or have synchronized the value
> identifiers), then the client has to do even more work than the current
> proposal of replacing the enter complex value.  Given such a choice I'm
> really skeptical that the pattern proposed by Ganesh would be widely used.
>  While Ganesh's proposal may be "specific", the practical simplicity of it
> is very much debatable.
>
> The benefit of specific sub-attribute identifiers needs to be substantial.
>  We're not only talking about changing how infrastructure is done, but also
> how applications are written. This leaves out the entire current adopters
> and all enterprise users.  A big concern we have obviously is we have to
> consider existing infrastructure and data stores and be realistic. I don't
> think the benefit is worth the cost.
>
> I agree with the others that the current draft could be changed to make
> patch operations more clear to the developer (simpler to read). While this
> may not improve logic, it will improve understanding and simplicity. The
> fact that certain operations may require an entire complex attribute value
> to be replaced is a reasonable compromise and should not be changed.
>
> Phil
>
> @independentid
> www.independentid.com
> [email-masked]
>
>
>
>
>
> On 2012-08-16, at 8:59 AM, Kelly Grizzle wrote:
>
> Hi Ganesh … your write-up concedes that this will be difficult to
> implement for an existing service provider.  I’m not sure that I understand
> the compromise.  Are you still suggesting that SCIM move to the
> unique-key-per-element strategy?****
> ** **
> If so, the cost/benefit of this seems way off to me.  You are gaining a
> more elegant API by introducing an additional datastore and requiring
> replication.  I don’t know of any service provider that would make this
> trade-off.  As you said, this is something that future service providers
> can keep in mind, but it is not going to help existing providers.****
> ** **
> --Kelly****
> ** **
> *From:* Ganesh and Sashi Prasad [mailto:[email-masked]<[email-masked]>
> ]
> *Sent:* Thursday, August 16, 2012 5:38 AM
> *To:* Anthony Nadalin
> *Cc:* Kelly Grizzle; Emmanuel Dreux; Melinda Shore; [email-masked]; Phil
> Hunt
> *Subject:* Re: [scim] scim Digest, Vol 8, Issue 24****
> ** **
> Hi all,****
> ** **
> Would this hybrid architecture be a workable compromise? See diagram
> towards the end: http://bit.ly/Rjc39Y****
> ** **
> Regards,****
>
> Ganesh****
> On 15 August 2012 05:54, Anthony Nadalin <[email-masked]> wrote:***
> *
> We should not be constrained by LDAP restrictions, this would not be
> productive.****
>  ****
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of
>  *Ganesh and Sashi Prasad
> *Sent:* Monday, August 13, 2012 2:07 PM
> *To:* Kelly Grizzle
> *Cc:* Emmanuel Dreux; Melinda Shore; [email-masked]; Phil Hunt****
>
> *Subject:* Re: [scim] scim Digest, Vol 8, Issue 24****
>   ****
> Thanks, Kelly. You've been most patient in hearing me out, I must say. I
> couldn't ask for more.****
>  ****
> Replying to Chris Philips's mail:****
> > Given that you have a number of thoughts about what could be changed in
> SCIM,Leif's recommendation to  craft them in an Internet Draft may be a
> better way to convey your thoughts.
>
> I'm coming around to the same conclusion. Do you think such an Internet
> Draft should be about changing SCIM, or should it propose a complementary
> spec for SPs who use a "NoLDAP" data store? I think the underlying problem
> is with LDAP, and unless we change that, these proposals won't fly.****
>  ****
> Regards,****
>
> Ganesh****
> On 14 August 2012 01:54, Kelly Grizzle <[email-masked]>
> wrote:****
> There are really two implementation options for a uid per element – either
> store the uids in the native underlying data store or have some secondary
> data store that maps elements to their uids.  The third option is to hope
> that a service provider has a NoLDAP data store or its equivalent.  None of
> these are practical for rapid and wide-spread adoption.****
>  ****
> > put the two together to propose a solution.****
>  ****
> As I said before, I am completely on board with cleaning up the PATCH
> semantics (eg – the inconsistency between meta.attributes and
> operation=delete, etc…).  Your suggestion of using different verbs is a
> good option to consider.  This cannot be based on a uid per element,
> though.  It seems as though you have admitted this in your conclusion – “As
> for LDAP and SCIM, I guess the best TLA is RIP.”****
>  ****
> --Kelly****
>  ****
>  *From:* Ganesh and Sashi Prasad [mailto:[email-masked]]
> *Sent:* Monday, August 13, 2012 9:56 AM
> *To:* Kelly Grizzle
> *Cc:* Phil Hunt; Melinda Shore; Emmanuel Dreux; [email-masked]****
>
> *Subject:* Re: [scim] scim Digest, Vol 8, Issue 24****
>   ****
> That was one suggestion. Another way could be container nodes with their
> own "dn"s. If one suggestion won't work, tell me another way to make it
> work. I'm waiting to hear a constructive suggestion that can square an
> elegant API with the implementation constraints that come from having to
> store multi-valued attributes in LDAP directories.****
>  ****
> I've heard enough of WHY this won't work. For a change, tell me HOW it can
> be made to work. Everyone now knows what the proposal means in terms of the
> API, and implementors understand the constraints of legacy data stores, so
> put the two together to propose a solution. C'mon, we have the "smartest
> guys in the room" here, surely we should be able to crack this.****
>  ****
> Regards,****
> Ganesh****
>  ****
> P.S. I'm rapidly reaching my own conclusions about what is to be done:****
>
> http://wisdomofganesh.blogspot.com.au/2012/08/after-nosql-its-time-for-noldap.html
>  ****
>
>  ****
> On 14 August 2012 00:27, Kelly Grizzle <[email-masked]>
> wrote:****
>  > After all, no one has challenged the claim that this proposal
> drastically simplifies the API for the client****
>  ****
> I agree that your proposal makes PATCH semantics simpler and more elegant.
> ****
>  ****
>  ****
> > … so it would appear to be worth doing. ****
>  ****
> I strongly disagree here.  This statements assumes that simplicity of the
> client API is the only factor that should be considered with the spec.****
>  ****
> Emmanuel’s example is from a real-world service provider that would not be
> able to implement the spec easily with a uid per element.  He is working on
> a SCIM interface that will help facilitate data exchange between multiple
> Active Directory servers.  Your solution was to change the data model from
> this:****
>  ****
>
> mail: [email-masked], [email-masked], [email-masked]****
>
>  ****
> to this:****
>  ****
> mail: aa66-daf9ea3bd902=[email-masked],9cda-8646c3085bbf=
> [email-masked], 7a6d1de664e1=[email-masked]****
>  ****
> I do not know of a single organization that would change their Active
> Directory data model to fit this.  For one thing, it would be a huge data
> migration effort (likely across other domain controllers, etc…) to assign
> these unique identifiers.  This also assumes that SCIM is the only
> reader/writer of this data, which will almost never be the case.  If the
> data model requires uids for every element, then every piece of non-SCIM
> code that writes data into the directory will have to follow this.
> Additionally, there are **many** tools and applications  (eg – address
> books) that rely on a certain data model in Active Directory, and this
> would cause them to break.  IMO this same argument holds true for most
> service providers.****
>  ****
>  ****
> PATCH is an optional part of the spec.  It was primarily introduced to
> make modifying resources with large multi-valued lists more efficient.  It
> does not need to solve every problem (eg – modifying sub-elements in nested
> arrays).  Adding uids to every multi-valued element does not strike the
> right balance between the needs of the client and the needs of the service
> provider.****
>  ****
> --Kelly****
>  ****
>  *From:* Ganesh and Sashi Prasad [mailto:[email-masked]]
> *Sent:* Monday, August 13, 2012 1:35 AM
> *To:* Phil Hunt; Melinda Shore
> *Cc:* Emmanuel Dreux; Kelly Grizzle; [email-masked]****
>
> *Subject:* Re: [scim] scim Digest, Vol 8, Issue 24****
>   ****
> Responding to extract of Melinda Shore's mail from digest:****
>  ****
>
> The issue being raised here isn't endpoint logic, but****
>
> network traffic, and I'm pretty sure it's not very helpful to****
>
> respond to the observation that your model requires more****
>
>
> messages with a complaint about what you seem to think is a****
>
> complex algorithm for attribute processing.****
>
>   ****
> It depends on how it's implemented. I'm confident we can have the best of
> both - simple API with low-overhead implementation. Can we brainstorm HOW
> this proposal can be implemented rather than WHY it can't be implemented
> (which is mostly what I've been hearing so far)? After all, no one has
> challenged the claim that this proposal drastically simplifies the API for
> the client, so it would appear to be worth doing. I'm sure there's more
> than enough intellectual horsepower in this working group to pull this off
> if we put our minds to it.****
>  ****
> Regards,****
> Ganesh****
>  ****
> On 13 August 2012 13:54, Ganesh and Sashi Prasad <[email-masked]>
> wrote:****
>
> > I strongly object to anything that leads to a read before modify
> requirement. Too complex and too chatty.****
> Sorry Phil, but you're contradicting yourself here. There seems to be an
> awful lot of matching (i.e., reading) going on in the spec as it stands,
> with if-then clauses to do one thing or another if the match either
> succeeds or fails. This is a complex, chatty protocol right now!****
>  ****
>
>    Multi-valued attributes:  An attribute value in the PATCH request****
>
>       body is added to the value collection if the value does not exist****
>
>       and merged if a matching value is present.  Values are matched by****
>
>       comparing the value Sub-Attribute from the PATCH request body to****
>
>       the value Sub-Attribute of the Resource.  Attributes that do not****
>
>       have a value Sub-Attribute; e.g., addresses, or do not have unique****
>
>       value Sub-Attributes cannot be matched and must instead be deleted****
>
>       then added.  Specific values can be removed from a Resource by****
>
>       adding an "operation" Sub-Attribute with the value "delete" to the****
>
>       attribute in the PATCH request body.  As with adding/updating****
>
>       attribute value collections, the value to delete is determined by****
>
>       comparing the value Sub-Attribute from the PATCH request body to****
>
>       the value Sub-Attribute of the Resource.  Attributes that do not****
>
>       have a value Sub-Attribute or that have a non-unique value Sub-****
>
>       Attribute are matched by comparing all Sub-Attribute values from****
>
>       the PATCH request body to the Sub-Attribute values of the****
>
>       Resource.  A delete operation is ignored if the attribute's name****
>
>       is in the meta.attributes list.  If the requested value to delete****
>
>       does not match a unique value on the Resource the server MAY****
>
>       return a HTTP 400 error.****
>
>   ****
> For a spec that is supposed to be about simplicity, the above description
> is anything but simple. I know you guys have worked hard on this and I
> don't mean to disparage those efforts, but think about how the above
> passage would appear to a new reader (i.e., a novice to the spec, not a
> technology novice).****
>  ****
> There is something fundamentally broken, and it is this: multi-valued
> attributes without a unique identifier per value. If you don't fix that,
> you won't get simplicity.****
>  ****
> We know LDAP trees are broken for multi-valued attributes. As Mark Wahl famously
> commented <http://www.ldap.com/1/commentary/wahl/20050617_01.shtml> back
> in 2005,****
>  ****
> "Unfortunately, some of the emerging protocols which also intend to
> represent and transfer personal identity information have perhaps taken a
> step backwards by not even considering these issues, perhaps sweeping them
> under the rug in the guise of simplicity, XMLification, or "fix in the next
> version", which only postpone finding interoperable solutions to allowing
> applications to express the identity entries they want to express."****
>  ****
> SCIM is exactly one of these "emerging protocols" Wahl talks about, and
> what I see now strikes me as "sweeping these issues under the rug in the
> guise of simplicity". Apologies for the bluntness.****
>   ****
> My take is that SPs are _already_ struggling to manage multi-valued
> attributes, and existing mechanisms are clumsy<http://ff1959.wordpress.com/2011/07/28/replace-a-value-of-a-multi-valued-attribute/>.
> They would be grateful for a specification that made operations easier at
> the cost of a re-engineered schema. That calls for some thought leadership
> from this working group.****
>   ****
> Regards,****
> Ganesh****
>
>  ****
> On 13 August 2012 10:13, Phil Hunt <[email-masked]> wrote:****
> I strongly object to anything that leads to a read before modify
> requirement. Too complex and too chatty.
>
> Phil****
>
>
> On 2012-08-12, at 15:29, Ganesh and Sashi Prasad <[email-masked]>
> wrote:****
>
> > Would it have to be stored on the account database of the service
> provider?****
>  ****
> Yes.****
>  ****
> > If so, I believe that this is impracticable in the core schema. Indeed
> it implies that a service provider must extend the schema of his account
> repository (LDAP partition, SQL db, …) and “prepare it” for SCIM
> integration.****
>   ****
> Why? That doesn't necessarily follow. Implementation is independent of
> representation. We're talking about a change in representation to make the
> API cleaner.****
>  ****
> As a simple example, if an LDAP node is being used to hold a list of
> comma-separated email addresses, it can just as easily store
> comma-separated name-value pairs.****
>  ****
>
> mail: [email-masked], [email-masked], [email-masked]****
>
> can be changed to****
>   ****
> mail: aa66-daf9ea3bd902=[email-masked],9cda-8646c3085bbf=
> [email-masked], 7a6d1de664e1=[email-masked]****
>  ****
> That's why I asked if there was an SP representative on this working group
> who could explain what such a change could mean for them. As of now, it
> looks like other people are presuming that SPs will not be able to
> implement these changes easily and are rejecting them for that reason.****
>  ****
> Regards,****
> Ganesh****
>   ****
> On 13 August 2012 04:29, Emmanuel Dreux <[email-masked]> wrote:****
>
> ð  addresses.3cbaaff8e84e.street-number = "243"****
>  ****
> Where would 3cbaaff8e84e come from? Would it have to be stored on the
> account database of the service provider?****
>  ****
> If so, I believe that this is impracticable in the core schema. Indeed it
> implies that a service provider must extend the schema of his account
> repository (LDAP partition, SQL db, …) and “prepare it” for SCIM
> integration.****
> This would be a show stopper. SCIM must be transparent, and must be able
> to be put on top of an existing system to provide provisioning apis.****
>  ****
> Said differently, SCIM must not be intrusive for existing systems and must
> not require modifications to allow its integration.****
> Correct me if I misunderstood your suggestion.****
>  ****
> --****
> Regards,****
> Emmanuel Dreux****
> http://www.cloudiway.com****
> Tel: +33 4 26 78 17 58 <%2B33%204%2026%2078%2017%2058>****
> Mobile: +33 6 47 81 26 70 <%2B33%206%2047%2081%2026%2070>****
> skype: Emmanuel.Dreux****
>  ****
>  *De :* Ganesh and Sashi Prasad [mailto:[email-masked]]
> *Envoyé :* dimanche 12 août 2012 04:53
> *À :* Kelly Grizzle
> *Cc :* [email-masked]; Phil Hunt
> *Objet :* Re: [scim] scim Digest, Vol 8, Issue 24****
>  ****
> >  Multi-valued attributes that don't have a value sub-attribute (eg -
> address) have to specified completely for uniqueness.  ****
>  ****
> That's exactly the point. How do we "specify completely for uniqueness"?**
> **
>  ****
> In the example below, how are you proposing that the following element be
> updated if we can't use positional indexes?****
>  ****
> addresses[1].street-number = "243"****
>  ****
> User object:****
>  ****
> {****
>   ...****
>   addresses: [****
>     {****
>       "type" : "home",****
>       "street-number" : "35",****
>       "street-name" : "High Road",****
>       "suburb" : "East Camden",****
>       "postcode" : "5346",****
>       "state" : "SA",****
>       "country" : "Australia"****
>     },****
>     {****
>       "type" : "office",****
>       "street-number" : "213",****
>       "street-name" : "Main Street",****
>       "suburb" : "Adelaide",****
>       "postcode" : "5000",****
>       "state" : "SA",****
>       "country" : "Australia"****
>     }****
>   ]****
> }****
>  ****
> It's impractical to use the value because it's the whole dictionary
> element:****
>  ****
> {****
>   "type" : "office",****
>   "street-number" : "213",****
>   "street-name" : "Main Street",****
>   "suburb" : "Adelaide",****
>   "postcode" : "5000",****
>   "state" : "SA",****
>   "country" : "Australia"****
> }****
>  ****
> With my proposal, the "addresses" array gets converted to a dictionary,
> and then we have a stable way of referencing this element:****
>  ****
> addresses.3cbaaff8e84e.street-number = "243"****
>  ****
> {****
>   ...****
>   addresses: {****
>     "d6ea365462f5" :****
>     {****
>       "type" : "home",****
>       "street-number" : "35",****
>       "street-name" : "High Road",****
>       "suburb" : "East Camden",****
>       "postcode" : "5346",****
>       "state" : "SA",****
>       "country" : "Australia"****
>     },****
>     "3cbaaff8e84e" :****
>     {****
>       "type" : "office",****
>       "street-number" : "213",****
>       "street-name" : "Main Street",****
>       "suburb" : "Adelaide",****
>       "postcode" : "5000",****
>       "state" : "SA",****
>       "country" : "Australia"****
>     }****
>   }****
> }****
>  ****
> If you're proposing one mechanism for composite attributes and another
> mechanism for simple attributes, I would suggest that's actually more
> complex than adopting a single mechanism that works the same way for _all_
> attributes. Remember that a lot of the administration is probably going to
> be scripted rather than done by hand, and having two mechanisms (depending
> on whether the attribute is simple or composite) will complicate every
> script that has to be written.****
>  ****
> There's a lot of talk about the "burden" on the SPs, but I believe this is
> overblown. Is there any SP representative in this WG who can tell us what
> this proposal will actually entail for them?****
>  ****
> Regards,****
> Ganesh****
>  ****
> On 12 August 2012 11:53, Kelly Grizzle <[email-masked]>
> wrote:****
> Ganesh,****
>  ****
> This is exactly how PATCH works in SCIM 1.0.  Multi-valued attributes that
> have a value sub-attribute can be removed by specifying only the value
> since it is unique.  Multi-valued attributes that don't have a value
> sub-attribute (eg - address) have to specified completely for uniqueness.
>  As I have said before, I am very opposed to adding a unique identifier to
> each element in a multi-valued collection due to the burden it will put on
> SPs.  Is it elegant?  No.  Is it functional?  Yes.  Will this non-elegance
> affect adoption?  My opinion is that adding unique keys to each element
> will have a much more detrimental effect on adoption.****
>  ****
> I do believe that in general PATCH can be made more intuitive without
> adding uids to each element.  The verbs that you propose make sense.  There
> is also a JSON Patch informational draft in the IETF that is interesting -
> http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-02.  It relies
> on a JSON Pointer draft which uses index-based addressing for multi-valued
> attributes.  I think that this is something that should be looked at within
> the WG and I would be willing to lead this effort.****
>  ****
> I'm curious if anyone else in the WG is in favor of unique identifiers for
> every multi-valued element.****
>  ****
> --Kelly****
>  ****
> ------------------------------
>
> *From:* [email-masked] [[email-masked]] on behalf of Ganesh
> and Sashi Prasad [[email-masked]]
> *Sent:* Saturday, August 11, 2012 10:50 AM
> *To:* Phil Hunt
> *Cc:* [email-masked]
> *Subject:* Re: [scim] scim Digest, Vol 8, Issue 24****
> Phil,****
>  ****
> The reason we cannot use the value itself to identify an element is that
> this method will only work for simple elements, not for nested structures.
> i.e., if we had an array of dictionaries (e.g., we had to record an array
> of addresses for each customer, with each address element having
> sub-elements like street number, street name, suburb, etc.), then it would
> be clumsy to supply the entire value of the array element because it's
> itself a dictionary. Creating a unique key for each element scales better.
> ****
>  ****
> Regards,****
>
> Ganesh****
> On 12 August 2012 01:12, Phil Hunt <[email-masked]> wrote:****
> Ganesh,****
>  ****
> Here's the sample that concerned me...****
>
> The two operations differ significantly, and it's not very intuitive. ****
> With my suggestion, here's how to delete a single member from a group:****
>  ****
> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept:
> application/json Authorization: Bearer h480djs93hd8 ETag:
> W/"a330bc54f0671c9" {****
> "operations" : [****
> {****
> "RETIRE" : {****
> "key" : "members.2819c223-7f76-453a-919d-413861904646"****
> }****
> }****
> ] }****
>
>  ****
>  ****
> You gave other examples of an attribute with an identifier that matched
> that value or of identifiers that were additional unique keys.****
>  ****
>
>
> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim
>
>

---

From: Melinda Shore <[email-masked]>
Date: Thu, 16 Aug 2012 13:23:54 -0800

On 8/16/12 1:19 PM, Ganesh and Sashi Prasad wrote:
> million subscribers) adopts the approach of using a relational database
> as the "source of truth" to which all updates are applied, and then
> writes out the "de-normalised" subscriber records to a
> geographically-dispersed LDAP cluster. I was speaking to one of the
> technical leads in charge of that area (since I am the architect for
> Identity and Access Management) and he believed that this two-phase
> approach was operationally simpler and more robust, not more complex!

We did something similar at a previous employer.  I think the
answer to that sort of thing is that what you know is always
simpler than what you don't know.  Be that as it may, I think
the issue here is the impact of your proposal on the data structures,
not processes.

Melinda