Subject: RE: LAST CALL: Java API Docs

From: Tim Howes <[email-masked]>
Date: Mon, 15 Nov 1999 16:09:25 -0800

The working group consensus was to progress the
API documents on the standards track.

I'll make sure the authors take this as a last
call comment to clarify this in the documents.
     -- Tim

> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:[email-masked]]
> Sent: Monday, November 15, 1999 10:19 AM
> To: Tim Howes
> Cc: [email-masked]'
> Subject: Re: LAST CALL: Java API Docs
> 
> 
> 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		<[email-masked]>
> Net Boolean Incorporated	<http://www.boolean.net/>
>

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 15 Nov 1999 17:27:58 -0800

>call comment to clarify this in the documents.

You might also want to update web page:

- Jul 99 Submit ID on C LDAP API to IESG for publication as a RFC
- Jul 99 Submit ID on Java LDAP API to IESG for publication as a RFC
- Jul 99 Submit ID on C LDAP API to IESG for consideration as a Proposed Standard
- Jul 99 Submit ID on Java LDAP API to IESG for consideration as a Proposed Standard

to be consistent with other standard-track submissions listed as
goals and milestones.

----

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 15 Nov 1999 17:36:37 -0800

>You might also want to update web page:

Teach me to generate diffs by hand... I meant:

- Jul 99 Submit ID on C LDAP API to IESG for publication as a RFC
- Jul 99 Submit ID on Java LDAP API to IESG for publication as a RFC
+ Jul 99 Submit ID on C LDAP API to IESG for consideration as a Proposed Standard
+ Jul 99 Submit ID on Java LDAP API to IESG for consideration as a Proposed Standard

(replace the first two goals with the second two goals).

----