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
