Re: [apps-discuss] Fwd: New Version Notification for draft-nottingham-link-hint-00.txt

Erik Wilde <dret@berkeley.edu> Tue, 11 June 2013 23:11 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 83C7321F9B86 for <apps-discuss@ietfa.amsl.com>; Tue, 11 Jun 2013 16:11:50 -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 n2m0031gqx58 for <apps-discuss@ietfa.amsl.com>; Tue, 11 Jun 2013 16:11:46 -0700 (PDT)
Received: from cm02fe.IST.Berkeley.EDU (cm02fe.IST.Berkeley.EDU [169.229.218.143]) by ietfa.amsl.com (Postfix) with ESMTP id 61F5821F9B77 for <apps-discuss@ietf.org>; Tue, 11 Jun 2013 16:11:46 -0700 (PDT)
Received: from mobile-166-137-185-191.mycingular.net ([166.137.185.191] helo=dretpro.local) by cm02fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from <dret@berkeley.edu>) id 1UmXj6-00025x-9K; Tue, 11 Jun 2013 16:11:46 -0700
Message-ID: <51B7AEAF.20404@berkeley.edu>
Date: Tue, 11 Jun 2013 16:11:43 -0700
From: Erik Wilde <dret@berkeley.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: IETF Apps Discuss <apps-discuss@ietf.org>
References: <20130610033804.19451.29465.idtracker@ietfa.amsl.com> <E6062DBC-CD7B-47CA-A6F0-5E7D64C0DB55@mnot.net>
In-Reply-To: <E6062DBC-CD7B-47CA-A6F0-5E7D64C0DB55@mnot.net>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: Mark Nottingham <mnot@mnot.net>, REST-Discuss <rest-discuss@yahoogroups.com>
Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-nottingham-link-hint-00.txt
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: Tue, 11 Jun 2013 23:11:50 -0000

On 2013-06-09 20:38 , Mark Nottingham wrote:
>> Filename:	 draft-nottingham-link-hint
>> Revision:	 00
>> Title:		 HTTP Link Hints
>> Creation date:	 2013-06-10
>> Group:		 Individual Submission
>> Number of pages: 12
>> URL:             http://www.ietf.org/internet-drafts/draft-nottingham-link-hint-00.txt
>> Status:          http://datatracker.ietf.org/doc/draft-nottingham-link-hint
>> Htmlized:        http://tools.ietf.org/html/draft-nottingham-link-hint-00
>> Abstract:
>>    This memo specifies "HTTP Link Hints", a mechanism for annotating Web
>>    links to HTTP(S) resources with information that otherwise might be
>>    discovered by interacting with them.

generally speaking, i think this might become a very useful way how 
various services can expose more helpful links to clients, if they 
choose to do so, and if the clients are interesting in taking that 
information into account.

but i have one question about the general registry model: the current 
draft says that hints MUST have a name (very reasonable, of course), but 
also that hints MUST have their data model being defined in JSON.

http://tools.ietf.org/html/draft-nottingham-link-hint-00#section-5.1

living in a world where we have JSON services, XML services, and RDF 
services, it seems that hard-coding a specific language data model into 
such a spec (without constraining it in any way) will limit the utility 
of such a registry. for example, in the Home Document draft, which is 
the original source of the link hint idea, the hints were hard-coded 
with very constrained data models. this made it relatively easy to 
expose them in a different syntax (in the XML Home Document draft):

http://tools.ietf.org/html/draft-wilde-home-xml-01#page-4

without getting too much into the details of this specific registry: 
what are the best practices about allowing/controlling language 
dependencies in registries? personally, i would feel more comfortable 
with having a registry that is of equal value to people regardless of 
their implementation language, but then again that means that the 
registry itself must define a "mini-language" of its own.

any pointers to similar situations and how they were resolved would be 
greatly appreciated. thanks and 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 |