Authors,
While reviewing this document during AUTH48, please resolve (as necessary) the
following questions, which are also in the XML file.
1) <!-- [rfced] Document title
a) Please review the document title, especially "sub-codestream latency JPEG
2000 streaming". Would updating as follows (or in another way) improve
clarity?
Original:
RTP Payload Format for sub-codestream latency JPEG 2000 streaming
Current (title case):
RTP Payload Format for Sub-Codestream Latency JPEG 2000 Streaming
Perhaps:
RTP Payload Format for JPEG 2000 Streaming and Sub-Codestream Latency
b) We updated the abbreviated title (appears in the running header at the top
of each page in the pdf output) as follows because "JPEG 2000" (rather than
"J2K")
is used in this document. Are any further updates needed to align with the
document title?
Original:
Sub-codestream latency J2K over RTP
Current:
Sub-Codestream Latency JPEG 2000 over RTP
-->
2) <!-- [rfced] This is a question for Pierre-Anthony. In the first-page header
for this document, your name appears as "P.-A. Lemieux". However, we note
that in RFCs 7302 and 7972, your name appears as "P. Lemieux". We have
updated to use the single initial for consistency with those RFCs, but
please let us know if you prefer otherwise.
-->
3) <!-- [rfced] Abstract: We have updated this sentence as follows. Let us know
any concerns.
Original:
This RTP payload format defines the streaming of a video signal
encoded as a sequence of JPEG 2000 codestreams.
Perhaps:
This document defines the RTP payload format for the streaming of a video
signal
encoded as a sequence of JPEG 2000 codestreams.
-->
4) <!-- [rfced] Please clarify "to be emitted" here.
Original:
* the payload format allows sub-codestream latency such that the
first RTP packet of a given codestream to be emitted before the
entire codestream is available.
Perhaps:
* The payload format allows sub-codestream latency such that the
first RTP packet of a given codestream is emitted before the
entire codestream is available.
Or:
* The payload format allows sub-codestream latency such that the
first RTP packet of a given codestream can be emitted before the
entire codestream is available.
-->
5) <!-- [rfced] Figure 1
a) FYI - We moved both the text defining "P" in the figure and the sentence
about expansions in the figure title. These now follow the figure. Let us know
any concerns.
Original:
P = (Optional) padding bytes
Figure 1: Packetization of a sequence of JPEG 2000 codestreams
(not to scale). See Section 3 for an expansion of the SOC, SOD,
SOT and EOC abbreviations.
Updated:
Figure 1: Packetization of a sequence of JPEG 2000 codestreams
(not to scale).
In Figure 1, P denotes (optional) padding bytes. See Section 3 for
expansions of SOC, SOD, SOT, and EOC.
b) Would you like to add text before the figure to introduce it? If so, please
provide that text.
-->
6) <!-- [rfced] May we remove the square brackets here and update as follows?
Original:
ORDH (Progression Order [Main Packet]): 3 bits
...
ORDB (Progression Order [Body Packet]): 1 bit
Perhaps:
ORDH (Progression Order of Main Packet): 3 bits
...
ORDB (Progression Order of Body Packet): 1 bit
-->
7) <!-- [rfced] Would it be helpful to add a pointer to Section 3 here? This
section mentions LRCP, RLCP, RPCL, PCRL, CPRL, and PRCL - the pattern is
explained in Section 3.
Original:
ORDH (Progression Order [Main Packet]): 3 bits
Specifies the progression order used by the codestream and whether
resync points are signaled.
Perhaps:
ORDH (Progression Order of Main Packet): 3 bits
Specifies the progression order used by the codestream and whether
resync points are signaled. See Section 3 for details about progression
orders.
-->
8) <!-- [rfced] Will "no more than 45 ms = 4095/90,000" be clear to readers?
Original:
NOTE: As described in Sections 7.4 and 8.1, PTSTAMP is intended to
improve clock recovery at the receiver and only applies when the
transmission time of two consecutive RTP packets with identical
timestamp fields differ by no more than 45 ms = 4095/90,000.
Perhaps:
NOTE: As described in Sections 7.4 and 8.1, PTSTAMP is intended to
improve clock recovery at the receiver and only applies when the
transmission time of two consecutive RTP packets with identical
timestamp fields differ by no more than 45 ms (which is 4095/90,000).
-->
9) <!-- [rfced] It may be unclear to readers what is being connected by "and" in
this sentence. How may we clarify?
Original:
* MUST contain the same codestream main header information,
with the exception of the SOT and COM marker segments, and
any pointer marker segments; and
Perhaps:
* MUST contain the same codestream main header information
(with the exception of the SOT and COM marker segments) and
any pointer marker segments; and
Or:
* MUST contain the same codestream main header information
(with the exception of the SOT and COM marker segments and
any pointer marker segments); and
-->
10) <!-- [rfced] Would it be helpful to update the "Otherwise" part below as
follows? Right now, it is part of <dl> in the xml file; the suggested
update changes it to appear in <t>. (Note: We will update the QUAL
definition in the same way.)
Current:
RES (Resolution Levels): 3 bits
0 The payload can contribute to all resolution levels.
Otherwise The payload contains at least one byte of one JPEG 2000
packet belonging to resolution level (N_L + RES - 7) but does
not contain any byte of any JPEG 2000 packet belonging to lower
resolution levels. N_L is the number of decomposition levels
of the codestream.
Perhaps:
RES (Resolution Levels): 3 bits
0 The payload can contribute to all resolution levels.
Otherwise, the payload contains at least one byte of one JPEG 2000
packet belonging to resolution level (N_L + RES - 7) but does
not contain any byte of any JPEG 2000 packet belonging to lower
resolution levels. N_L is the number of decomposition levels
of the codestream.
-->
11) <!-- [rfced] How may we update "and as described at Section 8.7" and "and as
specified in Section 7.9" here for clarity?
Original:
When C = 1, and
as described at Section 8.7, a receiver maintains a simple cache of
previously received code-blocks, which it uses to replace empty code-
blocks.
...
When C = 1, and as specified in Section 7.9, the sender can improve
bandwidth efficiency by only occasionally transmitting code-blocks
corresponding to static portions of the video and otherwise
transmitting empty code-blocks, as defined in Section 7.9.
Perhaps (add parenthetical at end):
When C = 1, a receiver maintains a simple cache of
previously received code-blocks, which it uses to replace empty code-
blocks (see Section 8.7).
...
When C = 1, the sender can improve
bandwidth efficiency by only occasionally transmitting code-blocks
corresponding to static portions of the video and otherwise
transmitting empty code-blocks (see Section 7.9).
-->
12) <!-- [rfced] The titles of Tables 2 and 3 are very long. We suggest
including
shorter titles and folding the information in the current titles into the
text describing the figures. What are your thoughts? If you agree, please
provide updated titles and text in OLD/NEW format. Also, would it be
helpful to move the figures to appear after the text describing them?
Original:
Table 2: Optional discarding of Body Packets based on the value
of the RES field when decoding a reduced resolution image, in the
case where N_L = 5 and all DWT stages consist of both horizontal
and vertical transforms. The image has nominal width and height
of W x H.
...
Table 3: Optional discarding of Body Packets based on the value
of the RES field when decoding a reduced resolution image, in the
case where N_L = 5 and some DWT stages consist of only horizontal
transforms. The image has nominal width and height of W x H.
-->
13) <!-- [rfced] We updated "values XTRAC" to "values of XTRAC" here. Please
let us
know if this is incorrect.
Original:
The receiver MUST accept values XTRAC other than 0 and MUST ignore
the value of XTRAB, whose length is given by XTRAC.
Perhaps:
The receiver MUST accept values of XTRAC other than 0 and MUST ignore
the value of XTRAB, whose length is given by XTRAC.
-->
14) <!-- [rfced] How may we improve the introductory text here?
Original:
When decoding a codestream, and for each code-block in the
codestream:
* if the code-block in the codestream is empty, the receiver MUST
replace it with a matching code-block from the cache, if one
exists; or
* if the code-block in the codestream is not empty, the receiver
MUST replace any matching code-block from the cache with the code-
block in the codestream.
Perhaps:
When decoding a codestream, the following procedures apply for each
code-block in the codestream:
* If the code-block in the codestream is empty, the receiver MUST
replace it with a matching code-block from the cache, if one
exist.
* If the code-block in the codestream is not empty, the receiver
MUST replace any matching code-block from the cache with the code-
block in the codestream.
-->
15) <!-- [rfced] Media Type Template
a) Section 5.6 of RFC 6838 notes the following:
"N/A", written exactly that way, can be used in any field if desired
to emphasize the fact that it does not apply or that the question was
not omitted by accident. Do not use 'none' or other words that could
be mistaken for a response.
We have thus made the following update to the template in Section 9.2 of this
document. Let us know any concerns.
Original:
Required parameters: None
Updated:
Required parameters: N/A
b) We note that the template in Section 9.2 does not contain the "Fragment
identifier considerations:" and "Additional information:" sections of the
template defined in RFC 6838. We have added these as shown below. Let us know
if "N/A" is incorrect.
Updated:
Fragment identifier considerations: N/A
Additional information: N/A
-->
16) <!-- [rfced] We got an error when parsing the line of ABNF in Section 9.2.
We
used the parser at https://author-tools.ietf.org/abnf and added some definitions
from RFCs 3986 and 5234. Please review.
This is one of the definitions we added when parsing:
path-empty = 0<pchar>
And it seems to be causing this error:
(61:27): fyi: absolute repeat count of zero means this element may not occur
at all
-->
17) <!-- [rfced] References
a) Would you like the references to be alphabetized or left in their current
order?
b) The following references have been withdrawn or superseded and replaced by
newer versions. We updated the dates to the most recent version and added
URLs. Please review to ensure correctness.
[jpeg2000-1]
[jpeg2000-2]
[rec-itu-t-h273]
[jpeg2000-9]
c) FYI - We added URLs to the following reference entries. Please review.
[jpeg2000-15]
[ov2110-0]
-->
18) <!-- [rfced] Notes
a) In cases like the following with "stacked" notes (there are
several instances in the document), may we update as shown below?
Original:
NOTE: Only ORDH = 4 and ORDH = 6 allow sub-codestream latency
streaming.
NOTE: Progression order PRCL is defined in [jpeg2000-2]. The
other progression orders are specified in [jpeg2000-1].
Perhaps:
NOTES:
* Only ORDH = 4 and ORDH = 6 allow sub-codestream latency
streaming.
* Progression order PRCL is defined in [jpeg2000-2]. The
other progression orders are specified in [jpeg2000-1].
b) Section 5.1 has numbered notes (i.e., NOTE 1 and NOTE 2), but we don't see
this in other sections. Would you like to make these notes consistent with the
others in the document?
c) Please review whether any of the notes in this document
should be in the <aside> element. It is defined as "a container for
content that is semantically less important or tangential to the
content that surrounds it"
(https://authors.ietf.org/en/rfcxml-vocabulary#aside).
-->
19) <!-- [rfced] Terminology
a) We note inconsistencies in the terms below throughout the text. Should
these be uniform? If so, please let us know which form is preferred.
coded image data vs. image coded data
resolutions level vs. resolution level
Fixed Header vs. fixed header
Payload Header vs. payload header
Note: "main header" is consistently lowercase, and "Extended Header" is
consistently capitalized in this document.
b) We note inconsistencies in the term listed below. We chose the form on the
right. Please let us know any objections.
RTP Packet vs. RTP packet
c) This document consistently uses "code-block" and "code-byte" (with
hyphen). We see that "code-block" is used in the ITU-T documents referenced by
this document. However, "code-block" has not been used in the RFC Series, and
"code-byte" has only been used in one early RFC; the forms with no hyphen
(i.e., "code block" and "code byte") have been used.
Would you like to update to use the forms more commonly used in the RFC
Series, or do you prefer the current (which seems to align with ITU-T usage)?
-->
20) <!-- [rfced] Text styling
a) The file below lists terms enclosed in <tt> in this document.
Please review to ensure the usage of <tt> is correct and consistent. Let
us know if any updates are needed.
https://www.rfc-editor.org/authors/rfc9828-TT.txt
Note: In the html and pdf outputs, the text enclosed in <tt> appears in
fixed-width font. In the txt output, the text enclosed in <tt> has no
text formatting.
b) FYI - We updated <tt> to <artwork> for the following equations:
Original:
<extended sequence number> = <ESEQ field> * 65536 + <sequence
number field of the RTP fixed header>
...
PID = c + s * num_components
c) The following are the instances of <em> in the document. Please review and
confirm that the <em> is needed.
<em>empty</em>
<em>matching</em>
<em>c</em>
<em>s</em>
<em>num_components</em>
Note: In the html and pdf outputs, the text enclosed in <em> appears in
italics. In the txt output, the text enclosed in <em> appears with an
underline character before and after.
-->
21) <!-- [rfced] Abbreviations
a) Should "LSBs" be expanded as "least significant bits" here (or perhaps just
use the expansion since this is the only instance in the document)? Our list
also includes the expansion "Locator-Status-Bit". See
https://www.rfc-editor.org/rpc/wiki/doku.php?id=abbrev_list.
Original:
The counter is sampled at the point
in time when each RTP Packet is transmitted and the 12 LSBs of the
sample are stored in the PTSTAMP field.
b) How should "HT" be expanded? Below is the only instance in the document.
Original:
* if the code-block conforms to [jpeg2000-15], contains an HT
cleanup segment and the first two bytes of the Magsgn byte-stream
are between 0xFF80 and 0xFF8F.
-->
22) <!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->
Thank you.
RFC Editor/rv
On Aug 6, 2025, at 12:19 PM, [email protected] wrote:
*****IMPORTANT*****
Updated 2025/08/06
RFC Author(s):
--------------
Instructions for Completing AUTH48
Your document has now entered AUTH48. Once it has been reviewed and
approved by you and all coauthors, it will be published as an RFC.
If an author is no longer available, there are several remedies
available as listed in the FAQ (https://www.rfc-editor.org/faq/).
You and you coauthors are responsible for engaging other parties
(e.g., Contributors or Working Group) as necessary before providing
your approval.
Planning your review
---------------------
Please review the following aspects of your document:
* RFC Editor questions
Please review and resolve any questions raised by the RFC Editor
that have been included in the XML file as comments marked as
follows:
<!-- [rfced] ... -->
These questions will also be sent in a subsequent email.
* Changes submitted by coauthors
Please ensure that you review any changes submitted by your
coauthors. We assume that if you do not speak up that you
agree to changes submitted by your coauthors.
* Content
Please review the full content of the document, as this cannot
change once the RFC is published. Please pay particular attention to:
- IANA considerations updates (if applicable)
- contact information
- references
* Copyright notices and legends
Please review the copyright notice and legends as defined in
RFC 5378 and the Trust Legal Provisions
(TLP – https://trustee.ietf.org/license-info).
* Semantic markup
Please review the markup in the XML file to ensure that elements of
content are correctly tagged. For example, ensure that <sourcecode>
and <artwork> are set correctly. See details at
<https://authors.ietf.org/rfcxml-vocabulary>.
* Formatted output
Please review the PDF, HTML, and TXT files to ensure that the
formatted output, as generated from the markup in the XML file, is
reasonable. Please note that the TXT will have formatting
limitations compared to the PDF and HTML.
Submitting changes
------------------
To submit changes, please reply to this email using ‘REPLY ALL’ as all
the parties CCed on this message need to see your changes. The parties
include:
* your coauthors
* [email protected] (the RPC team)
* other document participants, depending on the stream (e.g.,
IETF Stream participants are your working group chairs, the
responsible ADs, and the document shepherd).
* [email protected], which is a new archival mailing list
to preserve AUTH48 conversations; it is not an active discussion
list:
* More info:
https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
* The archive itself:
https://mailarchive.ietf.org/arch/browse/auth48archive/
* Note: If only absolutely necessary, you may temporarily opt out
of the archiving of messages (e.g., to discuss a sensitive matter).
If needed, please add a note at the top of the message that you
have dropped the address. When the discussion is concluded,
[email protected] will be re-added to the CC list and
its addition will be noted at the top of the message.
You may submit your changes in one of two ways:
An update to the provided XML file
— OR —
An explicit list of changes in this format
Section # (or indicate Global)
OLD:
old text
NEW:
new text
You do not need to reply with both an updated XML file and an explicit
list of changes, as either form is sufficient.
We will ask a stream manager to review and approve any changes that seem
beyond editorial in nature, e.g., addition of new text, deletion of text,
and technical changes. Information about stream managers can be found in
the FAQ. Editorial changes do not require approval from a stream manager.
Approving for publication
--------------------------
To approve your RFC for publication, please reply to this email stating
that you approve this RFC for publication. Please use ‘REPLY ALL’,
as all the parties CCed on this message need to see your approval.
Files
-----
The files are available here:
https://www.rfc-editor.org/authors/rfc9828.xml
https://www.rfc-editor.org/authors/rfc9828.html
https://www.rfc-editor.org/authors/rfc9828.pdf
https://www.rfc-editor.org/authors/rfc9828.txt
Diff file of the text:
https://www.rfc-editor.org/authors/rfc9828-diff.html
https://www.rfc-editor.org/authors/rfc9828-rfcdiff.html (side by side)
Diff of the XML:
https://www.rfc-editor.org/authors/rfc9828-xmldiff1.html
Tracking progress
-----------------
The details of the AUTH48 status of your document are here:
https://www.rfc-editor.org/auth48/rfc9828
Please let us know if you have any questions.
Thank you for your cooperation,
RFC Editor
--------------------------------------
RFC9828 (draft-ietf-avtcore-rtp-j2k-scl-08)
Title : RTP Payload Format for sub-codestream latency JPEG 2000
streaming
Author(s) : P. Lemieux, Ed., D. Taubman
WG Chair(s) : Dr. Bernard D. Aboba, Jonathan Lennox
Area Director(s) : Gorry Fairhurst, Mike Bishop
--
auth48archive mailing list -- [email protected]
To unsubscribe send an email to [email protected]
