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

From: [email-masked]
Date: Mon, 21 Oct 2002 08:56:36 +0300

Kaul, Amit writes:

 > I would prefer author of this RFC to document Subscription/dialog (RFC3265)
 > state machines 
 > in detail and explain the aberration (if any) with 3261 dialog state
 > machines in the
 > next update.

this is the minimum what the authors can do, but do we really need for
sub/not a dialog model that is not compatible with 3261?  my reply is no
and therefore i suggest that we redo 3265 in a way that is consistent
with 3261.

-- juha

_______________________________________________
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: "Kaul, Amit" <[email-masked]>
Date: Sun, 20 Oct 2002 22:34:59 -0700

I do agree that there are quite a few "grey areas" in dialog/subscription 
state machines which the Event Package RFC3265 is not clear or is confusing
to the reader.

Juha - your suggestion of making sub/not rfc obsolete does sound kind of 
radical and we don't need to pull the trigger like this. There would be lot
of issues 
with this approach.

I would prefer author of this RFC to document Subscription/dialog (RFC3265)
state machines 
in detail and explain the aberration (if any) with 3261 dialog state
machines in the
next update. It would definitely be very helpful because right now, these
state machines 
do seem to be conflicting at times.

However, to start with, can we have the doubts (in my previous email)
cleared by the 
author in this list ?

thanks
__amit

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Sunday, October 20, 2002 11:38 AM
> To: Kaul, Amit
> Cc: [email-masked]'
> Subject: [Sip] Subscribe/Notify and Refer/Notify
> 
> 
> Kaul, Amit writes:
> 
>  > i) As per the Subsc/Notify draft, Subscriber should be 
> able to receive
>  >    NOTIFY before receiving 2xx. Also, it shall create a new
>  > subscription/dialog
> 
> i also complained about this a couple of weeks ago to the 
> author of the
> sub/not rfc 3265.  sub/not rfc is not following the dialog 
> model of RFC
> 3261, which is very confusing.  at minimum, the sub/not rfc 
> should have
> had its own state diagrams in order to make the mess a bit clearer.  i
> suggest that we announce the sub/not rfc obsolete and replace 
> it with a
> new, simpler one.
> 
> -- juha
>