Approved. On Mon, Aug 18, 2025 at 1:43 PM Rebecca VanRheenen <rvanrhee...@staff.rfc-editor.org> wrote: > > 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
