hi Philipp, Thanks for pulling this together. I've finally had time to look at it.
> On 1 Feb 2019, at 16:49, Philipp S. Tiesel <[email protected]> wrote: > > Hi, > > during the January interim, we had some discussions regarding whether we want > to standardise strings for representing Transport Property Names and whether > we may need an IANA registry to keep track of these when new ones get added. > > > TL;DR > ===== > In the interim, we roughly agreed that we need to add names for the Transport > Properties to the API draft. Also, we agreed that these property names can > be prefixed with a namespace to separate standard generic properties from > protocol, > implementation, or vendor specific properties. > > Before writing text for that, I volunteered to bring the conclusion from the > interim to the mailing list and ask for feedback. > > > The bloody details > ================== > > Transport Property Names > ------------------------ > > Standardised Transport Property Names solve two purposes: > - Allow different components of a TAPS implementation to pass Transport > Properties, e.g., between a language frontend and a policy manager > - Make code of different TAPS implementations look similar / familiar > > My straw-man proposal to use camelCased strings got a lot criticism as it > discriminates non-camelCased languages. It seems that we need a canonical > string format that can be used across components of a TAPS system and can > be easily translated into strings, symbolic constants or static objects that > match the individual style of the programming APIs. > > As a first proposal, I favour lower-case strings with underscores as word > separators. This seems reasonable to me. Alternately we could party like it's 1982 and we can't afford an 80-column card and do UNDERSCORE_SEPARATED_UPPERCASE like the TCP RFCs do. (That's not a serious suggestion, but I note that it does make it very easy to see where the property names are when scanning the document, as long as we don't name a property RECOMMENDED.) > Namespaces > ---------- > > Besides the categorisation into Selection, Connection, and Message Properties, > we also have different kinds of Transport Properties: > - Generic Properties (most properties in the API draft fall in this case) > - Protocol Specific Properties (e.g., properties to control certain TCP > timers) > - Vendor or Implementation Specific Properties > > To allow a TAPS system to be extendable, we want to separate these out by > adding a namespace prefix to the Transport Properties. So the namespace question only really becomes interesting if we presume we want to have a registry with other than Standards Action policy. But if we presume that... Bikeshed question number 1: do we want to separate namespace prefixes with underscores as with spaces, or with some other character? i.e. to use a tortured example would it be something like tcp.retransmission_timeout or tcp_retransmission_timeout? (I'm borrowing from sysctl namespaces a little here) > As a first proposal, I favour the following > - Generic properties from the API draft or defined by an RFC carry no > namespace prefix. This makes sense. > - Protocol Specific Properties must carry the protocol acronym as > prefix, e.g., “tcp" for TCP specific Transport Properties. > For IETF protocols, property names unter these namespaces should > be defined in an RFC. This also makes sense. > - Vendors or implementation specific properties must prefix with the > vendor or implementation’s name. Bikeshed question number 2: you probably need a registry of vendor namespaces. what's the policy on creating those? Do we really want to create another PEN-like thing? > - Experimental or local-use properties must be Prefixed with an X or Y. I don't like this. MIME headers used to use the X- prefix, but this has been deprecated because the presumptive semantic benefit of this -- you can see which bits are experimental -- disappears because nobody ever replaces experimental identifiers when experiments transition to production. > Open Questions: > --------------- > > - Do we need an IANA registry for Generic Properties? That depends on what we think the extension mechanism for the TAPS API is. I tend to think no: new extensions to the API will require a standards action, and probably even need to update the core TAPS API docs. > - Do we need an IANA registry for Property Namespaces? Maybe? > - Do we need to request an IANA registry with the API document > or may we postpone the above decisions? I'm inclined to assign names (with generic and protocol-specific namespaces) and leave the whole vendor/registry thing as future work, because defining a registry well is hard, and I'm not sure such a thing will ever be used. It's a lot to do up front. > - Where do we want to define the rules for naming Transport Properties and > Namespaces? Consistent with my opinion above: name the transport namespaces in this doc, leave all other rules as future work. Cheers, Brian > > AVE! > Philipp S. Tiesel / phils… > -- > {phils}--->---([email protected])--->---(http://phils.in-panik.de)----, > wenn w eine aube ist dn man au dran dre en | > o Schr an muss hc h (Kurt Schwitters) | > :wq! <----(phone: +49-179-6737439)---<---(jabber: [email protected])----' > > _______________________________________________ > Taps mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/taps _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
