jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-core-resource-directory

Commentary: 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 : 
 should lt value in lookup give time from specification moment to end or from lookup moment to end 
 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 . is that something you 'd be happy with ?
Paragraph (version A):
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.
Paragraph (version A):
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), context (con) and lifetime (lt, if present).  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).
Paragraph (version B):
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)
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).
Draft: draft-ietf-core-resource-directory

Commentary: With the formal introduction of Target in , this seems even more important to point out . Next steps : merge unless someone protests .
Paragraph (version A):
A Context is a base URL that gives scheme and (typically)
authority information about an Endpoint.  The Context of an
Endpoint is provided at registration time, and is used by the
Resource Directory to resolve relative references inside the
registration into absolute URIs.
Paragraph (version A):
The target of a link is the destination address (URI) of the link.
It is sometimes identified with "href=", or displayed as
"<target>".  Relative targets need resolving with respect to the
Base URI (section 5.2 of RFC3986.
Paragraph (version B):
A Context is a base URL that gives scheme and (typically)
authority information about an Endpoint.  The Context of an
Endpoint is provided at registration time, and is used by the
Resource Directory to resolve relative references inside the
registration into absolute URIs.  This is a distinct concept from
the "link context" defined in RFC8288.
Paragraph (version B):
The target of a link is the destination address (URI) of the link.
It is sometimes identified with "href=", or displayed as
"<target>".  Relative targets need resolving with respect to the
Base URI (section 5.2 of RFC3986.  This use of the term Target is
consistent with RFC8288's use of the term.
Draft: draft-ietf-core-resource-directory

Commentary: This is easier to to satisfy with a " once per day " update , a nice round number , and still over 9000 . Closes : 
 I think that the default value of lt should be modified so that it is slightly greater than one day . If it is one day then a cron job which starts at midnight everyday could potentially end up not acting in time to renew rather than re - register an item . Given that a post to the resource adds the value of lt to the current time , there would be no drift in the expiration time .
Paragraph (version A):
Lifetime (optional).  Lifetime of the registration in seconds.
Range of 60-4294967295.  If no lifetime is included in the
initial registration, a default value of 86400 (24 hours)
SHOULD be assumed.
Paragraph (version B):
Lifetime (optional).  Lifetime of the registration in seconds.
Range of 60-4294967295.  If no lifetime is included in the
initial registration, a default value of 90000 (25 hours)
SHOULD be assumed.
Paragraph (version A):
Lifetime (optional).  Lifetime of the registration in seconds.
Range of 60-4294967295.  If no lifetime is included, the
previous last lifetime set on a previous update or the original
registration (falling back to 86400) SHOULD be used.
Paragraph (version B):
Lifetime (optional).  Lifetime of the registration in seconds.
Range of 60-4294967295.  If no lifetime is included, the
previous last lifetime set on a previous update or the original
registration (falling back to 90000) SHOULD be used.
Draft: draft-ietf-core-resource-directory

Commentary: Closes : See rationale there . Action if not commented on : merge 
 The proposal from last meeting about handling RC66900 - vs-8288 needs to be implemented : Prescribe that the RD always send href in absolute form if anchor is present ( things like can stay relative ) Adapt all examples Update the illustrative appendix Describe motivation for the rule 
 Open questions : Will links - json follow what we discussed and have clear 8288 - style resolution ? ( waiting for responses to ) Shall the rule for permissible data at registration be " no relative href when anchor is present " ( clear and concise , but overly restrictive at or " no relative href when anchor is present and more absolute than the target " ( verbose to describe , but less restrictive / does n't produce collateral damage ) ? The current proposal acknowledges the problem when referring to " the payload of the 6th request of section 5 of ... " ; the appendix will also need to have its examples adapted further on that when it 's decided . 
 The sharper variety of the rules can be phrased like this : ( For RFC6690 documents ) , " If anchor is an absolute reference , the target reference must be absolute . If the anchor is a relative reference , the target can only be a relative reference if its takes the same ABNF alternative choice as the anchor 's , or a choice listed earlier in the ABNF definition of in RFC 3986 -- unless anchor is of the form , in which case the target can not take the too but must be absolute or pick an earlier choice . ( Figuratively speaking , the anchor can not be more absolute than the target ) . " Quite a mouthful just to keep allowing all examples of RFC6690 like in .. ( The " bad " cases that cause ambiguity never showed up in any examples so far unless they were constructed on purpose to show the ambiguity . ) I 've pushed a version that includes the more restrictive variety to master to keep things flowing . 
 Revisiting this : fine - graned wording seems to be overkill , but so is ruling out common expressions in .well - known / core documents . Toning down to " SHOULD NOT contain statements that would cause ambiguity between RFC6690 and RFC8288 interpretation " in an upcoming pull request to close this issue .
Paragraph (version A):
Note that said content is in violation of the rule against relative
references in presence of the anchor attribute; the server accepted
it because no ambiguity is created in this particular case.
Draft: draft-ietf-core-resource-directory

Commentary: Text changes after it seems that empty 2.05+Content - Format observed representations work . Example updated because it seems fitting for the RD to announce that capability . ( Not that the indication changes anything about the possibility , but clients might not even try otherwise ) . Closes : would this shortened text still satisfy your concerns ? 
 For the example " obs " on rd - lookup / res is sufficient . 
 Hi  , thanks for all the work . We are making progress . I commented on 2 of the pull requests ( typo and suggestion ) . Text is suggested for the commit on identification ; I did not like the " debugging " annotation at all . Once everything is committed , I hope to go through it all again with today 's knowledge . I think  's text is terse but correct ; can you close the issue , or suggest small changes ? Thanks ,   schreef op 2018 - 01 - 31 19:25 : 
 ad " obs in /rd - lookup / res only " : I do n't see why the server should , but it works just as well , so why argue , updated . 
 It is an example . It shows that not all needs to be observed . chrysn schreef op 2018 - 02 - 01 12:21 :
Paragraph (version A):
The following example shows the way of indicating that a client may
request alternate content-formats.  The Content-Format code attribute
"ct" MAY include a space-separated sequence of Content-Format codes
as specified in Section 7.2.1 of RFC7252, indicating that multiple
content-formats are available.  The example below shows the required
Content-Format 40 (application/link-format) indicated as well as the
the CBOR and JSON representation of link format.  The RD resource
paths /rd, /rd-lookup, and /rd-group are example values.  The server
in this example also indicates that it is capable of providing
observation on lookup results.
Paragraph (version B):
The following example shows the way of indicating that a client may
request alternate content-formats.  The Content-Format code attribute
"ct" MAY include a space-separated sequence of Content-Format codes
as specified in Section 7.2.1 of RFC7252, indicating that multiple
content-formats are available.  The example below shows the required
Content-Format 40 (application/link-format) indicated as well as the
the CBOR and JSON representation of link format.  The RD resource
paths /rd, /rd-lookup, and /rd-group are example values.  The server
in this example also indicates that it is capable of providing
observation on resource lookups.
Draft: draft-ietf-core-resource-directory

Commentary: Unless takes a very surprising turn , I suggest reverting this : /rd - lookup / res ( assuming it was discovered ) always exists 2.03 is the wrong code this prescribes things already following from general observation Not reverting it yet awaiting the closure of . 
 chrysn schreef op 2018 - 01 - 31 12:26 :
Paragraph (version B):
When /rd-lookup/res does not exist, the response code 4.04 (Not
Found) is returned and the request is not registered.
Paragraph (version B):
When rd-lookup/res exists, the request is registered in the list
of subjects and observers.
Paragraph (version B):
When none of the links matches the filter, an empty payload with
response code 2.03 (Valid) is returned.
Paragraph (version B):
In all other cases, the set of matching links is returned in the
payload with response code 2.05 (Content).
Paragraph (version B):
Every time, the set of matching links changes, or the content of a
matching link changes, the RD sends a notification with the
matching link set.
Draft: draft-ietf-core-resource-directory

Commentary: The description of the Registration interface describes it as idempotent , I think it should be idempotent on CoAP and not only on application level -- the same request results in the same response with no further state change . As to what happens when the re - registration arrives with a different set of links , there we have options ; I went for " replaces the registration " here , but a 4.09 in that case would be just as valid an option . that topic came up with the removal of the plurality removal at Do you agree with the basic proposition of " an unmodified request should be 2.04 " , and do you think replacing is the right way , or 4.09 if the links do n't match ? 
 Replacement is OK , given the removal of " addition of inks " with a POST . Conflicts are indeed impossible then .
Paragraph (version A):
be included in the response when a new registration resource is
created.  This Location MUST be a stable identifier generated by
the RD as it is used for all subsequent operations on this
registration resource.  The registration resource location thus
returned is for the purpose of updating the lifetime of the
registration and for maintaining the content of the registered
links, including updating and deleting links.
Paragraph (version A):
registration resource with ep and d value pair which is already
present in an earlier created registration resource.
Paragraph (version B):
be included in the response when a new registration resource is
created.  This Location MUST be a stable identifier generated by
the RD as it is used for all subsequent operations on this
registration resource.  The registration resource location thus
returned is for the purpose of updating the lifetime of the
registration and for maintaining the content of the registered
links, including updating and deleting links.  A registration with
an already registered ep and d value pair responds with the same
success code and Location as the original registration; the set of
links registered with the endpoint is replaced with the links from
the payload.
Draft: draft-ietf-core-resource-directory

Commentary: See individual commit messages 
 As we support the alternative serializations from draft - ietf - core - links - json , I 'd like to add at least the numbers in the RD lookup examples . 
 Use TBD64 etc . , as discussed in the call .
Paragraph (version A):
A Resource Directory may optionally support HTTP.  Here is an example
of the same registration operation above, when done using HTTP.
Paragraph (version B):
A Resource Directory may optionally support HTTP.  Here is an example
of almost the same registration operation above, when done using HTTP
and the JSON Link Format.
Draft: draft-ietf-core-resource-directory

Commentary: The first commit tries to get across the difference between the relative references in the serialization and the URIs in the model more clearly . The second commit adds paragraphs to the descriptions of various operations about how and by whom URIs are resolved in those steps .
Paragraph (version B):
The posted link-format document can (and typically does) contain
relative references both in its link targets and in its anchors, or
contain empty anchors.  The server needs to resolve these references
in order to faithfully represent them in lookups.  The Base URI
against which they are resolved is the context of the registration,
which is provided either explicitly in the "con" parameter or
constructed implicitly from the requester's network address.  When
resolving relative target references, the server first resolves the
context of that link (the in the "anchor" attribute), and then
interprets the target as a reference relative to that context (see
resolution-rules).
Paragraph (version B):
If the context of the registration is changed in an update explicitly
or implicitly, relative references submitted in the original
registration or later updates are resolved anew against the new
context (like in the original registration).
Paragraph (version A):
Resource lookup results in links that are semantically equivalent to
the links submitted to the RD if they were accessed on the endpoint
itself.  The links and link parameters returned are equal to the
submitted ones except for anchor, which gets resolved according to
the endpoint's context.  That allows the client to interpret the
response as links without any further knowledge of what the RD does.
The Resource Directory MAY replace the contexts with a configured
intermediate proxy, e.g. in the case of an HTTP lookup interface for
CoAP endpoints.
Paragraph (version B):
Resource lookup results in links that are semantically equivalent to
the links submitted to the RD if they were accessed on the endpoint
itself.  The links and link parameters returned are equal to the
submitted ones except for anchor, which was resolved by the server
against the endpoint's context.
Paragraph (version B):
Links that did not have an anchor attribute are therefore returned
with the (explicitly or implicitly set) context URI of the
registration as the anchor.  Links whose anchor was submitted as an
absolute URI are returned as they were registered.  The hrefs of
links can always be served as they were submitted; the server MAY
return relative references in absolute form in to resource lookups,
but that results in needlessly verbose responses.
Paragraph (version B):
That allows the client to interpret the response as links without any
further knowledge of what the RD does.  The Resource Directory MAY
replace the contexts with a configured intermediate proxy, e.g. in
the case of an HTTP lookup interface for CoAP endpoints.
Draft: draft-ietf-core-resource-directory

Commentary: Says that this describes concepts and not implementation .
Paragraph (version B):
These models provide an abstract view of the information expressed in
link-format documents and a Resource Directory.  They cover the
concepts, but not necessarily all details of an RD's operation; they
are meant to give an overview, and not be a template for
implementations.
Draft: draft-ietf-core-resource-directory

Commentary: I think that rt is not an attribute of a registration ; the first commit reflects that . ( The second is more bycatch from that ) . Possibly we can simplify the whole section ; as everything in the result is links , we 're only applying the same link filtering that 6690 already specifies ( plus pagination ) . 
 Absolutely right . After all commits by Christian , I will look at these examples again together with discovery text and other details . cabo schreef op 2017 - 10 - 19 16:57 :
Paragraph (version A):
Link attribute parameters (optional).  Any link target
attribute as defined in Section 4.1 of RFC6690, used for
resource lookups.
Paragraph (version B):
Link parameters (optional).  Any link parameter as defined in
Section 4.1 of RFC6690, including href, used for resource
lookups.
Draft: draft-ietf-core-resource-directory

Commentary: Some minor text changes ( commented per commit ) I think are resonable and will merge soon unless someone speaks up against them .
Paragraph (version A):
An endpoint can send (a selection of) hosted resources to a directory
server for publication as described in simple_publishing.
Paragraph (version B):
An endpoint finally asks the directory server to probe it for
resources and publish them as described in simple_publishing.
Draft: draft-ietf-core-resource-directory

Commentary: This is the first step to closing [ 54 ] , doing the changes to the model itself . Wo n't close the issue by itself probably , as some other portions might mention the model . This does not try to address any of the open issues . [ 54 ] : 
 s taget / target/
Paragraph (version B):
Some of the attribute values are URIs.  Those values are always full
URIs and never relative references in the data model.  They can,
however, be expressed as relative references in serializations, and
often are.
Paragraph (version A):
One or more link relations (expressed as space-separated values in
the "rel" attribute, defaulting to "hosts").  They describe a
relations between the link context and the link target.
Paragraph (version A):
A link context URI ("anchor").  The link context defines the
source of the relation, and serves as the Base URI for resolving
the target.  It can be relative, in which case it gets resolved
against the Base URI of the ".well-known/core" document it was
obtained from . It can be absent, in which the Base URI of the
document is used as the context.
Paragraph (version A):
A link target URI ("href", expressed between the angular brackets
in link-format).  The link target defines the destination of the
relation, and is the topic of all other target attributes.  If it
is a relative URI, it gets resolved against the link context URI.
Paragraph (version B):
Zero or more link relations (expressed as space-separated values
in the "rel" attribute, defaulting to "hosts").  They describe a
relations between the link context and the link target.
Paragraph (version B):
A link context URI ("anchor").  The link context defines the
source of the relation, and serves as the Base URI for resolving
the target.  In the serialization, it can be relative, in which
case it gets resolved against the Base URI of the ".well-known/
core" document it was obtained from . It can be absent, in which
the Base URI of the document is used as the context.
Paragraph (version B):
A link target URI ("href", expressed between the angular brackets
in link-format).  The link target defines the destination of the
relation, and is the topic of all other target attributes.  In the
serialization, if it is a relative URI, it gets resolved against
the link context URI.
Paragraph (version A):
Links are modelled as they are in fig-ER-WKC.  As they do not have
their ".well-known/core" document associated with them any more which
would originally provide its Base URI, the "con" attribute of the
registration fills that gap and is used as a Base URI.
Paragraph (version B):
Links are modelled as they are in fig-ER-WKC.
Draft: draft-ietf-core-resource-directory

Commentary: This PR fixes a simple typo . Side question : I found a number of lines in the markdown document that have spaces before the newline character . Would a PR removing those also be of interest ? 
 Thanks ! Re your side question : So I 'm not the only person annoyed by trailing spaces :-) I went ahead and fixed this ( one command in Emacs :-) , including re - aligning a markdown table .
Paragraph (version A):
An update MAY update the lifetime or context registration parameters
"lt", "con" as in registration ) if the previous settings are to be
retained.  Parameters that are not being changed changed SHOULD NOT
be included in an update.  Adding parameters that have not changed
increases the size of the message but does not have any other
implications.  Parameters MUST be included as query parameters in an
update operation as in registration.
Paragraph (version B):
An update MAY update the lifetime or context registration parameters
"lt", "con" as in registration ) if the previous settings are to be
retained.  Parameters that are not being changed SHOULD NOT be
included in an update.  Adding parameters that have not changed
increases the size of the message but does not have any other
implications.  Parameters MUST be included as query parameters in an
update operation as in registration.
Draft: draft-ietf-core-resource-directory

Commentary: The document uses the PATCH request method and the 4.09 response codes defined there . Closes : 
 This is needed for the 4.09 error code referenced . 
 Note to self : That draft is now 
 Looks good .
Paragraph (version A):
The Registration Resource may also be used to inspect the
registration resource using GET, update the registration link
contents using PATCH, or cancel the registration using DELETE.
Paragraph (version B):
The Registration Resource may also be used to inspect the
registration resource using GET, update the registration link
contents using PATCH (as introduced in RFC8132), or cancel the
registration using DELETE.