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.
 The review of the -09 version stated "Section 4.1 contains this
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:
 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.
Here is the modification plan.
In Section 5:
The document extends the associated media type "video/jpeg2000"
from RFC XXXY . Here are additional optional parameters.
Reference  has still not been corrected. The Gen-ART review of
the -09 version stated:
Reference  should reference the Internet Draft by name.
 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  is published as an
The version of this draft has now advanced to -19.
Thank you and Best Regards,
Satoshi Futemma, Ph.D. / satosi-f(_at_)sm(_dot_)sony(_dot_)co(_dot_)jp
Network Software Development Dept.,
Common Technology Div., Technology Development Group,
5-1-12 Kitashinagawa Shinagawa-ku, Tokyo, 141-0001 Japan
Tel. +81-3-5448-3175 / fax. +81-3-5448-6438
IETF mailing list