Re: LAST CALL: Java API Docs

["Kurt D. Zeilenga" <kurt@boolean.net>]

It is not clear to me whether the Java API documents are targeted
as "Informational" or "Standard Track".  The statement "It
complements but does not replace RFC 1823" leads me to believe
that it's to targeted as informational (as RFC 1823 is informational).

I've reviewed the charter, and it says:
  "The deliverable from this work item [APIs] will be documents
  updating RFC 1823 for LDAPv3, documents defining API extensions
  to support protocol extensions, and a document defining a similar
  API for Java."

Since RFC 1823 is informational and we're updating it for LDAPv3,
my assumption is that result would be itself be informational (unless
explicitly stated otherwise).  A similar API for Java would also be
informational.

I believe the intended category of these documents should be
clarified such that they may be reviewed appropriately for their
intended category.

Regards, Kurt


At 11:59 AM 11/4/99 -0800, Tim Howes wrote:
>The purpose of this message is to initiate an LDAPEXT
>working group last call on the LDAPv3 Java API specification.
>These documents have been through last call before, and some
>substantive issues were raised. This version addresses
>those issues. Changes made since the previous version are
>summarized in appendix B of each document.
>
>WHAT DOCUMENT?
>
>The LDAPv3 Java API documents in last call are:
>
>      draft-ietf-ldapext-ldap-java-api-08.txt
>	draft-ietf-ldapext-ldap-java-api-asynch-ext-03.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 Thursday, November 18, 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
>
>

----
Kurt D. Zeilenga		<kurt@boolean.net>
Net Boolean Incorporated	<http://www.boolean.net/>