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 <miguel.a.garcia@ericsson.com>
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