Re: [Ietf-caldav] Going from browser to application

Julian Reschke <julian.reschke@gmx.de> Wed, 17 May 2006 12:18 UTC

Return-Path: <julian.reschke@gmx.de>
X-Original-To: ietf-caldav@osafoundation.org
Delivered-To: ietf-caldav@osafoundation.org
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id B8F3C7F82D for <ietf-caldav@osafoundation.org>; Wed, 17 May 2006 05:18:08 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id A9E1514227E for <ietf-caldav@osafoundation.org>; Wed, 17 May 2006 05:18:08 -0700 (PDT)
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 32311-02 for <ietf-caldav@osafoundation.org>; Wed, 17 May 2006 05:18:07 -0700 (PDT)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by laweleka.osafoundation.org (Postfix) with SMTP id 52745142271 for <ietf-caldav@osafoundation.org>; Wed, 17 May 2006 05:18:07 -0700 (PDT)
Received: (qmail invoked by alias); 17 May 2006 12:18:06 -0000
Received: from pd95b23e9.dip0.t-ipconnect.de (EHLO [192.168.1.61]) [217.91.35.233] by mail.gmx.net (mp029) with SMTP; 17 May 2006 14:18:06 +0200
X-Authenticated: #1915285
Message-ID: <446B147B.50306@gmx.de>
Date: Wed, 17 May 2006 14:18:03 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: Mike Shaver <mike.shaver@gmail.com>
Subject: Re: [Ietf-caldav] Going from browser to application
References: <19947449-68C8-40F7-A9B1-2182D13E1D29@osafoundation.org> <cc092ba00605162253g355bac13me28fd79d9ba0911d@mail.gmail.com>
In-Reply-To: <cc092ba00605162253g355bac13me28fd79d9ba0911d@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-1.6 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00
X-Spam-Level:
Cc: CalDAV DevList <ietf-caldav@osafoundation.org>
X-BeenThere: ietf-caldav@osafoundation.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussions on Calendar Access protocol based on WebDAV <ietf-caldav.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-caldav>, <mailto:ietf-caldav-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-caldav>
List-Post: <mailto:ietf-caldav@osafoundation.org>
List-Help: <mailto:ietf-caldav-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-caldav>, <mailto:ietf-caldav-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 17 May 2006 12:18:08 -0000

Mike Shaver schrieb:
> On 5/16/06, Lisa Dusseault <lisa@osafoundation.org> wrote:
>> When the same data can be viewed either as a Web page or as data to
>> be consumed by an application, there's a general issue over how to
>> get the user from one to the other.  Typically it's how you get the
>> user from browser to specialized application.
> 
> Content-disposition: attachment?
> 
> I'm not exactly sure why a browser can't be the thing that handles it
> correctly, but C-d:a is how servers are supposed to indicate "probably
> want the user to pick where this goes", by my recollection.

Yep, but I'm not sure how this helps here. Sending that header will 
cause user agents to display a download dialog. What we're looking for 
is something that triggers automatic invocation of a non-browser 
application for a specific URL.

> I don't like MIME type for this, since as you say it's the same data
> (in the same format), which seems to me to have the same undesirable
> characteristics as using a different scheme for data that comes over
> HTTP.

Depends on how you use the MIME type. The one I defined in 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-mount-04.html> is 
used to transport information about how to "mount" an HTTP URL in the 
system's WebDAV client. That information includes a base URL (mount 
target), a child collection to be displayed (which may be below the 
mount target), plus additional information (such as account).

Note sure how you would do that using response headers...

Best regards, Julian