On 02-Nov-22 20:16, Michael Richardson wrote:
https://github.com/anima-wg/constrained-join-proxy/pull/44
## GRASP Discovery Registry
IANA is asked to extend the registration of the "AN\_join\_registrar" (without quotes) in
the "GRASP Objective Names" table in the Grasp Parameter registry.
> I agree, but I don't see the value in adding bytes to the wire.
+1
To reduce testing effort for adopters of this solution it's best if we do not
specify/allow other resources than '/'. We haven't identified yet the value of
allowing other resources (only disadvantages).
Esko
-Original
Yes it's probably better to call it "path of the resource" or "URI path".
(Background: In CoAP implementations the term "resource name" is colloquially
used for the final URI path component. In the RFC 7252 URI composing section
it's used for the entire URI path + query components.)
Esko
https://github.com/anima-wg/constrained-join-proxy/pull/44
## GRASP Discovery Registry
IANA is asked to extend the registration of the "AN\_join\_registrar" (without
quotes) in the "GRASP Objective Names" table in the Grasp Parameter registry.
This document should also be cited for the
{wasn't actually offlist}
Brian E Carpenter wrote:
> By "URI resource name", do you mean "URI path component"? "Path" seems
> to be the official name for what follows the host in a URI, according
> to RFC3986.
I give up :-) whatever.
Uri-Path is the name of the CoAP option that
Brian E Carpenter wrote:
> Two comments there:
> 1) It would be trivial to extend the definition of the BRSKI_RJP
objective by giving
> it a meaningful value field, such as a string defining the URI resource
name. Like:
> objective-value = text ; URI resource name
I
Brian E Carpenter wrote:
> 2) At the moment draft-ietf-anima-constrained-join-proxy cuts a corner
> in its definition of BRSKI_JP. Even if you want to save typing by
> citing Fig. 10 of RFC8995, you need to
> add an IANA Consideration formally registering the objective (like
Esko Dijk wrote:
> On the one hand if we decide to use CoAP for a particular function then
> we may expect implementers need to know CoAP as well and e.g. read RFC
> 7252. Including thinking about security issues of unsecured-CoAP. The
> benefit or re-use comes with that
