Hi Jari, I have some thoughts and questions regarding the XCAP Diff Event draft (draft-urpalainen-sip-xcap-diff-event-01). What will the notification look like if a requested document cannot be found? No body or only <xcap-diff> element? What does it mean if a notification contains the document element with doc-selector but no etag attributes? OMA has implemented an architecure where the XCAP server has been split up into so called XCAP Document Management Servers (XDMS). Each XDMS handles separate AUIDs. If a subscription is for several documents distributed over several XDMSes (different auids), what should then the notification look like if there are some documents that don't exist or directories that are empty and there are some documents that cannot be reached because one XDMS does not answer? According to RFC 3265 the "pending" value of the Subscripton-State header indicates that the subscription has been received, but that policy information is insufficient to accept or deny the subscription at this time. Is the intention in section 4.7 in the draft that the subscription state should be pending if the resource the subscription is for cannot be found? What would then the subscription state be for a subscription for white space separated resources where some can be found and some cannot be found? Generation of a "first full response" notification might take time especially if the subscription is for several AUIDs, spread over several XCAP Document Management Servers, at the same time. Is there a need for an "initial" initial notification that may be sent to the subscriber before the "full response" can be sent? Chapter 4.7, second paragraph It is unclear to me what is meant by "...it MUST fall back to sending all component changes again for this resource." Is the intention that the server shall send a "full response" as in an initial notification (my preferred interpretation)? Or is the intention that the server shall send several notifications with the patches not aggregated? Best regards, Sofie
_______________________________________________ Sip mailing list https://www1.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
