Hi Pierre, We have marked your approval on the AUTH48 status page for this document (see https://www.rfc-editor.org/auth48/rfc9828).
We will wait for David’s review and approval. Thank you! Rebecca RFC Production Center > On Aug 14, 2025, at 12:19 PM, Pierre-Anthony Lemieux <p...@sandflow.com> > wrote: > > Approved by me. > > @David Taubman What say you? > > On Thu, Aug 14, 2025 at 11:26 AM Rebecca VanRheenen > <rvanrhee...@staff.rfc-editor.org> wrote: >> >> Hi Pierre, >> >> Thank you for the reply. We have updated the document title. We also updated >> the abbreviated title (appears in the running header at the top of each page >> in the pdf output) as follows to align with the updated title: >> >> Original: >> Sub-Codestream Latency JPEG 2000 over RTP >> >> Current: >> JPEG 2000 Streaming with Sub-Codestream Latency >> >> All of our questions have now been addressed. Please review the document >> carefully to ensure satisfaction as we do not make changes once it has been >> published as an RFC. Contact us with any further updates or with your >> approval of the document in its current form. We will await approvals from >> each author prior to moving forward in the publication process. >> >> — FILES (please refresh) — >> >> Updated XML file: >> https://www.rfc-editor.org/authors/rfc9828.xml >> >> Updated output files: >> https://www.rfc-editor.org/authors/rfc9828.txt >> https://www.rfc-editor.org/authors/rfc9828.pdf >> https://www.rfc-editor.org/authors/rfc9828.html >> >> Diff file showing all changes made during AUTH48: >> https://www.rfc-editor.org/authors/rfc9828-auth48diff.html >> https://www.rfc-editor.org/authors/rfc9828-auth48rfcdiff.html (side by side) >> >> Diff files showing all changes: >> https://www.rfc-editor.org/authors/rfc9828-diff.html >> https://www.rfc-editor.org/authors/rfc9828-rfcdiff.html (side by side) >> >> For the AUTH48 status of this document, please see: >> https://www.rfc-editor.org/auth48/rfc9828 >> >> Thank you, >> >> Rebecca VanRheenen >> RFC Production Center >> >> >> >>> On Aug 13, 2025, at 9:19 PM, Pierre-Anthony Lemieux <p...@sandflow.com> >>> wrote: >>> >>> On Mon, Aug 11, 2025 at 9:25 PM Rebecca VanRheenen >>> <rvanrhee...@staff.rfc-editor.org> wrote: >>>> >>>> Hi Pierre, >>>> >>>> Thank you for addressing our questions. We have updated the document >>>> accordingly and have a few followup questions/comments: >>>> >>>> a) >>>>> >>>>>> >>>>>> 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 >>>> >>>> We did not make any changes to the document title, but we suggest updating >>>> to one of the following for clarity based on the information you provided >>>> above. What are your thoughts? >>>> >>>> Perhaps: >>>> RTP Payload Format for JPEG 2000 Streaming with Sub-Codestream Latency >>> >>> LGTM. This is a nice improvement. >>> >>> Everything else looks good as well. >>> >>>> >>>> Or: >>>> RTP Payload Format for JPEG 2000 Streaming with Optional Sub-Codestream >>>> Latency >>>> >>>> >>>> b) >>>>> >>>>>> >>>>>> 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. >>>> >>>> We updated to use your preferred initials! We’ll also note your preference >>>> for any future RFCs you author. >>>> >>>> >>>> c) >>>>> >>>>>> >>>>>> 17) <!-- [rfced] References >>>>>> >>>>>> a) Would you like the references to be alphabetized or left in their >>>>>> current >>>>>> order? >>>>> >>>>> No preference. >>>> >>>> We sorted the references alphabetically (most common ordering in the RFC >>>> Series). >>>> >>>> >>>> d) >>>>>> <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. >>>> >>>> We updated to use a definition list for these. Let us know any concerns. >>>> >>>> >>>> — FILES (please refresh) — >>>> >>>> Updated XML file: >>>> https://www.rfc-editor.org/authors/rfc9828.xml >>>> >>>> Updated output files: >>>> https://www.rfc-editor.org/authors/rfc9828.txt >>>> https://www.rfc-editor.org/authors/rfc9828.pdf >>>> https://www.rfc-editor.org/authors/rfc9828.html >>>> >>>> Diff file showing all changes made during AUTH48: >>>> https://www.rfc-editor.org/authors/rfc9828-auth48diff.html >>>> https://www.rfc-editor.org/authors/rfc9828-auth48rfcdiff.html (side by >>>> side) >>>> >>>> Diff files showing all changes: >>>> https://www.rfc-editor.org/authors/rfc9828-diff.html >>>> https://www.rfc-editor.org/authors/rfc9828-rfcdiff.html (side by side) >>>> >>>> For the AUTH48 status of this document, please see: >>>> https://www.rfc-editor.org/auth48/rfc9828 >>>> >>>> Thank you, >>>> >>>> RFC Editor/rv >>>> >>>> >>>> >>>>> On Aug 6, 2025, at 10:48 PM, Pierre-Anthony Lemieux <p...@sandflow.com> >>>>> wrote: >>>>> >>>>> 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
