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

Julian Reschke <julian.reschke@gmx.de> Thu, 07 July 2016 13:47 UTC

Return-Path: <julian.reschke@gmx.de>
X-Original-To: http-auth@ietfa.amsl.com
Delivered-To: http-auth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19EEA12D0CF for <http-auth@ietfa.amsl.com>; Thu, 7 Jul 2016 06:47:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zcc8re2tP17l for <http-auth@ietfa.amsl.com>; Thu, 7 Jul 2016 06:47:26 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B24312B005 for <http-auth@ietf.org>; Thu, 7 Jul 2016 06:47:25 -0700 (PDT)
Received: from [192.168.1.123] ([5.10.171.186]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LxPgU-1bMssn3PuU-016xqT; Thu, 07 Jul 2016 15:47:19 +0200
To: =?UTF-8?B?5aSn5bKp5a+b?= <y.oiwa@aist.go.jp>, Yoav Nir <ynir.ietf@gmail.com>, httpauth mailing list <http-auth@ietf.org>
References: <2DBE893A-434D-4B67-BF12-AEFBDE7A23B7@gmail.com> <32b9df1f-b61d-405e-d935-5d964d9acbb6@gmx.de> <TY1PR01MB0588EA2490634AD993244DF1A0390@TY1PR01MB0588.jpnprd01.prod.outlook.com> <084b1a6f-3d32-ef37-da7c-7ed6d958974c@gmx.de> <TY1PR01MB05887032D226640D341DDFDBA03B0@TY1PR01MB0588.jpnprd01.prod.outlook.com>
From: Julian Reschke <julian.reschke@gmx.de>
Message-ID: <e66b021e-ed39-01aa-fc5b-3148b128d200@gmx.de>
Date: Thu, 7 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: <TY1PR01MB05887032D226640D341DDFDBA03B0@TY1PR01MB0588.jpnprd01.prod.outlook.com>
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: <https://mailarchive.ietf.org/arch/msg/http-auth/LBEZ4DbMPS8DOlmiCPZi7euiHrs>
Subject: Re: [http-auth] WGLC on the MutualAuth drafts
X-BeenThere: http-auth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: HTTP authentication methods <http-auth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/http-auth>, <mailto:http-auth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/http-auth/>
List-Post: <mailto:http-auth@ietf.org>
List-Help: <mailto:http-auth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/http-auth>, <mailto:http-auth-request@ietf.org?subject=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