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
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
