Re: Informal Last Call for draft-reschke-basicauth-enc-04, was: Fwd: I-D Action: draft-reschke-basicauth-enc-04.txt

Bjoern Hoehrmann <> Mon, 30 January 2012 11:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F007821F86B3 for <>; Mon, 30 Jan 2012 03:18:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.21
X-Spam-Status: No, score=-7.21 tagged_above=-999 required=5 tests=[AWL=3.389, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 05IAnAsHL20b for <>; Mon, 30 Jan 2012 03:18:40 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id B64B421F86B2 for <>; Mon, 30 Jan 2012 03:18:40 -0800 (PST)
Received: from lists by with local (Exim 4.69) (envelope-from <>) id 1RrpF6-0003Wo-04 for; Mon, 30 Jan 2012 11:17:48 +0000
Received: from ([]) by with esmtp (Exim 4.69) (envelope-from <>) id 1RrpEr-0003Uw-OF for; Mon, 30 Jan 2012 11:17:33 +0000
Received: from ([]) by with smtp (Exim 4.72) (envelope-from <>) id 1RrpEi-0003cn-UW for; Mon, 30 Jan 2012 11:17:29 +0000
Received: (qmail invoked by alias); 30 Jan 2012 11:16:58 -0000
Received: from (EHLO HIVE) [] by (mp037) with SMTP; 30 Jan 2012 12:16:58 +0100
X-Authenticated: #723575
X-Provags-ID: V01U2FsdGVkX1/qqD97kcnqgOhOD3W2EcIhZdlmhPk2WDnvlubNL1 zMoHk1/7iXPAs5
From: Bjoern Hoehrmann <>
To: Julian Reschke <>
Cc: HTTP Working Group <>
Date: Mon, 30 Jan 2012 12:17:18 +0100
Message-ID: <>
References: <> <>
In-Reply-To: <>
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-1.9
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01
X-W3C-Scan-Sig: 1RrpEi-0003cn-UW 97bceabe768ebfb33a78e57a9d2ad5fd
Subject: Re: Informal Last Call for draft-reschke-basicauth-enc-04, was: Fwd: I-D Action: draft-reschke-basicauth-enc-04.txt
Archived-At: <>
X-Mailing-List: <> archive/latest/12258
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>
Resent-Message-Id: <>
Resent-Date: Mon, 30 Jan 2012 11:17:48 +0000

* Julian Reschke wrote:

Well, "There is little interoperability for characters in the ISO-8859-1
character set" the US-ASCII subset works reasonably well.

Don't repeat so much of / so literally the Abstract in the Introduction,
it's confusing to read the duplicate.

I think you should mention "WWW-Authenticate" earlier than section 4,
(something like "for use in headers like WWW-Authenticate" somewhere),
otherwise it's easy to expect this is for `Authorization` (in part due
to the name, `useUTF8` or `use-utf-8="yes" or some such would have been

"For credentials sent by the user agent, the "encoding" parameter is
reserved for future use and MUST NOT be sent." You can only reserve
among options, and RFC 2617 does not allow `encoding` in credentials.
This should simply say it does not apply to credentials.

The following "The reason for this is" paragraph is confused, it should
probably be an editor's note to be removed later, otherwise you would
have to be much clearer what your idea for the parameter's content is,
the main use case would seem to be recognizing whether the client did
understand the request to use UTF-8, and that would seem useful enough.

>With respect to intended status: in theory, this is a candidate for 
>Experimental. However, Basic Authentication (as defined in RFC 2617) 
>doesn't have a registry for extension parameters, so the cleanest 
>approach appears to say "Updates 2617", which IMHO requires a standards 
>track document.

Updates 2617 sounds good to me; if there is any problem with that, we
could make two specifications, one that updates 2617 and establishes a
registry and then have your extension as experimental document.
Björn Höhrmann · ·
Am Badedeich 7 · Telefon: +49(0)160/4415681 ·
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 ·