Re: [apps-discuss] [rest-discuss] Re: Feedback on draft-wilde-profile-link-00

Jan Algermissen <jan.algermissen@nordsc.com> Thu, 12 April 2012 07:12 UTC

Return-Path: <jan.algermissen@nordsc.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 652F121F8473 for <apps-discuss@ietfa.amsl.com>; Thu, 12 Apr 2012 00:12:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level:
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lwRSfJVhKQE5 for <apps-discuss@ietfa.amsl.com>; Thu, 12 Apr 2012 00:12:23 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by ietfa.amsl.com (Postfix) with ESMTP id 9400A21F84B2 for <apps-discuss@ietf.org>; Thu, 12 Apr 2012 00:12:23 -0700 (PDT)
Received: from [192.168.2.103] (p548FB5B7.dip.t-dialin.net [84.143.181.183]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0MJF5W-1SJt9r34Cg-002lHE; Thu, 12 Apr 2012 09:12:13 +0200
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Jan Algermissen <jan.algermissen@nordsc.com>
In-Reply-To: <4F8665E4.9050303@berkeley.edu>
Date: Thu, 12 Apr 2012 09:12:13 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <5006D354-A78D-4347-A3D1-0ED840BD81ED@nordsc.com>
References: <04FC3F79-93B5-4F86-82B2-42029138E202@mnot.net> <4F7F416C.3050400@berkeley.edu> <FFA388B3-F4D9-47AB-81EF-0761200438FB@mnot.net> <624F8E5E-7997-4716-AE84-78B30F7D2E38@nordsc.com> <4F8665E4.9050303@berkeley.edu>
To: Erik Wilde <dret@berkeley.edu>
X-Mailer: Apple Mail (2.1084)
X-Provags-ID: V02:K0:5+lqunDZ2L/vQxYyGbNyTWVAi+h34bCLBSWHD7QopgX LPqfmwJcR+vXwa5kBaNFkapRXUGi4K9tVb7/JxcgUAWSEPTZUs Tk2BBYq4A8E0PQiS/qOB3bGDevLyxOHQc26FrApiLRc4cM0uSs eNOAdJ8fSz943CNgxYdYRVATo8oO9wPyMxubTVKCVcX4BrKzUm 2xD4jdzI3wmHwL9mOzb5Qgv363NUMiMwqmkcr8AKarwX/9gjY7 t/q4F/zwZtz7kKVIBSogfHy7F+OU/FglyNyb3pjBqxKLrIQnNe bLB9pw7UM2/NPriEqKg6lu2VORfXeYdQxesr8/Na01juaKgSbV 61lQGmcAHCPlkXEl7tplD9SUbDEDVawmVzN1yHypki03h9oCey +JYEjMhh6VFIw==
X-Mailman-Approved-At: Thu, 12 Apr 2012 08:28:28 -0700
Cc: Mark Nottingham <mnot@mnot.net>, "apps-discuss@ietf.org application-layer protocols" <apps-discuss@ietf.org>, REST Discuss <rest-discuss@yahoogroups.com>
Subject: Re: [apps-discuss] [rest-discuss] Re: Feedback on draft-wilde-profile-link-00
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Apr 2012 07:12:24 -0000

Hi Erik,

On Apr 12, 2012, at 7:19 AM, Erik Wilde wrote:

> hello jan.
> 
> On 2012-04-10 11:58 , Jan Algermissen wrote:
>> Likewise, what does that check for atompub capabilities buy you? The reason you check for them is that you assume they are there in the first place. If that check fails .... then what? You are in exactly the same situation as when you POST you atom entry right away and see what happens.
> 
> the idea is to be able to check for the profile URI to see whether a feed i have discovered supports atompub or not. if it does, i might show an "upload" feature in a UI that otherwise i would not show. without the feed advertising its capabilities, i cannot know, and i certainly don't want to create a fake post to test whether atompub is supported or not.

Ok (though I personally would not see a profile as saying something about the resource, but about the payload)

Anyhow - have you considered supporting your use case with the 'service' link relation? The pointed-to service document would tell your UA, what resource are app-collections.

(BTW, seems the registry is broken there, because service cites atompub as its spec - which it is not).

Jan




> 
> if all operations in atompub were exposed via links, it would be a different story in this particular case, but they are not, so a profile URI would be one way to go. and it's just one example and not the whole 'profile' story.
> 
> cheers,
> 
> dret.
> 
> -- 
> erik wilde | mailto:dret@berkeley.edu  -  tel:+1-510-2061079 |
>           | UC Berkeley  -  School of Information (ISchool) |
>           | http://dret.net/netdret http://twitter.com/dret |