> On Feb 19, 2025, at 2:49 PM, Megan Ferguson <mfergu...@staff.rfc-editor.org> > wrote: > > Hi Mo and Jonathan, > > Thank you for your replies regarding these cluster-wide questions. We had > some follow up questions/comments for you to consider (numbering based on our > original numbering for these questions). We will await replies to the > following prior to moving this cluster forward in the publication process. > > Question 1 (a-c): We have updated to use the forms Jonathan mentioned with: > -didactic caps when used with an abbreviation and > -hyphenation in attributive position > > Please review these updates and confirm that you have no objections.
No objections for 9627 or 9628, except as noted in my other e-mails. > > Question 2 (regarding the names of bits): We attempted to implement Mo’s > suggestion to add the bit names/expansions on first use and then use simply > the abbreviation; however, this became difficult as some of the > names/expansions are not readily apparent to us and/or conflict between the > documents in cluster or between these documents and their normative > references (see below). Note: This list is not comprehensive as regards > normative references, it just highlights a few of the bit names we spotted at > a glance. > > Abbreviation: 9626 9627 9628 > Normative References > I Independent Frame idr_flag Picture ID > present PictureID present > > D Discardable Frame n/a inter_layer > dependency used > > S Start of Frame n/a n/a > Start of VP8 partition > > E End of Frame n/a End of a frame > > B Base Layer Sync n/a Start of a frame > > TID Temporal-layer ID n/a n/a > > LID Layer ID n/a n/a > > C n/a used but not expanded n/a > used but not expanded > > P Used not expanded n/a Inter-picture > predicted frame padding / Inverse key frame flag > > U Used not expanded n/a Switching up > point > > M Used not expanded n/a Most > significant bit of the marker > first octet is > an ext flag > > N Used not expanded n/a ? (unsure) > Non-reference frame > > Y Used not expanded used but not expanded Each spatial > layer’s frame resolution > is present. > > L n/a n/a Layer indices > present TL0PICIDX present > > F n/a n/a Flexible mode > > V n/a n/a Scalability > Structure (SS) version > data present Many of these bits mean different things in the different drafts; these weren’t coordinated in terms of naming, but changing them now is probably a bad idea. The scope of the bits for each document is only itself, without cross-references, so this shouldn’t be a problem. I’ll leave 9626 to Mo. 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”. In 9628: The definitions you list are correct. N could be “An additional P_DIFF field is present”. I’m not sure what’s the best way to use this information, however. > As such, we can see two ways forward: > > 1. Simply remove the parenthetical with the expansion everywhere the > parenthetical appears and have bit names appear only as, e.g., “the I bit” > when used in text. However, we still believe that authors should review the > table above and let us know any updates. > > 2. Authors provide an expansion of the bit name to be included on the first > appearance of the bit name as well as information regarding if this name > should be used consistently throughout the cluster or if each document uses > different expansions. > > Further notes: > -We have updated to use “End of Frame” and “Start of Frame” throughout the > cluster. > -We have updated to remove double quotes around bit abbreviations (e.g., the > I bit not the “I” bit). > -We have cut the names in parentheses when used after the first occurrence. > > Please let us know any objections. > > Question 4: We have not made updates to any instances of H264 to appear as > H.264 in any docs in this cluster per Mo’s response to RFC-to-be 9626. > Please let us know if we have misinterpreted your intention (i.e., specific > old/new text if updates are desired in certain places). I’ll let Mo be definitive for 9626, but for 9627, please update the section titles of sections 4.1 and 4.3 to include the dot, i.e. to be “H.264 SVC” and “H.265” respectively. > > Please see each document’s individual AUTH48 thread for links to review the > documents as well as necessary further author actions. > > You may track the progress of all documents in this cluster through AUTH48 at: > https://www.rfc-editor.org/auth48/C324 > > Thank you. > > RFC Editor/mf > > >> On Feb 14, 2025, at 9:49 AM, Mo Zanaty (mzanaty) <mzan...@cisco.com> wrote: >> >> See Mo: inline for responses to cluster-wide questions. My responses are >> authoritative for FM. I think Jonathan will agree to this for LRR and VP9. >> Jonathan, please correct if you disagree. >> >> From: Megan Ferguson <mfergu...@staff.rfc-editor.org> >> Sent: Friday, January 24, 2025 7:08 PM >> To: Jonathan Lennox <jonathan.lennox=408x8....@dmarc.ietf.org>; Mo Zanaty >> (mzanaty) <mzan...@cisco.com>; Suhas Nandakumar (snandaku) >> <snand...@cisco.com>; Espen Berger (espeberg) <espeb...@cisco.com>; >> Zaheduzzaman Sarker <zahed.sarker.i...@gmail.com>; Bernard Aboba >> <bernard.ab...@gmail.com>; Jonathan Lennox <jonathan.lenno...@gmail.com>; >> da...@vidyo.com <da...@vidyo.com>; dannyh...@google.com >> <dannyh...@google.com>; mflod...@google.com <mflod...@google.com>; >> hol...@google.com <hol...@google.com>; jus...@uberti.name >> <jus...@uberti.name>; rachel.hu...@huawei.com <rachel.hu...@huawei.com>; >> Murray S. Kucherawy <superu...@gmail.com>; Francesca Palombini >> <francesca.palomb...@ericsson.com>; Orie Steele <orie@transmute.industries> >> Cc: RFC Editor <rfc-edi...@rfc-editor.org>; auth48archive@rfc-editor.org >> <auth48archive@rfc-editor.org> >> Subject: Re: Cluster C324 questions: RFCs 9626 >> <draft-ietf-avtext-framemarking>, 9627 <draft-ietf-avtext-lrr>, and 9628 >> <draft-ietf-payload-vp9> >> >> Greetings, >> >> [Please note the new email address on our end.] >> >> A friendly reminder that this document set awaits author attention. >> >> 1) We are awaiting responses to document-specific author queries and updates >> from your reviews. Please see our document-specific emails for further >> information and reply in those threads. >> >> Mo: See my FM document-specific email responses sent yesterday. I don't have >> visibility to other documents in the cluster since I'm not an author, chair, >> or AD. But I'm happy to respond if you add me to those other >> document-specific emails. I think Jonathan will agree with my responses, as >> we have discussed this cluster together in November. >> >> 2) Note also that we are awaiting further guidance as to which action to >> take regarding this from Jonathan in response to our cluster-wide queries in >> this email thread: >> >> Mo: I think Jonathan will agree with my response below. >> >>> >>> On Nov 7, 2024, at 7:51 AM, Jonathan Lennox >>> <jonathan.lennox=408x8....@dmarc.ietf.org> wrote: >>> >>>> 2) Please review the way bit names are treated throughout the cluster. >>>> Sometimes the >>>> names of the bits are included in parentheses (e.g., "the I (Independent >>>> Frame) and >>>> D (Discardable Frame) bits"), sometimes a pointer is given on where to see >>>> more about >>>> the bit (e.g., "B bit (described below"), sometimes the bit names are not >>>> included at >>>> all (e.g., "the D bit"), and sometimes we see the letters in quotes (e.g., >>>> the "D" bit). >>>> >>>> We suggest making these uses uniform and/or explaining them in one place >>>> and pointing the >>>> reader there for more information upon introduction of the bit in the >>>> document. Upon careful >>>> review, please let us know what updates are necessary using Old/New or by >>>> updating the XML >>>> files as necessary. >>> >>> That sounds good. >> >> Mo: I think Jonathan meant making these uniform as suggested sounds good. I >> don't think it's necessary to add a new section explaining them that all >> other sections refer to. It should be sufficient to include the bit name in >> parenthesis upon first use, i. e. "I (Independent) bit", then optionally >> omit (based on the editor's discretion of clarity versus verbosity) the bit >> name upon subsequent use without any further reference, i. e. "I bit". >> >> 3) Further note: >> We have received bounce-message notifications for Justin Uberti and Danny >> Hong on at least one email address listed. Could they each respond >> confirming receipt and letting us know how their contact information should >> appear in the documents themselves? >> >> Mo: I don't know the current contact information for those authors, but I >> know their affiliations have changed, so the original contact information is >> stale. >> >> Please see the AUTH48 status page for this cluster at: >> https://www.rfc-editor.org/auth48/C324 >> >> Thank you. >> >> Mo: Thank you, and apologies for the delay. >> >> RFC Editor/mf >> >>> On Nov 13, 2024, at 1:34 PM, Megan Ferguson <mfergu...@amsl.com> wrote: >>> >>> Jonathan, >>> >>> Thank you for your reply. >>> >>> Regarding the following question, please clarify how you would like us to >>> update or if you are planning to update the file yourself. >>> >>> RFC Editor/mf >>> >>> >>>> On Nov 7, 2024, at 7:51 AM, Jonathan Lennox >>>> <jonathan.lennox=408x8....@dmarc.ietf.org> wrote: >>>> >>>>> 2) Please review the way bit names are treated throughout the cluster. >>>>> Sometimes the >>>>> names of the bits are included in parentheses (e.g., "the I (Independent >>>>> Frame) and >>>>> D (Discardable Frame) bits"), sometimes a pointer is given on where to >>>>> see more about >>>>> the bit (e.g., "B bit (described below"), sometimes the bit names are not >>>>> included at >>>>> all (e.g., "the D bit"), and sometimes we see the letters in quotes >>>>> (e.g., the "D" bit). >>>>> >>>>> We suggest making these uses uniform and/or explaining them in one place >>>>> and pointing the >>>>> reader there for more information upon introduction of the bit in the >>>>> document. Upon careful >>>>> review, please let us know what updates are necessary using Old/New or by >>>>> updating the XML >>>>> files as necessary. >>>> >>>> That sounds good. >>> >> > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
