Subject: RE: [Sip] Subscribe/Notify and Refer/Notify

From: Adam Roach <[email-masked]>
Date: Mon, 21 Oct 2002 15:46:58 -0500

> i
> suggest that we announce the sub/not rfc obsolete and replace 
> it with a
> new, simpler one.

Are you volunteering to take my albatross? That's too kind.
It'd be great if you could make the -00 deadline for Atlanta.
Thanks!

/a
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: [email-masked]
Date: Tue, 22 Oct 2002 08:48:53 +0300

> It'd be great if you could make the -00 deadline for Atlanta.

it won't be too much effort to make the next version of 3265 compliant
with 3261.  i can do that after the working group has made an
announcement that the current version will be changed and that there is
no requirement that the next version will be backwards compatible with
the current one.

i can't understand how 3265 got through the iesg review process.  i
would think that the first thing they require is compatibility with the
newly released sip rfc.

-- juha

---

From: Robert Sparks <[email-masked]>
Date: 22 Oct 2002 10:52:17 -0500

Actually, there was a great deal of effort to _ensure_ that
3265 and 3261 were compatible - I remember several coordinated
rewrite sessions to make sure they said the same things. 

Having participated in the creation of both documents (having
long arguments with the other active participants over the 
intricacies of nested dialogs and when dialog life-cycles), and
having implemented systems that deal with all of them, I have to
say that I _strongly_ disagree with your statement that 3265 is wrong
and should be abandoned. 

I _will_ agree that the edge cases created by the consensus on how
to deal with the differences between and INVITE transaction and a
non-INVITE transaction can be more clearly documented. Everyone can help
with that - all that's required is understanding the problem and
providing text.

As far as I can tell, the behavior that's giving you the most
trouble right now is with establishing dialogs based on a NOTIFY
that arrives before a SUBSCRIBE transaction completes. The parallels
to look for in the INVITE mechanics are with early dialogs. Think
of SUB->200->NOT like INV->18x->200. If a 18x gets misordered and
is delivered after a 200, it's not going to affect any dialog state.

RjS