Hi, Thanks for the detailed review. I have entered the issues at: https://github.com/ietf-wg-avtcore/draft-ietf-avtcore-rtp-j2k-scl/issues ... and addressed them at: https://github.com/ietf-wg-avtcore/draft-ietf-avtcore-rtp-j2k-scl/pulls I am not sure that action is required for issues #19 [1] given existing practice, but do not object to moving the registration information if needed. [1] https://github.com/ietf-wg-avtcore/draft-ietf-avtcore-rtp-j2k-scl/issues/19 Please let me know if the proposed resolutions work. Best, -- Pierre On Fri, Apr 25, 2025 at 2:07 PM Reese Enghardt via Datatracker <noreply@xxxxxxxx> wrote: > > Document: draft-ietf-avtcore-rtp-j2k-scl > Title: RTP Payload Format for sub-codestream latency JPEG 2000 streaming > Reviewer: Reese Enghardt > Review result: Ready with Nits > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. > > Document: draft-ietf-avtcore-rtp-j2k-scl-05 > Reviewer: Reese Enghardt > Review Date: 2025-04-25 > IETF LC End Date: 2025-04-28 > IESG Telechat date: Not scheduled for a telechat > > Summary: The document is clear and concise, and it is ready for publication as > Proposed Standard. Below are a few suggestions to make the document easier to > understand and potentially more consistent. > > Major issues: None. > > Minor issues: > > Intro: > "the payload format includes the following features specifically designed for > streaming applications" Does "streaming applications" mean specifically Live > streaming? If so, please consider being more specific here. In addition, please > consider adding a bit more context on why these features such as sub-codestream > latency are necessary and useful for use cases beyond prior RFCs. Similarly, > what is preferable about JPEG2000 for the intended use cases, rather than using > other options? Please consider adding a sentence or two. > > Section 3: > "JPEG 2000 represents an image as one or more components, e.g., R, G and B, > each uniformly sampled on a common rectangular reference grid." Please consider > providing a definition for component. Assuming that, for example, "R" means > only the red compontent of an image, does the above sentence imply that an > image could be only one component, e.g., only R, on a grid? > > "The coded image data ultimately consists of code-blocks, each containing coded > samples belonging to a rectangular (spatial) region within one resolution level > of one component." Please consider providing a definition for resolution level. > > "Resolution Layer (R) > The information needed to reconstruct the lower spatial resolutions of the > image come before the information needed to reconstruct the higher spatial > resolutions of the image" Is a resolution layer the same as a resolution > level? If so, please consider unifying the terminology here. > > Section 5: > This section references a "SOD marker", while Section 3 mentiones a "SOT > marker". Is this intentional, and if so, what is the difference between SOD and > SOT markers? The "SOT marker" also appears in Section 5.3, whereas the "SOD > marker" only appears in section 5.1. > > "When concatenated, the sequence of JPEG 2000 codestream fragments emitted by > the sender MUST be a sequence of JPEG 2000 codestreams where two successive > JPEG 2000 codestreams MAY be separated by one or more arbitrary padding bytes > (see Figure 1)." In the "Packets" in Figure 1, is each component delineated as > "Main" or "Body" a single packet, or is it a sequence of packets? Does packet > still mean RTP packet here? Please consider stating this explicitly when > describing the figure. > > "A JPEG 2000 codestream fragment does not necessarily contain complete JPEG > 2000 packets, as defined in [jpeg2000-1]." Is a JPEG 2000 packet different from > an RTP packet? If so, how? Please consider defining a JPEG 2000 packet. > > Section 9: > Is it intentional to provide the registry information in this section, rather > than under "IANA Considerations" where many IETF readers would expect it? > Please consider moving it under "IANA Considerations". > > Nits/editorial comments: None. > > -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
