Dear Thierry,
I uderstand the necessity of making things move forward. However, I think that the deadline is this case was too close and that we could be in the risk of closing the topic without having reached an agreement (thus, future integration may fail).
Thus, in my opinion a topic regarding integration (in general, not only in this case) should be concluded when every participant people/partner feels confortable with the finally adopted decission, not when some particular date comes. But probably I'm a too idealistic guy ;)
Having said that, I think that we are close to reach an agreement, so problably we can conclude on the topic by May 28th.
Best regards,
------
Fermín
El 27/05/2014 16:22, thierry.nagellen at orange.com<mailto:thierry.nagellen at orange.com> escribió:
Hi Fermin,
I am the one pushing to hurry up the process because without deadline we do not have lots of contributions/reactions. Because we have many things to do, with the deadline, we put this point higher in the priority list. And at the end if we have also to integrate some changes in documentation and softwares, we should be able to do that before September and before SMEs joined through Open Call, just providing the most stable version for them.
BR
Thierry
De : 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] De la part de Fermín Galán Márquez
Envoyé : mardi 27 mai 2014 15:45
À : Tobias Jacobs
Cc : fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>
Objet : Re: [Fiware-ngsi] NGSI binding gap: format of 'reference' and 'providingApplication'
Dear Tobias,
Before closing the issue we would like to send our (TID) feedback. I hope to do it by today or tomorrow morning.
I wonder which is the reason to speed up the closing of the discussion (as your last email suggest)...
Best regards,
------
Fermín
El 27/05/2014 15:30, Tobias Jacobs escribió:
Hi all,
So I would like to close the topic; if there are further doubts from any partner, please let us know by today EoB.
Summarizing
- We standardize the “ngsi9”/”ngsi10” part of the resources to lowercase “ngsi”
- The Reference field will contain the URL where a notification can directly issued with a POST message
- The ProvidingApplication field will contain the URL including the “\ngsi10” part
I will do the editorial changes to the binding documents these days.
Best regards
Tobias
From: Rolando Sergio (Guest) [mailto:sergio.rolando at guest.telecomitalia.it]
Sent: Dienstag, 27. Mai 2014 14:39
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 Tobias,
thank you!
>From our side, your proposal is ok, and btw it avoids the problem with casing. Besides the nice fact that we have nothing to modify ☺, it is the way we chose from the beginning for our implementation and at that time it seemed us to be the most “natural” solution.
Best regards,
Sergio
From: Tobias Jacobs [mailto:Tobias.Jacobs at neclab.eu]
Sent: martedì 27 maggio 2014 12.17
To: Rolando Sergio (Guest); 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'
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
_________________________________________________________________________________________________________________________
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.
________________________________
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/30b4a9a6/attachment.html>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy