Hi all, Just checking in to see if you’ve had a chance to review the files posted (see email below)?
Please let us know if any further changes are necessary or if you’d like to approve the current version. Once we have approvals from each author listed at the AUTH48 status page for this document (see below), we will be ready to move it forward in the publication process with its cluster. The AUTH48 status page for this document is available here: https://www.rfc-editor.org/auth48/rfc9627 Please see the AUTH48 status page for all documents in the cluster here: https://www.rfc-editor.org/auth48/C324 Thank you. RFC Editor/mf > On Feb 21, 2025, at 3:13 PM, Megan Ferguson <mfergu...@staff.rfc-editor.org> > wrote: > > Jonathan, > > Thank you for spotting that! We have updated the files to include this > change. > > Please review the files carefully as we do not make changes after > publication. > > The files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9627.txt > https://www.rfc-editor.org/authors/rfc9627.pdf > https://www.rfc-editor.org/authors/rfc9627.html > https://www.rfc-editor.org/authors/rfc9627.xml > > The relevant diff files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9627-diff.html (comprehensive diff) > https://www.rfc-editor.org/authors/rfc9627-auth48diff.html (AUTH48 changes > only) > https://www.rfc-editor.org/authors/rfc9627-lastdiff.html (last to current > version only) > https://www.rfc-editor.org/authors/rfc9627-lastrfcdiff.html (ditto but side > by side) > > Please contact us with any further updates/questions/comments you may have. > > We will await approvals from each of the parties listed on the AUTH48 status > page prior to moving forward to publication. > > The AUTH48 status page for this document is available here: > > https://www.rfc-editor.org/auth48/rfc9627 > > Thank you. > > RFC Editor/mf > >> On Feb 21, 2025, at 2:01 PM, Jonathan Lennox <jonathan.len...@8x8.com> wrote: >> >> I have one more change to RFC 9627. >> >> In Section 3.2, the sentence "An LRR SHOULD be used only in situations where >> there is an explicit change in a decoders’ behavior:” should have >> “decoder’s” not “decoders’” (apostrophe-S not S-apostrophe), because given >> the article it is referring to a singular decoder. >> >>> On Feb 21, 2025, at 10:10 AM, Megan Ferguson >>> <mfergu...@staff.rfc-editor.org> wrote: >>> >>> Danny, >>> >>> Thank you for sending along your updated contact information. We have >>> rolled this change into the previous version of the files. >>> >>> As you indicated your approval, we have also updated the AUTH48 status page >>> to capture that information. >>> >>> Please review the files carefully as we do not make changes after >>> publication. >>> >>> The files have been posted here (please refresh): >>> https://www.rfc-editor.org/authors/rfc9627.txt >>> https://www.rfc-editor.org/authors/rfc9627.pdf >>> https://www.rfc-editor.org/authors/rfc9627.html >>> https://www.rfc-editor.org/authors/rfc9627.xml >>> >>> The relevant diff files have been posted here (please refresh): >>> https://www.rfc-editor.org/authors/rfc9627-diff.html (comprehensive diff) >>> https://www.rfc-editor.org/authors/rfc9627-auth48diff.html (AUTH48 changes >>> only) >>> https://www.rfc-editor.org/authors/rfc9627-lastdiff.html (last to current >>> version only) >>> https://www.rfc-editor.org/authors/rfc9627-lastrfcdiff.html (ditto but side >>> by side) >>> >>> Please contact us with any further updates/questions/comments you may have. >>> >>> >>> We will await approvals from each of the parties listed on the AUTH48 >>> status page prior to moving forward to publication. >>> >>> The AUTH48 status page for this document is available here: >>> >>> https://www.rfc-editor.org/auth48/rfc9627 >>> >>> Thank you. >>> >>> RFC Editor/mf >>> >>> >>>> On Feb 21, 2025, at 6:40 AM, Danny Hong <dannyh...@google.com> wrote: >>>> >>>> New affiliation for Danny Hong: >>>> Google, Inc. >>>> 315 Hudson St, >>>> New York, NY 10013 >>>> United States of America >>>> Email: dannyh...@google.com >>>> >>>> On Fri, Feb 21, 2025 at 8:37 AM Danny Hong <dannyh...@google.com> wrote: >>>> My sincere apologies for the late response. The emails have been piling >>>> up straight into a folder without any notifications. Fixed this so that >>>> now the emails go directly into my inbox. All the edits look good to me. >>>> My affiliation should now be Google, though. >>>> >>>> Thank you >>>> Danny >>>> >>>> On Thu, Feb 20, 2025 at 11:14 PM Megan Ferguson >>>> <mfergu...@staff.rfc-editor.org> wrote: >>>> Justin, >>>> >>>> Note that the following question/comments for you remain open: >>>> >>>> 1) Justin - we have updated your affiliation. Please review the physical >>>> address in these docs and let us know what (if any) updates are necessary. >>>> >>>> 2) Please provide further information on VP8 in this list as we don’t see >>>> any punctuation with VP* throughout the cluster: >>>>> the headings for Section 4 should probably include punctuation, e.g,. >>>>> H.264/SVC, VP8, H.265 >>>> >>>> Thank you. >>>> >>>> RFC Editor/mf >>>> >>>> >>>>> On Feb 20, 2025, at 9:12 PM, Megan Ferguson >>>>> <mfergu...@staff.rfc-editor.org> wrote: >>>>> >>>>> Hi Jonathan, >>>>> >>>>> Thanks for your reply and guidance. >>>>> >>>>> We have rolled these changes into the previous version. Please review >>>>> and let us know if any further updates are necessary. >>>>> >>>>> We now consider all document-specific and cluster-wide questions resolved. >>>>> >>>>> The files have been posted here (please refresh): >>>>> https://www.rfc-editor.org/authors/rfc9627.txt >>>>> https://www.rfc-editor.org/authors/rfc9627.pdf >>>>> https://www.rfc-editor.org/authors/rfc9627.html >>>>> https://www.rfc-editor.org/authors/rfc9627.xml >>>>> >>>>> The relevant diff files have been posted here (please refresh): >>>>> https://www.rfc-editor.org/authors/rfc9627-diff.html (comprehensive diff) >>>>> https://www.rfc-editor.org/authors/rfc9627-auth48diff.html (AUTH48 >>>>> changes only) >>>>> https://www.rfc-editor.org/authors/rfc9627-lastdiff.html (last to current >>>>> version only) >>>>> https://www.rfc-editor.org/authors/rfc9627-lastrfc diff.html (las to >>>>> current side by side) >>>>> >>>>> We will await approvals from each of the parties listed on the AUTH48 >>>>> status page prior to moving forward to publication. >>>>> >>>>> The AUTH48 status page for this document is available here: >>>>> >>>>> https://www.rfc-editor.org/auth48/rfc9627 >>>>> >>>>> Thank you. >>>>> >>>>> RFC Editor/mf >>>>> >>>>>> On Feb 20, 2025, at 3:28 PM, Jonathan Lennox <jonathan.len...@8x8.com> >>>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>>> On Feb 20, 2025, at 2:21 PM, Megan Ferguson >>>>>>> <mfergu...@staff.rfc-editor.org> wrote: >>>>>>> >>>>>>> >>>>>>> 3) Regarding the response to our cluster-wide question about bit names >>>>>>> (moving to this thread as now document-specific), Jonathan said: >>>>>>>> In 9627: >>>>>>>> C could be described as “Current layer information present” or “CTID >>>>>>>> and CLID present” if you want a name for it. >>>>>>>> Y is used in this document to reference the “Y” bit defined in RFC >>>>>>>> 7741, where it is named “1 layer sync bit”. >>>>>>> … >>>>>>>> I’m not sure what’s the best way to use this information, however. >>>>>>> >>>>>>> Perhaps no change to C as we already have: >>>>>>> >>>>>>> C (1 bit): >>>>>>> A flag bit indicating whether the Current Temporal-layer ID (CTID) >>>>>>> and Current Layer ID (CLID) fields are present in the FCI. If >>>>>>> this bit is 0, the sender of the LRR message is requesting refresh >>>>>>> of all layers up to and including the target layer. >>>>>> >>>>>> >>>>>> That seems good. >>>>>> >>>>>>> Perhaps just a citation for Y?: >>>>>>> A VP8 layer refresh point can be identified by the presence of the Y >>>>>>> bit (see [RFC7741]) in the VP8 payload header. >>>>>> >>>>>> Agreed. >>>>>> >>>>>> >>>>>>> 4) Please review points 3 and 4 from Madison’s mail (originally sent 13 >>>>>>> February) and let us know how you would like to proceed. Note also >>>>>>> that we will assume the other actions she described us taking in that >>>>>>> same mail are acceptable unless we hear objection. >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>> 10) <!--[rfced] We had the following questions related to the >>>>>>>>>>> abbreviations and initialisms used throughout the document: >>>>>>>>>>> >>>>>>>>>>> a) In the following equation, will it be clear to the reader what TO >>>>>>>>>>> and TN refer to? >>>>>>>>>>> >>>>>>>>>>> TID = TO and target TID = TN >>>>>>>>>>> >>>>>>>>>>> If these are abbreviations, they should be expanded on first use >>>>>>>>>>> (per >>>>>>>>>>> RFC 7322). >>>>>>>>> >>>>>>>>> These are nonce variables so we can talk about the specific values of >>>>>>>>> CTID and TTID sent in a hypothetical LRR message. Is there a clearer >>>>>>>>> way to express this? >>>>>>>> >>>>>>>> 3) Thank you for the clarification! Perhaps adding a note at the end >>>>>>>> of the sentence would clarify this for readers? >>>>>>>> >>>>>>>> Current: >>>>>>>> In this case, given current TID = TO and target TID = TN, layer >>>>>>>> refresh to TN is satisfied when a >>>>>>>> NAL unit type of 2 or 3 is seen for TID = T1, then TID = T2, all the >>>>>>>> way up to TID = TN. >>>>>>>> >>>>>>>> Perhaps: >>>>>>>> In this case, given current TID = TO and target TID = TN, layer >>>>>>>> refresh to TN is satisfied when a >>>>>>>> NAL unit type of 2 or 3 is seen for TID = T1, then TID = T2, all the >>>>>>>> way up to TID = TN (note that >>>>>>>> TN and TO refer to nonce variables in this instance). >>>>>> >>>>>> If you think that’s clearer, it works for me. >>>>>> >>>>>>>> 4) We have removed quotes surrounding field names upon first use for >>>>>>>> consistency. Also, please note that the following terms still need >>>>>>>> review: >>>>>>>> >>>>>>> [snip] >>>>>>>> Current Layer ID (CLID) vs. Current Layer Index >>>>>> >>>>>> Note the last paragraph of section 2: >>>>>> >>>>>> A "layer index" is a numeric label for a specific spatial and temporal >>>>>> layer of a scalable stream. It consists of both a "temporal-layer ID" >>>>>> identifying the temporal layer and a "layer ID" identifying the spatial >>>>>> or quality layer. The details of how layers of a scalable stream are >>>>>> labeled are codec specific. Details for several codecs are defined in >>>>>> Section 4.¶ >>>>>> >>>>>> So these are two separate things. >>>>>> >>>>>>> >>>>>>> Please review the files carefully as we do not make changes after >>>>>>> publication. >>>>>>> >>>>>>> The files have been posted here (please refresh): >>>>>>> https://www.rfc-editor.org/authors/rfc9627.txt >>>>>>> https://www.rfc-editor.org/authors/rfc9627.pdf >>>>>>> https://www.rfc-editor.org/authors/rfc9627.html >>>>>>> https://www.rfc-editor.org/authors/rfc9627.xml >>>>>>> >>>>>>> The relevant diff files have been posted here (please refresh): >>>>>>> https://www.rfc-editor.org/authors/rfc9627-diff.html (comprehensive >>>>>>> diff) >>>>>>> https://www.rfc-editor.org/authors/rfc9627-auth48diff.html (AUTH48 >>>>>>> changes only) >>>>>>> https://www.rfc-editor.org/authors/rfc9627-lastdiff.html (last to >>>>>>> current version only) >>>>>>> https://www.rfc-editor.org/authors/rfc9627-lastrfc diff.html (las to >>>>>>> current side by side) >>>>>>> >>>>>>> Please contact us with any further updates/questions/comments you may >>>>>>> have. >>>>>>> >>>>>>> We will await approvals from each of the parties listed on the AUTH48 >>>>>>> status page prior to moving forward to publication. >>>>>>> >>>>>>> The AUTH48 status page for this document is available here: >>>>>>> >>>>>>> https://www.rfc-editor.org/auth48/rfc9627 >>>>>>> >>>>>>> Thank you. >>>>>>> >>>>>>> RFC Editor/mf >>>>>>> >>>>>>>> On Feb 20, 2025, at 12:06 AM, Justin Uberti <jus...@uberti.name> wrote: >>>>>>>> >>>>>>>> A few very minor nits that I encountered when reviewing this document: >>>>>>>> - the RFC9626 reference for frame marking mistakenly refers to RFC 9621 >>>>>>>> - the headings for Section 4 should probably include punctuation, >>>>>>>> e.g,. H.264/SVC, VP8, H.265 >>>>>>>> - my affiliation is now OpenAI rather than Google >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Justin >>>>>>>> >>>>>>>> On Wed, Feb 19, 2025 at 2:28 PM Jonathan Lennox >>>>>>>> <jonathan.len...@8x8.com> wrote: >>>>>>>> A few changes: >>>>>>>> >>>>>>>> Section 2.1: since “FIR” is usually pronounced “eff-eye-arr” not “fir” >>>>>>>> like the tree, it begins with a vowel sound. Thus, presumably the >>>>>>>> second sentence of the third paragraph should be “This is the >>>>>>>> difference between a layer refresh and an FIR [RFC5104]”. I.e. “an” >>>>>>>> rather than “a”. >>>>>>>> >>>>>>>> Section 2.1 again, paragraphs after the figures: the text should >>>>>>>> remain “spatial layer S1” and “spatial layer S0”, not hyphenated. In >>>>>>>> this usage “spatial layer” is a noun, describing specific spatial >>>>>>>> layers named “S0” or “S1”, not an adjective. >>>>>>>> >>>>>>>> Section 3, third paragraph, should start “The design of LRR” (not “An >>>>>>>> LRR”), since this is discussing the overall mechanism, not a specific >>>>>>>> message. >>>>>>>> >>>>>>>>> On Feb 19, 2025, at 3:05 PM, Megan Ferguson >>>>>>>>> <mfergu...@staff.rfc-editor.org> wrote: >>>>>>>>> >>>>>>>>> Apologies for the noise, resending with our current email (please >>>>>>>>> reply to this address) >>>>>>>>> >>>>>>>>>> On Feb 19, 2025, at 12:48 PM, Megan Ferguson <mfergu...@amsl.com> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Greetings, >>>>>>>>>> >>>>>>>>>> This document has been updated with the responses to our >>>>>>>>>> cluster-wide queries we have received to date. Please review these >>>>>>>>>> updates carefully as we do not make changes once the document is >>>>>>>>>> published as an RFC. >>>>>>>>>> >>>>>>>>>> Note that we will await the following prior to moving forward in the >>>>>>>>>> publication process: >>>>>>>>>> -responses to the follow-up questions sent by Madison (see previous >>>>>>>>>> email) >>>>>>>>>> -resolution of outstanding cluster-wide issues (see separate email >>>>>>>>>> thread) >>>>>>>>>> -approvals from each author >>>>>>>>>> >>>>>>>>>> The files have been posted here (please refresh): >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9627.txt >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9627.pdf >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9627.html >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9627.xml >>>>>>>>>> >>>>>>>>>> The relevant diff files have been posted here (please refresh): >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9627-diff.html (comprehensive >>>>>>>>>> diff) >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9627-auth48diff.html (AUTH48 >>>>>>>>>> changes only) >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9627-lastdiff.html (last to >>>>>>>>>> current version only) >>>>>>>>>> >>>>>>>>>> The AUTH48 status page for this document is available here: >>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9627 >>>>>>>>>> >>>>>>>>>> The AUTH48 status page for this cluster is available here: >>>>>>>>>> https://www.rfc-editor.org/auth48/C324 >>>>>>>>>> >>>>>>>>>> Please contact us with any further updates/questions/comments you >>>>>>>>>> may have. >>>>>>>>>> >>>>>>>>>> Thank you. >>>>>>>>>> >>>>>>>>>> RFC Editor/mf >>>>>>>>>> >>>>>>>>>>> On Feb 13, 2025, at 10:36 AM, Madison Church >>>>>>>>>>> <mchu...@staff.rfc-editor.org> wrote: >>>>>>>>>>> >>>>>>>>>>> Hi Jonathan, >>>>>>>>>>> >>>>>>>>>>> Thank you for your reply! We have updated the document per your >>>>>>>>>>> response. Please see the thread below for followup comments and >>>>>>>>>>> updated files. >>>>>>>>>>> >>>>>>>>>>>>>> 3) <!--[rfced] We had the following questions regarding Section >>>>>>>>>>>>>> 2. >>>>>>>>>>>>>> Section 2 was titled "Conventions, Definitions, and Acronyms". >>>>>>>>>>>>>> It contains the BCP 14 boilerplate and a single subsection that >>>>>>>>>>>>>> is titled "Terminology". >>>>>>>>>>>>>> >>>>>>>>>>>>>> a) There is no list of acronyms in this section. Please review >>>>>>>>>>>>>> our >>>>>>>>>>>>>> updates to the title of this section and let us know any >>>>>>>>>>>>>> objections >>>>>>>>>>>>>> (of if a list of abbreviations was missing). >>>>>>>>>>>>>> >>>>>>>>>>>>>> Original: >>>>>>>>>>>>>> Conventions, Definitions and Acronyms >>>>>>>>>>>>>> >>>>>>>>>>>>>> Current: >>>>>>>>>>>>>> Conventions and Terminology >>>>>>>>>>>> >>>>>>>>>>>> That’s fine. >>>>>>>>>>>> >>>>>>>>>>>>>> b) We see several terms throughout the document that it may be >>>>>>>>>>>>>> useful >>>>>>>>>>>>>> to include in this section (as they are seemingly introduced in >>>>>>>>>>>>>> sections that follow). For example: >>>>>>>>>>>>>> >>>>>>>>>>>>>> temporally nested >>>>>>>>>>>>>> Layer Index >>>>>>>>>>>>>> temporal ID >>>>>>>>>>>>>> layer ID >>>>>>>>>>>>>> >>>>>>>>>>>>>> Please let us know if you'd like to add any terms to the >>>>>>>>>>>>>> Terminology >>>>>>>>>>>>>> section. >>>>>>>>>>>>>> --> >>>>>>>>>>>> >>>>>>>>>>>> Aren’t these all already defined in Section 2, or am I missing >>>>>>>>>>>> something? >>>>>>>>>>> >>>>>>>>>>> 1) Thank you for pointing this out. When re-reviewing Section 2.1, >>>>>>>>>>> it looks like the highlighted terms in question 3b are defined. >>>>>>>>>>> >>>>>>>>>>> For example (paragraph above Section 3): >>>>>>>>>>> "A 'layer index' is a numeric label for a specific spatial and >>>>>>>>>>> temporal layer of a scalable stream." >>>>>>>>>>> >>>>>>>>>>> We have left the definitions as is in this section. >>>>>>>>>>> >>>>>>>>>>>>>> 6) <!--[rfced] In the text below, are you referring to the title >>>>>>>>>>>>>> of the >>>>>>>>>>>>>> document? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Original: >>>>>>>>>>>>>> If the payload also specifies how it is used with the Frame >>>>>>>>>>>>>> Marking >>>>>>>>>>>>>> RTP Header Extension [I-D.ietf-avtext-framemarking], the syntax >>>>>>>>>>>>>> MUST >>>>>>>>>>>>>> be defined in the same manner as the TID and LID fields in that >>>>>>>>>>>>>> header. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Perhaps: >>>>>>>>>>>>>> If the payload also specifies how it is used with "Video Frame >>>>>>>>>>>>>> Marking >>>>>>>>>>>>>> RTP Header Extension" [RFC9626], the syntax MUST be defined in >>>>>>>>>>>>>> the >>>>>>>>>>>>>> same manner as the TID and LID fields in that header. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Or perhaps: >>>>>>>>>>>>>> If the payload also specifies how it is used with the [Video?] >>>>>>>>>>>>>> Frame >>>>>>>>>>>>>> Marking RTP Header Extension described in [RFC9626], the syntax >>>>>>>>>>>>>> MUST >>>>>>>>>>>>>> be defined in the same manner as the TID and LID fields in that >>>>>>>>>>>>>> header. >>>>>>>>>>>>>> --> >>>>>>>>>>>> >>>>>>>>>>>> The latter seems good, including the word “Video”. >>>>>>>>>>> >>>>>>>>>>> 2) We have updated the sentence above to use the second option. If >>>>>>>>>>> there are any additional changes needed to the text above (in >>>>>>>>>>> reference to the current status of RFC 9626), please let us know >>>>>>>>>>> and we will make those updates as well. >>>>>>>>>>> >>>>>>>>>>>>>> 10) <!--[rfced] We had the following questions related to the >>>>>>>>>>>>>> abbreviations and initialisms used throughout the document: >>>>>>>>>>>>>> >>>>>>>>>>>>>> a) In the following equation, will it be clear to the reader >>>>>>>>>>>>>> what TO >>>>>>>>>>>>>> and TN refer to? >>>>>>>>>>>>>> >>>>>>>>>>>>>> TID = TO and target TID = TN >>>>>>>>>>>>>> >>>>>>>>>>>>>> If these are abbreviations, they should be expanded on first use >>>>>>>>>>>>>> (per >>>>>>>>>>>>>> RFC 7322). >>>>>>>>>>>> >>>>>>>>>>>> These are nonce variables so we can talk about the specific values >>>>>>>>>>>> of CTID and TTID sent in a hypothetical LRR message. Is there a >>>>>>>>>>>> clearer way to express this? >>>>>>>>>>> >>>>>>>>>>> 3) Thank you for the clarification! Perhaps adding a note at the >>>>>>>>>>> end of the sentence would clarify this for readers? >>>>>>>>>>> >>>>>>>>>>> Current: >>>>>>>>>>> In this case, given current TID = TO and target TID = TN, layer >>>>>>>>>>> refresh to TN is satisfied when a >>>>>>>>>>> NAL unit type of 2 or 3 is seen for TID = T1, then TID = T2, all >>>>>>>>>>> the way up to TID = TN. >>>>>>>>>>> >>>>>>>>>>> Perhaps: >>>>>>>>>>> In this case, given current TID = TO and target TID = TN, layer >>>>>>>>>>> refresh to TN is satisfied when a >>>>>>>>>>> NAL unit type of 2 or 3 is seen for TID = T1, then TID = T2, all >>>>>>>>>>> the way up to TID = TN (note that >>>>>>>>>>> TN and TO refer to nonce variables in this instance). >>>>>>>>>>> >>>>>>>>>>>>>> b) We see: >>>>>>>>>>>>>> >>>>>>>>>>>>>> CLID - Current Layer ID >>>>>>>>>>>>>> >>>>>>>>>>>>>> and also Current Layer Index (or current layer indices or layer >>>>>>>>>>>>>> indices) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Please review these occurrences and let us know if they should >>>>>>>>>>>>>> be made >>>>>>>>>>>>>> uniform. >>>>>>>>>>>>>> 11) <!--[rfced] We had the following questions related to the >>>>>>>>>>>>>> terminology >>>>>>>>>>>>>> used throughout the document. >>>>>>>>>>>>>> >>>>>>>>>>>>>> a) Please review the way field names are treated with regard to >>>>>>>>>>>>>> capitalization and quotation and let us know if/how they should >>>>>>>>>>>>>> be >>>>>>>>>>>>>> made uniform. >>>>>>>>>>>>>> >>>>>>>>>>>>>> For example, we see: >>>>>>>>>>>>>> >>>>>>>>>>>>>> "R" field >>>>>>>>>>>>>> "RES" field >>>>>>>>>>>>>> layer index field >>>>>>>>>>>>>> LayerId field vs. layer ID field vs. LID field (see related >>>>>>>>>>>>>> cluster query) >>>>>>>>>>>>>> "media source" field >>>>>>>>>>>>>> "Current Temporal Layer ID (CTID)" and "Current Layer ID (CLID)" >>>>>>>>>>>>>> fields >>>>>>>>>>>>>> payload type field >>>>>>>>>>>>>> "SSRC of packet sender" field >>>>>>>>>>>>>> DID, QID, and TID fields >>>>>>>>>>>>>> --> >>>>>>>>>>>> >>>>>>>>>>>> I think I’ve tended to use quotes on first reference to a field, >>>>>>>>>>>> and not use them subsequently, but if you think that’s confusing >>>>>>>>>>>> feel free to remove them. >>>>>>>>>>>> >>>>>>>>>>>> I think I’ve also tended to use capitalization when referring to a >>>>>>>>>>>> protocol element and use plain English when referring to the >>>>>>>>>>>> abstract concept carried in that protocol element, but if you want >>>>>>>>>>>> to normalize them that's fine. >>>>>>>>>>> >>>>>>>>>>> 4) We have removed quotes surrounding field names upon first use >>>>>>>>>>> for consistency. Also, please note that the following terms still >>>>>>>>>>> need review: >>>>>>>>>>> >>>>>>>>>>> LayerId field vs. layer ID field vs. LID field (see related cluster >>>>>>>>>>> query) >>>>>>>>>>> Current Layer ID (CLID) vs. Current Layer Index >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The updated files have been posted here (please refresh): >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9627.txt >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9627.pdf >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9627.html >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9627.xml >>>>>>>>>>> >>>>>>>>>>> The updated diff files have been posted here (please refresh): >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9627-diff.html (comprehensive >>>>>>>>>>> diff) >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9627-rfcdiff.html (side by >>>>>>>>>>> side) >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9627-auth48diff.html (AUTH48 >>>>>>>>>>> changes) >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9627-auth48rfcdiff.html (side >>>>>>>>>>> by side) >>>>>>>>>>> >>>>>>>>>>> For the AUTH48 status of this document, please see: >>>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9627 >>>>>>>>>>> >>>>>>>>>>> Thank you, >>>>>>>>>>> RFC Editor/mc >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
