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
