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: MIME enveloping and Packaging work paper for Thursday con-cal l.


Personally I was thinking along the lines of RFC 2387:

   "... The Multipart/Related media type is intended for compound objects 
consisting of several inter-related body parts.  For a Multipart/Related 
object, proper display cannot be achieved by individually displaying the 
constituent body parts.  The content-type of the Multipart/Related object 
is specified by the type parameter. The "start" parameter, if given, 
points, via a content-ID, to the body part that contains the object 
root.  The default root is the first body part within the Multipart/Related 
body. The relationships among the body parts of a compound object 
distinguishes it from other object types.  These relationships are often 
represented by links internal to the object's components that reference the 
other components.  Within a single operating environment the links are 
often file names, such links may be represented within a MIME message using 
content-IDs or the value of some other "Content-" headers. ..... "

I think the language above leaves room for specific applications e.g. usage 
of URNs/URLs within an ebXML multipart - message. I may be wrong, but I 
thought this came up in Orlando (may have been an off-line chat) and I 
think your notion of a manifest is a good one. Hope this helps the 
discussion in the next conf. call.


p.s. Is there a good reason for having the manifest within the header 
structure as opposed to having the header point to the manifest (or vice 
versa) ?

At 11:09 AM 3/7/00 -0800, David Burdett wrote:
>I found the attached document interesting. However I'd like your views on
>how you would refer to MIME parts from within a Manifest, for example in XML
>Messaging I thought that the Message Manifest in the Message header might
>look something like ...
>   <DocumentReference Id='AB273' DocumentType='Text/XML'
>      URI='urn:example.com:ACV-CN-1999/2456#MessageRoutingInfo'
>      Purpose='MessageRoutingInfo' >
>   <DocumentReference Id='AB274' DocumentType='Text/XML'
>      URI='urn:example.com:ACV-CN-1999/2456#Invoice'
>      Purpose='NewInvoice' >
>   <DocumentReference Id='AB275' DocumentType='Image/Jpg'
>      URI='urn:example.com:ACV-CN-1999/2456#InvoiceImage'
>      Purpose='InvoiceAttachment' >
>The idea of using a URI is that you could refer to something that was:
>1. In the same Message by specifying a URN, or
>2. Somewhere on the web, by specifying a URL - if this was an ftp address
>then it could be useful for "sending" large files.
>You could also then use the URI as the unique identifier of a document after
>you had taken the message apart and put the various parts in a file or
>database somewhere.
>Two questions:
>1. how would this work if you wanted to refer to something in the same or
>another message
>2. You'll also notice that I've made the Manifest 'flat' rather than the
>nested Mime-within-Mime that you had in your example. What do you think are
>the pros and cons of this?
>I'd appreciate your thoughts on this.
>-----Original Message-----
>From: Dick Brooks [mailto:dick@8760.com]
>Sent: Monday, March 06, 2000 12:06 PM
>To: Ebxml
>Cc: Dick Brooks
>Subject: MIME enveloping and Packaging work paper for Thursday con-call.
>The attached file is the work paper Nick and I agreed to produce during the
>last con-call. Please review and prepare to discuss during the con-call on
>Dick Brooks

[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