> -----Original Message----- > From: ned.freed@mrochek.com [mailto:ned.freed@mrochek.com] > Sent: Thursday, August 15, 2002 10:13 AM > To: Paul Leach > Cc: Kurt D. Zeilenga; Patrik Fältström; Michael Armijo; Levon > Esibov; rlmorgan@washington.edu; ldapext@ietf.org; Ned Freed; > ietf-ldap@paf.se > Subject: RE: [ldapext] draft-ietf-ldapext-locate > > > > > "The format of the SRV RR > > > Here is the format of the SRV RR, whose DNS type code is 33: > > > _Service._Proto.Name TTL Class SRV Priority Weight > Port Target > > > (There is an example near the end of this document.) > > > Service > > The symbolic name of the desired service, as > defined in Assigned > > Numbers [STD 2] or locally. An underscore (_) is > prepended to > > the service identifier to avoid collisions with DNS > labels that > > occur in nature. > > ..." > > > In the case of LDAP, the symbolic name is "LDAP". > > Er, no. I remember this one... I wasn't an AD at the time but > I was the IAB's liason to the IESG. There was strong > objection from the IESG to this DNS ops document specifying > how a particular application service should be located using > SRV records. As a result the text was modified to include the > following: > > Note: LDAP is chosen as an example for illustrative purposes only, > and the LDAP examples used in this document should not be > considered > a definitive statement on the recommended way for LDAP to use SRV > records. As described in the earlier applicability section, consult > the appropriate LDAP documents for the recommended procedures. > > The bottom line is that if you think this sufficies as a > specification of the way to use SRV records to locate LDAP, > you're mistaken. (And I know a particular person who was on > the IESG at the time who would be very amused to hear this > mistake was made.) How about it 99% suffices. We would just need a one sentence (after boilerplate) RFC to say that locating an LDAP server given a domain name is done as per RFC 2782. Right? > > I don't know if this changes the previous assertion that this > document shouldn't make such a recommendation. Either way is > fine with me as long as it is clear what is meant. I think it would be pretty easy to restructure the draft-ietf-ldapext-locate for that it was in two parts: 1. How to find LDAP server given domain name - use SRV records as per 2782 2. How to find LDAP server given DC laden DN - Derive domain name from DC laden DN - use step 1 But I'd have to check the current wording to see how much work that is. It would be just an editorial change.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature