Subject: AW: [Simple] WGLC: partial notification

From: Schmidt Christian <[email-masked]>
Date: Fri, 30 Apr 2004 13:27:42 +0200

Hi Hisham,

this proposal would not solve the problem with a missing NOTIFY (full or partial). 

What´s about the following proposal:
The notifier must not issue a NOTIFY (full or partial), before it receives a 200 for the last issued NOTIFY (full or partial). After experation of a timer t, the notifier should send a full NOTIFY.

This would also work without version number and would cover reordering and packet loss cases.

Regards,
Christian

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von [email-masked]
Gesendet: Freitag, 30. April 2004 08:27
An: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Betreff: RE: [Simple] WGLC: partial notification

Ok, I also agree that overlapping partial NOTIFYs complicate things without benefit. I also would like to propose explicitly disallowing overlapping full state and partial. I.e. A notifier must not issue a partial state NOTIFY without first receiving the 200 for a full state NOTIFY. I believe the converse is also required: the notifier must not issue a full state NOTIFY before it receives a 200 for a partial state NOTIFY.

With all there restrictions, we can do without the version attribute.

Regards,
Hisham

> -----Original Message-----
> From: ext Paul Kyzivat [mailto:[email-masked]]
> Sent: 29.April.2004 21:47
> To: Robert Sparks
> Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki); Lonnfors Mikko
> (Nokia-NRC/Helsinki); [email-masked]
> Subject: Re: [Simple] WGLC: partial notification
> 
> 
> 
> 
> Robert Sparks wrote:
> > Aside from that I'd like for you to think through this again
> > from viewpoints besides active attack (use a transient malfunction
> > of the application (above the layer that would screw up basic SIP)),
> > I'm ready to let this go as long as we have _a_ solid solution to
> > dealing with reordered/missing notifies.
> 
> I'm not going to start down the path to speculation about how 
> to recover 
> from arbitrary malfunctions of an application. That is just plain 
> impossible without some characterization of the kinds of malfunctions 
> that are to be recovered from.
> 
> > So, backing out a layer, lets look at my original question of
> > whether or not we allow overlapping ->partial<- NOTIFYs at all
> > in this case.
> 
> I don't see any compelling need to support overlapping 
> partial notifies. 
> It is very difficult to see how to make them work.
> 
> I can imagine a case where there might be some motivation: I sent one 
> notification and have had no response. But I already have a bunch of 
> additional changes that you should know about. It might be 
> advantageous 
> to start sending them as soon as possible. But until you know 
> the prior 
> one has been handled it isn't safe to send the new one.
> 
> > Why would you want to? What value would doing that bring? 
> > 
> > 3261 and even presence-10 left sending full-state presence
> > NOTIFYs open. We wouldn't be changing that. If an application
> > for some reason decided it needed to send a new full-state
> > notify while a partial-state notify was pending, it could.
> > So any of the arguments for allowing it from the 3261/presence-10
> > are still satisfied. Can you see any use case where allowing
> > a server to send overlapping partial NOTIFYs is a good idea?
> > If not, disallowing it seems a powerful simplification.
> >
> 
> I agree.
> 
> 	Paul
> 
> 

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 30 Apr 2004 08:48:18 -0400

> This would also work without version number and would cover reordering and packet loss cases.

This would work. I guess it is obvious that if the full notify also 
times out then further retries, if any, should also send full state. And 
that this should continue until there is success. A notify with partial 
state could only happen after receiving a 2xx for the prior notify.

OTOH, this might be a bad choice for a bandwidth constrained device, 
like a cell phone. If you are driving thru a tunnel and can't receive 
for a few minutes, are going to be happy to get a full update when you 
emerge?

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 30 Apr 2004 08:48:18 -0400

Paul

---

From: Robert Sparks <[email-masked]>
Date: Fri, 30 Apr 2004 09:09:43 -0500

I don't see what purpose an additional timer serves.

If a NOTIFY transaction times out, the subscription is over.

RjS

---

From: Robert Sparks <[email-masked]>
Date: Fri, 30 Apr 2004 09:09:43 -0500

RjS