Miguel Garcia wrote: > 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? it seems not to be clearly written anywhere ;-) (which i thought was already clear) except that there's at least this one sentence "It is RECOMMENDED to implement the XML-Patch-Ops processing on a server". If diff-processing is an optional feature on the server what's left from the format spec ? The <document> element doesn't indicate then patching, i.e. <add>, <remove> or <replace> doesn't exist in notification bodies (see the figure 1 of the format spec). So the only available fall-back is that clients MUST then understand http retrievals of documents when document creations or modifications will happen. And no other harm will happen except you'll lose some optimizations. And still a reasonable aggregate mode is more complex than xcap-patching mode which should be explicitly stated though it is self-evident. So when notifier decides to simplify the implementation burden, support for aggregation is dropped first and then xcap-patching.
Having a really useful rejection handling is a nightmare of its own... e.g. how to signal event parameter errors or what to do with conflicts, 409 non-existing for sip ? So the status quo is to do what has been done before, be pragmatic, which means: subscriber sends a request and notifier fills in what it can provide. The client is then responsible for doing requests with http, and determining what might be wrong when it doesn't get what it is expecting. This is usually a programming error, i assume, and clients must be clever enough to make the right decisions or have some fall-backs. That being said, i hardly think you could fix things without changing the code when these kind of errors happen. But anyways, some clarification must be added to remove this implicit interpretation. > >>>>> - 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 > great. thanks, jari _______________________________________________ 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
