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

Mark Nottingham <mnot@mnot.net> Tue, 25 June 2013 04:18 UTC

Return-Path: <mnot@mnot.net>
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 0A56421E8175 for <apps-discuss@ietfa.amsl.com>; Mon, 24 Jun 2013 21:18:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.3
X-Spam-Level:
X-Spam-Status: No, score=-105.3 tagged_above=-999 required=5 tests=[AWL=-2.700, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 PNwFm8cUwQd7 for <apps-discuss@ietfa.amsl.com>; Mon, 24 Jun 2013 21:17:58 -0700 (PDT)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 9FBD921F9CB7 for <apps-discuss@ietf.org>; Mon, 24 Jun 2013 21:17:54 -0700 (PDT)
Received: from [192.168.1.80] (unknown [118.209.171.15]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id CE8A9509B6; Tue, 25 Jun 2013 00:17:52 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <51B7AEAF.20404@berkeley.edu>
Date: Tue, 25 Jun 2013 14:17:59 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <4CD4652F-4EAF-4258-A6EB-577019018D2C@mnot.net>
References: <20130610033804.19451.29465.idtracker@ietfa.amsl.com> <E6062DBC-CD7B-47CA-A6F0-5E7D64C0DB55@mnot.net> <51B7AEAF.20404@berkeley.edu>
To: Erik Wilde <dret@berkeley.edu>
X-Mailer: Apple Mail (2.1508)
Cc: REST-Discuss <rest-discuss@yahoogroups.com>, IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] 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, 25 Jun 2013 04:18:03 -0000

Hi Erik, 

Sorry for the delay - just back home now.

> 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.

It needs *a* data model.

> 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?

Whoa, hold on - who said anything about a language? This is just the underlying data model; you can express it in a document however makes sense.

> personally, i would feel more comfortable with having a registry that is of equal value to people regardless of their implementation language

You're using "language" quite loosely here. 

> , but then again that means that the registry itself must define a "mini-language" of its own.

-1. Defining Yet Another Data Model as a political solution to avoid picking an existing one is sub-optimal at best.

Cheers,


--
Mark Nottingham   http://www.mnot.net/