-
Notifications
You must be signed in to change notification settings - Fork 52
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Alternate path and discover request. #534
Comments
@dnav, @hannestschofenig any idea about this ? |
I guess the question is also relevant for the "CoreLink" data type. |
I guess first one (no alternate path) is OK (probably the better one) Anyway 1) or 2) could be implemented but not at the same time so I would like to be sure which one is the right one. As the specification says nothing about discover operation in alternate path, I guess this is rather the 1) ? |
@dnav, @hannestschofenig (or anyone else) I'm currently refactoring the Link API of Leshan and this will be really helpful to get clarification about this. So if you find time, this will be really appreciated 🙏. |
Thinking a bit more about this 🤔, maybe the second one could be annoying too as we need to handle inconsistency between the information giving at registration time and at discover time. |
@sbernard31 @dnav I believe this is addressed by CORELINK, please let me know if you still have any concerns |
@mkgillmore it's still not clear to me but maybe I missed something.
Could you provide your interpretation and also link to CORELINK which make you think what you think ? 🙂 |
The specification define alternate path.
I ask msyself if the DISCOVER payload must contains the root path or not ?
E.g. if at registration device sends :
</lwm2m>;rt="oma.lwm2m",</lwm2m/1/0>,</lwm2m/3/0>
On a DISCOVER request on
/3
what is the right expected payload :The text was updated successfully, but these errors were encountered: