New I-D uploaded: https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-j2k-scl/06/ On Wed, Apr 30, 2025 at 7:39 AM Reese Enghardt <ietf@xxxxxxxxxxxxx> wrote: > > Hi all, > > Thanks for addressing the comments. > > I approved the three PRs, adding a nit to one. > > Best, > Reese > > > > On 4/29/25 18:54, Stephan Wenger wrote: > > 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 <pal@xxxxxxxxxxxx> 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 > >>> <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
