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

[Doug Bunting <Doug@ariba.com>]

Since I entered the original comment, it's about time for me to weigh in on
this topic.

We have a well-proven mechanism for duplicate detection (message
identifiers).  Providing a second mechanism for the same purpose simply
confuses the specification and will result in solutions that can't
interoperate.  We should not mention use of sequence numbers for duplicate
detection except (possibly) in non-normative material.  I recommend that we
don't mention this confusion at all.

The history of the sequence number issue seems long and involved.  However,
I haven't heard us address one primary underlying issue: In-order delivery
of messages is not a requirement of the TRP.  The need to deliver portions
of a transaction in a particular order generally revolves around the
ordering of documents within a specific conversation.  That is, it happens
at a higher level than the point-to-point or end-to-end From / To
relationship (which may include many simultaneous conversations).  Ordering
of all messages within those relationships is unnecessary and runs counter
to our stated requirement to keep it simple.  If these semantics should be
provided by the TRP framework, we should provide them on a per-conversation
basis.

Assuming we decide to satisfy this new TRP requirement, David's approach
would work as long as messages with sequence numbers do not prevent delivery
of other reliable messages between the same two parties.  I'd recommend
going one step further and scope the sequence number to the conversation
identifier, making the level for its use explicit.  That is, the sequence
number would be required to be unique within the conversation and each
simultaneous conversation would (implicitly?) have a separate sliding window
to guarantee in-order delivery to the To party.  CPA properties such as
maximum number of simultaneous conversations would then be required.

Side question(s): Should the conversation identifier (ConversationId) be
scoped within the CPA identifier (CPAId)?  Similarly, should the Action be
scoped to the Service which is (in turn) scoped to the To information?

Lower-level issues with the current sequence number semantics: The
wraparound algorithm does not guarantee delivery of the last few messages
before starting at 0.  The receiver has no way to learn what the highest
number was prior to wrapping around.  And, how do these semantics handle
messages that fail due to an incorrect ebXML Header document?  Should a
replacement message that corrects the error reuse the previous sequence
number?

thanx,
	doug

-----Original Message-----
From: Burdett, David [mailto:david.burdett@commerceone.com]
Sent: December 27, 2000 09:26
To: 'SHIMAMURA Masayoshi'; ebXML Transport (E-mail)
Cc: IWASA Kazunori; Jacques Durand
Subject: RE: minutes 21-Dec-2000 tr&p con-call

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