Re: entity header

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 08:55:47 UTC