Re: [Cellar] draft-ietf-cellar-ffv1-13 comments

["Murray S. Kucherawy" <[e-mail]>]

On Wed, Apr 29, 2020 at 1:48 PM Jerome Martinez <[e-mail]>
wrote:

> Section 3.8.2.1.3:
> * Same issue about "value".
>
> Murray, I didn't get it (no comma there)
>

Sorry, disregard.  This referred to an issue I had with an earlier section
but I changed my mind, and deleted that one but forgot to delete this one.


> Section 4.2.3.1:
> * "AVI " should be just "AVI" (i.e., remove the trailing space)
>
> Murray, the "trailing" space is required. It is a part of a 4-letter
> identifier found in AVI files (0x41564920 in hexadecimal).
>
Interesting.  You might want to make that clear, because I expect the RFC
Editor will have exactly the same question.


> Section 4.6:
> * Another table with an empty "type" column.  I think I see now that the
> column is populated against each line that outputs something, but can it
> not just be omitted when there's no output to the function?
>
> Same as with other tables.
>
>
> * But does this function really output nothing?
>
> Murray, not sure I understand the question.
> This function read nothing from the input, and call Line() which calls
> Pixel().
> It is in a standalone pseudo-code block for an having blocks easy to
> understand (SliceHeader(), SliceContent(), SliceHeader()).
> SliceContent() could move into Slice() but IMO it is less readable.
>

This goes back to not understanding how to interpret these these "type"
columns.  But also, this is another place where a forward reference to
Line() would be helpful.  And then down in Line(), there are lines of
pseudo-code that appear to be standalone array references.  In the table in
Section 4.1, those lines have types, which I thought means there's some
output happening.  Is that not the case here?  If not, then this is a
nested set f function calls that do some computation but don't appear to
yield anything.  That's why I'm confused here.

Sections 4.6.1 through 4.6.4:
> * Same comment as before about inline formulae.
>
> Fixed.
> But it means that all is in one chapter, IMO it is a lot of formulae.
>
You don't have to put them all in one chapter.   I was thinking of just
this for 4.6.1, for example:

"primary_color_count" is defined as:

    1 + ( chroma_planes ? 2 : 0 ) + ( extra_plane ? 1 : 0 )

That even parses in C. :-)

-MSK