[http-state] Question regarding RFC 6265 and ietf process

Fagner Martins <eu@fagnermartins.com> Tue, 01 September 2015 15:16 UTC

Return-Path: <admin@fagnermartins.com>
X-Original-To: http-state@ietfa.amsl.com
Delivered-To: http-state@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 6407A1B5CE7 for <http-state@ietfa.amsl.com>; Tue, 1 Sep 2015 08:16:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.723
X-Spam-Status: No, score=0.723 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id v5bJA4Xk8i0P for <http-state@ietfa.amsl.com>; Tue, 1 Sep 2015 08:16:57 -0700 (PDT)
Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FBD11B4475 for <http-state@ietf.org>; Tue, 1 Sep 2015 08:16:56 -0700 (PDT)
Received: by wicge5 with SMTP id ge5so11024706wic.0 for <http-state@ietf.org>; Tue, 01 Sep 2015 08:16:54 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:date:message-id:subject:from :to:content-type; bh=0IbZtR3EjcgTBe3c+RKa18vO0wNww1WuMVxeWwcjAuc=; b=iCCse5vqMWAjamjeMyfcqaPTWCMMp7Kw42edZliiYSf7q+yQIe2HumbTbgY6x44xYS TKEoLMetWuQlSUNUuZ4yyrHyHIeukqUiZgPgIOHwIjK7rovw+KS/CnA2ee/vHxM70Eyb CeHVzbUE77Sbjq1+DIR2x27JOVbjmVuSPhSsnLmLPlifR3GFf65e+3j01TqttmCbPWiY pC4cOgjTGc8CBY222TMoEaSYexdUcYzERq32qrxVM413H79zkYI191UYlK4UA3a3ycsM RmGicn9Bv3lID/4LJVio+ZUjgwM/GzyLSMdJu2vD7kb6lTIqIaquGqPDKoUur8gw1w+p ia0Q==
X-Gm-Message-State: ALoCoQkwkOtLovP8o3eCxUr2G1dwowa8r2WpOXka4xiXFnr3Z/ZTOA9MnDgBd2lGLQd8oN7jyYGk
MIME-Version: 1.0
X-Received: by with SMTP id au1mr36700186wjc.115.1441120614559; Tue, 01 Sep 2015 08:16:54 -0700 (PDT)
Sender: admin@fagnermartins.com
Received: by with HTTP; Tue, 1 Sep 2015 08:16:54 -0700 (PDT)
X-Originating-IP: []
Date: Tue, 1 Sep 2015 12:16:54 -0300
X-Google-Sender-Auth: Bgmqx0328r1HBAhhkF7C1ZlHk9o
Message-ID: <CAK5xtXOF0FG1roQNfzEUtj9x2aNhfG3_O7Sxk_4mGqU1rfD_Mg@mail.gmail.com>
From: Fagner Martins <eu@fagnermartins.com>
To: http-state@ietf.org
Content-Type: multipart/alternative; boundary=089e0122f1a04f4c88051eb10a3e
Archived-At: <http://mailarchive.ietf.org/arch/msg/http-state/ciEe4Dt3UxAybPGUQvtWle3lkBw>
X-Mailman-Approved-At: Sat, 05 Sep 2015 16:06:44 -0700
Subject: [http-state] Question regarding RFC 6265 and ietf process
X-BeenThere: http-state@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discuss HTTP State Management Mechanism <http-state.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/http-state>, <mailto:http-state-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/http-state/>
List-Post: <mailto:http-state@ietf.org>
List-Help: <mailto:http-state-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/http-state>, <mailto:http-state-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Sep 2015 15:18:20 -0000


Sorry to bother but I really have no idea who to ask about this and I hope
I came to the correct mailing list.

A few weeks ago I did implemented a JavaScript library to handle
client-side cookies using the RFC 6265 as a baseline to percent-encode only
the cookie characters that are not allowed in the RFC, see

The thing is that recently we found out that some frameworks and
server-side programming languages, for historical reasons, do not accept a
character that the RFC allows. Here an example of the "+" octet:

Unfortunately those languages and frameworks cannot change the way they
handle cookies because in most of them the default cookie mechanism is
built-in very hard into the internals of the language/framework, and even
if they could, it would take time for the implementation reach to the
developers hand.

I am not a veteran on the internet, so I am not aware of how the process
works. But would it make sense to amend the RFC to account for characters
allowed in the browsers but realistically disallowed by most frameworks due
to historical reasons?

It would be very useful to make the RFC a documentation to serve as a
baseline for how the web *and the server-side languages *that are built on
it actually work instead of restricting only to how browsers work in the

Does it makes sense?

Fagner Martins Brack