David/Randy/Per,
I haven't seen any reply to this message. IESG review is coming up on
Thursday morning. Please respond to these issues well before then.
pr
On 7/5/11 9:53 AM, Miguel A. Garcia wrote:
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.
--
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
