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

["Kaul, Amit" <amit.kaul@intel.com>]

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: jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi]
> Sent: Sunday, October 20, 2002 11:38 AM
> To: Kaul, Amit
> Cc: 'sip@ietf.org'
> 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
> 
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip