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

[laurent.artusio at orange.com]

I vote for Tobias's proposal: the "providingApplication" field (or "reference" in subscribeContext method) should be "http://www.coolContext.org" when the actual query endpoint is "http://www.coolContext.org/ngsi10/queryContext".

BR,

Laurent

De : fiware-iot-bounces at lists.fi-ware.org [mailto:fiware-iot-bounces at lists.fi-ware.org] De la part de Tobias Jacobs
Envoyé : vendredi 23 mai 2014 15:34
À : Rolando Sergio (Guest)
Cc : fiware-iot at lists.fi-ware.org; fiware-ngsi at lists.fi-ware.eu
Objet : Re: [Fiware-iot] NGSI binding gap: format of 'reference' and 'providingApplication'

Hi Sergio,

Thanks a lot for your feedback.

Indeed my example in the proposal was inconsistent; what I wanted to say is if the query endpoint is "http://www.coolContext.org/ngsi10/queryContext" then the providingApplication should read "http://www.coolContext.org".

What you are proposing instead is, if I understand correctly, to make the providingApplication "http://www.coolContext.org/ngsi10" instead in that case.

I think these are the two reasonable possibilities, and I do not have a very strong preference for one of them, as long as we define it in a consistent way.

As the NGSI binding has been implemented by many partners, are there more opinions?

Best
Tobias


From: Rolando Sergio (Guest) [mailto:sergio.rolando at guest.telecomitalia.it]
Sent: Freitag, 23. Mai 2014 12:00
To: Tobias Jacobs
Cc: fiware-ngsi at lists.fi-ware.eu
Subject: RE: NGSI binding gap: format of 'reference' and 'providingApplication'

Hi Tobias,
If I understand well, I fear that your last example is not aligned with your proposal. Probably you meant that the "reference" field should be "http://www.coolContext.org", in order to be notified to the full URL "http://www.coolContext.org/ngsi10<http://www.coolContext.org/ngsi10>/notifyContext".
Similarly, the "providingApplication" field should be (ex.) "http://prov.app.com", if the full URL able to receive the queryContextRequest POST messages is "http://prov.app.com/ngsi10/queryContext"
Is it correct? Otherwise, I would not see any relation between these issues and the upper/lower case choice for mapping NGSI endpoints.

>From our side, in our CAP-CB implementation we assumed that the "providingApplication" field of NGSI-9 ContextRegistration is the URL without the NGSI method, without assuming specific paths (e.g. it could be http://test.app.com/test1, if the provider is able to answer to queryContext POST messages sent to http://test.app.com/test1/queryContext )
The "reference" field in NGSI-10 subscribeContextRequest is instead the full notification URL (e.g. http://www.coolContext.org/ngsi10<http://www.coolContext.org/ngsi10>/notifyContext), and I now see the inconsistency :(

IMHO I'd prefer to leave out only the NGSI method (in the examples above: http://www.coolContext.org/ngsi10<http://www.coolContext.org/ngsi10> and  http://prov.app.com/ngsi10), or even better specifying the full URL (which btw could not be compliant with the NGSI endpoints URL assumption), since it would be more readable in messages, and without problems with casing assumption, also if it is verbose and, I admit, not necessary.

Best regards,
Sergio


From: fiware-ngsi-bounces at lists.fi-ware.org<mailto:fiware-ngsi-bounces at lists.fi-ware.org> [mailto:fiware-ngsi-bounces at lists.fi-ware.org] On Behalf Of Tobias Jacobs
Sent: giovedì 22 maggio 2014 16.45
To: fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>
Subject: [Fiware-ngsi] NGSI binding gap: format of 'reference' and 'providingApplication'

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


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

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