RE: Content-Location MIME headers?

["Patil, Sanjay" <Spatil@netfish.com>]

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
>