Re: [apps-discuss] Apps-team review of draft-gellens-mime-bucket-bis-03

[David Singer <[e-mail]>]

On Apr 17, 2011, at 10:34 , Randall Gellens wrote:

> Hi sm,
> 
> Thanks for the helpful review.  I appreciate it.

I also appreciate it.  Thanks

> 
> All: Please see below for my thoughts:
> 
> At 6:43 AM -0700 4/16/11, S Moonesamy wrote:
> 
>> Hello,
>> 
>> I have been selected as the Applications Area Review Team reviewer for this draft (for background on apps-review, please see http://www.apps.ietf.org/content/applications-area-review-team).
>> 
>> Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft.
>> 
>> Document: draft-gellens-mime-bucket-bis-03
>> Reviewer: S. Moonesamy
>> Review Date: April 16, 2011
>> IETF Last Call Date: Unknown
>> IESG Telechat Date: Unknown
>> 
>> Summary:
>> 
>> This draft is almost ready for publication as a Proposed Standard but has a few nits that should be fixed before publication.
>> 
>> The Codecs Parameter for "Bucket" Media Types was specified in RFC 4281.  This draft specifies the Codecs and Profiles Parameters for "Bucket" Media Types.  As it is a significant change from RFC 4281, it does not fit the requirements specified in RFC 2026 for Draft Standard.  Please refer to RFC 5657 for additional information about how to advance a protocol to Draft Standard.
>> 
>> Please note that I have not read ISO/IEC 14496-15:2010, a normative reference, as it is not freely available.
>> 
>> Major Issues:
>> 
>> None
>> 
>> Minor Issues:
>> 
>> None
>> 
>> Nits:
>> 
>> draft-gellens-mime-bucket-bis-03 obsoletes RFC 4281 but there is no mention of that in the Abstract Section or the rest of the document.
> 
> There is a document header for it, but I agree that for clarify, there should be a statement to this effect in the text.  My suggestion is to add text at the end of the second paragraph of the Abstract (which starts 'This document specifies two parameters, "codecs" and "profiles"'.  The new text can say something along the lines of 'RFC 4281 added the "codecs" parameter, which this document retains in a backwards compatible manor; the "profiles" parameter is added by this document.'

and makes other clarifications to the use of the codecs parameter.

> 
> I think this makes the situation clear to those readers who aren't familiar with RFC 4281

OK, I wasn't sure whether such textual backwards-pointers were even allowed.  Now I know that they are encouraged.

> 
>> 
>> In Section 3.1:
>> 
>>   "An element MAY include an octet that must be encoded in order to
>>    comply with [RFC2045]"
>> 
>> I suggest capitalizing the "must" as key words are capitalized in that sentence.
> 
> This is a little tricky, because the "MAY include" in normative in this document (this document is imposing the rule) while the "must be encoded in order to comply" is descriptive; it describes the octet to which the rest of the clause applies.  I think simply capitalizing the "must" in this instance would make the text less clear.   What would people (especially my other authors) think about using wording such as:
> 
>    An element MAY include an octet that [RFC2045] REQUIRES to be
>    encoded.  In this case, [RFC2231] is used:

I agree, I think it best if capitalized verbs are used for requirements expressed in the document. So I would not capitalize 'requires' in this case, but it's OK by me.


> 
>> 
>>   "Note that, when the [RFC2231] form is used, the percent
>>    sign, asterisk, and single quote characters have special meaning and
>>    so must themselves be encoded."
>> 
>> I suggest capitalizing the "must".
> 
> I agree.
> 

Existing text from 4281.  Can I have  MUST in a 'Note' sentence?  Most bodies don't allow that.  I think that the 'Note that,' should go:
When the [RFC2231] form is used, the percent
   sign, asterisk, and single quote characters have special meaning and
   so MUST themselves be encoded.

Similarly below....

New suggested text (not yet uploaded, as per intsructions)

> 
>> 
>> In Section 4.2:
>> 
>>   "An element MAY include an octet that must be encoded in order to
>>    comply with [RFC2045]"
>> 
>> I suggest capitalizing the "must".
> 
> I suggest using the wording from above:
> 
>    An element MAY include an octet that [RFC2045] REQUIRES to be
>    encoded.  In this case, [RFC2231] is used:
> 
>> 
>>   "Note that, when the [RFC2231] form is used,
>>    the percent sign, asterisk, and single quote characters have special
>>    meaning and so must themselves be encoded."
>> 
>> I suggest capitalizing the "must".
> 
> I agree.
> 
> 
> -- 
> Randall Gellens
> Opinions are personal;    facts are suspect;    I speak for myself only
> -------------- Randomly selected tag: ---------------
> He who would travel happily must travel light.  --Antoine St. Exuperey

David Singer
Multimedia and Software Standards, Apple Inc.