Subject: [scim] metadata and actions

From: Bill Mills <[email-masked]>
Date: Mon, 24 Mar 2014 15:19:32 -0700 (PDT)

"meta" is used to return metadata about entries and in the case of PATCH it's used to specify elements to delete.   I'd like to propose a new "meta" element for action to be taken.  I think this would solve some of the question of triggering actions based on a PATCH.  So for example:

"meta": { "action": ["SuspendUser", "DeleteMailbox"]
}

Specifies 2 actions to be taken along with whatever data changes are applied.

Does this sound workable?

-bill

---

From: "Morteza Ansari (moransar)" <[email-masked]>
Date: Tue, 25 Mar 2014 03:20:39 +0000

Bill,

Can you expand on the problem this would solve?  I know this came up on one of the calls a while ago but I don’t think the problem is clearly captured on the mailing list before.

Cheers,
Morteza

From: Bill Mills <[email-masked]<mailto:[email-masked]>>
Reply-To: Bill Mills <[email-masked]<mailto:[email-masked]>>
Date: Monday, March 24, 2014 at 3:19 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [scim] metadata and actions

"meta": {
    "action": ["SuspendUser", "DeleteMailbox"]

}

-bill

---

From: Bill Mills <[email-masked]>
Date: Mon, 24 Mar 2014 21:17:06 -0700 (PDT)

The problem is that in a PATCH or PUT any action to be taken on the account has to be inferred from the data changes.  This also means that everyone has to share the entire schema for how an acount is managed.

We have a system that looks very much like SCIM (not a suprise since SCIM is standardizing a common task) but we have action verbs with data.  Comparing the two I much prefer the action verb with supporting data model.  In the current SCIM model actions have to be inferred from data changes.

For example we might have a "create_mailbox" verb, where in SCIM I need to compare the current state to the new state and dtermine that "mailbox_active" changed from "0" to "1".   

-bill

On Monday, March 24, 2014 8:20 PM, Morteza Ansari (moransar) <[email-masked]> wrote:
 
Bill,

Cheers,
Morteza

From: Bill Mills <[email-masked]>
Reply-To: Bill Mills <[email-masked]>
Date: Monday, March 24, 2014 at 3:19 PM
To: "[email-masked]" <[email-masked]>
Subject: [scim] metadata and actions

-bill

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

---

From: David Möbius <[email-masked]>
Date: Tue, 25 Mar 2014 07:05:44 +0100

Hello Bill,

I also don't realy understand why you need this action.
For you two examples:

SuspendUser: would be like active = false
DeleteMailbox: The scim user has no mailbox so what should the system
do? For my understanding a mailbox like something could only be a part
of an extension but not of the standard user. So it looks like that the
meta.action would be very client specific.

by David

Am 25.03.2014 05:17, schrieb Bill Mills:
> The problem is that in a PATCH or PUT any action to be taken on the
> account has to be inferred from the data changes.  This also means that
> everyone has to share the entire schema for how an acount is managed.
> 
> We have a system that looks very much like SCIM (not a suprise since
> SCIM is standardizing a common task) but we have action verbs with data.
>  Comparing the two I much prefer the action verb with supporting data
> model.  In the current SCIM model actions have to be inferred from data
> changes.
> 
> For example we might have a "create_mailbox" verb, where in SCIM I need
> to compare the current state to the new state and dtermine that
> "mailbox_active" changed from "0" to "1".   
> 
> -bill
> 
> 
> Can you expand on the problem this would solve?  I know this came up on
> one of the calls a while ago but I don’t think the problem is clearly
> captured on the mailing list before.
> 
> 
> Cheers,
> Morteza
> 
> From: Bill Mills <[email-masked] <mailto:[email-masked]>>
> To: "[email-masked] <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>
> "meta" is used to return metadata about entries and in the case of PATCH
> it's used to specify elements to delete.   I'd like to propose a new
> "meta" element for action to be taken.  I think this would solve some of
> the question of triggering actions based on a PATCH.  So for example:
> 
> "meta": {
> [email-masked] <mailto:[email-masked]>

---

From: Bill Mills <[email-masked]>
Date: Tue, 25 Mar 2014 07:42:39 -0700 (PDT)

What I'm asking for is a defined extension to the "meta" element, not  "mailbox" element.  We'll define our own schema as needed for the things spefici to our provisioning environment.  SCIM is about managing users AND things asociated with them, so a mailbox is a reasonable resource to be managing which is why I chose it as an example.

On Monday, March 24, 2014 11:05 PM, David Möbius <[email-masked]> wrote:
 
Hello Bill,

by David

---

From: David Möbius <[email-masked]>
Date: Tue, 25 Mar 2014 15:49:42 +0100

Yea that is sure but I think the meta attribute should only be for scim
attributes.

I don't know how you implement your code but I think you have your
"mailbox" or what else in some kind of extension. In this case you just
could definde an additional field in your extension where you store the
actions.

David

Am 25.03.2014 15:42, schrieb Bill Mills:
> What I'm asking for is a defined extension to the "meta" element, not
>  "mailbox" element.  We'll define our own schema as needed for the
> things spefici to our provisioning environment.  SCIM is about managing
> users AND things asociated with them, so a mailbox is a reasonable
> resource to be managing which is why I chose it as an example.
> 
> 
>> On Monday, March 24, 2014 8:20 PM, Morteza Ansari (moransar)
>> <[email-masked] <mailto:[email-masked]>> wrote:
>> Bill,
>>
>> From: Bill Mills <[email-masked]
> <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>>
>> Reply-To: Bill Mills <[email-masked]
> <mailto:[email-masked]>
>> <mailto:[email-masked] <mailto:[email-masked]>>>
>> To: "[email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>" <[email-masked] <mailto:[email-masked]>
>> <mailto:[email-masked] <mailto:[email-masked]>>>
>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>

---

From: Bill Mills <[email-masked]>
Date: Tue, 25 Mar 2014 08:54:28 -0700 (PDT)

1) I do not want to explicitly store the transactions, but I may log them in a different field.  A "no-store" mutability value could solve this too.

2) SCIM really needs this concept.  Diffs of data to determine what actions to take is not a great thing.

On Tuesday, March 25, 2014 7:49 AM, David Möbius <[email-masked]> wrote:

David

---

From: Phil Hunt <[email-masked]>
Date: Tue, 25 Mar 2014 20:31:31 -0700

It seems like you are defining high-level "functions" rather than simple stateful changes. 

I agree on the need, but i think many will say this is not RESTful.  

Phil

> On Mar 25, 2014, at 8:54, Bill Mills <[email-masked]> wrote:
>

---

From: Bill Mills <[email-masked]>
Date: Tue, 25 Mar 2014 22:16:48 -0700 (PDT)

I agree, it's not REST-ful perhaps, but I also think REST is an 80% solution.

Does adding a "no-store" mutability variant make a better solution?

On Tuesday, March 25, 2014 8:32 PM, Phil Hunt <[email-masked]> wrote:

Phil

>>> one of the
 calls a while ago but I don’t think the problem is clearly

---

From: Kelly Grizzle <[email-masked]>
Date: Thu, 27 Mar 2014 13:38:08 +0000

I have seen REST APIs add functions in a number of ways (although … technically not all REST-fully).  Here are the few that I have seen listed from most to least common.

1)      POST to a sub-resource to cause an action to occur.  Example:
POST /Users/1234/deleteMailbox

2)      Include an action in the POST to the endpoint (this is your suggestion).  Example:

POST /Users/1234

{

  “meta”: { “action”: “deleteMailbox” }

}

                Similarly, this could be achieved by extending the schema and adding an action attribute.  Example:

                                POST /Users/1234
                                {
 “urn:yahoo”: {
    “action”: “deleteMailbox”,

    … some data that provides parameters for the deleteMailbox command …
  }
}

3)      Include a “command object” in the POST body to the endpoint rather than a representation of the endpoint.  This is similar to what the new PATCH proposal does, but is keyed off of a special HTTP header or the Content-Type header.  Example:

POST /Users/1234

Content-Type: application/yahoo.deleteMailbox+json

{

  … some data that provides parameters for the deleteMailbox command …

}

There are pros and cons to each approach.

The first approach does not allow for deleting a mailbox while updating other attributes on the user.  Also, SCIM doesn’t currently have a good extension mechanism to define this … maybe through a ResourceType but this would be a stretch.

Using meta in the second approach is easier to solve from an extensibility perspective, but we would probably want a way for service providers to return which actions they support (eg – through the ResourceType endpoint).

Using a normal schema extension in the second approach wouldn’t require any changes to the spec.  You would just add an “action” attribute to the extension and set the mutability to writeOnly.  This has the added benefit that any data required by the action (eg – action = “setMailboxSize”, newMailboxSize = 1000000) is defined in the same place.

The last approach is very uncommon and would be the largest change to the spec, so I’ll leave it out.  Functionally, it is very similar to option 1.

SCIM does have a couple of places where it would be nice to have actions.  As you mentioned, changing the inactive flag is not always ideal (although this is probably the correct lowest common denominator across service providers).  Also, changing a password is another thing that we have shoe-horned into an attribute (see ticket 14 for where this has fallen short - http://tools.ietf.org/wg/scim/trac/ticket/14).  The difficult thing with these is that you often need to do them in conjunction with another action – such as setting the password when you create a user.

My opinion is that we should just use extensions to define actions (option 2b).  This provides a good amount of flexibility for mixing in actions with other operation (create and update), and we already have a facility for this through schema extension.  Essentially, this is just moving the action from the meta attribute to an extension.

--Kelly

From: scim [mailto:[email-masked]] On Behalf Of Bill Mills
Sent: Wednesday, March 26, 2014 12:17 AM
To: Phil Hunt
Cc: David Möbius; [email-masked]
Subject: Re: [scim] metadata and actions

On Tuesday, March 25, 2014 8:32 PM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:
It seems like you are defining high-level "functions" rather than simple stateful changes.

Phil

On Mar 25, 2014, at 8:54, Bill Mills <[email-masked]<mailto:[email-masked]>> wrote:
1) I do not want to explicitly store the transactions, but I may log them in a different field.  A "no-store" mutability value could solve this too.

On Tuesday, March 25, 2014 7:49 AM, David Möbius <[email-masked]<mailto:[email-masked]>> wrote:
Yea that is sure but I think the meta attribute should only be for scim
attributes.

David

Am 25.03.2014 15:42, schrieb Bill Mills:
> On Monday, March 24, 2014 11:05 PM, David Möbius <[email-masked]<mailto:[email-masked]>>
> wrote:
> Hello Bill,
>
>> <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>> Bill,
>>
>> From: Bill Mills <[email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>>>>
>> Reply-To: Bill Mills <[email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>>
>> <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>>
>> To: "[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>>>" <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>> <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>>
>> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>>>
>> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>

> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>

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

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

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

---

From: Bill Mills <[email-masked]>
Date: Thu, 27 Mar 2014 07:33:01 -0700 (PDT)

I hadn't thought about WriteOnly that way, it would work fine.

On Thursday, March 27, 2014 6:38 AM, Kelly Grizzle <[email-masked]> wrote:

 

                                POST /Users/1234
                                {
 “urn:yahoo”: {

 

 

 
--Kelly
 
From:scim [mailto:[email-masked]] On Behalf Of Bill Mills
Sent: Wednesday, March 26, 2014 12:17 AM
To: Phil Hunt
Cc: David Möbius; [email-masked]
Subject: Re: [scim] metadata and actions

 

Phil

---

From: Phil Hunt <[email-masked]>
Date: Thu, 27 Mar 2014 08:00:59 -0700

I agree with Kelly. 

The big concern I have with actions is they are often related to context and thus getting agreement on use and defn will be hard. 

One caution about extensions is that provider specific connectors to take advantage of actions will undermine some of our objectives around simplicity. That said, I have had some pressure to support functions. 

I think we should separate the issue of patch/modify from patch/action. Not saying they need to be separate in implementation but I would like to get basic PATCH agreed to first. 

Phil

> On Mar 27, 2014, at 7:33, Bill Mills <[email-masked]> wrote:
>