Subject: [AVT] Comments on draft-ietf-avt-rtp-jpeg2000-beam-03

From: Magnus Westerlund <[email-masked]>
Date: Mon, 13 Feb 2006 11:23:56 +0100

Hi,

I have reviewed the JPEG2000 payload format extensions and have the 
following comments.

1. The abstract contains references ([1]) which isn't allowed. Including 
the complete RFC number, currently as XXXX is fine.

2. Section 1. First sentence:
"This document is an extension of: "An RTP Payload Format for JPEG
    2000 Video Streams"[1]."

The reference doesn't use the correct title. There is no "An" in that title.

3. Section 1.1:
"  In the development of [1], Sony Corporation filed a patent
    application on certain mechanisms with the main header compensation,
    priority table usage, etc. in [1]."

I think is on the borderline to breaking the following rule of RFC 3979:

11.  No IPR Disclosures in IETF Documents

    IETF and RFC Editor Documents must not contain any mention of
    specific IPR.  All specific IPR disclosures must be submitted as
    described in Section 6.  Specific IPR disclosures must not be in the
    affected IETF and RFC Editor Documents because the reader could be
    misled.  The inclusion of a particular IPR disclosure in a document
    could be interpreted to mean that the IETF, IESG, or RFC Editor has
    formed an opinion on the validity, enforceability, or applicability
    of the IPR.  The reader could also be misled to think that the
    included IPR disclosures are the only IPR disclosures the IETF has
    received concerning the IETF document.  Readers should always refer
    to the on-line web page to get a full list of IPR disclosures
    received by the IETF concerning any Contribution.
    (http://www.ietf.org/ipr/)

I would recommend to reformulate that sentence:

"  In the development of [1], there was raised IPR claims on certain 
mechanisms with the main header compensation, priority table usage, etc. 
in [1]."

4. Section 3.1, last bullet:
"   o  When there are multiple JPEG 2000 packets in the same RTP payload
       packet, the sender MUST set the payload packet priority value to
       the lowest priority value of the lowest JPEG 2000 packet. (i.e. if
       JPEG 2000 packets with priority: 5,6,7 are packed into a single
       payload, the priority value MUST be 5.)"

The use of "lowest JPEG 2000 packet" is not clear to me.

Secondly, the usage of normative words in examples is not good. So 
please change "the priority value MUST be 5" to the priority value will 
be 5".

5. Section 3.1.1:
"   This is the default mode for payload packet priority value and all
    implementation of this specification MUST support."

I don't think this sentence is particular clear. I do understand the 
intention, but I think it can be formulated better.

6. Section 3.1.1:
The sender will have a one-to-one association between payload packet
    priority value and the payload packet value (i.e. the JPEG 2000
    codestream.)"

The terminology "packet value" is once more making things unclear in the 
above sentence.

7. Section 4.2:
"If the mh_id field is set to 0, the receiver MUST not save the main
  header and MUST NOT compensate for lost headers."
The first MUST NOT is lacking capital NOT.

8. Section 5. I think this security consideration section should be 
rewritten. If it starts with a reference to RFC XXXX [1] security 
section then it only need to cover security risks with the mechanism 
introduced in this document. All other things can be removed.

9. Section 6.1: As having a second companion document extend a media 
type is something not commonly done I am not 100% certain what the best 
practice will be. However I think you should have the extended media 
type be a complete registration with all parameters etc. That way one 
don't have as reviewer combine them in ones head. Thus [1] media type 
should be subset of the one in this document.

10. Section 6.1, priority-table-definitions. Is the list of values 
potentially extensible?

11. Section 6.1, comments on main draft regarding encoding consideration 
and restriction on usage (7 and 8) do apply also here.

12. Please do not use "none" in the magic number, file extension or 
Macintosh file type code, instead remove the headings.

13. Section 6.2, Please replace MIME with Media in second bullet.

14. Section 7, The offer/answer model, second bullet. I think this can 
be reformulated. The important aspects of all parameters are:
- How does the parameters work. To me it seems like negotiated 
parameters where both end-points uses the same values.
- How does they interact when the peers who don't support the extension. 
  although this is simple as the peer will leave them out of the message 
I think it is worth explaining that.

cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt