Please see in-line...
>1) OK - new schema will be checked and taken in if fine
>
>MW: Make sure you get the new one that was agreed last week
>(ftp://ftp.3gpp.org/tsg_sa/WG4_CODEC/TSGS4_36/Docs/S4-050641.zi
p). Additionally, the Schema in the FLUTE RFC is not valid >according to XML. 3GPP took the liberty of writing down what
>they thought the FLUTE FDT Schema 'ought' to be if it was
>modified to be valid XML, so I would suggest starting with that.
I have this, the DVB one and the original produced by Jani, Sami, Magnus and myself which went into the 3GPP CR. Don't worry, if there's a bug it will not be in the IETF! (Otherwise, I'll be looking for a sponsor to provide an edible hat :)
>2) Perhaps the whole EXT_FTI should be in the FEC-BB as it is
>more useful than just for FLUTE (see Toni's comments)
>
>MW: See my response to Toni's comment.
Yep, let's take that on the other thread.
>2a. OK providing FEC-BB preserves all the information
>specified (to be checked)
>
>MW: That was the intention.
My complete FEC-BB review is nigh...
>3) OK . However there are a couple of issues with FEC-BB...
>
>- FEC-BB §9.1 references the experimental FLUTE. Please remove
>this reference or change to a note "to be removed by the RFC editor"
>
>MW: It's just an informative reference to indicate that the
>algorithm is identical to the one previously specified in the
>Experimental RFC. Is this a problem ? We can remove it if you like.
Yep, this mustn't go into the standards track FEC-BB RFC. It's good as a note to be removed until all FLUTE, ALC, LCT, FEC-BB, FEC-basic are re-aligned
>- The improved (FEC-BB) wording doesn't take into account the
>improved integer version Vincent, Jani & Sami produced.
>(though it does remove the important note that the alg does
>not imply floating point arithmetic). This was all put in
>because of actual implementation experience and bugs so the
>integer stuff really does need mentioning. I guess using the
>integer algorithm (with improved wording if possible) is the
>best solution.
>
>MW: There isn't any non-integer arithmetic in the algorithm
>specified in the new FEC BB. The problem with the previous
>algorithm was that it had an actual real-valued variable
>'A_fraction' which was the multiplied by some integer and thus
>the integer implementation of this was not so clear. But this
>is removed now.
I take another look and bring it up again only if there need for something different.
>Can you point me at the other description that you refer to so
>I can better understand the difference ?
http://www.watersprings.org/pub/id/draft-peltotalo-rmt-bb-fec-supp-xor-pcm-rs-00.txt
>4) OK - but this relates to the definition of EXT_FTI. I think
>it should say in each instance "semantically equivalent to X
>as defined in the FEC-BB [REF]". Though I need to check that
>the FEC-BB does properly define these in this context...
>
>MW: Nothing to do with EXT-FTI, just the FDT. But yes, it
>should refer to the FEC BB just as you suggest. The FEC BB
>should indeed properly define these things and the FEC Schemes
>define the value ranges.
EXP FLUTE says "field X of FDT is sementically equivalent to field Y of EXT_FTI" in a number of places. This link needs preserving even though specific mention of FEC ID numbers can be pushed elsewhere (FEC-BB or FEC-basic, etc.).
Cheers, Rod.
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.