Re: Comments from Christian H. on LDAP

[Tim Howes <[e-mail]>]

> From:    Andrew Waugh <[e-mail]>
> To:      Erik Huizer <[e-mail]>

> From:    Christian Huitema <[e-mail]>
> >The general architecture is sound: it keeps the X.500 "ASE" while
> >removing the unnecessary overhead due to the Session, Presentation
> >and ROS layer.
> 
> But does it? I cannot see anything in the draft which either
> says that the BER is being sent directly over TCP (or other Transport
> Layer protocol) or implies it. There should be a statement in section 5:
> 
> 	"The encoded protocol elements of LDAP are sent directly
> 	over the Transport layer service. No Session, Presentation
> 	or other Application Layer Protocols (such as ROSE or ACSE)
> 	are used."

Doesn't seem like it should be necessary (shouldn't the default be
NO rose, acse, etc if it's not mentioned??).  Just like for smtp :-).
But if people want this text added, I've no objections.

> >I dont
> >understand whether LDAP allows to send a query without sending a
> >"BIND" first; stateless operation should be allowed!
> 
> I totally agree with Christian here. It should be possible for the
> user to open a TCP connection to the DSA and send an X.500 operation.
> The DSA could considered this as having received an implicit anonymous
> bind request. Closing the TCP connection could then be considered
> as an implicit UnbindRequest (and, if necessary, an abandonRequest).
> It will, however, be necessary to promote the version field of the
> BindRequest to be an optional parameter of LDAPMessage to do this.

The only problem here is version control.  If we were to get rid of
the initial bind, to get versioning we'd have to include the version
on every request.  Being able to specify a new version seems like
a good thing to me.

> I cannot see the necessity of including the messageID field in the
> LSAPMessage. I would assume that the operation of LDAP is synchronous;
> send an operation, get a response. For this a messageID field is not
> necessary. If LDAP is asynchronous this should be stated.

The protocol can be async.  From section 3 "Protocol Model":

	Note that, although servers are required to return responses
	whenever such responses are defined in the protocol, there is
	no requirement for synchronous behavior on the part of either
	client or server implementations: requests and responses for
	multiple operations may be exchanged by client and servers in
	any order, as long as clients eventually receive a response for
	every request that requires one.

   -- Tim