Re: [http-auth] Alexey Melnikov's No Objection on draft-ietf-httpauth-extension-08: (with COMMENT)

Alexey Melnikov <> Sat, 03 September 2016 09:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9405712B03D; Sat, 3 Sep 2016 02:43:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.72
X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key) header.b=Zww08KYL; dkim=pass (1024-bit key) header.b=PKg+D6bI
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EvEcWa-WagLQ; Sat, 3 Sep 2016 02:43:02 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5652F126D74; Sat, 3 Sep 2016 02:43:02 -0700 (PDT)
Received: from compute6.internal (compute6.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 9D740201C6; Sat, 3 Sep 2016 05:43:01 -0400 (EDT)
Received: from frontend1 ([]) by compute6.internal (MEProxy); Sat, 03 Sep 2016 05:43:01 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed;; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=qV4aB7JiJ4TDCPLe/SsVGAFvdrw=; b=Zww08K YLpWsIyObd77FNdpG2UH3M1CSm+dD4zTPbtCEhp40SOAvNBOD4ENy0DdupGOa2bF Z+Yuxl4Gy+nfRYO2P2+vUIIVkhf6Bta+SrQ6VKfYr0hVMotNa5FW/NsBUfjiomIB A7O/Ql1QcMGOP04sAsTp6Kd0j/41ZhBL5TTkc=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=qV4aB7JiJ4TDCPL e/SsVGAFvdrw=; b=PKg+D6bIUNK8QfFS2brCPb7zpHx8HXdCNHgo5XwkqfWXVJ7 3kT3N3Ycr+ZSEbfs+6oEnbJ+BPaHl7SMFQuNC3YU16kC43cAkllQY4jTX6kh3mvg V9nMM6i/HN3BeNBYIAWSnb+JF3izfgn6YHkkFSUedQihfimnHzMZ1KQjfa/g=
X-Sasl-enc: 0LbW8dCEW4aoQmLizH+dZkCV5+f4+lhZBAGSMKuOYe0X 1472895781
Received: from [] (unknown []) by (Postfix) with ESMTPA id 3C027F29D6; Sat, 3 Sep 2016 05:43:01 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (1.0)
From: Alexey Melnikov <>
X-Mailer: iPhone Mail (13G35)
In-Reply-To: <>
Date: Sat, 03 Sep 2016 10:55:30 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: 大岩寛 <>
Archived-At: <>
Cc: "" <>, "" <>, The IESG <>, "" <>
Subject: Re: [http-auth] Alexey Melnikov's No Objection on draft-ietf-httpauth-extension-08: (with COMMENT)
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: Sat, 03 Sep 2016 09:43:03 -0000


On 3 Sep 2016, at 05:05, 大岩寛 <> wrote:

>> In Section 3, last paragraph:
>>   Support of this header is OPTIONAL; clients MAY also implement this
>>   extension only for some selected authentication schemes.  New
>>   authentication schemes can make support of the optional
>>   authentication mandatory by its specification, though.
>> I don't think this paragraph is needed, as this is granted, because support
>> for any extension like specified in this document is optional. So I suggest
>> deleting it.
> Of course, Experimental thing is always optional, as a starting point.
> But if we have two or more OPTIONALs, we need to clarify whether these are
> "one-by-one" or "all-or-nothing".
> What we wanted to assure here is that
> - It's optional support may vary between schemes.
>   For example, an implementation MAY choose to support it in Digest but not in Basic.
>   Also, implementation MAY choose only to support "username" and not "logout-timeout".
>   In this point, it's "one-by-one" OPTIONAL.

In this case I suggest that you either remove the first optional or rephrase this to say that there is no requirement to support this for all supported authentication schemes.
> - We have another "experimental" draft which normatively refers this draft and
>   requires implementation of this extension.
>   It's a kind of "all-or-nothing" (more precisely, "A implies B").
>   It does not contradict with the "experimental status" of this draft.
> These need a little more clarification than just saying "OPTIONAL" or "Experimental".
> If you have some solution to resolve it nicely, it's really appreciated.