Re: [ebxml-msg] Messaging Spec v1.092

MHonArc v2.5.2 -->

ebxml-msg message

[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [Elist Home]

Subject: Re: [ebxml-msg] Messaging Spec v1.092

From: Arvola Chan <>

To: David Fischer <>,ebXML Msg <>

Date: Wed, 02 Jan 2002 12:33:40 -0800

David:

 

Here are some belated editorial comments. I hope 
they can be fixed without too much trouble:

  
Line 18: Don't we 
  have to wait for a calendar quarter boundary before the spec can be presented 
  to the OASIS membership for consideration as an OASIS 
  specification?

  
Line 311: The reference to [ebREQ] cannot be found 
  among the Non-Normative References (see line 2761).

  
LIne 896: The permissible values for 
  duplicateElimination in the CPA are perMessage, never, and always. Therefore, 
  replace "set to false" with "set to never" on line 897. Note: this is with 
  respect to the 1.1 CPP/A spec. Do we need to add a reference to the 
  forthcoming 1.1 CPP/A spec?

  
Line 1384: The schema says that this is a REQUIRED 
  attribute. It must be set to the value "http://schemas.xmlsoap.org/soap/actor/next". 
  It is somewhat different from being declared as a FIXED attribute in the 
  schema. Line 1384 seems to suggest the latter. Excerpts from the SOAP 1.1 
  spec: "The SOAP actor global attribute can be used to indicate the 
  recipient of a header element. The value of the SOAP actor attribute is a URI. 
  The special URI "http://schemas.xmlsoap.org/soap/actor/next" 
  indicates that the header element is intended for the very first SOAP 
  application that processes the message. This is similar to the hop-by-hop 
  scope model represented by the Connection header field in HTTP. Omitting the 
  SOAP actor attribute indicates that the recipient is the ultimate destination 
  of the SOAP message. This attribute MUST appear in the SOAP message instance 
  in order to be effective (see section 3 and 4.2.1)."

  
Line 1389: CPP/A attribute names start with a 
  lower case. SyncReplyMode should be globally repaced with 
  syncReplyMode.

  
Line 1412: I like to point out that a SyncReply 
  element is not compatible with an AckRequested element that is targeted at the 
  next MSH.

  
Line 1491: I think an errorCode of Inconsistent 
  should be accompanied by a severity of Error rather than warning. Didn't we 
  decide that inconsistency between the CPA and the message header must always 
  result in an error being returned?

  
1502: The statement "An Error Message MUST NOT 
  contain an AckRequested element" is not correct and should be struck out. 
  Please see http://lists.oasis-open.org/archives/ebxml-msg/200111/msg00231.html (Resolution 
  of issues in the issues database), IssueId 73, and/or http://lists.oasis-open.org/archives/ebxml-msg/200111/doc00004.doc, 
  Issue 73.

  
Line 1557: I think it is inconsistent to ask for a 
  signed Acknowledgment if the original message is not signed.

  
Line 1579: It will be useful to point out that 
  parameters that are not found in the message header are to be obtained from 
  the CPA.

  
Line 1584: Replace "value of duplicateElimination 
  in the CPA is false" with "value of duplicateElimination in the CPA is 
  never".

  
Line 1591: I think it may be problematical for the 
  recipient to do duplicate elimination when no DuplicateElimination element is 
  present. What happens if SyncReply is present and AckRequested is not present. 
  If the incoming message is not passed on to the application, should any reply 
  be returned to the sender?

  
Line 1602: It will be useful to point out that the 
  Retries parameter comes from the CPA.

  
Line 1605: It will be useful to point out that the 
  RetryInterval parameter comes from the CPA.

  
Line 1616: It will be useful to point out that the 
  PersistDuration parameter comes from the CPA.

  
Line 1625: As mentioned earlier, SyncReplyMode 
  should be spelt as syncReplyMode. Also, I just noticed the following statement 
  in the 1.0 CPP/A spec. "If the delivery channel identifies a transport 
  protocol that has no synchronous capabilities (such as SMTP) and the Characteristics element has a syncReplyMode attribute with a value 
  other than "none", a response SHALL contain the same content as if the 
  transport protocol did support synchronous responses." which contradicts the 
  statement on line 1625: "The SyncReplyMode parameter from the CPA is used only 
  if the data communications protocol is synchronous (e.g. 
  HTTP)."

  
Line 1646: The sentence is missing a closing 
  period.

  
Line 1678: This seems to contradict the statement 
  on line 1589.

  
Line 1684: There is an invalid reference to 
  section 0.

  
Line 1733 and line 1738: These two 
  bullet points assume that syncReplyMode in the CPA is not used with an 
  asynchronous communication channel. This is in conflict with the 1.0 
  CPP/A spec statement quoted in item 15 above. I think this is a minor 
  technical issue that may require some discussion.

  
Line 1772: Since one MSH is not allowed to place 
  more than one AckRequested element in the SOAP Header (according to line 
  1469), this matrix represents what an intermediary MSH or the To Party MSH may 
  receive, not what the From Party MSH may send.

  
Line 2098: I think the statement "The Receiving 
  MSH MUST NOT send an Acknowledgment Message until the message has been 
  delivered to the Next MSH" is not correct.  This does not correspond to 
  store and forward behavior (see line 2043). The Receiving MSH cannot know for 
  sure that the message has been delivered to the Next MSH until it receives an 
  Acknowledgment from the latter. The prescribed behavior defeats the purpose of 
  intermediate Acknowledgments.

  
Line 2619: This comment seems unnecessary. Would 
  it constitute an unrecognized MIME header?

Regards,

-Arvola