Subject: LAST CALL draft-ietf-ldapext-ldapv3-vlv-03.txt

From: Mark Wahl <[email-masked]>
Date: Mon, 22 Nov 1999 18:46:13 -0600

(VLV referenced simple paged and sorting: the first is now an RFC and the
second is done in our working group and with the Area Directors.)

The purpose of this message is to initiate an LDAPEXT
working group last call on the LDAPv3 extension for scrolling
list view browsing specification.

WHAT DOCUMENT?

The LDAPv3 Scrolling (Virtual) List View Browsing document 
in last call is:

      draft-ietf-ldapext-ldapv3-vlv-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, December 9, 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 document to the IESG for proposed standard
status.

2) Minor changes agreed to on the list are required, and
the document is revised. We then ask our ADs to put
forward the revised document 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 document
is with the IESG. The IESG reads it and may approve the
documents (with or without changes), or send the document
back to the working group to have major issues addressed.

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

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

WHAT SHOULD I DO?

You should read the document, 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 Tim Howes.

Read, enjoy, and send your comments in!

Mark Wahl, Directory Product Architect
Innosoft International, Inc.

---

From: [email-masked]
Date: Wed, 24 Nov 1999 13:59:54 +0100

There seem to be some errors in the example. See comments below.

> 6.  Protocol Example
>
> Here we walk through the client-server interaction for a  specific  vir-
> tual list view example:  The task is to display a list of all 78564 peo-
> ple in the US company "Ace Industry".  This will be done by  creating  a
> graphical  user  interface  object  to display the list contents, and by
> repeatedly sending different versions of  the  same  virtual  list  view
> search  request  to the server. The list view displays 20 entries on the
> screen at a time.
>
> We form a search with baseDN "o=Ace Industry, c=us"; search  scope  sub-
> tree;  filter "objectClass=inetOrgPerson". We attach a server sort order
> control to the search, specifying ascending sort on attribute  "cn".  To
> this  base  search,  we  attach a virtual list view request control with
> contents determined by the user activity and  send  the  search  to  the
> server.  We  display the results from each search in the list window and
> update the slider position.
>
> When the list view is first displayed, we want to  initialize  the  con-
> tents showing the beginning of the list. Therefore, we set beforeCount =
> 0, afterCount = 19, contentCount = 0, offset = 1 and send the request to
> the  server.  The  server duly returns the first 20 entries in the list,
> plus the content count = 78564 and  targetPosition  =  1.  We  therefore
> leave  the  scroll  bar  slider  at its current location (the top of its
> range).
>
> Say that next the user drags the scroll bar slider down to the bottom of
> its  range.   We now wish to display the last 20 entries in the list, so
> we set beforeCount = 19, afterCount = 0, contentCount = 78564, offset  =
> 78564 and send the request to the server. The server returns the last 20
> entries in the list, plus the content count = 78564 and targetPosition =
> 78564.
>
> Next the user presses a page up key. Our page size  is  20,  so  we  set
> beforeCount  =  0,  afterCount  =  19,  contentCount  =  78564, offset =
> 78564-19-20 and send the request to the server. The server  returns  the
> preceeding  20  entries  in the list, plus the content count = 78564 and
> targetPosition = 78524.

      Requested offset and returned targetPosition are different.
     IMHO targetPosition should be 78525.

     Request:
          offset         = 78564-19-20 = 78525
          beforeCount    =     0
          afterCount     =    19
          contentCount   = 78564

     Result:
          targetPosition = 78525        // was 78524
          contentCount   = 78564

> Now the user grabs the scroll bar slider and drags it to 68% of the  way
> down its travel. 68% of 78564 is 52424 so we set beforeCount = 9, after-
> Count = 10, contentCount = 78564, offset = 52424 and send the request to
> the  server.  The  server returns the preceeding 20 entries in the list,
> plus the content count = 78564 and targetPosition = 78524.

     68% of 78564 is 53424, not 52424. "The server returns..." was copied
     from the previous step and not modified to match this step.

     Request:
          offset         = 53424        // was 52424
          beforeCount    =     9
          afterCount     =    10
          contentCount   = 78564

     Result:
          targetPosition = 53424        // was 78524
          contentCount   = 78564

> Lastly, the user types the letter "B". We set beforeCount  =  9,  after-
> Count  =  10  and  greaterThanOrEqual  = "B". The server finds the first
> entry in the list not less  than  "B",  let's  say  "Babs  Jensen",  and
> returns  the nine preceeding entries, the target entry, and the proceed-
> ing 10 entries.  The server returns content count = 78564 and  targetPo-
> sition = 5234 and so the client updates its scroll bar slider to 6.6% of
> full scale.

     5234/78564 = 6.662% -> rounded 6.7%

Rolf Maeule
pc-plus COMPUTING