Subject: [core] A potential new ticket for '-d' usage in link format draft

From: Linyi Tian <[email-masked]>
Date: Wed, 10 Nov 2010 00:48:37 +0800

Hi, Z. Shelby and all

When I review the link format draft, I believe there is a potential issue
for d usage extension.

Consider the following example:
--Sensor-----Light
                |--Temp

For light, its URI could be
<Sensor/Light>;sh=²/l²;n=²LightLux²;d=²http://example.com/index²;ct=41

If the requestor sends GET /l, the xml description file will be returned
according to content type code 41. This is clear.

However what is the semantics behind the ³-d² URI is unclear. Even though
you mentioned that d could be a WADL definition, it is not possible for the
requestor to know the relation type and purpose of this d URI.

It is also unclear whether it is allowed for the requestor to use GET
command against this d URI. Do you think this would be a problem? I think
this needs to be clarified in the spec and the example.

By the way how to create a new ticket? Do I need to execute SQL to add a new
one? Is there any authority will review the reported issue and create a
ticket when he/she thinks this is really an issue?

Cheers,
Linyi

---

From: Robert Quattlebaum <[email-masked]>
Date: Wed, 10 Nov 2010 09:57:13 -0800

I got the feeling that the 'd' field was to be used similar to how XML namespaces are URIs. They may well point to something descriptive if actually queried, but the URI itself would normally be the only description needed or used. Devices would recognize the URIs that they support and use them. 

Then again, i could be misunderstanding this entirely or mixing my interpretation with my own worldview. Someone correct me if I'm mistaken. 

Sent from my iPad

On Nov 9, 2010, at 8:48 AM, Linyi Tian <[email-masked]> wrote:

> Hi, Z. Shelby and all
> 
> When I review the link format draft, I believe there is a potential issue for –d usage extension. 
> 
> For light, its URI could be <Sensor/Light>;sh=”/l”;n=”LightLux”;d=”http://example.com/index”;ct=41
> 
> If the requestor sends GET /l, the xml description file will be returned according to content type code 41. This is clear. 
> 
> However what is the semantics behind the “-d” URI is unclear. Even though you mentioned that –d could be a WADL definition, it is not possible for the requestor to know the relation type and purpose of this –d URI.
> 
> It is also unclear whether it is allowed for the requestor to use GET command against this –d URI. Do you think this would be a problem? I think this needs to be clarified in the spec and the example.
> 
> By the way how to create a new ticket? Do I need to execute SQL to add a new one? Is there any authority will review the reported issue and create a ticket when he/she thinks this is really an issue?
> 
> Cheers,
> Linyi
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Zach Shelby <[email-masked]>
Date: Thu, 11 Nov 2010 09:03:57 +0800

> I got the feeling that the 'd' field was to be used similar to how XML namespaces are URIs. They may well point to something descriptive if actually queried, but the URI itself would normally be th…

Right, this is exactly how it is meant to be used. I don't expect constrained devices to go and fetch a .wadl from the URI, parse it, and then generate code to interact the resource based on that :-/ 

Zach

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
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: Linyi Tian <[email-masked]>
Date: Thu, 11 Nov 2010 10:22:08 +0800

If I understand correctly, you are saying that the semantics will be defined
by the implementation. We just provide the mechanism to convey this URI in
the message and allow application to interpret.

The scenario came to my mind actually was from the draft. It says the -d
provides the URI to an interface to access the resource. Then WADL was
listed as an example. Did I misunderstood the draft?

Could you please give me a real example how can I use this -d field?

----------------------
2.3.  Description 'd' usage
The description "d" attribute can provide a URI to a specific
   interface definition used to access the target resource.  This could
   be for example a URI to the WADL definition of the target resource.

Cheers,
Linyi

On 10-11-11 上午9:03, "Zach Shelby" <[email-masked]> wrote:

>> I got the feeling that the 'd' field was to be used similar to how XML
>> namespaces are URIs. They may well point to something descriptive if actually
>> queried, but the URI itself would normally be the only description needed or
>> used. Devices would recognize the URIs that they support and use them.
> 
> Right, this is exactly how it is meant to be used. I don't expect constrained
> devices to go and fetch a .wadl from the URI, parse it, and then generate code
> to interact the resource based on that :-/
> 
> Zach
> 
>> 
>> Then again, i could be misunderstanding this entirely or mixing my
>> interpretation with my own worldview. Someone correct me if I'm mistaken.
>> 
>> Sent from my iPad
>> 
>>> for –d usage extension.
>>> <Sensor/Light>;sh=”/l”;n=”LightLux”;d=”http://example.com/index”;ct=41
>>> 
>>> However what is the semantics behind the “-d” URI is unclear. Even though
>>> you mentioned that –d could be a WADL definition, it is not possible for the
>>> requestor to know the relation type and purpose of this –d URI.
>>> 
>>> command against this –d URI. Do you think this would be a problem? I think

---

From: Robert Quattlebaum <[email-masked]>
Date: Thu, 11 Nov 2010 10:51:30 -0800

Hello Linyi!

> listed as an example. Did I misunderstood the draft?

The language in the draft is probably misleading. It should probably be reworded to indicate that the end devices are not expected to actually retrieve any document from the given URL, and that the value is only meant to identify a interface definition.

If you choose to implement a given interface definition, then seeing this field with the URI of the interface definition you support would simply indicate to you that you know how to read it. It could even be a URI which is not retrievable, like <urn:uuid:2cb8e2fa-b52a-4d33-9d45-c4a68939152d>. It is simply an identifier. If it happens to be a URI which points to a WADL definition, then that's great for developers---but it doesn't make any difference to constrained devices.

> Could you please give me a real example how can I use this -d field?

Lets say that there is a standardized interface definition for dim-able light fixtures called <http://example.com/light-intensity>. I have a CoAP light fixture and a CoAP dimmer switch---both of which support this interface definition. Lets say the both have a "Pair" button, so I press the pair button on both of them. The dimmer switch does service discovery by querying .well-known/core on the light fixture and notices that one of the returned items has an interface definition of <http://example.com/light-intensity>. Because the dimmer switch also supports <http://example.com/light-intensity>, it recognizes it and configures itself to use the URI that supported <http://example.com/light-intensity>. 

It is intended to be used simply as an opaque identifier by constrained devices to indicate that you can find a specific interface at the given location. That it happens to be a URI itself is somewhat confusing, but many other standards use URIs in a similar fashion (XML, for example).

I hope this helps.

__________________
Robert Quattlebaum
Jabber: [email-masked]
eMail:  [email-masked]
www:    http://www.deepdarc.com/