CIL. Many thanks for the thorough review. On Wed, Aug 6, 2025 at 12:30 PM <rfc-edi...@rfc-editor.org> wrote: > > 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
This works. The RTP Payload allows streaming of JPEG 2000 imagery with (optionally) sub-codestream latency. > > Perhaps: > RTP Payload Format for JPEG 2000 Streaming and Sub-Codestream Latency I feel the "and" is misleading since "sub-codestream" is specific to JPEG 2000 (each image is encoded as an independent codestream) and the RTP format allows the first RTP packet for a given image to be emitted before the entire image is available to or encoded by the sender > > > 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 LGTM > --> > > > 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. There are too many P. Lemieux, so I started using P.-A. Lemieux as with my earlier academic papers, e.g. https://journals.aps.org/prd/abstract/10.1103/PhysRevD.55.3873 Not a big deal if IETF prefers to stick with P. Lemieux. > --> > > > 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. LGTM > --> > > > 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. I suggest matching the abstract: The payload format allows sub-codestream latency such that the first RTP packet for a given image can be emitted before the entire image is available to or encoded by the sender. > --> > > > 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. LGTM > > 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. No text needed. > --> > > > 6) <!-- [rfced] May we remove the square brackets here and update as follows? It is not the Progression Order *of* the Main or Body packet, but progression-order-related-signaling *in* the Main or Body packet. What about "Progression Order Flag, Main Packet" and "Progression Order Flag, Body Packet"? > > 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. LGTM. > > 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). "Perhaps" LGTM > --> > > > 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 "Or" proposal LGTM. > --> > > > 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.) Semantically, it is preferable that "otherwise" be in its own <dt> since it is an alternative to "0". > > 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). "Perhaps" LGTM > --> > > > 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. After playing with this for a while I have not found a way to meaningfully reduce the length of table captions, without risking introducing errors/confusion in these complex examples. [ed.: I was not aware of the size limit and will endeavor to steer clear of it in future documents :)] > --> > > > 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. LGTM > --> > > > 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. LGTM > --> > > > 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 LGTM > > > 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 LGTM > --> > > > 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 I believe this is intended: the path component of a URI can be empty. ("The scheme and path components are required, though the path may be empty (no characters)." > --> > > > 17) <!-- [rfced] References > > a) Would you like the references to be alphabetized or left in their current > order? No preference. > > 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] The [ov2110-0] URL should be: https://pub.smpte.org/doc/ov2110-0/20181204-pub/ > --> > > > 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? I am not a big fan of stacking these notes since they are not directly related and should be referenceable individually. There is however a bug in the current draft, and the first note should be numbered "1" and the second numbered "2". > > 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? All notes should be numbered unless there is only one note in a section. The idea is to be able to refer to a note like "Section 4.2, Note 1". Makes sense? > > > 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). I have not found a use for <aside> in this specification. > --> > > > 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 "image coded data" should be "coded image data" > > resolutions level vs. resolution level "resolutions level(s)" should be "resolution level(s)" > > Fixed Header vs. fixed header "RTP fixed header" should be "RTP Fixed Header" > > Payload Header vs. payload header > Note: "main header" is consistently lowercase, and "Extended Header" is > consistently capitalized in this document. "Main Packet Payload Header" and "Body Packet Payload Header" should be capitalized because they refer to a specific structure. "payload header" in isolation is less specific can be kept lowercase. Ok? > > > 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 It should be "RTP packet" for consistency with RFC 3550. > > > 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)? I think ITU/ISO folks would rebel if we dropped the hyphen. > --> > > > 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 LGTM > > > 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> for the two terms above implies a definition, i.e., the term is reused in a specific way in surrounding text. It feels like an appropriate use of <em>. > <em>c</em> > <em>s</em> > <em>num_components</em> <em> for the terms above implies a mathematical symbol used in a formulae. Not sure it is wise or necessary. Please advise. > > 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. Yes, please expand to "least significant bits". > > > 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. "HT cleanup segment" is a defined term from ITU T.814. > --> > > > 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, rfc-edi...@rfc-editor.org 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 > > * rfc-edi...@rfc-editor.org (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). > > * auth48archive@rfc-editor.org, 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, > auth48archive@rfc-editor.org 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 -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
