Hi, It looks like you are replacing the contacts with proxy data. Are you completely replacing the contact data and not attempting to signal what contact data exists but redacted? This was not exactly the purpose of the replacement value method since it’s meant to be used on a per member basis. If you’re replacing the entire contact due to redaction with a privacy contact, then the replacement value method could be used at the level of the contact to provide that signal. If you are physically removing the contact due to redaction, then you could use the removal method. I recommend registering the contact-level “redacted name” values in the RDAP JSON Values registry to support this for each of your contacts, such as below where I don't include the use of two double quotes in the CSV values of Description:
Value, Type, Description, Registrant, Reference,Registant Name,Registrant Contact Information Registrant Contact,redacted name,“Redacted entity object class, with “registrant” role. The “removal” or “replacementValue” redacted “path” member JSONPath for Figure “Unredacted RDAP Lookup Response” of RFC 9537 is “$.entities[?(@.roles[0]=='registrant')]”,Namecheap,<Namecheap contact information> Tech Contact,redacted name,“Redacted entity object class, with “technical” role. The “removal” or “replacementValue” redacted “path” member JSONPath for Figure “Unredacted RDAP Lookup Response” of RFC 9537 is “$.entities[?(@.roles[0]=='technical')]”,Namecheap,<Namecheap contact information> Admin Contact,redacted name,“Redacted entity object class, with “administrative” role. The “removal” or “replacementValue” redacted “path” member JSONPath for Figure “Unredacted RDAP Lookup Response” of RFC 9537 is “$.entities[?(@.roles[0]=='administrative')]”,Namecheap,<Namecheap contact information> Billing Contact,redacted name,“Redacted entity object class, with “billing” role. The “removal” or “replacementValue” redacted “path” member JSONPath for Figure “Unredacted RDAP Lookup Response” of RFC 9537 is “$.entities[?(@.roles[0]=='billing')],Namecheap,<Namecheap contact information> Thanks, -- JG James Gould Fellow Engineer applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected] 703-948-3271 12061 Bluemont Way Reston, VA 20190 http://verisigninc.com/ From: Ksenia Chuprina <[email protected]> Date: Friday, July 25, 2025 at 11:50 AM To: James Gould <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Cc: "[email protected]" <[email protected]> Subject: [EXTERNAL] Re: [regext] Re: Namecheap Inc. inquiry: RFC9537 implementation peculiarities Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi James, Thank you for the prompt reply! We will then be waiting for your opinion regarding usage our privacy contact for 'Replacement' (questions 1,2). I've checked that the RFC doesn't specify what value we must use for replacement, it just tells 'The Redaction by Replacement Value Method is when a redacted field is not removed but its value is replaced with a different value', so hope our method works. Looking forward to hearing from you. On 07/25/2025 6:21 PM EEST Gould, James <[email protected]> wrote: CAUTION: This email originated from outside the organization. Do not click links unless you can confirm the sender and know the content is safe. Hi, The Replacement Value Method is not meant to replace the value with placeholder text. You can use the Removal Method as the signal for redaction. -- JG James Gould Fellow Engineer [email protected] 703-948-3271 12061 Bluemont Way Reston, VA 20190 http://secure-web.cisco.com/1B5dPbXH836nxJ1LZLoYBY0CqMuQCbGkHsoX-tthVcpec-ZEBBy5hvIhsu9DvlZ-I8gVbDA0iIEyKrZmUULXoDh_gG_v7x7csHzLwCghuK2dObVyJgGWP9qPtWMurF2hYRriPi88rNk7aB0LGlI0pnjGrwhEXp-w9pI6BV9HQW1VKq4hWz6bfOIESyakmamOPdF5Zu5BwMjHNolT2oHRr9iK8kz395wRsOGXUmY_bQM9fA8xDzN-uP7MGYvpQUM1xKtDZW935z70Q65YvBQ451wyhFVmnHDqoy9KpgiybPEw/http://verisigninc.com/ From: Ksenia Chuprina <[email protected]> Date: Friday, July 25, 2025 at 11:08 AM To: James Gould <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Cc: Daria Sydorenko <[email protected]> Subject: [EXTERNAL] Re: [regext] Re: Namecheap Inc. inquiry: RFC9537 implementation peculiarities Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi James, Apologies for following up again so soon. I just wanted to kindly ask if you could prioritize reviewing the third question regarding domain handle redaction, the others can wait a bit longer on our side. Let me repeat it here: 3) for domain handle, can we also use ‘Replacement’ method, by which we mean replacing the handle value with a text ‘redacted for privacy’? 3.1) in general, what methods can be used for redaction of this element? We’d really appreciate your reply on that specific point as soon as possible, as we’re aiming to get the team started right away. With the deadline a month away, we want to make sure we stay on track and don’t lose any time. Looking forward to your reply. On 07/24/2025 1:38 PM EEST Ksenia Chuprina <[email protected]> wrote: Hi James, Just following up on my previous message, have you had a chance to review my questions about contacts redaction? We want to clarify all uncertainties so that we have enough time for implementation till the August deadline. Looking forward to your reply. On 07/10/2025 6:12 PM EEST Ksenia Chuprina <[email protected]> wrote: Hello James, Thank you very much for the detailed explanations. We deeply appreciate your help. Let me clarify once more how we want to implement redaction of contact entities. We provide our customers with an option to turn on/off a Privacy tool for domains, which helps them to open/hide their contact information in RDAP. If a customer decides to enable the tool, we hide their contacts in RDAP, i.e. replace all customer’s data with the following values of the Privacy service contact, including also contact handle: ___________________________ handle: ID of Privacy service contact set associated with domain (not real ID of the client’s contact entity); unique for each contact entity and each domain. fn: Redacted for Privacy org: Privacy service provided by Withheld for Privacy ehf address: IS Kalkofnsvegur 2 Reykjavik Capital Region 101 tel: +354.4212434 fax: don’t pay attention to it being empty; the output is being worked on; we preliminary plan to come up with the value to hide client’s real fax email: anonymous email, which redirects correspondence to the customer’s real email address (This is the case that we want to address now. We have one more case with contact form, but we think we got how to deal with it from your explanations, thanks!) ___________________________ So these are not redaction signals, this is the contact info which belongs to our https://secure-web.cisco.com/1tz9G45aBiPmibL0IE-Ie8sYIibUvLDRkxbXRofQj35bHvZ1aU1WfPbnMZKxZRPNC8NCH5bTPEZFNPu66TkYImtuSXdD-0IemhKmUo3DJ5Zj6wbzjDSMkF34_oxyJK37WumeJ9SXRp3tjbtQLAjs3vnbgqc2aCLWFsEAzxWogm6BpwZBGFQr-Tr1CmCWQc58aVQ0LhqaKOJlDjjt15V1lnU0x4zgDGWluL4ie3OWHtQXrsw45_M3qkd4xqEvuLkbGqJa0cBikEgnhgW1JLshKQ9epKuzyocQkC-KypzKzus4/https://www.spaceship.com/domains/domain-name-privacy/. We are obliged to show it according to point https://secure-web.cisco.com/1GmOQhMPO_kzG-Ud0000ajkc98SwiU3K-N2PiCFEiUf2989tE1BKNl2qSC5lScLLeKazP9ydKSXP_WNT2vBsGYC1573aCDsPdbv4hMJOwH3KhUinoGKoaWI_dHKVbtmkGM3swWnzEqaeiuKBjTZRnMzNaXSrKN172uZIZsP3u8cKW4kWa4rRM1ZpEdcpqfni0OZxjK-1BW47ifXDMZe08vWKRfRnnASgZHXdTynSylm9WEQrIA47XlRRsb23LbC8nw_IB1ZtA2ml1z_05ROL5TctLpxwDX2-gBeqvrpSlK-0/https://www.icann.org/en/contracted-parties/consensus-policies/registration-data-policy#domain-name-registration-data, and we promise to show the data exactly this way to our customers. We want to avoid removing that info from RDAP output due to the reasons above. We intend to leave it as it is, and we’d like to specify the following with you to adjust our current approach so that it conforms with RFC9537: 1) could you confirm that what we are doing (replacing customer’s data with Privacy tool contacts) is Redaction by Replacement method (https://secure-web.cisco.com/12em8HkrBbLEegt_QRn7uLeKiNU-r0kZFGcmK169ZtqwF_hNv3j5HwaBxd_hKywacNyQ-tZDu9pAlldI7t8fJYmonpLUqXR4hl-4UXd68Ac04xbDmUgK9krzSPIfnPHKXH45C9xNGOEDXp050QbSE2BEkybxP1anQZHA98tNY9dLSVAEYQx9zujleiOJA_PAVCWPi6-uTzRNBQOD-rXIQHhKoQH93x7zQeJ9fsJYaScSATBFl47Hz4XvoDFAkTIPKLMChQdamvxBAe_l7JE2FyNQS2CrsVHbdXvNkg-jAxco/https://www.rfc-editor.org/rfc/rfc9537.html#name-redaction-by-replacement-va), and if it is not, could you explain why and what method it actually is? RDAP output example: https://secure-web.cisco.com/1ysa42S4lPal8eDdgDPQq_fAG7JqF_-wxkdtbyjNzy10HNLiM-IpDuj5hGx109LC3osHUeLZ60lx-pEjfB0JE66dFPfny2-yRoq0RbExgJZWOoDbobFMFSg0HLrcA3-xRKe8E0NVgqIOuIVc_0m_6LZ0uQ-x65zCl4m-XlmqaxziTmj8IFod2VSN3XrWGRT-tDo8qLls-1RVQ6zXCJjSzlsHCiwkgz2Bzy6RBD0gu20_vgQ4XzoqhVCFWX7idSmotR-nAg3g8fhxsUc7oo4pvqILhrqQJCoxNkagTBaUvUY0/https://rdap.spaceship.com/domain/1finechecks.com 2) since we are replacing value of every field in a contact object with Privacy tool data, can we reference the whole object (e.g. Registrant contact or Tech contact etc) in the 'redacted' member instead of referencing each separate field or we cannot? For example, like this: "redacted": [ { "name": { “description": "registrant entity” }, "method": "replacementValue", } ] And I also have an additional question to you: 3) for domain handle, can we also use ‘Replacement’ method, by which we mean replacing the handle value with a text ‘redacted for privacy’? 3.1) in general, what methods can be used for redaction of this element? Looking forward to hearing from you. On 07/08/2025 7:42 PM EEST Gould, James <[email protected]> wrote: CAUTION: This email originated from outside the organization. Do not click links unless you can confirm the sender and know the content is safe. Daria, Sorry for the delayed response. My responses are embedded below prefixed with “JG-“. -- JG James Gould Fellow Engineer [email protected] 703-948-3271 12061 Bluemont Way Reston, VA 20190 http://secure-web.cisco.com/1uoQk3dQRjpdRRB6izGP9m2sgqQraZTQiabbVtRvUpi7W0i_Il2MO7H5Bj2EzswJWbiSas5f4Moa0fAkAOrlK-SHa8-XYZ0gXxdwTCYcyOLXKhD0yVVcUWD5QfSrkFqkg_Js5_jmQEy1f8ueTy_A_pLsGRBe5z1ZLIdQctUMHm2d7WuwP7cSfvsRugUfq0WAJTXvTQ1B6pvga_pFz06Pml8gTzX5-TNyx6o1ziKCeUIcEfAaISIcmNfc_ldboyeci8QwRLrj8mU1SlCPMmzzud5H8CNxjo1tCOcViggStEyc/http://verisigninc.com/ From: Daria Sydorenko <[email protected]> Date: Friday, June 27, 2025 at 4:50 AM To: James Gould <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Cc: "[email protected]" <[email protected]> Subject: [EXTERNAL] Re: [regext] Re: Namecheap Inc. inquiry: RFC9537 implementation peculiarities Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Got it, thank you so much. For clarity, are you redacting all properties of the contacts, but including a proxy replacement for the e-mail property? Yes. You can check the following output as an example: https://secure-web.cisco.com/184Z5-cGSc1VoBYbz8zwT31osTi3emrFfajBZPCraTbUeIWIJSWqIuvDQQecTaQRyKWIh357_YKtlhAVHrIA5sSpGIwUnSU1WsYmCjARtVOrlc-1nXl-HT1bMu89Ocsk17avqA8TJdjuzAUxHxSGdN6z6pJUroo4iPf932vVjVapAUwQmhL4Fl6BYw62vnUt1jvfGFOp652Qkz5Ic7yV-WMurhXFOo3Cejk1wNHBeokMioDRkRXFO89RATC9mqzPcFDUNtbsNxem7VI9Jg84IniYymMz33T9BPG2IkcpwwUA/https://rdap.spaceship.com/domain/srgrthrsthsrh.sbs JG-I see that with the RDAP response that you’re currently using placeholder text to provide a redaction signal for the “fn” and “org” members and using replacement for the “email” member with the “contact-uri” member. The “adr” and the “tel” “voice” member is provided. I’m unclear why the “tel” “fax” member is being returned since it provides no value. This applies to all roles (“registrant”, “administrative”, “technical”, and “billing”). Based on this, the redaction would include the entries at a minimum: "redacted": [ { "name" : { "type": "Registrant Name" }, "method": "removal" }, { "name" : { "type": "Registrant Organization" }, "method": "removal" }, { "name" : { "type": "Registrant Email" }, "replacementPath": "$.entities[?(@.roles[0]=='registrant')].vcardArray[1][?(@[0]=='contact-uri')]", "method": "replacementValue" }, { "name" : { "description": "Administrative Name" }, "method": "removal" }, { "name" : { "description": "Administrative Organization" }, "method": "removal" }, { "name" : { "description": "Administrative Email" }, "replacementPath": "$.entities[?(@.roles[1]=='administrative')].vcardArray[1][?(@[0]=='contact-uri')]", "method": "replacementValue" }, { "name" : { "description": "Tech Name" }, "method": "removal" }, { "name" : { "description": "Tech Organization" }, "method": "removal" }, { "name" : { "description": "Tech Email" }, "replacementPath": "$.entities[?(@.roles[2]=='technical')].vcardArray[1][?(@[0]=='contact-uri')]", "method": "replacementValue" }, { "name" : { "description": "Billing Name" }, "method": "removal" }, { "name" : { "description": "Billing Organization" }, "method": "removal" }, { "name" : { "description": "Billing Email" }, "replacementPath": "$.entities[?(@.roles[3]=='billing')].vcardArray[1][?(@[0]=='contact-uri')]", "method": "replacementValue" } ] JG-The redaction name values of “Administrative Name”, “Administrative Organization”, “Administrative Email”, “Tech Name”, “Tech Organization”, “Tech Email”, “Billing Name”, “Billing Organization”, and “Billing Email” could be changed to use the “type” instead of the “description” once they’re registered in the RDAP JSON Values Registry. So, did I understand correctly that we should treat our redaction method (placing privacy service registration data instead of user PI) as a Removal Method since it doesn't provide any useful information but acts as a placeholder, yes? JG-If you were only returning the “email” member via replacement with the “contact-uri” member for all contact roles, then you would do something like the following: "redacted":[ { "name":{ "description":"Registrant Contact" }, "method":"removal" }, { "name":{ "type":"Registrant Email" }, "replacementPath":"$.entities[?(@.roles[0]=='registrant')].vcardArray[1][?(@[0]=='contact-uri')]", "method":"replacementValue" }, { "name":{ "description":"Administrative Contact" }, "method":"removal" }, { "name":{ "description":"Administrative Email" }, "replacementPath":"$.entities[?(@.roles[1]=='administrative')].vcardArray[1][?(@[0]=='contact-uri')]", "method":"replacementValue" }, { "name":{ "description":"Tech Contact" }, "method":"removal" }, { "name":{ "description":"Tech Email" }, "replacementPath":"$.entities[?(@.roles[2]=='technical')].vcardArray[1][?(@[0]=='contact-uri')]", "method":"replacementValue" }, { "name":{ "description":"Billing Contact" }, "method":"removal" }, { "name":{ "description":"Billing Email" }, "replacementPath":"$.entities[?(@.roles[3]=='billing')].vcardArray[1][?(@[0]=='contact-uri')]", "method":"replacementValue" } ] JG-You would remove the use of placeholder text values outside of the “redacted” member, which is one of the goals of the redaction extension. And we can scale this logic to other cases. For example, for GDPR, we can redact all properties of the contact so they have the value "REDACTED" except for the email address, which has contact-uri. In these cases, are we ok (in terms of RFCs) to call this redaction method Removal? Will it not be a mistake that the contact object is still present in the RDAP output? Do you think we should include any JSONPath (none of the "prePath", "postPath", or "replacementPath" looks fully relevant in this case for me)? JG-My recommendation is to include the use of the “replacementPath”, since it specifies what is replacing the “email” member due to redaction. _____________ Best regards, Daria Sydorenko Product Coordinator - Domains Compliance Namecheap/Spaceship On 06/26/2025 6:22 PM EEST Gould, James <[email protected]> wrote: CAUTION: This email originated from outside the organization. Do not click links unless you can confirm the sender and know the content is safe. Daria, For clarity, are you redacting all properties of the contacts, but including a proxy replacement for the e-mail property? In that case, it would be overkill to include all the contact properties individually that are using the Removal Method. What I’m thinking is that it would be best to signal the client that the contacts by type are being redacted via the Removal Method and include the redaction of the contact email individually via the Replacement Method in the redaction extension. So, for the 4 contacts roles, there would be four object-level removal redaction entries and four field-level replacement redaction entries. I don’t believe it will make a difference whether there is a single entity with four roles or multiple entities with a single role. The following redacted names could be registered to use the name “type” field instead of the name “description” field: • “Registrant Contact” • “Administrative Contact” • “Tech Contact” • “Billing Contact” • “Administrative Email” • “Billing Email” The “Registrant Email” and “Tech Email” redacted names are already registered. This is my initial thought, but there could be other approaches from the working group to cover this use case. Thanks, -- JG James Gould Fellow Engineer [email protected] 703-948-3271 12061 Bluemont Way Reston, VA 20190 http://secure-web.cisco.com/17zKPxSmnFoOpNLSiJklTuXrUQ2GOkdIvYkuYH_g-k2lIEBZUQ15Rzu5Nv9TIMMqLpwVrmA31oavl-9kwgDpL0G-hyhedjFNtmiBM7dvHdHuCbNaC43Sg9OxiQ938E33ueqlxH0Q9L4-J6gHBitUAFIQ6loTiNp3wQNZM9i_5ulxBFYmaCtQdzDzHBt4UfEVKXP8-zOabDey_hc3c4OPfCRNBPJikE7I0ELiJWXuYaZMVqgqZt4JnXb251pDk9QU64Ht9EfY0E-FLEQ4baFQni_VDObYgueov8YrDlnCJ4eE/http://verisigninc.com/ From: Daria Sydorenko <[email protected]> Date: Thursday, June 26, 2025 at 10:42 AM To: James Gould <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Cc: "[email protected]" <[email protected]> Subject: [EXTERNAL] Re: [regext] Re: Namecheap Inc. inquiry: RFC9537 implementation peculiarities Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. I would also like to add some context and clarify my questions We gather 4 contacts for all gTLDs: Registrant, Technical, Administrative, Billing, and show all four in our RDAP. When the user adds the Privacy service for their domain name, there can be 2 main cases: 1) RDAP output has one entity with four roles. 2) RDAP output has several entities with their own roles (but the redacted values are the same for each entity). My questions are: - FOR CASE 2: can we reference the whole object (e.g. Registrant contact, Administrative contact, etc.) in the redacted member? - FOR CASE 1: can we reference the whole object only once if it has more than 1 role? - If no, can we reference the same field only once if it has different roles when such a field is redacted for all roles (given that the reason is the same - privacy service)? For example, in both use cases, we can redact registrant, admin, billing, and technical email using the same contact-uri with the same link. Can we reference this in the "redacted" member only once, or do we need to add each redacted field separately? _____________ Best regards, Daria Sydorenko Product Coordinator - Domains Compliance Namecheap/Spaceship On 06/26/2025 4:09 PM EEST Daria Sydorenko <[email protected]> wrote: Hello James, I went through your answers. Thank you for the detailed responses. I have a comment about q. #1: 1. We mainly use the redaction by ‘Replacement Value' method. We checked that for the ‘Removal' method we can reference the whole object in the 'redacted' member if all fields of that object are removed (e.g. Tech contact). Can we do the same for the ‘Replacement Value’ method or do we need to reference each redacted field separately in the ‘redacted’ member? JG- The reason that the “Removal Method” can reference a single redaction element for a removed object is the redaction of the parent object applies to all children as well. I’m not exactly sure what the child members are being replaced with (e.g., proxy data, placeholder text). The “Replacement Value Method” is a more specific redaction feature that is meant to resolve to a useful value (e.g., anonymized email, web form). Can you describe what form of replacement that you’re planning on using? We have the following use case within our RDAP: we utilize the Privacy service. When a user enables our privacy service, we use redaction in the RDAP response as shown below: "vcardArray": [ "vcard", [ ["version", {}, "text", "4.0"], ["fn", {}, "text", "Redacted for Privacy Purposes"], ["org", {}, "text", "Privacy service provided by Withheld for Privacy ehf"], ["adr", { "cc": "IS" }, "text", ["", "", "Kalkofnsvegur 2", "Reykjavik", "Capital Region", "101", ""]], ["tel", { "type": ["voice"] }, "uri", "tel:+354.4212434"], ["tel", { "type": ["fax"] }, "uri", "fax:"], ["contact-uri", {}, "uri", "https://www.spaceship.com/domains/whois/contact/?d=domain.com";] ] ] *The user chooses if the email should be replaced with the contact form or an anonymized email. This approach complies with section 9.2.5 of ICANN's Registration Data Policy, which states: "For Registered Names using an Affiliated or Accredited Privacy or Proxy service, Registrar and Registry Operator MUST Publish the full Registration Data of the Privacy or Proxy Service, which MAY also include the existing privacy or proxy pseudonymized email." Following the policy, we don't remove the fields but replace them with the Registration Data of the Privacy Service that we use. Given this, we believe that our approach is the 'Replacement Value' Method for all fields. Do we need to list each replaced field individually in the redacted member, applying specific logic for each one? As I see, for fn, for example, we should use postPath child member, while for contact-uri, prePath and replacementPath will be more suitable. Is there any option to reference the whole object in the "redacted" member using the 'Replacement Value' method (for our use case) to simplify RDAP output? Will be looking forward to your reply. _____________ Best regards, Daria Sydorenko Product Coordinator - Domains Compliance Namecheap/Spaceship On 06/25/2025 9:28 PM EEST Gould, James <[email protected]> wrote: CAUTION: This email originated from outside the organization. Do not click links unless you can confirm the sender and know the content is safe. Hi, My feedback is embedded below, prefixed with “JG-“. Let me know if you have any additional questions. Thanks, -- JG James Gould Fellow Engineer [email protected] 703-948-3271 12061 Bluemont Way Reston, VA 20190 http://secure-web.cisco.com/1haCjyo7cl-91kyQ3VqfMki8w3kzHOAPlPtm9QAiIdvwjwA9FRm_pn0xE8O2nvC85ySBtrEY2TIFUivKRpmef_rDqItysXxAQe4kZ_whseY_AtF7Xc62MCHyuXitoYG8771RzjLXCOkNnLmyWtPT4AZ_OBV4wFX5BEn8i_gqWW2s4PHiJLHMQJisrZwm6yJpcdqZoUIU0Jv7Nt8G3qIn2bsnx7HUSGUzDDwhbTSu89QLuaLZjfPlxK13R6O31c23dsMG5b7mA1G5xPv7ApCfJkUdjlGFbzdCYaTTjcUKe2QM/http://verisigninc.com/ From: Daria Sydorenko <[email protected]> Date: Wednesday, June 25, 2025 at 11:59 AM To: Marc Blanchet <[email protected]>, "[email protected]" <[email protected]> Cc: Ksenia Chuprina <[email protected]> Subject: [EXTERNAL] [regext] Re: Namecheap Inc. inquiry: RFC9537 implementation peculiarities Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hello team, Could you please let us know if any information is already available to cover our question? We are looking forward to a response from you. _____________ Best regards, Daria Sydorenko Product Coordinator - Domains Compliance Namecheap/Spaceship On 05/27/2025 2:33 PM EEST Ksenia Chuprina <[email protected]> wrote: Hello Marc, Thank you for passing my query to the working group. We appreciate your efforts on RDAP, and if it helps you can use our Spaceship RDAP Production environment with .ote domain names for tests, e.g. https://secure-web.cisco.com/1wAdhc-t6b80KYiMW36BTSlLCmW---iTyvBcNggJl2mU2j1eZyC4utpleca_1foyJCebEy4vQhhn-8534cBwPXtnSvrp7Opop9WAd3ATJ68EwLroOjRREg6Nnttv1bDe7C8Uu9hYhEKYg5AlZ4nxcKGIALvZVY6nK6FsBu7UVun3wVmtaXwvWf4RN5ArDidUHwwrQ1cMTA6XpKreC7SDudNb__umuFSce8ZQmlRcBiFp7q4CTx3Gz8aN-TgRjk6XrwlSIBBwVdbmu2LuU5_BiqlElCSou0-46spDfYVAmeJ8/https://rdap.spaceship.com/domain/xn--20001013-01-75066601--1726844587268632-17da086aa.work.ote This is the only approach we can currently suggest. And just for you to know, we have not yet upgraded to the RDAP 2024 version. Should that suit you, let me know, and I will provide a few more .ote domain names. Have a wonderful one ahead! On 05/26/2025 3:45 PM EEST Marc Blanchet <[email protected]> wrote: CAUTION: This email originated from outside the organization. Do not click links unless you can confirm the sender and know the content is safe. Hello, I’ll let the wg respond to your query. I’m writing to you because I’m the author of the RDAP Browser mobile app (iOS and Android). I’m working on a major update of both versions which will include Redacted. (I was one pushing for a better solution than just random strings saying no data here). If you have any test server/infrastructure that would contain the real data but in a non-production mode, and interested in interop testing, let’s talk! Regards, Marc. Le 22 mai 2025 à 13:10, Ksenia Chuprina <[email protected]> a écrit : Greetings Team, I am a Business Analyst at Namecheap Inc, a Domain Registrar. We are currently working on the upgrade of our RDAP to the version 2024 and we have questions about entities redaction. We reached ICANN, but they have forwarded us to you. Hope you can help us with that: 1. We mainly use the redaction by ‘Replacement Value' method. We checked that for the ‘Removal' method we can reference the whole object in the 'redacted' member if all fields of that object are removed (e.g. Tech contact). Can we do the same for the ‘Replacement Value’ method or do we need to reference each redacted field separately in the ‘redacted’ member? JG- The reason that the “Removal Method” can reference a single redaction element for a removed object is the redaction of the parent object applies to all children as well. I’m not exactly sure what the child members are being replaced with (e.g., proxy data, placeholder text). The “Replacement Value Method” is a more specific redaction feature that is meant to resolve to a useful value (e.g., anonymized email, web form). Can you describe what form of replacement that you’re planning on using? 2. Many child members of the ‘redacted’ member are marked as ‘optional’ in the https://secure-web.cisco.com/1K-p06XuKlGkEPkvNLd0CFFLUUAXdJvZoYGuBloQH1ApcgRqEbkz8m8SpOaM6pGOYMixPweHL9Z57jsGmMpRUGGWCyxEfc2aQOh5NmeeCB_DG9ZdQmnbkBsqbJrt2IqCI5e8CSwdL3hglT8F-EVT1SUESR9il3jDd_IvAacOc9cPEfi9w9JNEHFK5KdrrH4_n4FQ07bBvuC6PDhT242rqiRiQ8R_n2fJu7sswGT-n1WRKMnCFNn6k-Ddwb-Jq9Q3Hih9judqi7GBZOX0HRJIIHkNZr26lnJbBk6Him5VKwYA/https://www.rfc-editor.org/rfc/rfc9537.html#name-redaction-by-removal-method. Is it totally up to us whether to include them or not, or do they become obligatory on a certain condition? In particular, we have doubts about ‘postPath’ and ‘method’ members when using the ‘Replacement Value’ redaction method, but it would be best to know the approach to all members. JG – The only required member is the “name” member and the “method” member, where the “method” member has an implied default value of “removal” when not provided. There are some normative MUST and MUST NOTs defined in the RFC that covers specific use cases, but in general it’s flexible to work for your redaction needs. 3. In the ‘name’ member of the ‘redacted’ member, can we always use the ‘description’ field or is it a must to use the ‘type’ field for the registered redacted names? JG – There is no normative requirement to use the “type” field when there is a registered redacted name, but I do recommend it. The client will get more meaning with the use of a pre-registered value as opposed to a custom value with the “description” field. If the latter is the case, where do we find the ‘registered redacted names’? Are those the Values in the Appendix E of the https://secure-web.cisco.com/1OIQ1ZznOOEGtb9TYBIlQtBSByoZ5yuTqoBGyrcwX5aUcLxkij4yFFgKevwKXbnXdNshnMAhX6VjrhSyLZidXV8R1TDjkUDFuax_2LVzwsw10fR3oTtKku871_UijCmMb8ESUs1gPIqR2dyDZah20jOPkaE5gLYnMxOJdosUnL_1zoXDcagAAU3ac9WdQTKPBzuq9JDmGM13RCSdSkV87_S48CV85ZnlI00XB4aQOtozWu9HJSFxifNa12mUUdua0HtfJLiDIglguaUCDNZlyMFNbl0TIrf4fU6EfXNSRK1g/https://validator.rdap.org/specs/gtld/2024-02/rdap-response-profile-21feb24-en.pdf#page=16? JG – You can find the registered redacted names in the RDAP JSON Values IANA Registry (https://secure-web.cisco.com/1eDh2kK7pjXMOckN5tTIz2nGSjxU6KAJCI77M-lvCXpNo5RfSbdCiYbhRxA29AkrF12wGL5bAFZ4DWsL8BDLIkUZhZJryz7lxNvfKva2q5kkBNf9Jjv0MozyYGlieSiwz9FGNmCeAtAzJ57BZuNz0zlepqVnbX4TaspWKzFH_WYMJysvB5MSvZgsxPKLB2_0mSkgAnc-LloP3tsZ8hLiyj_mqZV33GRUJvW1NLQ5RzQPf5MLqLOrIyo4ojbvlEmIcWycQjS9YWuiiZVrQiEsDtzqtjYDQ3kusPHFtcvFZoNw/https://www.iana.org/assignments/rdap-json-values) using the Type value of “redacted name”. These were registered when the RDAP Response Profile was completed. FYI We checked that we will have more contact sets/fields than covered in the Appendix, and also such values as ‘Registrant contact’ to reference the whole object are absent in it, that’s why we are wondering if we can always stick to the ‘description’ field. JG-As noted earlier, the use of the “type” field is better than using the “description” field, since the client will be able to better understand its meaning. If you see the need for more generic registered redacted name values, then you can go through the process defined in Section 10.2 of RFC 9083 to register them in the RDAP JSON Values registry (https://secure-web.cisco.com/1eDh2kK7pjXMOckN5tTIz2nGSjxU6KAJCI77M-lvCXpNo5RfSbdCiYbhRxA29AkrF12wGL5bAFZ4DWsL8BDLIkUZhZJryz7lxNvfKva2q5kkBNf9Jjv0MozyYGlieSiwz9FGNmCeAtAzJ57BZuNz0zlepqVnbX4TaspWKzFH_WYMJysvB5MSvZgsxPKLB2_0mSkgAnc-LloP3tsZ8hLiyj_mqZV33GRUJvW1NLQ5RzQPf5MLqLOrIyo4ojbvlEmIcWycQjS9YWuiiZVrQiEsDtzqtjYDQ3kusPHFtcvFZoNw/https://www.iana.org/assignments/rdap-json-values) referencing the Type “redacted name”. My recommendation is to leverage the “type” field for all registered redacted name values, register any new generic redacted name in the RDAP JSON Values registry (https://secure-web.cisco.com/1eDh2kK7pjXMOckN5tTIz2nGSjxU6KAJCI77M-lvCXpNo5RfSbdCiYbhRxA29AkrF12wGL5bAFZ4DWsL8BDLIkUZhZJryz7lxNvfKva2q5kkBNf9Jjv0MozyYGlieSiwz9FGNmCeAtAzJ57BZuNz0zlepqVnbX4TaspWKzFH_WYMJysvB5MSvZgsxPKLB2_0mSkgAnc-LloP3tsZ8hLiyj_mqZV33GRUJvW1NLQ5RzQPf5MLqLOrIyo4ojbvlEmIcWycQjS9YWuiiZVrQiEsDtzqtjYDQ3kusPHFtcvFZoNw/https://www.iana.org/assignments/rdap-json-values) and use the “type” field, and finally use the “description” field for custom redacted name values. 4. Do we get this right that we can choose either ‘type’ or ‘description’ field In the reason member of the ‘redacted’ member, or are they both required? Where can we find the list of ‘registered redacted reasons’? We saw Registries using ‘Server policy’ as a reason, is that okay to use that by default? JG – Yes, the same pattern is followed for the “reason” member as with the “name” member, where it’s better to use a “type” field if there is a registered redacted reason and use the “description” field otherwise. There are currently no registered redacted reason values in the RDAP JSON Values registry (https://secure-web.cisco.com/1eDh2kK7pjXMOckN5tTIz2nGSjxU6KAJCI77M-lvCXpNo5RfSbdCiYbhRxA29AkrF12wGL5bAFZ4DWsL8BDLIkUZhZJryz7lxNvfKva2q5kkBNf9Jjv0MozyYGlieSiwz9FGNmCeAtAzJ57BZuNz0zlepqVnbX4TaspWKzFH_WYMJysvB5MSvZgsxPKLB2_0mSkgAnc-LloP3tsZ8hLiyj_mqZV33GRUJvW1NLQ5RzQPf5MLqLOrIyo4ojbvlEmIcWycQjS9YWuiiZVrQiEsDtzqtjYDQ3kusPHFtcvFZoNw/https://www.iana.org/assignments/rdap-json-values), which can be addressed by going through the process defined in Section 10.2 of RFC 9083 to register them in the RDAP JSON Values registry referencing the Type “redacted reason”. The registration of the “Server policy” redacted reason makes logical sense. Looking forward to hearing from you. Best regards, Ksenia Chuprina Business Analyst BA&P Department Namecheap Inc. _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected] Best regards, Ksenia Chuprina Business Analyst BA&P Department Namecheap Inc. Best regards, Ksenia Chuprina Business Analyst BA&P Department Namecheap Inc. Best regards, Ksenia Chuprina Business Analyst BA&P Department Namecheap Inc. Best regards, Ksenia Chuprina Business Analyst BA&P Department Namecheap Inc. Best regards, Ksenia Chuprina Business Analyst BA&P Department Namecheap Inc.
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
