Hi, First, thanks for the work already put into this document, but i have to say that i’m not a big fan of forbidding bare extension identifiers and mandating prefixes.
Using prefixes to create namespaces for new attributes (JSON/URL/Headers) has limited additional value when: new attributes for standard track extensions are managed through a controlled process (e.g., the IETF working group process). That process can already ensures uniqueness and clarity, making namespaces redundant. Private (non-IETF) extension attributes are unconstrained, anyone can add them, using an uncoordinated process, with no central registry or enforcement. This means the risk of collisions is not removed by having mandatory prefixes for standard track extensions. Instead of using namespaces, an alternative approach may be to define separate extension profiles, where each extension: - Is clearly identified (e.g. via a profile URI or versioned identifier). - Define its own schema with new attributes added to the core protocol. A good example of a protocol alreading using a flat namespace is JSON Web Signature (JWS) RFC7515. JWS uses a flat namespace for attributes, all fields in a header or payload exist without prefixes. To avoid collisions, extensions must either: - Be registered (e.g. via IANA), or - Be documented in a profile, and - If critical to interpretation, be listed in the "crit" header array. Extensions can add new attributes, i think the most used extension for JWS is JSON Web Token (JWT, RFC 7519). JWT can be regarded as a profile of JWS that standardizes a set of claim names (iss, sub, exp, etc.) So this might be another alternative method for the currently already identified schemes in sections 2.3. "Bare Extension Identifiers” Best, Maarten _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
