Re: RFC 9205 - Building Protocols with HTTP

Eric J Bowman <mellowmutt@zoho.com> Fri, 01 March 2024 22:27 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=ietf.org@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA37FC14F686 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 1 Mar 2024 14:27:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.855
X-Spam-Level:
X-Spam-Status: No, score=-7.855 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=w3.org header.b="VDa5ry9W"; dkim=pass (2048-bit key) header.d=w3.org header.b="ipwtXQXA"; dkim=pass (1024-bit key) header.d=zoho.com header.b="VvKr7bsc"
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6wOE4JFfoc2p for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 1 Mar 2024 14:27:20 -0800 (PST)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2FFAC14F684 for <httpbisa-archive-bis2Juki@ietf.org>; Fri, 1 Mar 2024 14:27:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=w3.org; s=s1; h=Subject:Content-Type:MIME-Version:References:In-Reply-To:Message-Id: Cc:To:From:Date:Reply-To; bh=74cfg3k4nFE0fNwltF9R8DHePsS1bIi2LUdUuQdHtNg=; b= VDa5ry9WZXRmy2ijfpNbOeNeRupLqGaj916Piqs+7kxo4jWlK3QwmUIxW/gE0GWYHGs9+OoebIpGz DCfBjgBEd9TL1/UJ8xPgFRG39/sUODbfJWnPVN2CbNIPghk6P4EzMqEsLnWqnjqc5v1SB4yqSOMIL S+X3qRfuwx7oKJ6j0bzVmfjHYCCVnK58sV3cM73ywolxx9FLHjXLNhQJFCTnupfq2IZvujB3mshyt 6i/TSQa2sthqha+clm/rnvfcZRAds05kXmZcyvYbAym2z6idrOdPdIMEWMIZruyt05k5W61TXdg/8 VNz1rWPGHVcFQZNJYdmVRjg1j1CwL06ChQ==;
Received: from lists by lyra.w3.org with local (Exim 4.94.2) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1rgBJb-00CTqV-Ae for ietf-http-wg-dist@listhub.w3.org; Fri, 01 Mar 2024 22:25:15 +0000
Resent-Date: Fri, 01 Mar 2024 22:25:15 +0000
Resent-Message-Id: <E1rgBJb-00CTqV-Ae@lyra.w3.org>
Received: from pan.w3.org ([3.222.182.102]) by lyra.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <mellowmutt@zoho.com>) id 1rgBJY-00CTpP-LU for ietf-http-wg@listhub.w3.org; Fri, 01 Mar 2024 22:25:13 +0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=w3.org; s=s1; h=Content-Type:MIME-Version:Subject:References:In-Reply-To:Message-Id: Cc:To:From:Date:Reply-To; bh=74cfg3k4nFE0fNwltF9R8DHePsS1bIi2LUdUuQdHtNg=; t=1709331912; x=1710195912; b=ipwtXQXA1PHFuBE5cEIFLl/GtPYXaVB72rvBPlnJ+MDNkHe GCh60VVPCXKykuyF2fhTBjJMdd6hzuiPbd+HxHc84JLRHUU86dmsvxsqpWamLwAwpJNo7o9J+1Jte 3+/ugayhijy6kPJ3bXyR0f/n5UjoE5ciR926CQKkBQS9w+7H8xwGMpqcEqq9U7TlfGcWwpJtmQZET vCa5d/ys5kTfhxiDF8eQ8UiuUK/NcGoKbFwq5rzWO6Bf2egplhdSGSk4xwl4Y68/AGD/gJf29pi6l tFOBuDKs8hAIbI5t3d/A+gzvM9lDacb+d9mCmscd8ZI5PMbv1edKuQYxMfgwbx6g==;
Received-SPF: pass (pan.w3.org: domain of zoho.com designates 136.143.188.91 as permitted sender) client-ip=136.143.188.91; envelope-from=mellowmutt@zoho.com; helo=sender4-pp-o91.zoho.com;
Received: from sender4-pp-o91.zoho.com ([136.143.188.91]) by pan.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from <mellowmutt@zoho.com>) id 1rgBJX-006HXt-2A for ietf-http-wg@w3.org; Fri, 01 Mar 2024 22:25:12 +0000
Delivered-To: mellowmutt@zoho.com
ARC-Seal: i=1; a=rsa-sha256; t=1709331907; cv=none; d=zohomail.com; s=zohoarc; b=m7UlKVwB1gsJNJzOgkHAahNvWLi1J5kD82iHB9gogKT1bQFzCC47thscsXsM0hq43lkpWzXnge+kGqZD4TfD77j4bdpUjByuX28CtH1zHyRACNaBjmzs33LyiEZ2G4AOaBGP7LKWngLUIYgY4k2choMiW4B/D8KP/au8aSYycqM=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1709331907; h=Content-Type:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; bh=74cfg3k4nFE0fNwltF9R8DHePsS1bIi2LUdUuQdHtNg=; b=U6tYXt2WBHxrbPJwm8D7SNH3rivuD6EXMQe46KtLG+fUE1xt270Tf2pA/c+FeWfJQapgb8QJafDwPfiCy0kT8NB6BegdvG7QKHk5JMU+EGqTZ+vCFAa/3ps6gzrsQhsFfdrXjVQU7nWG1xWDB6GvAbYUeSaqhES0Ap2kwRgDvfQ=
ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=zoho.com; spf=pass smtp.mailfrom=mellowmutt@zoho.com; dmarc=pass header.from=<mellowmutt@zoho.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1709331907; s=zm2022; d=zoho.com; i=mellowmutt@zoho.com; h=Date:Date:From:From:To:To:Cc:Cc:Message-Id:Message-Id:In-Reply-To:References:Subject:Subject:MIME-Version:Content-Type:Feedback-ID:Reply-To; bh=74cfg3k4nFE0fNwltF9R8DHePsS1bIi2LUdUuQdHtNg=; b=VvKr7bsc4HcmS9iCZAPRS3hG4GRGePd6Ru0IX+1Azr+E6msF6hiTMRSfs6J8F2XU 8ZQqjJkvLO/7RhEF0tFPmgrPkmqvreVsfqfQ4jBniZqeT5R51bY0ZTSIRydU62YBZ66 alxuT+lyl2Rdct4Y3vw5e5JdsKu/Inwc0ALF9U+s=
Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1709331904992340.6824599214099; Fri, 1 Mar 2024 14:25:04 -0800 (PST)
Received: from [65.117.211.248] by mail.zoho.com with HTTP;Fri, 1 Mar 2024 14:25:04 -0800 (PST)
Date: Fri, 01 Mar 2024 14:25:04 -0800
From: Eric J Bowman <mellowmutt@zoho.com>
To: Eric J Bowman <mellowmutt@zoho.com>
Cc: Ietf Http Wg <ietf-http-wg@w3.org>
Message-Id: <18dfc1ef9d2.adb301bf6950.5759870972372100510@zoho.com>
In-Reply-To: <18d10a55ec3.f9f4497962867.8435735395234285775@zoho.com>
References: <18d10a55ec3.f9f4497962867.8435735395234285775@zoho.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_18645_231368943.1709331904978"
Importance: Medium
User-Agent: Zoho Mail
X-Mailer: Zoho Mail
Feedback-ID: rr08011228d5ff03daaac180f1f2669d210000b98da43688fcbb3596ab75f1fa3b3320e5504e2e89feaa05d940:zu080112274d0767ad0e7dfd302ffd800b000059751d0e2c6f2ee728eb3a93219c7ad010b1e3766a0adf18da:rf080112267ac048f7a84c024c6f67c2e20000e0e5a8716e7ba1d8b057915a1c91b938a30485cd14909e81:ZohoMail
X-W3C-Hub-DKIM-Status: validation passed: (address=mellowmutt@zoho.com domain=zoho.com), signature is good
X-W3C-Hub-DKIM-Status: validation passed: (address=mellowmutt@zoho.com domain=mellowmutt@zoho.com), signature is good
X-W3C-Hub-Spam-Status: No, score=-2.2
X-W3C-Hub-Spam-Report: ARC_SIGNED=0.001, ARC_VALID=0.001, BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, DMARC_PASS=-0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: pan.w3.org 1rgBJX-006HXt-2A 58f9b170bc934add187ceaf4aed45eab
X-Original-To: ietf-http-wg@w3.org
Subject: Re: RFC 9205 - Building Protocols with HTTP
Archived-At: <https://www.w3.org/mid/18dfc1ef9d2.adb301bf6950.5759870972372100510@zoho.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/51851
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/email/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

My protocol translator is running in a BSD jail with no network stack/apps. It has access to COM1, which connects an RS-485 serial bus speaking MODBUS protocol. It speaks HTTP over FastCGI via POSIX IPC. If you want to send data to a device (calibration factor to a pH sensor probe), you need 'x' permission on the file handle for that IPC socket. So, no MODBUS TCP, or HTTP behavior in jail, or ya go in the (/dev/null) hole! The following, are the values I send over MODBUS to a multifunction, submerged soil probe in an aquarium -- for this example and audience, I'm not using MODBUS syntax:



0x03 : COM1 : 0x01 : 40014 : 0013H : 0x12 : 0x02

GET example.org/fishroom1/aquarium1/{substrate|water}/temperature?scale={F|C|K}



Remember, this is an abstraction layer, we're hiding implementation details behind a uniform interface. The MODBUS response is a hex value which equals 9,427 "ohms of resistance measured across a thermistor". I default to F, so my httpd is configured to default to F (80 degrees in this case) in absence of the query string. The protocol translator is configured for the serial device in question, e.g. "has a 10K ohm = room temperature NTC thermistor circuit". Some other device might have cryogenic range, using a PTC thermistor where 10K ohms maps to absolute zero. Not in my fish room!



Speaking of abstraction, the jail has no idea its host FreeBSD is in a Zone administered by Tribblix running on a Sun T5120 (SPARC T2, 128GB, 1.8GHz 8-core NOS from bitd, Oracle EOL'd it before I ever unboxed it, talk about a rug-pull). My httpd is tightly integrated with UNIX security, 'w' allows PUT to reconfigure the translator, but 'x' is required have a POST sent out COM1 to a device...



POST example.org/fishroom2/aquarium1/water/pH?calibrate=6.8

(fishroom2 = COM2, actually COM7 on my laptop)



The pH=6.8 value comes from a handheld instrument, the translator knows how to make the MODBUS request to tell the buried sensor what its "drift" is, by sending it 0x2A8. The translator knows what to make of a MODBUS response value of 0x2A8 -- that's 680 = 6.8 pH. We want the HTTP response to say pH=6.8, not 0x2A8. And this is why we don't want to use MODBUS TCP, which sends register addresses and offsets over the Internet, exposing your infrastructure blueprint on the wire. My MODBUS traffic does not go over the WAN.



The 0x01 and 0x02 devices are in aquarium 1. The next three devices, are in aquarium 2. This logical hierarchy isn't reflected anywhere in MODBUS, it's added in by the abstraction layer (protocol translator). My httpd in the FreeBSD zone, and my translator in the jail, both parse XProc 3 config files into a nice "tree" data structure I can hit with recursive XQUERY's, e.g. there's a "/fishroom1" node which contains the particulars of the FCGI IPC socket for the protocol translator in the jail bound to COM1. All my apps are jailed like this. Legacy custom WordPress install on PHP 4.3? Do not pass Go, do not collect $200...



Once that socket's established, r-w-x permissions on its file handle lead to HTTP response codes based on the method, i.e. if you don't have 'x' your POST won't make it into the jail, you'll get 401/403. This is a uniform interface, not what's come to be known as a "REST API". MODBUS translates really well, once you understand that a 0x03 function code in an interrogation frame, is really just a GET. Not a MODBUS query POSTed to an endpoint! The resource is the register address of the sensor being interrogated, which a device has one or more of, which may have sub-resources, which are at different offsets (and lengths) within a register. With no sense of the hierarchical nature of the resources or their logical groupings.



BTW, stackless BSD jail isn't all that difficult, but you do need to globally find/replace 127.0.0.1 with 0.0.0.0 across all text files, handful of things will hang the boot waiting for loopback to initialize, but they're TCP-aware so they'll just fail and continue with all zeros. Yeah, I'm running FreeBSD on SPARC! Swap the four-disk striped-mirror ZFS with Tribblix, for the drives I installed NetBSD on, same ZFS RAID root pool can run a clone of the FreeBSD zone. L2ARC on 160GB HPE SLC SSD PCIe x4 card, I have two, one for each OS. This is a few hundreds of dollars' worth of NOS hardware resources.



Using MONT protocol, the DR (DeReference) method is GET, RE (REsolve) is HEAD, there is no POST equivalent, PA (tch) implements DARCS, and if I need to offline a pH probe to calibrate it to a reference standard solution I use INhibit and ReStore -- the translator does chmod 0000 on IN and chmod 0764 (or whatnot) on RS. The montd responds 503 (equivalent) if it sees 0000 on the referenced file handle, unless you sent the IN request. But, this is HTTP so we just use POST for everything and introspect deeper than a log file to get a sense of what the application is doing.



INHIBIT and RESTORE methods are there in the deep history of HTTP, can't remember where, just that I ripped 'em off for my in-house protocol. Surfacing to this list, is on-topic particularly when it comes to fleshing out the pros and cons of vendor-specific methods in RFC 9205. They could also trigger a server to respond 402 if the chmod is 0740, in my way of doing things, failed payment for webhosting. Very specific semantics of temporarily off-lining a resource for maintenance, recalibration, etc. which can be spelled out in the message entity of various 4xx/5xx possibilities.


-Eric