Subject: [Rmt] LCT BB 01 -- 02 changes: ALC PI 03 -- 04 changes : FEC BB 04 -- 05 changes

From: "Michael Luby" <[email-masked]>
Date: Wed, 21 Nov 2001 16:39:05 -0800

RMTers,
There were three updated drafts submitted to the RMT working group today:
LCT BB ver 02, ALC PI ver 04 and FEC BB ver 05.  These are all small updates
of the versions submitted a couple of weeks ago, and reflect some comments
from the group (primarily Vincent Roca) that were received shortly after the
previous drafts were published.  Below is a list of the changes.
Mike

----------------------------------------------------------------------------
----------------------------------
LCT BB changes 02 --> 03

(1) Header extension EXT_AUTH is now associated to value 1, not 2.

(2) Fixed a couple of typos.

(3) Added a paragraph in Section 2 at the end that says

"This document does not specify and restrict the type of exchanges between
LCT (or any PI built on top of LCT) and an upper application.
Some upper APIs may use an object-oriented approach, where the
only possible unit of data exchanged between LCT (or any PI built on
top of LCT) and an application, either at a source or at a receiver,
is an object.
Other APIs may enable a sending or receiving application to
exchange a subset of an object with LCT (or any PI built on top of
LCT), or may even follow a streaming model.
These considerations are out of the scope of this document."

(Note: the grammar in this language will be cleaned up when this is
published as an RFC.)
----------------------------------------------------------------------------
----------------------------------
ALC PI changes 03 --> 04

(1) Fixed a typo

----------------------------------------------------------------------------
----------------------------------
FEC BB changes 04 --> 05

(1) Fixed a couple of typos

(2) Section 2.2: changed "source block length is at most 65536 bytes" to
"source block length is at most 65536 source symbols" (this was a typo that
was significant).

(3) Section 2.2: Now uses the more precise terminology "encoding symbols"
(instead of just symbols).

(4) Section 2.2: Made it explicit that all encoding symbols (source symbols
and redundant symbols) are the same length for the FEC Encoding ID defined
in this section.  Made it explicit that if the application wants to use a
source block that is not an integral number of source symbols in length, the
convention for padding this out to a source block that is an integral number
of source symbols in length is left up to the application and is outside the
scope of this document.  Thus, all source blocks with this FEC Encoding ID
that are encoded are an integral number of source symbols in length.

(5) Section 2.2: Made it clear that the reason given for communicating the
maximum number of encoding symbols in a block is only an example.

(6) Section 2.1 and 2.2: Made it explicit that the FEC Object Transmission
Info does not have to be contained in an explicit list passed to receivers,
there are other methods and examples are given (but only examples).  How
this is passed to receivers is out of the scope of this document.

_______________________________________________
Rmt mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rmt