Re: draft-ietf-ldapext-locate-02 and UDP

["RL 'Bob' Morgan" <rlmorgan@washington.edu>]

> Section 4 states that the protocol can be either "udp" or "tcp".
> It is unclear to me whether this I-D is intended "udp" <Proto> 
> is to be used to locate CLDAPv2 (RFC1798) services or to locate
> CLDAPv3 (draft-ietf-ldapext-cldap-00) or was just an alias
> for "tcp".
> 
> As LDAP (RFC1777/RFC2251) does not provide a specification for
> LDAP over UDP, this proposal should not provide location of
> services operating over UDP.  

I agree that this needs to be more clear but I'm not sure I agree with the
conclusion.

RFC 1798 is a Proposed Standard.  It seems reasonable to specify a means
to discover services that implement it, and seems obvious to do so using
"_ldap._udp" as the -locate- draft implies.  There is enough compatibility
between LDAPv2-over-TCP and LDAPv3-over-TCP that servers can reasonably do
both, so we're not motivated to specify something like "_ldapv3._tcp" as a
separate name.  The only reason I can think of for removing references to
UDP from this document, that is, for deciding to have the DNS SRV method
*not* apply to services conforming to RFC 1798, is that we think that RFC
1798 is technically flawed enough that CLDAPv3 is likely to be
incompatible with it, hence we're inclined to reserve "_ldap._udp" to
apply to CLDAPv3 implementations only.  Is that what you're asserting,
Kurt?  (Obviously we can't refer to CLDAPv3 in this doc since CLDAPv3 is
not done yet; and I don't think publication of -locate- wants to wait on
it.)

Otherwise, I suggest that the text be modified to say:

  The name of this record has the following format:

      _<Service>._<Proto>.<Domain>

   where <Service> is always "ldap", and <Proto> is a protocol that can
   be either "udp" or "tcp".  "_ldap._tcp" applies to services compatible
   with LDAPv2 [RFC1777] or LDAPv3 [1].  "_ldap._udp" applies to services
   compatible with CLDAP [RFC1798].

 - RL "Bob"