> -----Original Message-----
> From: Gould, James <jgould=40verisign....@dmarc.ietf.org>
> Sent: Monday, September 21, 2020 2:27 PM
> To: Hollenbeck, Scott <shollenb...@verisign.com>; i...@antoin.nl;
> regext@ietf.org
> Subject: [EXTERNAL] Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7482bis
>
> Scott,
>
> Yes, lumping the registrar object with the contact object under a single RDAP
> entity object interface is the rub. We solved the problem in the RDAP
> Profile, by supporting entity lookup by IANA ID (number) and registrar name
> (string) for the registrar objects, and by ROID (“((\w|_){1,80}-\w{1,8}") for
> the contact objects. Where there is overlap, which is registrar name (string)
> and ROID ((“((\w|_){1,80}-\w{1,8}") the contact takes precedence. My
> recommendation is to provide guidance in the section 3.1.5 "Entity Path
> Segment Specification" for this real world case:
>
> The <handle> parameter represents an entity (such as a contact, registrant,
> or registrar) identifier whose syntax is specific to the registration
> provider.
> For example, for some DNRs, contact identifiers are specified in [RFC5730]
> and [RFC5733], and registrar identifiers are specified using the IANA
> Registrar
> ID assigned by ICANN. The server SHOULD define a scheme for the <handle>
> parameter to differentiate between the supported entity object types (e.g.,
> contact and registrar), such as using different <handle> formats, using a
> <handle> precedence order, or a combination of formats and precedence
> order.
>
> The SHOULD could be a MUST, but the point is to provide guidance to
> implementers of the protocol.
I'd like to see some discussion of this suggestion, too. What do people think?
Is it necessary?
Scott
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
