{clearing out old emails}
Jim Schaad <[email protected]> wrote:
> There are a couple of questions that I would put here that I think guides
> things.
> * Is there any expectation that the path components would ever change for
> some implementation or are they always going to be the same? Would a
> request voucher always be posted to /rv or could an implementation change
it
> to be /rvr?
To me, there is no reason.
> * Is there a reason for an endpoint to want to get what services are
> supported as a general rule rather than just assuming that if the root
> exists then all of the services are also going to exist.
I would tend to think that was the case.
> If the answer to the first question is no, then I don't know that they
even
> need to have resource types. You get the root and go from there.
> If the answer to both questions is yes, then a different rt for every
> service would be needed so that they can be distinguished.
> If the answer to the first question is no and the second is yes, then it
> would make sense to define a generic rt='ace.est.service' so that the root
> and the list of services can be queried for individually.
I don't think it's justified.
It might be useful to be able to inquire to an EST (CoAP) end point whether or
not
it supports the BRSKI extensions, but I can't come up with an operational
situation where this would be used.
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
