Re: [Taps] On Profiles for TAPS Preconnections

Max Franke <mfranke@inet.tu-berlin.de> Tue, 23 July 2019 13:51 UTC

Return-Path: <mfranke@inet.tu-berlin.de>
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9E46120116 for <taps@ietfa.amsl.com>; Tue, 23 Jul 2019 06:51:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.477
X-Spam-Level:
X-Spam-Status: No, score=0.477 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.1, MISSING_MIMEOLE=1.899, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iyhP11oF4y63 for <taps@ietfa.amsl.com>; Tue, 23 Jul 2019 06:51:52 -0700 (PDT)
Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [130.149.220.242]) by ietfa.amsl.com (Postfix) with ESMTP id 8976F1202DA for <taps@ietf.org>; Tue, 23 Jul 2019 06:51:52 -0700 (PDT)
Received: from [172.16.150.129] (unknown [207.115.96.130]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTPSA id A1069171B; Tue, 23 Jul 2019 15:51:50 +0200 (CEST)
Date: Tue, 23 Jul 2019 09:51:53 -0400
Message-ID: <f71bd460-e0a3-47eb-b384-d3dc9b0f1962@email.android.com>
X-Android-Message-ID: <f71bd460-e0a3-47eb-b384-d3dc9b0f1962@email.android.com>
In-Reply-To: <857A1326-9DA7-4BE9-A8C3-B12474ABEF76@apple.com>
From: Max Franke <mfranke@inet.tu-berlin.de>
To: Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>
Cc: "Philipp S. Tiesel" <philipp@tiesel.net>, taps WG <taps@ietf.org>
Importance: Normal
X-Priority: 3
X-MSMail-Priority: Normal
MIME-Version: 1.0
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/taps/EOYScn-6tbqHZEUoE2K-98_wzQA>
Subject: Re: [Taps] On Profiles for TAPS Preconnections
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IETF Transport Services \(TAPS\) Working Group" <taps.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/taps>, <mailto:taps-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/taps/>
List-Post: <mailto:taps@ietf.org>
List-Help: <mailto:taps-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/taps>, <mailto:taps-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Jul 2019 13:52:05 -0000



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.

Best
Max