RE: minutes 21-Dec-2000 tr&p con-call

["Burdett, David" <david.burdett@commerceone.com>]

I think that we should include sequence number in the routing header with
the following semantics:
1. The sequence number MUST be used if delivery of payload data to the end
application by the MSH must be in a specific sequence
2. The sequence number MAY be used to identify missing messages, but does
not remove the need for using MessageIds and RefToMessageId to identify that
a message has been received and for duplicate filtering.

David



-----Original Message-----
From: SHIMAMURA Masayoshi [mailto:shima.masa@jp.fujitsu.com]
Sent: Wednesday, December 27, 2000 2:42 AM
To: ebXML Transport (E-mail)
Cc: IWASA Kazunori; Jacques Durand
Subject: Re: minutes 21-Dec-2000 tr&p con-call


TRP Members, 

Here is my comment on the issue about SequenceNumber in the
previous teleconference minutes.

On Thu, 21 Dec 2000 12:51:13 -0500
Christopher Ferris <chris.ferris@east.sun.com> wrote:
...
> Issue 17
> Title - Sequence number
> Detail - 7.10 SequenceNumber as defined adds little or no value over the
> MessageID element required in MessageData.  Recommend removing this
section
> and the corresponding references to SequenceNumber in later  examples, the
> DTD and the schema.

The SequenceNumber has two kind of functions:

(1) Guarantee of Message Order
(2) Effective Duplication Check

The MessageID element in MessageData can not realize the two functions
above. Especially, there is no way to guarantee Message Order except for
using SequenceNumber. Because current MS specification has not the
blocking restriction. The Sender can send some messages without waiting
for acknowledgement message. Thus when a communication error and retry
sequence occurs, sent messages will reach the Receiver in invalid order.
To correct the invalid order in the Receiver, the SequenceNumber must be
included in each message.

> If this section remains, must define the exact content of the
SequenceNumber
> element when the numeric value is greater than 999.  Is the next value
> "1000" or "1,000"?  Is the text for the maximum value  "999999999" or
> "999,999,999" or are both allowed (and equivalent)?  Side note: Numeric
> formats vary by locale and a comma is not always the thousands

Good comment. I revise description of the SequenceNumber element to
clear this point.

> If this section remains, "long time" should be defined.  

I already removed the term "long time" from the RM spec and added
notification function of reset of SequenceNumber to the RM spec. See
following materials:

- Page 14 in the presentation material
  <http://lists.ebxml.org/archives/ebxml-transport/200011/pdf00003.pdf>
- Page 3 and 4 in latest RM spec v0-088
  <http://lists.ebxml.org/archives/ebxml-transport/200011/pdf00006.pdf> 

Both materials were posted to this mailing list on November and
distributed in previous TRP Meeting in Tokyo.

>                                                          At least, refer
to
> a TPA which makes this concrete for a specific trading relationship or
> mention later text on this subject (if any).
> 
> Proposal - sequenceNumber element is defined as type int
> in xsd, 

Good idea. The MS spec v0.9a defined SequenceNumber element as type int
in xsd in schema. Thank you, David.

>         members are in general agreement that should be adequate
> to address the typing issue. As to efficacy of SequenceNumber...
> defer/table discussion/resolution of meaningfulness
> of sequence number element to Jan 4th.
> Resolution - vote Jan 4th, incorporate changes into spec during
> Jan f2f

To realize (1)Guarantee of Message Order and (2)Effective Duplication
Check, the SequenceNumber is obviously needed. For the purpose (2), the
SequenceNumber was approved by the TRP Team and then added to MS spec
v0.8. For the purpose (1), Sliding Window with SequenceNumber in latest
RM spec was approved by the TRP Team in previous TRP meeting in Tokyo
(see the schedule
<http://lists.ebxml.org/archives/ebxml-transport/200011/pdf00005.pdf>
created in the meeting). Thus I believe we does not need more vote.
Please merge latest RM spec (v0-088) into the MS spec v0.9a.


History:

- in September, several TRP members strongly requested to remove the
  blocking restriction in mailing list and teleconference so that the
  Sender can send some messages without waiting for acknowledgement
  message.

- as the result of discussion, the TRP Term decided to remove the
  blocking restriction in teleconference on 5th October
    See:
    <http://lists.ebxml.org/archives/ebxml-transport/200010/msg00036.html>

- however removal of the blocking restriction caused two
  problems
   (1) Message order is not guaranteed
   (2) The Receiver can't know required buffer size previously

- So Fujitsu proposed Sliding Window with SequeceNumber to resolve the
  problems in this mailing list and the TRP meeting in Tokyo on November
    See:
    <http://lists.ebxml.org/archives/ebxml-transport/200010/msg00171.html>
    <http://lists.ebxml.org/archives/ebxml-transport/200011/msg00017.html> 
  
- In the TRP meeting in Tokyo, Fujitsu's proposal was approved. The TRP
  Team decided to merge latest RM spec (v0-084) including Sliding Window
  with SequenceNumber into MS spec
    See:
    <http://lists.ebxml.org/archives/ebxml-transport/200011/pdf00005.pdf>

- Fujitsu modified and posted revised RM spec (v0-088) including Sliding
  Window with SequenceNumber on 14th November to include the result of
  the discussion in the TRP meeting in Tokyo for integration with MS
  spec.
    See:
    <http://lists.ebxml.org/archives/ebxml-transport/200011/msg00062.html>


Regards, 

--
SHIMAMURA Masayoshi <shima.masa@jp.fujitsu.com>
TEL:+81-45-476-4590(ext.7128-4241)  FAX:+81-45-476-4726(ext.7128-6783)
Planning Dep., Strategic Planning Div., Software Group, FUJITSU LIMITED