Re: [TLS] WGLC comments on draft-ietf-tls-applayerprotoneg-01

Andrei Popov <> Mon, 19 August 2013 23:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 79F6E11E818D for <>; Mon, 19 Aug 2013 16:18:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.599
X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fl9JNifLehhq for <>; Mon, 19 Aug 2013 16:18:12 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2CD4B11E8172 for <>; Mon, 19 Aug 2013 16:18:11 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.745.25; Mon, 19 Aug 2013 23:18:10 +0000
Received: from ([]) by ([]) with mapi id 15.00.0745.000; Mon, 19 Aug 2013 23:18:09 +0000
From: Andrei Popov <>
To: Martin Thomson <>, "" <>
Thread-Topic: [TLS] WGLC comments on draft-ietf-tls-applayerprotoneg-01
Thread-Index: AQHOnQaaN1TNnQyJLEe2jldO/oM6xJmdHa2A
Date: Mon, 19 Aug 2013 23:18:09 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: [2001:4898:80e0:ed43::4]
x-forefront-prvs: 09435FCA72
x-forefront-antispam-report: SFV:NSPM; SFS:(13464003)(199002)(189002)(377454003)(164054003)(51856001)(65816001)(59766001)(80022001)(74366001)(46102001)(77982001)(47976001)(19580405001)(19580385001)(83322001)(76796001)(33646001)(19580395003)(81816001)(81686001)(76786001)(76576001)(63696002)(83072001)(49866001)(53806001)(79102001)(74316001)(31966008)(81542001)(4396001)(69226001)(74876001)(56776001)(54356001)(47736001)(56816003)(80976001)(74706001)(50986001)(47446002)(54316002)(77096001)(76482001)(74502001)(74662001)(81342001)(24736002)(3826001); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR03MB195;; CLIP:2001:4898:80e0:ed43::4; RD:InfoNoRecords; A:1; MX:1; LANG:en;
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossPremises-AuthAs: Internal
X-MS-Exchange-CrossPremises-AuthMechanism: 03
X-MS-Exchange-CrossPremises-SCL: 1
X-MS-Exchange-CrossPremises-messagesource: StoreDriver
X-MS-Exchange-CrossPremises-originalclientipaddress: 2001:4898:80e0:ed43::4
X-MS-Exchange-CrossPremises-avstamp-service: 1.0
X-MS-Exchange-CrossPremises-antispam-scancontext: DIR:Originating; SFV:NSPM; SKIP:0;
X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent
X-MS-Exchange-CrossPremises-ContentConversionOptions: False; 00160000; True; ; iso-8859-1
Subject: Re: [TLS] WGLC comments on draft-ietf-tls-applayerprotoneg-01
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 19 Aug 2013 23:18:16 -0000

1. If the HTTP WG has reservations about registering an HTTP/2.0 protocol ID at this time, perhaps we should remove it from the draft. New protocol ID registrations will need to be added in the future, and HTTP/2.0 could be among them.

2. ALPN defines protocol IDs as opaque byte strings, although the currently proposed protocol IDs consist of printable characters, for easy debugging, etc. ALPN protocol IDs are not meant to be displayed to the end user. I would prefer to keep the HTTP/1.1 protocol ID registration in the draft because it makes ALPN immediately useable for negotiating HTTP and SPDY connections.

3. The experimental namespace was requested by several TLS WG participants; it would be great if they could share their opinions of RFC 6648 section 3 "Recommendations for Creators of New Parameters".



-----Original Message-----
From: [] On Behalf Of Martin Thomson
Sent: Monday, August 19, 2013 11:04 AM
Subject: [TLS] WGLC comments on draft-ietf-tls-applayerprotoneg-01

I have read the draft and think that it is largely ready for publication, though there are a few minor issues that should be resolved regarding application strings.

(I sent some of these comments to the authors privately.)

Can I request that when you create the registry in ALPN that you do not register HTTP/2.0?  More likely than not, ALPN will precede
HTTP/2.0 and I want to avoid having a dependency issue, particularly if we find that we need to change the string for some reason.

I'm also a little concerned about the existence of a registration for HTTP/1.1, particularly when that registration differs from the string used in the protocol itself (even if only in letter case).  Have the authors consulted the HTTPbis working group about these registrations?

The other issue is the definition of the 'exp' prefix.  RFC 6648 advises against defining such constructs.  I would prefer if this prefix were not defined.
TLS mailing list