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: Additional MIME headers


Robert,

You make an excellent point.  It really is too bad we weren't defining 
an API.  I think ebXML would get a lot more attention if it did, but 
that's just my opinion.

I think it would be beneficial to at least state in the spec that 
applications _may_ set extra MIME fields, but they will not be used by 
the message server itself for standard ebxml communication.  Having that 
note in there may encourage people to not make changes to the 
ebXMLHeader element for their own purposes, instead using fields in the 
MIME envelope that are harmless to servers/clients that do not 
understand them.

Cheers,

Matt
Adams, Robert wrote:

> I would think this is more a function of the API to the transport system
> rather then an extension to the existing headers...  The API could return
> the "extended MIME header" or it could return the extra MIME information in
> a new version of the header syntax.
> 
> It's too bad we are not specifying the API.  There are a lot of semantics
> that we could pass off to or specify as a function of an API.
> 
> 	Robert Adams
> 	mailto:Robert.Adams@intel.com
> 	MS JF3-212
> 	2111 NE 25th Ave
> 	Hillsboro, OR   97124    USA
> 	phone: +1.503.264.9424; cell: +1.503.709.3259; FAX: +1.503.264.3375
> 
> 
> -----Original Message-----
> From: Matthew MacKenzie [mailto:matt@xmlglobal.com]
> Sent: Friday, December 15, 2000 7:44 PM
> To: Burdett, David
> Cc: ebXML Transport (E-mail)
> Subject: Re: Additional MIME headers
> 
> 
> Group,
> It might be prudent to place an extra, optional element into the 
> ebXMLHeader to hold the extra headers in the off chance
> they are useful (maybe not crucially useful).  A messaging server may 
> use the mime headers to set things like server version,
> time when the messaging layer accepted the message and other such minor 
> vendor enhancements.
> 
> Example:
> 
> Server: FooCom_ebXML_SRV/1.1.2
> M-Receipt_Time: 20011222T230333.12
> 
> would be...
> <ebXMLHeader>
> ....
> <MIMEExtraInfo>
>     <Server>FooCom_ebXML_SRV/1.1.2</Server>
>     <M-Receipt_Time>20011222T230333.12</M-Receipt_Time>
> </MIMEExtraInfo>
> 
> ....
> </ebXMLHeader>
> 
> Of course, the server could just read the extra mime headers itself and 
> do something with it, but having them in
> the header would cut down overhead for those who want this data.
> 
> Cheers,
> 
> Matt
> 
> Burdett, David wrote:
> 
>> Folks-
>> 
>> What do you think the behavior of a MSH should be if it receives a message
>> with additional MIME headers that are not specified in the ebXML specs.
>> Possible actions are:
>> 1. Ingore them, or
>> 2. Report an error.
>> 
>> Thoughts?
>> 
>> DAvid
>> 
>> Product Management, Commerce One
>> 4400 Rosewood Drive, Pleasanton, CA 94588, USA
>> Tel: +1 (925) 520 4422 (also voicemail); Pager: +1 (888) 936 9599 
>> mailto:david.burdett@commerceone.com; Web: http://www.commerceone.com
>> 
>> 
>> 




[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