Subject: [core] Need clarification for filter params in link format draft

From: Linyi Tian <[email-masked]>
Date: Wed, 10 Nov 2010 01:03:45 +0800

Hi, Z. Shelby and all

Currently there are five params listed in the filtering section. I doubt
whether Œuri¹, Œd¹ and Œsh¹ are needed.

resource-param = "uri" | "d" | "sh" | "n" | "id"

I am wondering how to use these three params. It is easy to understand the
case that that requestor doesn¹t know the exact location but just the name.
If the requestor knows the URI, what has been filtered by including the URI
(uri, d, sh)?

Another question is that why Œrel¹ and Œct¹ is not included. The requestor
may wants to know all the index nodes by adding rel param in the query. On
the other hand, the requestor may also wants to query all the resources with
content type image/jpeg. So do you think it make sense to include Œrel¹ and
Œct?

Cheers,
Linyi

---

From: Peter Bigot <[email-masked]>
Date: Tue, 9 Nov 2010 11:18:45 -0600

I believe "uri" was intended to provide a name that can be used to access
that portion of the link description that is called the "Target IRI" in
RFC5988.  It is the one field that you might want to filter on that is not a
link-param.

Naming specific elements seems unwise, as it leads to the sorts of other
questions you raise, and there's really no reason to do so.  I suspect the
rule should be:

   resource-param = "uri" | parmname

Peter

On Tue, Nov 9, 2010 at 11:03 AM, Linyi Tian <[email-masked]> wrote:

> whether ‘uri’, ‘d’ and ‘sh’ are needed.
>
> case that that requestor doesn’t know the exact location but just the name.
> Another question is that why ‘rel’ and ‘ct’ is not included. The requestor
> content type image/jpeg. So do you think it make sense to include ‘rel’ and
> ‘ct?
>
> Cheers,
> Linyi
>
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>
>

---

From: Zach Shelby <[email-masked]>
Date: Wed, 10 Nov 2010 01:26:58 +0800

On Nov 10, 2010, at 1:18 AM, Peter Bigot wrote:

> I believe "uri" was intended to provide a name that can be used to access that portion of the link description that is called the "Target IRI" in RFC5988.  It is the one field that you might want to filter on that is not a link-param.
> 
> Naming specific elements seems unwise, as it leads to the sorts of other questions you raise, and there's really no reason to do so.  I suspect the rule should be:
> 

I agree, that would make more sense. That way the filter query string could handle future link-extensions (and RFC5988 parameters) as well. 

Zach

> Currently there are five params listed in the filtering section. I doubt whether ‘uri’, ‘d’ and ‘sh’ are needed.
> 
> I am wondering how to use these three params. It is easy to understand the case that that requestor doesn’t know the exact location but just the name. If the requestor knows the URI, what has been filtered by including the URI (uri, d, sh)?
> 
> Another question is that why ‘rel’ and ‘ct’ is not included. The requestor may wants to know all the index nodes by adding rel param in the query. On the other hand, the requestor may also wants to query all the resources with content type image/jpeg. So do you think it make sense to include ‘rel’ and ‘ct?
> 
> Cheers,
> Linyi
> 

-- 
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: Wed, 10 Nov 2010 08:59:00 +0800

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

> I agree, that would make more sense. That way the filter query string could
> handle future link-extensions (and RFC5988 parameters) as well.
> 
> Zach

[Linyi] Yes, this will remove my doubt about URI. Some text and reference to
RFC5988 will be helpful. But It Is still unclear how to use "d" and "sh" In
the query. Could you please provide examples to explain?