Hi David and Pierre, David - Thank you for your reply. We have noted your approval on the AUTH48 status page for this document. See https://www.rfc-editor.org/auth48/rfc9828.
David and Pierre - We have one additional question. The following sentence appears in Section 9.2 of the document. May we update "height and width parameters of the media type specified in Section 9.2” to "height and width parameters of this media type”? Current: For example, the JPEG 2000 syntax allows image height and width up to 2^32 - 1 pixels, which is also captured in the syntax of the height and width parameters of the media type specified in Section 9.2. Perhaps: For example, the JPEG 2000 syntax allows image height and width up to 2^32 - 1 pixels, which is also captured in the syntax of the height and width parameters of this media type. Once this question is resolved, we will ask IANA to update the template at https://www.iana.org/assignments/media-types/video/jpeg2000-scl to match the edited document and then begin to prepare the document for publication. Thank you, Rebecca VanRheenen RFC Production Center > On Aug 16, 2025, at 10:19 PM, David Taubman <d.taub...@unsw.edu.au> wrote: > > Approved by me also. > > Thanks, Rebecca. > — > Professor David Taubman > Deputy Head of School (Strategy) > School of Electrical Engineering and Telecommunications > UNSW Sydney, > NSW 2052, Australia > > Email: d.taub...@unsw.edu.au > Phone: +61 2 9385 5223 > > > > >> On 15 Aug 2025, at 5:19 am, 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 >>>>>>> >>>>>> >>>>> >>> > > > Confidential communication - This email and any files transmitted with it are > confidential and are intended solely for the addressee. If you are not the > intended recipient, please be advised that you have received this email in > error and that any use, dissemination, forwarding, printing, or copying of > this email and any file attachments is strictly prohibited. If you have > received this email in error, please notify me immediately by return email > and destroy this email. > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
