On Mon, Aug 11, 2025 at 9:25 PM Rebecca VanRheenen <rvanrhee...@staff.rfc-editor.org> wrote: > > Hi Pierre, > > Thank you for addressing our questions. We have updated the document > accordingly and have a few followup questions/comments: > > a) > > > >> > >> 1) <!-- [rfced] Document title > >> > >> a) Please review the document title, especially "sub-codestream latency > >> JPEG > >> 2000 streaming". Would updating as follows (or in another way) improve > >> clarity? > >> > >> Original: > >> RTP Payload Format for sub-codestream latency JPEG 2000 streaming > >> > >> Current (title case): > >> RTP Payload Format for Sub-Codestream Latency JPEG 2000 Streaming > > > > This works. The RTP Payload allows streaming of JPEG 2000 imagery with > > (optionally) sub-codestream latency. > > > >> > >> Perhaps: > >> RTP Payload Format for JPEG 2000 Streaming and Sub-Codestream Latency > > > > I feel the "and" is misleading since "sub-codestream" is specific to JPEG > > 2000 (each image is encoded as an independent codestream) and the RTP > > format allows > > the first RTP packet for a given image to be emitted > > before the entire image is available to or encoded by the sender > > We did not make any changes to the document title, but we suggest updating to > one of the following for clarity based on the information you provided above. > What are your thoughts? > > Perhaps: > RTP Payload Format for JPEG 2000 Streaming with Sub-Codestream Latency
LGTM. This is a nice improvement. Everything else looks good as well. > > Or: > RTP Payload Format for JPEG 2000 Streaming with Optional Sub-Codestream > Latency > > > b) > > > >> > >> 2) <!-- [rfced] This is a question for Pierre-Anthony. In the first-page > >> header > >> for this document, your name appears as "P.-A. Lemieux". However, we note > >> that in RFCs 7302 and 7972, your name appears as "P. Lemieux". We have > >> updated to use the single initial for consistency with those RFCs, but > >> please let us know if you prefer otherwise. > > > > There are too many P. Lemieux, so I started using P.-A. Lemieux as with my > > earlier academic papers, e.g. > > https://journals.aps.org/prd/abstract/10.1103/PhysRevD.55.3873 > > Not a big deal if IETF prefers to stick with P. Lemieux. > > We updated to use your preferred initials! We’ll also note your preference > for any future RFCs you author. > > > c) > > > >> > >> 17) <!-- [rfced] References > >> > >> a) Would you like the references to be alphabetized or left in their > >> current > >> order? > > > > No preference. > > We sorted the references alphabetically (most common ordering in the RFC > Series). > > > d) > >> <em>c</em> > >> <em>s</em> > >> <em>num_components</em> > > > > <em> for the terms above implies a mathematical symbol used in a > > formulae. Not sure it is wise or necessary. Please advise. > > We updated to use a definition list for these. Let us know any concerns. > > > — FILES (please refresh) — > > Updated XML file: > https://www.rfc-editor.org/authors/rfc9828.xml > > Updated output files: > https://www.rfc-editor.org/authors/rfc9828.txt > https://www.rfc-editor.org/authors/rfc9828.pdf > https://www.rfc-editor.org/authors/rfc9828.html > > Diff file showing all changes made during AUTH48: > https://www.rfc-editor.org/authors/rfc9828-auth48diff.html > https://www.rfc-editor.org/authors/rfc9828-auth48rfcdiff.html (side by > side) > > Diff files showing all changes: > https://www.rfc-editor.org/authors/rfc9828-diff.html > https://www.rfc-editor.org/authors/rfc9828-rfcdiff.html (side by side) > > For the AUTH48 status of this document, please see: > https://www.rfc-editor.org/auth48/rfc9828 > > Thank you, > > RFC Editor/rv > > > > > On Aug 6, 2025, at 10:48 PM, Pierre-Anthony Lemieux <p...@sandflow.com> > > wrote: > > > > CIL. Many thanks for the thorough review. > > > > On Wed, Aug 6, 2025 at 12:30 PM <rfc-edi...@rfc-editor.org> wrote: > >> > >> Authors, > >> > >> While reviewing this document during AUTH48, please resolve (as necessary) > >> the following questions, which are also in the XML file. > >> > >> > >> 1) <!-- [rfced] Document title > >> > >> a) Please review the document title, especially "sub-codestream latency > >> JPEG > >> 2000 streaming". Would updating as follows (or in another way) improve > >> clarity? > >> > >> Original: > >> RTP Payload Format for sub-codestream latency JPEG 2000 streaming > >> > >> Current (title case): > >> RTP Payload Format for Sub-Codestream Latency JPEG 2000 Streaming > > > > This works. The RTP Payload allows streaming of JPEG 2000 imagery with > > (optionally) sub-codestream latency. > > > >> > >> Perhaps: > >> RTP Payload Format for JPEG 2000 Streaming and Sub-Codestream Latency > > > > I feel the "and" is misleading since "sub-codestream" is specific to JPEG > > 2000 (each image is encoded as an independent codestream) and the RTP > > format allows > > the first RTP packet for a given image to be emitted > > before the entire image is available to or encoded by the sender > > > >> > >> > >> b) We updated the abbreviated title (appears in the running header at the > >> top > >> of each page in the pdf output) as follows because "JPEG 2000" (rather > >> than "J2K") > >> is used in this document. Are any further updates needed to align with the > >> document title? > >> > >> Original: > >> Sub-codestream latency J2K over RTP > >> > >> Current: > >> Sub-Codestream Latency JPEG 2000 over RTP > > > > LGTM > > > >> --> > >> > >> > >> 2) <!-- [rfced] This is a question for Pierre-Anthony. In the first-page > >> header > >> for this document, your name appears as "P.-A. Lemieux". However, we note > >> that in RFCs 7302 and 7972, your name appears as "P. Lemieux". We have > >> updated to use the single initial for consistency with those RFCs, but > >> please let us know if you prefer otherwise. > > > > There are too many P. Lemieux, so I started using P.-A. Lemieux as with my > > earlier academic papers, e.g. > > https://journals.aps.org/prd/abstract/10.1103/PhysRevD.55.3873 > > Not a big deal if IETF prefers to stick with P. Lemieux. > > > >> --> > >> > >> > >> 3) <!-- [rfced] Abstract: We have updated this sentence as follows. Let us > >> know > >> any concerns. > >> > >> Original: > >> This RTP payload format defines the streaming of a video signal > >> encoded as a sequence of JPEG 2000 codestreams. > >> > >> Perhaps: > >> This document defines the RTP payload format for the streaming of a > >> video signal > >> encoded as a sequence of JPEG 2000 codestreams. > > > > LGTM > > > >> --> > >> > >> > >> 4) <!-- [rfced] Please clarify "to be emitted" here. > >> > >> Original: > >> * the payload format allows sub-codestream latency such that the > >> first RTP packet of a given codestream to be emitted before the > >> entire codestream is available. > >> > >> Perhaps: > >> * The payload format allows sub-codestream latency such that the > >> first RTP packet of a given codestream is emitted before the > >> entire codestream is available. > >> > >> Or: > >> * The payload format allows sub-codestream latency such that the > >> first RTP packet of a given codestream can be emitted before the > >> entire codestream is available. > > > > I suggest matching the abstract: The payload format allows > > sub-codestream latency such that the first RTP packet for a given image can > > be emitted before the entire image is available to or encoded by the sender. > > > >> --> > >> > >> > >> 5) <!-- [rfced] Figure 1 > >> > >> a) FYI - We moved both the text defining "P" in the figure and the sentence > >> about expansions in the figure title. These now follow the figure. Let us > >> know > >> any concerns. > > > > LGTM > > > >> > >> Original: > >> P = (Optional) padding bytes > >> > >> Figure 1: Packetization of a sequence of JPEG 2000 codestreams > >> (not to scale). See Section 3 for an expansion of the SOC, SOD, > >> SOT and EOC abbreviations. > >> > >> Updated: > >> Figure 1: Packetization of a sequence of JPEG 2000 codestreams > >> (not to scale). > >> > >> In Figure 1, P denotes (optional) padding bytes. See Section 3 for > >> expansions of SOC, SOD, SOT, and EOC. > >> > >> b) Would you like to add text before the figure to introduce it? If so, > >> please > >> provide that text. > > > > No text needed. > > > >> --> > >> > >> > >> 6) <!-- [rfced] May we remove the square brackets here and update as > >> follows? > > > > It is not the Progression Order *of* the Main or Body packet, but > > progression-order-related-signaling *in* the Main or Body packet. What > > about "Progression Order Flag, Main Packet" and "Progression Order > > Flag, Body Packet"? > > > >> > >> Original: > >> ORDH (Progression Order [Main Packet]): 3 bits > >> ... > >> ORDB (Progression Order [Body Packet]): 1 bit > >> > >> Perhaps: > >> ORDH (Progression Order of Main Packet): 3 bits > >> ... > >> ORDB (Progression Order of Body Packet): 1 bit > >> --> > >> > >> > >> 7) <!-- [rfced] Would it be helpful to add a pointer to Section 3 here? > >> This > >> section mentions LRCP, RLCP, RPCL, PCRL, CPRL, and PRCL - the pattern is > >> explained in Section 3. > > > > LGTM. > > > >> > >> Original: > >> ORDH (Progression Order [Main Packet]): 3 bits > >> > >> Specifies the progression order used by the codestream and whether > >> resync points are signaled. > >> > >> Perhaps: > >> ORDH (Progression Order of Main Packet): 3 bits > >> > >> Specifies the progression order used by the codestream and whether > >> resync points are signaled. See Section 3 for details about > >> progression orders. > >> --> > >> > >> > >> 8) <!-- [rfced] Will "no more than 45 ms = 4095/90,000" be clear to > >> readers? > >> > >> Original: > >> NOTE: As described in Sections 7.4 and 8.1, PTSTAMP is intended to > >> improve clock recovery at the receiver and only applies when the > >> transmission time of two consecutive RTP packets with identical > >> timestamp fields differ by no more than 45 ms = 4095/90,000. > >> > >> Perhaps: > >> NOTE: As described in Sections 7.4 and 8.1, PTSTAMP is intended to > >> improve clock recovery at the receiver and only applies when the > >> transmission time of two consecutive RTP packets with identical > >> timestamp fields differ by no more than 45 ms (which is 4095/90,000). > > > > "Perhaps" LGTM > > > >> --> > >> > >> > >> 9) <!-- [rfced] It may be unclear to readers what is being connected by > >> "and" in > >> this sentence. How may we clarify? > >> > >> Original: > >> * MUST contain the same codestream main header information, > >> with the exception of the SOT and COM marker segments, and > >> any pointer marker segments; and > >> > >> Perhaps: > >> * MUST contain the same codestream main header information > >> (with the exception of the SOT and COM marker segments) and > >> any pointer marker segments; and > >> > >> Or: > >> * MUST contain the same codestream main header information > >> (with the exception of the SOT and COM marker segments and > >> any pointer marker segments); and > > > > "Or" proposal LGTM. > > > >> --> > >> > >> > >> 10) <!-- [rfced] Would it be helpful to update the "Otherwise" part below > >> as > >> follows? Right now, it is part of <dl> in the xml file; the suggested > >> update changes it to appear in <t>. (Note: We will update the QUAL > >> definition in the same way.) > > > > Semantically, it is preferable that "otherwise" be in its own <dt> > > since it is an > > alternative to "0". > > > >> > >> Current: > >> RES (Resolution Levels): 3 bits > >> > >> 0 The payload can contribute to all resolution levels. > >> > >> Otherwise The payload contains at least one byte of one JPEG 2000 > >> packet belonging to resolution level (N_L + RES - 7) but does > >> not contain any byte of any JPEG 2000 packet belonging to lower > >> resolution levels. N_L is the number of decomposition levels > >> of the codestream. > >> > >> Perhaps: > >> RES (Resolution Levels): 3 bits > >> > >> 0 The payload can contribute to all resolution levels. > >> > >> Otherwise, the payload contains at least one byte of one JPEG 2000 > >> packet belonging to resolution level (N_L + RES - 7) but does > >> not contain any byte of any JPEG 2000 packet belonging to lower > >> resolution levels. N_L is the number of decomposition levels > >> of the codestream. > >> --> > >> > >> > >> 11) <!-- [rfced] How may we update "and as described at Section 8.7" and > >> "and as > >> specified in Section 7.9" here for clarity? > > > >> > >> Original: > >> When C = 1, and > >> as described at Section 8.7, a receiver maintains a simple cache of > >> previously received code-blocks, which it uses to replace empty code- > >> blocks. > >> ... > >> When C = 1, and as specified in Section 7.9, the sender can improve > >> bandwidth efficiency by only occasionally transmitting code-blocks > >> corresponding to static portions of the video and otherwise > >> transmitting empty code-blocks, as defined in Section 7.9. > >> > >> Perhaps (add parenthetical at end): > >> When C = 1, a receiver maintains a simple cache of > >> previously received code-blocks, which it uses to replace empty code- > >> blocks (see Section 8.7). > >> ... > >> When C = 1, the sender can improve > >> bandwidth efficiency by only occasionally transmitting code-blocks > >> corresponding to static portions of the video and otherwise > >> transmitting empty code-blocks (see Section 7.9). > > > > "Perhaps" LGTM > > > >> --> > >> > >> > >> 12) <!-- [rfced] The titles of Tables 2 and 3 are very long. We suggest > >> including > >> shorter titles and folding the information in the current titles into the > >> text describing the figures. What are your thoughts? If you agree, please > >> provide updated titles and text in OLD/NEW format. Also, would it be > >> helpful to move the figures to appear after the text describing them? > >> > >> Original: > >> Table 2: Optional discarding of Body Packets based on the value > >> of the RES field when decoding a reduced resolution image, in the > >> case where N_L = 5 and all DWT stages consist of both horizontal > >> and vertical transforms. The image has nominal width and height > >> of W x H. > >> ... > >> Table 3: Optional discarding of Body Packets based on the value > >> of the RES field when decoding a reduced resolution image, in the > >> case where N_L = 5 and some DWT stages consist of only horizontal > >> transforms. The image has nominal width and height of W x H. > > > > After playing with this for a while I have not found a way to > > meaningfully reduce > > the length of table captions, without risking introducing errors/confusion > > in > > these complex examples. [ed.: I was not aware of the size limit and > > will endeavor > > to steer clear of it in future documents :)] > > > >> --> > >> > >> > >> 13) <!-- [rfced] We updated "values XTRAC" to "values of XTRAC" here. > >> Please let us > >> know if this is incorrect. > >> > >> Original: > >> The receiver MUST accept values XTRAC other than 0 and MUST ignore > >> the value of XTRAB, whose length is given by XTRAC. > >> > >> Perhaps: > >> The receiver MUST accept values of XTRAC other than 0 and MUST ignore > >> the value of XTRAB, whose length is given by XTRAC. > > > > LGTM > > > >> --> > >> > >> > >> 14) <!-- [rfced] How may we improve the introductory text here? > >> > >> Original: > >> When decoding a codestream, and for each code-block in the > >> codestream: > >> > >> * if the code-block in the codestream is empty, the receiver MUST > >> replace it with a matching code-block from the cache, if one > >> exists; or > >> > >> * if the code-block in the codestream is not empty, the receiver > >> MUST replace any matching code-block from the cache with the code- > >> block in the codestream. > >> > >> Perhaps: > >> When decoding a codestream, the following procedures apply for each > >> code-block in the codestream: > >> > >> * If the code-block in the codestream is empty, the receiver MUST > >> replace it with a matching code-block from the cache, if one > >> exist. > >> > >> * If the code-block in the codestream is not empty, the receiver > >> MUST replace any matching code-block from the cache with the code- > >> block in the codestream. > > > > LGTM > > > >> --> > >> > >> > >> 15) <!-- [rfced] Media Type Template > >> > >> a) Section 5.6 of RFC 6838 notes the following: > >> > >> "N/A", written exactly that way, can be used in any field if desired > >> to emphasize the fact that it does not apply or that the question was > >> not omitted by accident. Do not use 'none' or other words that could > >> be mistaken for a response. > >> > >> We have thus made the following update to the template in Section 9.2 of > >> this > >> document. Let us know any concerns. > >> > >> Original: > >> Required parameters: None > >> > >> Updated: > >> Required parameters: N/A > > > > LGTM > > > >> > >> > >> b) We note that the template in Section 9.2 does not contain the "Fragment > >> identifier considerations:" and "Additional information:" sections of the > >> template defined in RFC 6838. We have added these as shown below. Let us > >> know > >> if "N/A" is incorrect. > >> > >> Updated: > >> Fragment identifier considerations: N/A > >> > >> Additional information: N/A > > > > LGTM > > > >> --> > >> > >> > >> 16) <!-- [rfced] We got an error when parsing the line of ABNF in Section > >> 9.2. We > >> used the parser at https://author-tools.ietf.org/abnf and added some > >> definitions > >> from RFCs 3986 and 5234. Please review. > >> > >> This is one of the definitions we added when parsing: > >> path-empty = 0<pchar> > >> > >> And it seems to be causing this error: > >> (61:27): fyi: absolute repeat count of zero means this element may not > >> occur at all > > > > I believe this is intended: the path component of a URI can be empty. > > ("The scheme and path components are required, though the path may be > > empty (no characters)." > > > >> --> > >> > >> > >> 17) <!-- [rfced] References > >> > >> a) Would you like the references to be alphabetized or left in their > >> current > >> order? > > > > No preference. > > > >> > >> b) The following references have been withdrawn or superseded and replaced > >> by > >> newer versions. We updated the dates to the most recent version and added > >> URLs. Please review to ensure correctness. > >> > >> [jpeg2000-1] > >> [jpeg2000-2] > >> [rec-itu-t-h273] > >> [jpeg2000-9] > >> > >> c) FYI - We added URLs to the following reference entries. Please review. > >> > >> [jpeg2000-15] > >> [ov2110-0] > > > > The [ov2110-0] URL should be: > > https://pub.smpte.org/doc/ov2110-0/20181204-pub/ > > > >> --> > >> > >> > >> 18) <!-- [rfced] Notes > >> > >> a) In cases like the following with "stacked" notes (there are > >> several instances in the document), may we update as shown below? > > > > I am not a big fan of stacking these notes since they are not directly > > related > > and should be referenceable individually. There is however a bug in > > the current draft, and the first note should be numbered "1" and the > > second numbered "2". > > > >> > >> Original: > >> NOTE: Only ORDH = 4 and ORDH = 6 allow sub-codestream latency > >> streaming. > >> > >> NOTE: Progression order PRCL is defined in [jpeg2000-2]. The > >> other progression orders are specified in [jpeg2000-1]. > >> > >> Perhaps: > >> NOTES: > >> > >> * Only ORDH = 4 and ORDH = 6 allow sub-codestream latency > >> streaming. > >> > >> * Progression order PRCL is defined in [jpeg2000-2]. The > >> other progression orders are specified in [jpeg2000-1]. > >> > >> > >> b) Section 5.1 has numbered notes (i.e., NOTE 1 and NOTE 2), but we don't > >> see > >> this in other sections. Would you like to make these notes consistent with > >> the > >> others in the document? > > > > All notes should be numbered unless there is only one note in a section. The > > idea is to be able to refer to a note like "Section 4.2, Note 1". Makes > > sense? > > > >> > >> > >> c) Please review whether any of the notes in this document > >> should be in the <aside> element. It is defined as "a container for > >> content that is semantically less important or tangential to the > >> content that surrounds it" > >> (https://authors.ietf.org/en/rfcxml-vocabulary#aside). > > > > I have not found a use for <aside> in this specification. > > > >> --> > >> > >> > >> 19) <!-- [rfced] Terminology > >> > >> a) We note inconsistencies in the terms below throughout the text. Should > >> these be uniform? If so, please let us know which form is preferred. > >> > >> coded image data vs. image coded data > > > > "image coded data" should be "coded image data" > > > >> > >> resolutions level vs. resolution level > > > > "resolutions level(s)" should be "resolution level(s)" > > > >> > >> Fixed Header vs. fixed header > > > > "RTP fixed header" should be "RTP Fixed Header" > > > >> > >> Payload Header vs. payload header > >> Note: "main header" is consistently lowercase, and "Extended Header" is > >> consistently capitalized in this document. > > > > "Main Packet Payload Header" and "Body Packet Payload Header" should > > be capitalized because they refer to a specific structure. "payload > > header" in isolation is less specific can be kept lowercase. Ok? > > > >> > >> > >> b) We note inconsistencies in the term listed below. We chose the form on > >> the > >> right. Please let us know any objections. > >> > >> RTP Packet vs. RTP packet > > > > It should be "RTP packet" for consistency with RFC 3550. > > > >> > >> > >> c) This document consistently uses "code-block" and "code-byte" (with > >> hyphen). We see that "code-block" is used in the ITU-T documents > >> referenced by > >> this document. However, "code-block" has not been used in the RFC Series, > >> and > >> "code-byte" has only been used in one early RFC; the forms with no hyphen > >> (i.e., "code block" and "code byte") have been used. > >> > >> Would you like to update to use the forms more commonly used in the RFC > >> Series, or do you prefer the current (which seems to align with ITU-T > >> usage)? > > > > I think ITU/ISO folks would rebel if we dropped the hyphen. > > > >> --> > >> > >> > >> 20) <!-- [rfced] Text styling > >> > >> a) The file below lists terms enclosed in <tt> in this document. > >> Please review to ensure the usage of <tt> is correct and consistent. Let > >> us know if any updates are needed. > >> > >> https://www.rfc-editor.org/authors/rfc9828-TT.txt > >> > >> Note: In the html and pdf outputs, the text enclosed in <tt> appears in > >> fixed-width font. In the txt output, the text enclosed in <tt> has no > >> text formatting. > >> > >> > >> b) FYI - We updated <tt> to <artwork> for the following equations: > >> > >> Original: > >> <extended sequence number> = <ESEQ field> * 65536 + <sequence > >> number field of the RTP fixed header> > >> ... > >> PID = c + s * num_components > > > > LGTM > > > >> > >> > >> c) The following are the instances of <em> in the document. Please review > >> and > >> confirm that the <em> is needed. > >> > >> <em>empty</em> > >> <em>matching</em> > > > > <em> for the two terms above implies a definition, i.e., the term is > > reused in a specific way in surrounding text. It feels like an > > appropriate use of <em>. > > > >> <em>c</em> > >> <em>s</em> > >> <em>num_components</em> > > > > <em> for the terms above implies a mathematical symbol used in a > > formulae. Not sure it is wise or necessary. Please advise. > > > >> > >> Note: In the html and pdf outputs, the text enclosed in <em> appears in > >> italics. In the txt output, the text enclosed in <em> appears with an > >> underline character before and after. > >> --> > >> > >> > >> 21) <!-- [rfced] Abbreviations > >> > >> a) Should "LSBs" be expanded as "least significant bits" here (or perhaps > >> just > >> use the expansion since this is the only instance in the document)? Our > >> list > >> also includes the expansion "Locator-Status-Bit". See > >> https://www.rfc-editor.org/rpc/wiki/doku.php?id=abbrev_list. > >> > >> Original: > >> The counter is sampled at the point > >> in time when each RTP Packet is transmitted and the 12 LSBs of the > >> sample are stored in the PTSTAMP field. > > > > Yes, please expand to "least significant bits". > > > >> > >> > >> b) How should "HT" be expanded? Below is the only instance in the document. > >> > >> Original: > >> * if the code-block conforms to [jpeg2000-15], contains an HT > >> cleanup segment and the first two bytes of the Magsgn byte-stream > >> are between 0xFF80 and 0xFF8F. > > > > "HT cleanup segment" is a defined term from ITU T.814. > > > >> --> > >> > >> > >> 22) <!-- [rfced] Please review the "Inclusive Language" portion of the > >> online > >> Style Guide > >> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> > >> and let us know if any changes are needed. Updates of this nature > >> typically > >> result in more precise language, which is helpful for readers. > >> > >> Note that our script did not flag any words in particular, but this should > >> still be reviewed as a best practice. > >> --> > >> > >> > >> Thank you. > >> > >> RFC Editor/rv > >> > >> > >> > >> On Aug 6, 2025, at 12:19 PM, rfc-edi...@rfc-editor.org wrote: > >> > >> *****IMPORTANT***** > >> > >> Updated 2025/08/06 > >> > >> RFC Author(s): > >> -------------- > >> > >> Instructions for Completing AUTH48 > >> > >> Your document has now entered AUTH48. Once it has been reviewed and > >> approved by you and all coauthors, it will be published as an RFC. > >> If an author is no longer available, there are several remedies > >> available as listed in the FAQ (https://www.rfc-editor.org/faq/). > >> > >> You and you coauthors are responsible for engaging other parties > >> (e.g., Contributors or Working Group) as necessary before providing > >> your approval. > >> > >> Planning your review > >> --------------------- > >> > >> Please review the following aspects of your document: > >> > >> * RFC Editor questions > >> > >> Please review and resolve any questions raised by the RFC Editor > >> that have been included in the XML file as comments marked as > >> follows: > >> > >> <!-- [rfced] ... --> > >> > >> These questions will also be sent in a subsequent email. > >> > >> * Changes submitted by coauthors > >> > >> Please ensure that you review any changes submitted by your > >> coauthors. We assume that if you do not speak up that you > >> agree to changes submitted by your coauthors. > >> > >> * Content > >> > >> Please review the full content of the document, as this cannot > >> change once the RFC is published. Please pay particular attention to: > >> - IANA considerations updates (if applicable) > >> - contact information > >> - references > >> > >> * Copyright notices and legends > >> > >> Please review the copyright notice and legends as defined in > >> RFC 5378 and the Trust Legal Provisions > >> (TLP – https://trustee.ietf.org/license-info). > >> > >> * Semantic markup > >> > >> Please review the markup in the XML file to ensure that elements of > >> content are correctly tagged. For example, ensure that <sourcecode> > >> and <artwork> are set correctly. See details at > >> <https://authors.ietf.org/rfcxml-vocabulary>. > >> > >> * Formatted output > >> > >> Please review the PDF, HTML, and TXT files to ensure that the > >> formatted output, as generated from the markup in the XML file, is > >> reasonable. Please note that the TXT will have formatting > >> limitations compared to the PDF and HTML. > >> > >> > >> Submitting changes > >> ------------------ > >> > >> To submit changes, please reply to this email using ‘REPLY ALL’ as all > >> the parties CCed on this message need to see your changes. The parties > >> include: > >> > >> * your coauthors > >> > >> * rfc-edi...@rfc-editor.org (the RPC team) > >> > >> * other document participants, depending on the stream (e.g., > >> IETF Stream participants are your working group chairs, the > >> responsible ADs, and the document shepherd). > >> > >> * auth48archive@rfc-editor.org, which is a new archival mailing list > >> to preserve AUTH48 conversations; it is not an active discussion > >> list: > >> > >> * More info: > >> > >> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc > >> > >> * The archive itself: > >> https://mailarchive.ietf.org/arch/browse/auth48archive/ > >> > >> * Note: If only absolutely necessary, you may temporarily opt out > >> of the archiving of messages (e.g., to discuss a sensitive matter). > >> If needed, please add a note at the top of the message that you > >> have dropped the address. When the discussion is concluded, > >> auth48archive@rfc-editor.org will be re-added to the CC list and > >> its addition will be noted at the top of the message. > >> > >> You may submit your changes in one of two ways: > >> > >> An update to the provided XML file > >> — OR — > >> An explicit list of changes in this format > >> > >> Section # (or indicate Global) > >> > >> OLD: > >> old text > >> > >> NEW: > >> new text > >> > >> You do not need to reply with both an updated XML file and an explicit > >> list of changes, as either form is sufficient. > >> > >> We will ask a stream manager to review and approve any changes that seem > >> beyond editorial in nature, e.g., addition of new text, deletion of text, > >> and technical changes. Information about stream managers can be found in > >> the FAQ. Editorial changes do not require approval from a stream manager. > >> > >> > >> Approving for publication > >> -------------------------- > >> > >> To approve your RFC for publication, please reply to this email stating > >> that you approve this RFC for publication. Please use ‘REPLY ALL’, > >> as all the parties CCed on this message need to see your approval. > >> > >> > >> Files > >> ----- > >> > >> The files are available here: > >> https://www.rfc-editor.org/authors/rfc9828.xml > >> https://www.rfc-editor.org/authors/rfc9828.html > >> https://www.rfc-editor.org/authors/rfc9828.pdf > >> https://www.rfc-editor.org/authors/rfc9828.txt > >> > >> Diff file of the text: > >> https://www.rfc-editor.org/authors/rfc9828-diff.html > >> https://www.rfc-editor.org/authors/rfc9828-rfcdiff.html (side by side) > >> > >> Diff of the XML: > >> https://www.rfc-editor.org/authors/rfc9828-xmldiff1.html > >> > >> > >> Tracking progress > >> ----------------- > >> > >> The details of the AUTH48 status of your document are here: > >> https://www.rfc-editor.org/auth48/rfc9828 > >> > >> Please let us know if you have any questions. > >> > >> Thank you for your cooperation, > >> > >> RFC Editor > >> > >> -------------------------------------- > >> RFC9828 (draft-ietf-avtcore-rtp-j2k-scl-08) > >> > >> Title : RTP Payload Format for sub-codestream latency JPEG 2000 > >> streaming > >> Author(s) : P. Lemieux, Ed., D. Taubman > >> WG Chair(s) : Dr. Bernard D. Aboba, Jonathan Lennox > >> Area Director(s) : Gorry Fairhurst, Mike Bishop > >> > > > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
