Subject: [core] WGLC for draft-ietf-core-link-format-02

From: Cullen Jennings <[email-masked]>
Date: Wed, 12 Jan 2011 08:42:06 -0700

I would like to start the working group last call for draft-ietf-core-link-format-02. Please review the draft and send comments to list by the end of the day Jan 26. If you review the draft and have no comments, send an email to the list or to the chairs so we have an idea of how much review the draft received. 

The draft is at http://tools.ietf.org/html/draft-ietf-core-link-format-02

Thank you,

Cullen & Carsten

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Thu, 20 Jan 2011 11:23:54 +0100

Probably I've missed something, however I have the feeling that the
/.well-known/core URI is useful mainly for an human interaction with a
CoAP server.

Link format could be certainly an useful technique for M2M
applications, and in the current draft some information useful for
that kind of interaction is present (content-type, interface
description, ..).

In contrast to this the /.well-known/core URI seems hardly useful by a
machine, because it will provide a list of resources..

For what I can see written in the draft, I cannot understand why a
machine could start a discovery procedure to see the whole content in
the network... Moreover this procedure leaves space for the known
amplification attacks pointed out in the CoAP draft.

In my opinion, machines are instructed to do specific tasks, and for
that tasks they probably will want to start a *service-specific*
discovery in the network.

The draft tells that the /.well-known/core URI is a MUST.

Probably the real question is: Are humans supposed to use CoAP directly?

I don't think so, and for this reason I think that the
/.well-known/core URI is not very useful at all.

I apologize for the late comment, I have had right now a more clear
idea about this...

Best,
Angelo

On Wed, Jan 12, 2011 at 16:42, Cullen Jennings <[email-masked]> wrote:
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 20 Jan 2011 12:41:22 +0100

Hi Angelo,

indeed the draft could explain better what the underlying discovery model is.
Maybe it doesn't because the discovery mechanisms are independent from how you use them, so strictly you don't have to understand the use case to use this protocol... But it sure helps when evaluating it.

During commissioning, if you have machines do all the discovery, they will never quite know what the items/objects mean.
They also can't really know environmental information, e.g. that the light switch B46FFE9DC12A4EEC8DF25346D88E1FB6 is the one near the kitchen door.
So a human installer will still be needed in many cases -- either at the place of installation or beforehand in planning/supervising an off-site commissioning process.
However, a human installer can be helped by a reasonably smart user interface on an installer device, and that in turn can be helped a lot by devices providing some information about themselves.
Making this information available may even enable simplifying the user interface for a simple installation enough that you actually can do it using a LED and two buttons.

In short, supporting installation/commissioning is the most useful application I see for resource discovery.
There are also applications in diagnostics/debugging and other management activities.

Gruesse, Carsten

---

From: "Rahman, Akbar" <[email-masked]>
Date: Tue, 25 Jan 2011 00:35:34 -0500

Hi Cullen/Carsten,

I read the draft and think it is in good shape, and I support passing of the working group last call for the draft.  I did, however, have some questions and comments on the draft as follows:

1) The draft refers to RFC5988 (Web Linking) for the original definition of Link Header.  In that RFC, the Link Header field is clearly defined in, for example, section 5 of the RFC. This draft takes RFC5988 definition of Link Header and adapts it for CORE.  But some important points in this adaptation and extension of Link Headers were not totally clear to me.  For example, do the cardinality rules of Link Headers from RFC5988 still apply to CORE?   A general suggestion would be to clarify section 2 of this draft to better explain the principles of how Link Format is used in CORE.

2) Some good examples of how the CORE Link Format is embedded in the payload are given in section 4.  
But some normative text should be added to specify precisely how the Link Format delimited and identified in the payload.

Nits:
 
3) If the CORE Link Format is embedded in the payload why is there a need to register for the "hosts" relation type in section 6.2?  (I'm probably missing something obvious here.)
 
4) Shouldn't "RFC 5785" be a normative reference?

Sincerely,

Akbar

________________________________

From: [email-masked] on behalf of Cullen Jennings
Sent: Wed 1/12/2011 10:42 AM
To: core WG
Subject: [core] WGLC for draft-ietf-core-link-format-02

Thank you,

Cullen & Carsten

---

From: "Dijk, Esko" <[email-masked]>
Date: Tue, 25 Jan 2011 11:18:46 +0100

Dear Cullen and Carsten,

I have read the draft and I noticed one potential issue, in the descriptions of filtering.

Section 3.1 states:
"If the decoded query-pattern does not end with "*", a link value matches the query only if the value of the attribute or URI-reference denoted by the resource-param is bytewise identical to the query-pattern".
In other words, a query without using "*" only finds values that equal the query-pattern.

Then the paragraph below this text states
"... An implementation supporting filtering MUST return only those entries  for which the value of the link attribute identified by the resource-param contains the query-pattern as a substring."
In other words, a query will return entries based on substring matching, so not necessarily bytewise identical. This seemingly contradicts the previous text. Also this sentence probably should take into account that querying can be done with/without wildcard "*" - the two cases cause different matching behavior.

best regards,

Esko Dijk

Philips Corporate Technologies, Research
High Tech Campus 34, Eindhoven, The Netherlands
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Cullen Jennings
Sent: Wednesday 12 January 2011 16:42
To: core WG
Subject: [core] WGLC for draft-ietf-core-link-format-02

Thank you,

Cullen & Carsten

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: Peter Saint-Andre <[email-masked]>
Date: Tue, 25 Jan 2011 15:06:16 -0700

On 1/20/11 4:41 AM, Carsten Bormann wrote:
> Hi Angelo,
> 
> indeed the draft could explain better what the underlying discovery
> model is. Maybe it doesn't because the discovery mechanisms are
> independent from how you use them, so strictly you don't have to
> understand the use case to use this protocol... But it sure helps
> when evaluating it.
> 
> During commissioning, if you have machines do all the discovery, they
> will never quite know what the items/objects mean. They also can't
> really know environmental information, e.g. that the light switch
> B46FFE9DC12A4EEC8DF25346D88E1FB6 is the one near the kitchen door. So
> a human installer will still be needed in many cases -- either at the
> place of installation or beforehand in planning/supervising an
> off-site commissioning process. However, a human installer can be
> helped by a reasonably smart user interface on an installer device,
> and that in turn can be helped a lot by devices providing some
> information about themselves. Making this information available may
> even enable simplifying the user interface for a simple installation
> enough that you actually can do it using a LED and two buttons.
> 
> In short, supporting installation/commissioning is the most useful
> application I see for resource discovery. There are also applications
> in diagnostics/debugging and other management activities.

IMHO it would be helpful to describe some of the use cases we envision
as a way to motivate the discussion. As part of that text, it would also
help to describe what kinds of things we expect will play the role of
constrained servers. Carsten, you mention "devices providing some
information about themselves" -- does that imply that the devices are
constrained servers?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 25 Jan 2011 16:14:58 -0700

On 1/12/11 8:42 AM, Cullen Jennings wrote:
> 
> I would like to start the working group last call for
> draft-ietf-core-link-format-02. Please review the draft and send
> comments to list by the end of the day Jan 26. If you review the
> draft and have no comments, send an email to the list or to the
> chairs so we have an idea of how much review the draft received.
> 
> The draft is at
> http://tools.ietf.org/html/draft-ietf-core-link-format-02

Here is some feedback from your friendly neighborhood area director...

1. Let's provide references if we can for REST, 6LoWPAN, HTTP, ABNF,
URN, Atom, etc.

2. As always, please spell out acronyms on first use (MTU, etc.).

3. I see that Klaus asked for a review of the coap: scheme on the
uri-review list. We also need to request:

3a. A review of the Well-known 'core' URI on the appropriate list:

    https://www.ietf.org/mailman/listinfo/wellknown-uri-review

3b. A review of the 'hosts' relation type on the appropriate list:

    https://www.ietf.org/mailman/listinfo/link-relations

3c. A review of the link-format Internet media type on the appropriate list:

    https://www.ietf.org/mailman/listinfo/ietf-types

4. As I noted elsewhere in this thread, I think it would be very useful
in the introduction to describe the motivations for this work, briefly
sketch out a few use cases, and at a high level describe the assumed
architecture (e.g., are all devices to be considered servers?). We can
point to other documents that provide this information, naturally.

5. As Akbar Rahman pointed out, we might need to spell out more clearly
how this work differs from RFC 5988. There is information about this in
several sections of this I-D and I'm not sure that they are entirely
consistent (but I will read them again).

6. Do we have good examples of resources that would be hosted somewhere
other than the constrained server (device) and how those would be used
in CoRE? If so, we might provide those in Section 2.1.2.

7. Section 2.1.3 states:

   It is not expected that all implementations will be able
   to derive useful information from explicitly anchored links.

So how important is the feature? Is it useful in some kinds of
implementations or deployments or environments but not others?

8. Section 2.2.5 defines the Observable 'obs' attribute. Does this
definition in fact belong in draft-ietf-core-observe?

9. Do we need an IANA registry of CoRE-specific target attributes so
that other specifications can add attributes in the future without
updating this document?

10. In Section 3.1, what is "parmname"?

I'm out of time right now, I might have more comments later or after
tomorrow's call.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Zach Shelby <[email-masked]>
Date: Wed, 26 Jan 2011 13:21:01 +0200

Hi Angelo,

Very valid questions. As an overall comment, we need to keep in mind that the title of this draft is "CoRE Link Format", which is its main purpose. It defines a way to express link relations appropriate for CoRE, as part of the Web Linking framework defined in RFC5988. By no means is this draft sufficient as a complete resource discovery solution for some application domain. Just as RFC5988 doesn't define how you should use link relations (although it does list some relations that are already in use), just how you can express them. 

I agree with Carsten and Peter that some more examples in the draft could help to illustrate how this can be used, I think we can consider that a useful ticket. Furthermore, I would hope to see some informational drafts from different applications on how they are applying this in practice. http://tools.ietf.org/id/draft-vanderstok-core-bc-02.txt already is a good start for building automation. 

What application do you have in mind? 

Here are some comments in-line:

> /.well-known/core URI is useful mainly for an human interaction with a

That is not the intention at all, although that is something people tend to use it for when playing with early implementations. 

> that kind of interaction is present (content-type, interface

That is exactly the main intention of the draft, which is in line with RFC5988.

> machine, because it will provide a list of resources..

For link relations to be useful for anything, you need to find out about them. In RFC5988 one way of finding out about links related to a web page is via the HTTP link header. In this draft we specify /.well-known/core for a similar purpose, except here we find out about all the link relations related to a server all at once (or a filtered subset of them).

> amplification attacks pointed out in the CoAP draft.

Not sure I understand the question. How you would use this draft for resource discovery will depend completely on your application use case. Home automation and building automation people for example have specific ways of using this in mind. In large scale M2M systems (with one or more central servers) we use the CoRE Link Format as a way to register resources with a resource directory.

Each application will need to define how it uses discovery (peer-to-peer? Local resource directory?), and most importantly, what the naming is for that application.  

> discovery in the network.

By defining your setup for discovery, along with naming for your resources used in services, the CoRE Link Format can be used for exactly that. 

> The draft tells that the /.well-known/core URI is a MUST.

"A server implementing
   this specification MUST support this resource on the default port
   appropriate for the protocol for the purpose of resource discovery."

Which means it is a MUST if you implement that specification, not CoAP in general. So not every CoAP has to be discoverable, and in some use cases they surely wouldn't be.

> /.well-known/core URI is not very useful at all.

I am not sure how you came to the conclusion of relating humans with /.well-known/core. The CoRE Link Format is a format meant to be used between machines, I hope I helped to clarify that for you. Of course as it is just a format, you need to define the common naming that your machines understand.

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: Salvatore Loreto <[email-masked]>
Date: Wed, 26 Jan 2011 12:21:34 +0100

On 1/12/11 4:42 PM, Cullen Jennings wrote:
> Cullen&  Carsten
Hi there,

I have reviewed the draft; below few comments

Section 2
--------
as a general comment Section 2 should be expanded to explain better how 
the link Format is used in CORE,
several points are vague and could lead to misinterpretations.

the following statement is not clear:

	It is expected that resources discovered in the
    CoRE Link Format may also be made available in alternative formats on
    the greater Internet.

is there already some thought about those alternative formats?
or "alternative" only means that the format is aspect to follow the Web 
Linking (as specified in RFC5988)
in the greater Internet?

Section 2.1 define the "hosts" relation time (why "hosts" and not 
"host"?) which indicates that the resource
is hosted by the server from which the link document was request;
I have some doubts about the context in the case of a multicast request, 
section 2.1.1 states:

	The context URI of a link (also called base URI in
    [RFC3986]) conveyed in the CoRE Link Format is by default built from
    the scheme and authority parts of the target URI.  In the absence of
    this information in the target URI, the context URI is built from the
    scheme and authority that was used for referencing the resource
    returning the set of links, replacing the path with an empty path.
    Thus by default links can be thought of as describing a target
    resource hosted by the server.

I don't think that the above applies in the case of a multicast request, 
or at least it should be explained better
how it applies.

Section 2.1.1. Resource name 'n' attribute
-----------------------------------
IMO "application-specific semantic name" is a bit vague and could lead a 
some interoperability problem

Section 2.2.4
-----------

  The maximum size estimate attribute "sz" gives an indication of the
    maximum size of the link indicated by the target URI.

s/link/resource

cheers
/Sal

-- 
Salvatore Loreto
www.sloreto.com

---

From: Zach Shelby <[email-masked]>
Date: Wed, 26 Jan 2011 13:41:52 +0200

Akbar,

Thanks for the review. 

On Jan 25, 2011, at 7:35 AM, Rahman, Akbar wrote:

> 1) The draft refers to RFC5988 (Web Linking) for the original definition of Link Header.  In that RFC, the Link Header field is clearly defined in, for example, section 5 of the RFC. This draft takes RFC5988 definition of Link Header and adapts it for CORE.  But some important points in this adaptation and extension of Link Headers were not totally clear to me.  For example, do the cardinality rules of Link Headers from RFC5988 still apply to CORE?   

Yes, the intention is that Section 5 applies to CoRE. The exception is that the "Link:" header is not included and several new link-extensions have been defined.  

> A general suggestion would be to clarify section 2 of this draft to better explain the principles of how Link Format is used in CORE.

Good comment, I think we should make a ticket to do that. Right now this concentrates on explaining how we technically apply Web Linking in CoRE. But some more plain language explanation on how we use it would surely help.

> But some normative text should be added to specify precisely how the Link Format delimited and identified in the payload.

The normative rules of the Link Format are described in Section 5 of RFC5988 and applied to CoRE in Section 2 of this document. I am not sure what else we could define, ideas? 

> 3) If the CORE Link Format is embedded in the payload why is there a need to register for the "hosts" relation type in section 6.2?  (I'm probably missing something obvious here.)

Web Linking is a tricky concept. But it involves a Target URI being related to a Context URI - which is a link. In the HTTP Link Header the document you just requested is the Context URI by default. In CoRE, the Context URI by default is the Scheme+Authority you used to request /.well-known/core (in other words that server). 

If we would include links there without any relation, they would be meaningless. The minimum goal in CoRE is to be able to express the link relation:

This server hosts a resource 

Where this server is the default Context URI, and a resource is the target URI between brackets in the link format. Although we first tried to use "service" from RFC5988, the existing relation types didn't describe this very well. For that reason we defined a new relation "hosts" which correctly defines this relationship. By making it the default, we were able to save some overhead.  

The CoRE link format can be used to express any of the other relation types (or new extensions) defined in RFC5988, also also relations between arbitrary URIs. In that way this can fully be used to realize the Web Linking concept.

> 4) Shouldn't "RFC 5785" be a normative reference?

Good point, I will check that.

Zach

---

From: Zach Shelby <[email-masked]>
Date: Wed, 26 Jan 2011 13:57:52 +0200

Esko,

Thanks, you definitely found a bug. I will make a ticket to take care of it.

> In other words, a query without using "*" only finds values that equal the query-pattern.

This is correct.

> "... An implementation supporting filtering MUST return only those entries  for which the value of the link attribute identified by the resource-param contains the query-pattern as a substring."

This sentence needs to be corrected to match the previous bytewise matching.

> In other words, a query will return entries based on substring matching, so not necessarily bytewise identical. This seemingly contradicts the previous text. Also this sentence probably should take…

Yes, I will do that.

Zach

---

From: Zach Shelby <[email-masked]>
Date: Wed, 26 Jan 2011 14:16:22 +0200

Thanks for the comments Salvatore. 

On Jan 26, 2011, at 1:21 PM, Salvatore Loreto wrote:
> as a general comment Section 2 should be expanded to explain better how the link Format is used in CORE,

Agreed, just created a ticket on that.  

> or "alternative" only means that the format is aspect to follow the Web Linking (as specified in RFC5988)
> in the greater Internet?

RFC5988 defines the concept of Web Linking where links can be expressed in a semantically equal way in many different formats. The HTTP Link Header, CoRE Link Format, HTML <LINK> element, and atom:feed link element [RFC4287] can all be used to represent these links. The purpose of that sentence is that we don't expect the whole Internet to understand the CoRE Link Format. I think a sentence should be added here to clarify that with a pointer to RFC5988, HTML <LINK> and RFC4287. Just made a ticket.

> 
> Section 2.1 define the "hosts" relation time (why "hosts" and not "host"?) which indicates that the resource

The Context URI "hosts" the Target URI. That is the reason for that form. Alternatively "hosted" could work (see Section 3 of RFC5988) - 

Context URI has a {relation type} resource at Target URI.

> I have some doubts about the context in the case of a multicast request, section 2.1.1 states:
> 

In CoAP there is no difference between how a unicast or multicast Request URI is reconstructed. The scheme + authority are identical in both cases. Does that need more explanation?

> 
> I don't think that the above applies in the case of a multicast request, or at least it should be explained better
> how it applies.
> 
> IMO "application-specific semantic name" is a bit vague and could lead a some interoperability problem

The CoRE Link Format is exactly that, a format. It doesn't claim any interoperability between the naming schemes used in different applications. Probably should add some text explaining that further specification is needed to define your resource and interface description names?

> Section 2.2.4

Good catch, thanks.

Zach

---

From: [email-masked]
Date: Wed, 26 Jan 2011 13:33:36 +0100

Hi Carsten,

>In short, supporting installation/commissioning is the most useful 
application I see for resource discovery.
>There are also applications in diagnostics/debugging and other management 
activities.

According to the draft /.well-known/core should only mention the important 
resources. I understand the term important resource as the entry point to 
a given service offered by the device instead of an exhaustive resource 
list. The service may then be made of subordinate resources that could be 
defined out-of-band in a specification (not very RESTful) or learned with 
links from the entry point. It is not clear to me if it is allowed to 
define such an entry point as a link-format resource. The sentence "Such a 
hierarchy MUST be under the /.well-known/core path." at the end of section 
3 makes me think that this kind of entry point would have to be in the 
/.well-known/core path.

But I think the link-format could be used out of the /.well-known/core 
path. For example to enumerate the current list of subordinates for a 
resource which is a collection. And IMHO /.well-known/core is not the 
rigth place to advertise resources with potentially short lifetimes. So 
what people think about the following example? Is it the right way to use 
link-format?

REQ: GET /.well-known/core
RES: 200 OK
</gps>;n="GPS position",
</fnc>;n="Geofence list";ct=40,
</alrm>;n="Pending alarms";ct=40;obs,

REQ: GET /gps
RES: 200 OK
45.185013,5.723476

REQ: GET /fnc
RES: 200 OK
</fnc/1>;ct=41,
</fnc/2>;ct=41;sz=200,

REQ: GET /alrm
RES: 200 OK
</alrm/1>;ct=41,
</alrm/2>;ct=41,
</alrm/3>;ct=41,

REQ: GET /fnc/1
RES: 200 OK
<fence>
...
</fence>

REQ: GET /alrm/1
RES: 200 OK
<alarm>
...
</alarm>

Sorry for the late comment,
Matthieu

---

From: Kerry Lynn <[email-masked]>
Date: Wed, 26 Jan 2011 08:52:56 -0500

I agree that there should be something of a "split" between relatively
coarse-grained discovery (a.k.a. "service discovery") which is done
at link-local or site-local scope, and fine-grained data ("resource
discovery") which is learned by querying the device in question.
Perhaps the former is exposed via multicast and the latter only
via unicast.  This might mitigate amplification attack concerns.

At the same time, I expect that even the former might have some
practical scaling limit when the size of the network reaches thousands
of points.  Therefore, I think one very practical application of link
format is to support the automatic population of scalable discovery
databases (e.g. DNS-SD) during commissioning.

It seemed like the original draft-ietf-core-coap-00 described a
scheme that would satisfy the discovery requirement from the
charter:

A definition of how to use CoAP to advertise about or query
for a Device's description.  This description may include the
device name and a list of its Resources, each with a URL, an
interface description URI (pointing e.g. to a Web Application
Description Language (WADL) document) and an optional name or
identifier.  The name taxonomy used for this description will
be consistent with other IETF work, e.g.
draft-cheshire-dnsext-dns-sd. [charter]

In particular, a DNS-SD name includes three basic concepts:
<instanceName>.<serviceType>.<location>.  I would like to
understand how target attributes can be mapped to these fields.
I was under the impression that the -00 text would be tweaked
and restored at some point?  If not, how will we address the
intent of the last sentence in the above requirement?

Also sorry for the late comment, -K-

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Wed, 26 Jan 2011 16:12:09 +0100

Zach,
thanks for the comments.

I quote a part of your message, mainly related to what needs
clarifications about my previous message.

> I am not sure how you came to the conclusion of relating humans with /.well-known/core. The CoRE Link Format is a format meant to be used between machines, I hope I helped to clarify that for you.…

In my opinion the service discovery cannot be "general": regarding all
the services present in the network or in a node.

But it should be service-specific, e.g. a multicast request for a
"well-known" URI of a *single* service.

Example 1: sent to a multicast group containing all temperature sensors
- GET /temperature (get all temperature values, all nodes in the
temperature multicast group respond?)

Example 2: sent to a multicast group containing ambient related sensors
- GET /.well-known/ambient-sensors (get a list of links to
ambient-related sensors, all nodes in group respond)

I have some doubts about the utility of "generic" multicast groups
(all-hosts) and "generic" URIs...

I hardly imagine use-cases different from debug where this "general"
node capability discovery can be useful...

I am looking forward to the proposed use cases mainly for this reason.

Best,
Angelo

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 26 Jan 2011 18:53:13 +0100

On 1/26/11 1:16 PM, Zach Shelby wrote:
> In CoAP there is no difference between how a unicast or multicast Request URI is reconstructed. The scheme + authority are identical in both cases. Does that need more explanation

Hi Zac,

I am not questioning the difference between unicast and multicast 
Request URI in CoAP.

what I had in mind is that when a client can send a GET /.well-know/core 
to a multicast Request URI,
the answers (CoRE Link Format) it gets from the all the nodes registered 
to the multicast node should not go
under the context of the multicast URI (in the absence of the authority 
part in an URI conveyed
in the CoRE Link Format) and that does not seem to be clear in the text 
above.

cheers
/Sal

-- 
Salvatore Loreto
www.sloreto.com