[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Content-Location MIME headers?
An alternative could be - the payload lists all the external objects it references along with the unique reference it uses for each object - during packaging, create a map of the ids of the parts holding the external objects and the references to those in the payload - have a standard location in the header for this map With this one level of indirection, 1> the packaging does not need reprocessing of the payload for inserting the ids of external objects generated by packaging. 2> packaging will be free to use whatever it chooses to for identifying the parts holding external objects i.e. Content-ID or Content-Location, etc. Just and idea which is lurking in my mind since quite some time. May be it doesn't make any sense at all. Please feel free to blast :-) thanks, Sanjay Patil ---------------------------------------------------------------------------- ------------------------------ Work Phone: 408 350 9619 http://www.netfish.com -----Original Message----- From: christopher ferris [mailto:chris.ferris@east.sun.com] Sent: Friday, December 22, 2000 11:31 AM To: ebxml-transport@lists.ebxml.org Subject: Content-Location MIME headers? All, I believe that we should seriously consider use of Content-Location MIME headers as defined in RFC2557 as an option for addressing a specific MIME part from within the Manifest [1]. This MAY make packaging of the payload and manifest simpler and would allow for the "primary" payload object to refer to composite elements (images, etc.) by an URI reference without having to be changed to refer to MIME CID's. From RFC2557: This standard specifies that body parts to be referenced can be identified either by a Content-ID (containing a Message-ID value) or by a Content-Location (containing an arbitrary URL). The reason why this standard does not only recommend the use of Content-ID-s is that it should be possible to forward existing web pages via e-mail without having to rewrite the source text of the web pages. Such rewriting has several disadvantages, one of them that security checksums will probably be invalidated. Use of this approach might be combined with the addition of the xml:base attribute to the ebXMLHeader. Thoughts? Chris [1] http://ietf.org/rfc/rfc2557.txt?number=2557
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC