I Approve the document. Thanks all for the efforts !! //Zahed
On Mon, Mar 17, 2025 at 4:14 PM Amanda Baber via RT <iana-mat...@iana.org> wrote: > Hi, > > This change is complete: > > https://www.iana.org/assignments/media-types/video/VP9 > > We'll update the reference to the document once it's been published. > > thanks, > > Amanda Baber > IANA Operations Manager > > On Thu Mar 13 19:26:02 2025, mfergu...@staff.rfc-editor.org wrote: > > IANA, > > > > Please update https://www.iana.org/assignments/media-types/video/VP9 > > to match Section 7 of this document. > > > > We have included the text and diff files below for your convenience: > > > > https://www.rfc-editor.org/authors/rfc9628.txt > > https://www.rfc-editor.org/authors/rfc9628-diff.html > > > > Please let us know when these updates are complete and/or if you have > > any questions or concerns about the updates themselves. > > > > Thank you. > > > > RFC Editor/mf > > > > > > > On Mar 13, 2025, at 12:18 PM, Justin Uberti <jus...@uberti.name> > > > wrote: > > > > > > I see the address has been updated. I approve the publication of this > > > document. > > > > > > Justin > > > > > > On Fri, Mar 7, 2025 at 11:55 AM Jonathan Lennox > > > <jonathan.len...@8x8.com> wrote: > > > 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
