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
