Re: [core] draft-shelby-core-resource-directory-04: unclear 'rt' parameter in Update

Zach Shelby <zach@sensinode.com> Mon, 10 September 2012 08:20 UTC

Return-Path: <zach@sensinode.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 919DE21F85E6 for <core@ietfa.amsl.com>; Mon, 10 Sep 2012 01:20:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVE7DQj09fgD for <core@ietfa.amsl.com>; Mon, 10 Sep 2012 01:20:51 -0700 (PDT)
Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 55A5D21F85D5 for <core@ietf.org>; Mon, 10 Sep 2012 01:20:50 -0700 (PDT)
Received: from [213.145.205.251] ([213.145.205.251]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q8A8KkSh012003; Mon, 10 Sep 2012 11:20:46 +0300
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="windows-1252"
From: Zach Shelby <zach@sensinode.com>
In-Reply-To: <3fb16263206d83b043a35c2a148211bf@xs4all.nl>
Date: Mon, 10 Sep 2012 11:20:46 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <7028F10B-37EF-4309-BC53-3B85E8E9AA89@sensinode.com>
References: <031DD135F9160444ABBE3B0C36CED618AE2066@011-DB3MPN2-081.MGDPHG.emi.philips.com> <3543A55E-A549-4EDA-AB5D-29D2B44E691E@sensinode.com> <3fb16263206d83b043a35c2a148211bf@xs4all.nl>
To: consultancy@vanderstok.org
X-Mailer: Apple Mail (2.1084)
Cc: core@ietf.org
Subject: Re: [core] draft-shelby-core-resource-directory-04: unclear 'rt' parameter in Update
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Sep 2012 08:20:53 -0000

Hi Peter,

On Sep 10, 2012, at 11:03 AM, peter van der Stok wrote:

> Zach,
> 
> In my opinion the same overloading of resource and end-type happens at several places in the document and the core -interfaces document.
> The grouping concept adds to the confusion. Making the distinction up front in the document would be helpful.
> You may consider resource-type, endpoint-type, and group-type. In core-interfaces you do a first attempt and talk about resource-type for resources and for Function-sets. Althoug you keep the same parameter name rt, you seem to distinguish in the name space
> What to do with batches, which are heterogeneous, is another question.
> 
> It would be nice if this is solved homogeneously over all documents. May be it is, and I just combine the wrong pieces of text.

I definitely agree some better uniformity and explanation would help. Matthieu and I can take a shot at that in the next update in both core-interfaces, and then in resource-directory as well. 

Group type, interesting idea we haven't been using yet. Not sure if we have a real need for it or not, but let's keep it in mind when we see a need. It might be that the group name is already a good enough descriptor. 

Zach

> 
> peter
> 
> 
> Zach Shelby schreef op 2012-09-07 11:38:
>> Esko,
>> 
>> The rt= query string parameter in a Registration or Update sets the
>> "Endpoint Type", which gives some meaning to an endpoint semantically
>> in a backend system. That can be used e.g. to set the correct icon for
>> an endpoint on a map. That has no effect on the Resource Type
>> parameter of individual resources, which you are correct wouldn't make
>> sense.
>> 
>> Probably using rt= for that query string parameter is confusing.
>> Could be better to change that to et= or type= in the query string?
>> 
>> Thanks,
>> Zach
>> 
>> On Aug 30, 2012, at 1:28 PM, Dijk, Esko wrote:
>> 
>>> Hello Zach, all,
>>> 
>>> in section 5.3 (Update) the ‘rt’ parameter can be specified when doing a PUT update of registration to Resource Directory. To me it’s not clear what this parameter would do. The resource types of each resource that is updated, would be already included in the payload as “rt=.....” link-format parameters. I assume it should be removed from the allowed query parameters in section 5.3?
>>> 
>>> regards,
>>> Esko
>>> 
>>> The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.
> 
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297