[Sip] Re: Questions on XCAP Diff Event draft

[Jari Urpalainen <[e-mail]>]

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"

thanks,
Jari


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip