Draft: draft-ietf-core-resource-directory

Commentary: As planned in the last authors ' meeting : et should become just one of the registrable endpoint attributes ( registry is already being prepared as RD parameter registry , but needs some work ) lookup should allow using any of those registered attributes lookup should define how endpoint attributes are used in resource lookups ( after all , should be possible even though none of the resource links actually carry that attribute ) This PR is not final as it is , but will track my branch as I 'm assembling ( and possibly rewriting / rebasing ) commits for this change . 
 et is not used by Fairhair , but that should not influence the text , I think 
 The bulk of the announced changes is now in the pull request ; I 'll go through it one more time myself before I merge it into master . ( I might still add a big reshuffling change to the lookup interface , because the text has grown in the past by always inserting paragraphs , and they 're not necessarily in a logical overall sequence . ) 
 I only just now merged the current state of the branch into master , the rebuild just completed . 
 See - Also : Some of what could be the review of this PR has come up in 
 I do n't see any reason to keep this section as pointed out during the last telco . When it is removed some examples i Registration update must be changed . The request GET /rd/4521 should change to GET /rd - lookup / ep?href = rd/4521 
 Apologies , that will not return the links of the endpoint The request GET /rd/4521 should change to GET /rd - lookup / res?ep=/rd/4521 or GET /rd - lookup / res?ep = node1 I am afraid we need to stay with ep name , difficult to use /rd/4521 as ep identifier . 
 The equivalent requests would be GET /rd - lookup / res?ep = node1 and GET /rd - lookup / res?href=/rd/4521 ( where the link has neither the ep = node1 nor the href=/rd/4521 link parameter , but its registration does ) . 
 I think that we do n't need the GET as long as there are no PATCHes ( and I recently saw we do n't even define PUT for the registration resource ) . The discussion has shown that this is one of the points where our understanding of resolved and unresolved addresses is tested : Can we have a resource whose content is " unresolved link - format " to operate on ? Or do we need to resolve the links even in there , and any PATCH format would need to work semantically from a shared understanding of both the RD and the client ? you wanted to meditate on that ; have you found deeper truth , or a path there ? 
 This weird indeed : In my understanding this means return all link resource paths with ep name node1 and GET /rd - lookup / res?href = skins /  / rd/4521 means return all link resource paths with href is skins /  / rd/4521 and will be empty chrysn schreef op 2017 - 10 - 30 13:03 : 
 returns resources that either have as their own link href , or are contained in an endpoint or group with that href . This was introduced in because we do not have ( due to the extensibility of the link attributes and the lack of a definitive registry ) a partition on attribute names that clearly states that one attribute can only be on a group , another only on an endpoint and a third only on a resource . Thus , we need to expect matches from either level -- and once we already have to do this , we can just as well do it with href because it 's treated like any other attribute . IMO the alternatives to this would be either having registries set up to partition the names so every query parameter is clearly an endpoint , group or resource attribute ( probably not going to happen with resource attributes , as requested and denied in RFC5988bis ) , or we 'd need a more complex lookup language than RFC6690 - style search -- something like so we could be explicit there . ( See also ) 
 Ok , you go faster than my shadow . As long as the text covers the example , and the intention is clear . I will need to read the finished text again . chrysn schreef op 2017 - 10 - 30 16:29 : 
 ( Moving some comments here from EMail to keep track :) [  ] I thought we agreed to remove section 5.4.3 , [ Christian ] I had that taken down as " we should think about it some more " ; I do expect that interfact to only become useful when we have a way to patch it . 
 Given the current direction of lookup with construction of absolute URI , we can leave section 5.4.3 in 
 The " RD Parameters " subregistry is set up in the IANA considerations , but only referenced at the registration interface . The lookup interface allows lookup by parameters of the same names ( and page and count are exclusively used for lookup ) , but does n't make a reference to the iana - registry . Next steps ( →CA ): Add a reference to lookup interface description ( and reviewing that text , decide on whether that does create linkage to any other existing registry ) .
Paragraph (version A):
Endpoint Type (optional).  The semantic type of the endpoint.
This parameter SHOULD be less than 63 bytes.
Paragraph (version A):
The endpoint MUST include the endpoint name and MAY include the
registration parameters d, lt, et and extra-attrs, in the POST
request as per registration.  The context of the registration is
taken from the requesting server's URI.
Paragraph (version B):
The endpoint MUST include the endpoint name and MAY include the
registration parameters d, lt and extra-attrs, in the POST request as
per registration.  The context of the registration is taken from the
requesting server's URI.
Paragraph (version A):
Endpoint and group lookups result in links to the selected
registration resource and group resources.  Endpoint registration
resources are annotated with their endpoint names (ep), domains (d,
if present), context (con), endpoint type (et, if present) 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 the selected
registration resource and group resources.  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):
An endpoint registering at an RD can describe itself with endpoint
types, similar to how resources are described with Resource Types in
RFC6690.  An endpoint type is expressed as a string, which can be
either a URI or one of the values defined in the Endpoint Type
subregistry; it SHOULD be shorter than 63 bytes.  Endpoint types can
be passed in the "et" query parameter as part of extra-attrs at the
Registration step, are shown on endpoint lookups using the "et"
target attribute, and can be filtered for using "et" as a search
criterion in resource and endpoint lookup.  Multiple endpoint types
are given as separate query parameters or link attributes.
Paragraph (version B):
Note that Endpoint Type differs from Resource Type in that it uses
multiple attributes rather than space separated values.  As a result,
Resource Directory implementations automatically support correct
filtering in the lookup interfaces from the rules for unknown
endpoint attributes.
Paragraph (version B):
This specification establishes a new sub-registry under "CoRE
Parameters" called "Endpoint Type".  The registry properties
(required policy, requirements, template) are identical to those of
the Resource Type parameters in RFC6690.  The registry is initially
empty.