< draft-ietf-ldapext-lang-00.txt		draft-ietf-ldapext-lang-01.txt >
	Network Working Group M. Wahl		Network Working Group M. Wahl
	INTERNET-DRAFT Critical Angle Inc.		INTERNET-DRAFT Innosoft International, Inc.
	T. Howes		T. Howes
	Netscape Communications Corp.		Netscape Communications Corp.
	Expires in six months from 8 January 1998		Expires in six months from 17 July 1998
	Intended Category: Standards Track		Intended Category: Standards Track
	Use of Language Codes in LDAP		Use of Language Codes in LDAP
	<draft-ietf-ldapext-lang-00.txt>		<draft-ietf-ldapext-lang-01.txt>
	1. Status of this Memo		1. Status of this Memo
	This document is an Internet-Draft. Internet-Drafts are working		This document is an Internet-Draft. Internet-Drafts are working
	documents of the Internet Engineering Task Force (IETF), its areas,and		documents of the Internet Engineering Task Force (IETF), its areas,and
	its working groups. Note that other groups may also distribute		its working groups. Note that other groups may also distribute
	working documents as Internet-Drafts.		working documents as Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	To learn the current status of any Internet-Draft, please check the		To learn the current status of any Internet-Draft, please check the
	"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow		"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
	Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe),		Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe),
	ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).		ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (1998). All Rights Reserved.		Copyright (C) The Internet Society (1998). All Rights Reserved.
	2. Abstract		2. Abstract
	The Lightweight Directory Access Protocol [1] provides a means for		The Lightweight Directory Access Protocol [1] provides a means for
	clients to interrogate and modify information stored in a distributed		clients to interrogate and modify information stored in a distributed
	directory system. The information in the directory is maintained as		directory system. The information in the directory is maintained as
	attributes [2] of entries. Most of these attributes have syntaxes		attributes [2] of entries. Most of these attributes have syntaxes
	which are human-readable strings, and it is desirable to be able to		which are human-readable strings, and it is desirable to be able to
	indicate the natural language associated with attribute values.		indicate the natural language associated with attribute values.
	This document describes how language codes [3] are carried in LDAP		This document describes how language codes [3] are carried in LDAP
	and are to be interpreted by LDAP servers. All implementations MUST		and are to be interpreted by LDAP servers. All implementations MUST
	be prepared to accept language codes in the LDAP protocols. Servers		be prepared to accept language codes in the LDAP protocols. Servers
	may or may not be capable of storing attributes with language codes		may or may not be capable of storing attributes with language codes
	in the directory.		in the directory. This document does not specify how to determine
			whether particular attributes can or cannot have language codes.
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
	this document are to be interpreted as described in RFC 2119 [4].		this document are to be interpreted as described in RFC 2119 [4].
	draft-ietf-ldapext-lang-00.txt January 1998
	3. Language Codes		3. Language Codes
	Section 2 of RFC 1766 [3] describes the language code format which is		Section 2 of RFC 1766 [3] describes the language code format which is
	used in LDAP. Briefly, it is a string of ASCII alphabetic characters		used in LDAP. Briefly, it is a string of ASCII alphabetic characters
	and hyphens. Examples include "fr", "en-US" and "ja-JP".		and hyphens. Examples include "fr", "en-US" and "ja-JP".
	Language codes are case insensitive. For example, the language code		Language codes are case insensitive. For example, the language code
	"en-us" is the same as "EN-US" and "en-US".		"en-us" is the same as "EN-US" and "en-US".
	Implementations MUST NOT otherwise interpret the structure of the		Implementations MUST NOT otherwise interpret the structure of the
	skipping to change at page 2, line 46 ¶		skipping to change at page 2, line 44 ¶
	a set of one or more values. In LDAP, the type and the options are		a set of one or more values. In LDAP, the type and the options are
	combined into the AttributeDescription, defined in section 4.1.5 of		combined into the AttributeDescription, defined in section 4.1.5 of
	[1]. This is represented as an attribute type name and a		[1]. This is represented as an attribute type name and a
	possibly-empty list of options. One of these options associates a		possibly-empty list of options. One of these options associates a
	natural language with values for that attribute.		natural language with values for that attribute.
	language-option = "lang-" lang-code		language-option = "lang-" lang-code
	lang-code = printable-ascii ; a code as defined in RFC 1766		lang-code = printable-ascii ; a code as defined in RFC 1766
	There can be at most one language option present in an		Multiple language options may be present on a particular value.
	AttributeDescription.
	The language code has no effect on the character set encoding for		The language code has no effect on the character set encoding for
	string representations of DirectoryString syntax values; the UTF-8		string representations of DirectoryString syntax values; the UTF-8
	representation of UniversalString (ISO 10646) is always used.		representation of UniversalString (ISO 10646) is always used.
	Examples of valid AttributeDescription:		Examples of valid AttributeDescription:
	givenName;lang-en-US		givenName;lang-en-US
	CN;lang-ja		CN;lang-ja
	draft-ietf-ldapext-lang-00.txt January 1998
	In LDAP and in examples in this document, a directory attribute is		In LDAP and in examples in this document, a directory attribute is
	represented as an AttributeDescription with a list of values. Note		represented as an AttributeDescription with a list of values. Note
	that the data could be stored in the LDAP server in a different		that the data could be stored in the LDAP server in a different
	representation.		representation.
	4.2. Distinguished Names and Relative Distinguished Names		4.2. Distinguished Names and Relative Distinguished Names
	No attribute description options are permitted in Distinguished Names		No attribute description options are permitted in Distinguished Names
	or Relative Distinguished Names. Thus language codes MUST NOT be		or Relative Distinguished Names. Thus language codes MUST NOT be
	skipping to change at page 4, line 5 ¶		skipping to change at page 4, line 5 ¶
	If the server does not support storing language codes with attribute		If the server does not support storing language codes with attribute
	values in the DIT, then any filter which includes a language code		values in the DIT, then any filter which includes a language code
	will always fail to match, as it is an unrecognized attribute type.		will always fail to match, as it is an unrecognized attribute type.
	No error would be returned because of this; a presence filter would		No error would be returned because of this; a presence filter would
	evaluate to FALSE and all other forms to Undefined.		evaluate to FALSE and all other forms to Undefined.
	If no language code is specified in the search filter, then only the		If no language code is specified in the search filter, then only the
	base attribute type and the assertion value need match the value in		base attribute type and the assertion value need match the value in
	the directory.		the directory.
	draft-ietf-ldapext-lang-00.txt January 1998
	Thus for example a filter of an equality match of type "name" and		Thus for example a filter of an equality match of type "name" and
	assertion value "Billy Ray", against the following directory entry		assertion value "Billy Ray", against the following directory entry
	objectclass: top DOES NOT MATCH (wrong type)		objectclass: top DOES NOT MATCH (wrong type)
	objectclass: person DOES NOT MATCH (wrong type)		objectclass: person DOES NOT MATCH (wrong type)
	name;lang-EN-US: Billy Ray MATCHES		name;lang-EN-US: Billy Ray MATCHES
	name;lang-EN-US: Billy Bob DOES NOT MATCH (wrong value)		name;lang-EN-US: Billy Bob DOES NOT MATCH (wrong value)
	CN;lang-EN-US;dynamic: Billy Ray MATCHES		CN;lang-EN-US;dynamic: Billy Ray MATCHES
	CN;lang-en;dynamic: Billy Ray MATCHES		CN;lang-en;dynamic: Billy Ray MATCHES
	name: Billy Ray MATCHES		name: Billy Ray MATCHES
	skipping to change at page 5, line 5 ¶		skipping to change at page 5, line 5 ¶
	will be returned.		will be returned.
	Thus in general, clients SHOULD NOT use the language code option in		Thus in general, clients SHOULD NOT use the language code option in
	AttributeDescription fields in the compare request.		AttributeDescription fields in the compare request.
	4.5. Requested Attributes in Search		4.5. Requested Attributes in Search
	Clients MAY provide language codes in AttributeDescription in the		Clients MAY provide language codes in AttributeDescription in the
	requested attribute list in a search request.		requested attribute list in a search request.
	draft-ietf-ldapext-lang-00.txt January 1998
	If a language code is provided in an attribute description, then only		If a language code is provided in an attribute description, then only
	attribute values in a directory entry which have the same language		attribute values in a directory entry which have the same language
	code as that provided are to be returned. Thus if a client requests an		code as that provided are to be returned. Thus if a client requests an
	attribute "description;lang-en", the server MUST NOT return values of		attribute "description;lang-en", the server MUST NOT return values of
	an attribute "description" or "description;lang-fr".		an attribute "description" or "description;lang-fr".
	Clients MAY provide in the attribute list multiple		Clients MAY provide in the attribute list multiple
	AttributeDescription which have the same base attribute type but		AttributeDescription which have the same base attribute type but
	different options. For example a client MAY provide both		different options. For example a client MAY provide both
	"name;lang-en" and "name;lang-fr", and this would permit an attribute		"name;lang-en" and "name;lang-fr", and this would permit an attribute
	skipping to change at page 6, line 5 ¶		skipping to change at page 6, line 5 ¶
	Clients MAY provide language codes in AttributeDescription in		Clients MAY provide language codes in AttributeDescription in
	attributes of a new entry to be created, subject to the limitation		attributes of a new entry to be created, subject to the limitation
	that the client MUST NOT use language codes in the attribute value or		that the client MUST NOT use language codes in the attribute value or
	values which form the RDN of the entry.		values which form the RDN of the entry.
	A client MAY provide multiple attributes with the same attribute type		A client MAY provide multiple attributes with the same attribute type
	and value, so long as each attribute has a different language code,		and value, so long as each attribute has a different language code,
	and at most one attribute does not have a language code option.		and at most one attribute does not have a language code option.
	draft-ietf-ldapext-lang-00.txt January 1998
	Servers which support storing language codes in the DIT MUST allow any		Servers which support storing language codes in the DIT MUST allow any
	attribute it recognizes that has the Directory String syntax to have a		attribute it recognizes that has the Directory String syntax to have a
	language option associated with it. Servers SHOULD allow language		language option associated with it. Servers SHOULD allow language
	options to be associated with other attributes.		options to be associated with other attributes.
	For example, the following is a legal request.		For example, the following is a legal request.
	objectclass: top		objectclass: top
	objectclass: person		objectclass: person
	objectclass: residentialPerson		objectclass: residentialPerson
	skipping to change at page 6, line 55 ¶		skipping to change at page 6, line 53 ¶
	values in the DIT, then it MUST treat an AttributeDescription with a		values in the DIT, then it MUST treat an AttributeDescription with a
	language code as an unrecognized attribute, and MUST fail the request		language code as an unrecognized attribute, and MUST fail the request
	with an appropriate result code.		with an appropriate result code.
	4.8. Diagnostic Messages		4.8. Diagnostic Messages
	Servers SHOULD use only printable ASCII characters in the errorMessage		Servers SHOULD use only printable ASCII characters in the errorMessage
	field, as not all clients will be able to display the full range of		field, as not all clients will be able to display the full range of
	Unicode.		Unicode.
	5. Security Considerations		5. Differences from X.500(1997)
			X.500(1997) defines a different mechanism, contexts, as the means of
			representing language tags. This section summarizes the major
			differences in approach.
			a) An X.500 operation which has specified a language code on a
			value matches a value in the directory without a language code.
			b) LDAP references RFC 1766, which allows for IANA registration of
			new tags.
			c) LDAP does not allow language codes in distinguished names.
			d) X.500 describes subschema administration procedures to allow
			language codes to be associated with particular attributes types.
			6. Security Considerations
	There are no known security considerations for this document. See		There are no known security considerations for this document. See
	the security considerations sections of [1] and [2] for security		the security considerations sections of [1] and [2] for security
	considerations of LDAP in general.		considerations of LDAP in general.
	draft-ietf-ldapext-lang-00.txt January 1998		7. Acknowledgements
	6. Acknowledgements
	This document is a product of the IETF ASID and LDAPEXT working groups.		This document is a product of the IETF ASID and LDAPEXT working groups.
	Martin Duerst provided many valuable comments on an earlier version of		Martin Duerst provided many valuable comments on an earlier version of
	this document.		this document.
	7. Bibliography		8. Bibliography
	[1] M.Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol		[1] M.Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol
	(v3)", RFC 2251.		(v3)", RFC 2251.
	[2] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight X.500		[2] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight X.500
	Directory Access Protocol Attribute Syntax Definitions",		Directory Access Protocol Attribute Syntax Definitions",
	RFC 2252.		RFC 2252.
	[3] H. Alvestrand, "Tags for the Identification of Languages",		[3] H. Alvestrand, "Tags for the Identification of Languages",
	RFC 1766.		RFC 1766.
	[4] S. Bradner, "Key words for use in RFCs to Indicate Requirement		[4] S. Bradner, "Key words for use in RFCs to Indicate Requirement
	Levels", RFC 2119.		Levels", RFC 2119.
	8. Authors Addresses		9. Authors Addresses
	Mark Wahl		Mark Wahl
	Critical Angle Inc.		Innosoft International, Inc.
	4815 W Braker Lane #502-385		8911 Capital of Texas Hwy Suite 4140
	Austin, TX 78759		Austin, TX 78759 USA
	USA
	EMail: M.Wahl@critical-angle.com		EMail: M.Wahl@innosoft.com
	Tim Howes		Tim Howes
	Netscape Communications Corp.		Netscape Communications Corp.
	501 E. Middlefield Rd		501 E. Middlefield Rd
	Mountain View, CA 94043		Mountain View, CA 94043 USA
	USA
	Phone: +1 650 937-3419		Phone: +1 650 937-3419
	EMail: howes@netscape.com		EMail: howes@netscape.com
	draft-ietf-ldapext-lang-00.txt January 1998
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The Internet Society (1998). All Rights Reserved.		Copyright (C) The Internet Society (1998). All Rights Reserved.
	This document and translations of it may be copied and furnished to		This document and translations of it may be copied and furnished to
	others, and derivative works that comment on or otherwise explain it		others, and derivative works that comment on or otherwise explain it
	or assist in its implementation may be prepared, copied, published		or assist in its implementation may be prepared, copied, published
	and distributed, in whole or in part, without restriction of any		and distributed, in whole or in part, without restriction of any
	kind, provided that the above copyright notice and this paragraph are		kind, provided that the above copyright notice and this paragraph are
End of changes. 19 change blocks.
	30 lines changed or deleted		30 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/