On Jul 5, 2011, at 7:53 , Miguel A. Garcia wrote:
> Minor issues:
>
> - I disagree with a few MAYs and MUSTs in Section 3.1. I will suggest to
> change all of them to lower case. Let me revise them:
>
> Therefore, when a receiver does not
> support all listed codecs, special handling MAY be required.
> ^^^
> This one does not specify a clear option that can be implemented. For
> example, I could not write a conformance requirement towards that "MAY". What
> should be the "special handling", and what are the options that I can
> implement or not?
>
I think this should not be upper-case. The ways the receiver handles missing
codecs will depend on the application, the availability of fall-backs, and so
on, all of which are out of scope.
>
> For
> example, the media element(s) MAY need to be examined in order to
> ^^^^
> determine if an unsupported codec is actually required ...
>
> This one has a contradiction: if it is an example ("For example,") then it
> cannot have a normative statement. Besides, it also suffers from the same
> problem as the previous "MAY", it is not clear what are the options to be
> implemented or not, and how to write a statement of compliance.
Again, lower-case the 'may'. It is possible, for example, that the codec in
question is only used in a part of the time-line that is not requested.
>
>
> NOTE: Although the parameter value MUST be complete and accurate in
> ^^^^
> 'breadth' (that is, it MUST report all four-character codes used in
> ^^^^
> all tracks for ISO-family files, for example) systems MUST NOT rely
> ^^^^^^^^
> on it being complete in 'depth'.
>
> The problem with the above three "MUSTs" is that they are in a NOTE, and
> notes are informative by nature. So, either you remove the word "NOTE:" or
> you turn them all lowercase. If you keep the uppercase, it would be nice to
> see which entity is responsible to execute the "MUST", i.e., the encoder of
> the decoder. The current wording, although polite, does not clearly indicate
> which entity is responsible for implementing the MUSTs.
This should not be a NOTE, it should be plain text. The encoder MUST report
across the complete breadth; the receiver MUST NOT rely on the report being
complete in depth.
>
>
> - Section 3.2. There is a uncongruency between the BNF and the examples.
> Please observe the BNF of the 'cod-fancy' object:
>
> cod-fancy := "codecs*" ":=" encodedv
>
> Now observe the examples given in Section 3.1:
>
> codecs*=''fo%2e
> codecs*="''%25%20xz, gork"
>
> I am missing a colon ":" before the equal sign "=", in order for the
> examples to be compliant with the BNF. Therefore, I would have expected that
> the examples were:
>
> codecs*:=''fo%2e
> ^
> codecs*:="''%25%20xz, gork"
> ^
>
> Alternatively, if the examples are correct, the ABNF should have not included
> a colon ":". I don't know which one is correct.
I believe that the ":" in the BNF is an error.
>
> Please observe that the resolution of this issue may also apply to the
> examples in Section 4.2 or the BNF in 4.5.
>
>
> - BNF in Section 3.2. The definition of "simpl-list" does not admit a white
> space in a list of elements, however the examples show them with spaces. So,
> either the BNF or the examples are wrong. Please observe the BNF:
>
> simp-list := DQUOTE id-simple *( "," id-simple ) DQUOTE
>
> and the examples in Section 3.1:
>
> codecs="a.bb.ccc.d, e.fff"
I think many people follow the examples; the BNF needs to permit (but not
require) white-space.
>
>
> - BNF in Section 3.2 There is normative words "MAY" written as comments to
> the BNF. I belive this is not the right place to insert normative statements,
> so I suggest to add that text elsewhere in the draft rather than embedded in
> a comment:
>
> fancy-sing := [charset] "'" [language] "'" id-encoded
> ; Parsers MAY ignore <language>
> ^^^
> ; Parsers MAY support only US-ASCII and UTF-8
> ^^^
> fancy-list := DQUOTE [charset] "'" [language] "'" id-list DQUOTE
> ; Parsers MAY ignore <language>
> ^^^
> ; Parsers MAY support only US-ASCII and UTF-8
> ^^^
>
Indeed, these two statements need to be moved.
> - A comment on the same part of the BNF. I think you need to add normative
> references to "US-ASCII" and "UTF-8".
Ouch. US-ASCII is formally defined by a spec. which is basically unavailable.
Does anyone reading this really not know what it is? UTF-8 needs a Unicode
reference, yes.
> - IANA considerations section. I am puzzled with this section. It says that
> IANA has already added "codecs" and "profiles" as optional parameters the
> media types... but honestly, I haven't found evidence of it. Can you please
> point to what IANA has already done?
I think 'codecs' got overlooked after the previous RFC was published. This is
written in the past tense so it will be true after the publication of this (and
the matching IANA action).
>
> Additionally, I noticed in the I-D tracker that IANA has added this draft as
> references to a selection of media types. Is this what was requested by this
> draft? Honestly, I think not. I suspect this is totally different from what
> this draft is requesting.
This draft should be additional to the base definition of the media types.
> Nits:
>
> - Section 3.1, at the top of page 8, the word "REQUIRES" is capitalized.
> Since this is not an RFC 2119 word, I would suggest to write it in lower case.
>
> An element MAY include an octet that [RFC2045] REQUIRES to be
> encoded.
>
>
OK
> - Section 3.1, same paragraph as the previous comment, towards the end. For
> the sake of clarity, I would suggest to refer to "percent encoded", which I
> believe is the common terminology for special characters that are encoded
> with a percent symbol. That would make the text:
>
> .... and single quote characters have special meaning and
> so MUST themselves be percent encoded.
> ^^^^^^^
>
> This comment also applies to the last paragraph in Section 4.2.
>
OK
>
> - I don't understand why Sections 3 and 4 have different structure. They
> should be equal in structure. For example, take the BNF definitions. We have
> Section 3.2 titled "Generic Syntax", while Section 4.2 is not a BNF. Ok, it
> is Section 4.5, but why is it titled "Profiles Parameter BNF definition"? I
> agree more with the latter title, but should also be applied to the codec BNF
> definition.
I left the previous structure of the 'codecs' section unchanged from the
previous RFC for consistency; but it seemed a new structure for the new
'profiles' section would aid clarity.
>
>
> Regards,
>
> Miguel G.
> --
> Miguel A. Garcia
> +34-91-339-3608
> Ericsson Spain
David Singer
Multimedia and Software Standards, Apple Inc.
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
