Hi David, thanks for your review. Sorry for the delay answering, but as a result of the IETF last call, I had to modify the partial notifications mechanism in the draft. It used to be based on XCAP diff and now is based on XML patch operations. You may want to re-review Section 6 of the draft, which has been rewritten:
http://users.piuha.net/gonzalo/temp/draft-ietf-sipping-pending-additions-04.txt > 5.1.2. SUBSCRIBE Bodies > > A SUBSCRIBE for Pending Additions events MAY contain a body. This > body would serve the purpose of filtering the subscription. The > definition of such a body is outside the scope of this specification. > > How is that supposed to be interoperable? A better approach > would be to prohibit bodies now and allow a future specification > to define them. this has been the text used in most of the event packages defined in SIP. Subscription filtering is something that will most likely be defined in the future as a general feature, usable by all (or most) event packages. I will leave the text as is, since there has been strong support from the community to use this type of text in many event packages. > 5.1.7. Subscriber Processing of NOTIFY Requests > > NOTIFY requests contain full state. The subscriber does not need to > perform any type of information aggregation. > > This text doesn't explain "the process followed by the > subscriber upon receipt of a NOTIFY request, including any > logic required to form a coherent resource state (if > applicable)" (see Section 4.4.8 of RFC 3265). This text > needs to be rewritten and expanded. When a subscriber receives a full notification, it does not need to do anything. All the information is there. It is typical RFC 3265 behavior. However, the process to follow when partial notifications are used needs to be specified. Now the text reads as follows: NOTIFY requests contain full state. The subscriber does not need to perform any type of information aggregation. Section 6 discusses the use of the Pending Additions event package with partial notifications. Thanks, Gonzalo _______________________________________________ Gen-art mailing list [email protected] http://www.ietf.org/mailman/listinfo/gen-art
