ext Dean Willis wrote:
On Apr 24, 2007, at 1:41 AM, Jari Urpalainen wrote:
A concern was raised about the initial sync stage, so what could be
less sucking options ? Actually there's a need for versioned
retrieval of documents based on their ETags which would cleanly solve
this issue.
One option would be that servers would make temporary copies of
subscribed documents during the initial subscription, and these
temporary URIs along with the real URIs would be carried within the
body of xcap-diff document. The client would need to fetch then these
versioned resources based on temporary URIs. For the server
implementation this is ugly and somewhat error prone, i.e. e.g. when
to remove these temporary stuff.
A better option would be to have "real" versioning on the xcap
server. So one could retrieve documents e.g. by requesting GET
/resource-lists/joe/index?etag=sfsdf343ds. So client would really
request the ETag based versioned resource. What's nice here that
you could add rfc3229 semantics here quite easily also, i.e. the
client could say: "I have this xyz version, give me the patch to the
latest version". Of course, for the server this would be yet another
additional requirement for the already pretty complex xcap picture.
So what am I missing here ? This issue is sad in a sense that it is
once again those cases which rarely exist in practice, a real corner
case that is.
dude, I am SO not wanting to go back to OMA with an LS that says
"Sorry, we need to revise XCAP to do full-blown versioning to meet
your needs".
right, well I just gave some alternatives (there are others as well...).
So I'm not really proposing this, just trying to move forward.
What ARE we going to tell them?
Let's do what the minutes say, move this to sip(ping) wg item or do the
informational thing, i.e. act ;-). And continue solving this issue.
My understanding was we were going to do a fairly straightforward
event package that met their needs, based on your old draft. As I
remember, this simply made it necessary to do a full get of the
most-current if you lost synch. Is this not acceptable?
--
Dean
I think what is written in the spec is the simplest solution, during the
initial sync stage the client just skips those possible already applied
patches, just some simple buffering (if even needed) on the client side.
Also during the subscription time it may happen that you have to
retrieve full docs. And then this ugly thing happens that you need two
round trips for this aggregation mode, but the alternatives aren't
better unless I'm missing here something. And once again this case
rarely exist in practice but implementers (especially clients) must be
aware of this. So it is anticipated that you can usually start with the
aggregation mode straight away, but it may fail. If it does, then retry
with this ugly mode. As I said versioning is imo the proper way to make
this cleanly work, but it does have other consequences...
br,
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
