RE: Representation header

One reason for specifying information in the Representation header is
that it can be secured using the mechanisms in WS-Security as it's just
another piece of XML. 

Gudge 

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of Anish Karmarkar
> Sent: 05 November 2003 08:18
> To: Mark Nottingham
> Cc: [email protected]; Xml-Dist-App@W3. Org
> Subject: 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, [email protected] 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.
> >>
> 
> 
>