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