Re: [apps-discuss] URI templates in Link header fields

Erik Wilde <> Mon, 29 August 2016 15:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DF4D612D78C for <>; Mon, 29 Aug 2016 08:30:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.791
X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=neutral reason="invalid (public key: not available)"
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 10epuY_zgYct for <>; Mon, 29 Aug 2016 08:30:51 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9527D12D77F for <>; Mon, 29 Aug 2016 08:30:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=Nz4oE9Mag1+buYkDFEXtep+PlEEvv3bi87DnEEKHcQU=; b=0LTSa7IcmdCCka+EsVKT9AAlyc H1Y3I9WFAoIw2QR7/RuhVJvmE7Az8rl/RbPy98tzsFCyts3DVbk4GOSn+WI/azuFYjjdJwSGyHEnt YVIFFaL4JxmyiMl1SXwAq1Ve2XabD+ZS4Tbhirr52XehnE4RHZ3/aA4DO/reIvOuqdcyWKUx3vKmN BxpdPrp7HLKPLLFvV9WwgjQIwA7PNTkv+N3m7PxsIj6kD+8WwxRK7Syx/LarRY8XYYFRL1jyxe7CF JNQaYpIPfS1RaEq6yhNZki9uv55CaP1SfZT6RGEjNRfEib/9yhKjaxS0BeQqZ6cgaW2p39jND0avO 7fuz09+w==;
Received: from ([]:58739 helo=[]) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from <>) id 1beOWQ-0000RV-AA; Mon, 29 Aug 2016 11:30:50 -0400
To: Julian Reschke <>, IETF Apps Discuss <>
References: <>
From: Erik Wilde <>
Message-ID: <>
Date: Mon, 29 Aug 2016 08:30:45 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
Archived-At: <>
Subject: Re: [apps-discuss] URI templates in Link header fields
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 29 Aug 2016 15:30:53 -0000

hello julian

On 2016-08-29 01:42, Julian Reschke wrote:
> In the meantime, I heard of a few cases where people were trying to use
> templates in Link header fields (an obvious thing to do), and came up
> with hacks to do so with the existing Link header field.
> I'm tempted to work on a small spec that defines an experimental new
> header field, similar to Link but allowing templates.

@mnot has been working on collecting ideas for an update to RFC 5988 for 
a while now. maybe that's one more motivation to go forward with this? 
i'd certainly be willing to put in some time to get it off the ground.

> Is anybody aware of existing code trying to use templates in Link header
> fields? If so, please report over here (or in doubt send private email).

this is not really code, but people want to use URI templates and there 
have been some efforts to provide a context that makes that more easy:

- @mnot's

- my own

- part of the JSON home model:

if i recall correctly all of these have slightly different use cases and 
models, but (unsurprisingly) also a lot of overlap. it would be great to 
consolidate all of this so that tooling and implementations can rely on 
a robust spec.



erik wilde | |
            |    |
            |    |