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

S Moonesamy <> Tue, 19 April 2011 07:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C312CE068E for <>; Tue, 19 Apr 2011 00:44:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 25-OpTiyNniT for <>; Tue, 19 Apr 2011 00:44:48 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0EDCFE0655 for <>; Tue, 19 Apr 2011 00:44:47 -0700 (PDT)
Received: from ([]) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id p3J7iWZe021691; Tue, 19 Apr 2011 00:44:38 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple;; s=mail; t=1303199081; bh=cN1qP2yrASuWU3WERgvaQmoStYY=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=k+9PQKShx/hOjhVjQUMMb4p2Zo+fradnGYVi5uQZZ1Wvh3KnCTmZTE4VGZybHTg0y iu1NPbZBHKhwPaCV9uC5uD6YErlgcClpD8Y0r1/zOM9s9+A1BeVTyQrNsAKqvRjrVc UqZ4CMne7dZZtSCAIU0YjmfGT0FxZptfa2NIPa4w=
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Version
Date: Mon, 18 Apr 2011 23:59:55 -0700
To: Randall Gellens <>
From: S Moonesamy <>
In-Reply-To: <p06240624c9d0cd69eff3@[]>
References: <> <p06240624c9d0cd69eff3@[]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: Randall Gellens <>, Per Frojdh <>, David Singer <>,
Subject: Re: [apps-discuss] Apps-team review of draft-gellens-mime-bucket-bis-03
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 19 Apr 2011 07:44:49 -0000

Hi Randy,

I removed the IESG from the Cc as the Apps Area ADs read the 
apps-discuss mailing list and can provide feedback to the IESG.

At 10:34 17-04-2011, Randall Gellens wrote:
>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.'

I noticed the document header.  As this is an editorial nit, feel 
free to ignore the comment.  Section 4.1.1 of the RFC Style Guide 
mentions that "Authors often also include a statement in the Abstract 
and/or Introduction sections".   That is flagged as a "should" by 
ID-nits by the way.  Your above comment sums up the changes in this draft.

You could also have:

    This document specifies two parameters, "codecs" and "profiles", which are
    used with various MIME types or type/subtype combinations to allow for
    unambiguous specification of the codecs and/or profiles  employed by the
    media formats contained within.  This document obsoletes RFC 4281 and
    retains the "codecs" parameter in a backwards compatible manner; the.

"profiles" parameter is added by this document.
>I think this makes the situation clear to those readers who aren't 
>familiar with RFC 4281


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

Thanks for explaining the subtlety of the "must".

>     An element MAY include an octet that [RFC2045] REQUIRES to be
>     encoded.  In this case, [RFC2231] is used:


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


Best regards,
S. Moonesamy