Re: Strawman proposal for Representation header

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