I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft. For background on Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>
Please resolve these comments along with any other comments you may receive.
Document: draft-gellens-mime-bucket-bis-05.txt
Reviewer: Miguel Garcia <[email protected]>
Review Date: 2011-07-05
IETF LC End Date: 2011-07-14
IESG Telechat date: 2011-07-14
Summary: This draft is on the right track but has open issues, described
in the review.
Major issues: none
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?
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.
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.
- 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.
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"
- 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
^^^
- A comment on the same part of the BNF. I think you need to add
normative references to "US-ASCII" and "UTF-8".
- 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?
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.
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.
- 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.
- 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.
Regards,
Miguel G.
--
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
