[Fiware-ngsi] NGSI binding gap: format of 'reference' and 'providingApplication'

Tobias Jacobs Tobias.Jacobs at neclab.eu
Thu May 22 16:45:04 CEST 2014


Dear all NGSI-interested people,

in the IoT integration meeting a few weeks ago we identified an underspecified point in the NGSI 9 and NGSI 10 binding, regarding

-          the exact format of the 'providingApplication' field in the NGSI 9 ContextRegistration structure, and

-          the exact format of the 'reference' field in the NGSI 10 'subscribeContextRequest' and the NGSI 9 'subscribeContextAvailabilityRequest' operations.

In order to remove the ambiguity, our proposal is to

-          make mandatory for NGSI9 [ NGSI10 ] servers to provide NGSI9 [ NGSI10 ] functionality under the URL "{serverRoot}/ngsi9"  [ "/{serverRoot}/ngsi10" ]. This deviates from the current binding in that we use lowercase "ngsi" instead of uppercase "NGSI". Using lowercase seems to be more common in REST interfaces, and anyway all IoT GEs have implemented it with lowercase as far as we know.

-          Make mandatory to specify in the 'reference' and 'providingApplication' field only the {serverRoot} part, without the 'ngsi9' part.

o   For example, for announcing in a contextRegistration that context information can be retrieved by sending POST messages to  "http://www.coolContext.org/ngsi10/queryContext" as defined by the NGSI standard, the 'reference' field has to be http://www.coolContext.org/ngsi10<http://www.coolContext.org/ngsi10>.

Please let us know you are ok with that proposal, or if you want to propose an alternative way to remove the ambiguity.

Best regards
Tobias

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/fiware-ngsi/attachments/20140522/0eae37b4/attachment.html>


More information about the Fiware-ngsi mailing list

You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy   Cookies policy