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