Hi, please use the following address for me for both 9627 and 9268: OpenAI 1455 3rd St San Francisco, CA 94158
On Fri, Mar 7, 2025 at 11:45 AM Jonathan Lennox <jonathan.len...@8x8.com> wrote: > Other than Justin’s postal address, this document is good to go; I approve > once that’s resolved. > > Justin, please send your current postal contact address you want listed in > the draft — right now it still lists Google’s Kirkland address. > > > On Mar 4, 2025, at 2:11 PM, Megan Ferguson < > mfergu...@staff.rfc-editor.org> wrote: > > > > 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
