headers
Cyrus Daboo | 9 Mar 2009 19:15
Favicon

Re: [VCARDDAV] WGLC comments on draft-ietf-vcarddav-webdav-mkcol-03, was: vcarddav WGLC on draft-ietf-vcarddav-{carddav, mkcol}

Hi Julian,

--On February 25, 2009 4:13:24 PM +0100 Julian Reschke 
<julian.reschke <at> gmx.de> wrote:

> below are some comments on draft-ietf-vcarddav-webdav-mkcol-03:
>
> Section 1., paragraph 2:

> s/proposes/defines/

Fixed.

> Section 2., paragraph 4:

> Actually, I'd recommend to just borrow the relevant paragraphs from
> <http://tools.ietf.org/html/rfc5323#section-1.4>. See also older message
> from Nov 2008:
> <http://www.ietf.org/mail-archive/web/vcarddav/current/msg00702.html>.

OK - I replaced the existing text with that from 5323 almost verbatim.

> Section 3., paragraph 2:

> s/MAY/may/ - this doesn't deserve RFC2119 terminology; there may be
> similar places...

Fixed.

> Section 5.2., paragraph 5:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Cyrus Daboo | 10 Mar 2009 15:09
Favicon

draft-daboo-webdav-sync-01

Hi folks,
I have posted an update for the webdav-sync extension: 
<http://tools.ietf.org/html/draft-daboo-webdav-sync-01>. This is mostly as 
refresh of the original -00 with a few references updated. The goal is to 
restart discussion of this specification as I have been getting quite a few 
enquiries from folks interested in implementing something like this now.

For now let is keep primary discussion of this document on 
w3c-dist-auth <at> w3.org. CalDAV and CardDAV have been cc'd as this is of 
interest in those areas too.

--

-- 
Cyrus Daboo

_______________________________________________
ietf-caldav mailing list -- ietf-caldav <at> osafoundation.org
See http://ietf.webdav.org/caldav/ for more CalDAV resources
http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
Permalink | Reply | 0 comments |
headers
Arnaud Quillaud | 11 Mar 2009 11:16
Picon

depth in draft-daboo-webdav-sync-01

Hello,

In Section 4.2 
(http://tools.ietf.org/html/draft-daboo-webdav-sync-01#section-4.2), the 
response is defined as:

<<

The response body for a successful DAV:sync-collection REPORT
      request MUST contain a DAV:sync-response element for each resource
      that was created, has changed or been deleted since the last
      synchronization operation as specified by the DAV:sync-token
      provided in the request.

 >>

Given that the depth header should be ignored, and given the ambiguity 
of the term "resource", it would be worth mentioning that this applies 
only to non-collection resources directly contained in the target 
collection.
In other words, creation/modification/deletion of subcollections and 
their children should not be included.

Arnaud
Permalink | Reply | 1 comment |
headers
Arnaud Quillaud | 11 Mar 2009 11:48
Picon

use of DAV:valid-sync-token - need for another precondition in draft-daboo-webdav-sync-01

Hello,

In the overview 
(http://tools.ietf.org/html/draft-daboo-webdav-sync-01#section-4.1), it 
is mentioned that the server may return an error when a token is out of 
date while in the precondition section, the only precondition defined is:

<<

(DAV:valid-sync-token): The DAV:sync-token element value MUST map
      to a valid token previously returned by the server;

 >>

Depending on the meaning you give to the term "valid", an out of date 
token can be seen as "a valid token previously returned by the server", 
in which case this precondition does not apply to out of date token.

 So we could either add a DAV:no-expired-sync-token precondition or 
change the definition of the existing one to include tokens previously 
returned by the server but which have expired.

Should we add a "Use with" in the precondition definition as in 
(http://tools.ietf.org/html/rfc4918#section-16) and would it be 403 or 
409 ? In any case, it would be worth mentioning that the client can 
solve this precondition failure by initiating a full sync.

Arnaud Q
(Continue reading)

Permalink | Reply | 0 comments |
headers
Julian Reschke | 11 Mar 2009 11:52
Picon
Picon

Re: depth in draft-daboo-webdav-sync-01

Arnaud Quillaud wrote:
> Hello,
> 
> In Section 4.2 
> (http://tools.ietf.org/html/draft-daboo-webdav-sync-01#section-4.2), the 
> response is defined as:
> 
> <<
> 
> The response body for a successful DAV:sync-collection REPORT
>      request MUST contain a DAV:sync-response element for each resource
>      that was created, has changed or been deleted since the last
>      synchronization operation as specified by the DAV:sync-token
>      provided in the request.
> 
>  >>
> 
> Given that the depth header should be ignored, and given the ambiguity 
> of the term "resource", it would be worth mentioning that this applies 
> only to non-collection resources directly contained in the target 
> collection.
> In other words, creation/modification/deletion of subcollections and 
> their children should not be included.

I was going to write something related about carddav (still reading it...).

A definition of a WebDAV report absolutely MUST specify the scope of the 
request. So, for Depth:0, it needs to specify whether it affects only 
the resource at the Request-URI, or more. The semantics for Depth:1 or 
Depth:infinity then follow from that.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Arnaud Quillaud | 11 Mar 2009 13:22
Picon

collection recreated in draft-daboo-webdav-sync-01

Hello,

Still on the topic of precondition failure, the token might become 
invalid for reasons other than reaching the history limit of the server.

For example, if a collection is deleted, then recreated, the server 
won't necessary maintain sync information about the defunct collection.
Or the server may have encountered a crash causing the history 
information to be lost.

Hence, we might want to change the overview section to be more generic:

<<

In some cases a server may no longer be able to honor a previously returned token.
   For example, it may only wish to maintain a limited amount of
   history about changes to a collection.  In that situation it will
   return an error to the client when the client presents a token that
   is "out of date".  At that point the client has to fall back to
   synchronizing the entire collection by re-running the report request
   using an empty token value.

 >>

Arnaud

PS: about the collection recreate scenario, do we want to return a 
different precondition ?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Arnaud Quillaud | 11 Mar 2009 14:14
Picon

multiple changes and draft-daboo-webdav-sync

Hello,

I think we should clarify some aspects of the response when multiple 
changes to the same resource have occurred:

1) for a given resource, only one sync-response is returned, regardless 
of how many state changes (e.g. created --> modified --> deleted --> 
recreated) it has gone through. The status reflects the latest state of 
the resource at the time of the query (but see 2)).
2) if a resource has been created, then modified since the last sync, 
the server MUST return '201 Created'.
3) if a resource has been deleted then recreated since the last sync, 
the server MUST return '201 Created' (cf open issue No 6).

Of course, the above points reflect my interpretation of the spec. I may 
be wrong, but that would be just another justification for clarifying 
the desired behavior.

Finally, there is a race condition where some resources are 
created/modified/deleted and a report issued at the exact same time. 
Depending on how the sync token is implemented on the server side, it 
might be hard to avoid having those resource being returned twice (in 2 
consecutive reports).

Hence, I think it is worth mentioning that:
"Under some rare circumstances, the server may return the same 
sync-response (i.e. refering to the same resource and with the same 
status) in response to 2 consecutive sync-collection report requests. 
The client can easily detect such duplicate by asking for the getetag 
property and comparing it with a previously stored value."
(Continue reading)

Permalink | Reply | 0 comments |
headers
Julian Reschke | 12 Mar 2009 13:54
Picon
Picon

allprop behaviour, was: [VCARDDAV] vcarddav WGLC on draft-ietf-vcarddav-{carddav,mkcol}

Marc Blanchet wrote:
> Hi,
>  This is the working group last call for the following two documents:
> http://tools.ietf.org/html/draft-ietf-vcarddav-carddav-05
> http://tools.ietf.org/html/draft-ietf-vcarddav-webdav-mkcol-03
> 
> Please provide any comments to the wg mailing list
> (mailto:vcarddav <at> ietf.org) by March 9th 2009, 23h00 GMT.
> 
> Regards,
>  Marc and Kurt, vcarddav wg chairs

Hi,

apologies for the late feedback.

I've been going through draft-ietf-vcarddav-carddav-06, and have quite a 
few comments which I'll raise in separate emails (trying to collect 
things that belong together into single mails).

The first one is a generic comment about the properties defined in 
Section 6.2 
(<http://tools.ietf.org/html/draft-ietf-vcarddav-carddav-06#section-6.2>).

For each property, it states:

    allprop behavior:  SHOULD be returned by a PROPFIND DAV:allprop
       request.

This deviates from how every single other WebDAV extension (including
(Continue reading)

Permalink | Reply | 1 comment |
headers
Julian Reschke | 12 Mar 2009 14:41
Picon
Picon

use of DTD in draft-ietf-vcarddav-carddav-06, was: [VCARDDAV] vcarddav WGLC on draft-ietf-vcarddav-{carddav,mkcol}

Hi,

a few comments with respect how draft-ietf-vcarddav-carddav-06 uses DTD 
fragments for defining the CardDAV related elements:

1) Section 2.2 (XML Namespaces and Processing) should be expanded to 
include statements about how the DTD fragments are to be understood, 
similar to Section 2 in draft-ietf-vcarddav-webdav-mkcol-04.

2) The XML spec reference needs to be updated to W3C.REC-xml-20081126, 
just as in draft-ietf-vcarddav-webdav-mkcol-04. (Note I'd recommend to 
use a shorter reference name, such as just "XML".

3) I had trang (<http://www.thaiopensource.com/relaxng/trang.html>) 
parse the DTD fragments for me (to do that just markup the artwork with 
the proper type of "application/xml-dtd", then use rfc2629xslt's 
extract-artwork.xslt 
(<http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#extract-artwork>).

A minor issue I found is that at least one element type definition 
(addressbook) appeared multiple times; this is not really a problem as 
long as they all say the same thing.

On the other hand, address-data has three different definitions (see 
<http://tools.ietf.org/html/draft-ietf-vcarddav-carddav-06#section-10.4>), 
depending on the context it's used in. I think this really should be 
avoided. The simplest fix for this seems to just use three distinct names.

Best regards, Julian
(Continue reading)

Permalink | Reply | 2 comments |
headers
Julian Reschke | 12 Mar 2009 15:33
Picon
Picon

broken XML in examples, was: [VCARDDAV] vcarddav WGLC on draft-ietf-vcarddav-{carddav,mkcol}

Marc Blanchet wrote:
> Hi,
>  This is the working group last call for the following two documents:
> http://tools.ietf.org/html/draft-ietf-vcarddav-carddav-05
> http://tools.ietf.org/html/draft-ietf-vcarddav-webdav-mkcol-03
> 
> Please provide any comments to the wg mailing list
> (mailto:vcarddav <at> ietf.org) by March 9th 2009, 23h00 GMT.
> 
> Regards,
>  Marc and Kurt, vcarddav wg chairs

Hi,

in 
<http://tools.ietf.org/html/draft-ietf-vcarddav-carddav-06#section-7.1.1> 
the XML is not well-formed.

        <C:addressbook-home-set xmlns:D="DAV:"
           xmlns:C="urn:ietf:params:xml:ns:carddav">
          <D:href>http://addressbook.example.com/bernard/addresses/<
          /D:href>
        </C:addressbook-home-set>

The simplest fix would be just to use an absolute path, as in

        <C:addressbook-home-set xmlns:D="DAV:"
           xmlns:C="urn:ietf:params:xml:ns:carddav">
          <D:href>/bernard/addresses/≤/D:href>
        </C:addressbook-home-set>
(Continue reading)

Permalink | Reply | 1 comment |

Gmane