On Thu, 27 Nov 2003 18:32:50 MST, Jeroen Bekaert
<jeroen(_dot_)bekaert(_at_)ugent(_dot_)be> said:
As such, a possible value of Y could be "text/xml; charset=utf-8"?
As such, a possible value of Y could be: "text"
You want media-type to be "text" with a subtype of "xml" and
a parameter "charset=utf-8".
I don't see any way to use the BNF of RFC2046, section 5.1 to get any
other parse. In fact, further down in section 5, it says:
type of data. Thus, a media type of "image/xyz" is enough to tell a
user agent that the data is an image, even if the user agent has no
knowledge of the specific image format "xyz". Such information can
be used, for example, to decide whether or not to show a user the raw
data from an unrecognized subtype -- such an action might be
reasonable for unrecognized subtypes of text, but not for
unrecognized subtypes of image or audio. For this reason, registered
So the intent is to have the media-type say "this is text" or "this is an
image" or "this is a sound" or "this is a composite", and so on, so that an MUA
can make a vague guess as to what do with it even if it has no clue at all what
to do with the specific subtype or parameters. For instance, an MUA would be
within it's rights to refused to deal with *any* flavor of text/* (including
even text/plain) if it included a 'charset=' parameter it didn't know how to
deal with. As an example, displaying *any* sort of Big5 text on a display that
is ascii/8859-* only is basically doomed...
pgphGNYLOeXRP.pgp
Description: PGP signature