<font size=2 face="sans-serif">Dear Wolfgang and John,</font>
<br><font size=2 face="sans-serif">I fully agree with your approach. The
context of the notification should be clear without an additional service
parameter.</font>
<br>
<br><font size=2 face="sans-serif">Kind regards,</font>
<br><font size=2 face="sans-serif">Holger</font>
<br>
<br><font size=2 face="sans-serif">Holger Dreihahn<br>
European Spacecraft Operations Centre | European Space Agency | S-431<br>
+49 6151 90 2233 | </font><a href=http://www.esa.int/esoc><font size=2 face="sans-serif">http://www.esa.int/esoc</font></a>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">Wolfgang Hell <Wolfgang_._Hell@t-online.de></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">"CCSDS_CSTSWG
(css-csts@mailman.ccsds.org)" <css-csts@mailman.ccsds.org>,
</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">27/02/2015 10:31</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">[Css-csts] URGENT:
Discrepancy in the SFW regarding the NOTIFY invocation</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Sent by:
</font><font size=1 face="sans-serif">css-csts-bounces@mailman.ccsds.org</font>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>Dear CSTS colleagues,<br>
<br>
While trying to close all RIDs and other comments regarding the SFW, <br>
John and I detected a discrepancy between some requirements in the main
<br>
part of the SFW document and the NOTIFY invocation type specification in
<br>
annex E. The SFW contained in some place requirements postulating that
a <br>
notification shall report the service that triggered the reported event.
<br>
Taking a look at the type specification, it turns out that this <br>
information cannot be conveyed except if one would introduce a related
<br>
parameter either by changing the invocation type or by means of <br>
extension. However, in general the reporting of the service is not <br>
needed as the user can be safely assumed to know which service is being
<br>
used when the notification comes in. There might be the case that a <br>
service has to send notifications that actually triggered due to other
<br>
services being used in which case one would need the extra parameter <br>
identifying the service with which the notification is associated. It <br>
turns out that not even the MD CSTS has such need. Therefore John and I
<br>
favor the following approach:<br>
<br>
- Any requirement postulating that the service triggering an event is <br>
reported in the notification are removed from the SFW.<br>
- The type specifications associated with the NOTIFY invocation are left
<br>
alone, i.e. no additional parameter is introduced.<br>
- Should at some point in the future the need arise to accommodate an <br>
additional parameter reporting the service triggering the event, this <br>
can be achieved by means of extension.<br>
<br>
Given that we are proposing to remove an originally specified <br>
capability, we are seeking the WG consent on this point. A reply at your
<br>
earliest convenience will be appreciated since John and I are trying to
<br>
wrap up the SFW asap.<br>
<br>
Best regards,<br>
Wolfgang<br>
<br>
_______________________________________________<br>
Css-csts mailing list<br>
Css-csts@mailman.ccsds.org<br>
</font></tt><a href="http://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts"><tt><font size=2>http://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts</font></tt></a><tt><font size=2><br>
</font></tt>
<br><PRE>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.
</PRE>