Hi Mario, Feedback with PK3>
On 13.08.25 17:37, Mario Loffredo wrote:
PK3> Are you proposing to include all address components as listed here https://www.iana.org/assignments/jscontact/jscontact.xml#jscontact-enum-values-4 ?Hi Pawel, gain my responses inline prefixed with ML3. Il 12/08/2025 08:24, Pawel Kowalik ha scritto:Hi Mario, Jasdip, On 25.07.25 16:11, Mario Loffredo wrote:PK2> Following rfc1958 3.2, I would suggest to remove unstructured address. If there would be opinions appearing with good arguments to add it (and as I read Jasdip's response, these are not RIRs), we can always do it with a clear use case at hand. Otherwise we have a clear advantage for the client implementation that they can rely on the structured data being used - which is much better for them.Hi Jasdip, thanks for your comments. Please find my own inline prefixed with [ML]. Il 25/07/2025 14:22, Jasdip Singh ha scritto:[ML] Yes, JSContact is very flexible in this regard.It's good to know that the structured name must be considered.Hi Mario, Pawel, Please see my comments below. Thanks, Jasdip *From: *Pawel Kowalik <[email protected]> *Date: *Thursday, July 24, 2025 at 6:09 PM*To: *Mario Loffredo <[email protected]>, Pawel Kowalik <[email protected]>, [email protected] <[email protected]> *Subject: *[regext] Re: Fwd: I-D Action: draft-ietf-regext-rdap-jscontact-22.txt1) Some fields in the profile seems duplicated to other fields and I am not convinced we need them at all: components Name -> we have full Name … full Address -> we have components of Address [ML] Viceversa, here in the following examples where the postal address is represented only as an unstructured text. https://rdap.arin.net/registry/ip/199.0.0.0 (again) https://rdap.apnic.net/ip/133.0.0.0 https://rdap.db.ripe.net/ip/193.0.0.25 In these cases, I assumed that either only the unstructured postal address was available or mayve RIRs share the policy to display the full address (@Tom, @Jasdip you can shed a light here). The above cases made me think that both formats should be allowed.PK> OK, this would be a friction for the clients to support both, so unless RIRs say they also have structured data we can't do any better. Thanks for clarification.[JS] The RIRs are expected to align with the NRO RDAP Profile [1]. As for the name and address fields from jCard, per section 5.1.1 of this profile, “fn”, “n”, and “adr” may be returned. For ARIN’s RDAP service, the unstructured “adr” is constructed from structured address data (street, city, state, zip, and country) from the database.The RDAP JSContact draft says:“The JSContact "name" property MUST include the "full" member and MAY include the "components" array to specify the name components of an individual.”“The JSContact "Address" type MUST include at least one between the "full", "components" and "countryCode" members.”Looks like RDAP JSContact allows for unstructured names and addresses and their structured components. That seems flexible enough for various server operators (DNRs, RIRs, etc.) but not sure if it would be more complex interoperability-wise for the clients.[1] https://bitbucket.org/nroecg/nro-rdap-profile/raw/0ede2b21a9103409b7d4c9c8a1894eb230b77dcd/nro-rdap-profile.txtRegarding the full address, based on your answer, it seems redundant, although the current RDAP responses provided by RIR servers suggest otherwise.The unstructured address leaves room for postal address implementations whose postal address scheme doesn't match the current structure of either jCard or JSContact.So my final opinion is to keep it.[ML3] I think that a reasonable compromise could be removing the unstructured address and, at the same time, omitting to specify the structured address components as I proposed in https://mailarchive.ietf.org/arch/msg/regext/ypO-0Dnz3A3HgQRkzEXwY8W-LfY/Does it work for you ?
I don't particularly like the level of decomposition that has no correspondence in registry data model. room/floor/building/number/block/direction/landmark/separator are typically all stored under "street" together with what is "name" in JSContact. What will happen is that in most cases all data would be filled in as "name" resulting the clients ignoring other fields anyway. If it happens that a server would fill in any of those fields the clients may be confused what to do with it.
If there is a good reason to add all or some of those fields I would suggest to have a clear recommendation in the draft which fields are mandatory how to compose a "standard" data model out of such highly broken down model, so that the clients do it all the same way without being experts on addressing schemas. Especially a MUST NOT needs to be stated for the servers, that if the address is broken down into components, "name" MUST NOT contain any redundant information which are contained in the components.
PK2> the text must be clear whether: a) keys are only temporary for a single response (i.e. can vary between 2 responses of the same object), there is no gap in numbering; -> likely not fully compliant with JSContact RFC b) keys are stable for a period of time when the object is not changed (i.e. as long as no of e-mails got added, deleted or updated, the keys are stable. There is no gap in numbering* ; c) keys are always stable, there can be gaps in numbering.[ML2] The former, i.e. the keys are not bound to the values. After all, this is exactly what happens with the standard RDAP properties.3) 3.1.12. Map Keys[JS] The interesting discussion between you and Pawel raised one point for me. :) Say, an entity has “email”, email-1”, and “email-2” keys to start with. If “email-1” value were to be deleted at some point, in the subsequent responses, would the “email-2” value then become the “email-1” value, or would both “email-1” and “email-2” keys still be returned with an empty value for “email-1”?In this case, the use of numbers as keys or in the keys could confuse the implementer, but I think that a clarifying text could suffice.Keeping the history of changes should be material for a specific RDAP extension like the one Tom proposed some time ago.* if redaction is considered, there might be gaps created anyway[ML3] Option b) works for me
PK3> for me too. Kind Regards, Pawel
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
