[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] 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 at 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 at example.com/coworkers"
> previous-etag="x">
> <add sel="*"><foo/></add>
> </document>
> <document new-etag="x+2s"
> sel="resource-lists/users/sip:joe at 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 at 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.
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip