Everything looks good to me and ready to publish. -Chris
> On Jun 17, 2025, at 1:54 PM, Alice Russo <aru...@staff.rfc-editor.org> wrote: > > Jon, Chris, > > 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/ar > >> On Jun 9, 2025, at 3:16 PM, Alice Russo <aru...@staff.rfc-editor.org> wrote: >> >> Chris, >> >> Thank you for your reply. The revised files are here (please refresh): >> https://www.rfc-editor.org/authors/rfc9795.html >> https://www.rfc-editor.org/authors/rfc9795.txt >> https://www.rfc-editor.org/authors/rfc9795.pdf >> https://www.rfc-editor.org/authors/rfc9795.xml >> >> This diff file shows all changes from the approved I-D: >> https://www.rfc-editor.org/authors/rfc9795-diff.html >> https://www.rfc-editor.org/authors/rfc9795-rfcdiff.html (side by side) >> >> This diff file shows the changes made during AUTH48 thus far: >> https://www.rfc-editor.org/authors/rfc9795-auth48diff.html >> https://www.rfc-editor.org/authors/rfc9795-auth48rfcdiff.html (side by side) >> >> Re: #26, <aside> is used by some authors; it is not required. We've only >> added one instance of <aside> for the note that starts "Note:" in Section >> 5.1.4. Please let us know if any updates are needed. >> >> We will wait to hear from you again and from your coauthor >> before continuing the publication process. This page shows >> the AUTH48 status of your document: >> https://www.rfc-editor.org/auth48/rfc9795 >> >> Thank you. >> RFC Editor/ar >> >>>> On Jun 7, 2025, at 6:47 AM, Chris Wendt <chris-i...@chriswendt.net> wrote: >>> >>> >>> Thanks for the review and suggestions. Comments inline: >>> >>>> On May 23, 2025, at 4:54 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] For clarity, may the last phrase of this sentence be >>>> reworded as follows or otherwise? It's not clear what is placing the >>>> constraint on the RCD. >>>> >>>> Original: >>>> Finally, this document describes how to preserve the integrity of the >>>> RCD in scenarios where there may be non-authoritative users >>>> initiating and signing RCD and therefore a constraint on the RCD data >>>> that a PASSporT can attest via certificate-level controls. >>>> >>>> Option A: >>>> Finally, this document describes how to preserve the integrity of the >>>> RCD in scenarios where there may be non-authoritative users initiating >>>> and signing RCD, therefore limiting whether a PASSporT can attest the >>>> RCD via certificate-level controls. >>>> >>>> Option B: >>>> Finally, this document describes how to preserve the integrity of the >>>> RCD in scenarios where there may be non-authoritative users initiating >>>> and signing RCD by specifying the use of JWT claims constraints on the >>>> RCD data that a PASSporT can attest to via certificate-level controls. >>>> --> >>> >>> Option A works well. >>> Maybe slight variation: >>> Finally, this document describes how to preserve the integrity of the RCD >>> in scenarios where there may be non-authoritative users initiating and >>> signing RCD, therefore limiting a PASSporT and the RCD claims it asserts >>> via certificate-level controls. >>> >>>> >>>> >>>> 2) <!--[rfced] Please clarify the list in this sentence. >>>> >>>> Original: >>>> This document defines a >>>> mechanism that allows for a direct or indirect party that enforces >>>> the policies to approve or certify the content, create a >>>> cryptographic digest that can be used to validate that data and >>>> applies a constraint in the certificate to allow the recipient and >>>> verifier to validate that the specific content of the RCD is as >>>> intended at its creation and approval or certification. >>>> >>>> Option A: >>>> This document defines a mechanism that allows for a party that >>>> (a) enforces X, (b) creates Y, and (c) applies Z. >>>> >>>> Option B: >>>> This document defines a mechanism that >>>> (a) allows for a party that enforces X, (b) creates Y, and (c) applies Z. >>>> >>>> >>>> Perhaps (if Option A is accurate): >>>> This document defines a mechanism that allows for a direct or >>>> indirect party that (a) enforces >>>> the policies to approve or certify the content, (b) creates a >>>> cryptographic digest that can be used to validate that data, and >>>> (c) applies a constraint in the certificate to allow the recipient and >>>> verifier to validate that the specific content of the RCD is as >>>> intended at its creation and its approval or certification. >>>> --> >>> >>> The suggested text above works. >>> >>>> >>>> >>>> 3) <!--[rfced] May this phrase be reworded for clarity? >>>> Seems "allowing the ability to enable a mechanism for allowing" >>>> could be simplified. >>>> >>>> Original: >>>> The third and fourth modes cover cases where there is a different >>>> authoritative entity responsible for the content of the RCD, separate >>>> from the signer of the PASSporT itself, allowing the ability, in >>>> particular when delegating signing authority for PASSporT, to enable >>>> a mechanism for allowing agreed or vetted content included in or >>>> referenced by the RCD claim contents. >>>> >>>> Specifically, regarding the last part: >>>> allowing the ability, in particular when [...], >>>> to enable a mechanism for allowing agreed or vetted content included in >>>> or referenced by the RCD claim contents. >>>> >>>> Option A: >>>> allowing the ability, in particular when [...], >>>> to enable a mechanism for agreed or vetted content to be included >>>> in or referenced by the RCD claim contents. >>>> >>>> Option B: >>>> allowing the ability, in particular when [...], >>>> for agreed or vetted content to be included in or >>>> referenced by the RCD claim contents. >>>> --> >>> >>> Option B is simple and works. >>> >>>> >>>> >>>> 4) <!-- [rfced] This sentence appeared to intend to cite 3GPP TS 24.229, >>>> but there was not a corresponding reference. We added an informative >>>> reference as follows; please review and let us know if this is accurate. >>>> Would you like to update this to the most recent version? (We see >>>> version 19.0.2 from March 2025.) >>>> >>>> Original: >>>> The "apn" key value is an optional alternate presentation number >>>> associated with the originator of personal communications, which may >>>> for example match the user component of the From header field value >>>> of a SIP request (in cases where a network number is carried in the >>>> P-Asserted-Identity [RFC3325]), or alternatively from the Additional- >>>> Identity header field value [3GPP TS 24.229 v16.7.0], or a similar >>>> field in other PASSporT using protocols. >>>> >>>> Current: >>>> The "apn" key value is an optional alternate presentation number >>>> associated with the originator of personal communications, which may >>>> for example match the user component of the From header field value >>>> of a SIP request (in cases where a network number is carried in the >>>> P-Asserted-Identity [RFC3325]), or alternatively of the Additional- >>>> Identity header field value [TS.3GPP.24.229], or a similar >>>> field in other PASSporT-using protocols. >>>> >>>> Added in Section 18.2: >>>> >>>> [TS.3GPP.24.229] >>>> 3GPP, "IP multimedia call control protocol based on >>>> Session Initiation Protocol (SIP) and Session Description >>>> Protocol (SDP); Stage 3", 16.7.0, 3GPP TS 24.229, >>>> September 2020, >>>> <https://www.3gpp.org/ftp/Specs/html-info/24229.htm>. >>>> --> >>> >>> That is correct >>> >>>> >>>> >>>> 5) <!--[rfced] What does "This usage" refer to? The preceding sentence >>>> is included for context. Perhaps it refers to the use of the "apn" >>>> key in general? >>>> >>>> Original: >>>> How the signer determines >>>> that a user is authorized to present the number in question is a >>>> policy decision outside the scope of this document, however, the >>>> vetting of the alternate presentation number should follow the same >>>> level of vetting as telephone identities or any other information >>>> contained in an "rcd" PASSporT or "rcd" claims. This usage is >>>> intended as an alternative to conveying the presentation number in >>>> the "tel" key value of a jCard, in situations where no other rich >>>> jCard data needs to be conveyed with the call. >>>> >>>> Perhaps: >>>> How the signer determines [...] >>>> The use of the "apn" key is intended as an alternative to conveying >>>> the presentation number ... >>>> --> >>> >>> Yes, clearer >>> >>>> >>>> >>>> 6) <!--[rfced] Please clarify "using Call-Info as protocol". >>>> >>>> Original: >>>> Note: even though we refer to [RFC9796] as the definition of the >>>> jcard properties for usage in "rcd" claims, using Call-Info as >>>> protocol with the addition of an identity header carrying the >>>> PASSPorT is not required. >>>> --> >>> >>> How about “… using the Call-Info header field with RCD information in a SIP >>> request beyond the use of identity header as defined in this document is >>> not required. Identity header fields are generally encouraged for all >>> transport of authenticated and protected RCD information over >>> Network-to-Network Interfaces (NNI) between untrusted parties or over >>> untrusted networks. The use of Call-Info header fields to carry RCD >>> information as defined in [RFC9796] is suggested for use in trusted >>> networks relationships, generally for User-Network Interfaces (UNI).” >>> >>>> >>>> >>>> 7) <!--[rfced] Is this a 1:1 relationship? In other words, >>>> should this be "Each of these claims corresponds to each of the elements"? >>>> >>>> Original: >>>> These objects correspond to each of the >>>> elements of the "rcd" claim object that require integrity protection >>>> with an associated digest over the content referenced by the key >>>> string. >>>> --> >>> >>> Correct, it is a 1:1 relationship. >>> Each “rcdi” claim key/value pair corresponds to each of the elements of the >>> “rcd” claim object … >>> >>>> >>>> >>>> 8) <!--[rfced] Would you like to list the codepoint for this character >>>> in a more typical manner? "ASCII 45" was last used in RFC 1849. >>>> >>>> Original: >>>> MUST be a hyphen character, "-", or ASCII 45. >>>> >>>> Perhaps: >>>> MUST be a hyphen character ("-", %x2D). >>>> >>>> Or: >>>> MUST be a hyphen character, "-" (HYPHEN-MINUS, U+002D). >>>> --> >>> >>> Yes the first suggestion works. >>> >>>> >>>> >>>> 9) <!--[rfced] How should the first point be changed to a complete >>>> sentence? (The second and third points are complete sentences.) >>>> Also, for subject/verb agreement, should "the JWT Claim Constraints is >>>> applied" be "the JWT Claim Constraints certificate extension is applied" >>>> or "the JWT Claim Constraints are applied" or otherwise? >>>> >>>> Preceding sentence for context: >>>> In order to facilitate proper verification of the digests and to >>>> determine whether the "rcd" elements or content referenced by URIs >>>> were modified, the input to the digest must be completely >>>> deterministic at three points in the process: >>>> >>>> Original: >>>> First, at the certification point where the content >>>> is evaluated to conform to the application policy and the JWT Claim >>>> Constraints is applied to the certificate containing the digest. >>>> >>>> Perhaps: >>>> First, it must be deterministic at the certification point when the >>>> content is evaluated to conform to the application policy and when >>>> the JWT Claim Constraints are applied to the certificate containing >>>> the digest. >>>> --> >>> >>> The suggested text is good. >>> >>>> >>>> >>>> 10) <!--[rfced] Please clarify this sentence. In particular, what does >>>> "with the exception and the minor modification" mean? >>>> We suggest making this into two sentences. >>>> >>>> Original: >>>> In the case of the use of a "jcl" URI reference to an external jCard, >>>> the procedures are similar to "jcd" with the exception and the minor >>>> modification to JSON pointer, where "/jcl" is used to refer to the >>>> external jCard array string and any following numeric array indices >>>> added to the "jcl" (e.g., "/jcl/1/2/3") are treated as if the >>>> external content referenced by the jCard was directly part of the >>>> overall "rcd" claim JSON object. >>>> >>>> Perhaps: >>>> In the case of the use of a "jcl" URI reference to an external jCard, >>>> the procedures are similar to "jcd" with the minor >>>> modification to the JSON pointer, where "/jcl" is used to refer to the >>>> external jCard array string. Also, any following numeric array indices >>>> added to the "jcl" (e.g., "/jcl/1/2/3") are treated as if the >>>> external content referenced by the jCard were directly part of the >>>> overall "rcd" claim JSON object. >>>> --> >>> >>> Yes this works. >>> >>>> >>>> >>>> 11) <!--[rfced] May 'usage' be cut from the title of Section 6.3 for >>>> consistency with the title of Section 6.2? >>>> >>>> Original: >>>> 6.2. JWT Claim Constraints for "rcd" claims >>>> 6.3. JWT Claim Constraints usage for "rcd" and "rcdi" claims >>>> >>>> Perhaps: >>>> 6.2. JWT Claim Constraints for "rcd" Claims >>>> 6.3. JWT Claim Constraints for "rcd" and "rcdi" Claims >>>> --> >>> >>> Yes >>> >>>> >>>> >>>> 12) <!--[rfced] Is this whole sentence describing an example? If so, we >>>> suggest moving "as an example" to the start. >>>> >>>> Original: >>>> This would often be associated with the use of delegate >>>> certificates [RFC9060] for the signing of calls by the calling party >>>> directly as an example, even though the "authorized party" is not >>>> necessarily the subject of a STIR certificate. >>>> >>>> Perhaps: >>>> For example, this may be used with delegate certificates [RFC9060] >>>> for the signing of calls by the calling party directly, even though >>>> the "authorized party" is not necessarily the subject of a STIR >>>> certificate. >>>> --> >>> >>> That works. >>> >>>> >>>> >>>> 13) <!--[rfced] May we update these section titles to make them parallel >>>> and simplified? >>>> >>>> Original: >>>> 5. PASSporT Claim "rcd" Definition and Usage >>>> 6. "rcdi" RCD Integrity Claim Definition and Usage >>>> 7. PASSporT "crn" claim - Call Reason Definition and Usage >>>> >>>> Option A: >>>> 5. PASSporT Claim "rcd" Definition and Usage >>>> 6. PASSporT Claim "rcdi" Definition and Usage >>>> 7. PASSporT Claim "crn" Definition and Usage >>>> >>>> Option B (as this word order is also used within this document): >>>> 5. "rcd" PASSporT Claim: Definition and Usage >>>> 6. "rcdi" PASSporT Claim: Definition and Usage >>>> 7. "crn" PASSporT Claim: Definition and Usage >>>> --> >>> >>> Yes, Option B works. >>> >>>> >>>> >>>> 14) <!--[rfced] There is one instance of "JWT Constraints" (plural) in this >>>> document; should it be "JWT Claim Constraints" to match usage elsewhere >>>> within this document? >>>> >>>> Original: >>>> The integrity of the "crn" claim contents can optionally be protected >>>> by the authoritative certificate issuer using JWT Constraints in the >>>> certificate. >>>> --> >>> >>> Yes please normalize with “Claim” included. >>> >>>> >>>> >>>> 15) <!--[rfced] May this be rephrased to clarify "at least one or both an"? >>>> >>>> Original: >>>> ... in which case the PASSporT >>>> claims MUST contain at least one or both an "rcd" or "crn" claim. >>>> >>>> Perhaps: >>>> In that case, >>>> the PASSporT MUST contain at least one "rcd" or "crn" claim (or both). >>>> --> >>> >>> Yes that works. >>> >>>> >>>> >>>> 16) <!--[rfced] Do both of these sentences refer to the example that >>>> follows? Perhaps the text can be clarified? >>>> >>>> Original: >>>> In an example PASSporT, where a jCard is linked via HTTPS URL using >>>> "jcl", a jCard file served at a particular URL. >>>> >>>> An example jCard JSON file hosted at the example web address of >>>> https://example.com/qbranch.json is shown as follows: >>>> >>>> Perhaps: >>>> In the following PASSporT example, a jCard is linked via HTTPS URL >>>> using "jcl", and a jCard file is served at a particular URL. >>>> >>>> Example jCard JSON file hosted at https://example.com/qbranch.json: >>>> --> >>> >>> Yes, suggestion is good. >>> >>>> >>>> >>>> 17) <!--[rfced] Please clarify this sentence. Specifically, >>>> what is "leading to too restrictive a set of constraints"? >>>> Also, please consider starting with "The claims" or similar >>>> to make a clearer break with the preceding sentence (which ends >>>> with the example of the empty string "".). >>>> >>>> Original: >>>> "jcl" and "jcd" MUST NOT be used with compact form due to >>>> integrity rules and URI reference rules in this document leading to >>>> too restrictive of a set of constraints. >>>> >>>> Perhaps: >>>> The claims >>>> "jcl" and "jcd" MUST NOT be used with compact form because >>>> the integrity rules and URI reference rules defined in this document >>>> would lead to a set of constraints that is too restrictive. >>>> --> >>> >>> Suggested text is good. >>> >>>> >>>> >>>> 18) <!--[rfced] What is "It" in "It is intended"? The third-party PASSporT? >>>> (The preceding sentence is included for context.) >>>> >>>> Original: >>>> This third-party >>>> PASSporT attests information about the calling number, rather than >>>> the call or caller itself, and as such its RCD MUST NOT be used when >>>> a call lacks a first-party PASSporT that assures verification >>>> services that the calling party number is not spoofed. It is >>>> intended to be used in cases when the originating side does not >>>> supply a display-name for the caller, so instead some entity in the >>>> call path invokes a third-party service to provide rich caller data >>>> for a call. >>>> --> >>> >>> Yes, Replace “It is” with “A third-party PASSporT is” >>> >>>> >>>> >>>> 19) <!--[rfced] Please clarify "providers that are indirectly or delegated >>>> authority to sign PASSporTs". What is the intended meaning? Is a word >>>> missing? >>>> >>>> Original: >>>> As "rcd" can be provided by either first party providers that are >>>> directly authorized to sign PASSporTs in the STIR eco-system or third >>>> party providers that are indirectly or delegated authority to sign >>>> PASSporTs. >>>> --> >>> >>> The word ‘As “rcd”’ should just be replaced with ‘A set of ”rcd” claims’ to >>> make it a complete factual phrase. >>> >>>> >>>> >>>> 20) <!--[rfced] Please note that we have removed "and" from the sentence >>>> below. Please let us know if this incorrect. >>>> >>>> Original: >>>> This section documents SIP-specific usage for "rcd" PASSporTs and in >>>> the SIP Identity header field value. >>>> >>>> Current: >>>> This section documents SIP-specific usage for "rcd" PASSporTs in >>>> the SIP Identity header field value. >>>> --> >>> >>> Yes that works. >>> >>>> >>>> >>>> 21) <!--[rfced] Is this a list of five elements? If so, may it be rephrased >>>> as follows or otherwise? >>>> >>>> Original: >>>> Similarly, "jcd" or "jcl" jcard information, "icn", "apn", or "crn" >>>> can be optionally, based on local policy for devices that support it, >>>> used to populate a Call-Info header field following the format of >>>> [I-D.ietf-sipcore-callinfo-rcd]. >>>> >>>> Perhaps: >>>> Similarly, "jcd", "jcl", "icn", "apn", or "crn" elements >>>> can be used optionally (based on local policy for devices that support >>>> it) to populate a Call-Info header field following the format of >>>> [RFC9796]. >>>> --> >>> >>> That works. >>> >>>> >>>> >>>> 22) <!-- [rfced] Regarding [ATIS-1000074.v002], the original URL provided >>>> yields "Sorry, the document could not be found". >>>> We found the following URL of a more recent version of this standard: >>>> https://access.atis.org/higherlogic/ws/public/download/67436 >>>> (which appears to be Version 3 of this standard and was published >>>> 16 August 2022). May we update this reference to that version? >>>> >>>> Original: >>>> [ATIS-1000074.v002] >>>> ATIS/SIP Forum NNI Task Group, "Signature-based Handling >>>> of Asserted information using toKENs (SHAKEN) >>>> <https://access.atis.org/apps/group_public/ >>>> download.php/62391/ATIS-1000074.v002.pdf>", November >>>> 2021. >>>> >>>> Perhaps: >>>> [ATIS-1000074.v003] >>>> Alliance for Telecommunications Industry Solutions, >>>> "Signature-based Handling of Asserted information using >>>> toKENs (SHAKEN)", August 2022, >>>> <https://access.atis.org/higherlogic/ws/public/ >>>> download/67436>. >>>> --> >>> >>> Yes >>> >>>> >>>> >>>> 23) <!-- [rfced] Regarding [W3C-SubresourceIntegrity], 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-SubresourceIntegrity] >>>> W3C, "Subresource Integrity <https://www.w3.org/TR/SRI/>", >>>> 23 June 2016. >>>> >>>> Current: >>>> [W3C-SubresourceIntegrity] >>>> 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/>. >>>> --> >>> >>> Yes >>> >>>> >>>> >>>> 24) <!--[rfced] Terminology >>>> >>>> a) We updated the following terms to the form on the right >>>> based on common usage. Please let us know if you prefer otherwise. >>>> >>>> Verification Service -> verification service >>>> >>>> JSON Pointer -> JSON pointer >>>> >>>> 'display-name', "display-name" -> display-name >>>> (because it most often appeared without quotes) >>>> >>>> >>>> b) JWTClaimConstraints (4 instances) vs. >>>> JWT Claim Constraints (15 instances) >>>> Do these have the same meaning? If so, should one be used >>>> consistently? >>>> >>>> c) Note that we added hyphens as shown on the right below. Please let us >>>> know if you have any concerns. >>>> >>>> URI referenced content -> URI-referenced content >>>> URI linked content -> URI-linked content >>>> --> >>> >>> For a) Yes. >>> For b), interesting question, looking at RFC8226 and RFC9118 I believe the >>> way this document uses the term it should be made consistent using spaces >>> “JWT Claim Constraints” >>> For c) No concerns, that works. >>> >>>> >>>> >>>> 25) <!-- [rfced] Please review the "type" attribute of each sourcecode >>>> element in the XML file to ensure correctness. If the current list of >>>> preferred values for "type" >>>> (https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types) >>>> does not contain an applicable type, then feel free to let us know. >>>> Also, it is acceptable to leave the "type" attribute not set. >>>> >>>> In addition, review each artwork element. Specifically, >>>> should any artwork element be tagged as sourcecode or another >>>> element? >>>> --> >>> >>> I don’t believe we have the need for any sourcecode elements/types in the >>> document, but this is a bit new to me, so i can defer that to the editor to >>> what looks like convention for JSON examples perhaps. >>> >>>> >>>> >>>> 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). >>>> --> >>> >>> I am ok to make notes aside elements if that is typical. >>> >>>> >>>> >>>> 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. >>>> >>>> In addition, please consider whether "traditional" should be updated for >>>> clarity in the instances listed below. While the NIST website >>>> <https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1> >>>> indicates that this term is potentially biased, it is also ambiguous. >>>> "Tradition" is a subjective term, as it is not the same for everyone. >>>> >>>> >>>> ... the traditional "Caller ID" of the telephone network >>>> >>>> Traditional telephone network signaling protocols ... >>>> >>>> The first data is a more >>>> traditional set of info about a caller associated with "display-name" >>>> in SIP ... >>>> >>>> ... even in traditional calling name services today ... >>>> >>>> While in the traditional telephone network, ... >>>> --> >>> >>> I reviewed for inclusive language and did not find any. >>> >>> For the use of “traditional”, i believe this is a common way to refer to >>> the “legacy” telephone network which is sometimes considered a bit >>> derogatory, so I think keeping “traditional” is a good way to >>> conventionally refer to older types of telephony networks and usage and not >>> changed. >>> >>>> >>>> >>>> Thank you. >>>> >>>> RFC Editor >>>> >>>> >>>> >>>> On May 23, 2025, at 1:48 PM, 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/rfc9795.xml >>>> https://www.rfc-editor.org/authors/rfc9795.html >>>> https://www.rfc-editor.org/authors/rfc9795.pdf >>>> https://www.rfc-editor.org/authors/rfc9795.txt >>>> >>>> Diff file of the text: >>>> https://www.rfc-editor.org/authors/rfc9795-diff.html >>>> https://www.rfc-editor.org/authors/rfc9795-rfcdiff.html (side by side) >>>> >>>> Diff of the XML: >>>> https://www.rfc-editor.org/authors/rfc9795-xmldiff1.html >>>> >>>> >>>> Tracking progress >>>> ----------------- >>>> >>>> The details of the AUTH48 status of your document are here: >>>> https://www.rfc-editor.org/auth48/rfc9795 >>>> >>>> Please let us know if you have any questions. >>>> >>>> Thank you for your cooperation, >>>> >>>> RFC Editor >>>> >>>> -------------------------------------- >>>> RFC 9795 (draft-ietf-stir-passport-rcd-26) >>>> >>>> Title : PASSporT Extension for Rich Call Data >>>> Author(s) : C. Wendt, J. Peterson >>>> WG Chair(s) : Ben Campbell, Robert Sparks, Russ Housley >>>> 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
