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. 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. 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 Again, others would be able to provide profiles that do more such as offering cryptocurrency wallets and avatars, etc.... 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. -andy _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
