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://www.rfc-editor.org/authors/rfc9796-auth48diff.html https://www.rfc-editor.org/authors/rfc9796-auth48rfcdiff.html (side by side) The current files are available here: https://www.rfc-editor.org/authors/rfc9796.xml https://www.rfc-editor.org/authors/rfc9796.txt https://www.rfc-editor.org/authors/rfc9796.pdf https://www.rfc-editor.org/authors/rfc9796.html Diffs of most recent update only: https://www.rfc-editor.org/authors/rfc9796-lastdiff.html https://www.rfc-editor.org/authors/rfc9796-lastrfcdiff.html (side by side) AUTH48 diffs: https://www.rfc-editor.org/authors/rfc9796-auth48diff.html https://www.rfc-editor.org/authors/rfc9796-auth48rfcdiff.html (side by side) Comprehensive diffs: https://www.rfc-editor.org/authors/rfc9796-diff.html https://www.rfc-editor.org/authors/rfc9796-rfcdiff.html (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://www.rfc-editor.org/authors/rfc9796.xml >> https://www.rfc-editor.org/authors/rfc9796.txt >> https://www.rfc-editor.org/authors/rfc9796.pdf >> https://www.rfc-editor.org/authors/rfc9796.html >> >> AUTH48 diffs: >> https://www.rfc-editor.org/authors/rfc9796-auth48diff.html >> https://www.rfc-editor.org/authors/rfc9796-auth48rfcdiff.html (side by side) >> >> Comprehensive diffs: >> https://www.rfc-editor.org/authors/rfc9796-diff.html >> https://www.rfc-editor.org/authors/rfc9796-rfcdiff.html (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://www.rfc-editor.org/rfc/rfc7322.html#section-3.6). 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://www.w3.org/TR/2016/REC-SRI-20160623/). We have updated this >>>> reference to that. >>>> >>>> However, please let us know if you intended to point to >>>> the First Public Working Draft >>>> (https://www.w3.org/TR/2025/WD-sri-2-20250422/) >>>> or otherwise. >>>> >>>> Original: >>>> [W3C-SRI] W3C, "Subresource Integrity", 23 July 2016, >>>> <https://www.w3.org/TR/SRI/>. >>>> >>>> Current: >>>> [W3C-SRI] Akhawe, D., Ed., Braun, F., Ed., Marier, F., Ed., and J. >>>> Weinberger, Ed., "Subresource Integrity", W3C >>>> Recommendation, 23 June 2016, >>>> <https://www.w3.org/TR/2016/REC-SRI-20160623/>. >>>> --> >>> >>> 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://www.itu.int/rec/T-REC-T.871-201105-I/en). 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://www.iso.org/standard/29581.html>. >>>> --> >>> >>> 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://authors.ietf.org/en/rfcxml-vocabulary#aside). >>>> --> >>> >>> 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://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 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://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 >>>> >>>> * 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://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, >>>> 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://www.rfc-editor.org/authors/rfc9796.xml >>>> https://www.rfc-editor.org/authors/rfc9796.html >>>> https://www.rfc-editor.org/authors/rfc9796.pdf >>>> https://www.rfc-editor.org/authors/rfc9796.txt >>>> >>>> Diff file of the text: >>>> https://www.rfc-editor.org/authors/rfc9796-diff.html >>>> https://www.rfc-editor.org/authors/rfc9796-rfcdiff.html (side by side) >>>> >>>> Diff of the XML: >>>> https://www.rfc-editor.org/authors/rfc9796-xmldiff1.html >>>> >>>> >>>> Tracking progress >>>> ----------------- >>>> >>>> The details of the AUTH48 status of your document are here: >>>> https://www.rfc-editor.org/auth48/rfc9796 >>>> >>>> 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
