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 <mich...@ifi.uio.no> 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 <go...@erg.abdn.ac.uk> 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 <tpa...@apple.com >>> <mailto:tpa...@apple.com>> 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 >>> Taps@ietf.org <mailto:Taps@ietf.org> >>> https://www.ietf.org/mailman/listinfo/taps >>> >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >>> >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >>> >> >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
