idnits 2.17.1 draft-ietf-acap-abook-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 628 has weird spacing: '...Address paf...' == Line 638 has weird spacing: '...Address gra...' == Line 646 has weird spacing: '...Address paf...' == Line 658 has weird spacing: '...Address paf...' == Line 664 has weird spacing: '...Address gra...' == (4 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 25, 2002) is 7824 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'VCARD' on line 450 == Unused Reference: '10' is defined on line 842, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 849, but no explicit reference was found in the text == Unused Reference: '22' is defined on line 879, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. '3') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2279 (ref. '5') (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 2396 (ref. '6') (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2821 (ref. '7') (Obsoleted by RFC 5321) ** Obsolete normative reference: RFC 3066 (ref. '8') (Obsoleted by RFC 4646, RFC 4647) -- Obsolete informational reference (is this intentional?): RFC 1510 (ref. '9') (Obsoleted by RFC 4120, RFC 6649) -- Obsolete informational reference (is this intentional?): RFC 2028 (ref. '10') (Obsoleted by RFC 9281) -- Obsolete informational reference (is this intentional?): RFC 2060 (ref. '12') (Obsoleted by RFC 3501) -- Obsolete informational reference (is this intentional?): RFC 2222 (ref. '14') (Obsoleted by RFC 4422, RFC 4752) -- Obsolete informational reference (is this intentional?): RFC 2368 (ref. '15') (Obsoleted by RFC 6068) -- Obsolete informational reference (is this intentional?): RFC 2426 (ref. '17') (Obsoleted by RFC 6350) -- Obsolete informational reference (is this intentional?): RFC 2440 (ref. '18') (Obsoleted by RFC 4880) -- Obsolete informational reference (is this intentional?): RFC 2633 (ref. '20') (Obsoleted by RFC 3851) -- Obsolete informational reference (is this intentional?): RFC 2822 (ref. '21') (Obsoleted by RFC 5322) Summary: 9 errors (**), 0 flaws (~~), 12 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Newman 3 Internet-Draft Sun Microsystems 4 Expires: May 26, 2003 November 25, 2002 6 ACAP Personal Addressbook Dataset Class 7 draft-ietf-acap-abook-03.txt 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on May 26, 2003. 32 Copyright Notice 34 Copyright (C) The Internet Society (2002). All Rights Reserved. 36 Abstract 38 Internet Message Access Protocol (IMAP) allows nomadic users to 39 access their mail store from any client, but it does not support 40 storage of personal addressbooks. Application Configuration Access 41 Protocol (ACAP) provides a mechanism for storage of personal 42 addressbooks. While ACAP permits the definition of vendor specific 43 solutions to this problem, having a documented addressbook dataset 44 class permits clients from different vendors to interoperably share 45 the same personal addressbooks. This specification defines an ACAP 46 dataset class for personal addressbooks. 48 Table of Contents 50 1. Conventions Used in this Document . . . . . . . . . . . . . . 3 51 2. Design Issues . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2.1 Reason for Publication . . . . . . . . . . . . . . . . . . . . 3 53 3. ACAP Personal Addressbooks . . . . . . . . . . . . . . . . . . 3 54 3.1 ACAP Addressbook Dataset Class . . . . . . . . . . . . . . . . 3 55 3.2 ACAP Addressbook Capability . . . . . . . . . . . . . . . . . 4 56 3.3 ACAP Addressbook Hierarchy . . . . . . . . . . . . . . . . . . 4 57 4. Recommended ACAP Attributes . . . . . . . . . . . . . . . . . 4 58 4.1 Basic Attributes . . . . . . . . . . . . . . . . . . . . . . . 5 59 4.2 Naming Attributes . . . . . . . . . . . . . . . . . . . . . . 5 60 4.3 Reference Attribute . . . . . . . . . . . . . . . . . . . . . 7 61 4.4 Computer Communication Attributes . . . . . . . . . . . . . . 7 62 4.5 Telephone Number Attributes . . . . . . . . . . . . . . . . . 10 63 4.6 Postal Address Attributes . . . . . . . . . . . . . . . . . . 12 64 4.7 Commentary Attributes . . . . . . . . . . . . . . . . . . . . 12 65 4.8 Locational Attributes . . . . . . . . . . . . . . . . . . . . 13 66 4.9 Public Keys . . . . . . . . . . . . . . . . . . . . . . . . . 14 67 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 68 6. Mapping vCards to ACAP addressbooks . . . . . . . . . . . . . 16 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 71 Normative References . . . . . . . . . . . . . . . . . . . . . 19 72 Informative References . . . . . . . . . . . . . . . . . . . . 19 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 21 74 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 75 Intellectual Property and Copyright Statements . . . . . . . . 23 77 1. Conventions Used in this Document 79 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 80 in this document are to be interpreted as defined in "Key words for 81 use in RFCs to Indicate Requirement Levels" [2]. 83 The attribute syntax specifications use the Augmented Backus-Naur 84 Form (ABNF) [3] notation including the core rules defined in Appendix 85 A. This also inherits ABNF rules from ACAP [4], SMTP [7], URI [6] 86 and Language Tags [8]. 88 When UTF-8 [5] is referred to in this document, it refers to an 89 encoding of Unicode version 2.0 or later, and not Unicode version 90 1.1. 92 2. Design Issues 94 Although this is not a white pages service, in order to provide more 95 consistency, this was designed to match the Common Schema for 96 Internet White Pages [13]. It was also designed to minimize email 97 client complexity, provide a clean model for personal distribution 98 lists and hierarchical addressbooks and permit storage of vCards [17] 99 for correspondents. 101 Personal addressbooks differ from white pages services because all 102 the attributes and entries are controlled by the user who owns the 103 addressbook rather than a directory administrator. The user or the 104 clients he uses may add new attributes at any time and some of these 105 attributes are not suitable for a white pages service. 107 2.1 Reason for Publication 109 This document is the result of some hard work in the mid to late 110 1990s. Given the current direction of the market for which this 111 protocol was designed, it appears relatively unlikely the specific 112 combination of ACAP [4] with this specification will be widely 113 deployed on the Internet. However, the author believes this work 114 will be valuable for future reference by those working on personal 115 address book systems. 117 3. ACAP Personal Addressbooks 119 3.1 ACAP Addressbook Dataset Class 121 Datasets whose names begin with "/addressbook" are assumed to contain 122 addressbook entries as defined in this specification. 124 3.2 ACAP Addressbook Capability 126 The "addressbook.Expand.Address" and "addressbook.Expand.Complete" 127 attributes require active client or server support. The attribute 128 "capability.addressbook.expand" in the "/capability/~/addressbook" 129 entry is non-NIL if they are supported. 131 3.3 ACAP Addressbook Hierarchy 133 Hierarchical addressbooks SHOULD be represented using ACAP hierarchy. 134 Any entry in an addressbook can also be a hierarchy node by setting 135 the "subdataset" attribute. This structure is used to represent both 136 sub-addressbooks and mailing lists. 138 4. Recommended ACAP Attributes 140 The following attributes MAY be used in an ACAP addressbook entry. 141 An addressbook entry MUST have an "entry" attribute, and one or more 142 of "addressbook.Alias", "addressbook.CommonName" and 143 "addressbook.Email" attributes. The purpose of this rule is to make 144 it possible to easily select an attribute which can be displayed to a 145 user. 147 An addressbook entry MUST have at most one of the attributes 148 "addressbook.List", "addressbook.Reference", and "addressbook.Email". 149 The purpose of this rule is to force each entry to be either a 150 regular addressbook entry with an Email address, a pointer to another 151 addressbook entry, or a distribution list. In order to resolve 152 ambiguities, if there is an "addressbook.List" attribute, both 153 "addressbook.Email" and "addressbook.Reference" attributes MUST be 154 ignored. If there is no "addressbook.List" attribute but there is an 155 "addressbook.Email" attribute, then the "addressbook.Reference" 156 attribute MUST be ignored. Beyond these rules, clients MAY choose 157 any subset of these attributes as well as using registered private 158 attributes. Clients are encouraged to provide a way to view all 159 textual attributes in an entry regardless of whether the client knows 160 the special semantics associated with them. 162 The ABNF defines the content of the attribute values prior to their 163 encoding as an ACAP string. Clients MUST conform to the syntax when 164 generating these attributes, but MUST NOT assume that the attribute 165 values will conform to this syntax on access. Servers MUST NOT 166 enforce the syntax. 168 Unless otherwise stated, all attributes in this specification are 169 single-valued and textual. 171 4.1 Basic Attributes 173 These attributes are defined in ACAP [4] and have meaning in all 174 dataset classes. This section describes how they are used in an 175 addressbook dataset. 177 entry 179 The "entry" attribute is a unique string used to refer to an 180 addressbook entry within an addressbook dataset. It is client 181 defined and may not be suitable for display to users. 183 subdataset 185 The "subdataset" attribute is used both for addressbook hierarchy 186 and for addressbook distribution lists. It indicates there is 187 another addressbook dataset underneath this entry. If there is 188 also an "addressbook.List" attribute, then this entry is an email 189 distribution list and the subdataset contains the members of that 190 list. If "subdataset" exists, then any "addressbook.Email" or 191 "addressbook.Reference" attributes SHOULD be ignored. 193 4.2 Naming Attributes 195 These attributes contain information about the name of the person or 196 entity to which the entry refers. 198 addressbook.CommonName 200 The "addressbook.CommonName" attribute holds the full common name 201 of the person or entity to which the addressbook entry refers. If 202 a person or entity has multiple names, they may be stored in the 203 "addressbook.AlternateNames" attribute. 205 abook-common-name = 1*TEXT-UTF8-CHAR 207 addressbook.GivenName 209 The "addressbook.GivenName" attribute holds the given name of the 210 person to which the addressbook entry refers. 212 abook-given-name = 1*TEXT-UTF8-CHAR 214 addressbook.Surname 216 The "addressbook.Surname" attribute holds the surname (or family 217 name) of the person to which the addressbook entry refers. 219 abook-surname = 1*TEXT-UTF8-CHAR 221 addressbook.MiddleName 223 This holds the middle name(s) or initial(s) of the person to which 224 the addressbook entry refers. If there are multiple such names or 225 initials, they are separated by a space. 227 abook-middle = 1*TEXT-UTF8-CHAR 229 addressbook.Prefix 231 This holds any prefixes (e.g., "Mr.", "Mrs.") for the person to 232 which the addressbook entry refers. 234 abook-prefix = 1*TEXT-UTF8-CHAR 236 addressbook.Suffix 238 This holds any suffixes (e.g., "Jr.", "M.D.") for the person to 239 which the addressbook entry refers. 241 abook-suffix = 1*TEXT-UTF8-CHAR 243 addressbook.AlternateNames 245 This is a multi-value attribute containing a list of alternate 246 names for the entry. Short attributes describing the use of the 247 alternate name may follow the name, separated by a NUL character. 249 NUL = %x00 ; US-ASCII NUL character 251 abook-alt-name = 1*TEXT-UTF8-CHAR *(NUL 1*TEXT-UTF8-CHAR) 252 ; multi-valued 254 addressbook.Alias 256 A shorthand way to refer to this entry (e.g., a nickname). 257 Clients are discouraged from storing characters which fall into 258 the class of "white-space" or "specials" as defined in Internet 259 Message Format [21] with the exception of period ("."). The alias 260 is typically used by clients as a way for users to quickly refer 261 to a particular addressbook entry via a type-in field. For this 262 to work best, clients are encouraged to avoid using the same alias 263 in multiple entries within a dataset. 265 abook-alias = 1*<"." or any TEXT-UTF8-CHAR except 266 white-space or specials as 267 defined in RFC 2822> 269 4.3 Reference Attribute 271 addressbook.Reference 273 This addressbook entry is a reference to another ACAP addressbook 274 entry, or an LDAP white pages entry. The reference is in the form 275 of a relative or absolute URI [6]. Clients SHOULD support this 276 attribute for the local ACAP server and MAY support it for other 277 ACAP or LDAP servers. 279 abook-reference = relativeURI / absoluteURI 280 ; as defined in RFC 2396 282 4.4 Computer Communication Attributes 284 These attributes are related to computer communication. The format 285 for email addresses MUST be canonicalized so it is suitable for use 286 over SMTP [7]. Linear-white-space and obsolete address formats from 287 Internet Message Format [21] are not permitted in a canon-addr-spec. 288 The canonical format for a "mailbox" eliminates folding and obsolete 289 formats. 291 canon-addr-spec = Local-part "@" Domain 292 ; Terminals defined in RFC 2821 294 canon-disp-name = (Atom / Quoted-string) 295 *(SP (Atom / Quoted-string)) 296 ; Terminals defined in RFC 2821 298 canon-mailbox = canon-disp-name SP "<" canon-addr-spec ">" 300 canon-address = canon-mailbox / canon-addr-spec 302 addressbook.CommonName.MIME 304 This contains the CommonName encoded as a US-ASCII string 305 according to the rules in MIME Headers [1]. This is set when a 306 personal addressbook entry is created from an Internet Mail 307 Address [21] which uses MIME Header encoding for the common name 308 portion of the address. This is the preferred attribute to use 309 for the phrase portion of the Internet Mail Address as it 310 preserves the sender's preferred character set. Otherwise, the 311 phrase is constructed from the "addressbook.CommonName" field with 312 all non US-ASCII characters encoded according to MIME headers 313 using UTF-8. This attribute SHOULD be NIL if the CommonName is 314 made up of only US-ASCII characters or the sender's preferred 315 character set is UTF-8. 317 abook-mime-hdr = canon-disp-name 319 addressbook.Email 321 The primary email address for contacting the person or entity to 322 which this entry refers. 324 abook-email = canon-addr-spec 326 addressbook.EmailOther 328 This is a multi-valued attribute containing alternate email 329 addresses for the user. The purpose of a particular email address 330 may be included in short tokens after the address, separated by a 331 NUL. 333 abook-emailother = canon-addr-spec *(NUL 1*TEXT-UTF8-CHAR) 335 addressbook.List 337 If both this attribute and the "subdataset" attribute exist then 338 this entry is an email distribution list. The entries in the 339 subdataset are the members of the list. When this attribute 340 exists, then any "addressbook.Email" or "addressbook.Reference" 341 attributes SHOULD be ignored. 343 abook-list = "1" 345 addressbook.Expand.Address 347 This is an operational attribute which is present if the ACAP 348 server announces the ADDRESSBOOK capability. Its value is 349 computed by the ACAP server. The result is a CRLF-separated list 350 of all the values from the addressbook.Email attributes of this 351 entry, any entry referred to by "addressbook.Reference" on the 352 local server, and any entries contained in the "subdataset" on 353 this server. This expansion is recursive. 355 abook-expand-addr = canon-addr-spec *(CRLF canon-addr-spec) 357 addressbook.Expand.Complete 359 This is an operational attribute which is present if the ACAP 360 server announces the ADDRESSBOOK capability. Its value is 361 computed by the ACAP server. The result is a CRLF-separated list 362 of all the Internet Mail Addresses as computed from the 363 addressbook.Email, addressbook.CommonName, and 364 addressbook.CommonName.MIME attributes. The entry itself, any 365 entry referred to by "addressbook.Reference" on the local server, 366 and any entries contained in the "subdataset" on the local server 367 are expanded. This expansion is recursive. 369 abook-expand-compl = canon-address *(CRLF canon-address) 371 addressbook.List.Subscribe 373 This entry contains a URI [6] for the subscription address of the 374 mailing list to which this entry refers (mailto URLs [15] are 375 preferred). Any unknown "?" portions of a mailto URL 376 in this context are ignored to permit future extension. The 377 addressbook.List attributes are based on the List-* headers 378 defined in The Use of URLs as Meta-Syntax for Core Mail List 379 Commands and their Transport through Message Header Fields [16]. 381 abook-subscribe = absoluteURI 383 addressbook.List.Unsubscribe 385 This entry contains a URI [6] for the un-subscription address of 386 the mailing list to which this entry refers (mailto URLs are 387 preferred). Any unknown "?" portions of a mailto URL 388 in this context are ignored to permit future extension. 390 abook-unsubscribe = absoluteURI 392 addressbook.List.Help 394 This entry contains a URI [6] for help information about the 395 mailing list to which this entry refers. Any unknown 396 "?" portions of a mailto URL in this context are 397 ignored to permit future extension. 399 abook-listhelp = absoluteURI 401 addressbook.Subscribed 403 If this attribute is non-NIL, then the entry refers to a mailing 404 list address to which the addressbook's owner is currently 405 subscribed. 407 abook-subscribed = "1" 409 addressbook.HomePage 411 This contains the URI [6] to the primary home page describing the 412 person or entity to which the addressbook entry refers. 414 abook-home-page = absoluteURI 416 addressbook.HomePageOther 418 This is a multi-valued attribute containing alternate home page 419 URLs for the person or entity to which the addressbook entry 420 refers. 422 abook-home-page = absoluteURI 424 4.5 Telephone Number Attributes 426 Fully qualified international form is preferred for telephone numbers 428 +1 555 555 1234 ext 54 430 but as these are likely to be human-entered any form is permitted. 432 A telephone number may be qualified with attributes describing its 433 uses. These attributes are separated from the number by a NUL 434 character. The following attributes are initially defined: 436 home This is a residence phone number 437 work This is an office phone number 438 msg This number has voice messaging support 439 cell This is a cellular telephone number 440 voice This number is a voice number 441 fax This number has fax support 442 modem This number has modem support 443 pager This is a pager number 445 Thus a number such as: 447 +1 555 555 1234 ext 54officevoicemsg 449 Indicates an office voice phone with voice messaging. The intention 450 is to keep the telephone attributes aligned with the vCARD [VCARD] 451 specification. 453 The formal syntax is as follows: 455 abook-phone = 1*TEXT-UTF8-CHAR 456 *(NUL abook-use-attribute) 458 abook-use-attribute = "home" / "work" / "msg" / "cell" / "voice" 459 / "fax" / "modem" / "pager" / abook-use-ext 461 abook-use-ext = 1*ATOM-CHAR 462 ; see ACAP base spec for ATOM-CHAR 463 ; reserved for future extension 465 addressbook.Telephone 467 This is the primary telephone number for the person referred to by 468 the entry. 470 abook-telephone = abook-phone 472 addressbook.TelephoneOther 474 This multi-valued attribute may hold additional telephone numbers. 476 abook-phone-other = abook-phone 478 4.6 Postal Address Attributes 480 Postal addresses should be in the same format that they appear on an 481 envelope, preferably fully qualified. The multiple lines are CRLF 482 separated within the attribute. 484 addressbook.Postal 486 This contains the preferred postal address for the person or 487 entity referred to by the entry. Attributes may be added to the 488 end of the address with a NUL separator. The attributes "home" 489 and "work" are initially defined to refer to home and work 490 addresses. 492 abook-postal = 1*TEXT-UTF8-CHAR *(CRLF *TEXT-UTF8-CHAR) 493 *(NUL abook-postal-attr) 495 abook-postal-attr = "home" / "work" / abook-use-ext 497 addressbook.PostalOther 499 This is a multi-valued attribute which contains alternate postal 500 addresses. This uses the same syntax as the Postal attribute. 502 abook-postalother = abook-postal 504 4.7 Commentary Attributes 506 These are free-form text attributes used to store commentary about 507 the entry. 509 addressbook.Comment 511 This is a free-form text field where the owner of the addressbook 512 may put comments about the person or entity referred to by the 513 entry. 515 abook-comment = 1*UTF8-CHAR 517 addressbook.Description 519 This is a free-form comment field for a self-description of the 520 person or entity referred to by the entry. It is primarily used 521 when an entry is imported from a remote directory. 523 abook-description = 1*UTF8-CHAR 525 4.8 Locational Attributes 527 These contain information about the location of the person or entity 528 referred to by this entry. 530 addressbook.Organization 532 If the person or entity to which the entry refers is a member of 533 an organization, this attribute contains the name of that 534 organization. 536 abook-organization = 1*TEXT-UTF8-CHAR 538 addressbook.Title 540 This is the title of the person referred to by the entry. 542 abook-title = 1*TEXT-UTF8-CHAR 544 addressbook.Locality 546 This is the name of the locality where the person or entity is 547 normally located. 549 abook-locality = 1*TEXT-UTF8-CHAR 551 addressbook.Country 553 This is the country code [23] where the person or entity is 554 normally located. 556 abook-country = 2*3ALPHA 558 addressbook.Language 560 This is the language code [8] for the language which the person or 561 entity prefers to speak. 563 abook-language = Language-Tag 564 ; as defined in RFC 3066 566 addressbook.LanguageOther 568 This is a multi-valued attribute containing language tags for 569 alternate languages which the person or entity can speak. 571 abook-languageother = Language-Tag 572 ; as defined in RFC 3066 574 4.9 Public Keys 576 The PGP [18] or S/MIME [20] public key for a correspondent MAY be 577 included in the addressbook entry. 579 addressbook.PGP.bin 581 This holds the binary form of the primary signature PGP public key 582 for the person or entity referred to by the addressbook entry. 583 The format is as documented in [18]. Clients MUST check the 584 version number field to permit future versions. 586 abook-pgp = *OCTET 587 ; as defined in RFC 2440 589 addressbook.PGPOther.bin 591 This is a multi-valued attribute containing alternate PGP public 592 keys for this entry. It is assumed that the purpose for the 593 alternate keys is encoded in the key format itself. 595 abook-pgp-other = *OCTET 596 ; as defined in RFC 2440 598 addressbook.SMIMEv3.bin 600 This holds the binary form of the primary signature S/MIME public 601 key for the person or entity referred to by the addressbook entry. 603 abook-smime3 = *OCTET 604 ; as defined in RFC 2633 606 addressbook.SMIMEv3Other.bin 608 This is a multi-valued attribute containing alternate S/MIME 609 public keys for the person or entity referred to by the 610 addressbook entry. It is assumed that the purpose for the 611 alternate keys is encoded in the key format itself. 613 abook-smime3-other = *OCTET 614 ; as defined in RFC 2633 616 5. Examples 618 Some sample entries from addressbook /addressbook/user/hubert: 620 attribute name value 621 -------------- ----- 622 entry ABC123 623 addressbook.CommonName Patrik Faltstrom 624 addressbook.GivenName Patrik 625 addressbook.Surname Faltstrom 626 addressbook.Email paf@example.com 627 addressbook.CommonName.MIME =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= 628 addressbook.Expand.Address paf@example.com 629 addressbook.Expand.Complete 630 =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= 632 entry ABC567 633 addressbook.CommonName Terry Gray 634 addressbook.GivenName Terry 635 addressbook.Surname Gray 636 addressbook.Alias teg 637 addressbook.Email gray@example.com 638 addressbook.Expand.Address gray@example.com 639 addressbook.Expand.Complete Terry Gray 641 entry defghi 642 subdataset . 643 addressbook.List 1 644 addressbook.CommonName List of Two 645 addressbook.CommonName.MIME List of Two 646 addressbook.Expand.Address paf@example.com 647 gray@example.com 648 fred@bedrock.example.com 649 addressbook.Expand.Complete 650 =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= 651 Terry Gray 652 Fred Flintstone 654 In dataset /addressbook/user/hubert/defghi: 656 entry xyz1 657 addressbook.Reference ../ABC123 658 addressbook.Expand.Address paf@example.com 659 addressbook.Expand.Complete 660 =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= 662 entry xyz2 663 addressbook.Reference ../ABC567 664 addressbook.Expand.Address gray@example.com 665 addressbook.Expand.Complete Terry Gray 667 entry z2t 668 addressbook.CommonName Fred Flintstone 669 addressbook.GivenName Fred 670 addressbook.Surname Flintstone 671 addressbook.Email fred@bedrock.example.com 672 addressbook.CommonName.MIME Fred Flintstone 673 addressbook.Expand.Address fred@bedrock.example.com 674 addressbook.Expand.Complete 675 Fred Flintstone 677 6. Mapping vCards to ACAP addressbooks 679 An ACAP addressbook can store vCards [17]. It provides access to 680 business cards of your contacts from any machine you use regularly, 681 complete with the ability to annotate the contact information. The 682 following table describes the mapping. A multi-valued vCard "type" 683 is mapped to either a multi-valued ACAP attribute or the "preferred" 684 instance is mapped to a single value ACAP attribute and other 685 instances are mapped to a separate multi-valued ACAP attribute. A 686 vCard "type" which may be either a URI or a binary value is mapped to 687 one of two ACAP attributes named appropriately. vCard "TYPE=" 688 parameters from vCard types are mapped to ACAP attribute value syntax 689 in a similar fashion to the addressbook.Telephone attribute. ACAP 690 attributes not defined above follow the same syntax and semantics as 691 an untyped vCard attribute. 693 vCard "type" ACAP personal addressbook attribute(s) 694 ------------ -------------------------------------- 695 FN addressbook.CommonName 696 N addressbook.Surname 697 addressbook.GivenName 698 addressbook.MiddleName 699 addressbook.Prefix 700 addressbook.Suffix 702 NICKNAME addressbook.AlternateNames *1 703 PHOTO addressbook.Photo.bin 704 or addressbook.Photo.URI 705 BDAY addressbook.Bday 706 ADR addressbook.Adr *2 707 LABEL addressbook.Postal 708 and addressbook.PostalOther 709 TEL addressbook.Telephone 710 and addressbook.TelephoneOther 711 EMAIL addressbook.Email *3 712 addressbook.EmailOther 713 MAILER addressbook.Mailer 714 TZ addressbook.TZ 715 GEO addressbook.GEO 716 TITLE addressbook.Title 717 ROLE addressbook.Role 718 LOGO addressbook.Logo.bin 719 addressbook.Logo.URI 720 AGENT addressbook.Agent.URI 721 ORG addressbook.Organization 722 CATEGORIES addressbook.Categories (multi-valued) 723 NOTE addressbook.Note 724 PRODID addressbook.vCard.Prodid *4 725 REV addressbook.vCard.Rev *4 726 SORT-STRING addressbook.SortString 727 SOUND addressbook.Sound.bin 728 addressbook.Sound.URI 729 UID addressbook.vCard.uid *4 730 URL addressbook.HomePage 731 VERSION addressbook.vCard.Version *4 732 CLASS addressbook.vCard.Class *4 733 KEY addressbook.PGP.bin *5 734 KEY addressbook.SMIMEv3.bin *5 736 *1 - space separated single valued attribute 737 *2 - Multi-valued attribute. Each value follows vCard value syntax, 738 with vCard type "TYPE=" parameters mapped in a similar fashion 739 to the addressbook.Telephone attribute. 740 *3 - only for "TYPE=internet". No mapping exists for other types. 741 *4 - only used when mapping from a vCard 742 *5 - map with appropriate "TYPE=" attribute. 744 7. IANA Considerations 746 This document constitutes the registration for the "addressbook" 747 dataset class per section 7.3 of ACAP [4]. 749 Dataset class name/attribute prefix: addressbook 751 Purpose: Personal addressbooks (Section 4) 753 Published Specification(s): This specification 755 Person and email address to contact for further information: 757 See the "Author's Address" section near the end of this 758 specification. 760 8. Security Considerations 762 An ACAP dataset class inherits the security considerations of the 763 ACAP specification [4]. 765 Personal addressbooks have frequently been used as an extremely 766 effective mechanism to distribute email-bourne worms. Recipients 767 often trust active content from frequent correspondents, and the 768 personal addressbook provides a convenient list of such potential 769 recipients. Clients which access personal address books and support 770 active content MUST have a mechanism which prevents active content 771 from accessing the personal addressbook without explicit permission 772 from the end-user. The risks of active content described in MIME 773 Media Types [11] also apply to such clients. 775 Because the use of a personal address book as a worm distribution 776 list is such a serious risk, the password (or other credential) used 777 to access an ACAP server holding personal addressbooks has to be 778 treated with great care. If the ACAP password is stored on 779 persistent media (e.g., the hard disk), it SHOULD be stored in an 780 encrypted keychain which verifies a secure hash of any binary or 781 active content prior to granting access to that password. The MacOS 782 X keychain is an example of such a system. This secure hash 783 validation is particularly important for single-sign-on mechanisms 784 such as the one provided by Kerberos [9]. 786 An application which provides an indirect interface to an ACAP 787 personal address book (e.g. via a scripting language) will inherit 788 these security considerations and has to provide an authorization 789 mechanism for the consumer of that interface. 791 While it is common to share an organizational directory with the 792 entire organization, personal addressbooks need to be treated as 793 private information by default. Public exposure of otherwise private 794 comments in an addressbook can have serious consequences (e.g., if an 795 employee uses the alias "idiot" for his boss, that employee might be 796 fired if that addressbook was exposed publicly). Therefore, 797 addressbook user interfaces need to clearly indicate when the ACAP 798 access controls on an addressbook dataset permit access by users 799 other than the owner. 801 If PGP or S/MIME public keys are stored in a remote personal 802 addressbook this creates a situation where an attacker could 803 substitute a different public key for the purpose of impersonating a 804 correspondent. Using an ACAP protocol security layer (such as TLS 805 [19] or SASL [14]) which provides at least integrity protection would 806 defend against this attack. If the public key includes an 807 appropriate trust chain and/or signed email address, verifying those 808 items can also mitigate this attack. 810 Normative References 812 [1] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part 813 Three: Message Header Extensions for Non-ASCII Text", RFC 2047, 814 November 1996. 816 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 817 Levels", BCP 14, RFC 2119, March 1997. 819 [3] Crocker, D. and P. Overell, "Augmented BNF for Syntax 820 Specifications: ABNF", RFC 2234, November 1997. 822 [4] Newman, C. and J. Myers, "ACAP -- Application Configuration 823 Access Protocol", RFC 2244, November 1997. 825 [5] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 826 2279, January 1998. 828 [6] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource 829 Identifiers (URI): Generic Syntax", RFC 2396, August 1998. 831 [7] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 832 2001. 834 [8] Alvestrand, H., "Tags for the Identification of Languages", BCP 835 47, RFC 3066, January 2001. 837 Informative References 839 [9] Kohl, J. and B. Neuman, "The Kerberos Network Authentication 840 Service (V5)", RFC 1510, September 1993. 842 [10] Hovey, R. and S. Bradner, "The Organizations Involved in the 843 IETF Standards Process", BCP 11, RFC 2028, October 1996. 845 [11] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 846 Extensions (MIME) Part Two: Media Types", RFC 2046, November 847 1996. 849 [12] Crispin, M., "Internet Message Access Protocol - Version 850 4rev1", RFC 2060, December 1996. 852 [13] Genovese, T. and B. Jennings, "A Common Schema for the Internet 853 White Pages Service", RFC 2218, October 1997. 855 [14] Myers, J., "Simple Authentication and Security Layer (SASL)", 856 RFC 2222, October 1997. 858 [15] Hoffman, P., Masinter, L. and J. Zawinski, "The mailto URL 859 scheme", RFC 2368, July 1998. 861 [16] Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax for 862 Core Mail List Commands and their Transport through Message 863 Header Fields", RFC 2369, July 1998. 865 [17] Dawson, F. and T. Howes, "vCard MIME Directory Profile", RFC 866 2426, September 1998. 868 [18] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP 869 Message Format", RFC 2440, November 1998. 871 [19] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, 872 June 1999. 874 [20] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 875 2633, June 1999. 877 [21] Resnick, P., "Internet Message Format", RFC 2822, April 2001. 879 [22] Elkins, M., Del Torto, D., Levien, R. and T. Roessler, "MIME 880 Security with OpenPGP", RFC 3156, August 2001. 882 [23] International Organization for Standardization, "Codes for the 883 representation of names of countries, 3rd edition", ISO 884 Standard 3166, August 1988. 886 Author's Address 888 Chris Newman 889 Sun Microsystems 890 1050 Lakes Drive 891 West Covina, CA 91790 892 US 894 EMail: chris.newman@sun.com 896 Index 898 A 899 addressbook.Alias 6 900 addressbook.AlternateNames 6 901 addressbook.Comment 12 902 addressbook.CommonName 5 903 addressbook.CommonName.MIME 7 904 addressbook.Country 13 905 addressbook.Description 12 906 addressbook.Email 8 907 addressbook.EmailOther 8 908 addressbook.Expand.Address 8 909 addressbook.Expand.Complete 9 910 addressbook.GivenName 5 911 addressbook.HomePage 10 912 addressbook.HomePageOther 10 913 addressbook.Language 13 914 addressbook.LanguageOther 13 915 addressbook.List 8 916 addressbook.List.Help 9 917 addressbook.List.Subscribe 9 918 addressbook.List.Unsubscribe 9 919 addressbook.Locality 13 920 addressbook.MiddleName 6 921 addressbook.Organization 13 922 addressbook.PGP.bin 14 923 addressbook.PGPOther.bin 14 924 addressbook.Postal 12 925 addressbook.PostalOther 12 926 addressbook.Prefix 6 927 addressbook.Reference 7 928 addressbook.SMIMEv3.bin 14 929 addressbook.SMIMEv3Other.bin 14 930 addressbook.Subscribed 9 931 addressbook.Suffix 6 932 addressbook.Surname 5 933 addressbook.Telephone 11 934 addressbook.TelephoneOther 11 935 addressbook.Title 13 937 E 938 entry 5 940 S 941 subdataset 5 943 Intellectual Property Statement 945 The IETF takes no position regarding the validity or scope of any 946 intellectual property or other rights that might be claimed to 947 pertain to the implementation or use of the technology described in 948 this document or the extent to which any license under such rights 949 might or might not be available; neither does it represent that it 950 has made any effort to identify any such rights. Information on the 951 IETF's procedures with respect to rights in standards-track and 952 standards-related documentation can be found in BCP-11. Copies of 953 claims of rights made available for publication and any assurances of 954 licenses to be made available, or the result of an attempt made to 955 obtain a general license or permission for the use of such 956 proprietary rights by implementors or users of this specification can 957 be obtained from the IETF Secretariat. 959 The IETF invites any interested party to bring to its attention any 960 copyrights, patents or patent applications, or other proprietary 961 rights which may cover technology that may be required to practice 962 this standard. Please address the information to the IETF Executive 963 Director. 965 Full Copyright Statement 967 Copyright (C) The Internet Society (2002). All Rights Reserved. 969 This document and translations of it may be copied and furnished to 970 others, and derivative works that comment on or otherwise explain it 971 or assist in its implementation may be prepared, copied, published 972 and distributed, in whole or in part, without restriction of any 973 kind, provided that the above copyright notice and this paragraph are 974 included on all such copies and derivative works. However, this 975 document itself may not be modified in any way, such as by removing 976 the copyright notice or references to the Internet Society or other 977 Internet organizations, except as needed for the purpose of 978 developing Internet standards in which case the procedures for 979 copyrights defined in the Internet Standards process must be 980 followed, or as required to translate it into languages other than 981 English. 983 The limited permissions granted above are perpetual and will not be 984 revoked by the Internet Society or its successors or assignees. 986 This document and the information contained herein is provided on an 987 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 988 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 989 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 990 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 991 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 993 Acknowledgement 995 Funding for the RFC Editor function is currently provided by the 996 Internet Society.