I would volunteer to bring this discussion on the floor in Bangkok, but will only remotely participate in this meeting. Also, I have no experience with setting up an IANA registry.
My anticipated strategy for the registry issue is the following: - Use the planned restructuring of the Transport Properties to make Section 12.3 a collection of all properties. - (re)shape this collection in a way it could be dumped in a registry - get someone to review whether this will be accepted as a registry - delay the actual decision unit we see WG last call approaching > On 5. Sep 2018, at 23:19, Aaron Falk <[email protected]> wrote: > > I worry that a registry will somewhat heavyweight with unclear benefits. I'm > in favor of punting on this topic for the moment. Does anyone feel > sufficiently passionate about this topic to lead a discussion in Bangkok? I'd > prefer not to use interim meeting time and focus on the docs. > > --aaron > > On 5 Sep 2018, at 11:15, Gorry Fairhurst wrote: > > 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 > <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 > <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] <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 > <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] <mailto:[email protected]>> > https://www.ietf.org/mailman/listinfo/taps > <https://www.ietf.org/mailman/listinfo/taps> > > _______________________________________________ > Taps mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/taps > <https://www.ietf.org/mailman/listinfo/taps> > > _______________________________________________ > Taps mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/taps > <https://www.ietf.org/mailman/listinfo/taps> > _______________________________________________ > Taps mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/taps > <https://www.ietf.org/mailman/listinfo/taps> > _______________________________________________ > Taps mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/taps > <https://www.ietf.org/mailman/listinfo/taps>_______________________________________________ > Taps mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/taps 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
