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
