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

[Fermín Galán Márquez]

Dear Tobias, Sergio,

First of all, I would separate the discussion on "reference" from the discussion on "providingApplication". For "reference" I understand that we all agree on interpreting the URL as the final destination of the callback (without any additions) leaving free choice to subscribers/providers. Is that correct?

Regarding "providingApplication", we believe that the main point is not the URL format (we think it is a minor aspect and 'IP:port/prefix/ngsi10/' is ok), but to close the subset of NGSI operations that a standard compliant providing application must support. In this sense, we understand that the operations list to consider is:

  1.  NGSI10 queryContext standard operation (POST)
  2.  NGSI10 convenience operations for query (GET):
     *   contextEntities/{EntityID}
     *   contextEntities/{EntityID}/attributes/{attributeName}
     *   contextEntities/{EntityID}/attributes/{attributeName}/{valueID}
     *   contextEntities/{EntityID}/attributeDomains/{attributeDomainName}
     *   contextEntityTypes/{typeName}
     *   contextEntityTypes/{typeName}/attributes/{attributeName}
     *   contextEntityTypes/{typeName}/attributeDomains/{attributeDomainName}
  3.  NGSI10 updateContext standard operation (POST)
  4.  NGSI10 convenience operations for updating (POST/PUT)
     *   contextEntities/{EntityID}
     *   contextEntities/{EntityID}/attributes/{attributeName}
     *   contextEntities/{EntityID}/attributes/{attributeName}/{valueID}
  5.  Anything that I'm missing?

>From our point of view, only number 1 should be mandatory (the other could be optional and we can state that in our documents).

Best regards,

------
Fermín

PD. Sergio, contragulations for your new baby! :)

El 27/05/2014 12:17, Tobias Jacobs escribió:
Dear Sergio,

First of all, congratulations to your new baby!! Also thanks for a quick reaction on this.

For the “Reference” field we can live with your proposal, as there is anyway only one resource defined in the binding where you can invoke notifications.

But putting http://www.coolContext.org/foo/bar/ngsi10/queryContext for providingApplication is really an unsatisfying solution for me. How do you then know what can be done with that resource (standard query, convenience query, subscription, etc.)?
I think this will also be a problem for your Context Broker implementation.

So I would rather keep it as you have implemented it now (full URL for Reference, http://www.coolContext.org/foo/bar/ngsi10/<http://www.coolContext.org/foo/bar/ngsi10/queryContext> for ProvidingApplication). This might be not so beautiful, but at least is work. And you guys have less implementation work to do ;-)

Best regards
Tobias





From: Rolando Sergio (Guest) [mailto:sergio.rolando at guest.telecomitalia.it]
Sent: Dienstag, 27. Mai 2014 10:49
To: Tobias Jacobs; Fermín Galán Márquez
Cc: fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>
Subject: RE: [Fiware-ngsi] NGSI binding gap: format of 'reference' and 'providingApplication'

Hi all,
In order not to impose restrictions (I think that this point is important), I would propose to:

1.       specify the full URL in reference and providingApplication fields, ex.:  http://www.coolContext.org/foo/bar/ngsi10/queryContext or http://www.coolContext.org/foo/bar/NGSI10/notifyContext  , therefore leaving free choice to subscribers/providers.

2.       this way, the problem with casing is not present, and we can leave binding specifications as is (e.g. …/NGSI10) saving existing Context Broker implementations (providers and subscribing applications can instead  choose freely their endpoints, as said in 1.)
I think that this solution would avoid any confusion, since no part is added to the specified URL.
Let me know your opinion.

About TI Context Broker, our subscribeContextRequest “reference” field contains already the full URL, we will modify the ContextRegistration “providingApplication”, which now does not contains the method (queryContext in the example).
Since the idea of provider is part of NGSI standard (not only FI-WARE binding by means of convenience functions), we have assumed that the provider is able to return a queryContextResponse data structure, as for standard NGSI queryContext response, without considering convenience functions.

Best regards,
Sergio

PS My new born baby is wonderful, thanks God! ☺

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: lunedì 26 maggio 2014 14.05
To: Fermín Galán Márquez
Cc: fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>
Subject: Re: [Fiware-ngsi] NGSI binding gap: format of 'reference' and 'providingApplication'

Hi Fermin,

It is not about imposing restrictions, but it is about how to interpret what is written in providingApplication and Reference.

Assuming that in the ProvidingApplication field there is http://www.coolContext.org/foo/bar and now I want to retrieve data on entity “Room1” by convenience operation. Do I make a GET at

http://www.coolContext.org/foo/bar/ngsi10/ContextEntities/Room1

or is it rather

http://www.coolContext.org/foo/bar/ContextEntities/Room1
?

I think that this should be agreed in the standard to ensure interoperability.

Best
Tobias


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

Dear Tobias,

As far as I remember, NGSI OMA spec doesn't impose any restriction in both providingAppliction or reference formats (appart that they has to be xs:anyUri) and I don't see any reason to impose such restrictions ourselves.

Regarding your question, my opinion is that is not resposbility of the NGSI server to decide if providingApplication has to have one format or other, either http://www.coolContext.org/ngsi10, http://www.coolContext.org/ or http://www.coolContext.org/foo/bar. Let's NGSI clients decide as they send the registerContext to the NGSI server.

Best regards,

------
Fermín
El 26/05/2014 12:22, Tobias Jacobs escribió:
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<mailto: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

________________________________

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


________________________________

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/20140527/b77d3fd8/attachment.html>