[Date Prev][Date Next] [Chronological] [Thread] [Top]

Standards and APIs (C LDAP API: security considerations)

We disgress, so I changed the subject line...

At 02:17 17.11.99 -0800, Paul Leach (Exchange) wrote:


> -----Original Message-----
> From: Harald Tveit Alvestrand [<mailto:Harald@Alvestrand.no>mailto:Harald@Alvestrand.no]
> Sent: Wednesday, November 17, 1999 5:23 AM

>
> <SPAN MODE="IETF Policy">
> IMNSHO, this is exactly the wrong thing to have happen in the
> *standard*
> LDAP API. Policy engines cannot be standardized at the
> present stage of our
> ignorance; a standard API should (IMNSHO) be no more than a means of
> creating protocol elements on the wire and state in the state
> machines on
> each end.
>
> It is then up to the vendor (hi vendor!) to provide extended
> APIs that
> build upon the standard LDAP API to encapsulate policy
> decisions by the
> site admin.
> But this functionality SHOULD NOT be standardized and MUST
> NOT be mandatory.
> </SPAN>

I respectfully submit that this is not why most people want a standardized API. What you propose means that the LDAP API becomes an interface for vendors to use to build the _actual_ API layer that applications call. That layer would not be a standard. What people want is a standard API for applications to use, not vendors. 

One man's application is another man's vendor.

The classical reason for standard APIs is so that you can have one application running on multiple platforms, or multiple OS versions, and have the results of that application be the same.

If you create a situation where the PDUs being put on the wire are different (for example having different authentication data) from the *same* application written on 2 different platforms to the *same* API, and this is not visible to the application, I would claim that you don't have interoperability at the API level.

I do not believe that it is necessary to have a standardized policy engine to say that an API is supposed to enforce policy (whatever it is). That's different than saying the API must enforce some particular policy.

I do not believe that it is possible for the IETF to have a standard that says "this is the API, this is the protocol - in between them something may happen that causes behaviour to vary, sometimes rendering applications noninteroperable, but how this happens is outside the scope of the standard".

This line of reasoning is (I think) what led to the original policy of all APIs being Informational rather than standards-track.

BTW, the term "API is supposed to enforce policy" seems strange to me - I think you mean "the implementation of an API is supposed to enforce policy"?
I disagree with both statements, but the second one is clearer :-)

                            Harald A

--
Harald Tveit Alvestrand, Maxware, Norway
Harald.Alvestrand@maxware.no