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
<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.
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 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: +39.0503153497
Web:http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
