Hi Pierre, Regarding the media-tupes registration and IANA considerations section: you indeed followed established practice and the guidelines of RFC8088 as updated. My recommendation is to keep the section organization “as is”. Stephan Sent from my iPhone
> On Apr 29, 2025, at 13:26, Pierre-Anthony Lemieux <[email protected]> wrote: > > 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 >> <[email protected]> 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. >> >> _______________________________________________ Gen-art mailing list -- [email protected] To unsubscribe send an email to [email protected]
