Subject: [Sip] RE: Questions on XCAP Diff Event draft

From: "Sofie Lassborn (TN/EAB)" <[email-masked]>
Date: Mon, 18 Jun 2007 09:52:54 +0200

Hi Jari,

I have some more questions regarding the last paragraph. Please see
below.

Best regards,
Sofie 

-----Original Message-----
From: Jari Urpalainen [mailto:[email-masked]] 
Sent: den 18 maj 2007 09:12
To: Sofie Lassborn (TN/EAB)
Cc: [email-masked]
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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Jari Urpalainen <[email-masked]>
Date: Tue, 19 Jun 2007 11:30:42 +0300

> wants to send all patches separately?
Sorry, probably i've been unclear on this. Rate limitation/throttle 
combined with patching is indeed challenging but doable. And even you 
can combine filtering here in addition to standard authorization so the 
complexity begins to be quite high (although i could say that even the 
basic authorization handling is hard enough to implement, be it on 
server or client ;-)). So the notifier must be well aware of the client 
state all the time, it is not that one could simply drop some events, so 
"throttle engine" and patching process must co-operate properly. 
However, related to patching/syncing the key issue is that after the 
notifier sends only the http references, it doesn't have the knowledge 
when the client eventually has read the  relevant resource content. So 
once the notifier does this reference sending, it fall backs into the 
"xml-patching" mode with full etag change history, i.e. aggregation 
_may_ cause similar trouble than during the initial sync. But 
subscription refresh (or versioning support in xcap  server ;-)) would 
similarly solve this.

But anyways, i think that i'll  just submit a new version with some 
clarifications (and better examples) ?
thanks, jari