Skip to main content

IETF Last Call Review of draft-ietf-avtcore-rtp-j2k-scl-05
review-ietf-avtcore-rtp-j2k-scl-05-genart-lc-enghardt-2025-04-25-00

Request Review of draft-ietf-avtcore-rtp-j2k-scl
Requested revision No specific revision (document currently at 08)
Type IETF Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2025-04-28
Requested 2025-04-14
Authors Pierre-Anthony Lemieux , David Taubman
I-D last updated 2025-06-13 (Latest revision 2025-06-13)
Completed reviews Secdir IETF Last Call review of -05 by Wes Hardaker (diff)
Genart IETF Last Call review of -05 by Reese Enghardt (diff)
Assignment Reviewer Reese Enghardt
State Completed
Request IETF Last Call review on draft-ietf-avtcore-rtp-j2k-scl by General Area Review Team (Gen-ART) Assigned
Posted at https://mailarchive.ietf.org/arch/msg/gen-art/jKQBYiicIwb4EjjkhOebTJt-ypQ
Reviewed revision 05 (document currently at 08)
Result Ready w/nits
Completed 2025-04-25
review-ietf-avtcore-rtp-j2k-scl-05-genart-lc-enghardt-2025-04-25-00
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.