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 [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
