Re: [core] draft-ietf-core-resource-directory = GET /rd

HI Michael,

For me it looks OK. A few reflections:
It must be clear in accompanying text, that "href" refers to the 
registration and "con" to the links of the registration. And 
core-rd.endpoint needs to be explained in text, and registered in core 
registry. Further, "ct" is an attribute of the links in all RD examples 
and not of the registration.

Cheerio,
Peter

Michael Koster schreef op 2017-09-08 10:08:
> Hi Peter,
> 
> In your example, "loc" I presume is "location" which is how this is
> returned in the response header when the registration resource is
> created.
> 
> In my example, I propose a hyperlink to a resource, so "href" is the
> usual key for this in a link JSON.
> 
> I also propose to include all of the link attributes including rt and
> ct, so the client knows what it is without needing to infer anything.
> 
> So your example would look like this:
> 
> [
>   {
>     "href" : "/rd/541",
>     "con": "coap://[fdfd::12]:17072",
>     "ep": "example-endpoint-name",
>     "et": "ocf-device",
>     "rt": "core.rd-endpoint",
>     "ct": 40,
>     "lt": 600,
>     "d": "floor-3"
>   }
> ]
> 
>> On Sep 8, 2017, at 12:25 AM, peter van der Stok <stokcons@xs4all.nl>
>> wrote:
>> 
>> Hi Michael,
>> 
>> I would have expected:
>> 
>> [
>> {
>> "con": "coap://[fdfd::12]:17072",
>> "loc" : "/rd/541",
>> "ep": "example-endpoint-name",
>> "et": "ocf-device",
>> "lt": 600,
>> "d": "floor-3"
>> }
>> ]
>> 
>> and may be only ep and loc attributes;
>> With this information the rest of the link information can be
>> inferred.
>> 
>> cheerio,
>> 
>> Peter
>> 
>> Michael Koster schreef op 2017-09-05 20:37:
>> Hi Peter,
>> The representation on slide 4 is not a complete dump, but exactly
>> what
>> you say; it's the locations and the registration parameters, exposed
>> as link target attributes.
>> The example has one "self" link for the RD itself, and one link for
>> each registration resource (only one is shown).
>> [
>> {
>> "href": "/registration/",
>> "rel": "self",
>> "rt": "core.rd",
>> "ct": 40
>> },
>> {
>> "href": "/registration/f3cca57e/",
>> "con": "coap://[fdfd::12]:17072"
>> "rt": "core.rd-endpoint",
>> "ct": 40,
>> "ep": "example-endpoint-name",
>> "et": "ocf-device",
>> "lt": 600,
>> "d": "floor-3"
>> }
>> ]
>> On Sep 4, 2017, at 11:37 PM, peter van der Stok <stokcons@xs4all.nl>
>> wrote:
>> Hi Michael,
>> Originally, I thought the same, but the packets get really large by
>> doing a complete dump.
>> The compromise is just sending the (endpoint names/ registration
>> resource location) with its registration attributes.
>> Peter
>> Michael Koster schreef op 2017-09-05 08:27:
>> I would propose returning links for all registration resources in
>> the
>> RD as shown in slide 4 of the attached deck (JSON format shown).
>> This
>> would include the most recent setting of the "lt" or lifetime
>> parameter as a link target attribute as shown.
>> On Sep 4, 2017, at 8:27 AM, Jim Schaad <ietf@augustcellars.com>
>> wrote:
>> Yes that is what I had in mind.  It would be useful to add a ttl
>> attribute
>> as well.
>> Jim
>> -----Original Message-----
>> From: peter van der Stok [mailto:stokcons@xs4all.nl]
>> Sent: Monday, September 4, 2017 1:46 AM
>> To: Jim Schaad <ietf@augustcellars.com>
>> Cc: draft-ietf-core-resource-directory@ietf.org; core@ietf.org
>> Subject: Re: draft-ietf-core-resource-directory = GET /rd
>> Hi Jim,
>> Personally, I like the idea.
>> That would mean that all registration resources are returned.
>> In the next version of the RD, location or endpoint identifies the
>> registration.
>> Uniqueness of links is specified in section 5.3.4, already commented
>> on by
>> you.
>> Your request means returning all locations with the ep, lt, d, and
>> et
>> attributes
>> and the associated scheme://authority:port value.
>> Correct?
>> Peter
>> Jim Schaad schreef op 2017-08-31 03:59:
>> I am wondering if there should be a GET action defined against the
>> resource directory object.  Currently, if an entity does a
>> registration for an endpoint it gets back a location for that
>> registration.  If a second entity modifies the endpoint and wants to
>> update the registration, it currently has no method to get the
>> location associated with the endpoint and cannot make a second new
>> registration since the <domain, endpoint> pair is required to be
>> unique.
>> Thus
>> Interaction: EP -> RD
>> Method: GET
>> URI Template: {+rd}{?ep,d}
>> Content-Format: application/link-format (or variants)
>> <rd/0099>;ep=endpoint1,<rd/0098>;ep=endpoint1;domain=beta, ...
>> Jim
>> _______________________________________________
>> core mailing list
>> core@ietf.org
>> https://www.ietf.org/mailman/listinfo/core