Subject: RE: [Simple] WGLC: partial notification

From: [email-masked]
Date: Tue, 27 Apr 2004 12:33:40 +0300

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).

/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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 27 Apr 2004 11:37:19 -0400

Sounds like what is needed is:

1, 1.1, 1.2, ..., 1.x, 2, 2.1, 2.2, ... 2.y, 3, 3.1, 3.2, ..., 3.z, ...

Namely, version number and revision number. If there is no revision 
number, then it is full, otherwise partial. If you get Version a, 
Revision b, then you had better have already received Version a, 
Revision b-1, or else there is a problem.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 27 Apr 2004 11:37:19 -0400

Paul

---

From: Robert Sparks <[email-masked]>
Date: Tue, 27 Apr 2004 10:49:59 -0500

This introduce a new attack - if I inject a message with
version = <very large number>, you are not likely to recover
even with a reSUBSCRIBE.

RjS

---

From: Robert Sparks <[email-masked]>
Date: Tue, 27 Apr 2004 10:49:59 -0500

RjS