Hi Pierre and David, We have received all needed approvals, and IANA has updated the template to match the edited document. We now consider AUTH48 complete:
https://www.rfc-editor.org/auth48/rfc9828 We will begin to prepare the document for publication at this time. Thank you for your attention and guidance during the AUTH48 process! Best regards, Rebecca VanRheenen RFC Production Center > On Aug 19, 2025, at 9:36 PM, Rebecca VanRheenen > <rvanrhee...@staff.rfc-editor.org> wrote: > > Hi David, > > Thanks for updating! > > Best regards, > Rebecca > > > >> On Aug 18, 2025, at 5:32 PM, David Dong via RT <iana-mat...@iana.org> wrote: >> >> Hi Rebecca, >> >> We've updated the template: >> >> https://www.iana.org/assignments/media-types/video/jpeg2000-scl >> >> Thank you. >> >> Best regards, >> >> David Dong >> IANA Services Sr. Specialist >> >> On Mon Aug 18 20:55:54 2025, rvanrhee...@staff.rfc-editor.org wrote: >>> IANA, >>> >>> Please update the media type registration at >>> https://www.iana.org/assignments/media-types/video/jpeg2000-scl to >>> match the template in Section 9.2 of RFC-to-be 9828. >>> >>> Here are the edited files: >>> >>> https://www.rfc-editor.org/authors/rfc9828.txt >>> https://www.rfc-editor.org/authors/rfc9828-diff.html >>> >>> Please let us know when this updates are complete. >>> >>> Thank you, >>> >>> Rebecca VanRheenen >>> RFC Production Center >>> >>> >>> >>>> On Aug 18, 2025, at 1:44 PM, Pierre-Anthony Lemieux >>>> <p...@sandflow.com> wrote: >>>> >>>> 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
