Subject: Re: [Taps] To registry, or not to registry?

From: Michael Welzl <[email-masked]>
Date: Wed, 5 Sep 2018 16:31:33 +0200

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-masked]> 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-masked]
>>            <mailto:[email-masked]>> 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-masked] <mailto:[email-masked]>
>>            https://www.ietf.org/mailman/listinfo/taps
>> 
>>        _______________________________________________
>>        Taps mailing list
>>        [email-masked]
>>        https://www.ietf.org/mailman/listinfo/taps
>> 
>>    _______________________________________________
>>    Taps mailing list
>>    [email-masked]
>>    https://www.ietf.org/mailman/listinfo/taps
>> 
> 
> _______________________________________________
> Taps mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/taps

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 05 Sep 2018 07:45:50 -0700

That's a good point—if a registry were to be complete to include what all various implementations and transport protocols supported, the list (I imagine) would be quite long and include many fairly obscure and optional extensions. From an application developer's point of view, just because something is defined in the registry, I'm not guaranteed that it will be available on the platform or TAPS implementation that I'm writing my code against.

One question is: who is the audience of this registry, and what value does it provide them? Is the application developer using TAPS (and if so, why don't they just look in the TAPS library headers)? Is it the implementor of the TAPS system (at which point we need to know what is required and optional)? Or is it someone else entirely?

Thanks,
Tommy 

> On Sep 5, 2018, at 7:31 AM, Michael Welzl <[email-masked]> wrote:
> 
> Hi all,
>

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Wed, 5 Sep 2018 17:05:44 +0200

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-masked]> wrote:
> 
> Hi all,
>

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 5 Sep 2018 16:15:29 +0100

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

---

From: "Aaron Falk" <[email-masked]>
Date: Wed, 05 Sep 2018 17:19:04 -0400

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:

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

---

From: "Philipp S. Tiesel" <[email-masked]>
Date: Thu, 6 Sep 2018 21:37:16 +0200

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-masked]> 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
> 
> 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
> 
> 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
> 
> https://www.iana.org/assignments/service-codes/service-codes.xhtml <https://www.iana.org/assignments/service-codes/service-codes.xhtml>
> 
> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
> 
> Hello TAPS,
> 
> https://github.com/taps-api/drafts/issues/210 <https://github.com/taps-api/drafts/issues/210>
> 
> Philipp:
> 
> [email-masked] <mailto:[email-masked] <mailto:[email-masked]>>
> https://www.ietf.org/mailman/listinfo/taps <https://www.ietf.org/mailman/listinfo/taps>
> 
> https://www.ietf.org/mailman/listinfo/taps <https://www.ietf.org/mailman/listinfo/taps>
> 
> https://www.ietf.org/mailman/listinfo/taps <https://www.ietf.org/mailman/listinfo/taps>
> https://www.ietf.org/mailman/listinfo/taps <https://www.ietf.org/mailman/listinfo/taps>
> https://www.ietf.org/mailman/listinfo/taps <https://www.ietf.org/mailman/listinfo/taps>_______________________________________________
> Taps mailing list
> [email-masked]

AVE!
  Philipp S. Tiesel / phils…
-- 
   {phils}--->---([email-masked])--->---(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-masked])----'