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://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
