Thank you for your comments. The lack of the discussion about the referrals in the LCUP draft was not intentional but an oversight. I will add a discussion on this to the next revision of the document.
I think that, because the intent of the protocol is for the clients to contain exactly the same data as the servers, the protocol should act as though ManageDsaIT control is attached. We can require that clients attach the ManageDsaIT control to the search operation. Alternatively we can require that servers treat synchronization requests as though there is a ManageDsaIT control attached.
Olga
Mircea Pana wrote:
Mark,
LCUP does not describe any specific behavior for continuation references. The document only states that "the server returns a set of SearchResultEntries that fits the client's specification.". No mention of SearchResultReferences.
Was this the intent of the authors?
Assuming that for a search operation, the server would normally return continuation references, what is supposed to happen when the same search request contains a clientUpdate control that indicates the client's intent to initiate a synchronization session?
What is supposed to happen when the server acquires knowledge of a subordinated naming context on a different server, while synchronizing a client? What should happen in the opposite case: when knowledge of a subordinates naming context is removed from the server? etc.
Should the ManageDsaIT control be used when the client has interest in the knowledge information and its evolution? ...quite limiting, this sounds more like a work-around than a solution.
Thanks,
Mircea.