Subject: RE: [Simple] 200 vs. 202

From: "Brian Stucker" <[email-masked]>
Date: Mon, 8 Oct 2001 14:20:03 -0500

Forking of SUBSCRIBEs in a general sense is very useful. I agree. What
I'm concerned with is that the event state that is being created is being
created according to the needs of the application. Some applications may not
be very strict about how this is done.

With presence, I think we need to be more strict about it than the current 
draft suggests.

Section 5.1.7.2 of your events -00 draft says that the NOTIFY after a 202
acts as notification that the subscription has finally been processed. I'm
all
for that model. What seems to make no sense is sending a NOTIFY that doesn't
really mean anything, then sending another NOTIFY later on that signifies
that
the subscription has finally been processed.

According to the revision of your draft that I have available to me, the 
meaningless NOTIFY after the 202 makes the 202 irrelevant. It's as good as
sending
a 200 in the first place in the general event framework.

Am I misreading 5.1.7.2?

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, October 08, 2001 2:12 PM
To: Stucker, Brian [NGB:B621:EXCH]; James Undery; Ngo, Dai (c); 'Moran
Tim (NET/Dallas)'; 'ext Paul Kyzivat'; Jonathan Rosenberg
Cc: simple
Subject: RE: [Simple] 200 vs. 202

Sorry; I haven't been following this closely (things have been
hellishly busy recently). This conversation, though, seems to
have taken a dangerous turn.

Remember that the behaviour of SUB/NOT is general, and not just
related to presence. And, in the general case, forking of SUBSCRIBEs
can be extremely useful.

However, without a three-way handshake, such forking becomes quite
messy and unpleasant to implement.

The immediate NOTIFY is the third message of this three-way handshake.
It can't be removed from the base SUB/NOT draft; by extension, the use
of SUB/NOT for presence needs to keep it.

/a

-----Original Message-----
From: Brian Stucker [mailto:[email-masked]]
Sent: Monday, October 08, 2001 1:54 PM
To: James Undery; Ngo, Dai (c); 'Moran Tim (NET/Dallas)'; 'ext Paul
Kyzivat';
Jonathan Rosenberg
Cc: simple
Subject: RE: [Simple] 200 vs. 202

Ok, as a compromise, since we all seem to feel that the NOTIFY after a 202
is
totally useless...
Can't we make the 202 act as an implied 'Offline' (or some other harmless,
and
meaningless indication)
NOTIFY within the context of how CPIM requirements work in a SIP network?
Gateway functions to other
protocols can generate whatever messages they want from this, but in the
context of what gets sent
around in a SIP network, the 202 acts as a NOTIFY itself.
Heck, you could even put dummy XML in the 202 message body if you really
wanted
(but I'd rather not).
Brian Stucker
-----Original Message-----
From: James Undery [mailto:[email-masked]]
Sent: Monday, October 08, 2001 5:12 AM
To: Ngo, Dai (c); 'Moran Tim (NET/Dallas)'; 'ext Paul Kyzivat'; Jonathan
Rosenberg
Cc: simple
Subject: RE: [Simple] 200 vs. 202

I'd like to agree with you too, unfortunately it's a CPIM requirement
as 2xx are successful responses. The SIMPLE charter requires CPIM
complience.
James
-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Ngo, Dai (c)
Sent: 05 October 2001 17:52
To: 'Moran Tim (NET/Dallas)'; 'ext Paul Kyzivat'; Jonathan Rosenberg
Cc: [email-masked]
Subject: RE: [Simple] 200 vs. 202

I agree that there is no need to send an immediate, empty NOTIFY after
a 202 was sent in the pending case.
-- Dai
-----Original Message-----
From: Moran Tim (NET/Dallas) [mailto:[email-masked]]
Sent: Friday, October 05, 2001 10:33 AM
To: 'ext Paul Kyzivat'; Jonathan Rosenberg
Cc: [email-masked]
Subject: RE: [Simple] 200 vs. 202
My comments are in line.
> -----Original Message-----
> From: ext Paul Kyzivat [mailto:[email-masked]]
> Sent: Friday, October 05, 2001 8:04 AM
> To: Jonathan Rosenberg
> Cc: Moran Tim (NET/Dallas); [email-masked]
> Subject: Re: [Simple] 200 vs. 202
>
>
Seems you are both saying the same thing. I seem to recall an earlier
dialogue where it was stated that non-Invite requests are treated
differently than Invites in that only one response in sent back to the
"Subscriber" in this case.  So it would appear that the PA (with proxy
capabilities) will wait some predetermined amount of time to collect
all of the responses (or until all are received whichever comes first)
and send back the best response. If the best is a 202, then does the
proxy wait for the Notify and send the 202+Notify or just the 202 and
the Notify later? I guess I don't see the need for a 202 indicating
pending followed immediately by another message (Notify with no real
status) which adds no value.

_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple