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. --> 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. --> 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. --> 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. --> 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] --> 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. --> 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. --> 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 ... --> 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. --> 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." --> 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>. --> 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. --> 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]
