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

Erik Wilde <dret@berkeley.edu> Thu, 12 April 2012 05:36 UTC

Return-Path: <dret@berkeley.edu>
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 C299921F85A5 for <apps-discuss@ietfa.amsl.com>; Wed, 11 Apr 2012 22:36:18 -0700 (PDT)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7mBjgUTx7ul for <apps-discuss@ietfa.amsl.com>; Wed, 11 Apr 2012 22:36:18 -0700 (PDT)
Received: from cm01fe.IST.Berkeley.EDU (cm01fe.IST.Berkeley.EDU [169.229.218.142]) by ietfa.amsl.com (Postfix) with ESMTP id 1253421F8527 for <apps-discuss@ietf.org>; Wed, 11 Apr 2012 22:36:18 -0700 (PDT)
Received: from 108-67-66-127.lightspeed.sntcca.sbcglobal.net ([108.67.66.127] helo=[192.168.1.64]) by cm01fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from <dret@berkeley.edu>) id 1SIChb-0004cD-4p; Wed, 11 Apr 2012 22:36:16 -0700
Message-ID: <4F8669D4.7050401@berkeley.edu>
Date: Wed, 11 Apr 2012 22:36:20 -0700
From: Erik Wilde <dret@berkeley.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Mark Nottingham <mnot@mnot.net>
References: <04FC3F79-93B5-4F86-82B2-42029138E202@mnot.net> <4F7F416C.3050400@berkeley.edu> <FFA388B3-F4D9-47AB-81EF-0761200438FB@mnot.net>
In-Reply-To: <FFA388B3-F4D9-47AB-81EF-0761200438FB@mnot.net>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "apps-discuss@ietf.org application-layer protocols" <apps-discuss@ietf.org>, REST Discuss <rest-discuss@yahoogroups.com>
Subject: Re: [apps-discuss] 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 05:36:18 -0000

hello mark.

thanks for the comments!

On 2012-04-10 8:56 , Mark Nottingham wrote:
> On 06/04/2012, at 2:18 PM, Erik Wilde wrote:
>> now i am little bit confused. taking your example, i am not concerned with the link relation that was used to discover 'foo' at all. all i am concerned with is that if i am retrieving 'foo' and i find a 'bar' profile identifier in the representation, i know that it follows constraints and conventions beyond the 'foo' media type.
> Yup.

good to see we're in basic agreement.

>> one example i am currently considering adding is atompub. currently, when you retrieve a feed, there's no way to tell it's atompub-capable just by looking at it.
> Well, what thing in this case is atom pub capable? The format that the links are occurring within, or the targets of the links themselves? I'd argue the latter. You can take that argument too far, of course, but generally I see profiles as describing format conventions, and link relations as describing behaviours of resources. Of course, some of those behaviours can be "produce this format" and some of the formatting conventions can be "link to something with this behaviour".

with atompub i think you're right about 'edit' links in entries, so if i 
aggregate atompub-capable feeds, then my aggregate feed may not be 
atompub-capable, but the entries may very well be. but if my feed is 
indeed able to accept POST requests to create new entries, then there 
simply is no link to represent that fact, and a profile URI would be one 
way to represent that capability in the feed itself.

while i see your point about profile more being about format conventions 
(this is where HTML started this idea, and in that case my podcast 
example might better fit your bill), i think eventually the line between 
format conventions and behavior is fuzzy. maybe the best way for me to 
go forward is to finish the examples section, and then we can start more 
concrete discussions whether this would be the kind of scenario we'd 
like to encourage for 'profile' links.

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 |