IETF Logo Mail Archive

Re: [art] Artart last call review of draft-ietf-core-links-json-07

"Roy T. Fielding" <fielding@gbiv.com> Tue, 25 April 2017 20:09 UTC

Return-Path: <fielding@gbiv.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D31651294BD; Tue, 25 Apr 2017 13:09:42 -0700 (PDT)
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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gbiv.com
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 zO3d1RO-ttsv; Tue, 25 Apr 2017 13:09:41 -0700 (PDT)
Received: from homiemail-a42.g.dreamhost.com (sub5.mail.dreamhost.com [208.113.200.129]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 822F2128CD5; Tue, 25 Apr 2017 13:09:41 -0700 (PDT)
Received: from homiemail-a42.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a42.g.dreamhost.com (Postfix) with ESMTP id E59779018A3E; Tue, 25 Apr 2017 13:09:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=content-type :mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=768msT/pCVcCIOXkVMHTvPXcNI8=; b=HKj2hRl35LJd8eNI/Hrp1nCP1VC9 LA29bFPPLMxkvx2idjdYgDl1FscwyCbzj6ZyJ98EuSGm9va3KYzrUeT0r47PUZll Zh8l3Hi600mLG6qa4rHfcx8ezTsK3heIvhmXm8KFD+tTPKSAM27Z2FeUCKP5ycJ6 McWkBzelJXKWWPQ=
Received: from [192.168.1.8] (ip68-228-71-159.oc.oc.cox.net [68.228.71.159]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by homiemail-a42.g.dreamhost.com (Postfix) with ESMTPSA id ADC1C9018A3C; Tue, 25 Apr 2017 13:09:40 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Subject: Re: [art] Artart last call review of draft-ietf-core-links-json-07
From: "Roy T. Fielding" <fielding@gbiv.com>
In-Reply-To: <23DDC7F2-D46F-4C19-AEA8-C71187099414@tzi.org>
Date: Tue, 25 Apr 2017 13:09:40 -0700
Cc: Julian Reschke <julian.reschke@gmx.de>, IETF <ietf@ietf.org>, art@ietf.org, draft-ietf-core-links-json.all@ietf.org, "core@ietf.org WG" <core@ietf.org>, Erik Wilde <erik.wilde@dret.net>, Herbert Van de Sompel <hvdsomp@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <A43ECEE0-47C8-485C-A9AC-E7890B0A6AA4@gbiv.com>
References: <149188258769.15738.17473942496982365590@ietfa.amsl.com> <A12A8CB3-F756-4790-806A-A67AA8CE1D78@tzi.org> <CAOywMHdqitw-uN09p11j2xkBK6TO8y3wjAWipK7vhqbTWp0T1w@mail.gmail.com> <a2350664-05a7-8909-4cf4-5b765e09f9e7@dret.net> <027F2C41-E498-4801-86E2-047771E10545@tzi.org> <4cd01462-2a0f-803e-df10-e68b3eed0226@dret.net> <B04F33DD-51C1-4545-AD59-2F1A3AF14FF6@tzi.org> <feee7d84-263a-49e4-d95e-09ab8526b703@dret.net> <CAOywMHfJpYB6u7BFVf10Gf=Nxk0E1h5iEvyVX5VeAW0UKQOSzQ@mail.gmail.com> <5EB045F7-09FA-4EE8-844A-5AC0E3BF5C1E@tzi.org> <f1b9f42f-559d-d146-e355-c3e2ba31cb01@gmx.de> <23DDC7F2-D46F-4C19-AEA8-C71187099414@tzi.org>
To: Carsten Bormann <cabo@tzi.org>
X-Mailer: Apple Mail (2.2104)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/-NrXqeFt46TwRZC3JqwatmdcOOw>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Apr 2017 20:09:43 -0000

> On Apr 25, 2017, at 11:59 AM, Carsten Bormann <cabo@tzi.org> wrote:
> 
> On Apr 25, 2017, at 18:46, Julian Reschke <julian.reschke@gmx.de> wrote:
>> 
>> Do you have a specific problem in mind?
> 
> This work was done half a decade ago (May 18, 2012, that is), so I don’t remember all the details.
> RFC 6690 says:
> 
>   In
>   order to convert an HTTP Link Header field to this link format, first
>   the "Link:" HTTP header is removed, any linear whitespace (LWS) is
>   removed, the header value is converted to UTF-8, and any percent-
>   encodings are decoded.

Well, that's broken.

> So we get rid of all that fun before it becomes RFC 6690 (and CoAP of course is all UTF-8 in any case).
> 
> So far, we have run into one real case where that approach is a limitation, and that is in URIs:
> 
> The link
> 
> coap://example.com?stupid%3Dkey=4711
> 
> is not distinguishable from
> 
> coap://example.com?stupid=key=4711
> 
> (The typical reaction of an implementer is “then don’t do that!” [1,2].)

That isn't a "limitation".  It's a bug to decode pct-encoded octets in
a URI before decomposing the reference into its parts.  ASCII is already
in UTF-8.  Decoding a pct-encoding doesn't make it "more UTF-8"; it just
means the string is no longer a URI reference.  That's broken.  So utterly
broken that it obviously wasn't reviewed by the right people.

> We know that because the CoAP protocol itself also completely runs in the UTF-8 domain (there is no percent encoding on the wire); I’m not sure that simplification actually hurt in RFC 6690 use cases yet.

*sigh*

....Roy

v2.23.0 | Report a Bug | By Email