Re: [wsrm] Proposed resolution for Rel 50

Hi Jacques,

 See some more comments.

Jacques Durand wrote:
 

Sunil:<?xml:namespace
prefix = o ns = "urn:schemas-microsoft-com:office:office" />

 

 

My
next action will be to revise Rel52, 57 based on this.

Some
more inline comments, though.

-----Original
Message-----

From:
Sunil Kunisetty [mailto:]

Sent:
Thursday, November 13, 2003 9:06 AM

To: Jacques
Durand

Cc: Iwasa;


Subject:
Re: [wsrm] Proposed resolution for Rel 50

 

 Hi
Jacques,

Jacques
Durand wrote:

Sunil:

I
have been thinking about the two proposed semantics for ExpiryTime, and
I do not see them as different as I thought initially.

That
was my point all along.

-
Either assume that it was application's responsibility and leave all the
times altogether

 
[I disagree with this, but stating it]

-
If we are doing Expiry checks, might as well do it when the realm of RMP
ends, i.e.,

 
when RMP makes the message available to the user. I hardly see any gain
in doing any

 
checks at the time of receiving.

[Jacques
Durand] from our implementation perspective (Fujitsu), we certainly see
a significant benefit in checking ExpiryTime at reception time,  as
we don't want to process further and do duplicate checks on messages that
we know up-front will never make it to the app. (So two checks will be
in order for us.)

It
will be definitely simpler, but to me it's a broken semantics... I don't
think one

additional
check is a burden.

 

But
there is more to fix even if we keep previous semantics: the "processing
model" we had outlined in last f-2-f Wednesday minutes, 6.2 Rel50) does
not hold anymore, w/r to Acks: If you don't require an up-front expiration
check, that means you will Ack positively an expired message, then later
send an Error for non-delivery to app due to expiration. 

 

Why
do we need to do that? We can use the same processing logic on the Sender
side too

and
identify such expired messages. I think we need to define the Processing
Model for Sender.

 

 

 

 

 

I
must admit yours is also the original one as currently worded in the spec.Although
I

Yes.
I'm not proposing anything new. Just want the current semantics to stand.

believe
the current semantics adds unnecessary checks and cases, and pretends to
an "application

Only
thing would be one additional "timestamp" stamp. This is a drop in the
ocean especially we

will
have to do many other checks for DE and trying to compute the max(ExpiryTimes)
"if"

neither
of the other parameters are available.

As
per the rules on the Sender, the same rules apply irrespective of it. For
ex., we cannot

assume
even otherwise that Ack means that the Receiver will always make the Msg.
available

to
the User. Because, after sending an Ack. for an out-of-order Msg., the
Group may have

terminated/removed
before it was every made available. So the Sender still has to obey the

rules
I mentioned in one of my previous rules. Essentially, the rules on the
Receiver for

the
group termination/removal applies to the Sender also. So I don't see any
additional

complexities
on the rules by saying that ExpiryTime semantics are the current TTL semantics.

[Jacques
Durand] If we keep it as is, one
more rule now for not delivering an Acked message, is that if it expires.
Agree group termination does not seem to be affected much one way or the
other.

(This
was the point I was making at the F2F.. which no one seems to caring :))

 

 

 

 

 

semantics"
flavor that is no substitute tobusiness-level timeout handling in the application
in my view, I can settle with this.

The
inconsistencies you still see in my proposal (your scenario case), however,
I contend only occur if you authorize the Sender to bump-up ExpiryTime
whenresending a message, which I still strongly oppose (and the current
spec is on myside on this, see 3.1.4 in V0.7). Indeed, I believe this ExpiryTime
update does not have any semantic ground, and introduces all sorts of complications,
from dup elimination to group expiration management.

I
believe I can clarify the semantics very clearly without any confusion.
However as I said in my

previous
mail, this is not a big deal for us and we can still certainly live with
the fact that ExpiryTimes

cannot
change.

[Jacques
Durand] I’d prefer to keep ExpiryTime immutable, once it is set… (so
all in all, we keep as much of the current spec as we can :)

Ok...No
problem.

 

 

I
thought of another discrepancy with this model, but I don't seem to recollect
right now.

 

 

 

 

 

 

The
ExpiryTime as defined currently seems to now reflect an app to app contract,
and has no reason to see its value upgraded for a given message, I believe,
due to underlying transport/RMP mishaps.

Would
you agree with this analysis?

Yes,
but that will have a bearing on RMP implementation for persistence and
DE.

[Jacques
Durand] And I think this bearing is positive, but let us postpone
this debate :)

Sure.
Indeed it is a positive one.

 

 -Sunil