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

[Ben Campbell <[e-mail]>]

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?

>>
>>
>> "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.

[...]

>>
>> 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.

[...]

>>
>> "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.

>
>>
>>
>> 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.)

>> 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?

> 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.)

>
>>
>> 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.

[...]

>>
>> 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.

Thanks!

Ben.
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip