Re: Representation header

It seems like a good idea to have a generic/extensible mechanism to 
allow one to specify such metadata in the Representation headers.

On the other hand, MTOM is really a trick which allows one to transmit 
data as raw binary, but still retains the infoset view of the data as 
base64Binary. In a lot of case (though not all), it is very likely that 
applications will process the raw binary data, referred to by the 
Representation header, without converting it to base64. In these cases, 
where the application does have access to the MIME parts (and therefore 
the MIME headers), it would be unnecessary to specify the metadata in 
the Representation header.

More comments inlined.

Thx.

-Anish
--

Mark Nottingham wrote:

> 
> +1
> 
> I think what we might end up doing is specifying the Representation 
> header as a shell with slots for metadata (whether attributes or element 
> children), paying special attention to the syntactic issues, 
> transforming back and forth between XML and MIME headers, etc., and then 
> define the media type indicator as something that slots in.
> 
> This reminds me of two issues in this area:
> * media type or content-type - when we define this media type attribute, 
> is is really the media type or the content-type? I.e., is it just a bare 
> type/subtype or can it have parameters like content types? If it's just 
> a media type, what are the implications WRT transforming back and forth 
> to MIME?
> 

Seems like it would be a good idea to allow content-type and not just 
the media type. For example, this would allow a text/xml media type 
document with encoding of shift_JIS to be transported as base64Binary 
inside a SOAP env with encoding of UTF-8.

> * content encoding - should we have a separate piece of metadata that 
> talks about the encoding? In MIME, that's Content-Transfer-Encoding; in 
> HTTP it's content-coding. If we don't do this, it bakes base64 in as the 
> only option ever (because it's implicit), so it may be beneficial to 
> specify something like
> 

I am not sure I understand, aren't the contents of the EII always 
base64Binary?

> <x:Representation media-type="image/jpg" content-encoding="base64">
>  ...
> </x:Representation>
> 
> This would allow you to have Representation headers that weren't base64 
> (i.e., you could have XML in there, or plaintext, or css, etc.). Note 
> that this is separate from the issue of what encodings <mtom:Include/> 
> supports.
> 
> 
> On Nov 3, 2003, at 2:12 PM, noah_mendelsohn@us.ibm.com wrote:
> 
>>
>> I have a vague intuition that some of the metadata we might want to carry
>> is specific to the "Representation" header, but others might be 
>> applicable
>> to a broader range of MTOM content.  For example, just because my binary
>> is an image/jpeg doesn't mean I should need to claim that it's a cached
>> copy of some particular URI.  So, I'd claim we want to allow media type
>> annontation on most any child element that's base64Binary.  Perhaps the
>> same for some others such as content-encoding, content-language, etc.  On
>> the other hand, I would think that the URI being cached is pertinent only
>> to the Representation header.  So:  would it be worth a bit of energy to
>> sort out which things apply only to Representation and which to a broader
>> range of MTOM content.
>>
>> BTW:  It's really too bad that XML doesn't have structured attributes, as
>> many of the MIME headers would seem to fit nicely as structured 
>> attributes
>> on the corresponding base64Binary representation of the content.
>>

Received on Wednesday, 5 November 2003 03:17:59 UTC