Subject: [core] draft-ietf-core-link-format-13: limitations to multiple values in single attribute removed?

From: "Dijk, Esko" <[email-masked]>
Date: Fri, 1 Jun 2012 08:25:54 +0000

An additional point: we had ticket #178 (http://trac.tools.ietf.org/wg/core/trac/ticket/178 ) to impose SHOULD NOT for use of multiple values in a single attribute. Later we had #199 (http://trac.tools.ietf.org/wg/core/trac/ticket/199 ) to align better with RFC5988 in case multiple values is needed despite the SHOULD NOT. However it seems that the "SHOULD NOT" was dropped without discussion in writing the new text.

I'm ok with the newest solution, though it implies a bit more parsing complexity on constrained devices. I did not find clear reasons/discussion for this change of mind though.

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.

---

From: Zach Shelby <[email-masked]>
Date: Fri, 1 Jun 2012 13:39:46 +0300

Esko,

> An additional point: we had ticket #178 (http://trac.tools.ietf.org/wg/core/trac/ticket/178 ) to impose SHOULD NOT for use of multiple values in a single attribute. Later we had #199 (http://trac.t…

This was the result of two changes that we made due to IETF LC and IESG reviews (there were discussions and tickets, but this was an easy point to miss):

1. Due to the new CoRE Parameters registries, the rt= and if= attributes became relation-types, just like rel=. Thus they inherited the same properties.

2. In the past, we have allowed multiple rt= or if= attributes to be included in a link, e.g.:

</sensor/temp>;rt="temperature";rt="outdoor-temperature"

However in order to be compatible with RFC5988 and rel=, we were asked to no longer allow multiple attributes (no other RFC5988 parameters do), but instead allow multiple values in the attribute:

</sensor/temp>;rt="temperature outdoor-temperature"

The result of 1. and 2. is that we went from multiple attributes to multiple values in an attribute. This achieves the same thing in the end, and now all the relation-types attributes can be handled the same way. 

> I’m ok with the newest solution, though it implies a bit more parsing complexity on constrained devices. I did not find clear reasons/discussion for this change of mind though.

A constrained node is not forced to understand/store multiple values for an attribute if its application has no such need. Also since each value in a relation-type can not contain spaces, it is easy to parse that in my experience. 

Hopefully the explanation above clarifies the reasoning?

Zach

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

---

From: "Dijk, Esko" <[email-masked]>
Date: Fri, 1 Jun 2012 11:14:34 +0000

Yes, clear for me

thanks
Esko

-----Original Message-----
From: Zach Shelby [mailto:[email-masked]] 
Sent: Friday 1 June 2012 12:40
To: Dijk, Esko
Cc: [email-masked] WG
Subject: Re: draft-ietf-core-link-format-13: limitations to multiple values in single attribute removed?

Esko,

Zach