Subject: Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7483bis

From: "James Galvin" <[email-masked]>
Date: Fri, 02 Oct 2020 16:06:27 -0400

The WGLC for this document was scheduled to end today.  While there is 
support to move the document forward there are two minor comments that 
have been raised during the last call.

The chairs would like to hear from other working group members as to 
what to do with these comments.  Rather than close the last call and 
risk another last call, we are extending this last call for another 
week.  If we can come to a consensus as to how to proceed before the end 
of last call than the document can stay on track to be submitted to the 
IESG after the last call.

The WG last call will end at close of business on Friday, 9 October 
2020.

Here are the comments as seen on the mailing list.  Please respond with 
your suggestions regarding these two comments.

James Gould:

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.

Two response have been offered:

Scott Hollenbeck:

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?

Jasdip Singh:

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.

Mario Loffredo:

The document does not contain any requirement or recommendation about 
when returning ldhName and unicodeName values. However, the examples 
seem to convey the idea that ldhName must  always be returned and 
unicodeName must be returned in case of an IDN.

No responses yet.

Thanks!

Antoin and Jim

On 18 Sep 2020, at 9:52, Antoin Verschuren wrote:

> The following working group document is believed to be ready for 
> submission to the IESG for publication as a standards track document:
>
> https://datatracker.ietf.org/doc/draft-ietf-regext-rfc7483bis/
>
> This WG last call will end at close of business, Friday, 2 October 
> 2020.
>
> Please review this document and indicate your support (a simple 
> “+1” is sufficient) or concerns with the publication of this 
> document by replying to this message on the list.
>
> The document shepherd for this document is Jasdip Singh.
>
> Regards,
>
> Jim and Antoin
>
>
>
>
>
>
>
> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext

---

From: Mario Loffredo <[email-masked]>
Date: Sat, 3 Oct 2020 11:37:35 +0200

Il 02/10/2020 22:06, James Galvin ha scritto:
> week.  If we can come to a consensus as to how to proceed before the 
> end of last call than the document can stay on track to be submitted 
> to the IESG after the last call.
>
> The WG last call will end at close of business on Friday, 9 October 2020.
>
>
>
> Here are the comments as seen on the mailing list.  Please respond 
> with your suggestions regarding these two comments.
>
>
>
> James Gould:
>
> 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 
> 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 
IMHO RFC7095 omits to state something about the "fn" element while it 
states clearly that the "version" element must be set to "4.0".  This 
omission leaves the door open to the interpretation that the empty 
string is an allowable value. In my opinion this interpretation is 
correct while the "fn" element must not be null. Besides, in this way,  
RDAP implementers are free to differentiate between the case where a 
value is missing from the case where the value exists but isn't 
displayed for privacy concerns.

That being said, I would write the above sentence as in the following:

/Contact information is defined using jCards as described in [RFC7095].  
The “fn” member is required and MUST NOT be null according to [RFC6350], 
where an empty “fn” member MAY be used when the contact name does not 
exist or is redacted. /

As an additional note, I would like to announce that soon I will release 
a Java library, named jscontact-tools, offering capabilities for 
JSContactcreation, validation, serialization/deserialization and 
conversion from vCard, xCard e jCard. Validation and conversion leverage 
the features provided by ez-vcard 
<https://github.com/mangstadt/ez-vcard> Java library.

I have tested the library against the responses returned by the RDAP 
servers listed in the IANA Boostrap Service Registy for Domain Name 
Space. Almost 25% of jCard instances processed don't return a value for 
the "fn" element  (e.g.  it is either missing or null). This leads me to 
think that the clarification proposed by James is needed.

Best,

Mario

>> This WG last call will end at close of business, Friday, 2 October 2020.
>>
>> Please review this document and indicate your support (a simple “+1” 
>> is sufficient) or concerns with the publication of this document by 
>> replying to this message on the list.
>>

-- 
Dr. Mario Loffredo
Systems and Technological Development Unit
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Mobile: +39.3462122240
Web: http://www.iit.cnr.it/mario.loffredo

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 5 Oct 2020 12:53:29 +0000

From: regext <[email-masked]> On Behalf Of Mario Loffredo
Sent: Saturday, October 3, 2020 5:38 AM
To: James Galvin <[email-masked]>; [email-masked]
Subject: [EXTERNAL] Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7483bis

   The WGLC for this document was scheduled to end today.  While there is support to move the document forward there are two minor comments that have been raised during the last call.

   The chairs would like to hear from other working group members as to what to do with these comments.  Rather than close the last call and risk another last call, we are extending this last call for another week.  If we can come to a consensus as to how to proceed before the end of last call than the document can stay on track to be submitted to the IESG after the last call.

   Here are the comments as seen on the mailing list.  Please respond with your suggestions regarding these two comments.

   James Gould:

   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.

   Scott Hollenbeck:

   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?

   Jasdip Singh:

   Seems if the RDAP profile for the DNRs (https://www.icann.org/resources/pages/rdap-operational-profile-2016-07-26-en<https://secure-web.cisco.com/1FxE3-8AUQw4AMA04p2iQVRJh0991-gT1gZXLVQSMAGE7tIRQNXEHKTfHbT8hB5Hh6DzlG-girMWkzLkV72lTk4Z8roLcu5bB8T1cfS56XCwqHHHCAZY_boa6q_s3GO3IWufTUBd7di2-x_W-1_pUctunaV9v5bOUtNuRIA_bSa3p1iqsMLydRI3WQg2z4xHhx8OOkodbwNnUW-FQULjEfcgY99Rggri_FHuPl8aeW-B4Bh8cqaMNy-Y2xpTGGu5gvE3kTjgn4VYoHYJtA5JfQQ/https%3A%2F%2Fwww.icann.org%2Fresources%2Fpages%2Frdap-operational-profile-2016-07-26-en>) could clarify this, the spec could be left as-is.

   IMHO RFC7095 omits to state something about the "fn" element while it states clearly that the "version" element must be set to "4.0".  This omission leaves the door open to the interpretation that the empty string is an allowable value. In my opinion this interpretation is correct while the "fn" element must not be null. Besides, in this way,  RDAP implementers are free to differentiate between the case where a value is missing from the case where the value exists but isn't displayed for privacy concerns.

   Contact information is defined using jCards as described in [RFC7095].  The “fn” member is required and MUST NOT be null according to [RFC6350], where an empty “fn” member MAY be used when the contact name does not exist or is redacted.

   [SAH] I’m OK with this. Any objections?

   Scott

---

From: Jasdip Singh <[email-masked]>
Date: Mon, 5 Oct 2020 14:13:25 +0000

Hi. I am fine with this update. Thanks for highlighting and clarifying it, James and Mario.

Jasdip

From: regext <[email-masked]> on behalf of "Hollenbeck, Scott" <shollenbeck=[email-masked]>
Date: Monday, October 5, 2020 at 8:53 AM
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7483bis

James Gould:

Scott Hollenbeck:

Jasdip Singh:

Scott

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 12 Oct 2020 13:26:31 +0000

> -----Original Message-----
> From: regext <[email-masked]> On Behalf Of James Galvin
> Sent: Friday, October 2, 2020 4:06 PM
> To: [email-masked]
> The chairs would like to hear from other working group members as to what
> to do with these comments.  Rather than close the last call and risk another
> last call, we are extending this last call for another week.  If we can come to a
> consensus as to how to proceed before the end of last call than the
> document can stay on track to be submitted to the IESG after the last call.
>
> (https://secure-
> web.cisco.com/11khs_gD3RqFuWkwSmkqxXidBMgZZIHUGiC-
> mnI0WBAe7ZaFAHesmDgIEQi6C5xdf4AFgOuCxci5Eg7TKAZOYRCMTpkn4HpQ
> A0IDR_way6sBg1J7G75Fc6554SdNlt4CZkx6Y4of235gC9pdotYdG-
> DmTSKFkMu7EbRZFxRQq2wuuUIJrvrbPz8ZGCf81LYvWGTfZrUMt-
> DtcEm1hz8yHyNC2J1hOc_6YhTLsOG_N5ZHM81dqp6v_HPIIN9ppz69MwuaZA
> ao62RBYsmFe3OyFzQ/https%3A%2F%2Fwww.icann.org%2Fresources%2Fpa
> ges%2Frdap-operational-profile-2016-07-26-en)

[SAH] I just updated the document to address this feedback.

> unicodeName must be returned in case of an IDN.

[SAH] There was no additional discussion, so I left this one alone.

Scott

---

From: Antoin Verschuren <[email-masked]>
Date: Mon, 26 Oct 2020 16:11:44 +0100

Thank you Scott and all others that replied during the extended WGLC..
This is to inform you that this WGLC is now officially closed.
We had 3 explicit statements of support for this document, and 2 concerns which led to an extended WGLC. 
1 of the concerns was addressed by the autor in a new version of the document, and 1 concern did not get support.
We will submit the new version of the document to the IESG as is.

The document shepherd for this document is Jasdip Singh.
Jasdip, could you please start your shepherd writeup?

Regards,

Jim and Antoin

> Op 12 okt. 2020, om 15:26 heeft Hollenbeck, Scott <shollenbeck=[email-masked]> het volgende geschreven:
> 
>> From: regext <[email-masked] <mailto:[email-masked]>> On Behalf Of James Galvin
>> To: [email-masked] <mailto:[email-masked]>
>> (https://secure- <https://secure-/>
>> web.cisco.com/11khs_gD3RqFuWkwSmkqxXidBMgZZIHUGiC- <http://web.cisco.com/11khs_gD3RqFuWkwSmkqxXidBMgZZIHUGiC->
>> ao62RBYsmFe3OyFzQ/https%3A%2F%2Fwww.icann.org <http://2fwww.icann.org/>%2Fresources%2Fpa
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/regext <https://www.ietf.org/mailman/listinfo/regext>