Click Here!
home account info subscribe login search My ITKnowledge FAQ/help site map contact us


 
Brief Full
 Advanced
      Search
 Search Tips
To access the contents, click the chapter and section titles.

HTML 4.0 Sourcebook
(Publisher: John Wiley & Sons, Inc.)
Author(s): Ian S. Graham
ISBN: 0471257249
Publication Date: 04/01/98

Bookmark It

Search this book:
 
Previous Table of Contents Next


LDAP URLs

LDAP, or Lightweight Directory Access Protocol, is a technology that provides corporate directory services—it allows for directory-like information about staff, resources, facilities, addresses, et cetera, accessible from directory servers that can be searched using LDAP requests. As a component of their implementation of LDAP, Netscape developed a now-standardized URL scheme for referencing LDAP directory information from an LDAP server. The general form is:

ldap:// int.domain.nam:port/ldap-query

where int.domain.nam is the machine running the LDAP server at the indicated port (default value is 389) and ldap-query is a query string requesting information from the server. The syntax for such queries is complex and is not reproduced here—in general, a query is composed by the software creating the URL, and not by the user. An example query is:

ldap://ldap.utoronto.ca/o=University%20of%Toronto,c=CA

which requests directory information about the University of Toronto in Canada.

Ldap URLs are supported by Netscape Navigator 4 and Internet Explorer 4 and later, but are not supported by earlier versions of these (or other) browsers.

LDAPS URLs—Secure LDAP

Ldaps URLs are equivalent to ldap URLs, except that the request is addressed to port 636 instead of 389, and the connection to the LDAP server is encrypted. Ldaps URLs are supported by Netscape, but only via the conferencing and address book components of Netscape Communicator.

Mailto URLs

The mailto URL designates an Internet-format mail address to which mail can be sent. The format is

mailto:mail_address

where mail_address is the Internet mail address (as specified in RFC 822, the document that specifies the format for Internet mail) to which a message can be mailed. Typically, this is of the form name@host, where name is the user mail account name of the person and host is the name of the machine at which the user receives mail. A browser that supports mailto will provide a mechanism for users to compose and send a letter to this destination.

Some mail addresses contain the percent character. This character must be encoded, since it is a special character (marking the beginning of a character encoding string). As an example, the e-mail address:

jello%ian@irc.utoronto.ca

must be converted into the mailto URL:

mailto:jello%25ian@irc.utoronto.ca

A mailto URL does not indicate how the mail should be sent. In general, a client mail program must contact a mail server—a program which validates the mail and forwards it to its destination. Mailto URLs do not specify a mail server—this information must be separately configured into a browser. Web browsers usually provide a configuration menu for this purpose.

Specifying Subject and Other Mail Message Information

When composing a URL to send a mail message, authors often want to include information beyond just the destination address. For example, the author may want to specify a default subject line or perhaps give alternate (CC’d) mail destinations for the letter.

One proposed approach for specifying the subject line is to place the message subject in a TITLE attribute of the element containing the mailto reference (typically an A or FORM). Thus elements of the form

<A HREF=“mailto:address” TITLE=“Message title”>.....</A>

<FORM ACTION=“mailto:address” ... TITLE=“Message title”> ...

would use the TITLE value as the subject when composing the message. This approach, within the context of A, is supported by some versions of the lynx browser.

Netscape Navigator developers took a different approach and decided to include the information as query string information within the mailto URL itself. This is done by appending any required mail header in URL-encoded format, using strings of the form header=value, where header is the mail header name (URL-encoded) and value is the (URL-encoded) string to associate with the name. For example, to send a message to the address address, specifying a given title and a list of CC recipients, the URL would be

mailto:address?subject=test%20mail%20message&cc=address1%2caddress2

which associates the subject line “test mail message” to the indicated address, as well as the two indicated CC’d addresses. Notice how the different values are separated by the ampersand character (as with FORM data encoding) and that all special characters in the fields are encoded via their URL-encoded values.

If a mailto URL appears in a hyperlink, then any headers that do not correspond to headers that can be edited in a mail authoring tool are ignored and are not added to the letter. On the other hand, if the mailto appears within a FORM that is using the POST method to send mail, then all headers present in the URL are generated, even if they are not understood by the mail client. However, headers that should not be altered (return address, content type, etc.) cannot be changed by the mailto URL, and in these cases the information in the URL is ignored. The list of mail headers that cannot be overridden is:

Apparently-to BCC Content-encoding
Content-length Content-transfer-encoding Content-type
Date Distribution FCC
Followup-to From Lines
MIME-version Message-ID Newsgroup
Organization Reply-To Sender
X-UIDL XREF

Netscape 4 also allows for the inclusion of the actual message body within the URL, via the syntax:

mailto:address@domain.com?subject=xxxx?body=body-of-message

where the special keyword body is equal to the content of the message. This is not supported by Netscape Navigator 3 or earlier.

There is an obvious problem with this approach— it does not work with other browsers, in particular Internet Explorer 4, which assume the extra text to be part of the mail address. Fortunately, the address fields can be hand-edited before sending the letter—provided the user understands the problem and how to fix it.


Previous Table of Contents Next


Products |  Contact Us |  About Us |  Privacy  |  Ad Info  |  Home

Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc.
All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.