Re: [regext] JSContact issues

[Mario Loffredo <[e-mail]>]

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]>  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.

>> 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]"
           },

           "phone-1" : {
             "@type": "Phone",
             "contexts": {
               "work": true
             },
             "features": {
                "voice": true
             },
             "pref": 2,
             "number":"tel:[phone]"
           },
           "fax" : {
             "@type": "Phone",
             "contexts": {
               "work": true
             },
             "features": {
                "fax": true
             },
             "number":"tel:[phone]"
           }

         },

Option 2:

         "phones": {
           "phone-1" : {
             "@type": "Phone",
             "contexts": {
               "work": true
             },
             "features": {
                "voice": true
             },
             "pref": 1,
             "number":"tel:[phone]"
           },

           "phone-2" : {
             "@type": "Phone",
             "contexts": {
               "work": true
             },
             "features": {
                "voice": true
             },
             "pref": 2,
             "number":"tel:[phone]"
           },
           "phone-3" : {
             "@type": "Phone",
             "contexts": {
               "work": true
             },
             "features": {
                "fax": true
             },
             "number":"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.

> 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