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. > > 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. > > 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. -andy _______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
