[Css-csts] A few more comments on the Framework
Yves.Doat at esa.int
Yves.Doat at esa.int
Tue Aug 18 04:50:07 EDT 2009
Dear John,
Thanks for your comments.
Please find below the answers to each of them.
Section 3.9.2 heading should be just INVOCATION AND PARAMETERS for
TRANSFER-DATA.
>>YD: Corrected.
Section 3.11.2 heading should be just INVOCATION AND PARAMETERS for
NOTIFY.
>>YD: Corrected.
D1.12, “nextension” should be “extension”.
>>YD: Corrected
In D2.5, “startDiagnosticnExt” should be “startDiagnosticsExt” in the
assignment of the OID for startDiagnosticsExt.
NOTE ? for the other operation extensions, the names are of the form
“…DiagnosticExt”, that is, there is no “s” between “Diagnostic” and “Ext”.
Perhaps the same should apply to the START operation.
>>YD: Corrected to startDiagnosticExt
In section 4.5.3.1.1, the sentence should read “Table 4?9 shows the [use
of the ?] extension parameters of the START operation defined by this
procedure.” (see below for comment on “use of the”.
>>YD: Corrected
Inconsistent title for sections that specify extensions of
notification-type. The variations are “Extension notification-types
values”, “Extension notification-type”, and “Notification-type extension”.
What should it be?
>>YD: I changed it to "Extension notification-type".
The various specifications of extension parameters for operations use the
phrasing “Table XXX shows the use of the extension parameters of the YYY
operation defined by this procedure.” I think “use of the” was okay when
we had the extension-parameters as an explicit parameter in the tables,
but since we’ve decided that the extension mechanism is an artifact of
ASN.1, I think these sentences should be of the form “Table XXX shows the
extension parameters of the YYY operation defined by this procedure.”
>>YD: Changed as proposed.
In the ASN.1, dpStartInvocExt, dpProcessDataNegReturnExt,
dpNotifyInvocNotifTypeExt, dpNotifyInvocExt, and
dpExecDirInvocDirectiveIdExt, all have the same OID:
{dpExtProcedureParam 1}.
>>YD: Changed as follows:
dpStartInvocExt OBJECT IDENTIFIER ::=
{dpExtProcedureParam 1}
dpProcessDataNegReturnExt OBJECT IDENTIFIER ::= {dpExtProcedureParam 2}
dpNotifyInvocNotifTypeExt OBJECT IDENTIFIER ::= {dpExtProcedureParam 3}
dpNotifyInvocExt OBJECT IDENTIFIER ::=
{dpExtProcedureParam 4}
dpExecDirInvocDirectiveIdExt OBJECT IDENTIFIER ::=
{dpExtProcedureParam 5}
The values are now aligned with the OID tree at the end of the document.
The names of some of the extension object types are very similar to the
names of their associated object identifiers (e.g., StartDiagnosticsExt
for the object type name, startDiagnosticsExt for the associated OID
name), whereas others have greater differences (e.g.,
ExecDirectiveINegReturnDiagnosticsExt for the object type name, vs.
teExecDirDiagnosticsExt for the associated OID name). These name pairs are
recognizable by humans as referring to the same thing, especially because
the OID appears right after the object specification in the ASN.1.
However, it might be much more difficult to make the connection if they
weren’t listed one after the other. Is there any reason not to use the
same name for both, differing only in the first letter (upper case for
object type name, lower case for OID name)?
>>YD: Here is the list of types and associated OID:
AssocBindPosReturnExt acBindPosReturnExt
AssocBindNegResultDiagnosticExt acBindDiagnosticExt
ExecDirectiveNegAckDiagnosticEx t execDirAckDiagnosticExt
ExecDirectiveNegReturnDiagnosticExt
execDirReturnDiagnosticExt
GetPosReturnExt getPosReturnExt
GetDiagnosticExt getDiagnosticExt
ProcessDataPosReturnExt procDataPosReturnExt
ProcessDataDiagnosticExt procDataDiagnosticExt
ProcessDataNegReturnExt procDataNegReturnExt
StartDiagnosticsExt startDiagnosticExt
BuffDataDelStartPosInvocExt bddStartInvocExt
BuffDataDelStartDiagnosticsExt bddStartDiagExt
BuffDataDelNotificationInvocTypeExt bddNotifInvocTypeExt
CyclicReportStartInvocExt crStartInvocExt
CyclicReportDiagnosticsExt crNegStartReturnExt
CyclicReportTransferDataExt
crTransferDataInvocDataExt
ExecuteDirectiveNegReturnDiagnosticsExt
teExecDirDiagnosticsExt
DataProcessingStartInvocExt dpStartInvocExt
DataProcessingProcessDataNegReturnExt
dpProcessDataNegReturnExt
DataProcessingNotifyInvocNotificationTypeExt
dpNotifyInvocNotifTypeExt
DataProcessingNotifyInvocExt dpNotifyInvocExt
DataProcessingExecDirectiveInvocationDirectiveIdExt
dpExecDirInvocDirectiveIdExt
NotificationStartInvocExt nStartInvocExt
NotificationNegStartReturnExt nNegStartReturnExt
NotificationTypeExt nTypeExt
Looking at all cases you will note that the OID names are very much
shortened compared to the names of the corresponding types.
In case of operations, the operation names abbreviation is considered (not
in a systematic way, I agree)
In case of procedures, the names always starts with the first letters of
the procedure.
The main reason to shorten the name is that I wanted them to fit in the
tree at the end of the document.
In case you feel it's a problem please let me know a more acceptable
scheme and I will adapt the tree if necessary.
.
The NotificationTypes type concludes with the notificationExtension. Some
of the notification-type extension objects also conclude with
notificationExtension, but some conclude with extensionNotification. These
should all be notificationExtension, or perhaps even
notificationTypeExtension.
>>YD: I could not find the identifier extensionNotification. I changed
all identifiers to notificationTypeExtension.
Best regards
Yves
More information about the Css-csts
mailing list