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

[Tobias Jacobs]

Hi Fermin,

Can you clarify how you would like to have the ‘providingApplication’ field in the below example?
Would it be “http://www.coolContext.org/ngsi10<http://www.coolContext.org/ngsi10/queryContext>” [compatible with Sergio’s proposal]?

As for the ‘reference’ field, I think there is a conflict between what would be consistent and what is implemented and deployed already now. I think however it would be good to avoid branching – in the end we should be compatible to each other.

For NEC it would be ok to go for the way it is implemented in Orion right now, and maybe later move to a version of the standard where it is changed to a consistent way.

Best
Tobias


From: Fermín Galán Márquez [mailto:fermin at tid.es]
Sent: Montag, 26. Mai 2014 11:33
To: Tobias Jacobs
Cc: fiware-ngsi at lists.fi-ware.eu
Subject: Re: [Fiware-ngsi] NGSI binding gap: format of 'reference' and 'providingApplication'

Dear Tobias,

Here comes feedback from the point of view of TID's implementation, i.e. Orion. Please find it inline.
El 22/05/2014 16:45, Tobias Jacobs escribió:
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.
[FGM1] We agree in using lowercase for that (in fact, Orion supports both lowercase and uppercase or a combination of both for that URL token, e.g. /NGSI10, /ngsi10, /Ngsi10, etc.).


-          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>.
[FGM2] We don't agree. In our opinion, NGSI server implementations shouldn't impose any constraints in the URLs to use as providingApplication and reference in order to provide maximum flexibility for all use cases. Moreover, imposing a particular format in the URLs (especially in the "reference" element) would break current applications using Orion, already deployed in FI-LAB and other environments.

However, as an alternative, we don't opose to define some kind of "IoT usage profile" in which we state the format for the URLs to be used internally in IoT chapter integration.

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

Best regards,

------
Fermín
________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/fiware-ngsi/attachments/20140526/bd538770/attachment.html>