Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-v2-bearer-15.txt> (The

Bjoern Hoehrmann <derhoermi@gmx.net> Wed, 25 January 2012 02:14 UTC

Return-Path: <derhoermi@gmx.net>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4C4211E80A2 for <oauth@ietfa.amsl.com>; Tue, 24 Jan 2012 18:14:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level:
X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[AWL=-2.300, BAYES_00=-2.599, J_CHICKENPOX_73=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZxx3wZwh2OJ for <oauth@ietfa.amsl.com>; Tue, 24 Jan 2012 18:14:12 -0800 (PST)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 98CBA11E809D for <oauth@ietf.org>; Tue, 24 Jan 2012 18:14:11 -0800 (PST)
Received: (qmail invoked by alias); 25 Jan 2012 02:14:09 -0000
Received: from dslb-094-222-155-127.pools.arcor-ip.net (EHLO HIVE) [94.222.155.127] by mail.gmx.net (mp070) with SMTP; 25 Jan 2012 03:14:09 +0100
X-Authenticated: #723575
X-Provags-ID: V01U2FsdGVkX1/iEsl6xNzirjiOEnuZRUC/6pe5bk7xZFHs3rJfku Gf5xMnIGkgmVu8
From: Bjoern Hoehrmann <derhoermi@gmx.net>
To: Mike Jones <Michael.Jones@microsoft.com>
Date: Wed, 25 Jan 2012 03:14:26 +0100
Message-ID: <2rkuh71k7eh4h1ciu15p6b2sss77u6qhtp@hive.bjoern.hoehrmann.de>
References: <4E1F6AAD24975D4BA5B168042967394366380094@TK5EX14MBXC284.redmond.corp.microsoft.com> from "Mike Jones" at Jan 25, 12 00:03:15 am <201201250028.q0P0SwiS000165@fs4113.wdf.sap.corp> <4E1F6AAD24975D4BA5B1680429673943663801ED@TK5EX14MBXC284.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943663801ED@TK5EX14MBXC284.redmond.corp.microsoft.com>
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
X-Mailman-Approved-At: Wed, 25 Jan 2012 05:27:14 -0800
Cc: "mrex@sap.com" <mrex@sap.com>, "oauth@ietf.org" <oauth@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
Subject: Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-v2-bearer-15.txt> (The
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Jan 2012 02:14:13 -0000

* Mike Jones wrote:
>Thanks for asking, Martin.  That's effectively what the spec does
>already.  It restricts the input values of these parameters to be quoted
>strings containing no backslashes.

Most XML parsers do not tell you, and most XML generators do not allow
you to control, the difference between <x y='z' /> and <x y="&#x7a"/>.
You could make a specification that says the value of the y attribute
on the x element must not be z, but it stops there. The difference be-
tween the two XML elements is in the lexical space, not in the value
space, the attribute value in both cases is "z", it's just encoded in a
different form.

Try writing a C function `int example(int i)` that returns `1` when it
is called like `example(00)` but returns `0` for `example(0)`. Without
some hack you can't do that because the C specification defines that it
does not matter whether you write `0` or `00` for an int. Same problem,
just as the C specification does not give you an interface to tell the
two inputs apart, the HTTP specification does not give you an interface
that allows you to tell `x` and `"x"` apart in this particular case. If
the draft said "When using WWW-Authenticate: Bearer ... then the header
name must be written `wWw-authenTICate`, same problem. HTTP says case
does not matter, and if another specification says "Yes, it does" then
it is overriding the underlying specification, to some degree anyway.

This is not always wrong, you might have coding guidelines for example
that tell you to write `example( 0 )` instead of `example(0)` and that
may work well with limited scope, but with coding guidelines people are
typically aware that they impose limits on formally equivalent things,
along with the understanding that if someone ignored the restriction the
code would work just as well, but that does not seem to be quite the
case here. If I make another scheme, WWW-Authenticate: Example, and say
all the parameters must be tokens, not quoted strings, and the tokens
must not contain "q" characters, but they are case-insensitive so you
can use "Q" to the same effect, would that be just as well?

If you want to keep the distinction, you should offer an argument why
this is something individual schemes should regulate (since having the
same rules for all schemes is much simpler).
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/