Subject: RE: [Sipping] Immediate NOTIFIES change in sip-events-01

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Mon, 5 Nov 2001 14:22:21 -0800

Thanks for the response Adam.

Okay, I can see why a three-way handshake is required for the forking case.
Perhaps it would be better if section 8.2 mentioned forking as a rationale
for sending an immediate NOTIFY.

> Given that we fork, the NOTIFY actually serves some portion
> of the purpose that the 202 does. That's why Robert's arguments
> aren't necessarily valid.

I lost you there. Why is 202 needed (instead of simple SUBSCRIBE 200 OK)?
The NOTIFY will always be sent immediately, so surely 202 is no longer
needed for SUBSCRIBE.

> There's a further advantage with the immediate notifies: you can
> be assured that you will know how many SUB/NOT dialogs have been
> established within a small period of time (less than a minute,
> at least) by counting the number of NOTIFY messages you get.
> Once again, this is a consideration driven by forking.

Okay. That's a subtle point but I see it. 

However, with the current arrangement it is actually making it more
difficult to determine how many _real_ subscriptions you have (due to the
fact that the initial NOTIFY may be a dummy event). This means that in order
to know whether or not a _REAL_ subscription has yet been created (i.e.
successfully authorized, etc, etc) is now largely Event package specific - a
subscriber must now differentiate a "dummy" NOTIFY from a "real" NOTIFY.

In my mind we MUST have a non-Event-specific mechanism to differentiate a
dummy initial NOTIFY (i.e., used just for a three-way handshake) from a
NOTIFY carrying actual initial state information (which may also be the
initial NOTIFY). This doesn't have to be anything complicated but in my mind
it must be part of the SIP event specification.

For instance, if the NOTIFY does not contain a message body then it can be
considered that the dialog has been created but the subscription is still
"pending" (i.e., unauthorized or a number of other reasons). On the other
hand, I think it would be better to have some explicit reason code rather
than relying on the lack of a event message body. We do need something
though - rather than making each Event package come up with its own scheme
to communicate when a subscription actually becomes useful and/or why it is
still pending.

Cheers,

Robert.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: 05 November 2001 19:57
> To: 'Sriram Parameswar'; [email-masked]; [email-masked];
> [email-masked]
> Subject: RE: [Sipping] Immediate NOTIFIES change in sip-events-01
> 
> 
> Sean is absolutely correct: the three-way handshake becomes
> crucial in the forked-SUBSCRIBE case. Everyone needs to carefully
> consider forking when they are discussing this issue. It would be
> extremely straightforward (and exactly like Sriram descibed)
> if forking didn't exist.
> 
> But, we fork. It's just part of the protocol.
> 
> Given that we fork, the NOTIFY actually serves some portion
> of the purpose that the 202 does. That's why Robert's arguments
> aren't necessarily valid.
> 
> There's a further advantage with the immediate notifies: you can
> be assured that you will know how many SUB/NOT dialogs have been
> established within a small period of time (less than a minute,
> at least) by counting the number of NOTIFY messages you get.
> Once again, this is a consideration driven by forking.
> 
> Just some grist for the mill. Make sure that any further discussions
> on this topic consider and address forking.
> 
> /a
> 
> > -----Original Message-----
> > From: Sean Olson (EUS) [mailto:[email-masked]]
> > Sent: Monday, November 05, 2001 1:09 PM
> > To: 'Sriram Parameswar'; [email-masked]'; [email-masked]';
> > [email-masked]'
> > Subject: RE: [Sipping] RE: Sipping digest, Vol 1 #172 - 5 msgs
> > 
> > 
> > But the three-way handshake *IS* needed for establishing
> > legs in the forking scenario. Or has that changed? 
> >  
> > /sean
> > 
> > -----Original Message-----
> > From: Sriram Parameswar [mailto:[email-masked]]
> > Sent: Monday, November 05, 2001 12:10 PM
> > To: [email-masked]'; [email-masked]'; 
> > [email-masked]'
> > Subject: [Sipping] RE: Sipping digest, Vol 1 #172 - 5 msgs
> > 
> > 
> > 
> > Robert; 
> > 
> > I agree with you - that the 'empty or neutral' NOTIFY does 
> > not buy us anything, and we should probably eliminate it. 
> > However we should retain the semantics that 202 means 
> > Authenticated but not Authorized and a 200 OK response to 
> > SUBSCRIBE as being both Authenticated and Authorized. In 
> > either case there is no requirement for an immediate NOTIFY 
> > (there may not be a reportable state associated with the 
> > subscribed object).
> > 
> > On the flip side, a discussion on the SIMPLE list (Adam 
> > contributed)stated that the immediate NOTIFY formed part of a 
> > 'Three way handshake'. A combination of signals results in a 
> > 3-way handshake as follows:
> > 
> >         * SUBSCRIBE 
> >         * 202-NOTIFY 
> >         * 200 OK for the NOTIFY 
> > 
> > I would contend that a 3-way handshake is _not_ necessary. 
> > 
> > Regards, 
> > 
> > Sriram 
> > 
> > __________________________________________ 
> > Sriram Parameswar              Phone: 972-685-8540 
> > Interactive Multimedia Server (IMS) Fax: 972-685-3563 
> > Nortel Networks, Richardson USA  Email: [email-masked] 
> > 
> > 
> > 
> > Message: 1 
> > From: "Fairlie-Cuninghame, Robert" <[email-masked]> 
> > To: "[email-masked]'" <[email-masked]> 
> > Cc: "[email-masked]'" <[email-masked]> 
> > Date: Mon, 5 Nov 2001 03:24:18 -0800 
> > charset="iso-8859-1" 
> > Subject: [Sipping] Immediate NOTIFIES change in sip-events-01 
> > 
> > 
> > Hi Adam, 
> > 
> > The new PDF format looks good. 
> > 
> > I wish to discuss the following section: 
> > 
> > 8.3 Immediate notifies 
> > 
> > There has been discussion, but no consensus, on the issue of 
> > whether each 
> > SUBSCRIBE must have an immediate NOTIFY message sent in 
> response. In 
> > attempts to follow the prevailing sentiment, this draft had become 
> > inter-nally inconsistent. 
> > 
> > This version of this document has eliminated these 
> inconsistancies by 
> > requir-ing notifiers always to send a NOTIFY immediately upon 
> > receiving a 
> > SUB-SCRIBE. This decision does not necessarily represent 
> > group consensus, 
> > and further discussion may be warranted. 
> > 
> > --- 
> > 
> > As Adam rightly says in a later section, this burdens Event 
> > packages with 
> > have to support and fake/dummy NOTIFIES while authorization 
> > is pending. [And 
> > just makes things plain messy!] 
> > 
> > Firstly I address these questions to the list as a whole 
> > [since Adam is just 
> > documenting list consensus]. 
> > 
> > So what information is the immediate NOTIFY providing? None. 
> > We have a 202 
> > Accepted that informs the subscriber that the SUBSCRIBE 
> > request is being 
> > processed (and that it may take a non-trivial amount of time). 
> > 
> > The subscriber knows that the subscription is in effect when 
> > the first 
> > _real_ NOTIFY arrives, so sending a dummy NOTIFY immediately 
> > is actually 
> > confusing things! What is the rationale? 
> > 
> > If this does stay Adam, the rationale needs to be added and 
> > the 202 Accepted 
> > response code can be removed as far as I can see. 
> > 
> > Regards, 
> > 
> > Robert. 
> > 
> > 
> 

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

---

From: "Bert Culpepper" <[email-masked]>
Date: Tue, 6 Nov 2001 09:17:27 -0500

Hello Robert,

If my memory serves me correct, the 202 was "defined" to indicate
"acceptance" of the SUBSCRIBE but not authenticated and/or authorized.
This way re-transmissions of the SUBSCRIBE can be prevented while the
device obtains the user's permission to accept the SUBSCRIBE, for
example.  (It may take some time for this causing the 200 to be
"delayed", therefore 202 was defined.)  Once the subscription is
"authorized", a 200 is sent.  Then immediate NOTIFY to handle forked
SUBSCRIBES.

regards,
Bert

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> Fairlie-Cuninghame, Robert
>

---

From: [email-masked]
Date: Tue, 6 Nov 2001 13:34:57 -0600

> From: Bert Culpepper [mailto:[email-masked]]
> "authorized", a 200 is sent.  

Ummm... no. 202 is a final response. There will be no further final
responses.

> Then immediate NOTIFY to handle forked
> SUBSCRIBES. [after authorization has occurred]

Such was originally the intention; however, this setup has advantages
as well as disadvantages. At least, I assume it has advantages, since
people are arguing for it.

The only factor I'm aware of is that such a scheme makes it possible
to receive an initial NOTIFY (i.e. one that sets up a new dialog)
minutes or even hours after sending the SUBSCRIBE unless NOTIFYs
are sent immediately upon reception of the SUBSCRIBE regardless of
authorization. 

Originally, I was neutral on the topic, but the more analysis I
do, the more I lean towards the immediate NOTIFY solution.

I don't like the delayed NOTIFYs for a couple of reasons: first,
it makes implementations keep around the "prototype" dialog (the
one without a tag on the "To") for an indefinite period of time.
Immediate notifies allow you to safely discard such state after
a determinate period of time.

The second issue is user experience: I foresee that the state
conveyed by NOTIFY messages will often be rendered for users.
There's an expectation of some amount of chaotic behavior
upon startup (users can understand different status indicators
popping up upon program startup or when they add a new resource to
monitor), but objects being rendered to the user minutes or even
hours after the initial request makes for bad user interface design.

No one has made any other arguments on the topic of immediate
or delayed notifies (at least, none that correctly take forking
into account). The only issue that appears to be a topic of
discussion right now is whether 202 is to be used at all. This
seems like such an extreme non-issue that I can't believe people
are holding up resolution of this draft -- on which several other
drafts depend -- with what amounts to an aesthetic decision. We're
not gobbling up a status code that could otherwise be useful,
since 202 is defined in HTTP. Current client implementations that
actually implement SIP correctly handle 202 like a 200 (since any
unknown status code is treated like the x00 code of the same class). 

Even if a 202 status code were unleashed on the SIP world, notifiers
would work just fine sending a 200. There may be packages that
want to take advantage of the subtle difference between 200 and 202
to alter processing (forking can be taken out of the picture for these
cases by packages forcing subscribers to 481 all NOTIFYs that are on a
dialog other than the one established by the SUBSCRIBE response; this
doesn't always make sense, but it sometimes does).

I'd love to hear *technical* arguments for or against particular modes
of operation.

/a