Roland, Andy*, * Andy (as AD), please review and let us know if you approve the changes to the abstract, based on replies to our questions below. The changes are shown in the diff files below; here is the current abstract:
The Third Generation Partnership Project (3GPP) has identified cases where different SIP private header extensions referred to as "P-" header fields, and defined in RFC 7315, need to be included in SIP requests and responses where they were not allowed according to RFC 7315. This document updates RFC 7315, in order to allow inclusion of the affected "P-" header fields in such requests and responses. This document obsoletes RFC 7976. The changes related to RFC 7976 involve the inclusion of the P-Visited-Network-ID header field in SIP responses. This document also makes updates to RFC 7315 in order to fix misalignments that occurred when RFC 3455 was obsoleted by RFC 7315. Roland, Thank you for your reply. The revised files are here (please refresh): https://www.rfc-editor.org/authors/rfc9878.html https://www.rfc-editor.org/authors/rfc9878.txt https://www.rfc-editor.org/authors/rfc9878.pdf https://www.rfc-editor.org/authors/rfc9878.xml This diff file shows all changes from the approved I-D: https://www.rfc-editor.org/authors/rfc9878-diff.html https://www.rfc-editor.org/authors/rfc9878-rfcdiff.html (side by side) This diff file shows the changes made during AUTH48 thus far: https://www.rfc-editor.org/authors/rfc9878-auth48diff.html https://www.rfc-editor.org/authors/rfc9878-auth48rfcdiff.html (side by side) We will wait to hear from you again and from your coauthors before continuing the publication process. This page shows the AUTH48 status of your document: https://www.rfc-editor.org/auth48/rfc9878 Thank you. Alice Russo RFC Production Center > On Oct 23, 2025, at 2:51 AM, [email protected] wrote: > > Hi, > Thank you for your review. > Find the answers below > > Best regards > > Roland > > -----Ursprüngliche Nachricht----- > Von: [email protected] <[email protected]> > Gesendet: Samstag, 11. Oktober 2025 03:23 > An: [email protected]; [email protected]; > [email protected]; Jesske, Roland <[email protected]> > Cc: [email protected]; [email protected]; [email protected]; > [email protected]; [email protected]; [email protected] > Betreff: Re: AUTH48: RFC-to-be 9878 <draft-ietf-sipcore-rfc7976bis-04> for > your review > > Authors, > > While reviewing this document during AUTH48, please resolve (as necessary) > the following questions, which are also in the source file. > > 1) <!-- [rfced] Because this document updates RFC 7315, please review the > errata reported for RFC 7315 > (https://www.rfc-editor.org/errata/rfc7315) > and let us know if you confirm our opinion that none of them are relevant to > the content of this document. > --> [RJ] Yes is not relevant to the content of this document. > > > 2) <!-- [rfced] Because this document obsoletes RFC 7976, please > review the errata reported for RFC 7976 > (https://www.rfc-editor.org/errata/rfc7976) > and let us know if you confirm our opinion that none of them > are relevant to the content of this document. > -->[RJ] Yes is not relevant to the content of this document. > > > 3) <!-- [rfced] While we understand the original document (RFC 7976) was > published with the text in some of the questions below, the opportunity > with the "bis" document is to make the text as clear as possible. > If you decide to make changes, you have the option to add text to > Section 7 to mention minor editorial updates. > --> [RJ] No need to add additional text. > > > 4) <!--[rfced] Abstract and Introduction: Please review if the first sentence > conveys the intended meaning. Specifically, should "currently not allowed" > be rephrased? This text is directly from RFC 7976, published in 2016. What > is the subject of "not allowed"? It can be read as the requests and responses > are not allowed. > > Based on "This specification allows some header fields to be present > in messages where they were previously not allowed" (Section 5), > we make the following suggestion. > > Original: > The Third Generation Partnership Project (3GPP) has identified cases > where different SIP private header extensions referred to as "P-" > header fields, and defined in RFC 7315, need to be included in SIP > requests and responses currently not allowed according to RFC 7315. > > Perhaps: > The Third Generation Partnership Project (3GPP) has identified cases > where different SIP private header extensions referred to as "P-" > header fields, and defined in RFC 7315, need to be included in SIP > requests and responses where they were not allowed according to RFC 7315. > --> [OK for me] > > > 5) <!--[rfced] Abstract and Introduction: Please clarify "when RFC 3455 was > updated and subsequently obsoleted by the publication of RFC 7315". > In the RFC series, "updated" and "obsoleted" have distinct meanings > regarding the relationships between RFCs. > > RFC 3455 has not been updated by any other RFCs, so the original sentence > is not accurate. We suggest simply "obsoleted" as follows. Please let us > know if this is acceptable. > > Original: > This document also makes updates for RFC 7315 in order to fix > misalignments that occurred when RFC 3455 was updated and > subsequently obsoleted by the publication of RFC 7315. > > Perhaps: > This document also makes updates for RFC 7315 in order to fix > misalignments that occurred when RFC 3455 was obsoleted by > RFC 7315. > > Or (if you prefer to explain "obsoleted"): > This document also makes updates for RFC 7315 in order to fix > misalignments that occurred when RFC 3455 was obsoleted by > RFC 7315, i.e., when the content of RFC 3455 was completely replaced. > > > FYI, similarly, we have updated Section 2.2 as follows for accuracy. > > Original: when [RFC3455] was updated and obsolated by [RFC7315] > Current: when [RFC3455] was obsoleted by [RFC7315] > -->[RJ] I would then prefer: > > This document also makes updates for RFC 7315 in order to fix > misalignments that occurred when RFC 3455 was obsoleted by > RFC 7315. > > I think this is completely OK > > 6) <!-- [rfced] Would you like the note in this document to be in an > <aside> element, or remain as is? It is defined as "a container for > content that is semantically less important or tangential to the > content that surrounds it" (https://authors.ietf.org/rfcxml-vocabulary#aside). > > Original: > NOTE: In the case of the P-Called-Party-ID header field, allowing it > in PUBLISH requests was done deliberately in [RFC7315]. Therefore, > it is not considered a misalignment. > > --> We could shift it to: <aside> element > > > 7) <!--[rfced] To prevent misreading this sentence (i.e., "the NPLI needs to > be stored as the location of the user"), may we add a comma as follows? > > Original: > When an IMS session is modified, the NPLI also > needs to be stored as the location of the user at the time when the > session is modified may generate a charging event. > > Suggested: > When an IMS session is modified, the NPLI also > needs to be stored, as the location of the user at the time when the > session is modified may generate a charging event. > > --> Yes use coma > > > 8) <!--[rfced] We suggest adding articles ('the' and 'a') as follows; please > let > us know if this is acceptable. (We note that RFC 7976 did not use > articles in similar text, but 'a SIP 2xx response' appears in other RFCs.) > > Original: ... within SIP 2xx response to the SIP INVITE request. > Perhaps: ... within the SIP 2xx response to the SIP INVITE request. > > Original: Upon reception of the SDP answer within SIP 2xx response .. > Perhaps: Upon reception of the SDP answer within a SIP 2xx response ... > > --> Yes would be good to use articles. Reads better > > > 9) <!--[rfced] non-2xx response vs. SIP non-2xx response > In other instances in this document, "SIP" does not appear before > "non-2xx response"; may it be removed here, or is it necessary? > > Original: > The P-Charging-Vector header field shall not be included in SIP ACK > requests triggered by SIP non-2xx responses. > > Perhaps (to match usage in Sections 2.3.2 and 3): > The P-Charging-Vector header field shall not be included in SIP ACK > requests triggered by non-2xx responses. > > --> OK let's go with your proposal > > > 10) <!--[rfced] FYI, in Section 3, the quote of RFC 7315 ("Old text") has > been updated to exactly match the RFC. If you prefer to keep the blank > lines between each sentence, then please let us know and we would suggest > adding text to note that it does not match the original, e.g., "Blank > lines have been added for readability." > --> We had a discussion on this. That I swhy we added the blank lines for > readability. So please keep it an add a note please. > > > 11) <!-- [rfced] FYI, we updated the 3GPP reference titles to match > the titles provided by 3GPP. We have also added URLs that point to > the specific version used in the references. Please review. > > We note the version referenced in this document is from 2016 and there have > been several updates over the years. Would you like to update this > reference to a more current version? Or would you like these > references to point to the 3GPP Technical Specifications in general? > > Current: > [TS23.228] 3GPP, "IP Multimedia Subsystem (IMS); Stage 2", Version > 13.6.0, Release 13, 3GPP TS 23.228, June 2016, > <https://www.3gpp.org/ftp//Specs/ > archive/23_series/23.228/23228-g30.zip>. > > [TS24.229] 3GPP, "IP multimedia call control protocol based on > Session Initiation Protocol (SIP) and Session Description > Protocol (SDP); Stage 3", Version 13.6.0, Release 13, 3GPP > TS 24.229, June 2016, <https://www.3gpp.org/ftp/Specs/ > archive/24_series/24.229/24229-d60.zip>. > > Perhaps: > [TS23.228] > 3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP > TS 23.228, > <https://portal.3gpp.org/desktopmodules/Specifications/ > SpecificationDetails.aspx?specificationId=821>. > > [TS24.229] > 3GPP, "IP multimedia call control protocol based on > Session Initiation Protocol (SIP) and Session Description > Protocol (SDP); Stage 3", 3GPP TS 24.229, > <https://portal.3gpp.org/desktopmodules/Specifications/ > SpecificationDetails.aspx?specificationId=1055>. > > > --> We can shift to the generic reference > > > 12) <!-- [rfced] Please review the "Inclusive Language" portion of the online > Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> > and let us know if any changes are needed. Updates of this nature typically > result in more precise language, which is helpful for readers. > > Note that our script did not flag any words in particular, but this should > still be reviewed as a best practice. > > --> I have not seen anything that must be changed under these aspects > > > Thank you. > > Alice Russo > RFC Production Center > > On Oct 10, 2025, [email protected] wrote: > > *****IMPORTANT***** > > Updated 2025/10/10 > > RFC Author(s): > -------------- > > Instructions for Completing AUTH48 > > Your document has now entered AUTH48. Once it has been reviewed and > approved by you and all coauthors, it will be published as an RFC. > If an author is no longer available, there are several remedies > available as listed in the FAQ (https://www.rfc-editor.org/faq/). > > You and you coauthors are responsible for engaging other parties > (e.g., Contributors or Working Group) as necessary before providing > your approval. > > Planning your review > --------------------- > > Please review the following aspects of your document: > > * RFC Editor questions > > Please review and resolve any questions raised by the RFC Editor > that have been included in the XML file as comments marked as > follows: > > <!-- [rfced] ... --> > > These questions will also be sent in a subsequent email. > > * Changes submitted by coauthors > > Please ensure that you review any changes submitted by your > coauthors. We assume that if you do not speak up that you > agree to changes submitted by your coauthors. > > * Content > > Please review the full content of the document, as this cannot > change once the RFC is published. Please pay particular attention to: > - IANA considerations updates (if applicable) > - contact information > - references > > * Copyright notices and legends > > Please review the copyright notice and legends as defined in > RFC 5378 and the Trust Legal Provisions > (TLP - https://trustee.ietf.org/license-info). > > * Semantic markup > > Please review the markup in the XML file to ensure that elements of > content are correctly tagged. For example, ensure that <sourcecode> > and <artwork> are set correctly. See details at > <https://authors.ietf.org/rfcxml-vocabulary>. > > * Formatted output > > Please review the PDF, HTML, and TXT files to ensure that the > formatted output, as generated from the markup in the XML file, is > reasonable. Please note that the TXT will have formatting > limitations compared to the PDF and HTML. > > > Submitting changes > ------------------ > > To submit changes, please reply to this email using 'REPLY ALL' as all > the parties CCed on this message need to see your changes. The parties > include: > > * your coauthors > > * [email protected] (the RPC team) > > * other document participants, depending on the stream (e.g., > IETF Stream participants are your working group chairs, the > responsible ADs, and the document shepherd). > > * [email protected], which is a new archival mailing list > to preserve AUTH48 conversations; it is not an active discussion > list: > > * More info: > > https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc > > * The archive itself: > https://mailarchive.ietf.org/arch/browse/auth48archive/ > > * Note: If only absolutely necessary, you may temporarily opt out > of the archiving of messages (e.g., to discuss a sensitive matter). > If needed, please add a note at the top of the message that you > have dropped the address. When the discussion is concluded, > [email protected] will be re-added to the CC list and > its addition will be noted at the top of the message. > > You may submit your changes in one of two ways: > > An update to the provided XML file > - OR - > An explicit list of changes in this format > > Section # (or indicate Global) > > OLD: > old text > > NEW: > new text > > You do not need to reply with both an updated XML file and an explicit > list of changes, as either form is sufficient. > > We will ask a stream manager to review and approve any changes that seem > beyond editorial in nature, e.g., addition of new text, deletion of text, > and technical changes. Information about stream managers can be found in > the FAQ. Editorial changes do not require approval from a stream manager. > > > Approving for publication > -------------------------- > > To approve your RFC for publication, please reply to this email stating > that you approve this RFC for publication. Please use 'REPLY ALL', > as all the parties CCed on this message need to see your approval. > > > Files > ----- > > The files are available here: > https://www.rfc-editor.org/authors/rfc9878.xml > https://www.rfc-editor.org/authors/rfc9878.html > https://www.rfc-editor.org/authors/rfc9878.pdf > https://www.rfc-editor.org/authors/rfc9878.txt > > Diff file of the text: > https://www.rfc-editor.org/authors/rfc9878-diff.html > https://www.rfc-editor.org/authors/rfc9878-rfcdiff.html (side by side) > > Diff of the XML: > https://www.rfc-editor.org/authors/rfc9878-xmldiff1.html > > > Tracking progress > ----------------- > > The details of the AUTH48 status of your document are here: > https://www.rfc-editor.org/auth48/rfc9878 > > Please let us know if you have any questions. > > Thank you for your cooperation, > > RFC Editor > > -------------------------------------- > RFC9878 (draft-ietf-sipcore-rfc7976bis-04) > > Title : Updates to Private Header (P-Header) Extension Usage in > Session Initiation Protocol (SIP) Requests and Responses > Author(s) : C. Holmberg, N. Biondic, G. Salgueiro, R. Jesske > WG Chair(s) : Brian Rosen, Jean Mahoney > Area Director(s) : Andy Newton, Orie Steele > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
