- From: Mark Nottingham <mark.nottingham@bea.com>
- Date: Tue, 11 Nov 2003 10:44:12 -0800
- To: "Martin Gudgin" <mgudgin@microsoft.com>
- Cc: "Xml-Dist-App@W3. Org" <xml-dist-app@w3.org>
On Nov 7, 2003, at 9:50 AM, Martin Gudgin wrote: > My own take is that this approach is actually the reverse of what we > actually want. Going XML->MIME is easier, because there are questions of canonicalizing MIME headers (e.g., multiple header folding w/ commas, multiple-line headers, etc.). See all of RFC2822 Section 2.2. > I suggest that we actually start by deciding what > metadata we care about in two cases: > > a. On a Representation element information item > b. On an arbitrary element information item whose content is in > canonical base64 > > and then define a mapping from that metadata to the appropriate MIME > headers. > > Part of my action was to attempt a classification of MIME headers into > two 'buckets' along the lines of a and b above. I have not had time to > do this. Apologies. It might be good to think of these as two separate cases; It might be good to have a generic representation mechanism that doesn't have any special knowledge of particular headers, e.g., <foo:Representation> <header name="Content-Type">text/plain</header> <header name="whatever">bazbarbat</header> <body>...</body> </foo:Representation> Whilst having something that is more specialized for marking arbitrary content; <x:Picture m:content-type="image/jpg">...</x:Picture> It's important to make the field name an attribute value, rather than the localname of an element or attribute; this is because of hte allowable syntax of a field-name; > A field name MUST be composed of printable US-ASCII characters (i.e., > characters that have values between 33 and 126, inclusive), except > colon. So, it would be very easy to find some MIME or MIME-like headers that wouldn't be legal QNames (e.g., the HTTP Extension Framework puts headers in name spaces by prefixing them with integers). Regarding the set of headers to be included in (b), I'd be inclined to keep it very, very small; a good starting point is restricting it to anything that starts with "content-", because RFC2045 says: > Any field not beginning with "content-" can have no defined meaning > and may be ignored. in the definition of MIME-part-headers. My suggestion: limit it to our media/content type header. Why? Arguably, content-language and xml:lang do the same thing, content-type and content-transfer-encoding both may contribute to xsi:type, and Content-ID to xml:id (if it ever joins us). Content-Location and Content-Disposition are interesting ones, but perhaps we should wait for use cases... -- Mark Nottingham Principal Technologist Office of the CTO BEA Systems
Received on Tuesday, 11 November 2003 13:44:17 UTC