raffazizzi
commented
13 years ago We may have had a misunderstanding as I suggested to treat the specification of the media type as a possible content of the "accept" HTTP header. It seems that that may need to become a separate ticket [see below]. Part of the reason for the misunderstanding is that the current description of @mimeTime is veeeery general and we wanted to make some sense of it. The description should be more informative.
As for "media types", it seems to me that the term is at least three ways ambiguous, and the doc at http://www.ietf.org/rfc/rfc4288.txt shows at least two, maybe all three of the usages. Besides interpreting the term as referring to the top-level type, e.g. "text", which we are rather not interested in here on its own, the treatment intended currently in the Guidelines apparently concerns the type/subtype combination, as in "text/plain", but as some RFCs stress or strongly recommend (e.g. http://www.ietf.org/rfc/rfc3023.txt -- "XML Media Types"), it often makes sense to also use parameters, and these parameters are separated by a space, hence data.word alone indeed does not appear sufficient. Example from RFC3023: "text/xml; charset='utf-8'".
The issue of the "accept" HTTP header that may need to go into a separate ticket for a separate attribute, leaving this one as solely informative, concerns strings such as:
"text/plain; q=0.5, text/html, text/x-dvi; q=0.8, text/x-c"
which means "text/html and text/x-c are the preferred media types, but if they do not exist, then send the text/x-dvi entity, and if that does not exist, send the text/plain entity."
Original comment by: bansp
As mimeTypes are defined and used, for example in http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html, they are meant to be able to supply multiple values. Currently
@mimeTypeis datatype data.word and we're suggesting it should be 1-infinity of data.word+-James
Original comment by: jamescummings