Re: [art] Revising BCP56: On the use of HTTP as a Substrate
Ira McDonald <blueroofmusic@gmail.com> Sun, 16 July 2017 12:41 UTC
Return-Path: <blueroofmusic@gmail.com>
X-Original-To: art@ietfa.amsl.com
Delivered-To: art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE011130133 for <art@ietfa.amsl.com>; Sun, 16 Jul 2017 05:41:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 SANwCv_DuC7t for <art@ietfa.amsl.com>; Sun, 16 Jul 2017 05:41:50 -0700 (PDT)
Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD3C11300BC for <art@ietf.org>; Sun, 16 Jul 2017 05:41:49 -0700 (PDT)
Received: by mail-qk0-x22e.google.com with SMTP id d78so103765464qkb.1 for <art@ietf.org>; Sun, 16 Jul 2017 05:41:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tWYWjl7lc0nJ/yfj173/x12FXwIInvHeXfZ5g5xwSrY=; b=jxQUgqYFm8nA+kKQJRHuI1kwoHs2ENxQRfMLvbu22EV4SHRtbpdSuIP/7yKXyAL5ww c1XmRM5SolUkd5eqNxXR9FTihJdw2x6mFhRe4NPzOQaCI/sEZDaB2eXmQQ0kjUYhQPyy zeOaxX6Qi67dPIFWUTeW7HuECX1WkwQp4QAvaemBpbfGvwxzP0oVv2kuv4WdMIsFQqDo AcQFcIADH5v39NblIFYMs52/rAF4bpaQNTz+NpjKPFDESjCQw7kjPVFGBHlQplfuZwT3 aZoRperFZffqJPuWyyyZy36U+Oxxce6AcII645gjoAVwmI8Ius+E4q4iOUii4DFLY/el E/9g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tWYWjl7lc0nJ/yfj173/x12FXwIInvHeXfZ5g5xwSrY=; b=UCqwlGTBDelJQa9h8oApOIhnxW2pz/DCG/g79ssMTCBd6vJqjBUWJueoVV7BXpNfGL Ji8eQnvflUcwePJF5R57ON4rLNpY3PKfrb3Yq13Wn80pdwnz/zg3/q81bpz2gefgvDRN FYxooT9ZH8SMxs7eDdknHDogLf0jjm2Hp/z+FAqcT+iV1ipnodwdHuROy8LvXVnWKx4W YBrNeWOLnHVoahxwdoXV9+NpqSuvnlXLPGV44igsYXFupPDQpmsqDsxtskKCSU6UsGM8 KuISlRbZjuYWM2I0nJ8B/d1lFF0FP3a/1m8uOQppm0XD+ZWz6C+aAtsYz25fJ8tbx7eK LQ4A==
X-Gm-Message-State: AIVw112fKJ8HnuXb16QtR4Jw38sbo1zQTQwlpJSeh/77KTKt9k19h//G 6QAdxB74dvAj69RnVhNXUkA6hwemUQ==
X-Received: by 10.55.27.83 with SMTP id b80mr20788882qkb.148.1500208909064; Sun, 16 Jul 2017 05:41:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.43.101 with HTTP; Sun, 16 Jul 2017 05:41:28 -0700 (PDT)
In-Reply-To: <cc70eccc-b19f-a966-dc1d-0e67b42eea46@it.aoyama.ac.jp>
References: <83273F06-63D3-41C1-BC3C-9ECE401C2279@mnot.net> <ebabe106-d914-f21b-30c2-f91f583f4de5@nostrum.com> <DE1772EA-E54A-4FC5-AF5B-6958477B0F44@mnot.net> <CA+9kkMCaSqH=RwQgKJaLdRWA8mYnGL2Lw=cb20Szx4O__mg_Hw@mail.gmail.com> <989a76b8-7006-5c9b-66cb-0a03f8e9e517@nostrum.com> <CAN40gSvM118c+JUD8kp-K9Noz7BQxYcnLgAoe5QJCt_V=Zq95w@mail.gmail.com> <cc70eccc-b19f-a966-dc1d-0e67b42eea46@it.aoyama.ac.jp>
From: Ira McDonald <blueroofmusic@gmail.com>
Date: Sun, 16 Jul 2017 08:41:28 -0400
Message-ID: <CAN40gStKReRYijsKW8tCCoZoHcKinarKCGf+uYSLTinDFs_e0A@mail.gmail.com>
To: "Martin J. Dürst" <duerst@it.aoyama.ac.jp>
Cc: Adam Roach <adam@nostrum.com>, Alexey Melnikov <alexey.melnikov@isode.com>, Ted Hardie <ted.ietf@gmail.com>, Mark Nottingham <mnot@mnot.net>, art@ietf.org, Patrick McManus <mcmanus@ducksong.com>
Content-Type: multipart/alternative; boundary="001a1147f15c1d1dcf05546e9b82"
Archived-At: <https://mailarchive.ietf.org/arch/msg/art/KL_thx8X0z34TfKWDnuItJ4zIaI>
Subject: Re: [art] Revising BCP56: On the use of HTTP as a Substrate
X-BeenThere: art@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Applications and Real-Time Area Discussion <art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/art>, <mailto:art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/art/>
List-Post: <mailto:art@ietf.org>
List-Help: <mailto:art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/art>, <mailto:art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 16 Jul 2017 12:41:52 -0000
Hi Martin, I'll try to be more specific: IPP uses a unique binary encoding of its primitive datatypes (integer, language-tagged string, keyword (registered) as distinct from name (vendor free-form), etc.). So the HTTP payload of IPP is opaque. IPP original authors were told that using an HTTP substrate would make penetrating firewalls easier - it didn't of course. IPP "resources" do not correspond to the general HTTP idea of resources, so the semantics of HTTP Get on an IPP URI are surprising. IPP uses HTTP POST for the main operation requests. The fact that the wrapper was HTTP has led to numerous problems with intermediate entities attempting to optimize/cache/whatever the IPP operation requests and responses. HTTP Basic and Digest were supposed to be good authentication methods - but they're weak and have been largely replaced by Kerberos, OAuth, etc., in practice. Printer vendors sometimes re-invented their own HTTP layers (LOTS of bugs) or pasted in HTTP layers from immature sources (and then never maintained them). What IPP needed was a TLS connection for end-to-end authentication and encryption. Modern printers almost universally use TLS "under" their HTTP layer, as is mandated by IPP Everywhere (IEEE-ISTO PWG 5100.14). IPP is ubiquitous (over 98% of all printers sold in recent years), but the HTTP layer was just used as an over-complicated way of getting a TLS connection. I hope this helps explain my aversion to the use of HTTP in the IPP protocol stack. Cheers, - Ira Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@gmail.com Jan-April: 579 Park Place Saline, MI 48176 734-944-0094 May-Dec: PO Box 221 Grand Marais, MI 49839 906-494-2434 On Sun, Jul 16, 2017 at 1:42 AM, Martin J. Dürst <duerst@it.aoyama.ac.jp> wrote: > Hello Ira, > > On 2017/07/16 00:22, Ira McDonald wrote: > >> Hi, >> >> Speaking as the co-editor of both the "ipp" and "ipps" URI schemes and the >> successor (RFC 8010) to RFC 2910, using HTTP as a substrate for IPP was >> a serious design mistake that has added numerous implementation errors and >> no functional value. >> > > Can you be a bit more specific, or point to something more specific? > > Regards, Martin. > > > One prominent (non-conforming) implementation of IPP does use port 443, >> but that's just plain wrong and fails the IEEE-ISTO PWG IPP Everywhere >> conformance certification tests. >> >> Please don't use IPP as justification in this discussion. The use of HTTP >> as >> a substrate was based on bad advice from IETF regulars who should have >> known better. >> >> [ok - back into my cave...] >> >> Cheers, >> - Ira >> >
- [art] Revising BCP56: On the use of HTTP as a Sub… Mark Nottingham
- Re: [art] Revising BCP56: On the use of HTTP as a… Eliot Lear
- Re: [art] Revising BCP56: On the use of HTTP as a… Joe Touch
- Re: [art] Revising BCP56: On the use of HTTP as a… Adam Roach
- Re: [art] Revising BCP56: On the use of HTTP as a… Ben Campbell
- Re: [art] Revising BCP56: On the use of HTTP as a… Ted Hardie
- Re: [art] Revising BCP56: On the use of HTTP as a… Mark Nottingham
- Re: [art] Revising BCP56: On the use of HTTP as a… Adam Roach
- Re: [art] Revising BCP56: On the use of HTTP as a… Adam Roach
- Re: [art] Revising BCP56: On the use of HTTP as a… Ira McDonald
- Re: [art] Revising BCP56: On the use of HTTP as a… Martin J. Dürst
- Re: [art] Revising BCP56: On the use of HTTP as a… Dave Thaler
- Re: [art] Revising BCP56: On the use of HTTP as a… Mark Nottingham
- Re: [art] Revising BCP56: On the use of HTTP as a… Dave Thaler
- Re: [art] Revising BCP56: On the use of HTTP as a… Mark Nottingham
- Re: [art] Revising BCP56: On the use of HTTP as a… Ira McDonald
- Re: [art] Revising BCP56: On the use of HTTP as a… Roy T. Fielding
- Re: [art] Revising BCP56: On the use of HTTP as a… Mark Nottingham
- Re: [art] Revising BCP56: On the use of HTTP as a… Ted Hardie
- Re: [art] Revising BCP56: On the use of HTTP as a… Mark Nottingham