Subject: RE: [Simple] WGLC: partial notification

From: [email-masked]
Date: Thu, 29 Apr 2004 15:36:54 +0300

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> ext [email-masked]
> Sent: 27.April.2004 13:05
> To: Lonnfors Mikko (Nokia-NRC/Helsinki); [email-masked];
> [email-masked]
> Subject: RE: [Simple] WGLC: partial notification
> 
> 
> 
> 
> > -----Original Message-----
> > From: Lonnfors Mikko (Nokia-NRC/Helsinki) 
> > Sent: 27.April.2004 12:46
> > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); 
> > [email-masked]';
> > [email-masked]'
> > Subject: RE: [Simple] WGLC: partial notification
> > 
> > 
> > Hi,
> > 
> > > Here is an example where both state and version are needed:
> > > 
> > > PA sends N1(full), N2(full), N3(partial).
> > > 
> > > If the version is set to 0 everytime there is full state, and 
> > > N2 was never received, the subscriber would then think that 
> > > N3 is a partial of N1.
> > > 
> > > To solve this, you need the version to continuously increase 
> > > by 1, even when a full state is being sent. You would then 
> > > also need the state attribute to indicate full/partial. The 
> > > version is used by the subscriber to learn that a NOTIFY was 
> > > not received (N2).
> > 
> > Ok, so your proposal is that "version" should be scoped with 
> > the subscription i.e. first NOTIFY within a subscription 
> > would have version="0" and then it would be continuously 
> > increased by one for every notifications (regardless if it 
> > contains full or partial state)?
> > 
> > How should subscription refreshes be handled? If we have
> > PA sends N1(full), N2(full), N3(partial)
> > And N2 is lost watcher would refresh the subscription when it 
> > receives N3. Now
> > Would the PA send N1(full, version="0") or N4(full, version="3")?
> 
> version gets reset to 0 when a SUBSCRIBE refresh is received.

Now that I think about this a little more, I think the version should forever increase for the whole duration of the subscription, including refreshes. Imagine this scenario:

----> SUBSCRIBE
<---- 200
<---- NOTIFY1 (full, version 0)
----> 200
  X-- NOTIFY2 (full, version 1)
<---- NOTIFY3 (partial, version 3)
----> 200
----> SUBSCRIBE
<---- 200
<---- NOTIFY4 (full, version 0)
----> 200
<--x  NOTIFY2 (full, version 1) Now NOTIFY2 arrives

How does the subscribe know that the last NOTIFY (NOTIFY2) was sent after the subscribe refresh? If NOTIFY 4 had version 4 instead of 0, then it would.

/Hisham

> 
> /Hisham
> > 
> > - Mikko 
> > 
> > > /Hisham
> > > 
> > > > -----Original Message-----
> > > > From: [email-masked] 
> > > [mailto:[email-masked]]On Behalf Of 
> > > > ext [email-masked]
> > > > Sent: 26.April.2004 22:17
> > > > To: [email-masked]; [email-masked]
> > > > Subject: RE: [Simple] WGLC: partial notification
> > > > 
> > > > 
> > > > Hi,
> > > > 
> > > > Thanks for comments. Responses inline:
> > > > 
> > > > > Writing as a WG member - not as chair -
> > > > > 
> > > > > I've sent a list of typo level nits in these drafts to
> > > > Mikko privately
> > > > 
> > > > > -
> > > > > 
> > > > > While doing a nit review, I found some things that should have
> > > > > received list attention earlier.
> > > > > 
> > > > > In section 4.4 of -partial-notify it says "The PA SHOULD
> > > > construct the
> > > > 
> > > > > partial presence document according to the following
> > > > logic:" followed
> > > > > by a bunch of MUST level statements. Why is that SHOULD 
> > > there? What
> > > > > would it mean to violate it? I suggest striking it and 
> > > > simply saying
> > > > > "The PA constructs"
> > > > 
> > > > Yes, SHOULD is probably useless and confusing here. I will 
> > > remove it.
> > > > 
> > > > > Why do we have both "state" and "version"? As defined in
> > > > these drafts,
> > > > 
> > > > > state=full if and only if version=0. You could delete 
> the state
> > > > > parameter with no loss of information, so why is it there?
> > > > 
> > > > I believe the original need for the "state" was that the
> > > > "version" could
> > > > be initialized to some random value. Now, if "version" is always
> > > > initialized to 0 there is no need for the "state" 
> attribute. Both
> > > > solutions should work and if nobody else comments 
> otherwise I will
> > > > remove the "state" attribute.
> > > > 
> > > > > 3261 currently allows overlapping non-INVITE 
> > transactions inside a
> > > > > dialog (there's an open issue suggesting this might be a 
> > > bad thing, 
> > > > > see http://bugs.sipit.net/sipwg/show_bug.cgi?id=686). Neither
> > > > > 3265 or simple-presence prohibit overlapping NOTIFYs. For 
> > > > > full state documents, having multiple outstanding NOTIFYs is 
> > > > > probably manageable. For partial state documents, at least as 
> > > > > they are specified here, it could be disastrous. Consider 
> > > > > four notifies N1(full), N2(partial), N3(full), N4(partial). 
> > > > > If the recipient receives only N1 and N4 (something prevents 
> > > > > N2 and N3 from being delivered or simply delays them 
> > > > > (packetloss over UDP for example)), it will apply the delta 
> > > > > in N4 to the wrong full state document (N1 instead of N3). 
> > > > 
> > > > Actually it wouldn't because of "version" handling. Section
> > > > 4.5 applies
> > > > here. But in any case this kind of behavior is quite bad 
> > as it might
> > > > result in frequent subscription refreshes to obtain full 
> > > > presence state.
> > > > More below.
> > > > 
> > > > > We
> > > > > can preserve the properties of the existing system is 
> we forbid 
> > > > > sending a NOTIFY with a document with state="partial" 
> > > when any other 
> > > > > NOTIFY transaction is still in progress on
> > > > this dialog.
> > > > 
> > > > This is a good point. Your proposed solution should work.
> > > > This may cause
> > > > some extra implementation effort for PA but I cannot see any 
> > > > way around
> > > > this. If no other comments are received I will add text 
> forbidding
> > > > sending a NOTIFY with a document with state="partial" 
> > > (version=0) when
> > > > any other NOTIFY transaction is still in progress on 
> this dialog. 
> > > > 
> > > > > Section 4.5 of partial-notify says "If the watcher receives a 
> > > > > presence document whose "version" attribute value (is) 
> > higher by 
> > > > > more than one with the locally stored value, the 
> > watcher assumes 
> > > > > that one or more NOTIFYs were lost. The watcher SHOULD either 
> > > > > refresh the subscription in order to receive a full presence 
> > > > > document or terminate the subscription."  Why is that 
> > SHOULD? In 
> > > > > what scenario is any other course of action reasonable? 
> > (The only 
> > > > > one I can think of is _if_ we allow overlapping partial 
> > NOTIFYs, 
> > > > > then the watcher can wait around for awhile for the gaps 
> > > to fill in 
> > > > > - if we allow this, then we need to explicitly state this as
> > > > > why the above is SHOULD, not MUST. However, I think this 
> > > > > should be a MUST.)
> > > > 
> > > > Well, there probably isn't any good cases where watcher 
> wouldn't 
> > > > terminate or refresh subscription. Changing SHOULD to 
> MUST should 
> > > > provide more consistent behavior.
> > > >  
> > > > > Just below that, there's a "SHOULD discard the document" if
> > > > > it gets a partial notification with a lower version number. I 
> > > > > don't see how this is right at all, and suggest that this 
> > > > > MUST trigger a refresh or termination instead. (We wouldn't 
> > > > > get to this logic if a NOTIFY was reordered and arrived late 
> > > > > - the CSeq processing logic would 
> > > > > have caught it).
> > > > 
> > > > Right, and if we don't allow sending new NOTIFYs if there 
> > > is a pending 
> > > > transaction then I believe reordering should never happen. 
> > > But if in 
> > > > this situation watcher receives a presence document with 
> > > lower version 
> > > > number there should be no harm in discarding it because it 
> > > already has 
> > > > a consistent presence state. This is more or less an error 
> > > case which
> > > > probably should never happen but I think there is no need to 
> > > > refresh or
> > > > terminate the subscription.
> > > > 
> > > > - Mikko
> > > > 
> > > > > I'll send a separate message on the Security Considerations
> > > > > section for -partial-notify.
> > > > > 
> > > > > RjS
> > > > > 
> > > > > 
> > > > > On Wed, 2004-04-21 at 09:55, Robert Sparks wrote:
> > > > > > This is a Working Group Last call on the following drafts:
> > > > > > 
> > > > > > 
> > > > > http://www.ietf.org/internet-drafts/draft->
> > > > ietf-simple-partial-notify-0
> > > > > > 2.txt
> > > > > > 
> > > > > http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-
> > > > pidf-format-01.txt
> > > > > 
> > > > > This abbreviated WGLC will end on Wednesday, April 28.
> > > > > 
> > > > > These drafts went through a previous last call at the 
> > beginning of
> > > > > March. These versions reflect changes due to comments 
> > > > received during
> > > > > that period. See
> > > > > 
> > > 
> https://www1.ietf.org/mail-archive/working-groups/simple/current/msg02
> > > 519.html
> > > for details.
> > > 
> > > Please send comments to the list, copying the editor. If 
> > you reviewed
> > > the draft and found no issues, please indicate so on the list.
> > > 
> > > RjS
> > > 
> > > 
> > > _______________________________________________
> > > Simple mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/simple
> > 
> > 
> > _______________________________________________
> > Simple mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/simple
> > 
> > _______________________________________________
> > Simple mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/simple
> > 
> 
> _______________________________________________
> 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: Robert Sparks <[email-masked]>
Date: Thu, 29 Apr 2004 08:39:31 -0500

>   X-- NOTIFY2 (full, version 1)

If you didn't allow overlapping NOTIFYs
(which is still how I think you should solve
this), then the subscription would be terminated
at this point.

---

From: Robert Sparks <[email-masked]>
Date: Thu, 29 Apr 2004 08:39:31 -0500