idnits 2.17.1 draft-ietf-vcarddav-vcardxml-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 26, 2011) is 4718 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-20 ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) -- Obsolete informational reference (is this intentional?): RFC 4288 (Obsoleted by RFC 6838) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 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 26, 2011 5 Expires: November 27, 2011 7 xCard: vCard XML Representation 8 draft-ietf-vcarddav-vcardxml-11 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 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). Note that other groups may also distribute 21 working documents as Internet-Drafts. The list of current Internet- 22 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on November 27, 2011. 31 Copyright Notice 33 Copyright (c) 2011 IETF Trust and the persons identified as the 34 document authors. All rights reserved. 36 This document is subject to BCP 78 and the IETF Trust's Legal 37 Provisions Relating to IETF Documents 38 (http://trustee.ietf.org/license-info) in effect on the date of 39 publication of this document. Please review these documents 40 carefully, as they describe your rights and restrictions with respect 41 to this document. Code Components extracted from this document must 42 include Simplified BSD License text as described in Section 4.e of 43 the Trust Legal Provisions and are provided without warranty as 44 described in the Simplified BSD License. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 3. The Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 4. Example: Author's XML vCard . . . . . . . . . . . . . . . . . 3 52 5. Design Considerations . . . . . . . . . . . . . . . . . . . . 5 53 5.1. Extensibility . . . . . . . . . . . . . . . . . . . . . . 6 54 5.2. Limitations . . . . . . . . . . . . . . . . . . . . . . . 8 55 6. Format Conversions . . . . . . . . . . . . . . . . . . . . . . 8 56 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 57 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 58 8.1. Registration of the XML Namespace . . . . . . . . . . . . 10 59 8.2. Media Type . . . . . . . . . . . . . . . . . . . . . . . . 11 60 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 61 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 62 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 63 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 64 Appendix A. Relax NG Schema . . . . . . . . . . . . . . . . . . . 14 65 Appendix B. Change Log (to be removed by RFC Editor prior to 66 publication) . . . . . . . . . . . . . . . . . . . . 22 67 B.1. Changes in -11 . . . . . . . . . . . . . . . . . . . . . . 22 68 B.2. Changes in -10 . . . . . . . . . . . . . . . . . . . . . . 22 69 B.3. Changes in -09 . . . . . . . . . . . . . . . . . . . . . . 22 70 B.4. Changes in -08 . . . . . . . . . . . . . . . . . . . . . . 23 71 B.5. Changes in -07 . . . . . . . . . . . . . . . . . . . . . . 23 72 B.6. Changes in -06 . . . . . . . . . . . . . . . . . . . . . . 23 73 B.7. Changes in -05 . . . . . . . . . . . . . . . . . . . . . . 23 74 B.8. Changes in -04 . . . . . . . . . . . . . . . . . . . . . . 23 75 B.9. Changes in -03 . . . . . . . . . . . . . . . . . . . . . . 23 76 B.10. Changes in -02 . . . . . . . . . . . . . . . . . . . . . . 24 77 B.11. Changes in -01 . . . . . . . . . . . . . . . . . . . . . . 24 78 B.12. Changes in -00 . . . . . . . . . . . . . . . . . . . . . . 24 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 xCard, an XML [W3C.REC-xml-20081126] representation 86 for vCard. The underlying data structure is exactly the same, 87 enabling a 1-to-1 mapping between the original vCard format and the 88 XML representation. The XML formatting may be preferred in some 89 contexts where an XML engine is readily available and may be reused 90 instead of writing a stand-alone 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. Conventions 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in [RFC2119]. 102 3. The Schema 104 The schema is expressed in the RELAX NG language [ISO.19757-2.2008] 105 and is found in Appendix A. 107 4. Example: Author's XML vCard 109 110 111 112 Simon Perreault 113 114 Perreault 115 Simon 116 117 118 ing. jr 119 M.Sc. 120 121 --0203 122 123 20090808T1430-0500 124 125 M 126 127 1 128 fr 129 130 131 2 132 en 133 134 135 work 136 Viagenie 137 138 139 140 work 141 145 146 147 148 2875 boul. Laurier, suite D2-630 149 Quebec 150 QC 151 G1V 2M2 152 Canada 153 154 155 156 157 work 158 voice 159 160 161 tel:+1-418-656-9254;ext=102 162 163 164 165 166 work 167 text 168 voice 169 cell 170 video 171 172 173 tel:+1-418-262-6501 174 175 176 work 177 simon.perreault@viagenie.ca 178 179 180 work 181 geo:46.766336,-71.28955 182 183 184 work 185 http://www.viagenie.ca/simon.perreault/simon.asc 186 187 America/Montreal 188 189 home 190 http://nomis80.org 191 192 193 195 5. Design Considerations 197 The general idea is to map vCard parameters, properties, and value 198 types to XML elements. For example, the "FN" property is mapped to 199 the "fn" element. That element in turn contains a text element whose 200 content corresponds to the vCard property's value. 202 vCard parameters are also mapped to XML elements. They are contained 203 in the element, which is contained in property elements. 204 For example, the "TYPE" parameter applied to the "TEL" property would 205 look like the following in XML: 207 208 209 210 voice 211 video 212 213 214 tel:+1-555-555-555 215 217 Parameters taking a list of values are simply repeated multiple 218 times, once for each value in the list. 220 Properties having structured values (e.g. the "N" property) are 221 expressed by XML element trees. Element names in that tree (e.g. 222 "surname", "given", etc.) do not have a vCard equivalent since they 223 are identified by position in plain vCard. 225 Line folding is a non-issue in XML. Therefore, the mapping from 226 vCard to XML is done after the unfolding procedure is carried out. 227 Conversely, the mapping from XML to vCard is done before the folding 228 procedure is carried out. 230 A top-level element is used as root. It contains one or 231 more element, each representing a complete vCard. The 232 element MUST be present even when only a single vCard is 233 present in an XML document. 235 The group construct (Section 3.2 in [I-D.ietf-vcarddav-vcardrev]) is 236 represented with the element. The "name" attribute contains 237 the group's name. For example: 239 240 241 242 ... 243 ... 244 245 246 ... 247 248 ... 249 250 252 is equivalent to: 254 BEGIN:VCARD 255 VERSION:4.0 256 contact.FN=... 257 contact.EMAIL=... 258 media.PHOTO=... 259 CATEGORIES=... 260 END:VCARD 262 5.1. Extensibility 264 The original vCard format is extensible. New properties, parameters, 265 data types and values (collectively known as vCard elements, not to 266 be confused with XML elements) can be registered with IANA (see 267 [I-D.ietf-vcarddav-vcardrev] section 10.2). It is expected that 268 these vCard extensions will also specify extensions to the XML format 269 described in this document. 271 New XML vCard property and parameter element names MUST be lower- 272 case. This is necessary to ensure that round-tripping between XML 273 and plain-text vCard works correctly. 275 Unregistered extensions (i.e. those starting with "X-" and 276 "VND-...-") are expressed in XML by using elements starting with "x-" 277 and "vnd-...-". Usage of XML namespaces [W3C.REC-xml-names-20091208] 278 for extensibility is RECOMMENDED for extensions that have no 279 equivalent in plain text vCard. Refer to Section 6 for the 280 implications when converting between plain-text vCard and XML. 282 Examples: 284 285 286 1 287 288 value goes here 289 291 293 294 1 295 296 value goes here 297 299 Note that extension elements do not need the "X- or "VND-" prefix in 300 XML. The XML namespace mechanism is sufficient. 302 A vCard XML parser MUST ignore XML elements and attributes for which 303 it doesn't recognize the expanded name. The normal behaviour of 304 ignoring XML processing instructions whose target is not recognized 305 MUST also be followed. 307 In the original vCard format, the "VERSION" property was mandatory 308 and played a role in extensibility. In XML, this property is absent. 309 Its role is played by the vCard core namespace identifier, which 310 includes the version number. vCard revisions will use a different 311 namespace. 313 Parameters containing a list of values are expressed using a list of 314 elements in XML (e.g. the element). 316 5.2. Limitations 318 The schema does not validate the cardinality of properties. This is 319 a limitation of the schema definition language. Cardinalities of the 320 original vCard format [I-D.ietf-vcarddav-vcardrev] MUST still be 321 respected. 323 Some constructs (e.g. value enumerations in type parameters) have 324 additional ordering constraints in XML. This is a result of 325 limitations of the schema definition language and the order is 326 arbitrary. The order MUST be respected in XML for the vCard to be 327 valid. However, reordering as part of conversion to or from plain 328 vCard MAY happen. 330 6. Format Conversions 332 When new properties or "X-" proeprties used, a vCard<->xCard 333 converter might not recognize them, and know what the appropriate 334 default value types are, yet they need to be able to preserve the 335 values. A similar issue arises for unrecognized property parameters. 336 As a result, the following rules are applied when dealing with 337 unrecognized properties and property parameters: 339 o When converting from vCard to xCard: 341 * Any property that does not include a "VALUE" parameter and 342 whose default value type is not known MUST be converted using 343 the value type XML element . The content of that 344 element is the unprocessed value text. 346 * Any unrecognized property parameter MUST be converted using the 347 value type XML element , with its content set to the 348 parameter value text, treated as if it were a text value, or 349 list of text values. 351 * The content of "XML" properties is copied as-is to XML. 353 * Property and parameter XML element names are converted to 354 lower-case. 356 * Property value escaping is undone. For example, "\n" becomes a 357 NEWLINE character (ASCII decimal 10). 359 * Double-quoting of parameter values, as well as backslash 360 escaping in parameter values, is undone. For example, 361 PARAM="\"foo\",\"bar\"" becomes "foo","bar". 363 o When converting xCard to vCard: 365 * Properties in the vCard 4 namespace: 367 + If the converter knows of a specific plain-text 368 representation for this property, it uses it. For example, 369 the element corresponds to the "ADR" property, which 370 is encoded using comma-separated lists separated by semi- 371 colons. 373 + Otherwise, the property name is taken from the element name, 374 property parameters are taken from the element, 375 and the content of the property is taken from the content of 376 the value element. If the property element has attributes 377 or contains other XML elements, they are dropped. 379 + If a standard property's XML element contains XML elements 380 and attributes for which the converter doesn't recognize the 381 expanded name, they are dropped. Therefore, it is 382 RECOMMENDED to limit extensions to the property level to 383 ensure that all data is preserved intact in round-trip 384 conversions. 386 * Properties in other namespaces are wrapped as-is inside an 387 "XML" property. 389 * Any property value XML elements are converted 390 directly into vCard values. The containing property MUST NOT 391 have a "VALUE" parameter. 393 * Any parameter value XML elements are converted as if 394 they were value type XML elements. 396 * Property and parameter names are converted to upper-case. 398 * Property value escaping (Section 3.3 of 399 [I-D.ietf-vcarddav-vcardrev]) is carried out. For example, a 400 NEWLINE character (ASCII decimal 10) becomes "\n". 402 * Double-quoting of parameter values, as well as backslash 403 escaping in parameter values, is carried out. For example, 404 "foo","bar" becomes PARAM="\"foo\",\"bar\"". 406 For example, these two vCards are equivalent: 408 409 410 411 J. Doe 412 413 Doe 414 J. 415 416 417 418 419 420 421 image/jpeg 422 423 alien.jpg 424 425 My web page! 427 428 430 BEGIN:VCARD 431 VERSION:4.0 432 FN:J. Doe 433 N:Doe;J.;; 434 X-FILE;MEDIATYPE=image/jpeg:alien.jpg 435 XML:My web page! 437 END:VCARD 439 7. Security Considerations 441 All the security considerations applicable to plain vCard 442 [I-D.ietf-vcarddav-vcardrev] are applicable to this document as well. 444 XML Signature [W3C.CR-xmldsig-core1-20110303] and XML Encryption 445 [W3C.CR-xmlenc-core1-20110303] can be used with xCard to provide 446 authentication and confidentiality. 448 8. IANA Considerations 450 8.1. Registration of the XML Namespace 451 URI: urn:ietf:params:xml:ns:vcard-4.0 453 Registrant Contact: Simon Perreault 455 XML: None. Namespace URIs do not represent an XML specification. 457 8.2. Media Type 459 This section defines the MIME media type [RFC4288] for use with 460 vCard-in-XML data. 462 To: ietf-types@iana.org 464 Subject: Registration of media type application/vcard+xml 466 Type name: application 468 Subtype name: vcard+xml 470 Required parameters: none 472 Optional parameters: charset as defined for application/xml in 473 [RFC3023]; per [RFC3023], use of the charset parameter with the 474 value "utf-8" is "STRONGLY RECOMMENDED" 476 Encoding considerations: Same as encoding considerations of 477 application/xml as specified in [RFC3023] 479 Security considerations: This media type has all of the security 480 considerations described in [RFC3023], plus those listed in 481 Section 7. 483 Interoperability considerations: This media type provides an 484 alternative syntax to vCard data [I-D.ietf-vcarddav-vcardrev] 485 based on XML. 487 Published specification: This specification. 489 Applications which use this media type: Applications that currently 490 make use of the text/vcard media type can use this as an 491 alternative. In general, applications that maintain or process 492 contact information can use this media type. 494 Additional information: 496 Magic number(s): none 498 File extension(s): XML data should use ".xml" as the file 499 extension. 501 Macintosh file type code(s): none 503 Person & email address to contact for further information: Simon 504 Perreault 506 Intended usage: COMMON 508 Restrictions on usage: none 510 Author: Simon Perreault 512 Change controller: IETF 514 9. Acknowledgements 516 Thanks to the following people for their input: 518 Alexey Melnikov, Barry Leiba, Bjorn Hoehrmann, Cyrus Daboo, Joe 519 Hildebrand, Joseph Smarr, Marc Blanchet, Mike Douglas, Peter Saint- 520 Andre, Robins George, Zahhar Kirillov, Zoltan Ordogh. 522 10. References 524 10.1. Normative References 526 [I-D.ietf-vcarddav-vcardrev] Perreault, S., "vCard Format 527 Specification", 528 draft-ietf-vcarddav-vcardrev-20 529 (work in progress), May 2011. 531 [ISO.19757-2.2008] International Organization for 532 Standardization, "Information 533 technology -- Document Schema 534 Definition Language (DSDL) -- Part 535 2: Regular-grammar-based validation 536 -- RELAX NG", ISO International 537 Standard 19757-2, October 2008. 539 [RFC2119] Bradner, S., "Key words for use in 540 RFCs to Indicate Requirement 541 Levels", BCP 14, RFC 2119, 542 March 1997. 544 [RFC3023] Murata, M., St. Laurent, S., and D. 545 Kohn, "XML Media Types", RFC 3023, 546 January 2001. 548 [W3C.REC-xml-20081126] Yergeau, F., Maler, E., Paoli, J., 549 Sperberg-McQueen, C., and T. Bray, 550 "Extensible Markup Language (XML) 551 1.0 (Fifth Edition)", World Wide Web 552 Consortium Recommendation REC-xml- 553 20081126, November 2008, . 557 [W3C.REC-xml-names-20091208] Tobin, R., Hollander, D., Thompson, 558 H., Bray, T., and A. Layman, 559 "Namespaces in XML 1.0 (Third 560 Edition)", World Wide Web Consortium 561 Recommendation REC-xml-names- 562 20091208, December 2009, . 566 10.2. Informative References 568 [I-D.dawson-vcard-xml-dtd] Dawson, F., "The vCard v3.0 XML 569 DTD", draft-dawson-vcard-xml-dtd-03 570 (work in progress), June 1998. 572 [RFC4288] Freed, N. and J. Klensin, "Media 573 Type Specifications and Registration 574 Procedures", BCP 13, RFC 4288, 575 December 2005. 577 [W3C.CR-xmldsig-core1-20110303] Reagle, J., Roessler, T., Solo, D., 578 Yiu, K., Eastlake, D., Nystroem, M., 579 and F. Hirsch, "XML Signature Syntax 580 and Processing Version 1.1", World 581 Wide Web Consortium CR CR-xmldsig- 582 core1-20110303, March 2011, . 586 [W3C.CR-xmlenc-core1-20110303] Eastlake, D., Reagle, J., Hirsch, 587 F., and T. Roessler, "XML Encryption 588 Syntax and Processing Version 1.1", 589 World Wide Web Consortium CR CR- 590 xmlenc-core1-20110303, March 2011, < 591 http://www.w3.org/TR/2011/ 592 CR-xmlenc-core1-20110303>. 594 Appendix A. Relax NG Schema 596 default namespace = "urn:ietf:params:xml:ns:vcard-4.0" 598 ### Section 3.3: vCard Format Specification 599 # 600 # 3.3 601 iana-token = xsd:string { pattern = "[a-zA-Z0-9-]+" } 602 x-name = xsd:string { pattern = "x-[a-zA-Z0-9-]+" } 604 ### Section 4: Value types 605 # 606 # 4.1 607 value-text = element text { text } 608 value-text-list = value-text+ 610 # 4.2 611 value-uri = element uri { xsd:anyURI } 613 # 4.3.1 614 value-date = element date { 615 xsd:string { pattern = "\d{8}|\d{4}-\d\d|--\d\d(\d\d)?|---\d\d" } 616 } 618 # 4.3.2 619 value-time = element time { 620 xsd:string { pattern = "(\d\d(\d\d(\d\d)?)?|-\d\d(\d\d?)|--\d\d)" 621 ~ "(Z|[+\-]\d\d(\d\d)?)?" } 622 } 624 # 4.3.3 625 value-date-time = element date-time { 626 xsd:string { pattern = "(\d{8}|--\d{4}|---\d\d)T\d\d(\d\d(\d\d)?)?" 627 ~ "(Z|[+\-]\d\d(\d\d)?)?" } 628 } 630 # 4.3.4 631 value-date-and-or-time = value-date | value-date-time | value-time 633 # 4.3.5 634 value-timestamp = element timestamp { 635 xsd:string { pattern = "\d{8}T\d{6}(Z|[+\-]\d\d(\d\d)?)?" } 636 } 638 # 4.4 639 value-boolean = element boolean { xsd:boolean } 640 # 4.5 641 value-integer = element integer { xsd:integer } 643 # 4.6 644 value-float = element float { xsd:float } 646 # 4.7 647 value-utc-offset = element utc-offset { 648 xsd:string { pattern = "[+\-]\d\d(\d\d)?" } 649 } 651 # 4.8 652 value-language-tag = element language-tag { 653 xsd:string { pattern = "([a-z]{2,3}((-[a-z]{3}){0,3})?|[a-z]{4,8})" 654 ~ "(-[a-z]{4})?(-([a-z]{2}|\d{3}))?" 655 ~ "(-([0-9a-z]{5,8}|\d[0-9a-z]{3}))*" 656 ~ "(-[0-9a-wyz](-[0-9a-z]{2,8})+)*" 657 ~ "(-x(-[0-9a-z]{1,8})+)?|x(-[0-9a-z]{1,8})+|" 658 ~ "[a-z]{1,3}(-[0-9a-z]{2,8}){1,2}" } 659 } 661 ### Section 5: Parameters 662 # 663 # 5.1 664 param-language = element language { value-language-tag }? 666 # 5.2 667 param-pref = element pref { 668 element integer { 669 xsd:integer { minInclusive = "1" maxInclusive = "100" } 670 } 671 }? 673 # 5.4 674 param-altid = element altid { value-text }? 676 # 5.5 677 param-pid = element pid { 678 element text { xsd:string { pattern = "\d+(\.\d+)?" } }+ 679 }? 681 # 5.6 682 param-type = element type { element text { "work" | "home" }+ }? 684 # 5.7 685 param-mediatype = element mediatype { value-text }? 687 # 5.8 688 param-calscale = element calscale { element text { "gregorian" } }? 690 # 5.9 691 param-sort-as = element sort-as { value-text+ }? 693 # 5.10 694 param-geo = element geo { value-uri }? 696 # 5.11 697 param-tz = element tz { value-text | value-uri }? 699 ### Section 6: Properties 700 # 701 # 6.1.3 702 property-source = element source { 703 element parameters { param-altid, param-pid, param-pref, 704 param-mediatype }, 705 value-uri 706 } 708 # 6.1.4 709 property-kind = element kind { 710 element text { "individual" | "group" | "org" | "location" | 711 x-name | iana-token }* 712 } 714 # 6.2.1 715 property-fn = element fn { 716 element parameters { param-language, param-altid, param-pid, 717 param-pref, param-type }?, 718 value-text 719 } 721 # 6.2.2 722 property-n = element n { 723 element parameters { param-language, param-sort-as, param-altid }?, 724 element surname { text }+, 725 element given { text }+, 726 element additional { text }+, 727 element prefix { text }+, 728 element suffix { text }+ 729 } 731 # 6.2.3 732 property-nickname = element nickname { 733 element parameters { param-language, param-altid, param-pid, 734 param-pref, param-type }?, 735 value-text-list 737 } 739 # 6.2.4 740 property-photo = element photo { 741 element parameters { param-altid, param-pid, param-pref, param-type, 742 param-mediatype }?, 743 value-uri 744 } 746 # 6.2.5 747 property-bday = element bday { 748 element parameters { param-altid, param-calscale }?, 749 (value-date-and-or-time | value-text) 750 } 752 # 6.2.6 753 property-anniversary = element anniversary { 754 element parameters { param-altid, param-calscale }?, 755 (value-date-and-or-time | value-text) 756 } 758 # 6.2.7 759 property-gender = element gender { 760 element sex { "" | "M" | "F" | "O" | "N" | "U" }, 761 element identity { text }? 762 } 764 # 6.3.1 765 param-label = element label { value-text }? 766 property-adr = element adr { 767 element parameters { param-language, param-altid, param-pid, 768 param-pref, param-type, param-geo, param-tz, 769 param-label }?, 770 element pobox { text }+, 771 element ext { text }+, 772 element street { text }+, 773 element locality { text }+, 774 element region { text }+, 775 element code { text }+, 776 element country { text }+ 777 } 779 # 6.4.1 780 property-tel = element tel { 781 element parameters { 782 param-altid, 783 param-pid, 784 param-pref, 785 element type { 786 element text { "work" | "home" | "text" | "voice" 787 | "fax" | "cell" | "video" | "pager" 788 | "textphone" }+ 789 }?, 790 param-mediatype 791 }?, 792 (value-text | value-uri) 793 } 795 # 6.4.2 796 property-email = element email { 797 element parameters { param-altid, param-pid, param-pref, 798 param-type }?, 799 value-text 800 } 802 # 6.4.3 803 property-impp = element impp { 804 element parameters { param-altid, param-pid, param-pref, 805 param-type, param-mediatype }?, 806 value-uri 807 } 809 # 6.4.4 810 property-lang = element lang { 811 element parameters { param-altid, param-pid, param-pref, 812 param-type }?, 813 value-language-tag 814 } 816 # 6.5.1 817 property-tz = element tz { 818 element parameters { param-altid, param-pid, param-pref, 819 param-type, param-mediatype }?, 820 (value-text | value-uri | value-utc-offset) 821 } 823 # 6.5.2 824 property-geo = element geo { 825 element parameters { param-altid, param-pid, param-pref, 826 param-type, param-mediatype }?, 827 value-uri 828 } 830 # 6.6.1 831 property-title = element title { 832 element parameters { param-language, param-altid, param-pid, 833 param-pref, param-type }?, 834 value-text 835 } 837 # 6.6.2 838 property-role = element role { 839 element parameters { param-language, param-altid, param-pid, 840 param-pref, param-type }?, 841 value-text 842 } 844 # 6.6.3 845 property-logo = element logo { 846 element parameters { param-language, param-altid, param-pid, 847 param-pref, param-type, param-mediatype }?, 848 value-uri 849 } 851 # 6.6.4 852 property-org = element org { 853 element parameters { param-language, param-altid, param-pid, 854 param-pref, param-type, param-sort-as }?, 855 value-text-list 856 } 858 # 6.6.5 859 property-member = element member { 860 element parameters { param-altid, param-pid, param-pref, 861 param-mediatype }?, 862 value-uri 863 } 865 # 6.6.6 866 property-related = element related { 867 element parameters { 868 param-altid, 869 param-pid, 870 param-pref, 871 element type { 872 element text { 873 "work" | "home" | "contact" | "acquaintance" | 874 "friend" | "met" | "co-worker" | "colleague" | "co-resident" | 875 "neighbor" | "child" | "parent" | "sibling" | "spouse" | 876 "kin" | "muse" | "crush" | "date" | "sweetheart" | "me" | 877 "agent" | "emergency" 878 }+ 879 }?, 880 param-mediatype 882 }?, 883 (value-uri | value-text) 884 } 886 # 6.7.1 887 property-categories = element categories { 888 element parameters { param-altid, param-pid, param-pref, 889 param-type }?, 890 value-text-list 891 } 893 # 6.7.2 894 property-note = element note { 895 element parameters { param-language, param-altid, param-pid, 896 param-pref, param-type }?, 897 value-text 898 } 900 # 6.7.3 901 property-prodid = element prodid { value-text } 903 # 6.7.4 904 property-rev = element rev { value-timestamp } 906 # 6.7.5 907 property-sound = element sound { 908 element parameters { param-language, param-altid, param-pid, 909 param-pref, param-type, param-mediatype }?, 910 value-uri 911 } 913 # 6.7.6 914 property-uid = element uid { value-uri } 916 # 6.7.7 917 property-clientpidmap = element clientpidmap { 918 element sourceid { xsd:positiveInteger }, 919 value-uri 920 } 922 # 6.7.8 923 property-url = element url { 924 element parameters { param-altid, param-pid, param-pref, 925 param-type, param-mediatype }?, 926 value-uri 927 } 929 # 6.8.1 930 property-key = element key { 931 element parameters { param-altid, param-pid, param-pref, 932 param-type, param-mediatype }?, 933 (value-uri | value-text) 934 } 936 # 6.9.1 937 property-fburl = element fburl { 938 element parameters { param-altid, param-pid, param-pref, 939 param-type, param-mediatype }?, 940 value-uri 941 } 943 # 6.9.2 944 property-caladruri = element caladruri { 945 element parameters { param-altid, param-pid, param-pref, 946 param-type, param-mediatype }?, 947 value-uri 948 } 950 # 6.9.3 951 property-caluri = element caluri { 952 element parameters { param-altid, param-pid, param-pref, 953 param-type, param-mediatype }?, 954 value-uri 955 } 957 # Top-level grammar 958 property = property-adr | property-anniversary | property-bday 959 | property-caladruri | property-caluri | property-categories 960 | property-clientpidmap | property-email | property-fburl 961 | property-fn | property-geo | property-impp | property-key 962 | property-kind | property-lang | property-logo 963 | property-member | property-n | property-nickname 964 | property-note | property-org | property-photo 965 | property-prodid | property-related | property-rev 966 | property-role | property-gender | property-sound 967 | property-source | property-tel | property-title 968 | property-tz | property-uid | property-url 969 start = element vcards { 970 element vcard { 971 (property 972 | element group { 973 attribute name { text }, 974 property* 975 })+ 976 }+ 977 } 979 Appendix B. Change Log (to be removed by RFC Editor prior to 980 publication) 982 B.1. Changes in -11 984 o Refer to ISO standard for Relax NG. 986 o Adjust text on vCard extensibility through IANA. 988 o Add missing case conversion rules. 990 o Refer to XML Signature and XML Encryption in security 991 considerations section. 993 B.2. Changes in -10 995 o Fixed bugs in examples. 997 o New XML elements MUST be lower-case. 999 o Adjusted case conversion rules for unknown parameters. 1001 o Added utc-offset as possible value type to tz property. 1003 o Added "agent" and "emergency" related values. 1005 o Added x-name and iana-token in kind values. 1007 o Added cross-references to vcardrev sections. 1009 o Add element for round-tripping. 1011 o Tweak sex grammar. 1013 o "Structured" properties don't need elements. 1015 o Fixed wrong example. 1017 B.3. Changes in -09 1019 o Added "Conventions" section with reference to RFC2119. 1021 o Fixed bad XML in example. 1023 o Updated MIME type registration following feedback from 1024 ietf-types@iana.org. 1026 B.4. Changes in -08 1028 o Synchronized with draft-ietf-vcarddav-vcardrev-17. 1030 o Added some references. 1032 o Fixed bad XML in example. 1034 o Added element around pid param value. 1036 B.5. Changes in -07 1038 o Synchronized with draft-ietf-vcarddav-vcardrev-16. 1040 o Fixed bad XML in example. 1042 o Fixed which now takes a value-text-list. 1044 o All parameters now use value elements. This affects type, 1045 calscale, and pref. 1047 B.6. Changes in -06 1049 o Synchronized with draft-ietf-vcarddav-vcardrev-15. 1051 B.7. Changes in -05 1053 o Synchronized with draft-ietf-vcarddav-vcardrev-13. 1055 B.8. Changes in -04 1057 o Synchronized with draft-ietf-vcarddav-vcardrev-12. 1059 o Added application/vcard+xml media type. 1061 o Added rules for backslash escaping and quoting when converting. 1063 o Added description of element. 1065 o Described group construct in XML. 1067 B.9. Changes in -03 1069 o Created "Format Conversions" section. 1071 o Turned more parameter values into plain text. 1073 o Removed need for empty value elements in components. 1075 o Wrapped value of , , and in value elements. 1077 B.10. Changes in -02 1079 o Synchronized with draft-ietf-vcarddav-vcardrev-10. 1081 o Turned parameter values into plain text. 1083 o Moved the "XML" property to vCard base. 1085 o Changed title to avoid confusion with XML Schema. 1087 o Added prefixes "value-", "param-", and "property-" in schema. 1089 o Better language for specifying what a parser must ignore. 1091 B.11. Changes in -01 1093 o Synchronized with draft-ietf-vcarddav-vcardrev-09. 1095 o Added the element to allow multiple vCards in a single 1096 XML file. 1098 o Created the container element. 1100 o Use text value for enumeration in element. 1102 o Created the "XML" vCard property. 1104 o Added IANA considerations section. 1106 o Added security considerations section. 1108 B.12. Changes in -00 1110 o Same as draft-perreault-vcarddav-vcardxml-02. 1112 Author's Address 1114 Simon Perreault 1115 Viagenie 1116 2600 boul. Laurier, suite 625 1117 Quebec, QC G1V 4W1 1118 Canada 1120 Phone: +1 418 656 9254 1121 EMail: simon.perreault@viagenie.ca 1122 URI: http://www.viagenie.ca