hi all, lu wants me to help on drafting and formatting the rfc, and i think this is a good thing. so i started looking at it and have some ideas for changes to make, but i don't want to step on any feet.. abstract: this should mention the codec-agnosticism and ability to perform container-level operations without any awareness of the data format, since these aspects are probably the most novel from a multimedia standards perspective. i want to add the text "without regard for the specific formats of the streams, and" before "with minimal computational cost" and perhaps work more on improving the content of the abstract. definitions: the definition of pts is somewhat confusing in relation to b frames and out of order decoding. can we do something about "completed by decoding the coded frame" to make it more clear? the definition of dts is rather vague... frame: i had a good formal definition the other day but can't remember at the moment... keyframe: rewording for clarity and formal english: A keyframe is a frame in a stream at which decoding of that stream can successfully begin independent of prior frames. Keyframe status of frames within one stream is independent of any other streams. Assign to each frame in a stream an integer position n. The nth frame of a stream is a keyframe if and only if the mth frame, for each m≥n+k, can be decoded successfully without reference to data contained in the lth frame for any l<n, where k is the smallest nonnegative integer such that keyframes other than the initial frame can exist in the stream's coding scheme. This definition coincides with the ordinary notion of a keyframe for common video coding schemes where k=0, and also allows for overlapped-window audio coding schemes where k≥1 accounts for the missing overlap from the previous frame. Readers should be aware that this definition of keyframe is dependent on the ordering of frames according to pts and dts as mandated by this standard. data types: strings: the requirement that strings not contain U+0000 is mysteriously missing. also, i would like to change the terminology from "string" to "text" to align mostly with the posix sense of text (i.e. bytes must represent characters and must not contain 0). string is somewhat less precise imo because to some people binary data (or binary data without embedded 0's) is a "string" but not "text". also then we could move the requirements of text to a "definition of text" under the definitions section, which i think would be nice organizationally speaking. finally, lu thought this was okay but i'd like to run it by others: can i commit changes like these directly to the rfc xml file? the intent would not be to impose my wishes on others, but rather to accelerate completion of the document. i would certainly welcome others to revert or heavily alter anything objectionable and start discussions on the list as appropriate, but i feel now that we're to the stage of documenting the format we already designed rather than designing it, the types of potential objections are very different and much less severe and we always have the authoritative nut.txt to go back to. if anyone else has differing or better ideas on how to work on the rfc i'd be happy to hear them too. rich