RE: Content-Location MIME headers?

[Dick Brooks <dick@8760.com>]

Thanks to an off-list discussion with Chris Ferris I have a better
understanding of the intended usage of
Content-Location and I no longer believe there are issues with remote access
at the MSH level. Sorry for any confusion my previous posts may have caused.

Happy holidays to all...


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: Dick Brooks [mailto:dick@8760.com]
> Sent: Saturday, December 23, 2000 11:02 AM
> To: Patil, Sanjay; 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>
>
> 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
> > >
>