Registration of media type text/vcard

Julian Reschke julian.reschke at gmx.de
Thu Aug 26 13:42:21 CEST 2010


On 25.08.2010 18:28, Ned Freed wrote:
>> On 2010-08-25 11:48, Paul Libbrecht wrote:
>>> What is the advantage of having a charset parameter?
>
>> You mean for vCard 4 or for MIME?
>
>> For vCard 4, we felt that MIME came with a charset parameter and we had
>> no power to way "this parameter MUST NOT not be applied to vCard 4".
>
> Not sure where you got this idea, but in any case, it's incorrect. From RFC
> 2046, section 4.1:
>
>     A "charset" parameter may be used to
>     indicate the character set of the body text for "text" subtypes,
>     notably including the subtype "text/plain", which is a generic
>     subtype for plain text.
>
> Note the "may". May != must. Indeed, may != should. So there is no reason why
> you cannot say "optonal parameters: none" for thie media type.

Oh, indeed. Also, in 4.1.2:

"The specification for any future subtypes of "text" must specify 
whether or not they will also utilize a "charset" parameter, and may 
possibly restrict its values as well. For other subtypes of "text" than 
"text/plain", the semantics of the "charset" parameter should be defined 
to be identical to those specified here for "text/plain", i.e., the body 
consists entirely of characters in the given charset. In particular, 
definers of future "text" subtypes should pay close attention to the 
implications of multioctet character sets for their subtype 
definitions." -- 
<http://greenbytes.de/tech/webdav/rfc2046.html#rfc.section.4.1.2.p.4>

So from that point of view, both charset, and restricting it to a single 
value is ok.

> THere's no shortages of "running code" here either - several type subtypes have
> been registered without a charset parameter (rtf, rtp-enc-aescm128,
> vnd.DMClientScript, etc.).
>
>> That's why we say instead that if it is used, then it MUST say UTF-8.
>
> While this approach does not violate any restriction I'm aware of, it
> definitely violates the MIME design philosophy, which was to avoid unnnecessary
> silly states.

Well, it has the benefit that if you send content to a recipient that 
has some default handling for text/*, but not for text/vcard, you can 
specify the encoding (I just verified that with Thunderbird).

Best regards, Julian


More information about the Ietf-types mailing list