I do not think that this definition is one of action but one of
decision. You can decide not to act, or to act.
But I believe that you need to at least push a button in order to act.
Frank
On Aug 17, 2006, at 6:18 AM, Rex Brooks wrote:
> I hope no one is surprised if I quibble with this particular
> definition, which comes close, in my opinion, but fall just short
> of the mark. I take exception with the choice of using the concept
> of force per se, though I do understand and agree with the
> requirement of making "action" transitive. I would apply a small
> bit of mental jiu jitsu on this definition, thus:
>
> Action: the application of 'intent' to achieve an effect by an
> agent on an object.
>
> Thus, the application of "intent" applies equally well to choosing
> to do "nothing" and allow inertia/momentum to achieve an effect, or
> to require action by some other agent to achieve, prevent or allow
> an effect. In the study of heuristics, one of the least well
> explored results is exactly this, the intentional refusal to act
> per se, which, I contend, constitutes a decision, which is, in and
> of itself, an action at a choice-point branching of a decision-tree.
>
> BTW, this answers the last question below: Yes! and full
> responsibility or culpability applies. Needless to say, this is
> utterly critical to security. Choose not to apply a patch in time,
> and you are caught holding the hot potato if bad things happen to
> good systems.
>
> Cheers,
> Rex
>
>
>
> At 7:55 AM -0400 8/17/06, Ken Laskey wrote:
>> Some comments from Frank that didn't get back to the list:
>>
>> Ken:
>> The POA *is* the action as it is applied.
>> If the service is the glove, the POA is the iron fist:)
>>
>> Different people have different definitions of action, (try
>> define:action in google). None of these definitions is all that
>> satisfactory to me.
>> My definition is adapted from John Sowa:
>>
>> Action: the application of force by an agent on an object with the
>> intention of achieving an effect.
>>
>> I.e., its a kind of event. The POA is a characterization of that
>> event. (One reason I like this definition is that is includes all
>> human actions but excludes rocks rolling down the hill hitting
>> other rocks.)
>>
>> The service interface is the characterization of what it means to
>> perform an action. It is not the action itself though.
>>
>> Hope that this throws a little light on the matter.
>> Frank
>>
>> Per Danny's response, I think he caught my question well with the
>> final line of his response below:
>>
>>> One question
>>> we can ask is can we identify a point of action
>>> meaningful to the reference architecture that would
>>> not have a service interface?
>>>
>>
>> Ken
>>
>>
>>
>> On Aug 17, 2006, at 1:55 AM, Danny Thornton wrote:
>>
>>> To draw another analogy for the point of action, I
>>> know your mind will be the point of action for
>>> processing this e-mail as you read the e-mail. The
>>> e-mail address and the english language is like a
>>> service interface.
>>>
>>> The SOA has many points of action, each point of
>>> action potentially affecting many other points of
>>> action. We can identify points of action in a SOA
>>> relevant to the reference architecture. One question
>>> we can ask is can we identify a point of action
>>> meaningful to the reference architecture that would
>>> not have a service interface?
>>>
>>> Danny
>>>
>>>
>>> --- Ken Laskey <<mailto:>> wrote:
>>>
>>>> The following are from my notes at the ftf
>>>>
>>>> Point of Action (poa)
>>>>
>>>> - Frank: anchoring mechanism for numerous
>>>> things, e.g. policy
>>>> enforcement, evaluating needs & capabilities
>>>>
>>>> - Ken: how does poa relate to service
>>>> interface? Frank:
>>>> service interface includes actions you can perform;
>>>> each instance of
>>>> use consists of performing action; actual action is
>>>> poa; interface
>>>> vs. poa is class vs. instance relationship; the
>>>> physical action is
>>>> the point of action
>>>>
>>>> - [Ken] Given a policy is a desire of one
>>>> participant and an
>>>> agreement as part of the execution context for
>>>> participants to abide
>>>> by that policy (i.e. the other participant(s) agree
>>>> to make that
>>>> policy theirs), the policy enforcement point becomes
>>>> the point of
>>>> action for enforcing the agreed-upon policy.
>>>>
>>>> - [Frank alternative] A policy is a constraint
>>>> that represents
>>>> the desire of a participant. A contract is a
>>>> constraint that
>>>> represents the agreed desires of two or more
>>>> participants. A [policy]
>>>> enforcement point is the point of action for
>>>> enforcing constraints
>>>> that represent either policies or contracts.
>>>>
>>>>
>>>> I've reread this and am still having problems
>>>> differentiating between
>>>> service interface and point of action. It appears
>>>> that poa is more
>>>> general because it is the location to which a user
>>>> would send a
>>>> command for action. If the receiver is a service,
>>>> then the poa would
>>>> seem to be the service interface. In the policy
>>>> example, if the
>>>> enforcement mechanism is accessed through a service,
>>>> the PEP could be
>>>> said to have a service interface.
>>>>
>>>> I still seem to be missing something.
>>>>
>>>> Ken
>>>>
>>>> ---
>>>> Ken Laskey
>>>> MITRE Corporation, M/S H305 phone: 703-983-7934
>>>> 7515 Colshire Drive fax:
>>>> 703-983-1379
>>>> McLean VA 22102-7508
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> __________________________________________________
>>> Do You Yahoo!?
>>> Tired of spam? Yahoo! Mail has the best spam protection around
>>> <http://mail.yahoo.com>http://mail.yahoo.com
>>>
>>
>> ---
>> Ken Laskey
>> MITRE Corporation, M/S H305 phone: 703-983-7934
>> 7515 Colshire Drive fax: 703-983-1379
>> McLean VA 22102-7508
>
>
> --
> Rex Brooks
> President, CEO
> Starbourne Communications Design
> GeoAddress: 1361-A Addison
> Berkeley, CA 94702
> Tel: 510-849-2309
