On Wed, Feb 12, 2025 at 10:12 AM Pawel Kowalik <kowa...@denic.de> wrote: > > 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.
Sorry, I wasn't trying to throw out extraneous observations. I was countering your argument that clients would still need to deal with these extensions. With the exception of "redacted", it does not appear to be an issue. > > 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. Why does requiring a prefix preclude generic use? -andy _______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
