Friday, June 17, 2005, 6:14:38 PM, Tim Bray wrote:
> My feeling was that we ruled out composite types in *local* content > [...] I'm still looking, but my suspicion is that we never did rule them out, and that this restriction crept in during some editorial rephrasing. > [...] for fairly obvious reasons. I don't know what the obvious reasons are... Lack of client support? - hardly seems a reason to ban a MIME type, else there is a huge list of ones that we should ban at IANA. We are defining a data format here. If publishers want to publish entries as text, message/rfc-822, application/msword, image/jp2, or whatever, then that is up to them. I don't see how we can justify a MUST NOT requirement for "composite types". > The fix is obvious, in 4.1.3.1 > "Failing that, it MUST be a MIME media type. If the "src" attribute > is not provided, i.e. the content is local, the value of the "type" > attribute MUST NOT be a composite type... " I'm in favour of replacing: "Failing that, it MUST be a MIME media type, but MUST NOT be a composite type (see Section 4.2.6 of [MIMEREG])." with: "Failing that, it MUST be a MIME media type." -- Dave
