Miguel Garcia wrote: > Inline too, only points that require further discussion. > > Jari Urpalainen wrote: >> responses inline >> >> Miguel Garcia wrote: >>> Hi: >>> >>> Here are some comments to the XCAP event package, in sequential order. >>> >>> >>> - Introduction, 2nd paragraph. Indicate that the subscription can be >>> applied to "several documents". There is a reference to RFC 4918 >>> that I don't get it. I don't understand what is this reference, so >>> better remove it. >> well the document uses the collection as defined by rfc4918 (and with >> similar semantics as well). > > So, RFC 4918 defines collection as: > > Collections: The ability to create sets of documents and to retrieve > a hierarchical membership listing (like a directory listing in a file > system). > > If the definition is correct for this document, I recommend to add a > note in Section 3 saying: This document reuses the following term from > RFC 4918: Collections. > ok. >>> - Introduction... More than an Introduction, the third paragraph is >>> an Overview of Operation. Perhaps this paragraph should be promoted >>> to its own section (titled Overview of operation), and should have >>> an overview of what the draft does: The SUBSCRIBE contains a list, >>> the first NOTIFY contains references, further NOTIFYs contain >>> changes according to the selected diff-processing model, which can >>> be this and that... ETags management, etc. >>> >> developer question, how does it influence the _running_ code ;-) ? >> Seriously, one could really improve the text... > > If the developer does not get the full picture he will write shit buggy > code, so, I believe this is of utmost importance. Remember that not > every developer will be an authority in XCAP, WebDav, and SIP. > unfortunately implementing this _requires_ basic understanding of these, it is far from being an easy task, and if you have to start from scratch... > >>> >>> - 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 ;-) >> >>> >>> - Section 4.3. This section answers better the title of Section 4.1: >>> XCAP-Diff processing. However, in the first paragraph, the document >>> should clarify: a) what are the differences between the 3 models; b) >>> what is NOT included in notifications for each of the models. >>> >> see above, so patches may not ever be included. > > That is not my point. My point is that the text should describe how the > 3 models work by saying what they share in common and the differences > among them. I think this is not clearly indicated now point taken > . > >>> - Section 4.4, 1st paragraph, the text reads: >>> >>> When generating a subscribe request, the subscriber needs to define >>> the resources it is interested in getting information. This can be >>> done simply by sending a URI list to the SIP notifier. >>> >>> This can be done???? I am missing some stronger language, in >>> particular, some language that clearly defines that there could be >>> other potential mechanisms (SUBSCRIBE URI-list servers), but these >>> aren't considered in this document. I propose: >>> >>> When generating a SUBSCRIBE request, the subscriber needs to define >>> the resources it is interested in getting information. This >>> document provides a mechanism to include lists of URIs in the >>> SUBSCRIBE request: An XCAP resource list according to the format >>> specified in RFC 4826 [RFC2836] is included as a body of the >>> SUBSCRIBE request that creates the subscription. Each of these URIs >>> in the XCAP resource list represents an XCAP resource for which >>> notification of changes are requested. >> looks better though collections are not xcap resources. > > s/XCAP resource/XCAP resource or collection > >>> - 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 ...) >>> - Section 4.7, 4th paragraph says: >>> >>> However, the notifier MUST support XCAP component >>> subscriptions. >>> >>> So, is there another alternative? I mean, this gives me the >>> impression like if XCAP components were an option in XCAP, and >>> therefore, subscriptions to those XCAP components were also >>> optional. Is this the case? >>> >> the format spec support component subscriptions but you _could_ >> define an event package based on the format spec which needs not to >> support xcap component subscriptions, so the statement is better to >> stay there. > > Perhaps the text that you just wrote could be added as a note, so it > will help the reader to better understand the concept. note would be fine > > >>> - Section 6, IANA considerations section fails to mention >>> that this registration is about "SIP". So, >>> first, I would remove the first two sentences, and the headline 6.1, >>> and just would leave: >>> >>> >>> This specification instructs IANA to add a new event package to the >>> SIP Event Types Namespace registry. The new data to be added is: >>> >>> Package Name Type Contact Reference >>> ------------- -------- ------- --------- >>> xcap-diff package IETF SIPPING Working Group [RFCXXXX] >>> <sipping&ietf.org> >>> >>> >> template better yes, though this is sip wg ;-) > > Ouch... right... SIP, not SIPPING. > > /Miguel > 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
