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
>>
>