Hello Scott, James.
Seems if the RDAP profile for the DNRs
(https://www.icann.org/resources/pages/rdap-operational-profile-2016-07-26-en)
could clarify this, the spec could be left as-is.
Jasdip
On 9/24/20, 12:30 PM, "regext on behalf of Hollenbeck, Scott"
<regext-boun...@ietf.org on behalf of
shollenbeck=40verisign....@dmarc.ietf.org> wrote:
> -----Original Message-----
> From: regext <regext-boun...@ietf.org> On Behalf Of Gould, James
> Sent: Tuesday, September 22, 2020 10:55 AM
> To: i...@antoin.nl; regext@ietf.org
> Subject: [EXTERNAL] Re: [regext] WG LAST CALL:
draft-ietf-regext-rfc7483bis
>
> I have one item to bring up with draft-ietf-regext-rfc7483bis, which is
> associated with Section 5.1 “The Entity Object Class”. The jCard
"version"
> and "fn" members are required according to RFC 6350, which poses an issue
> if a contact name does not exist or needs to be redacted. To address this
> case, I recommend adding a sentence to the end of section 3 "Common Data
> Types":
>
> Contact information is defined using jCards as described in [RFC7095].
The
> “version” and “fn” members are required according to [RFC6350], where an
> empty “fn” member MAY be used when the contact name does not exist or
> is redacted.
I'd like to see some discussion of this suggestion. If one understands the
normative references, the suggestion is already implicitly addressed. There may
be some value in describing this situation explicitly since it came up in the
ICANN gTLD implementation context, but so others think this clarification is
necessary?
Scott
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
