Registration of media type text/vcard
Type name: text Subtype name: vcard Required parameters: none Optional parameters: version The "version" parameter is to be interpreted identically as the VERSION vCard property. If this parameter is present, all vCards in a text/vcard body part MUST have a VERSION property with value identical to that of this MIME parameter. Encoding considerations: The "charset" MIME parameter, if present, MUST be set to "UTF-8", as defined in [RFC3629]. Security considerations: See Section 9. Interoperability considerations: The text/vcard media type is intended to identify vCard data of any version. There are older specifications of vCard [RFC2426][oldreference_VCARD] still in common use. While these formats are similar, they are not strictly compatible. In general, it is necessary to inspect the value of the VERSION property (see Section 6.7.9) for identifying the standard to which a given vCard object conforms. In addition, the following media types are known to have been used to refer to vCard data. They should be considered deprecated in favor of text/vcard. * text/directory * text/directory; profile=vcard * text/x-vcard Published specification: draft-ietf-vcarddav-vcardrev-13 Applications that use this media type: They are numerous, diverse, and include mail user agents, instant messaging clients, address book applications, directory servers, customer relationship management software, etc. Additional information: Magic number(s): File extension(s): .vcf Macintosh file type code(s): Person & email address to contact for further information: Simon Perreault <simon.perreault@viagenie.ca> Intended usage: COMMON Restrictions on usage: none Author: Simon Perreault and Pete Resnick Change controller: IETF -- NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org
On 18.08.2010 18:21, Simon Perreault wrote:
Type name: text
Subtype name: vcard
Required parameters: none
Optional parameters: version
The "version" parameter is to be interpreted identically as the VERSION vCard property. If this parameter is present, all vCards in a text/vcard body part MUST have a VERSION property with value identical to that of this MIME parameter.
Encoding considerations: The "charset" MIME parameter, if present, MUST be set to "UTF-8", as defined in [RFC3629]. ...
I wonder whether restricting the allowed values of charset to "UTF-8" is compatible with <http://tools.ietf.org/html/rfc4288#section-4.2.1>: The "text" media type is intended for sending material that is principally textual in form. A "charset" parameter MAY be used to indicate the charset of the body text for "text" subtypes, notably including the subtype "text/plain", which is a generic subtype for plain text defined in [RFC2046]. If defined, a text "charset" parameter MUST be used to specify a charset name defined in accordance to the procedures laid out in [RFC2978]. If we all agree this is ok it might be good to submit an erratum fpr RFC 4288. Best regards, Julian
The following might be a personal opinion: What is the advantage of having a charset parameter? When I see how this has caused issues with faulty transmissions (most commonly servers claiming media type text/html; charset=iso-8859-1 without certainty that it is in the right charset), I would like to discourage any charset parameter anywhere possible. From your registration the parameter brings no information (am I right?). So why include it and not simply rely on the Byte-Order-Mark? Paul Le 18 août 2010 à 18:21, Simon Perreault <simon.perreault@viagenie.ca> a écrit :
Type name: text
Subtype name: vcard
Required parameters: none
Optional parameters: version
The "version" parameter is to be interpreted identically as the VERSION vCard property. If this parameter is present, all vCards in a text/vcard body part MUST have a VERSION property with value identical to that of this MIME parameter.
Encoding considerations: The "charset" MIME parameter, if present, MUST be set to "UTF-8", as defined in [RFC3629].
Security considerations: See Section 9.
Interoperability considerations: The text/vcard media type is intended to identify vCard data of any version. There are older specifications of vCard [RFC2426][oldreference_VCARD] still in common use. While these formats are similar, they are not strictly compatible. In general, it is necessary to inspect the value of the VERSION property (see Section 6.7.9) for identifying the standard to which a given vCard object conforms.
In addition, the following media types are known to have been used to refer to vCard data. They should be considered deprecated in favor of text/vcard.
* text/directory
* text/directory; profile=vcard
* text/x-vcard
Published specification: draft-ietf-vcarddav-vcardrev-13
Applications that use this media type: They are numerous, diverse, and include mail user agents, instant messaging clients, address book applications, directory servers, customer relationship management software, etc.
Additional information:
Magic number(s):
File extension(s): .vcf
Macintosh file type code(s):
Person & email address to contact for further information: Simon Perreault <simon.perreault@viagenie.ca>
Intended usage: COMMON
Restrictions on usage: none
Author: Simon Perreault and Pete Resnick
Change controller: IETF
-- NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org
The following might be a personal opinion:
What is the advantage of having a charset parameter?
When I see how this has caused issues with faulty transmissions (most commonly servers claiming media type text/html; charset=iso-8859-1 without certainty that it is in the right charset), I would like to discourage any charset parameter anywhere possible.
A charset parameter makes sense when (a) Multiple charsets are in use that cannot be readily distinguished from each other and (b) The media type does not identify the charset in use internally. If those conditions aren't met, then the parameter makes no sense. If they are, a parameter is needed. Ned
* Simon Perreault wrote:
Type name: text
Subtype name: vcard
Required parameters: none
Optional parameters: version
The "version" parameter is to be interpreted identically as the VERSION vCard property. If this parameter is present, all vCards in a text/vcard body part MUST have a VERSION property with value identical to that of this MIME parameter.
This should probably say that not only the semantic but also the syntax is the same as for the "VERSION" property.
Encoding considerations: The "charset" MIME parameter, if present, MUST be set to "UTF-8", as defined in [RFC3629].
The "charset" parameter would have to be defined under "optional parameters"; this field should have one of the values defined in RFC 4288 (7bit, framed, binary, or 8bit). Further, this should first define syntax and semantics of the parameter value and then limit the set of permissable values, so something like '"charset": as defined for text/plain; encodings other than UTF-8 [STD0063] must not be used." I do note that there are plenty of applications that treat text types with a charset parameter as being text in the specified encoding, while such an imposed limit will cause some implementations to treat documents as UTF-8 encoded regardless of the parameter; that in turn can be a se- curity vulnerability and should be noted in the Security Considerations.
Interoperability considerations: The text/vcard media type is intended to identify vCard data of any version. There are older specifications of vCard [RFC2426][oldreference_VCARD] still in common use. While these formats are similar, they are not strictly compatible. In general, it is necessary to inspect the value of the VERSION property (see Section 6.7.9) for identifying the standard to which a given vCard object conforms.
In addition, the following media types are known to have been used to refer to vCard data. They should be considered deprecated in favor of text/vcard.
* text/directory
* text/directory; profile=vcard
* text/x-vcard
I've just posted a comment on this to vcarddav@ietf.org.
Published specification: draft-ietf-vcarddav-vcardrev-13
Applications that use this media type: They are numerous, diverse, and include mail user agents, instant messaging clients, address book applications, directory servers, customer relationship management software, etc.
The trailing "etc." is unnecessary here as it is clear that these are only examples. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
participants (5)
-
Bjoern Hoehrmann -
Julian Reschke -
Ned Freed -
Paul Libbrecht -
Simon Perreault