Hi Andrew, On 12.02.25 15:09, Andrew Newton (andy) wrote:
On Wed, Feb 12, 2025 at 1:42 AM Pawel Kowalik<kowa...@denic.de> wrote:[PK] I am typically of an opinion that simple is better than complicated.In this case however I have my concerns that even though new rules would be defined the specifications not following them would be hard to weed out making it of no value for the clients because they would have to deal with the "legacy" extensions forever.As far as I know, most of these legacy extensions are not implemented anywhere. In fact, "redacted" is the only one I have ever seen in the wild, and it has other very big problems wrt interoperability.
Is it a fact or an opinion? I think talking about some extensions "legacy" implies there is an intention to replace them with something else.
So when it comes to rules around JSON names, query parameters, query paths, and object class names, I think it is better to say it will always be "extid_camelCaseName". As for the existing extensions that are now RFCs or passed WGLC, we just note that they don't follow the rules but we are exempting them but they will no longer be allowed. [PK] Your example forcing everything to be extid_camelCaseName seems to assume that bare identifiers won't be allowed anymore - even if the identifiers would be registered.Correct.I think this approach drifts away from the original concept of dealing with potential conflicts through registration of identifiers and going into the direction of hardcore prefix/namespacing, which is in fact a very unnatural concept to JSON representations and http based protocols, at least in the area of query parameters or URL path segments."unnatural" is subjective. Interoperability less so.
[PK] Unnatural I mean that RFC8259 does not foresee a notion of namespaces. Interoperability can be achieved by different ways and in my eyes bare identifiers, if registered, do not prevent
interoperability in any way.Registering full (bare) names is as good for interoperability as registering prefixes.
I think we don't have enough or real technical reason to change the existing protocol to that extent. In doing this, I think we can simplify the document. [PK] Yes, the document may be simpler but not necessarily the protocol.Things get much more difficult if namespace collisions occur, which is the point of the simplification.
What is the risk of collision if there is registration of the identifier in place and right rules to prevent registering colliding names?
My general point is that in the discussion we tend to treat extension as second class citizens of RDAP ecosystems, not looking at the perspective of maybe in 10 years these extensions becoming so popular that one would want to include them into core standard. But nobody sane would do that, because of the popularity of the extension it would be very hard/not wanted to redefine identifiers, so it would stay as second class citizen forever.
Allowing bare identifiers still leave the choice open for extensions which have a potential of generic use.
Kind Regards, Pawel
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
