RE: Tw bobs worth on TOP, LDAP standards process and subschemasub entry attribute usage in rootDSE

[Andrew Probert <AndrewP@rotek.com.au>]

I agree with Alan that one cannot re-define the most fundamental of objects
in an object-oriented system and have it continue to work.

There are formal ways to extend these objects, they are 1)  Structural
Classes that inherit TOP and extend it as neccesary 
and 2) Auxilliary Classes that dynamically extend an existing Structural
Class at the time an object is added.

To date, it appears that it is only Microsoft that is non-conformant.  A
clear message needs to be sent about this.

I think *some* people are emotively defending the right for IETF to diverge
from ISO/ITU, rather than objectively looking at the facts, the problem, and
the ramifications.

I request that it is put to a *VOTE*, that the TOP used in LDAP conforms to
the ISO/ITU definition of TOP.  


Andew Probert
Rotek Consulting   http://www.rotek.com.au
a Division of Secure Network Solutions
Tel  +61 3 9690 8877
Fax +61 3 9690 8171



> -----Original Message-----
> From:	Mark Wahl [SMTP:M.Wahl@INNOSOFT.COM]
> Sent:	Tuesday, July 06, 1999 9:26 AM
> To:	Alan Lloyd
> Cc:	'ietf-ldapext@netscape.com '
> Subject:	Re: Tw bobs worth on TOP, LDAP standards process and
> subschemasub entry attribute usage in rootDSE
> 
> 
> I wish to address your concern that that there is a problem with the LDAP 
> standards process because a few implementors have not followed the
> IETF/ISO 
> standards and ITU-T recommendations regarding 'top'.
> 
> It appears to me that there are vendors who have been unaware or
> uninterested 
> in the X.500 features available through LDAP that would enable them to
> address 
> their customer base requirements without modifying 'top'.  Their changes 
> have shown up as bugs in inter-vendor interoperability testing, and the
> vendor 
> responses have tended to be of the following:
> 
>  - acknowledged the problem and fixed in a subsequent release
> 
>  - acknowledged the problem but not yet fixed it
> 
>  - there is no problem as inter-vendor interoperability is not of interest
> to 
>    their customer base
> 
> While this is unfortunate in individual cases for those deploying 
> implementations which do not interoperate, I view this as a natural effect
> of
> the open-to-any-implementor standards process as practiced by the IETF.
> 
> Background on the IETF standards process
> 
> The standardization of LDAP has followed and continues to follow the
> guidelines
> for any IETF standard.
> 
> The goal of the IETF standards process in a specification that is
> "...stable and well-understood, is technically competent, has multiple,
> independent, and interoperable implementations with substantial
> operational
> experience, enjoys significant public support, and is recognizably useful
> in some or all parts of the Internet." (RFC 2026 section 1.1)
> 
> The requirements statements in RFC 2251-2256 are based on RFC 2119, and
> implementations which follow the specifications are expected to
> interoperate.
> 
> The Draft Standard level, to which LDAPv3 RFCs 2251-2256 would next
> progress,
> has the requirement that "two independent and interoperable
> implementations 
> from different code bases have been developed, and for which sufficient 
> operational experience has been obtained" (RFC 2026 section 4.1.2). This 
> applies to all aspects of the RFCs, including schema and the information
> model.
> 
> These requirements are there because implementations of the Proposed
> Standard 
> may have bugs that show up in testing with another implementation, or 
> clarifications to the specifications may be necessary to achieve 
> interoperability.
> 
> I believe that it will be possible to show that there have been two
> independent
> implementations with operational experience which both implement LDAPv3 
> correctly, including the 'top' object class.  Furthermore, I believe that
> a 
> significant majority of the implementations correctly implement the 'top' 
> object class.  This will be shown in a document from Tim Howes and I when
> these
> RFCs are ready to go to Draft Standard level, as described in the third 
> paragraph of RFC 2026 4.1.2.  
> 
> Please note that these requirements are based on selecting independent 
> implementations for which there has been suffficent operational
> experience.
> 
> It does not require that every pair of implementations have been tested
> and 
> shown to interoperate, nor does it require that the implementation with
> the
> largest number of operational deployed sites be shown to interoperate with
> the second largest, so long as there are other interoperable
> implementations 
> with sufficient operational expereince.
> 
> Historical outcome of the IETF standards process
> 
> Overall, the IETF standards process has resulted in a series of protocol
> specs
> that for the most part products which follow are able to interoperate.
> 
> However, this world has not been perfect.  Most modern and widely-deployed
> 
> implementations of TCP/IP and popular application-layer protocols include 
> at last one workaround for a problem with some specific vendor
> implementation.
> Perhaps an early version of that vendor's product is still in wide use, or
> new versions of the vendor's product continues to be noncompliant. In some
> cases the most widely deployed implementation may be noncompliant.  
> 
> Over time, it has been the case that major deployed implementations of
> TCP, HTTP
> SMTP or MIME have had serious interoperability problems.  Many of the
> other 
> implementors of these protocols have had to put in 'hacks' in their code
> to 
> deal with noncompliant products sending them illegal data or not being
> able to
> handle legal data.  The same problem also has applied to ITU-T
> recommendations 
> and the implementations of them, BTW.
> 
> The IETF standards process does not enforce conformance.  The IETF does
> not 
> operate a branding program, have an enforcement arm, trademark or license
> the 
> elements of protocol.  The IETF does not tend to sue implementors when
> their
> products are nonconformant.  Furthermore, an application protocol such as
> LDAP
> would have either Recommended or Elective status: even FTP or SMTP do not
> have 
> the Required status. 
> 
> Therefore, the same can be anticipated for LDAP as with any other popular 
> standards-track application protocol:
> 
>  - There are many independent implementations.
> 
>  - Most implementations interoperate.
> 
>  - There are implementations which send data to port 389 that is not legal
> LDAP.
> 
>  - There are implementations which listen on port 389 but do not support 
>    certain key LDAP features.
> 
>  - Some of these noncompliant implementations have become widely deployed.
> 
>  - The IETF would be unlikely to 'require' an implementor to fix a
> noncompliant
>    LDAP implementation.
> 
> If there were serious problems where the majority of implementations could
> not
> interoperate, then this is an issue that the document authors should
> address
> by revising the document.   However, I have not seen this occur in LDAPv3.
> 
> There are alternatives to the IETF standards process, of course.  The 
> University of Michigan could have chosen to 'license' the LDAP
> specfication to
> other implementors and require them to pass a conformance test before
> shipping.
> Some vendors attempt to patent their server design or protocol extensions.
> 
> As a result, there would be a legal means to enforce conformance to a
> protocol 
> specification.  Hoewver, it would be significantly less likely to be
> permitted 
> to result in an Internet Standard. First, RFC 2026 10.3.2 (C) requires the
> 
> assurance that when it becomes a Proposed Standard, "...any party will be
> able 
> to obtain the right to implement, use and distribute the technology or
> works
> when implementing, using or distributing technology based upon the
> specific 
> specification(s) under openly specified, reasonable, non-discriminatory
> terms."
> Second, the IETF would be more likely to choose a technology for
> standardization
> that has fewer IPR encumberances over one with more.  None of the popular
> IETF 
> application layer protocols have a requirement for conformance testing
> before
> an implementation can be shipped.
> 
> There are several ways to work in the IETF standards process to improve
> matters:
> 
>  - review your implementation against the standards-track RFCs and
> reference
>    documents
> 
>  - take your implementation to interoperability tests and publish the 
>    results of testing with your implementation and others
> 
>  - encourage other implementors to follow standards where appopriate: they
>    may be unaware of them
> 
>  - send email to the document editors where clarifications are needed
> 
>  - encourage communities of deployers to evaluate implementations on a 
>    technical basis by reviewing interoperability test results
> 
> Mark Wahl, Directory Product Architect
> Innosoft International, Inc.