Hi Jari, I have some more questions regarding the last paragraph. Please see below.
Best regards, Sofie -----Original Message----- From: Jari Urpalainen [mailto:[EMAIL PROTECTED] Sent: den 18 maj 2007 09:12 To: Sofie Lassborn (TN/EAB) Cc: [email protected] Subject: Re: Questions on XCAP Diff Event draft ext Sofie Lassborn (TN/EAB) wrote: > > 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? > good catch, actually the current xcap-diff format requires at least one document update (but it should be fixed), so either of your proposals should work. > > What does it mean if a notification contains the document element with > doc-selector but no etag attributes? > This is not defined in xcap-diff format, as it is sort of an error case with documents. With xcap-component subscription it is somewhat vague. When etags are included, you could e.g. do a conditional replace based on them. So perhaps it is better to add etags always, certainly I don't want any negotiations about this. > > 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? > Good question. I could do a counterquestion, why did OMA do that, and instead let the implementations figure these out ? I mean this introduces a lot of complexity and several difficult error cases. But the intention here (in the i-d) is to do what is typical in the ietf, i.e. just to define the interface and let the implementations do the rest. But back to the question, the i-d says that you send in the initial notify request what you can "read", so probably you could still compose this from separate responses from several xdms, as results from different auids should be orthogonal. But hey, I really wouldn't personally like to implement it ;-). > > 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? > While using "pending" I was wandering that I'll produce somewhat confusing text..., I'll try to clarify this. > > 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? > In practice, I wouldn't anticipate that you would need this empty body or neutral body notify, i.e. clients will most likely keep the state information based on the response of subscribe. But the spec allows to use it although null body interpretation with content-type header _is_ interesting. > > 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 > The latter, after sending the http reference, the server does not know when the client has really read the content, thus no aggregation allowed with "rapidly changing resources" [Sofie wrote:] I see aggregation as very useful in conjuction with rate limitation and throttle. An issue arrises though when a notification with aggregated patches becomes too large. According to you the notifier should then send all patches separately in several notifications but if rate limitation or throttle is being used the client might never catch up. Could it instead be the choise of the notifier if it wants to send a notification with only the document link (content indirection) or if it wants to send all patches separately? thanks, Jari _______________________________________________ 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
