Andy, That language looks better. I believe it would be good for draft-ietf-regext-rdap-extensions to cover how new RDAP JSON Values types are defined. The RDAP JSON Values registry can be extended by Type and by Value. The definition of a new RDAP JSON Values type could include the expected format of the values. Should clients do an exact match of the values or a case insensitive match of the value? I believe there should be no conflicting values based on case in the registry and clients should implement a case insensitive match instead of an exact match. Some values may benefit from the use of case and some values may not. The values for the "notice and remark type" and the "redacted reason" could benefit from the use of mixed case since they're not identifiers but use sentence form.
Thanks, -- JG James Gould Fellow Engineer jgo...@verisign.com <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 9/4/24, 11:05 AM, "Andrew Newton (andy)" <a...@hxr.us <mailto:a...@hxr.us>> wrote: 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 and Scott, I posted a PR to address your discussion points. https://secure-web.cisco.com/1BL1W6xpoZ0nbLY0e-0m_89D7qPxPhLivfb51zodFBE1tL2byYCWbyfUPbZ7K9cgnE_N4T3ETzFh6xm1hJRPhXvpCZWXegUgRGzdv2Nno-CWeNVwEG9lqyOlFL77v_ajLE68K_Ud48AnPN5rKXRNm0n6gPyOyM32KYuxzt_5ecaBWzWTt0KPNoZMDYQ08IKnLWVo33jXsFAAk1lq3CHWH8NwOaQGNxgybXYB8JTWj-sgzZToMfTjghi17hUuuV1Ps2tkK2AHOLQdSc5DiHMq0aAlYzlnN1pxx53pQFlcxZeQ/https%3A%2F%2Fgithub.com%2Fanewton1998%2Fdraft-regext-rdap-extensions%2Fpull%2F30%2Ffiles <https://secure-web.cisco.com/1BL1W6xpoZ0nbLY0e-0m_89D7qPxPhLivfb51zodFBE1tL2byYCWbyfUPbZ7K9cgnE_N4T3ETzFh6xm1hJRPhXvpCZWXegUgRGzdv2Nno-CWeNVwEG9lqyOlFL77v_ajLE68K_Ud48AnPN5rKXRNm0n6gPyOyM32KYuxzt_5ecaBWzWTt0KPNoZMDYQ08IKnLWVo33jXsFAAk1lq3CHWH8NwOaQGNxgybXYB8JTWj-sgzZToMfTjghi17hUuuV1Ps2tkK2AHOLQdSc5DiHMq0aAlYzlnN1pxx53pQFlcxZeQ/https%3A%2F%2Fgithub.com%2Fanewton1998%2Fdraft-regext-rdap-extensions%2Fpull%2F30%2Ffiles> Let me know what you think. -andy On 8/23/24 10:00, Gould, James wrote: > Andy, > > It may be useful to include guidance for RDAP extensions use of the RDAP JSON > Values registry in the extensions draft. I believe that new RDAP extensions > should be encouraged to support standard values to increase interoperability, > where extending the RDAP JSON Values registry is better than creating a new > registry specific to the RDAP extension and certainly better than not > leveraging the RDAP JSON Values registry at all. The Redacted Extension did > this to define three new types with "redacted name", "redacted reason", and > "redacted expression language", and the language used in the first paragraph > of section 6.2 supported the extension of the types. We could look to have > any new types define the expected format of the values to help support the > review by the DEs, where some types may be more freeform than others (e.g., > support mixed case). For example, the "redacted name" values did use mixed > case to match the source policy and I believe the "redacted reason" values > would be in more sentence form with mixed case and potentially punctuation. > The "redacted expression language" is more of an identifier, so it could be > predefined as being only lowercase. The Versioning Extension has a similar > extension of the RDAP JSON Values registry types with the "versioning" type > and registration of the values of "opaque" and "semantic". I view the > "versioning" type as more of an identifier, where being lowercase makes sense. > > The extensions draft could clarify the expected value format for the > predefined types in the RDAP RFCs and provide the guidance for how to define > new types with the expected value format for future RDAP extensions. > _______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
