idnits 2.17.1 draft-ietf-vcarddav-vcardxml-07.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 222: '... element MUST be present even ...' RFC 2119 keyword, line 263: '... RECOMMENDED for extensions that hav...' RFC 2119 keyword, line 286: '...vCard XML parser MUST ignore XML eleme...' RFC 2119 keyword, line 289: '... MUST also be followed....' RFC 2119 keyword, line 304: '... original vCard format [I-D.ietf-vcarddav-vcardrev] MUST still be...' (3 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 10, 2011) is 4795 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-16 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 March 10, 2011 5 Expires: September 11, 2011 7 vCard XML Representation 8 draft-ietf-vcarddav-vcardxml-07 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 September 11, 2011. 37 Copyright Notice 39 Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . . . 6 59 4.2. Limitations . . . . . . . . . . . . . . . . . . . . . . . 7 60 5. Format Conversions . . . . . . . . . . . . . . . . . . . . . . 8 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 62 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 63 7.1. Registration of the XML Namespace . . . . . . . . . . . . 10 64 7.2. Media Type . . . . . . . . . . . . . . . . . . . . . . . . 10 65 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 66 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 67 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 68 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 69 Appendix A. Relax NG Schema . . . . . . . . . . . . . . . . . . . 12 70 Appendix B. Change Log (to be removed by RFC Editor prior to 71 publication) . . . . . . . . . . . . . . . . . . . . 18 72 B.1. Changes in -07 . . . . . . . . . . . . . . . . . . . . . . 18 73 B.2. Changes in -06 . . . . . . . . . . . . . . . . . . . . . . 18 74 B.3. Changes in -05 . . . . . . . . . . . . . . . . . . . . . . 18 75 B.4. Changes in -04 . . . . . . . . . . . . . . . . . . . . . . 18 76 B.5. Changes in -03 . . . . . . . . . . . . . . . . . . . . . . 18 77 B.6. Changes in -02 . . . . . . . . . . . . . . . . . . . . . . 19 78 B.7. Changes in -01 . . . . . . . . . . . . . . . . . . . . . . 19 79 B.8. Changes in -00 . . . . . . . . . . . . . . . . . . . . . . 19 81 1. Introduction 83 vCard [I-D.ietf-vcarddav-vcardrev] is a data format for representing 84 and exchanging information about individuals and other entities. It 85 is a text-based format (as opposed to a binary format). This 86 document defines an XML representation for vCard. The underlying 87 data structure is exactly the same, enabling a 1-to-1 mapping between 88 the original vCard format and the XML representation. The XML 89 formatting may be preferred in some contexts where an XML engine is 90 readily available and may be reused instead of writing a stand-alone 91 vCard parser. 93 Earlier work on an XML format for vCard was started in 1998 by Frank 94 Dawson [I-D.dawson-vcard-xml-dtd]. Sadly it did not take over the 95 world. 97 2. The Schema 99 The schema is expressed in the RELAX NG language 100 [relaxng][relaxng-compact] and is found in Appendix A. 102 3. Example: Author's XML vCard 104 105 106 107 Simon Perreault 108 109 Perreault 110 Simon 111 112 113 114 ing. jr. 115 M.Sc. 116 117 118 --0203 119 120 20090808T1430-0500 121 122 M 123 124 1 125 fr 126 127 128 2 129 en 130 131 132 work 133 Viagenie 134 135 136 137 work 138 140 141 142 143 2875 boul. Laurier, suite D2-630 144 Quebec 145 QC 146 G1V 2M2 147 Canada 148 149 150 151 152 work 153 voice 154 155 156 tel:+1-418-656-9254;ext=102 157 158 159 160 161 work 162 text 163 voice 164 cell 165 video 166 167 168 tel:+1-418-262-6501 169 170 171 work 172 simon.perreault@viagenie.ca 173 174 175 work 176 geo:46.766336,-71.28955 178 179 180 work 181 http://www.viagenie.ca/simon.perreault/simon.asc 182 183 America/Montreal 184 185 187 4. Design Considerations 189 The general idea is to map vCard parameters, properties, and value 190 types to XML elements. For example, the "FN" property is mapped to 191 the "fn" element. That element in turn contains a text element whose 192 content corresponds to the vCard property's value. 194 vCard parameters are also mapped to XML elements. They are contained 195 in the element, which is contained in property elements. 196 For example, the "TYPE" parameter applied to the "TEL" property would 197 look like the following in XML: 199 200 201 voice 202 video 203 204 tel:+1-555-555-555 205 207 Parameters taking a list of values are simply repeated multiple 208 times, once for each value in the list. 210 Properties having structured values (e.g. the "N" property) are 211 expressed by XML element trees. Element names in that tree (e.g. 212 "surname", "given", etc.) do not have a vCard equivalent since they 213 are identified by position in plain vCard. 215 Line folding is a non-issue in XML. Therefore, the mapping from 216 vCard to XML is done after the unfolding procedure is carried out. 217 Conversely, the mapping from XML to vCard is done before the folding 218 procedure is carried out. 220 A top-level element is used as root. It contains one or 221 more element, each representing a complete vCard. The 222 element MUST be present even when only a single vCard is 223 present in an XML document. 225 The group construct (Section 3.2 in [I-D.ietf-vcarddav-vcardrev]) is 226 represented with the element. The "name" attribute contains 227 the group's name. For example: 229 230 231 232 ... 233 ... 234 235 236 ... 237 238 ... 239 240 242 is equivalent to: 244 BEGIN:VCARD 245 VERSION:4.0 246 contact.FN=... 247 contact.EMAIL=... 248 media.PHOTO=... 249 CATEGORIES=... 250 END:VCARD 252 4.1. Extensibility 254 The original vCard format is extensible. New properties, parameters, 255 data types and values (collectively known as vCard objects) can be 256 registered with IANA. It is expected that these vCard extensions 257 will also specify extensions to the XML format described in this 258 document. 260 Unregistered extensions (i.e. those starting with "X-" and 261 "VND-...-") are expressed in XML by using elements starting with "x-" 262 and "vnd-...-". Usage of XML namespaces for extensibility is 263 RECOMMENDED for extensions that have no equivalent in plain text 264 vCard. Refer to Section 5 for the implications when converting 265 between plain-text vCard and XML. 267 Examples: 269 270 271 1 272 value goes here 273 275 277 278 1 279 280 value goes here 281 283 Note that extension elements do not need the "X- or "VND-" prefix in 284 XML. The XML namespace mechanism is sufficient. 286 A vCard XML parser MUST ignore XML elements and attributes for which 287 it doesn't recognize the expanded name. The normal behaviour of 288 ignoring XML processing instructions whose target is not recognized 289 MUST also be followed. 291 In the original vCard format, the "VERSION" property was mandatory 292 and played a role in extensibility. In XML, this property is absent. 293 Its role is played by the vCard core namespace identifier, which 294 includes the version number. vCard revisions will use a different 295 namespace. 297 Parameters containing a list of values are expressed using a list of 298 elements in XML (e.g. the element). 300 4.2. Limitations 302 The schema does not validate the cardinality of properties. This is 303 a limitation of the schema definition language. Cardinalities of the 304 original vCard format [I-D.ietf-vcarddav-vcardrev] MUST still be 305 respected. 307 Some constructs (e.g. value enumerations in type parameters) have 308 additional ordering constraints in XML. This is a result of 309 limitations of the schema definition language and the order is 310 arbitrary. The order MUST be respected in XML for the vCard to be 311 valid. However, reordering as part of conversion to or from plain 312 vCard MAY happen. 314 5. Format Conversions 316 When converting from XML vCard (this specification) to plain-text 317 vCard [I-D.ietf-vcarddav-vcardrev], the following rules apply: 319 o Properties in the vCard 4 namespace: 321 * If the converter knows of a specific plain-text representation 322 for this property, it uses it. For example, the element 323 corresponds to the "ADR" property, which is encoded using 324 comma-separated lists separated by semi-colons. 326 * Otherwise, the property name is taken from the element name, 327 property parameters are taken from the element, 328 and the content of the property is taken from the content of 329 the value element. If the property element has attributes or 330 contains other XML elements, they are dropped. 332 * If a standard property's XML element contains XML elements and 333 attributes for which the converter doesn't recognize the 334 expanded name, they are dropped. Therefore, it is RECOMMENDED 335 to limit extensions to the property level to ensure that all 336 data is preserved intact in round-trip conversions. 338 o Properties in other namespaces are wrapped as-is inside an "XML" 339 property. 341 o Property value escaping (Section 3.3 of 342 [I-D.ietf-vcarddav-vcardrev]) is carried out. For example, a 343 NEWLINE character (ASCII decimal 10) becomes "\n". 345 o Double-quoting of parameter values, as well as backslash escaping 346 in parameter values, is carried out. For example, 347 "foo","bar" becomes PARAM="\"foo\",\"bar\"". 349 When converting from plain-text vCard [I-D.ietf-vcarddav-vcardrev] to 350 XML vCard (this specification), the following rules apply: 352 o The content of "XML" properties is converted as-is to XML. 354 o Properties for which the converter knows of a specific XML 355 representation use it. For example, the "ADR" property is 356 represented using the element and related sub-elements. 358 o Other properties are converted to XML in the following way: 360 * The XML namespace of the property element is set to the vCard 4 361 namespace. 363 * The name of the property element is set to the lowercased name 364 of the property. 366 * If the property has parameters, they get translated as-is 367 (without lowercasing of parameter names, removal of backslash 368 escaping, and removal of quoting) into sub-elements of the 369 element 371 * The property element contains a single element whose 372 content is copied as-is from the property's value. 374 o Property value escaping is undone. For example, "\n" becomes a 375 NEWLINE character (ASCII decimal 10). 377 o Double-quoting of parameter values, as well as backslash escaping 378 in parameter values, is undone. For example, 379 PARAM="\"foo\",\"bar\"" becomes "foo","bar". 381 For example, these two vCards are equivalent: 383 384 385 386 J. Doe 387 388 Doe 389 J. 390 391 392 393 394 395 image/jpeg 396 alien.jpg 397 398 My web page! 400 401 403 BEGIN:VCARD 404 VERSION:4.0 405 FN:J. Doe 406 N:Doe;J.;; 407 X-FILE;TYPE=image/jpeg:alien.jpg 408 XML:My web page! 411 END:VCARD 413 6. Security Considerations 415 All the security considerations applicable to plain vCard 416 [I-D.ietf-vcarddav-vcardrev] are applicable to this document as well. 418 7. IANA Considerations 420 7.1. Registration of the XML Namespace 422 URI: urn:ietf:params:xml:ns:vcard-4.0 424 Registrant Contact: Simon Perreault 426 XML: None. Namespace URIs do not represent an XML specification. 428 7.2. Media Type 430 This section defines the MIME media type for use with vCard-in-XML 431 data. 433 To: ietf-types@iana.org 435 Subject: Registration of media type application/vcard+xml 437 Type name: application 439 Subtype name: vcard+xml 441 Required parameters: none 443 Optional parameters: none 445 Encoding considerations: Same as for application/xml. 447 Security considerations: See Section 6. 449 Interoperability considerations: This media type provides an 450 alternative syntax to vCard data [I-D.ietf-vcarddav-vcardrev] 451 based on XML. 453 Published specification: This specification. 455 Applications which use this media type: Applications that currently 456 make use of the text/vcard media type can use this as an 457 alternative. 459 Additional information: 461 Magic number(s): none 463 File extension(s): XML data should use ".xml" as the file 464 extension. 466 Macintosh file type code(s): none 468 Person & email address to contact for further information: Simon 469 Perreault 471 Intended usage: COMMON 473 Restrictions on usage: none 475 Author: Simon Perreault 477 Change controller: IETF 479 8. Acknowledgements 481 Thanks to the following people for their input: 483 Alexey Melnikov, Barry Leiba, Cyrus Daboo, Joe Hildebrand, Joseph 484 Smarr, Marc Blanchet, Peter Saint-Andre, Robins George, Zahhar 485 Kirillov, Zoltan Ordogh. 487 9. References 489 9.1. Normative References 491 [I-D.ietf-vcarddav-vcardrev] Perreault, S., "vCard Format 492 Specification", 493 draft-ietf-vcarddav-vcardrev-16 (work 494 in progress), March 2011. 496 [relaxng] Clark, J., "RELAX NG Specification", 497 December 2001. 499 [relaxng-compact] Clark, J., "RELAX NG Compact Syntax", 500 November 2002, . 503 9.2. Informative References 505 [I-D.dawson-vcard-xml-dtd] Dawson, F., "The vCard v3.0 XML DTD", 506 draft-dawson-vcard-xml-dtd-03 (work in 507 progress), June 1998. 509 Appendix A. Relax NG Schema 511 default namespace = "urn:ietf:params:xml:ns:vcard-4.0" 513 # Value types 514 value-text = element text { text } 515 value-text-list = value-text+ 516 value-uri = element uri { xsd:anyURI } 517 value-date = element date { 518 xsd:string { pattern = "\d{8}|\d{4}-\d\d|--\d\d(\d\d)?|---\d\d" } 519 } 520 value-time = element time { 521 xsd:string { pattern = "(\d\d(\d\d(\d\d)?)?|-\d\d(\d\d?)|--\d\d)" 522 ~ "(Z|[+\-]\d\d(\d\d)?)?" } 523 } 524 value-date-time = element date-time { 525 xsd:string { pattern = "(\d{8}|--\d{4}|---\d\d)T\d\d(\d\d(\d\d)?)?" 526 ~ "(Z|[+\-]\d\d(\d\d)?)?" } 527 } 528 value-date-and-or-time = value-date | value-date-time | value-time 529 value-timestamp = element timestamp { 530 xsd:string { pattern = "\d{8}T\d{6}(Z|[+\-]\d\d(\d\d)?)?" } 531 } 532 value-boolean = element boolean { xsd:boolean } 533 value-integer = element integer { xsd:integer } 534 value-float = element float { xsd:float } 535 value-language-tag = element language-tag { 536 xsd:string { pattern = "([a-z]{2,3}((-[a-z]{3}){0,3})?|[a-z]{4,8})" 537 ~ "(-[a-z]{4})?(-([a-z]{2}|\d{3}))?" 538 ~ "(-([0-9a-z]{5,8}|\d[0-9a-z]{3}))*" 539 ~ "(-[0-9a-wyz](-[0-9a-z]{2,8})+)*" 540 ~ "(-x(-[0-9a-z]{1,8})+)?|x(-[0-9a-z]{1,8})+|" 541 ~ "[a-z]{1,3}(-[0-9a-z]{2,8}){1,2}" } 542 } 544 # Parameters 545 param-language = element language { value-language-tag }? 546 param-pref = element pref { 547 element integer { 548 xsd:integer { minInclusive = "1" maxInclusive = "100" } 549 } 550 }? 551 param-altid = element altid { value-text }? 552 param-pid = element pid { 553 xsd:string { pattern = "\d+(\.\d+)?" } 554 }? 556 param-type = element type { element text { "work" | "home" }+ }? 557 param-calscale = element calscale { element text { "gregorian" } }? 558 param-sort-as = element sort-as { value-text+ }? 559 param-geo = element geo { value-uri }? 560 param-tz = element tz { value-text | value-uri }? 561 param-label = element label { value-text }? 563 # Properties 564 property-source = element source { 565 element parameters { param-altid, param-pid, param-pref }, 566 value-uri 567 } 568 property-kind = element kind { 569 element text { "individual" | "group" | "org" | "location" }* 570 } 571 property-fn = element fn { 572 element parameters { param-language, param-altid, param-pid, 573 param-pref, param-type }?, 574 value-text 575 } 576 property-n = element n { 577 element parameters { param-language, param-sort-as, param-altid }?, 578 element surname { value-text-list? }, 579 element given { value-text-list? }, 580 element additional { value-text-list? }, 581 element prefix { value-text-list? }, 582 element suffix { value-text-list? } 583 } 584 property-nickname = element nickname { 585 element parameters { param-language, param-altid, param-pid, 586 param-pref, param-type }?, 587 value-text-list 588 } 589 property-photo = element photo { 590 element parameters { 591 param-altid, 592 param-pid, 593 param-pref, 594 param-type 595 }?, 596 value-uri 597 } 598 property-bday = element bday { 599 element parameters { param-altid, param-calscale }?, 600 (value-date-and-or-time | value-text) 601 } 602 property-anniversary = element anniversary { 603 element parameters { param-altid, param-calscale }?, 604 (value-date-and-or-time | value-text) 605 } 606 property-gender = element gender { 607 element sex { 608 element text { "M" | "F" | "O" | "N" | "U" }? 609 }, 610 element identity { value-text-list? } 611 } 612 property-adr = element adr { 613 element parameters { 614 param-language, 615 param-altid, 616 param-pid, 617 param-pref, 618 param-type, 619 param-geo, 620 param-tz, 621 param-label 622 }?, 623 element pobox { value-text-list? }, 624 element ext { value-text-list? }, 625 element street { value-text-list? }, 626 element locality { value-text-list? }, 627 element region { value-text-list? }, 628 element code { value-text-list? }, 629 element country { value-text-list? } 630 } 631 property-tel = element tel { 632 element parameters { 633 param-altid, 634 param-pid, 635 param-pref, 636 element type { 637 element text { "work" | "home" | "text" | "voice" 638 | "fax" | "cell" | "video" | "pager" 639 | "textphone" }+ 640 }? 641 }?, 642 (value-text | value-uri) 643 } 644 property-email = element email { 645 element parameters { param-altid, param-pid, param-pref, 646 param-type }?, 647 value-text 648 } 649 property-impp = element impp { 650 element parameters { param-altid, param-pid, param-pref, 651 param-type }?, 653 value-uri 654 } 655 property-lang = element lang { 656 element parameters { param-altid, param-pid, param-pref, 657 param-type }?, 658 value-language-tag 659 } 660 property-tz = element tz { 661 element parameters { param-altid, param-pid, param-pref, 662 param-type }?, 663 (value-text | value-uri) 664 } 665 property-geo = element geo { 666 element parameters { param-altid, param-pid, param-pref, 667 param-type }?, 668 value-uri 669 } 670 property-title = element title { 671 element parameters { param-language, param-altid, param-pid, 672 param-pref, param-type }?, 673 value-text 674 } 675 property-role = element role { 676 element parameters { param-language, param-altid, param-pid, 677 param-pref, param-type }?, 678 value-text 679 } 680 property-logo = element logo { 681 element parameters { 682 param-language, 683 param-altid, 684 param-pid, 685 param-pref, 686 param-type 687 }?, 688 value-uri 689 } 690 property-org = element org { 691 element parameters { param-language, param-altid, param-pid, 692 param-pref, param-type, param-sort-as }?, 693 value-text-list 694 } 695 property-member = element member { 696 element parameters { param-altid, param-pid, param-pref }?, 697 value-uri 698 } 699 property-related = element related { 700 element parameters { 701 param-altid, 702 param-pid, 703 param-pref, 704 element type { 705 element text { 706 "work" | "home" | "contact" | "acquaintance" | 707 "friend" | "met" | "co-worker" | "colleague" | "co-resident" | 708 "neighbor" | "child" | "parent" | "sibling" | "spouse" | 709 "kin" | "muse" | "crush" | "date" | "sweetheart" | "me" 710 }+ 711 }? 712 }?, 713 (value-uri | value-text) 714 } 715 property-categories = element categories { 716 element parameters { param-altid, param-pid, param-pref, 717 param-type }?, 718 value-text-list 719 } 720 property-note = element note { 721 element parameters { param-language, param-altid, param-pid, 722 param-pref, param-type }?, 723 value-text 724 } 725 property-prodid = element prodid { value-text } 726 property-rev = element rev { value-timestamp } 727 property-sound = element sound { 728 element parameters { 729 param-language, 730 param-altid, 731 param-pid, 732 param-pref, 733 param-type 734 }?, 735 value-uri 736 } 737 property-uid = element uid { value-uri } 738 property-clientpidmap = element clientpidmap { 739 element sourceid { xsd:positiveInteger }, 740 value-uri 741 } 742 property-url = element url { 743 element parameters { param-altid, param-pid, param-pref, 744 param-type }?, 745 value-uri 746 } 747 property-key = element key { 748 element parameters { 749 param-altid, 750 param-pid, 751 param-pref, 752 param-type 753 }?, 754 (value-uri | value-text) 755 } 756 property-fburl = element fburl { 757 element parameters { param-altid, param-pid, param-pref, 758 param-type }?, 759 value-uri 760 } 761 property-caladruri = element caladruri { 762 element parameters { param-altid, param-pid, param-pref, 763 param-type }?, 764 value-uri 765 } 766 property-caluri = element caluri { 767 element parameters { param-altid, param-pid, param-pref, 768 param-type }?, 769 value-uri 770 } 772 # Top-level grammar 773 property = property-adr | property-anniversary | property-bday 774 | property-caladruri | property-caluri | property-categories 775 | property-clientpidmap | property-email | property-fburl 776 | property-fn | property-geo | property-impp | property-key 777 | property-kind | property-lang | property-logo 778 | property-member | property-n | property-nickname 779 | property-note | property-org | property-photo 780 | property-prodid | property-related | property-rev 781 | property-role | property-gender | property-sound 782 | property-source | property-tel | property-title 783 | property-tz | property-uid | property-url 784 start = element vcards { 785 element vcard { 786 (property 787 | element group { 788 attribute name { text }, 789 property* 790 })+ 791 }+ 792 } 794 Appendix B. Change Log (to be removed by RFC Editor prior to 795 publication) 797 B.1. Changes in -07 799 o Synchronized with draft-ietf-vcarddav-vcardrev-16. 801 o Fixed bad XML in example. 803 o Fixed which now takes a value-text-list. 805 o All parameters now use value elements. This affects type, 806 calscale, and pref. 808 B.2. Changes in -06 810 o Synchronized with draft-ietf-vcarddav-vcardrev-15. 812 B.3. Changes in -05 814 o Synchronized with draft-ietf-vcarddav-vcardrev-13. 816 B.4. Changes in -04 818 o Synchronized with draft-ietf-vcarddav-vcardrev-12. 820 o Added application/vcard+xml media type. 822 o Added rules for backslash escaping and quoting when converting. 824 o Added description of element. 826 o Described group construct in XML. 828 B.5. Changes in -03 830 o Created "Format Conversions" section. 832 o Turned more parameter values into plain text. 834 o Removed need for empty value elements in components. 836 o Wrapped value of , , and in value elements. 838 B.6. Changes in -02 840 o Synchronized with draft-ietf-vcarddav-vcardrev-10. 842 o Turned parameter values into plain text. 844 o Moved the "XML" property to vCard base. 846 o Changed title to avoid confusion with XML Schema. 848 o Added prefixes "value-", "param-", and "property-" in schema. 850 o Better language for specifying what a parser must ignore. 852 B.7. Changes in -01 854 o Synchronized with draft-ietf-vcarddav-vcardrev-09. 856 o Added the element to allow multiple vCards in a single 857 XML file. 859 o Created the container element. 861 o Use text value for enumeration in element. 863 o Created the "XML" vCard property. 865 o Added IANA considerations section. 867 o Added security considerations section. 869 B.8. Changes in -00 871 o Same as draft-perreault-vcarddav-vcardxml-02. 873 Author's Address 875 Simon Perreault 876 Viagenie 877 2600 boul. Laurier, suite 625 878 Quebec, QC G1V 4W1 879 Canada 881 Phone: +1 418 656 9254 882 EMail: simon.perreault@viagenie.ca 883 URI: http://www.viagenie.ca