Futemma-san, > I have sent the mail about the priority mapping of > progression based ordering. > So, I reply to the other comments on the mail. > > [EMAIL PROTECTED] 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.
Please *remove* the quoted sentence from Section 4.1. There is essentially no security value in a random number that is limited to 7 possible values. If that sentence is going to remain in Section 4.1, the words "for security purposes" should be removed. > > 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." Ok. > > 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. Ok. > > 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. Ok. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 [EMAIL PROTECTED] Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
