Hi Andy,
please find my comments inline.
Il 27/11/2023 21:26, Andrew Newton ha scritto:
Mario,
Many thanks for this message.
On Fri, Nov 17, 2023 at 5:57 AM Mario Loffredo
<mario.loffr...@iit.cnr.it> wrote:
2) Chapter "Make it simpler"
Prefer "Make it better". I mean, simplicity cannot be the only parameter used
within IETF to evaluate a technical solution. IMO there are other parameters that are
more important: flexibility, estensibility, efficiency.
In addition, no one in their right mind deliberately makes a proposal
inherently complex. JSContact started as simple as possible and get more
complex to meet the requirements.
As I recall, this is also what happened with jCard. What it ended up
being was nothing like how it started.
My original message on the concept of SimpleContact was born out of
shock at just how complex JSContact had become. In that message, I
proposed multiple paths, one of which was scoping down JSContact usage
in RDAP to its simple parts. However, the thread turned into
SimpleContact vs JSContact, arrays vs objects, us vs them, etc..
etc... etc... and that's how we got here.
[ML] When rdap-jscontact was adopted, JSContact spec already included
the extra information.
From that perspective, JSContact was already more complex than a
contact representation converted from RFC5733 information.
But I do believe this was not considered relevant as the focus was on
the information used in RDAP.
Would also like to outline that some information might appear useless at
present but could turn out useful in the future.
Let's take for example the possible link between the uid property and
the unique and persistent identifier as defined by the European eIDAS
regulation
<https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32015R1501&from=EN>
for the purposes of cross-border identification and validation of domain
registrants as explained in a CENTR white paper
<https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&ved=2ahUKEwj0y9HD7eaCAxVqSvEDHdxOAh4QFnoECBIQAQ&url=https%3A%2F%2Fwww.centr.org%2Flibrary%2Flibrary%2Fdownload%2F10478%2F7435%2F41.html&usg=AOvVaw1URRwBVrzbGecv4oa5nTCM&opi=89978449>.
I'm aware that a digital identifier will probably be publicly
unavailable but it could be useful to some kind of authorized and
legitimized users such as authorities and cybercrime investigators.
With regard to the JSContact properties used in RDAP, never opposed
prejudicially objects to arrays and arrays to maps. JSContact makes use
of all of them depending on the implementation the authors have
considered mostly efficient.
But it is not too late to explore that path. If you are willing, I'd
be happy to work with you on "SimpleContact expressed in JSContact".
The basic premise would be to define a default RDAP extension profile
of JSContact. Others may define their own extension profiles if they
need more from JSContact, but the default profile would limit
JSContact to expressing only that which is in SimpleContact.
[ML] This is exactly the purpose of Section 3 of rdap-jscontact but have
never got a relevant feedback about it.
Meantime, just for a better clarity, have changed the document by
removing from the example in rdap-jscontact the information that is
unlikely used in RDAP.
In more detail, We (because I talked to Tom about this) think the
default profile would do the following:
- only express the items in SimpleContact
- clarify the use of 5733's "sp" (examples suggest it is a region
code, but it is a string)
- define RFC 8605 CONTACT-URI is a JSContact link of type "contact"
- more specificity of the 5733 int/loc mapping (use of und-Latn and
some clarity around the keys).
- restrict localizations from using patch objects (it looks like this
is the case in the latest drafts).
- restricting to JSContact 1.0.
- clarity around JSContact links vs RDAP links
- define a more concrete scheme on sequenced IDs (and some examples)
- clarity on hybrid address types (found in 5733 but also in other
registry models)
- make signaling survive redirects
[ML] Thanks for this. Really appreciated. Think I will be able to
address most of the points above in the next version. Some others need
to be discussed.
I'll provide feedback about it in a separate post.
Again, others would be able to provide profiles that do more such as
offering cryptocurrency wallets and avatars, etc....
[ML] Neither I think they will ever be used in RDAP but some other
information might be instead.
Taking a look at the eIDAS SAML Attribute Profile
<https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&ved=2ahUKEwjThv_N7uiCAxXdgf0HHdOGDcUQFnoECBMQAQ&url=https%3A%2F%2Fec.europa.eu%2Fdigital-building-blocks%2Fwikis%2Fdownload%2Fattachments%2F467109280%2Feidas_saml_attribute_profile_v1.0_2.pdf%3Fversion%3D1%26modificationDate%3D1639417533738%26api%3Dv2&usg=AOvVaw1uVFGFgzXzfkFgyWapXQiF&opi=89978449>,
we can see that the mandatory properties for individuals include family
and first names and date of birth.
About the date of birth, it could be used by some registries to check
whether the registrant is underage.
Of course, I'm talking about properties that could be accessed only to
some users.
But by providing
a default profile, RDAP client implementers need not guess at which
parts of JSContact are needed and which parts are not. While I still
believe SimpleContact is much simpler, this approach would make
JSContact much more well defined when used in RDAP and provide better
guidance to both server and client implementers.
[ML] Agreed about the purpose.
Best,
Mario
-andy
--
Dott. Mario Loffredo
Senior Technologist
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
