For this draft as well, I approve once the issue of Justin’s postal address is resolved.
> On Mar 4, 2025, at 2:11 PM, Megan Ferguson <mfergu...@staff.rfc-editor.org> > wrote: > > 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
