On Apr 3, 2008, at 7:28 AM, Jari Urpalainen wrote: [...]
>>> >>>> >>>> >>>> Paragraph 2: (substantive) >>>> >>>> You cannot safely use non-sequential CSeq to detect missing >>>> NOTIFY requests. For example, if the NOTIFY request is challenged >>>> by an intervening proxy, the subscriber will see non-sequential >>>> CSeq values. It may be unusual for NOTIFY to get challenged, but >>>> unless we forbid it, then we cannot depend on CSeq for this >>>> purpose. >>> ok, didn't think about that at all. >> >> This one needs some thought, then. There are actually a lot more >> causes than just digest challenges that may cause the client to see >> non-sequential CSeqs. If detection of lost notifies is critical, we >> need another solution (either to detect lost notifies or to remove >> the need to do so.) > now I've managed to put this "utter crap" myself :-), sorry, i.e. > unordering doesn't happen when the notifier acts _properly_, so it's > better to move that text altogether. The text was more about missing NOTIFY requests than it was out-of- order NOTIFYs (CSeq will actually catch the out-of-order case). Are you saying that it is okay to not be able to detect missing NOTIFYs, even in patch mode? Note that missing and out-of-order notifies can (rarely, we hope) happen due to intervening devices even if the notifier is perfectly well behaved. > >> >>>> Section 4.10 (substantive) >>>> >>>> It's not clear to me how this interacts with the "aggregation" >>>> mechanism. In particular, if the notifier has more than one >>>> change in the 5 second window, but the subscriber did not allow >>>> aggregation, how is it handled? >>> yep this is indeed _difficult_. Easy to write (one sentence only), >>> but really, really hard to implement properly ;-). First off >>> there's a SHOULD directive fortunately... I'm not 100 % sure if >>> you mean that xcap-patching is also disabled. So there's not a big >>> difference in this context whether you have aggregation or xcap- >>> patching modes, since in the xcap-patching mode you will see >>> changes e.g. from "a" to "b" to "c" with all corresponding Etags >>> while in the aggregate mode you'll see e.g. only changes from "a" >>> to "c" in the notification body without the intermediate state. >>> Certainly aggregation body is smaller but it fails to show the >>> versioning history and the diff formats differ, but the end result >>> will be the same certainly, i.e. "c". So _if_ you obey the timer, >>> you wait for it to expire and then send the result in both cases >>> (and of course during this timer interval you wait for any changes >>> in these resources, and do something relevant, e.g. store internal >>> object states). If there's not any patching modes applied, then >>> you should wait for the timer to expire and send appropriate >>> actions, i.e. document(s) has either been created, modified or >>> deleted. >> >> I'm not sure I understand what you mean on the last two sentences-- >> can you give an example? > btw. just noted that a rate limit was per a _user_ what would that > mean ? so should be per _subscription_. > > let's say you'll notify a initial document at some time x. then > comes two changes 1 & 2 for the same document within 2 seconds > (ETags are those timestamps): > NOTIFY 1 -- x change 1 -- x+1s. > change 2 -- x+2s. > NOTIFY 2 -- x+5s. > > so if those two changes are reported (NOTIFY 2) _without any > patching_ you'll report the document uri reference with Etags at > time x+5s due to this 5s rate limitation: > <xcap-diff xcap-root="http://xcap.example.com/root/";> > <document new-etag="x+2s" > sel="resource-lists/users/sip:[EMAIL PROTECTED]/coworkers" > previous-etag="x"/> > </xcap-diff> > > with xcap-patching you could have: > > <xcap-diff xcap-root="http://xcap.example.com/root/";> > <document new-etag="x+1s" > sel="resource-lists/users/sip:[EMAIL PROTECTED]/coworkers" > previous-etag="x"> > <add sel="*"><foo/></add> > </document> > <document new-etag="x+2s" > sel="resource-lists/users/sip:[EMAIL PROTECTED]/coworkers" > previous-etag="x+1s"> > <add sel="*"><bar/></add> > </document> > </xcap-diff>' Ah, I see you are effectively listing both change events in a single xcap-diff document, but still as separate events. That makes sense, but it was not obvious to me from the text that you could do this. I don't recall if the data format doc addressed it or not. It would definitely help to include examples for each mode of operation. > > > while with the "aggregate" mode: > > <xcap-diff xcap-root="http://xcap.example.com/root/";> > <document new-etag="x+2s" > sel="resource-lists/users/sip:[EMAIL PROTECTED]/coworkers" > previous-etag="x"> > <add sel="*"><foo/><bar/></add> > </document> > </xcap-diff> > > So the first one shows the simplest case, and then the more complex > xcap-patching and lastly aggregate, does this help ? I've the > intention to add something similar to an appendix regardless of the > pain... > > So as can be seen from the example "aggregate" and "xcap-patching" > both aggregate patches, but the "real" aggregate can do much clever > decisions with the added complexity. > > And i've made it now explicit that the notifier MAY respond with all > of these 3 ways if aggregate is requested. If notifier requests xcap- > patching "aggregate" MUST NOT be used, and with "no-patching" > naturally only the simplest mode is allowed. > >> >>> IIRC, in partial PIDF where we use the exact same patchings >>> there's not a single line about this since this timer is inherited >>> from the base PIDF package. In summary, you just don't have to do >>> anything mysterious with timers except wait for a certain period >>> of time. In practice, it happens to be quite a challenging task >>> (but these specs usually _ignore_ the implementation PITA ;-)) >> >> It's still not clear to me if this is just a "hard implementation" >> problem or if it is really a conflict in normative requirements. >> Coding aside, what do you expect the most commen behavior to be if >> multiple changes occur inside the 5 second window, but the client >> has not allowed aggregation? (The example requested above might >> help me understand this.) >> > imo it is not a conflict, just a PITA in implementations, though > sometimes a very nice optimization. I _think_ I am okay with this, pending seeing the new text. [...] Thanks! Ben. _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
