Re: [regext] JSContact issues

[Jasdip Singh <[e-mail]>]

Hi.

Just wanted to inject couple of inputs, marked [JS].

Thanks,
Jasdip

From: regext <[e-mail]> on behalf of Mario Loffredo <[e-mail]>
Date: Tuesday, March 21, 2023 at 5:40 AM
To: Andy Newton <[e-mail]>
Cc: Registration Protocols Extensions <[e-mail]>
Subject: Re: [regext] JSContact issues

HI Andy,

again my comments below.
Il 20/03/2023 12:06, Andrew Newton ha scritto:

On Fri, Mar 17, 2023 at 10:45 AM Mario Loffredo

<[e-mail]><mailto:[e-mail]> wrote:

1) Section 3 has some strong MUST language regarding JSContact and

EPP. As I'm reading it, I am trying to deduce what interoperability

problem is being mitigated but, at least to me, it is not apparent. If

there is some cardinality issue, I think the rules should be

generalized because RDAP is used by more than just the EPP registries,

most notably the RIRs but also Marc's space debris proposal.



If an EPP mapping is truly necessary, I think putting it in a separate

EPP mapping section would be better. Also, unless things will truly

break, the normatives should be SHOULD and not MUST.

[ML] No problem. I can remove the reference to the RFC5733 labels and

generally talk about the unique or the preferred value for each contact

property.

For clarity, I don't think a 5733 mapping is a bad thing. I just want

to be sure we accommodate those servers where it has no relevance.

[ML] Me neither. But I think there would be no more need to clearly refer to RFC5733 properties if I talked more generally about mostly used properties in RDAP  and their related unique/preferred values.

The bigger contains the smaller. :-)

Would like to know if there are other possible commonly used contact properties in addition to those mentioned currently.

[JS] Just checked RFC 9083, and there is no explicit mention of RFC 5733 vis-à-vis defining the Entity Object class. So, agree that no need to tie closely with RFC 5733 here.

As for the non-DNR actors, just looking at what ARIN returns for an entity response, what’s currently listed in this draft should suffice.

I would be inclined to leave MUST to provide clients and servers with a

pre-defined set of map keys for the mostly used contact properties.

If left as a MUST, the document should be clear about what

interoperability problem will occur if that MUST is violated. At least

to me it is not clear.

[ML] I refer to the interoperability issues coming from using different JSON labels to identify the same logical JSON object.

Let's take, for example, how a JSContact collection can be handled. If it gets deserlized to a map,  you can leverage the map capability to access an entry by its key rather than looping on the entries to find out the desire entry.

I mean, you can access the unique/preferred fax number by getting the right entry of the "phones" map by the "fax" key instead of looping on all the "Phone" objects to find out the one whose "features" include "fax" and "pref"  equals to 1.

Through the capabilities of the JSON libraries, it is easy to implement a mixed deserialization strategy: "phones" is an object having two Phone members, namely "voice" and "fax", and additional Phone members are put on a map.

All above is possible so long as the map keys are pre-defined.

In addition, I would define a general mapping scheme that SHOULD

(instead of MAY) be used for the additional entries of the mostly used

maps or others.



The scheme could merely consist in appending a sequential number to the

map name in the singular (e.g. "phone-1", "phone-2" for the additional

entries of the "phones" map to those identified by "voice" and "fax" ).



The other option is to always apply the general scheme to any map key.



Which way do you and others consider the most suitable ?

Conceptually this sounds good. I would need to see a few examples to

wrap my brain around it though. :)

[ML] Here in the following an example of how the "phones" map could be.

Option 1:

        "phones": {

          "voice" : {

            "@type": "Phone",

            "contexts": {

              "work": true

            },

            "features": {

               "voice": true

            },

            "pref": 1,

            "number": "tel:[phone]"<tel:[phone]>

          },



          "phone-1" : {

            "@type": "Phone",

            "contexts": {

              "work": true

            },

            "features": {

               "voice": true

            },

            "pref": 2,

            "number": "tel:[phone]"<tel:[phone]>

          },

          "fax" : {

            "@type": "Phone",

            "contexts": {

              "work": true

            },

            "features": {

               "fax": true

            },

            "number": "tel:[phone]"<tel:[phone]>

          }



        },

Option 2:

        "phones": {

          "phone-1" : {

            "@type": "Phone",

            "contexts": {

              "work": true

            },

            "features": {

               "voice": true

            },

            "pref": 1,

            "number": "tel:[phone]"<tel:[phone]>

          },



          "phone-2" : {

            "@type": "Phone",

            "contexts": {

              "work": true

            },

            "features": {

               "voice": true

            },

            "pref": 2,

            "number": "tel:[phone]"<tel:[phone]>

          },

          "phone-3" : {

            "@type": "Phone",

            "contexts": {

              "work": true

            },

            "features": {

               "fax": true

            },

            "number": "tel:[phone]"<tel:[phone]>

          }



        },

2) I think Section 4 will actually hinder transition rather than help

it. If a server doesn't support JSContact, there are no amount of

query parameters that a client can send to make it do so. Therefore,

we should treat this like any other extension... server's just send it

if they have it.



If there is a desire to save hamster wheel time (i.e. bandwidth),

shouldn't we try to make use of the "subsetting" extension?

[ML] The main reason supporting the proposed approach is to avoid to

duplicate contact data.  Conceptually, it seems to me the best way to go

because jCard and JSContact are alternative formats for the same

information.



The other reason is that servers can realize when the transition is

really concluded because no more clients use the jcard parameter so that

there is no risk to break the response.



Otherwise, the servers couldn't know when it's time to remove jCard from

the responses and that decision would be made arbitrarily.

I think the majority of servers will switch to JSContact via mandate

rather than metrics. But that's just my opinion.
[ML] Switching by mandate seems to me unsuitable for all of the RDAP contexts, e.g. ccTLDs .






That said, if the goal is to collect metrics I believe that can be

accomplished with one query parameter instead of two.

[ML] The goal is to support a smooth transition from jCard to JSContact and, at the same time, minimize the payload that can be remarkable in the case of search responses.

In addition, the proposed approach mitigates the risk of breaking the RDAP response and is in line with the current practices in deprecating REST APIs.

[JS] This is a tricky balance to pull off. My initial impression of the API deprecation approach was that it is too complex but unless we could find a better way to not bloat entity responses with both jCard and JSContact entries, those extra 2 request parameters are palatable enough. :)

Using the “subsetting” extension is an interesting idea but IIRC it only applies to search path segments. Even if we could apply it more broadly, not sure if it is simple enough to offset the “complexity” we perceive from those 2 temporary request parameters.



Also, I don't think we want to set a precedent of sending query

parameters for every extension. After a while, we'll run into URI

length limitations. Additionally, if we want to start signaling client

capabilities instead of user queries, we should look into doing that

in headers or some other HTTP mechanism.

[ML] The precedent already exists. There are other RFCs/drafts along with this document that propose both request and response extensions, and this is the only one defining two alternative query parameters that would be used as long as the jCard deprecation process is in place.

With regard to the maximum length allowed for an URL, there is no rule but a general recommendation to not exceed 2048 bytes.

I have tested the length of an RDAP query including the following:

- reverse search domains by entity handle and role

- jscard=1

- count=1

- fieldSet=brief

- sort=registrationDate

- cursor = <the value resulting from the link in paging_metadata

The result I got was approximately 250 bytes that is a bit more than 12% of the maximum length allowed.

Based on that, I'm pretty confident that we'll hardly exceed that limit and, most likely, we'll have to add the POST method in order to meet new user requirements.

Therefore, my first concern still remains to provide a deprecation process that minimize the risk of breaking the REST API.

Finally, it seems to me that headers or other HTTP mechanisms can't be used here.

They are focused on resources rather than single resource features.

For example, RFC 8594 talks about resource deprecation that means making an URI to became unresponsive.

Furthermore, I see many drawbacks in returning both jCard and JSContact

in the same response such as the implications on the use of the fn

parameter in both standard and reverse searches (see point 3), and

duplicating some possible items of the redacted array.



I would leave the document as is about this point unless there was a

large consensus on treating JSContact as additional to jCard.

This is a fair point, but during a transition the work has to be done

to support both JCard and JSContact by both client and servers anyway.

So no work or complexity is being avoided.

[ML] Don't see great complexity. Consider that basicly implementing the deprecation process consists in repeating twice the actions needed to support the pure extension approach.

I mean, the extension approach requires servers to recognize and support the jscard parameter for a while and ignore it after the switch.

Instead, the deprecation process requires servers to do exactly the same as above but first for the jscard parameter and then for the jcard parameter.

Obviously, I'm open to whatever solution being a better balance between reducing the implementation effort and avoiding RDAP breaks.



And if there is a desire to indicate a server has deprecated JCard

(YES!!!), perhaps a "jcard_deprecated" RDAP conformance value can be

used for that.

[ML] Sounds reasonable to me to include such an RDAP conformance tag in

the help response.

[ML] Thinking again about this, think it would make sense just for pure extension approach.

From the third step of the deprecation process on, jCard is no more returned by default.



3) There is no support for section 3.2.3 of RFC 9082, specifically the

name search. The current pattern is "entities?fn=XXX". The use of "fn"

parameter is a bit unfortunate, but this draft should indicate how a

server supporting only JSContact maps this query.

[ML] On the assumption that either jCard or JSContact is returned, think

it's embedded in the mapping between the vCard fn and JSContact fullName

as described in the appendix.



The query parameter remains fn but it is mapped to another RDAP property.

Great. IMHO, this should be explicitly stated and strongly normative

in the document.

[ML] No problem, will do.

Best,

Mario







-andy

--

Dott. Mario Loffredo

Technological Unit “Digital Innovation”

Institute of Informatics and Telematics (IIT)

National Research Council (CNR)

via G. Moruzzi 1, I-56124 PISA, Italy

Phone: [phone]

Web: http://www.iit.cnr.it/mario.loffredo