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

[Randall Gellens <[e-mail]>]

At 11:36 AM -0700 4/18/11, David Singer wrote:

>  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.

Dave made my point, which is that it can be confusing when normative 
directives are used for informative purposes.  One approach I try to 
use is to reword to be descriptive, but it's hard in this case.  I 
think "requires" can be written lower case here.


>
>   >>   "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.

I've used MUST in notes before; I think it's fine here.


>
>  Similarly below....
>
>  New suggested text (not yet uploaded, as per intsructions)
>
>
>  Attachment converted: TiLand:draft-gellens-mime-#29C6465.txt 
> (TEXT/R*ch) (029C6465)
>
>>
>>>
>>>  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.


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
The trouble with the world is not that people know too little, but
that they know so many things that ain't so.
--Mark Twain