We had a similar discussion in the Babel WG regarding link types in our data model - which isn't sent over the wire. We landed on having an IANA registry of strings so there is one place to find the mapping from string to specification. We're planning on reserving all strings starting with an underscore "_" for experimental use so the registry does not get in anyone's way. Apparently IANA registries have very low overhead. Hope this helps.
David > On Jul 23, 2018, at 13:15, Tommy Pauly <[email protected]> wrote: > > Hello TAPS, > > Migrating a thread from GitHub to the email list, since it needs broad WG > input. I've pasted the discussion so far below. > > Essentially, the question is if we have a set of standard properties for > Transport Services APIs, should they have a formal registry or not? > > Thanks, > Tommy > > ====================================== > > https://github.com/taps-api/drafts/issues/210 > <https://github.com/taps-api/drafts/issues/210> > > Philipp: > > We will end up with a set Turns out we might need a lot of (protocol) > specific properties, we should discuss whether we need an IANA registry of > properties and how this will look like. > • Include Types ? > • Include Names ? > • Some numeric representation ? > What do we do with ENUM values? > > Mirja: > I don't really understand why we would need a registry. Who would be using > the registry? > > Tommy: > I agree that a registry seems unnecessary; this is not a matter of protocol > or on-the-wire standard. > > Philipp: > If we don't want to clutter the basic API document, we will end up having at > least a half a dozen documents defining specific properties for different > protocols. > Does anyone have a good alternative to collect all these except in an IANA > registry? > > Tommy: > We do not need to have documents specify every property. Implementation > should be allowed to extend as they need. > > Brian: > this discussion does suggest that we might want to be more explicit up front > in the interface document about the scope and purpose of the document (i.e. > this is meant primarily to define a standard API "shape", not the particular > strings and codepoints, etc.). I'll file an issue. > > Colin: > I agree with @tfpauly that we don't need to document every property, and with > @britram that we're documenting the shape of an abstract API, but I also see > value in consistent property naming across concrete implementations of that > API. Some form of registry might make sense here. > _______________________________________________ > Taps mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/taps
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
