> 1. Support for obligations in Rules is relevant even for "genuine"
> obligations, so this change is really orthogonal to the meaning of
> the term obligation.
I agree that there is value in more granular control/response. So long
as we are providing that mechanism in order to actually provide more
granular obligations.
> 2. I don't think it's a good idea to have two different mechanisms,
> one for genuine obligations and one for "informational" obligations.
> The reasons are:
"Informational Obligations" is an oxymoron and as such is an anathema
to standards definition in my opinion. There are Obligations--things
which the PEP is compelled to act upon (read: verb)--and there is
information that may be used in an number of ways (read: adjective).
So I reject the notion that these are similar. True there is
similarity in how they would be handled but as Rich pointed out, we
have much of that in Policies and PolicySets today , yet they remain
discrete.
> a. The mechanism will be the exact same thing at the low technical
> level in the PDP, so it's implementation overhead to have them both.
Since neither is required to be supported it is a decision of the
implementer as to what overhead is appropriate.
> b. As I think Hal said on the previous call, if we have two
> mechanisms, then it's going to be really hard for us to tell people
> when to use which of the two mechanisms because the end result will
> be the same regardless which one is used, and there is going to be a
> huge gray area between what is a genuine obligation and what is an
> informational obligation.
If it is hard to define the use of two discretely defined mechanisms,
then I suggest it is impossible to describe the use of a polymorphic
junk drawer in any way that will be portable.
> So I am strongly opposed two different mechanisms.
>
> 3. The question then is, as you say, should we reconsider the term
> "obligation". For me personally I don't mind the name since it's the
> semantics which matter. Also, if we change it, people will wonder
> what the difference to 2.0 is. It also means a bit more code for
> implementations which support both 2.0 and 3.0, but I suppose that
> this is no big deal.
I think it is very dangerous to take the position that the meaning of
the nomenclature is unimportant. The TC wrestled with the term
Obligations for weeks in an attempt to be precise about what this
instrument is designed for. Relying solely upon semantics will allow
us to solve the problem for a discrete implementation but I fear that
attempting to use this across implementations will require a very
"white box" approach to interoperability.
> And as a side note, I think informational obligations are a special
> case of genuine obligations since the interpretation of the
> obligation is up to the obligation issuer to define, and he could
> say that doing nothing is valid enforcement of the obligation.
Er, lets discuss the propriety of null actions later :)
b
