Re: [Gen-art] [core] Review: draft-ietf-core-link-format-11

Cullen Jennings <> Wed, 18 April 2012 18:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AC91D21F84FA; Wed, 18 Apr 2012 11:40:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id F2AIUUFAFLS3; Wed, 18 Apr 2012 11:40:52 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D3E0821F84EB; Wed, 18 Apr 2012 11:40:51 -0700 (PDT)
Received: from [] (unknown []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id BBA5B22E25D; Wed, 18 Apr 2012 14:40:44 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Cullen Jennings <>
In-Reply-To: <>
Date: Wed, 18 Apr 2012 12:40:43 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Zach Shelby <>
X-Mailer: Apple Mail (2.1084)
X-Mailman-Approved-At: Wed, 18 Apr 2012 11:41:47 -0700
Cc:, core WG <>
Subject: Re: [Gen-art] [core] Review: draft-ietf-core-link-format-11
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 18 Apr 2012 18:40:52 -0000

On Mar 8, 2012, at 5:55 AM, Zach Shelby wrote:

>> Major issues:
>>   What is the registration / collision avoidance strategy for resource type (rt) and interface description (if) values?  They are both defined as opaque strings which can happen to be URIs.  So there seems to be potential for collision.
> There is definitely a possibility for collision for those two attributes, especially as there will be a mix of specifications that define specific values to be used, and developers using their own values. Currently while those are being defined in CoRE drafts we can avoid collisions, but when other WGs or SDOs start defining them...
> We have deliberated on the idea of defining registries for rt= and if= values, but it has not been clear if that should be done in this document. Recently several CoRE drafts have been written that do specify well-known values for those fields, so it starts to become obvious that those registries would be useful. If I understand right, your recommendation would be that we define those registries in the IANA section of this document? I would be in favor of doing that.

Where are we on resolving topic? This is closely linked with the registry proposed in senml.