Hi Jon, Thank you for your review. We have noted your approval on the AUTH48 page and will coordinate publication with RFC 9795.
Thank you, RFC Editor/sg > On Jul 7, 2025, at 10:53 AM, Peterson, Jon <jon.peter...@transunion.com> > wrote: > > > Okay, this looks good to me. Thanks! > > - J > > From: Sandy Ginoza <sgin...@staff.rfc-editor.org> > Date: Thursday, July 3, 2025 at 4:57 PM > To: Peterson, Jon <jon.peter...@transunion.com> > Cc: Chris Wendt <ch...@appliedbits.com>, RFC Editor > <rfc-edi...@rfc-editor.org>, sipcore-...@ietf.org <sipcore-...@ietf.org>, > sipcore-cha...@ietf.org <sipcore-cha...@ietf.org>, Jean Mahoney > <maho...@nostrum.com>, auth48archive <auth48archive@rfc-editor.org> > Subject: AUTH48: RFC-to-be 9796 <draft-ietf-sipcore-callinfo-rcd-19> for your > review > > Hi Jon, This is a reminder that we await word from you regarding this > document's readiness for publication as an RFC. The files are available from > the URLs below. Thank you, RFC Editor/sg > On Jun 30, 2025, at 1: 26 PM, > Andrew (andy) Newton > Hi Jon, > > This is a reminder that we await word from you regarding this document's > readiness for publication as an RFC. The files are available from the URLs > below. > > Thank you, > RFC Editor/sg > > > On Jun 30, 2025, at 1:26 PM, Andrew (andy) Newton <a...@hxr.us> wrote: > > > > My apologies. Looks good. Thanks. > > > > -andy > > > > On 6/26/25 14:12, Sandy Ginoza wrote: > >> Hi Jon and Andy, > >> Just a friendly reminder that we do not believe we have heard from you > >> regarding this document’s readiness for publication. Please review and > >> let us know if any updates are needed or if you approve the RFC for > >> publication. > >> Please see the notes and files below. > >> Thank you, > >> RFC Editor/sg > >>> On Jun 12, 2025, at 7:13 AM, Sandy Ginoza <sgin...@staff.rfc-editor.org> > >>> wrote: > >>> > >>> Hi Chris, Andy (as AD)*, > >>> > >>> Chris, thank you for your replies. We have updated the document as > >>> requested. > >>> > >>> *Andy, please review the diffs in Sections 4-10.1 and let us know if you > >>> approve. The updates are most easily viewed in one of these files: > >>> > >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9796-auth48diff.html__;!!GX53klZ1TQ0!2YzIjhtU--a_QRUYy3eK0TZGORROxAqeB7nXIjNqKhRrS9BA67DZew1r8IS6Von_ZK6zq7iXF0mvsforAISjI5IJP_hhBg$ > >>> > >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9796-auth48rfcdiff.html__;!!GX53klZ1TQ0!2YzIjhtU--a_QRUYy3eK0TZGORROxAqeB7nXIjNqKhRrS9BA67DZew1r8IS6Von_ZK6zq7iXF0mvsforAISjI5KYVQezIw$ > >>> (side by side) > >>> > >>> The current files are available here: > >>> > >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9796.xml__;!!GX53klZ1TQ0!2YzIjhtU--a_QRUYy3eK0TZGORROxAqeB7nXIjNqKhRrS9BA67DZew1r8IS6Von_ZK6zq7iXF0mvsforAISjI5K3X9nGag$ > >>> > >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9796.txt__;!!GX53klZ1TQ0!2YzIjhtU--a_QRUYy3eK0TZGORROxAqeB7nXIjNqKhRrS9BA67DZew1r8IS6Von_ZK6zq7iXF0mvsforAISjI5IzDJswfw$ > >>> > >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9796.pdf__;!!GX53klZ1TQ0!2YzIjhtU--a_QRUYy3eK0TZGORROxAqeB7nXIjNqKhRrS9BA67DZew1r8IS6Von_ZK6zq7iXF0mvsforAISjI5Jp2W8q9g$ > >>> > >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9796.html__;!!GX53klZ1TQ0!2YzIjhtU--a_QRUYy3eK0TZGORROxAqeB7nXIjNqKhRrS9BA67DZew1r8IS6Von_ZK6zq7iXF0mvsforAISjI5IrIPE3ag$ > >>> > >>> Diffs of most recent update only: > >>> > >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9796-lastdiff.html__;!!GX53klZ1TQ0!2YzIjhtU--a_QRUYy3eK0TZGORROxAqeB7nXIjNqKhRrS9BA67DZew1r8IS6Von_ZK6zq7iXF0mvsforAISjI5IQ1HAOCg$ > >>> > >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9796-lastrfcdiff.html__;!!GX53klZ1TQ0!2YzIjhtU--a_QRUYy3eK0TZGORROxAqeB7nXIjNqKhRrS9BA67DZew1r8IS6Von_ZK6zq7iXF0mvsforAISjI5Jki4f0fg$ > >>> (side by side) > >>> > >>> AUTH48 diffs: > >>> > >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9796-auth48diff.html__;!!GX53klZ1TQ0!2YzIjhtU--a_QRUYy3eK0TZGORROxAqeB7nXIjNqKhRrS9BA67DZew1r8IS6Von_ZK6zq7iXF0mvsforAISjI5IJP_hhBg$ > >>> > >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9796-auth48rfcdiff.html__;!!GX53klZ1TQ0!2YzIjhtU--a_QRUYy3eK0TZGORROxAqeB7nXIjNqKhRrS9BA67DZew1r8IS6Von_ZK6zq7iXF0mvsforAISjI5KYVQezIw$ > >>> (side by side) > >>> > >>> Comprehensive diffs: > >>> > >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9796-diff.html__;!!GX53klZ1TQ0!2YzIjhtU--a_QRUYy3eK0TZGORROxAqeB7nXIjNqKhRrS9BA67DZew1r8IS6Von_ZK6zq7iXF0mvsforAISjI5Keug89RA$ > >>> > >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9796-rfcdiff.html__;!!GX53klZ1TQ0!2YzIjhtU--a_QRUYy3eK0TZGORROxAqeB7nXIjNqKhRrS9BA67DZew1r8IS6Von_ZK6zq7iXF0mvsforAISjI5JH0etbdw$ > >>> (side by side) > >>> > >>> Authors, please review and let us know if any additional updates are > >>> needed or if you approve the RFC for publication. > >>> > >>> Thank you, > >>> RFC Editor/sg > >>> > >>> > >>>> On Jun 11, 2025, at 5:50 PM, Chris Wendt <ch...@appliedbits.com> wrote: > >>>> > >>>> Answer inline: > >>>> > >>>>> On Jun 9, 2025, at 3:08 PM, Sandy Ginoza <sgin...@staff.rfc-editor.org> > >>>>> wrote: > >>>>> > >>>>> Hi Chris, > >>>>> > >>>>> Thank you for your review. We have updated the document per your reply. > >>>>> > >>>>> For this item, it is unclear to us whether the RCD information or the > >>>>> Call-Info header must not be modified. > >>>>> > >>>>> > >>>>>>> 4) <!-- [rfced] For readability, please consider the possible update > >>>>>>> below. Also, is the information not to be "considered" modifiable, > >>>>>>> or should it be not modifiable? > >>>>>>> > >>>>>>> Original: > >>>>>>> The insertion of the RCD Call-Info header field > >>>>>>> should be considered a trusted action based on trusted information, > >>>>>>> and the information MUST NOT be considered modifiable representing > >>>>>>> the best practice of determining the final representation of the > >>>>>>> caller RCD to the user. > >>>>>>> > >>>>>>> Perhaps: > >>>>>>> The best way to determine the final representation of the > >>>>>>> caller RCD to the user is to consider the insertion of the > >>>>>>> RCD Call-Info header field a trusted action based on trusted > >>>>>>> information, > >>>>>>> whereby the information MUST NOT be considered modifiable. > >>>>>>> --> > >>>>>> > >>>>>> I agree that sentence is awkwardly written, but i would modify it as > >>>>>> follows: > >>>>>> Representing the trusted and verified caller RCD information to the > >>>>>> user by inserting it into the RCD Call-Info header field MUST NOT be > >>>>>> modified or altered as this should be a trusted action that accurately > >>>>>> represents the verified information. > >>>>> > >>>>> Is one of the following accurate? > >>>>> > >>>>> Perhaps A: > >>>>> Representing the trusted and verified caller RCD information to the > >>>>> user is > >>>>> accomplished by inserting it into the RCD Call-Info header field. This > >>>>> information > >>>>> MUST NOT be modified or altered because it should be a trusted action > >>>>> that > >>>>> accurately represents the verified information. > >>>>> > >>>>> Perhaps B: > >>>>> The trusted and verified caller RCD information inserted in the RCD > >>>>> Call-Info > >>>>> header field MUST NOT be modified or altered. The user should be able > >>>>> to > >>>>> trust that the RCD information accurately represents the verified > >>>>> information. > >>>>> > >>>>> Perhaps C: > >>>>> The insertion of the RCD Call-Info header field > >>>>> should be considered a trusted action based on trusted information. > >>>>> That information MUST NOT be modifiable because the insertion > >>>>> represents the best practice of determining the final representation of > >>>>> the > >>>>> caller RCD to the user. > >>>> > >>>> I think B is closest. Thanks. > >>>> > >>>>> > >>>>> > >>>>> The current files are available here: > >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9796.xml__;!!GX53klZ1TQ0!2YzIjhtU--a_QRUYy3eK0TZGORROxAqeB7nXIjNqKhRrS9BA67DZew1r8IS6Von_ZK6zq7iXF0mvsforAISjI5K3X9nGag$ > >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9796.txt__;!!GX53klZ1TQ0!2YzIjhtU--a_QRUYy3eK0TZGORROxAqeB7nXIjNqKhRrS9BA67DZew1r8IS6Von_ZK6zq7iXF0mvsforAISjI5IzDJswfw$ > >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9796.pdf__;!!GX53klZ1TQ0!2YzIjhtU--a_QRUYy3eK0TZGORROxAqeB7nXIjNqKhRrS9BA67DZew1r8IS6Von_ZK6zq7iXF0mvsforAISjI5Jp2W8q9g$ > >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9796.html__;!!GX53klZ1TQ0!2YzIjhtU--a_QRUYy3eK0TZGORROxAqeB7nXIjNqKhRrS9BA67DZew1r8IS6Von_ZK6zq7iXF0mvsforAISjI5IrIPE3ag$ > >>>>> > >>>>> AUTH48 diffs: > >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9796-auth48diff.html__;!!GX53klZ1TQ0!2YzIjhtU--a_QRUYy3eK0TZGORROxAqeB7nXIjNqKhRrS9BA67DZew1r8IS6Von_ZK6zq7iXF0mvsforAISjI5IJP_hhBg$ > >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9796-auth48rfcdiff.html__;!!GX53klZ1TQ0!2YzIjhtU--a_QRUYy3eK0TZGORROxAqeB7nXIjNqKhRrS9BA67DZew1r8IS6Von_ZK6zq7iXF0mvsforAISjI5KYVQezIw$ > >>>>> (side by side) > >>>>> > >>>>> Comprehensive diffs: > >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9796-diff.html__;!!GX53klZ1TQ0!2YzIjhtU--a_QRUYy3eK0TZGORROxAqeB7nXIjNqKhRrS9BA67DZew1r8IS6Von_ZK6zq7iXF0mvsforAISjI5Keug89RA$ > >>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9796-rfcdiff.html__;!!GX53klZ1TQ0!2YzIjhtU--a_QRUYy3eK0TZGORROxAqeB7nXIjNqKhRrS9BA67DZew1r8IS6Von_ZK6zq7iXF0mvsforAISjI5JH0etbdw$ > >>>>> (side by side) > >>>>> > >>>>> > >>>>> Thank you, > >>>>> RFC Editor/sg > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> On Jun 5, 2025, at 3:58 PM, Chris Wendt <ch...@appliedbits.com> wrote: > >>>>>> > >>>>>> > >>>>>> Thank you for the suggested improvements, my specific responses inline: > >>>>>> > >>>>>>> On May 23, 2025, at 2:51 PM, rfc-edi...@rfc-editor.org wrote: > >>>>>>> > >>>>>>> Authors, > >>>>>>> > >>>>>>> While reviewing this document during AUTH48, please resolve (as > >>>>>>> necessary) the following questions, which are also in the XML file. > >>>>>>> > >>>>>>> 1) <!-- [rfced] Is "For this document" needed? > >>>>>>> > >>>>>>> Original: > >>>>>>> For this document > >>>>>>> and depending on the policies of the communications system, a calling > >>>>>>> party could be either the end user device (e.g., a SIP user agent > >>>>>>> (UA)) or a network service as part of a telephone service provider. > >>>>>>> > >>>>>>> Perhaps: > >>>>>>> Depending on the policies of the communications system, a calling > >>>>>>> party could be either the end user device (e.g., a SIP user agent > >>>>>>> (UA)) or a network service as part of a telephone service provider. > >>>>>>> > >>>>>>> Alternatively, perhaps: > >>>>>>> As defined in this document, depending on the policies of the > >>>>>>> communications system, a calling party could be either the end > >>>>>>> user device (e.g., a SIP user agent (UA)) or a network service > >>>>>>> as part of a telephone service provider. > >>>>>>> --> > >>>>>> > >>>>>> The Perhaps clause is good > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> 2) <!-- [rfced] FYI - We have added expansions for abbreviations upon > >>>>>>> first use > >>>>>>> per the RFC Style Guide (see > >>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc7322.html*section-3.6__;Iw!!GX53klZ1TQ0!2YzIjhtU--a_QRUYy3eK0TZGORROxAqeB7nXIjNqKhRrS9BA67DZew1r8IS6Von_ZK6zq7iXF0mvsforAISjI5LFkkmo6g$). > >>>>>>> Please review each expansion in the document carefully to ensure > >>>>>>> correctness. > >>>>>>> > >>>>>>> UNI -> User-Network Interface (UNI) > >>>>>>> STIR -> Secure Telephone Identity Revisited (STIR) > >>>>>>> --> > >>>>>> > >>>>>> Yes, they are correct > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> 3) <!-- [rfced] Are logo and icons an example of calling name info? > >>>>>>> > >>>>>>> Original: > >>>>>>> The STIR RCD > >>>>>>> specification [I-D.ietf-stir-passport-rcd] defines calling name, a > >>>>>>> logo or icon associated with the caller, and a call reason string. > >>>>>>> > >>>>>>> Perhaps: > >>>>>>> The STIR RCD > >>>>>>> specification [RFC9795] defines calling name (e.g., a logo or icon > >>>>>>> associated with the caller) and a call reason string. > >>>>>>> --> > >>>>>> > >>>>>> No, but you are correct, it should be clearer: > >>>>>> Recommendation is the following: > >>>>>> The STIR RCD specification [RFC9795] defines the following primary > >>>>>> rich call data elements: a calling name, a logo or icon associated > >>>>>> with the caller, and a call reason string. > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> 4) <!-- [rfced] For readability, please consider the possible update > >>>>>>> below. Also, is the information not to be "considered" modifiable, > >>>>>>> or should it be not modifiable? > >>>>>>> > >>>>>>> Original: > >>>>>>> The insertion of the RCD Call-Info header field > >>>>>>> should be considered a trusted action based on trusted information, > >>>>>>> and the information MUST NOT be considered modifiable representing > >>>>>>> the best practice of determining the final representation of the > >>>>>>> caller RCD to the user. > >>>>>>> > >>>>>>> Perhaps: > >>>>>>> The best way to determine the final representation of the > >>>>>>> caller RCD to the user is to consider the insertion of the > >>>>>>> RCD Call-Info header field a trusted action based on trusted > >>>>>>> information, > >>>>>>> whereby the information MUST NOT be considered modifiable. > >>>>>>> --> > >>>>>> > >>>>>> I agree that sentence is awkwardly written, but i would modify it as > >>>>>> follows: > >>>>>> Representing the trusted and verified caller RCD information to the > >>>>>> user by inserting it into the RCD Call-Info header field MUST NOT be > >>>>>> modified or altered as this should be a trusted action that accurately > >>>>>> represents the verified information. > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> 5) <!-- [rfced] It's unclear which section this sentence is referring > >>>>>>> to, as this document does not have a Section 8.2. Perhaps Section > >>>>>>> 10.2 is intended? > >>>>>>> > >>>>>>> Current: > >>>>>>> Section 8.2 provides high-level guidance on image formatting and > >>>>>>> related information. > >>>>>>> --> > >>>>>> > >>>>>> Sorry it should be: Section 8.2 of [RFC9795] provides high-level … > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> 6) <!-- [rfced] We are having trouble parsing this sentence. > >>>>>>> > >>>>>>> a) Are "fn", "photo", and "logo" fields AND properties, or should the > >>>>>>> text > >>>>>>> refer to the properties (e.g., 'If "fn", "photo", or "logo" are > >>>>>>> used...')? > >>>>>>> > >>>>>>> b) What MUST match? > >>>>>>> > >>>>>>> c) Should single quotes be used as follows, as it appears token names > >>>>>>> usually appear in single quote? > >>>>>>> > >>>>>>> purpose token -> 'purpose' token > >>>>>>> > >>>>>>> Original: > >>>>>>> The fields like "fn", "photo", or "logo" if used with the use of > >>>>>>> "icon" or calling name in From or P-Asserted-ID header field or > >>>>>>> purpose token, as described in the previous section, MUST match if > >>>>>>> present to allow the called party to clearly determine the intended > >>>>>>> calling name or icon. > >>>>>>> --> > >>>>>>> > >>>>>> > >>>>>> Yes you are correct ‘purpose’ should be single quoted. > >>>>>> So suggested text to fix other questions and expand the explanation a > >>>>>> bit: > >>>>>> > >>>>>> jCard has multiple fields that may convey similar information, for > >>>>>> example, "fn", “n”, or “nickname” are strings that represent names in > >>>>>> different ways, or "photo" or "logo" represent a picture. Users of > >>>>>> this specification should make sure there is consistency for the > >>>>>> calling name string corresponding to the single name in the SIP From > >>>>>> or P-Asserted-ID header field or a “logo” or “photo” corresponds to > >>>>>> the RCD “icon” as described in the previous section. As described in > >>>>>> [RFC8224] and [RFC9795] verification procedures, the values > >>>>>> represented in the RCD MUST match the corresponding information in the > >>>>>> SIP message to enable proper verification of calling name or icon > >>>>>> consistently. > >>>>> > >>>>> > >>>>> > >>>>>> > >>>>>>> > >>>>>>> 7) <!-- [rfced] We are having trouble understanding how "or any > >>>>>>> future parameters that may be defined" relates to the text. "only" > >>>>>>> seems to limit the parameters that may be used, but "any future > >>>>>>> parameters" seems open ended (i.e., any parameter). Please review > >>>>>>> and consider whether the text can be clarified. > >>>>>>> > >>>>>>> Original: > >>>>>>> In the case that there is only a 'call-reason' or 'verified' > >>>>>>> parameter or any future parameters that may be defined and no need > >>>>>>> for a purpose parameter with no associated URI the null data URI, > >>>>>>> "data:" is used as the URI. > >>>>>>> --> > >>>>>> > >>>>>> Yes, replace with this: > >>>>>> For ‘call-reason’ or ‘verified’ parameters defined in this document > >>>>>> that do not require a an associated URI, or future parameters not > >>>>>> requiring an associated URI, the Call-Info header field URI should be > >>>>>> set to the null data URI, “data:”. > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> 8) <!--[rfced] May this be rephrased to clarify "of whom"? Seemingly > >>>>>>> this > >>>>>>> is about the trusted relationship with the party from whom they > >>>>>>> receive > >>>>>>> the SIP request. > >>>>>>> > >>>>>>> Original: > >>>>>>> As a general > >>>>>>> principle of Call-Info header field information, the recipients > >>>>>>> ability to trust the 'verified' parameter is based on the trusted > >>>>>>> relationship of whom they are receiving the SIP request. > >>>>>>> > >>>>>>> Perhaps: > >>>>>>> As a general > >>>>>>> principle of Call-Info header field information, the recipients' > >>>>>>> ability to trust the 'verified' parameter is based on the trusted > >>>>>>> relationship with the party from whom they are receiving the SIP > >>>>>>> request. > >>>>>>> --> > >>>>>> > >>>>>> Yes this is appropriate > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> 9) <!-- [rfced] 'icon' vs. "icon" > >>>>>>> This term appears in single quotes (2 instances) and double quotes (6 > >>>>>>> instances); > >>>>>>> should it be consistent? > >>>>>>> > >>>>>>> Original: > >>>>>>> Example where the parameter verified="true" is used to represent that > >>>>>>> a verification procedure has been performed within a trust domain to > >>>>>>> indicate the 'icon' URL has been successfully verified: > >>>>>>> --> > >>>>>> > >>>>>> Yes for ‘purpose’ parameter tokens, it should be double quotes, “icon” > >>>>>> since that is the string value associated with purpose=. I actually > >>>>>> found that there is an inconsistency with “jcard” also so should > >>>>>> probably make that consistent by using “jcard” with double quotes also. > >>>>> > >>>>> > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> 10) <!-- [rfced] This sentence is difficult to parse. Please clarify. > >>>>>>> > >>>>>>> Original: > >>>>>>> This > >>>>>>> document defines the convention that when a Call-Info header field > >>>>>>> with a null data URI, "data:", a default purpose of "jcard" and > >>>>>>> adding a verified="true" indicates that the display-name information > >>>>>>> in either the From and/or P-Asserted-ID header field has been > >>>>>>> verified via RCD verification procedures. > >>>>>>> > >>>>>>> Perhaps: > >>>>>>> This > >>>>>>> document defines that the display-name information > >>>>>>> in either the From and/or P-Asserted-ID header field has > >>>>>>> been verified via RCD verification procedures when the following are > >>>>>>> present: > >>>>>>> > >>>>>>> * a Call-Info header field with a null data URI, "data:", > >>>>>>> * a default purpose of "jcard", and > >>>>>>> * verified="true". > >>>>>>> --> > >>>>>> > >>>>>> Yes, that is much clearer, i think you could say it this way: > >>>>>> This document defines that the display-name information in either the > >>>>>> From and/or P-Asserted-ID header field has been verified via RCD > >>>>>> PASSporT verification procedures when the following is present: a > >>>>>> ‘purpose’ parameter tokens of “jcard”, a Call-Info header field with a > >>>>>> null data URI “data:”, and a verified parameter equal to “true”. > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> 11) <!-- [rfced] This sentence starts with "this hash value" and > >>>>>>> switches to "the integrity value", but the connection between these > >>>>>>> is unclear. Please review. > >>>>>>> > >>>>>>> Original: > >>>>>>> Typically, this hash value, assuming the URI and the resource pointed > >>>>>>> to the URI don't change between the STIR RCD PASSporT and the Call- > >>>>>>> Info URI value, the integrity value can be directly used as the same > >>>>>>> corresponding string in both the 'rcdi' claim and the 'integrity' > >>>>>>> parameter string value. > >>>>>>> > >>>>>>> Perhaps: > >>>>>>> Assuming the URI and the resource pointing > >>>>>>> to the URI don't change between the STIR RCD PASSporT and the Call- > >>>>>>> Info URI value, the integrity value can typically be used as the same > >>>>>>> corresponding string in both the "rcdi" claim and the 'integrity' > >>>>>>> parameter. > >>>>>>> --> > >>>>>> > >>>>>> Yes the new version is clearer. > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> 12) <!-- [rfced] We are having trouble parsing this sentence. Please > >>>>>>> clarify. > >>>>>>> > >>>>>>> Original: > >>>>>>> Note: the inclusion of both the 'verified' and 'integrity' when an > >>>>>>> 'rcdi' claim is included and the identity header field and included > >>>>>>> PASSporT is verified successfully is the suggested outcome. > >>>>>>> > >>>>>>> Perhaps: > >>>>>>> Note: The ideal outcome is to include the 'verified' and > >>>>>>> 'integrity' parameters in an "rcdi" claim and the identity > >>>>>>> header field, and to have the PASSporT verified successfully. > >>>>>>> --> > >>>>>> > >>>>>> Yes, not clear, suggest the following: > >>>>>> Note: When the ‘rcdi’ claim is part of the successfully verified RCD > >>>>>> PASSporT, the Call-Info Header Field should include both the > >>>>>> ‘verified’ and ‘integrity’ parameters. > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> 13) <!-- [rfced] We are unsure what "is a general anticipated > >>>>>>> process" means. Perhaps the text should refer to an "expected > >>>>>>> process" or an "accepted process"? Also, is the process a "general > >>>>>>> process" or is the process "generally anticipated"? > >>>>>>> > >>>>>>> Original: > >>>>>>> Because the 'rcd' Call-Info header field is inserted as part of the > >>>>>>> receiving part of the transition from NNI to UNI, the information > >>>>>>> populated in a received stir ‘rcd’ PASSporT that is verified is a > >>>>>>> general anticipated process for translating information into the > >>>>>>> 'rcd' Call-Info header field to transport the rich call data into the > >>>>>>> UNI toward the end user device. > >>>>>>> --> > >>>>>> > >>>>>> Yes, probably not a great way to put it, the following is an > >>>>>> appropriate replacement: > >>>>>> > >>>>>> Since the ‘rcd’ Call-Info header field is verified during the > >>>>>> transition from the Network-to-Network Interface (NNI) to the > >>>>>> User-to-Network Interface (UNI), a common approach is to extract and > >>>>>> translate the verified information from a received STIR ‘rcd’ PASSporT > >>>>>> into this header field. This allows the rich call data to be delivered > >>>>>> to the end user device through the UNI. > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> 14) <!-- [rfced] Should the text refer to the "jcard" and "icon" > >>>>>>> parameters here (i.e., lowercase and doublequotes)? > >>>>>>> > >>>>>>> Original: > >>>>>>> The following example provides both the STIR RCD PASSporT and the > >>>>>>> corresponding set of Call-Info header fields shows the use of > >>>>>>> multiple 'purpose' parameters to indicate a jCard and an icon and > >>>>>>> also a 'call-reason' parameter: > >>>>>>> --> > >>>>>> > >>>>>> Yes that would be appropriate so, i would suggest: > >>>>>> … multiple Call-Info 'purpose' tokens to indicate “jcard” and “icon” > >>>>>> and also a 'call-reason' Call-Info parameter: > >>>>>>> > >>>>>>> > >>>>>>> 15) <!-- [rfced] The last sentence below is dense and hard to follow. > >>>>>>> Please review. > >>>>>>> > >>>>>>> Original (the sentence prior is provided for context): > >>>>>>> When one or more URIs are used in a jCard, it is important to note > >>>>>>> that any URI-referenced data, with the exception of the top-level > >>>>>>> usage of "jcl" as a URI to the jCard itself MUST NOT contain any URI > >>>>>>> references. In other words, the jCard can have URI references as > >>>>>>> defined in the jCard specification and this document, but the content > >>>>>>> referenced by those URIs MUST NOT have any URIs, and therefore MUST > >>>>>>> be enforced by the client to not follow those URI references or not > >>>>>>> render that content to the user if any URI are present in that > >>>>>>> specific URI linked content. > >>>>>>> > >>>>>>> Perhaps: > >>>>>>> In other words, the jCard can have URI references as > >>>>>>> defined in the jCard specification and this document, but the content > >>>>>>> referenced by those URIs MUST NOT have any URIs; therefore, the > >>>>>>> client MUST > >>>>>>> ensure that those URI references are not followed, and any URIs that > >>>>>>> are > >>>>>>> present in that specific URI-linked content are not rendered. > >>>>>>> --> > >>>>>> > >>>>>> Yes, that works. > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> 16) <!-- [rfced] It appears as though tokens appear in double quotes. > >>>>>>> Should the section title be updated to reflect "icon"? > >>>>>>> > >>>>>>> Original: > >>>>>>> 10.2. Usage of Multimedia Data in jCard or with Icon > >>>>>>> > >>>>>>> Perhaps: > >>>>>>> 10.2. Usage of Multimedia Data in jCard or with the "icon" Token > >>>>>>> --> > >>>>>> > >>>>>> Yes, or how about “Usage of Multimedia Data in jCard or with the > >>>>>> “icon” Call-Info ‘purpose’ token” > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> 17) <!-- [rfced] Is it accurate to refer to the 'potential instances > >>>>>>> of the "tel" property', as opposed to 'instances of the "tel" > >>>>>>> property'? > >>>>>>> > >>>>>>> Original: > >>>>>>> It is important to note that any of the potential instances of the > >>>>>>> "tel" property should not be considered part of the authentication or > >>>>>>> verification part of STIR [RFC8224] or required to match the "orig" > >>>>>>> claim in the PASSporT [RFC8225]. > >>>>>>> > >>>>>>> Similarly, is "has the intent" correct in the following (instead of > >>>>>>> "provides" and "specifies")? > >>>>>>> > >>>>>>> Original: > >>>>>>> The "title" property has the intent of providing the position or job > >>>>>>> of the object the jCard represents. Reference [RFC6350], > >>>>>>> Section 6.6.1. > >>>>>>> > >>>>>>> The "role" property has the intent of providing the position or job > >>>>>>> of the object the jCard represents. Reference [RFC6350], > >>>>>>> Section 6.6.2. > >>>>>>> > >>>>>>> The "logo" property has the intent of specifying a graphic image of a > >>>>>>> logo associated with the object the jCard represents. Reference > >>>>>>> [RFC6350], Section 6.6.3. > >>>>>>> > >>>>>>> The "org" property has the intent of specifying the organizational > >>>>>>> name and units of the object the jCard represents. Reference > >>>>>>> [RFC6350], Section 6.6.4. > >>>>>>> > >>>>>>> The "version" property MUST be included and is intended to specify > >>>>>>> the version of the vCard specification used to format this vCard. > >>>>>>> --> > >>>>>> > >>>>>> Agree, the word “potential” can be removed. > >>>>>> > >>>>>> Also agree, “provides” or “specifies” can replace “has the intent of > >>>>>> providing” and “has the intent of specifying” > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> 18) <!-- [rfced] For clarity, we suggest the update below. Please > >>>>>>> review and let us know if this acceptable. > >>>>>>> > >>>>>>> Original: > >>>>>>> The end client receiving a jCard with a > >>>>>>> "url" property MUST only display the URL and not automatically follow > >>>>>>> the URL or provide automatic preview of the URL, and generally > >>>>>>> provide good practices in making it clear to the user it is their > >>>>>>> choice to follow the URL in a browser context consistent with all of > >>>>>>> the common browser security and privacy practices available on most > >>>>>>> consumer OS environments. > >>>>>>> > >>>>>>> Perhaps: > >>>>>>> The end client receiving a jCard with a > >>>>>>> "url" property MUST only display the URL and not automatically follow > >>>>>>> the URL or provide an automatic preview of the URL. In addition, it > >>>>>>> MUST generally > >>>>>>> adhere to good practice to make it clear to the user that it is their > >>>>>>> choice whether to follow the URL in a browser context consistent with > >>>>>>> all of > >>>>>>> the common browser security and privacy practices available on most > >>>>>>> consumer OS environments. > >>>>>>> --> > >>>>>> > >>>>>> Yes, clearer. > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> 19) <!-- [rfced] "since its existence" is awkward; may we update the > >>>>>>> text as follows? > >>>>>>> > >>>>>>> Current: > >>>>>>> The SIP framework, defined in [RFC3261] and the various extensions to > >>>>>>> SIP, which includes STIR [RFC8224] and rich call data [RFC9795], since > >>>>>>> its existence has provided mechanisms to assert information about the > >>>>>>> person or entity behind the call. > >>>>>>> > >>>>>>> Perhaps: > >>>>>>> The SIP framework, defined in [RFC3261] and the various extensions to > >>>>>>> SIP, which includes STIR [RFC8224] and rich call data [RFC9795], > >>>>>>> has always provided mechanisms to assert information about the > >>>>>>> person or entity behind the call. > >>>>>>> --> > >>>>>> > >>>>>> Yes, better. > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> 20) <!-- [rfced] What does "weigh this responsibility" refer to? Is > >>>>>>> it > >>>>>>> the core security consideration, the risk of impersonation, or both? > >>>>>>> > >>>>>>> Original (earlier sentences included for context): > >>>>>>> It can also > >>>>>>> enable the ability for actors to impersonate a calling party they are > >>>>>>> not authorized to represent. The core security consideration that > >>>>>>> either explicitly or implicitly have been acknowledged with any of > >>>>>>> the SIP and STIR specifications is that there is a management and > >>>>>>> policy layer that validates the participants in the ecosystem and > >>>>>>> their use of a SIP network with telephone number identifiers and > >>>>>>> identity related information. The use of this specification should > >>>>>>> weigh this responsibility and make the appropriate considerations to > >>>>>>> validate the proper participation and use of these tools follow these > >>>>>>> larger security, impersonation prevention, and privacy > >>>>>>> considerations. > >>>>>>> > >>>>>>> Perhaps: > >>>>>>> Users should assess this [risk / core consideration / both the risk > >>>>>>> and core consideration] and make the appropriate adjustments to > >>>>>>> validate proper participation while following these > >>>>>>> larger security, impersonation prevention, and privacy > >>>>>>> considerations. > >>>>>>> --> > >>>>>> > >>>>>> I would suggest: > >>>>>> Users should assess this risk and make the appropriate adjustments to > >>>>>> validate proper participation while … > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> 21) <!--[rfced] May this be rephrased for readability? If so, who > >>>>>>> should > >>>>>>> do the considering? > >>>>>>> > >>>>>>> Original: > >>>>>>> A network specific > >>>>>>> set of policies or best practices for the use and hosting of media > >>>>>>> content that is agreed to contain validated media resources that have > >>>>>>> been evaluated to not pose a security threat to the participants or > >>>>>>> the devices supported in the ecosystem should be considered. > >>>>>>> > >>>>>>> Perhaps: > >>>>>>> Network administrators should consider a network-specific > >>>>>>> set of policies or best practices for the use and hosting of media > >>>>>>> content that is agreed to contain validated media resources that have > >>>>>>> been evaluated to not pose a security threat to the participants or > >>>>>>> the devices supported in the ecosystem. > >>>>>>> --> > >>>>>> > >>>>>> You can replace as suggested, “network administrators” is appropriate > >>>>>> for who is doing the considering. > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> 22) <!-- [rfced] Regarding [W3C-SRI], the original URL > >>>>>>> for this reference directed the reader to a W3C First Public Working > >>>>>>> Draft > >>>>>>> with a date of 22 April 2025. However, the original date provided for > >>>>>>> this reference was 23 June 2016, which matches that of the W3C > >>>>>>> Recommendation titled "Subresource Integrity" > >>>>>>> (https://urldefense.com/v3/__https://www.w3.org/TR/2016/REC-SRI-20160623/__;!!GX53klZ1TQ0!2YzIjhtU--a_QRUYy3eK0TZGORROxAqeB7nXIjNqKhRrS9BA67DZew1r8IS6Von_ZK6zq7iXF0mvsforAISjI5ISLk2glQ$). > >>>>>>> We have updated this > >>>>>>> reference to that. > >>>>>>> > >>>>>>> However, please let us know if you intended to point to > >>>>>>> the First Public Working Draft > >>>>>>> (https://urldefense.com/v3/__https://www.w3.org/TR/2025/WD-sri-2-20250422/__;!!GX53klZ1TQ0!2YzIjhtU--a_QRUYy3eK0TZGORROxAqeB7nXIjNqKhRrS9BA67DZew1r8IS6Von_ZK6zq7iXF0mvsforAISjI5IN8OhaJg$) > >>>>>>> or otherwise. > >>>>>>> > >>>>>>> Original: > >>>>>>> [W3C-SRI] W3C, "Subresource Integrity", 23 July 2016, > >>>>>>> > >>>>>>> <https://urldefense.com/v3/__https://www.w3.org/TR/SRI/__;!!GX53klZ1TQ0!2YzIjhtU--a_QRUYy3eK0TZGORROxAqeB7nXIjNqKhRrS9BA67DZew1r8IS6Von_ZK6zq7iXF0mvsforAISjI5KsEpZcsg$>. > >>>>>>> > >>>>>>> Current: > >>>>>>> [W3C-SRI] Akhawe, D., Ed., Braun, F., Ed., Marier, F., Ed., and J. > >>>>>>> Weinberger, Ed., "Subresource Integrity", W3C > >>>>>>> Recommendation, 23 June 2016, > >>>>>>> > >>>>>>> <https://urldefense.com/v3/__https://www.w3.org/TR/2016/REC-SRI-20160623/__;!!GX53klZ1TQ0!2YzIjhtU--a_QRUYy3eK0TZGORROxAqeB7nXIjNqKhRrS9BA67DZew1r8IS6Von_ZK6zq7iXF0mvsforAISjI5ISLk2glQ$>. > >>>>>>> --> > >>>>>> > >>>>>> You can use the reference as listed above to the 2016 version. > >>>>>> > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> 23) <!-- [rfced] Regarding [ITUJPEG]: This reference uses the date > >>>>>>> for the ISO/IEC > >>>>>>> Standard ISO/IEC 10918-5 (May 2013), but points to the ITU-T > >>>>>>> Recommendation which was published in May 2011 > >>>>>>> (https://urldefense.com/v3/__https://www.itu.int/rec/T-REC-T.871-201105-I/en__;!!GX53klZ1TQ0!2YzIjhtU--a_QRUYy3eK0TZGORROxAqeB7nXIjNqKhRrS9BA67DZew1r8IS6Von_ZK6zq7iXF0mvsforAISjI5LKtv0MiA$). > >>>>>>> We have updated this > >>>>>>> reference to use the date for the ITU-T Recommendation and added a URL > >>>>>>> pointing to that specification. Please let us know if you have any > >>>>>>> concerns. > >>>>>>> --> > >>>>>> > >>>>>> No concern > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> 24) <!-- [rfced] We have added a URL to the [ISOPNG] reference. > >>>>>>> Please let us know if you have any concerns. > >>>>>>> > >>>>>>> Current: > >>>>>>> [ISOPNG] ISO/IEC, "Information technology - Computer graphics and > >>>>>>> image processing - Portable Network Graphics (PNG), > >>>>>>> Functional specification", ISO/IEC 15948:2004, March 2004, > >>>>>>> > >>>>>>> <https://urldefense.com/v3/__https://www.iso.org/standard/29581.html__;!!GX53klZ1TQ0!2YzIjhtU--a_QRUYy3eK0TZGORROxAqeB7nXIjNqKhRrS9BA67DZew1r8IS6Von_ZK6zq7iXF0mvsforAISjI5IBWYzxIw$>. > >>>>>>> --> > >>>>>> > >>>>>> No concern > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> 25) <!-- [rfced] Note that we updated claim names to use double > >>>>>>> quotes to match the use in RFC-to-be 9575 > >>>>>>> <draft-ietf-stir-passport-rcd>. Please let us know if any updates > >>>>>>> are required. > >>>>>>> > >>>>>>> Throughout the text, the following terminology appears to be used > >>>>>>> inconsistently. Please review these occurrences and let us know > >>>>>>> if/how they > >>>>>>> may be made consistent. > >>>>>>> > >>>>>>> rich call data vs. Rich Call Data > >>>>>>> > >>>>>>> Also, would you like instances of "Rich Call Data" to be replaced > >>>>>>> with "RCD" > >>>>>>> throughout, or is it intentionally expanded in the instances that > >>>>>>> remain? > >>>>>>> --> > >>>>>> > >>>>>> Use of RCD throughout is probably the most appropriate. > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> 26) <!-- [rfced] Please review whether any of the notes in this > >>>>>>> document > >>>>>>> should be in the <aside> element. It is defined as "a container for > >>>>>>> content that is semantically less important or tangential to the > >>>>>>> content that surrounds it" > >>>>>>> (https://urldefense.com/v3/__https://authors.ietf.org/en/rfcxml-vocabulary*aside__;Iw!!GX53klZ1TQ0!2YzIjhtU--a_QRUYy3eK0TZGORROxAqeB7nXIjNqKhRrS9BA67DZew1r8IS6Von_ZK6zq7iXF0mvsforAISjI5KlPq-pZA$). > >>>>>>> --> > >>>>>> > >>>>>> That would be fine, thanks for the reference wasn’t aware of that. > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> 27) <!-- [rfced] Please review the "Inclusive Language" portion of > >>>>>>> the online > >>>>>>> Style Guide > >>>>>>> <https://urldefense.com/v3/__https://www.rfc-editor.org/styleguide/part2/*inclusive_language__;Iw!!GX53klZ1TQ0!2YzIjhtU--a_QRUYy3eK0TZGORROxAqeB7nXIjNqKhRrS9BA67DZew1r8IS6Von_ZK6zq7iXF0mvsforAISjI5JMkxSIAQ$> > >>>>>>> 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 reviewed and did not identify any additional needed changes. > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Thank you. > >>>>>>> > >>>>>>> RFC Editor/sg/ar > >>>>>>> > >>>>>>> On May 23, 2025, rfc-edi...@rfc-editor.org wrote: > >>>>>>> > >>>>>>> *****IMPORTANT***** > >>>>>>> > >>>>>>> Updated 2025/05/23 > >>>>>>> > >>>>>>> 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://urldefense.com/v3/__https://www.rfc-editor.org/faq/__;!!GX53klZ1TQ0!2YzIjhtU--a_QRUYy3eK0TZGORROxAqeB7nXIjNqKhRrS9BA67DZew1r8IS6Von_ZK6zq7iXF0mvsforAISjI5KvKn3zoQ$). > >>>>>>> > >>>>>>> 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://urldefense.com/v3/__https://trustee.ietf.org/license-info__;!!GX53klZ1TQ0!2YzIjhtU--a_QRUYy3eK0TZGORROxAqeB7nXIjNqKhRrS9BA67DZew1r8IS6Von_ZK6zq7iXF0mvsforAISjI5KMZII2UQ$). > >>>>>>> > >>>>>>> * 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://urldefense.com/v3/__https://authors.ietf.org/rfcxml-vocabulary__;!!GX53klZ1TQ0!2YzIjhtU--a_QRUYy3eK0TZGORROxAqeB7nXIjNqKhRrS9BA67DZew1r8IS6Von_ZK6zq7iXF0mvsforAISjI5KiOaHoKQ$>. > >>>>>>> > >>>>>>> * 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 > >>>>>>> > >>>>>>> * rfc-edi...@rfc-editor.org (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). > >>>>>>> > >>>>>>> * auth48archive@rfc-editor.org, which is a new archival mailing list > >>>>>>> to preserve AUTH48 conversations; it is not an active discussion > >>>>>>> list: > >>>>>>> > >>>>>>> * More info: > >>>>>>> > >>>>>>> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc__;!!GX53klZ1TQ0!2YzIjhtU--a_QRUYy3eK0TZGORROxAqeB7nXIjNqKhRrS9BA67DZew1r8IS6Von_ZK6zq7iXF0mvsforAISjI5Ksygez-g$ > >>>>>>> > >>>>>>> * The archive itself: > >>>>>>> > >>>>>>> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/auth48archive/__;!!GX53klZ1TQ0!2YzIjhtU--a_QRUYy3eK0TZGORROxAqeB7nXIjNqKhRrS9BA67DZew1r8IS6Von_ZK6zq7iXF0mvsforAISjI5JqQqnWkQ$ > >>>>>>> > >>>>>>> * 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, > >>>>>>> auth48archive@rfc-editor.org 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://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9796.xml__;!!GX53klZ1TQ0!2YzIjhtU--a_QRUYy3eK0TZGORROxAqeB7nXIjNqKhRrS9BA67DZew1r8IS6Von_ZK6zq7iXF0mvsforAISjI5K3X9nGag$ > >>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9796.html__;!!GX53klZ1TQ0!2YzIjhtU--a_QRUYy3eK0TZGORROxAqeB7nXIjNqKhRrS9BA67DZew1r8IS6Von_ZK6zq7iXF0mvsforAISjI5IrIPE3ag$ > >>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9796.pdf__;!!GX53klZ1TQ0!2YzIjhtU--a_QRUYy3eK0TZGORROxAqeB7nXIjNqKhRrS9BA67DZew1r8IS6Von_ZK6zq7iXF0mvsforAISjI5Jp2W8q9g$ > >>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9796.txt__;!!GX53klZ1TQ0!2YzIjhtU--a_QRUYy3eK0TZGORROxAqeB7nXIjNqKhRrS9BA67DZew1r8IS6Von_ZK6zq7iXF0mvsforAISjI5IzDJswfw$ > >>>>>>> > >>>>>>> Diff file of the text: > >>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9796-diff.html__;!!GX53klZ1TQ0!2YzIjhtU--a_QRUYy3eK0TZGORROxAqeB7nXIjNqKhRrS9BA67DZew1r8IS6Von_ZK6zq7iXF0mvsforAISjI5Keug89RA$ > >>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9796-rfcdiff.html__;!!GX53klZ1TQ0!2YzIjhtU--a_QRUYy3eK0TZGORROxAqeB7nXIjNqKhRrS9BA67DZew1r8IS6Von_ZK6zq7iXF0mvsforAISjI5JH0etbdw$ > >>>>>>> (side by side) > >>>>>>> > >>>>>>> Diff of the XML: > >>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9796-xmldiff1.html__;!!GX53klZ1TQ0!2YzIjhtU--a_QRUYy3eK0TZGORROxAqeB7nXIjNqKhRrS9BA67DZew1r8IS6Von_ZK6zq7iXF0mvsforAISjI5IFNQtFpg$ > >>>>>>> > >>>>>>> > >>>>>>> Tracking progress > >>>>>>> ----------------- > >>>>>>> > >>>>>>> The details of the AUTH48 status of your document are here: > >>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9796__;!!GX53klZ1TQ0!2YzIjhtU--a_QRUYy3eK0TZGORROxAqeB7nXIjNqKhRrS9BA67DZew1r8IS6Von_ZK6zq7iXF0mvsforAISjI5IorWGZ4w$ > >>>>>>> > >>>>>>> Please let us know if you have any questions. > >>>>>>> > >>>>>>> Thank you for your cooperation, > >>>>>>> > >>>>>>> RFC Editor > >>>>>>> > >>>>>>> -------------------------------------- > >>>>>>> RFC9796 (draft-ietf-sipcore-callinfo-rcd-19) > >>>>>>> > >>>>>>> Title : SIP Call-Info Parameters for Rich Call Data > >>>>>>> Author(s) : C. Wendt, J. Peterson > >>>>>>> WG Chair(s) : Brian Rosen, Jean Mahoney > >>>>>>> Area Director(s) : Andy Newton, Orie Steele > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
