draft-ietf-vcarddav-vcardxml-11.txt   rfc6351.txt 
Network Working Group S. Perreault Internet Engineering Task Force (IETF) S. Perreault
Internet-Draft Viagenie Request for Comments: 6351 Viagenie
Intended status: Standards Track May 26, 2011 Category: Standards Track August 2011
Expires: November 27, 2011 ISSN: 2070-1721
xCard: vCard XML Representation xCard: vCard XML Representation
draft-ietf-vcarddav-vcardxml-11
Abstract Abstract
This document defines the XML schema of the vCard data format. This document defines the XML schema of the vCard data format.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on November 27, 2011. 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 Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. The Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. The Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 2
4. Example: Author's XML vCard . . . . . . . . . . . . . . . . . 3 4. Example: Author's XML vCard . . . . . . . . . . . . . . . . . 3
5. Design Considerations . . . . . . . . . . . . . . . . . . . . 5 5. Design Considerations . . . . . . . . . . . . . . . . . . . . 4
5.1. Extensibility . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Extensibility . . . . . . . . . . . . . . . . . . . . . . 6
5.2. Limitations . . . . . . . . . . . . . . . . . . . . . . . 8 5.2. Limitations . . . . . . . . . . . . . . . . . . . . . . . 7
6. Format Conversions . . . . . . . . . . . . . . . . . . . . . . 8 6. Format Conversions . . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8.1. Registration of the XML Namespace . . . . . . . . . . . . 10 8.1. Registration of the XML Namespace . . . . . . . . . . . . 11
8.2. Media Type . . . . . . . . . . . . . . . . . . . . . . . . 11 8.2. Media Type . . . . . . . . . . . . . . . . . . . . . . . . 11
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . . 13 10.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Relax NG Schema . . . . . . . . . . . . . . . . . . . 14 Appendix A. Relax NG Schema . . . . . . . . . . . . . . . . . . . 14
Appendix B. Change Log (to be removed by RFC Editor prior to
publication) . . . . . . . . . . . . . . . . . . . . 22
B.1. Changes in -11 . . . . . . . . . . . . . . . . . . . . . . 22
B.2. Changes in -10 . . . . . . . . . . . . . . . . . . . . . . 22
B.3. Changes in -09 . . . . . . . . . . . . . . . . . . . . . . 22
B.4. Changes in -08 . . . . . . . . . . . . . . . . . . . . . . 23
B.5. Changes in -07 . . . . . . . . . . . . . . . . . . . . . . 23
B.6. Changes in -06 . . . . . . . . . . . . . . . . . . . . . . 23
B.7. Changes in -05 . . . . . . . . . . . . . . . . . . . . . . 23
B.8. Changes in -04 . . . . . . . . . . . . . . . . . . . . . . 23
B.9. Changes in -03 . . . . . . . . . . . . . . . . . . . . . . 23
B.10. Changes in -02 . . . . . . . . . . . . . . . . . . . . . . 24
B.11. Changes in -01 . . . . . . . . . . . . . . . . . . . . . . 24
B.12. Changes in -00 . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
vCard [I-D.ietf-vcarddav-vcardrev] is a data format for representing vCard [RFC6350] is a data format for representing and exchanging
and exchanging information about individuals and other entities. It information about individuals and other entities. It is a text-based
is a text-based format (as opposed to a binary format). This format (as opposed to a binary format). This document defines xCard,
document defines xCard, an XML [W3C.REC-xml-20081126] representation an XML [W3C.REC-xml-20081126] representation for vCard. The
for vCard. The underlying data structure is exactly the same, underlying data structure is exactly the same, enabling a 1-to-1
enabling a 1-to-1 mapping between the original vCard format and the mapping between the original vCard format and the XML representation.
XML representation. The XML formatting may be preferred in some The XML formatting may be preferred in some contexts where an XML
contexts where an XML engine is readily available and may be reused engine is readily available and may be reused instead of writing a
instead of writing a stand-alone vCard parser. standalone vCard parser.
Earlier work on an XML format for vCard was started in 1998 by Frank Earlier work on an XML format for vCard was started in 1998 by Frank
Dawson [I-D.dawson-vcard-xml-dtd]. Sadly it did not take over the Dawson [VCARD-DTD]. Sadly, it did not take over the world.
world.
2. Conventions 2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. The Schema 3. The Schema
The schema is expressed in the RELAX NG language [ISO.19757-2.2008] The schema is expressed in the RELAX NG language [ISO.19757-2.2008]
skipping to change at page 5, line 27 skipping to change at page 4, line 48
<parameters><type><text>home</text></type></parameters> <parameters><type><text>home</text></type></parameters>
<uri>http://nomis80.org</uri> <uri>http://nomis80.org</uri>
</url> </url>
</vcard> </vcard>
</vcards> </vcards>
5. Design Considerations 5. Design Considerations
The general idea is to map vCard parameters, properties, and value The general idea is to map vCard parameters, properties, and value
types to XML elements. For example, the "FN" property is mapped to types to XML elements. For example, the "FN" property is mapped to
the "fn" element. That element in turn contains a text element whose the "fn" element. In turn, that element contains a text element
content corresponds to the vCard property's value. whose content corresponds to the vCard property's value.
vCard parameters are also mapped to XML elements. They are contained vCard parameters are also mapped to XML elements. They are contained
in the <parameters> element, which is contained in property elements. in the <parameters> element, which is contained in property elements.
For example, the "TYPE" parameter applied to the "TEL" property would For example, the "TYPE" parameter applied to the "TEL" property would
look like the following in XML: look like the following in XML:
<tel> <tel>
<parameters> <parameters>
<type> <type>
<text>voice</text> <text>voice</text>
<text>video</text> <text>video</text>
</type> </type>
</parameters> </parameters>
<uri>tel:+1-555-555-555</uri> <uri>tel:+1-555-555-555</uri>
</tel> </tel>
Parameters taking a list of values are simply repeated multiple Parameters taking a list of values are simply repeated multiple
times, once for each value in the list. times, once for each value in the list.
Properties having structured values (e.g. the "N" property) are Properties having structured values (e.g., the "N" property) are
expressed by XML element trees. Element names in that tree (e.g. expressed by XML element trees. Element names in that tree (e.g.,
"surname", "given", etc.) do not have a vCard equivalent since they "surname", "given", etc.) do not have a vCard equivalent since they
are identified by position in plain vCard. are identified by position in plain vCard.
Line folding is a non-issue in XML. Therefore, the mapping from Line folding is a non-issue in XML. Therefore, the mapping from
vCard to XML is done after the unfolding procedure is carried out. vCard to XML is done after the unfolding procedure is carried out.
Conversely, the mapping from XML to vCard is done before the folding Conversely, the mapping from XML to vCard is done before the folding
procedure is carried out. procedure is carried out.
A top-level <vcards> element is used as root. It contains one or A top-level <vcards> element is used as root. It contains one or
more <vcard> element, each representing a complete vCard. The more <vcard> elements, each representing a complete vCard. The
<vcards> element MUST be present even when only a single vCard is <vcards> element MUST be present even when only a single vCard is
present in an XML document. present in an XML document.
The group construct (Section 3.2 in [I-D.ietf-vcarddav-vcardrev]) is The group construct (Section 3.2 in [RFC6350]) is represented with
represented with the <group> element. The "name" attribute contains the <group> element. The "name" attribute contains the group's name.
the group's name. For example: For example:
<vcards> <vcards>
<vcard> <vcard>
<group name="contact"> <group name="contact">
<fn>...</fn> <fn>...</fn>
<email>...</email> <email>...</email>
</group> </group>
<group name="media"> <group name="media">
<photo>...</photo> <photo>...</photo>
</group> </group>
skipping to change at page 6, line 48 skipping to change at page 6, line 33
contact.EMAIL=... contact.EMAIL=...
media.PHOTO=... media.PHOTO=...
CATEGORIES=... CATEGORIES=...
END:VCARD END:VCARD
5.1. Extensibility 5.1. Extensibility
The original vCard format is extensible. New properties, parameters, The original vCard format is extensible. New properties, parameters,
data types and values (collectively known as vCard elements, not to data types and values (collectively known as vCard elements, not to
be confused with XML elements) can be registered with IANA (see be confused with XML elements) can be registered with IANA (see
[I-D.ietf-vcarddav-vcardrev] section 10.2). It is expected that [RFC6350], Section 10.2). It is expected that these vCard extensions
these vCard extensions will also specify extensions to the XML format will also specify extensions to the XML format described in this
described in this document. document.
New XML vCard property and parameter element names MUST be lower- New XML vCard property and parameter element names MUST be lower-
case. This is necessary to ensure that round-tripping between XML case. This is necessary to ensure that round-tripping between XML
and plain-text vCard works correctly. and plain-text vCard works correctly.
Unregistered extensions (i.e. those starting with "X-" and Unregistered extensions (i.e., those starting with "X-" and
"VND-...-") are expressed in XML by using elements starting with "x-" "VND-...-") are expressed in XML by using elements starting with "x-"
and "vnd-...-". Usage of XML namespaces [W3C.REC-xml-names-20091208] and "vnd-...-". Usage of XML namespaces [W3C.REC-xml-names-20091208]
for extensibility is RECOMMENDED for extensions that have no for extensibility is RECOMMENDED for extensions that have no
equivalent in plain text vCard. Refer to Section 6 for the equivalent in plain-text vCard. Refer to Section 6 for the
implications when converting between plain-text vCard and XML. implications when converting between plain-text vCard and XML.
Examples: Examples:
<x-my-prop> <x-my-prop>
<parameters> <parameters>
<pref><integer>1</integer></pref> <pref><integer>1</integer></pref>
</parameters> </parameters>
<text>value goes here</text> <text>value goes here</text>
<x-my-prop> </x-my-prop>
<ext:my-prop <ext:my-prop
ext:xmlns="http://example.com/extensions/my-vcard"> ext:xmlns="http://example.com/extensions/my-vcard">
<parameters> <parameters>
<pref><integer>1</integer></pref> <pref><integer>1</integer></pref>
</parameters> <!-- Core vCard elements --> </parameters> <!-- Core vCard elements -->
<text>value goes here</text> <!-- are still accessible --> <text>value goes here</text> <!-- are still accessible -->
</ext:my-prop> </ext:my-prop>
Note that extension elements do not need the "X- or "VND-" prefix in Note that extension elements do not need the "X-" or "VND-" prefix in
XML. The XML namespace mechanism is sufficient. XML. The XML namespace mechanism is sufficient.
A vCard XML parser MUST ignore XML elements and attributes for which A vCard XML parser MUST ignore XML elements and attributes for which
it doesn't recognize the expanded name. The normal behaviour of it doesn't recognize the expanded name. The normal behavior of
ignoring XML processing instructions whose target is not recognized ignoring XML processing instructions whose target is not recognized
MUST also be followed. MUST also be followed.
In the original vCard format, the "VERSION" property was mandatory In the original vCard format, the "VERSION" property was mandatory
and played a role in extensibility. In XML, this property is absent. and played a role in extensibility. In XML, this property is absent.
Its role is played by the vCard core namespace identifier, which Its role is played by the vCard core namespace identifier, which
includes the version number. vCard revisions will use a different includes the version number. vCard revisions will use a different
namespace. namespace.
Parameters containing a list of values are expressed using a list of Parameters containing a list of values are expressed using a list of
elements in XML (e.g. the <type> element). elements in XML (e.g., the <type> element).
5.2. Limitations 5.2. Limitations
The schema does not validate the cardinality of properties. This is The schema does not validate the cardinality of properties. This is
a limitation of the schema definition language. Cardinalities of the a limitation of the schema definition language. Cardinalities of the
original vCard format [I-D.ietf-vcarddav-vcardrev] MUST still be original vCard format [RFC6350] MUST still be respected.
respected.
Some constructs (e.g. value enumerations in type parameters) have Some constructs (e.g., value enumerations in type parameters) have
additional ordering constraints in XML. This is a result of additional ordering constraints in XML. This is a result of
limitations of the schema definition language and the order is limitations of the schema definition language, and the order is
arbitrary. The order MUST be respected in XML for the vCard to be arbitrary. The order MUST be respected in XML for the vCard to be
valid. However, reordering as part of conversion to or from plain valid. However, reordering as part of conversion to or from plain
vCard MAY happen. vCard MAY happen.
6. Format Conversions 6. Format Conversions
When new properties or "X-" proeprties used, a vCard<->xCard When new properties or "X-" properties are used, a vCard<->xCard
converter might not recognize them, and know what the appropriate converter might not recognize them or know what the appropriate
default value types are, yet they need to be able to preserve the default value types are, yet they need to be able to preserve the
values. A similar issue arises for unrecognized property parameters. values. A similar issue arises for unrecognized property parameters.
As a result, the following rules are applied when dealing with As a result, the following rules are applied when dealing with
unrecognized properties and property parameters: unrecognized properties and property parameters:
o When converting from vCard to xCard: o When converting from vCard to xCard:
* Any property that does not include a "VALUE" parameter and * Any property that does not include a "VALUE" parameter and
whose default value type is not known MUST be converted using whose default value type is not known MUST be converted using
the value type XML element <unknown>. The content of that the value type XML element <unknown>. The content of that
element is the unprocessed value text. element is the unprocessed value text.
* Any unrecognized property parameter MUST be converted using the * Any unrecognized property parameter MUST be converted using the
value type XML element <unknown>, with its content set to the value type XML element <unknown>, with its content set to the
parameter value text, treated as if it were a text value, or parameter value text, treated as if it were a text value, or
list of text values. list of text values.
* The content of "XML" properties is copied as-is to XML. * The content of "XML" properties is copied as is to XML.
* Property and parameter XML element names are converted to * Property and parameter XML element names are converted to
lower-case. lower-case.
* Property value escaping is undone. For example, "\n" becomes a * Property value escaping is undone. For example, "\n" becomes a
NEWLINE character (ASCII decimal 10). NEWLINE character (ASCII decimal 10).
* Double-quoting of parameter values, as well as backslash * Double-quoting of parameter values, as well as backslash
escaping in parameter values, is undone. For example, escaping in parameter values, is undone. For example,
PARAM="\"foo\",\"bar\"" becomes <param>"foo","bar"</param>. PARAM="\"foo\",\"bar\"" becomes <param>"foo","bar"</param>.
o When converting xCard to vCard: o When converting xCard to vCard:
* Properties in the vCard 4 namespace: * Properties in the vCard 4 namespace:
+ If the converter knows of a specific plain-text + If the converter knows of a specific plain-text
representation for this property, it uses it. For example, representation for this property, it uses it. For example,
the <adr> element corresponds to the "ADR" property, which the <adr> element corresponds to the "ADR" property, which
is encoded using comma-separated lists separated by semi- is encoded using comma-separated lists separated by
colons. semicolons.
+ Otherwise, the property name is taken from the element name, + Otherwise, the property name is taken from the element name,
property parameters are taken from the <parameters> element, property parameters are taken from the <parameters> element,
and the content of the property is taken from the content of and the content of the property is taken from the content of
the value element. If the property element has attributes the value element. If the property element has attributes
or contains other XML elements, they are dropped. or contains other XML elements, they are dropped.
+ If a standard property's XML element contains XML elements + If a standard property's XML element contains XML elements
and attributes for which the converter doesn't recognize the and attributes for which the converter doesn't recognize the
expanded name, they are dropped. Therefore, it is expanded name, they are dropped. Therefore, it is
RECOMMENDED to limit extensions to the property level to RECOMMENDED to limit extensions to the property level to
ensure that all data is preserved intact in round-trip ensure that all data is preserved intact in round-trip
conversions. conversions.
* Properties in other namespaces are wrapped as-is inside an * Properties in other namespaces are wrapped as is inside an
"XML" property. "XML" property.
* Any <unknown> property value XML elements are converted * Any <unknown> property value XML elements are converted
directly into vCard values. The containing property MUST NOT directly into vCard values. The containing property MUST NOT
have a "VALUE" parameter. have a "VALUE" parameter.
* Any <unknown> parameter value XML elements are converted as if * Any <unknown> parameter value XML elements are converted as if
they were <text> value type XML elements. they were <text> value type XML elements.
* Property and parameter names are converted to upper-case. * Property and parameter names are converted to upper-case.
* Property value escaping (Section 3.3 of * Property value escaping (Section 3.3 of [RFC6350]) is carried
[I-D.ietf-vcarddav-vcardrev]) is carried out. For example, a out. For example, a NEWLINE character (ASCII decimal 10)
NEWLINE character (ASCII decimal 10) becomes "\n". becomes "\n".
* Double-quoting of parameter values, as well as backslash * Double-quoting of parameter values, as well as backslash
escaping in parameter values, is carried out. For example, escaping in parameter values, is carried out. For example,
<param>"foo","bar"</param> becomes PARAM="\"foo\",\"bar\"". <param>"foo","bar"</param> becomes PARAM="\"foo\",\"bar\"".
For example, these two vCards are equivalent: For example, these two vCards are equivalent:
<?xml version="1.0"?> <?xml version="1.0"?>
<vcards xmlns="urn:ietf:params:xml:ns:vcard-4.0"> <vcards xmlns="urn:ietf:params:xml:ns:vcard-4.0">
<vcard> <vcard>
skipping to change at page 10, line 38 skipping to change at page 10, line 40
VERSION:4.0 VERSION:4.0
FN:J. Doe FN:J. Doe
N:Doe;J.;; N:Doe;J.;;
X-FILE;MEDIATYPE=image/jpeg:alien.jpg X-FILE;MEDIATYPE=image/jpeg:alien.jpg
XML:<a xmlns="http://www.w3.org/1999/xhtml"\n XML:<a xmlns="http://www.w3.org/1999/xhtml"\n
href="http://www.example.com">My web page!</a> href="http://www.example.com">My web page!</a>
END:VCARD END:VCARD
7. Security Considerations 7. Security Considerations
All the security considerations applicable to plain vCard All the security considerations applicable to plain vCard [RFC6350]
[I-D.ietf-vcarddav-vcardrev] are applicable to this document as well. are applicable to this document as well.
XML Signature [W3C.CR-xmldsig-core1-20110303] and XML Encryption XML Signature [W3C.CR-xmldsig-core1-20110303] and XML Encryption
[W3C.CR-xmlenc-core1-20110303] can be used with xCard to provide [W3C.CR-xmlenc-core1-20110303] can be used with xCard to provide
authentication and confidentiality. authentication and confidentiality.
8. IANA Considerations 8. IANA Considerations
8.1. Registration of the XML Namespace 8.1. Registration of the XML Namespace
URI: urn:ietf:params:xml:ns:vcard-4.0 URI: urn:ietf:params:xml:ns:vcard-4.0
Registrant Contact: Simon Perreault <simon.perreault@viagenie.ca> Registrant Contact: The IESG <iesg@ietf.org>
XML: None. Namespace URIs do not represent an XML specification. XML: None. Namespace URIs do not represent an XML specification.
8.2. Media Type 8.2. Media Type
This section defines the MIME media type [RFC4288] for use with This section defines the MIME media type [RFC4288] for use with
vCard-in-XML data. vCard-in-XML data.
To: ietf-types@iana.org To: ietf-types@iana.org
Subject: Registration of media type application/vcard+xml Subject: Registration of media type application/vcard+xml
Type name: application Type name: application
Subtype name: vcard+xml Subtype name: vcard+xml
Required parameters: none Required parameters: none
Optional parameters: charset as defined for application/xml in Optional parameters: charset as defined for application/xml in
[RFC3023]; per [RFC3023], use of the charset parameter with the [RFC3023]; per [RFC3023], use of the charset parameter with the
value "utf-8" is "STRONGLY RECOMMENDED" value "utf-8" is "STRONGLY RECOMMENDED".
Encoding considerations: Same as encoding considerations of Encoding considerations: Same as encoding considerations of
application/xml as specified in [RFC3023] application/xml as specified in [RFC3023].
Security considerations: This media type has all of the security Security considerations: This media type has all of the security
considerations described in [RFC3023], plus those listed in considerations described in [RFC3023], plus those listed in
Section 7. Section 7.
Interoperability considerations: This media type provides an Interoperability considerations: This media type provides an
alternative syntax to vCard data [I-D.ietf-vcarddav-vcardrev] alternative syntax to vCard data [RFC6350] based on XML.
based on XML.
Published specification: This specification. Published specification: This specification.
Applications which use this media type: Applications that currently Applications that use this media type: Applications that currently
make use of the text/vcard media type can use this as an make use of the text/vcard media type can use this as an
alternative. In general, applications that maintain or process alternative. In general, applications that maintain or process
contact information can use this media type. contact information can use this media type.
Additional information: Additional information:
Magic number(s): none Magic number(s): none
File extension(s): XML data should use ".xml" as the file File extension(s): XML data should use ".xml" as the file
extension. extension.
skipping to change at page 12, line 23 skipping to change at page 12, line 25
Perreault <simon.perreault@viagenie.ca> Perreault <simon.perreault@viagenie.ca>
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: none Restrictions on usage: none
Author: Simon Perreault Author: Simon Perreault
Change controller: IETF Change controller: IETF
9. Acknowledgements 9. Acknowledgments
Thanks to the following people for their input: Thanks to the following people for their input:
Alexey Melnikov, Barry Leiba, Bjorn Hoehrmann, Cyrus Daboo, Joe Alexey Melnikov, Barry Leiba, Bjorn Hoehrmann, Cyrus Daboo, Joe
Hildebrand, Joseph Smarr, Marc Blanchet, Mike Douglas, Peter Saint- Hildebrand, Joseph Smarr, Marc Blanchet, Mike Douglass, Peter Saint-
Andre, Robins George, Zahhar Kirillov, Zoltan Ordogh. Andre, Robins George, Zahhar Kirillov, Zoltan Ordogh.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-vcarddav-vcardrev] Perreault, S., "vCard Format [ISO.19757-2.2008]
Specification", International Organization for Standardization,
draft-ietf-vcarddav-vcardrev-20 "Information technology -- Document Schema Definition
(work in progress), May 2011. Language (DSDL) -- Part 2: Regular-grammar-based
validation -- RELAX NG", ISO International
Standard 19757-2, October 2008.
[ISO.19757-2.2008] International Organization for [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Standardization, "Information Requirement Levels", BCP 14, RFC 2119, March 1997.
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 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
RFCs to Indicate Requirement Types", RFC 3023, January 2001.
Levels", BCP 14, RFC 2119,
March 1997.
[RFC3023] Murata, M., St. Laurent, S., and D. [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350,
Kohn, "XML Media Types", RFC 3023, August 2011.
January 2001.
[W3C.REC-xml-20081126] Yergeau, F., Maler, E., Paoli, J., [W3C.REC-xml-20081126]
Sperberg-McQueen, C., and T. Bray, Paoli, J., Yergeau, F., Maler, E., Bray, T., and C.
"Extensible Markup Language (XML) Sperberg-McQueen, "Extensible Markup Language (XML) 1.0
1.0 (Fifth Edition)", World Wide Web (Fifth Edition)", World Wide Web Consortium
Consortium Recommendation REC-xml- Recommendation REC-xml-20081126, November 2008,
20081126, November 2008, <http:// <http://www.w3.org/TR/2008/REC-xml-20081126>.
www.w3.org/TR/2008/
REC-xml-20081126>.
[W3C.REC-xml-names-20091208] Tobin, R., Hollander, D., Thompson, [W3C.REC-xml-names-20091208]
H., Bray, T., and A. Layman, Bray, T., Hollander, D., Layman, A., Tobin, R., and H.
"Namespaces in XML 1.0 (Third Thompson, "Namespaces in XML 1.0 (Third Edition)", World
Edition)", World Wide Web Consortium Wide Web Consortium Recommendation REC-xml-names-20091208,
Recommendation REC-xml-names- December 2009,
20091208, December 2009, <http:// <http://www.w3.org/TR/2009/REC-xml-names-20091208>.
www.w3.org/TR/2009/
REC-xml-names-20091208>.
10.2. Informative References 10.2. Informative References
[I-D.dawson-vcard-xml-dtd] Dawson, F., "The vCard v3.0 XML [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
DTD", draft-dawson-vcard-xml-dtd-03 Registration Procedures", BCP 13, RFC 4288, December 2005.
(work in progress), June 1998.
[RFC4288] Freed, N. and J. Klensin, "Media [VCARD-DTD]
Type Specifications and Registration Dawson, F., "The vCard v3.0 XML DTD", Work in Progress,
Procedures", BCP 13, RFC 4288, June 1998.
December 2005.
[W3C.CR-xmldsig-core1-20110303] Reagle, J., Roessler, T., Solo, D., [W3C.CR-xmldsig-core1-20110303]
Yiu, K., Eastlake, D., Nystroem, M., Roessler, T., Solo, D., Yiu, K., Reagle, J., Hirsch, F.,
and F. Hirsch, "XML Signature Syntax Eastlake, D., and M. Nystroem, "XML Signature Syntax and
and Processing Version 1.1", World Processing Version 1.1", World Wide Web Consortium CR CR-
Wide Web Consortium CR CR-xmldsig- xmldsig-core1-20110303, March 2011,
core1-20110303, March 2011, <http:// <http://www.w3.org/TR/2011/CR-xmldsig-core1-20110303>.
www.w3.org/TR/2011/
CR-xmldsig-core1-20110303>.
[W3C.CR-xmlenc-core1-20110303] Eastlake, D., Reagle, J., Hirsch, [W3C.CR-xmlenc-core1-20110303]
F., and T. Roessler, "XML Encryption Eastlake, D., Reagle, J., Roessler, T., and F. Hirsch,
Syntax and Processing Version 1.1", "XML Encryption Syntax and Processing Version 1.1", World
World Wide Web Consortium CR CR- Wide Web Consortium CR CR-xmlenc-core1-20110303,
xmlenc-core1-20110303, March 2011, < March 2011,
http://www.w3.org/TR/2011/ <http://www.w3.org/TR/2011/CR-xmlenc-core1-20110303>.
CR-xmlenc-core1-20110303>.
Appendix A. Relax NG Schema Appendix A. Relax NG Schema
default namespace = "urn:ietf:params:xml:ns:vcard-4.0" default namespace = "urn:ietf:params:xml:ns:vcard-4.0"
### Section 3.3: vCard Format Specification ### Section 3.3: vCard Format Specification
# #
# 3.3 # 3.3
iana-token = xsd:string { pattern = "[a-zA-Z0-9-]+" } iana-token = xsd:string { pattern = "[a-zA-Z0-9-]+" }
x-name = xsd:string { pattern = "x-[a-zA-Z0-9-]+" } x-name = xsd:string { pattern = "x-[a-zA-Z0-9-]+" }
skipping to change at page 22, line 5 skipping to change at page 22, line 27
start = element vcards { start = element vcards {
element vcard { element vcard {
(property (property
| element group { | element group {
attribute name { text }, attribute name { text },
property* property*
})+ })+
}+ }+
} }
Appendix B. Change Log (to be removed by RFC Editor prior to
publication)
B.1. Changes in -11
o Refer to ISO standard for Relax NG.
o Adjust text on vCard extensibility through IANA.
o Add missing case conversion rules.
o Refer to XML Signature and XML Encryption in security
considerations section.
B.2. Changes in -10
o Fixed bugs in examples.
o New XML elements MUST be lower-case.
o Adjusted case conversion rules for unknown parameters.
o Added utc-offset as possible value type to tz property.
o Added "agent" and "emergency" related values.
o Added x-name and iana-token in kind values.
o Added cross-references to vcardrev sections.
o Add <unknown> element for round-tripping.
o Tweak sex grammar.
o "Structured" properties don't need <text> elements.
o Fixed wrong example.
B.3. Changes in -09
o Added "Conventions" section with reference to RFC2119.
o Fixed bad XML in example.
o Updated MIME type registration following feedback from
ietf-types@iana.org.
B.4. Changes in -08
o Synchronized with draft-ietf-vcarddav-vcardrev-17.
o Added some references.
o Fixed bad XML in example.
o Added <text> element around pid param value.
B.5. Changes in -07
o Synchronized with draft-ietf-vcarddav-vcardrev-16.
o Fixed bad XML in example.
o Fixed <categories> which now takes a value-text-list.
o All parameters now use value elements. This affects type,
calscale, and pref.
B.6. Changes in -06
o Synchronized with draft-ietf-vcarddav-vcardrev-15.
B.7. Changes in -05
o Synchronized with draft-ietf-vcarddav-vcardrev-13.
B.8. Changes in -04
o Synchronized with draft-ietf-vcarddav-vcardrev-12.
o Added application/vcard+xml media type.
o Added rules for backslash escaping and quoting when converting.
o Added description of <vcards> element.
o Described group construct in XML.
B.9. Changes in -03
o Created "Format Conversions" section.
o Turned more <type> parameter values into plain text.
o Removed need for empty value elements in components.
o Wrapped value of <sex>, <class>, and <kind> in value elements.
B.10. Changes in -02
o Synchronized with draft-ietf-vcarddav-vcardrev-10.
o Turned <type> parameter values into plain text.
o Moved the "XML" property to vCard base.
o Changed title to avoid confusion with XML Schema.
o Added prefixes "value-", "param-", and "property-" in schema.
o Better language for specifying what a parser must ignore.
B.11. Changes in -01
o Synchronized with draft-ietf-vcarddav-vcardrev-09.
o Added the <vcards> element to allow multiple vCards in a single
XML file.
o Created the <parameters> container element.
o Use text value for enumeration in <class> element.
o Created the "XML" vCard property.
o Added IANA considerations section.
o Added security considerations section.
B.12. Changes in -00
o Same as draft-perreault-vcarddav-vcardxml-02.
Author's Address Author's Address
Simon Perreault Simon Perreault
Viagenie Viagenie
2600 boul. Laurier, suite 625 2600 boul. Laurier, Suite 625
Quebec, QC G1V 4W1 Quebec, QC G1V 4W1
Canada Canada
Phone: +1 418 656 9254 Phone: +1 418 656 9254
EMail: simon.perreault@viagenie.ca EMail: simon.perreault@viagenie.ca
URI: http://www.viagenie.ca URI: http://www.viagenie.ca
 End of changes. 53 change blocks. 
280 lines changed or deleted 112 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/