Subject: [regext] Fwd: New Version Notification for draft-loffredo-regext-rdap-jcard-deprecation-00.txt

From: Mario Loffredo <[email-masked]>
Date: Mon, 23 Mar 2020 13:48:29 +0100

The first draft about using JSContact in RDAP JSON Responses has been 
submitted to the IETF.  I co-authored this draft with Gavin Brown from 
CentralNic to provide a model for deprecating jCard in RDAP.

Additional examples of conversion between jCard and the contact card 
defined by JSContact are available at 
https://github.com/mario-loffredo/jcard-deprecation/

Please review the draft and provide any feedback.

Thanks,

Mario

-------- Messaggio Inoltrato --------
Oggetto: 	New Version Notification for 
draft-loffredo-regext-rdap-jcard-deprecation-00.txt
Data: 	Mon, 23 Mar 2020 05:37:10 -0700
Mittente: 	[email-masked]
A: 	Gavin Brown <[email-masked]>, Mario Loffredo 
<[email-masked]>

A new version of I-D, draft-loffredo-regext-rdap-jcard-deprecation-00.txt
has been successfully submitted by Mario Loffredo and posted to the
IETF repository.

Name: draft-loffredo-regext-rdap-jcard-deprecation
Revision: 00
Title: Using JSContact in Registration Data Access Protocol (RDAP) JSON 
Responses
Document date: 2020-03-23
Group: Individual Submission
Pages: 12
URL: 
https://www.ietf.org/internet-drafts/draft-loffredo-regext-rdap-jcard-deprecation-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-loffredo-regext-rdap-jcard-deprecation/
Htmlized: 
https://tools.ietf.org/html/draft-loffredo-regext-rdap-jcard-deprecation-00
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-loffredo-regext-rdap-jcard-deprecation

Abstract:
This document describes how RDAP servers can represent entity contact
information in JSON responses using JSContact.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: "Gould, James" <[email-masked]>
Date: Mon, 23 Mar 2020 15:57:32 +0000

Mario,

Thanks for posting the draft.  I reviewed the draft and below is my feedback:

  1.  High level
     *   I believe this should be Standards Track instead of Best Current Practice, since it defines protocol (e.g., new query parameters and new response fields) and not strictly practice.
     *   I recommend defining JSCard as an RDAP extension that replaces the use of jCard in RFC7483 with JSCard by injecting some of the content of draft-loffredo-jmap-jscontact-vcard (focused on presenting the RDAP contact information using JSCard) and placing the transition steps outlined in section 4 into a Transition Considerations section.
  2.  Section 2
     *   Nit – “only JSCard objects are considered” instead of “only JSCard obejcts are considered”.
  3.  Section 4.3.3
     *   To replace jCard with JSCard, I believe the goal “the response would always be compliant to RFC7483<https://tools.ietf.org/html/rfc7483>” can only be met if support for JSCard is defined as an RDAP extension.
  4.  Section 6
     *   There is the need to register the “jscard” extension identifier in the IANA RDAP Extensions Registry, assuming that a new RDAP extension is being defined.
  5.  You may want to outline in a Privacy Considerations section to define how redaction is handled when using JSCard.  The assumption is that the redacted fields are excluded from the response, but I would be explicit about it.

--

JG

James Gould
Distinguished Engineer
[email-masked]<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email-masked]>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com<http://verisigninc.com/>

From: regext <[email-masked]> on behalf of Mario Loffredo <[email-masked]>
Date: Monday, March 23, 2020 at 8:50 AM
To: "[email-masked]" <[email-masked]>
Subject: [EXTERNAL] [regext] Fwd: New Version Notification for draft-loffredo-regext-rdap-jcard-deprecation-00.txt

The first draft about using JSContact in RDAP JSON Responses has been submitted to the IETF.  I co-authored this draft with Gavin Brown from CentralNic to provide a model for deprecating jCard in RDAP.

Additional examples of conversion between jCard and the contact card defined by JSContact are available at https://github.com/mario-loffredo/jcard-deprecation/

Thanks,
Mario

-------- Messaggio Inoltrato --------
Oggetto:

New Version Notification for draft-loffredo-regext-rdap-jcard-deprecation-00.txt

Data:

Mon, 23 Mar 2020 05:37:10 -0700

Mittente:

[email-masked]<mailto:[email-masked]>

A:

Gavin Brown <[email-masked]><mailto:[email-masked]>, Mario Loffredo <[email-masked]><mailto:[email-masked]>

Name: draft-loffredo-regext-rdap-jcard-deprecation
Revision: 00
Title: Using JSContact in Registration Data Access Protocol (RDAP) JSON Responses
Document date: 2020-03-23
Group: Individual Submission
Pages: 12
URL: https://www.ietf.org/internet-drafts/draft-loffredo-regext-rdap-jcard-deprecation-00.txt
Status: https://datatracker.ietf.org/doc/draft-loffredo-regext-rdap-jcard-deprecation/
Htmlized: https://tools.ietf.org/html/draft-loffredo-regext-rdap-jcard-deprecation-00
Htmlized: https://datatracker.ietf.org/doc/html/draft-loffredo-regext-rdap-jcard-deprecation

Abstract:

The IETF Secretariat

---

From: Mario Loffredo <[email-masked]>
Date: Tue, 24 Mar 2020 17:55:29 +0100

Hi James,

thanks a lot for your quick reply and careful review.

My responses to your comments are included below.

Il 23/03/2020 16:57, Gould, James ha scritto:
>           a. I believe this should be Standards Track instead of Best 
> Current Practice, since it defines protocol (e.g., new query 
> parameters and new response fields) and not strictly practice.
Agreed. I was so focused on the transition model that I missed I was 
implicitly defining new query and response extensions.
>
>           b. I recommend defining JSCard as an RDAP extension that 
> replaces the use of jCard in RFC7483 with JSCard by injecting some of 
> the content of draft-loffredo-jmap-jscontact-vcard (focused on 
> presenting the RDAP contact information using JSCard)
OK. I will replace the example included in the "Using JSCard objects ib 
RDAP Responses" with one taken from RFC7483 to point out the differences 
between jCard and JSCard.
> and placing the transition steps outlined in section 4 into a 
> Transition Considerations section.
Sounds reasonable.
>
> 2. Section 2
>
>          a. Nit – “only JSCard objects are considered” instead of 
> “only JSCard obejcts are considered”.
Good catch.
>
> 3. Section 4.3.3
>
>         a. To replace jCard with JSCard, I believe the goal “the 
> response would always be compliant to RFC7483 
> <https://tools.ietf.org/html/rfc7483>” can only be met if support for 
> JSCard is defined as an RDAP extension.
Agreed.
>
> 4. Section 6
>
>        a. There is the need to register the “jscard” extension 
> identifier in the IANA RDAP Extensions Registry, assuming that a new 
> RDAP extension is being defined.
OK.
>
> 5, You may want to outline in a Privacy Considerations section to 
> define how redaction is handled when using JSCard.  The assumption is 
> that the redacted fields are excluded from the response, but I would 
> be explicit about it.
>
OK. I will resume and expand the point already included in the 
"JSContact" section. The basic concept is that you can simply exclude 
the redacted fields instead of using placeholder values.

Best,

Mario

> -- 
>
> JG
>
>
>
> *James Gould
> *Distinguished Engineer
> [email-masked] 
> <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email-masked]>
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com <http://verisigninc.com/>
>
> *From: *regext <[email-masked]> on behalf of Mario Loffredo 
> *Date: *Monday, March 23, 2020 at 8:50 AM
> *To: *"[email-masked]" <[email-masked]>
> *Subject: *[EXTERNAL] [regext] Fwd: New Version Notification for 
> *Oggetto: *
> New Version Notification for 
> *Data: *
> *Mittente: *
> [email-masked] <mailto:[email-masked]>
>
> *A: *
>
> 	
>
> Gavin Brown <[email-masked]> 
> <mailto:[email-masked]>, Mario Loffredo 
> <[email-masked]> <mailto:[email-masked]>
>
>
>
>
> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext

-- 
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
#pleasestayathome

---

From: Mario Loffredo <[email-masked]>
Date: Tue, 24 Mar 2020 19:45:06 +0100

Hi George,

Il 23/03/2020 23:15, George Michaelson ha scritto:
> Nice work Mario. I have put this into consideration inside the RIR 
> engineers group.
Thanks. Any feedback will be greatly appreciated.
>
> Thanks for your effort in this btw. It is much appreciated that you 
> think about migration and present alternatives like this.
Happy it could be useful.
>
> All the best to you and your family, and please, stay safe.

Thanks for your concern. We (i.e. all Italians) are doing whatever it 
takes :-)

Cheers,

Mario

>
> -george
>
>
> On Mon, Mar 23, 2020 at 10:50 PM Mario Loffredo 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     The first draft about using JSContact in RDAP JSON Responses has
>     been submitted to the IETF.  I co-authored this draft with Gavin
>     Brown from CentralNic to provide a model for deprecating jCard in
>     RDAP.
>
>     Additional examples of conversion between jCard and the contact
>     card defined by JSContact are available at
>     Mittente: 	[email-masked] <mailto:[email-masked]>
>     A: 	Gavin Brown <[email-masked]>
>     A new version of I-D,
>     until the htmlized version and diff are available at
>     tools.ietf.org <http://tools.ietf.org>.
>
>     The IETF Secretariat
>
>
>     [email-masked] <mailto:[email-masked]>