Jon, Thank you for your reply. Your information has been updated accordingly (please refresh): https://www.rfc-editor.org/authors/rfc9795.txt https://www.rfc-editor.org/authors/rfc9795.html https://www.rfc-editor.org/authors/rfc9795.pdf
This diff files shows only the most recent changes: https://www.rfc-editor.org/authors/rfc9795-lastrfcdiff.html Re: > Once that’s been fixed it has my approval to ship, thanks! We have noted your approval on the AUTH48 page for this document (https://www.rfc-editor.org/auth48/rfc9795). We will move this document forward in the publication process. Thank you. RFC Editor/ar > On Jul 7, 2025, at 10:29 AM, Peterson, Jon <jon.peter...@transunion.com> > wrote: > > > Could you please update my affiliation to TransUnion, instead of Neustar? > Similarly my author email at the end should bejon.peter...@transunion.com. > > Once that’s been fixed it has my approval to ship, thanks! > > - J > > From: Alice Russo <aru...@staff.rfc-editor.org> > Date: Thursday, July 3, 2025 at 2:36 PM > To: Peterson, Jon <jon.peter...@transunion.com> > Cc: Chris Wendt <chris-i...@chriswendt.net>, stir-...@ietf.org > <stir-...@ietf.org>, stir-cha...@ietf.org<stir-cha...@ietf.org>, Russ Housley > <hous...@vigilsec.com>, Murray S. Kucherawy <superu...@gmail.com>, > auth48archive <auth48archive@rfc-editor.org>, RFC Editor > <rfc-edi...@rfc-editor.org> > Subject: Re: AUTH48: RFC-to-be 9795 <draft-ietf-stir-passport-rcd-26> for > your review > > Jon, This is a reminder that we await word from you regarding this document's > readiness for publication as an RFC. The files are available from the URLs > below. Thank you. RFC Editor/ar > On Jun 9, 2025, at 3: 16 PM, Alice Russo > <arusso@ staff. rfc-editor. org> > Jon, > > This is a reminder that we await word from you regarding this document's > readiness for publication as an RFC. The files are available from the URLs > below. > > Thank you. > RFC Editor/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://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9795.html__;!!GX53klZ1TQ0!1x0PbH5wMAZVtY_PxrACEzYjkd01rqbemMl-Y9LNs6WeomVxCG_x1VRDar7_z_JP6lo1J-O3I8TJZcrE474XmKZSzgNI$ > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9795.txt__;!!GX53klZ1TQ0!1x0PbH5wMAZVtY_PxrACEzYjkd01rqbemMl-Y9LNs6WeomVxCG_x1VRDar7_z_JP6lo1J-O3I8TJZcrE474XmDZn4IPm$ > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9795.pdf__;!!GX53klZ1TQ0!1x0PbH5wMAZVtY_PxrACEzYjkd01rqbemMl-Y9LNs6WeomVxCG_x1VRDar7_z_JP6lo1J-O3I8TJZcrE474XmHdrtbSy$ > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9795.xml__;!!GX53klZ1TQ0!1x0PbH5wMAZVtY_PxrACEzYjkd01rqbemMl-Y9LNs6WeomVxCG_x1VRDar7_z_JP6lo1J-O3I8TJZcrE474XmPihcVD1$ > > > > This diff file shows all changes from the approved I-D: > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9795-diff.html__;!!GX53klZ1TQ0!1x0PbH5wMAZVtY_PxrACEzYjkd01rqbemMl-Y9LNs6WeomVxCG_x1VRDar7_z_JP6lo1J-O3I8TJZcrE474XmCSESgR6$ > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9795-rfcdiff.html__;!!GX53klZ1TQ0!1x0PbH5wMAZVtY_PxrACEzYjkd01rqbemMl-Y9LNs6WeomVxCG_x1VRDar7_z_JP6lo1J-O3I8TJZcrE474XmJbfQs7V$ > > (side by side) > > > > This diff file shows the changes made during AUTH48 thus far: > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9795-auth48diff.html__;!!GX53klZ1TQ0!1x0PbH5wMAZVtY_PxrACEzYjkd01rqbemMl-Y9LNs6WeomVxCG_x1VRDar7_z_JP6lo1J-O3I8TJZcrE474XmHX19PZz$ > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9795-auth48rfcdiff.html__;!!GX53klZ1TQ0!1x0PbH5wMAZVtY_PxrACEzYjkd01rqbemMl-Y9LNs6WeomVxCG_x1VRDar7_z_JP6lo1J-O3I8TJZcrE474XmPchfldL$ > > (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://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9795__;!!GX53klZ1TQ0!1x0PbH5wMAZVtY_PxrACEzYjkd01rqbemMl-Y9LNs6WeomVxCG_x1VRDar7_z_JP6lo1J-O3I8TJZcrE474XmCKCGXUm$ > > > > 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://urldefense.com/v3/__https://www.3gpp.org/ftp/Specs/html-info/24229.htm__;!!GX53klZ1TQ0!1x0PbH5wMAZVtY_PxrACEzYjkd01rqbemMl-Y9LNs6WeomVxCG_x1VRDar7_z_JP6lo1J-O3I8TJZcrE474XmGk--SaP$>. > >>> --> > >> > >> 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://urldefense.com/v3/__https://example.com/qbranch.json__;!!GX53klZ1TQ0!1x0PbH5wMAZVtY_PxrACEzYjkd01rqbemMl-Y9LNs6WeomVxCG_x1VRDar7_z_JP6lo1J-O3I8TJZcrE474XmDlXm79D$ > >>> 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://urldefense.com/v3/__https://example.com/qbranch.json__;!!GX53klZ1TQ0!1x0PbH5wMAZVtY_PxrACEzYjkd01rqbemMl-Y9LNs6WeomVxCG_x1VRDar7_z_JP6lo1J-O3I8TJZcrE474XmDlXm79D$: > >>> > >>> --> > >> > >> 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://urldefense.com/v3/__https://access.atis.org/higherlogic/ws/public/download/67436__;!!GX53klZ1TQ0!1x0PbH5wMAZVtY_PxrACEzYjkd01rqbemMl-Y9LNs6WeomVxCG_x1VRDar7_z_JP6lo1J-O3I8TJZcrE474XmOHzE4OW$ > >>> (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://urldefense.com/v3/__https://access.atis.org/apps/group_public/__;!!GX53klZ1TQ0!1x0PbH5wMAZVtY_PxrACEzYjkd01rqbemMl-Y9LNs6WeomVxCG_x1VRDar7_z_JP6lo1J-O3I8TJZcrE474XmAgFWU5u$ > >>> 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://urldefense.com/v3/__https://access.atis.org/higherlogic/ws/public/__;!!GX53klZ1TQ0!1x0PbH5wMAZVtY_PxrACEzYjkd01rqbemMl-Y9LNs6WeomVxCG_x1VRDar7_z_JP6lo1J-O3I8TJZcrE474XmFKsg7Q7$ > >>> 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://urldefense.com/v3/__https://www.w3.org/TR/2016/REC-SRI-20160623/__;!!GX53klZ1TQ0!1x0PbH5wMAZVtY_PxrACEzYjkd01rqbemMl-Y9LNs6WeomVxCG_x1VRDar7_z_JP6lo1J-O3I8TJZcrE474XmAsdxh91$). > >>> We have updated this > >>> reference to that. > >>> > >>> However, please let us know if you intended to point to > >>> the First Public Working Draft > >>> (https://urldefense.com/v3/__https://www.w3.org/TR/2025/WD-sri-2-20250422/__;!!GX53klZ1TQ0!1x0PbH5wMAZVtY_PxrACEzYjkd01rqbemMl-Y9LNs6WeomVxCG_x1VRDar7_z_JP6lo1J-O3I8TJZcrE474XmIfA-6X_$) > >>> or otherwise. > >>> > >>> Original: > >>> [W3C-SubresourceIntegrity] > >>> W3C, "Subresource Integrity > >>> <https://urldefense.com/v3/__https://www.w3.org/TR/SRI/__;!!GX53klZ1TQ0!1x0PbH5wMAZVtY_PxrACEzYjkd01rqbemMl-Y9LNs6WeomVxCG_x1VRDar7_z_JP6lo1J-O3I8TJZcrE474XmGEdNHie$>", > >>> 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://urldefense.com/v3/__https://www.w3.org/TR/2016/REC-SRI-20160623/__;!!GX53klZ1TQ0!1x0PbH5wMAZVtY_PxrACEzYjkd01rqbemMl-Y9LNs6WeomVxCG_x1VRDar7_z_JP6lo1J-O3I8TJZcrE474XmAsdxh91$>. > >>> --> > >> > >> 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://urldefense.com/v3/__https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types__;!!GX53klZ1TQ0!1x0PbH5wMAZVtY_PxrACEzYjkd01rqbemMl-Y9LNs6WeomVxCG_x1VRDar7_z_JP6lo1J-O3I8TJZcrE474XmBSlmMsS$) > >>> 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://urldefense.com/v3/__https://authors.ietf.org/en/rfcxml-vocabulary*aside__;Iw!!GX53klZ1TQ0!1x0PbH5wMAZVtY_PxrACEzYjkd01rqbemMl-Y9LNs6WeomVxCG_x1VRDar7_z_JP6lo1J-O3I8TJZcrE474XmFvB0Tp4$). > >>> --> > >> > >> 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://urldefense.com/v3/__https://www.rfc-editor.org/styleguide/part2/*inclusive_language__;Iw!!GX53klZ1TQ0!1x0PbH5wMAZVtY_PxrACEzYjkd01rqbemMl-Y9LNs6WeomVxCG_x1VRDar7_z_JP6lo1J-O3I8TJZcrE474XmBXEweCR$> > >>> 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://urldefense.com/v3/__https://web.archive.org/web/20250214092458/https:/*www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions*table1__;LyM!!GX53klZ1TQ0!1x0PbH5wMAZVtY_PxrACEzYjkd01rqbemMl-Y9LNs6WeomVxCG_x1VRDar7_z_JP6lo1J-O3I8TJZcrE474XmHA5azg1$> > >>> 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://urldefense.com/v3/__https://www.rfc-editor.org/faq/__;!!GX53klZ1TQ0!1x0PbH5wMAZVtY_PxrACEzYjkd01rqbemMl-Y9LNs6WeomVxCG_x1VRDar7_z_JP6lo1J-O3I8TJZcrE474XmKcuMf9k$). > >>> > >>> 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://urldefense.com/v3/__https://trustee.ietf.org/license-info__;!!GX53klZ1TQ0!1x0PbH5wMAZVtY_PxrACEzYjkd01rqbemMl-Y9LNs6WeomVxCG_x1VRDar7_z_JP6lo1J-O3I8TJZcrE474XmLCrfyIe$). > >>> > >>> * 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://urldefense.com/v3/__https://authors.ietf.org/rfcxml-vocabulary__;!!GX53klZ1TQ0!1x0PbH5wMAZVtY_PxrACEzYjkd01rqbemMl-Y9LNs6WeomVxCG_x1VRDar7_z_JP6lo1J-O3I8TJZcrE474XmLOpA4vq$>. > >>> > >>> * 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://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc__;!!GX53klZ1TQ0!1x0PbH5wMAZVtY_PxrACEzYjkd01rqbemMl-Y9LNs6WeomVxCG_x1VRDar7_z_JP6lo1J-O3I8TJZcrE474XmBIOWUuo$ > >>> > >>> * The archive itself: > >>> > >>> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/auth48archive/__;!!GX53klZ1TQ0!1x0PbH5wMAZVtY_PxrACEzYjkd01rqbemMl-Y9LNs6WeomVxCG_x1VRDar7_z_JP6lo1J-O3I8TJZcrE474XmH7bToo8$ > >>> > >>> * 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://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9795.xml__;!!GX53klZ1TQ0!1x0PbH5wMAZVtY_PxrACEzYjkd01rqbemMl-Y9LNs6WeomVxCG_x1VRDar7_z_JP6lo1J-O3I8TJZcrE474XmPihcVD1$ > >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9795.html__;!!GX53klZ1TQ0!1x0PbH5wMAZVtY_PxrACEzYjkd01rqbemMl-Y9LNs6WeomVxCG_x1VRDar7_z_JP6lo1J-O3I8TJZcrE474XmKZSzgNI$ > >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9795.pdf__;!!GX53klZ1TQ0!1x0PbH5wMAZVtY_PxrACEzYjkd01rqbemMl-Y9LNs6WeomVxCG_x1VRDar7_z_JP6lo1J-O3I8TJZcrE474XmHdrtbSy$ > >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9795.txt__;!!GX53klZ1TQ0!1x0PbH5wMAZVtY_PxrACEzYjkd01rqbemMl-Y9LNs6WeomVxCG_x1VRDar7_z_JP6lo1J-O3I8TJZcrE474XmDZn4IPm$ > >>> > >>> Diff file of the text: > >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9795-diff.html__;!!GX53klZ1TQ0!1x0PbH5wMAZVtY_PxrACEzYjkd01rqbemMl-Y9LNs6WeomVxCG_x1VRDar7_z_JP6lo1J-O3I8TJZcrE474XmCSESgR6$ > >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9795-rfcdiff.html__;!!GX53klZ1TQ0!1x0PbH5wMAZVtY_PxrACEzYjkd01rqbemMl-Y9LNs6WeomVxCG_x1VRDar7_z_JP6lo1J-O3I8TJZcrE474XmJbfQs7V$ > >>> (side by side) > >>> > >>> Diff of the XML: > >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9795-xmldiff1.html__;!!GX53klZ1TQ0!1x0PbH5wMAZVtY_PxrACEzYjkd01rqbemMl-Y9LNs6WeomVxCG_x1VRDar7_z_JP6lo1J-O3I8TJZcrE474XmE9bJOty$ > >>> > >>> > >>> Tracking progress > >>> ----------------- > >>> > >>> The details of the AUTH48 status of your document are here: > >>> https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9795__;!!GX53klZ1TQ0!1x0PbH5wMAZVtY_PxrACEzYjkd01rqbemMl-Y9LNs6WeomVxCG_x1VRDar7_z_JP6lo1J-O3I8TJZcrE474XmCKCGXUm$ > >>> > >>> 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
