IETF Logo Mail Archive

Re: [Taps] On Profiles for TAPS Preconnections

Anna Brunström <anna.brunstrom@kau.se> Tue, 23 July 2019 20:47 UTC

Return-Path: <anna.brunstrom@kau.se>
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 A1495120999 for <taps@ietfa.amsl.com>; Tue, 23 Jul 2019 13:47:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.297
X-Spam-Level:
X-Spam-Status: No, score=-4.297 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kau.se
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 oyiWHfS7Flqz for <taps@ietfa.amsl.com>; Tue, 23 Jul 2019 13:47:13 -0700 (PDT)
Received: from smtp1.kau.se (smtp1.kau.se [130.243.21.250]) by ietfa.amsl.com (Postfix) with ESMTP id 130BF1209B2 for <taps@ietf.org>; Tue, 23 Jul 2019 13:47:13 -0700 (PDT)
Received: from e-mailfilter02.sunet.se (e-mailfilter02.sunet.se [192.36.171.202]) by smtp1.kau.se (Postfix) with ESMTP id 2C90618145AF; Tue, 23 Jul 2019 22:47:12 +0200 (CEST)
Received: from Exch-A3.personal.kau (exch-a3.kau.se [130.243.19.84]) by e-mailfilter02.sunet.se (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id x6NKlAR7143797 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Tue, 23 Jul 2019 22:47:10 +0200
Received: from Exch-A2.personal.kau (130.243.19.83) by Exch-A3.personal.kau (130.243.19.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1591.10; Tue, 23 Jul 2019 22:47:10 +0200
Received: from Exch-A2.personal.kau ([fe80::d09:7e68:ff95:4a60]) by Exch-A2.personal.kau ([fe80::d09:7e68:ff95:4a60%7]) with mapi id 15.01.1591.017; Tue, 23 Jul 2019 22:46:57 +0200
From: Anna Brunström <anna.brunstrom@kau.se>
To: Michael Welzl <michawe@ifi.uio.no>, Max Franke <mfranke@inet.tu-berlin.de>
CC: "Philipp S. Tiesel" <philipp@tiesel.net>, Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>, "taps@ietf.org" <taps@ietf.org>
Thread-Topic: [Taps] On Profiles for TAPS Preconnections
Thread-Index: AQHVQMEKasj+RXnz0kKDEHWACfIXBKbXHl0AgAAFLQCAAPA7gIAAAZ2AgAADJYCAAAcUgIAAjIvw
Date: Tue, 23 Jul 2019 20:46:57 +0000
Message-ID: <8fb41c493c4542bfbaee1f0b230c361c@kau.se>
References: <f71bd460-e0a3-47eb-b384-d3dc9b0f1962@email.android.com> <7DB06BAF-BC10-4367-BD5E-C7EFB698200B@ifi.uio.no>
In-Reply-To: <7DB06BAF-BC10-4367-BD5E-C7EFB698200B@ifi.uio.no>
Accept-Language: en-US, sv-SE
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.243.27.149]
Content-Type: multipart/alternative; boundary="_000_8fb41c493c4542bfbaee1f0b230c361ckause_"
MIME-Version: 1.0
X-Bayes-Prob: 0.9999 (Score 5, tokens from: outbound, outbound-kau-se:default, kau-se:default, base:default, @@RPTN)
X-p0f-Info: os=Windows 7 or 8, link=Ethernet or modem
X-CanIt-Geo: No geolocation information available for fe80::d09:7e68:ff95:4a60
X-CanItPRO-Stream: outbound-kau-se:outbound (inherits from outbound-kau-se:default, kau-se:default, base:default)
X-Canit-Stats-ID: 0a0EkLaaL - 6995646c99b0 - 20190723
X-Antispam-Training-Forget: https://mailfilter.sunet.se/canit/b.php?c=f&i=0a0EkLaaL&m=6995646c99b0&rlm=outbound-kau-se&t=20190723
X-Antispam-Training-Nonspam: https://mailfilter.sunet.se/canit/b.php?c=n&i=0a0EkLaaL&m=6995646c99b0&rlm=outbound-kau-se&t=20190723
X-Antispam-Training-Phish: https://mailfilter.sunet.se/canit/b.php?c=p&i=0a0EkLaaL&m=6995646c99b0&rlm=outbound-kau-se&t=20190723
X-Antispam-Training-Spam: https://mailfilter.sunet.se/canit/b.php?c=s&i=0a0EkLaaL&m=6995646c99b0&rlm=outbound-kau-se&t=20190723
X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=kau.se; h=from:to:cc :subject:date:message-id:references:in-reply-to:content-type :mime-version; s=canit; bh=X8V5KqeuGNvjIMD2B3+dl7ouIDVR7wZBSMGqy VL70oA=; b=ZznIa5BFQbra7K/8os9JKpqyjFShY9FLAIBLAJopo0OvhLGE5Yia+ FvqOGdWZXJohL757n3qvdIQzdZ8sox/4XMYjxIFBUnZx9yv3u4EM9Zj5Nn6wu5/J NU/YidozQUCuousJFw6LotVPyjqkCPO0wfEUylxsW7R+90+gu+At8egSdsZjOx5A r9S6RszCUe1jycZVmptjqPwL5NMbSMZ/dzkLcwrhlmtAf05vd/4Xqnaqc7monmLr baKMkB9TvluLauoqc4woLwiTqz0vBYcGs56TGDKfa882KM5LxnPuTdYvH8eikyR+ 8+XP2fg4PKrEETqGGOJp7cqXghcnkiNOA==
X-Scanned-By: CanIt (www . roaringpenguin . com)
Archived-At: <https://mailarchive.ietf.org/arch/msg/taps/D-3HEW2iy7MUWFpxs1ZIRrMMYd0>
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 20:47:27 -0000


From: Taps <taps-bounces@ietf.org> On Behalf Of Michael Welzl
Sent: den 23 juli 2019 16:17
To: Max Franke <mfranke@inet.tu-berlin.de>
Cc: Philipp S. Tiesel <philipp@tiesel.net>; Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>; taps@ietf.org
Subject: Re: [Taps] On Profiles for TAPS Preconnections




On Jul 23, 2019, at 9:51 AM, Max Franke <mfranke@inet.tu-berlin.de<mailto:mfranke@inet.tu-berlin.de>> 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 agree an appendix can be a good idea. I would still prefer not to define a list of profiles, rather mention the concept of profiles as one of the convenience functions and perhaps give an example.

Anna

Cheers,
Michael

v2.23.0 | Report a Bug | By Email