Re: [regext] JSContact issues
Hi Andy, again my response below. Il 22/03/2023 22:17, Andrew Newton ha scritto: Mario, Response in-line. On Tue, Mar 21, 2023 at 2:39 AM Mario Loffredo wrote: [ML] I refer to the interoperability issues coming from using different JSON labels to identify the same logical JSON object.> I understand now and support your approach. Thanks for the example. And strong normative language seems appropriate. [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. However, if you look at this from a client perspective once the client understands JSContact, it will alway set this parameter. But given not all servers will be transitioning at the same time, clients will always need to understand JCard as well. So they will always send both parameters forever. Therefore, the parameters are useless and just add complexity. [ML2] In both approaches, clients will likely issue the jscard parameter beyond the end of the transition. The purpose of the jcard parameter is to let clients to take their time to support JSContact without stop working even for short time. I'll bring this topic for discussion at next meeting to have a feedback from the WG. 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: +39.0503153497 Web: http://www.iit.cnr.it/mario.loffredo ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] JSContact issues
Mario, Response in-line. On Tue, Mar 21, 2023 at 2:39 AM Mario Loffredo wrote: > > [ML] I refer to the interoperability issues coming from using different JSON > labels to identify the same logical JSON object.> I understand now and support your approach. Thanks for the example. And strong normative language seems appropriate. > [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. However, if you look at this from a client perspective once the client understands JSContact, it will alway set this parameter. But given not all servers will be transitioning at the same time, clients will always need to understand JCard as well. So they will always send both parameters forever. Therefore, the parameters are useless and just add complexity. -andy ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] JSContact issues
Hi.
Just wanted to inject couple of inputs, marked [JS].
Thanks,
Jasdip
From: regext on behalf of Mario Loffredo
Date: Tuesday, March 21, 2023 at 5:40 AM
To: Andy Newton
Cc: Registration Protocols Extensions
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
<mailto:mario.loffr...@iit.cnr.it> 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:+1-555-555-1234"
},
"phone-1" : {
"@type": "Phone",
"contexts": {
"work": true
},
"features": {
"voice": true
},
"pref": 2,
"number": "tel:+1-555-555-5678"
},
"fax" : {
"@type": "Phone",
"contexts"
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
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:+1-555-555-1234"
},
"phone-1" : {
"@type": "Phone",
"contexts": {
"work": true
},
"features": {
"voice": true
},
"pref": 2,
"number":"tel:+1-555-555-5678"
},
"fax" : {
"@type": "Phone",
"contexts": {
"work": true
},
"features": {
"fax": true
},
"number":"tel:+1-555-555-9012"
}
},
Option 2:
"phones": {
"phone-1" : {
"@type": "Phone",
"contexts": {
"work": true
},
"features": {
"voice": true
},
"pref": 1,
"number":"tel:+1-555-555-1234"
},
"phone-2" : {
"@type": "Phone",
"contexts": {
"work": true
},
"features": {
"voice": true
},
"pref": 2,
"number":"tel:+1-555-555-5678"
},
"phone-3" : {
"@type": "Phone",
"contexts": {
"work": true
},
"features": {
"fax": true
},
"number":"tel:+1-555-555-9012"
}
},
2) I think Section 4 will actually hinder transition
Re: [regext] JSContact issues
On Fri, Mar 17, 2023 at 10:45 AM Mario Loffredo 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. > > 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. > > 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. :) > > > > > 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. That said, if the goal is to collect metrics I believe that can be accomplished with one query parameter instead of two. 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. > > 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. > > > > > 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. > > > > 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. -andy
Re: [regext] JSContact issues
Hi Andy, thanks a lot for your review and feedback. Please find my comments below. Il 16/03/2023 15:24, Andrew Newton ha scritto: Hi all, I'm doing some RDAP programming and looking at the JSContact draft and have a couple of comments. 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. 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. 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 ? 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. 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. 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. 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. Best, Mario Thanks. -andy ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext -- 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: +39.0503153497 Web: http://www.iit.cnr.it/mario.loffredo ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
