[Fiware-ngsi] Issues in the NGSI OMA spec

[Moltchanov Boris]

Hi Tobias,

if there is no reason to have the SID asked by the client thus it shall be assigned by the broker, then I don't see the reason to have this field in the subCxtAv request but only as MANDATORY in the broker's response. I'm not sure what will be better with respect to OMA spec to have it as optional YES in the client's request and then overwritten by the broker answering to the client with a new ID, or just exclude it from the request...

The rest shall work as before.

Best Regards,
Boris

From: Tobias Jacobs [mailto:Tobias.Jacobs at neclab.eu]
Sent: Tuesday, January 29, 2013 2:53 PM
To: Moltchanov Boris; Fermín Galán Márquez
Cc: fiware-ngsi at lists.fi-ware.eu
Subject: RE: [Fiware-ngsi] Issues in the NGSI OMA spec

Hi Boris, all,

For me the possibility for the client to suggest its own subscription ID is ok. However, in the current OMA NGSI specs the client does not have that possibility in the subscribeContextRequest of NGSI 10.
Is there a specific reason for this inconsistency between OMA NGSI 9 and 10?

I still think it would be good if we collect the "improvements" somewhere. I guess this will then also be the ones proposed to OMA.
FI-WARE NGSI is mainly a binding document, so it would be a difficult task to see the differences just by comparison with the OMA specs.

Furthermore, if we want to go back to OMA with our NGSI version, we should stick to the OMA approach of distinguishing abstract interface definitions and binding. We would then submit (a) the RESTful binding, and possibly (b) change requests to the abstract specs.

Best
Tobias


From: Moltchanov Boris [mailto:boris.moltchanov at telecomitalia.it]
Sent: Dienstag, 29. Januar 2013 14:42
To: Tobias Jacobs; Fermín Galán Márquez
Cc: fiware-ngsi at lists.fi-ware.eu
Subject: RE: [Fiware-ngsi] Issues in the NGSI OMA spec

Tobias,

sorry I didn't answered nor commented your question where we may collect the "improvements" point for the OMA spec - cannot we do it just comparing resulting final FI-WARE NGSI spec and xsd against the original OMA's one? A sort of dif.

Please, if you update the FI-WARE NGSI spec and xsd, let us know republish the last version of the schemas.

Thanks.

Best Regards,
Boris

From: fiware-ngsi-bounces at lists.fi-ware.eu<mailto:fiware-ngsi-bounces at lists.fi-ware.eu> [mailto:fiware-ngsi-bounces at lists.fi-ware.eu] On Behalf Of Moltchanov Boris
Sent: Tuesday, January 29, 2013 2:36 PM
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] Issues in the NGSI OMA spec

Well, let's make it clear here.

The subscribed part (Broker) assigns the SID and provides it to the subscribed (client), if the client DON'T ask (allowed to do) its own purpose ID.

I hope the spec means that just in the first operation subCxtAv a client MAY assign its OWN subID and broker MIGHT say "I don't like it (busy or not compliant, etc., so use that one!", otherwise, the broker assigns it own SID.

The updateCxtAvSub is IMPOSSIBLE without a priory subscription (having and ID), independently who assigned the SID, the broker or the client.

And then:
The client MUST use that ID (assigned by whoever, the broker or the client itself) in further operations in order to handle the right subscription.

I understood the 4 points in the sequence in the first email below like that.

I hope we did a reasonable job and will change the spec where and if really correct and needed.

BR,
B

From: Tobias Jacobs [mailto:Tobias.Jacobs at neclab.eu]
Sent: Tuesday, January 29, 2013 1:35 PM
To: Moltchanov Boris; Fermín Galán Márquez
Cc: fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>; Martin Bauer; Salvatore Longo
Subject: RE: [Fiware-ngsi] Issues in the NGSI OMA spec

Hi all,

I agree with Fermin in all four points. The subscription ID should be issued by the component which receives the subscription request, not the subscriber. This is why it should not be specified in the original subscription, but should be mandatory in subscription updates and unsubscribe operations. Still this is just my personal opinions, and maybe the people who wrote the specs have a good reason for defining it like this.

In general, we should somewhere document where we deviate from the OMA specs, and also where we resolve ambiguities. Any idea where to do this? Maybe in the FI-WARE wiki?

Best regards
Tobias

From: fiware-ngsi-bounces at lists.fi-ware.eu<mailto:fiware-ngsi-bounces at lists.fi-ware.eu> [mailto:fiware-ngsi-bounces at lists.fi-ware.eu] On Behalf Of Moltchanov Boris
Sent: Dienstag, 29. Januar 2013 12:44
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] Issues in the NGSI OMA spec

Fermin,

the FI-WARE NGSI is NOT "legally" OMA NGSI as far as FI-WARE NGSI is NOT formally compliant with OMA NGSI, but BASED on that.

The OMA NGSI might have some "points to improve" as have been also specified in the OMA news release, where we highlighted this fact and this is where FI-WARE partners worked the FI-WARE NGSI out, spent their time and effort.

Therefore, if our FI-WARE NGSI differs from OMA NGSI, this is for purpose (I hope) and no legal obligations shall be respected. We, the same partners in FI-WARE and OMA have intention to bring our FI-WARE experience "making OMA NGSI ideas come truth" back to the OMA NGSI spec and maybe even its "reference" binding.

Welcome to FI-WARE NGSI :).

Best Regards,
Boris

From: Fermín Galán Márquez [mailto:fermin at tid.es]
Sent: Tuesday, January 29, 2013 12:36 PM
To: Moltchanov Boris
Cc: fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>
Subject: Re: [Fiware-ngsi] Issues in the NGSI OMA spec

Dear Boris,

"SubscriptionIDs are needed to point which subscriptions handle in the respective operations you've listed"

You are right, you need subscriptionID in the updateContextAvSub or unsusbscribeContextAv, but note that "Optional"is marked as "Yes" in the tables in the mentioned 5.3.4.1 and 5.3.5.1 section, so it would be legal according to OMA spec to have an updateContextAvSub or unsusbscribeContextAv without subscriptionID. This was the problem I'm trying to raise.

Best regards,

------
Fermín

El 29/01/2013 12:18, Moltchanov Boris escribió:
Hi Fermín,

I believe that the subscribeContextAvailability lets know to the subscribed part that the subscribed context is available. That is, simple as it is :). While updateContextAvSub is an update to prolong or shorten this subscription.

SubscriptionIDs are needed to point which subscriptions handle in the respective operations you've listed.

I'm not sure, therefore keep silence :), for the last case you've mentioned (blank).

There is the only spec you pointed of this Enabler in OMA. No evolutions, as far as no one, as far as know, fully implemented it and let it know to OMA. Thus, why for to evolve, if no usage. The FI-WARE is probably first exercise to do get it alive and hopefully our experience bad or good will be reported to OMA jointly with FI-WARE partners involved there and improving / evolving the NGSI Enabler spec - this was an intention of FI-WARE.

Best Regards,
Boris

From: fiware-ngsi-bounces at lists.fi-ware.eu<mailto:fiware-ngsi-bounces at lists.fi-ware.eu> [mailto:fiware-ngsi-bounces at lists.fi-ware.eu<mailto:ailto:fiware-ngsi-bounces at lists.fi-ware.eu>] On Behalf Of Fermin Galan Marquez
Sent: Tuesday, January 29, 2013 12:01 PM
To: fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>
Subject: [Fiware-ngsi] Issues in the NGSI OMA spec

Hi,

We have found some (apparent) typos in the NSGI OMA spec referred from FIWARE wiki pages (Candidate Version 1.0, August 3rd 2010) that we will like to expose to the group in order to know your opinion. Again, sorry if this has been already discussed previously to October 2012.

 *   Section 5.3.3.1: SubcriptionId is allowed in subscribeContextAvailability. What would be the purpose of this, taking into account that an updateContextAvailabilitySubscription operation is available? (In this sense, this is different from registerContext in 5.3.1.1, where it make sense to include RegistrationId for updates)
 *   Section 5.3.4.1: SubscriptionId shall be mandatory (otherwise, there is no way of knowing which subscription to update)
 *   Section 5.3.4.1: SubscriptionId shall be mandatory (otherwise, there is no way of knowing which subscription to cancel)
 *   Section 5.3.6.1: ErrorCode has a "blank" in Part Type and Optional cells
Moreover, this version of NGSI seems quite old (August 3rd 2010) and doesn't seem to be a final version (given that "Candidate" reads in the name). Do you know if there is any other more recent version, please?

Thanks!

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
Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.
[cid:00000000000000000000000000000003 at TI.Disclaimer]Rispetta l'ambiente. Non stampare questa mail se non è necessario.


________________________________

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/20130129/47c55d3a/attachment.html>