RE: Content-Location MIME headers?

[Dick Brooks <dick@8760.com>]

Sanjay,

I've had similar discussions regarding Content-Location with both the SOAP
and XP communities. RFC 2557 is very clear in describing the potential uses
of Content-Location, you cited one in your e-mail but you didn't cite the
other use, which I've included here: ref page 1 of RFC 2557

   "While initially designed to support e-mail transfer of complete
   multi-resource HTML multimedia documents, these conventions can also
   be employed to resources retrieved by other transfer protocols such
   as HTTP and FTP to retrieve a complete multi-resource HTML multimedia
   document in a single transfer or for storage and archiving of
   complete HTML-documents."

In other words Content-Location is a MIME equivalent to <a href="remote
URL"> where the data is NOT contained in the message but is retrieved from a
remote location using a URL.

If an MSH has to resolve all remote links, securely and reliably, before
issuing a transport ACK it will significantly and unnecessarily complicate
the MSH process. This is a consensus based process, if the group agrees that
Content-Location is required then our Commerce-Agent product will include
the functionality. However, I'm not convinced this functionality is a
"mainstream" requirement! The Energy industry has been doing E-Commerce over
the Internet since 1997 without this functionality and nobody is knocking
the doors down for it.

> What Chris is recommending is to utilize Content-Location
> instead of Content-ID MIME part header for labeling the part
> so that the main document doesn't need any re-working to set
> the references straight.

Sanjay, I don't understand what "re-work to set references straight" you're
referring to with CID's, please explain.

Dick Brooks
Group 8760
110 12th Street North
Birmingham, AL 35203
dick@8760.com
205-250-8053
Fax: 205-250-8057
http://www.8760.com/

InsideAgent - Empowering e-commerce solutions

> -----Original Message-----
> From: Patil, Sanjay [mailto:Spatil@netfish.com]
> Sent: Friday, December 22, 2000 8:50 PM
> To: 'dick@8760.com'; christopher ferris; ebxml-transport@lists.ebxml.org
> Cc: Askary, Sid
> Subject: RE: Content-Location MIME headers?
>
>
> List-Unsubscribe:
>  <mailto:ebxml-transport-request@lists.ebxml.org?body=unsubscribe>
> List-Archive: <http://lists.ebxml.org/archives/ebxml-transport>
> List-Help: <http://lists.ebxml.org/doc/email-manage.html>,
>  <mailto:ebxml-transport-request@lists.ebxml.org?body=help>
>
>
> Dick, I am missing something here. Please clarify ...
> As I understand, Content-Location is not required to be
> a "link" to any global available resource. Instead, it is
> just a label of the MIME part containing the external
> entity reference in the main document.
> Excerpt from RFC 2557 ...
>
>    An URI in a Content-Location header need not refer to an resource
>    which is globally available for retrieval using this URI (after
>    resolution of relative URIs).
>
> What Chris is recommending is to utilize Content-Location
> instead of Content-ID MIME part header for labeling the part
> so that the main document doesn't need any re-working to set
> the references straight.
>
> Assuming we can encrypt the entire MIME message which includes
> the main document as well as the reference entities,
> I do not see security issues here.
>
> Again, what I was proposing in my original reply to Chris
> was to have a level of indirection and create a map of
> references made inside the main document and labels of the
> MIME parts containing the referents, so that we could use
> any header for labeling. This map could be part of the Manifest.
>
> thanks,
> Sanjay Patil
> ------------------------------------------------------------------
> ----------
> ------------------------------
> Work Phone: 408 350 9619
> http://www.netfish.com
>
>
> -----Original Message-----
> From: Dick Brooks [mailto:dick@8760.com]
> Sent: Friday, December 22, 2000 5:34 PM
> To: christopher ferris; ebxml-transport@lists.ebxml.org
> Subject: RE: Content-Location MIME headers?
>
>
> Chris,
>
> The Content-Location header is useful for "pass by reference" scenarios
> where the data is not contained
> in the packaging of a message. The Content-Location is in essence a "link"
> to the actual data contents of
> a "body part", as opposed to having the actual data contents present
> directly in the MIME body part.
>
> There are a couple of practical issues with "pass be reference" semantics.
> For example:
>
> Should an MSH retrieve all Content-Location URL's before issuing
> a transport
> ack? What should a MSH do when it can't retrieve a Content-Location URL?
>
> Should ebXML specify how to report errors related to failed
> "retrievals" of
> Content-Location URL's?
>
> Should intermediaries retrieve Content-Location URL's to see if they're
> valid before forwarding a message?
>
> There are real security related concerns with Content-Location URL's. For
> example, I'm meeting with some healthcare
> folks next month to help them define their B2B interoperability
> profile/standard to be used in HIPAA and HL7. I believe
> these folks would not want to open a URL on the Internet
> containing a X-ray
> or other sensitive data without some form
> of access control (user/pass) and/or encryption/authentication. How does a
> MSH SECURELY convey access control information in a Content-Location URL?
>
> I also believe that most of the target market for ebXML is
> planning to send
> their data in a message, the same way they do today through VAN's or using
> Internet technology (e.g. http, ftp, smtp). I believe the number of people
> who would practically use "pass by reference" B2B is small compared to the
> number of people who will send an entire composite message containing the
> entire set of business documents to be processed.
>
> I believe we should not include "pass by reference" semantics, through the
> Content-Location MIME header, in ebXML TR&P.
>
> Dick Brooks
> Group 8760
> 110 12th Street North
> Birmingham, AL 35203
> dick@8760.com
> 205-250-8053
> Fax: 205-250-8057
> http://www.8760.com/
>
> InsideAgent - Empowering e-commerce solutions
>
> > -----Original Message-----
> > From: christopher ferris [mailto:chris.ferris@east.sun.com]
> > Sent: Friday, December 22, 2000 1:31 PM
> > 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
> >