idnits 2.17.1 draft-ietf-acap-abook-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-28) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 7 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The abstract seems to contain references ([ACAP], [IMAP4]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and 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? RFC 2119 keyword, line 112: '...cal addressbooks SHOULD be represented...' RFC 2119 keyword, line 119: '...owing attributes MAY be used in an ACA...' RFC 2119 keyword, line 120: '...ddressbook entry MUST have an "entry" ...' RFC 2119 keyword, line 126: '...ddressbook entry MUST have at most one...' RFC 2119 keyword, line 133: '...ence" attributes MUST be ignored. If t...' (15 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 542 has weird spacing: '...Address paf...' == Line 552 has weird spacing: '...Address gra...' == Line 560 has weird spacing: '...Address paf...' == Line 572 has weird spacing: '...Address paf...' == Line 578 has weird spacing: '...Address gra...' == (1 more instance...) -- 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 (March 1998) is 9510 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) -- Missing reference section? 'IMAP4' on line 617 looks like a reference -- Missing reference section? 'ACAP' on line 607 looks like a reference -- Missing reference section? 'KEYWORDS' on line 620 looks like a reference -- Missing reference section? 'ABNF' on line 603 looks like a reference -- Missing reference section? 'UTF8' on line 639 looks like a reference -- Missing reference section? 'WHITE-SCHEMA' on line 645 looks like a reference -- Missing reference section? 'VCARD' on line 642 looks like a reference -- Missing reference section? 'IMAIL' on line 614 looks like a reference -- Missing reference section? 'MIME-HDRS' on line 240 looks like a reference -- Missing reference section? 'REL-URL' on line 633 looks like a reference -- Missing reference section? 'SMTP' on line 636 looks like a reference -- Missing reference section? 'BASIC-URL' on line 610 looks like a reference -- Missing reference section? 'LANG-TAGS' on line 623 looks like a reference -- Missing reference section? 'PGP-FMT' on line 629 looks like a reference -- Missing reference section? 'MBOX-NAMES' on line 626 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 7 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Newman 3 Internet Draft: ACAP Addressbook Dataset Class Innosoft 4 Document: draft-ietf-acap-abook-02.txt S. Hubert 5 University of Washington 6 March 1998 7 Expires in six months 9 ACAP Personal Addressbook Dataset Class 11 Status of this memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet-Drafts 21 as reference material or to cite them other than as "work in 22 progress." 24 To view the entire list of current Internet-Drafts, please check 25 the "1id-abstracts.txt" listing contained in the Internet-Drafts 26 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 27 (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East 28 Coast), or ftp.isi.edu (US West Coast). 30 Abstract 32 IMAP [IMAP4] allows nomadic users to access their mail store from 33 any client, but it does not support storage of personal 34 addressbooks. Application Configuration Access Protocol [ACAP] 35 provides an ideal mechanism for storage of personal addressbooks. 36 While ACAP permits the definition of vendor specific solutions to 37 this problem, having a standard addressbook dataset class permits 38 clients from different vendors to interoperably share the same 39 personal addressbooks. This specification defines a standard 40 dataset class for personal addressbooks. 42 Table of Contents 44 Status of this memo ............................................... i 45 Abstract .......................................................... i 46 1. Conventions Used in this Document ............................ 1 47 2. Design Issues ................................................ 1 48 3. ACAP Personal Addressbooks ................................... 1 49 3.1. ACAP Addressbook Dataset Class ............................... 1 50 3.2. ACAP Addressbook Capability .................................. 1 51 3.3. ACAP Addressbook Hierarchy ................................... 1 52 3. Recommended ACAP Attributes .................................. 2 53 3.1. Basic Attributes ............................................. 2 54 4.2. Naming Attributes ............................................ 3 55 4.3. Reference Attribute .......................................... 5 56 4.4. Computer Communication Attributes ............................ 5 57 4.5. Telephone Number Attributes .................................. 7 58 4.6. Postal Address Attributes .................................... 8 59 4.7. Commentary Attributes ........................................ 9 60 4.8. Locational Attributes ........................................ 9 61 4.9. PGP Public Keys .............................................. 10 62 5. Examples ..................................................... 11 63 6. Mapping vCards to ACAP addressbooks .......................... 12 64 7. References ................................................... 12 65 8. Security Considerations ...................................... 13 66 9. Authors' Addresses ............................................ 13 67 Appendix .......................................................... 15 68 A. Attribute Index .............................................. 15 69 1. Conventions Used in this Document 71 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 72 in this document are to be interpreted as defined in "Key words for 73 use in RFCs to Indicate Requirement Levels" [KEYWORDS]. 75 The attribute syntax specifications use the Augmented Backus-Naur 76 Form (ABNF) notation as specified in [ABNF]. 78 When UTF-8 [UTF8] is referred to in this document, it refers to 79 Unicode version 2.0, and not Unicode version 1.1. 81 2. Design Issues 83 Although this is not a white pages service, in order to provide 84 more consistency, this was designed to match the Common Schema for 85 Internet White Pages [WHITE-SCHEMA]. It was also designed to 86 minimize email client complexity, provide a clean model for 87 personal distribution lists and hierarchical addressbooks and 88 permit storage of vCards [VCARD] for correspondents. 90 Personal addressbooks differ from white pages services because all 91 the attributes and entries are controlled by the user who owns the 92 addressbook rather than a directory administrator. The user or the 93 clients he uses may add new attributes at any time and some of 94 these attributes are not suitable for a white pages service. 96 3. ACAP Personal Addressbooks 98 3.1. ACAP Addressbook Dataset Class 100 Datasets whose names begin with "/addressbook" are assumed to 101 contain addressbook entries as defined in this specification. 103 3.2. ACAP Addressbook Capability 105 The "addressbook.Expand.Address" and "addressbook.Expand.Complete" 106 attributes require active client or server support. The attribute 107 "capability.addressbook.expand" in the "/capability/~/addressbook" 108 entry is non-NIL if they are supported. 110 3.3. ACAP Addressbook Hierarchy 112 Hierarchical addressbooks SHOULD be represented using ACAP 113 hierarchy. Any entry in an addressbook can also be a hierarchy 114 node by setting the "subdataset" attribute. This structure is used 115 to represent both sub-addressbooks and mailing lists. 117 3. Recommended ACAP Attributes 119 The following attributes MAY be used in an ACAP addressbook entry. 120 An addressbook entry MUST have an "entry" attribute, and one or 121 more of "addressbook.Alias", "addressbook.CommonName" and 122 "addressbook.Email" attributes. The purpose of this rule is to 123 make it possible to easily select an attribute which can be 124 displayed to a user. 126 An addressbook entry MUST have at most one of the attributes 127 "addressbook.List", "addressbook.Reference", and 128 "addressbook.Email". The purpose of this rule is to force each 129 entry to be either a regular addressbook entry with an Email 130 address, a pointer to another addressbook entry, or a distribution 131 list. In order to resolve ambiguities, if there is an 132 "addressbook.List" attribute, both "addressbook.Email" and 133 "addressbook.Reference" attributes MUST be ignored. If there is no 134 "addressbook.List" attribute but there is an "addressbook.Email" 135 attribute, then the "addressbook.Reference" attribute MUST be 136 ignored. Beyond these rule, clients MAY choose any subset of these 137 attributes as well as using registered private attributes. Clients 138 are encouraged to provide a way to view all textual attributes in 139 an entry regardless of whether the client knows the special 140 semantics associated with them. 142 The ABNF defines the content of the attribute values prior to their 143 encoding as an ACAP string. Clients MUST conform to the syntax 144 when generating these attributes, but MUST NOT assume that the 145 attribute values will conform to this syntax on access. Servers 146 MUST NOT enforce the syntax. 148 Unless otherwise stated, all attributes in this specification are 149 single-valued and textual. 151 3.1. Basic Attributes 153 These attributes are defined in ACAP [ACAP] and have meaning in all 154 dataset classes. This section describes how they are used in an 155 addressbook dataset. 157 entry 158 The "entry" attribute is a unique string used to refer to an 159 addressbook entry within an addressbook dataset. It is client 160 defined and may not be suitable for display to users. 162 subdataset 163 The "subdataset" attribute is used both for addressbook 164 hierarchy and for addressbook distribution lists. It 165 indicates there is another addressbook dataset underneath this 166 entry. If there is also an "addressbook.List" attribute, then 167 this entry is an email distribution list and the subdataset 168 contains the members of that list. If "subdataset" exists, 169 then any "addressbook.Email" or "addressbook.Reference" 170 attributes SHOULD be ignored. 172 4.2. Naming Attributes 174 These attributes contain information about the name of the person 175 or entity to which the entry refers. 177 addressbook.CommonName 178 The "addressbook.CommonName" attribute holds the full common 179 name of the person or entity to which the addressbook entry 180 refers. If a person or entity has multiple names, they may be 181 stored in the "addressbook.AlternateNames" attribute. 183 abook-common-name = 1*TEXT-UTF8-CHAR 185 addressbook.GivenName 186 The "addressbook.GivenName" attribute holds the given name of 187 the person to which the addressbook entry refers. 189 abook-given-name = 1*TEXT-UTF8-CHAR 191 addressbook.Surname 192 The "addressbook.Surname" attribute holds the surname (or 193 family name) of the person to which the addressbook entry 194 refers. 196 abook-surname = 1*TEXT-UTF8-CHAR 198 addressbook.MiddleName 199 This holds the middle name(s) or initial(s) of the person to 200 which the addressbook entry refers. 202 abook-middle = 1*TEXT-UTF8-CHAR 204 addressbook.Prefix 205 This holds any prefixes (e.g., "Mr.", "Mrs.") for the person 206 to which the addressbook entry refers. 208 abook-prefix = 1*TEXT-UTF8-CHAR 210 addressbook.Suffix 211 This holds any suffixes (e.g., "Jr.", "M.D.") for the person 212 to which the addressbook entry refers. 214 abook-suffix = 1*TEXT-UTF8-CHAR 216 addressbook.AlternateNames 217 This is a multi-value attribute containing a list of alternate 218 names for the entry. Short attributes describing the use of 219 the alternate name may follow the name, separated by a NUL 220 character. 222 abook-alt-name = 1*TEXT-UTF8-CHAR *(NUL 1*TEXT-UTF8-CHAR) 223 ;; multi-valued 225 addressbook.Alias 226 A shorthand way to refer to this entry (e.g. a nickname). 227 Clients MUST NOT store characters which fall into the class of 228 "white-space" or "specials" as defined in Internet Message 229 Format [IMAIL] with the exception of period ("."). The alias 230 is typically used by clients as a way for users to quickly 231 refer to a particular addressbook entry via a type-in field. 232 For this to work best, clients are encouraged to avoid using 233 the same alias in multiple entries within a dataset. 235 abook-alias = 1*<"." or any TEXT-UTF8-CHAR except 236 white-space or specials as defined in [IMAIL]> 238 addressbook.CommonName.MIME 239 This contains the CommonName encoded as a US-ASCII string 240 according to the rules in MIME Headers [MIME-HDRS]. This is 241 set when a personal addressbook entry is created from an 242 Internet Mail Address [IMAIL] which uses MIME Header encoding 243 for the common name portion of the address. This is the 244 preferred attribute to use for the phrase portion of the 245 Internet Mail Address as it preserves the sender's preferred 246 character set. Otherwise, the phrase is constructed from the 247 "addressbook.CommonName" field with all non US-ASCII 248 characters encoded according to MIME headers using UTF-8. 249 This attribute SHOULD be NIL if the CommonName is made up of 250 only US-ASCII characters or the sender's preferred character 251 set is UTF-8. 253 abook-mime-hdr = phrase 254 ;; as defined in [IMAIL] 256 4.3. Reference Attribute 258 addressbook.Reference 259 This addressbook entry is a reference to another ACAP 260 addressbook entry, or an LDAP white pages entry. The 261 reference is in the form of a relative URL. Clients SHOULD 262 support this attribute for the local ACAP server and MAY 263 support it for other ACAP or LDAP servers. 265 abook-reference = relativeURL 266 ;; as defined in [REL-URL] 267 ;; ACAP relative URL is defined in [ACAP] 269 4.4. Computer Communication Attributes 271 These attributes are related to computer communication. The format 272 for email addresses MUST be canonicalized so it is suitable for use 273 in both [IMAIL] and [SMTP]. This uses terminals from [IMAIL], 274 except that free insertion of linear-white-space is not permitted. 275 Unnecessary quoting SHOULD NOT be used. 277 canon-addr-spec = canon-local-part "@" domain 279 canon-local-part = quoted-string / (atom *("." atom)) 281 addressbook.Email 282 The primary email address for contacting the person or entity 283 to which this entry refers. 285 abook-email = canon-addr-spec 287 addressbook.EmailOther 288 This is a multi-valued attribute containing alternate email 289 addresses for the user. The purpose of a particular email 290 address may be included in short tokens after the address, 291 separated by a NUL. 293 abook-emailother = canon-addr-spec *(NUL 1*TEXT-UTF8-CHAR) 295 addressbook.List 296 If both this attribute and the "subdataset" attribute exist 297 then this entry is an email distribution list. The entries in 298 the subdataset are the members of the list. When this 299 attribute exists, then any "addressbook.Email" or 300 "addressbook.Reference" attributes SHOULD be ignored. 302 abook-list = "1" 304 addressbook.Expand.Address 305 This is an operational attribute which is present if the ACAP 306 server announces the ADDRESSBOOK capability. It's value is 307 computed by the ACAP server. The result is a CRLF-separated 308 list of all the values from the addressbook.Email attributes 309 of this entry, any entry referred to by 310 "addressbook.Reference" on the local server, and any entries 311 contained in the "subdataset" on this server. This expansion 312 is recursive. 314 abook-expand-addr = canon-addr-spec *(CRLF canon-addr-spec) 316 addressbook.Expand.Complete 317 This is an operational attribute which is present if the ACAP 318 server announces the ADDRESSBOOK capability. Its value is 319 computed by the ACAP server. The result is a CRLF-separated 320 list of all the Internet Mail Addresses as computed from the 321 addressbook.Email, addressbook.CommonName, and 322 addressbook.CommonName.MIME attributes. The entry itself, any 323 entry referred to by "addressbook.Reference" on the local 324 server, and any entries contained in the "subdataset" on the 325 local server are expanded. This expansion is recursive. 327 abook-expand-compl = mailbox *(CRLF mailbox) 328 ;; mailbox defined in [IMAIL] without folding 330 addressbook.List.Subscribe 331 This entry contains a URL [BASIC-URL] for the subscription 332 address of the mailing list to which this entry refers (mailto 333 URLs are preferred). Any unknown "?" portions of 334 a mailto URL in this context are ignored to permit future 335 extension. 337 abook-subscribe = url 339 addressbook.List.Unsubscribe 340 This entry contains a URL [BASIC-URL] for the un-subscription 341 address of the mailing list to which this entry refers (mailto 342 URLs are preferred). Any unknown "?" portions of 343 a mailto URL in this context are ignored to permit future 344 extension. 346 abook-unsubscribe = url 348 addressbook.List.Help 349 This entry contains a URL [BASIC-URL] for help information 350 about the mailing list to which this entry refers. Any 351 unknown "?" portions of a mailto URL in this 352 context are ignored to permit future extension. 354 abook-listhelp = url 356 addressbook.Subscribed 357 If this attribute is non-NIL, then the entry refers to a 358 mailing list address to which the addressbook's owner is 359 currently subscribed. 361 abook-subscribed = "1" 363 addressbook.HomePage 364 This contains the URL [BASIC-URL] to the primary home page 365 describing the person or entity to which the addressbook entry 366 refers. 368 abook-home-page = url 369 ;; as defined in [BASIC-URL] 371 addressbook.HomePageOther 372 This is a multi-valued attribute containing alternate home 373 page URLs for the person or entity to which the addressbook 374 entry refers. 376 4.5. Telephone Number Attributes 378 Fully qualified international form is preferred for telephone 379 numbers 380 +1 555 555 1234 ext 54 381 but as these are likely to be human-entered any form is permitted. 383 A telephone number may be qualified with attributes describing its 384 uses. These attributes are separated from the number by a NUL 385 character. The following attributes are initially defined: 387 home This is a residence phone number 388 work This is an office phone number 389 msg This number has voice messaging support 390 cell This is a cellular telephone number 391 voice This number is a voice number 392 fax This number has fax support 393 modem This number has modem support 394 pager This is a pager number 396 Thus a number such as: 398 +1 555 555 1234 ext 54officevoicemsg 400 Indicates an office voice phone with voice messaging. The 401 intention is to keep the telephone attributes aligned with the 402 vCARD [VCARD] specification. 404 The formal syntax is as follows: 406 abook-phone = 1*TEXT-UTF8-CHAR 407 *(NUL abook-use-attribute) 409 abook-use-attribute = "home" / "work" / "msg" / "cell" / "voice" / 410 "fax" / "modem" / "pager" / abook-use-ext 412 abook-use-ext = 1*ATOM-CHAR 413 ;; as defined by future RFCs 415 addressbook.Telephone 416 This is the primary telephone number for the person referred 417 to by the entry. 419 addressbook.TelephoneOther 420 This multi-valued attribute may hold additional telephone 421 numbers. 423 4.6. Postal Address Attributes 425 Postal addresses should be in the same format that they appear on 426 an envelope, preferably fully qualified. The multiple lines are 427 CRLF separated within the attribute. 429 addressbook.Postal 430 This contains the preferred postal address for the person or 431 entity referred to by the entry. Attributes may be added to 432 the end of the address with a NUL separator. The attributes 433 "home" and "work" are initially defined to refer to home and 434 work addresses. 436 abook-postal = 1*TEXT-UTF8-CHAR *(CRLF *TEXT-UTF8-CHAR) 437 *(NUL abook-postal-attr) 439 abook-postal-attr = "home" / "work" / abook-use-ext 441 addressbook.PostalOther 442 This is a multi-valued attribute which contains alternate 443 postal addresses. This uses the same syntax as the Postal 444 attribute. 446 4.7. Commentary Attributes 448 These are free-form text attributes used to store commentary about 449 the entry. 451 addressbook.Comment 452 This is a free-form comment field where the owner of the 453 addressbook may put comments about the person or entity 454 referred to by the entry. 456 abook-comment = 1*UTF8-CHAR 458 addressbook.Description 459 This is a free-form comment field for a self-description of 460 the person or entity referred to by the entry. It is 461 primarily used when an entry is imported from a remote 462 directory. 464 abook-description = 1*UTF8-CHAR 466 4.8. Locational Attributes 468 These contain information about the location of the person or 469 entity referred to by this entry. 471 addressbook.Organization 472 If the person or entity to which the entry refers is a member 473 of an organization, this attribute contains the name of that 474 organization. 476 abook-organization = 1*TEXT-UTF8-CHAR 478 addressbook.Title 479 This is the title of the person referred to by the entry. 481 abook-title = 1*TEXT-UTF8-CHAR 483 addressbook.Locality 484 This is the name of the locality where the person or entity is 485 normally located. 487 abook-locality = 1*TEXT-UTF8-CHAR 489 addressbook.Country 490 This is the ISO 3166 country code where the person or entity 491 is normally located. 493 abook-country = 2*3ALPHA 495 addressbook.Language 496 This is the language code [LANG-TAGS] for the language which 497 the person or entity prefers to speak. 499 abook-language = Language-Tag 500 ;; as defined in [LANG-TAGS] 502 addressbook.LanguageOther 503 This is a multi-valued attribute containing language tags 504 [LANG-TAGS] for alternate languages which the person or entity 505 can speak. 507 4.9. PGP Public Keys 509 The PGP public key for a correspondent MAY be included in the 510 addressbook entry. Note that a field is not defined at this time 511 for X.509 public keys, but may be defined in the future when an 512 IETF profile of X.509 public keys is completed. 514 addressbook.PGP.bin 515 This holds the binary form of the primary signature PGP public 516 key for the person or entity referred to by the addressbook 517 entry. The format is as documented in [PGP-FMT]. Clients 518 MUST check the version number field to permit future versions. 520 abook-pgp = *OCTET 521 ;; as defined in [PGP-FMT] 523 addressbook.PGPOther.bin 524 This is a multi-valued attribute containing alternate PGP 525 public keys for this entry. It is assumed that the purpose 526 for the alternate keys is encoded in the key format itself. 528 5. Examples 530 Some sample entries: 532 In addressbook /addressbook/user/hubert 534 attribute name value 535 -------------- ----- 536 entry ABC123 537 addressbook.CommonName Patrik Faltstrom 538 addressbook.GivenName Patrik 539 addressbook.Surname Faltstrom 540 addressbook.Email paf@swip.net 541 addressbook.CommonName.MIME =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= 542 addressbook.Expand.Address paf@swip.net 543 addressbook.Expand.Complete 544 =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= 546 entry ABC567 547 addressbook.CommonName Terry Gray 548 addressbook.GivenName Terry 549 addressbook.Surname Gray 550 addressbook.Alias teg 551 addressbook.Email gray@cac.washington.edu 552 addressbook.Expand.Address gray@cac.washington.edu 553 addressbook.Expand.Complete Terry Gray 555 entry defghi 556 subdataset . 557 addressbook.List 1 558 addressbook.CommonName List of Two 559 addressbook.CommonName.MIME List of Two 560 addressbook.Expand.Address paf@swip.net 561 gray@cac.washington.edu 562 fred@bedrock.com 563 addressbook.Expand.Complete 564 =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= 565 Terry Gray 566 Fred Flintstone 568 In dataset /addressbook/user/hubert/defghi 570 entry xyz1 571 addressbook.Reference ../ABC123 572 addressbook.Expand.Address paf@swip.net 573 addressbook.Expand.Complete 574 =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= 576 entry xyz2 577 addressbook.Reference ../ABC567 578 addressbook.Expand.Address gray@cac.washington.edu 579 addressbook.Expand.Complete Terry Gray 581 entry z2t 582 addressbook.CommonName Fred Flintstone 583 addressbook.GivenName Fred 584 addressbook.Surname Flintstone 585 addressbook.Email fred@bedrock.com 586 addressbook.CommonName.MIME Fred Flintstone 587 addressbook.Expand.Address fred@bedrock.com 588 addressbook.Expand.Complete Fred Flintstone 590 6. Mapping vCards to ACAP addressbooks 592 An ACAP addressbook is a good place to store vCards [VCARD]. It 593 provides access to business cards of your contacts from any machine 594 you use regularly, complete with the ability to annotate the 595 contact information. This section describes a preliminary mapping 596 from vCards. The intention is to map vCard attributes which do not 597 have equivalents in this specification to an "addressbook." 598 attribute where is the vCard attribute name. A future 599 specification will define this mapping precisely. 601 7. References 603 [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: 604 ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd, 605 November 1997. 607 [ACAP] Newman, Myers, "ACAP -- Application Configuration Access 608 Protocol", RFC 2244, Innosoft, Netscape, November 1997. 610 [BASIC-URL] Berners-Lee, Masinter, McCahill, "Uniform Resource 611 Locators (URL)", RFC 1738, CERN, Xerox Coproration, University of 612 Minnesota, December 1994. 614 [IMAIL] Crocker, "Standard for the Format of ARPA Internet Text 615 Messages", STD 11, RFC 822, University of Delaware, August 1982. 617 [IMAP4] Crispin, "Internet Message Access Protocol - Version 618 4rev1", RFC 2060, University of Washington, December 1996. 620 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate 621 Requirement Levels", RFC 2119, Harvard University, March 1997. 623 [LANG-TAGS] Alvestrand, H., "Tags for the Identification of 624 Languages", RFC 1766, March 1995. 626 [MBOX-NAMES] Crocker, D., "Mailbox Names for Common Services, Roles 627 and Functions", RFC 2142, Internet Mail Consortium, May 1997. 629 [PGP-FMT] Atkins, Stallings, Zimmermann, "PGP Message Exchange 630 Formats", RFC 1991, MIT, Comp-Comm Consulting, Boulder Software 631 Engineering, August 1996. 633 [REL-URL] Fielding, "Relative Uniform Resource Locators", RFC 1808, 634 UC Irvine, June 1995. 636 [SMTP] Postel, "Simple Mail Transfer Protocol", RFC 821, 637 Information Sciences Institute, August 1982. 639 [UTF8] Yergeau, "UTF-8, a transformation format of ISO 10646", 640 RFC 2279, Alis Technologies, January 1998. 642 [VCARD] Dawson, Howes, "vCard MIME Directory Profile", Lotus, 643 Netscape Communications, Work in Progress. 645 [WHITE-SCHEMA] Genovese, Jennings, "A Common Schema for the 646 Internet White Pages Service", RFC 2218, Microsoft, Sandia National 647 Laboratory, October 1997. 649 8. Security Considerations 651 It is important to make sure that access controls are set correctly 652 on personal addressbooks. One should be careful of sharing 653 information which might contain personal comments. 655 If PGP public keys are stored in a personal addressbook it would be 656 wise to use an ACAP protocol security layer which provides at least 657 integrity protection. 659 9. Authors' Addresses 661 Chris Newman 662 Innosoft International, Inc. 663 1050 Lakes Drive 664 West Covina, CA 91790 USA 666 Email: chris.newman@innosoft.com 667 Steve Hubert 668 Networks and Distributed Computing 669 University of Washington 670 4545 15th Ave. NorthEast 671 Seattle, WA 98105-4527 USA 673 Email: hubert@cac.washington.edu 675 Appendix 677 A. Attribute Index 679 addressbook.Alias .......................................... 4 680 addressbook.AlternateNames ................................. 4 681 addressbook.Comment ........................................ 9 682 addressbook.CommonName ..................................... 3 683 addressbook.CommonName.MIME ................................ 4 684 addressbook.Country ........................................ 10 685 addressbook.Description .................................... 9 686 addressbook.Email .......................................... 5 687 addressbook.EmailOther ..................................... 5 688 addressbook.Expand.Address ................................. 6 689 addressbook.Expand.Complete ................................ 6 690 addressbook.GivenName ...................................... 3 691 addressbook.HomePage ....................................... 7 692 addressbook.HomePageOther .................................. 7 693 addressbook.Language ....................................... 10 694 addressbook.LanguageOther .................................. 10 695 addressbook.List ........................................... 5 696 addressbook.List.Help ...................................... 7 697 addressbook.List.Subscribe ................................. 6 698 addressbook.List.Unsubscribe ............................... 6 699 addressbook.Locality ....................................... 9 700 addressbook.MiddleName ..................................... 3 701 addressbook.Organization ................................... 9 702 addressbook.PGP.bin ........................................ 10 703 addressbook.PGPOther.bin ................................... 10 704 addressbook.Postal ......................................... 8 705 addressbook.PostalOther .................................... 9 706 addressbook.Prefix ......................................... 3 707 addressbook.Reference ...................................... 5 708 addressbook.Subscribed ..................................... 7 709 addressbook.Suffix ......................................... 3 710 addressbook.Surname ........................................ 3 711 addressbook.Telephone ...................................... 8 712 addressbook.TelephoneOther ................................. 8 713 addressbook.Title .......................................... 9 714 entry ...................................................... 2 715 subdataset ................................................. 2