Re: [Ietf-carddav] Comments on draft-daboo-carddav-02

Cyrus Daboo <cyrus@daboo.name> Mon, 16 July 2007 15:31 UTC

Return-Path: <cyrus@daboo.name>
X-Original-To: ietf-carddav@osafoundation.org
Delivered-To: ietf-carddav@osafoundation.org
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 2AEDE7FCCC for <ietf-carddav@osafoundation.org>; Mon, 16 Jul 2007 08:31:22 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0428114220D for <ietf-carddav@osafoundation.org>; Mon, 16 Jul 2007 08:30:27 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -2.2
X-Spam-Level:
X-Spam-Status: No, score=-2.2 tagged_above=-50 required=4 tests=[AWL=0.201, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LuuZuEDPvSOY for <ietf-carddav@osafoundation.org>; Mon, 16 Jul 2007 08:30:26 -0700 (PDT)
Received: from mail2507.carrierzone.com (mail2507.carrierzone.com [64.29.147.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id E25BE14220A for <ietf-carddav@osafoundation.org>; Mon, 16 Jul 2007 08:30:25 -0700 (PDT)
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 mail2507.carrierzone.com (8.13.6.20060614/8.13.1) with ESMTP id l6GFUDnS021100; Mon, 16 Jul 2007 15:30:17 GMT
Received: from TENCOSERVER.TencoAssembliesInc.local ([10.0.0.2]) by TENCOSERVER.TencoAssembliesInc.local with Microsoft SMTPSVC(5.0.2195.6713); Mon, 16 Jul 2007 11:30:13 -0400
Received: by TENCOSERVER.TencoAssembliesInc.local (Microsoft Connector for POP3 Mailboxes 5.00.2195) with SMTP (Global POP3 Download) id MSG07162007-113012-11747.MMD@TencoAssembliesInc.local; Mon, 16 Jul 2007 11:30:12 -0400
X-From_: w3c-dist-auth-request@frink.w3.org Mon Jul 16 15:20:51 2007
X-Envelope-From: w3c-dist-auth-request@frink.w3.org
Received: from frink.w3.org (frink.w3.org [128.30.52.16]) by mail2574.carrierzone.com (8.13.6.20060614/8.13.1) with ESMTP id l6GFKnbq017912 for <JTentilucci@tencoassemblies.com>; Mon, 16 Jul 2007 15:20:50 GMT
Received: from lists by frink.w3.org with local (Exim 4.50) id 1IASMR-0002Ok-7B for w3c-dist-auth-dist@listhub.w3.org; Mon, 16 Jul 2007 15:19:43 +0000
Received: from aji.w3.org ([133.27.228.225]) by frink.w3.org with esmtp (Exim 4.50) id 1IASMP-0002Nx-Js for w3c-dist-auth@listhub.w3.org; Mon, 16 Jul 2007 15:19:41 +0000
Received: from piper.mulberrymail.com ([151.201.22.177] helo=mulberrymail.com) by aji.w3.org with esmtp (Exim 4.63) (envelope-from <cyrus@daboo.name>) id 1IASMM-00039o-Lf for w3c-dist-auth@w3.org; Mon, 16 Jul 2007 15:19:40 +0000
Received: from caldav.corp.apple.com ([17.101.32.44]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id l6GFJMaX026544 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Jul 2007 11:19:25 -0400
Date: Mon, 16 Jul 2007 11:19:17 -0400
From: Cyrus Daboo <cyrus@daboo.name>
To: "Mr. Demeanour" <mrdemeanour@jackpot.uk.net>, w3c-dist-auth@w3.org
Message-ID: <C4E535EC204E5BF24F6076F0@caldav.corp.apple.com>
In-Reply-To: <469B8976.9040402@jackpot.uk.net>
References: <4699F52B.10101@gmx.de> <DA70918551A4706E579F3829@caldav.corp.apple.com> <469B8976.9040402@jackpot.uk.net>
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
Received-SPF: none
X-SPF-Guess: pass
X-W3C-Hub-Spam-Status: No, score=-2.6
X-W3C-Scan-Sig: aji.w3.org 1IASMM-00039o-Lf 9248d9e12e73ffa9865c436089c6be3d
X-Original-To: w3c-dist-auth@w3.org
Subject: Re: [Ietf-carddav] Comments on draft-daboo-carddav-02
X-Archived-At: http://www.w3.org/mid/C4E535EC204E5BF24F6076F0@caldav.corp.apple.com
Resent-From: w3c-dist-auth@w3.org
X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/12723
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: <E1IASMR-0002Ok-7B@frink.w3.org>
Resent-Date: Mon, 16 Jul 2007 15:19:43 +0000
X-Antivirus: Scanned by F-Prot Antivirus (http://www.f-prot.com)
X-OriginalArrivalTime: 16 Jul 2007 15:30:13.0497 (UTC) FILETIME=[3416C690:01C7C7BE]
Cc: ietf-carddav@osafoundation.org
X-BeenThere: ietf-carddav@osafoundation.org
X-Mailman-Version: 2.1.5
List-Id: ietf-carddav.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-carddav>, <mailto:ietf-carddav-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-carddav>
List-Post: <mailto:ietf-carddav@osafoundation.org>
List-Help: <mailto:ietf-carddav-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-carddav>, <mailto:ietf-carddav-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Jul 2007 15:31:25 -0000

Hi Mr.,

--On July 16, 2007 4:06:30 PM +0100 "Mr. Demeanour" 
<mrdemeanour@jackpot.uk.net> wrote:

>> What do others thinks about this?
>
> Strongly in favour - and I agree with you that it should be separate
> from the CardDAV spec.
>
> But that doesn't force you to adopt the MKADDRESSBOOK route in the
> meantime, does it?

That is true. One option would be to keep MKADDRESSBOOK in, but if the 
MKCOL extension  spec beats CardDAV to the IESG we could remove it.

>>
>> 2) multiget allows both the data and properties to be returned in one
>>  go: i.e. it is the equivalent of a GET and a PROPFIND.
>
> Not really; the CalDAV multiget requires the server to parse the
> resource body, because the client can ask for selected iCalendar
> properties. ASs it happens, I think that was a rotten idea, and multiget
> would be better-off without that feature.

Returning partial data is important for "low capacity" devices such as 
mobile devices, who arguably benefit the most from multiget as well. Note 
that parsing the data is an implementation issue, e.g. servers that store 
the data in a database can simply implement the the "partial data" aspect 
by doing a query for only the requested parameters etc.

-- 
Cyrus Daboo