idnits 2.17.1 draft-dawson-vcard-xml-dtd-00.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 Internet-Drafts being working documents. ** 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 13 longer pages, the longest (page 2) being 62 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 ([VCARD], [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. RFC 2119 keyword, line 637: '...the Internet Standards process MUST be...' 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 (July 19, 1998) is 9403 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 600 looks like a reference -- Missing reference section? 'VCARD' on line 596 looks like a reference -- Missing reference section? 'FPI' on line 584 looks like a reference -- Missing reference section? 'ISO9070' on line 588 looks like a reference -- Missing reference section? 'RFC 2119' on line 593 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NetWORK WORKing Group Frank Dawson 3 Internet Draft Lotus Development Corporation 4 5 Expires six months after: July 19, 1998 7 The vCard v3.0 XML DTD 9 Status of this Memo 11 This document is an Internet-Draft.Internet-Drafts are WORKing 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 andits WORKing groups. Note that other groups may also distribute 14 WORKing documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months.Internet-Drafts may be updated, replaced, or made obsolete by 18 other documents at any time.It is not appropriate to use Internet- 19 Drafts as reference material or to cite them other than as a "WORKing 20 draft" or "WORK in progress". 22 To view the entire list of current Internet-Drafts, please check the 23 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 25 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 26 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 28 Distribution of this document is unlimited. 30 Copyright (C) The Internet Society 1998. All Rights Reserved. 32 Abstract 34 This memo defines a [XML] Document Type Definition (DTD) that 35 corresponds to the vCard, electronic business card format defined by 36 [VCARD]. This DTD provides equivalent functionality to the standard 37 format defined by [VCARD]. 39 The mailing list for discussion of this memo is "ietf-vcard- 40 xml@imc.org". Send an email to "ietf-vcard-xml-request@imc.org" with 41 the message "SUBSCRIBE" to add your email address to this mailing 42 list. Send an email to "xml-vcard-request@imc.org" with the message 43 "UNSUBSCRIBE" to remove your email address from this mailing list. 45 1. Introduction 47 The Extended Markup Language (XML) as defined in [XML] is gaining 48 widespread attention as a "web friendly" syntax for encoding and 49 exchanging documents and data on the Internet. This interest includes 50 requests for and discussion of possible document type definitions 51 (DTD) for IETF standards such at the vCard, electronic business card 52 format define by [VCARD]. 54 While there is some merit to the argument that multiple encodings of 55 an object seldom provide more utility than to provide an additional 56 obstacle to interoperability or to provide unnecessary alternatives 57 to implementation teams, this document is intended to minimize both 58 of these faults by introducing an XML equivalent form of the vCard 59 specification defined by the IETF ASID WORKing Group. By introducing 60 this DTD to the same body that formulated the IETF vCard 61 specification, it is hoped that the XML encoding does not evolve in 62 incompatible ways with the MIME content type for vCard. 64 The vCard DTD does not introduce any capability not expressible in 65 the format defined by [VCARD]. However, an attempt has been made to 66 leverage the capabilities of the XML syntax to better articulate the 67 original intent of the vCard authors. 69 The vCard DTD promotes a number of vCard properties into attributes 70 on the "vCard" element. This has been done to express these 71 properties as "global attributes" for the vCard object, as a whole. 72 For example, the VERSION, REV, PRODID, UID, CLASS properties have 73 been "mapped" into attributes on the vCard object. 75 XML does not support a mixing of XML and non-XML content in a single 76 XML entity. These two notations need to be separated into different 77 entities. As such, the content information for the PHOTO, LOGO, SOUND 78 and KEY properties are specified through external entity references. 79 There is no inline binary content in a XML encoded vCard. 81 The [VCARD] specification defines a strongly typed object format. 82 This level of data typing is difficult to express in XML content 83 models. However, an attempt has been made to convey a data typing 84 through a "value" attribute on the property elements. However, unlike 85 the [VCARD] specification, the element content is expressed as a 86 single data type. Since the XML content model does easily provide a 87 method for "typing" of content, data integrity checking of a XML 88 encoded vCard is the responsibility of the XML application supporting 89 this DTD. 91 2. vCard XML Document Type Definition 93 The following DTD conforms to XML version 1.0, as specified by [XML]. 95 96 99 100 102 105 107 110 111 114 117 118 122 125 126 128 132 133 135 139 140 142 143 147 148 152 153 157 158 162 163 166 167 171 172 176 177 181 182 183 185 188 195 196 197 198 199 201 202 203 204 208 209 213 214 217 218 221 222 225 226 229 230 233 234 237 238 241 242 244 245 247 249 253 254 255 256 257 258 259 261 262 266 267 269 270 272 273 274 277 278 281 283 284 286 287 294 295 297 298 300 301 304 305 308 309 312 314 315 318 319 321 322 325 326 329 330 333 334 337 338 341 342 344 345 347 348 350 351 352 354 ]> 356 3. vCard v3.0 Notation 358 A XML document can reference an external non-XML entity containing a 359 vCard v3.0 object, as specified by [VCARD]. The vCard v3.0 object, 360 while encoded in the standard, non-XML format can be referenced in an 361 external entity reference that identifies the [VCARD] format in a 362 notation declaration. The [VCARD] format is identified by the formal 363 public identifier "-//IETF//NONSGML vCard version 3.0//EN", as 364 defined in [FPI]. 366 4. Example Usage 368 4.1 Simple vCard 370 The following is a simple example of a XML document using this DTD. 372 373 375 377 Frank Dawson 378 Dawson Frank 379 +1-617-693-8728 380 +1-919-676-9515 381 382 6544 Battleford Drive 383 Raleigh NC 384 27613-3502 US 385 387 Frank_Dawson@Lotus.com 388 390 4.2 vCard with non-standard extension 392 The following is an example of vCard that also includes a non- 393 standard extension. 395 396 402 403 ]> 405 408 Frank Dawson 409 Dawson 410 Frank 411 +1-617-693-8728 412 O+ 413 414 6544 Battleford Drive 415 Raleigh NC 416 27613-3502 US 417 419 Frank_Dawson@Lotus.com 420 422 4.3 vCard with photo element 424 The following is an example of a vCard that also includes a photo 425 element. Similar structure would be used to represent a vCard with a 426 logo, sound or public key/certificate. 428 429 433 434 ]> 436 440 Frank Dawson 441 Dawson 442 Frank 443 +1-617-693-8728 444 445 446 6544 Battleford Drive 447 Raleigh NC 448 27613-3502 US 449 451 Frank_Dawson@Lotus.com 452 454 4.4 vCard with an agent element 456 The following is an example of a vCard that includes an agent 457 element. The content of the agent element is another vCard. 459 460 462 465 Frank Dawson 466 Dawson 467 Frank 468 +1.617-693.8728 469 472 Kathie Collins 473 Collins 474 Kathie 475 +1.617.693-5660 476 Kathie_Collins@Lotus.com 477 478 Frank_Dawson@Lotus.com 479 481 4.5 XML document reference to a non-XML vCard 483 The following is an example of a XML document with a proper reference 484 to a non-XML entity containing a vCard object in the format defined 485 by [VCARD]. This example shows how existing vCard objects can be 486 integrated into XML documents without any delay. 488 489 494 496 ]> 498 499 500 01234-56789 501 $1,000,000 502 504 5. Open DTD Design Issues 506 The following issues remain open for discussion in the design of the 507 DTD: 509 . New lines in "label" and "note" elements are specified with the 510 "br" empty content element. Should this be specified with a 511 processor instruction instead? 513 . How should the ability to specify multiple vCard objects within a 514 document be specified? 516 . The VERSION, REV, PRODID, UID, CLASS properties were mapped to 517 attributes on the "vCard" element, rather than separate vCard 518 content particles. This seemed to be the optimal method to elevate 519 the semantic of these as global attributes on the vCard as a 520 whole. 522 . Rather than allow the "n" element's "given" content particle to be 523 repeatable, multiple given names will appear within a single 524 "given" element. For example, "Jose Maria Jesus". 525 This approach will avoid the ambiguity of understanding which 526 given name is "primary" when multiple "given" elements are 527 specified. 529 . Is the "property.component" form of naming content particle 530 elements too verbose? For example, family, given, n.otr, etc. 532 . Should the content model for "extadd" have the "*, optional and 533 repeatable" or should it have the "?, optional and not repeatable" 534 occurrence indicator? 536 . Should the content model for "street" have the "*, optional and 537 repeatable" or should it have the "?, optional and not repeatable" 538 occurrence indicator? 540 . Is any EMPTY content model for "photo", "logo" and "sound" 541 elements (but with appropriate attributes) WORKable? 542 . Should the "photo", "logo" and "sound" elements have the 543 "img.type" and "aud.type" (respectively) attribute to designate 544 the IANA registered media type for the entity? Or is this 545 information already provided by the NDATA (which must be specified 546 in a vCard document that includes these elements) adequate? The 547 NDATA will require a NOTATION definition. 549 . Is NMTOKENS the way to define the "del.type" and "tel.type" 550 attributes? 552 . Should we provide a "grouping" mechanism in the property elements? 553 For example: and . 555 . The "agent" element is defined with a "vCard" content particle. 556 Should this be redefined as an element with empty content and an 557 attribute that references an external entity? In XML, won't this 558 require the external entity be defined with a NDATA (non-XML) 559 content? This is not what we want. We want the "agent" content to 560 be parsed "vCard" character data. 562 . Should "sort-string" element name be shortened to "sort". 564 . Should the "key" be defined as an external entity reference or is 565 there a more PREFerred content model that should be used? 567 . When the XML vCard is conveyed in a MIME message, are there 568 special vCard properties that ought to be conveyed as attributes 569 on the Content-Type MIME header field? 571 6. Acknowledgments 573 The following have participated in the drafting and discussion of 574 this memo: 576 Paul Hoffman 578 7. Security Considerations 580 Security issues are not currently discussed in this memo. 582 8. Bibliography 584 [FPI] F. Dawson and P. Hoffman, "vCard v3.0 Formal Public 585 Identifier", Internet Draft, http://www.internic.net/internet- 586 drafts/draft-dawson-vcard-fpi-00.txt, July 1998. 588 [ISO9070] "Information Technology_SGML Support Facilities_ 589 Registration Procedures for Public Text Owner Identifiers", ISO/IEC 590 9070, Second Edition, International Organization for Standardization, 591 April, 1991. 593 [RFC 2119] "Key words for use in RFCs to Indicate Requirement 594 Levels", RFC 2119, March 1997. 596 [VCARD] F. Dawson and T. Howes, "vCard MIME Directory Profile", , http://www.internic.net/internet-drafts/draft- 598 ietf-asid-mime-vcard-06.txt, April 1998. 600 [XML] "Extensible Markup Language (XML)", Worldwid Web Consortium, 601 http://www.w3.org/TR/PR-xml-971208, December 1997. 603 9. Author's Address 605 The following address information is provided in a vCard v3.0 606 electronic business card, format. 608 BEGIN:VCARD 609 VERSION:3.0 610 FN:Frank Dawson 611 N:Dawson;Frank 612 ORG:Lotus Development Corporation 613 ADR;WORK;POSTAL;PARCEL:;;6544 Battleford Drive;Raleigh; 614 NC;27613-3502;USA 615 TEL;PREF;WORK;MSG:+1-617-693-8728 616 TEL;WORK;MSG:+1-919-676-9515 617 EMAIL;PREF;INTERNET:Frank_Dawson@Lotus.com 618 EMAIL; INTERNET:fdawson@earthlink.net 619 END:VCARD 621 10. 623 Full Copyright Statement 625 "Copyright (C) The Internet Society (1998).All Rights Reserved. 627 This document and translations of it may be copied and furnished to 628 others, and derivative WORKs that comment on or otherwise explain it 629 or assist in its implmentation may be prepared, copied, published and 630 distributed, in whole or in part, without restriction of any kind, 631 provided that the above copyright notice and this paragraph are 632 included on all such copies and derivative WORKs.However, this 633 document itself may not be modified in any way, such as by removing 634 the copyright notice or references to the Internet Society or other 635 Internet organizations, except as needed for the purpose of 636 developing Internet standards in which case the procedures for 637 copyrights defined in the Internet Standards process MUST be 638 followed, or as required to translate it into languages other than 639 English. 641 The limited permissions granted above are perpetual and will not be 642 revoked by the Internet Society or its successors or assigns. 644 This document and the information contained herein is provided on an 645 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 646 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 647 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 648 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 649 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.