Hi Andy, On 05.02.25 21:41, Andrew Newton (andy) wrote:
Hi all,We, the author team, have posted a new version of this draft. This reflects 22 closed issues from the tracker, and these are noted in the draft text with an aside. All that said, I think our efforts to do carve-outs based on existing extensions creates a somewhat complex set of rules for extensions. In the end, I think these will end up causing interoperability issues. I'd rather have consistency for the sake of interoperability even at the expense of ruling out otherwise nifty little "short-cuts".
[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 outmaking it of no value for the clients because they would have to deal with the "legacy" extensions forever.
[PK] Your example forcing everything to be extid_camelCaseName seems to assumeSo 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.
that bare identifiers won't be allowed anymore - even if the identifiers would be registered.
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.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. 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
