idnits 2.17.1 draft-perreault-vcarddav-vcardxml-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The 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 186: '...vCard XML parser MUST ignore elements ...' RFC 2119 keyword, line 203: '... origiginal vCard format [I-D.ietf-vcarddav-vcardrev] MUST still be...' RFC 2119 keyword, line 209: '...rary. The order MUST be respected in ...' RFC 2119 keyword, line 211: '... vCard MAY happen....' -- The draft header indicates that this document obsoletes RFC2425, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document obsoletes RFC2426, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document obsoletes RFC4770, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC2739, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2739, updated by this document, for RFC5378 checks: 1998-08-14) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 13, 2009) is 5402 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-08 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 7 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 Obsoletes: 2425, 2426, 4770 July 13, 2009 5 (if approved) 6 Updates: 2739 (if approved) 7 Intended status: Standards Track 8 Expires: January 14, 2010 10 vCard XML Schema 11 draft-perreault-vcarddav-vcardxml-02 13 Status of This Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 14, 2010. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 49 This document defines the XML schema of the vCard data format. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. The Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Example: Author's XML vCard . . . . . . . . . . . . . . . . . 3 56 4. Design Considerations . . . . . . . . . . . . . . . . . . . . 4 57 4.1. Extensibility . . . . . . . . . . . . . . . . . . . . . . 5 58 4.2. Limitations . . . . . . . . . . . . . . . . . . . . . . . 5 59 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 60 6. Normative References . . . . . . . . . . . . . . . . . . . . . 6 61 Appendix A. Relax NG Schema . . . . . . . . . . . . . . . . . . . 6 62 Appendix B. Change Log (to be removed by RFC Editor prior to 63 publication) . . . . . . . . . . . . . . . . . . . . 10 64 B.1. Changes in -02 . . . . . . . . . . . . . . . . . . . . . . 10 65 B.2. Changes in -01 . . . . . . . . . . . . . . . . . . . . . . 10 67 1. Introduction 69 vCard [I-D.ietf-vcarddav-vcardrev] is a data format for representing 70 and exchanging information about individuals. It is a text-based 71 format (as opposed to a binary format). This document defines an XML 72 representation for vCard. The underlying data structure is exactly 73 the same, enabling a 1-to-1 mapping between the original vCard format 74 and the XML representation. The XML formatting may be preferred in 75 some contexts where an XML engine is readily available and may be 76 reused instead of writing a stand-alone vCard parser. 78 2. The Schema 80 The schema is expressed in the RELAX NG language 81 [relaxng][relaxng-compact] and is found in Appendix A. 83 3. Example: Author's XML vCard 85 86 87 Simon Perreault 88 89 Perreault 90 Simon 91 92 93 ing. jr. 94 M.Sc. 95 96 97 --0203 98 99 20090808T1430-0500 100 101 1 102 1fr 103 2en 104 105 Viagenie 106 107 108 Suite 625 109 2600 boul. Laurier 110 Quebec 111 QC 112 G1V 4W1 113 Canada 114 115 116 117 tel:+1-418-656-9254;ext=102 118 119 120 121 tel:+1-418-262-6501 122 123 124 125 tel:+1-418-656-9257 126 127 simon.perreault@viagenie.ca 128 geo:46.772673,-71.282945 129 130 http://www.viagenie.ca/simon.perreault/simon.asc 131 132 133 America/Montreal 134 135 137 4. Design Considerations 139 The general idea is to map vCard parameters, properties, and value 140 types to XML elements. For example, the "FN" property is mapped to 141 the "fn" element. That element in turn contains a text element whose 142 content corresponds to the vCard property's value. 144 vCard parameters are also mapped to XML elements. They are contained 145 in property elements. For example, the "TYPE" parameter applied to 146 the "TEL" property would look like the following in XML: 148 149 150 tel:+1-555-555-555 151 153 Properties having structured values (e.g. the N property) are 154 expressed by XML element trees. Element names in that tree (e.g. 155 "surname", "given", etc.) do not have a vCard equivalent since they 156 are identified by position in plain vCard. 158 Line folding is a non-issue in XML. Therefore, the mapping from 159 vCard to XML is done after the unfolding procedure is carried out. 160 Conversely, the mapping from XML to vCard is done before the folding 161 procedure is carried out. 163 4.1. Extensibility 165 The original vCard format is extensible. New properties, parameters, 166 data types and values (collectively known as vCard objects) can be 167 registered from IANA. It is expected that these vCard extensions 168 will also specify extensions to the XML format described in this 169 document. This is not a requirement: a separate document may be used 170 instead. 172 Unregistered extensions (i.e. those starting with "X-" and 173 "VND-...-") can be expressed in XML by making use of XML namespaces. 174 They simply correspond to elements outside of the core namespace. 175 For example: 177 179 1 180 value goes here 181 183 Note that extension elements do not need the "X- or "VND-" prefix in 184 XML. The XML namespace mechanism is sufficient. 186 A vCard XML parser MUST ignore elements that are not part of this 187 specification. 189 In the original vCard format, the VERSION property was mandatory and 190 played a role in extensibility. In XML, this property is absent. 191 Its role is played by the vCard core namespace identifier, which 192 includes the version number. vCard revisions will use a different 193 namespace. 195 Since vCard also has provisions for extending value enumerations, 196 such as the allowed TYPE parameter values, these values are expressed 197 using tags in XML. 199 4.2. Limitations 201 The schema does not validate the cardinality of properties. This is 202 a limitation of the schema definition language. Cardinalities of the 203 origiginal vCard format [I-D.ietf-vcarddav-vcardrev] MUST still be 204 respected. 206 Some constructs (e.g. value enumerations in type parameters) have 207 additional ordering constraints in XML. This is a result of 208 limitations of the schema definition language and the order is 209 arbitrary. The order MUST be respected in XML for the vCard to be 210 valid. However, reordering as part of conversion to or from plain 211 vCard MAY happen. 213 5. Security Considerations 215 TBD 217 6. Normative References 219 [I-D.ietf-vcarddav-vcardrev] Perreault, S. and P. Resnick, "vCard 220 Format Specification", 221 draft-ietf-vcarddav-vcardrev-08 (work 222 in progress), July 2009. 224 [relaxng] Clark, J., "RELAX NG Specification", 225 December 2001. 227 [relaxng-compact] Clark, J., "RELAX NG Compact Syntax", 228 November 2002. 230 Appendix A. Relax NG Schema 232 default namespace = "urn:ietf:params:xml:ns:vcard-4.0" 234 # Value types 235 \text = element text { text } 236 text-list = \text+ 237 uri = element uri { xsd:anyURI } 238 date = 239 element date { 240 xsd:string { pattern = "\d{8}|\d{4}-\d\d|--\d\d(\d\d)?|---\d\d" } 241 } 242 time = 243 element time { 244 xsd:string { pattern = 245 "(\d\d(\d\d(\d\d)?)?|-\d\d(\d\d?)|--\d\d)" 246 ~ "(Z|[+\-]\d\d(\d\d)?)?" } 247 } 248 date-time = 249 element date-time { 250 xsd:string { pattern = 251 "(\d{8}|--\d{4}|---\d\d)T\d\d(\d\d(\d\d)?)?" 252 ~ "(Z|[+\-]\d\d(\d\d)?)?" } 253 } 254 date-and-or-time = date | date-time | time 255 timestamp = 256 element timestamp { 257 xsd:string { pattern = "\d{8}T\d{6}(Z|[+\-]\d\d(\d\d)?)?" } 258 } 260 boolean = element boolean { xsd:boolean } 261 integer = element integer { xsd:integer } 262 float = element float { xsd:float } 263 binary = element binary { xsd:base64Binary } 264 language-tag = 265 element language-tag { 266 xsd:string { pattern = 267 "([a-z]{2,3}((-[a-z]{3}){0,3})?|[a-z]{4,8})" 268 ~ "(-[a-z]{4})?(-([a-z]{2}|\d{3}))?" 269 ~ "(-([0-9a-z]{5,8}|\d[0-9a-z]{3}))*" 270 ~ "(-[0-9a-wyz](-[0-9a-z]{2,8})+)*(-x(-[0-9a-z]{1,8})+)?|" 271 ~ "x(-[0-9a-z]{1,8})+|[a-z]{1,3}(-[0-9a-z]{2,8}){1,2}" } 272 } 273 data = 274 (element type { 275 xsd:string { pattern = "[A-Za-z\d!#$&.+\-^_]{1,127}/" 276 ~ "[A-Za-z\d!#$&.+\-^_]{1,127}" } 277 }, 278 binary) 279 | uri 281 # Parameters 282 language = element language { language-tag }? 283 pref = 284 element pref { 285 xsd:integer { minInclusive = "1" maxInclusive = "100" } 286 }? 287 pid = 288 element pid { 289 xsd:string { pattern = "\d+(\.\d+)?" } 290 }? 292 # Properties 293 source = element source { pid, pref, uri } 294 name = element name { \text } 295 kind = 296 element kind { 297 element individual { empty } 298 | element group { empty } 299 | element org { empty } 300 | element location { empty } 301 } 302 fn = element fn { language, pid, pref, \text } 303 n = 304 element n { 305 language, 306 element surname { text-list }, 307 element given { text-list }, 308 element prefix { text-list }, 309 element suffix { text-list } 310 } 311 nickname = element nickname { language, pid, pref, text-list } 312 photo = element photo { pid, pref, data } 313 bday = element bday { date-and-or-time | \text } 314 dday = element dday { date-and-or-time | \text } 315 birth = element birth { language, \text } 316 death = element death { language, \text } 317 anniversary = element anniversary { date-and-or-time | \text } 318 sex = element sex { "0" | "1" | "2" | "9" } 319 adr = 320 element adr { 321 language, 322 element geo { uri }?, 323 element tz { \text | uri }?, 324 pid, 325 pref, 326 element pobox { text-list }, 327 element ext { text-list }, 328 element street { text-list }, 329 element locality { text-list }, 330 element region { text-list }, 331 element code { text-list }, 332 element country { text-list } 333 } 334 label = element label { language, pid, pref, \text } 335 tel = 336 element tel { 337 element type { 338 element text { empty }?, 339 element voice { empty }?, 340 element fax { empty }?, 341 element cell { empty }?, 342 element video { empty }?, 343 element pager { empty }? 344 }?, 345 pid, 346 pref, 347 uri 348 } 349 email = element email { pid, pref, \text } 350 impp = element impp { pid, pref, uri } 351 lang = element lang { pid, pref, language-tag } 352 tz = element tz { pid, pref, (\text | uri) } 353 geo = element geo { pid, pref, uri } 354 title = element title { language, pid, pref, \text } 355 role = element role { language, pid, pref, \text } 356 logo = element logo { language, pid, pref, data } 357 org = element org { language, pid, pref, text-list } 358 member = element member { pid, pref, uri } 359 related = 360 element related { 361 element type { 362 element parent { empty } 363 | element child { empty } 364 | element sibling { empty } 365 | element spouse { empty } 366 | element family { empty } 367 | element friend { empty } 368 | element supervisor { empty } 369 | element supervisee { empty } 370 | element assistant { empty } 371 | element colleague { empty } 372 | element agent { empty } 373 | element emergency { empty } 374 }?, 375 pid, 376 pref, 377 (uri | \text) 378 } 379 categories = element categories { pid, pref, \text } 380 note = element note { language, pid, pref, \text } 381 prodid = element prodid { \text } 382 rev = element rev { timestamp } 383 sort-string = element sort-string { \text } 384 sound = element sound { language, pid, pref, data } 385 uid = element uid { uri } 386 clientpidmap = 387 element clientpidmap { 388 element sourceid { xsd:positiveInteger }, 389 uri 390 } 391 url = element url { pid, pref, uri } 392 class = 393 element class { 394 element PUBLIC { empty } 395 | element PRIVATE { empty } 396 | element CONFIDENTIAL { empty } 397 } 398 key = element key { pid, pref, data } 399 fburl = element fburl { pid, pref, uri } 400 caladruri = element caladruri { pid, pref, uri } 401 caluri = element caluri { pid, pref, uri } 403 # Top-level grammar 404 group-property = fn | nickname | photo | adr | label | tel | email | 405 impp | lang | tz | geo | title | role | logo | org | related | 406 categories | note | sound | url | key | fburl | caladruri | caluri 407 any-property = group-property | source | name | kind | n | bday | 408 dday | birth | death | anniversary | sex | member | prodid | 409 rev | sort-string | uid | clientpidmap | class 410 start = 411 element vcard { 412 (any-property 413 | element group { 414 attribute name { text }, 415 group-property* 416 })* 417 } 419 Appendix B. Change Log (to be removed by RFC Editor prior to 420 publication) 422 B.1. Changes in -02 424 o Synchronized with [I-D.ietf-vcarddav-vcardrev]. 426 B.2. Changes in -01 428 o Completely reworked the schema as a result of WG feedback. 430 o Parameters and value types are now elements. 432 o Feature parity with plain vCard has been reached. 434 o RELAX NG compact syntax is now used. 436 o Chose XML namespace from IANA's range. 438 o Added section on limitations. 440 Author's Address 442 Simon Perreault 443 Viagenie 444 2600 boul. Laurier, suite 625 445 Quebec, QC G1V 4W1 446 Canada 448 Phone: +1 418 656 9254 449 EMail: simon.perreault@viagenie.ca 450 URI: http://www.viagenie.ca