For what it is worth: I think this is an attempt to standardise some
names... and avoid many variants of the same. That may work, or it may
fail horribly. which to me depends on the interests of TAPS developers
in standardising cross-platform support. I think I suggested anyway if
we go this way, that we really need to differentiate IETF-RFC entries
from privately defined ones.
And... I for one think this can wait. I'd rather have a complete
revision to proof read than worry about the registry....
Gorry
On 05/09/2018 16:05, Brian Trammell (IETF) wrote:
Hi, all,
I'd see the contents of the appropriate sections of taps-interface (7.3 and
12.3 in the current editor's copy at
https://taps-api.github.io/drafts/draft-ietf-taps-interface.html) as the
initial contents of these registries, and MTI as per the (normative) RFC
taps-interface will become. Anything else should be added to the registry on
either expert
As to how useful a set of names beyond those in the document will be in terms
of reducing the confusion of users of taps-compliant APIs: eh? I'm not sure.
Metaquestion: is this a question we have to answer before publishing the
current documents, or can we focus on getting them done, then potentially
specify a registry in a future document (incorporating the parameters in the
already-published taps-interface by reference)?
Cheers,
Brian
On 5 Sep 2018, at 16:31, Michael Welzl <[email protected]> wrote:
Hi all,
I like the idea too, but I also wonder: does this give us a risk that the whole
system could become super-flexible, obscure and non-implementable at some point?
But maybe that’s easily solved, by stating that only the transport properties
in RFCs are required to implement, and everything from the registry is optional…
Cheers,
Michael
On Aug 6, 2018, at 11:44 AM, Gorry Fairhurst <[email protected]> wrote:
I quite like the idea of trying to design a simple registry format. If it looks
good, I'd be happy to see this go forward.
Gorry
On 24/07/2018 19:13, Aaron Falk wrote:
Caveat: I am not an expert on registries but my sense is that they are most
useful for interoperability. I think Gorry's concern about redundancy much less
important. And, in fact, it may take a while to figure out how to describe the
parameters. It might be more useful to allow for variety in how these are
defined to permit creative approaches. YMMV of course.
--aaron
On 24 Jul 2018, at 10:06, G Fairhurst wrote:
I don't yet know for sure myself....
On the one hand: I think a registry is a great way to capture the
"bundle" of things that we know about needing to send across the
API. Having common keywords (names) is a way to help people (who
wish to take this approach) from unwantingly choosing the same
function/param with a different name. And avoids accidentally
choosing the same key. I like these advantages. especially if I
thought people would use the registry.
On the other hand, as an author I am still bemused about exactly
which list of items I think /need/ could appear in this registry.
I know some I'd expect, there are some I would not be surprised to
see, and some I'd expect not to see. Also this doesn't stop people
dreaming of slight variants of functions/params because they want
to be different or don't understand/agree with another definition,
especially since the concrete API isn't specified by the IETF.
There are ways we could help support different uses, which I think
we should consider:
* We can define "well-known" IETF keywords that start with a
special prefix that require some IETF practice to assign;
* we can also define "public" keywords that have no prefix and are
first-come-first served, the easy way to get a unique entery.
* We can allow private defintions with some different prefix that
are not specified by IANA. (We simply preclude this format from
the registry).
This approach has been used in many places, a simple, but similar
transport example is the Service Codes registry:
https://www.iana.org/assignments/service-codes/service-codes.xhtml
- Let's all think about whether this is a useful approach for our API?
Gorry
On 23/07/2018, 21:32, David Schinazi wrote:
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]
<mailto:[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
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] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/taps
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
