Re: [auth48] AUTH48: RFC-to-be 9559 <draft-ietf-cellar-matroska-21> for your review

[[e-mail]]

Authors,

While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.


1) <!-- [rfced] We added "Updates: 8794" to the document header per the text in
the Abstract and Section 4.2. Please let us know any concerns.
-->


2) <!-- [rfced] Should "Specifications" (plural) in the document title be updated
to "Specification" (singular)? Or is the current correct?

Original:
  Matroska Media Container Format Specifications

Perhaps: 
  Matroska Media Container Format Specification
-->


3) <!-- [rfced] How may we clarify "a form of Segment linking with other
Segments"?

Original: 
In the rare case it doesn't, there should be a form of Segment
linking with other Segments, possibly using Chapters, see Section 17.

Perhaps: 
In the rare case it doesn't, there should be a method for Segments
to link together, possibly using Chapters; see Section 17.
-->


4) <!-- [rfced] May we update "the title it was released as in Germany" in one of
the following ways to improve readability?

Original:
   For example, a movie's "title" Tag might contain both the original
   English title as well as the title it was released as in Germany.

Perhaps:
   For example, a movie's "title" Tag might contain both the original
   English title as well as the German title.

Or:
   For example, a movie's "title" Tag might contain both the original
   English title as well as the title used when it was released in Germany.
-->


5) <!-- [rfced] We are having trouble understanding the second sentence below. Is
it redundant with the first sentence? Should it be either deleted or rephrased?

Original:
   This specification includes an EBML Schema, which defines the
   Elements and structure of Matroska using the EBML Schema elements and
   attributes defined in Section 11.1 of [RFC8794].  The EBML Schema
   defines every valid Matroska element in a manner defined by the EBML
   specification.

Perhaps (delete second sentence):
   This specification includes an EBML Schema that defines the
   Elements and structure of Matroska using the EBML Schema elements and
   attributes defined in Section 11.1 of [RFC8794].

Or (rephrase second sentence):
   This specification includes an EBML Schema that defines the
   Elements and structure of Matroska using the EBML Schema elements and
   attributes defined in Section 11.1 of [RFC8794].  The EBML Schema in this document
   defines every valid Matroska element in a manner defined by the EBML
   specification [RFC8794].
-->


6) <!-- [rfced] FYI - To make the definition lists in Section 5.1 consistent
(especially when definitions appear after a table), we moved the tables out
of the definition lists.
-->


7) <!-- [rfced] The following sections include paragraphs that are not part of
the <dl>. Should these paragraphs be nested under "definition:"?

5.1.3.5.5
5.1.4.1.28.44
5.1.4.1.28.45
5.1.4.1.28.46
-->


8) <!-- [rfced] Does "they" refer to "Chapter Codec" in these sentences? If so,
we will updated "Chapter Codec" to "Chapter Codecs".

Original:
   rationale:  Chapter Codec may need to address different segments, but
      they may not know of the way to identify such segment when stored
      in Matroska.

   rationale:  Chapter Codec may need to address content in specific
      track, but they may not know of the way to identify tracks in
      Matroska.  

Perhaps:
   rationale:  Chapter Codecs may need to address different segments, but
      they may not know of the way to identify such segments when stored
      in Matroska.

   rationale:  Chapter Codecs may need to address content in specific
      track, but they may not know of the way to identify tracks in
      Matroska.  
-->


9) <!-- [rfced] Will readers know what "libmatroska" is? Would a citation be
helpful or is the current okay?

Original:
   definition:  Muxing application or library (example: "libmatroska-
      0.4.3").
   ...
   definition:  Bogus StereoMode value used in old versions of
      libmatroska.
   ...
   usage notes:  This Element MUST NOT be used.  It was an incorrect
      value used in libmatroska up to 0.9.0.
   ...
   There was also a bug in libmatroska
   prior to 0.9.0 that would save/read it as 0x53B9 instead of 0x53B8;
   see OldStereoMode (Section 5.1.4.1.28.5).  
-->


10) <!-- [rfced] Will readers understand "the main one" here? 

Original: 
   definition:  Contain additional binary data to complete the main one;
      see Codec BlockAdditions section of [MatroskaCodec] for more
      information.  

Perhaps: 
   definition:  Contain additional binary data to complete the Block element;
      see Section 4.1.5 of [MatroskaCodec] for more
      information.  
-->


11) <!-- [rfced] Section 5.1.3.5.2.3 ("BlockAddID Element") has two "usage
notes". Would you like to combine these or leave as is?

Original:
   usage notes:  Each BlockAddID value MUST be unique between all
      BlockMore elements found in a BlockAdditions.
   usage notes:  To keep MaxBlockAdditionID as low as possible, small
      values SHOULD be used.

Perhaps:
   usage notes:  Each BlockAddID value MUST be unique between all
      BlockMore elements found in a BlockAdditions. To keep MaxBlockAdditionID
      as low as possible, small values SHOULD be used.
-->


12) <!-- [rfced] Please review "the meaning of the BlockAdditional data" in the
following sentences. Will this be clear?

Original: 
A value of 1 indicates that the meaning of the BlockAdditional data
is defined by the codec.  Any other value indicates the meaning of the
BlockAdditional data is found in the BlockAddIDType found in the TrackEntry.

Perhaps: 
A value of 1 indicates that the BlockAdditional data is defined by
the codec. Any other value indicates that the BlockAdditional data should be handled according
to the BlockAddIDType that is located in the TrackEntry.
-->


13) <!-- [rfced] For elements containing "see implementation notes", would it be
helpful to direct the reader to the corresponding table? Or is the
current okay? Here is one example:

Original (BlockDuration Element):
  minOccurs / maxOccurs:  see implementation notes / 1

Perhaps (BlockDuration Element):
  minOccurs / maxOccurs:  see Table 2 / 1 -->


14) <!-- [rfced] How may we clarity "When not written and with no DefaultDuration"?

Original:
When not written and with no DefaultDuration, the value is assumed to be the       
difference between the timestamp of this Block and the timestamp of the next Block in "display"     
order (not coding order).

Perhaps:
If a value is not specified and no DefaultDuration is present, the value is assumed to be the       
difference between the timestamp of this Block and the timestamp of the next Block in "display"     
order (not coding order).
-->


15) <!-- [rfced] How may we rephrase the part of this sentence starting with "but
without..." for clarity?

Original: 
The value "0" MAY also be used to signify this Block cannot be
decoded on its own, but without knownledge of which Block is necessary.

Perhaps: 
The value "0" MAY also be used to signify that this Block cannot be
decoded on its own but the necessary Block is unknown.
-->


16) <!-- [rfced] May we rephrase the following in Table 3 (last column)?

Original:
A mix of different other TrackType.

Perhaps:
A mix of other TrackType Elements.
-->


17) <!-- [rfced] Should "subs" here be updated to "subtitle"?

Original:
   definition:  Set if that track (audio, video or subs) is eligible for
      automatic selection by the player; see Section 19 for more
      details.
-->


18) <!-- [rfced] For the definitions of "FlagDefault Element" and "FlagForced
Element", should the following sentences be rephrased to clarify the
values that should be set? We note that surrounding elements use the
phrase "Set to 1..." consistently.

Original: 
  Set if that track (audio, video or subs) is eligible for automatic
  selection by the player; see Section 19 for more details.
  ...
  Set if that
  track is eligible for automatic selection by the player if it matches the
  user's language preference...

Perhaps: 
  Set to 1 if the track (audio, video, or subs) is eligible for
  automatic selection by the player; see Section 19 for more details.  
  ...  
  Set to 1 if the track is eligible for automatic selection by the player if it
  matches the user's language preference...
-->


19) <!-- [rfced] Would updating "This TrackTranslate applies" in one of the
following ways improve readability and maintain consistency with other
definition??

Original:
   definition:  This TrackTranslate applies to this chapter codec of the
      given chapter edition(s); see Section 5.1.7.1.4.15.

Perhaps: 
   definition:  Applies to the chapter codec of the
      given chapter edition(s); see Section 5.1.7.1.4.15.

Or:
   definition:  Indicates that this TrackTranslate applies to the chapter codec of the
      given chapter edition(s); see Section 5.1.7.1.4.15.
-->


20) <!-- [rfced] Please clarify the parenthetical in the second sentence below,
i.e., "(considered either as 0 or 1)". Also, we updated "by to" to "by"
in the first sentence. Please review.

Original:
   definition:  Indicate whether the BlockAdditional Element with
      BlockAddID of "1" contains Alpha data as defined by to the Codec
      Mapping for the CodecID.  Undefined values SHOULD NOT be used, as
      the behavior of known implementations is different (considered
      either as 0 or 1).
      
Perhaps: 
   definition:  Indicates whether the BlockAdditional Element with
      BlockAddID of "1" contains Alpha data as defined by the Codec
      Mapping for the CodecID.  Undefined values (i.e., values other than
      0 or 1) SHOULD NOT be used, as the behavior of known implementations
      is different.
-->


21) <!-- [rfced] We updated this sentence as follows. Please review and let us
know any concerns.

Original: 
Used to render spherical, VR videos or flipping videos
horizontally/vertically.

Updated:
Used to render spherical or VR videos or to flip videos horizontally
or vertically.
-->


22) <!-- [rfced] Please review "both included" in Sections 5.1.4.1.28.44 through
5.1.4.1.28.46. Is the meaning here "inclusive"?
     
Original: 
The value of this element MUST be in the -180 to 180 degree range,
both included.
...
The value of this element MUST be in the -90 to 90 degree range, both
included.
...
The value of this element MUST be in the -180 to 180 degree range, both
included. 

Perhaps: 
The value of this element MUST be in the -180 to 180 (inclusive) degree range.
...
The value of this element MUST be in the -90 to 90 (inclusive) degree range.
...
The value of this element MUST be in the -180 to 180 (inclusive) degree range.
-->


23) <!-- [rfced] May we rephrase the first sentence of this definition as follows
for clarity?

Original: 
Tell in which order to apply each ContentEncoding of the
ContentEncodings.

Perhaps: 
Defines the order to apply to each ContentEncoding of the ContentEncodings.
-->


24) <!-- [rfced] Please review "as possible" here. Is this phrase needed? If it is
needed, should it be updated to "if possible"?
     
Original: 
A Matroska Reader MAY support methods "1" and "2" as possible, and
SHOULD support other methods.

Perhaps (deleted "as possible"):
A Matroska Reader MAY support methods "1" and "2" and
SHOULD support other methods.

Or (use "if possible"):
A Matroska Reader MAY support methods "1" and "2" if possible and
SHOULD support other methods.
-->


25) <!-- [rfced] Please clarify "Timestamp of the end of Chapter timestamp
excluded".

Original:
   definition:  Timestamp of the end of Chapter timestamp excluded,
      expressed in Matroska Ticks - i.e., in nanoseconds; see
      Section 11.1.
-->


26) <!-- [rfced] How may we rephrase the parenthetical in the following sentence for
clarity?

Original: 
Hidden chapters SHOULD NOT be available to the user interface (but
still to Control Tracks; see Section 20.2.5 on Chapter flags).

Perhaps: 
Hidden chapters SHOULD NOT be available to the user interface (but
still be available to Control Tracks); see Section 20.2.5 on Chapter flags.
-->


27) <!-- [rfced] We have two questions about the definition below:

a) Does "to be defined" need further clarification, perhaps "to be defined in
future specifications"?

b) Section 20.3 defines value 0 as "matroska script" and value 1 as "menu
borrowed from the DVD [DVD-Video]". Should the definitions match? Or is the
current okay?

Original:
   definition:  Contains the type of the codec used for the processing.
      A value of 0 means built-in Matroska processing (to be defined), a
      value of 1 means the DVD command set is used; see Section 20.3 on
      DVD menus.
-->


28) <!-- [rfced] Please clarify "with a property: stream copy: True when".

Original:
   An Element is marked with a property: stream copy: True when the
   values of that Element need to be kept identical between the source
   and destination file.
   
Perhaps: 
   An Element is marked with the property "stream copy: True" when the
   values of that Element need to be kept identical between the source
   and destination files.  
-->


29) <!-- [rfced] Is "on up to" correct here?

Original:
   The value can be coded on up to 8 octets.

Perhaps:
   The value can be coded up to 8 octets.
-->


30) <!-- [rfced] Please clarify "The following data" in these similar
sentences. Is the intended meaning "The remaining data", or something
else? Would a pointer to Section 10.3 be helpful?

Original: 
   The following data in the Block correspond to the lacing data and
   frames usage as described in each respective lacing mode.
   ...
   The following data in the SimpleBlock correspond to the lacing data
   and frames usage as described in each respective lacing mode.

Perhaps:
   The remaining data in the Block corresponds to the lacing data and
   frames usage as described in each respective lacing mode (see Section 10.3).
   ...
   The remaining data in the SimpleBlock corresponds to the lacing data
   and frames usage as described in each respective lacing mode (see Section 10.3).
-->    


31) <!-- [rfced] We have two questions about the sentences below.

a) Please confirm that "bits 5 and 6" and "bits 5-6" are correct in the text
below. Or should this be "bits 6-7" per Figures 11-14? Or possibly just "The
LACING bits"?

b) The sentences below have "0b00", "0b01", "0b11", and "0b10", but Sections
10.1 and 10.2 have "00b", "01b", "11b", and "10b" for the LACING bits. Please
review and let us know if any updates are needed.
      
Original:
   When lacing is not used, i.e. to store a single frame, the lacing
   bits 5 and 6 of the Block or SimpleBlock MUST be set to zero.

   The bits 5-6 of the Block Header flags are set to 0b00.

   The bits 5-6 of the Block Header flags are set to 0b01.

   The bits 5-6 of the Block Header flags are set to 0b11.

   The bits 5-6 of the Block Header flags are set to 0b10.

Perhaps:
   When lacing is not used, i.e. to store a single frame, the lacing
   bits 6 and 7 of the Block or SimpleBlock MUST be set to zero.

   Bits 6-7 of the Block Header flags are set to 00b.

   Bits 6-7 of the Block Header flags are set to 01b.

   Bits 6-7 of the Block Header flags are set to 11b.

   Bits 6-7 of the Block Header flags are set to 10b.

Or:
   When lacing is not used, i.e. to store a single frame, the lacing
   bits (bits 6 and 7) of the Block or SimpleBlock MUST be set to zero.

   The LACING bits of the Block Header flags are set to 00b.

   The LACING bits of the Block Header flags are set to 01b.

   The LACING bits of the Block Header flags are set to 11b.

   The LACING bits of the Block Header flags are set to 10b.
-->


32) <!-- [rfced] We updated "these data" to "frames". Please let us know any
objections.

Original: 
As these data are small, they can be stored in a lace to save space.

Current:
Because these frames are small, they can be stored in a lace to save space.
-->


33) <!-- [rfced] Will readers understand the following? Note that this text
appears in three locations in the document.

Original: 
* Lacing Head on 1 Octet: Number of frames in the lace minus 1.
-->


34) <!-- [rfced] Is RAP read as "rap" or "R-A-P"? We ask for guidance in order to
choose the appropriate indefinite article for it to follow (i.e., a or
an). We see both "an RAP" and "a RAP" in the document.-->


35) <!-- [rfced] In Section 10.4, would you like to change the text introducing
the XML examples to be figure titles (would appear under the XML and also
include a figure number)? Or do you prefer the current?

Current:
  BlockGroup with a frame that references another frame, with the
  EBML tree shown as XML:

Perhaps (below XML example): 
  Figure 15: Blockgroup with a Frame That References Another Frame,
  with the EBML Tree Shown as XML
-->


36) <!-- [rfced] We updated the end tag as follows in two blocks of XML in
Section 10.4. Please review.

Original:
  <BlockDuration>20<BlockDuration>

Perhaps:
  <BlockDuration>20</BlockDuration>
-->


37) <!-- [rfced] Will readers know what "For such elements" refers to in this
first sentence of Section 11.1.1??

Original:
   For such elements, the timestamp value is stored directly in
   nanoseconds.
-->


38) <!-- [rfced] How may we update "to provide authorization" to create parallel
structure for the list in this sentence? The other items in the list are
nouns (i.e., confidentiality, integrity, authenticity).
     
Original:
   This Matroska specification provides no interoperable solution for
   securing the data container with any assurances of confidentiality,
   integrity, authenticity, or to provide authorization.
   
Perhaps: 
   This Matroska specification provides no interoperable solution for
   securing the data container with any assurances of confidentiality,
   integrity, authenticity, or authorization. 
-->


39) <!-- [rfced] In Sections 18 and 19, would it be helpful for the names of the
flags to align more closely with those in Sections 5.1.4.1.4 to
5.1.4.1.11? Or is the current okay? We are specifically asking about the
following flags (the others match).

Original (in Sections 18 and 19):
  hearing-impaired flag
  visual-impaired flag 
  descriptions flag 

Current:
  Hearing-Impaired flag
  Visual-Impaired flag
  Descriptions flag

Perhaps:
  HearingImpaired flag
  VisualImpaired flag
  TextDescriptions flag

Note that we see both "default track flag" and "Default flag" in the text. We
updated to "Default flag" for consistency.
-->


40) <!-- [rfced] The noun ("tracks") is plural, but the pronoun ("it's") is
singular. Which of the following options is the best way to fix this
agreement issue?

Original:
   Overlay tracks SHOULD be rendered in the same channel as the track
   it's linked to.  

Perhaps (both plural):
   Overlay tracks SHOULD be rendered in the same channel as the track
   they are linked to.

Or (both singular):
   An overlay track SHOULD be rendered in the same channel as the track
   it's linked to.  
-->


41) <!-- [rfced] Would it be helpful to update "Old stereo 3D" to "Old stereo 3D
movies" or something similar?

Original:
Old stereo 3D were displayed using anaglyph (cyan and red colors separated).

Perhaps:
Old stereo 3D movies were displayed using anaglyph (cyan and red colors separated).
-->


42) <!-- [rfced] Please review "If configured to specifically prefer" here. What
is configured?

Original: 
If configured to specifically prefer audio tracks in English or
Spanish, the player should select one of the tracks in the corresponding
language.

Perhaps: 
If the user has configured to specifically prefer audio
tracks in English or Spanish, the player should select one of the tracks in
the corresponding language.
-->


43) <!-- [rfced] Please review "Chapter ChapterFlagHidden flag" and "Parent
Chapter ChapterFlagHidden flag". Will these be clear for readers? Would
updating to use a possessive be helpful? 

Original: 
   Each Chapter ChapterFlagHidden flag works independently of parent
   chapters.  A Nested Chapter with a ChapterFlagHidden that evaluates
   to "0" remains visible in the user interface even if the Parent
   Chapter ChapterFlagHidden flag is set to "1".

Perhaps: 
   Each Chapter's ChapterFlagHidden flag works independently of Parent
   Chapters.  A Nested Chapter with a ChapterFlagHidden flag that evaluates to
   "0" remains visible in the user interface even if the Parent Chapter's
   ChapterFlagHidden flag is set to "1".
-->


44) <!-- [rfced] Will readers understand the use of "idem" here? Would it be
helpful to update as follows (or something similar)?

Original:
   The private data depend on
   the type of menu system (stored in ChapProcessPrivate), idem for the
   data in the chapters (stored in ChapProcessData).

Perhaps: 
   The private data depend on
   the type of menu system (stored in ChapProcessPrivate), which is the same for the
   data in the chapters (stored in ChapProcessData).

Or:
   The private data depend on
   the type of menu system (stored in ChapProcessPrivate); the same is true for the
   data in the chapters (stored in ChapProcessData).
-->


45) <!-- [rfced] How may we clarify this sentence? Note that this sentence appears
twice in the document.

Original:
   This would translate in the following matroska form, with the EBML
   tree shown as XML :
   
Perhaps: 
   This translates to Matroska form, with the EBML tree shown as follows in XML:
-->


46) <!-- [rfced] We see "The killer arrested" in the bulleted list below but not
in the XML following this list. The XML has "After the crime" (in both
English and French). Please review and let us know if any updates are
needed.

Current:
   *  00000 ms - 05000 ms: Intro
   *  05000 ms - 25000 ms: Before the crime
   *  25000 ms - 27500 ms: The crime
   *  27500 ms - 38000 ms: The killer arrested
   *  38000 ms - 43000 ms: Credits
-->


47) <!-- [rfced] FYI - We updated "SubStation Alpha (SSA/ASS)" as follows. Please
let us know any concerns.

Original:
   Subtitle codecs, such as SubStation Alpha (SSA/ASS), usually refer to
   a font by its Font Name, not by its filename.
   
Perhaps: 
   Subtitle codecs, such as SubStation Alpha (SSA) and Advanced SubStation
   Alpha (ASS), usually refer to a font by its Font Name, not by its filename. 
-->


48) <!-- [rfced] Would it be helpful to rephrase the text starting with "without a
lot of data..."?

Original: 
The guidelines in Section 25, when followed, help reduce the number
of seeking operations for regular playback and also have the playback start
quickly without a lot of data needed to read first (like a Cues Element,
Attachment Element or SeekHead Element).

Perhaps: 
When followed, the guidelines in Section 25 help reduce the number of
seeking operations for regular playback and also have the playback start
quickly without needing to read lot of data first (like a Cues Element,
Attachment Element, or SeekHead Element).
-->


49) <!-- [rfced] Should "Track Name" here be updated to "Name" per Section
5.1.4.1.18? Or is the original okay?

Original:
   Some Matroska elements also contain their own string value like the
   Track Name (Section 5.1.4.1.18) or the Chapter String
   (Section 5.1.7.1.4.10).
   ...
   *  The Track Name Element (Section 5.1.4.1.18) corresponds to a tag
      with the TagTrackUID (Section 5.1.8.1.1.3) set to the given track,
-->


50) <!-- [rfced] Similar to the question above, should "Chapter String" be updated
to "ChapString" per Section 5.1.7.1.4.10?

Original:
   Some Matroska elements also contain their own string value like the
   Track Name (Section 5.1.4.1.18) or the Chapter String
   (Section 5.1.7.1.4.10).
   ...
   *  The Chapter String Element (Section 5.1.7.1.4.10) corresponds to a
      tag with the TagChapterUID
-->


51) <!-- [rfced] How may we clarify the text starting with "depending on the..."?

Original:
   The size of this Void Element should be adjusted depending on the
   Matroska file already having Tags, Chapters, and Attachments
   Elements.
   
Perhaps: 
   The size of this Void Element should be adjusted depending on the
   Tags, Chapters, and Attachments
   Elements in the Matroska file.
-->


52) <!-- [rfced] Would it be helpful to include "[RFC8794]" in this sentence in
the Security Considerations section?

Original:
   Matroska inherits security considerations from EBML.

Perhaps: 
   Matroska inherits security considerations from EBML [RFC8794].
-->


53) <!-- [rfced] How may we rephrase this sentence to make it more concise and
clear?

Original:
   It is up to the
   decision of the Matroska Readers on how to handle the errors if they
   are recoverable in their code or not. 

Perhaps:
   Matroska Readers decide how to handle the errors whether or not they
   are recoverable in their code.  
-->


54) <!-- [rfced] We moved "28. Annex A: Historic Deprecated Elements" to be
"Appendix A.  Historic Deprecated Elements" (appears after the references
section). If no objections, we will ask IANA to update the section
pointers in the registry defined in Section 27.1 accordingly.

However, if you wish to retain this as Section 28, we will update to
"28. Historic Deprecated Elements" (no "Annex A").

Link to registry: https://www.iana.org/assignments/matroska/matroska.xhtml
-->


55) <!-- [rfced] We have included some specific questions about the IANA text 
in the document.  In addition to responding to those questions, please review 
all of the IANA-related updates carefully and let us know if any updates are needed. 

a) Section 27.1: Should the list in this sentence include an "Element Name"?
Also, does IANA assign the Element ID? If so, should the sentence be updated
per the "Or" text below to include "Element Name" but not "Element ID"?

Also, please confirm that the Reference is optional.

Original:
   To register a new Element ID in this registry, one needs an Element
   ID, a Change Controller (IETF or email of registrant) and an optional
   Reference to a document describing the Element ID.

Perhaps (both Element ID and Element Name in list):
   To register a new Element ID in this registry, one needs an Element
   ID, an Element Name, a Change Controller (IETF or email of
   registrant), and an optional Reference to a document describing the
   Element ID.

Or (Element ID not in list):
   To register a new Element ID in this registry, one needs an Element
   Name, a Change Controller (IETF or email of
   registrant), and an optional Reference to a document describing the
   Element ID.


b) Section 27.2: Similar to the question above, should the list in this
sentence include "description" and possibly remove "Chapter Codec ID" from the
list?

Also, please confirm that the Reference is optional.

Original:
   To register a new Chapter Codec ID in this registry, one needs a
   Chapter Codec ID, a Change Controller (IETF or email of registrant)
   and an optional Reference to a document describing the Chapter Codec
   ID.

Perhaps (both Chapter Codec ID and description in list):
   To register a new Chapter Codec ID in this registry, one needs a
   Chapter Codec ID, description, a Change Controller (IETF or email of
   registrant), and an optional Reference to a document describing the
   Chapter Codec ID.

Or (Chapter Codec ID not in list):
   To register a new Chapter Codec ID in this registry, one needs a
   description, a Change Controller (IETF or email of
   registrant), and an optional Reference to a document describing the
   Chapter Codec ID.


c) Would it be helpful to include the ranges listed in the registry at
https://www.iana.org/assignments/matroska/?

Original:
   One-octet Matroska Element IDs are to be allocated according to the
   "RFC Required" policy [RFC8126].

   Two-octet Matroska Element IDs are to be allocated according to the
   "Specification Required" policy [RFC8126].

   Three-octet and four-octet Matroska Element IDs are to be allocated
   according to the "First Come First Served" policy [RFC8126].

Perhaps:
   One-octet Element IDs (range 0x00-0xFF) are to be allocated according to the
   "RFC Required" policy [RFC8126].

   Two-octet  Element IDs (range 0x0100-0xFFFF) are to be allocated according
   to the "Specification Required" policy [RFC8126].

   Three-octet and four-octet Element IDs (range 0x00010000-0xFFFFFFFF) are to
   be allocated according to the "First Come First Served" policy [RFC8126].


d) We have combined the text below into one complete sentence. Should "within
a BlockGroup or Chapters" be updated to "BlockGroup or Chapters" (no "within a")?

Original: 
   Given the scarcity of the One-octet Element IDs, they should only be
   created to save space for elements found many times in a file.  For
   example, within a BlockGroup or Chapters.

Current:
   Given the scarcity of one-octet Element IDs, they should only be
   created to save space for elements found many times in a file (for
   example, within a BlockGroup or Chapters).

Perhaps:
   Given the scarcity of one-octet Element IDs, they should only be
   created to save space for elements found many times in a file (for
   example, BlockGroup or Chapters).


e) FYI - We removed "Described in" from the Reference column of the table in
Section 27.1 to match the IANA registry at https://www.iana.org/assignments/matroska/.


f) The table in Section 27.1 does not contain the "Change Controller" column that appears in the registry at https://www.iana.org/assignments/matroska. Would it be helpful to add a sentence noting that that the change controller for all initial entries in the registry is "IETF"?

Current:
   Table 54 shows the initial contents of the "Matroska Element IDs"
   registry.
   
Perhaps:
   Table 54 shows the initial contents of the "Matroska Element IDs"
   registry. Note that the Change Controller for all entries in Table 54 is "IETF".


g) Section 27.2 notes this:

Original:
   The values correspond to the unsigned
   integer ChapProcessCodecID value described in Section 5.1.7.1.4.15.
   ...
   ChapProcessCodecID values of "0" and "1" are RESERVED to the IETF for
   future use.
   
Values 0 and 1 in the registry are listed as Reserved, with this document as a
reference. See
https://www.iana.org/assignments/matroska/matroska.xhtml#matroska-chapter-codec-ids.

However, Section 5.1.7.1.4.15 notes this about values "0" and "1" for ChapProcessCodecID:

Original:
   definition:  Contains the type of the codec used for the processing.
      A value of 0 means built-in Matroska processing (to be defined), a
      value of 1 means the DVD command set is used; see Section 20.3 on
      DVD menus.  More codec IDs can be added later.
      
Please review and let us know if any updates are needed.


h) Sections 27.3.1-27.3.3: May we update this text to avoid "..." in one of
the following ways? Note that this appears three times (in each of the
templates in Section 27.3).

Original:
  FFmpeg, VLC, ...

Perhaps:
  FFmpeg, VLC, etc.

Or:
  FFmpeg and VLC


i) Sections 27.3.1-27.3.3: We made a few minor edits to the templates in these
sections. Please review and let us know any concerns. We will ask IANA to
update the templates to match the edited document prior to publication:

https://www.iana.org/assignments/media-types/audio/matroska
https://www.iana.org/assignments/media-types/video/matroska
https://www.iana.org/assignments/media-types/video/matroska-3d
-->


56) <!-- [rfced] We see both "color" (American spelling) and "colour" (British
spelling) used in the document, with the Colour Element registered with
IANA. The document generally uses American spelling (e.g., "optimized"
rather than "optimised", etc.).

Are any updates needed for consistency? Perhaps update all instances to
"color" and request that IANA update the entry in the registry accordingly?

Link to registry: https://www.iana.org/assignments/matroska/matroska.xhtml
-->


57) <!-- [rfced] Please review the text after the ":" and let us know how to
update for clarity. Are the words "files" and "tracks" needed?

Original:
   Matroska files and streams are found in three main forms: audio-video
   files, audio-only and occasionally with stereoscopic video tracks.
   
Perhaps: 
  Matroska files and streams are found in three main forms: audio-video,
  audio-only, and (occasionally) stereoscopic video.
-->


58) <!-- [rfced] BCP 47 contains two RFCs: RFC 4647 and RFC 5646. See
https://www.rfc-editor.org/info/bcp47.

It seems that when "BCP 47" and "[BCP47]" are used, the intent is to refer to
RFC 5646. Is this correct?

If so, we recommend the following updates. Note that we will not make any
changes to element names (e.g., LanguageBCP47 and ChapLanguageBCP47).


a) Add the following sentence to the end of Section 12 to clarify that "BCP47"
in element names refers specifically to RFC 5646.

Perhaps:
   In this document, "BCP47" in element names refers specifically to [RFC5646], which is
   part of BCP 47.


b) Update these sentences in Section 12 as follows to use RFC 5647 rather than BCP 47

Original:
   Starting in Matroska version 4, either [ISO639-2] or [BCP47] MAY be
   used, although BCP 47 is RECOMMENDED.  The BCP 47 Language Elements
   are "LanguageBCP47 Element", "TagLanguageBCP47 Element", and
   "ChapLanguageBCP47 Element".  If a BCP 47 Language Element and an ISO
   639-2 Language Element are used within the same Parent Element, then
   the ISO 639-2 Language Element MUST be ignored and precedence given
   to the BCP 47 Language Element.

Perhaps:
   Starting in Matroska version 4, the forms defined
   in either [ISO639-2] or [RFC5646] MAY be
   used, although the form in [RFC5646] is RECOMMENDED.  The Language Elements
   in the [RFC5646] form are are "LanguageBCP47 Element", "TagLanguageBCP47 Element",
   and "ChapLanguageBCP47 Element".  If both an [ISO639-2] Language Element and 
   an [RFC5646] Language Element are used within the same Parent Element, then
   the Language Element in the [ISO639-2] form MUST be ignored and precedence given
   to the Language Element in the [RFC5646] form.


c) Update these sentences to use RFC 5647 rather than BCP 47

Original:
   definition:  The language of the track, in the [BCP47] form; see
      Section 12 on language codes.

   definition:  A language corresponding to the ChapString, in the
      [BCP47] form; see Section 12 on language codes.  

   definition:  The language used in the TagString, in the [BCP47] form;
      see Section 12 on language codes.  

   Country codes are the [BCP47] two-letter region subtag, without the
   UK exception.

Perhaps:
   definition:  The language of the track, in the form defined in
      [RFC5646]; see Section 12 on language codes.

   definition:  A language corresponding to the ChapString, in
      the form defined in [RFC5646]; see Section 12 on language codes.  

   definition:  The language used in the TagString, in
      the form defined in [RFC5646]; see Section 12 on language codes.  

   Country codes are the two-letter region subtag defined in [RFC5646],
   without the UK exception.
-->


59) <!-- [rfced] We see a few instances of "in the Matroska languages form" with a
pointer to Section 12, which discusses the [ISO639-2] or [BCP47]
forms. Please review and let us know if "in the Matroska languages form"
will be clear to readers or if updates are needed.

Original:
   definition:  The language of the track, in the Matroska languages
      form; see Section 12 on language codes. 

   definition:  A language corresponding to the string, in the Matroska
      languages form; see Section 12 on language codes. 

   definition:  Specifies the language of the tag specified, in the
      Matroska languages form; see Section 12 on language codes. 
-->


60) <!-- [rfced] References

a) FYI - For clarity, we added "[RFC8794]" after several instances of "the
EBML specification". 


b) The original link provided for the following reference is a withdrawn
standard. We have updated the the date and URL to point to the current
version. Please let us know any concerns.

Original:
   [ISO9899]  International Organization for Standardization,
              "Information technology - Programming languages - C",
              ISO/IEC 9899:2011, 2011,
              <https://www.iso.org/standard/57853.html>.

Current:
   [ISO9899]  International Organization for Standardization,
              "Information technology - Programming languages -  C",
              ISO/IEC 9899:2018, June 2018,
              <https://www.iso.org/standard/74528.html>.

c) The URL in the following reference entry displays a landing page titled
"Welcome to the DVD Forum". We were unable to find a page titled "DVD-Books:
Part 3 DVD-Video Book". How may we update this entry so that readers can find
the reference?

Original:
[DVD-Video]
           DVD Forum, "DVD-Books: Part 3 DVD-Video Book", 1 November
           1995, <http://www.dvdforum.org/>.


d) We do not see the title "DivX Trick Track Extensions" at the URL
provided. Should the title of this reference entry be updated to "DivX Plus MKV
extension: Smooth FF/RW" per the URL?

Original:
[DivXTrickTrack]
           "DivX Trick Track Extensions", 14 December 2010,
           <https://web.archive.org/web/20101222001148/
           http://labs.divx.com/node/16601>.


e) We note that this standard was withdrawn on May 19, 2005. Are any updates needed?

Original:
[FIPS.46-3]
           US National Institute of Standards and Technology, "Data
           Encryption Standard (DES)", FIPS PUB 46, 25 October 1999,
           <https://csrc.nist.gov/publications/detail/fips/46/3/
           archive/1999-10-25>.


f) We have updated the reference as follows to reflect 1) the title shown in
the URL and 2) the authors listed in the Authors section of the URL. Please
let us know any concerns.


[LZO]      Tarreau, W., Rodgman, R., and M. Oberhumer, "Lempel-Ziv-
           Oberhumer compression", 30 October 2018,
           <https://www.kernel.org/doc/Documentation/lzo.txt>.

Current:
[LZO]      Tarreau, W. and R. Rodgman, "LZO stream format as
           understood by Linux's LZO decompressor", October 2018,
           <https://www.kernel.org/doc/Documentation/lzo.txt>.


g) May we update the URL in this reference entry as follows to point
directly to the paper?

Original:
[Twofish]  Schneier, B., Kelsey, J., Whiting, D., Wagner, D., Hall,
           C., and N. Ferguson, "Twofish: A 128-Bit Block Cipher", 15
           June 1998, <https://www.schneier.com/academic/twofish/>.

Current:
[Twofish]  Schneier, B., Kelsey, J., Whiting, D., Wagner, D., Hall,
           C., and N. Ferguson, "Twofish: A 128-Bit Block Cipher",
           June 1998, <https://www.schneier.com/academic/archives/1998/06/twofish_a_128-bit_bl.html>.


h) The Security Considerations section points to Section 2.1 of [RFC4732], but
no corresponding entry in the References section was included. We added
[RFC4732] as an informative reference. Please let us know if it should be
normative instead.
-->


61) <!-- [rfced] Please clarify "A URL to download about". Should this text be
updated as follows?

Original:
documentation:  A URL to download about the codec used.

Perhaps:
documentation:  A URL to download information about the codec used.
-->


62) <!-- [rfced] Formatting with <tt>

a) Sometimes the word "element" is included in the <tt> tags and sometimes it
appears outside the tags. For example, we see both of the following in the xml:

<tt>SimpleBlock Element</tt>
<tt>SimpleBlock</tt> Element

We suggest making such terms consistent. Should "Element" appear in <tt>
tagging, or should it appear outside the tags?


b) The following terms appear both with and without <tt> in the xml. Please
review and let us know if the tagging should be consistent.

Attachment
Attachments
Block
BlockAdditions
BlockDuration
BlockGroup
ChapProcessCodecID
ChapProcessData
ChapProcessPrivate
Chapter
ChapterAtom
Chapters
ChapterSegmentEditionUID
ChapterSegmentUUID
ChapterTranslate
ChapterUID
Cluster
Clusters
CodecID
Cues
DiscardPadding
Edition
EditionEntry
Editions
Element
FileName
Matroska
NextUUID
PrevUUID
SeekHead
Segment
Segments
SegmentUUID
SimpleBlock
Tag
Tags
TagString
Timestamp
TimestampScale
Track
TrackNumber
Tracks
TrackTranslate
-->


63) <!-- [rfced] Terminology

a) Please review the following similar terms used in the document. Should these be
consistent?

Audio/Video container
audio and visual container 
audiovisual data container 

Original:
   First, it is essential to clarify exactly "What an Audio/Video
   container is", to avoid any misunderstandings:
   ...
   As an audio and visual container format, a Matroska file or stream
   will potentially encapsulate numerous byte streams created with a
   variety of codecs.
   ...   
   Matroska is an audiovisual data container format.
   ...
   This document defines the Matroska audiovisual data container
   structure, 


b) Please review the following and let us know if both forms are correct or if
updates are needed for consistency.

Attachment Element vs. Attachments Element
  Note: "Attachments Element" is defined in Section 5.1.6. 

Track Element vs. Tracks Element
  Note: "Tracks Element" is defined in Section 5.1.4.

Cue Element vs. Cues Element
  Note: "Cues Element" is defined in Section 5.1.5.

Chapters Element vs. Chapter Element vs. Chapter element
  Note: "Chapters Element" is defined in Section 5.1.7, but perhaps "Chapter
  element" refers to elements like "ChapterAtom" and "ChapterTrack"? 


c) In these sentences, should "Attachment" be updated to "Attachments Element" 
or "attachment"?

   When stored,
   the normal cover SHOULD be the first Attachment in storage order.
   ...
   Thus, for
   maximum compatibility, it's usually better to put the strings in the
   TrackEntry, ChapterAtom, and Attachment and keep the tags matching
   these values if tags are also used.


d) Please review the use of lowercase "attachment" in the document. Should any
instances be updated to "Attachments Element"?


e) We note inconsistencies in the terms listed below. We chose the form on the
right. Please let us know any objections.

Matroska reader vs. Matroska Reader

Matroska writer vs. Matroska Writer

Matroska player vs. Matroska Player


f) We see the following forms used in the document. We believe that the
capitalized form indicates the element (even when not followed by the word
"Element"), while the lowercase is for general use. Please review that this
usage is consistent.

Tag vs. tag
Tags vs. tags

Example general use:
   When tags from the previous layout

Examples of capped form not followed by "Element":
   ...has its UID listed in the Tags.

   The Tags contain all extra information


g) We note that the following terms are used inconsistently throughout the
document. Please review and let us know if any updates are needed for consistency.

segment vs. Segment

alpha vs. Alpha
  Note: In context of "Alpha data" and "alpha channel data".

AnaGlyph vs. anaglyph

EBML header vs. EBML Header

block element vs. Block Element

block header vs. Block header vs. Block Header
  Note: We will make capitalization of "header" in "SimpleBlock header" consistent
  with the decision here.

block vs. Block 
  Note: In general text, e.g., "of the virtual block" and "contained in the Block".

chapter codec vs. Chapter Codec 

chapter edition(s) vs. Chapter Edition(s) 

child element vs. Child Element

codec ID vs. Codec ID
  Note: We will not change "CodecID" used in element names.

codec state vs. Codec State 

filename vs. file name
  Note: We are asking about instances aside from "FileName Element".

fourcc vs. FourCC
  Note: "fourcc" is only used in the context of "fourcc field".

linked Segment vs. Linked Segment 

track name vs. Track Name 

Track vs. track
  Note: In general text, e.g., "For separate tracks" and "end of a Track")

trackUID vs. TrackUID

segment vs. Segment 

cluster vs. Cluster

Stereo-3D vs. stereo 3D

edition vs. Edition

Control Track vs. control track
-->


64) <!-- [rfced] Capitalization of "element"

a) We note that capitalization of "element" is inconsistent when following the name
of elements. Please review and let us know if any updates are needed for
consistency.

Some examples:

Capitalized:
  Root Element
  Top-Level Element
  Empty Element
  Segment Element
  Info Element
  SeekHead Element
  Chapters Element
  Cluster Element

Lowercase:
  DiscardPadding element
  NextFilename element
  TagDefault element
  TrackEntry\Name element
  AttachmentLink element

Mixed capitalization:
  CRC-32 element vs. CRC-32 Element
  ReferenceBlock element vs. ReferenceBlock Element
  Chapter element vs. Chapter Element
  ChapterTimeEnd element vs. ChapterTimeEnd Element
  ChapterSegmentUUID element vs. ChapterSegmentUUID Element
  ChapterAtom element vs. ChapterAtom Element 


b) Should "element" (lowercase) vs. "Element" (uppercase) be used in general 
text? We recommend the lowercase form.

Some examples:
   When both values exist in the file, the value found in Tags takes
   precedence over the value found in original location of the element.

   In that case these elements are informational only.

   These Elements
   allow edges of the frame that are not intended for display,

   An Element which is not
   stored within a Segment Element, such as the Elements of the EBML
   Header, do not have a Segment Position.

   The Segment Position of an Element refers to the position of the...
-->


65) <!-- [rfced] Abbreviations 

a) FYI - We have added expansions for abbreviations upon first use per Section
3.6 of RFC 7322 ("RFC Style Guide"). Please review each expansion in the
document carefully to ensure correctness.


b) How may we expanded "VANC" here? We do not see this in published RFCs.

Original: 
  These Elements allow edges of the frame that are not intended for
  display, such as the sprockets of a full-frame film scan or the VANC area of a
  digitized analog videotape... 


c) Should "SBR" be expanded as "Spectral Band Replication"?

Original: 
  Real output sampling frequency in Hz (used for SBR techniques).

Perhaps: 
  Real output sampling frequency in Hz that is used for Spectral Band
  Replication (SBR) techniques.
-->


66) <!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. For example, please consider whether
the following should be updated:

black
white
master
-->


Thank you.

RFC Editor/mc/rv


On Apr 17, 2024, at 11:23 PM, [e-mail] wrote:

*****IMPORTANT*****

Updated 2024/04/17

RFC Author(s):
--------------

Instructions for Completing AUTH48

Your document has now entered AUTH48.  Once it has been reviewed and 
approved by you and all coauthors, it will be published as an RFC.  
If an author is no longer available, there are several remedies 
available as listed in the FAQ (https://www.rfc-editor.org/faq/).

You and you coauthors are responsible for engaging other parties 
(e.g., Contributors or Working Group) as necessary before providing 
your approval.

Planning your review 
---------------------

Please review the following aspects of your document:

*  RFC Editor questions

  Please review and resolve any questions raised by the RFC Editor 
  that have been included in the XML file as comments marked as 
  follows:

  <!-- [rfced] ... -->

  These questions will also be sent in a subsequent email.

*  Changes submitted by coauthors 

  Please ensure that you review any changes submitted by your 
  coauthors.  We assume that if you do not speak up that you 
  agree to changes submitted by your coauthors.

*  Content 

  Please review the full content of the document, as this cannot 
  change once the RFC is published.  Please pay particular attention to:
  - IANA considerations updates (if applicable)
  - contact information
  - references

*  Copyright notices and legends

  Please review the copyright notice and legends as defined in
  RFC 5378 and the Trust Legal Provisions 
  (TLP – https://trustee.ietf.org/license-info/).

*  Semantic markup

  Please review the markup in the XML file to ensure that elements of  
  content are correctly tagged.  For example, ensure that <sourcecode> 
  and <artwork> are set correctly.  See details at 
  <https://authors.ietf.org/rfcxml-vocabulary>.

*  Formatted output

  Please review the PDF, HTML, and TXT files to ensure that the 
  formatted output, as generated from the markup in the XML file, is 
  reasonable.  Please note that the TXT will have formatting 
  limitations compared to the PDF and HTML.


Submitting changes
------------------

To submit changes, please reply to this email using ‘REPLY ALL’ as all 
the parties CCed on this message need to see your changes. The parties 
include:

  *  your coauthors

  *  [e-mail] (the RPC team)

  *  other document participants, depending on the stream (e.g., 
     IETF Stream participants are your working group chairs, the 
     responsible ADs, and the document shepherd).

  *  [e-mail], which is a new archival mailing list 
     to preserve AUTH48 conversations; it is not an active discussion 
     list:

    *  More info:
       https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc

    *  The archive itself:
       https://mailarchive.ietf.org/arch/browse/auth48archive/

    *  Note: If only absolutely necessary, you may temporarily opt out 
       of the archiving of messages (e.g., to discuss a sensitive matter).
       If needed, please add a note at the top of the message that you 
       have dropped the address. When the discussion is concluded, 
       [e-mail] will be re-added to the CC list and 
       its addition will be noted at the top of the message. 

You may submit your changes in one of two ways:

An update to the provided XML file
— OR —
An explicit list of changes in this format

Section # (or indicate Global)

OLD:
old text

NEW:
new text

You do not need to reply with both an updated XML file and an explicit 
list of changes, as either form is sufficient.

We will ask a stream manager to review and approve any changes that seem
beyond editorial in nature, e.g., addition of new text, deletion of text, 
and technical changes.  Information about stream managers can be found in 
the FAQ.  Editorial changes do not require approval from a stream manager.


Approving for publication
--------------------------

To approve your RFC for publication, please reply to this email stating
that you approve this RFC for publication.  Please use ‘REPLY ALL’,
as all the parties CCed on this message need to see your approval.


Files 
-----

The files are available here:
  https://www.rfc-editor.org/authors/rfc9559.xml
  https://www.rfc-editor.org/authors/rfc9559.html
  https://www.rfc-editor.org/authors/rfc9559.pdf
  https://www.rfc-editor.org/authors/rfc9559.txt

Diff file of the text:
  https://www.rfc-editor.org/authors/rfc9559-diff.html
  https://www.rfc-editor.org/authors/rfc9559-rfcdiff.html (side by side)

Alt-diff of the text (allows you to more easily view changes 
where text has been deleted or moved): 
  https://www.rfc-editor.org/authors/rfc9559-alt-diff.html

Diff of the XML: 
  https://www.rfc-editor.org/authors/rfc9559-xmldiff1.html


Tracking progress
-----------------

The details of the AUTH48 status of your document are here:
  https://www.rfc-editor.org/auth48/rfc9559

Please let us know if you have any questions.  

Thank you for your cooperation,

RFC Editor

--------------------------------------
RFC9559 (draft-ietf-cellar-matroska-21)

Title            : Matroska Media Container Format Specifications
Author(s)        : S. Lhomme, M. Bunkus, D. Rice
WG Chair(s)      : Michael Richardson, Spencer Dawkins
Area Director(s) : Murray Kucherawy, Orie Steele