Subject: Re: control combination was: Re: protocol-22 comments)

From: "Jim Sermersheim" <[email-masked]>
Date: Mon, 10 May 2004 11:52:38 -0600

>>> "Kurt D. Zeilenga" <[email-masked]> 5/9/04 7:12:32 PM >>>

>Does it matter how it's defined?  It seems to me that all that
>matters is that it is defined. 

I think I'm missing something fundamental here. The semantics of LAP
operations are defined in documents like Internet-Drafts, RFCS, and ITU
recommendations. Up until now, I think people consider semantics not
documented in this way as undefined (even if two implementations
bilaterally agree upon semantics out of band).

For purposes of interoperability, we talk about operation semantics in
terms of definitions found in the above documents. If we are not worried
about operation semantics defined outside the scope of these documents,
then for this type of operation, it seems we're not worried about
interoperability. 

If we're not worried about this kind of interoperability (which is a
valid option), I prefer to use language like "behavior is undefined".
This language has been used in the past and I think is understood by the
reader. Using the term "defined" to allow less than documented in the
above documents I think invites surprises.

Let me know where I'm getting derailed.

Jim

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 10 May 2004 12:24:08 -0700

At 10:52 AM 5/10/2004, Jim Sermersheim wrote:
>I think I'm missing something fundamental here.

I think you are confusing whether semantics have been defined
with whether the defined semantics are known, or could be known,
to an implementation.

>The semantics of LAP

No, they are simply not openly specified semantics.  However, the
semantics are still defined.  Regardless of whether the semantics
are defined openly or in some closed fashion, those semantics may
not be known to a particular implementation.

>For purposes of interoperability,

between whom?

Some extensions are designed for broad adoption, others are not.

>we talk about operation semantics in
>terms of definitions found in the above documents.

For extensions we define, yes.  But we do not preclude others from
designing and implementing private extensions.

>If we are not worried

We need to worry about interoperability of base protocol, of extensions
we define, and of mechanisms used to negotiate and make use of
extensions (whether private or public).

>above documents I think invites surprises.

I think we need to avoid '(un)defined' here and use the term
"(in)appropriate for the operation".  When we say a control is
"appropriate for the operation" we assume that there is some
agreement between the peers in this area.  Interoperability
between the peers doesn't depend on how the agreement was
reached, only in that there is an agreement.

Of course, open standard documents is how we reach agreement
between independently developed implementations.  However, nothing
in LDAP should be viewed as precluding extensions which preclude
(or hinder) independently developed implementation of these
extensions.