Re: Last Call: draft-daboo-srv-caldav (Use of SRV records for locating CalDAV and CardDAV services) to Proposed Standard

Cyrus Daboo <cyrus@daboo.name> Wed, 23 June 2010 21:05 UTC

Return-Path: <cyrus@daboo.name>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AD663A69C7 for <ietf@core3.amsl.com>; Wed, 23 Jun 2010 14:05:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.001
X-Spam-Level:
X-Spam-Status: No, score=-3.001 tagged_above=-999 required=5 tests=[AWL=-0.702, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
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 SnPeJ4YAMZx9 for <ietf@core3.amsl.com>; Wed, 23 Jun 2010 14:05:46 -0700 (PDT)
Received: from daboo.name (daboo.name [151.201.22.177]) by core3.amsl.com (Postfix) with ESMTP id 5E7463A69B9 for <ietf@ietf.org>; Wed, 23 Jun 2010 14:05:46 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 36F5C17C852C4; Wed, 23 Jun 2010 17:05:54 -0400 (EDT)
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 kzMTkeKYmkNL; Wed, 23 Jun 2010 17:05:53 -0400 (EDT)
Received: from caldav.corp.apple.com (unknown [17.101.32.44]) by daboo.name (Postfix) with ESMTPSA id 77B6117C852B9; Wed, 23 Jun 2010 17:05:52 -0400 (EDT)
Date: Wed, 23 Jun 2010 17:05:49 -0400
From: Cyrus Daboo <cyrus@daboo.name>
To: Patrik Fältström <paf@cisco.com>
Subject: Re: Last Call: draft-daboo-srv-caldav (Use of SRV records for locating CalDAV and CardDAV services) to Proposed Standard
Message-ID: <6EDEE4A17E063608491655AF@caldav.corp.apple.com>
In-Reply-To: <856941CB-7C17-4919-9B4B-CBD3FF135C19@cisco.com>
References: <20100618155119.133353A6A8F@core3.amsl.com> <50BC2CEC-9EF6-4A0E-886F-6140552913F1@cisco.com> <29086_1277189668_o5M6sRJn006182_307E2698-A9DF-4198-8FEF-C5DE7EE270DB@cisco.com> <923C2AD1F5768D40D940E71A@caldav.corp.apple.com> <856941CB-7C17-4919-9B4B-CBD3FF135C19@cisco.com>
X-Mailer: Mulberry/4.1.0a1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline; size="1661"
Cc: Cullen Jennings <fluffy@cisco.com>, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Jun 2010 21:05:47 -0000

Hi Patrik,

--On June 23, 2010 10:07:44 PM +0200 Patrik Fältström <paf@cisco.com> 
wrote:

>> I did chat with a few server implementors about this and the feeling was
>> SRV + .well-known is a good solution that can quickly be deployed. Some
>> points:
>>
>> 1) SRV's are very deployable today - a new RR will be harder to deploy.
>>
>> 2) There is a push to support SRV's with other protocols (e.g.
>> draft-daboo-srv-email for IMAP, POP3, and Submission) so from an
>> operational standpoint its likely to be more common.
>>
>> 3) .well-known is useful in the absence of any DNS records. i.e. if no
>> SRV/URI were available, a client can still try auto-discovery by
>> attempting an HTTP connection to the host (derived from user input) and
>> the .well-known path.
>
> Hmm...regarding the new RR, the only thing I can think of today is the
> need for some changes in the provisioning system from which one create
> the DNS zones. I do not know of any DNS code today that can not handle
> "unknown" DNS RR Types, but maybe I am wrong? I am though confused over
> (1) as this is 2010 and not 1998.

I am thinking more of client APIs.

> Regarding (3), I think it is sad people move redirects and lookups and
> functionality to be on top of HTTP instead of IP. And I do not understand
> "in the absence of DNS"...that is an interesting situation ;-)
> Specifically to use that as the foundation for the architecture to use
> for calendaring, that is -- I hope -- one of the more fundamental
> applications on the Internet.

Sorry - bad wording on my part. What I meant was "in the absence of a 
service-type to hostname mapping in the DNS".

-- 
Cyrus Daboo