RE: [Simple] WGLC: partial notification

[[e-mail]]

Actually, the text is described in draft-ietf-simple-winfo-format-04.txt:

"version: This attribute allows the recipient of watcherinfo
             documents to properly order them. Versions start at 0, and
             increment by one for each new document sent to a
             subscriber. Versions are scoped within a watcherinfo
             subscription. Versions MUST be representable using a 32 bit
             integer. However, versions do not wrap."

and

"The
   version number MUST be initialized with the value of the "version"
   attribute from the "watcherinfo" element in the first document
   received. Each time a new document is received, the value of the
   local version number, and the "version" attribute in the new
   document, are compared. If the value in the new document is one
   higher than the local version number, the local version number is
   increased by one, and the document is processed. If the value in the
   document is more than one higher than the local version number, the
   local version number is set to the value in the new document, the
   document is processed, and the watcherinfo subscriber SHOULD generate
   a refresh request to trigger a full state notification. If the value
   in the document is less than the local version, the document is
   discarded without processing."

If the problem exists for partial notification, then it also exists for winfo, and for any event package that defines partial state. The text quoted above to winfo is much similar to what I suggested for the use of version.

/Hisham

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On Behalf Of
> ext [e-mail]
> Sent: 03.May.2004 13:40
> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); [e-mail];
> [e-mail]
> Cc: [e-mail]
> Subject: RE: [Simple] WGLC: partial notification
> 
> 
> Hi,
> 
> Related to this issue it occurred to me that winfo
> (draft-ietf-simple-winfo-package-05) may also suffer from this. As far
> as I can tell "version" and "state" handling is quite similar 
> (in winfo
> version is scoped to the subscription) in both cases (winfo 
> and partial
> notify) and winfo also doesn't prohibit sending new NOTIFYs if there
> exists a pending NOTIFY.  
> 
> Thoughts?
> - Mikko
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On 
> > Behalf Of ext [e-mail]
> > Sent: Friday, April 30, 2004 9:27 AM
> > To: [e-mail]; [e-mail]
> > Cc: Lonnfors Mikko (Nokia-NRC/Helsinki); [e-mail]
> > Subject: 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:[e-mail]]
> > > Sent: 29.April.2004 21:47
> > > To: Robert Sparks
> > > Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki); Lonnfors Mikko 
> > > (Nokia-NRC/Helsinki); [e-mail]
> > > 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
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/simple
> > 
> 
> _______________________________________________
> Simple mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/simple
> 

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