I just had another idea. Suppose we created
optional attributes that are only used for create operations and give them a
special name. For instance we could have attributes like:
initialPassword
initialPasswordExpirationDate
initialDisabledState
These be semantically defined to only be
meaningful on create operations. This would allow us a mechanism to create
persons and accounts in a disabled state, while still requiring the capability
specific operations to suspend/restore and set passwords.
I am not suggesting any change to the
specification. Just descriptions in each of the attributes that indicate that
they could optionally be used on create, but would be ignored otherwise.
How does that sound?
From: Gary.P.Cole@Sun.COM [mailto:Gary.P.Cole@Sun.COM]
Sent: Tuesday, May 22, 2007 11:29
AM
To: Kent Spaulding
Cc: PSTC
Subject: [provision] Operational
attributes (was "Re: [provision] Standard Schema draft 4 - big
issues.")
Kent Spaulding wrote:
I have yet to read the latest revision, but I'm chime in anyway.
On 5/6/07 6:08 PM, "Gary.P.Cole" <Gary.P.Cole@Sun.COM> wrote:
1) Should the Schema have operational attributes that duplicate
standard capabilities?
NOTE: Jeff Bohren dislikes this, but operational attributes allow a single
request to do much more than it otherwise could (e.g., create a Person in a
disabled state or create an Account with a pre-expired password).
Perhaps I misunderstand, but I don't generally like data that is 'active'
either... At least for over-the-wire protocols. The idealist says all
side-effects are bad.
Hmmm, maybe I need some clarification... Am I to understand that if I use
'disabled' as an attribute in the schema to represent disabled accounts, and
I do a 'modify' that changes 'disabled' for some account from false to true,
I've just enabled the account. I suppose that's not exactly a side-effect...
And would be what one might expect. Besides, to avoid this, we'd have to
have the notion of read-only (of informational-only) attributes that can't
be set. We'd have to complain (or ignore that attribute) in the modify.
Having said all that, I suppose, since we went to all that trouble to define
all those operations, we should try to avoid confounding them with yet
another mechanism - so count me in Jeff's camp.
We defined capabilities as operations because we could
not agree on schema. If we can agree on attributes such as
"password" and "passwordExpirationDate", then a client can
do much more in a single request.
I gave an example in the draft of creating a Person or an Account in a disabled
state (with a password that is pre-set and pre-expired). Today that would
take four operations, and they are not atomic.
Simply put, there is currently no way to create an object in a disabled state.