Registration of media type text/vcard

[Ned Freed]

> 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.

Yes, although I again note that a parameter that can only accept a single value
is at odds with trying to minimize silly states.

> > 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).

This may be a benefit in the short term, but in the long term... I'm not so
sure. Unless you make both the parameter and its only value mandatory, you
cannot count on it being present. So basically this is a workaround for viewer
issues that would be better addressed by being able to associate a different
default charset with different subtypes of text.

It is extremely unfortunate that such functionality is necessary, but because
of the time and the way MIME was developed, plus the changes HTTP decided to
impose, it is.

More specifically, this is one of the few technical changes we really need to
make in MIME: RFC 2046 currently states that the default charset for all
subtypes of text is us-ascii. text/html breaks that, and even worse, breaks it
in order to support iso-8859-1 and not utf-8.

The correct fix at this point IMO is for text/plain to default to us-ascii and
allow other subtypes to specify their own defaults. In the absence of a
specification of a default, I'm tempted to say the "default default" should
be UTF-8. 

				Ned