[Taps] I-D Action: draft-ietf-taps-minset-08.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Services WG of the IETF.

Title   : A Minimal Set of Transport Services for End Systems
Authors : Michael Welzl
  Stein Gjessing
Filename: draft-ietf-taps-minset-08.txt
Pages   : 47
Date: 2018-09-05

Abstract:
   This draft recommends a minimal set of Transport Services offered by
   end systems, and gives guidance on choosing among the available
   mechanisms and protocols.  It is based on the set of transport
   features in RFC 8303.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-taps-minset/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-taps-minset-08
https://datatracker.ietf.org/doc/html/draft-ietf-taps-minset-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-minset-08


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] Genart last call review of draft-ietf-taps-minset-06

[Michael Welzl]

Hi,


> On Sep 4, 2018, at 7:57 PM, Robert Sparks  wrote:
> 
> 
> 
> On 9/1/18 10:43 PM, Spencer Dawkins at IETF wrote:
>> Hi, Michael,
>> 
>> On Fri, Aug 31, 2018, 15:35 Michael Welzl > > wrote:
>> Hi Spencer,
>> 
>> See below:
>> 
>>> On Aug 31, 2018, at 7:41 PM, Spencer Dawkins at IETF 
>>> mailto:spencerdawkins.i...@gmail.com>> 
>>> wrote:
>>> 
>>> Thanks, Robert, for the careful read, and thanks, Michael, for the quick 
>>> response. I have one thought, on Robert's last question.
>>> 
>>> On Fri, Aug 31, 2018 at 3:37 AM Michael Welzl >> > wrote:
>>> Hi,
>>> 
>>> Thank you very much for this careful review!  We just posted a revision ( 
>>> -07 ) that, we believe, addresses these comments.
>>> 
>>> A few answers in line below:
>>> 
>>> > On 28 Aug 2018, at 23:38, Robert Sparks >> > > wrote:
>>> > 
>>> > Reviewer: Robert Sparks
>>> > Review result: Ready with Nits
>>> 
>>> ...
>>>  
>>> > In Appendix A.1, this document had to "slightly change" the
>>> > characterization of features  from those in RFC8303, introducing this
>>> > "ADDED" construct. That feels out of balance. Is this a warning sign
>>> > that RFC8303 needs adjusting?
>>> 
>>> It isn't: different from this document, RFC 8303 does not make any changes 
>>> or derive anything from the services that protocols offer - it just 
>>> reflects what the protocol specifications say.
>>> 
>>> In the minset document, there are only 3 items using the "ADDED" construct, 
>>> and this is only meant to streamline the derivation a little. Take 
>>> "Unreliably transfer a message", for example.
>>> This is based on (from RFC 8303) "Unreliably transfer a message, with 
>>> congestion control" for SCTP, and "Unreliably transfer a message, without 
>>> congestion control" for UDP(-Lite). The added "Unreliably transfer a 
>>> message" leaves the choice of congestion control open, such that an 
>>> application CAN simply say "Unreliably transfer a message" without having 
>>> to care about the choice of congestion control (unless it wants to care, 
>>> which comes at the cost of binding itself to either UDP(-Lite) or SCTP).
>>> 
>>> Michael, this explanation helps a lot, but since I happen to know that 
>>> Robert is out of town for the three-day weekend in the US, I'll guess on 
>>> his behalf that "ADDED" may not be the word you're looking for - at a 
>>> minimum, "transfer unreliably" in RFC 8303 being divided into "transfer 
>>> unreliably with congestion control" and "transfer unreliably without 
>>> congestion control" in this draft doesn't look like addition to me. 
>>> 
>>> Is this more about "refactoring the protocol-independent definition in RFC 
>>> 8303”? 
>> 
>> Yes, “refactoring” is exactly right - it’s not adding anything new. We could 
>> just as well have left this without the “ADDED” cases and then had more 
>> explanations in the “discussions” section (appendix A.3), but these are so 
>> minor that they don’t really merit a “discussion”, hence we felt that this 
>> way it’s shorter and clearer.
>> 
>> If that helps, I can rename “ADDED” into “REFACTORED”?
> With that explanation, the single word without the explanation above feels 
> like insider knowledge.
> Maybe adding a sentence explaining exactly what you say above at the point 
> you introduce the term would be enough, then the term-name itself wouldn't 
> matter as much.

Agreed - done (I just submitted an update to -08), thanks!  I kept “ADDED”, but 
explain it where the term is introduced.

Cheers,
Michael

___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

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

[Michael Welzl]

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

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

[Tommy Pauly]

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

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

[Brian Trammell (IETF)]

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

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

[Gorry Fairhurst]

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

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

[Aaron Falk]

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