[NUT-devel] [RFC] internet draft for NUT

[Ivo]

Hi,

Here are some things I noticed:

On Tuesday 25 September 2007 10:54, Luca Barbato wrote:
[..]
> 1.1.  Terminology
>
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>    document are to be interpreted as described in [RFC2119].
>
>    This document refers to the following definitions

definitions:

[..]
>    frame  Minimal unit of information that can be decoded completely, it
>       is usually holds a full frame video frame, a group of audio
>       samples or a subtitle line.

it [-is] usually holds

Also, I know what a frame is, but the description is a bit confusing. It 
says it's a minimal unit that can be decoded completely, but below it says 
you can only start decoding at a keyframe. So you can only decode a given 
frame/unit completely if it's either a keyframe or you have decoded 
previous (in dts sense) frames which the current frame depends on. 

>    Keyframe  A keyframe is a frame from which you can start decoding.
>       The nth frame is a keyframe if and only if frames n, n+1, ... in
>       presentation order (that are all frames with a pts >=
>       frame[n].pts) can be decoded successfully without reference to
>       frames prior n in storage order (that are all frames with a dts <
>       frame[n].dts).  If no such frames exist (for example due to using
>       overlapped transforms like the MDCT in an audio codec), then the
>       definition shall be extended by dropping n out of the set of
>       frames which must be decodable, if this is still insufficient then
>       n+1 shall be dropped, and so on until there is a keyframe.  Every
>       frame which is marked as a keyframe MUST be a keyframe according
>       to the definition above, a muxer MUST mark every frame it knows is
>       a keyframe as such, a muxer SHOULD NOT analyze future frames to
>       determine the keyframe status of the current frame but instead
>       just set the frame as non-keyframe.

IMHO the last comma should be replaced by 'and' (i.e. so it says: A, B and 
C) or the sentence could be split up in three sentences.

> 1.2.  Syntax Convetions
>
>    Since NUT heavily uses variable length fields, the simplest way to
>    describe it is using a pseudocode approach instead of graphical
>    bitfield descriptions.
>
>    The syntax uses datatypes, tagnames and C-like constructs.
>
> 1.2.1.  Datatypes
>
>    f(n)  n fixed bits in bigendian order

big-endian

>    u(n)  Unsigned value encoded in n bits MSB-first
>
>    v  Unsigned variable length value.
>
>      value=0
>      do{
>          more_data                       u(1)
>          data                            u(7)
>          value= 128*value + data
>      }while(more_data)

I'd prefer spaces between do and { and } and while, but I suppose that's a 
matter of personal taste. Same for value = instead of value=.

>                    Figure 1: Variable Length Unsigned Value
>
>       Values can be encoded using the following logic: the data is in
>       network order, every byte has the most significant bit used as
>       flag and the following 7 used to store the value.  The first N bit

bits

>       are to be taken, where N is number of bits representing the value
>       modulo 7, and stored in the first byte.  If there are more bits,
>       the flag bit is set to 1 and the subsequent 7bit are stored in the

7 bits

>       following byte, if there are remaining bits set the flag to 1 and
>       the same procedure is repeated.  The ending byte has the flag bit
>       set to 0.

I find this description a bit confusing, e.g. it's not clear when you talk 
about the input value and when about the output bytes.

[..]
>       Strings and binary data can be encoded basically writing the byte
>       count as a Variable Length Unsigned Value and the the string.  The

and then the

>       strings MUST be encoded in utf-8
>
>    t  Variable length binary data (or utf-8 string).

wrong description

>        tmp                                 v
>        id= tmp % time_base_count
>        value= (tmp / time_base_count) * time_base[id]
>
>                      Figure 4: Variable Length Timestamp

--Ivo