[Sis-dtn] New text for 4.4.7 and 4.4.8 in the attached.

[Keith Scott]

I think 4.4.8 is garbage.  It's not referenced from anywhere.

I redid 4.4.7 and suggest renaming it to Send.indication since it's the
indication returned by a Send.request (or we could rename Send.request to
BundleSend.request, I suppose).

Text of updated 4.4.7 (also in attached)

1.1.1      Send.indication[KS1] <#_msocom_1>  1.1.1.1      Function

The Send.indication primitive shall be used to provide information to a
sending application about a bundle that the application caused to be
created via a previous Send.request . Since the indication is a ‘bundle
ID’, which contains the source EID and the bundle creation timestamp, it
may not be generated immediately after the Send.request is received if the
bundle implementation delays generating a bundle from the request[KS2]
<#_msocom_2> .  If the generation of the Send.indication is asynchronous
with respect to the Send.request, some implementation-specific mechanism to
associate the indication with the request that triggered it would be
necessary.  Such implementation-specific mechanisms are beyond the scope of
this book.
1.1.1.2      Semantics

Send.indication shall provide parameters as follows:

Send.indication               (bundle ID)
1.1.1.3      When Generated

Send.indication shall be generated by a BP agent upon creation of a bundle
in response to a Send.request primitive by the application.
1.1.1.4      Effect on Receipt

The effect on receipt is defined by the application.
1.1.1.5      Discussion—Additional Comments

None.
------------------------------

 [KS1] <#_msoanchor_1>I suggest renaming this to Send.indication to better
associate it with the Send.request.

 [KS2] <#_msoanchor_2>So what this means is that, depending on the
implementation, this indication could be received synchronously as a result
of a send.request (e.g. the send.request could contain a bundle_ID* that
gets filled in before the request returns) or it might be generated later
and returned asynchronously.  If the latter then there would need to be
some implementation-specific way to associate the Send.indication with the
corresponding Send.request that is out of scope of this document.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20250220/8b255316/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Updated 4.4.7 and 4.4.8.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 224032 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20250220/8b255316/attachment-0001.docx>