idnits 2.17.1
draft-dawson-vcard-xml-dtd-03.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** Looks like you're using RFC 2026 boilerplate. This must be updated to
follow RFC 3978/3979, as updated by RFC 4748.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
** Missing expiration date. The document expiration date should appear on
the first and last page.
** The document seems to lack a 1id_guidelines paragraph about 6 months
document validity -- however, there's a paragraph with a matching
beginning. Boilerplate error?
** The document seems to lack a 1id_guidelines paragraph about the list of
current Internet-Drafts.
** The document seems to lack a 1id_guidelines paragraph about the list of
Shadow Directories.
== No 'Intended status' indicated for this document; assuming Proposed
Standard
== The page length should not exceed 58 lines per page, but there was 1
longer page, the longest (page 1) being 1726 lines
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 abstract seems to contain references ([RFC2426], [RFC2119], [XML]),
which it shouldn't. Please replace those with straight textual mentions
of the documents in question.
** 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 -- however, there's a paragraph with a matching beginning.
Boilerplate error?
RFC 2119 keyword, line 141: '... namespaces MUST NOT include other n...'
RFC 2119 keyword, line 177: '... This FPI MUST be used on the DOCTYP...'
RFC 2119 keyword, line 180: '... This FPI SHOULD also be used to ide...'
RFC 2119 keyword, line 212: '...is specification MUST be able to prope...'
RFC 2119 keyword, line 288: '...ding NOTATION declaration MUST also be...'
(12 more instances...)
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
match the current year
-- 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 (June 22, 1998) is 9438 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
-- Missing reference section? 'XML' on line 1322 looks like a reference
-- Missing reference section? 'RFC2426' on line 1319 looks like a reference
-- Missing reference section? 'RFC 2119' on line 1315 looks like a reference
-- Missing reference section? 'RFC 2045' on line 1311 looks like a reference
-- Missing reference section? 'XMLNS' on line 1325 looks like a reference
-- Missing reference section? 'RFC2045' on line 307 looks like a reference
-- Missing reference section? 'FPI' on line 1300 looks like a reference
-- Missing reference section? 'ISO9070' on line 1306 looks like a reference
Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 10 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
1 Network Working Group Frank Dawson, Lotus
2 Internet Draft
3 draft-dawson-vcard-xml-dtd-03.txt
4 Expires six months after: June 22, 1998
6 The vCard v3.0 XML DTD
8 Status of this Memo
10 This document is an Internet-Draft and is in full conformance with
11 all provisions of Section 10 of RFC2026.
13 Internet-Drafts are working documents of the Internet Engineering
14 Task Force (IETF), its areas, and its working groups. Note that other
15 groups may also distribute working documents as Internet-Drafts.
16 Internet-Drafts are draft documents valid for a maximum of six months
17 and may be updated, replaced, or obsoleted by other documents at any
18 time. It is inappropriate to use Internet- Drafts as reference
19 material or to cite them other than as "work in progress." The list
20 of current Internet-Drafts can be accessed at
21 http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft
22 Shadow Directories can be accessed at
23 http://www.ietf.org/shadow.html.
25 Distribution of this document is unlimited.
27 Copyright (C) The Internet Society 1999. All Rights Reserved.
29 Abstract
31 This memo defines a [XML] Document Type Definition (DTD) that
32 corresponds to the vCard, electronic business card format defined by
33 [RFC2426]. This DTD provides equivalent functionality to the standard
34 format defined by [RFC2426]. Documents structured in accordance with
35 this DTD may also be known as "XML vCard" documents.
37 The mailing list for discussion of this memo is "ietf-vcard-
38 xml@imc.org". Send an email to " ietf-vcard-xml-request@imc.org" with
39 the message "SUBSCRIBE" to add your email address to this mailing
40 list. Send an email to " ietf-vcard-xml-request@imc.org" with the
41 message "UNSUBSCRIBE" to remove your email address from this mailing
42 list.
44 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
45 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this
46 document are to be interpreted as described in [RFC 2119].
48 Dawson 1 Expires December 1999
49 Table of Contents
51 1. INTRODUCTION........................................................4
53 2. USING XML FOR REPRESENTING VCARD....................................5
55 2.1 XML DEPENDENCIES .................................................5
56 2.2 DOCUMENT TYPE DEFINITION .........................................5
57 2.3 WORKING WITH STANDARD AND XML VCARD REPRESENTATIONS ..............5
58 2.3.1 Conversion ....................................................5
59 2.3.2 Mixed Use of Both Representations .............................5
60 2.4 USING DATA TYPES .................................................6
61 2.5 INCLUDING BINARY CONTENT .........................................7
62 2.6 INCLUDING MULTIPLE VCARD OBJECTS .................................8
63 2.7 MAPPING VCARD TYPE PARAMETERS TO XML .............................8
64 2.8 MAPPING VCARD TYPES TO XML ......................................10
65 2.9 PARAMETER ENTITIES ..............................................12
66 2.10 NAMESPACE ......................................................12
67 2.11 EMAILING THE VCARD XML REPRESENTATION ..........................13
68 2.12 VCARD XML REPRESENTATION AND FILE SYSTEMS ......................13
70 3. VCARD XML DOCUMENT TYPE DEFINITION.................................13
72 4. VCARD V3.0 NOTATION................................................20
74 5. EXAMPLE USAGE......................................................21
76 5.1 SIMPLE VCARD ....................................................21
77 5.2 VCARD WITH NON-STANDARD EXTENSION ...............................21
78 5.3 VCARD WITH PHOTO ELEMENT ........................................22
79 5.4 VCARD WITH AN AGENT ELEMENT .....................................22
80 5.5 DOCUMENT WITH MULTIPLE VCARDS ...................................23
81 5.6 DOCUMENT UTILIZING VCARD NAMESPACE ..............................23
82 5.7 XML DOCUMENT REFERENCE TO A NON-XML VCARD .......................24
84 6. NAMESPACE..........................................................24
86 7. MAJOR CONTRIBUTORS.................................................25
88 8. ACKNOWLEDGMENTS....................................................25
90 9. SECURITY CONSIDERATIONS............................................25
92 10. BIBLIOGRAPHY......................................................25
94 Dawson 2 Expires December 1999
95 11. AUTHOR'S ADDRESS..................................................26
97 12. FULL COPYRIGHT STATEMENT..........................................26
99 Dawson 3 Expires December 1999
100 1. Introduction
102 The Extended Markup Language (XML) as defined in [XML] is gaining
103 widespread attention as a "web friendly" syntax for representing and
104 exchanging documents and data on the Internet. This interest includes
105 requests for and discussion of possible document type definitions
106 (DTD) for IETF standards such at the vCard, electronic business card
107 format defined by [RFC2426].
109 The XML DTD in this memo is in no way intended to create a separate
110 definition for the vCard schema. The sole purpose for this memo is to
111 define an alternative XML representation for the format defined by
112 [RFC2426]. The vCard DTD does not introduce any capability not
113 expressible in the format defined by [RFC2426].
115 An attempt has been made to leverage the standard features of the XMl
116 syntax in order to represent the vCard semantics. For example, strong
117 data typing is specified using the XML notation declaration. It is
118 the responsibility of the XML application supporting this DTD to make
119 sure that the content information is formatted consistently with the
120 notation declared for each element.
122 The vCard DTD promotes a number of vCard properties into attributes
123 on the "vCard" element. This has been done to express these
124 properties as "global attributes" for the vCard object, as a whole.
125 For example, the VERSION, REV, PRODID, UID, CLASS properties have
126 been "mapped" into attributes on the vCard object.
128 Binary content in the PHOTO, LOGO, SOUND and KEY properties may
129 either be specified through an external entity reference to the non-
130 XML image or sound content or may be included in the content after
131 first encoding the binary information using the BASE64 encoding of
132 [RFC 2045].
134 The publication of [XML] was followed by the publication of a World-
135 Wide-Web Consortium (W3C) recommendation on "Namespaces in XML". A
136 XML namespace is a collection of names, identified by a URI. In
137 anticipation of the broader use of XML namespaces, this memo includes
138 the definition of the URI to be used to identify the namespace
139 associated with the vCard DTD element types in other XML documents.
140 XML applications that conform to this memo and also make use of
141 namespaces MUST NOT include other non-vCard namespaces in a vCard XML
142 document.
144 It is expected that the DTD defined in this memo will not normally be
145 included with vCard XML documents that are distributed. Instead, the
146 DTD will be referenced in the document type declaration in the
147 document entity. Such vCard XML documents will be well-formed and
148 valid, as defined in [XML]. In addition, other vCard XML documents
149 will be specified that do not include the XML prolog. Such vCard XML
150 documents will be well-formed but not valid.
152 Dawson 4 Expires December 1999
153 2. Using XML for Representing vCard
155 XML is a simplified version of the text markup syntax defined by ISO
156 8879, Standard Generalized Markup Language (SGML). XML was published
157 as a recommendation [XML] by the W3C on February 10, 1998.
159 2.1 XML Dependencies
161 This memo specifies the XML representation for the standard vCard
162 format defined by [RFC2426]. There are no XML dependencies other than
163 the [XML] and the [XMLNS] recommendations.
165 2.2 Document Type Definition
167 A XML DTD for vCard is defined by the DTD specified in section 3.
169 The formal public identifier (FPI) for the DTD is:
171 "-//IETF/DTD VCARDXML/vCard XML//EN"
173 NOTE: The "VCARDXML" text in the FPI value will be replaced with
174 the text "RFC xxxx", where "xxxx" is the RFC number, when the
175 memo is published as a RFC.
177 This FPI MUST be used on the DOCTYPE statement within a XML document
178 referencing the DTD defined by this memo.
180 This FPI SHOULD also be used to identify vCard XML documents within
181 operating system registries of file, clipboard and interactive
182 rendering (e.g., memory clipboard or drag/drop) formats.
184 2.3 Working With Standard and XML vCard Representations
186 This memo defines an alternative, XML representation for the standard
187 vCard format defined in [RFC2426]. This alternative representation
188 provides the same semantics as that defined in the standard format.
190 2.3.1 Conversion
192 The standard format can be converted to and from this XML format
193 without loss of any vCard information. When the XML representation
194 was defined, every attempt was made to use existing vCard type and
195 naming conventions for type parameters. This greatly facilitates
196 transformations between the two representations of the vCard.
198 2.3.2 Mixed Use of Both Representations
200 As previously indicated, conversion between the standard and XML
201 representations of vCard is a straightforward process. In addition,
202 mixed use of both representations is also possible.
204 With the use of the MIME multipart content-types, such as
205 multipart/alternative, compound MIME entities containing a mix of the
206 standard and XML representations can be specified. This capability is
208 Dawson 5 Expires December 1999
209 useful in applications where both representations might be
210 encountered. In addition, this capability demonstrates the isomeric
211 nature of the two representations. XML applications conforming to
212 this specification MUST be able to properly parse and process a MIME
213 multipart entity containing the MIME content-type associated with
214 this vCard XML document type.
216 2.4 Using Data Types
218 Strong "data typing" is an integral design principle in the vCard
219 format. Strong data typing in vCard means that the format type for
220 each vCard type value is well known. Within [RFC2426], the data type
221 is called the "value type". The standard format defined by [RFC2426]
222 specifies a default value type for each vCard type. In addition, many
223 of the vCard types allow for the specification of alternate value
224 types. This XML representation continues this design principle.
226 Explicit value typing in the XML representation is specified with the
227 "value" attribute on each element type. In addition, the XML DTD
228 specifies a default value type for each element type. XML documents
229 conforming to this memo need only specify the "value" attribute on
230 element types when the default value type is overridden. The standard
231 value types defined in [RFC2426] are specified in the XML DTD by
232 individual notation declarations. The formal public identifier for
233 standard value types all have the common string format of:
235 -//IETF/NOTATION VCARDXML/VALUE TYPE/xxx//EN
237 NOTE: The "VCARDXML" text in the FPI value will be replaced with
238 the text "RFC xxxx", where "xxxx" is the RFC number, when the
239 memo is published as a RFC.
241 Where "xxx" is replaced with the text specified in the table below.
243 The following table specifies the XML value type that corresponds to
244 each of the standard value types defined in [RFC2426].
246 +--------------+--------------+-------------------------+
247 | RFC 2426 | XML Value | Notation FPI Text |
248 | Value Type | Type | |
249 +--------------+--------------+-------------------------+
250 | BINARY | BINARY | Binary |
251 | BOOLEAN | BOOLEAN | Boolean |
252 | DATE | DATE | Date |
253 | DATE-TIME | DATE-TIME | Date-Time |
254 | FLOAT | FLOAT | Float |
255 | INTEGER | INTEGER | Integer |
256 | PHONE-NUMBER | PHONE-NUMBER | Phone-Number |
257 | TEXT | TEXT | Text |
258 | TIME | TIME | Time |
259 | URI | URI | URI |
260 | UTC-OFFSET | UTC-OFFSET | UTC-Offset |
261 | VCARD | VCARD | vCard |
262 | Non-standard | X-NAME | X-Name |
264 Dawson 6 Expires December 1999
265 +--------------+--------------+-------------------------+
267 2.5 Including Binary Content
269 Binary content can be included in a standard format of vCard with the
270 "PHOTO", "LOGO", or "SOUND" type. In the standard vCard format this
271 content may either be specified through an external entity reference,
272 using a URI value type, or maybe specified within the vCard object,
273 after first BASE64 encoding the content.
275 The XML representation for vCard also supports including binary
276 content in a vCard with the "photo", "logo" and "sound" types. It
277 also supports either an external reference to the non-XML binary
278 content or inclusion of the binary content after first encoding the
279 binary information using the BASE64 encoding of [RFC2045].
281 Any vCard type defined in [RFC2426] that can be used to include
282 binary content are defined in the XML DTD as an element type with a
283 content model that consists of either the "extref" or the "b64bin"
284 element type. The "extref" element type is used to reference an
285 external entity containing the binary content. An external reference
286 to the binary content is specified by the "uri" attribute on the
287 "extref" element type. For every external reference, an ENTITY
288 declaration and a corresponding NOTATION declaration MUST also be
289 specified in an internal DTD to identify the location and format of
290 the external entity. For example, the following XML snippets would be
291 needed to include a reference to the executable "foo.jpg" in the
292 "photo" element type:
294
296
298
301
303
305 The "b64bin" element type is used to include the binary content
306 within the XML document after first character encoding the binary
307 information using the BASE64 encoding method of [RFC2045]. For
308 example, the following XML snippets would be needed to include the
309 executable "foo.jpg" in the "photo" element type; after first BASE64
310 encoding the binary information:
312
314 MIICajCC
315 AdOgAwIBAgICBEUwDQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05l
316 dHNjYXBlIENvbW11bmljYXRpb25z...and so on...IENvcnBvc==
317
319 Dawson 7 Expires December 1999
320 2.6 Including Multiple vCard Objects
322 The vCard standard format has the capability for including multiple,
323 individual vCards in a single data stream. The XML representation
324 also supports this feature. Individual vCards are specified by the
325 "vCard" element type. One or more "vCard" element types are permitted
326 within the parent element type, called "vCardSet". For example:
328
329
330
332
333
334
336 2.7 Mapping vCard Type Parameters to XML
338 The type parameters defined in the standard vCard format are
339 represented in the XML representation as attributes on element types.
340 The following table specifies the attribute name corresponding to
341 each type parameter.
343 +----------------+------------+-----------+-----------------+
344 | Type | Attribute | Attribute | Default |
345 | Parameter Name | Name | Type | Value |
346 +----------------+------------+-----------+-----------------+
347 | ENCODING | Not Used | n/a | n/a |
348 | LANGUAGE | lang | CDATA | IMPLIED |
349 | TYPE for ADR | del.type | NMTOKENS | 'INTL POSTAL |
350 | and LABEL | | | PARCEL WORK' |
351 | TYPE for TEL | tel.type | NMTOKENS | 'VOICE' |
352 | TYPE for EMAIL | email.type | NMTOKENS | 'INTERNET' |
353 | TYPE for PHOTO,| img.type | CDATA | REQUIRED |
354 | and LOGO | | | |
355 | TYPE for SOUND | aud.type | CDATA | REQUIRED |
356 | VALUE | value | NOTATION | See elements |
357 +----------------+------------+-----------+-----------------+
359 The "VERSION", "REV", "PRODID", "UID" and "CLASS" vCard types have
360 been mapped into the attributes as specified by the following table.
362 +----------------+------------+------------+----------------+
363 | Type | Attribute | Attribute | Default |
364 | Name | Name | Type | Value |
365 +----------------+------------+------------+----------------+
366 | CLASS | class | enumerated | 'PUBLIC' |
367 | PRODID | prodid | CDATA | IMPLIED |
368 | REV | rev | CDATA | IMPLIED |
369 | UID | uid | CDATA | IMPLIED |
370 | VERSION | version | CDATA | IMPLIED |
371 +----------------+------------+------------+----------------+
373 Dawson 8 Expires December 1999
374 The inline "ENCODING" property parameter is not needed in the XML
375 representation. Inline binary information is always included as
376 parsable character data, after first being encoded using the BASE64
377 encoding of [RFC 2045].
379 A non-standard, experimental parameter can be added to the XML
380 representation by declaring it in an attribute list declaration and
381 assigning it a XML attribute type and corresponding default value.
383 In addition to these attributes, the "vCard" element type can also
384 have the following attributes:
386 +-----------+-----------+---------+----------------------------+
387 | Attribute | Attribute | Default | Description |
388 | Name | Type | Value | |
389 +-----------+-----------+---------+----------------------------+
390 | xmlns | CDATA | FIXED | Used to specify the default|
391 | | | | vCard XML name space. |
392 | xmlns: + | CDATA | FIXED | Used to specify the |
393 | | | | prefix is used to specify |
395 | | | | a namespace. |
396 +-----------+-----------+---------+----------------------------+
398 The semantics of the"xmlns" attribute, and any attribute with
399 "xmlns:" as a prefix, is as specified in [XMLNS]. It is used to
400 declare a namespace in XML. It can be used to declare the vCard XML
401 namespace in a XML document with a document type other than the vCard
402 XML document type. The vCard XML document type MUST only use element
403 types from the vCard namespace.
405 To specify the vCard namespace, the attribute value for the "xmlns"
406 and any attribute with the prefix "xmlns:" MUST be:
408 'http://www.ietf.org/internet-drafts/draft-dawson-vCard-xml-dtd-
409 04.txt'
411 NOTE: This attribute value will be replaced with the URL
412 "http://www.ietf.org/rfc/rfcxxxx.txt", where "xxxx" is the RFC
413 number, when this memo is published as a RFC.
415 For example:
417
419
423
425 Dawson 9 Expires December 1999
426 2.8 Mapping vCard Types to XML
428 The following tables provide mappings of the vCard types to their
429 corresponding XML element types along with their respective content
430 models.
432 Identification Types
433 +----------------+------------+-----------------------------+
434 | vCard | Element | Element Content Model |
435 | Type Name | Name | |
436 +----------------+------------+-----------------------------+
437 | FN | fn | PCDATA |
438 | N | n | family*,given*,other*, |
439 | | | prefix*, suffix* |
440 | | family | PCDATA |
441 | | given | PCDATA |
442 | | other | PCDATA |
443 | | prefix | PCDATA |
444 | | suffix | PCDATA |
445 | NICKNAME | nickname | PCDATA |
446 | PHOTO | photo | extref or b64bin |
447 | | extref | EMPTY |
448 | | b64bin | PCDATA |
449 | BDAY | bday | PCDATA |
450 +----------------+------------+-----------------------------+
452 Delivery Addressing Types
453 +----------------+------------+-----------------------------+
454 | vCard | Element | Element Content Model |
455 | Type Name | Name | |
456 +----------------+------------+-----------------------------+
457 | ADR | adr | pobox*,extadd*,street*, |
458 | | | locality*,region*,pcode*, |
459 | | | country* |
460 | | pobox | PCDATA |
461 | | extadd | PCDATA |
462 | | street | PCDATA |
463 | | locality | PCDATA |
464 | | region | PCDATA |
465 | | pcode | PCDATA |
466 | | country | PCDATA |
467 | LABEL | LABEL | PCDATA |
468 +----------------+------------+-----------------------------+
470 Telecommunications Addressing Types
471 +----------------+------------+-----------------------------+
472 | vCard | Element | Element Content Model |
473 | Type Name | Name | |
474 +----------------+------------+-----------------------------+
475 | TEL | tel | PCDATA |
476 | EMAIL | email | PCDATA |
477 | MAILER | mailer | PCDATA |
478 +----------------+------------+-----------------------------+
480 Dawson 10 Expires December 1999
481 Geographical Types
482 +----------------+------------+-----------------------------+
483 | vCard | Element | Element Content Model |
484 | Type Name | Name | |
485 +----------------+------------+-----------------------------+
486 | TZ | tz | PCDATA |
487 | GEO | geo | lat,lon |
488 | | lat | PCDATA |
489 | | lon | PCDATA |
490 +----------------+------------+-----------------------------+
492 Organizational Types
493 +----------------+------------+-----------------------------+
494 | vCard | Element | Element Content Model |
495 | Type Name | Name | |
496 +----------------+------------+-----------------------------+
497 | TITLE | title | PCDATA |
498 | ROLE | role | PCDATA |
499 | LOGO | logo | extref or b64bin |
500 | | extref | EMPTY |
501 | | b64bin | PCDATA |
502 | AGENT | agent | vCard | extref |
503 | ORG | org | orgnam,orgunit* |
504 | | orgnam | PCDATA |
505 | | orgunit | PCDATA
506 +----------------+------------+-----------------------------+
508 Explanatory Types
509 +----------------+------------+-----------------------------+
510 | vCard | Element | Element Content Model |
511 | Type Name | Name | |
512 +----------------+------------+-----------------------------+
513 | CATEGORIES | categories | item* |
514 | | item | PCDATA |
515 | NOTE | note | PCDATA |
516 | SORT-STRING | sort | PCDATA |
517 | SOUND | sound | extref | b64bin |
518 | | extref | EMPTY |
519 | | b64bin | PCDATA |
520 | URL | url | PCDATA |
521 | URI | uri | PCDATA |
522 +----------------+------------+-----------------------------+
524 Security Types
525 +----------------+------------+-----------------------------+
526 | vCard | Element | Element Content Model |
527 | Type Name | Name | |
528 +----------------+------------+-----------------------------+
529 | KEY | key | extref | b64bin |
530 | | extref | EMPTY |
531 | | b64bin | PCDATA |
533 Dawson 11 Expires December 1999
534 +----------------+------------+-----------------------------+
536 Non-standard, experimental element types and attributes lists MUST
537 only be specified by declarations in an internal DTD within the vCard
538 XML document.
540 The [RFC2426] specification specifies that the vCard types
541 corresponding to the "label" and "note" element types can contain
542 formatted content, such as is specified by multiple lines of text. In
543 such cases, the formatted text should be specified as CDATA section
544 content. The CDATA section specifies arbitrary character data that is
545 not meant to be interpretted. It is not scanned for markup by the XML
546 parser.
548 2.9 Parameter Entities
550 The external, vCard XML DTD specified in section 3 makes use of
551 parameter entity declarations. This XML feature is used to group
552 declarations within the DTD. This technique has been used in DTD
553 design in order to facilitate the reading and comprehension of the
554 structure specified by the DTD.
556 2.10 Namespace
558 [XMLNS] defines "Namespaces in XML" to be a collection of names,
559 identified by a URI, which are used in XML documents as element types
560 and attribute names. The [XML] specification does not include a
561 definition for namespaces, but does set down some guidelines for
562 experimental naming of namespaces.
564 XML namespaces allow multiple markup vocabularies in a single
565 document. Considering the utility of the vCard types in other
566 applications, it is important for the vCard XML DTD to define a
567 namespace for the vCard element types and attributes.
569 This memo defines the value that MUST be used in non-vCard XML
570 documents that reference element types or attribute lists from the
571 vCard namespace.
573 The following is an example of a well-formed but invalid "xdoc"
574 document type that includes elements and attribute lists from the
575 vCard namespace:
577
578
579
583
584
586
587
589 Dawson 12 Expires December 1999
590 2.11 Emailing the vCard XML Representation
592 It is expected that vCard XML documents will need to be sent over
593 SMTP/MIME email. The "text/xml" and "application/xml" content-types
594 have been registered for XML documents.
596 The "text/xml" and "application/xml" content-type definitions do not
597 provide for any header field parameters to identify the type of XML
598 document contained in the MIME entity. This means that a recipient
599 mail user agent must (MUA) open up each "text/xml" or
600 "application/xml" content in order to determine what object handler
601 is needed to process the information. To a MUA, all XML documents
602 look like just plain "text/xml" or "application/xml" content.
604 Internet application conforming to this memo MUST identify vCard XML
605 documents with the experimental content-type "text/x-xcfxml". For
606 example, a vCard XML document would have the following content-type
607 header field:
609 content-type:text/x-xcfxml
611 An XML application supporting the vCard XML document type MUST be
612 able to receive and properly process the "text/x-vcardxml" content-
613 type contained within a "multipart" message.
615 2.12 vCard XML Representation and File Systems
617 The vCard XML documents will be stored in file systems. The accepted
618 practice for file extensions for XML documents is the text "XML".
619 However, in order to uniquely identify vCard XML documents for file
620 association with applications that can directly process this document
621 type, it is RECOMMENDED that the file extension be the text "XCF".
623 3. vCard XML Document Type Definition
625 The following DTD conforms to XML version 1.0, as specified by [XML].
627
629
630
631
633
636
638
641
646
649
653
656
658
661
663
666
668
669
673
674
678
679
683
684
688
689
693
694
698 Dawson 14 Expires December 1999
699
700
704
705
709
710
715
716
717
719
722
725
728
731
734
737
740
743
746
749
752 Dawson 15 Expires December 1999
753
756
759
760
761
763
764
766
768
780
781
782
783
784
786
787
788
789
793
795
796
800
801
805
806
812
813
817
818
822
823
827
828
831
832
833
835
836
839
840
842
843
845
846
847
849
850
852
854
857
858
862
864 Dawson 17 Expires December 1999
865
869
870
874
875
879
880
884
885
889
890
894
895
900
901
903
904
905
909
910
914
915
919 Dawson 18 Expires December 1999
920
921
923
924
925
927
929
930
931
933
934
935
937
938
940
941
945
946
950
951
954
955
956
958
960
961
963
965
966
969
970
974 Dawson 19 Expires December 1999
975
976
978
980
981
985
986
990
991
995
996
999
1000
1001
1003
1004
1006
1008
1009
1011
1013
1014
1015
1016
1018 4. vCard v3.0 Notation
1020 The formal public identifier (FPI) for the DTD described in this
1021 specification is "-//IETF//DTD vCard v3.0//EN".
1023 A XML document can reference an external non-XML entity containing a
1024 vCard v3.0 object, as specified by [RFC2426]. The vCard v3.0 object,
1025 while encoded in the standard, non-XML format can be referenced in an
1026 external entity reference that identifies the [RFC2426] format in a
1027 notation declaration. The [RFC2426] format is identified by the
1029 Dawson 20 Expires December 1999
1030 formal public identifier "-//IETF//NONSGML vCard version 3.0//EN", as
1031 defined in [FPI].
1033 5. Example Usage
1035 5.1 Simple vCard
1037 The following is a simple example of a XML document using this DTD.
1039
1040
1042
1044 Frank Dawson
1045 DawsonFrank
1046 +1-617-693-8728
1047 +1-919-676-9515
1048
1049 6544 Battleford Drive
1050 RaleighNC
1051 27613-3502US
1052
1055 Frank_Dawson@Lotus.com
1056
1058 5.2 vCard with non-standard extension
1060 The following is an example of vCard that also includes a non-
1061 standard extension.
1063
1064
1069
1070
1071 ]>
1073
1076 Frank Dawson
1077 Dawson
1078 Frank
1079 +1-617-693-8728
1080 O+
1081
1083 Dawson 21 Expires December 1999
1084 5.3 vCard with photo element
1086 The following is an example of a vCard that also includes an external
1087 reference to a photo. Similar structure would be used to represent a
1088 vCard with an external reference to a logo, sound or public
1089 key/certificate.
1091
1092
1096
1098 ]>
1100
1103 Frank Dawson
1104 Dawson
1105 Frank
1106 +1-617-693-8728
1107
1108 Frank_Dawson@Lotus.com
1109
1111 The following is an example of a vCard that includes a photo element
1112 as inline binary content.
1114
1115
1117
1118 Frank Dawson
1119 DawsonFrank
1120 MIICajCCAdOgAwIBAgICBEUwDQ
1121 EEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bmlj
1122 YXRpb25z...and so on...IENvcnBvc==
1123
1125 5.4 vCard with an agent element
1127 The following is an example of a vCard that includes an agent
1128 element. The content of the agent element is another vCard.
1130
1131
1133
1136 Frank Dawson
1137 Dawson
1139 Dawson 22 Expires December 1999
1140 Frank
1141 +1.617.693.8728
1142
1145 Kathie Collins
1146 Collins
1147 Kathie
1148 +1.617.693-5660
1149 Kathie_Collins@Lotus.com
1150
1151 Frank_Dawson@Lotus.com
1152
1154 5.5 Document with multiple vCards
1156 The following is an example of a vCard document that includes more
1157 than one vCard.
1159
1160
1162
1163
1164 John Smith
1165 Smith
1166 John
1167 jsmith@host.com
1168
1169
1170 Fred Stone
1171 Stone
1172 Fred
1173 fstone@host1.com
1174
1175
1177 5.6 Document utilizing vCard namespace
1179 The following is an example of a XML document that declares the vCard
1180 namespace as its default namespace.
1182
1184
1186 Frank Dawson
1187 DawsonFrank
1188 fdawson@host1.com
1189
1191 The following is an example of a XML document that includes elements
1192 from the vCard namespace.
1194 Dawson 23 Expires December 1999
1195
1197
1200 John Smith
1201 +1-919-555-1234
1202 1234567
1203 999.99
1204
1206 5.7 XML document reference to a non-XML vCard
1208 The following is an example of a XML document with a proper reference
1209 to a non-XML entity containing a vCard object in the format defined
1210 by [RFC2426]. This example shows how existing vCard objects can be
1211 integrated into XML documents using the XML structure defined in this
1212 document.
1214
1215
1220
1222 ]>
1224
1225
1226 01234-56789
1227 $1,000,000
1228
1230 6. Namespace
1232 [XMLNS] defines "XML namespaces" to be a collection of names,
1233 identified by a URI, which are used in XML documents as element types
1234 and attribute names. XML namespaces allow multiple markup vocabulary
1235 in a single document. Considering the utility of the vCard properties
1236 in other applications, it is important for the vCard XML DTD to
1237 define a namespace for the vCard element types.
1239 This memo includes the definition of both a qualified name for the
1240 vCard namespace and also a default namespace. The namespace
1241 declaration is specified by attributes on the "vCard" element. The
1242 default namespace is specified with the "xmlns" attribute and the
1243 qualified name for the vCard namespace is specified with the
1244 "xmlns:vcf" attribute.
1246 The default namespace attribute is useful in XML documents that are
1247 based on the vCard document types. The qualified name for the vCard
1249 Dawson 24 Expires December 1999
1250 namespace is useful in XML documents that partially consist of vCard
1251 elements types but also consist of element types from other schemas.
1253 The following is an example of the a vCard namespace declaration
1254 using the qualified namespace:
1256
1257
1261
1262
1264
1266 The following is an example of a vCard namespace declaration using
1267 the default namespace:
1269
1270
1273
1274
1276
1278 7. Major Contributors
1280 The following individual has provided major contribution in the
1281 concepts and content to this memo:
1283 Paul Hoffman
1285 8. Acknowledgments
1287 The following have participated in the drafting and discussion of
1288 this memo:
1290 Scott Boag, Dean Burton, Charles Goldfarb, Alex Hoppman, Lisa
1291 Lippert, Sean McGrath, Noah Mendelsohn, Surendra Reddy, Thomas
1292 Rowe, Doug Royer
1294 9. Security Considerations
1296 Security issues are not currently discussed in this memo.
1298 10. Bibliography
1300 [FPI] F. Dawson and P. Hoffman, "vCard v3.0 Formal Public
1301 Identifier", Internet Draft, http://www.internic.net/internet-
1302 drafts/draft-dawson-vcard-fpi-00.txt, July 1998.
1304 Dawson 25 Expires December 1999
1306 [ISO9070] "Information Technology_SGML Support Facilities_
1307 Registration Procedures for Public Text Owner Identifiers", ISO/IEC
1308 9070, Second Edition, International Organization for Standardization,
1309 April, 1991.
1311 [RFC 2045] N. Freed, N. Borenstein, "Multipurpose Internet Mail
1312 Extensions (MIME) - Part One: Format of Internet Message Bodies", RFC
1313 2045, http://www.ietf.org/rfc/rfc2045.txt, November 1996.
1315 [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate
1316 Requirement Levels", RFC 2119, http://www.ietf.org/rfc/rfc2119.txt,
1317 March 1997.
1319 [RFC2426] F. Dawson and T. Howes, "vCard MIME Directory Profile", RFC
1320 2426, http://www.ietf.org/rfc/rfc2426.txt, September 1998.
1322 [XML] "Extensible Markup Language (XML)", Worldwid Web Consortium,
1323 http://www.w3.org/TR/1998/REC-xml-19980210, February 1998.
1325 [XMLNS] "Namespaces in XML", Worldwide Web Consortium,
1326 http://www.w3.org/TR/1999/REC-xml-names-19990114, January 1999.
1328 11. Author's Address
1330 The following address information is provided in a vCard XML DTD
1331 electronic business card, format.
1333
1336 Frank Dawson
1337 Dawson
1338 Frank
1339 Lotus Development Corporation
1340
1341 6544 Battleford Drive
1342 Raleigh
1343 NC
1344 27613-3502
1345
1346 +1-617-693-8728
1347 +1-919-676-9515
1348 Frank_Dawson@Lotus.com
1349 fdawson@earthlink.net
1350
1352 12. Full Copyright Statement
1354 "Copyright (C) The Internet Society (1999).All Rights Reserved.
1356 This document and translations of it may be copied and furnished to
1357 others, and derivative works that comment on or otherwise explain it
1359 Dawson 26 Expires December 1999
1360 or assist in its implmentation may be prepared, copied, published and
1361 distributed, in whole or in part, without restriction of any kind,
1362 provided that the above copyright notice and this paragraph are
1363 included on all such copies and derivative works.However, this
1364 document itself may not be modified in any way, such as by removing
1365 the copyright notice or references to the Internet Society or other
1366 Internet organizations, except as needed for the purpose of
1367 developing Internet standards in which case the procedures for
1368 copyrights defined in the Internet Standards process MUST be
1369 followed, or as required to translate it into languages other than
1370 English.
1372 The limited permissions granted above are perpetual and will not be
1373 revoked by the Internet Society or its successors or assigns.
1375 This document and the information contained herein is provided on an
1376 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
1377 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
1378 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
1379 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
1380 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1382 Dawson 27 Expires December 1999