Network Working Group M. Wahl INTERNET-DRAFT ISODE Consortium Expires in six months from 23 February 1996 Intended Category: Experimental Lightweight Directory Access Protocol: MIME-based Transport Mapping 1. Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 2. Abstract The Lightweight Directory Access Protocol (LDAP) [1] is a mechanism for clients to access a Directory service. Protocol mappings have been defined for TCP, UDP and OSI Connection-Oriented Transport. This document defines how LDAP may be represented using MIME Content Types, so that it can be carried in SMTP or other protocols such as HTTP. 3. Specification The application/ber-stream defined in [2] is used to encode LDAP for transport in MIME. The protocol is identified by an OBJECT IDENTIFIER based on TCP port 389 (assigned in RFC 1777). The content of the application/ber-stream is the base64 representation of a BER encoding of a series of one or more ASN.1 data values, each of type Lightweight-Directory-Access-Protocol.LDAPMessage. The subset of BER described in section 5 of [1] must be used when encoding, and the values must be concatenated according to the LDAP specification. Quoted printable content transfer encoding must not be generated. INTERNET-DRAFT LDAP MIME-based Transport Mapping 19 February 1996 4. Request/Response Mechanisms The client will produce a single content containing a series of LDAPMessages. The acceptable choices in the request content for LDAPMessage are bindRequest, searchRequest, modifyRequest, addRequest, delRequest, modDNRequest, compareRequest, newDelRequest, extendedReq and unbindRequest. Message Ids must be unique across all requests in a content, and no requests must follow an unbindRequest. A Content-ID must be generated and associated with this content. The server will parse this content and process each request individually and in order. If a bindRequest fails the server should process no following requests. In addition, the server should stop processing following an unbindRequest. For all other operations the server should continue to process even if a request fails. The server will respond to this content with another application/ber-stream content, containing a series of LDAPMessages. The references field of the Content-Type contains the Content-Id of the request. The acceptable choices in the response content for LDAPMessage are bindRespBasic, bindRespExtd, searchResEntry, searchResDone, searchResRef, modifyResponse, addResponse, delResponse, modDNResponse, compareResponse and extendedResp. There will typically be one response per request, except that there may be more than one response to the searchRequest, and there is no response to an unbindRequest. 4.1. Mapping to SMTP The client will produce an electronic mail message containing a single content, the application/ber-stream of the request, and mail it to an automated responder of the server. The server will reply to the requestor with an electronic mail message containing a single content, the application/ber-stream of the response, and mail it to the requesting address. 4.2. Mapping to HTTP The client will post a request to the server in the HTTP [3] protocol. The POST includes an Entity-Body of the application/ber-stream content of the request. As the response will be returned over the same TCP connection a Content-ID need not be generated. The server will reply to this request with status 200 and include another content, the application/ber-stream of the response. The references field should be absent if Content-ID was not in the request. 5. Security Considerations Security considerations are not currently discussed in this memo. INTERNET-DRAFT LDAP MIME-based Transport Mapping 19 February 1996 6. Bibliography [1] M. Wahl, W. Yeong, T. Howes, S. Kille, "Lightweight Directory Access Protocol (Version 3)", INTERNET-DRAFT, . [2] M.Wahl, "A MIME Content-Type for ASN.1 PDUs", INTERNET-DRAFT, . [3] T. Berners-Lee, R. Fielding, H. Frystyk, "Hypertext Transport Protocol -- HTTP/1.0", INTERNET-DRAFT, . 7. Author's Address Mark Wahl ISODE Consortium Inc. 3925 West Braker Lane #333 Austin TX 78759 USA M.Wahl@isode.com +1 (512) 305-0280