Re: [AVT] Gen-ART review of draft-ietf-avt-rtp-jpeg2000-beam-10.txt

Satoshi Futemma <> Thu, 19 June 2008 17:48 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id B2B113A6963; Thu, 19 Jun 2008 10:48:09 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3DD0B3A695E; Wed, 18 Jun 2008 21:48:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.09
X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xtZgE8xlNojv; Wed, 18 Jun 2008 21:48:08 -0700 (PDT)
Received: from (ms6.Sony.CO.JP []) by (Postfix) with ESMTP id 563AD3A67DD; Wed, 18 Jun 2008 21:48:07 -0700 (PDT)
Received: from (mta5.Sony.CO.JP []) by (R8/Sony) with ESMTP id m5J4mOtm012779; Thu, 19 Jun 2008 13:48:24 +0900 (JST)
Received: from (localhost []) by (R8/Sony) with ESMTP id m5J4mP1D005578; Thu, 19 Jun 2008 13:48:25 +0900 (JST)
Received: from ([]) by (R8/Sony) with ESMTP id m5J4mOOl005574; Thu, 19 Jun 2008 13:48:24 +0900 (JST)
Received: from [] ([]) by (8.14.1/8.14.1) with ESMTP id m5J4mObE027670; Thu, 19 Jun 2008 13:48:24 +0900
Message-ID: <>
Date: Thu, 19 Jun 2008 13:47:15 +0900
From: Satoshi Futemma <>
User-Agent: Thunderbird (Windows/20080421)
MIME-Version: 1.0
Subject: Re: [AVT] Gen-ART review of draft-ietf-avt-rtp-jpeg2000-beam-10.txt
References: <>
In-Reply-To: <>
X-Mailman-Approved-At: Thu, 19 Jun 2008 10:48:03 -0700
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Dear Black,

Thank you for the comment.

I have sent the mail about the priority mapping of
progression based ordering.
So, I reply to the other comments on the mail. wrote:
> [2] The review of the -09 version stated "Section 4.1 contains this
> problematic text:
>    An initial value of mh_id MUST be selected randomly between 1 and 7
>    for security reasons."
> This has been partially addressed.  While section 2.1 now requires that
> the initial value of mh_id always be zero, the above "problematic text"
> remains, and still needs to be removed from Section 4.1.

I will change the sentence in Section 2.1.

> In addition, Security Considerations paragraph on mh_id concludes with
> a rather cryptic statement that "Care should be taken to prevent
> implementation bugs with potential security consequences."  Either
> more specific guidance should be given, or the entire paragraph should
> be removed, as mh_id does not appear to have any security value.

Pasi suggested the paragraph which we agree to.

So how about replacing the last sentence with:

   "Even if the incorrect main header is passed, the standard
    JPEG 2000 decoder could detect inconsistency of the codestream
    and process it properly. It is recommended to clear the saved
    mh_id if the decoder detect such an inconsistency."

> In addition, there is a new open issue:
> [3] Section 7 does not appear to instruct IANA on what is to be done.
> It appears that IANA should add the new parameters in section 5 to
> the existing registration of a media type, but neither section 5
> nor section 7 tells IANA what do to or which media type registration
> is to be modified.

All right,

Here is the modification plan.

In Section 5:

   The document extends the associated media type "video/jpeg2000"
   from RFC XXXY [1]. Here are additional optional parameters.

> Nits:
> Reference [1] has still not been corrected.  The Gen-ART review of
> the -09 version stated:
>   Reference [1] should reference the Internet Draft by name.
>    [1]  Futemma, "RTP Payload Format for JPEG 2000 Video Streams",
>         RFC XXXY, April 2007.
>   I believe this is draft-ietf-avt-rtp-jpeg2000-18.txt.  That should
>   be in the reference instead of RFC XXXY.  Then add an RFC Editor
>   note asking the RFC Editor to replace all instances of RFC XXXY
>   with the RFC number assigned when reference [1] is published as an
> RFC.
> The version of this draft has now advanced to -19.

I agree.

Thank you and Best Regards,


Satoshi Futemma, Ph.D. /

Network Software Development Dept.,
Common Technology Div., Technology Development Group,
Sony Corporation
5-1-12 Kitashinagawa Shinagawa-ku, Tokyo, 141-0001 Japan
Tel. +81-3-5448-3175 / fax. +81-3-5448-6438
IETF mailing list