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
