- From: Martin Gudgin <mgudgin@microsoft.com>
- Date: Wed, 5 Nov 2003 03:44:15 -0800
- To: "Anish Karmarkar" <Anish.Karmarkar@oracle.com>, "Mark Nottingham" <mark.nottingham@bea.com>
- Cc: <noah_mendelsohn@us.ibm.com>, "Xml-Dist-App@W3. Org" <xml-dist-app@w3.org>
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: xml-dist-app-request@w3.org > [mailto:xml-dist-app-request@w3.org] On Behalf Of Anish Karmarkar > Sent: 05 November 2003 08:18 > To: Mark Nottingham > Cc: noah_mendelsohn@us.ibm.com; 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, 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 06:44:22 UTC