Cyrus Daboo | 3 Jul 2006 14:54
Favicon

Re: What happened to the CalDav website?

Hi Adam,

--On June 29, 2006 12:39:00 PM +0100 Adam Laurie 
<adam.laurie <at> thebunker.net> wrote:

> For the past couple of weeks I've been trying to find a download with no
> joy... All URLS previously mentioned appear to be down:
>
>   http://ietf.cse.ucsc.edu/caldav
>   http://caldav.org/
>   http://www.caldav.org/
>   http://ietf.webdav.org/caldav/
>
> Is there CVS or some other access, or is the distribution site likely to
> come back any time soon?
>
> BTW, please copy me on replies - I'm not subscribed to this list.

The website has moved, but the owner of caldav.org has not updated to 
redirect to the new site.

<http://ietf.osafoundation.org/caldav/home.html>

--

-- 
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
(Continue reading)

Julian Reschke | 25 Jul 2006 22:28
Picon
Picon

Re: Last Call comment on Etag requirements in draft-dusseault-caldav-12

Cyrus Daboo schrieb:
> Hi Julian,
> 
> --On June 5, 2006 8:30:25 PM +0200 Julian Reschke 
> <julian.reschke <at> gmx.de> wrote:
> 
>> I notice that draft-dusseault-caldav-12 now is in IESG Evaluation
>> (<https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag
>> =11253>).
>>
>> For the record: as far as I can tell, the issue that I raised below is
>> critical (given the fact that we have a separate activity to clarify this
>> in HTTP), and has not been addressed. It's not clear to me whether the
>> client issue it attempts to solve really is important. If it is, there is
>> a simpler way to accomplish this ([1]) that doesn't risk making CalDAV
>> incompatible with other specs extending HTTP (or HTTP itself, for that
>> matter).
> 
> We are planning on addressing this ETag issue in a revision now that 
> last-call is over. Authors are discussing right now.

The new text says 
(<http://greenbytes.de/tech/webdav/draft-dusseault-caldav-13.html#rfc.section.5.3.4.p.2>):

"A response to a GET request targeted at a calendar object resource MUST 
contain an ETag response header field indicating the current value of 
the strong entity tag of the calendar object resource.

Servers SHOULD return a strong entity tag (ETag header) in a PUT 
response when the stored calendar object resource is equivalent by octet 
(Continue reading)

Robert Sayre | 25 Jul 2006 23:08
Picon
Gravatar

Re: [Ietf-caldav] Last Call comment on Etag requirements in draft-dusseault-caldav-12

On 7/25/06, Julian Reschke <julian.reschke <at> gmx.de> wrote:
>
> Again, this profiles HTTP in a way that may turn out to be incompatible
> with the way the issue will be resolved in general; also this conflicts
> with ETag requirements in XCAP, which is also under IESG evaluation. By
> all means, please let this issue be clarified in a *single* place and in
> a way consistent for all HTTP resources.

Neither draft obsoletes RFC2616, right? It seems obviously
inappropriate for either draft to redefine ETag. If the protocols need
something HTTP doesn't provide, they can mint a new header name,
rather than base the semantics of the ETag response header on the
results of a previous request. Wouldn't it be easier send "Sync: OK"
or something?

--

-- 

Robert Sayre

_______________________________________________
Ietf mailing list
Ietf <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Julian Reschke | 30 Jul 2006 20:26
Picon
Picon

Re: Last Call: 'Calendaring Extensions to WebDAV (CalDAV)' to Proposed Standard (draft-dusseault-caldav)

Hi,

below are last call comments, interleaved with the spec text.

Best regards, Julian

--

Section 1., para. 2:

     Discussion of this specification is taking place on the mailing list
     <http://lists.osafoundation.org/mailman/listinfo/ietf-caldav>.
     [[anchor2: Clarify that this paragraph should be removed upon
     publication --reschke]]

Section 1.2., para. 3:

     The XML declarations used in this document do not include namespace
     information.  Thus, implementers MUST NOT use these declarations as
     the only way to create valid CalDAV properties or to validate CalDAV
     XML element type. [[anchor5: "...MUST NOT use these declarations as
     the only way..." is extremly hard to understand; the presence of
     RFC2119 keywords make things worse in that the reader is confused to
     believe that a normative statement is being made.  As far as I can
     tell, all this wants to say is that the missing namespace needs to be
     taken into account.  Please clarify. --reschke]] Some of the
     declarations refer to XML elements defined by WebDAV
     [I-D.ietf-webdav-rfc2518bis] which use the "DAV:" namespace.
     Wherever such XML elements appear, they are explicitly prefixed with
     "DAV:" to avoid confusion.
(Continue reading)

Julian Reschke | 29 Jul 2006 23:19
Picon
Picon

Re: Last Call: 'Calendaring Extensions to WebDAV (CalDAV)' to Proposed Standard (draft-dusseault-caldav)

Hi,

below are last call comments, interleaved with the spec text (plus 
additional as HTML formatted diffs to draft 13).

Best regards, Julian

--

Section 1., para. 2:
OLD:

     Discussion of this specification is taking place on the mailing list
     <http://lists.osafoundation.org/mailman/listinfo/ietf-caldav>.

NEW:

     Discussion of this specification is taking place on the mailing list
     <http://lists.osafoundation.org/mailman/listinfo/ietf-caldav>.
     [[anchor2: Clarify that this paragraph should be removed upon
     publication --reschke]]

Section 1.2., para. 3:
OLD:

     The XML declarations used in this document do not include namespace
     information.  Thus, implementers MUST NOT use these declarations as
     the only way to create valid CalDAV properties or to validate CalDAV
     XML element type.  Some of the declarations refer to XML elements
     defined by WebDAV [I-D.ietf-webdav-rfc2518bis] which use the "DAV:"
(Continue reading)


Gmane