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

ext Ben Campbell wrote:
> Thanks for the quick response. My comments for anything that still 
> seems like an open issue are inline:
>
>
> On Apr 2, 2008, at 5:04 AM, Jari Urpalainen wrote:
>> ext Ben Campbell wrote:
>
> [...]
>
>>> Section 4.4, paragraph 1(clarity):
>>> "The usage of hierarchical lists and <entry>
>>>   references, etc. can thus be omitted."
>>>
>>> You say that the usage of hierarchical lists and <entry> references 
>>> can be omitted. Are they actually being forbidden in this context, 
>>> or do you just mean to say that they are optional? If features of 
>>> the resource list format are forbidden, then this draft needs 
>>> normative language saying explicitly what is not to be used. If you 
>>> just mean to say that they are optional, what are the 
>>> interoperability issues if one device chooses to use them but the 
>>> peer does not understand them?
>
> Do you have any thoughts concerning the above comment?
Sorry, i already made an actual fix, but forgot to reply.  Yep, these 
are "sophisticated" features which don't bring in any value here --> 
"...MUST NOT be used"

>
>>>
>>>
>>> "As it is
>>>   anticipated that the XCAP server will be collocated with the SIP
>>>   notifier, the subscriber MAY use relative XCAP URIs."
>>>
>>> Is it the authors' intention to require this collocation? That seems 
>>> to be an architectural consequence of allowing relative URIs, unless 
>>> we assert that if an implementation is architected differently, it 
>>> is up to the implementation to be able to dereference relative URIs.
>>>
>> in practice, the sip notifier must be aware of changes made by 
>> another protocol, i.e. http in this case. If these servers (notifier 
>> & http (xcap) daemon) are separated they need some sort of immediate 
>> mechanism to signal these events. It can be done with some 
>> unspecified ways, but the most simple one is when they are running on 
>> the very same host. However, even that simplest case is pretty hard 
>> (or complex enough) to implement properly (implementation description 
>> can be a long story although you are using OSS tools, like e.g. linux 
>> with Apache + xcap_module and some decent Sip stack with all the 
>> source code), and the intention is to define only the very simplest 
>> use-case here. It is not ruled out that they were separated but that 
>> would be much, much more difficult to implement, and there are many 
>> obstacles and open issues there. So there's magic (outside the scope 
>> of this i-d) here how to map the sip-uri to the xcap-root-uri, but 
>> this, the most simple use-case is what i'd expect to be implemented 
>> (and maybe, even some minor deployment as well ;-)).
>>
>> Also we agreed with Miguel to be more explicit about this magic, does 
>> it sound sufficient to you ?
>
> Likely. As long as we mention the need for the notifier to learn about 
> changes at the XCAP server, and that such mechanisms are out of scope 
> for this document. It makes sense to mention collocation as an example 
> way to solve this, but it's only an example.
>
> [...]
fine.
>
>
>>>
>>> Paragraph 3 (clarity):
>>>
>>> I'm not sure what the MUST applies to here--are you saying that the 
>>> server MUST check for the condition you list as an example, or 
>>> simply that, if the notifier chooses not to send XML-Patch-Ops 
>>> patches for reasons of local policy, it MUST fall back to 
>>> xcap-patching mode?
>> the reason to drop the aggregation mode for that particular resource 
>> is that once the client have to use http, it might get out-of-sync 
>> (with "rapidly" changing resources), the rule is to be certain that 
>> it will not happen. I'll try to clarify.
>
> Thanks. I think it would be helpful to have a section dedicated 
> describing the issue, and mention the ways to work around it.
>
> [...]
i 've added a whole new chapter about this into the "notifier 
generation" and re-arranged things so that it SHOULD be now much more 
unambiquous.

>
>
>>>
>>> "After that the
>>>   subscriber MAY send a re-subscription to start the diff "aggregation"
>>>   on the server."
>>>
>>> Does this mean to imply the subscriber cannot start out with 
>>> aggregation turned on? (I think this may be another case of 
>>> presenting the edge case without presenting the primary use case 
>>> first.)
>> it can try to start in the aggregate mode straight away, but it may 
>> fail. So the safe way is to disable aggregation first before sync is 
>> achieved and enable it afterwards. I think I'll add something about 
>> this into those dreaded examples (in an appendix)
>
> See my previous comment about having a separate section to describe 
> the issue and possible solutions. It's also important that we are 
> clear on whether the delayed activation of "aggregation" mode is 
> simply an optional solution to a potential issue, or is a normative 
> requirement.
>
As the aggregate mode has its drawbacks when versioning is not supported 
in http, I think I've managed to fix the text...
>>
>>>
>>>
>>> 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.
>
>>> 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>

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.
>>
>>>
>>> Section 5, figure 3 (clarity):
>>>
>>> It would be nice to see this in context of an actual NOTIFY.
>> I'll try to digest something into an appendix. That being said, the 
>> important things are bodies...
>
> To some degree, it is up to the companion draft to define the body in 
> detail--this draft really talks about the SIP-event package, so I do 
> think it is appropriate to show real message flows including the SIP 
> parts.
>
> [...]
>
yep, though from sip event pov. only the event-paramer and conditional 
headers are really relevant, and indeed the body examples are not shown 
in other specs, which allow virtually everything. In this case, this 
package _requires_ those limitations to those formats with/without 
patching, so it is definitely good to have good examples.

>>>
>>> Section 7, Security Considerations (substantive)
>>>
>>> I think we need more here. What sort of authentication is adequate 
>>> (particularly for authenticating the notifier.) Does the potential 
>>> sensitive content create any need for privacy and integrity 
>>> protection beyond that generically needed for SIP-Events?
>>>
>> yep, besides DoS TLS & S/MIME recommendations some text about 
>> identity "mapping" between http & sip would be reasonable. Anything 
>> else ?
>
> I had not thought of the identity mapping issue--that discussion 
> always seems to get more "interesting" than you might expect :-)  It 
> might be worth adding SIPS thoughts to any TLS discussion.
yep.
>
> Thanks!
>
> Ben.

Thanks again,
Jari
_______________________________________________
Simple mailing list
Simple@ietf.org
https://www.ietf.org/mailman/listinfo/simple