Re: entity header

Mark,

the UC2 is the driving scenario for this feature. The word 'cache'
implies an HTTP cache which carries a lot of complexity and so it's not
called out in UC2. 

But even for a full-fledged cache using the Representation header it's
the Infoset that feeds the cache and it doesn't matter, what the XOP
MIME packages look like. Perhaps my previous comment was misdirected by
misinterpretation of your text. 

I think we agree that XOP/MTOM don't care about Representation, that in
fact Representation doesn't care about those two (but the combination
is, in fact, useful), and that for a full cache more than just
content-type is necessary. My latest proposal for Representation header
gives an example how further information can be added to the header by
an extension. We may specify that extension, if we choose to do so.
Personally, I don't think it's worth it, I think the bare and simple
Representation will do in practice.

Best regards,

                   Jacek Kopecky

                   Systinet Corporation
                   http://www.systinet.com/




On Fri, 2004-01-16 at 14:55, Mark Nottingham wrote:
> AFAIK, the driver for the Representation header is the 'portable cache' 
> scenario, for some measure of backwards compatibility with uses of SwA. 
> If we still want to enable that, I think we need to be capable of more 
> metadata than media type, because some people may be using such 
> metadata in MIME, and will need corresponding metadata in the header.
> 
> Do I misunderstand why we're doing this?
> 
> Cheers,
> 
> 
> On Jan 16, 2004, at 5:21 AM, Jacek Kopecky wrote:
> 
> > On Wed, 2004-01-14 at 19:59, Mark Nottingham wrote:
> >>> With this, I think the metadata element
> >>> should go from the core proposal because it's no longer needed.
> >>> Basically, I suggest we go back to
> >>
> >> It's true that the only part that's interesting to MIFFYizing the
> >> entity's body is the Content-Type; however, there are other bits of
> >> metadata that may be interesting to the application that uses the
> >> header. If we don't enable other headers, there will be loss of
> >> information when an XML entity is transcoded to a MIME entity.
> >
> > Mark, I don't believe it's the goal of XOP to create fully described
> > MIME entities out of the optimized parts, the goal is to optimize the
> > serialization of a document infoset. I believe we could just go with
> > marking every part (but the root) of the resulting MIME package as
> > application/octet-stream with no further information. The fact that we
> > may allow some more information from the infoset to be used when
> > creating the parts (like content-type and possibly other stuff) is 
> > nice,
> > but not necessary for the main goal.
> >
> > I think we shouldn't expand that goal too much - specifying the
> > content-type may be easy so we'll probably add it in XOP in some way,
> > handling other MIME or HTTP headers with the given layering
> > (Representation header takes advantage of XOP but XOP is not necessary
> > for Representation header to function properly) may not be as simple to
> > specify generally enough for it to be really useful.
> >
> > Best regards,
> >
> >                    Jacek Kopecky
> >
> >                    Systinet Corporation
> >                    http://www.systinet.com/
> >
> >
> >
>

Received on Friday, 16 January 2004 09:15:21 UTC