aboutsummaryrefslogtreecommitdiffstats
path: root/vendor/sabre/dav/docs/rfc6351.txt
diff options
context:
space:
mode:
Diffstat (limited to 'vendor/sabre/dav/docs/rfc6351.txt')
-rw-r--r--vendor/sabre/dav/docs/rfc6351.txt1235
1 files changed, 1235 insertions, 0 deletions
diff --git a/vendor/sabre/dav/docs/rfc6351.txt b/vendor/sabre/dav/docs/rfc6351.txt
new file mode 100644
index 000000000..5ae0fa3f2
--- /dev/null
+++ b/vendor/sabre/dav/docs/rfc6351.txt
@@ -0,0 +1,1235 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) S. Perreault
+Request for Comments: 6351 Viagenie
+Category: Standards Track August 2011
+ISSN: 2070-1721
+
+
+ xCard: vCard XML Representation
+
+Abstract
+
+ This document defines the XML schema of the vCard data format.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6351.
+
+Copyright Notice
+
+ Copyright (c) 2011 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+
+
+
+Perreault Standards Track [Page 1]
+
+RFC 6351 xCard August 2011
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 3. The Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 4. Example: Author's XML vCard . . . . . . . . . . . . . . . . . 3
+ 5. Design Considerations . . . . . . . . . . . . . . . . . . . . 4
+ 5.1. Extensibility . . . . . . . . . . . . . . . . . . . . . . 6
+ 5.2. Limitations . . . . . . . . . . . . . . . . . . . . . . . 7
+ 6. Format Conversions . . . . . . . . . . . . . . . . . . . . . . 8
+ 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
+ 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
+ 8.1. Registration of the XML Namespace . . . . . . . . . . . . 11
+ 8.2. Media Type . . . . . . . . . . . . . . . . . . . . . . . . 11
+ 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
+ 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
+ 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
+ 10.2. Informative References . . . . . . . . . . . . . . . . . . 13
+ Appendix A. Relax NG Schema . . . . . . . . . . . . . . . . . . . 14
+
+1. Introduction
+
+ vCard [RFC6350] is a data format for representing and exchanging
+ information about individuals and other entities. It is a text-based
+ format (as opposed to a binary format). This document defines xCard,
+ an XML [W3C.REC-xml-20081126] representation for vCard. The
+ underlying data structure is exactly the same, enabling a 1-to-1
+ mapping between the original vCard format and the XML representation.
+ The XML formatting may be preferred in some contexts where an XML
+ engine is readily available and may be reused instead of writing a
+ standalone vCard parser.
+
+ Earlier work on an XML format for vCard was started in 1998 by Frank
+ Dawson [VCARD-DTD]. Sadly, it did not take over the world.
+
+2. Conventions
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2119].
+
+3. The Schema
+
+ The schema is expressed in the RELAX NG language [ISO.19757-2.2008]
+ and is found in Appendix A.
+
+
+
+
+
+
+Perreault Standards Track [Page 2]
+
+RFC 6351 xCard August 2011
+
+
+4. Example: Author's XML vCard
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <vcards xmlns="urn:ietf:params:xml:ns:vcard-4.0">
+ <vcard>
+ <fn><text>Simon Perreault</text></fn>
+ <n>
+ <surname>Perreault</surname>
+ <given>Simon</given>
+ <additional/>
+ <prefix/>
+ <suffix>ing. jr</suffix>
+ <suffix>M.Sc.</suffix>
+ </n>
+ <bday><date>--0203</date></bday>
+ <anniversary>
+ <date-time>20090808T1430-0500</date-time>
+ </anniversary>
+ <gender><sex>M</sex></gender>
+ <lang>
+ <parameters><pref><integer>1</integer></pref></parameters>
+ <language-tag>fr</language-tag>
+ </lang>
+ <lang>
+ <parameters><pref><integer>2</integer></pref></parameters>
+ <language-tag>en</language-tag>
+ </lang>
+ <org>
+ <parameters><type><text>work</text></type></parameters>
+ <text>Viagenie</text>
+ </org>
+ <adr>
+ <parameters>
+ <type><text>work</text></type>
+ <label><text>Simon Perreault
+ 2875 boul. Laurier, suite D2-630
+ Quebec, QC, Canada
+ G1V 2M2</text></label>
+ </parameters>
+ <pobox/>
+ <ext/>
+ <street>2875 boul. Laurier, suite D2-630</street>
+ <locality>Quebec</locality>
+ <region>QC</region>
+ <code>G1V 2M2</code>
+ <country>Canada</country>
+ </adr>
+ <tel>
+
+
+
+Perreault Standards Track [Page 3]
+
+RFC 6351 xCard August 2011
+
+
+ <parameters>
+ <type>
+ <text>work</text>
+ <text>voice</text>
+ </type>
+ </parameters>
+ <uri>tel:+1-418-656-9254;ext=102</uri>
+ </tel>
+ <tel>
+ <parameters>
+ <type>
+ <text>work</text>
+ <text>text</text>
+ <text>voice</text>
+ <text>cell</text>
+ <text>video</text>
+ </type>
+ </parameters>
+ <uri>tel:+1-418-262-6501</uri>
+ </tel>
+ <email>
+ <parameters><type><text>work</text></type></parameters>
+ <text>simon.perreault@viagenie.ca</text>
+ </email>
+ <geo>
+ <parameters><type><text>work</text></type></parameters>
+ <uri>geo:46.766336,-71.28955</uri>
+ </geo>
+ <key>
+ <parameters><type><text>work</text></type></parameters>
+ <uri>http://www.viagenie.ca/simon.perreault/simon.asc</uri>
+ </key>
+ <tz><text>America/Montreal</text></tz>
+ <url>
+ <parameters><type><text>home</text></type></parameters>
+ <uri>http://nomis80.org</uri>
+ </url>
+ </vcard>
+ </vcards>
+
+5. Design Considerations
+
+ The general idea is to map vCard parameters, properties, and value
+ types to XML elements. For example, the "FN" property is mapped to
+ the "fn" element. In turn, that element contains a text element
+ whose content corresponds to the vCard property's value.
+
+
+
+
+
+Perreault Standards Track [Page 4]
+
+RFC 6351 xCard August 2011
+
+
+ vCard parameters are also mapped to XML elements. They are contained
+ in the <parameters> element, which is contained in property elements.
+ For example, the "TYPE" parameter applied to the "TEL" property would
+ look like the following in XML:
+
+ <tel>
+ <parameters>
+ <type>
+ <text>voice</text>
+ <text>video</text>
+ </type>
+ </parameters>
+ <uri>tel:+1-555-555-555</uri>
+ </tel>
+
+ Parameters taking a list of values are simply repeated multiple
+ times, once for each value in the list.
+
+ Properties having structured values (e.g., the "N" property) are
+ expressed by XML element trees. Element names in that tree (e.g.,
+ "surname", "given", etc.) do not have a vCard equivalent since they
+ are identified by position in plain vCard.
+
+ Line folding is a non-issue in XML. Therefore, the mapping from
+ vCard to XML is done after the unfolding procedure is carried out.
+ Conversely, the mapping from XML to vCard is done before the folding
+ procedure is carried out.
+
+ A top-level <vcards> element is used as root. It contains one or
+ more <vcard> elements, each representing a complete vCard. The
+ <vcards> element MUST be present even when only a single vCard is
+ present in an XML document.
+
+ The group construct (Section 3.2 in [RFC6350]) is represented with
+ the <group> element. The "name" attribute contains the group's name.
+ For example:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Perreault Standards Track [Page 5]
+
+RFC 6351 xCard August 2011
+
+
+ <vcards>
+ <vcard>
+ <group name="contact">
+ <fn>...</fn>
+ <email>...</email>
+ </group>
+ <group name="media">
+ <photo>...</photo>
+ </group>
+ <categories>...</categories>
+ </vcard>
+ </vcards>
+
+ is equivalent to:
+
+ BEGIN:VCARD
+ VERSION:4.0
+ contact.FN=...
+ contact.EMAIL=...
+ media.PHOTO=...
+ CATEGORIES=...
+ END:VCARD
+
+5.1. Extensibility
+
+ The original vCard format is extensible. New properties, parameters,
+ data types and values (collectively known as vCard elements, not to
+ be confused with XML elements) can be registered with IANA (see
+ [RFC6350], Section 10.2). It is expected that these vCard extensions
+ will also specify extensions to the XML format described in this
+ document.
+
+ New XML vCard property and parameter element names MUST be lower-
+ case. This is necessary to ensure that round-tripping between XML
+ and plain-text vCard works correctly.
+
+ Unregistered extensions (i.e., those starting with "X-" and
+ "VND-...-") are expressed in XML by using elements starting with "x-"
+ and "vnd-...-". Usage of XML namespaces [W3C.REC-xml-names-20091208]
+ for extensibility is RECOMMENDED for extensions that have no
+ equivalent in plain-text vCard. Refer to Section 6 for the
+ implications when converting between plain-text vCard and XML.
+
+
+
+
+
+
+
+
+
+Perreault Standards Track [Page 6]
+
+RFC 6351 xCard August 2011
+
+
+ Examples:
+
+ <x-my-prop>
+ <parameters>
+ <pref><integer>1</integer></pref>
+ </parameters>
+ <text>value goes here</text>
+ </x-my-prop>
+
+ <ext:my-prop
+ ext:xmlns="http://example.com/extensions/my-vcard">
+ <parameters>
+ <pref><integer>1</integer></pref>
+ </parameters> <!-- Core vCard elements -->
+ <text>value goes here</text> <!-- are still accessible -->
+ </ext:my-prop>
+
+ Note that extension elements do not need the "X-" or "VND-" prefix in
+ XML. The XML namespace mechanism is sufficient.
+
+ A vCard XML parser MUST ignore XML elements and attributes for which
+ it doesn't recognize the expanded name. The normal behavior of
+ ignoring XML processing instructions whose target is not recognized
+ MUST also be followed.
+
+ In the original vCard format, the "VERSION" property was mandatory
+ and played a role in extensibility. In XML, this property is absent.
+ Its role is played by the vCard core namespace identifier, which
+ includes the version number. vCard revisions will use a different
+ namespace.
+
+ Parameters containing a list of values are expressed using a list of
+ elements in XML (e.g., the <type> element).
+
+5.2. Limitations
+
+ The schema does not validate the cardinality of properties. This is
+ a limitation of the schema definition language. Cardinalities of the
+ original vCard format [RFC6350] MUST still be respected.
+
+ Some constructs (e.g., value enumerations in type parameters) have
+ additional ordering constraints in XML. This is a result of
+ limitations of the schema definition language, and the order is
+ arbitrary. The order MUST be respected in XML for the vCard to be
+ valid. However, reordering as part of conversion to or from plain
+ vCard MAY happen.
+
+
+
+
+
+Perreault Standards Track [Page 7]
+
+RFC 6351 xCard August 2011
+
+
+6. Format Conversions
+
+ When new properties or "X-" properties are used, a vCard<->xCard
+ converter might not recognize them or know what the appropriate
+ default value types are, yet they need to be able to preserve the
+ values. A similar issue arises for unrecognized property parameters.
+ As a result, the following rules are applied when dealing with
+ unrecognized properties and property parameters:
+
+ o When converting from vCard to xCard:
+
+ * Any property that does not include a "VALUE" parameter and
+ whose default value type is not known MUST be converted using
+ the value type XML element <unknown>. The content of that
+ element is the unprocessed value text.
+
+ * Any unrecognized property parameter MUST be converted using the
+ value type XML element <unknown>, with its content set to the
+ parameter value text, treated as if it were a text value, or
+ list of text values.
+
+ * The content of "XML" properties is copied as is to XML.
+
+ * Property and parameter XML element names are converted to
+ lower-case.
+
+ * Property value escaping is undone. For example, "\n" becomes a
+ NEWLINE character (ASCII decimal 10).
+
+ * Double-quoting of parameter values, as well as backslash
+ escaping in parameter values, is undone. For example,
+ PARAM="\"foo\",\"bar\"" becomes <param>"foo","bar"</param>.
+
+ o When converting xCard to vCard:
+
+ * Properties in the vCard 4 namespace:
+
+ + If the converter knows of a specific plain-text
+ representation for this property, it uses it. For example,
+ the <adr> element corresponds to the "ADR" property, which
+ is encoded using comma-separated lists separated by
+ semicolons.
+
+ + Otherwise, the property name is taken from the element name,
+ property parameters are taken from the <parameters> element,
+ and the content of the property is taken from the content of
+ the value element. If the property element has attributes
+ or contains other XML elements, they are dropped.
+
+
+
+Perreault Standards Track [Page 8]
+
+RFC 6351 xCard August 2011
+
+
+ + If a standard property's XML element contains XML elements
+ and attributes for which the converter doesn't recognize the
+ expanded name, they are dropped. Therefore, it is
+ RECOMMENDED to limit extensions to the property level to
+ ensure that all data is preserved intact in round-trip
+ conversions.
+
+ * Properties in other namespaces are wrapped as is inside an
+ "XML" property.
+
+ * Any <unknown> property value XML elements are converted
+ directly into vCard values. The containing property MUST NOT
+ have a "VALUE" parameter.
+
+ * Any <unknown> parameter value XML elements are converted as if
+ they were <text> value type XML elements.
+
+ * Property and parameter names are converted to upper-case.
+
+ * Property value escaping (Section 3.3 of [RFC6350]) is carried
+ out. For example, a NEWLINE character (ASCII decimal 10)
+ becomes "\n".
+
+ * Double-quoting of parameter values, as well as backslash
+ escaping in parameter values, is carried out. For example,
+ <param>"foo","bar"</param> becomes PARAM="\"foo\",\"bar\"".
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Perreault Standards Track [Page 9]
+
+RFC 6351 xCard August 2011
+
+
+ For example, these two vCards are equivalent:
+
+ <?xml version="1.0"?>
+ <vcards xmlns="urn:ietf:params:xml:ns:vcard-4.0">
+ <vcard>
+ <fn><text>J. Doe</text></fn>
+ <n>
+ <surname>Doe</surname>
+ <given>J.</given>
+ <additional/>
+ <prefix/>
+ <suffix/>
+ </n>
+ <x-file>
+ <parameters>
+ <mediatype><text>image/jpeg</text></mediatype>
+ </parameters>
+ <unknown>alien.jpg</unknown>
+ </x-file>
+ <a xmlns="http://www.w3.org/1999/xhtml"
+ href="http://www.example.com">My web page!</a>
+ </vcard>
+ </vcards>
+
+
+ BEGIN:VCARD
+ VERSION:4.0
+ FN:J. Doe
+ N:Doe;J.;;
+ X-FILE;MEDIATYPE=image/jpeg:alien.jpg
+ XML:<a xmlns="http://www.w3.org/1999/xhtml"\n
+ href="http://www.example.com">My web page!</a>
+ END:VCARD
+
+7. Security Considerations
+
+ All the security considerations applicable to plain vCard [RFC6350]
+ are applicable to this document as well.
+
+ XML Signature [W3C.CR-xmldsig-core1-20110303] and XML Encryption
+ [W3C.CR-xmlenc-core1-20110303] can be used with xCard to provide
+ authentication and confidentiality.
+
+
+
+
+
+
+
+
+
+Perreault Standards Track [Page 10]
+
+RFC 6351 xCard August 2011
+
+
+8. IANA Considerations
+
+8.1. Registration of the XML Namespace
+
+ URI: urn:ietf:params:xml:ns:vcard-4.0
+
+ Registrant Contact: The IESG <iesg@ietf.org>
+
+ XML: None. Namespace URIs do not represent an XML specification.
+
+8.2. Media Type
+
+ This section defines the MIME media type [RFC4288] for use with
+ vCard-in-XML data.
+
+ To: ietf-types@iana.org
+
+ Subject: Registration of media type application/vcard+xml
+
+ Type name: application
+
+ Subtype name: vcard+xml
+
+ Required parameters: none
+
+ Optional parameters: charset as defined for application/xml in
+ [RFC3023]; per [RFC3023], use of the charset parameter with the
+ value "utf-8" is "STRONGLY RECOMMENDED".
+
+ Encoding considerations: Same as encoding considerations of
+ application/xml as specified in [RFC3023].
+
+ Security considerations: This media type has all of the security
+ considerations described in [RFC3023], plus those listed in
+ Section 7.
+
+ Interoperability considerations: This media type provides an
+ alternative syntax to vCard data [RFC6350] based on XML.
+
+ Published specification: This specification.
+
+ Applications that use this media type: Applications that currently
+ make use of the text/vcard media type can use this as an
+ alternative. In general, applications that maintain or process
+ contact information can use this media type.
+
+
+
+
+
+
+Perreault Standards Track [Page 11]
+
+RFC 6351 xCard August 2011
+
+
+ Additional information:
+
+ Magic number(s): none
+
+ File extension(s): XML data should use ".xml" as the file
+ extension.
+
+ Macintosh file type code(s): none
+
+ Person & email address to contact for further information: Simon
+ Perreault <simon.perreault@viagenie.ca>
+
+ Intended usage: COMMON
+
+ Restrictions on usage: none
+
+ Author: Simon Perreault
+
+ Change controller: IETF
+
+9. Acknowledgments
+
+ Thanks to the following people for their input:
+
+ Alexey Melnikov, Barry Leiba, Bjorn Hoehrmann, Cyrus Daboo, Joe
+ Hildebrand, Joseph Smarr, Marc Blanchet, Mike Douglass, Peter Saint-
+ Andre, Robins George, Zahhar Kirillov, Zoltan Ordogh.
+
+
+10. References
+
+10.1. Normative References
+
+ [ISO.19757-2.2008]
+ International Organization for Standardization,
+ "Information technology -- Document Schema Definition
+ Language (DSDL) -- Part 2: Regular-grammar-based
+ validation -- RELAX NG", ISO International
+ Standard 19757-2, October 2008.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
+ Types", RFC 3023, January 2001.
+
+ [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350,
+ August 2011.
+
+
+
+Perreault Standards Track [Page 12]
+
+RFC 6351 xCard August 2011
+
+
+ [W3C.REC-xml-20081126]
+ Paoli, J., Yergeau, F., Maler, E., Bray, T., and C.
+ Sperberg-McQueen, "Extensible Markup Language (XML) 1.0
+ (Fifth Edition)", World Wide Web Consortium
+ Recommendation REC-xml-20081126, November 2008,
+ <http://www.w3.org/TR/2008/REC-xml-20081126>.
+
+ [W3C.REC-xml-names-20091208]
+ Bray, T., Hollander, D., Layman, A., Tobin, R., and H.
+ Thompson, "Namespaces in XML 1.0 (Third Edition)", World
+ Wide Web Consortium Recommendation REC-xml-names-20091208,
+ December 2009,
+ <http://www.w3.org/TR/2009/REC-xml-names-20091208>.
+
+10.2. Informative References
+
+ [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
+ Registration Procedures", BCP 13, RFC 4288, December 2005.
+
+ [VCARD-DTD]
+ Dawson, F., "The vCard v3.0 XML DTD", Work in Progress,
+ June 1998.
+
+ [W3C.CR-xmldsig-core1-20110303]
+ Roessler, T., Solo, D., Yiu, K., Reagle, J., Hirsch, F.,
+ Eastlake, D., and M. Nystroem, "XML Signature Syntax and
+ Processing Version 1.1", World Wide Web Consortium CR CR-
+ xmldsig-core1-20110303, March 2011,
+ <http://www.w3.org/TR/2011/CR-xmldsig-core1-20110303>.
+
+ [W3C.CR-xmlenc-core1-20110303]
+ Eastlake, D., Reagle, J., Roessler, T., and F. Hirsch,
+ "XML Encryption Syntax and Processing Version 1.1", World
+ Wide Web Consortium CR CR-xmlenc-core1-20110303,
+ March 2011,
+ <http://www.w3.org/TR/2011/CR-xmlenc-core1-20110303>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Perreault Standards Track [Page 13]
+
+RFC 6351 xCard August 2011
+
+
+Appendix A. Relax NG Schema
+
+default namespace = "urn:ietf:params:xml:ns:vcard-4.0"
+
+### Section 3.3: vCard Format Specification
+#
+# 3.3
+iana-token = xsd:string { pattern = "[a-zA-Z0-9-]+" }
+x-name = xsd:string { pattern = "x-[a-zA-Z0-9-]+" }
+
+### Section 4: Value types
+#
+# 4.1
+value-text = element text { text }
+value-text-list = value-text+
+
+# 4.2
+value-uri = element uri { xsd:anyURI }
+
+# 4.3.1
+value-date = element date {
+ xsd:string { pattern = "\d{8}|\d{4}-\d\d|--\d\d(\d\d)?|---\d\d" }
+ }
+
+# 4.3.2
+value-time = element time {
+ xsd:string { pattern = "(\d\d(\d\d(\d\d)?)?|-\d\d(\d\d?)|--\d\d)"
+ ~ "(Z|[+\-]\d\d(\d\d)?)?" }
+ }
+
+# 4.3.3
+value-date-time = element date-time {
+ xsd:string { pattern = "(\d{8}|--\d{4}|---\d\d)T\d\d(\d\d(\d\d)?)?"
+ ~ "(Z|[+\-]\d\d(\d\d)?)?" }
+ }
+
+# 4.3.4
+value-date-and-or-time = value-date | value-date-time | value-time
+
+# 4.3.5
+value-timestamp = element timestamp {
+ xsd:string { pattern = "\d{8}T\d{6}(Z|[+\-]\d\d(\d\d)?)?" }
+ }
+
+# 4.4
+value-boolean = element boolean { xsd:boolean }
+
+
+
+
+
+Perreault Standards Track [Page 14]
+
+RFC 6351 xCard August 2011
+
+
+# 4.5
+value-integer = element integer { xsd:integer }
+
+# 4.6
+value-float = element float { xsd:float }
+
+# 4.7
+value-utc-offset = element utc-offset {
+ xsd:string { pattern = "[+\-]\d\d(\d\d)?" }
+ }
+
+# 4.8
+value-language-tag = element language-tag {
+ xsd:string { pattern = "([a-z]{2,3}((-[a-z]{3}){0,3})?|[a-z]{4,8})"
+ ~ "(-[a-z]{4})?(-([a-z]{2}|\d{3}))?"
+ ~ "(-([0-9a-z]{5,8}|\d[0-9a-z]{3}))*"
+ ~ "(-[0-9a-wyz](-[0-9a-z]{2,8})+)*"
+ ~ "(-x(-[0-9a-z]{1,8})+)?|x(-[0-9a-z]{1,8})+|"
+ ~ "[a-z]{1,3}(-[0-9a-z]{2,8}){1,2}" }
+ }
+
+### Section 5: Parameters
+#
+# 5.1
+param-language = element language { value-language-tag }?
+
+# 5.2
+param-pref = element pref {
+ element integer {
+ xsd:integer { minInclusive = "1" maxInclusive = "100" }
+ }
+ }?
+
+# 5.4
+param-altid = element altid { value-text }?
+
+# 5.5
+param-pid = element pid {
+ element text { xsd:string { pattern = "\d+(\.\d+)?" } }+
+ }?
+
+# 5.6
+param-type = element type { element text { "work" | "home" }+ }?
+
+# 5.7
+param-mediatype = element mediatype { value-text }?
+
+
+
+
+
+Perreault Standards Track [Page 15]
+
+RFC 6351 xCard August 2011
+
+
+# 5.8
+param-calscale = element calscale { element text { "gregorian" } }?
+
+# 5.9
+param-sort-as = element sort-as { value-text+ }?
+
+# 5.10
+param-geo = element geo { value-uri }?
+
+# 5.11
+param-tz = element tz { value-text | value-uri }?
+
+### Section 6: Properties
+#
+# 6.1.3
+property-source = element source {
+ element parameters { param-altid, param-pid, param-pref,
+ param-mediatype },
+ value-uri
+ }
+
+# 6.1.4
+property-kind = element kind {
+ element text { "individual" | "group" | "org" | "location" |
+ x-name | iana-token }*
+ }
+
+# 6.2.1
+property-fn = element fn {
+ element parameters { param-language, param-altid, param-pid,
+ param-pref, param-type }?,
+ value-text
+ }
+
+# 6.2.2
+property-n = element n {
+ element parameters { param-language, param-sort-as, param-altid }?,
+ element surname { text }+,
+ element given { text }+,
+ element additional { text }+,
+ element prefix { text }+,
+ element suffix { text }+
+ }
+
+
+
+
+
+
+
+
+Perreault Standards Track [Page 16]
+
+RFC 6351 xCard August 2011
+
+
+# 6.2.3
+property-nickname = element nickname {
+ element parameters { param-language, param-altid, param-pid,
+ param-pref, param-type }?,
+ value-text-list
+ }
+
+# 6.2.4
+property-photo = element photo {
+ element parameters { param-altid, param-pid, param-pref, param-type,
+ param-mediatype }?,
+ value-uri
+ }
+
+# 6.2.5
+property-bday = element bday {
+ element parameters { param-altid, param-calscale }?,
+ (value-date-and-or-time | value-text)
+ }
+
+# 6.2.6
+property-anniversary = element anniversary {
+ element parameters { param-altid, param-calscale }?,
+ (value-date-and-or-time | value-text)
+ }
+
+# 6.2.7
+property-gender = element gender {
+ element sex { "" | "M" | "F" | "O" | "N" | "U" },
+ element identity { text }?
+ }
+
+# 6.3.1
+param-label = element label { value-text }?
+property-adr = element adr {
+ element parameters { param-language, param-altid, param-pid,
+ param-pref, param-type, param-geo, param-tz,
+ param-label }?,
+ element pobox { text }+,
+ element ext { text }+,
+ element street { text }+,
+ element locality { text }+,
+ element region { text }+,
+ element code { text }+,
+ element country { text }+
+ }
+
+
+
+
+
+Perreault Standards Track [Page 17]
+
+RFC 6351 xCard August 2011
+
+
+# 6.4.1
+property-tel = element tel {
+ element parameters {
+ param-altid,
+ param-pid,
+ param-pref,
+ element type {
+ element text { "work" | "home" | "text" | "voice"
+ | "fax" | "cell" | "video" | "pager"
+ | "textphone" }+
+ }?,
+ param-mediatype
+ }?,
+ (value-text | value-uri)
+ }
+
+# 6.4.2
+property-email = element email {
+ element parameters { param-altid, param-pid, param-pref,
+ param-type }?,
+ value-text
+ }
+
+# 6.4.3
+property-impp = element impp {
+ element parameters { param-altid, param-pid, param-pref,
+ param-type, param-mediatype }?,
+ value-uri
+ }
+
+# 6.4.4
+property-lang = element lang {
+ element parameters { param-altid, param-pid, param-pref,
+ param-type }?,
+ value-language-tag
+ }
+
+# 6.5.1
+property-tz = element tz {
+ element parameters { param-altid, param-pid, param-pref,
+ param-type, param-mediatype }?,
+ (value-text | value-uri | value-utc-offset)
+ }
+
+
+
+
+
+
+
+
+Perreault Standards Track [Page 18]
+
+RFC 6351 xCard August 2011
+
+
+# 6.5.2
+property-geo = element geo {
+ element parameters { param-altid, param-pid, param-pref,
+ param-type, param-mediatype }?,
+ value-uri
+ }
+
+# 6.6.1
+property-title = element title {
+ element parameters { param-language, param-altid, param-pid,
+ param-pref, param-type }?,
+ value-text
+ }
+
+# 6.6.2
+property-role = element role {
+ element parameters { param-language, param-altid, param-pid,
+ param-pref, param-type }?,
+ value-text
+ }
+
+# 6.6.3
+property-logo = element logo {
+ element parameters { param-language, param-altid, param-pid,
+ param-pref, param-type, param-mediatype }?,
+ value-uri
+ }
+
+# 6.6.4
+property-org = element org {
+ element parameters { param-language, param-altid, param-pid,
+ param-pref, param-type, param-sort-as }?,
+ value-text-list
+ }
+
+# 6.6.5
+property-member = element member {
+ element parameters { param-altid, param-pid, param-pref,
+ param-mediatype }?,
+ value-uri
+ }
+
+
+
+
+
+
+
+
+
+
+Perreault Standards Track [Page 19]
+
+RFC 6351 xCard August 2011
+
+
+# 6.6.6
+property-related = element related {
+ element parameters {
+ param-altid,
+ param-pid,
+ param-pref,
+ element type {
+ element text {
+ "work" | "home" | "contact" | "acquaintance" |
+ "friend" | "met" | "co-worker" | "colleague" | "co-resident" |
+ "neighbor" | "child" | "parent" | "sibling" | "spouse" |
+ "kin" | "muse" | "crush" | "date" | "sweetheart" | "me" |
+ "agent" | "emergency"
+ }+
+ }?,
+ param-mediatype
+ }?,
+ (value-uri | value-text)
+ }
+
+# 6.7.1
+property-categories = element categories {
+ element parameters { param-altid, param-pid, param-pref,
+ param-type }?,
+ value-text-list
+ }
+
+# 6.7.2
+property-note = element note {
+ element parameters { param-language, param-altid, param-pid,
+ param-pref, param-type }?,
+ value-text
+ }
+
+# 6.7.3
+property-prodid = element prodid { value-text }
+
+# 6.7.4
+property-rev = element rev { value-timestamp }
+
+# 6.7.5
+property-sound = element sound {
+ element parameters { param-language, param-altid, param-pid,
+ param-pref, param-type, param-mediatype }?,
+ value-uri
+ }
+
+
+
+
+
+Perreault Standards Track [Page 20]
+
+RFC 6351 xCard August 2011
+
+
+# 6.7.6
+property-uid = element uid { value-uri }
+
+# 6.7.7
+property-clientpidmap = element clientpidmap {
+ element sourceid { xsd:positiveInteger },
+ value-uri
+ }
+
+# 6.7.8
+property-url = element url {
+ element parameters { param-altid, param-pid, param-pref,
+ param-type, param-mediatype }?,
+ value-uri
+ }
+
+# 6.8.1
+property-key = element key {
+ element parameters { param-altid, param-pid, param-pref,
+ param-type, param-mediatype }?,
+ (value-uri | value-text)
+ }
+
+# 6.9.1
+property-fburl = element fburl {
+ element parameters { param-altid, param-pid, param-pref,
+ param-type, param-mediatype }?,
+ value-uri
+ }
+
+# 6.9.2
+property-caladruri = element caladruri {
+ element parameters { param-altid, param-pid, param-pref,
+ param-type, param-mediatype }?,
+ value-uri
+ }
+
+# 6.9.3
+property-caluri = element caluri {
+ element parameters { param-altid, param-pid, param-pref,
+ param-type, param-mediatype }?,
+ value-uri
+ }
+
+
+
+
+
+
+
+
+Perreault Standards Track [Page 21]
+
+RFC 6351 xCard August 2011
+
+
+# Top-level grammar
+property = property-adr | property-anniversary | property-bday
+ | property-caladruri | property-caluri | property-categories
+ | property-clientpidmap | property-email | property-fburl
+ | property-fn | property-geo | property-impp | property-key
+ | property-kind | property-lang | property-logo
+ | property-member | property-n | property-nickname
+ | property-note | property-org | property-photo
+ | property-prodid | property-related | property-rev
+ | property-role | property-gender | property-sound
+ | property-source | property-tel | property-title
+ | property-tz | property-uid | property-url
+start = element vcards {
+ element vcard {
+ (property
+ | element group {
+ attribute name { text },
+ property*
+ })+
+ }+
+ }
+
+Author's Address
+
+ Simon Perreault
+ Viagenie
+ 2600 boul. Laurier, Suite 625
+ Quebec, QC G1V 4W1
+ Canada
+
+ Phone: +1 418 656 9254
+ EMail: simon.perreault@viagenie.ca
+ URI: http://www.viagenie.ca
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Perreault Standards Track [Page 22]
+