Re: [ebxml-msg] Comments on the 1.09 draft

Jacques:

 

Thank you for your feedback. My responses are 
inline.

 

-Arvola

  
-----Original Message-----
From: 
  Jacques Durand <>
To: 'Arvola 
  Chan' <>;  <>
Date: 
  Monday, November 26, 2001 6:50 PM
Subject: RE: [ebxml-msg] 
  Comments on the 1.09 draft

  
Arvola:

  
 

  
just a few 
  comments on your comments:

  
 

  

  
>Page: 
  10
>Has.

  
I guess the intent 
  was "MUST have" here.

  
<ac>I agree with 
  you.</ac>

  

  
>Page: 
  20
>I think this should be the 
  time by which a message is received by the To Party MSH. The receiving 
  application may actually process the message at a time greater 
  than TimeToLive.

  
I agree with this. 
  But if so, the relationship between PersistDuration and TimeToLive need be 
  clarified (if still applicable): they seem to address time windows that are quite 
  independent (do not overlap 
  at all). In that case, there is no clear reason anymore to require 
  PersistDuration+timestamp to be greater than TimeToLive (in 
  7.4.6)

  
<ac>The reason for requiring timestamp + 
  PersistDuration to be greater than TimeToLive in section 7.4.6 is to ensure 
  that duplicate messages are properly detected. Once the received message has 
  stayed in the persistent store beyond the PersistDuration, it is liable to be 
  garbage collected. Therefore, it would be problematic if TimeToLive is set to 
  an arbitrary time value that does not bear a relationship with timestamp and 
  PersistDuration</ac>

  
>Page: 
  33
>I suggest striking out this 
  paragraph. What alternative to a persistent store can be used for duplicate 
  detection?

  
in case sequence 
  numbers are used, very fast (and space efficient) duplicate elimination can be 
  done using sliding windows, that does not rely on storage of messages and 
  their IDs. Just a possibility.

  
<ac>I agree it is possible 
  to remember sequence numbers instead of message IDs and/or message contents to 
  facilitate duplicate elimination. Still, it is necessary to keep track of the 
  the received sequence numbers in some form of a persistent store. Otherwise, 
  duplicates may not be detected after a crash 
  recovery.</ac>

  
>Page: 
  48
>I think all messages sent with the same 
  ConversationId should have the same value for duplicateElimination 
  and messageOrderSemantics. You don't want to allow messages 1, 3, 5 to 
  have order Guaranteed and messages 2, 4 to have order 
NotGuaranteed.

  
Although I believe what you suggest is the general 
  use case, I do not see a major technical issue here, because messages that hav 
  NotGuaranteed, will simply NOT report any sequence number. So even if some 
  messages in a conversation are left out of the order enforcement (an app could 
  decide that order be relaxed for some lesser messages, e.g. some receipts), 
  then all order-guaranteed messages would still have contiguous numbers. Maybe 
  that is a CPA decision.

  
<ac>In section 10.1.2, it is stated that (a) 
  the SequenceNumber is incremented for every message sent within a 
  conversation; (b) if duplicateElimination is set to true then 
  messageOrderSemantics may be set to Guaranteed or NotGuaranteed; (c) a 
  SequenceNumber may be present even if messageOrderSemantics is NotGuaranteed 
  provided that duplicateElimination is true. Now consider the scenario where 
  messages with SequenceNumbers 1, 3, and 5 require message order guarantee 
  while messages with SequenceNumbers 2 and 4 require no message order 
  guarantee. One correct delivery order is 1, 2, 4, 3, 5. However, the MSH will 
  have to persistently remember more information to enable such out of order 
  delivery. Instead of just remembering the highest SequenceNumber message 
  with message order guarantee requirement that has been delivered, it will be 
  necessary to remember also the SequenceNumbers of messages that do not have 
  message order guarantee requirement and have been delivered ahead of the ones 
  which have message order guarantee requirement. Point (a) above is the 
  problematic requirement. Even if a message does not require message order 
  guarantee, it still must be assigned a unique SequenceNumber within the 
  conversation.</ac>

  
Jacques Durand

  
Fujitsu Software