jiebi/CodeConvo huggingface dataset:
Change:
We've had conflicting concepts (show remaining vs show registered), and they problematic w/rt caching and useless to some kinds of consumers, respectively. Given that there is no clear case for existing consumers that could fully work from those attributes in lookup, they're removed; when a use case does come up, it can still register a lookup parameter. Closes: URL
should lt value in lookup give time from specification moment to end or from lookup moment to end
added text in this sense in section 7
That's hard to keep consistent with caching. What use cases do we have for exposing a lifetime in the endpoint lookup at all?
returning the lt value as specified at registration time does not really help and can be omitted at lookup. Returning the remaining registration time till end of registration "could" be useful to a commissioning device that is unaware of the earlier registration time because it was not involved.
Given that caching of down-counting values is problematic, and the 'Returning the remaining [...] time [...] "could" be useful' does not sound too convinced, I'd suggest just not returning it by default and leaving it up to extensions to say what exactly they need. NAME is that something you'd be happy with?

Discussion:
endpoints and a resource lookup MUST return a list of links to resources. <del> The value of the lt attribute of the registration represents the time interval form the lookup moment till the end of life of the registration. </del> The lookup type is selected by a URI endpoint, which is indicated by a Resource Type as per lookup-types below:

Endpoint and group lookups result in links to registration resources and group resources, respectively.  Endpoint registration resources <del> are annotated with their endpoint names (ep), domains (d, if present), context (con) and lifetime (lt, if present).  Additional </del> <ins> are annotated with their endpoint names (ep), domains (d, if present) and context (con); the lifetime (lt) is not reported.  Additional </ins> endpoint attributes are added as link attributes to their endpoint link unless their specification says otherwise.  Group resources are annotated with their group names (gp), domain (d, if present) and
Change:
Observe, ETag and possible future mechanisms are stated to be generally usable, but phrased as a "like with any other resource", because there is no need to actually define something new here.
Merged as agreed in the last call. NAME I'll address your comments in a different issue as I think they don't relate directly to that PR.
It would be good to provide a way for clients to receive notifications upon updates of an RD.
Is this something we need to specify? IMO it'd be orthogonal to the interface description -- if the RD advertises a , any client can try to observe the presence of endpoints.
So we should just say that such a lookup can be tried with observe, and that the link attribute "obs" is a good way to provide a hint. Any future optimized collection observe would probably use RD as a prominent example, so we can expect RD implementers to pick this up later.

Discussion:
filtering on groups would return a list of endpoints that are in the specified groups. <ins> Clients that are interested in a lookup result repeatedly or continuously can use mechanisms like ETag caching, resource observation (RFC7641), or any future mechanism that might allow more efficient observations of collections.  These are advertised, detected and used according to their own specifications and can be used with the lookup interface as with any other resource. </ins> The lookup interface is specified as follows: Client -> RD
Change:
This executes the renaming of con to base and domain to sector as agreed on in the last meeting. Two follow-up commits create consistency in the ER diagram (which had to be modified anyway for the renaming) and the accompanying text, both internally (describe groups the same way as resources) and within the document (we describe several properties of a group that the ER did not show).

Discussion:
optionally a sector (abbreviated "d" for historical reasons), <ins> a group resource location inside the RD ("href"), </ins> zero or one multicast addresses expressed as a base URI ("base"), and is composed of zero or more registrations (endpoints).

a lifetime ("lt"), <del> a registration resource location inside the RD ("loc"), </del> <ins> a registration resource location inside the RD ("href"), </ins> optionally a sector ("d")
Change:
The rules laid out below the removed sentence are pretty clear, but the removed sentence itself can be read to contradict them ("may be created at any time to supersede an existing registration") or at best does not add anything. Assuming it was left over from an older version (before the rules were added), I suggest we remove it. NAME that's your section of expertise. Please merge if you agree or reject otherwise.

Discussion:
the registration or update interface.  The registration interface MUST be implemented to be idempotent, so that registering twice with the same endpoint parameters ep and d (sector) does not create <del> multiple registration resources.  A new registration resource may be created at any time to supersede an existing registration, replacing the registration parameters and links. </del> <ins> multiple registration resources. </ins> The following rules apply for an update identified by a given (ep, d) value pair:
Change:
Populates missing descriptions in the IANA template for resource types, but primarily adds new resource types (URL and URL) to the lookup results.
(This was quickly but a bit vaguely agreed on in the last meeting; will merge if nobody objects.)
This was discussed in the last meeting but did not result in an action item; will check whether we agreed to do this (AFAIR we did) and add the text for it.
The right place is in the management example. I hesitated but did not do it chrysn schreef op 2018-06-27 11:51: Links: [1] URL [2] URL
Done with in 801a4352587f4354d57949ab7cb427600a139158.

Discussion:
Endpoint and group lookups result in links to registration resources and group resources, respectively.  Endpoint registration resources are annotated with their endpoint names (ep), domains (d, if present) <del> and context (con); the lifetime (lt) is not reported.  Additional endpoint attributes are added as link attributes to their endpoint link unless their specification says otherwise.  Group resources are annotated with their group names (gp), domain (d, if present) and multicast address (con, if present). </del> <ins> and context (con) as well as a constant resource type (rt="core.rd- ep"); the lifetime (lt) is not reported.  Additional endpoint attributes are added as link attributes to their endpoint link unless their specification says otherwise. Group resources are annotated with their group names (gp), domain (d, if present) and multicast address (con, if present) as well as a constant resource type (rt="core.rd-gp"). </ins> While Endpoint Lookup does expose the registration resources, the RD does not need to make them accessible to clients.  Clients SHOULD NOT

changes from -13 to -14 <ins> Introduced resource types core.rd-ep and core.rd-gp </ins> Registration management moved to appendix A Minor editorial changes
Change:
The luminary of the example previously discovered its group addresses by looking up its own registration resource (which it did not know because it was entered by a CT), and via that its groups. As long as the device does not need to know its own registration resource, the same can be achieved in a single step by looking up groups that contain it directly, based on the address it would originally have compared the endpoint results against. Closes: URL Like with : NAME that's the example where you know all the rationales, feel free to merge or discard.
In the luminary example, the device first does an endpoint lookup to find its ep by comparing values, and then a group lookup to find its groups. That is unnecessary; by the rules of lookup, it could just do a group lookup with base= its own address and get the same result in one step.

Discussion:
luminaries can learn to which groups they belong, and enable their interface for the multicast address. <del> The luminary, knowing its sector, queries the RD for the endpoint with rt=light and d=R2-4-015.  The RD returns all endpoints in the sector. </del> <ins> The luminary, knowing its sector and own IPv6 address, looks up the groups containing light resources it is assigned to: </ins> <del> Knowing its own IPv6 address, the luminary discovers its endpoint name.  With the endpoint name the luminary queries the RD for all groups to which the endpoint belongs. From the base parameter value, the luminary learns the multicast address of the multicast group. </del> <ins> From the returned base parameter value, the luminary learns the multicast address of the multicast group. </ins> Alternatively, the CT can communicate the multicast address directly to the luminaries by using the "coap-group" resource specified in
Change:
The implementors in RIOT asked about whether a registrant could possibly maintain multiple registrations at different RDs, and how they interact. I think what I'm saying in this PR is obvious (though not redundant, as we don't talk about that topic otherwise), but given it was asked about, it's probably not. What are your opinions?
(Text updated after I learned more about what they thought was expected from Registrant-EPs.)
Shortened and merged.
A registrant-ep cannot be forbidden to register with multiple RDs anyway. May be a bit too much text for an obvious fact.

Discussion:
RD is provided using the CoRE Link Format. A Registrant-EP MAY keep concurrent registrations to more than one RD <del> at the same time, but that is not expected to supported by typical EP implementations.  Any such registrations are independent of each other. For this case to occur, the EP would need to be explicitly configured to register multiple times: either by having multiple discovery mechanisms or addresses configured (which are not merely fallbacks to each other), or by having several sets of registration data to register with (eg. multiple endpoint names). </del> <ins> at the same time if explicitly configured to do so, but that is not expected to be supported by typical EP implementations.  Any such registrations are independent of each other.  The usual expectation when multiple discovery mechanisms or addresses are configured is that they constitute a fallback path for a single registration. </ins> 3.3.
Change:
This solves issue ("nobody really knows what the parameter is for") by removing the parameter altogether.
We are not clear on how to use "res"in a lookup query. For example, what does xx represent in this query? GET /example/rd-lookup-gp?res=xx I couldn't find text to explain. Is it expected to be the address of a resource, like href or anchor+href ?
Hi Michael, From version 04 to the current version the ?res has undergone a change In the -10 example the return is ;rt=sensor;ct=60 where I might have expected ;rt=sensor;ct=60 But I cannot check because we do not know the contents of the RD and hypothesizing now: ?res=xx would have returned nothing unless there was an entry like ;rt=sensor;ct=60 and even more confusing we have something called resource-param. In an earlier e-mail Christian already suggested to modify that to link-param if I remember correctly. So yes, I can concur with you and agreeing with the existence of confusion. Peter Michael Koster schreef op 2017-05-05 16:01:
The last I had in mind about the parameter a short mention in the phone call -- to me it looked like a relic whose role has been superseded by ins et al. It is now the first time I perceive it as a parameter that does anything with the path. What is the intended overall purpose of res=? And what do you mean by the contents of the RD?
Hi Chris, I assume this a sequel to my answer to Michael. May be not..... The contents of the RD are all the information about ep, resources, etc. stored into the RD by whatever means. My speculation about res=xx means that it indicates filtering on resource paths which start with /xx/...... Peter
For such filtering, there is already , which is covered by the query parameter referencing RFC 6690. NAME of the RD": I see. Going through all the references in the document, it seems to me that the examples you mentioned are not about the lookup parameter, but just the arbitrary resource names in the pagination example. I'd suggest removing the parameter altogether (PR ) unless its use resurfaces.
I think "res" (for resource) may be useful as a link target attribute for tagging resources, and in that context could also be used as a lookup parameter. If we don't plan to create "res" as a target attribute we should remove it from the document. If we do want to define a new target attribute, maybe we can come up with something more descriptive than "res"...

Discussion:
GET <del> {+type-lookup-location}{?d,res,ep,gp,et,rt,page,count,resource- param} </del> <ins> {+type-lookup-location}{?d,ep,gp,et,rt,page,count,resource-param} </ins>

Domain (optional).  Used for domain, group, endpoint and resource lookups. <del> resource (optional).  Used for domain, group, endpoint and resource lookups. </del> gp := Group name (optional).  Used for endpoint, group and resource lookups.
Change:
The document uses the PATCH request method and the 4.09 response codes defined there. Closes: URL
This is needed for the 4.09 error code referenced.
Note to self: That draft is now
Looks good.

Discussion:
The Registration Resource may also be used to inspect the registration resource using GET, update the registration link <del> contents using PATCH, or cancel the registration using DELETE. </del> <ins> contents using PATCH (as introduced in RFC8132), or cancel the registration using DELETE. </ins> These operations are described in this section.
Change:
Jaime provided a detailled review, and Matthias provided an interesting use case that helped shape the base parameter details Closes: URL Disposition: Merge with next batch
The Acknowledgements section has not been updated for quite a while; I'll update it with the reviewers before releasing -20.

Discussion:
Oscar Novo, Srdjan Krco, Szymon Sasin, Kerry Lynn, Esko Dijk, Anders Brandt, Matthieu Vial, Jim Schaad, Mohit Sethi, Hauke Petersen, <del> Hannes Tschofenig, Sampo Ukkola, Linyi Tian, and Jan Newmarch have provided helpful comments, discussions and ideas to improve and shape this document.  Zach would also like to thank his colleagues from the EU FP7 SENSEI project, where many of the resource directory concepts were originally developed. </del> <ins> Hannes Tschofenig, Sampo Ukkola, Linyi Tian, Jan Newmarch, Matthias Kovatsch and Jaime Jimenez have provided helpful comments, discussions and ideas to improve and shape this document.  Zach would also like to thank his colleagues from the EU FP7 SENSEI project, where many of the resource directory concepts were originally developed. </ins> 12.
Change:
Not setting to 0 as this would require further explanation on what it means, and also leaves the 0 value usable as a sentinel in implementations for "no lt given" (although the same, with -1, could be achieved by reducing the range at the top end). Closes: URL
Feedback from LwM2M: Their testing takes long with the arbitrary limit of 60s. We found no technical reasons to keep it there, and it should probably be abolished in favor of the natural lower limit of 1 second.

Discussion:
authorization token. Lifetime (optional).  Lifetime of the registration in seconds. <del> Range of 60-4294967295.  If no lifetime is included in the </del> <ins> Range of 1-4294967295.  If no lifetime is included in the </ins> initial registration, a default value of 90000 (25 hours) SHOULD be assumed.

successful earlier registration. Lifetime (optional).  Lifetime of the registration in seconds. <del> Range of 60-4294967295.  If no lifetime is included, the </del> <ins> Range of 1-4294967295.  If no lifetime is included, the </ins> previous last lifetime set on a previous update or the original registration (falling back to 90000) SHOULD be used.
Change:
Reviewing the discussion in [1] and [2], my original patch seems to have overshot. [1]: URL [2]: URL
Much more sensibleless ambitious and more correct. The outcome in discussion in the Friday meeting was that the resource-directory specification should simply define the small number of DNS-SD service types that are needed for resource directory discovery. We said details were to be taken to the list, which I want to initiate now. In the meeting, I gave the three examples core-URL, core-rd-URL, and core-URL — noting that while core-rd is a proper RD service type, core-rd-tls isn’t. To cover the six transports we have for CoAP today (coap, coaps, coap+tcp, coaps+tcp, coap+ws, coaps+ws), we would need four service types on top of tcp and could use two of them over udp? Grüße, Carsten

Discussion:
4.1.2. <del> A resource directory can advertise its resources in DNS-SD using the service names "_rd._udp", "_rd-lookup-res._udp" and "_rd_lookup- ep._udp" defined in this document for its Directory Resource, its resource lookup and endpoint lookup resource, respectively.  A "path" key SHOULD be set, and indicate the path on the server (starting with a slash). </del> <ins> A resource directory can advertise its presence in DNS-SD using the service name "_core-rd._udp" defined in this document. </ins> <del> The use of those service names implies that CoAP-over-UDP is used. With that information, the host name and port given in the SRV record and the path from the TXT record, the discovering client can perform RD and URI discovery in a single step. </del> <ins> The use of that service names implies that CoAP-over-UDP is used. The SRV record points the client to a host name and port to use as a starting point for the URI discovery steps of discovery. </ins> <del> When the "path" key is absent, the client MUST discovery the URIs on the server according to discovery. This section is a concrete application of the more generic mechanism that is being developed as I-D.ietf-core-rd-dns-sd. </del> <ins> This section is a simplified concrete application of the more generic mechanism specified in I-D.ietf-core-rd-dns-sd. </ins> 4.2.

9.7. <del> IANA is asked to enter two new items into the Service Names and Transport Protocol Port Number Registry, all with this document as a reference: Service name "rd" over protocol "udp", described as "Resource Directory Directory Resource accessed using CoAP" </del> <ins> IANA is asked to enter a new item into the Service Names and Transport Protocol Port Number Registry: </ins> <del> Service name "rd-lookup-res" over protocol "udp", described as "Resource Directory resource lookup accessed using CoAP" </del> <ins> Service name: "core-rd" </ins> <del> Service name "rd-lookup-ep" over protocol "udp", described as "Resource Directory endpoint lookup accessed using CoAP" </del> <ins> Protocol: "udp" </ins> <del> All share the same assignment note: </del> <ins> Description: "Resource Directory accessed using CoAP" </ins> <del> Defined TXT key: path (e.g. "path=/rd") </del> <ins> Reference: this document </ins> 10.
Change:
This was missed in the original pull of mechanism from RD-DNS-SD into here; its wording was brought in line with the other recommendations ("In case X, Y is recommended") and now goes to the internal section rather than the external document. Will be merged on Monday before submission unless spoken against.

Discussion:
available), the use of a preconfigured anycast address is recommended (e.g. installation phase described in automation). <del> The use of DNS facilities is described in I-D.ietf-core-rd-dns-sd. </del> <ins> In networks managed using DNS-SD, the use of DNS-SD for discovery as described in rd-using-dnssd is recommended. </ins> The use of multicast discovery in mesh networks is NOT recommended.
Change:
Those were in the original proposals during IETF / on the list, but not in the text yet. Depends on for practical merging purposes.

Discussion:
4.1.2. A resource directory can advertise its presence in DNS-SD using the <del> service name "_core-rd._udp" defined in this document. </del> <ins> service name "_core-rd._udp" (for CoAP), "_core-rd-dtls._udp" (for CoAP over UDP), "_core-rd._tcp" (for CoAP over TCP) or "_core-rd- tls._tcp" (for CoAP over TLS)` defined in this document.  (For the WebSocket transports of CoAP, no service is defined as DNS-SD is typically unavailable in environments where CoAP over WebSockets). </ins> <del> The use of that service names implies that CoAP-over-UDP is used. The SRV record points the client to a host name and port to use as a starting point for the URI discovery steps of discovery. </del> <ins> The selection of the service indicates the protocol used, and the SRV record points the client to a host name and port to use as a starting point for the URI discovery steps of discovery. </ins> This section is a simplified concrete application of the more generic mechanism specified in I-D.ietf-core-rd-dns-sd.

9.7. <del> IANA is asked to enter a new item into the Service Names and </del> <ins> IANA is asked to enter four new items into the Service Names and </ins> Transport Protocol Port Number Registry: <del> Service name: "core-rd" </del> <ins> Service name: "core-rd", Protocol: "udp", Description: "Resource Directory accessed using CoAP" </ins> <del> Protocol: "udp" </del> <ins> Service name "core-rd-dtls", Protocol: "udp", Description: "Resource Directory accedded using CoAP over DTLS" </ins> <del> Description: "Resource Directory accessed using CoAP" </del> <ins> Service name: "core-rd", Protocol: "tcp", Description: "Resource Directory accessed using CoAP over TCP" </ins> <del> Reference: this document </del> <ins> Service name "core-rd-tls", Protocol: "tcp", Description: "Resource Directory accedded using CoAP over TLS" All in common have this document as their reference. </ins> 10.
Change:
This is to address Russ's genart comment:
The reflowing commit went here by accident (wrong branch / didn't check on upload). I'm pushing it to master, hoping this makes the PR's diff show only what's intended.

Discussion:
A web entity that stores information about web resources and implements the REST interfaces defined in this specification for <del> registration and lookup of those resources. </del> <ins> discovery, for the creation, the maintenance and the removal of registrations, and for lookup of the registered resources. </ins> In the context of a Resource Directory, a sector is a logical
Change:
It appears I've missed some of Alexey's remarks responding to the changes made after his initial review (, 2019-11-20). This contains fixes for the points he still wanted changed / suggested after my original response to his review.

Discussion:
This section describes how the registering endpoint can maintain the registrations that it created.  The registering endpoint can be the <del> registrant-ep or the CT.  An endpoint SHOULD NOT use this interface for registrations that it did not create.  The registrations are resources of the RD. </del> <ins> registrant-ep or the CT.  The registrations are resources of the RD. An endpoint should not use this interface for registrations that it did not create.  This is usually enforced by security policies, which in general require equivalent credentials for creation of and operations on a registration. </ins> After the initial registration, the registering endpoint retains the returned location of the Registration Resource for further

Search criteria for limiting the number of results (optional). <ins> The search criteria are an associative array, expressed in a form-style query as per the URI template (see RFC6570 Sections 2.4.2 and 3.2.8) </ins> Page (optional).  Parameter cannot be used without the count parameter.  Results are returned from result set in pages that contain 'count' links starting from index (page * count).  Page

registration of endpoints, as a query parameter in lookups, or be expressed as a target attribute, <del> validity requirements if any, </del> <ins> syntax and validity requirements if any, </ins> a description,