Authors (and *AD), Just checking in to see if you’ve had a chance to review the files posted and/or *AD queries in the emails below?
Please let us know if any further changes are necessary or if you’d like to approve the current version. We are awaiting approvals from authors and *AD guidance/approval: once those are received, we will send any necessary updates to IANA registries to align them with the document. After the registry update(s) are confirmed, this document will be ready to move forward in the publication process with its cluster. The AUTH48 status page for this document is available here: https://www.rfc-editor.org/auth48/rfc9628 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:10 PM, Megan Ferguson <mfergu...@staff.rfc-editor.org> > wrote: > > Just an update to add the following change to the AD review list: > >> In the definition of Picture ID, in section 4.2, in the phrase "if the field >> transitions from 15 bits to 7 bits, it is truncated (i.e., the value after >> 0x1bbe is 0xbf)” the value “0xbf” should be replaced by “0x3f”. (0xbf is >> not a 7-bit value.) > > Thank you. > > RFC Editor/mf > > >> On Feb 21, 2025, at 3:08 PM, Megan Ferguson <mfergu...@staff.rfc-editor.org> >> wrote: >> >> Hi Jonathan, Justin, and *AD, >> >> Thanks for your reply. >> >> We have updated to use Mo’s proposed text as related to question 10 (the >> text sent to the WG). We will await *AD review/confirmation that we are >> okay to go forward with this text: >> >> Current: >> U: Switching up point. When this bit is set to one, if the >> current picture has a temporal-layer ID equal to value T, then >> subsequent pictures with temporal-layer ID values higher than T >> will not depend on any picture before the current picture (in >> decode order) with a temporal-layer ID value greater than T. >> >> We are hoping to hear from Justin as to how to edit the postal address >> (affiliation has been updated as requested). >> >> 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/rfc9628.txt >> https://www.rfc-editor.org/authors/rfc9628.pdf >> https://www.rfc-editor.org/authors/rfc9628.html >> https://www.rfc-editor.org/authors/rfc9628.xml >> >> The relevant diff files have been posted here (please refresh): >> https://www.rfc-editor.org/authors/rfc9628-diff.html (comprehensive diff) >> https://www.rfc-editor.org/authors/rfc9628-auth48diff.html (AUTH48 changes >> only) >> https://www.rfc-editor.org/authors/rfc9628-lastdiff.html (last to current >> version only) >> https://www.rfc-editor.org/authors/rfc9628-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/rfc9628 >> >> Thank you. >> >> RFC Editor/mf >> >>> On Feb 21, 2025, at 1:53 PM, Jonathan Lennox <jonathan.len...@8x8.com> >>> wrote: >>> >>> I also notice that Justin’s affiliation was updated for 9627, but not for >>> 9628. >>> >>>> On Feb 21, 2025, at 3:51 PM, Jonathan Lennox <jonathan.len...@8x8.com> >>>> wrote: >>>> >>>> >>>> >>>>> On Feb 20, 2025, at 2:21 PM, Megan Ferguson >>>>> <mfergu...@staff.rfc-editor.org> wrote: >>>>> >>>>> All, >>>>> >>>>> Thank you for your replies. We have updated according to the responses >>>>> we have received thus far to the document—specific and cluster-wide >>>>> queries. >>>>> >>>>> We had the following questions/comments to (hopefully) finish the list of >>>>> queries out: >>>>> >>>>> 1) Related to the cluster-wide bit name question: we suggest making no >>>>> changes to this document as we were able to glean these names from the >>>>> existing in-document descriptions (and no pattern seems to be changing in >>>>> RFC 9626 to use “the X (name) bit” format). >>>> >>>> Good. >>>> >>>>> >>>>> 2) Jonathan - please review the suggested text that uses “module” where >>>>> the document used “modulo”. We will await your reply prior to closing >>>>> this out. >>>>> >>>>>> Same item next paragraph, I realized the wording as written technically >>>>>> contradicts the first paragraph. The last sentence should read “Every >>>>>> picture containing a frame with show_frame==1, however, MUST have a >>>>>> unique timestamp module the 2^32 wrap of the field.” I.e., add “picture >>>>>> containing a” after “Every”. >>>> >>>> Thanks for catching that, yes, that was an autocorrect error. It should >>>> indeed be “modulo”. >>>> >>>> >>>>> 3) Just a reminder that this document has a question out to the WG and >>>>> that IANA updates to match the changes in the Media Type Registration in >>>>> Section 7 will be requested once all author approvals are received (as >>>>> possible delays to moving forward in the publication process). >>>> >>>> Mo had a response to the WG mail about that language — I agree with him, >>>> the parenthetical phrase would be better as “(in decoding order)” to match >>>> other usages. >>>> >>>> >>>> I also have two more changes for this document: >>>> >>>> In the definition of Picture ID, in section 4.2, in the phrase "if the >>>> field transitions from 15 bits to 7 bits, it is truncated (i.e., the value >>>> after 0x1bbe is 0xbf)” the value “0xbf” should be replaced by “0x3f”. >>>> (0xbf is not a 7-bit value.) >>>> >>>> The title of section 4.5 should be “Example of a VP9 RTP Stream”, because >>>> there is only one example. >>>> >>>> Thank you! >>> >> > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
