inline Jari Urpalainen wrote:
>>>> - The draft should say which of the 3 XCAP-Diff processing models is >>>> mandatory to implement. I suspect the draft assumes that all 3 are >>>> mandatory to implement in both the server and the clients. So, it >>>> should say it. But isn't that in contradiction with the following >>>> sentence in Section 4.7? >>>> >>>> It is RECOMMENDED to implement the XML-Patch-Ops processing on a >>>> server. >>>> >>>> How can one implement the xcap-patch diff-processing model without >>>> the XML-Patch-Ops? >>> clearly this needs some clarification. Yes you don't need to support >>> _any_ patching at all (in the server) as the notifier may decide to >>> send only references to docs and only indicate element/attribute >>> subscriptions. The diff-processing parameter is thus a hint to the >>> notifier. This is to allow naive implementations or where >>> transmission optimizations are not important. But the parameter >>> value "no-patching" is not a hint, the notifier MUST NOT provide >>> patches then. >> >> >> You said that the server dos not need to support patching. So, what >> happens if the subscriber selects diff-processing=xcap-patching and the >> server does not support it? How will the developer be ready in its code >> to react to it? >> > well, it is almost no-brainer stuff, since the thing you MUST understand > is http-retrievals of documents, i.e. it is the fall-back resolution you > must understand (well, if you request in a corner-case reasonable xcap > component contents you could avoid having implementing http). Patching > is truly an optional thing and an optimization technique which you don't > necessarily always need. So in principle, the client side patchings are > fairly easy, but what is not mandated by the spec that the servers > (notifiers) MUST implement the inevitably complex thing: the > diff-processing in the notifier. Even if you support only the simple ;-) > xcap-patching mode, e.g. combining with throttling MAY be challenging > enough... So what is important in this package that you can have an > almost immediate notification once a change happens, but requiring > _always_ the most complex thing would be an unnecessary burden. Hey, > _good_ implementations would certainly implement decent diffing ;-) I still didn't get a question to my answer. A subscriber sends a SUBSCRIBE request. The Event header is set to xcap-diff;diff-processing=xcap-patch. The server does not support it. So, now what? Is the SUBSCRIBE request rejected (with which response code?) or is it accepted and a fall back to some of the other processing models (to which one)? Where is that written? >>>> - Section 4.4. Missing text about the Request-URI. Although the >>>> title of Section 4.4 has nothing to do with Request-URIs, I think >>>> somehow somewhere the document should say what is the assumption >>>> about the Request-URI of the SUBSCRIBE request. I guess the document >>>> tries to say: >>>> >>>> A subscribers need to appropriately populate the Request-URI of the >>>> SUBSCRIBE request. This document does not provide any constraints to >>>> it. It is assumed that the subscriber is provisioned or has >>>> learned the Request-URI of the notifier of this event package. >>>> Initial SUBSCRIBE requests are assumed to be addressed to the URI of >>>> that notifier. >>> except the last sentence which i don't follow looks good. >> >> The point with the last sentence is that in an initial SUBSCRIBE >> request, the Request-URI is populated with the SIP URI of the notifier, >> which is learned somehow (outside the scope of the document). Once the >> dialog is created, if there is a subsequent SUBSCRIBE request (e.g., to >> refresh the subscription), then the Request-URI will obey the SIP rules: >> it will be set to the URI that was received in the Contact header of the >> 200 OK response for that initial SUBSCRIBE. Conclusion: the >> Request-URI of the initial SUBSCRIBE request and the following ones (in >> the same dialog) need not be the same. >> > huh, does this explain the last sentence, i mean are they really > equivalent ?. If so, i can include it (though i still don't get it (the > single line), sorry ...) Let me try by rephrasing the last sentence: Instead of: Initial SUBSCRIBE requests are assumed to be addressed to the URI of that notifier. what about this one? This specification assumes that subscriber populates initial SUBSCRIBE requests with the URI of that notifier. /Miguel -- Miguel A. Garcia tel:+358-50-4804586 Nokia Siemens Networks Espoo, Finland _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
