idnits 2.17.1 draft-dawson-vcard-xml-dtd-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: ---------------------------------------------------------------------------- ** 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 1726 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) ** The abstract seems to contain references ([RFC2426], [RFC2119], [XML]), 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 141: '... namespaces MUST NOT include other n...' RFC 2119 keyword, line 177: '... This FPI MUST be used on the DOCTYP...' RFC 2119 keyword, line 180: '... This FPI SHOULD also be used to ide...' RFC 2119 keyword, line 212: '...is specification MUST be able to prope...' RFC 2119 keyword, line 288: '...ding NOTATION declaration MUST also be...' (12 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (June 22, 1998) is 9438 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? 'XML' on line 1322 looks like a reference -- Missing reference section? 'RFC2426' on line 1319 looks like a reference -- Missing reference section? 'RFC 2119' on line 1315 looks like a reference -- Missing reference section? 'RFC 2045' on line 1311 looks like a reference -- Missing reference section? 'XMLNS' on line 1325 looks like a reference -- Missing reference section? 'RFC2045' on line 307 looks like a reference -- Missing reference section? 'FPI' on line 1300 looks like a reference -- Missing reference section? 'ISO9070' on line 1306 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Frank Dawson, Lotus 2 Internet Draft 3 draft-dawson-vcard-xml-dtd-03.txt 4 Expires six months after: June 22, 1998 6 The vCard v3.0 XML DTD 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that other 15 groups may also distribute working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet- Drafts as reference 19 material or to cite them other than as "work in progress." The list 20 of current Internet-Drafts can be accessed at 21 http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft 22 Shadow Directories can be accessed at 23 http://www.ietf.org/shadow.html. 25 Distribution of this document is unlimited. 27 Copyright (C) The Internet Society 1999. All Rights Reserved. 29 Abstract 31 This memo defines a [XML] Document Type Definition (DTD) that 32 corresponds to the vCard, electronic business card format defined by 33 [RFC2426]. This DTD provides equivalent functionality to the standard 34 format defined by [RFC2426]. Documents structured in accordance with 35 this DTD may also be known as "XML vCard" documents. 37 The mailing list for discussion of this memo is "ietf-vcard- 38 xml@imc.org". Send an email to " ietf-vcard-xml-request@imc.org" with 39 the message "SUBSCRIBE" to add your email address to this mailing 40 list. Send an email to " ietf-vcard-xml-request@imc.org" with the 41 message "UNSUBSCRIBE" to remove your email address from this mailing 42 list. 44 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 45 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this 46 document are to be interpreted as described in [RFC 2119]. 48 Dawson 1 Expires December 1999 49 Table of Contents 51 1. INTRODUCTION........................................................4 53 2. USING XML FOR REPRESENTING VCARD....................................5 55 2.1 XML DEPENDENCIES .................................................5 56 2.2 DOCUMENT TYPE DEFINITION .........................................5 57 2.3 WORKING WITH STANDARD AND XML VCARD REPRESENTATIONS ..............5 58 2.3.1 Conversion ....................................................5 59 2.3.2 Mixed Use of Both Representations .............................5 60 2.4 USING DATA TYPES .................................................6 61 2.5 INCLUDING BINARY CONTENT .........................................7 62 2.6 INCLUDING MULTIPLE VCARD OBJECTS .................................8 63 2.7 MAPPING VCARD TYPE PARAMETERS TO XML .............................8 64 2.8 MAPPING VCARD TYPES TO XML ......................................10 65 2.9 PARAMETER ENTITIES ..............................................12 66 2.10 NAMESPACE ......................................................12 67 2.11 EMAILING THE VCARD XML REPRESENTATION ..........................13 68 2.12 VCARD XML REPRESENTATION AND FILE SYSTEMS ......................13 70 3. VCARD XML DOCUMENT TYPE DEFINITION.................................13 72 4. VCARD V3.0 NOTATION................................................20 74 5. EXAMPLE USAGE......................................................21 76 5.1 SIMPLE VCARD ....................................................21 77 5.2 VCARD WITH NON-STANDARD EXTENSION ...............................21 78 5.3 VCARD WITH PHOTO ELEMENT ........................................22 79 5.4 VCARD WITH AN AGENT ELEMENT .....................................22 80 5.5 DOCUMENT WITH MULTIPLE VCARDS ...................................23 81 5.6 DOCUMENT UTILIZING VCARD NAMESPACE ..............................23 82 5.7 XML DOCUMENT REFERENCE TO A NON-XML VCARD .......................24 84 6. NAMESPACE..........................................................24 86 7. MAJOR CONTRIBUTORS.................................................25 88 8. ACKNOWLEDGMENTS....................................................25 90 9. SECURITY CONSIDERATIONS............................................25 92 10. BIBLIOGRAPHY......................................................25 94 Dawson 2 Expires December 1999 95 11. AUTHOR'S ADDRESS..................................................26 97 12. FULL COPYRIGHT STATEMENT..........................................26 99 Dawson 3 Expires December 1999 100 1. Introduction 102 The Extended Markup Language (XML) as defined in [XML] is gaining 103 widespread attention as a "web friendly" syntax for representing and 104 exchanging documents and data on the Internet. This interest includes 105 requests for and discussion of possible document type definitions 106 (DTD) for IETF standards such at the vCard, electronic business card 107 format defined by [RFC2426]. 109 The XML DTD in this memo is in no way intended to create a separate 110 definition for the vCard schema. The sole purpose for this memo is to 111 define an alternative XML representation for the format defined by 112 [RFC2426]. The vCard DTD does not introduce any capability not 113 expressible in the format defined by [RFC2426]. 115 An attempt has been made to leverage the standard features of the XMl 116 syntax in order to represent the vCard semantics. For example, strong 117 data typing is specified using the XML notation declaration. It is 118 the responsibility of the XML application supporting this DTD to make 119 sure that the content information is formatted consistently with the 120 notation declared for each element. 122 The vCard DTD promotes a number of vCard properties into attributes 123 on the "vCard" element. This has been done to express these 124 properties as "global attributes" for the vCard object, as a whole. 125 For example, the VERSION, REV, PRODID, UID, CLASS properties have 126 been "mapped" into attributes on the vCard object. 128 Binary content in the PHOTO, LOGO, SOUND and KEY properties may 129 either be specified through an external entity reference to the non- 130 XML image or sound content or may be included in the content after 131 first encoding the binary information using the BASE64 encoding of 132 [RFC 2045]. 134 The publication of [XML] was followed by the publication of a World- 135 Wide-Web Consortium (W3C) recommendation on "Namespaces in XML". A 136 XML namespace is a collection of names, identified by a URI. In 137 anticipation of the broader use of XML namespaces, this memo includes 138 the definition of the URI to be used to identify the namespace 139 associated with the vCard DTD element types in other XML documents. 140 XML applications that conform to this memo and also make use of 141 namespaces MUST NOT include other non-vCard namespaces in a vCard XML 142 document. 144 It is expected that the DTD defined in this memo will not normally be 145 included with vCard XML documents that are distributed. Instead, the 146 DTD will be referenced in the document type declaration in the 147 document entity. Such vCard XML documents will be well-formed and 148 valid, as defined in [XML]. In addition, other vCard XML documents 149 will be specified that do not include the XML prolog. Such vCard XML 150 documents will be well-formed but not valid. 152 Dawson 4 Expires December 1999 153 2. Using XML for Representing vCard 155 XML is a simplified version of the text markup syntax defined by ISO 156 8879, Standard Generalized Markup Language (SGML). XML was published 157 as a recommendation [XML] by the W3C on February 10, 1998. 159 2.1 XML Dependencies 161 This memo specifies the XML representation for the standard vCard 162 format defined by [RFC2426]. There are no XML dependencies other than 163 the [XML] and the [XMLNS] recommendations. 165 2.2 Document Type Definition 167 A XML DTD for vCard is defined by the DTD specified in section 3. 169 The formal public identifier (FPI) for the DTD is: 171 "-//IETF/DTD VCARDXML/vCard XML//EN" 173 NOTE: The "VCARDXML" text in the FPI value will be replaced with 174 the text "RFC xxxx", where "xxxx" is the RFC number, when the 175 memo is published as a RFC. 177 This FPI MUST be used on the DOCTYPE statement within a XML document 178 referencing the DTD defined by this memo. 180 This FPI SHOULD also be used to identify vCard XML documents within 181 operating system registries of file, clipboard and interactive 182 rendering (e.g., memory clipboard or drag/drop) formats. 184 2.3 Working With Standard and XML vCard Representations 186 This memo defines an alternative, XML representation for the standard 187 vCard format defined in [RFC2426]. This alternative representation 188 provides the same semantics as that defined in the standard format. 190 2.3.1 Conversion 192 The standard format can be converted to and from this XML format 193 without loss of any vCard information. When the XML representation 194 was defined, every attempt was made to use existing vCard type and 195 naming conventions for type parameters. This greatly facilitates 196 transformations between the two representations of the vCard. 198 2.3.2 Mixed Use of Both Representations 200 As previously indicated, conversion between the standard and XML 201 representations of vCard is a straightforward process. In addition, 202 mixed use of both representations is also possible. 204 With the use of the MIME multipart content-types, such as 205 multipart/alternative, compound MIME entities containing a mix of the 206 standard and XML representations can be specified. This capability is 208 Dawson 5 Expires December 1999 209 useful in applications where both representations might be 210 encountered. In addition, this capability demonstrates the isomeric 211 nature of the two representations. XML applications conforming to 212 this specification MUST be able to properly parse and process a MIME 213 multipart entity containing the MIME content-type associated with 214 this vCard XML document type. 216 2.4 Using Data Types 218 Strong "data typing" is an integral design principle in the vCard 219 format. Strong data typing in vCard means that the format type for 220 each vCard type value is well known. Within [RFC2426], the data type 221 is called the "value type". The standard format defined by [RFC2426] 222 specifies a default value type for each vCard type. In addition, many 223 of the vCard types allow for the specification of alternate value 224 types. This XML representation continues this design principle. 226 Explicit value typing in the XML representation is specified with the 227 "value" attribute on each element type. In addition, the XML DTD 228 specifies a default value type for each element type. XML documents 229 conforming to this memo need only specify the "value" attribute on 230 element types when the default value type is overridden. The standard 231 value types defined in [RFC2426] are specified in the XML DTD by 232 individual notation declarations. The formal public identifier for 233 standard value types all have the common string format of: 235 -//IETF/NOTATION VCARDXML/VALUE TYPE/xxx//EN 237 NOTE: The "VCARDXML" text in the FPI value will be replaced with 238 the text "RFC xxxx", where "xxxx" is the RFC number, when the 239 memo is published as a RFC. 241 Where "xxx" is replaced with the text specified in the table below. 243 The following table specifies the XML value type that corresponds to 244 each of the standard value types defined in [RFC2426]. 246 +--------------+--------------+-------------------------+ 247 | RFC 2426 | XML Value | Notation FPI Text | 248 | Value Type | Type | | 249 +--------------+--------------+-------------------------+ 250 | BINARY | BINARY | Binary | 251 | BOOLEAN | BOOLEAN | Boolean | 252 | DATE | DATE | Date | 253 | DATE-TIME | DATE-TIME | Date-Time | 254 | FLOAT | FLOAT | Float | 255 | INTEGER | INTEGER | Integer | 256 | PHONE-NUMBER | PHONE-NUMBER | Phone-Number | 257 | TEXT | TEXT | Text | 258 | TIME | TIME | Time | 259 | URI | URI | URI | 260 | UTC-OFFSET | UTC-OFFSET | UTC-Offset | 261 | VCARD | VCARD | vCard | 262 | Non-standard | X-NAME | X-Name | 264 Dawson 6 Expires December 1999 265 +--------------+--------------+-------------------------+ 267 2.5 Including Binary Content 269 Binary content can be included in a standard format of vCard with the 270 "PHOTO", "LOGO", or "SOUND" type. In the standard vCard format this 271 content may either be specified through an external entity reference, 272 using a URI value type, or maybe specified within the vCard object, 273 after first BASE64 encoding the content. 275 The XML representation for vCard also supports including binary 276 content in a vCard with the "photo", "logo" and "sound" types. It 277 also supports either an external reference to the non-XML binary 278 content or inclusion of the binary content after first encoding the 279 binary information using the BASE64 encoding of [RFC2045]. 281 Any vCard type defined in [RFC2426] that can be used to include 282 binary content are defined in the XML DTD as an element type with a 283 content model that consists of either the "extref" or the "b64bin" 284 element type. The "extref" element type is used to reference an 285 external entity containing the binary content. An external reference 286 to the binary content is specified by the "uri" attribute on the 287 "extref" element type. For every external reference, an ENTITY 288 declaration and a corresponding NOTATION declaration MUST also be 289 specified in an internal DTD to identify the location and format of 290 the external entity. For example, the following XML snippets would be 291 needed to include a reference to the executable "foo.jpg" in the 292 "photo" element type: 294 296 298 301 303 305 The "b64bin" element type is used to include the binary content 306 within the XML document after first character encoding the binary 307 information using the BASE64 encoding method of [RFC2045]. For 308 example, the following XML snippets would be needed to include the 309 executable "foo.jpg" in the "photo" element type; after first BASE64 310 encoding the binary information: 312 314 MIICajCC 315 AdOgAwIBAgICBEUwDQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05l 316 dHNjYXBlIENvbW11bmljYXRpb25z...and so on...IENvcnBvc== 317 319 Dawson 7 Expires December 1999 320 2.6 Including Multiple vCard Objects 322 The vCard standard format has the capability for including multiple, 323 individual vCards in a single data stream. The XML representation 324 also supports this feature. Individual vCards are specified by the 325 "vCard" element type. One or more "vCard" element types are permitted 326 within the parent element type, called "vCardSet". For example: 328 329 330 332 333 334 336 2.7 Mapping vCard Type Parameters to XML 338 The type parameters defined in the standard vCard format are 339 represented in the XML representation as attributes on element types. 340 The following table specifies the attribute name corresponding to 341 each type parameter. 343 +----------------+------------+-----------+-----------------+ 344 | Type | Attribute | Attribute | Default | 345 | Parameter Name | Name | Type | Value | 346 +----------------+------------+-----------+-----------------+ 347 | ENCODING | Not Used | n/a | n/a | 348 | LANGUAGE | lang | CDATA | IMPLIED | 349 | TYPE for ADR | del.type | NMTOKENS | 'INTL POSTAL | 350 | and LABEL | | | PARCEL WORK' | 351 | TYPE for TEL | tel.type | NMTOKENS | 'VOICE' | 352 | TYPE for EMAIL | email.type | NMTOKENS | 'INTERNET' | 353 | TYPE for PHOTO,| img.type | CDATA | REQUIRED | 354 | and LOGO | | | | 355 | TYPE for SOUND | aud.type | CDATA | REQUIRED | 356 | VALUE | value | NOTATION | See elements | 357 +----------------+------------+-----------+-----------------+ 359 The "VERSION", "REV", "PRODID", "UID" and "CLASS" vCard types have 360 been mapped into the attributes as specified by the following table. 362 +----------------+------------+------------+----------------+ 363 | Type | Attribute | Attribute | Default | 364 | Name | Name | Type | Value | 365 +----------------+------------+------------+----------------+ 366 | CLASS | class | enumerated | 'PUBLIC' | 367 | PRODID | prodid | CDATA | IMPLIED | 368 | REV | rev | CDATA | IMPLIED | 369 | UID | uid | CDATA | IMPLIED | 370 | VERSION | version | CDATA | IMPLIED | 371 +----------------+------------+------------+----------------+ 373 Dawson 8 Expires December 1999 374 The inline "ENCODING" property parameter is not needed in the XML 375 representation. Inline binary information is always included as 376 parsable character data, after first being encoded using the BASE64 377 encoding of [RFC 2045]. 379 A non-standard, experimental parameter can be added to the XML 380 representation by declaring it in an attribute list declaration and 381 assigning it a XML attribute type and corresponding default value. 383 In addition to these attributes, the "vCard" element type can also 384 have the following attributes: 386 +-----------+-----------+---------+----------------------------+ 387 | Attribute | Attribute | Default | Description | 388 | Name | Type | Value | | 389 +-----------+-----------+---------+----------------------------+ 390 | xmlns | CDATA | FIXED | Used to specify the default| 391 | | | | vCard XML name space. | 392 | xmlns: + | CDATA | FIXED | Used to specify the | 393 | | | | prefix is used to specify | 395 | | | | a namespace. | 396 +-----------+-----------+---------+----------------------------+ 398 The semantics of the"xmlns" attribute, and any attribute with 399 "xmlns:" as a prefix, is as specified in [XMLNS]. It is used to 400 declare a namespace in XML. It can be used to declare the vCard XML 401 namespace in a XML document with a document type other than the vCard 402 XML document type. The vCard XML document type MUST only use element 403 types from the vCard namespace. 405 To specify the vCard namespace, the attribute value for the "xmlns" 406 and any attribute with the prefix "xmlns:" MUST be: 408 'http://www.ietf.org/internet-drafts/draft-dawson-vCard-xml-dtd- 409 04.txt' 411 NOTE: This attribute value will be replaced with the URL 412 "http://www.ietf.org/rfc/rfcxxxx.txt", where "xxxx" is the RFC 413 number, when this memo is published as a RFC. 415 For example: 417 419 423 425 Dawson 9 Expires December 1999 426 2.8 Mapping vCard Types to XML 428 The following tables provide mappings of the vCard types to their 429 corresponding XML element types along with their respective content 430 models. 432 Identification Types 433 +----------------+------------+-----------------------------+ 434 | vCard | Element | Element Content Model | 435 | Type Name | Name | | 436 +----------------+------------+-----------------------------+ 437 | FN | fn | PCDATA | 438 | N | n | family*,given*,other*, | 439 | | | prefix*, suffix* | 440 | | family | PCDATA | 441 | | given | PCDATA | 442 | | other | PCDATA | 443 | | prefix | PCDATA | 444 | | suffix | PCDATA | 445 | NICKNAME | nickname | PCDATA | 446 | PHOTO | photo | extref or b64bin | 447 | | extref | EMPTY | 448 | | b64bin | PCDATA | 449 | BDAY | bday | PCDATA | 450 +----------------+------------+-----------------------------+ 452 Delivery Addressing Types 453 +----------------+------------+-----------------------------+ 454 | vCard | Element | Element Content Model | 455 | Type Name | Name | | 456 +----------------+------------+-----------------------------+ 457 | ADR | adr | pobox*,extadd*,street*, | 458 | | | locality*,region*,pcode*, | 459 | | | country* | 460 | | pobox | PCDATA | 461 | | extadd | PCDATA | 462 | | street | PCDATA | 463 | | locality | PCDATA | 464 | | region | PCDATA | 465 | | pcode | PCDATA | 466 | | country | PCDATA | 467 | LABEL | LABEL | PCDATA | 468 +----------------+------------+-----------------------------+ 470 Telecommunications Addressing Types 471 +----------------+------------+-----------------------------+ 472 | vCard | Element | Element Content Model | 473 | Type Name | Name | | 474 +----------------+------------+-----------------------------+ 475 | TEL | tel | PCDATA | 476 | EMAIL | email | PCDATA | 477 | MAILER | mailer | PCDATA | 478 +----------------+------------+-----------------------------+ 480 Dawson 10 Expires December 1999 481 Geographical Types 482 +----------------+------------+-----------------------------+ 483 | vCard | Element | Element Content Model | 484 | Type Name | Name | | 485 +----------------+------------+-----------------------------+ 486 | TZ | tz | PCDATA | 487 | GEO | geo | lat,lon | 488 | | lat | PCDATA | 489 | | lon | PCDATA | 490 +----------------+------------+-----------------------------+ 492 Organizational Types 493 +----------------+------------+-----------------------------+ 494 | vCard | Element | Element Content Model | 495 | Type Name | Name | | 496 +----------------+------------+-----------------------------+ 497 | TITLE | title | PCDATA | 498 | ROLE | role | PCDATA | 499 | LOGO | logo | extref or b64bin | 500 | | extref | EMPTY | 501 | | b64bin | PCDATA | 502 | AGENT | agent | vCard | extref | 503 | ORG | org | orgnam,orgunit* | 504 | | orgnam | PCDATA | 505 | | orgunit | PCDATA 506 +----------------+------------+-----------------------------+ 508 Explanatory Types 509 +----------------+------------+-----------------------------+ 510 | vCard | Element | Element Content Model | 511 | Type Name | Name | | 512 +----------------+------------+-----------------------------+ 513 | CATEGORIES | categories | item* | 514 | | item | PCDATA | 515 | NOTE | note | PCDATA | 516 | SORT-STRING | sort | PCDATA | 517 | SOUND | sound | extref | b64bin | 518 | | extref | EMPTY | 519 | | b64bin | PCDATA | 520 | URL | url | PCDATA | 521 | URI | uri | PCDATA | 522 +----------------+------------+-----------------------------+ 524 Security Types 525 +----------------+------------+-----------------------------+ 526 | vCard | Element | Element Content Model | 527 | Type Name | Name | | 528 +----------------+------------+-----------------------------+ 529 | KEY | key | extref | b64bin | 530 | | extref | EMPTY | 531 | | b64bin | PCDATA | 533 Dawson 11 Expires December 1999 534 +----------------+------------+-----------------------------+ 536 Non-standard, experimental element types and attributes lists MUST 537 only be specified by declarations in an internal DTD within the vCard 538 XML document. 540 The [RFC2426] specification specifies that the vCard types 541 corresponding to the "label" and "note" element types can contain 542 formatted content, such as is specified by multiple lines of text. In 543 such cases, the formatted text should be specified as CDATA section 544 content. The CDATA section specifies arbitrary character data that is 545 not meant to be interpretted. It is not scanned for markup by the XML 546 parser. 548 2.9 Parameter Entities 550 The external, vCard XML DTD specified in section 3 makes use of 551 parameter entity declarations. This XML feature is used to group 552 declarations within the DTD. This technique has been used in DTD 553 design in order to facilitate the reading and comprehension of the 554 structure specified by the DTD. 556 2.10 Namespace 558 [XMLNS] defines "Namespaces in XML" to be a collection of names, 559 identified by a URI, which are used in XML documents as element types 560 and attribute names. The [XML] specification does not include a 561 definition for namespaces, but does set down some guidelines for 562 experimental naming of namespaces. 564 XML namespaces allow multiple markup vocabularies in a single 565 document. Considering the utility of the vCard types in other 566 applications, it is important for the vCard XML DTD to define a 567 namespace for the vCard element types and attributes. 569 This memo defines the value that MUST be used in non-vCard XML 570 documents that reference element types or attribute lists from the 571 vCard namespace. 573 The following is an example of a well-formed but invalid "xdoc" 574 document type that includes elements and attribute lists from the 575 vCard namespace: 577 578 579 583 584 586 587 589 Dawson 12 Expires December 1999 590 2.11 Emailing the vCard XML Representation 592 It is expected that vCard XML documents will need to be sent over 593 SMTP/MIME email. The "text/xml" and "application/xml" content-types 594 have been registered for XML documents. 596 The "text/xml" and "application/xml" content-type definitions do not 597 provide for any header field parameters to identify the type of XML 598 document contained in the MIME entity. This means that a recipient 599 mail user agent must (MUA) open up each "text/xml" or 600 "application/xml" content in order to determine what object handler 601 is needed to process the information. To a MUA, all XML documents 602 look like just plain "text/xml" or "application/xml" content. 604 Internet application conforming to this memo MUST identify vCard XML 605 documents with the experimental content-type "text/x-xcfxml". For 606 example, a vCard XML document would have the following content-type 607 header field: 609 content-type:text/x-xcfxml 611 An XML application supporting the vCard XML document type MUST be 612 able to receive and properly process the "text/x-vcardxml" content- 613 type contained within a "multipart" message. 615 2.12 vCard XML Representation and File Systems 617 The vCard XML documents will be stored in file systems. The accepted 618 practice for file extensions for XML documents is the text "XML". 619 However, in order to uniquely identify vCard XML documents for file 620 association with applications that can directly process this document 621 type, it is RECOMMENDED that the file extension be the text "XCF". 623 3. vCard XML Document Type Definition 625 The following DTD conforms to XML version 1.0, as specified by [XML]. 627 629 630 631 633 636 638 641 646 649 653 656 658 661 663 666 668 669 673 674 678 679 683 684 688 689 693 694 698 Dawson 14 Expires December 1999 699 700 704 705 709 710 715 716 717 719 722 725 728 731 734 737 740 743 746 749 752 Dawson 15 Expires December 1999 753 756 759 760 761 763 764 766 768 780 781 782 783 784 786 787 788 789 793 795 796 800 801 805 806 812 813 817 818 822 823 827 828 831 832 833 835 836 839 840 842 843 845 846 847 849 850 852 854 857 858 862 864 Dawson 17 Expires December 1999 865 869 870 874 875 879 880 884 885 889 890 894 895 900 901 903 904 905 909 910 914 915 919 Dawson 18 Expires December 1999 920 921 923 924 925 927 929 930 931 933 934 935 937 938 940 941 945 946 950 951 954 955 956 958 960 961 963 965 966 969 970 974 Dawson 19 Expires December 1999 975 976 978 980 981 985 986 990 991 995 996 999 1000 1001 1003 1004 1006 1008 1009 1011 1013 1014 1015 1016 1018 4. vCard v3.0 Notation 1020 The formal public identifier (FPI) for the DTD described in this 1021 specification is "-//IETF//DTD vCard v3.0//EN". 1023 A XML document can reference an external non-XML entity containing a 1024 vCard v3.0 object, as specified by [RFC2426]. The vCard v3.0 object, 1025 while encoded in the standard, non-XML format can be referenced in an 1026 external entity reference that identifies the [RFC2426] format in a 1027 notation declaration. The [RFC2426] format is identified by the 1029 Dawson 20 Expires December 1999 1030 formal public identifier "-//IETF//NONSGML vCard version 3.0//EN", as 1031 defined in [FPI]. 1033 5. Example Usage 1035 5.1 Simple vCard 1037 The following is a simple example of a XML document using this DTD. 1039 1040 1042 1044 Frank Dawson 1045 Dawson Frank 1046 +1-617-693-8728 1047 +1-919-676-9515 1048 1049 6544 Battleford Drive 1050 Raleigh NC 1051 27613-3502 US 1052 1055 Frank_Dawson@Lotus.com 1056 1058 5.2 vCard with non-standard extension 1060 The following is an example of vCard that also includes a non- 1061 standard extension. 1063 1064 1069 1070 1071 ]> 1073 1076 Frank Dawson 1077 Dawson 1078 Frank 1079 +1-617-693-8728 1080 O+ 1081 1083 Dawson 21 Expires December 1999 1084 5.3 vCard with photo element 1086 The following is an example of a vCard that also includes an external 1087 reference to a photo. Similar structure would be used to represent a 1088 vCard with an external reference to a logo, sound or public 1089 key/certificate. 1091 1092 1096 1098 ]> 1100 1103 Frank Dawson 1104 Dawson 1105 Frank 1106 +1-617-693-8728 1107 1108 Frank_Dawson@Lotus.com 1109 1111 The following is an example of a vCard that includes a photo element 1112 as inline binary content. 1114 1115 1117 1118 Frank Dawson 1119 DawsonFrank 1120 MIICajCCAdOgAwIBAgICBEUwDQ 1121 EEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bmlj 1122 YXRpb25z...and so on...IENvcnBvc== 1123 1125 5.4 vCard with an agent element 1127 The following is an example of a vCard that includes an agent 1128 element. The content of the agent element is another vCard. 1130 1131 1133 1136 Frank Dawson 1137 Dawson 1139 Dawson 22 Expires December 1999 1140 Frank 1141 +1.617.693.8728 1142 1145 Kathie Collins 1146 Collins 1147 Kathie 1148 +1.617.693-5660 1149 Kathie_Collins@Lotus.com 1150 1151 Frank_Dawson@Lotus.com 1152 1154 5.5 Document with multiple vCards 1156 The following is an example of a vCard document that includes more 1157 than one vCard. 1159 1160 1162 1163 1164 John Smith 1165 Smith 1166 John 1167 jsmith@host.com 1168 1169 1170 Fred Stone 1171 Stone 1172 Fred 1173 fstone@host1.com 1174 1175 1177 5.6 Document utilizing vCard namespace 1179 The following is an example of a XML document that declares the vCard 1180 namespace as its default namespace. 1182 1184 1186 Frank Dawson 1187 Dawson Frank 1188 fdawson@host1.com 1189 1191 The following is an example of a XML document that includes elements 1192 from the vCard namespace. 1194 Dawson 23 Expires December 1999 1195 1197 1200 John Smith 1201 +1-919-555-1234 1202 1234567 1203 999.99 1204 1206 5.7 XML document reference to a non-XML vCard 1208 The following is an example of a XML document with a proper reference 1209 to a non-XML entity containing a vCard object in the format defined 1210 by [RFC2426]. This example shows how existing vCard objects can be 1211 integrated into XML documents using the XML structure defined in this 1212 document. 1214 1215 1220 1222 ]> 1224 1225 1226 01234-56789 1227 $1,000,000 1228 1230 6. Namespace 1232 [XMLNS] defines "XML namespaces" to be a collection of names, 1233 identified by a URI, which are used in XML documents as element types 1234 and attribute names. XML namespaces allow multiple markup vocabulary 1235 in a single document. Considering the utility of the vCard properties 1236 in other applications, it is important for the vCard XML DTD to 1237 define a namespace for the vCard element types. 1239 This memo includes the definition of both a qualified name for the 1240 vCard namespace and also a default namespace. The namespace 1241 declaration is specified by attributes on the "vCard" element. The 1242 default namespace is specified with the "xmlns" attribute and the 1243 qualified name for the vCard namespace is specified with the 1244 "xmlns:vcf" attribute. 1246 The default namespace attribute is useful in XML documents that are 1247 based on the vCard document types. The qualified name for the vCard 1249 Dawson 24 Expires December 1999 1250 namespace is useful in XML documents that partially consist of vCard 1251 elements types but also consist of element types from other schemas. 1253 The following is an example of the a vCard namespace declaration 1254 using the qualified namespace: 1256 1257 1261 1262 1264 1266 The following is an example of a vCard namespace declaration using 1267 the default namespace: 1269 1270 1273 1274 1276 1278 7. Major Contributors 1280 The following individual has provided major contribution in the 1281 concepts and content to this memo: 1283 Paul Hoffman 1285 8. Acknowledgments 1287 The following have participated in the drafting and discussion of 1288 this memo: 1290 Scott Boag, Dean Burton, Charles Goldfarb, Alex Hoppman, Lisa 1291 Lippert, Sean McGrath, Noah Mendelsohn, Surendra Reddy, Thomas 1292 Rowe, Doug Royer 1294 9. Security Considerations 1296 Security issues are not currently discussed in this memo. 1298 10. Bibliography 1300 [FPI] F. Dawson and P. Hoffman, "vCard v3.0 Formal Public 1301 Identifier", Internet Draft, http://www.internic.net/internet- 1302 drafts/draft-dawson-vcard-fpi-00.txt, July 1998. 1304 Dawson 25 Expires December 1999 1306 [ISO9070] "Information Technology_SGML Support Facilities_ 1307 Registration Procedures for Public Text Owner Identifiers", ISO/IEC 1308 9070, Second Edition, International Organization for Standardization, 1309 April, 1991. 1311 [RFC 2045] N. Freed, N. Borenstein, "Multipurpose Internet Mail 1312 Extensions (MIME) - Part One: Format of Internet Message Bodies", RFC 1313 2045, http://www.ietf.org/rfc/rfc2045.txt, November 1996. 1315 [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate 1316 Requirement Levels", RFC 2119, http://www.ietf.org/rfc/rfc2119.txt, 1317 March 1997. 1319 [RFC2426] F. Dawson and T. Howes, "vCard MIME Directory Profile", RFC 1320 2426, http://www.ietf.org/rfc/rfc2426.txt, September 1998. 1322 [XML] "Extensible Markup Language (XML)", Worldwid Web Consortium, 1323 http://www.w3.org/TR/1998/REC-xml-19980210, February 1998. 1325 [XMLNS] "Namespaces in XML", Worldwide Web Consortium, 1326 http://www.w3.org/TR/1999/REC-xml-names-19990114, January 1999. 1328 11. Author's Address 1330 The following address information is provided in a vCard XML DTD 1331 electronic business card, format. 1333 1336 Frank Dawson 1337 Dawson 1338 Frank 1339 Lotus Development Corporation 1340 1341 6544 Battleford Drive 1342 Raleigh 1343 NC 1344 27613-3502 1345 1346 +1-617-693-8728 1347 +1-919-676-9515 1348 Frank_Dawson@Lotus.com 1349 fdawson@earthlink.net 1350 1352 12. Full Copyright Statement 1354 "Copyright (C) The Internet Society (1999).All Rights Reserved. 1356 This document and translations of it may be copied and furnished to 1357 others, and derivative works that comment on or otherwise explain it 1359 Dawson 26 Expires December 1999 1360 or assist in its implmentation may be prepared, copied, published and 1361 distributed, in whole or in part, without restriction of any kind, 1362 provided that the above copyright notice and this paragraph are 1363 included on all such copies and derivative works.However, this 1364 document itself may not be modified in any way, such as by removing 1365 the copyright notice or references to the Internet Society or other 1366 Internet organizations, except as needed for the purpose of 1367 developing Internet standards in which case the procedures for 1368 copyrights defined in the Internet Standards process MUST be 1369 followed, or as required to translate it into languages other than 1370 English. 1372 The limited permissions granted above are perpetual and will not be 1373 revoked by the Internet Society or its successors or assigns. 1375 This document and the information contained herein is provided on an 1376 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1377 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1378 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1379 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1380 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1382 Dawson 27 Expires December 1999