X.500 URI Attribute: Definition of an X.500 Attribute Type and an Object Class to Hold Uniform Resource Identifiers (URIs)
A standard way to store web addresses, with optional labels, in LDAP and X.500 directory entries.
Smith, M., "Definition of an X.500 Attribute Type and an Object Class to Hold Uniform Resource Identifiers (URIs)", RFC 2079, DOI 10.17487/RFC2079, January 1997, <https://www.rfc-editor.org/info/rfc2079>.
@misc{rfc2079,
series = {Request for Comments},
number = 2079,
howpublished = {RFC 2079},
publisher = {RFC Editor},
doi = {10.17487/RFC2079},
url = {https://www.rfc-editor.org/info/rfc2079},
author = {M. Smith},
title = {{Definition of an X.500 Attribute Type and an Object Class to Hold Uniform Resource Identifiers (URIs)}},
pagetotal = 5,
year = 1997,
month = jan,
} RFC text
Contents
Network Working Group M. Smith
Request for Comments: 2079 Netscape Communications
Category: Standards Track January 1997
Definition of an X.500 Attribute Type and an Object Class to Hold
Uniform Resource Identifiers (URIs)
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract
Uniform Resource Locators (URLs) are being widely used to specify the
location of Internet resources. There is an urgent need to be able
to include URLs in directories that conform to the LDAP and X.500
information models, and a desire to include other types of Uniform
Resource Identifiers (URIs) as they are defined. A number of
independent groups are already experimenting with the inclusion of
URLs in LDAP and X.500 directories. This document builds on the
experimentation to date and defines a new attribute type and an
auxiliary object class to allow URIs, including URLs, to be stored in
directory entries in a standard way.
Background and Intended Usage
Uniform Resource Locators (URLs) as defined by [1] are the first of
several types of Uniform Resource Identifiers (URIs) being defined by
the IETF. URIs are widely used on the Internet, most notably within
Hypertext Markup Language [2] documents. This document defines an
X.500 [3,4] attribute type called labeledURI and an auxiliary object
class called labeledURIObject to hold all types of URIs, including
URLs. These definitions are designed for use in LDAP and X.500
directories, and may be used in other contexts as well.
Schema Definition of the labeledURI Attribute Type
Name: labeledURI
ShortName: None
Description: Uniform Resource Identifier with optional label
OID: umichAttributeType.57 (1.3.6.1.4.1.250.1.57)
Syntax: caseExactString
SizeRestriction: None
SingleValued: False
Discussion of the labeledURI Attribute Type
The labeledURI attribute type has the caseExactString syntax (since
URIs are case-sensitive) and it is multivalued. Values placed in the
attribute should consist of a URI (at the present time, a URL)
optionally followed by one or more space characters and a label.
Since space characters are not allowed to appear un-encoded in URIs,
there is no ambiguity about where the label begins. At the present
time, the URI portion must comply with the URL specification [1].
Multiple labeledURI values will generally indicate different
resources that are all related to the X.500 object, but may indicate
different locations for the same resource.
The label is used to describe the resource to which the URI points,
and is intended as a friendly name fit for human consumption. This
document does not propose any specific syntax for the label part. In
some cases it may be helpful to include in the label some indication
of the kind and/or size of the resource referenced by the URI.
Note that the label may include any characters allowed by the
caseExactString syntax, but that the use of non-IA5 (non-ASCII)
characters is discouraged as not all directory clients may handle
them in the same manner. If non-IA5 characters are included, they
should be represented using the X.500 conventions, not the HTML
conventions (e.g., the character that is an "a" with a ring above it
should be encoded using the T.61 sequence 0xCA followed by an "a"
character; do not use the HTML escape sequence "å").
Examples of labeledURI Attribute Values
An example of a labeledURI attribute value that does not include a
label:
ftp://ds.internic.net/rfc/rfc822.txt
An example of a labeledURI attribute value that contains a tilde
character in the URL (special characters in a URL must be encoded as
specified by the URL document [1]). The label is "LDAP Home Page":
http://www.umich.edu/%7Ersug/ldap/ LDAP Home Page
Another example. This one includes a hint in the label to help the
user realize that the URL points to a photo image.
http://champagne.inria.fr/Unites/rennes.gif Rennes [photo]
Schema Definition of the labeledURIObject Object Class
Name: labeledURIObject
Description: object that contains the URI attribute type
OID: umichObjectClass.15 (1.3.6.1.4.1.250.3.15)
SubclassOf: top
MustContain:
MayContain: labeledURI
Discussion of the labeledURIObject Object Class
The labeledURIObject class is a subclass of top and may contain the
labeledURI attribute. The intent is that this object class can be
added to existing directory objects to allow for inclusion of URI
values. This approach does not preclude including the labeledURI
attribute type directly in other object classes as appropriate.
Security Considerations
Security considerations are not discussed in this memo, except to
note that blindly inserting the label portion of a labeledURI
attribute value into an HTML document is not recommended, as this may
allow a malicious individual to include HTML tags in the label that
mislead viewers of the entire document in which the labeledURI value
was inserted.
Acknowledgments
Paul-Andre Pays, Martijn Koster, Tim Howes, Rakesh Patel, Russ
Wright, and Hallvard Furuseth provided invaluable assistance in the
creation of this document.
This material is based in part upon work supported by the National
Science Foundation under Grant No. NCR-9416667.
Appendix: The labeledURL Attribute Type (Deprecated)
An earlier draft of this document defined an additional attribute
type called labeledURL. This attribute type is deprecated, and
should not be used when adding new values to directory entries. The
original motivation for including a separate attribute type to hold
URLs was that this would better enable efficient progammatic access
to specific types of URIs. After some deliberation, the IETF-ASID
working group concluded that it was better to simply have one
attribute than two.
The schema definition for labeledURL is included here for historical
reference only. Directory client software may want to support this
schema definition (in addition to labeledURI) to ease the transition
away from labeledURL for those sites that are using it.
Name: labeledURL
ShortName: None
Description: Uniform Resource Locator with optional label
OID: umichAttributeType.41 (1.3.6.1.4.1.250.1.41)
Syntax: caseExactString
SizeRestriction: None
SingleValued: False
OID: umichAttributeType.41 (1.3.6.1.4.1.250.1.41)
References
[1] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
Resource Locators (URL)", RFC 1738, CERN, Xerox Corporation,
University of Minnesota, December 1994.
<URL:ftp://ds.internic.net/rfc/rfc1738.txt>
[2] Berners-Lee, T., and D. Connolly, "Hypertext Markup Language -
2.0", RFC 1866, <URL:ftp://ds.internic.net/rfc/rfc1866.txt>
[3] The Directory: Overview of Concepts, Models and Service. CCITT
Recommendation X.500, 1988.
[4] Information Processing Systems -- Open Systems Interconnection --
The Directory: Overview of Concepts, Models and Service. ISO/IEC JTC
1/SC21; International Standard 9594-1, 1988.
Author's Address
Mark Smith
Netscape Communications Corp.
501 E. Middlefield Rd.
Mountain View, CA 94043, USA
Phone: +1 415 937-3477
EMail: mcs@netscape.com
AI ELI5
On this page
§1Background and Intended Use
URLs, as defined in RFC 1738, are the first of several kinds of Uniform Resource Identifiers (URIs). Several groups were already experimenting with putting URLs in LDAP and X.500 directories. This RFC builds on that work and defines an X.500 attribute type called labeledURI and an auxiliary object class called labeledURIObject.
They are designed for LDAP and X.500 directories and may be used elsewhere.
People wanted to put web addresses into directories, so this note picks one common way to do it.
§2The labeledURI Attribute
The attribute has the caseExactString syntax, because URIs are case-sensitive, and it is multivalued. Its OID is 1.3.6.1.4.1.250.1.57. A value is a URI (at present a URL) optionally followed by one or more spaces and a label. Spaces cannot appear unencoded in a URI, so it is clear where the label starts.
The label is a friendly name for people, and the RFC proposes no syntax for it. Non-ASCII characters in it are discouraged. If used, they should follow X.500 conventions, not HTML ones. Several values usually point to different related resources, but may be different locations for one resource.
Each entry holds a web address, and after a space you can add a short note about it, like a caption.
§3Object Class and Examples
The labeledURIObject class (OID 1.3.6.1.4.1.250.3.15) is a subclass of top that may contain labeledURI. It can be added to existing directory objects. The attribute can also be placed directly in other object classes.
Examples include http://www.umich.edu/%7Ersug/ldap/ LDAP Home Page, with the label "LDAP Home Page", and http://champagne.inria.fr/Unites/rennes.gif Rennes [photo], where the label hints the target is a photo.
The object class is a sticker you can put on an existing directory entry to give it a place for web addresses.
§4Security and the Deprecated labeledURL
The memo says security is not discussed, except to warn that blindly inserting a label into an HTML document is not recommended. A malicious label could carry HTML tags that mislead viewers.
An earlier draft defined a separate labeledURL attribute. It is deprecated and should not be used for new values, because the IETF-ASID working group decided one attribute is better than two. Clients may support it to ease the transition.
Do not paste the note text into a web page without care, since a sneaky note could trick people. An old second attribute was dropped.