Re: [Simple] WGLC Comments on draft-ietf-sip-xcapevent-01

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:joe@example.com/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:joe@example.com/coworkers"
>            previous-etag="x">
>      <add sel="*"><foo/></add>
> </document>
> <document new-etag="x+2s"
>            sel="resource-lists/users/sip:joe@example.com/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:joe@example.com/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.

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www.ietf.org/mailman/listinfo/simple