Subject: Re: [core] Core linking

From: Zach Shelby <[email-masked]>
Date: Mon, 22 Nov 2010 14:38:05 +0200

Martin Thomson and I discussed the CoRE link format after the WG meeting in Beijing, and he was nice enough to give us some helpful comments as well. Here I am CCing the list when responding as this compliments the comments from Peter too. 

On Nov 10, 2010, at 5:05 AM, Thomson, Martin wrote:

> 'd' sounds like a neat metadata indirection mechanism.  That's probably the best of these links.
> 
> Like others, I agree that 'sh' is not useful.  If you need a short URI for the resource, then you can simply identify the resource with a short URI and save the bytes from all uses for the resource.
> 
> 'id' seems a little strange.  Unless the scope of the identifier is something other than the server, the URL provides enough information for someone to identify a resource.  Does this have a different scope than the one server?  Or is the intent to convey information on from different identification domains?

We were originally thinking ID would have global scope, something like a UUID. However in Beijing it was suggested to instead give it server scope and use it as a kind of index. For example you might have three different hosted resources with the semantic name "TemperatureC". The index would be used to give each an index on the server. 

> I really like the format, but I have two requests:  
>  Can you use line terminations to separate links rather than commas?  That's going to be easier for me to process (in unix tools for example) and display.  I know that the link header uses commas, but that is intended for a single HTTP header.  In a file format, this is less important.

I wouldn't want to do that, we actually prefer to stick with the comma. When this is displayed to a human at some point, the display can always add terminations.

>  Can you use UTF-8 rather than ASCII?  The only cost being that clients need to be able to cope with having the high bit set in each octet.  The cost to a parser can be quite small and I think that you'll find that this will save you a lot of awkward questions.

Now this is a very interesting idea, which will probably save us lots of pain later. I will make a ticket. 

> The 'rel'/'n' stuff is tricky.
> 
> Keying on 'n' sounds dangerous as it is currently defined.  The fact that it is both (or variably) human readable and semantically significant is an overloading that could cause problems.
> 
> For one, 'n' and 'title' [RFC5988] seem very similar.  Maybe the human readable capability is better left to 'title'.  It also punts on the other human-readable concerns, like language tagging.

I like this suggestion. We should instead use title for these human readable uses. 

> With human-readable concerns dealt with, that leaves 'n' with a single purpose... If it is needed.

n is meant to be a semantic name, used for a machine to find a resource to use, e.g. "TemperatureC". This would indeed leave it for a single purpose, which is good. 

> 
> 'rel' might be used to provide typing in the way that is compatible with 'n'.  The form that this takes might be a little different.  And from .well-known it is difficult because the context of .well-known is somewhat poorly understood.
> 
> For instance, a light sensor could provide a .well-known with a link maybe like...
> 
>  </light>,rel=sensor-state
> 
> The .well-known resource is about the server; the sensor state resource is related to the .well-known resource in a specific way.

For this I like the suggestion from Peter on the CoRE list, which is to define that the context is coap://authority and we use a new relation type "hosts". 

> 
> That doesn't work that well for devices with multiple sensors; so having a separate disambiguation function is useful.  The URL does that.  The title can be used to provide user-consumable clues.  For automatons, you need something less fuzzy than title and more definite than a URI (potentially something across different servers).
> 
> In my experience, having a domain-specific namespace for identifying the type of resource is the easiest solution.  Something defined by the server with scoping for the server.  I think that this is what you intended for the 'n' parameter.  Though in this case it might be better to find a better label for the parameter.  "name" is something with a lot of semantic baggage.  Maybe you can consider using 'id' for this purpose (in light of my above comment).
> 
>  </temp/now>;id='current';rel=sensor;title="Current Temperature"
>  </temp/hr>;id='hourly';rel=sensor;title="Temperate Average (Hourly)"
> 
> This is a tricky problem.  I expect that you will need to explore your options and provide a good amount of explanatory text on the topic when you finally decide.  Each type-/name-/identifier-class parameter needs a description that identifies scope, domain and all that sort of stuff.  I don't think that there is enough there yet.

We'll need to discuss this some more, maybe more examples will be the best for nailing down the best uses for the extensions.

Regards,
Zach 

> 
> --Martin
> 
> (Feel free to forward this to the core WG, if you think that this is useful.)

-- 
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: Peter Bigot <[email-masked]>
Date: Mon, 22 Nov 2010 09:53:11 -0600

On Mon, Nov 22, 2010 at 6:38 AM, Zach Shelby <[email-masked]> wrote:

> > 'id' seems a little strange.  Unless the scope of the identifier is
> something other than the server, the URL provides enough information for
> someone to identify a resource.  Does this have a different scope than the
> one server?  Or is the intent to convey information on from different
> identification domains?
>
> We were originally thinking ID would have global scope, something like a
> UUID. However in Beijing it was suggested to instead give it server scope
> and use it as a kind of index. For example you might have three different
> hosted resources with the semantic name "TemperatureC". The index would be
> used to give each an index on the server.
>

This is really unconvincing.  "a kind of index"?  How is the application
supposed to use that index?

I don't think we should include id without a better understanding of what
it's for, why it's necessary, and how the (M2M) application or a human is
expected to make use of it.

> >  Can you use line terminations to separate links rather than commas?
>  That's going to be easier for me to process (in unix tools for example) and
> display.  I know that the link header uses commas, but that is intended for
> a single HTTP header.  In a file format, this is less important.
>
> I wouldn't want to do that, we actually prefer to stick with the comma.
> When this is displayed to a human at some point, the display can always add
> terminations.
>

Or otherwise reformat it, e.g. into a table.  I also feel the syntax should
match HTTP unless there's a compelling reason within CoAP to deviate from
this.

>
> >  Can you use UTF-8 rather than ASCII?  The only cost being that clients
> need to be able to cope with having the high bit set in each octet.  The
> cost to a parser can be quite small and I think that you'll find that this
> will save you a lot of awkward questions.
>

OK.  I wonder if we should do the same with the URI options that carry
text.  (Actually, we have to, at least for URI-Query, if we intend to
support search for UTF-8 parameter values.)

> > Keying on 'n' sounds dangerous as it is currently defined.  The fact that
> it is both (or variably) human readable and semantically significant is an
> overloading that could cause problems.
> >
> > For one, 'n' and 'title' [RFC5988] seem very similar.  Maybe the human
> readable capability is better left to 'title'.  It also punts on the other
> human-readable concerns, like language tagging.
>

> n is meant to be a semantic name, used for a machine to find a resource to
> use, e.g. "TemperatureC". This would indeed leave it for a single purpose,
> which is good.
>

Consistent with what I just proposed; agreed.

> >
> > 'rel' might be used to provide typing in the way that is compatible with
> 'n'.  The form that this takes might be a little different.  And from
> .well-known it is difficult because the context of .well-known is somewhat
> poorly understood.
> >
> > The .well-known resource is about the server; the sensor state resource
> is related to the .well-known resource in a specific way.
>
> For this I like the suggestion from Peter on the CoRE list, which is to
> define that the context is coap://authority and we use a new relation type
> "hosts".
>
> >
> > That doesn't work that well for devices with multiple sensors; so having
> a separate disambiguation function is useful.  The URL does that.  The title
> can be used to provide user-consumable clues.  For automatons, you need
> something less fuzzy than title and more definite than a URI (potentially
> something across different servers).
> >
> > In my experience, having a domain-specific namespace for identifying the
> type of resource is the easiest solution.  Something defined by the server
> with scoping for the server.  I think that this is what you intended for the
> 'n' parameter.  Though in this case it might be better to find a better
> label for the parameter.  "name" is something with a lot of semantic
> baggage.  Maybe you can consider using 'id' for this purpose (in light of my
> above comment).
> >
> > This is a tricky problem.  I expect that you will need to explore your
> options and provide a good amount of explanatory text on the topic when you
> finally decide.  Each type-/name-/identifier-class parameter needs a
> description that identifies scope, domain and all that sort of stuff.  I
> don't think that there is enough there yet.
>

I think it would be inappropriate to use the "rel" attribute with a value
"sensor"; the server does not have a "sensor" relation to the resource
"/temp/now".  "/temp/now" is a resource with role (class, type) "sensor".
Adding a new link parameter would be appropriate, if it is necessary to do
this.

In fact, can "n" (which is also pretty vague) go away if we add two new
parameters:

u -- units, a semantic identifier like "degC"

r -- role, a semantic identifier like "temperature"

We'll need to discuss this some more, maybe more examples will be the best
> for nailing down the best uses for the extensions.
>
> Regards,
> Zach
>
> >
> > --Martin
> >
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>
>

---

From: Zach Shelby <[email-masked]>
Date: Wed, 24 Nov 2010 11:48:52 +0200

On Nov 22, 2010, at 5:53 PM, Peter Bigot wrote:

> This is really unconvincing.  "a kind of index"?  How is the application supposed to use that index?

This idea of an index was brought up in Beijing by Carsten. This was just an idea thrown out there during the meeting. 

> I don't think we should include id without a better understanding of what it's for, why it's necessary, and how the (M2M
> ) application or a human is expected to make use of it.

I happen to agree, if we don't find its use as either a universal ID or a local index useful, then it can be removed. The current draft defines that this could be an XRI for the resource. Do people familiar with XRIs think this would be useful?  
> OK.  I wonder if we should do the same with the URI options that carry text.  (Actually, we have to, at least for URI-Query, if we intend to support search for UTF-8 parameter values.)

Good question, I will make a coap ticket on that. Already our text/* MIME types are defined as being UTF-8.

> I think it would be inappropriate to use the "rel" attribute with a value "sensor"; the server does not have a "sensor" relation to the resource "/temp/now".  "/temp/now" is a resource with role (class, type) "sensor".  Adding a new link parameter would be appropriate, if it is necessary to do this.
> 
> In fact, can "n" (which is also pretty vague) go away if we add two new parameters:
> 

That is getting too specific. If we were developing a framework for sensors, it would make sense. But for general M2M use we need to allow the application domain, deployment or other SDO to specify what their names mean. If a specific application needs more specific fields, it can always add its own link extensions. 

Zach