[Css-csts] URGENT: Discrepancy in the SFW regarding the NOTIFY invocation
Margherita.di.Giulio at esa.int
Margherita.di.Giulio at esa.int
Fri Feb 27 13:08:48 UTC 2015
Wolfgang, John,
I fully support your analysis and your proposal .
In case a future service really requires such piece of information, this
can always be introduced by extension ( as per your text).
Kind regards,
Margherita
From: Wolfgang Hell <Wolfgang_._Hell at t-online.de>
To: "CCSDS_CSTSWG (css-csts at mailman.ccsds.org)"
<css-csts at mailman.ccsds.org>,
Date: 27/02/2015 10:31
Subject: [Css-csts] URGENT: Discrepancy in the SFW regarding the
NOTIFY invocation
Sent by: css-csts-bounces at mailman.ccsds.org
Dear CSTS colleagues,
While trying to close all RIDs and other comments regarding the SFW,
John and I detected a discrepancy between some requirements in the main
part of the SFW document and the NOTIFY invocation type specification in
annex E. The SFW contained in some place requirements postulating that a
notification shall report the service that triggered the reported event.
Taking a look at the type specification, it turns out that this
information cannot be conveyed except if one would introduce a related
parameter either by changing the invocation type or by means of
extension. However, in general the reporting of the service is not
needed as the user can be safely assumed to know which service is being
used when the notification comes in. There might be the case that a
service has to send notifications that actually triggered due to other
services being used in which case one would need the extra parameter
identifying the service with which the notification is associated. It
turns out that not even the MD CSTS has such need. Therefore John and I
favor the following approach:
- Any requirement postulating that the service triggering an event is
reported in the notification are removed from the SFW.
- The type specifications associated with the NOTIFY invocation are left
alone, i.e. no additional parameter is introduced.
- Should at some point in the future the need arise to accommodate an
additional parameter reporting the service triggering the event, this
can be achieved by means of extension.
Given that we are proposing to remove an originally specified
capability, we are seeking the WG consent on this point. A reply at your
earliest convenience will be appreciated since John and I are trying to
wrap up the SFW asap.
Best regards,
Wolfgang
_______________________________________________
Css-csts mailing list
Css-csts at mailman.ccsds.org
http://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts
This message and any attachments are intended for the use of the addressee or addressees only.
The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its
content is not permitted.
If you received this message in error, please notify the sender and delete it from your system.
Emails can be altered and their integrity cannot be guaranteed by the sender.
Please consider the environment before printing this email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/css-csts/attachments/20150227/2a8518ac/attachment.html>
More information about the CSS-CSTS
mailing list