< draft-ietf-acap-abook-02.txt		draft-ietf-acap-abook-03.txt >
	Network Working Group C. Newman		Network Working Group C. Newman
	Internet Draft: ACAP Addressbook Dataset Class Innosoft		Internet-Draft Sun Microsystems
	Document: draft-ietf-acap-abook-02.txt S. Hubert		Expires: May 26, 2003 November 25, 2002
	University of Washington
	March 1998
	Expires in six months
	ACAP Personal Addressbook Dataset Class		ACAP Personal Addressbook Dataset Class
			draft-ietf-acap-abook-03.txt
	Status of this memo		Status of this Memo
	This document is an Internet-Draft. Internet-Drafts are working		This document is an Internet-Draft and is in full conformance with
	documents of the Internet Engineering Task Force (IETF), its areas,		all provisions of Section 10 of RFC2026.
	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		Internet-Drafts are working documents of the Internet Engineering
	months and may be updated, replaced, or obsoleted by other		Task Force (IETF), its areas, and its working groups. Note that
	documents at any time. It is inappropriate to use Internet-Drafts		other groups may also distribute working documents as Internet-
	as reference material or to cite them other than as "work in		Drafts.
	progress."
	To view the entire list of current Internet-Drafts, please check		Internet-Drafts are draft documents valid for a maximum of six months
	the "1id-abstracts.txt" listing contained in the Internet-Drafts		and may be updated, replaced, or obsoleted by other documents at any
	Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net		time. It is inappropriate to use Internet-Drafts as reference
	(Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East		material or to cite them other than as "work in progress."
	Coast), or ftp.isi.edu (US West Coast).
			The list of current Internet-Drafts can be accessed at http://
			www.ietf.org/ietf/1id-abstracts.txt.
			The list of Internet-Draft Shadow Directories can be accessed at
			http://www.ietf.org/shadow.html.
			This Internet-Draft will expire on May 26, 2003.
			Copyright Notice
			Copyright (C) The Internet Society (2002). All Rights Reserved.
	Abstract		Abstract
	IMAP [IMAP4] allows nomadic users to access their mail store from		Internet Message Access Protocol (IMAP) allows nomadic users to
	any client, but it does not support storage of personal		access their mail store from any client, but it does not support
	addressbooks. Application Configuration Access Protocol [ACAP]		storage of personal addressbooks. Application Configuration Access
	provides an ideal mechanism for storage of personal addressbooks.		Protocol (ACAP) provides a mechanism for storage of personal
	While ACAP permits the definition of vendor specific solutions to		addressbooks. While ACAP permits the definition of vendor specific
	this problem, having a standard addressbook dataset class permits		solutions to this problem, having a documented addressbook dataset
	clients from different vendors to interoperably share the same		class permits clients from different vendors to interoperably share
	personal addressbooks. This specification defines a standard		the same personal addressbooks. This specification defines an ACAP
	dataset class for personal addressbooks.		dataset class for personal addressbooks.
	Table of Contents		Table of Contents
	Status of this memo ............................................... i		1. Conventions Used in this Document . . . . . . . . . . . . . . 3
	Abstract .......................................................... i		2. Design Issues . . . . . . . . . . . . . . . . . . . . . . . . 3
	1. Conventions Used in this Document ............................ 1		2.1 Reason for Publication . . . . . . . . . . . . . . . . . . . . 3
	2. Design Issues ................................................ 1		3. ACAP Personal Addressbooks . . . . . . . . . . . . . . . . . . 3
	3. ACAP Personal Addressbooks ................................... 1		3.1 ACAP Addressbook Dataset Class . . . . . . . . . . . . . . . . 3
	3.1. ACAP Addressbook Dataset Class ............................... 1		3.2 ACAP Addressbook Capability . . . . . . . . . . . . . . . . . 4
	3.2. ACAP Addressbook Capability .................................. 1		3.3 ACAP Addressbook Hierarchy . . . . . . . . . . . . . . . . . . 4
	3.3. ACAP Addressbook Hierarchy ................................... 1		4. Recommended ACAP Attributes . . . . . . . . . . . . . . . . . 4
	3. Recommended ACAP Attributes .................................. 2		4.1 Basic Attributes . . . . . . . . . . . . . . . . . . . . . . . 5
	3.1. Basic Attributes ............................................. 2		4.2 Naming Attributes . . . . . . . . . . . . . . . . . . . . . . 5
	4.2. Naming Attributes ............................................ 3		4.3 Reference Attribute . . . . . . . . . . . . . . . . . . . . . 7
	4.3. Reference Attribute .......................................... 5		4.4 Computer Communication Attributes . . . . . . . . . . . . . . 7
	4.4. Computer Communication Attributes ............................ 5		4.5 Telephone Number Attributes . . . . . . . . . . . . . . . . . 10
	4.5. Telephone Number Attributes .................................. 7		4.6 Postal Address Attributes . . . . . . . . . . . . . . . . . . 12
	4.6. Postal Address Attributes .................................... 8		4.7 Commentary Attributes . . . . . . . . . . . . . . . . . . . . 12
	4.7. Commentary Attributes ........................................ 9		4.8 Locational Attributes . . . . . . . . . . . . . . . . . . . . 13
	4.8. Locational Attributes ........................................ 9		4.9 Public Keys . . . . . . . . . . . . . . . . . . . . . . . . . 14
	4.9. PGP Public Keys .............................................. 10		5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
	5. Examples ..................................................... 11		6. Mapping vCards to ACAP addressbooks . . . . . . . . . . . . . 16
	6. Mapping vCards to ACAP addressbooks .......................... 12		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
	7. References ................................................... 12		8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
	8. Security Considerations ...................................... 13		Normative References . . . . . . . . . . . . . . . . . . . . . 19
	9. Authors' Addresses ............................................ 13		Informative References . . . . . . . . . . . . . . . . . . . . 19
	Appendix .......................................................... 15		Author's Address . . . . . . . . . . . . . . . . . . . . . . . 21
	A. Attribute Index .............................................. 15		Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
	1. Conventions Used in this Document		Intellectual Property and Copyright Statements . . . . . . . . 23
	The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"		1. Conventions Used in this Document
	in this document are to be interpreted as defined in "Key words for
	use in RFCs to Indicate Requirement Levels" [KEYWORDS].
	The attribute syntax specifications use the Augmented Backus-Naur		The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
	Form (ABNF) notation as specified in [ABNF].		in this document are to be interpreted as defined in "Key words for
			use in RFCs to Indicate Requirement Levels" [2].
	When UTF-8 [UTF8] is referred to in this document, it refers to		The attribute syntax specifications use the Augmented Backus-Naur
	Unicode version 2.0, and not Unicode version 1.1.		Form (ABNF) [3] notation including the core rules defined in Appendix
			A. This also inherits ABNF rules from ACAP [4], SMTP [7], URI [6]
			and Language Tags [8].
	2. Design Issues		When UTF-8 [5] is referred to in this document, it refers to an
			encoding of Unicode version 2.0 or later, and not Unicode version
			1.1.
	Although this is not a white pages service, in order to provide		2. Design Issues
	more consistency, this was designed to match the Common Schema for
	Internet White Pages [WHITE-SCHEMA]. It was also designed to
	minimize email client complexity, provide a clean model for
	personal distribution lists and hierarchical addressbooks and
	permit storage of vCards [VCARD] for correspondents.
	Personal addressbooks differ from white pages services because all		Although this is not a white pages service, in order to provide more
	the attributes and entries are controlled by the user who owns the		consistency, this was designed to match the Common Schema for
	addressbook rather than a directory administrator. The user or the		Internet White Pages [13]. It was also designed to minimize email
	clients he uses may add new attributes at any time and some of		client complexity, provide a clean model for personal distribution
	these attributes are not suitable for a white pages service.		lists and hierarchical addressbooks and permit storage of vCards [17]
			for correspondents.
	3. ACAP Personal Addressbooks		Personal addressbooks differ from white pages services because all
			the attributes and entries are controlled by the user who owns the
			addressbook rather than a directory administrator. The user or the
			clients he uses may add new attributes at any time and some of these
			attributes are not suitable for a white pages service.
	3.1. ACAP Addressbook Dataset Class		2.1 Reason for Publication
	Datasets whose names begin with "/addressbook" are assumed to		This document is the result of some hard work in the mid to late
	contain addressbook entries as defined in this specification.		1990s. Given the current direction of the market for which this
			protocol was designed, it appears relatively unlikely the specific
			combination of ACAP [4] with this specification will be widely
			deployed on the Internet. However, the author believes this work
			will be valuable for future reference by those working on personal
			address book systems.
	3.2. ACAP Addressbook Capability		3. ACAP Personal Addressbooks
	The "addressbook.Expand.Address" and "addressbook.Expand.Complete"		3.1 ACAP Addressbook Dataset Class
	attributes require active client or server support. The attribute
	"capability.addressbook.expand" in the "/capability/~/addressbook"
	entry is non-NIL if they are supported.
	3.3. ACAP Addressbook Hierarchy		Datasets whose names begin with "/addressbook" are assumed to contain
			addressbook entries as defined in this specification.
	Hierarchical addressbooks SHOULD be represented using ACAP		3.2 ACAP Addressbook Capability
	hierarchy. Any entry in an addressbook can also be a hierarchy
	node by setting the "subdataset" attribute. This structure is used
	to represent both sub-addressbooks and mailing lists.
	3. Recommended ACAP Attributes		The "addressbook.Expand.Address" and "addressbook.Expand.Complete"
			attributes require active client or server support. The attribute
			"capability.addressbook.expand" in the "/capability/~/addressbook"
			entry is non-NIL if they are supported.
	The following attributes MAY be used in an ACAP addressbook entry.		3.3 ACAP Addressbook Hierarchy
	An addressbook entry MUST have an "entry" attribute, and one or
	more of "addressbook.Alias", "addressbook.CommonName" and
	"addressbook.Email" attributes. The purpose of this rule is to
	make it possible to easily select an attribute which can be
	displayed to a user.
	An addressbook entry MUST have at most one of the attributes		Hierarchical addressbooks SHOULD be represented using ACAP hierarchy.
	"addressbook.List", "addressbook.Reference", and		Any entry in an addressbook can also be a hierarchy node by setting
	"addressbook.Email". The purpose of this rule is to force each		the "subdataset" attribute. This structure is used to represent both
	entry to be either a regular addressbook entry with an Email		sub-addressbooks and mailing lists.
	address, a pointer to another addressbook entry, or a distribution
	list. In order to resolve ambiguities, if there is an
	"addressbook.List" attribute, both "addressbook.Email" and
	"addressbook.Reference" attributes MUST be ignored. If there is no
	"addressbook.List" attribute but there is an "addressbook.Email"
	attribute, then the "addressbook.Reference" attribute MUST be
	ignored. Beyond these rule, clients MAY choose any subset of these
	attributes as well as using registered private attributes. Clients
	are encouraged to provide a way to view all textual attributes in
	an entry regardless of whether the client knows the special
	semantics associated with them.
	The ABNF defines the content of the attribute values prior to their		4. Recommended ACAP Attributes
	encoding as an ACAP string. Clients MUST conform to the syntax
	when generating these attributes, but MUST NOT assume that the
	attribute values will conform to this syntax on access. Servers
	MUST NOT enforce the syntax.
	Unless otherwise stated, all attributes in this specification are		The following attributes MAY be used in an ACAP addressbook entry.
	single-valued and textual.		An addressbook entry MUST have an "entry" attribute, and one or more
			of "addressbook.Alias", "addressbook.CommonName" and
			"addressbook.Email" attributes. The purpose of this rule is to make
			it possible to easily select an attribute which can be displayed to a
			user.
	3.1. Basic Attributes		An addressbook entry MUST have at most one of the attributes
			"addressbook.List", "addressbook.Reference", and "addressbook.Email".
			The purpose of this rule is to force each entry to be either a
			regular addressbook entry with an Email address, a pointer to another
			addressbook entry, or a distribution list. In order to resolve
			ambiguities, if there is an "addressbook.List" attribute, both
			"addressbook.Email" and "addressbook.Reference" attributes MUST be
			ignored. If there is no "addressbook.List" attribute but there is an
			"addressbook.Email" attribute, then the "addressbook.Reference"
			attribute MUST be ignored. Beyond these rules, clients MAY choose
			any subset of these attributes as well as using registered private
			attributes. Clients are encouraged to provide a way to view all
			textual attributes in an entry regardless of whether the client knows
			the special semantics associated with them.
	These attributes are defined in ACAP [ACAP] and have meaning in all		The ABNF defines the content of the attribute values prior to their
	dataset classes. This section describes how they are used in an		encoding as an ACAP string. Clients MUST conform to the syntax when
	addressbook dataset.		generating these attributes, but MUST NOT assume that the attribute
			values will conform to this syntax on access. Servers MUST NOT
			enforce the syntax.
	entry		Unless otherwise stated, all attributes in this specification are
	The "entry" attribute is a unique string used to refer to an		single-valued and textual.
	addressbook entry within an addressbook dataset. It is client
	defined and may not be suitable for display to users.
	subdataset		4.1 Basic Attributes
	The "subdataset" attribute is used both for addressbook
	hierarchy and for addressbook distribution lists. It
	indicates there is another addressbook dataset underneath this
	entry. If there is also an "addressbook.List" attribute, then
	this entry is an email distribution list and the subdataset
	contains the members of that list. If "subdataset" exists,
	then any "addressbook.Email" or "addressbook.Reference"
	attributes SHOULD be ignored.
	4.2. Naming Attributes		These attributes are defined in ACAP [4] and have meaning in all
			dataset classes. This section describes how they are used in an
			addressbook dataset.
	These attributes contain information about the name of the person		entry
	or entity to which the entry refers.
	addressbook.CommonName		The "entry" attribute is a unique string used to refer to an
	The "addressbook.CommonName" attribute holds the full common		addressbook entry within an addressbook dataset. It is client
	name of the person or entity to which the addressbook entry		defined and may not be suitable for display to users.
	refers. If a person or entity has multiple names, they may be
	stored in the "addressbook.AlternateNames" attribute.
	abook-common-name = 1*TEXT-UTF8-CHAR		subdataset
	addressbook.GivenName		The "subdataset" attribute is used both for addressbook hierarchy
	The "addressbook.GivenName" attribute holds the given name of		and for addressbook distribution lists. It indicates there is
	the person to which the addressbook entry refers.		another addressbook dataset underneath this entry. If there is
			also an "addressbook.List" attribute, then this entry is an email
			distribution list and the subdataset contains the members of that
			list. If "subdataset" exists, then any "addressbook.Email" or
			"addressbook.Reference" attributes SHOULD be ignored.
	abook-given-name = 1*TEXT-UTF8-CHAR		4.2 Naming Attributes
	addressbook.Surname		These attributes contain information about the name of the person or
	The "addressbook.Surname" attribute holds the surname (or		entity to which the entry refers.
	family name) of the person to which the addressbook entry
	refers.
	abook-surname = 1*TEXT-UTF8-CHAR		addressbook.CommonName
	addressbook.MiddleName		The "addressbook.CommonName" attribute holds the full common name
	This holds the middle name(s) or initial(s) of the person to		of the person or entity to which the addressbook entry refers. If
	which the addressbook entry refers.		a person or entity has multiple names, they may be stored in the
			"addressbook.AlternateNames" attribute.
	abook-middle = 1*TEXT-UTF8-CHAR		abook-common-name = 1*TEXT-UTF8-CHAR
	addressbook.Prefix		addressbook.GivenName
	This holds any prefixes (e.g., "Mr.", "Mrs.") for the person
	to which the addressbook entry refers.
	abook-prefix = 1*TEXT-UTF8-CHAR		The "addressbook.GivenName" attribute holds the given name of the
			person to which the addressbook entry refers.
	addressbook.Suffix		abook-given-name = 1*TEXT-UTF8-CHAR
	This holds any suffixes (e.g., "Jr.", "M.D.") for the person
	to which the addressbook entry refers.
	abook-suffix = 1*TEXT-UTF8-CHAR		addressbook.Surname
	addressbook.AlternateNames		The "addressbook.Surname" attribute holds the surname (or family
	This is a multi-value attribute containing a list of alternate		name) of the person to which the addressbook entry refers.
	names for the entry. Short attributes describing the use of
	the alternate name may follow the name, separated by a NUL
	character.
	abook-alt-name = 1*TEXT-UTF8-CHAR *(NUL 1*TEXT-UTF8-CHAR)		abook-surname = 1*TEXT-UTF8-CHAR
	;; multi-valued
	addressbook.Alias		addressbook.MiddleName
	A shorthand way to refer to this entry (e.g. a nickname).
	Clients MUST NOT store characters which fall into the class of
	"white-space" or "specials" as defined in Internet Message
	Format [IMAIL] with the exception of period ("."). The alias
	is typically used by clients as a way for users to quickly
	refer to a particular addressbook entry via a type-in field.
	For this to work best, clients are encouraged to avoid using
	the same alias in multiple entries within a dataset.
	abook-alias = 1*<"." or any TEXT-UTF8-CHAR except		This holds the middle name(s) or initial(s) of the person to which
	white-space or specials as defined in [IMAIL]>		the addressbook entry refers. If there are multiple such names or
			initials, they are separated by a space.
	addressbook.CommonName.MIME		abook-middle = 1*TEXT-UTF8-CHAR
	This contains the CommonName encoded as a US-ASCII string
	according to the rules in MIME Headers [MIME-HDRS]. This is
	set when a personal addressbook entry is created from an
	Internet Mail Address [IMAIL] which uses MIME Header encoding
	for the common name portion of the address. This is the
	preferred attribute to use for the phrase portion of the
	Internet Mail Address as it preserves the sender's preferred
	character set. Otherwise, the phrase is constructed from the
	"addressbook.CommonName" field with all non US-ASCII
	characters encoded according to MIME headers using UTF-8.
	This attribute SHOULD be NIL if the CommonName is made up of
	only US-ASCII characters or the sender's preferred character
	set is UTF-8.
	abook-mime-hdr = phrase		addressbook.Prefix
	;; as defined in [IMAIL]
	4.3. Reference Attribute		This holds any prefixes (e.g., "Mr.", "Mrs.") for the person to
			which the addressbook entry refers.
	addressbook.Reference		abook-prefix = 1*TEXT-UTF8-CHAR
	This addressbook entry is a reference to another ACAP
	addressbook entry, or an LDAP white pages entry. The
	reference is in the form of a relative URL. Clients SHOULD
	support this attribute for the local ACAP server and MAY
	support it for other ACAP or LDAP servers.
	abook-reference = relativeURL		addressbook.Suffix
	;; as defined in [REL-URL]
	;; ACAP relative URL is defined in [ACAP]
	4.4. Computer Communication Attributes		This holds any suffixes (e.g., "Jr.", "M.D.") for the person to
			which the addressbook entry refers.
	These attributes are related to computer communication. The format		abook-suffix = 1*TEXT-UTF8-CHAR
	for email addresses MUST be canonicalized so it is suitable for use
	in both [IMAIL] and [SMTP]. This uses terminals from [IMAIL],
	except that free insertion of linear-white-space is not permitted.
	Unnecessary quoting SHOULD NOT be used.
	canon-addr-spec = canon-local-part "@" domain		addressbook.AlternateNames
	canon-local-part = quoted-string / (atom *("." atom))		This is a multi-value attribute containing a list of alternate
			names for the entry. Short attributes describing the use of the
			alternate name may follow the name, separated by a NUL character.
	addressbook.Email		NUL = %x00 ; US-ASCII NUL character
	The primary email address for contacting the person or entity
	to which this entry refers.
	abook-email = canon-addr-spec		abook-alt-name = 1*TEXT-UTF8-CHAR *(NUL 1*TEXT-UTF8-CHAR)
			; multi-valued
	addressbook.EmailOther		addressbook.Alias
	This is a multi-valued attribute containing alternate email
	addresses for the user. The purpose of a particular email
	address may be included in short tokens after the address,
	separated by a NUL.
	abook-emailother = canon-addr-spec *(NUL 1*TEXT-UTF8-CHAR)		A shorthand way to refer to this entry (e.g., a nickname).
			Clients are discouraged from storing characters which fall into
			the class of "white-space" or "specials" as defined in Internet
			Message Format [21] with the exception of period ("."). The alias
			is typically used by clients as a way for users to quickly refer
			to a particular addressbook entry via a type-in field. For this
			to work best, clients are encouraged to avoid using the same alias
			in multiple entries within a dataset.
	addressbook.List		abook-alias = 1*<"." or any TEXT-UTF8-CHAR except
	If both this attribute and the "subdataset" attribute exist		white-space or specials as
	then this entry is an email distribution list. The entries in		defined in RFC 2822>
	the subdataset are the members of the list. When this
	attribute exists, then any "addressbook.Email" or
	"addressbook.Reference" attributes SHOULD be ignored.
	abook-list = "1"		4.3 Reference Attribute
	addressbook.Expand.Address		addressbook.Reference
	This is an operational attribute which is present if the ACAP
	server announces the ADDRESSBOOK capability. It's value is
	computed by the ACAP server. The result is a CRLF-separated
	list of all the values from the addressbook.Email attributes
	of this entry, any entry referred to by
	"addressbook.Reference" on the local server, and any entries
	contained in the "subdataset" on this server. This expansion
	is recursive.
	abook-expand-addr = canon-addr-spec *(CRLF canon-addr-spec)		This addressbook entry is a reference to another ACAP addressbook
			entry, or an LDAP white pages entry. The reference is in the form
			of a relative or absolute URI [6]. Clients SHOULD support this
			attribute for the local ACAP server and MAY support it for other
			ACAP or LDAP servers.
	addressbook.Expand.Complete		abook-reference = relativeURI / absoluteURI
	This is an operational attribute which is present if the ACAP		; as defined in RFC 2396
	server announces the ADDRESSBOOK capability. Its value is
	computed by the ACAP server. The result is a CRLF-separated
	list of all the Internet Mail Addresses as computed from the
	addressbook.Email, addressbook.CommonName, and
	addressbook.CommonName.MIME attributes. The entry itself, any
	entry referred to by "addressbook.Reference" on the local
	server, and any entries contained in the "subdataset" on the
	local server are expanded. This expansion is recursive.
	abook-expand-compl = mailbox *(CRLF mailbox)		4.4 Computer Communication Attributes
	;; mailbox defined in [IMAIL] without folding
	addressbook.List.Subscribe		These attributes are related to computer communication. The format
	This entry contains a URL [BASIC-URL] for the subscription		for email addresses MUST be canonicalized so it is suitable for use
	address of the mailing list to which this entry refers (mailto		over SMTP [7]. Linear-white-space and obsolete address formats from
	URLs are preferred). Any unknown "?<searchpart>" portions of		Internet Message Format [21] are not permitted in a canon-addr-spec.
	a mailto URL in this context are ignored to permit future		The canonical format for a "mailbox" eliminates folding and obsolete
	extension.		formats.
	abook-subscribe = url		canon-addr-spec = Local-part "@" Domain
			; Terminals defined in RFC 2821
	addressbook.List.Unsubscribe		canon-disp-name = (Atom / Quoted-string)
	This entry contains a URL [BASIC-URL] for the un-subscription		*(SP (Atom / Quoted-string))
	address of the mailing list to which this entry refers (mailto		; Terminals defined in RFC 2821
	URLs are preferred). Any unknown "?<searchpart>" portions of
	a mailto URL in this context are ignored to permit future
	extension.
	abook-unsubscribe = url		canon-mailbox = canon-disp-name SP "<" canon-addr-spec ">"
	addressbook.List.Help		canon-address = canon-mailbox / canon-addr-spec
	This entry contains a URL [BASIC-URL] for help information
	about the mailing list to which this entry refers. Any
	unknown "?<searchpart>" portions of a mailto URL in this
	context are ignored to permit future extension.
	abook-listhelp = url		addressbook.CommonName.MIME
	addressbook.Subscribed		This contains the CommonName encoded as a US-ASCII string
	If this attribute is non-NIL, then the entry refers to a		according to the rules in MIME Headers [1]. This is set when a
	mailing list address to which the addressbook's owner is		personal addressbook entry is created from an Internet Mail
	currently subscribed.		Address [21] which uses MIME Header encoding for the common name
			portion of the address. This is the preferred attribute to use
			for the phrase portion of the Internet Mail Address as it
			preserves the sender's preferred character set. Otherwise, the
			phrase is constructed from the "addressbook.CommonName" field with
			all non US-ASCII characters encoded according to MIME headers
			using UTF-8. This attribute SHOULD be NIL if the CommonName is
			made up of only US-ASCII characters or the sender's preferred
			character set is UTF-8.
	abook-subscribed = "1"		abook-mime-hdr = canon-disp-name
	addressbook.HomePage		addressbook.Email
	This contains the URL [BASIC-URL] to the primary home page
	describing the person or entity to which the addressbook entry
	refers.
	abook-home-page = url		The primary email address for contacting the person or entity to
	;; as defined in [BASIC-URL]		which this entry refers.
	addressbook.HomePageOther		abook-email = canon-addr-spec
	This is a multi-valued attribute containing alternate home
	page URLs for the person or entity to which the addressbook
	entry refers.
	4.5. Telephone Number Attributes		addressbook.EmailOther
	Fully qualified international form is preferred for telephone		This is a multi-valued attribute containing alternate email
	numbers		addresses for the user. The purpose of a particular email address
	+1 555 555 1234 ext 54		may be included in short tokens after the address, separated by a
	but as these are likely to be human-entered any form is permitted.		NUL.
	A telephone number may be qualified with attributes describing its		abook-emailother = canon-addr-spec *(NUL 1*TEXT-UTF8-CHAR)
	uses. These attributes are separated from the number by a NUL
	character. The following attributes are initially defined:
	home This is a residence phone number		addressbook.List
	work This is an office phone number
	msg This number has voice messaging support
	cell This is a cellular telephone number
	voice This number is a voice number
	fax This number has fax support
	modem This number has modem support
	pager This is a pager number
	Thus a number such as:		If both this attribute and the "subdataset" attribute exist then
			this entry is an email distribution list. The entries in the
			subdataset are the members of the list. When this attribute
			exists, then any "addressbook.Email" or "addressbook.Reference"
			attributes SHOULD be ignored.
	+1 555 555 1234 ext 54<NUL>office<NUL>voice<NUL>msg		abook-list = "1"
	Indicates an office voice phone with voice messaging. The		addressbook.Expand.Address
	intention is to keep the telephone attributes aligned with the
	vCARD [VCARD] specification.
	The formal syntax is as follows:		This is an operational attribute which is present if the ACAP
			server announces the ADDRESSBOOK capability. Its value is
			computed by the ACAP server. The result is a CRLF-separated list
			of all the values from the addressbook.Email attributes of this
			entry, any entry referred to by "addressbook.Reference" on the
			local server, and any entries contained in the "subdataset" on
			this server. This expansion is recursive.
	abook-phone = 1*TEXT-UTF8-CHAR		abook-expand-addr = canon-addr-spec *(CRLF canon-addr-spec)
	*(NUL abook-use-attribute)
	abook-use-attribute = "home" / "work" / "msg" / "cell" / "voice" /		addressbook.Expand.Complete
	"fax" / "modem" / "pager" / abook-use-ext
	abook-use-ext = 1*ATOM-CHAR		This is an operational attribute which is present if the ACAP
	;; as defined by future RFCs		server announces the ADDRESSBOOK capability. Its value is
			computed by the ACAP server. The result is a CRLF-separated list
			of all the Internet Mail Addresses as computed from the
			addressbook.Email, addressbook.CommonName, and
			addressbook.CommonName.MIME attributes. The entry itself, any
			entry referred to by "addressbook.Reference" on the local server,
			and any entries contained in the "subdataset" on the local server
			are expanded. This expansion is recursive.
	addressbook.Telephone		abook-expand-compl = canon-address *(CRLF canon-address)
	This is the primary telephone number for the person referred
	to by the entry.
	addressbook.TelephoneOther		addressbook.List.Subscribe
	This multi-valued attribute may hold additional telephone
	numbers.
	4.6. Postal Address Attributes		This entry contains a URI [6] for the subscription address of the
			mailing list to which this entry refers (mailto URLs [15] are
			preferred). Any unknown "?<searchpart>" portions of a mailto URL
			in this context are ignored to permit future extension. The
			addressbook.List attributes are based on the List-* headers
			defined in The Use of URLs as Meta-Syntax for Core Mail List
			Commands and their Transport through Message Header Fields [16].
	Postal addresses should be in the same format that they appear on		abook-subscribe = absoluteURI
	an envelope, preferably fully qualified. The multiple lines are
	CRLF separated within the attribute.
	addressbook.Postal		addressbook.List.Unsubscribe
	This contains the preferred postal address for the person or
	entity referred to by the entry. Attributes may be added to
	the end of the address with a NUL separator. The attributes
	"home" and "work" are initially defined to refer to home and
	work addresses.
	abook-postal = 1*TEXT-UTF8-CHAR *(CRLF *TEXT-UTF8-CHAR)		This entry contains a URI [6] for the un-subscription address of
	*(NUL abook-postal-attr)		the mailing list to which this entry refers (mailto URLs are
			preferred). Any unknown "?<searchpart>" portions of a mailto URL
			in this context are ignored to permit future extension.
	abook-postal-attr = "home" / "work" / abook-use-ext		abook-unsubscribe = absoluteURI
	addressbook.PostalOther		addressbook.List.Help
	This is a multi-valued attribute which contains alternate
	postal addresses. This uses the same syntax as the Postal
	attribute.
	4.7. Commentary Attributes		This entry contains a URI [6] for help information about the
			mailing list to which this entry refers. Any unknown
			"?<searchpart>" portions of a mailto URL in this context are
			ignored to permit future extension.
	These are free-form text attributes used to store commentary about		abook-listhelp = absoluteURI
	the entry.
	addressbook.Comment		addressbook.Subscribed
	This is a free-form comment field where the owner of the
	addressbook may put comments about the person or entity
	referred to by the entry.
	abook-comment = 1*UTF8-CHAR		If this attribute is non-NIL, then the entry refers to a mailing
			list address to which the addressbook's owner is currently
			subscribed.
	addressbook.Description		abook-subscribed = "1"
	This is a free-form comment field for a self-description of
	the person or entity referred to by the entry. It is
	primarily used when an entry is imported from a remote
	directory.
	abook-description = 1*UTF8-CHAR		addressbook.HomePage
	4.8. Locational Attributes		This contains the URI [6] to the primary home page describing the
			person or entity to which the addressbook entry refers.
	These contain information about the location of the person or		abook-home-page = absoluteURI
	entity referred to by this entry.
	addressbook.Organization		addressbook.HomePageOther
	If the person or entity to which the entry refers is a member
	of an organization, this attribute contains the name of that
	organization.
	abook-organization = 1*TEXT-UTF8-CHAR		This is a multi-valued attribute containing alternate home page
			URLs for the person or entity to which the addressbook entry
			refers.
	addressbook.Title		abook-home-page = absoluteURI
	This is the title of the person referred to by the entry.
	abook-title = 1*TEXT-UTF8-CHAR		4.5 Telephone Number Attributes
	addressbook.Locality		Fully qualified international form is preferred for telephone numbers
	This is the name of the locality where the person or entity is
	normally located.
	abook-locality = 1*TEXT-UTF8-CHAR		+1 555 555 1234 ext 54
	addressbook.Country		but as these are likely to be human-entered any form is permitted.
	This is the ISO 3166 country code where the person or entity
	is normally located.
	abook-country = 2*3ALPHA		A telephone number may be qualified with attributes describing its
			uses. These attributes are separated from the number by a NUL
			character. The following attributes are initially defined:
	addressbook.Language		home This is a residence phone number
	This is the language code [LANG-TAGS] for the language which		work This is an office phone number
	the person or entity prefers to speak.		msg This number has voice messaging support
			cell This is a cellular telephone number
			voice This number is a voice number
			fax This number has fax support
			modem This number has modem support
			pager This is a pager number
	abook-language = Language-Tag		Thus a number such as:
	;; as defined in [LANG-TAGS]
	addressbook.LanguageOther		+1 555 555 1234 ext 54<NUL>office<NUL>voice<NUL>msg
	This is a multi-valued attribute containing language tags
	[LANG-TAGS] for alternate languages which the person or entity
	can speak.
	4.9. PGP Public Keys		Indicates an office voice phone with voice messaging. The intention
			is to keep the telephone attributes aligned with the vCARD [VCARD]
			specification.
	The PGP public key for a correspondent MAY be included in the		The formal syntax is as follows:
	addressbook entry. Note that a field is not defined at this time
	for X.509 public keys, but may be defined in the future when an
	IETF profile of X.509 public keys is completed.
	addressbook.PGP.bin		abook-phone = 1*TEXT-UTF8-CHAR
	This holds the binary form of the primary signature PGP public		*(NUL abook-use-attribute)
	key for the person or entity referred to by the addressbook
	entry. The format is as documented in [PGP-FMT]. Clients
	MUST check the version number field to permit future versions.
	abook-pgp = *OCTET		abook-use-attribute = "home" / "work" / "msg" / "cell" / "voice"
	;; as defined in [PGP-FMT]		/ "fax" / "modem" / "pager" / abook-use-ext
	addressbook.PGPOther.bin		abook-use-ext = 1*ATOM-CHAR
	This is a multi-valued attribute containing alternate PGP		; see ACAP base spec for ATOM-CHAR
	public keys for this entry. It is assumed that the purpose		; reserved for future extension
	for the alternate keys is encoded in the key format itself.
	5. Examples		addressbook.Telephone
	Some sample entries:		This is the primary telephone number for the person referred to by
			the entry.
	In addressbook /addressbook/user/hubert		abook-telephone = abook-phone
	attribute name value		addressbook.TelephoneOther
	-------------- -----
	entry ABC123
	addressbook.CommonName Patrik Faltstrom
	addressbook.GivenName Patrik
	addressbook.Surname Faltstrom
	addressbook.Email paf@swip.net
	addressbook.CommonName.MIME =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=
	addressbook.Expand.Address paf@swip.net
	addressbook.Expand.Complete
	=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@swip.net>
	entry ABC567		This multi-valued attribute may hold additional telephone numbers.
	addressbook.CommonName Terry Gray
	addressbook.GivenName Terry
	addressbook.Surname Gray
	addressbook.Alias teg
	addressbook.Email gray@cac.washington.edu
	addressbook.Expand.Address gray@cac.washington.edu
	addressbook.Expand.Complete Terry Gray <gray@cac.washington.edu>
	entry defghi		abook-phone-other = abook-phone
	subdataset .
	addressbook.List 1
	addressbook.CommonName List of Two
	addressbook.CommonName.MIME List of Two
	addressbook.Expand.Address paf@swip.net
	gray@cac.washington.edu
	fred@bedrock.com
	addressbook.Expand.Complete
	=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@swip.net>
	Terry Gray <gray@cac.washington.edu>
	Fred Flintstone <fred@bedrock.com>
	In dataset /addressbook/user/hubert/defghi		4.6 Postal Address Attributes
	entry xyz1		Postal addresses should be in the same format that they appear on an
	addressbook.Reference ../ABC123		envelope, preferably fully qualified. The multiple lines are CRLF
	addressbook.Expand.Address paf@swip.net		separated within the attribute.
	addressbook.Expand.Complete
	=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@swip.net>
	entry xyz2		addressbook.Postal
	addressbook.Reference ../ABC567
	addressbook.Expand.Address gray@cac.washington.edu
	addressbook.Expand.Complete Terry Gray <gray@cac.washington.edu>
	entry z2t		This contains the preferred postal address for the person or
	addressbook.CommonName Fred Flintstone		entity referred to by the entry. Attributes may be added to the
	addressbook.GivenName Fred		end of the address with a NUL separator. The attributes "home"
	addressbook.Surname Flintstone		and "work" are initially defined to refer to home and work
	addressbook.Email fred@bedrock.com		addresses.
	addressbook.CommonName.MIME Fred Flintstone
	addressbook.Expand.Address fred@bedrock.com
	addressbook.Expand.Complete Fred Flintstone <fred@bedrock.com>
	6. Mapping vCards to ACAP addressbooks		abook-postal = 1*TEXT-UTF8-CHAR *(CRLF *TEXT-UTF8-CHAR)
			*(NUL abook-postal-attr)
	An ACAP addressbook is a good place to store vCards [VCARD]. It		abook-postal-attr = "home" / "work" / abook-use-ext
	provides access to business cards of your contacts from any machine
	you use regularly, complete with the ability to annotate the
	contact information. This section describes a preliminary mapping
	from vCards. The intention is to map vCard attributes which do not
	have equivalents in this specification to an "addressbook.<attr>"
	attribute where <attr> is the vCard attribute name. A future
	specification will define this mapping precisely.
	7. References		addressbook.PostalOther
	[ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications:		This is a multi-valued attribute which contains alternate postal
	ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd,		addresses. This uses the same syntax as the Postal attribute.
	November 1997.
	[ACAP] Newman, Myers, "ACAP -- Application Configuration Access		abook-postalother = abook-postal
	Protocol", RFC 2244, Innosoft, Netscape, November 1997.
	[BASIC-URL] Berners-Lee, Masinter, McCahill, "Uniform Resource		4.7 Commentary Attributes
	Locators (URL)", RFC 1738, CERN, Xerox Coproration, University of
	Minnesota, December 1994.
	[IMAIL] Crocker, "Standard for the Format of ARPA Internet Text		These are free-form text attributes used to store commentary about
	Messages", STD 11, RFC 822, University of Delaware, August 1982.		the entry.
	[IMAP4] Crispin, "Internet Message Access Protocol - Version		addressbook.Comment
	4rev1", RFC 2060, University of Washington, December 1996.
	[KEYWORDS] Bradner, "Key words for use in RFCs to Indicate		This is a free-form text field where the owner of the addressbook
	Requirement Levels", RFC 2119, Harvard University, March 1997.		may put comments about the person or entity referred to by the
			entry.
	[LANG-TAGS] Alvestrand, H., "Tags for the Identification of		abook-comment = 1*UTF8-CHAR
	Languages", RFC 1766, March 1995.
	[MBOX-NAMES] Crocker, D., "Mailbox Names for Common Services, Roles		addressbook.Description
	and Functions", RFC 2142, Internet Mail Consortium, May 1997.
	[PGP-FMT] Atkins, Stallings, Zimmermann, "PGP Message Exchange		This is a free-form comment field for a self-description of the
	Formats", RFC 1991, MIT, Comp-Comm Consulting, Boulder Software		person or entity referred to by the entry. It is primarily used
	Engineering, August 1996.		when an entry is imported from a remote directory.
	[REL-URL] Fielding, "Relative Uniform Resource Locators", RFC 1808,		abook-description = 1*UTF8-CHAR
	UC Irvine, June 1995.
	[SMTP] Postel, "Simple Mail Transfer Protocol", RFC 821,		4.8 Locational Attributes
	Information Sciences Institute, August 1982.
	[UTF8] Yergeau, "UTF-8, a transformation format of ISO 10646",		These contain information about the location of the person or entity
	RFC 2279, Alis Technologies, January 1998.		referred to by this entry.
	[VCARD] Dawson, Howes, "vCard MIME Directory Profile", Lotus,		addressbook.Organization
	Netscape Communications, Work in Progress.
	[WHITE-SCHEMA] Genovese, Jennings, "A Common Schema for the		If the person or entity to which the entry refers is a member of
	Internet White Pages Service", RFC 2218, Microsoft, Sandia National		an organization, this attribute contains the name of that
	Laboratory, October 1997.		organization.
	8. Security Considerations		abook-organization = 1*TEXT-UTF8-CHAR
	It is important to make sure that access controls are set correctly		addressbook.Title
	on personal addressbooks. One should be careful of sharing
	information which might contain personal comments.
	If PGP public keys are stored in a personal addressbook it would be		This is the title of the person referred to by the entry.
	wise to use an ACAP protocol security layer which provides at least
	integrity protection.
	9. Authors' Addresses		abook-title = 1*TEXT-UTF8-CHAR
	Chris Newman		addressbook.Locality
	Innosoft International, Inc.
	1050 Lakes Drive
	West Covina, CA 91790 USA
	Email: chris.newman@innosoft.com		This is the name of the locality where the person or entity is
	Steve Hubert		normally located.
	Networks and Distributed Computing
	University of Washington
	4545 15th Ave. NorthEast
	Seattle, WA 98105-4527 USA
	Email: hubert@cac.washington.edu		abook-locality = 1*TEXT-UTF8-CHAR
	Appendix		addressbook.Country
	A. Attribute Index		This is the country code [23] where the person or entity is
			normally located.
	addressbook.Alias .......................................... 4		abook-country = 2*3ALPHA
	addressbook.AlternateNames ................................. 4
	addressbook.Comment ........................................ 9		addressbook.Language
	addressbook.CommonName ..................................... 3
	addressbook.CommonName.MIME ................................ 4		This is the language code [8] for the language which the person or
	addressbook.Country ........................................ 10		entity prefers to speak.
	addressbook.Description .................................... 9
	addressbook.Email .......................................... 5		abook-language = Language-Tag
	addressbook.EmailOther ..................................... 5		; as defined in RFC 3066
	addressbook.Expand.Address ................................. 6
	addressbook.Expand.Complete ................................ 6		addressbook.LanguageOther
	addressbook.GivenName ...................................... 3
	addressbook.HomePage ....................................... 7		This is a multi-valued attribute containing language tags for
	addressbook.HomePageOther .................................. 7		alternate languages which the person or entity can speak.
	addressbook.Language ....................................... 10
	addressbook.LanguageOther .................................. 10		abook-languageother = Language-Tag
	addressbook.List ........................................... 5		; as defined in RFC 3066
	addressbook.List.Help ...................................... 7
	addressbook.List.Subscribe ................................. 6		4.9 Public Keys
	addressbook.List.Unsubscribe ............................... 6
	addressbook.Locality ....................................... 9		The PGP [18] or S/MIME [20] public key for a correspondent MAY be
	addressbook.MiddleName ..................................... 3		included in the addressbook entry.
	addressbook.Organization ................................... 9
	addressbook.PGP.bin ........................................ 10		addressbook.PGP.bin
	addressbook.PGPOther.bin ................................... 10
	addressbook.Postal ......................................... 8		This holds the binary form of the primary signature PGP public key
	addressbook.PostalOther .................................... 9		for the person or entity referred to by the addressbook entry.
	addressbook.Prefix ......................................... 3		The format is as documented in [18]. Clients MUST check the
	addressbook.Reference ...................................... 5		version number field to permit future versions.
	addressbook.Subscribed ..................................... 7
	addressbook.Suffix ......................................... 3		abook-pgp = *OCTET
	addressbook.Surname ........................................ 3		; as defined in RFC 2440
	addressbook.Telephone ...................................... 8
	addressbook.TelephoneOther ................................. 8		addressbook.PGPOther.bin
	addressbook.Title .......................................... 9
	entry ...................................................... 2		This is a multi-valued attribute containing alternate PGP public
	subdataset ................................................. 2		keys for this entry. It is assumed that the purpose for the
			alternate keys is encoded in the key format itself.
			abook-pgp-other = *OCTET
			; as defined in RFC 2440
			addressbook.SMIMEv3.bin
			This holds the binary form of the primary signature S/MIME public
			key for the person or entity referred to by the addressbook entry.
			abook-smime3 = *OCTET
			; as defined in RFC 2633
			addressbook.SMIMEv3Other.bin
			This is a multi-valued attribute containing alternate S/MIME
			public keys for the person or entity referred to by the
			addressbook entry. It is assumed that the purpose for the
			alternate keys is encoded in the key format itself.
			abook-smime3-other = *OCTET
			; as defined in RFC 2633
			5. Examples
			Some sample entries from addressbook /addressbook/user/hubert:
			attribute name value
			-------------- -----
			entry ABC123
			addressbook.CommonName Patrik Faltstrom
			addressbook.GivenName Patrik
			addressbook.Surname Faltstrom
			addressbook.Email paf@example.com
			addressbook.CommonName.MIME =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=
			addressbook.Expand.Address paf@example.com
			addressbook.Expand.Complete
			=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@example.com>
			entry ABC567
			addressbook.CommonName Terry Gray
			addressbook.GivenName Terry
			addressbook.Surname Gray
			addressbook.Alias teg
			addressbook.Email gray@example.com
			addressbook.Expand.Address gray@example.com
			addressbook.Expand.Complete Terry Gray <gray@example.com>
			entry defghi
			subdataset .
			addressbook.List 1
			addressbook.CommonName List of Two
			addressbook.CommonName.MIME List of Two
			addressbook.Expand.Address paf@example.com
			gray@example.com
			fred@bedrock.example.com
			addressbook.Expand.Complete
			=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@example.com>
			Terry Gray <gray@example.com>
			Fred Flintstone <fred@bedrock.example.com>
			In dataset /addressbook/user/hubert/defghi:
			entry xyz1
			addressbook.Reference ../ABC123
			addressbook.Expand.Address paf@example.com
			addressbook.Expand.Complete
			=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@example.com>
			entry xyz2
			addressbook.Reference ../ABC567
			addressbook.Expand.Address gray@example.com
			addressbook.Expand.Complete Terry Gray <gray@example.com>
			entry z2t
			addressbook.CommonName Fred Flintstone
			addressbook.GivenName Fred
			addressbook.Surname Flintstone
			addressbook.Email fred@bedrock.example.com
			addressbook.CommonName.MIME Fred Flintstone
			addressbook.Expand.Address fred@bedrock.example.com
			addressbook.Expand.Complete
			Fred Flintstone <fred@bedrock.example.com>
			6. Mapping vCards to ACAP addressbooks
			An ACAP addressbook can store vCards [17]. It provides access to
			business cards of your contacts from any machine you use regularly,
			complete with the ability to annotate the contact information. The
			following table describes the mapping. A multi-valued vCard "type"
			is mapped to either a multi-valued ACAP attribute or the "preferred"
			instance is mapped to a single value ACAP attribute and other
			instances are mapped to a separate multi-valued ACAP attribute. A
			vCard "type" which may be either a URI or a binary value is mapped to
			one of two ACAP attributes named appropriately. vCard "TYPE="
			parameters from vCard types are mapped to ACAP attribute value syntax
			in a similar fashion to the addressbook.Telephone attribute. ACAP
			attributes not defined above follow the same syntax and semantics as
			an untyped vCard attribute.
			vCard "type" ACAP personal addressbook attribute(s)
			------------ --------------------------------------
			FN addressbook.CommonName
			N addressbook.Surname
			addressbook.GivenName
			addressbook.MiddleName
			addressbook.Prefix
			addressbook.Suffix
			NICKNAME addressbook.AlternateNames *1
			PHOTO addressbook.Photo.bin
			or addressbook.Photo.URI
			BDAY addressbook.Bday
			ADR addressbook.Adr *2
			LABEL addressbook.Postal
			and addressbook.PostalOther
			TEL addressbook.Telephone
			and addressbook.TelephoneOther
			EMAIL addressbook.Email *3
			addressbook.EmailOther
			MAILER addressbook.Mailer
			TZ addressbook.TZ
			GEO addressbook.GEO
			TITLE addressbook.Title
			ROLE addressbook.Role
			LOGO addressbook.Logo.bin
			addressbook.Logo.URI
			AGENT addressbook.Agent.URI
			ORG addressbook.Organization
			CATEGORIES addressbook.Categories (multi-valued)
			NOTE addressbook.Note
			PRODID addressbook.vCard.Prodid *4
			REV addressbook.vCard.Rev *4
			SORT-STRING addressbook.SortString
			SOUND addressbook.Sound.bin
			addressbook.Sound.URI
			UID addressbook.vCard.uid *4
			URL addressbook.HomePage
			VERSION addressbook.vCard.Version *4
			CLASS addressbook.vCard.Class *4
			KEY addressbook.PGP.bin *5
			KEY addressbook.SMIMEv3.bin *5
			*1 - space separated single valued attribute
			*2 - Multi-valued attribute. Each value follows vCard value syntax,
			with vCard type "TYPE=" parameters mapped in a similar fashion
			to the addressbook.Telephone attribute.
			*3 - only for "TYPE=internet". No mapping exists for other types.
			*4 - only used when mapping from a vCard
			*5 - map with appropriate "TYPE=" attribute.
			7. IANA Considerations
			This document constitutes the registration for the "addressbook"
			dataset class per section 7.3 of ACAP [4].
			Dataset class name/attribute prefix: addressbook
			Purpose: Personal addressbooks (Section 4)
			Published Specification(s): This specification
			Person and email address to contact for further information:
			See the "Author's Address" section near the end of this
			specification.
			8. Security Considerations
			An ACAP dataset class inherits the security considerations of the
			ACAP specification [4].
			Personal addressbooks have frequently been used as an extremely
			effective mechanism to distribute email-bourne worms. Recipients
			often trust active content from frequent correspondents, and the
			personal addressbook provides a convenient list of such potential
			recipients. Clients which access personal address books and support
			active content MUST have a mechanism which prevents active content
			from accessing the personal addressbook without explicit permission
			from the end-user. The risks of active content described in MIME
			Media Types [11] also apply to such clients.
			Because the use of a personal address book as a worm distribution
			list is such a serious risk, the password (or other credential) used
			to access an ACAP server holding personal addressbooks has to be
			treated with great care. If the ACAP password is stored on
			persistent media (e.g., the hard disk), it SHOULD be stored in an
			encrypted keychain which verifies a secure hash of any binary or
			active content prior to granting access to that password. The MacOS
			X keychain is an example of such a system. This secure hash
			validation is particularly important for single-sign-on mechanisms
			such as the one provided by Kerberos [9].
			An application which provides an indirect interface to an ACAP
			personal address book (e.g. via a scripting language) will inherit
			these security considerations and has to provide an authorization
			mechanism for the consumer of that interface.
			While it is common to share an organizational directory with the
			entire organization, personal addressbooks need to be treated as
			private information by default. Public exposure of otherwise private
			comments in an addressbook can have serious consequences (e.g., if an
			employee uses the alias "idiot" for his boss, that employee might be
			fired if that addressbook was exposed publicly). Therefore,
			addressbook user interfaces need to clearly indicate when the ACAP
			access controls on an addressbook dataset permit access by users
			other than the owner.
			If PGP or S/MIME public keys are stored in a remote personal
			addressbook this creates a situation where an attacker could
			substitute a different public key for the purpose of impersonating a
			correspondent. Using an ACAP protocol security layer (such as TLS
			[19] or SASL [14]) which provides at least integrity protection would
			defend against this attack. If the public key includes an
			appropriate trust chain and/or signed email address, verifying those
			items can also mitigate this attack.
			Normative References
			[1] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part
			Three: Message Header Extensions for Non-ASCII Text", RFC 2047,
			November 1996.
			[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
			Levels", BCP 14, RFC 2119, March 1997.
			[3] Crocker, D. and P. Overell, "Augmented BNF for Syntax
			Specifications: ABNF", RFC 2234, November 1997.
			[4] Newman, C. and J. Myers, "ACAP -- Application Configuration
			Access Protocol", RFC 2244, November 1997.
			[5] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
			2279, January 1998.
			[6] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
			Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
			[7] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April
			2001.
			[8] Alvestrand, H., "Tags for the Identification of Languages", BCP
			47, RFC 3066, January 2001.
			Informative References
			[9] Kohl, J. and B. Neuman, "The Kerberos Network Authentication
			Service (V5)", RFC 1510, September 1993.
			[10] Hovey, R. and S. Bradner, "The Organizations Involved in the
			IETF Standards Process", BCP 11, RFC 2028, October 1996.
			[11] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
			Extensions (MIME) Part Two: Media Types", RFC 2046, November
			1996.
			[12] Crispin, M., "Internet Message Access Protocol - Version
			4rev1", RFC 2060, December 1996.
			[13] Genovese, T. and B. Jennings, "A Common Schema for the Internet
			White Pages Service", RFC 2218, October 1997.
			[14] Myers, J., "Simple Authentication and Security Layer (SASL)",
			RFC 2222, October 1997.
			[15] Hoffman, P., Masinter, L. and J. Zawinski, "The mailto URL
			scheme", RFC 2368, July 1998.
			[16] Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax for
			Core Mail List Commands and their Transport through Message
			Header Fields", RFC 2369, July 1998.
			[17] Dawson, F. and T. Howes, "vCard MIME Directory Profile", RFC
			2426, September 1998.
			[18] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP
			Message Format", RFC 2440, November 1998.
			[19] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595,
			June 1999.
			[20] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC
			2633, June 1999.
			[21] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
			[22] Elkins, M., Del Torto, D., Levien, R. and T. Roessler, "MIME
			Security with OpenPGP", RFC 3156, August 2001.
			[23] International Organization for Standardization, "Codes for the
			representation of names of countries, 3rd edition", ISO
			Standard 3166, August 1988.
			Author's Address
			Chris Newman
			Sun Microsystems
			1050 Lakes Drive
			West Covina, CA 91790
			US
			EMail: chris.newman@sun.com
			Index
			A
			addressbook.Alias 6
			addressbook.AlternateNames 6
			addressbook.Comment 12
			addressbook.CommonName 5
			addressbook.CommonName.MIME 7
			addressbook.Country 13
			addressbook.Description 12
			addressbook.Email 8
			addressbook.EmailOther 8
			addressbook.Expand.Address 8
			addressbook.Expand.Complete 9
			addressbook.GivenName 5
			addressbook.HomePage 10
			addressbook.HomePageOther 10
			addressbook.Language 13
			addressbook.LanguageOther 13
			addressbook.List 8
			addressbook.List.Help 9
			addressbook.List.Subscribe 9
			addressbook.List.Unsubscribe 9
			addressbook.Locality 13
			addressbook.MiddleName 6
			addressbook.Organization 13
			addressbook.PGP.bin 14
			addressbook.PGPOther.bin 14
			addressbook.Postal 12
			addressbook.PostalOther 12
			addressbook.Prefix 6
			addressbook.Reference 7
			addressbook.SMIMEv3.bin 14
			addressbook.SMIMEv3Other.bin 14
			addressbook.Subscribed 9
			addressbook.Suffix 6
			addressbook.Surname 5
			addressbook.Telephone 11
			addressbook.TelephoneOther 11
			addressbook.Title 13
			E
			entry 5
			S
			subdataset 5
			Intellectual Property Statement
			The IETF takes no position regarding the validity or scope of any
			intellectual property or other rights that might be claimed to
			pertain to the implementation or use of the technology described in
			this document or the extent to which any license under such rights
			might or might not be available; neither does it represent that it
			has made any effort to identify any such rights. Information on the
			IETF's procedures with respect to rights in standards-track and
			standards-related documentation can be found in BCP-11. Copies of
			claims of rights made available for publication and any assurances of
			licenses to be made available, or the result of an attempt made to
			obtain a general license or permission for the use of such
			proprietary rights by implementors or users of this specification can
			be obtained from the IETF Secretariat.
			The IETF invites any interested party to bring to its attention any
			copyrights, patents or patent applications, or other proprietary
			rights which may cover technology that may be required to practice
			this standard. Please address the information to the IETF Executive
			Director.
			Full Copyright Statement
			Copyright (C) The Internet Society (2002). All Rights Reserved.
			This document and translations of it may be copied and furnished to
			others, and derivative works that comment on or otherwise explain it
			or assist in its implementation may be prepared, copied, published
			and distributed, in whole or in part, without restriction of any
			kind, provided that the above copyright notice and this paragraph are
			included on all such copies and derivative works. However, this
			document itself may not be modified in any way, such as by removing
			the copyright notice or references to the Internet Society or other
			Internet organizations, except as needed for the purpose of
			developing Internet standards in which case the procedures for
			copyrights defined in the Internet Standards process must be
			followed, or as required to translate it into languages other than
			English.
			The limited permissions granted above are perpetual and will not be
			revoked by the Internet Society or its successors or assignees.
			This document and the information contained herein is provided on an
			"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
			TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
			BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
			HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
			MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
			Acknowledgement
			Funding for the RFC Editor function is currently provided by the
			Internet Society.
End of changes. 159 change blocks.
	515 lines changed or deleted		392 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/