new webdav sync draft

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

new webdav sync draft

Arnaud Quillaud
Hello,

I have just submitted a new version of the webdav sync draft (
http://www.ietf.org/id/draft-daboo-webdav-sync-02.txt ).

This draft addresses several, if not all, of the comments from the last
version (change history is part of the draft).

The open issues section still contains 2 significant items, to be discussed.

Comments welcome...

Arnaud Quillaud

Reply | Threaded
Open this post in threaded view
|

Re: [VCARDDAV] [caldav] new webdav sync draft

Julian Reschke
Andrew McMillan wrote:
> ...
> In 4.2, under 'Marshalling' it states:
>
>         The request URI MUST be a collection.  The request body MUST be
>         a DAV:sync-collection XML element (see Section 6.1), which MUST
>         contain one DAV:sync-token XML element, and optionally a
>         DAV:propstat XML element.
> ...

Nit: s/be a collection/identify a collection/

I confess I haven't looked at this closely yet, but why is it defining
elements in the DAV: namespace?

BR, Julian

Reply | Threaded
Open this post in threaded view
|

Re: [caldav] [VCARDDAV] new webdav sync draft

Cyrus Daboo-2
Hi Julian,

--On November 20, 2009 8:08:41 AM +0100 Julian Reschke
<[hidden email]> wrote:

>>         The request URI MUST be a collection.  The request body MUST be
>>         a DAV:sync-collection XML element (see Section 6.1), which MUST
>>         contain one DAV:sync-token XML element, and optionally a
>>         DAV:propstat XML element.
>> ...
>
> Nit: s/be a collection/identify a collection/
>
> I confess I haven't looked at this closely yet, but why is it defining
> elements in the DAV: namespace?

This is generic to WebDAV, not specific to CardDAV or CalDAV. So use of
DAV: is justified.

--
Cyrus Daboo


Reply | Threaded
Open this post in threaded view
|

Re: [caldav] [VCARDDAV] new webdav sync draft

Julian Reschke
Cyrus Daboo wrote:
> ...
>> I confess I haven't looked at this closely yet, but why is it defining
>> elements in the DAV: namespace?
>
> This is generic to WebDAV, not specific to CardDAV or CalDAV. So use of
> DAV: is justified.
> ...

<http://greenbytes.de/tech/webdav/rfc4918.html#rfc.section.21.1>:

"Creation of identifiers in the "DAV:" namespace is controlled by the IETF."

So it's not relevant whether something is generic. What's important is
that there's IETF consensus to add new names to the namespace.

I'm not saying this can't be the case here, but I think the proper way
would be to start with a proposal in a custom namespace, and then switch
to the DAV: namespace once it's clear that consensus has been achieved.

BR, Julian

Reply | Threaded
Open this post in threaded view
|

Re: [VCARDDAV] [caldav] new webdav sync draft

Arnaud Quillaud
In reply to this post by Arnaud Quillaud
On 11/19/09 11:01 PM, Andrew McMillan wrote:
On Thu, 2009-11-19 at 18:20 +0100, Arnaud Quillaud wrote:
  
Hello,

I have just submitted a new version of the webdav sync draft ( 
http://www.ietf.org/id/draft-daboo-webdav-sync-02.txt ).

This draft addresses several, if not all, of the comments from the last 
version (change history is part of the draft).

The open issues section still contains 2 significant items, to be discussed.

Comments welcome...
    
Hi Arnaud,

I have added support for this as at draft 1, and I see nothing in draft
2 to contradict what I have done other than clarifications and further
questions, so that's great.


In 4.2, under 'Marshalling' it states:

        The request URI MUST be a collection.  The request body MUST be
        a DAV:sync-collection XML element (see Section 6.1), which MUST
        contain one DAV:sync-token XML element, and optionally a
        DAV:propstat XML element.

This looks like an error, and that the optional element should be a
DAV:prop element rather than a DAV:propstat, which is the response.
  
Fixed. Thks.

Additionally, the examples shown seem to only request 'DAV:getetag' to
be returned, but it seems to me that in synchronising a collection that
it would be valuable for the report to return other properties.
  
Yes. I could add a proprietary dead property in the example to make it more clear.
In particular when synchronising a calendar collection it would be
desirable for the report to be able to return 'caldav:calendar-data',
which in many cases would then save the further round-trip of a
calendar-multiget report following this report.  I assume there would be
similar advantages in retrieving the actual changed data in other 

Is it intended that this sort of activity is OK?  In my implementation I
have assumed that any property might be requested - not limited to
DAV:getetag - but from reading the examples it seems to me that it could
be misinterpreted conservatively as only allowing requests for
DAV:getetag.

  
A client may ask for any property... as long as it is defined as such... calendar-data is not one of them. See http://tools.ietf.org/html/rfc4791#section-9.6 :
<<
However, the CALDAV:calendar-data XML element is
      not a WebDAV property and, as such, is not returned in PROPFIND
      responses
>>

Thanks for your feedback.

Arnaud

PS: I should have mentioned this upfront but we may want to move further discussion to theĀ  [hidden email] mailing list only to avoid too much cross posting.
Reply | Threaded
Open this post in threaded view
|

Re: [VCARDDAV] [caldav] new webdav sync draft

Julian Reschke
In reply to this post by Julian Reschke
Alexey Melnikov wrote:

> ...
>> <http://greenbytes.de/tech/webdav/rfc4918.html#rfc.section.21.1>:
>>
>> "Creation of identifiers in the "DAV:" namespace is controlled by the
>> IETF."
>>
>> So it's not relevant whether something is generic. What's important is
>> that there's IETF consensus to add new names to the namespace.
>>
>> I'm not saying this can't be the case here, but I think the proper way
>> would be to start with a proposal in a custom namespace, and then
>> switch to the DAV: namespace once it's clear that consensus has been
>> achieved.
>
> This sounds like a question to bring during IETF LC. If the document
> fails to reach IETF consensus, then the prefix can be changed.
> Unless you are concerned about early implementations of the draft.
> ...

Not sure.

What you say makes it sound as if any document published by the IETF can
use the DAV: namespace; I think the intent of RFC 4918 was something
else (but I may be misinterpreting it): the default extension point for
WebDAV (both in RFC 4918 and 2518) is to put extensions into a
*different* namespace.

So far we have made exceptions in cases where the specs actually started
as WG deliverables (redirect, search, or bind), were proposed by another
WG (MKCOL extension), or were a *really* minor extension to an existing
WebDAV spec (WebDAV Current Principal Extension).

The concern about early implementations is there as well, of course.

Best regards, Julian



Reply | Threaded
Open this post in threaded view
|

Re: [caldav] [VCARDDAV] new webdav sync draft

Andrew McMillan-5
In reply to this post by Arnaud Quillaud
On Fri, 2009-11-20 at 17:13 +0100, Arnaud Quillaud wrote:
> On 11/19/09 11:01 PM, Andrew McMillan wrote:
> >
> > In particular when synchronising a calendar collection it would be
> > desirable for the report to be able to return 'caldav:calendar-data',
> > which in many cases would then save the further round-trip of a
> > calendar-multiget report following this report.  I assume there would be
> > similar advantages in retrieving the actual changed data in other extensions.

 
> A client may ask for any property... as long as it is defined as
> such... calendar-data is not one of them. See
> http://tools.ietf.org/html/rfc4791#section-9.6 :
> <<
> However, the CALDAV:calendar-data XML element is
>       not a WebDAV property and, as such, is not returned in PROPFIND
>       responses
> >>

Ah, what a shame.  Can I take it from this that CardDAV will also suffer
from this limitation?


> PS: I should have mentioned this upfront but we may want to move
> further discussion to the  [hidden email] mailing list only to
> avoid too much cross posting.

OK, I have done so.

Cheers,
                                        Andrew.

------------------------------------------------------------------------
http://andrew.mcmillan.net.nz/                     Porirua, New Zealand
Twitter: _karora                                  Phone: +64(272)DEBIAN
Facts do not cease to exist because they are ignored. -- Aldous Huxley,
                         "Proper Studies", 1927

------------------------------------------------------------------------


signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [caldav] [VCARDDAV] new webdav sync draft

Julian Reschke
Andrew McMillan wrote:

> On Fri, 2009-11-20 at 17:13 +0100, Arnaud Quillaud wrote:
>> On 11/19/09 11:01 PM, Andrew McMillan wrote:
>>> In particular when synchronising a calendar collection it would be
>>> desirable for the report to be able to return 'caldav:calendar-data',
>>> which in many cases would then save the further round-trip of a
>>> calendar-multiget report following this report.  I assume there would be
>>> similar advantages in retrieving the actual changed data in other extensions.
>
>  
>> A client may ask for any property... as long as it is defined as
>> such... calendar-data is not one of them. See
>> http://tools.ietf.org/html/rfc4791#section-9.6 :
>> <<
>> However, the CALDAV:calendar-data XML element is
>>       not a WebDAV property and, as such, is not returned in PROPFIND
>>       responses
>
> Ah, what a shame.  Can I take it from this that CardDAV will also suffer
> from this limitation?
> ...

Can't resist: "I told you so". Pseudo-properties are bad; they require
more special cases, create ambiguities and confusion.

 > ..

BR, Julian

Reply | Threaded
Open this post in threaded view
|

Re: [caldav] [VCARDDAV] new webdav sync draft

Andrew McMillan-5
On Sat, 2009-11-21 at 07:56 +0100, Julian Reschke wrote:

> Andrew McMillan wrote:
> > On Fri, 2009-11-20 at 17:13 +0100, Arnaud Quillaud wrote:
> >> On 11/19/09 11:01 PM, Andrew McMillan wrote:
> >>> In particular when synchronising a calendar collection it would be
> >>> desirable for the report to be able to return 'caldav:calendar-data',
> >>> which in many cases would then save the further round-trip of a
> >>> calendar-multiget report following this report.  I assume there would be
> >>> similar advantages in retrieving the actual changed data in other extensions.
> >
> >  
> >> A client may ask for any property... as long as it is defined as
> >> such... calendar-data is not one of them. See
> >> http://tools.ietf.org/html/rfc4791#section-9.6 :
> >> <<
> >> However, the CALDAV:calendar-data XML element is
> >>       not a WebDAV property and, as such, is not returned in PROPFIND
> >>       responses
> >
> > Ah, what a shame.  Can I take it from this that CardDAV will also suffer
> > from this limitation?
> > ...
>
> Can't resist: "I told you so". Pseudo-properties are bad; they require
> more special cases, create ambiguities and confusion.
Conceptually, the idea of the actual data just being one element of the
meta-data doesn't seem unreasonable.

I have to confess that in my implementations to date I had just assumed
that the data is only one property within the schema, and it's certainly
much simpler for me to code it that way in my own application.

For webdav sync I would suggest that the caldav:calendar-data and
carddav:address-data (and perhaps other pseudo-properties I don't know
about) should be available to the sync report in the same way as they
are for the caldav:calendar-multiget and carddav:addressbook-multiget
reports.

It would also be nice to see a generic DAV:multiget report replacing the
*-multiget reports, since they don't seem to do anything particularly
special within their respective namespaces.

Cheers,
                                        Andrew McMillan.

------------------------------------------------------------------------
http://andrew.mcmillan.net.nz/                     Porirua, New Zealand
Twitter: _karora                                  Phone: +64(272)DEBIAN
       The truth is rarely pure, and never simple. -- Oscar Wilde
------------------------------------------------------------------------


signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [caldav] [VCARDDAV] new webdav sync draft

Julian Reschke
Andrew McMillan wrote:
> ...
>> Can't resist: "I told you so". Pseudo-properties are bad; they require
>> more special cases, create ambiguities and confusion.
>
> Conceptually, the idea of the actual data just being one element of the
> meta-data doesn't seem unreasonable.
> ...

Yes, that is true. But in that case, it should behave the same
everywhere, be it PROPFIND, PROPPATCH, REPORT or SEARCH.

> I have to confess that in my implementations to date I had just assumed
> that the data is only one property within the schema, and it's certainly
> much simpler for me to code it that way in my own application.

Indeed.

> ...

BR, Julian

Reply | Threaded
Open this post in threaded view
|

Re: new webdav sync draft

Helge Hess
In reply to this post by Arnaud Quillaud
Hi,

Arnaud asked me on my opinion on the following ...

On 19.11.2009, at 18:20, Arnaud Quillaud wrote:
> I have just submitted a new version of the webdav sync draft (http://www.ietf.org/id/draft-daboo-webdav-sync-02.txt ).

=>
>    2.  Do clients really need to be notified that a resource was created
>        versus modified ?  They should be able to figure that out by
>        looking at the state of their current cache.  If this information
>        is not necessary, the response would not need to contain a DAV:
>        status along with the DAV:propstat.  This would allow the use of
>        a regular multistatus (simply extended with a sync-token
>        element).

Its not crucial, but helpful. If I don't know that a resource is new, I obviously have to scan the cache to check for that. Which is significantly more expensive than a simple INSERT (status = 'N', url=abc) ...
Given that WebDAV sync is supposed to improve sync with large folders, the 'check' time consumption becomes more relevant too ...

The question is whether I would do the scan anyways, just to be sure there are no DUPs. Probably! :-) [either me, or a database unique constraint doing effectively the same thing]

So I guess either way is fine with me with a slight preference towards having a separate 'created'. If that would be significantly more difficult for servers, lets drop it, if not, lets preserve it.

Greets,
  Helge


Reply | Threaded
Open this post in threaded view
|

Re: [caldav] new webdav sync draft

Arnaud Quillaud
On 6/12/09 22:34, Helge Hess wrote:
Hi,

Arnaud asked me on my opinion on the following ...

On 19.11.2009, at 18:20, Arnaud Quillaud wrote:
  
I have just submitted a new version of the webdav sync draft (http://www.ietf.org/id/draft-daboo-webdav-sync-02.txt ).
    

=>
  
   2.  Do clients really need to be notified that a resource was created
       versus modified ?  They should be able to figure that out by
       looking at the state of their current cache.  If this information
       is not necessary, the response would not need to contain a DAV:
       status along with the DAV:propstat.  This would allow the use of
       a regular multistatus (simply extended with a sync-token
       element).
    

Its not crucial, but helpful. If I don't know that a resource is new, I obviously have to scan the cache to check for that. Which is significantly more expensive than a simple INSERT (status = 'N', url=abc) ...
Given that WebDAV sync is supposed to improve sync with large folders, the 'check' time consumption becomes more relevant too ...

The question is whether I would do the scan anyways, just to be sure there are no DUPs. Probably! :-) [either me, or a database unique constraint doing effectively the same thing]
  
Maximilian Odendahl who is working on the Symbian CalDAV connector gave us the same feedback.
And it looks like the Inverse Edition of Mozilla Lightning is doing the same thing (i.e. scan regardless of the status sent by the server).

Arnaud
So I guess either way is fine with me with a slight preference towards having a separate 'created'. If that would be significantly more difficult for servers, lets drop it, if not, lets preserve it.

Greets,
  Helge



_______________________________________________
caldav mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/caldav
  

Reply | Threaded
Open this post in threaded view
|

Re: [caldav] new webdav sync draft

Cyrus Daboo-2
In reply to this post by Helge Hess
Hi Helge,

--On December 6, 2009 10:34:33 PM +0100 Helge Hess
<[hidden email]> wrote:

> Its not crucial, but helpful. If I don't know that a resource is new, I
> obviously have to scan the cache to check for that. Which is
> significantly more expensive than a simple INSERT (status = 'N', url=abc)
> ... Given that WebDAV sync is supposed to improve sync with large
> folders, the 'check' time consumption becomes more relevant too ...
>
> The question is whether I would do the scan anyways, just to be sure
> there are no DUPs. Probably! :-) [either me, or a database unique
> constraint doing effectively the same thing]
>
> So I guess either way is fine with me with a slight preference towards
> having a separate 'created'. If that would be significantly more
> difficult for servers, lets drop it, if not, lets preserve it.

Just to clarify - right now the spec says that a resource that is deleted
and re-created is reported as "new" if a sync-token prior to the deletion
is given in the REPORT. In that case, were you to do an INSERT using the
UID as a unique key for that reported item you would get an error as the
client already has the old copy cached. So a "simple" INSERT isn't going to
work in that case.

Now we could change that behavior to have the deleted/re-created resource
reported as "modified" rather than "new". However, I think the reality is
that clients are going to have to accept the fact that there may be false
positives (though hopefully never false negatives) so the prudent thing to
do is always do a proper match between the server reported results and the
full cache they currently have. Maybe we need a statement clarify that.

--
Cyrus Daboo


Reply | Threaded
Open this post in threaded view
|

Re: [caldav] new webdav sync draft

Helge Hess
On 07.12.2009, at 16:55, Cyrus Daboo wrote:
> Just to clarify - right now the spec says that a resource that is deleted and re-created is reported as "new" if a sync-token prior to the deletion is given in the REPORT.

Ah, OK. I would have expected a "deleted" and a "new" entry in such a case.

Now thinking about it, I think it might be an issue if a resource in the cache is replaced with an entirely new resource.
Eg the client might have (real world: is likely to have) extra client-side data which is only valid for the 'old' resource.

But then, the client can't discover that specific situation with the regular PROPFIND either. And it won't be terribly common, as new URLs usually change in most systems.

> However, I think the reality is that clients are going to have to accept the fact that there may be false positives (though hopefully never false negatives) so the prudent thing to do is always do a proper match between the server reported results and the full cache they currently have. Maybe we need a statement clarify that.

I think performance might be a real world issue with restricted clients (mobile) and large folders, where a key lookup does have a cost.

Anyways, I stick to my opinion, slightly extended: Either way is fine with me with a slight preference towards having a separate 'created' AND 'deleted'. If that would be significantly more difficult for servers, lets drop it, if not, lets preserve it.

:-)

Greets,
  Helge


Reply | Threaded
Open this post in threaded view
|

Re: [VCARDDAV] [caldav] new webdav sync draft

Julian Reschke
Helge Hess wrote:
> On 07.12.2009, at 16:55, Cyrus Daboo wrote:
>> Just to clarify - right now the spec says that a resource that is deleted and re-created is reported as "new" if a sync-token prior to the deletion is given in the REPORT.
>
> Ah, OK. I would have expected a "deleted" and a "new" entry in such a case.
>
> Now thinking about it, I think it might be an issue if a resource in the cache is replaced with an entirely new resource.
> Eg the client might have (real world: is likely to have) extra client-side data which is only valid for the 'old' resource.
>
> But then, the client can't discover that specific situation with the regular PROPFIND either. And it won't be terribly common, as new URLs usually change in most systems.

It could if the server supports DAV:resourceid. (see
draft-ietf-webdav-bind).

> ...

BR, Julian

Reply | Threaded
Open this post in threaded view
|

Re: [VCARDDAV] [caldav] new webdav sync draft

Andrew McMillan-5
In reply to this post by Helge Hess
On Mon, 2009-12-07 at 21:43 +0100, Helge Hess wrote:
> On 07.12.2009, at 16:55, Cyrus Daboo wrote:
> > Just to clarify - right now the spec says that a resource
> > that is deleted and re-created is reported as "new" if a
> > sync-token prior to the deletion is given in the REPORT.
>
> Ah, OK. I would have expected a "deleted" and a "new" entry in such a
> case.

Yes, and in fact I revisited my code for this situation after reading
Cyrus' note and discovered that I had implemented that particular case
incorrectly in exactly that way.

Sending a DELETE followed by a CREATE in this situation would seem to
more clearly communicate the real-world action, and while there will be
times when the sync report simply ends up prompting the client to
perform a full sync, reducing the frequency of those situations should
also be a goal.

On the other hand if we consider this analogous to two consecutive
PROPFIND requests providing a difference of 'that resource is modified'
which clients must necessarily have to cope with already, then it would
be better to send a 'resource modified' in the sync response.

As it stands, it seems to me to be a gotcha and an inevitable a source
of bugs for any client side implementation which sees the create and
makes the easy assumption that it means no resource existed in a local
cache.


> Anyways, I stick to my opinion, slightly extended: Either way is fine
> with me with a slight preference towards having a separate 'created'
> AND 'deleted'. If that would be significantly more difficult for
> servers, lets drop it, if not, lets preserve it.

That does seem the safest approach.

Regards,
                                Andrew McMillan.


------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com                            +64(272)DEBIAN
        Don't you wish you had more energy... or less ambition?
------------------------------------------------------------------------


signature.asc (205 bytes) Download Attachment