> On 23. Jul 2019, at 10:17, Michael Welzl <[email protected]> wrote: > > > >> On Jul 23, 2019, at 9:51 AM, Max Franke <[email protected] >> <mailto:[email protected]>> wrote: >> >> >> >> The API prescribed by this document is abstract, and needs to give freedom >> to implementations to make things elegant in their particular languages. >> >> What about having an appending, that's non-normative and not required for >> RFC compliance, that describes suggested conveniences, such as >> "properties.prefer()" and the concept of convenience profiles? >> Yes, I like this idea. I also agree that the API is complex enough as it is >> and requiring convenience features to be RFC compliant is probably not a >> good idea. As long as we are consistent with moving all conveniences to the >> appendix this is my preferred option. > > +1 on this if it’s a workable solution (sounds like it is), and a particular > +1 on the side comment about "consistently moving all conveniences to the > appendix”
I am fine with moving all conveniences to the appendix, but we might still need to reference them in the main text to make sure the API does not look overly inconvenient. I also would like to use the profiles in one of the examples. AVE! Philipp S. Tiesel -- Philipp S. Tiesel https://philipp.tiesel.net/
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
