Re: [http-auth] WGLC on the MutualAuth drafts

Julian Reschke <> Thu, 07 July 2016 13:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 19EEA12D0CF for <>; Thu, 7 Jul 2016 06:47:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Zcc8re2tP17l for <>; Thu, 7 Jul 2016 06:47:26 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0B24312B005 for <>; Thu, 7 Jul 2016 06:47:25 -0700 (PDT)
Received: from [] ([]) by (mrgmx103) with ESMTPSA (Nemesis) id 0LxPgU-1bMssn3PuU-016xqT; Thu, 07 Jul 2016 15:47:19 +0200
To: 大岩寛 <>, Yoav Nir <>, httpauth mailing list <>
References: <> <> <> <> <>
From: Julian Reschke <>
Message-ID: <>
Date: Thu, 07 Jul 2016 15:47:27 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="iso-2022-jp"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:DUkORn9H4gQg/IBF4GToNi1ek1imttIQmYTRMQVJAqPbXhjRthl aXUsssalZ+KsIIZDsrDIZg5++dh2Ri0a+pknvH45TYRLvcwauWeT/FDc5Cz0oHV00NNkXT1 B3MQDt0Ld+Qt/XcFGv6T6S1nfGydcSof9YugS3LLoJTB8SHcyB+3wcqWXWVpbQ1elx6Xkr4 3V7O2zf6rn4C0TD0+iJOA==
X-UI-Out-Filterresults: notjunk:1;V01:K0:9ZmGD7za3gs=:UbDGqs5GCyJdRafFIFSBGi ZGVy9+i5JouBgtUw9eb/v2KBxh+Ikeicz+YmIr92fU3R3CyYmQNkkEmEGLGVdn08wt45qbuyV mwexVsc2iN516g2CFt+GQ3Eu92wb0suyU8UV8tWNmvMHbRABRbYd69BTsIJhXtE51fd4M5Rao EHcMKyQAEUNqGJnNU7clbUFFbSVNNBTXtIATQDvJJXZih6kuLwBnI1wHUVofF4aj912HepG8X KSWFNACU0nHyOOpCZ4MGAFq8AEqr7Bz1DjzwDNvSLn+2RPZLTSu715AtmzcY/bLOojTz5fU8m 3tsCWqKVHh/5M9m7IA39LJE21PZQRWlinE6DfuLlj+LhlyS0v0WRNkwyf2CsX47SclXsprgxT E5xLSrge6sAXRX27Kqy29V4HA12naYJw0+UQAIY1cxQfb63y7GcaOmfLVMFWEZAyZZg4V+ltY w8zVRjYNgXQy6VM7ePTyhOGj1x7fa2i0e1oqhmYrdL8TVPvIYyL+3hr8hLT4z9gbwuv6EPSHR NGQ4a7U8J/TQ7ZbouXA9XHjUqoPU4VrEU4/pSr3pfnoZiOw/xd3skpXlyvWzYWT9z2QaZXlrL hyltEVRf6DCdH1y5l6+vfSCUMTkWw8WPMAYAW7RJd3o+SXKlczriZfiR5MGhRgLrw+gXf56yF C4qYy11PA0CWuC0MFLf8A7TVYwbO9QXs6HztxLOUSLvUU5PPkITUwD2O/CUui352rmNyf27YI cfiOsHPF7+ynKYpX2t3yLhcPFVqHGa/FjoDyhzyxqtRRgti89hV5q/9ZaQWXT2BlMCPS0Zqtc iTcQtoY
Archived-At: <>
Subject: Re: [http-auth] WGLC on the MutualAuth drafts
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: HTTP authentication methods <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 07 Jul 2016 13:47:28 -0000

On 2016-07-07 15:32, 大岩寛 wrote:
> Dear Julian,
> My understanding of your message is that you'll just define the
> value encoding of I18n string, and all RFCs referring it must say,
> for example, "the value of parameter foo will be encoded by RFC5987bis,
> like foo=UTF-8''caf%C3%89 ."
> Is it right? If not, please forgive me and skip the rest of my message.

Something like that.

(did you want to say "foo*" here?)

> If it's true, in that case, I'm *not in favor* of "obsoleting" or "replacing"
> the current 5987 by it, as it simply drops the current feature, not replacing it.
> Both defining the value encoding
> And defining the general parameter extension framework
> is definitely the two existing features of current 5987.
> I'm relying basically on *the latter feature*.

The problem is that there isn't a generic parameter framework. For  
instance, header fields differ in whitespace and error handling.

(I agree that it would be good if there was something like that, but  
that's a separate discussion)

> The most important value of the current 5987 is that non-percent-encoded
> ASCII parameters and percent-encoded 5987-style parameters
> can co-exist and deterministically distinguished,
> while keeping ASCII-only use cases wire-compatible.
> Yes, it's a bit tricky encoding, but it works.
> If I need to say "this parameter will be 5987bis-value-encoded
> (so %20 MUST be treated as a space, not percent-two-zero)",
> it's no better than simple percent-encoded UTF-8,
> especially with cryptographic operations
> (which requires binary-to-binary equivalence and thus denies
> almost all kinds of character encoding negotiations).

We'll keep the recommendation to mark the use of the encoding by  
appending "*" to the parameter name, if that's what you're concerned about.

> ...

Best regards, Julian