Subject: LAST CALL: draft-ietf-ldapext-ldap-c-api-04.txt

From: "Tim Howes" <[email-masked]>
Date: Mon, 18 Oct 1999 20:00:23 -0700

The purpose of this message is to initiate an LDAPEXT
working group last call on the LDAPv3 C API specification.
This document has been through last call before, and some
substantive issues were raised. This version addresses
those issues. Changes made since revision -03 are summarized
in appendix F.

WHAT DOCUMENT?

The LDAPv3 C API document in last call is:

        draft-ietf-ldapext-ldap-c-api-04.txt

WHAT IS A LAST CALL FOR?

The purpose of the working group last call is to ensure
that the working group has reached consensus on the
document, believes that all the known outstanding issues
have been addressed, and is ready to put the document
forward for proposed standard status.

During the last call, any comments on the documents are
collected and discussed on the mailing list.

HOW LONG DOES IT LAST?

The last call starts today and will last approximately two
weeks. It will end on Monday, November 1, 1999.

WHAT'S THE NEXT STEP?

After the last call completes, there are three possible
outcomes:

1) No changes are required and we request our ADs to put
forward the documents to the IESG for proposed standard
status.

2) Minor changes agreed to on the list are required, and
the documents are revised. We then ask our ADs to put
forward the revised documents to the IESG for proposed
standard status.

3) Major issues are raised and no consensus is reached on
the list. In this case, we slink back and discuss things
until consensus is reached, at which time another working
group last call will be issued.

Assuming we achieve outcome 1) or 2), and that the ADs
agree with our assessment, the next stop for the documents
is with the IESG. The IESG reads them and may approve the
documents (with or without changes), or send the documents
back to the working group to have major issues addressed.

If the first outcome happens, the documents are put forward
for a two-week last call to the entire IETF, and after
successful completion the documents are published as RFCs
with proposed standard status.

If the second outcome happens, we go back and address
the issues, putting the documents forward again when we
believe they're ready.

WHAT SHOULD I DO?

You should read the documents, making sure that 1) there
are no problems or deficiencies or outstanding issues that
need to be resolved; and 2) that there are no typos,
formatting problems, grammatical errors, etc.

Any substantive problems you find, you should send to the
list. Any minor problems (typos, etc.) you may send to the
list or just to the authors. If, for some reason, you have
comments you don't want to send to the entire list, you may
send them to me or my co-chair Mark Wahl.

Read, enjoy, and send your comments in!
            -- Tim

__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sun, 31 Oct 1999 18:20:48 -0800

The C LDAP API, in my opinion, does not provide sufficient error
information to warrant adoption as a standard and hence should
not be progressed as a standard track document.

The draft, itself, hints at the problem:

draft-ietf-ldap-c-api-04, 17:
	Note that the functions defined in this section all provide a
	method for determining success or failure but generally do not
	provide access to specific error codes.  Therefore, applications
	that require precise error information when encoding or decoding
	ASN.1 values SHOULD NOT use these functions."

The fact that the numerous routines throughout the draft also
suffer from similar problems, one could argue that the above
statement should be extended:

	Note that the functions defined by this document may not
	provide a method for determining success or failure nor
	provide a method for determining the nature of the failure.
	Therefore, applications that require precise error
	information SHOULD NOT use these functions.

I also believe it inappropriate for a standard track API to rely
upon "operating system error reporting" or other implementation
specific reporting mechanisms.

Kurt