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

S Moonesamy <sm+ietf@elandsys.com> Tue, 19 April 2011 07:44 UTC

Return-Path: <sm@elandsys.com>
X-Original-To: apps-discuss@ietfc.amsl.com
Delivered-To: apps-discuss@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C312CE068E for <apps-discuss@ietfc.amsl.com>; Tue, 19 Apr 2011 00:44:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25-OpTiyNniT for <apps-discuss@ietfc.amsl.com>; Tue, 19 Apr 2011 00:44:48 -0700 (PDT)
Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by ietfc.amsl.com (Postfix) with ESMTP id 0EDCFE0655 for <apps-discuss@ietf.org>; Tue, 19 Apr 2011 00:44:47 -0700 (PDT)
Received: from subman.elandsys.com ([41.136.236.170]) (authenticated bits=0) by mail.elandsys.com (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; d=elandsys.com; 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: <6.2.5.6.2.20110418231517.068b9298@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Mon, 18 Apr 2011 23:59:55 -0700
To: Randall Gellens <randy@qualcomm.com>
From: S Moonesamy <sm+ietf@elandsys.com>
In-Reply-To: <p06240624c9d0cd69eff3@[10.10.34.68]>
References: <6.2.5.6.2.20110416051507.05ba6868@elandnews.com> <p06240624c9d0cd69eff3@[10.10.34.68]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: Randall Gellens <randy@qualcomm.com>, Per Frojdh <Per.Frojdh@ericsson.com>, David Singer <singer@apple.com>, apps-discuss@ietf.org
Subject: Re: [apps-discuss] Apps-team review of draft-gellens-mime-bucket-bis-03
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=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

Yes.

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

Ok.

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

Ok.

Best regards,
S. Moonesamy