RE: [wsrm] SequenceNumber element

[Jacques Durand <JDurand@fsw.fujitsu.com>]

Title: RE: [wsrm] SequenceNumber element

Tom and all:

Overall I do agree with Scott's position, as he stated below.

But my issue was different (see second part of my email 9/8):

Since you ask me, here it is.
(BTW, I know I should have had this discussion at f-2-f . 
But I think we went too quickly on this "new" issue anyway, not even formally registered,
 almost closed as soon as it was raised, and I admit I missed it for whatever reason.
I like to have time to read things.)

And I'll be bold on this one (feeling rather strongly about it...) :

Using SequenceNumber = 0, or whatever state/value about this element, to signal the
"Ordering" requirement/agreement to a receiver, is nothing but an ugly hack.
I believe SequenceNumber should be nothing more than that: a number in a sequence,
and not be overloaded with semantics about what should/not be done with this number.

Consider this:
- For Guaranteed delivery we have a full, explicit header element (AckRequested)
to signal the feature.
- For duplicate elimination, we also have a full, explicit header element (DuplicateElimination)
to signal the feature.

Why is it that Ordering does not deserve that treatment? Why not simply have a message with an "OrderedDelivery" element when we start a group? (does not even need to be on each message!)

Semantic overloading of data is always dangerously restrictive and confusing, unless we are
desperate in saving a few bits of bandwidth, which could make sense if we were working
at the lowest and fairly closed layers of network protocols, but not at this level
where the protocol is still likely to evolve a lot, and needs clean design to start with.

I have stated in my email (9/8) an example of future use of sequence numbers,
decoupled from the Ordering feature, namely space-efficient and much faster duplicate
elimination algorithms (e.g. for small devices).
I am not putting this forward as the main reason for my request, but as an example
of what a restrictive specification will prevent implementers from doing, or
at the cost of breaking compatibility across versions.

Now that (groupId + seqnumbers) will assume the broader role of message Id,
I do not see any reason for restricting the way these elements are used when not
doing ordering. One should be allowed to use one-message groups, as well as
multi-message groups.
Why not keep the specification more open when it costs us nothing to do so ?

(sigh...)

Jacques

-----Original Message-----
From: Scott Werden [mailto:scottw@wrq.com]
Sent: Tuesday, September 16, 2003 5:46 PM
To: 'tom@coastin.com'
Cc: wsrm@lists.oasis-open.org
Subject: RE: [wsrm] SequenceNumber element

See below....
Scott

> -----Original Message-----
> From: Tom Rutt [mailto:tom@coastin.com]
> Sent: Tuesday, September 16, 2003 5:27 PM
> To: Scott Werden
> Cc: wsrm@lists.oasis-open.org
> Subject: Re: [wsrm] SequenceNumber element
>
>
> Scott Werden wrote:
>
> >I propose that SequenceNumber element be required, but the
> text say that it
> >will be ignored (or perhaps we can say it must be empty)
> except for when
> >message ordering is being used. It makes header processing a
> little cleaner
> >and certainly makes the schema more precise. Having a header element
> >required or disallowed depending on the presence of an element (the
> >DuplicateElimination element) in a different header block
> seems a little
> >strange to me.
> >
> It seems that Scott and Jacques were not present when we voted to
> simpify the semantics by
> making SequenceNumber conditional (and actually signalling)
> on the use
> of ordered delivery.

>
> The sequence Number is now the signal that ordered delivery is
> required.  The sequence status is now an attribute of the sequence
> number.  We took away the orderedDelivery element when we
> made Sequence
> number optional.
>
> If we were to entertain a new issue, the proposers would have
> to explain
> the semantics of using sequence numbers other than 0 when ordered
> delivery is not required.
>

I am not proposing new semantics at all. SequenceNumber is not used by any
feature other than Ordering, and this will stay the same. My proposal has
two benefits:
(1) SequenceNumber element will always be present, so the semantics of the
protocol will match the schema. Right now, the SequenceNumber is optional
from the perspective of the schema, but it really isn't optional - sometimes
it is REQUIRED. That sort of mismatch with the schema defeats the purpose of
schema.
(2) The elements which enable features (guaranteed delivery, ordering,
duplicate elimination) will all be located under the same header (the
Request header) rather than split.

> In my opinion, as chair, we should have another proposal basically
> agreeed on email discussions for replacement text before actually
> opening a new issue which overturns the resolution of a
> previous issue.
>
> What do you think scott and Jacques?
>
> Tom Rutt
>
> >
> >Scott
> >
> >
> > 
> >
> >>-----Original Message-----
> >>From: Sunil Kunisetty [mailto:Sunil.Kunisetty@oracle.com]
> >>Sent: Tuesday, September 16, 2003 12:00 PM
> >>To: wsrm@lists.oasis-open.org
> >>Subject: [wsrm] [Rel-87]schema for Headers
> >>
> >>
> >>
> >> All -
> >>
> >> Before Scott & I work on the Schema for the RM Headers, we
> >>would like to
> >> know that this is what we have decided so far. Please
> >>correct us if we missed
> >> something or didn't capture any resolution properly.
> >>
> >> -Sunil
> >>
> >>--------------------------------------------------------------
> >>-------------------------------
> >>MessageHeader
> >>     - GroupId - "mid URI" scheme from RFC2392 - Mandatory
> >>     - SequenceNo - unsignedLong - Long
> >>       --   status attribute - xsd:string -  Begin, Continue, End
> >>     - TimeStamp  - UTC  - Mandtory
> >>     - ExpiryTime  - UTC - Mandatory
> >>     - ReplyPattern -  xsd:string  - Optional
> >>       - replyTo attribute - uri  - Optional
> >>
> >>Request
> >>     - AckRequested  - Optional
> >>     - DuplicateElimination  - Optional
> >>
> >>Response
> >>   RefToGroupId - "mid URI" scheme  from RFC2392 - Mandatory
> >>   RefToSequenceNo - unsignedLong - Optional
> >>
> >>Fault - QName - Mandatory
> >>
> >>Namespace:
> >>
> >>  urn:oasis:names:tc:wsrm:schema:1.1:SOAP1.1
> >>   urn:oasis:names:tc:wsrm:schema:1.1:SOAP1.2
> >>
> >>URL Location:
> >>
> >>   
> >>
> >  http://www.oasis-open.org/committees/wsrm/schema/1.1/SOAP1.1
> >  http://www.oasis-open.org/committees/wsrm/schema/1.1/SOAP1.2
> >
> >
> >-------------------------------------------------------------
> ---------------
> >---------------------
> >
> >
> >To unsubscribe from this mailing list (and be removed from
> the roster of the
> >OASIS TC), go to
> >http://www.oasis-open.org/apps/org/workgroup/wsrm/members/lea
> ve_workgroup.ph
> >p.
> >
> >To unsubscribe from this mailing list (and be removed from
> the roster of the OASIS TC), go to
> http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leav
e_workgroup.php.
>
> 
>

--
----------------------------------------------------
Tom Rutt                email: tom@coastin.com; trutt@fsw.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133

To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php.