> -----Original Message-----
> From: Harald Tveit Alvestrand [mailto:Harald@Alvestrand.no]
> Sent: Wednesday, November 17, 1999 8:36 AM
> To: Paul Leach (Exchange); ietf-ldapext@netscape.com
> Subject: Standards and APIs (C LDAP API: security considerations)
>
> >
> >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.
I don't disagree as far as it goes -- I'm just adding "results of that application be the same when the configured policies are 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.
Sure you can -- it just means that there is state under the API that affects the PDU. Such as, which authentication protocols are configured.
>
> >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".
The whole intent of policy to to say, in some cases, "thou shalt not interoperate here". I.e., there is a distinction between "interoperable" -- capable of interoperation -- and actual interoperation in partucular cases. A strict reading of your paragraph above might imply that a connection could never be refused due to an authentication failure.
I don't think that the whole utility or interoperability of a standard API would be destroyed if there were a status code for each function that said "denied by policy settings". Any more than there is by the ones that probably exist already that say "authentication failure" or "access denied".
>
> 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 :-)
Yes. The first one is just less to type.
Paul