Subject: [core] Resource directory evolution

From: Carsten Bormann <[email-masked]>
Date: Sat, 11 Jun 2016 18:22:28 +0200

The current RD draft offers a number of "function sets", some of which
have become quite popular.  Now, additional usages of RD are coming
up, e.g., in OCF and in the W3C Web of Things group, that would want
to continue to use the RD, but add more "function sets".  The best way
to advertise these new function sets from an RD would be to provide
them as explicitly linked hypermedia controls.  That raises the
question why the existing function sets aren't offered in the same
way.  We could use the rt= registry as a bridge leading us there.

Now there is a lot of handwaving in the above, and we should try to
form this into a plan that minimizes the impact on the RD
specification as it is, while making sure there is nothing in there
that gets in the way of this evolution.

* We need to link the resources implicitly included in the current
  function sets (can be done in .well-known/core)
* We need to annotate how to formulate the requests to these resources
  (can be done with rt= for now, backed by the textual descriptions we
  have in the RD specification)
* We need to allow for additional lookup interfaces (can be done
  through additional rt= registrations, backed by the specifications
  referenced)
* The registration interface would not change much, just support
  additional media types (containing collections of links, which
  need to be made available in link-format style to those consumers
  not familiar with the media type)

We should have the rel= types in place that will allow this
information to be a citizen in the greater Web of Things.
(E.g., compare rel="create-form" for the registration interface.)
Further evolution can then center more on explicit information
provided at the resources pointed to via the rel= types; providing a
smooth transition away from relying just on rt=.

The next step will be to collect information about how the lookup
functions are actually being used (or their use is envisioned) from
the various groups that already are making use of the RD.
Obviously, the objective is not to step on those uses but, conversely,
to enable the evolution these groups need.

Grüße, Carsten, Klaus, Matthias

---

From: "weigengyu" <[email-masked]>
Date: Mon, 13 Jun 2016 13:06:53 +0800

Hi,

Some comments on "9.  DNS-SD Mapping" of 
draft-ietf-core-resource-directory-07.

In "9.6.  Importing resource links into DNS-SD",
it seems to expose the resouce's link to DNS-SD by a RD, not to pose a RD's 
web link to DNS-SD.

Is there such a resource Lookup with two phases:
1.  getting a weblink of RD by DNS-SD Lookup; it can be seen as a 
coarse-grained resolution.
2.  getting the weblingk of EP by RD Lookup; it can be seen as a 
fine-grained resolution.
And two lookups are processed in order automatically.

It is required, or not.

Regards,

Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications
-----原始邮件----- 
From: Carsten Bormann
Sent: Sunday, June 12, 2016 12:22 AM
To: [email-masked] WG
Subject: [core] Resource directory evolution

_______________________________________________
core mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/core

---

From: peter van der Stok <[email-masked]>
Date: Mon, 13 Jun 2016 09:06:06 +0200

Hi Weigenyu,

What you describe is correct.
No there are no additional functions to access RD via DNS.

It may be worthwhile to write a draft that promotes look-ups from RD to 
DNS and from DNS to RD.
There have been no plans in this directuon.

greetings,

Peter

weigengyu schreef op 2016-06-13 07:06:
> it seems to expose the resouce's link to DNS-SD by a RD, not to pose a
> RD's web link to DNS-SD.
>

---

From: peter van der Stok <[email-masked]>
Date: Mon, 13 Jun 2016 09:25:27 +0200

Hi Carsten,

Do I understand correctly that this evolution takes place in a draft 
referencing the future RD RFC?

Peter