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.
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.
As a first proposal, I favour the following
- Generic properties from the API draft or defined by an RFC carry no
namespace prefix.
- 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.
- Vendors or implementation specific properties must prefix with the
vendor or implementation’s name.
- Experimental or local-use properties must be Prefixed with an X or Y.
Open Questions:
---------------
- Do we need an IANA registry for Generic Properties?
- Do we need an IANA registry for Property Namespaces?
- Do we need to request an IANA registry with the API document
or may we postpone the above decisions?
- Where do we want to define the rules for naming Transport Properties and
Namespaces?
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])----'
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
