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
