Re: [Gen-art] Gen-ART review of draft-gellens-mime-bucket-bis-05.txt

[Pete Resnick <[e-mail]>]

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 <[e-mail]>
> 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: [phone], Fax: [phone]