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: TRP Messaging Service Specification


we are going to leave it with the tech writers, ralph, martha ian for the time being. ralph has control of it through the comment period....
-----Original Message-----
From: Dick Brooks [mailto:dick@8760.com]
Sent: Monday, August 14, 2000 9:39 AM
To: richard drummond; ebxml-transport@lists.ebxml.org
Cc: Dick Brooks
Subject: RE: TRP Messaging Service Specification

I sent these comments to the list on Sunday, 8/13, but they never appeared, so here we go again....
 
I'm not sure, but I think David and I are responsible for making documentation changes from this point forward, if so I'll be happy to make the changes listed here.
 
Rik, is document change control back in the hands of the editors now?
 
 
First, kudos to the team that reworked the two specs into one cohesive document, excellent work. I've found just a few minor corrections:
 
Line 198, replace "multi-part" with "multipart"
 
Line 200, replace "four" with "two"
 
Line 202, replace "4" with "2"
 
Line 213, remove "version=0.1" from the example.
 
Line 221, insert a ";" before boundary
 
Line 221 remove the spaces before and after "application/vnd.eb+xml"
 
Add the following to section 2.4:
  "The header body part MUST occur as the first (a.k.a. root) body part in an ebXML message.
 
In section 2.4.2 replace lines 243, 244 which reads,
   "The Content-Length header is a decimal value used to identify the total number of OCTETS contained in all constituent message body parts, including body part boundaries.  Example:"
 
WITH
 
"The Content-Length header is a decimal value used to identify the total number of OCTETS contained in the ebXML header document (excluding body part boundaries).   Example:"
 
Line 254, replace "0.1" with "1.0"
 
Line 256, replace "iso-8859-1" with "UTF-8"
 
Line 259 remove the spaces between "charset" and "=" and “UTF-8”
 
 
Lines 200/301 replace
   "The Content-ID MIME header identifies this instance of an ebXML is used to uniquely identify an instance of an ebXML message payload body part. "
 
WITH
 
 "The Content-ID MIME header is used to uniquely identify an instance of an ebXML message payload body part."
 
Section 2.5.4, we need to specify that encryption is also allowed.
 
Also in section 2.5.4, we should specify that implementers SHOULD indicate the character set used within the payload when the content-type permits the inclusion of the "charset" parameter.
 
Line 311, replace "header" with "payload".
 
Line 313, replace "application/vnd.eb+xml" with "application/xml"
 
Replace lines 351/352 of the example with "Content-Type: multipart/related; type="application/vnd.eb+xml"; boundary="8760"
 
Line 370 replace "he" with "the"
 
General comments:
 
It seems redundant to have a version parameter in the Content-type header of the ebXML header and a version attribute in the ebXMLHeader root element of the ebXML header document. I suggest we place version in one or the other, but not both.
 
I really like the enhancements to DocumentId, very nice indeed.....
 
We need to provide a complete list of possible values for the "context" attribute within the PartyId element. I believe ISO has a specification for this, William K, can you provide pointers to that document (thanks).
 
I believe the MessageData element should also include a "DeliveryDeadline" element which indicates the last instance in time a message can be delivered to an intended recipient and a "ResponseDeadline" element to tell the receiver how long they have to send an acknowledgement. I believe it would also be valuable to indicate how an  acknowledgement should be delivered with an OPTIONAL "AcknowledgeTo" element (e.g. <AcknowledgeTo>mailto:ebXMLacks@8760.com</AcknowledgeTo> or <AcknowledgeTo>http://ecommerce.8760.com/servlets/ebXMLackHandler</AcknowledgeTo> or <AcknowledgeTo>synchronous</AcknowledgeTo>). The example using "synchronous" indicates that an acknowledgement should be sent on the same session that was used to send the ebXML message. If the AcknowledgeTo element is not present then whatever was specified in the TPA determines how acknowledgements are delivered.
 
 

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: richard drummond [mailto:rvd2@worldnet.att.net]
Sent: Monday, August 14, 2000 9:16 AM
To: ebxml-transport@lists.ebxml.org
Subject: RE: TRP Messaging Service Specification

we plan to vote to release to the wider ebxml community  for review on this thursday's conference call. our intent is to get it approved in tokyo  please read it and be prepared to discuss it on thursday.    regards, rik
-----Original Message-----
From: Ralph Berwanger [mailto:rab7067@earthlink.net]
Sent: Thursday, August 10, 2000 8:36 PM
To: ebxml-transport@lists.ebxml.org
Subject: TRP Messaging Service Specification

The attached document represents the work of the TRP group during the San Jose meeting and is forward for your review and comment.   Ralph Berwanger has agreed to capture all comments related to the document and will post them back to the TRP chair for distribution and action.

            A list of former comments and the action taken on those comments will forward under separate message later this week.

 

Ralph Berwanger

bTrade.com

(703) 530-0286

 



[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