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

ext Ben Campbell wrote:
>
> 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.
>
the implicit rule _now_ for the notifier is: if you don't get a final 
200 ack for a notify, do not send a new request and for a timeout, tear 
down the session (this is what i propose but as explicit). So what 
happens with  4xx, 5xx, 6xx etc is unspecified. So the rule for waiting 
for the 200 OK rules out-of-order. So if you get 4/5/6xx will that mean 
drop-out possibility ? no imo, since you can't send a new one unless the 
previous one has been sent successfully. So personally i _could_ go that 
far that tear down always if return code != 200, but probably some 
intelligent notifiers could resolve e.g. 413, though i have my doubts....
>>>
>>>>> 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.
>
it is in the format spec, it was implicit in some older versions, but i 
fixed that:
"If several <document>
   elements with the same "sel" selector value exist in the XCAP diff
   document, i.e. for example, the full ETag change history is
   indicated, the corresponding patches MUST be appliable in the given
   document order."
>>
>>
>> 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.
>
great, i really hope you have time to look at the updated text when i 
get it "fully" ready with those reasonable examples ...

thanks,
Jari

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