From douglm@rpi.edu Tue Nov 3 10:12:48 2009 Return-Path: X-Original-To: caldav@core3.amsl.com Delivered-To: caldav@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A5DB28C129 for ; Tue, 3 Nov 2009 10:12:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.182 X-Spam-Level: X-Spam-Status: No, score=0.182 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dcIxFkdiBRwl for ; Tue, 3 Nov 2009 10:12:47 -0800 (PST) Received: from smtp7.server.rpi.edu (smtp7.server.rpi.edu [128.113.2.227]) by core3.amsl.com (Postfix) with ESMTP id 7AD4D28B23E for ; Tue, 3 Nov 2009 10:12:47 -0800 (PST) Received: from [128.113.124.223] (blue-eyes-white-dragon-15.dynamic2.rpi.edu [128.113.124.223]) (authenticated bits=0) by smtp7.server.rpi.edu (8.13.1/8.13.1) with ESMTP id nA3ID69J031640 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 3 Nov 2009 13:13:07 -0500 Message-ID: <4AF072B2.3080202@rpi.edu> Date: Tue, 03 Nov 2009 13:13:06 -0500 From: Mike Douglass User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 CC: caldav@ietf.org References: <4AC23DBD.6020206@sun.com> <4AD737D5.7040300@oracle.com> <002901ca4dab$f9ba6850$ed2f38f0$@net> <88061EBB-EA5E-4129-A358-840BA7F8C794@opengroupware.org> In-Reply-To: <88061EBB-EA5E-4129-A358-840BA7F8C794@opengroupware.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-RPI-SA-Score: undef - SENDER Whitelisted (douglm@rpi.edu: Mail from user authenticated via SMTP AUTH allowed always) X-CanItPRO-Stream: outgoing X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.113.2.227 Subject: [caldav] Clarification(s) X-BeenThere: caldav@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 18:12:48 -0000 Section 9.6.5 caldav expand element We have the text: The returned calendar components MUST NOT use recurrence properties (i.e., EXDATE, EXRULE, RDATE, and RRULE) and MUST NOT have reference to or include VTIMEZONE components. Date and local time with reference to time zone information MUST be converted into date with UTC time. I assume this is meant to apply only to recurrence instances. i.e. non instances remain with tzinfo. Also note that RFC 4791 example for expanded retrieval has the events with floating time not UTC DTSTART:20060103T170000 Helge Hess wrote: > On 15.10.2009, at 17:27, Tim Hare wrote: >> In RFC 5445 for PRODID >> >> " Purpose: This property specifies the identifier for the product >> that >> created the iCalendar object." >> >> While it doesn't say this is REQUIRED or 'MUST specify' I believe >> that is >> the intent. The language could perhaps specify that requirement in the >> future, with some standardized form for 'hand-edited' items. For >> interop >> troubleshooting issues it is critical that we know what created the >> particular object we're looking at. > > In the context of CalDAV its a bit more complicated than with the > throwaway iMIP entities (which the original iCal authors probably had > in mind). > For example our Outlook plugin only touches the parts of the iCalendar > entity which it knows about, other parts are preserved as-is. Hence > the resulting iCalendar entity after PUT operations is like a mixture > between two or even more clients. > > I'm not sure what the PRODID is good for anyways, user-agent sniffing > is dangerous ... > > Greets, > Helge -- Mike Douglass douglm@rpi.edu Senior Systems Programmer Communication & Collaboration Technologies 518 276 6780(voice) 2809 (fax) Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180 From bernard.desruisseaux@oracle.com Wed Nov 4 18:34:52 2009 Return-Path: X-Original-To: caldav@core3.amsl.com Delivered-To: caldav@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC2C13A69D8 for ; Wed, 4 Nov 2009 18:34:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.397 X-Spam-Level: X-Spam-Status: No, score=-5.397 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.001, J_CHICKENPOX_66=0.6, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GFXdqZNSvTlI for ; Wed, 4 Nov 2009 18:34:51 -0800 (PST) Received: from acsinet12.oracle.com (acsinet12.oracle.com [141.146.126.234]) by core3.amsl.com (Postfix) with ESMTP id 99F0D3A67E6 for ; Wed, 4 Nov 2009 18:34:51 -0800 (PST) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by acsinet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id nA52Yt0A030199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 5 Nov 2009 02:34:57 GMT Received: from hqdfmt01.oracle.com (hqdfmt01.oracle.com [148.87.24.194]) by acsinet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id nA52aaOx020189; Thu, 5 Nov 2009 02:36:39 GMT Received: from [141.144.121.203] (/141.144.121.203) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 04 Nov 2009 18:35:05 -0800 Message-ID: <4AF239D5.7010005@oracle.com> Date: Wed, 04 Nov 2009 21:35:01 -0500 From: Bernard Desruisseaux User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Mike Douglass References: <4AC23DBD.6020206@sun.com> <4AD737D5.7040300@oracle.com> <002901ca4dab$f9ba6850$ed2f38f0$@net> <88061EBB-EA5E-4129-A358-840BA7F8C794@opengroupware.org> <4AF072B2.3080202@rpi.edu> In-Reply-To: <4AF072B2.3080202@rpi.edu> Content-Type: multipart/alternative; boundary="------------020207060402000808020508" X-Source-IP: hqdfmt01.oracle.com [148.87.24.194] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4AF239DD.0054:SCFSTAT9981554,ss=1,fgs=0 Cc: caldav@ietf.org Subject: [caldav] RFC4791: CALDAV:expand [Re: Clarification(s)] X-BeenThere: caldav@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 02:34:52 -0000 This is a multi-part message in MIME format. --------------020207060402000808020508 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Mike, Mike Douglass wrote: > Section 9.6.5 caldav expand element > > We have the text: > > The returned calendar components MUST NOT use recurrence > properties (i.e., EXDATE, EXRULE, RDATE, and RRULE) and MUST NOT > have reference to or include VTIMEZONE components. Date and local > time with reference to time zone information MUST be converted > into date with UTC time. > > I assume this is meant to apply only to recurrence instances. i.e. non > instances remain with tzinfo. > No. It applies to recurring as well as non-recurring calendar components. See: http://tools.ietf.org/html/rfc4791#section-7.6 A CalDAV client with no support for recurrence properties (i.e., EXDATE, EXRULE, RDATE, and RRULE) and possibly VTIMEZONE components, or a client unwilling to perform recurrence expansion because of limited processing capability, can request to receive only the recurrence instances that overlap a specified time range as separate calendar components that each define exactly one recurrence instance (see CALDAV:expand in Section 9.6.5.) A calendar user agent unable to handle RRULE in VEVENT components will most likely not be able to handle RRULE in VTIMEZONE components as well. > Also note that RFC 4791 example for expanded retrieval has the events > with floating time not UTC > > DTSTART:20060103T170000 > Yes. The following lines in *red* were fixed in my annotated copy of RFC4791: >> Response << HTTP/1.1 207 Multi-Status Date: Sat, 11 Nov 2006 09:32:12 GMT Content-Type: application/xml; charset="utf-8" Content-Length: xxxx http://cal.example.com/bernard/work/abcd2.ics "fffff-abcd2" BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Example Corp.//CalDAV Client//EN BEGIN:VEVENT DTSTAMP:20060206T001121Z *DTSTART:20060103T170000Z* DURATION:PT1H *RECURRENCE-ID:20060103T170000Z* SUMMARY:Event #2 UID:00959BC664CA650E933C892C@example.com END:VEVENT BEGIN:VEVENT DTSTAMP:20060206T001121Z *DTSTART:20060104T190000Z* DURATION:PT1H *RECURRENCE-ID:20060104T170000Z* SUMMARY:Event #2 bis UID:00959BC664CA650E933C892C@example.com END:VEVENT END:VCALENDAR HTTP/1.1 200 OK http://cal.example.com/bernard/work/abcd3.ics "fffff-abcd3" BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Example Corp.//CalDAV Client//EN BEGIN:VEVENT ATTENDEE;PARTSTAT=ACCEPTED;ROLE=CHAIR:mailto:cyrus@example.com ATTENDEE;PARTSTAT=NEEDS-ACTION:mailto:lisa@example.com DTSTAMP:20060206T001220Z *DTSTART:20060104T150000Z* DURATION:PT1H LAST-MODIFIED:20060206T001330Z ORGANIZER:mailto:cyrus@example.com SEQUENCE:1 STATUS:TENTATIVE SUMMARY:Event #3 UID:DC6C50A017428C5216A2F1CD@example.com X-ABC-GUID:E1CX5Dr-0007ym-Hz@example.com END:VEVENT END:VCALENDAR HTTP/1.1 200 OK Cheers, Bernard --------------020207060402000808020508 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Mike,

Mike Douglass wrote: 
Section 9.6.5 caldav expand element

We have the text:

      The returned calendar components MUST NOT use recurrence
      properties (i.e., EXDATE, EXRULE, RDATE, and RRULE) and MUST NOT
      have reference to or include VTIMEZONE components.  Date and local
      time with reference to time zone information MUST be converted
      into date with UTC time.

I assume this is meant to apply only to recurrence instances. i.e. non
instances remain with tzinfo.
No.  It applies to recurring as well as non-recurring calendar components.

See:  http://tools.ietf.org/html/rfc4791#section-7.6

   A CalDAV client with no support for recurrence properties (i.e.,
   EXDATE, EXRULE, RDATE, and RRULE) and possibly VTIMEZONE components,
   or a client unwilling to perform recurrence expansion because of
   limited processing capability, can request to receive only the
   recurrence instances that overlap a specified time range as separate
   calendar components that each define exactly one recurrence instance
   (see CALDAV:expand in Section 9.6.5.)

A calendar user agent unable to handle RRULE in VEVENT components will most likely not be able to handle RRULE in VTIMEZONE components as well.
Also note that RFC 4791 example for expanded retrieval has the events
with floating time not UTC

   DTSTART:20060103T170000
Yes.  The following lines in red were fixed in my annotated copy of RFC4791:

>> Response <<

HTTP/1.1 207 Multi-Status
Date: Sat, 11 Nov 2006 09:32:12 GMT
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx

<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:"
           xmlns:C="urn:ietf:params:xml:ns:caldav">
  <D:response>
    <D:href>http://cal.example.com/bernard/work/abcd2.ics</D:href>
    <D:propstat>
      <D:prop>
        <D:getetag>"fffff-abcd2"</D:getetag>
        <C:calendar-data>BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example Corp.//CalDAV Client//EN
BEGIN:VEVENT
DTSTAMP:20060206T001121Z
DTSTART:20060103T170000Z
DURATION:PT1H
RECURRENCE-ID:20060103T170000Z
SUMMARY:Event #2
UID:00959BC664CA650E933C892C@example.com
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20060206T001121Z
DTSTART:20060104T190000Z
DURATION:PT1H
RECURRENCE-ID:20060104T170000Z
SUMMARY:Event #2 bis
UID:00959BC664CA650E933C892C@example.com
END:VEVENT
END:VCALENDAR
</C:calendar-data>
      </D:prop>
      <D:status>HTTP/1.1 200 OK</D:status>
    </D:propstat>
  </D:response>
  <D:response>
    <D:href>http://cal.example.com/bernard/work/abcd3.ics</D:href>
    <D:propstat>
      <D:prop>
        <D:getetag>"fffff-abcd3"</D:getetag>
        <C:calendar-data>BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example Corp.//CalDAV Client//EN
BEGIN:VEVENT
ATTENDEE;PARTSTAT=ACCEPTED;ROLE=CHAIR:mailto:cyrus@example.com
ATTENDEE;PARTSTAT=NEEDS-ACTION:mailto:lisa@example.com
DTSTAMP:20060206T001220Z
DTSTART:20060104T150000Z
DURATION:PT1H
LAST-MODIFIED:20060206T001330Z
ORGANIZER:mailto:cyrus@example.com
SEQUENCE:1
STATUS:TENTATIVE
SUMMARY:Event #3
UID:DC6C50A017428C5216A2F1CD@example.com
X-ABC-GUID:E1CX5Dr-0007ym-Hz@example.com
END:VEVENT
END:VCALENDAR
</C:calendar-data>
      </D:prop>
      <D:status>HTTP/1.1 200 OK</D:status>
    </D:propstat>
  </D:response>
</D:multistatus>
Cheers,
Bernard --------------020207060402000808020508-- From douglm@rpi.edu Wed Nov 4 21:48:45 2009 Return-Path: X-Original-To: caldav@core3.amsl.com Delivered-To: caldav@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADED528C0FA for ; Wed, 4 Nov 2009 21:48:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_66=0.6, J_CHICKENPOX_75=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RU3XXjgCTWei for ; Wed, 4 Nov 2009 21:48:44 -0800 (PST) Received: from smtp6.server.rpi.edu (smtp6.server.rpi.edu [128.113.2.226]) by core3.amsl.com (Postfix) with ESMTP id ADE2C28C153 for ; Wed, 4 Nov 2009 21:48:44 -0800 (PST) Received: from [192.168.2.10] (cpe-24-92-49-115.nycap.res.rr.com [24.92.49.115]) (authenticated bits=0) by smtp6.server.rpi.edu (8.13.1/8.13.1) with ESMTP id nA55n4OP019957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Nov 2009 00:49:04 -0500 Message-ID: <4AF2674F.8000602@rpi.edu> Date: Thu, 05 Nov 2009 00:49:03 -0500 From: Mike Douglass User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Bernard Desruisseaux References: <4AC23DBD.6020206@sun.com> <4AD737D5.7040300@oracle.com> <002901ca4dab$f9ba6850$ed2f38f0$@net> <88061EBB-EA5E-4129-A358-840BA7F8C794@opengroupware.org> <4AF072B2.3080202@rpi.edu> <4AF239D5.7010005@oracle.com> In-Reply-To: <4AF239D5.7010005@oracle.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-RPI-SA-Score: undef - SENDER Whitelisted (douglm@rpi.edu: Mail from user authenticated via SMTP AUTH allowed always) X-CanItPRO-Stream: outgoing X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.113.2.226 Cc: caldav@ietf.org Subject: Re: [caldav] RFC4791: CALDAV:expand [Re: Clarification(s)] X-BeenThere: caldav@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 05:48:45 -0000 I can buy that and I flip-flopped between the two. I guess there's an assumption here I hadn't seen, that the client is actually doing the timezone processing. I'd suggest the language is changed to de-emphasize recurring. Bernard Desruisseaux wrote: > Hi Mike, > > Mike Douglass wrote: >> Section 9.6.5 caldav expand element >> >> We have the text: >> >> The returned calendar components MUST NOT use recurrence >> properties (i.e., EXDATE, EXRULE, RDATE, and RRULE) and MUST NOT >> have reference to or include VTIMEZONE components. Date and local >> time with reference to time zone information MUST be converted >> into date with UTC time. >> >> I assume this is meant to apply only to recurrence instances. i.e. non >> instances remain with tzinfo. >> > No. It applies to recurring as well as non-recurring calendar components. > > See: http://tools.ietf.org/html/rfc4791#section-7.6 > > A CalDAV client with no support for recurrence properties (i.e., > EXDATE, EXRULE, RDATE, and RRULE) and possibly VTIMEZONE components, > or a client unwilling to perform recurrence expansion because of > limited processing capability, can request to receive only the > recurrence instances that overlap a specified time range as separate > calendar components that each define exactly one recurrence instance > (see CALDAV:expand in Section 9.6.5.) > > A calendar user agent unable to handle RRULE in VEVENT components will > most likely not be able to handle RRULE in VTIMEZONE components as well. >> Also note that RFC 4791 example for expanded retrieval has the events >> with floating time not UTC >> >> DTSTART:20060103T170000 >> > Yes. The following lines in *red* were fixed in my annotated copy of > RFC4791: > > >> Response << > > HTTP/1.1 207 Multi-Status > Date: Sat, 11 Nov 2006 09:32:12 GMT > Content-Type: application/xml; charset="utf-8" > Content-Length: xxxx > > > xmlns:C="urn:ietf:params:xml:ns:caldav"> > > http://cal.example.com/bernard/work/abcd2.ics > > > "fffff-abcd2" > BEGIN:VCALENDAR > VERSION:2.0 > PRODID:-//Example Corp.//CalDAV Client//EN > BEGIN:VEVENT > DTSTAMP:20060206T001121Z > *DTSTART:20060103T170000Z* > DURATION:PT1H > *RECURRENCE-ID:20060103T170000Z* > SUMMARY:Event #2 > UID:00959BC664CA650E933C892C@example.com > END:VEVENT > BEGIN:VEVENT > DTSTAMP:20060206T001121Z > *DTSTART:20060104T190000Z* > DURATION:PT1H > *RECURRENCE-ID:20060104T170000Z* > SUMMARY:Event #2 bis > UID:00959BC664CA650E933C892C@example.com > END:VEVENT > END:VCALENDAR > > > HTTP/1.1 200 OK > > > > http://cal.example.com/bernard/work/abcd3.ics > > > "fffff-abcd3" > BEGIN:VCALENDAR > VERSION:2.0 > PRODID:-//Example Corp.//CalDAV Client//EN > BEGIN:VEVENT > ATTENDEE;PARTSTAT=ACCEPTED;ROLE=CHAIR:mailto:cyrus@example.com > ATTENDEE;PARTSTAT=NEEDS-ACTION:mailto:lisa@example.com > DTSTAMP:20060206T001220Z > *DTSTART:20060104T150000Z* > DURATION:PT1H > LAST-MODIFIED:20060206T001330Z > ORGANIZER:mailto:cyrus@example.com > SEQUENCE:1 > STATUS:TENTATIVE > SUMMARY:Event #3 > UID:DC6C50A017428C5216A2F1CD@example.com > X-ABC-GUID:E1CX5Dr-0007ym-Hz@example.com > END:VEVENT > END:VCALENDAR > > > HTTP/1.1 200 OK > > > > Cheers, > Bernard -- Mike Douglass douglm@rpi.edu Senior Systems Programmer Communication & Collaboration Technologies 518 276 6780(voice) 2809 (fax) Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180 From Arnaud.Quillaud@Sun.COM Thu Nov 19 01:50:27 2009 Return-Path: X-Original-To: caldav@core3.amsl.com Delivered-To: caldav@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34B563A68F9 for ; Thu, 19 Nov 2009 01:50:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LUaiD2wTzReG for ; Thu, 19 Nov 2009 01:50:26 -0800 (PST) Received: from gmp-eb-inf-1.sun.com (gmp-eb-inf-1.sun.com [192.18.6.21]) by core3.amsl.com (Postfix) with ESMTP id 22AA23A68EE for ; Thu, 19 Nov 2009 01:50:22 -0800 (PST) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nAJ9oJ07004185 for ; Thu, 19 Nov 2009 09:50:19 GMT MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_HboZ3WlmQ2OTzgbAFmO3ew)" Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KTC00200NZL0I00@fe-emea-10.sun.com> for caldav@ietf.org; Thu, 19 Nov 2009 09:50:00 +0000 (GMT) Received: from vpn-129-150-116-96.uk.sun.com ([unknown] [129.150.116.96]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KTC00E6EON74ZC0@fe-emea-10.sun.com> for caldav@ietf.org; Thu, 19 Nov 2009 09:49:57 +0000 (GMT) Date: Thu, 19 Nov 2009 10:49:57 +0100 From: Arnaud Quillaud Sender: Arnaud.Quillaud@Sun.COM To: caldav@ietf.org Message-id: <4B0514C5.5030902@sun.com> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.4pre) Gecko/20090915 Lightning/1.0pre Thunderbird/3.0b4 Subject: [caldav] SCHEDULE-STATUS inconsistencies and questions X-BeenThere: caldav@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 09:50:27 -0000 This is a multi-part message in MIME format. --Boundary_(ID_HboZ3WlmQ2OTzgbAFmO3ew) Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Hello, I noticed some inconsistencies between the definition and the examples regarding the SCHEDULE-STATUS parameter: While the definition states that only the status code (e.g. "2.1") should be present, all the examples include both the status code and status description (e.g. "1.2;Scheduling message has been delivered"). Then a question: the list of valid status for delivery at http://tools.ietf.org/html/draft-desruisseaux-caldav-sched-08#section-9.2 includes 3.8 " The scheduling message was not delivered due to insufficient privileges." I assumed that this would happen in the case where the organizer does not have schedule-deliver-invite privilege, or if the attendee replying does not have schedule-deliver-reply. On the other hand, iTIP describes 3.8 (http://tools.ietf.org/html/draft-ietf-calsify-2446bis-10#section-3.6.21) as meaning that " iTIP operation failed because an **Attendee** does not have suitable privileges for the operation." When would this happen ? Thanks, Arnaud Quillaud --Boundary_(ID_HboZ3WlmQ2OTzgbAFmO3ew) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Hello,

I noticed some inconsistencies between the definition and the examples regarding the SCHEDULE-STATUS parameter:

While the definition states that only the status code (e.g. "2.1") should be present, all the examples include both the status code and status description (e.g. "1.2;Scheduling message has been delivered").

Then a question: the list of valid status for delivery at http://tools.ietf.org/html/draft-desruisseaux-caldav-sched-08#section-9.2 includes

3.8 " The scheduling message was not delivered due to insufficient privileges."

I assumed that this would happen in the case where the organizer does not have schedule-deliver-invite privilege, or if the attendee replying does not have schedule-deliver-reply.

On the other hand, iTIP describes 3.8 (http://tools.ietf.org/html/draft-ietf-calsify-2446bis-10#section-3.6.21) as meaning that " iTIP operation failed because an **Attendee** does not have suitable privileges for the operation."

When would this happen ?

Thanks,

Arnaud Quillaud
--Boundary_(ID_HboZ3WlmQ2OTzgbAFmO3ew)-- From Arnaud.Quillaud@Sun.COM Thu Nov 19 02:10:42 2009 Return-Path: X-Original-To: caldav@core3.amsl.com Delivered-To: caldav@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 169423A6A78 for ; Thu, 19 Nov 2009 02:10:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kuNf6VxnJBHZ for ; Thu, 19 Nov 2009 02:10:40 -0800 (PST) Received: from gmp-eb-inf-1.sun.com (gmp-eb-inf-1.sun.com [192.18.6.21]) by core3.amsl.com (Postfix) with ESMTP id 5191D3A6A57 for ; Thu, 19 Nov 2009 02:10:40 -0800 (PST) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nAJAAatN007864 for ; Thu, 19 Nov 2009 10:10:36 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KTC00800PAYNZ00@fe-emea-09.sun.com> for caldav@ietf.org; Thu, 19 Nov 2009 10:10:34 +0000 (GMT) Received: from vpn-129-150-116-96.uk.sun.com ([unknown] [129.150.116.96]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KTC00H21PLGGK70@fe-emea-09.sun.com> for caldav@ietf.org; Thu, 19 Nov 2009 10:10:28 +0000 (GMT) Date: Thu, 19 Nov 2009 11:10:30 +0100 From: Arnaud Quillaud In-reply-to: <4B0514C5.5030902@sun.com> Sender: Arnaud.Quillaud@Sun.COM To: caldav@ietf.org Message-id: <4B051996.6050902@sun.com> References: <4B0514C5.5030902@sun.com> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.4pre) Gecko/20090915 Lightning/1.0pre Thunderbird/3.0b4 Subject: Re: [caldav] SCHEDULE-STATUS inconsistencies and questions X-BeenThere: caldav@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 10:10:42 -0000 OK. Should have read the table more carefully: it looks like a lack of schedule-deliver-invite or schedule-deliver-reply privilege would actually result in a 5.3: " The scheduling message was not delivered and was rejected because scheduling with that recipient is not allowed. This is likely a permanent failure, and the originator should not try to send the message again." If it is the case, does 3.8 correspond to the lack of " schedule-send" privilege ? I would have expected a needs-privilege error when doing the PUT when lacking such privilege. Or does it correspond to something else ? Thanks, Arnaud Quillaud On 11/19/09 10:49 AM, Arnaud Quillaud wrote: > Hello, > > I noticed some inconsistencies between the definition and the examples > regarding the SCHEDULE-STATUS parameter: > > While the definition states that only the status code (e.g. "2.1") > should be present, all the examples include both the status code and > status description (e.g. "1.2;Scheduling message has been delivered"). > > Then a question: the list of valid status for delivery at > http://tools.ietf.org/html/draft-desruisseaux-caldav-sched-08#section-9.2 > includes > > 3.8 " The scheduling message was not delivered due to insufficient > privileges." > > I assumed that this would happen in the case where the organizer does > not have schedule-deliver-invite privilege, or if the attendee > replying does not have schedule-deliver-reply. > > On the other hand, iTIP describes 3.8 > (http://tools.ietf.org/html/draft-ietf-calsify-2446bis-10#section-3.6.21) > as meaning that " iTIP operation failed because an **Attendee** does > not have suitable privileges for the operation." > > When would this happen ? > > Thanks, > > Arnaud Quillaud From Arnaud.Quillaud@Sun.COM Thu Nov 19 09:21:16 2009 Return-Path: X-Original-To: caldav@core3.amsl.com Delivered-To: caldav@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AD463A6882; Thu, 19 Nov 2009 09:21:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZw9NgBMQ31f; Thu, 19 Nov 2009 09:21:15 -0800 (PST) Received: from gmp-eb-inf-2.sun.com (gmp-eb-inf-2.sun.com [192.18.6.24]) by core3.amsl.com (Postfix) with ESMTP id 349DA3A6825; Thu, 19 Nov 2009 09:21:15 -0800 (PST) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nAJHL9Gk020034; Thu, 19 Nov 2009 17:21:09 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KTD00500932CO00@fe-emea-09.sun.com>; Thu, 19 Nov 2009 17:20:51 +0000 (GMT) Received: from kirikou.local ([unknown] [82.227.203.159]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KTD00C1A9IJA5B0@fe-emea-09.sun.com>; Thu, 19 Nov 2009 17:20:44 +0000 (GMT) Date: Thu, 19 Nov 2009 18:20:43 +0100 From: Arnaud Quillaud Sender: Arnaud.Quillaud@Sun.COM To: caldav@ietf.org, w3c-dist-auth@w3.org, vcarddav@ietf.org Message-id: <4B057E6B.7040808@sun.com> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.4pre) Gecko/20090915 Lightning/1.0pre Thunderbird/3.0b4 Subject: [caldav] new webdav sync draft X-BeenThere: caldav@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 17:21:16 -0000 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 From Arnaud.Quillaud@Sun.COM Thu Nov 19 09:33:26 2009 Return-Path: X-Original-To: caldav@core3.amsl.com Delivered-To: caldav@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C07243A6844; Thu, 19 Nov 2009 09:33:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=-3.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RPGa+8ygF-x5; Thu, 19 Nov 2009 09:33:26 -0800 (PST) Received: from mail382c25.carrierzone.com (mail382c25.carrierzone.com [209.235.146.152]) by core3.amsl.com (Postfix) with ESMTP id F1DFB3A67A7; Thu, 19 Nov 2009 09:33:25 -0800 (PST) X-Authenticated-User: master.tencoassemblies.com Received: from TENCOSERVER.TencoAssembliesInc.local (static-68-162-87-75.phil.east.verizon.net [68.162.87.75]) (authenticated bits=0) by mail382c25.carrierzone.com (8.13.6/8.13.1) with ESMTP id nAJHXHic007921; Thu, 19 Nov 2009 17:33:21 GMT Received: from TENCOSERVER.TencoAssembliesInc.local ([10.0.0.2]) by TENCOSERVER.TencoAssembliesInc.local with Microsoft SMTPSVC(5.0.2195.6713); Thu, 19 Nov 2009 12:31:04 -0500 Received: by TENCOSERVER.TencoAssembliesInc.local (Microsoft Connector for POP3 Mailboxes 5.00.2195) with SMTP (Global POP3 Download) id MSG11192009-123059-8897.MMD@TencoAssembliesInc.local; Thu, 19 Nov 2009 12:30:59 -0500 X-Envelope-From: w3c-dist-auth-request@frink.w3.org Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by mail362c25.carrierzone.com (8.13.6/8.13.1) with ESMTP id nAJHMlo9018802 for ; Thu, 19 Nov 2009 12:22:49 -0500 Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from ) id 1NBAhV-00039X-5P for w3c-dist-auth-dist@listhub.w3.org; Thu, 19 Nov 2009 17:21:45 +0000 Received: from bart.w3.org ([128.30.52.63]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1NBAhU-00038t-3m for w3c-dist-auth@listhub.w3.org; Thu, 19 Nov 2009 17:21:44 +0000 Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by bart.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1NBAhR-0003yt-IO for w3c-dist-auth@w3.org; Thu, 19 Nov 2009 17:21:44 +0000 Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nAJHL9lP020035 for ; Thu, 19 Nov 2009 17:21:09 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KTD00500932CO00@fe-emea-09.sun.com> for w3c-dist-auth@w3.org; Thu, 19 Nov 2009 17:20:51 +0000 (GMT) Received: from kirikou.local ([unknown] [82.227.203.159]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KTD00C1A9IJA5B0@fe-emea-09.sun.com>; Thu, 19 Nov 2009 17:20:44 +0000 (GMT) Date: Thu, 19 Nov 2009 18:20:43 +0100 From: Arnaud Quillaud To: caldav@ietf.org, w3c-dist-auth@w3.org, vcarddav@ietf.org Message-id: <4B057E6B.7040808@sun.com> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.4pre) Gecko/20090915 Lightning/1.0pre Thunderbird/3.0b4 Received-SPF: none X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-6.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4 X-W3C-Scan-Sig: bart.w3.org 1NBAhR-0003yt-IO 2d6dcc4cba484ef924eb9619391f0ddb X-Original-To: w3c-dist-auth@w3.org Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13173 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Resent-Message-Id: Resent-Date: Thu, 19 Nov 2009 17:21:45 +0000 X-MMR: 0 X-Antivirus: Scanned by F-Prot Antivirus (http://www.f-prot.com) X-OriginalArrivalTime: 19 Nov 2009 17:31:04.0351 (UTC) FILETIME=[11F30AF0:01CA693E] Subject: [caldav] new webdav sync draft X-BeenThere: caldav@ietf.org X-Mailman-Version: 2.1.9 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 17:33:26 -0000 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 From julian.reschke@gmx.de Thu Nov 19 23:09:03 2009 Return-Path: X-Original-To: caldav@core3.amsl.com Delivered-To: caldav@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE7293A6A2C for ; Thu, 19 Nov 2009 23:09:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.966 X-Spam-Level: X-Spam-Status: No, score=-4.966 tagged_above=-999 required=5 tests=[AWL=-2.967, BAYES_00=-2.599, J_CHICKENPOX_38=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28roTK7NA3Y0 for ; Thu, 19 Nov 2009 23:09:03 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id B3AF93A69E3 for ; Thu, 19 Nov 2009 23:09:02 -0800 (PST) Received: (qmail invoked by alias); 20 Nov 2009 07:08:57 -0000 Received: from p508FFA94.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.250.148] by mail.gmx.net (mp005) with SMTP; 20 Nov 2009 08:08:57 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+5wJNEvGS5TEkNomIi75yz6JDYtjShjdvmjSIvMZ 5Nf2NZZQdvnzke Message-ID: <4B064079.50404@gmx.de> Date: Fri, 20 Nov 2009 08:08:41 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Andrew McMillan References: <4B057E6B.7040808@sun.com> (sfid-20091120_062140_570344_FA568882) <1258668093.15545.555.camel@happy.home.mcmillan.net.nz> In-Reply-To: <1258668093.15545.555.camel@happy.home.mcmillan.net.nz> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.64 Cc: Arnaud Quillaud , caldav@ietf.org, w3c-dist-auth@w3.org, vcarddav@ietf.org Subject: Re: [caldav] [VCARDDAV] new webdav sync draft X-BeenThere: caldav@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 07:09:03 -0000 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 From julian.reschke@gmx.de Thu Nov 19 23:18:43 2009 Return-Path: X-Original-To: caldav@core3.amsl.com Delivered-To: caldav@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F25C3A6A6F; Thu, 19 Nov 2009 23:18:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.224 X-Spam-Level: X-Spam-Status: No, score=-8.224 tagged_above=-999 required=5 tests=[AWL=1.775, BAYES_00=-2.599, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lXRdj4z4agO0; Thu, 19 Nov 2009 23:18:43 -0800 (PST) Received: from mail384c25.carrierzone.com (mail384c25.carrierzone.com [209.235.146.154]) by core3.amsl.com (Postfix) with ESMTP id 42B533A6A5E; Thu, 19 Nov 2009 23:18:43 -0800 (PST) X-Authenticated-User: master.tencoassemblies.com Received: from TENCOSERVER.TencoAssembliesInc.local (static-68-162-87-75.phil.east.verizon.net [68.162.87.75]) (authenticated bits=0) by mail384c25.carrierzone.com (8.13.6/8.13.1) with ESMTP id nAK7Iab3011961; Fri, 20 Nov 2009 07:18:38 GMT Received: from TENCOSERVER.TencoAssembliesInc.local ([10.0.0.2]) by TENCOSERVER.TencoAssembliesInc.local with Microsoft SMTPSVC(5.0.2195.6713); Fri, 20 Nov 2009 02:16:17 -0500 Received: by TENCOSERVER.TencoAssembliesInc.local (Microsoft Connector for POP3 Mailboxes 5.00.2195) with SMTP (Global POP3 Download) id MSG11202009-021606-9078.MMD@TencoAssembliesInc.local; Fri, 20 Nov 2009 02:16:06 -0500 X-Envelope-From: w3c-dist-auth-request@frink.w3.org Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by mail362c25.carrierzone.com (8.13.6/8.13.1) with ESMTP id nAK7AoGQ001962 for ; Fri, 20 Nov 2009 02:10:53 -0500 Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from ) id 1NBNci-00005W-B1 for w3c-dist-auth-dist@listhub.w3.org; Fri, 20 Nov 2009 07:09:40 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1NBNcf-0008Uj-Sp for w3c-dist-auth@listhub.w3.org; Fri, 20 Nov 2009 07:09:38 +0000 Received: from mail.gmx.net ([213.165.64.20]) by maggie.w3.org with smtp (Exim 4.69) (envelope-from ) id 1NBNcX-0000Mo-SO for w3c-dist-auth@w3.org; Fri, 20 Nov 2009 07:09:32 +0000 Received: (qmail invoked by alias); 20 Nov 2009 07:08:57 -0000 Received: from p508FFA94.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.250.148] by mail.gmx.net (mp005) with SMTP; 20 Nov 2009 08:08:57 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+5wJNEvGS5TEkNomIi75yz6JDYtjShjdvmjSIvMZ 5Nf2NZZQdvnzke Message-ID: <4B064079.50404@gmx.de> Date: Fri, 20 Nov 2009 08:08:41 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Andrew McMillan References: <4B057E6B.7040808@sun.com> (sfid-20091120_062140_570344_FA568882) <1258668093.15545.555.camel@happy.home.mcmillan.net.nz> In-Reply-To: <1258668093.15545.555.camel@happy.home.mcmillan.net.nz> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.64 Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001 X-W3C-Scan-Sig: maggie.w3.org 1NBNcX-0000Mo-SO d5e88f5bfe0fe5c7160db73867523ed0 X-Original-To: w3c-dist-auth@w3.org Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13174 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Resent-Message-Id: Resent-Date: Fri, 20 Nov 2009 07:09:40 +0000 X-MMR: 0 X-Antivirus: Scanned by F-Prot Antivirus (http://www.f-prot.com) X-OriginalArrivalTime: 20 Nov 2009 07:16:17.0507 (UTC) FILETIME=[5A171330:01CA69B1] Cc: Arnaud Quillaud , caldav@ietf.org, w3c-dist-auth@w3.org, vcarddav@ietf.org Subject: Re: [caldav] [VCARDDAV] new webdav sync draft X-BeenThere: caldav@ietf.org X-Mailman-Version: 2.1.9 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 07:18:43 -0000 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 From cyrus@daboo.name Fri Nov 20 06:11:48 2009 Return-Path: X-Original-To: caldav@core3.amsl.com Delivered-To: caldav@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFC463A6AD7; Fri, 20 Nov 2009 06:11:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_38=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Ip979GY+swJ; Fri, 20 Nov 2009 06:11:44 -0800 (PST) Received: from daboo.name (daboo.name [151.201.22.177]) by core3.amsl.com (Postfix) with ESMTP id D46603A6A70; Fri, 20 Nov 2009 06:11:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id CAE6F17E15C8; Fri, 20 Nov 2009 09:11:27 -0500 (EST) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7fKtxKiyVc2; Fri, 20 Nov 2009 09:11:25 -0500 (EST) Received: from caldav.corp.apple.com (unknown [17.101.32.44]) by daboo.name (Postfix) with ESMTPSA id 613D917E1203; Fri, 20 Nov 2009 09:11:22 -0500 (EST) Date: Fri, 20 Nov 2009 09:11:16 -0500 From: Cyrus Daboo To: Julian Reschke , Andrew McMillan Message-ID: <351598D1DDF378AF6AF4C3E4@caldav.corp.apple.com> In-Reply-To: <4B064079.50404@gmx.de> References: <4B057E6B.7040808@sun.com> (sfid-20091120_062140_570344_FA568882) <1258668093.15545.555.camel@happy.home.mcmillan.net.nz> <4B064079.50404@gmx.de> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=631 Cc: Arnaud Quillaud , caldav@ietf.org, w3c-dist-auth@w3.org, vcarddav@ietf.org Subject: Re: [caldav] [VCARDDAV] new webdav sync draft X-BeenThere: caldav@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 14:11:48 -0000 Hi Julian, --On November 20, 2009 8:08:41 AM +0100 Julian Reschke 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 From cyrus@daboo.name Fri Nov 20 06:18:30 2009 Return-Path: X-Original-To: caldav@core3.amsl.com Delivered-To: caldav@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EFF83A6816; Fri, 20 Nov 2009 06:18:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=4.000, BAYES_00=-2.599, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4mDwR4vHaGaK; Fri, 20 Nov 2009 06:18:30 -0800 (PST) Received: from mail384c25.carrierzone.com (mail384c25.carrierzone.com [209.235.146.154]) by core3.amsl.com (Postfix) with ESMTP id 5471C3A67DF; Fri, 20 Nov 2009 06:18:30 -0800 (PST) X-Authenticated-User: master.tencoassemblies.com Received: from TENCOSERVER.TencoAssembliesInc.local (static-68-162-87-75.phil.east.verizon.net [68.162.87.75]) (authenticated bits=0) by mail384c25.carrierzone.com (8.13.6/8.13.1) with ESMTP id nAKEIKts019346; Fri, 20 Nov 2009 14:18:21 GMT Received: from TENCOSERVER.TencoAssembliesInc.local ([10.0.0.2]) by TENCOSERVER.TencoAssembliesInc.local with Microsoft SMTPSVC(5.0.2195.6713); Fri, 20 Nov 2009 09:16:04 -0500 Received: by TENCOSERVER.TencoAssembliesInc.local (Microsoft Connector for POP3 Mailboxes 5.00.2195) with SMTP (Global POP3 Download) id MSG11202009-091600-9117.MMD@TencoAssembliesInc.local; Fri, 20 Nov 2009 09:16:00 -0500 X-Envelope-From: w3c-dist-auth-request@frink.w3.org Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by mail362c25.carrierzone.com (8.13.6/8.13.1) with ESMTP id nAKED0l5002696 for ; Fri, 20 Nov 2009 09:13:02 -0500 Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from ) id 1NBUDN-0002R5-50 for w3c-dist-auth-dist@listhub.w3.org; Fri, 20 Nov 2009 14:11:57 +0000 Received: from bart.w3.org ([128.30.52.63]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1NBUDM-0002QQ-4q for w3c-dist-auth@listhub.w3.org; Fri, 20 Nov 2009 14:11:56 +0000 Received: from daboo.name ([151.201.22.177]) by bart.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1NBUDK-0003ut-Nn for w3c-dist-auth@w3.org; Fri, 20 Nov 2009 14:11:56 +0000 Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id CAE6F17E15C8; Fri, 20 Nov 2009 09:11:27 -0500 (EST) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7fKtxKiyVc2; Fri, 20 Nov 2009 09:11:25 -0500 (EST) Received: from caldav.corp.apple.com (unknown [17.101.32.44]) by daboo.name (Postfix) with ESMTPSA id 613D917E1203; Fri, 20 Nov 2009 09:11:22 -0500 (EST) Date: Fri, 20 Nov 2009 09:11:16 -0500 From: Cyrus Daboo To: Julian Reschke , Andrew McMillan Message-ID: <351598D1DDF378AF6AF4C3E4@caldav.corp.apple.com> In-Reply-To: <4B064079.50404@gmx.de> References: <4B057E6B.7040808@sun.com> (sfid-20091120_062140_570344_FA568882) <1258668093.15545.555.camel@happy.home.mcmillan.net.nz> <4B064079.50404@gmx.de> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=631 Received-SPF: none X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599 X-W3C-Scan-Sig: bart.w3.org 1NBUDK-0003ut-Nn 89a71114da160e4fcc6e75f846d5eefb X-Original-To: w3c-dist-auth@w3.org Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13175 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Resent-Message-Id: Resent-Date: Fri, 20 Nov 2009 14:11:57 +0000 X-MMR: 0 X-Antivirus: Scanned by F-Prot Antivirus (http://www.f-prot.com) X-OriginalArrivalTime: 20 Nov 2009 14:16:04.0116 (UTC) FILETIME=[FE7A9D40:01CA69EB] Cc: Arnaud Quillaud , caldav@ietf.org, w3c-dist-auth@w3.org, vcarddav@ietf.org Subject: Re: [caldav] [VCARDDAV] new webdav sync draft X-BeenThere: caldav@ietf.org X-Mailman-Version: 2.1.9 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 14:18:30 -0000 Hi Julian, --On November 20, 2009 8:08:41 AM +0100 Julian Reschke 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 From julian.reschke@gmx.de Fri Nov 20 06:31:31 2009 Return-Path: X-Original-To: caldav@core3.amsl.com Delivered-To: caldav@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 337923A6AD9 for ; Fri, 20 Nov 2009 06:31:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.524 X-Spam-Level: X-Spam-Status: No, score=-4.524 tagged_above=-999 required=5 tests=[AWL=-1.925, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-GC26lxR3Z4 for ; Fri, 20 Nov 2009 06:31:30 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id F2A283A6906 for ; Fri, 20 Nov 2009 06:31:29 -0800 (PST) Received: (qmail invoked by alias); 20 Nov 2009 14:31:25 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.105]) [217.91.35.233] by mail.gmx.net (mp006) with SMTP; 20 Nov 2009 15:31:25 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18OlG1UAOcOPDnR7bY4i5tVYT/cZplT3IasoMZaIB 698jamnGddQZ7Y Message-ID: <4B06A836.7010007@gmx.de> Date: Fri, 20 Nov 2009 15:31:18 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Cyrus Daboo References: <4B057E6B.7040808@sun.com> (sfid-20091120_062140_570344_FA568882) <1258668093.15545.555.camel@happy.home.mcmillan.net.nz> <4B064079.50404@gmx.de> <351598D1DDF378AF6AF4C3E4@caldav.corp.apple.com> In-Reply-To: <351598D1DDF378AF6AF4C3E4@caldav.corp.apple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.64 Cc: caldav@ietf.org, Arnaud Quillaud , Andrew McMillan , w3c-dist-auth@w3.org, vcarddav@ietf.org Subject: Re: [caldav] [VCARDDAV] new webdav sync draft X-BeenThere: caldav@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 14:31:31 -0000 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. > ... : "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 From julian.reschke@gmx.de Fri Nov 20 06:33:31 2009 Return-Path: X-Original-To: caldav@core3.amsl.com Delivered-To: caldav@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93B0A28C130; Fri, 20 Nov 2009 06:33:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.363 X-Spam-Level: X-Spam-Status: No, score=-8.363 tagged_above=-999 required=5 tests=[AWL=2.236, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZPOl5f8ksMCx; Fri, 20 Nov 2009 06:33:31 -0800 (PST) Received: from mail385c25.carrierzone.com (mail385c25.carrierzone.com [209.235.146.155]) by core3.amsl.com (Postfix) with ESMTP id 5AD713A6906; Fri, 20 Nov 2009 06:33:31 -0800 (PST) X-Authenticated-User: master.tencoassemblies.com Received: from TENCOSERVER.TencoAssembliesInc.local (static-68-162-87-75.phil.east.verizon.net [68.162.87.75]) (authenticated bits=0) by mail385c25.carrierzone.com (8.13.6/8.13.1) with ESMTP id nAKEXMIU021060; Fri, 20 Nov 2009 14:33:23 GMT Received: from TENCOSERVER.TencoAssembliesInc.local ([10.0.0.2]) by TENCOSERVER.TencoAssembliesInc.local with Microsoft SMTPSVC(5.0.2195.6713); Fri, 20 Nov 2009 09:31:06 -0500 Received: by TENCOSERVER.TencoAssembliesInc.local (Microsoft Connector for POP3 Mailboxes 5.00.2195) with SMTP (Global POP3 Download) id MSG11202009-093100-9123.MMD@TencoAssembliesInc.local; Fri, 20 Nov 2009 09:31:00 -0500 X-Envelope-From: w3c-dist-auth-request@frink.w3.org Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by mail366c25.carrierzone.com (8.13.6/8.13.1) with ESMTP id nAKEWXiB025694 for ; Fri, 20 Nov 2009 09:32:36 -0500 Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from ) id 1NBUWr-00039m-Q9 for w3c-dist-auth-dist@listhub.w3.org; Fri, 20 Nov 2009 14:32:05 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1NBUWr-00038F-0s for w3c-dist-auth@listhub.w3.org; Fri, 20 Nov 2009 14:32:05 +0000 Received: from mail.gmx.net ([213.165.64.20]) by maggie.w3.org with smtp (Exim 4.69) (envelope-from ) id 1NBUWi-0001pw-SS for w3c-dist-auth@w3.org; Fri, 20 Nov 2009 14:31:59 +0000 Received: (qmail invoked by alias); 20 Nov 2009 14:31:25 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.105]) [217.91.35.233] by mail.gmx.net (mp006) with SMTP; 20 Nov 2009 15:31:25 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18OlG1UAOcOPDnR7bY4i5tVYT/cZplT3IasoMZaIB 698jamnGddQZ7Y Message-ID: <4B06A836.7010007@gmx.de> Date: Fri, 20 Nov 2009 15:31:18 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Cyrus Daboo References: <4B057E6B.7040808@sun.com> (sfid-20091120_062140_570344_FA568882) <1258668093.15545.555.camel@happy.home.mcmillan.net.nz> <4B064079.50404@gmx.de> <351598D1DDF378AF6AF4C3E4@caldav.corp.apple.com> In-Reply-To: <351598D1DDF378AF6AF4C3E4@caldav.corp.apple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.64 Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001 X-W3C-Scan-Sig: maggie.w3.org 1NBUWi-0001pw-SS 68aaf80eb6a807fa7c314626010a6aa3 X-Original-To: w3c-dist-auth@w3.org Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13177 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Resent-Message-Id: Resent-Date: Fri, 20 Nov 2009 14:32:05 +0000 X-MMR: 0 X-Antivirus: Scanned by F-Prot Antivirus (http://www.f-prot.com) X-OriginalArrivalTime: 20 Nov 2009 14:31:06.0491 (UTC) FILETIME=[18561CB0:01CA69EE] Cc: caldav@ietf.org, Arnaud Quillaud , Andrew McMillan , w3c-dist-auth@w3.org, vcarddav@ietf.org Subject: Re: [caldav] [VCARDDAV] new webdav sync draft X-BeenThere: caldav@ietf.org X-Mailman-Version: 2.1.9 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 14:33:31 -0000 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. > ... : "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 From Arnaud.Quillaud@Sun.COM Fri Nov 20 08:13:55 2009 Return-Path: X-Original-To: caldav@core3.amsl.com Delivered-To: caldav@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7A053A67A6; Fri, 20 Nov 2009 08:13:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.698 X-Spam-Level: X-Spam-Status: No, score=-5.698 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r+15azPsHA4K; Fri, 20 Nov 2009 08:13:53 -0800 (PST) Received: from gmp-eb-inf-2.sun.com (gmp-eb-inf-2.sun.com [192.18.6.24]) by core3.amsl.com (Postfix) with ESMTP id 7617F3A6A1F; Fri, 20 Nov 2009 08:13:53 -0800 (PST) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nAKGDnxB006270; Fri, 20 Nov 2009 16:13:49 GMT MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_Lg8ETQRR5+Vlp/WGoeGBLQ)" Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KTE00J00ZZP4V00@fe-emea-09.sun.com>; Fri, 20 Nov 2009 16:13:37 +0000 (GMT) Received: from vpn-129-150-118-65.uk.sun.com ([unknown] [129.150.118.65]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KTF00AUB12GW580@fe-emea-09.sun.com>; Fri, 20 Nov 2009 16:13:29 +0000 (GMT) Date: Fri, 20 Nov 2009 17:13:28 +0100 From: Arnaud Quillaud In-reply-to: <1258668093.15545.555.camel@happy.home.mcmillan.net.nz> Sender: Arnaud.Quillaud@Sun.COM To: Andrew McMillan Message-id: <4B06C028.9050200@sun.com> References: <4B057E6B.7040808@sun.com> <1258668093.15545.555.camel@happy.home.mcmillan.net.nz> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.4pre) Gecko/20090915 Lightning/1.0pre Thunderbird/3.0b4 Cc: caldav@ietf.org, w3c-dist-auth@w3.org, vcarddav@ietf.org Subject: Re: [caldav] [VCARDDAV] new webdav sync draft X-BeenThere: caldav@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 16:13:55 -0000 This is a multi-part message in MIME format. --Boundary_(ID_Lg8ETQRR5+Vlp/WGoeGBLQ) Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT 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 w3c-dist-auth@w3.org mailing list only to avoid too much cross posting. --Boundary_(ID_Lg8ETQRR5+Vlp/WGoeGBLQ) Content-type: text/html; charset=UTF-8 Content-transfer-encoding: 8BIT 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  w3c-dist-auth@w3.org mailing list only to avoid too much cross posting.
--Boundary_(ID_Lg8ETQRR5+Vlp/WGoeGBLQ)-- From Arnaud.Quillaud@Sun.COM Fri Nov 20 08:18:31 2009 Return-Path: X-Original-To: caldav@core3.amsl.com Delivered-To: caldav@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8ADA83A6908; Fri, 20 Nov 2009 08:18:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.05 X-Spam-Level: X-Spam-Status: No, score=-3.05 tagged_above=-999 required=5 tests=[AWL=-3.648, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_38=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rJ-be4f7ozFQ; Fri, 20 Nov 2009 08:18:30 -0800 (PST) Received: from mail385c25.carrierzone.com (mail385c25.carrierzone.com [209.235.146.155]) by core3.amsl.com (Postfix) with ESMTP id 4F4203A6814; Fri, 20 Nov 2009 08:18:30 -0800 (PST) X-Authenticated-User: master.tencoassemblies.com Received: from TENCOSERVER.TencoAssembliesInc.local (static-68-162-87-75.phil.east.verizon.net [68.162.87.75]) (authenticated bits=0) by mail385c25.carrierzone.com (8.13.6/8.13.1) with ESMTP id nAKGILXL007765; Fri, 20 Nov 2009 16:18:24 GMT Received: from TENCOSERVER.TencoAssembliesInc.local ([10.0.0.2]) by TENCOSERVER.TencoAssembliesInc.local with Microsoft SMTPSVC(5.0.2195.6713); Fri, 20 Nov 2009 11:16:05 -0500 Received: by TENCOSERVER.TencoAssembliesInc.local (Microsoft Connector for POP3 Mailboxes 5.00.2195) with SMTP (Global POP3 Download) id MSG11202009-111602-9166.MMD@TencoAssembliesInc.local; Fri, 20 Nov 2009 11:16:02 -0500 X-Envelope-From: w3c-dist-auth-request@frink.w3.org Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by mail368c25.carrierzone.com (8.13.6/8.13.1) with ESMTP id nAKGFGaq005760 for ; Fri, 20 Nov 2009 11:15:18 -0500 Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from ) id 1NBW7y-0001wZ-3I for w3c-dist-auth-dist@listhub.w3.org; Fri, 20 Nov 2009 16:14:30 +0000 Received: from maggie.w3.org ([193.51.208.68]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1NBW7w-0001vg-SX for w3c-dist-auth@listhub.w3.org; Fri, 20 Nov 2009 16:14:29 +0000 Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by maggie.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1NBW7o-0007D8-M2 for w3c-dist-auth@w3.org; Fri, 20 Nov 2009 16:14:23 +0000 Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nAKGDnnw006272 for ; Fri, 20 Nov 2009 16:13:49 GMT MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_6nHdPuL4GveD3G1pS17k4A)" Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KTE00J00ZZP4V00@fe-emea-09.sun.com> for w3c-dist-auth@w3.org; Fri, 20 Nov 2009 16:13:37 +0000 (GMT) Received: from vpn-129-150-118-65.uk.sun.com ([unknown] [129.150.118.65]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KTF00AUB12GW580@fe-emea-09.sun.com>; Fri, 20 Nov 2009 16:13:29 +0000 (GMT) Date: Fri, 20 Nov 2009 17:13:28 +0100 From: Arnaud Quillaud In-reply-to: <1258668093.15545.555.camel@happy.home.mcmillan.net.nz> To: Andrew McMillan Message-id: <4B06C028.9050200@sun.com> References: <4B057E6B.7040808@sun.com> <1258668093.15545.555.camel@happy.home.mcmillan.net.nz> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.4pre) Gecko/20090915 Lightning/1.0pre Thunderbird/3.0b4 Received-SPF: none X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-6.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4 X-W3C-Scan-Sig: maggie.w3.org 1NBW7o-0007D8-M2 942167713015bbc2c987aba2ab24c545 X-Original-To: w3c-dist-auth@w3.org Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13178 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Resent-Message-Id: Resent-Date: Fri, 20 Nov 2009 16:14:30 +0000 X-MMR: 0 X-Antivirus: Scanned by F-Prot Antivirus (http://www.f-prot.com) X-OriginalArrivalTime: 20 Nov 2009 16:16:05.0679 (UTC) FILETIME=[C2F1EBF0:01CA69FC] Cc: caldav@ietf.org, w3c-dist-auth@w3.org, vcarddav@ietf.org Subject: Re: [caldav] [VCARDDAV] new webdav sync draft X-BeenThere: caldav@ietf.org X-Mailman-Version: 2.1.9 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 16:18:31 -0000 This is a multi-part message in MIME format. --Boundary_(ID_6nHdPuL4GveD3G1pS17k4A) Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-Transfer-Encoding: 7BIT 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 w3c-dist-auth@w3.org mailing list only to avoid too much cross posting. --Boundary_(ID_6nHdPuL4GveD3G1pS17k4A) Content-type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by gmp-eb-inf-2.sun.com id nAKGDnnw006272 = 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 (=20
http://www.ietf.org/id/draft-daboo-webdav-sync-02.tx=
t ).

This draft addresses several, if not all, of the comments from the last=20
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=20

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=C2=A0 w3c-dist-auth@w3.org mailing list only = to avoid too much cross posting.
--Boundary_(ID_6nHdPuL4GveD3G1pS17k4A)-- From julian.reschke@gmx.de Fri Nov 20 09:38:14 2009 Return-Path: X-Original-To: caldav@core3.amsl.com Delivered-To: caldav@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F39E3A6875 for ; Fri, 20 Nov 2009 09:38:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.535 X-Spam-Level: X-Spam-Status: No, score=-4.535 tagged_above=-999 required=5 tests=[AWL=-1.936, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lZr89RPGPxMe for ; Fri, 20 Nov 2009 09:38:13 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id DFF643A6A38 for ; Fri, 20 Nov 2009 09:38:12 -0800 (PST) Received: (qmail invoked by alias); 20 Nov 2009 17:38:08 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.105]) [217.91.35.233] by mail.gmx.net (mp025) with SMTP; 20 Nov 2009 18:38:08 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+IxgRo3wuIOqRHXKwXql3/erUI0GzxqGrKCX7qgT ntWn0NQk092nwL Message-ID: <4B06D3FA.8050904@gmx.de> Date: Fri, 20 Nov 2009 18:38:02 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Alexey Melnikov References: <4B057E6B.7040808@sun.com> (sfid-20091120_062140_570344_FA568882) <1258668093.15545.555.camel@happy.home.mcmillan.net.nz> <4B064079.50404@gmx.de> <351598D1DDF378AF6AF4C3E4@caldav.corp.apple.com> <4B06A836.7010007@gmx.de> <4B06D073.5080107@isode.com> In-Reply-To: <4B06D073.5080107@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.57 Cc: Arnaud Quillaud , caldav@ietf.org, w3c-dist-auth@w3.org, vcarddav@ietf.org Subject: Re: [caldav] [VCARDDAV] new webdav sync draft X-BeenThere: caldav@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 17:38:14 -0000 Alexey Melnikov wrote: > ... >> : >> >> "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 From julian.reschke@gmx.de Fri Nov 20 09:48:28 2009 Return-Path: X-Original-To: caldav@core3.amsl.com Delivered-To: caldav@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48BDF3A6985; Fri, 20 Nov 2009 09:48:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.397 X-Spam-Level: X-Spam-Status: No, score=-8.397 tagged_above=-999 required=5 tests=[AWL=2.202, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SiEHxLrALr7H; Fri, 20 Nov 2009 09:48:28 -0800 (PST) Received: from mail384c25.carrierzone.com (mail384c25.carrierzone.com [209.235.146.154]) by core3.amsl.com (Postfix) with ESMTP id 101733A6857; Fri, 20 Nov 2009 09:48:27 -0800 (PST) X-Authenticated-User: master.tencoassemblies.com Received: from TENCOSERVER.TencoAssembliesInc.local (static-68-162-87-75.phil.east.verizon.net [68.162.87.75]) (authenticated bits=0) by mail384c25.carrierzone.com (8.13.6/8.13.1) with ESMTP id nAKHmKGp026025; Fri, 20 Nov 2009 17:48:22 GMT Received: from TENCOSERVER.TencoAssembliesInc.local ([10.0.0.2]) by TENCOSERVER.TencoAssembliesInc.local with Microsoft SMTPSVC(5.0.2195.6713); Fri, 20 Nov 2009 12:46:04 -0500 Received: by TENCOSERVER.TencoAssembliesInc.local (Microsoft Connector for POP3 Mailboxes 5.00.2195) with SMTP (Global POP3 Download) id MSG11202009-124600-9193.MMD@TencoAssembliesInc.local; Fri, 20 Nov 2009 12:46:00 -0500 X-Envelope-From: w3c-dist-auth-request@frink.w3.org Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by mail364c25.carrierzone.com (8.13.6/8.13.1) with ESMTP id nAKHdVDR011472 for ; Fri, 20 Nov 2009 12:39:33 -0500 Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from ) id 1NBXRU-0005v4-5k for w3c-dist-auth-dist@listhub.w3.org; Fri, 20 Nov 2009 17:38:44 +0000 Received: from bart.w3.org ([128.30.52.63]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1NBXRT-0005uQ-6B for w3c-dist-auth@listhub.w3.org; Fri, 20 Nov 2009 17:38:43 +0000 Received: from mail.gmx.net ([213.165.64.20]) by bart.w3.org with smtp (Exim 4.69) (envelope-from ) id 1NBXRR-0007HI-99 for w3c-dist-auth@w3.org; Fri, 20 Nov 2009 17:38:43 +0000 Received: (qmail invoked by alias); 20 Nov 2009 17:38:08 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.105]) [217.91.35.233] by mail.gmx.net (mp025) with SMTP; 20 Nov 2009 18:38:08 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+IxgRo3wuIOqRHXKwXql3/erUI0GzxqGrKCX7qgT ntWn0NQk092nwL Message-ID: <4B06D3FA.8050904@gmx.de> Date: Fri, 20 Nov 2009 18:38:02 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Alexey Melnikov References: <4B057E6B.7040808@sun.com> (sfid-20091120_062140_570344_FA568882) <1258668093.15545.555.camel@happy.home.mcmillan.net.nz> <4B064079.50404@gmx.de> <351598D1DDF378AF6AF4C3E4@caldav.corp.apple.com> <4B06A836.7010007@gmx.de> <4B06D073.5080107@isode.com> In-Reply-To: <4B06D073.5080107@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.57 Received-SPF: pass X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-2.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001 X-W3C-Scan-Sig: bart.w3.org 1NBXRR-0007HI-99 22109b5a54b7a8a7014b4f4a4fd6d12c X-Original-To: w3c-dist-auth@w3.org Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13179 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Resent-Message-Id: Resent-Date: Fri, 20 Nov 2009 17:38:44 +0000 X-MMR: 0 X-Antivirus: Scanned by F-Prot Antivirus (http://www.f-prot.com) X-OriginalArrivalTime: 20 Nov 2009 17:46:04.0132 (UTC) FILETIME=[54AC7A40:01CA6A09] Cc: Arnaud Quillaud , caldav@ietf.org, w3c-dist-auth@w3.org, vcarddav@ietf.org Subject: Re: [caldav] [VCARDDAV] new webdav sync draft X-BeenThere: caldav@ietf.org X-Mailman-Version: 2.1.9 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 17:48:28 -0000 Alexey Melnikov wrote: > ... >> : >> >> "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