On Thu, 27 Nov 2003 18:32:50 MST, Jeroen Bekaert <jeroen.bekaert@xxxxxxxx> 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...
Attachment:
pgp00353.pgp
Description: PGP signature