idnits 2.17.1 draft-ietf-vcarddav-vcardxml-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 237: '...vCard XML parser MUST ignore XML eleme...' RFC 2119 keyword, line 240: '... MUST also be followed....' RFC 2119 keyword, line 255: '... original vCard format [I-D.ietf-vcarddav-vcardrev] MUST still be...' RFC 2119 keyword, line 261: '...rary. The order MUST be respected in ...' RFC 2119 keyword, line 263: '... vCard MAY happen....' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 9, 2010) is 5100 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-22) exists of draft-ietf-vcarddav-vcardrev-11 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Perreault 3 Internet-Draft Viagenie 4 Intended status: Standards Track May 9, 2010 5 Expires: November 10, 2010 7 vCard XML Representation 8 draft-ietf-vcarddav-vcardxml-03 10 Abstract 12 This document defines the XML schema of the vCard data format. 14 Status of This Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on November 10, 2010. 37 Copyright Notice 39 Copyright (c) 2010 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. The Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Example: Author's XML vCard . . . . . . . . . . . . . . . . . 3 57 4. Design Considerations . . . . . . . . . . . . . . . . . . . . 5 58 4.1. Extensibility . . . . . . . . . . . . . . . . . . . . . . 5 59 4.2. Limitations . . . . . . . . . . . . . . . . . . . . . . . 6 60 5. Format Conversions . . . . . . . . . . . . . . . . . . . . . . 7 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 62 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 63 7.1. Registration of the XML Namespace . . . . . . . . . . . . 9 64 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 65 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 67 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 68 Appendix A. Relax NG Schema . . . . . . . . . . . . . . . . . . . 9 69 Appendix B. Change Log (to be removed by RFC Editor prior to 70 publication) . . . . . . . . . . . . . . . . . . . . 15 71 B.1. Changes in -03 . . . . . . . . . . . . . . . . . . . . . . 15 72 B.2. Changes in -02 . . . . . . . . . . . . . . . . . . . . . . 15 73 B.3. Changes in -01 . . . . . . . . . . . . . . . . . . . . . . 16 74 B.4. Changes in -00 . . . . . . . . . . . . . . . . . . . . . . 16 76 1. Introduction 78 vCard [I-D.ietf-vcarddav-vcardrev] is a data format for representing 79 and exchanging information about individuals. It is a text-based 80 format (as opposed to a binary format). This document defines an XML 81 representation for vCard. The underlying data structure is exactly 82 the same, enabling a 1-to-1 mapping between the original vCard format 83 and the XML representation. The XML formatting may be preferred in 84 some contexts where an XML engine is readily available and may be 85 reused instead of writing a stand-alone vCard parser. 87 Earlier work on an XML format for vCard was started in 1998 by Frank 88 Dawson [I-D.dawson-vcard-xml-dtd]. Sadly it did not take over the 89 world. 91 2. The Schema 93 The schema is expressed in the RELAX NG language 94 [relaxng][relaxng-compact] and is found in Appendix A. 96 3. Example: Author's XML vCard 98 99 100 101 Simon Perreault 102 103 Perreault 104 Simon 105 106 107 ing. jr. 108 M.Sc. 109 110 111 --0203 112 113 20090808T1430-0500 114 115 1 116 117 1 118 fr 119 120 121 2 122 en 123 124 125 work 126 Viagenie 127 128 129 work 130 131 Suite 625 132 2600 boul. Laurier 133 Quebec 134 QC 135 G1V 4W1 136 Canada 137 138 139 140 work 141 voice 142 143 tel:+1-418-656-9254;ext=102 144 145 146 147 work 148 text 149 voice 150 cell 151 video 152 153 tel:+1-418-262-6501 154 155 156 157 work 158 fax 159 160 tel:+1-418-656-9257 161 162 163 work 164 simon.perreault@viagenie.ca 165 166 167 work 168 geo:46.772673,-71.282945 169 170 171 work 172 http://www.viagenie.ca/simon.perreault/simon.asc 173 174 America/Montreal 175 PUBLIC 176 177 179 4. Design Considerations 181 The general idea is to map vCard parameters, properties, and value 182 types to XML elements. For example, the "FN" property is mapped to 183 the "fn" element. That element in turn contains a text element whose 184 content corresponds to the vCard property's value. 186 vCard parameters are also mapped to XML elements. They are contained 187 in the element, which is contained in property elements. 188 For example, the "TYPE" parameter applied to the "TEL" property would 189 look like the following in XML: 191 192 193 voice 194 video 195 196 tel:+1-555-555-555 197 199 Parameters taking a list of values are simply repeated multiple 200 times, once for each value in the list. 202 Properties having structured values (e.g. the "N" property) are 203 expressed by XML element trees. Element names in that tree (e.g. 204 "surname", "given", etc.) do not have a vCard equivalent since they 205 are identified by position in plain vCard. 207 Line folding is a non-issue in XML. Therefore, the mapping from 208 vCard to XML is done after the unfolding procedure is carried out. 209 Conversely, the mapping from XML to vCard is done before the folding 210 procedure is carried out. 212 4.1. Extensibility 214 The original vCard format is extensible. New properties, parameters, 215 data types and values (collectively known as vCard objects) can be 216 registered from IANA. It is expected that these vCard extensions 217 will also specify extensions to the XML format described in this 218 document. This is not a requirement: a separate document may be used 219 instead. 221 Unregistered extensions (i.e. those starting with "X-" and 222 "VND-...-") can be expressed in XML by making use of XML namespaces. 223 They simply correspond to elements outside of the core namespace. 224 For example: 226 228 229 1 230 231 value goes here 232 234 Note that extension elements do not need the "X- or "VND-" prefix in 235 XML. The XML namespace mechanism is sufficient. 237 A vCard XML parser MUST ignore XML elements and attributes for which 238 it doesn't recognize the expanded name. The normal behaviour of 239 ignoring XML processing instructions whose target is not recognized 240 MUST also be followed. 242 In the original vCard format, the "VERSION" property was mandatory 243 and played a role in extensibility. In XML, this property is absent. 244 Its role is played by the vCard core namespace identifier, which 245 includes the version number. vCard revisions will use a different 246 namespace. 248 Parameters containing a list of values are expressed using a list of 249 elements in XML (e.g. the element). 251 4.2. Limitations 253 The schema does not validate the cardinality of properties. This is 254 a limitation of the schema definition language. Cardinalities of the 255 original vCard format [I-D.ietf-vcarddav-vcardrev] MUST still be 256 respected. 258 Some constructs (e.g. value enumerations in type parameters) have 259 additional ordering constraints in XML. This is a result of 260 limitations of the schema definition language and the order is 261 arbitrary. The order MUST be respected in XML for the vCard to be 262 valid. However, reordering as part of conversion to or from plain 263 vCard MAY happen. 265 5. Format Conversions 267 When converting from XML vCard (this specification) to plain-text 268 vCard [I-D.ietf-vcarddav-vcardrev], the following rules apply: 270 o Properties in the vCard 4 namespace: 272 o 274 * If the converter knows of a specific plain-text representation 275 for this property, it uses it. For example, the element 276 corresponds to the "ADR" property, which is encoded using 277 comma-separated lists separated by semi-colons. 279 * Otherwise, the property name is taken from the element name, 280 property parameters are taken from the element, 281 and the content of the property is taken from the content of 282 the value element. If the property element has attributes or 283 contains other XML elements, they are dropped. 285 * If a standard property's XML element contains XML elements and 286 attributes for which the converter doesn't recognize the 287 expanded name, they are dropped. Therefore, it is RECOMMENDED 288 to limit extensions to the property level to ensure that all 289 data is preserved intact in round-trip conversions. 291 o Properties in other namespaces are wrapped as-is inside an "XML" 292 property. 294 When converting from plain-text vCard [I-D.ietf-vcarddav-vcardrev] to 295 XML vCard (this specification), the following rules apply: 297 o The content of "XML" properties is converted as-is to XML. 299 o Properties for which the converter knows of a specific XML 300 representation use it. For example, the "ADR" property is 301 represented using the element and related sub-elements. 303 o Other properties are converted to XML in the following way: 305 o 307 * The XML namespace of the property element is set to the vCard 4 308 namespace. 310 * The name of the property element is set to that of the 311 property. 313 * If the property has attributes, they get translated as-is into 314 sub-elements of the element 316 * The property element contains a single element whose 317 content is copied as-is from the property's value. 319 For example, these two vCards are equivalent: 321 322 323 324 J. Doe 325 326 Doe 327 J. 328 329 330 331 332 image/jpeg 333 alien.jpg 334 335 My web page! 337 338 339 341 BEGIN:VCARD 342 VERSION:4.0 343 FN:J. Doe 344 N:Doe;J.;; 345 X-FILE;TYPE=image/jpeg:alien.jpg 346 XML:My web page! 348 END:VCARD 350 6. Security Considerations 352 All the security considerations applicable to plain vCard 353 [I-D.ietf-vcarddav-vcardrev] are applicable to this document as well. 355 7. IANA Considerations 356 7.1. Registration of the XML Namespace 358 URI: urn:ietf:params:xml:ns:vcard-4.0 360 Registrant Contact: Simon Perreault 362 XML: None. Namespace URIs do not represent an XML specification. 364 8. Acknowledgements 366 Thanks to the following people for their input: 368 Alexey Melnikov, Barry Leiba, Cyrus Daboo, Joe Hildebrand, Joseph 369 Smarr, Marc Blanchet, Peter Saint-Andre, Robins George, Zahhar 370 Kirillov, Zoltan Ordogh. 372 9. References 374 9.1. Normative References 376 [I-D.ietf-vcarddav-vcardrev] Perreault, S. and P. Resnick, "vCard 377 Format Specification", 378 draft-ietf-vcarddav-vcardrev-11 (work 379 in progress), May 2010. 381 [relaxng] Clark, J., "RELAX NG Specification", 382 December 2001. 384 [relaxng-compact] Clark, J., "RELAX NG Compact Syntax", 385 November 2002, . 388 9.2. Informative References 390 [I-D.dawson-vcard-xml-dtd] Dawson, F., "The vCard v3.0 XML DTD", 391 draft-dawson-vcard-xml-dtd-03 (work in 392 progress), June 1998. 394 Appendix A. Relax NG Schema 396 default namespace = "urn:ietf:params:xml:ns:vcard-4.0" 398 # Value types 399 value-text = element text { text } 400 value-text-list = value-text+ 401 value-uri = element uri { xsd:anyURI } 402 value-date = element date { 403 xsd:string { pattern = "\d{8}|\d{4}-\d\d|--\d\d(\d\d)?|---\d\d" } 405 } 406 value-time = element time { 407 xsd:string { pattern = "(\d\d(\d\d(\d\d)?)?|-\d\d(\d\d?)|--\d\d)" 408 ~ "(Z|[+\-]\d\d(\d\d)?)?" } 409 } 410 value-date-time = element date-time { 411 xsd:string { pattern = "(\d{8}|--\d{4}|---\d\d)T\d\d(\d\d(\d\d)?)?" 412 ~ "(Z|[+\-]\d\d(\d\d)?)?" } 413 } 414 value-date-and-or-time = value-date | value-date-time | value-time 415 value-timestamp = element timestamp { 416 xsd:string { pattern = "\d{8}T\d{6}(Z|[+\-]\d\d(\d\d)?)?" } 417 } 418 value-boolean = element boolean { xsd:boolean } 419 value-integer = element integer { xsd:integer } 420 value-float = element float { xsd:float } 421 value-binary = element binary { xsd:base64Binary } 422 value-language-tag = element language-tag { 423 xsd:string { pattern = "([a-z]{2,3}((-[a-z]{3}){0,3})?|[a-z]{4,8})" 424 ~ "(-[a-z]{4})?(-([a-z]{2}|\d{3}))?" 425 ~ "(-([0-9a-z]{5,8}|\d[0-9a-z]{3}))*" 426 ~ "(-[0-9a-wyz](-[0-9a-z]{2,8})+)*" 427 ~ "(-x(-[0-9a-z]{1,8})+)?|x(-[0-9a-z]{1,8})+|" 428 ~ "[a-z]{1,3}(-[0-9a-z]{2,8}){1,2}" } 429 } 431 # Parameters 432 param-language = element language { value-language-tag }? 433 param-pref = element pref { 434 xsd:integer { minInclusive = "1" maxInclusive = "100" } 435 }? 436 param-pid = element pid { 437 xsd:string { pattern = "\d+(\.\d+)?" } 438 }? 439 param-type = element type { "work" | "home" }* 440 param-calscale = element calscale { "gregorian" }? 442 # Properties 443 property-source = element source { 444 element parameters { param-pid, param-pref }, 445 value-uri 446 } 447 property-name = element name { value-text } 448 property-kind = element kind { 449 element text { "individual" | "group" | "org" | 450 "location" | "thing" }* 451 } 452 property-fn = element fn { 453 element parameters { param-language, param-pid, 454 param-pref, param-type }?, 455 value-text 456 } 457 property-n = element n { 458 element parameters { param-language }?, 459 element surname { value-text-list? }, 460 element given { value-text-list? }, 461 element prefix { value-text-list? }, 462 element suffix { value-text-list? } 463 } 464 property-nickname = element nickname { 465 element parameters { param-language, param-pid, 466 param-pref, param-type }?, 467 value-text-list 468 } 469 property-photo = element photo { 470 element parameters { 471 param-pid, 472 param-pref, 473 param-type, 474 element type { element media { value-text } }? 475 }?, 476 (value-binary | value-uri) 477 } 478 property-bday = element bday { 479 element parameters { param-calscale }?, 480 (value-date-and-or-time | value-text) 481 } 482 property-dday = element dday { 483 element parameters { param-calscale }?, 484 (value-date-and-or-time | value-text) 485 } 486 property-birth = element birth { 487 element parameters { param-language }?, 488 value-text 489 } 490 property-death = element death { 491 element parameters { param-language }?, 492 value-text 493 } 494 property-anniversary = element anniversary { 495 element parameters { param-calscale }?, 496 (value-date-and-or-time | value-text) 497 } 498 property-sex = element sex { 499 element integer { "0" | "1" | "2" | "9" } 500 } 502 property-adr = element adr { 503 element parameters { 504 param-language, 505 param-pid, 506 param-pref, 507 param-type, 508 element geo { value-uri }?, 509 element tz { value-text | value-uri }? 510 }?, 511 element pobox { value-text-list? }, 512 element ext { value-text-list? }, 513 element street { value-text-list? }, 514 element locality { value-text-list? }, 515 element region { value-text-list? }, 516 element code { value-text-list? }, 517 element country { value-text-list? } 518 } 519 property-label = element label { 520 element parameters { param-language, param-pid, 521 param-pref, param-type }?, 522 value-text 523 } 524 property-tel = element tel { 525 element parameters { 526 param-pid, 527 param-pref, 528 element type { "work" | "home" | "text" | "voice" 529 | "fax" | "cell" | "video" | "pager" }* 530 }, 531 value-uri 532 } 533 property-email = element email { 534 element parameters { param-pid, param-pref, param-type }?, 535 value-text 536 } 537 property-impp = element impp { 538 element parameters { param-pid, param-pref, param-type }?, 539 value-uri 540 } 541 property-lang = element lang { 542 element parameters { param-pid, param-pref, param-type }?, 543 value-language-tag 544 } 545 property-tz = element tz { 546 element parameters { param-pid, param-pref, param-type }?, 547 (value-text | value-uri) 548 } 549 property-geo = element geo { 550 element parameters { param-pid, param-pref, param-type }?, 551 value-uri 552 } 553 property-title = element title { 554 element parameters { param-language, param-pid, 555 param-pref, param-type }?, 556 value-text 557 } 558 property-role = element role { 559 element parameters { param-language, param-pid, 560 param-pref, param-type }?, 561 value-text 562 } 563 property-logo = element logo { 564 element parameters { 565 param-language, 566 param-pid, 567 param-pref, 568 param-type, 569 element type { element media { value-text } }? 570 }?, 571 (value-binary | value-uri) 572 } 573 property-org = element org { 574 element parameters { param-language, param-pid, 575 param-pref, param-type }?, 576 value-text-list 577 } 578 property-member = element member { param-pid, param-pref, value-uri } 579 property-related = element related { 580 element parameters { 581 param-pid, 582 param-pref, 583 element type { "work" | "home" | "parent" | "child" 584 | "sibling" | "spouse" | "family" | "friend" 585 | "supervisor" | "supervisee" | "assistant" 586 | "colleague" | "agent" | "emergency" }* 587 }?, 588 (value-uri | value-text) 589 } 590 property-categories = element categories { 591 element parameters { param-pid, param-pref, param-type }?, 592 value-text 593 } 594 property-note = element note { 595 element parameters { param-language, param-pid, 596 param-pref, param-type }?, 597 value-text 599 } 600 property-prodid = element prodid { value-text } 601 property-rev = element rev { value-timestamp } 602 property-sort-string = element sort-string { 603 element surname { value-text }+, 604 element given { value-text }* 605 } 606 property-sound = element sound { 607 element parameters { 608 param-language, 609 param-pid, 610 param-pref, 611 element type { "work" | "home" | 612 element media { value-text } }* 613 } 614 }?, 615 (value-binary | value-uri) 616 } 617 property-uid = element uid { value-uri } 618 property-clientpidmap = element clientpidmap { 619 element sourceid { xsd:positiveInteger }, 620 value-uri 621 } 622 property-url = element url { 623 element parameters { param-pid, param-pref, param-type }?, 624 value-uri 625 } 626 property-class = element class { 627 element text { "PUBLIC" | "PRIVATE" | "CONFIDENTIAL" } 628 } 629 property-key = element key { 630 element parameters { 631 param-pid, 632 param-pref, 633 element type { "work" | "home" | 634 element media { value-text } }* 635 } 636 }?, 637 (value-binary | value-uri) 638 } 639 property-fburl = element fburl { 640 element parameters { param-pid, param-pref, param-type }?, 641 value-uri 642 } 643 property-caladruri = element caladruri { 644 element parameters { param-pid, param-pref, param-type }?, 645 value-uri 646 } 648 property-caluri = element caluri { 649 element parameters { param-pid, param-pref, param-type }?, 650 value-uri 651 } 653 # Top-level grammar 654 property = property-adr | property-anniversary | property-bday 655 | property-birth | property-caladruri | property-caluri 656 | property-categories | property-class | property-clientpidmap 657 | property-dday | property-death | property-email 658 | property-fburl | property-fn | property-geo | property-impp 659 | property-key | property-kind | property-label | property-lang 660 | property-logo | property-member | property-n | property-name 661 | property-nickname | property-note | property-org 662 | property-photo | property-prodid | property-related 663 | property-rev | property-role | property-sex 664 | property-sort-string | property-sound | property-source 665 | property-tel | property-title | property-tz | property-uid 666 | property-url 667 start = element vcards { 668 element vcard { 669 (property 670 | element group { 671 attribute name { text }, 672 property* 673 })+ 674 }+ 675 } 677 Appendix B. Change Log (to be removed by RFC Editor prior to 678 publication) 680 B.1. Changes in -03 682 o Created "Format Conversions" section. 684 o Turned more parameter values into plain text. 686 o Removed need for empty value elements in components. 688 o Wrapped value of , , and in value elements. 690 B.2. Changes in -02 692 o Synchronized with draft-ietf-vcarddav-vcardrev-10. 694 o Turned parameter values into plain text. 696 o Moved the "XML" property to vCard base. 698 o Changed title to avoid confusion with XML Schema. 700 o Added prefixes "value-", "param-", and "property-" in schema. 702 o Better language for specifying what a parser must ignore. 704 B.3. Changes in -01 706 o Synchronized with draft-ietf-vcarddav-vcardrev-09. 708 o Added the element to allow multiple vCards in a single 709 XML file. 711 o Created the container element. 713 o Use text value for enumeration in element. 715 o Created the "XML" vCard property. 717 o Added IANA considerations section. 719 o Added security considerations section. 721 B.4. Changes in -00 723 o Same as draft-perreault-vcarddav-vcardxml-02. 725 Author's Address 727 Simon Perreault 728 Viagenie 729 2600 boul. Laurier, suite 625 730 Quebec, QC G1V 4W1 731 Canada 733 Phone: +1 418 656 9254 734 EMail: simon.perreault@viagenie.ca 735 URI: http://www.viagenie.ca