Hi Andy, On 10.01.25 17:26, Andrew Newton (andy) wrote:
2. what about a general purpose extension which won't get defined by IETF and would like to approach it later?What about them? Is there something so onerous in this requirement that they must break the rules?
[PK] Nothing, just lifecycle issue. I'm not happy with saying: you can do something if you startwork on your extension within IETF, but you can't if you start elsewhere and then go standardising it.
[PK] And this is a scenario which is not welcoming people to come to IETF for this to happen.[JS] If so, it would at that time be considered from an IETF extension angle and would most likely get a new extension identifier which may or may not be used for prefixing.
3. would it not be just enough to have a proper review on IANA level when identifiers are being registered to assure no general terms are being overloaded by a specific extension or no conflicts between the extensions?It would not be enough, because that supposes the IANA or the DEs need to deconflict every JSON name etc.. and that would lead to mistakes.
[PK] I don't consider this a big issue. JSON Web Token Claims registry works like this in a way more heterogeneous environment.
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
