OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

[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 
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 :-)

Sanjay Patil
Work Phone: 408 350 9619

-----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?


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.



[1] http://ietf.org/rfc/rfc2557.txt?number=2557

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC