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
